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.
The version 5.9.1.4.0.7 is unstable for me.
5.7.8.12.0.7, aka 5.7.8.C.0.7 is stable for me.
bt,homehub-v5a
OpenWrt 19.07.1 r10911-c155900f66
ATU-C Vendor ID: Broadcom 177.191
Firmware Version: 5.7.8.12.0.7
Annex: B
Line Mode: G.993.5 (VDSL2 with down- and upstream vectoring)
Line Uptime: 3d 11h 11m 3s
I own a BT Hub 5A and have tested several firmwares during the last 14 days. I can say that in my case 5.9.0.12.1.7 has been by far the most stable and this is what I am going to stick with.
5.9.1.4.0.7 was less stable and a few promising versions as per users' feedback (5.7.8.12.0.7 and 5.7.11.5.0.7) were quite annoyingly unstable with around 2 line drops per day.
My ISP has VDSL2 with Vectoring and DSLAM's chip is a Broadcom 177.166.
I think that each user has to test several firmwares to find the ideal combo for each particular case. I am not so sure if a general rule of stable and unstable firmwares exists.
@takimata, I think you generalize things a bit in relation to the origin of the cloud and maybe it is not appropriate in this instance; at least provide some concrete evidence to support your argument. Fyi, I did SHA1 checksum for firmware 5.9.0.12.1.7 (in both 6.85 and 6.86 folders of the aforementioned zip file) and they are identical between each other. Furthermore, I compared such SHA1 with the values of the firmwares located in: https://xdarklight.github.io/lantiq-xdsl-firmware-info/
As you can see below, the values are identical, hence I do not see anything dodgy, at least in the firmware that I checked:
I can confirm that I am stable, fast and happy with firmware 5.7.8.12.0.7 on a Zyxel 2812 with stock OpenWRT 19.07.2 on KPN WBA (Telfort) VDSL in Netherlands. Since last reboot, 10 days uptime and counting. I have a stable line, and with telco firmware on the 2812 I would easily get months of uptime. I hope to be able to get the same with this OpenWRT-firmware combo.
The DSLAM is Broadcom 177.191.
Interestingly, I do seem to hit a bug where my actual line speed (as measured with iperf3) is quite a bit higher than the data rate reported by dsl_control. I will investigate this further.
As far as i can tell nDslMode=1 means VDSL, so only the last two should be relevant, in my case bReTxEnable=1 indicates the G.INP retransmissions are active (which can have an influence on the estimated rates, eithter gross rates or rates with some deductions for likely retransmit loss).
to confirm that ReTx is actually in use. Unfortunately that command is not supported out of the box, see
Blockquote for the necessary patches. But that is going to cost some time and is not guaranteed to go anywhere. The reason I bring this up is simply that ReTx introduced a new reported speed category that (if retransmits do happen) is lower than the real sync speed and as long as no retransmits eat into the sync budget that achievable speed will be above that ReTx corrected Rate. It could be that either driver or blob differ in which rate they report... But I see no real actionable outcome for figuring this out, if a driver/firmware combination is robust and stable, I would happily accept a slightly oddity in reported sync numbers instead of getting correct/precise numbers from an unstable combo.
I am not sure if the developers will pick up patches from bugs.openwrt.org.
When you consider the patch ready to be integrated into OpenWrt, I suggest to follow the Submitting patches guide. You can mention the bug number in the commit message like this:
Thanks! Good idea. I had hoped that at least somebody else, preferably on a non G.INP/ReTx VDSL link coud actually test this for side-effects, but I guess just hoping for that to happen was quite naive