Fritzbox 7520 - wan (dsl0.7) device is missing

I think the big difference is that @NerdyProjects you are using VDSL2/PTM (which a number of users managed to get going by simply following the instructions, myself included), while @wood tries to use ADSL2+/ATM/AAL5... IIRC that was not yet tested all that well for the VRX518 generation...

1 Like

Thanks for the reply and the experience you made. Will try to adopt my config a bit based on yours...but will have to find time here to take down internet.

Hm...that would make sense why it does not work out of the box as described. I am living in a small village and will try to contact O2 to check if the adsl+ line is possible to be switched to vdsl. =0)
Thanks for the information.

While ADSL/ATM support of this modem is so far untested, it may still be worth to have a look at the modem stats. What is the output of the command ubus call dsl metrics? The kernel log may also be useful, the relevant messages would be those containing "vrx518" and "plat_tc_request".

1 Like

The xDSL firmware file documented in the 7530 installation guide (8D1507_8D0901) is for ADSL Annex A, but if you're in .de you may need an ADSL Annex B firmware - I don't know how Annex J fits into this picture but you might want to try an ADSL Annex B firmware from the VRX500 list at
https://xdarklight.github.io/lantiq-xdsl-firmware-info/ to see whether you get different results.

1 Like

Many thanks for all the hints and knowledge you are sharing. That's exactly why I love open source projects. =0)


@janh : I guess the ubus call dsl metrics should be called when I try to connect. I will try to find some time when I can take down internet here at home for a while.

# ubus call dsl metrics
{
	"api_version": "4.23.1",
	"firmware_version": "8.13.0.9.0.1",
	"chipset": "Lantiq-VRX500",
	"driver_version": "1.11.1",
	"state": "Not initialized",
	"state_num": 0,
	"up": false,
	"atu_c": {
		
	},
	"power_state": "L3 - No power",
	"power_state_num": 3,
	"upstream": {
		
	},
	"downstream": {
		
	},
	"olr": {
		"downstream": {
			"bitswap": {
				"requested": 0,
				"executed": 0,
				"rejected": 0,
				"timeout": 0
			},
			"sra": {
				"requested": 0,
				"executed": 0,
				"rejected": 0,
				"timeout": 0
			},
			"sos": {
				"requested": 0,
				"executed": 0,
				"rejected": 0,
				"timeout": 0
			}
		},
		"upstream": {
			"bitswap": {
				"requested": 0,
				"executed": 0,
				"rejected": 0,
				"timeout": 0
			},
			"sra": {
				"requested": 0,
				"executed": 0,
				"rejected": 0,
				"timeout": 0
			},
			"sos": {
				"requested": 0,
				"executed": 0,
				"rejected": 0,
				"timeout": 0
			}
		}
	},
	"errors": {
		"near": {
			
		},
		"far": {
			"rx_corrupted": 0,
			"rx_uncorrected_protected": 0,
			"rx_retransmitted": 0,
			"rx_corrected": 0,
			"tx_retransmitted": 0
		}
	}
}

Here is the relevant part from dmesg.

