How to adjust ADSL SNR offset?

Looks good.

Nice work.

Keep an eye on the log if/when you get disconnects.

You can further narrow down results by including time of day...

Specific date and time (example - 5 PM hour)...

logread | grep 'May 14 17:'

1 Like

Some friendly advice.

You also posted this issue on reddit -

Whenever you cross-post, it's considered a courtesy to include the link(s) to the other site(s) you've posted the issue on.

It helps eliminate confusion, and wasting other people's time researching and suggesting things that have already been done.

Thanks.

1 Like

Aight thanks.

The connection hasn't dropped yet after completely disabling the IPv6, but I'm not entirely sure yet if it is because of the night (has always seemed more stable at night).

Do you know if it's possible to see error counts on the more recent OpenWrt versions? IIRC 18.something used to show error statistics on the status page.

And of course as I was typing the previous comment, the connection dropped again..

Sat May 14 02:17:47 2022 authpriv.notice dropbear[4530]: Password auth succeeded for 'root' from 192.168.0.110:58990
Sat May 14 02:49:18 2022 kern.warn kernel: [ 2290.833105] leave showtime
Sat May 14 02:49:18 2022 daemon.notice netifd: Network device 'dsl0' link is down
Sat May 14 02:49:18 2022 daemon.notice netifd: Interface 'wan' has link connectivity loss
Sat May 14 02:49:19 2022 daemon.notice netifd: wan (3191): udhcpc: received SIGTERM
Sat May 14 02:49:19 2022 daemon.notice netifd: wan (3191): udhcpc: unicasting a release of 91.xxx.xxx.xxx to 195.74.2.54
Sat May 14 02:49:19 2022 daemon.notice netifd: wan (3191): udhcpc: sending release
Sat May 14 02:49:19 2022 daemon.notice netifd: wan (3191): udhcpc: entering released state
Sat May 14 02:49:19 2022 daemon.notice netifd: wan (3191): Command failed: Permission denied
Sat May 14 02:49:19 2022 daemon.notice netifd: Interface 'wan' is now down
Sat May 14 02:49:19 2022 daemon.notice netifd: Interface 'wan' is disabled
Sat May 14 02:49:19 2022 daemon.notice netifd: Interface 'wan' is enabled
Sat May 14 02:49:19 2022 daemon.warn dnsmasq[2483]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry
Sat May 14 02:50:07 2022 kern.err kernel: [ 2339.213710] [DSL_BSP_Showtime 914]: Datarate US intl = 1078767, fast = 0
Sat May 14 02:50:07 2022 kern.warn kernel: [ 2339.219088] enter showtime, cell rate: 0 - 2544, 1 - 2544, xdata addr: 0x833a0000
Sat May 14 02:50:07 2022 kern.info kernel: [ 2339.226665] IPv6: ADDRCONF(NETDEV_CHANGE): dsl0: link becomes ready
Sat May 14 02:50:07 2022 daemon.notice netifd: Network device 'dsl0' link is up
Sat May 14 02:50:07 2022 daemon.notice netifd: Interface 'wan' has link connectivity
Sat May 14 02:50:07 2022 daemon.notice netifd: Interface 'wan' is setting up now
Sat May 14 02:50:07 2022 daemon.notice netifd: wan (5327): udhcpc: started, v1.33.2
Sat May 14 02:50:08 2022 daemon.notice netifd: wan (5327): udhcpc: sending discover
Sat May 14 02:50:10 2022 daemon.notice netifd: wan (5327): udhcpc: sending discover
Sat May 14 02:50:10 2022 daemon.notice netifd: wan (5327): udhcpc: sending select for 91.xxx.xxx.xxx
Sat May 14 02:50:10 2022 daemon.notice netifd: wan (5327): udhcpc: lease of 91.xxx.xxx.xxx obtained, lease time 14400
Sat May 14 02:50:10 2022 daemon.notice netifd: Interface 'wan' is now up
Sat May 14 02:50:10 2022 daemon.info dnsmasq[2483]: reading /tmp/resolv.conf.d/resolv.conf.auto
Sat May 14 02:50:10 2022 daemon.info dnsmasq[2483]: using only locally-known addresses for domain test
Sat May 14 02:50:10 2022 daemon.info dnsmasq[2483]: using only locally-known addresses for domain onion
Sat May 14 02:50:10 2022 daemon.info dnsmasq[2483]: using only locally-known addresses for domain localhost
Sat May 14 02:50:10 2022 daemon.info dnsmasq[2483]: using only locally-known addresses for domain local
Sat May 14 02:50:10 2022 daemon.info dnsmasq[2483]: using only locally-known addresses for domain invalid
Sat May 14 02:50:10 2022 daemon.info dnsmasq[2483]: using only locally-known addresses for domain bind
Sat May 14 02:50:10 2022 daemon.info dnsmasq[2483]: using only locally-known addresses for domain lan
Sat May 14 02:50:10 2022 daemon.info dnsmasq[2483]: using nameserver 193.229.0.40#53
Sat May 14 02:50:10 2022 daemon.info dnsmasq[2483]: using nameserver 193.229.0.42#53
Sat May 14 02:50:11 2022 user.notice firewall: Reloading firewall due to ifup of wan (dsl0)
Sat May 14 02:50:59 2022 authpriv.info dropbear[4530]: Exit (root) from <192.168.0.110:58990>: Exited normally
Sat May 14 02:51:06 2022 authpriv.info dropbear[5612]: Child connection from 192.168.0.110:59676
Sat May 14 02:51:12 2022 authpriv.notice dropbear[5612]: Password auth succeeded for 'root' from 192.168.0.110:59676
Sat May 14 02:52:07 2022 authpriv.info dropbear[5612]: Exit (root) from <192.168.0.110:59676>: Exited normally
Sat May 14 02:52:40 2022 authpriv.info dropbear[5630]: Child connection from 192.168.0.110:59684
Sat May 14 02:52:43 2022 authpriv.notice dropbear[5630]: Password auth succeeded for 'root' from 192.168.0.110:59684
Sat May 14 02:52:51 2022 authpriv.info dropbear[5630]: Exit (root) from <192.168.0.110:59684>: Exited normally
Sat May 14 02:53:02 2022 authpriv.info dropbear[5641]: Child connection from 192.168.0.110:59699
Sat May 14 02:53:05 2022 authpriv.notice dropbear[5641]: Password auth succeeded for 'root' from 192.168.0.110:59699

