Lantiq vrx200 xDSL firmware recommendation thread

Just trying to extract "filesystem.image" from the latest Labor image of Fritz box 7490 (build 85134) via 7z and while extracting I get the following: "No files to process"
Nothing is extracted to the folder.
Does anyone know if something changed recently in terms of the image structure?
I wanted to check if a newer version of the lantiq xdsl firmware exists or if it is still 5.9.1.4.0.7 - normally AVM is/was the place to look for a newer version.

AFAIK you need to unsquashfs4-avm-be the .image, also binwalk works better than 7z sometimes.. some reference here and here.

1 Like

I just found this thread and I'm wondering:

Is that still your recommended firmware for a 3370?

I just switched from a somewhat stable TL-W8970B on 100/40 VDSL line to the fritzbox and I am having a hard time finding a firmware that does not reconnect every 15 minutes... Right now I am on the one from inside https://download.avm.de/archive/fritz.box/fritzbox.wlan_3370/firmware/deutsch/ and it seems stable for now, but the speed is disappointing. For what it's worth: with the TP-Link I had 5.7.6.A.0.7 and it worked okay.

Good stuff. Thanks for the guidance.
Fyi, the latest build (85134) of 7490's fw still has 5.9.1.4. The checksum is identical to the one existing in your 2nd link.
Going forward, is it fair to assume that there is no scope for a newer release after 5.9.1.4? This has remained the same for the last couple of years.

I have a TPlink vr200v, any recommendation for 50Mbit/vectoring ? I can't seem to get a sync. Thanks.

I can't answer this anymore, neither in a positive or in a negative. While I was happy with the transfer rate and the "relative stability" of the line using that firmware version, I still had troubles with deterioriating line values. Over the span of about two weeks, the SNR would slowly but steadily go down to the point where a resync was forced. This seems to be a general problem with Lantiq modems, not just with a specific firmware, I have seen reports of it happening even on AVM firmware unmodified Fritzboxen.

For several reasons (one of them wanting to upgrade to 802.11ac WiFi which the Lantiq devices cannot provide) I then decided to switch to an external Broadcom-based modem + router combination. In my case that was a dirt-cheap used Zyxel VMG1312-B30A (and a Netgear R6220). This setup has been rock stable, with excellent -- and more importantly, dynamically recovering! -- line rates, for the last six months, to the point where it ran into an amusing bug where the reported uptime tops out after slightly less than two months. I don't intend to go back to a Lantiq modem anymore.

1 Like

Thank you for the detailed response! I'll see how it goes and consider the route you took as a backup :slight_smile:

Same here, depending on the DSLAM's line card broadcom VDSL modems seem to perform better than xrx200 generation latiq SoCs (for Annex Q 35 MHz Super VDSL things are less clear and modern lantiq SoCs appear equally good or better than current Broadcom SoCs).
I switched the same zyxel, for debugging, and have not have an urge to go back to the lantiq :wink:
(Full disclosure, I recently cleaned up my in apartment wiring and now see zero errors/errored seconds on the line and am tempted to test the lantiq modem again, will post my experince here should I get round to it)

Most importantly, they dynamically recover the line quality, something I have never seen with Lantiq modems that only seem to reduce, but never recover. They should be able to do that, too, of course ... but for whatever reason they just ... don't. There is some speculation that the firmware is brought up differently by OpenWrt, but as I said, there are reports that the original Fritzbox firmware does suffer from that, too.

That actually was the biggest surprise to me. I live "downtown", in a quite crowded/electrically noisy neighborhood with copper lines that date back to the Paleolithic. (Seriously, I once watched over the shoulder of a service technician "debugging" our in-house wiring, it is nothing short of astonishing that the mess of bell wire works at all, let alone as well it does.) With Lantiqs I didn't have any major issues as far as errors go, a dozen or so CRC errors per day didn't cause me any loss of sleep (they are recoverable errors after all), the consensus seems to be that they only start to indicate a problem in the mid-double digits.

But with the Zyxel, my statistics report an average of 0.3 downstream and 0.4 upstream CRC errors per day. That means my line regularly goes days without a single CRC error. This is the graph for the last month (for scale, every blip essentially marks a single CRC error.)

2 Likes

Good point, I have not actually looked at that aspect in the past and hence can not add anything here (in case I try the lantiq again, I will look at this though). Thanks to your collectd scripts for the zyxel I see a nice pattern to up- and downstream capacity, which both gently increase diring the dead of night, only to decrease again in the morning, which confirms the "broadcom can recover" argument to some degree.

Oh, this is more about my ISP's (DT) DLM syste which downgraded the maximum sync of my link based on the errors, now with zero errors logged, trying the lantiq once more seems like more than a fools errand (that said, there really is very little to gain either).

Mmmh, since I changed my wiring I get exactly 0 CRCs, HECs, ESs, SESs. I see some FEC bursts (up to 20K/hour and more) and a few successful G.INP retransmits, but other than that the link now looks stabilized (and DLM released me from 90/32 to essentially full sync at 116/37).