[   13.135030] IFXOS, Version 1.7.1 (c) Copyright 2009, Lantiq Deutschland GmbH
[   13.137246] vrx518: Intel(R) SmartPHY DSL(VRX518) PCIe EP/ACA Driver - version 2.1.0-k
[   13.141231] vrx518: Copyright (c) 2016 Intel Corporation.
[   13.149083] vrx518 0000:01:00.0: enabling device (0140 -> 0142)
[   13.158245] NET: Registered PF_ATMPVC protocol family
[   13.160091] NET: Registered PF_ATMSVC protocol family
[   13.169279] vrx518_tc:pcie_ep_probe: Total 1 VRX518 EP detected
[   13.182420] vrx518 0000:01:00.0: dc_ep_clk_on failed
[   13.197205] MD5 checksum pass!!!
[   13.197254] Firmware pointer id(0):size(10636), fw addr(26ccefc3), off(100)
[   13.199517] Firmware pointer id(1):size(19548), fw addr(c5255120), off(10736)
[   13.206250] Firmware pointer id(2):size(11504), fw addr(ddc90ae8), off(30284)
[   13.213537] Firmware pointer id(3):size(23076), fw addr(3f7138fe), off(41788)
[   13.220610] VRX518 PPE Firmware header info
[   13.227736] 	PTM Version: 3.5.75
[   13.231727] 	PTM Feature: A0000000
[   13.235187] 	ATM Version: 3.6.5
[   13.238398] 	ATM Feature: B0000000
[   13.241449] 	Compability ID: 00000004
[   13.244911] 	Size: 00000010
[   13.248641] 	FW built Date: 3-25-2021
[   13.251259] 	Number of firmware: 4
[   13.255066] 		Firmware[0]: ID[0] size[2659] at[0x26ccefc3]
[   13.258369] 		Firmware[1]: ID[1] size[4887] at[0xc5255120]
[   13.263851] 		Firmware[2]: ID[2] size[2876] at[0xddc90ae8]
[   13.269306] 		Firmware[3]: ID[3] size[5769] at[0x3f7138fe]
[   13.274878] vrx518_tc:tc_drv_init: Intel(R) SmartPHY DSL(VRX518) PCIe TC Driver - version 1.5.12.4
[   13.280249] vrx518_tc:tc_drv_init: Copyright (c) 2018 Intel Corporation.
[   13.297145] Lantiq (VRX) DSL CPE MEI driver, version 1.11.1, (c) 2007-2016 Lantiq Deutschland GmbH
[   13.297396] Found 1 PCI VRX devices, 
[   13.315153] 
[   13.315153] 
[   13.315153] Lantiq CPE API Driver version: DSL CPE API V4.23.1
[   13.315215] 
[   13.315215] 
[   13.315215] Lantiq CPE API Driver - autoloading layout...
[   13.323076] 
[   13.323076] 
[   13.323076] Lantiq CPE API Device layout: 1 devices, 1 lines, 1 channels
[   13.331106] 
[   13.331106] Predefined debug level: 3
[   13.340834] 
[   13.340834] ++++++++++++++++++ MEI_InternalDevOpen ++++++++++++++++++
[   13.340834] 
[   13.346318] 
[   13.346318] ++++++++++++++++++ MEI_InternalDevOpen ++++++++++++++++++
[   13.346318] 
[   13.362138] GACT probability on
[   13.365718] Mirror/redirect action on
[   13.376353] u32 classifier
[   13.376395]     input device check on
[   13.377965]     Actions configured
[   13.398112] Loading modules backported from Linux version v6.1-rc8-0-g76dcd734eca2
[   13.398163] Backport generated by backports.git v5.15.81-1-41-g02e352527db5
[   13.437915] xt_time: kernel timezone is -0000
[   13.527907] PPP generic driver version 2.4.2

I will also try another firmware file as suggested by @pythonic.

Using a different firmware also did not bring up the DSL line.

# ubus call dsl  metrics | head -n 20
{
	"api_version": "4.23.1",
	"firmware_version": "8.13.0.12.1.2",
	"chipset": "Lantiq-VRX500",
	"driver_version": "1.11.1",
	"state": "Handshake",
	"state_num": 4,
	"up": false,
	"uptime": 0,
	"atu_c": {
		
	},
	"power_state": "L3 - No power",
	"power_state_num": 3,
	"upstream": {
		
	},
	"downstream": {
		
	},

The state went from Handshake to Exception to Idle request ...


Will also try to get VDSL configuration from the ISP.

Yes, for both the metrics and the kernel log the modem should actually be connected to the DSL line.

However, the log already shows the error message dc_ep_clk_on failed. To get the data path working on this device, you would definitely need the patch from this post (even if the modem managed to get a connection in the first place, and this would also be the case for VDSL).

So for some reason, the modem fails to synchronize to the DSL line. This is obviously an issue…

Edit: If the state switches directly from "Handshake" to "Exception", and never reaches "Full init", it may be a good idea to double check the configuration. @wood: What does the config dsl section in the network config file look like right now?

Hello @janh ,

I tried different settings and I am not sure which one I used last, since I lost that state. =0) I tried to build a firmware image with the patch included you mentioned, but had to de-brick the Fritzbox then and started over again. Good to see that bricking a Fritzbox is nearly impossible.

