VDSL on Fritzbox 7362SL

Hi everybody,

my Fritzbox 7326SL is successfully running Openwert 22.0.3. I can connect to Telekom easily via DSL but only get 16Mbit/s so possible only DSL instead of the 100Mbit VDSL which the connection provides when using a Fritzbox 7490.
I also tried to download, extract and upload the firmware as suggested in some articles but then I just get an error.

So my question is: has anyone successfully set up VDSL on this box with Openwrt? If so, what are the steps?

Regards, Alfonso

You definitely need a DSL firmware with vectoring support, otherwise the line only runs in a band-limited non-vectoring fallback mode.

What does the error message look like?

It should work fine with a DSL firmware extracted from the AVM firmware (the latest version would be 5.9.1.4.0.7-5.9.0.D.0.2 for Annex B, see here for download instructions).

Transfer the file to the device using scp. For example, you could create a new directory /etc/dsl/ and put it there. To make the firmware survive a sysupgrade, you should add the path to /etc/sysupgrade.conf (which can also be edited using the web interface in the configuration section under "Backup/Flash Firmware").

Then you need to configure the path of the firmware file in the DSL section of /etc/config/network (alternatively use the DSL options in the web interface).

config dsl 'dsl'
	option ds_snr_offset '0'
	option annex 'b'
	option firmware '/etc/dsl/my_firmware_file.bin'  # <- add or edit this line

Restart the DSL daemon using /etc/init.d/dsl_control restart to load the new firmware.

1 Like

Thx for your effort.

I followed your description and I get connected. The connection is still limited to 16Mbit/s instead of 100. The system log shows the following:

Wed Oct 12 20:45:13 2022 daemon.notice netifd: Interface 'wan' is enabled
Wed Oct 12 20:45:13 2022 daemon.notice netifd: Interface 'wan' is setting up now
Wed Oct 12 20:45:13 2022 kern.info kernel: [377315.538489] device dsl0 entered promiscuous mode
Wed Oct 12 20:45:14 2022 daemon.err insmod: module is already loaded - slhc
Wed Oct 12 20:45:14 2022 daemon.err insmod: module is already loaded - ppp_generic
Wed Oct 12 20:45:14 2022 daemon.err insmod: module is already loaded - pppox
Wed Oct 12 20:45:14 2022 daemon.err insmod: module is already loaded - pppoe
Wed Oct 12 20:45:14 2022 daemon.info pppd[15296]: Plugin pppoe.so loaded.
Wed Oct 12 20:45:14 2022 daemon.info pppd[15296]: PPPoE plugin from pppd 2.4.9
Wed Oct 12 20:45:14 2022 daemon.notice pppd[15296]: pppd 2.4.9 started by root, uid 0
Wed Oct 12 20:45:19 2022 daemon.info pppd[15296]: PPP session is 44
Wed Oct 12 20:45:19 2022 daemon.warn pppd[15296]: Connected to 84:b5:9c:68:a1:26 via interface dsl0.7
Wed Oct 12 20:45:19 2022 kern.info kernel: [377321.229574] pppoe-wan: renamed from ppp0
Wed Oct 12 20:45:19 2022 daemon.info pppd[15296]: Renamed interface ppp0 to pppoe-wan
Wed Oct 12 20:45:19 2022 daemon.info pppd[15296]: Using interface pppoe-wan
Wed Oct 12 20:45:19 2022 daemon.notice pppd[15296]: Connect: pppoe-wan <--> dsl0.7
Wed Oct 12 20:45:19 2022 daemon.info pppd[15296]: Remote message: SRU=1479#SRD=20373#
Wed Oct 12 20:45:19 2022 daemon.notice pppd[15296]: PAP authentication succeeded
Wed Oct 12 20:45:19 2022 daemon.notice pppd[15296]: peer from calling number 84:B5:9C:68:A1:26 authorized
Wed Oct 12 20:45:19 2022 daemon.notice pppd[15296]: local  IP address XXX
Wed Oct 12 20:45:19 2022 daemon.notice pppd[15296]: remote IP address YYY
Wed Oct 12 20:45:19 2022 daemon.notice pppd[15296]: primary   DNS address 217.237.151.51
Wed Oct 12 20:45:19 2022 daemon.notice pppd[15296]: secondary DNS address 217.237.149.205
Wed Oct 12 20:45:19 2022 daemon.notice pppd[15296]: local  LL address XXX
Wed Oct 12 20:45:19 2022 daemon.notice pppd[15296]: remote LL address YYY
Wed Oct 12 20:45:19 2022 daemon.warn dnsmasq[1]: failed to create listening socket for XXX%pppoe-wan: Address not available
Wed Oct 12 20:45:19 2022 daemon.warn dnsmasq[1]: failed to create listening socket for XXX%pppoe-wan: Address not available
Wed Oct 12 20:45:20 2022 daemon.notice netifd: Network device 'pppoe-wan' link is up
Wed Oct 12 20:45:20 2022 daemon.notice netifd: Interface 'wan6' is enabled
Wed Oct 12 20:45:20 2022 daemon.notice netifd: Network alias 'pppoe-wan' link is up
Wed Oct 12 20:45:20 2022 daemon.notice netifd: Interface 'wan6' has link connectivity
Wed Oct 12 20:45:20 2022 daemon.notice netifd: Interface 'wan6' is setting up now
Wed Oct 12 20:45:20 2022 daemon.notice netifd: Interface 'wan' is now up