There should be a DSL stats page where you can check CRC and HEC errors.

If you find it, post those.

I don't think this image has such DSL stats page either, iirc I saw from the older OpenWrt version (which still showed the errors), that there used to be a flow of CRC and HEC errors just prior to dropping the connection. My Asus router does get similar bursts or errors (lower error count), but it doesn't drop the connection.

Looking at the logread, the device dropped the connection 23 times while I was sleeping, so I think I'll have give up trying to use this device as a modem, and maybe use it just as a router instead.

Still, thanks a lot for helping.

The DSL connection or only something running on top of it like a PPPoE connection? If it is the former than you might want to think about replacing that device completely...

Yeah, it's the former I'm afraid.

It is possible that the OEM firmware uses better-debugged drivers/firmware blobs and stability might increase with switching back, but that is no way guaranteed.

Personally I had issues with an xrx200 modem running OpenWrt for a long time on a VDSL2 link, so much in fact that I switched to using a broadcom-SoC based modem (configured in bridge-mode) in front of my router (instead of the xrx200 modem running OpenWrt which I also used as dedicated bridge-mode modem in front of the same router). Recent changes in OpenWrt's xrx200 dsl drivers solved that long standing issue and I switched back to the OpenWrt modem (stability is now on par with the broadcom's multiple month between unforced resyncs, compared to the unforced resyncs multiple times a week with the buggy driver). I guess my point is, software can have a significant effect on a modem's stability so trying different alternatives seems worth your time.

Also if you switch to using a bridged modem in front of an OpenWrt router, exchanging the modem gets less painful compared ot replacing an all in one router...

The OEM firmware showed exact same behavior, which is why I tried OpenWrt.

Do you know if it would be possible to configure the DGN3500 as a router only? It doesn't have any dedicated WAN ports, so I'd have to use one of the LAN ports if that works.

My Asus router is pretty stable as a modem, but it doesn't support OpenWrt sadly, so I'll have to use two devices if I want to use SQM. I'm total newb with routers, only used a single modem/router combo devices in the past.

Aye, then it seems time to:
a) bother your ISP
b) try to figure out why your link goes down so often*
c) try completely different hardware