Anyway, I am curious to see how the lantiq will behave on my now much cleaner link, but not sure I want to go through the required motions and hassle, it is not that the lantiq will offer much in excess of the broadcom modem, worse reporting and monitoring, but slightly more download (gigabit ethernet instead of the zyxel's fas ethernet)... The more I think about it the less I am inclined to change anything :wink:

1 Like

I had FEC in my statistics for some time and one day decided to stop worrying and love the FECs. They don't matter, like, literally they don't matter, so I stopped graphing them. Also keep in mind that, in contrast to the Lantiqs, the Zyxel does report FECs, not FECSs, and as such the number will always be much, much higher than with Lantiqs.

As for the bursts, when writing the collectd parsing script I noticed that sometimes the reported FEC numbers bump up for no reason at all, to the tune of 10000 more from one minute to the next. There's a bug buried there, somewhere.

1 Like

Sure, they are effectively a sign that the links coding is sufficient close its capacity ;). But the tech provider (DT) of my ISP (O2) seems to also evaluate FECs for its automatic determination of the sync limits they enforce for each individual link.

Oh I think I looked at the true FEC counter on lantiq as well, but that was before I cleaned up my wiring and bach then FECs were the least of my concerns :wink:

Well possible, but I see FEC spikes in DSLStats as well (I did not bother to write something myself, much nicer to use something shiny with a GUI that works out of the box :wink: ) so the bug could be in the binary on the modem that actually reports these numbers...

1 Like

I agree with you, I've been using the Zyxel VMG8324-B10A model in bridge mode for a while. Broadcom BCM63168 chipset is much more stable. I no longer use my P2812 modem. I am using my 100down / 8up mbps connection without any problems, it also has gigabit ports.

That's because DSLStats does exactly what I do: telnet into the modem and parse the output of xdslctl. Because that's the only way you can programmatically get those values from the modem at all.

We are literally puling the same numbers from the same place using the same means.

That's almost certainly it. I noticed these random spikes too, and being the compulsive yak shaver that I am, I thought I did something wrong in my parsing and tried to hunt down that bug. So I logged not only the parsed values, but also the raw xdslctl output until a spike occured and and ... nope, the number actually occasionally bumps up in xdslctl for no good reason.

1 Like

That might actually be the best argument for digging out the lantiq once more, just to see whether this will show similar FEC storms (which truly could be driven by noise ingress). But I assume that your assessment, that this is an idiosyncrasy of xdslctl/broadcom SoCs is correct, so I guess I leave the zyxel connected and spend my time on better things :wink:

I am having quite a stable (one crash in three weeks) connection with this firmware version:

bt,homehub-v5a
OpenWrt 19.07.4 r11208-ce6496d796
ATU-C Vendor ID:                          Broadcom 178.31
Firmware Version:                         5.8.1.5.0.7
Annex:                                    B
Line Mode:                                G.993.5 (VDSL2 with down- and upstream vectoring)
Line Uptime:                              18d 9h 51m 45s

Data rate is at 60 MBit/s downstream and 12 MBit/s upstream.

Before, I tried with 5.9.1.4.0.7 and 5.9.0.C.1.7 but had more than one crash per day. So right now I am quite happy with this.

3 Likes

Using the stock firmware, 5.7.9.9.0.6, I was having line drops every 2-3 days. This was when I came across this thread and started to investigate different firmware versions.

I tried 5.9.0.12.1.7 which didn't last 24 hours. More importantly it didn't reconnect without intervention.

I then tried 5.7.8.12.0.7 which has given much better results, and I shall stick with it.

bt,homehub-v5a
OpenWrt 19.07.6 r11278-8055e38794
ATU-C Vendor ID:                          Broadcom 164.161
Firmware Version:                         5.7.8.12.0.7
Annex:                                    B
Line Mode:                                G.993.2 (VDSL2)
Line Uptime:                              39d 13h 4m 17s

As a counterpoint, a friend with the same hardware and connected to the same exchange is fine with the stock firmware. The line remained connected for 40 days before the last disconnect.

bt,homehub-v5a
OpenWrt 19.07.3 r11063-85e04e9f46
ATU-C Vendor ID:                          Broadcom 164.161
Firmware Version:                         5.7.9.9.0.6
Annex:                                    B
Line Mode:                                G.993.2 (VDSL2)
Line Uptime:                              5d 5h 32m 31s

Can we next to doing this, have a setting in the LUCI config file ( LUCI Interfaces -> DSL ) for a service provider/Country?
Reason being that as time goes on and we learn of specific settings for different providers for the firmware we collect these settings in the setup (LUCI) scripts.
So each provider specific setting translates to options in the low level startup script for the dsl_cep_contrl script. Changes can then be tracked in GitHub

Sorry, but that's a pipe dream. There's hundreds of providers, each with multiple products, each customer with their own line setup that can differ from another customer's, and any of those settings can change at any time. There's a reason only very few commercial router firmwares come with such presets, and only if they are sold in a specific country, and only for a handful of the largest providers.

2 Likes

Agree there are many variants, but not unlimited. In UK it is BT Infinity that 'owns' the infrastructure that a number of providers use.
At least the framework of doing this can be implemented so that different people/groups can create a installable profile via the software install interface that will then show up under the interface-> dsl settings page as choice for profile to use. This instead of having to know the annex, tone, etc etc . There could always be an advanced page for specifying the profile details for experts :wink: