Lantiq vrx200 xDSL firmware recommendation thread

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.

tplink,tdw8970
OpenWrt 19.07.0 r10860-a3ffeb413b
ATU-C Vendor ID:                          26,00,48,49,53,49,34,12
Firmware Version:                         5.7.8.12.0.7
Annex:                                    B
Line Mode:                                G.993.2 (VDSL2)
Line Uptime:                              4d 1h 16m 53s

26,00: that is the T.35 country code for China
48,49,53,49: HISI could be HiSilicon/Huawei?

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.

1 Like

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.

2 Likes

Since the audience of this thread might be interested in that as well:
https://forum.openwrt.org/t/simple-tool-to-query-lantiq-modem-statistics-and-diagnostics-useful-for-modem-routers-running-openwrts-dsl-cmd/53857

Might be helpful to get Bitloading, SNR, H(log) and QLN plots out of lantiq modems under OpenWrt...

Sorry for the distraction.

zyxel,p-2812hnu-f1
OpenWrt 19.07.0-rc2 r10775-db8345d8e4
ATU-C Vendor ID: Broadcom 192.244
Firmware Version: 5.7.5.6.1.7
Annex: B
Line Mode: G.993.5 (VDSL2 with down- and upstream vectoring)
Line Uptime: 5d 0h 52m 54s

So, basically I'm not sure whether this is conclusive or not, but my dis-/reconnects have a strange pattern. I observed it during the last 14 days.:

Monday		10.02.20	19:00	
Thuesday	11.02.20	20:00	
Wednesday	12.02.20	10:20	
Thursday	13.02.20	---	
Friday		14.02.20	---	
Saturday	15.02.20	19:30	
Sunday		16.02.20	15:00	
Monday		17.02.20	13:00	
Tuesday		18.02.20	---	
Wednesday	19.02.20	20:00	20:15
Thursday	20.02.20	---	
Friday		21.02.20	18:00	18:35
Saturday	22.02.20	---	
Sunday		23.02.20	---	
Monday		24.02.20	---	
Tuesday		25.02.20	17:00	

It is +/- 3 minutes, but still weird. It seems this isn't caused by my router but the ATU?

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

Vdsl2 with no vectoring an everything stable on whatever firmware I push to W8970. Currently on 5.9.1.4.0.7 annexa and 5.4 kernel

That's a first. AFAIR everyone who used v9.x ended up regretting the decision because it simply doesn't work.

same for me, stable whatever firmware... can't notice any differences in performance.. TD-W8970 in bridged mode 19.07.2 stable..

ATU-C Vendor ID:                          Broadcom 164.154
ATU-C System Vendor ID:                   Broadcom
Chipset:                                  Lantiq-VRX200
Firmware Version:                         5.9.1.4.0.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 Uptime:                              13d 31h 24m 53s

All firmware I can find is here.

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:

5.9.0.C.1.7-5.9.0.A.0.2
SHA1: 756553dcb16ffee8bc1a92f13ae1670d6db35a79
905028 bytes

Name: vr9-B-dsl.bin
Size: 905028 bytes (883 KiB)
CRC32: 2FDD75F2
CRC64: 7238377B27BEC622
SHA256: 8644CBB409BB8DE9FBB088A490FAB7EB12BD733015E01963400BB1382DBDEE49
SHA1: 756553DCB16FFEE8BC1A92F13AE1670D6DB35A79
BLAKE2sp: 268C63E2CC20F8A6CBAE9A0D1B65D316E42ADB75571EED921BC8166EEFCA5356

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.

mmmh, I wonder, does your ISP use G.INP?

Could you post the outpout of the following 4 commands as issued on your vrx200' command line, please?

. /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 0 0
. /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 0 1
. /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 1 0
. /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 1 1

I get (vdsl2 with vectoting and bi-directional G.INP/ReTx):

root@vrx200:~# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 0 0
nReturn=0 nDslMode=0 nDirection=0 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=0 bVirtualNoiseSupport=0 b20BitSupport=-1
root@ vrx200:~# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 0 1
nReturn=0 nDslMode=0 nDirection=1 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=0 bVirtualNoiseSupport=0 b20BitSupport=-1
root@ vrx200:~# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 1 0
nReturn=0 nDslMode=1 nDirection=0 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=1 bVirtualNoiseSupport=1 b20BitSupport=-1
root@ vrx200:~# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 1 1
nReturn=0 nDslMode=1 nDirection=1 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=1 bVirtualNoiseSupport=1 b20BitSupport=-1

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).

Hi @moeller0 here you go, same output by the looks of it?

# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 0 0
nReturn=0 nDslMode=0 nDirection=0 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=0 bVirtualNoiseSupport=0 b20BitSupport=-1
# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 0 1
nReturn=0 nDslMode=0 nDirection=1 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=0 bVirtualNoiseSupport=0 b20BitSupport=-1
# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 1 0
nReturn=0 nDslMode=1 nDirection=0 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=1 bVirtualNoiseSupport=1 b20BitSupport=-1
# . /lib/functions/lantiq_dsl.sh ; dsl_cmd LineFeatureConfigGet 1 1
nReturn=0 nDslMode=1 nDirection=1 bTrellisEnable=1 bBitswapEnable=1 bReTxEnable=1 bVirtualNoiseSupport=1 b20BitSupport=-1

Thanks, yes, that would indicate that G.INP is in use. Now we would need to get access to the ReTx statistics:

root@vrx200:~# . /lib/functions/lantiq_dsl.sh ; dsl_cmd ReTxStatisticsGet 0
nReturn=0 nDirection=0 nRxCorruptedTotal=1580226 nRxUncorrectedProtected=1367016 nRxRetransmitted=0 nRxCorrected=213210 nTxRetransmitted=193672
root@vrx200:~# . /lib/functions/lantiq_dsl.sh ; dsl_cmd ReTxStatisticsGet 1
nReturn=0 nDirection=1 nRxCorruptedTotal=381223 nRxUncorrectedProtected=344923 nRxRetransmitted=0 nRxCorrected=36300 nTxRetransmitted=488171

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 :wink: 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:

Fixes: FS#2792
1 Like

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 :wink: