Lantiq vrx200 xDSL firmware recommendation thread

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.


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:

I am aware of the "Rule Britannia" sentiment, but I'm sure you would reluctantly agree that there's 194 other countries in the world.

OpenWrt is open source. By all means, feel free to implement it.

1 Like

By no means was the UK example meant as a "rule the waves", I think it is common knowledge around the world , except for WESTMINSTER government, that that has ended quite a while ago :wink:

As of the framework, is the command line interface for passing options via vdsl_cpe_control documented somewhere?

1 Like

I run a pretty recent self-compiled trunk version of OpenWrt that does not show DSL statistics when running /etc/init.d/dsl_control status. Instead, you have to run /etc/init.d/dsl_control dslstat, which then runs ubus call dsl metrics. The output is in JSON format.

This means the command from the original post would not work. Forgive my ignorance, I adapted it to
jsonfilter -e </etc/board.json; grep '^OPENWRT_RELEASE' /etc/os-release | cut -f2 -d'"'; ubus call dsl metrics | jsonfilter -e @.atu_c.vendor -e @.firmware_version -e @.mode -e @.annex -e @.uptime

My results: was horrible, I had disconnects every few hours. works great, the line is up for nearly 9 days, which is the time I last booted the router:

OpenWrt SNAPSHOT r15734-6934d30cf8
Broadcom 194.80
G.993.2 (VDSL2, Profile 17a, with down- and upstream vectoring)

Reading back on this thread someone has failed to mention that VDSL2 circuits will put interleaving (higher pings and speed changes) on your profile if you dont keep your line stable unless you live in a country where an engineer will visit the street cabinet and reset the DSLAM cabinet.

i myself always issue via SSH /etc/init.d/dsl_control stop which nicely terminates the VDSL2 session and puts the modem offline whats is better then yanking out the telephone cable or some other random disconnect registers as "Port error".via the ISP logs

If trying a new firmware highly i recommend 60 days (2 months max)
30 days for the line to stable agan
30 days to test firmware

1 Like

My test setup seems to work fine with VES-1608FA-35 DSLAM and about 340m cable length.
Continuously transmits cctv video stream (about 3.5Mbit/s).
Firmware extracted from factory firmware.

OpenWrt SNAPSHOT r16585+11-182eaa4916
Ikanos 1.1
G.993.2 (VDSL2, Profile 30a)

Would anyone be able to confirm the last 5.7 version, is it:


On my DM200 it's clear that Netgear downgraded the DSL firmware from 5.8 on firmware version and kept with 5.7 for all later firmware versions.

I'm stuck on Profile 17a VDSL2 without vectoring so if anyone could recommend a better firmware I'm happy to try it.

The DSL firmware from Netgear's DM200 v1.0.0.52 and later images definitely supports vectoring in my experience, at least for the Australian NBN VDSL implementation which has Broadcom based cabinets/nodes. v1.0.0.34 and earlier images were known not to be able to connect at all in this environment...

1 Like

@sven What hardware are you running this on? I'm currently on a fritzbox 7360SL and I have severe speed deterioration problems. The line starts with 95Mbit downstream and after a couple of hours it ends up being only 20Mbit.

Broadcom 178.31
G.993.2 (VDSL2, Profile 17a, with down- and upstream vectoring)

Sorry, local cabinet does not have vectoring enabled, no issues with dm200

@stonerl I'm also using a FritzBox 7360SL. My provider is Vodafone. I have a 100 MBit/s line and it runs fine with full 100 MBit/s. But I have to admit I only use the 7360SL als a modem, NOT as a router because the CPU can't handle NATing full line speed.

Could be this issue:- Vectoring on Lantiq VRX200 / VR9 - missing callback for sending error samples

1 Like

No problems on default OpenWRT firmware for me:

Chipset:	         	Lantiq™ XWAY™ VRX268
Firmware Version:
API Version:
MEI Version:
Power Management Mode:	L0 - Synchronized
Line State:		        UP [0x801: showtime_tc_sync]
Line Uptime:		    26d 3h 14m 11s
Resyncs:		        5
XTSE Capabilities:	    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex:			        B
Line Mode:		        G.993.2 (VDSL2)
Profile:		        17a
Trellis:		        D: ON / U: ON
Bitswap:		        D: ON / U: ON
G.INP:			        D: Not Enabled / U: Not Enabled
Virtual Noise Support:  D: Not Supported / U: Not Supported
Attain Data Rate:	    87.334 Mb/s / 25.058 Mb/s
Actual Data Rate:	    79.995 Mb/s / 20.000 Mb/s
Impulse Noise Prot:	    0.0 sym / 0.0 sym
Interleave Delay:	    0.0 ms / 0.0 ms
NFEC:			        255 / 255
RFEC:			        16 / 16
LSYMB:			        21451 / 5410
Interleave Depth:	    1 / 1
Interleave Block:	    255 / 255
LPATH:			        0 / 0
Line Attenuation:	    11.8dB / 13.4dB
Signal Attenuation:	    11.8dB / 13.2dB
Noise Margin:		    4.2dB / 9.3dB
Transmit power:	    	13.8dBm / 3.3dBm
FECS:			        54547 / 16902
ES:			            3201 / 31817
SES:			        0 / 17
LOSS:			        6 / 0
UAS:		        	145 / 145
HEC:			        0 / 0
CRC_P:			        0 / 0
CRCP_P:			        0 / 0
15m Code Violations:	0 / 2
15m FEC Errors:		    3 / 3
1d Code Violations:	    30 / 68
1d FEC Errors:		    6402 / 296

I was curious though, can you get the hlog using a stock build of OpenWRT?

I know you deleted your question, but I will still answer it: I rewrote the statistics collector and display definitions quite extensively for 21.02. I just need to sort out some problems with Github and multple accounts and some shenanigans, but it's on top of the queue for publication.

@takimata , sorry, my mistake.

Sure, would be more than willing to support you get get this working. Just let me know once it's there.

(As for "getting it working", the script has been running fine for months, but I had to work out some kinks with a multi-github account setup to actually push it to github.)

Edit: oops, forgot the ACL script, added now.


Really nice, thanks! Could you maybe add a few example images to the github page as this will be the best advertisement, why one would like to run this :wink: ?

1 Like

For Aussies looking for an NBN "SOS/ROC" compatible (*) xDSL firmware, the version required is 5.7.C.8.1.7_5.7.5.A.1.1 from the Vigor 130 "modem 11" package - see for more info about getting it.

(*) The VRX200 chipset isn't technically SOS/ROC compliant, however it can be sufficiently compliant for NBN's purposes if SRA works properly when the NBN FTTN/FTTB node is configured for SOS/ROC. Unfortunately most Lantiq xDSL blob versions lose downstream SRA in this environment unless the service is put onto a "Stability profile", which deactivates the SOS/ROC configuration and after 3-7 days moves the service to Dynamic Line Management (DLM). The 5.7.C.8.1.7_5.7.5.A.1.1 xDSL version has been confirmed to have bidirectional dynamic SRA on an SOS/ROC enabled connection.