The command ubus call dsl metrics returns information about the DSL connection. Can you post the output here?

The command ubus call dsl metrics returns information about the DSL connection. Can you post the output here?

{
	"api_version": "4.17.18.6",
	"firmware_version": "5.9.1.4.0.7",
	"chipset": "Lantiq-VRX200",
	"driver_version": "1.5.17.6",
	"state": "Showtime with TC-Layer sync",
	"state_num": 7,
	"up": true,
	"uptime": 641,
	"atu_c": {
		"vendor_id": [
			181,
			0,
			66,
			68,
			67,
			77,
			194,
			127
		],
		"vendor": "Broadcom 194.127",
		"system_vendor_id": [
			181,
			0,
			66,
			68,
			67,
			77,
			0,
			0
		],
		"system_vendor": "Broadcom",
		"version": [
			118,
			49,
			50,
			46,
			48,
			52,
			46,
			49,
			50,
			55,
			32,
			32,
			32,
			32,
			32,
			0
		],
		"serial": [
			101,
			113,
			32,
			110,
			114,
			32,
			112,
			111,
			114,
			116,
			58,
			50,
			50,
			32,
			32,
			111,
			101,
			109,
			105,
			100,
			32,
			115,
			111,
			102,
			116,
			119,
			97,
			114,
			101,
			114,
			101,
			118
		]
	},
	"power_state": "L0 - Synchronized",
	"power_state_num": 0,
	"xtse": [
		0,
		0,
		0,
		0,
		0,
		0,
		0,
		2
	],
	"annex": "B",
	"standard": "G.993.2",
	"profile": "17a",
	"mode": "G.993.2 (VDSL2, Profile 17a)",
	"upstream": {
		"vector": false,
		"trellis": true,
		"bitswap": false,
		"retx": false,
		"virtual_noise": false,
		"interleave_delay": 12000,
		"data_rate": 1580000,
		"latn": 3.000000,
		"satn": 3.000000,
		"snr": 9.700000,
		"actps": -90.100000,
		"actatp": 2.700000,
		"attndr": 1721000
	},
	"downstream": {
		"vector": false,
		"trellis": true,
		"bitswap": false,
		"retx": true,
		"virtual_noise": false,
		"interleave_delay": 640,
		"data_rate": 21691000,
		"latn": 5.100000,
		"satn": 5.100000,
		"snr": 6.300000,
		"actps": -90.100000,
		"actatp": 12.800000,
		"attndr": 22020096
	},
	"errors": {
		"near": {
			"es": 0,
			"ses": 0,
			"loss": 0,
			"uas": 172,
			"lofs": 0,
			"fecs": 0,
			"hec": 0,
			"ibe": 0,
			"crc_p": 1,
			"crcp_p": 0,
			"cv_p": 0,
			"cvp_p": 0,
			"rx_corrupted": 1680,
			"rx_uncorrected_protected": 1664,
			"rx_retransmitted": 0,
			"rx_corrected": 16,
			"tx_retransmitted": 0
		},
		"far": {
			"es": 19,
			"ses": 6,
			"loss": 0,
			"uas": 172,
			"lofs": 0,
			"fecs": 5680,
			"hec": 0,
			"ibe": 0,
			"crc_p": 0,
			"crcp_p": 0,
			"cv_p": 0,
			"cvp_p": 0
		}
	}
}

The firmware seems to be loaded correctly and there doesn't appear to be anything else that is obviously wrong. Do you have another device to test (or can you alternatively revert to stock firmware temporarily)?

There is a chance your line may have gotten stuck in the fallback profile and needs a manual reset. In that case you would need to contact the ISP (if you are a direct customer of Telekom, the online form may even allow to perform a line reset directly).

I'd at least keep the VDSL line unconnected for ~15 minutes, that might already help sorting things out.

