I have been using OpenWrt on various Lantiq devices for quite some time now. One thing I often had problems with was the stability of the xDSL connection.
Debugging these problems turned out to be difficult, since the providers I used so far usually refused to give free support when using a modem they didn't provide. Another problem was the absence of useful error messages when a xDSL disconnect happened, which is most probably because something in the modem firmware went wrong.
After having my line checked by a technician, which showed no problems, I began to test various firmware files from http://xdarklight.github.io/lantiq-xdsl-firmware-info/ and still didn't have success.
After finding another vrx200 firmware file on the web and using that, I was quite delighted to find my VDSL line completely stable for about 20 days now.
Finding the correct firmware file probably depends on a lot of different variables (device, OpenWrt version, line mode, annex, DSLAM manufacturer, etc.) and I fear it will be nearly impossible to cover all cases.
However it would be nice to make it easier to use OpenWrt devices as xDSL modems. There are a few reports by people on the forum that had a stable xDSL connection after installing a specific firmware, but these reports are buried deep down in various different threads. My proposal would be to collect the "I have found my perfect firmware" stories in one thread, so that other people have a starting point and at least have a better chance to find a suitable firmware sooner.
So, if you have a stable xDSL connection with OpenWrt, reply with the output of the following command:
echo; egrep '"id":' /etc/board.json | sed -nE 's/(\s*"id":\s")(.*)(",)/\2/p'; egrep 'OPENWRT_RELEASE' /etc/os-release | sed -nE 's/(OPENWRT_RELEASE=")(.*)(")/\2/p'; /etc/init.d/dsl_control status | egrep 'ATU-C Vendor ID:|Firmware Version:|Line Mode:|Annex:|Line Uptime:'
Greetings,
Sebastian
Update 2022
If you're using a DSL line with vectoring, make sure that your're using at least 22.03-rc4 (or a current master build), before testing different firmware versions. Recent OpenWrt versions have the Lantiq vectoring driver built in, which is needed for a stable vectoring connection.
Great idea, maybe the router model and openwrt version could be extracted automatically and information for the DSLAM maker and firmware version could be added as well?
Edit: Since @sebastian_de updated the reference command line, I just re-ran with the new version:
echo; egrep '"id":' /etc/board.json | sed -nE 's/(\s*"id":\s")(.*)(",)/\2/p'; egrep 'OPENWRT_RELEASE' /etc
/os-release | sed -nE 's/(OPENWRT_RELEASE=")(.*)(")/\2/p'; /etc/init.d/dsl_control status | egrep 'ATU-C Vendor ID:|Firmware Version
:|Line Mode:|Annex:|Line Uptime:'
bt,homehub-v5a
OpenWrt 19.07.0 r10860-a3ffeb413b
ATU-C Vendor ID: Broadcom 193.218
Firmware Version: 5.9.1.4.0.7
Annex: B
Line Mode: G.993.5 (VDSL2 with down- and upstream vectoring)
Line Uptime: 2d 22h 39m 43s
Note that this is the firmware blob from FritzOS 7.12 for the FritzBox 7490 that is not really stable with the Broadcom vectoring linecard, so this is just an example for extended output.
If you consider it confusing to have a false positive report in this thread, please do not hesitate to flag this post as off-topic so it gets mostly hidden.
Thanks, nice idea! I edited the command accordingly and made the output more readable. Please note that I'm not a regex expert, so any tips are welcome.
Hello, I live in Turkey and I use the ZyXEL P-2812HNUL-F1 with OpenWRT. My line values are as follows, Unfortunately there are upload speed restrictions in my country.
OpenWrt 18.06.6 r7957-d81a8a3e29
ATU-C Vendor ID: Broadcom 164.27
ATU-C System Vendor ID: Broadcom
Chipset: Lantiq-VRX200
Firmware Version: 5.9.0.12.1.7
API Version: 4.17.18.6
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.2 (VDSL2)
Profile: 17a
Line State: UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS): Near: 0 / Far: 3348
Errored seconds (ES): Near: 0 / Far: 58
Severely Errored Seconds (SES): Near: 0 / Far: 0
Loss of Signal Seconds (LOSS): Near: 0 / Far: 0
Unavailable Seconds (UAS): Near: 28 / Far: 28
Header Error Code Errors (HEC): Near: 0 / Far: 0
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]: 0.0 ms [Fast] 0.0 ms [Fast]
Data Rate: Down: 79.865 Mb/s / Up: 4.095 Mb/s
Line Attenuation (LATN): Down: 8.7 dB / Up: 7.5 dB
Signal Attenuation (SATN): Down: 8.7 dB / Up: 10.7 dB
Noise Margin (SNR): Down: 15.2 dB / Up: 31.0 dB
Aggregate Transmit Power (ACTATP): Down: -5.0 dB / Up: 14.5 dB
Max. Attainable Data Rate (ATTNDR): Down: 136.172 Mb/s / Up: 43.616 Mb/s
Line Uptime Seconds: 42616
Line Uptime: 11h 50m 16s
in addition to I have 5.9.1.4.0.7-5.9.0.D.0.1,2 dsl firmware version of fritzbox 7490. But it doesn't work stably. The version of 5.9.0.C.1.7 I use is the most stable version in me.
"Stable", as in "usually works for days and weeks", with "usually" being the operative word? Because there is still a long time standing, unresolved bug that makes PPPoE fail to (re)connect from time to time even though the DSL line itself is up and running. I'm guessing you are not referring to that circumstance?
So here's the firmware I am having luck with on my TP-Link W8980 on a 100/40 VDSL line:
tplink,tdw8980
ATU-C Vendor ID: Infineon 192.200
Firmware Version: 5.7.9.5.1.7
Annex: A, B, C
Line Mode: G.993.2 (VDSL2)
Line Uptime: 1d 7h 6m 6s
Note 1: I never did any experiments with firmware versions, I pretty much took the
highest version of
vectoring capable where
I didn't have to jump through hoops to get the firmware blob (squashfs extractions or other shenanigans, i.e. just the blob in a tgz if I remember correctly)
Note 2: My uptime is only ~1 day because I ran into the aforementioned bug yesterday. I have seen uptimes in excess of two months with this firmware, though.
I am running a different one on my home router that is on a measly 16/1 line:
ATU-C Vendor ID: Broadcom 147.240
Firmware Version: 5.7.4.4.0.2
Annex: B
Line Mode: G.992.5 (ADSL2+)
Line Uptime: 4d 4h 13m 32s
... and I honestly don't remember why I chose this one. Some sort of holdover from an earlier router I guess. I could probably just go with the stock OpenWrt firmware blob on this router.
The stock firmware on v19.07.0 works just fine for one of my routers (that I manage remotely). With uptime of more than 2 days at times. But there is also the possibility of power outages, restarts etc but I think it pretty much depends on the line quality though and firmware being the 2nd issue.
Mmmh, maybe http://lists.infradead.org/pipermail/openwrt-devel/2020-January/021305.html is related? I happen to never have seen this issue (or never noticed it happening, well possible I misdiagnosed the root cause of a disconnect/hang), but I do not run PPPoE on the vrx200 device itself, but only use this as bridged modem with fancy GUI/management interface....
As I said, I sometimes see several months uptime, and sometimes a few breakdowns within a few days. It's really hard to pinpoint the cause because it's not reproducible, a Frankenbug. But it seems to be an issue of PPPoE, not of the DSL firmware. It's okay, I can live with it, and I've automated around the issue.
I guess what I'm trying to say is that, for me, no matter which DSL firmware I use, it is still more stable than the system around it, which is by no means "unstable" itself.
It's a Huawei cabinet (Huawei stamp on the cabinet) but I have no idea what chip is used inside. It should be Broardcom but why it's not listed as the ATU-C Vendor that's another mystery.
JFTR, after a bit back and forth, the fix has been merged into master and 19.07 (just in time to be included in today's 19.07.1). If the PPPoE bug is caused by this issue and fixed by the patch -- and I have high hopes it does -- it solves a really, really long standing bug with DSL on Lantiq.
At any rate, the bugfix will solve stability problems with DSL on Lantiq, so upgrading to 19.07.1 or a current master is certainly not a bad idea anyway, if only to rule out stability issues with the system before looking into minute differences of DSL firmware blobs.
Update 2022