Lantiq vrx200 xDSL firmware recommendation thread

Installing and Using OpenWrt Network and Wireless Configuration
21

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?

22

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
23

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

1 Like
24

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

25

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
26

All firmware I can find is here.

28

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

29

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.

30

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

31

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
32

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.

33

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
34

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:

35

So my situation has changed in the last few days and I can attest to that statement. Yesterday, one of my lines changed to a 100/40 vectoring line. For me, 5.7.8.9.0.7 does the trick (quite appropriately so, as it originally comes from a FritzBox 3370 image, and is now running on a FritzBox 3370 again), whereas 5.9.0 or 5.9.1 firmwares were unstable with frequent disconnects.

Oh, I wholeheartedly agree that it is a really handy collection of firmwares if you need to try out a few to find the one that works for you. I may have overreacted a bit, and yes, you can be sufficiently safe if you compare checksums. But please keep in mind that it is still technically illegal to redistribute firmware blobs. There is a reason why the xdarklight page does not offer them for direct download, as handy as that would be.

36 
avm,fritz7360sl
OpenWrt 19.07.1 r10911-c155900f66
ATU-C Vendor ID:      Broadcom 178.5
Firmware Version:     5.7.4.4.1.7
Annex:                B
Line Mode:            G.993.5 (VDSL2 with down- and upstream vectoring)
Line Uptime:          24d 4h 30m 6s
1 Like
37

I'm currently having some stability issues on my WR9980 as well. I compared the performance with my Fritzbox 7490 and this one hardly ever needs to resync.

Now I setup a grafana dashboard to monitor the DSL stats. It seems that SNR noise margin is sometimes dropping with about 3db at once and this causes reTx counters to go up quite a bit. The FritzBox however did not do any resyncs at all. That one however is 'certified' and whitelisted by the ISP.

I found that the firmware did not have bitswap enabled on the downstream by default. Also rate adaptation was not in the same mode for downstream as upstream. I enabled those settings by patching the dsl_control script and it seems to be more stable now.

Also I have added bitswap and ginp status in the dslstats stdout dump. Might be interesting to add this to openwrt trunk as these stats are also in the default fritzbox pages (so rather important stuff for stability?)

Does anyone else here have some experience with these settings? Maybe stability is more a matter of having these settings enabled instead of finding the right firmware version?

1 Like
38

That certainly is not helpful for stability... So the certified modem used bitswap by default the other did not? Bitswap allows the modem to change the bitloading of different carriers (the sum needs to stay constant) so that noise affecting one/a few carriers only does not necessarily cause a loss of sync. SRA/seamless rate adaption supposedly goes a step further in that the sum does not need to stay constant (my ISP does not enable SRA at all).

+1; I would love to see a bit more in there.

Well, I always has bitswap enabled bi-directionally and SRA disabled and still had to play the firmware blob lottery.

39

Yes I compared my OpenWrt settings with those of the fritzbox (that seemed to run very stable) and so openwrt did not enable the bitswap while the fritbox had it enabled on both sides. Adding a config option to enable it through autoboot could be helpful as well?

The weird thing here is that I am using the exact same 'certfified' blob that runs very stable on the fritzbox, but that is coming up with different settings (bitswap disabled) and unstable on OpenWrt?

One extra thing to check would be to see if the certified modem uses sra and in which mode. I know fritzbox has some settings to determine the 'stability' vs performance tradeoff. I wonder which setting they modify in the firmware to accomplish this. So at least it would be nice to have these options in OpenWrt so people can try some settings easily when they have an unstable line.

40

First of all: Thank you for picking this up, I too am suffering from "line deterioration" where my downstream sync starts out at ~10dB SNR and over about 2 to 3 days gradually goes down to ~6dB. It recovers slightly in between, bouncing between 6 and 7dB sometimes, but in the end falls down to ~3dB (eek) and resyncs. After the resync, I invariably and immediately land at ~10dB again.

FTR: I'm currently using 19.07.1 and modem firmware 5.7.9.5.1.7 on a FritzBox 3370. And I am very happy with its performance, reliably synching at ~110/43 out of a possible ~133/49 mbit. OTOH, I had no luck with newer firmwares (5.8 or 5.9), I could actually provoke those to resync with a simple web-based speedtest.

If I'm looking in the correct places I can't confirm: Pre your modifications:

Trellis:                                  Down: 1 / Up: 1
G.INP:                                    Down: 1 / Up: 1
Bitswap:                                  Down: 1 / Up: 1
Virtual noise:                            Down: 1 / Up: 1

so ... bitswap was already enabled after all? After manually inserting your patch (dsl_control changed between 19.07 and master) and rebooting:

Trellis:                                  Down: 1 / Up: 1
G.INP:                                    Down: 1 / Up: 1
Bitswap:                                  Down: 1 / Up: 1
Virtual noise:                            Down: 0 / Up: 1

So your patch is being applied and dials in some other parameters. We'll see how the line holds up, and hopefully recovers from the inevitable dips over the next few days.

IMNSHO, though: I really, really think it's time for a luci-app-dslstats or something to that tune. For two reasons:

Calling dsl_control status is pegging the CPU for about 3 seconds, and it's called almost continuously from the LuCI front/status page, causing a load of 0.8+ on the device if you keep the page open in the background. An abbreviated "line status overview" like I wrote for myself only uses a fraction of the resources and should be much easier on the device. And the detailed dsl status could go to a subpage if you really need the details.

And on the other hand, it would allow us to do other fun things with what we can get from the modem. Like a spectrum graph, just as the FritzBoxes have it. It's actually quite easy to pull the data from the modem, and it's downright trivial to put them into pretty JavaScript graphs. I looked a bit into it already, but I stumbled a bit mostly because I'm horrible at LUA which would be needed to at least preprocess (e.g. chop off the header of) the results of g997bansg and g997sansg (maybe even convert them into JSON). And LuCI changed quite a bit between 19.07 and current master, so I can't even try out very much on my current setup.

1 Like
41

Having a look at your output it seems that you had the bitswap already enabled. I think my patch does disable the virtual noise (not sure what it does or whether it's enabled on my stable setup but I can check ofcourse). My point was that I use the exact same blob from the fritzbox which is very stable, while on OpenWrt it's not (resync every day). So that made me conclude that there might be other settings that influence stability beside the blob.

You're right about the lucistat, it's very heavy, I'm not sure how often OpenWrt calls the script but it might be in a tight loop. I sort of reuse the same thing to send those metrics to collectd which I use now as an input for a grafana dashboard. I made a pull request for this but I don't think it'll be included in this form and I might need to use the lua plugin instead, as you suggest.

Currently I'm working on the snr / bitallocation frequency plots as I want to have them and their history as well. I'm using the github from @moeller0 as an inspiration here.