I have a question about ADSL stability in Lantiq based devices. I am using TpLink W8980 with ADSL2+ and I must say that line synchronization is worse than Broadcom ADSL. As I have a Broadcom router already, there are very few disconnections if any but with this device, sometimes I can barely connect to internet. It keeps syncing but fails to do so for so many times until it gets connected. It can also be a configuration issue maybe but I have no idea since documentation in this regard is very much limited.
So my question is whether Broadcom devices are more reliable than Lantiq ones or the configuration for Lantiq devices under Openwrt/Lede needs more attention? Thanks
You're right, xDSL connection instability can be a problem on lantiq devices with OpenWrt. I have ADSL, too and previously used a TP-Link Archer VR200v as DSL modem and experienced disconnects under high load. These started to occur more often in the last weeks and I tried to debug them, but this turned out to be quite difficult. Not only because these disconnects happen quite random, but they never produced any error messages (apart from pppoed). To reconnect, only a reboot of the modem helps.
Currently I'm using an o2 Box 6431 as modem and didn't experience a disconnect yet, but sometimes they occur after several days or weeks.
I can understand that you're frustrated (I am too), but getting lantiq DSL right is difficult, since it relies on closed source firmware blobs, which are always a pain.
If you have a bit of time it would be very helpful if you could look for error messages on your modem that may help to fix this issue.
Can you still log in on your modem via ssh after a disconnect occurs? If so, does dmesg show any dsl/firmware related errors? Posting them here is really appreciated!
Can you give more details about your installation? Which LEDE/OpenWrt version are you using?
There are forum posts and bugs related to VDSL disconnects, see here and here.
I did't file an ADSL related issue yet (because lacking useful error messages), but maybe something occurs on your installation that could be useful for a bug report.
Are there other lantiq users, still using ADSL, that experience disconnects? Please chime in!
Well first I thought it was because of the Linux Kernel maybe, well because using the latest Trunk version seemed to connect me to the internet faster than the stable release 17.01.4 and also configuring the ADSL was quite difficult on stable release compared to Trunk. I am currently using the Trunk version and apart from vlan switches no problem has occurred so far.
While talking about ADSL (I have no experience with VDSL yet) I have no idea why the disconnects were happening, well they also happen on the Broadcom router for me but at least the line gets stable and I can connect to internet. Last night while I was configuring the router, I never got connected to internet on stable release, until I used the Trunk and the only change that I had to do was put username and password and voila it got connected. But again it started disconnecting and for an hour the line did not synchronize. Then I used the SNR offset of -2 db and it got stable and now I am using SNR offset of -1.5 db and it seems to be really great and so far very few disconnects compared to before.
And about the errors I didnt get any errors when it disconnected but sometimes the Line state showed 'showtime_no_sync' and when it gets connected it shows 'showtime_tc_sync'. I have no idea what that means but I'll see if I can find any errors related to this.
[Edit]
The following two lines seem to appear along with the disconnect of ADSL. Wed Jul 4 15:30:38 2018 kern.warn kernel: [ 3836.889154] enter showtime, cell rate: 0 - 2511, 1 - 2511, xdata addr: 0xa1970000
Wed Jul 4 15:30:38 2018 kern.warn kernel: [ 3836.905894] enter showtime, cell rate: 0 - 2511, 1 - 2511, xdata addr: 0xa1970000
I also tried to experiment with different SNR offsets, but for me this didn't stop the disconnects.
I'm not 100% sure about the values shown by /etc/init.d/dsl_control status either. I guess showtime_tc_sync means that modem and DSLAM agreed on the frequencies to be used. I've never seen showtime_no_sync - for me line status was shown as showtime_tc_sync, even after a disconnect.
Correct, showtime_tc_sync means all parameters are negotiated and the xDSL connection is established. Other states could be silent (no signal) and handshake (negotiation in progress.).
Reading FS#494: I don't have the issue any longer. After being forcefully upgraded to vectoring, the reliability of my line was even worse than before (sync with somewhat around 10Mbit downstream, xDSL handshake every 30min).
A service technician from my ISP checked my line and found the issues. Only one of the two wires were connected and this wire was faulty on top. It is amazing that Very high speed Digital Subscriber Line worked at all.
After being switch to two working wires > 2 month ago, I haven't seen FS#494 any more.
Show us the /etc/init.d/dsl_control status output if your line is in sync. It sounds like you're far-away from the DSLAM and your SNR being really low. If the SNR is under a threshold (5.5db?) the connection is terminated and re-synced. Sure, you can lower the SNR threshold to <5.5db but if the xDSL chip isn't able to distinguished valid signals from (background) noise, it wont work either. Might be the broadcom xDSL chips work better in low SNR situations, but since there is no open-source/free available driver for these it doesn't really matter.
root@AhmarRouter:~# /etc/init.d/dsl_control status
ATU-C Vendor ID: Broadcom 163.156
ATU-C System Vendor ID: 00,00,30,30,30,30,00,00
Chipset: Lantiq-VRX200
Firmware Version: 5.8.0.11.1.1
API Version: 4.17.18.6
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0
Annex: A
Line Mode: G.992.5 (ADSL2+)
Profile:
Line State: UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS): Near: 4046795 / Far: 1016
Errored seconds (ES): Near: 1086 / Far: 263591
Severely Errored Seconds (SES): Near: 433 / Far: 160317
Loss of Signal Seconds (LOSS): Near: 37 / Far: 149237
Unavailable Seconds (UAS): Near: 602 / Far: 602
Header Error Code Errors (HEC): Near: 7559 / Far: 2095307
Non Pre-emtive CRC errors (CRC_P): Near: 0 / Far: 0
Pre-emtive CRC errors (CRCP_P): Near: 0 / Far: 0
Power Management Mode: L0 - Synchronized
Latency [Interleave Delay]: 15.0 ms [Interleave] 13.25 ms [Interleave]
Data Rate: Down: 4.606 Mb/s / Up: 1.081 Mb/s
Line Attenuation (LATN): Down: 38.7 dB / Up: 22.8 dB
Signal Attenuation (SATN): Down: 36.4 dB / Up: 22.3 dB
Noise Margin (SNR): Down: 4.7 dB / Up: 5.5 dB
Aggregate Transmit Power (ACTATP): Down: 18.1 dB / Up: 12.0 dB
Max. Attainable Data Rate (ATTNDR): Down: 9.576 Mb/s / Up: 1.069 Mb/s
Line Uptime Seconds: 210
Line Uptime: 3m 30s
But my SNR margin seems to be changing all the time, so I guess it can also be a line issue. I should check my wirings appropriately and see if there is an issue and if things get better.
I see the problem both on a VDSL (vectoring) and an ADSL2+ (ATM) line.
At some point this issue has gotten so frequent that I'm mitigating it with a script in /etc/hotplug.d/iface that, after an ifdown on wan, checks for a few minutes for wan to return and then reboots the router.
I can't back it up with concrete data but I feel the problem doesn't occur, or doesn't occur nearly as often, since I disabled SQM on pppoe-wan. That might be anecdotal and unrelated, though.
Edit: Perhaps similarly anecdotal, but I remember that I was able to provoke the error with large downloads off mega.co.nz through Chrome on Windows 10, sometimes to the point where I could barely download 50 or 100 MB before pppoe would hang up. Other large downloads went through perfectly fine, both on http and other protocols.
Actually I experienced a lot more disconnects, when testing cake with ack-filtering, so thanks for sharing this! Since the disconnects happen randomly, I can't really test this effectively. I also have no idea in what way SQM can affect the DSL modem.
Well last night I decided to try again the Stable build and I compiled a custom image with relevant packages and configured the router. At first ADSL was performing very poorly, it was not even synchronizing the line. So I decided to drop the SNR and did so by 2.5 or 3 db using vdsl_cpe_control --console command and also put it in the startup script because there is no setting for SNR offset in stable build (as I know so far).
Doing so actually helped me get to internet and right now the router uptime is 7H and 47M and ADSL Line uptime is 6H and 18M which is surprising for me because even for snapshot build ADSL did not stay connected for even 30M.
So I think it's not just Line quality but also the configuration and Kernel stability that matters here.
I assume you installed LEDE 17.01.4, did you try OpenWrt 18.06.0-rc1, as well? If 17.01.4 is performing better than 18.06.0-rc1 there's also the possibility of a regression introduced between these releases. But 18.06.0-rc1 still uses Linux 4.9, whereas current master switched to 4.14 AFAIK, so it could be a regression in master as well.
I compile from the openwrt-18.06 branch and currently my ADSL connection has been stable for the last days.
I tried the latest snapshots first and they gave me some trouble with UPNP so I went back to stable release. Well there is also the possibility of my line being faulty enough for random disconnections. As my line stats suggest above, I think I will go with the faulty line. Unless I get an improved line I wont be able to tell which one is better and that is not happening in the near future.
I can actually confirm that due to some configuration options available in Broadcom devices, which are not yet available in Openwrt/LEDE, such as SRA and Bitswap, the ADSL line is rather much stable in Broadcom based routers. In stable LEDE 17.01.4 I was facing a lot of disconnections around 1/min so I decided to use the ISP router in bridge mode and I am pleased to say that I can finally browse the internet properly without much problems.
I also think maybe Openwrt is more suitable for VDSL rather than ADSL because of the structure, but I could be wrong.
I think I have a bad line probably, because at times it's so shit it can barely sync and right now it's working like a charm. Anyway, it's time to close the topic. Both hardware and software seem fine for Broadcom and Lantiq devices.