Here are the relevant parts of the dsl section .

config dsl 'dsl'
	option annex 'j'
	option ds_snr_offset '0'
	option tone 'bv'
	option xfer_mode 'atm'
	option line_mode 'adsl'
	option firmware '/lib/firmware/vdsl.bin'

As far as I remember I also tried to set the different 992.5 options for Annex. But I am happy to test again with a more targeted configuration. I am not really familiar with DSL and testing on my side was more like trial and error.

Thanks
Thomas

It is possible that the changed configuration doesn't actually take effect if the modem is already initialized (the VRX518 drivers are a bit buggy in that area). So if you try out different DSL settings, it might make sense to reboot the device or reload the kernel modules. These commands should work:

/etc/init.d/dsl_control stop
rmmod drv_dsl_cpe_api
rmmod drv_mei_cpe
modprobe drv_mei_cpe
modprobe drv_dsl_cpe_api
/etc/init.d/dsl_control start

Have you tried with a DSL configuration similar to the default? If there isn't some major issue somewhere that prevents ADSL from working, I would expect one of these configs to at least allow obtaining a sync (whether ATM then actually works is another question):

config dsl 'dsl'
	option annex 'j'
	option tone 'b'
config dsl 'dsl'
	option annex 'j'
	option tone 'b'
	option line_mode 'adsl'

Any other value for the "annex" and "tone" options is very unlikely to be correct in this case.

Hello @janh,

following your advice unloading the dsl* modules did help bring things a step further I guess. Using firmwares

brings the DSL line to a status "Showtime with TC-Layer sync" and shows the connection mode and annex as expected for now. Still trying to check with o2 to get VDSL working.

# ubus call dsl metrics
{
        "api_version": "4.23.1",
        "firmware_version": "8.13.0.13.1.2",
        "chipset": "Lantiq-VRX500",
        "driver_version": "1.11.1",
        "state": "Showtime with TC-Layer sync",
        "state_num": 7,
        "up": true,
        "uptime": 19,
...
        "annex": "J",
        "standard": "G.992.5",
        "mode": "G.992.5 (ADSL2+)",
        "upstream": {
                "trellis": true,
                "bitswap": false,
                "retx": false,
                "virtual_noise": false,
                "interleave_delay": 3250,
                "inp": 1.000000,
                "data_rate": 2446000,
                "latn": 6.000000,
                "satn": 5.600000,
                "snr": 6.600000,
                "actps": -40.700000,
                "actatp": 12.800000,
                "attndr": 2614000
        },
...

Well, still no internet connection. But I guess the last step would be to get the issue fixed related to dc_ep_clk_on failed?
I would greatly appreciate having this fixed in upstream as I am not really familiar with building patched firmwares on my own.

Does the dsl0 device show up now? If there isn't any other (ATM-related) issue, then it should now exist, as the dc_ep_clk_on failed issue only affects the actual data forwarding. There should also be some ATM-related messages in the kernel log now.

I just sent another message to the mailing list, to maybe improve the chances of the patch getting accepted.

First of all, thanks for all your work and effort you put in here. I really appreciate this!


The dsl0 device shows up in ip a, but does not get any address. I was expecting having a dsl0.7 device as well for the VLAN 7 but could not spot that.

# ip a
...
19: dsl0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

And there are several atm related messages in the kernel log.

Tue Apr 25 04:00:34 2023 kern.info kernel: [   11.548672] NET: Registered PF_ATMPVC protocol family
Tue Apr 25 04:00:34 2023 kern.info kernel: [   11.550905] NET: Registered PF_ATMSVC protocol family
Tue Apr 25 04:00:34 2023 kern.info kernel: [   11.626877] 	ATM Version: 3.5.36
Tue Apr 25 04:00:34 2023 kern.info kernel: [   11.630090] 	ATM Feature: B0000000
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.339691] vrx518_tc:atm_tc_load : TC switch to ATM
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.345572] vrx518_tc:atm_tc_hw_fw_init : port	  = 0
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.350232] vrx518_tc:atm_tc_hw_fw_init : irq	  = 107
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.355245] vrx518_tc:atm_tc_hw_fw_init : membase	  = 0xd1600000
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.360124] vrx518_tc:atm_tc_hw_fw_init : phy_membase = 0x40800000
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.366308] vrx518_tc:ppe_atm_fw_hw_init : ep_id[0]qsb_en[1]
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.391807] vrx518_tc:ppe_atm_fw_hw_init : atm_wtx_queue_cfg_init
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.391889] vrx518_tc:ppe_atm_fw_hw_init : atm_wtx_port_cfg_init
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.396919] vrx518_tc:ppe_atm_fw_hw_init : atm_wrx_queue_cfg_init
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.403075] vrx518_tc:ppe_atm_fw_hw_init : atm_ds_aal5_desq_cfg_ctxt_init
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.409078] vrx518_tc:ppe_atm_fw_hw_init : atm_ds_oam_desq_cfg_ctxt_init
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.415831] vrx518_tc:ppe_atm_fw_hw_init : atm_us_qos_cfg_init
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.422608] vrx518_tc:ppe_atm_fw_hw_init : atm_us_qos_des_cfg_ctxt_init
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.429306] vrx518_tc:ppe_atm_fw_hw_init : atm_local_des_cfg_ctxt_init
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.434730] vrx518_tc:atm_local_des_cfg_ctxt_init : Configure US local descriptor
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.441314] vrx518_tc:atm_pdbram_mem_layout : PDBRAM US: 218000
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.448905] vrx518_tc:atm_local_des_cfg_ctxt_init : Configure sharing CDMA
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.454612] vrx518_tc:atm_local_des_cfg_ctxt_init : Configure sharing CDMA context
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.461614] vrx518_tc:atm_local_des_cfg_ctxt_init : Configure DS local descriptor
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.469061] vrx518_tc:atm_pdbram_mem_layout : PDBRAM DS: 228000
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.476673] vrx518_tc:atm_local_des_cfg_ctxt_init : Configure DS OAM local descriptor
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.482392] vrx518_tc:atm_pdbram_mem_layout : PDBRAM DS OAM: 234000
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.490320] vrx518_tc:atm_pdbram_mem_layout : PDBRAM DS OAM: 234000
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.496459] vrx518_tc:atm_pdbram_mem_layout : PDBRAM DS OAM: 234000
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.502707] vrx518_tc:atm_pdbram_mem_layout : PDBRAM DS OAM: 234000
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.508898] vrx518_tc:atm_pdbram_mem_layout : PDBRAM DS OAM: 234000
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.515203] vrx518_tc:atm_pdbram_mem_layout : PDBRAM DS OAM: 234000
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.521562] vrx518_tc:atm_pdbram_mem_layout : PDBRAM DS OAM: 234000
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.527650] vrx518_tc:atm_pdbram_mem_layout : PDBRAM DS OAM: 234000
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.533953] vrx518_tc:atm_pdbram_mem_layout : PDBRAM DS OAM: 234000
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.540149] vrx518_tc:atm_pdbram_mem_layout : PDBRAM DS OAM: 234000
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.546470] vrx518_tc:atm_cdma_init : Configure CDMA in sharing mode
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.552751] vrx518_tc:atm_fw_load : atm_fw_load: Firmware size[5311] ptr[43bed13b]
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.559251] Loading ATM FW ver: 3.5.36
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.566686] pp32_load: ATM load data [43bed13b][5311]
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.583176] vrx518_tc:atm_datapath_init : atm_datapath_init : ep_id[0] irq_id[107]
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.586773] vrx518_tc:atm_fw_cfg_init : ATM FW PVC init
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.594309] vrx518_tc:atm_fw_cfg_init : atm_fw_cfg_init : No PVC table
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.599358] vrx518_tc:atm_tc_hw_fw_init : ATM TC init successfully
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.606080] vrx518_tc:atm_umt_init : 	UMT period: 400, dst: 0x408500c8
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.618633] vrx518_tc:atm_aca_init : txin: bswp: 0, hdsz:4, pd: dbase(0x2801c0), dnum(64), sz_indw(2), soc_dbase:0x827b8000, soc_dnum:0x80, soc cnt addr: 0x40b21480
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.629744] vrx518_tc:atm_aca_init : txout: bswp: 0, hdsz:1, pd: dbase(0x282580), dnum(64), sz_indw(2), soc_dbase:0x82577000, soc_dnum:0x80, soc cnt addr: 0x40b21484
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.644645] vrx518_tc:atm_aca_init : rxout: bswp: 0, hdsz:4, pd: dbase(0x284400), dnum(32), sz_indw(2), soc_dbase:0x82764000, soc_dnum:0x400, soc cnt addr: 0x40b21488
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.659324] vrx518_tc:atm_aca_init : rxin: bswp: 0, hdsz:4, pd: dbase(0x2855c0), dnum(32), sz_indw(2), soc_dbase:0x0, soc_dnum:0x0, soc cnt addr: 0x40b2148c
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.674073] vrx518_tc:atm_aca_init : txout: (stat:0x40a837d0, pd: 0x40a837d4, cnt: 0x40a837cc)
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.688210] vrx518_tc:atm_aca_init : rxout: (stat:0x40a837e8, pd: 0x40a837ec, cnt: 0x40a837e4)
Tue Apr 25 04:01:17 2023 kern.info kernel: [   62.696603] vrx518_tc:atm_aca_init : rxin: (stat:0x40a837dc, pd: 0x40a837e0, cnt: 0x40a837d8)
Tue Apr 25 04:01:17 2023 kern.info kernel: [   63.038588] vrx518_tc:atm_tc_load : ATM TC Loaded
Tue Apr 25 04:01:19 2023 local2.notice br2684ctl[4587]: Communicating over ATM 0.1.32, encapsulation: LLC
Tue Apr 25 04:01:19 2023 local2.err br2684ctl[4587]: setsockopt SO_ATMQOS 22
Tue Apr 25 04:01:30 2023 kern.info kernel: [   75.938363] vrx518_tc:atm_irq_handler : Disable TTHA
Tue Apr 25 04:03:08 2023 kern.info kernel: [   95.700221] vrx518_tc:atm_framer_requst_en : Enable TTHA!
Tue Apr 25 04:03:22 2023 kern.info kernel: [  109.512632] vrx518_tc:atm_showtime_enter : ATM Showtime: Enter[0]
Tue Apr 25 04:03:22 2023 kern.info kernel: [  109.512710] vrx518_tc:atm_showtime_enter : ATM Showtime: max rate[5768] args[0 5768]
Tue Apr 25 04:03:22 2023 kern.info kernel: [  109.517776] vrx518_tc:atm_showtime_enter : ATM Showtime: max rate[5768] args[5768 5768]
Tue Apr 25 04:03:22 2023 kern.info kernel: [  109.525667] vrx518_tc:atm_showtime_enter : ATM line[0]:enter showtime, cell rate: 0 - 5768, 1 - 5768
Tue Apr 25 04:05:54 2023 kern.info kernel: [  261.360725] vrx518_tc:atm_showtime_exit : Line[0]: show time exit!
Tue Apr 25 04:05:54 2023 kern.info kernel: [  261.363591] vrx518_tc:atm_irq_handler : Disable TTHA
Tue Apr 25 04:06:49 2023 kern.info kernel: [  316.419053] vrx518_tc:atm_framer_requst_en : Enable TTHA!
Tue Apr 25 04:07:03 2023 kern.info kernel: [  330.016111] vrx518_tc:atm_irq_handler : Disable TTHA
Tue Apr 25 04:07:23 2023 kern.info kernel: [  349.808510] vrx518_tc:atm_framer_requst_en : Enable TTHA!
Tue Apr 25 04:07:36 2023 kern.info kernel: [  363.593570] vrx518_tc:atm_showtime_enter : ATM Showtime: Enter[0]
Tue Apr 25 04:07:36 2023 kern.info kernel: [  363.593693] vrx518_tc:atm_showtime_enter : ATM Showtime: max rate[5768] args[0 5768]
Tue Apr 25 04:07:36 2023 kern.info kernel: [  363.598755] vrx518_tc:atm_showtime_enter : ATM Showtime: max rate[5768] args[5768 5768]
Tue Apr 25 04:07:36 2023 kern.info kernel: [  363.606679] vrx518_tc:atm_showtime_enter : ATM line[0]:enter showtime, cell rate: 0 - 5768, 1 - 5768

