Adding support for VRX518 (and maybe VRX320)

If the VX518 device runs OpenWrt I believe this is just a configuration question. On xrx200 I:
0) set the modem's IP-range to, with the modem at

  1. bridged dsl0.7 with eth0.7, to pass internet onto my primary OpenWrt router's eth2.7 (eth2 is the wan interface)
  2. bridged eth0.2 with the modem's br-lan, and then created another static interface on the primary router using eth2.2, with a static IP of and added that to the wan firewall zone...

That way I can access both the internet via PPPoE over eth2.7->eth0.7-dsl0.7, And still access the modem's LUCI interface (or shell) simply by using as target IP.

I did it in a hurry after a bad update took out my w8980. I couldn't remember how I configured before DSA so just went the easy route.

Bridge (br-wan) with dsl0 + eth0. Unmanaged interface (wan) on br-wan.

No PPPoE on my connection so I only need it as a converter.

If I really need the DSL stats I can get it via serial :smile:

I don't use PPPoE either :slight_smile: so that means i should be able to put one of the ports on the modem on it's own untagged/vlan at the switch, and then apply a static route back to my router. That way I have a persistent connection, and don't need any NAT rules on my WAN side of my router. My router is a rather powerful opnsense appliance so I'll be using openwrt in bridge mode too.

I like to keep an eye on my sync stats as I live in Australia and have crummy copper, it makes support requests a lot easier when I can email them a graph of when the piece of copper was fine and when it got "worse". This is a thing that happens every few years or so.

So that brings me to my other question about SoS and ROC, do these work? I know with with this chipset? Is there any way to check? You were able to check Seamless Rate Adaption (SRA), it shows up as bVirtualNoiseSupport with lfcg.

I would like to know if there's something in there about SOS/ROC as those are part of our requirements.

Also does the included firmware support vectoring? Vectoring and SRA are requirements or you get a locked port and have to call your ISP.

I compiled and flashed your branch, but i have no ptm interface. Did i miss something?

The dsl0 interface is only created while the modem establishes the initial DSL connection.

After 98 days of uptime I just had a weird issue. The DSL interface stopped receiving packets almost entirely (a few packets made its way through, so the PPPoE connection was occasionally established for a short time, but it didn't actually work).

After re-establishing the DSL connection using /etc/init.d/dsl_control stop and /etc/init.d/dsl_control start everything worked again immediately.

There are no messages in the kernel log, and the debug information from /proc/driver/vrx518 was consistent with almost no data being received. So I have no idea what this might have been caused by, and if it was due of the modem or its driver at all.

Can you explain that a little more? I plugged in the DSL cable, but no dsl0 device appeared. dmesg shows no hit, if i search for "dsl"

root@OpenWrt:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP qlen 1000
    link/ether 32:7a:e4:0b:57:86 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 3c:37:12:81:19:8f brd ff:ff:ff:ff:ff:ff
4: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 3c:37:12:81:19:90 brd ff:ff:ff:ff:ff:ff
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 32:7a:e4:0b:57:86 brd ff:ff:ff:ff:ff:ff

This probably means the modem hasn't established a connection. Did you check the DSL status using ubus call dsl metrics?

root@OpenWrt:~# ubus call dsl metrics
Command failed: Not found

I noticed something else: the Round-Trip Time (RTT) has risen by 100%, if i use my new 7520.
Sending 300 Pings from my firewall to OpenWRT:

My old Fritzbox 3370 (OpenWrt 21.02.3):
rtt min/avg/max/mdev = 0.735/0.837/1.065/0.051 ms

My new Fritzbox 7520 (OpenWrt branch from dhewg):
rtt min/avg/max/mdev = 0.845/1.964/2.605/0.161 ms

This is the same output you would get on an OpenWrt device without a DSL modem. Are you sure that the image you are using actually includes the DSL driver and application? If yes, is the dsl_control service running (the actual process is called vdsl_cpe_control)?

CPU frequency scaling causes a bit of jitter of IPQ40xx devices. You'll probably see more consistent latency with fixed CPU frequency. I am using the following command in /etc/rc.local:

echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor

Are there any additional steps necessary, besides compiling the branch of dhewg?
I usually don't compile on my own. I took a quick peek, and for me it looked like firmware files are put in place by the compiling process..?

No, normally the required packages should be automatically selected, if you choose the right device in make menuconfig.

Have you checked if the service is running? You could also try lsmod | grep vrx518 to check if the drivers are loaded.

@dhewg any chance you could update your branch with the latest DSA patch (I'm on a Fritz!7520 and I only get 100M on two ports without it)? I know I'm asking for quite a bit of work, drop me a line if not, then I'll take care of it. I just want to avoid two concurrent branches.
Apart from that: I've been using your branch on two different providers with great success for a few months now.


I tested a while ago with a 7530 and it just seemed like things got funky after a while (like weird stalling) and there's the spam to the kernel log about the error messages. If it's not 100% yet hopefully one day in the future it will be.

I'll give it another go and see. I've been running a bt hh5a with openwrt master on my line for months (103 mb/s downstream) and it has been rock solid, absolutely fantastic but it does sync lower than the fritz 7530.

I had that at one point. There're some annoying conflicts when rebasing with or without it, but nothing major.
But the PR itself wouldn't rebase cleanly on master at times, which is one reason why I dropped it again.

But I think it's close to getting merged, let's give it a few days...


seeing stuff like this

maybe it fixes the kernel spam

there's a branch that appears to have 5.15 support for dsa with some boards like the fritz 7530

yeah, but that one doesn't have the patches for the VRX518 support.

this is a bit random to put here but i've noticed at least for the xrx200, if you add the bridger daemon to a build it appears to segfault as soon as the dsl interface is brought up