The firmware seems to be loaded correctly and there doesn't appear to be anything else that is obviously wrong. Do you have another device to test (or can you alternatively revert to stock firmware temporarily)?

I also have a Fritzbox 7490 with FritzOS 7.29. With that 100Mbits are provided easily.

I'd at least keep the VDSL line unconnected for ~15 minutes, that might already help sorting things out.

I'll try that as soon as possible (not before next week, though). Until now I have always switched from 7490 to 7362SL right away.

Since my line is not vector enabled I cannot confirm vectoring on my 7362SL . You might try different build like master or 22.03.1 and different blob (5.7.B.5.0.7-5.7.5.4.0.1) .There is also PR for 7490 so You might build firmware and use EVA boot to run it without flashing. It should work (unless proven otherwise :wink: )

There is definitely no general issue with the 7362SL. I used the same model for testing during development of the vectoring fixes. The DSL firmware I used also reported itself as version 5.9.1.4.0.7 (although at least two different revisions with that version have been shipped in AVM firmware).

I'd at least keep the VDSL line unconnected for ~15 minutes, that might already help sorting things out.

Didn't make any difference:

{
	"api_version": "4.17.18.6",
	"firmware_version": "5.9.1.4.0.7",
	"chipset": "Lantiq-VRX200",
	"driver_version": "1.5.17.6",
	"state": "Showtime with TC-Layer sync",
	"state_num": 7,
	"up": true,
	"uptime": 740,
	"atu_c": {
		"vendor_id": [
			181,
			0,
			66,
			68,
			67,
			77,
			194,
			127
		],
		"vendor": "Broadcom 194.127",
		"system_vendor_id": [
			181,
			0,
			66,
			68,
			67,
			77,
			0,
			0
		],
		"system_vendor": "Broadcom",
		"version": [
			118,
			49,
			50,
			46,
			48,
			52,
			46,
			49,
			50,
			55,
			32,
			32,
			32,
			32,
			32,
			0
		],
		"serial": [
			101,
			113,
			32,
			110,
			114,
			32,
			112,
			111,
			114,
			116,
			58,
			50,
			50,
			32,
			32,
			111,
			101,
			109,
			105,
			100,
			32,
			115,
			111,
			102,
			116,
			119,
			97,
			114,
			101,
			114,
			101,
			118
		]
	},
	"power_state": "L0 - Synchronized",
	"power_state_num": 0,
	"xtse": [
		0,
		0,
		0,
		0,
		0,
		0,
		0,
		2
	],
	"annex": "B",
	"standard": "G.993.2",
	"profile": "17a",
	"mode": "G.993.2 (VDSL2, Profile 17a)",
	"upstream": {
		"vector": false,
		"trellis": true,
		"bitswap": false,
		"retx": false,
		"virtual_noise": false,
		"interleave_delay": 12000,
		"data_rate": 1577000,
		"latn": 3.000000,
		"satn": 3.000000,
		"snr": 9.600000,
		"actps": -90.100000,
		"actatp": 2.700000,
		"attndr": 1716000
	},
	"downstream": {
		"vector": false,
		"trellis": true,
		"bitswap": true,
		"retx": true,
		"virtual_noise": false,
		"interleave_delay": 640,
		"data_rate": 21711000,
		"latn": 5.100000,
		"satn": 5.100000,
		"snr": 6.400000,
		"actps": -90.100000,
		"actatp": 12.800000,
		"attndr": 22118400
	},
	"errors": {
		"near": {
			"es": 0,
			"ses": 0,
			"loss": 2,
			"uas": 439752,
			"lofs": 0,
			"fecs": 0,
			"hec": 0,
			"ibe": 0,
			"crc_p": 1,
			"crcp_p": 0,
			"cv_p": 0,
			"cvp_p": 0,
			"rx_corrupted": 6823,
			"rx_uncorrected_protected": 6798,
			"rx_retransmitted": 0,
			"rx_corrected": 25,
			"tx_retransmitted": 0
		},
		"far": {
			"es": 19,
			"ses": 6,
			"loss": 0,
			"uas": 439752,
			"lofs": 0,
			"fecs": 6462,
			"hec": 0,
			"ibe": 0,
			"crc_p": 0,
			"crcp_p": 0,
			"cv_p": 0,
			"cvp_p": 0
		}
	}
}

That is pretty unfortunate as I'd rather have openwrt running on the front line than the 7490 with a more one year old OS which in addition makes it difficult to route VPN traffic over the 7362SL to the lan https://forum.openwrt.org/t/openvpn-server-general-understanding-of-forwarding-and-routing/139387
But that's another story