That probably is possible, I have no first hand experience though. I would probably opt for a somewhat faster/more modern basis for a router, but I understand that might not be feasible or desirable for many reasons.

Okay, that seems to indicate that your ADSL issue is solvable!

Configuring a dedicated port on the LAN switch as WAN does not sound like rocket science, but also not something I have done (recently, my experience is a decade ago, not helpful in how to configure that on modern OpenWrt in detail)... Maybe start a new thread with a fitting title like "How can I configure a Netgear DGN3500 for ethernet WAN" or similar.... to attract forum members that might have more recent first hand experience?

*) The root cause can be external RF interference sources your ISP has little control over.

My ISP is getting rid if the copper lines probably within this year, so I don't think I'm going to bother them about the line quality anymore.

Sucks that I'll be left with 4G connection after the ADSL is gone, but luckily 4G is pretty decent in my country, no data caps, ping is almost as good as with ADSL.
Although I'm not a fan of the massively fluctuating download speeds, I had 4G for a while (from the same ISP as my current DSL is), and in the evenings my DL speed dropped to 3-8Mbps. At middle of the night I got like 140Mbps speeds.

Okay, that seems to indicate that your ADSL issue is solvable!

Yeah, I can solve it with manual SNR offset :upside_down_face:
But even with the Asus DSL-N17U, I still get some occasional errors with the maximum -10dbm offset.

Yeah I'll start a new thread if I can't figure out how to configure the DGN3500 as a router, thanks for your help.

You might be able to get some stats out of the OpenWrt modem using the following commands:

echo "PM_ChannelCountersShowtimeGet 0 0 0" > /tmp/pipe/dsl_cpe0_cmd; cat /tmp/pipe/dsl_cpe0_ack
#output: nReturn=0 nChannel=0 nDirection=0 nHistoryInterval=0 nElapsedTime=577084 bValid=1 nCodeViolations=6 nFEC=0
echo "PM_ChannelCountersShowtimeGet 0 1 0" > /tmp/pipe/dsl_cpe0_cmd; cat /tmp/pipe/dsl_cpe0_ack
#output: nReturn=0 nChannel=0 nDirection=1 nHistoryInterval=0 nElapsedTime=577095 bValid=1 nCodeViolations=319 nFEC=3639

Can't test with the DGN3500 currently as there's other family members using the connection, but here's some old stats, I'd imagine they are looking very similar as currently.

I would ask your ISP to do a line test.

You're paying for this service...until they actually get rid of the copper lines.

My ISP already took the ADSL connection away from me once, and gave me the awful working 4G connection as a replacement.
The 4G worked so slow in the evenings, I complained to my country's "communications agency" about it, which resulted in them (the agency) forcing my ISP to return the ADSL connection to me.
So if I complained about it the line quality now, I'm 99% sure they'd just expedite the copper line removal process, which I want to avoid even if they upgraded their 4G towers in the area.

Anyway I just got the DGN3500 to work as a router behind the N17U working as a bridge, so I'm happy now.

Quick note, if you get switched to LTE/5G only have a look at @Lynx's great CAKE-autorate thread https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848
This is targeted at keeping acceptable bufferbloat on variable rate links like LTE through using active delay measurements to adjust a traffic shaper continuously.

EDIT: typos... bad eye sight, small screen, and touch keyboard -> loads of typos

2 Likes

Nice, I've been wondering if something like that exists, thanks.

Living in the Scottish Highlands, the only available option for our household is 4G (else 4Mbit/s ADSL). Our 4G rate varies between 10Mbit/s to 70Mbit/s (depending on congestion).

The bash script linked at the top of the adaptive rate thread was developed out of my frustration with having to set a single static compromise bandwidth for both download and upload for CAKE, and it seems to do a fantastic job at keeping latency low, whilst at the same time offering download and/or upload excursions for whenever heavy downloading or uploading is needed. After working on it for many months, I now just run it as a service 24/7. It seems quite a few others use it now too, and so hopefully it will improve things for you if you do need to work with 4G.

For me CAKE plus the adaptive rate code means latency stays between 40-80ms and I get to use the available bandwidth when needed. So the connection is responsive, Zoom and Teams calls work well, and downloads or uploads will get allocated as much bandwidth as possible without hurting latency.

If you do try out the code please report your findings - good or bad - on the thread.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.