Last but not least, I got the message from o2 today that they will start the technology change to VDSL shortly. =0)

If you configured the WAN interface to use the device "dsl.7", then the interface should be created. The WAN IP addresses should be on the separate interface "pppoe-wan" once the PPPoE connection is established (but that is not going to happen without the PCIe hack applied).

It looks like there aren't any obvious errors (other than the device losing the connection and re-establishing it again towards the end). But I also don't know how it should look like for a working connection, as I don't have any line using ATM for testing.

Hey @janh ,

today I got VDSL, but did not get the link up in my openWRT installation. I got the dsl0.7 device this time, but no IP address.

There is still the issue with

[   11.432031] vrx518_tc:pcie_ep_probe: Total 1 VRX518 EP detected
[   11.444606] vrx518 0000:01:00.0: dc_ep_clk_on failed

But then ...

[  129.122685] IPv6: ADDRCONF(NETDEV_CHANGE): dsl0: link becomes ready
[  129.129080] IPv6: ADDRCONF(NETDEV_CHANGE): dsl0.7: link becomes ready
[  136.054425] vrx518_tc:ptm_stop: ptm stop
[  136.064981] vrx518_tc:ptm_open: ptm open
[  146.391575] ------------[ cut here ]------------
[  146.392024] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x2bc/0x2c0
[  146.395624] NETDEV WATCHDOG: dsl0 (vrx518): transmit queue 0 timed out
[  146.403717] Modules linked in: pppoe ppp_async nft_fib_inet nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet ath10k_pci ath10k_core ath pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_counter nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mac80211 iptable_mangle iptable_filter ipt_REJECT ipt_ECN ip_tables cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_comment xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY x_tables slhc sch_cake nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c hwmon crc_ccitt compat clip sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred act_gact drv_dsl_cpe_api drv_mei_cpe ifb br2684 vrx518_tc
[  146.405779]  atm vrx518 drv_ifxos md5 ghash_arm_ce cmac leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_qcom gpio_button_hotplug crc32c_generic
[  146.497533] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.15.106 #0
[  146.510571] Hardware name: Generic DT based system
[  146.516853] [<c030cdbc>] (unwind_backtrace) from [<c030985c>] (show_stack+0x10/0x14)
[  146.521536] [<c030985c>] (show_stack) from [<c0623540>] (dump_stack_lvl+0x40/0x4c)
[  146.529431] [<c0623540>] (dump_stack_lvl) from [<c03220b8>] (__warn+0x8c/0x100)
[  146.536804] [<c03220b8>] (__warn) from [<c0322194>] (warn_slowpath_fmt+0x68/0x78)
[  146.544019] [<c0322194>] (warn_slowpath_fmt) from [<c084994c>] (dev_watchdog+0x2bc/0x2c0)
[  146.551667] [<c084994c>] (dev_watchdog) from [<c038a428>] (call_timer_fn.constprop.0+0x24/0x88)
[  146.559821] [<c038a428>] (call_timer_fn.constprop.0) from [<c038ab48>] (__run_timers.part.0+0x1f0/0x25c)
[  146.568336] [<c038ab48>] (__run_timers.part.0) from [<c038abec>] (run_timer_softirq+0x38/0x68)
[  146.577973] [<c038abec>] (run_timer_softirq) from [<c03012b4>] (__do_softirq+0x10c/0x2c4)
[  146.586390] [<c03012b4>] (__do_softirq) from [<c0326c1c>] (irq_exit+0xbc/0x100)
[  146.594633] [<c0326c1c>] (irq_exit) from [<c036fcf4>] (handle_domain_irq+0x60/0x78)
[  146.601753] [<c036fcf4>] (handle_domain_irq) from [<c063ba0c>] (gic_handle_irq+0x7c/0x90)
[  146.609394] [<c063ba0c>] (gic_handle_irq) from [<c0300b3c>] (__irq_svc+0x5c/0x78)
[  146.617720] Exception stack(0xc107bf58 to 0xc107bfa0)
[  146.625190] bf40:                                                       00014200 00000000
[  146.630249] bf60: 00000001 c0312880 00000003 c0d04f28 c107a000 00000000 00000000 ffffe000
[  146.638408] bf80: 00000000 c0d04f5c c0d04fcc c107bfa8 c03070ac c03070b0 60000013 ffffffff
[  146.646549] [<c0300b3c>] (__irq_svc) from [<c03070b0>] (arch_cpu_idle+0x38/0x3c)
[  146.654708] [<c03070b0>] (arch_cpu_idle) from [<c035106c>] (do_idle+0x238/0x298)
[  146.662172] [<c035106c>] (do_idle) from [<c03513d0>] (cpu_startup_entry+0x18/0x1c)
[  146.669625] [<c03513d0>] (cpu_startup_entry) from [<80301510>] (0x80301510)
[  146.677936] ---[ end trace 50325a5c0e245807 ]---
[  151.712815] vrx518_tc:ptm_stop: ptm stop
[  151.723813] vrx518_tc:ptm_open: ptm open

I did not have the chance to test the image you provided yet, since the time I can take down internet at home is very limited. =0)
Will try that next time...

That is the expected result of the dc_ep_clk_on failed error, so it should go away if you switch to a build with the patch.

Alright, just tested with your image and I did get an DSL link and internet access, IPv4 and IPv6 address.
Whereas the download speed is much slower than expected ~20Mbit vs 50Mbit, but upload speed was good at 10Mbit and as expected.

Is the sync speed of the DSL connection already that low? The current DSL metrics may help to diagnose. And ideally also spectrum graphs, which should be available from the "Status -> DSL Status" menu provided by the "luci-mod-dsl" package (which is already included in the image I sent you).

I did some more tests and found a hint here in the forum to enable WMM, which finally have the expected bandwidth.
So issue was WiFi in this case.

I am also hoping that your patch will make it into the next release. Let me know if I can vote somewhere or help by other means.

Thanks
Thomas

WMM is a hard requirement for 802.11n and newer, without it, you're limiting yourself to 54 MBit/s.

1 Like

For the record...another rather old device also had speeds at 12Mbit, which was due WPA3, which I thought was a good idea to enable it.
Now with WMM mode enabled and WPA2 only, performance is as expected.