Fritzbox3370 abysmal dsl data rate

Good Day!

First of all thank you very much for this great project.
I'm fairly new here, please consider that I'm doing something completely wrong, im sorry in advance.

If im using my fritzbox 7412 with stock firmware at my location i get something about 50/10 Through DSL, which I have booked.
If im using fritzbox 3370 with openwrt, I land at:

Hostname OpenWrt
Model AVM FRITZ!Box 3370 Rev. 2 (Micron NAND)
Architecture xRX200 rev 1.2
Target Platform lantiq/xrx200
Firmware Version OpenWrt 22.03.0-rc2 r19374-34b6abf5a8 / LuCI openwrt-22.03 branch git-22.140.66268-ef99568

Line State: Showtime with TC-Layer sync
Line Mode: G.993.2 (VDSL2, Profile 17a)
Line Uptime: 0h 1m 16s
Annex: B
Data Rate: 12.501 Mb/s / 1.561 Mb/s
Max. Attainable Data Rate (ATTNDR): 13.298 Mb/s / 1.592 Mb/s
Latency: 0.25 ms / 0.00 ms
Line Attenuation (LATN): 10.5 dB / 3.5 dB
Signal Attenuation (SATN): 10.5 dB / 3.5 dB
Noise Margin (SNR): 7.3 dB / 9.2 dB
Aggregate Transmit Power (ACTATP): 14.5 dB / -4.6 dB
Forward Error Correction Seconds (FECS): 0 / 2186
Errored seconds (ES): 202 / 5584
Severely Errored Seconds (SES): 43 / 2143
Loss of Signal Seconds (LOSS): 21 / 0
Unavailable Seconds (UAS): 7114 / 7114
Header Error Code Errors (HEC): 0 / 0
Non Pre-emptive CRC errors (CRC_P): 0 / 0
Pre-emptive CRC errors (CRCP_P): 0 / 0
ATU-C System Vendor ID: Broadcom 193.214
Power Management Mode: L0 - Synchronized

Is there something visible thats wrongly set up?

Im thinking about just using the 3370 behind the 7412, if I cant fix it.

I tried openwrt 21.stable, several DSL firmware blobs, ranging from no connection at all to same results.
Any direction what might be wrong?
Thank you very much!

Which country and which ISP? Also could you use @janh's great go-dsl to collect SNR and Bitloading spectra and post these here.

As a completely wild speculation, I think your problem could be that your Huawei MSAN moved you onto a non-vectoring fall-back profile (which uses only frequencies up to 2.2 MHz). Most linecards should switch back to using vectoring if your modem supports that (by using a vectoring enabled linecard) but IIRC some Huawei devices can become stuck on the fall-back profile and need a port reset (or even a line card reset)...

1 Like

Germany: ISP o2
Im not sure about what you tried to say with Huawei;
The other end should be a Broadcom device.

My Fritzbox on stock firmware says the following:
|DSLAM-Datenrate Max.|kbit/s|63680|12736|
|DSLAM-Datenrate Min.|kbit/s|1152|0|
|Aktuelle Datenrate|kbit/s|63679|12735|
|Nahtlose Ratenadaption||aus|aus|
|Impulsstörungsschutz (INP)||23|34|
|Trägertausch (Bitswap)||an|aus|

I havn't used the go-dsl, if I understood it correctly I can probe via SSH, right?

Which DSL firmware versions did you try? You need a firmware with vectoring support (the last digit needs to be 7). The most recent stable Annex B firmware from AVM identifies itself as Lantiq version (VDSL) / 5.9.0.D.0.2 (ADSL). (Instructions for extracting)

$ sha256sum vr9-B-dsl.bin 
9d5277b36b322e66d634f5bcf3c9a72e97b80db03506f8494e345790fa22c29b  vr9-B-dsl.bin

Also, for proper vectoring support you should use a snapshot image of OpenWrt, as the fixes are not included in any stable release. (This is not directly related to your issue though, the typical symptoms of that issue would be slowly decreasing SNR/SNRM over time.)

The DSL modem itself is made by Broadcom, but this is just a piece of a larger system (MSAN). Assuming that o2 rents your line from DTAG, the reported version number actually suggests that the system vendor is Huawei in your case.

As system vendors use different software, there can be slight differences in behaviour, even if the modem itself is from the same vendor. And the mentioned issue about lines getting stuck in the non-vectoring fallback is one of these differences which existed at least at some point (but it is possible this has been fixed since).

Yes, for OpenWrt devices you would need to use the Lantiq SSH client option.

1 Like

OK, then the MSAN is likely operated by Deutsche Telekom and you likely are in the fall-back profile.

Broadcom is the maker of the Chip in the linecard at the remote end, but the chassis can be made by a number of manufacturers (Nokia, Adtran, Huawei, see e.g. here for which formware versions are currently used by which Manufacturer). Broadcom sells chips and CPE SoCs but does not build MSANs/DSAMs.

Does your nice tool also work with stock fritzboxes or is that foiled by a lack of ssh/telnet in FBs?


Are strong indicators for the non-vectoring fall-back profile under OpenWrt, while FritzOS negotiated vectoring successfully...

Yes, it uses the web interface and can optionally load the support data for additional information. (All of the supported device types are listed in the README file. Whenever SSH or Telnet is used this is part of the client type string.)

1 Like
  1. @janh the Sha256sum you posted is the same that I have.
  2. I have used a snapshot image of 21.Openwrt, installed about a month ago, which had the same issue.
    Good to know, I'll reinstall later this eveningand try again. Also: I use the dsl tool and post back.
  3. I suspected a Fallback also. But I was wondering why it was happening for me and not for others.
  4. Regarding the information with the MSAN; thank you, I didn't knew we have Huawai in use, I mean I know they are big but just like with cisco there are some indications about industry espionage which makes me worry (->snowden)...

Thanks so far, I learn..

Have you made sure that the modem is actually using this firmware? The currently loaded version is included in the output of ubus call dsl metrics. (Alternatively you could use vig, and it is also shown in my tool.)

Just to be clear, by snapshot image i mean development snapshot (these don't have a version number like 21.* or 22.*).

Yes, it was a development snapshot, about 1 month old, I wasnt precise, I wanted to say it was in 21 development cycle.
Nevertheless, there are some things happening right now therefore I'll try another snapshot.
The one I'm using is missing something, yes?
OpenWrt 22.03.0-rc2 r19374-34b6abf5a8 / LuCI openwrt-22.03 branch git-22.140.66268-ef99568

	"api_version": "",
	"firmware_version": "",
	"chipset": "Lantiq-VRX200",
	"driver_version": "",
	"state": "Full init",
	"state_num": 5,
	"up": false,
	"uptime": 8644,
	"atu_c": {

it cycles between: full init - handshake - silent - exception.
then it gets the downgraded dsl...
anything else I can provide?

"annex": "B",
	"standard": "G.993.2",
	"profile": "17a",
	"mode": "G.993.2 (VDSL2, Profile 17a)",
	"upstream": {
		"vector": false,
		"trellis": true,
		"bitswap": true,
		"retx": true,
		"virtual_noise": false,
		"interleave_delay": 0,
		"data_rate": 1569000,
		"latn": 3.200000,
		"satn": 3.200000,
		"snr": -1.300000,
		"actps": -90.100000,
		"actatp": -3.900000,
		"attndr": 1565000
	"downstream": {
		"vector": false,
		"trellis": true,
		"bitswap": true,
		"retx": true,
		"virtual_noise": false,
		"interleave_delay": 230,
		"data_rate": 13748000,
		"latn": 10.200000,
		"satn": 10.200000,
		"snr": 6.200000,
		"actps": -90.100000,
		"actatp": 12.800000,
		"attndr": 13975552

That's not a snapshot, and especially not one that contains the Vectoring fixes. But like @janh already said, that's just relevant for long-term stability, it shouldn't matter for the sync (any old OpenWrt should sync to Vectoring lines using the correct firmware binary).

Just to make sure, and I'm not even certain it matters much: My stanza in /etc/config/network regarding annex and tone looks as follows:

config dsl 'dsl'
        option annex 'b'
        option tone 'av'
        option firmware '<path-to-where-you-stored-your-firmware.bin>'

Because otherwise, I'm a bit stumped too. Nothing else in the config would possibly influence what the modem does. I am running the exact same firmware on my Fritz3370-used-as-modem, and it syncs with Vectoring just fine, exceptionally well even.

Does this happen for every connection? I'm seeing similar behaviour, but only on the first connection after a reboot of the device (or after manually reloading the DSL kernel modules). You can trigger a reconnect using acs 2.

It is also possible that there is something during the failed connection attempt that the MSAN doesn't like, and as a result it forces the line into the fallback profile.

Just to make sure, do you still get the full data rate when switching back to the device with original firmware? If not, this would be a case of the stuck-in-fallback-profile issue.

(And one more thing, just so you are aware of it: The ASSIA/DLM system in use by DTAG may misinterpret resyncs caused during testing as errors, and limit your maximum data rate as a result, in an attempt to stabilize the line. Even if that happens, it should go back after a few days/weeks of stable operation, though. I also want to add that it never happened for me, even when trying out changes during development, so it is possible that the system is actually better than its reputation.)

From one of your older posts, it seems you are on a Adtran MSAN (Broadcom 193.218). Is this still the case? This might be the important difference here.

It did happen for me (albeit using a Draytek Vigor 130b/ OEM firmware), it usually took 10-14 days (after each reboot/ firmware upgrade) to get back up to full speed again (the speed loss amounted to ~10%-15%, so not fallback profile niveau - but I never 'tested' excessive resyncs though).

Disclaimer: I no longer have VDSL access, so I can't re-check this.

Pretty much. I am on a Broadcom 194.127 (v12.04.127). Apparantly it has been updated earlier this year (early March IIRC).

This happened to me a few times while fiddling around with firmware versions. The "punishments" always happened in gradual "steps" with obviously artificial limits (e.g. to exactly 100 mbit, then 90, then 80). But I never got downgraded to a sync without Vectoring. I'm not an expert (in anything) but I'm having a hard time believing this is the problem at hand.

I know, I was referring to the former installation of Openwrt, it didn't work so I naturally installed the newest kind-of-stable.
You can advise me which one to install, for the vectoring fixes.

I had option tone bv, but changed it now.

I issued your command and took a Note of the connection process, the states are as follows:
(S)ilent (F)ull(i)nit S (H)andshake S Fi (E)xception S H S H Fi S H S E S Fi (I)dle(r)equest S H S Fi Ir S H S Fi Ir H S Notinitialize H Fi S Ir H Fi S H S Fi E S H S E H Fi Ir S H S Fi Ir H Ir H Fi S H S E S Fi Ir H S Fi Success.

My router surely shook a lot of hands.
I think also that the MSAN at some point gives up on him and changes protocoll.

The device with original firmware isn't a 3370 it is a 7412, but it indeed gets full speed.; atleast yesterday it worked about 4 times.

Any more Ideas? I would prefer just using the Fritzbox3370 since 1und1 wants their 7412 back..
Should I probe with the go-dsl tool mentioned earlier or did I provide the information asked for?
Thanks a lot!

This version also matches Adtran.

While looking it up again, I also noticed that the "stuck-in-fallback-profile" issue is/was actually specific to Adtran, so it isn't actually relevant for @neophrema's case.

Any image from here includes the vectoring fixes. Note that these are development snapshots and as described in the link I posted earlier, these do not include a graphical user interface (it has to be installed manually afterwards).

But again, this won't help for your current issue, so you may still do the upgrade after this is taken care of. The issue which is fixed by the vectoring changes occurs only after the connection is already established.

To stick with the specification 1TR112 by DTAG, you should use the value b. Other carrier sets can also work in practice (even V43 which is explicitly forbidden), but it is probably best to stick with the rules in this case.

Interestingly the DSL init script does not enable B43c (which is one of the allowed carrier sets). You could try to edit /etc/init.d/dsl_control and change the relevant line to tone_vdsl_b="0x81" to check if this helps (this applies only to the config option value b). You need to restart the service using /etc/init.d/dsl_control restart afterwards.

OK, something is clearly wrong here, it shouldn't take that many tries to reach showtime state. In this case, it seems quite reasonable that the MSAN gives up and switches to the fallback profile.

Are there any differences between using the 3370 and the 7412 apart from firmware? For example different cable between socket and modem? I've already had two of those (from Fritzboxes) which had a loose contact resulting in increased errors... (wiggling the cable at both ends and in between helps to find this kind of issue)

One possibility could also be that the modem in the 3370 is just broken. You could try returning to stock firmware to rule this out (or try OpenWrt on the 7412, but maybe not worth the risk if you actually need to return it - although I'm surprised they want it back, I always thought 1&1 allows you to keep the devices).

I don't know if it is going to provide any useful information in this case, but on the other hand having a look at the spectrum graphs (SNR etc.) probably wouldn't hurt (also from the working Fritzbox if you connect it again).

Nothing changed.

I use the same Cable, I just switch it.

Maybe I overlooked something: Can I only revert it with the AVM recovery tool? Cause it appears to be an exe file and I dont have a windows pc anywhere accessible cause I burned that evil ;-).

I thought so too.
1und1 was troublesome with me and I havn't seen something like them before. I tried to cancel my contract for two years in a row after the binding 2 years, they simply refused to do so, lied to me on the phone, didn't accept papers, lost them or whatever- made it unbelievable hard to end the contract. One employee even told me in secret that they are advised to hold customers as long as possible even against their informed wish. In the end I was telling them that I get a Lawyer if they wont let me go, cause EU laws have changed (which they didn't inform me to either-, I asked for the fastest termination they just ignored it).
After ages and hours of calling they let me leave. But wrote that they want the router back.
I assume it's cause of the trouble I had with them.

Maybe it works if you flash the same way as initial installation of OpenWrt, but using the kernel.image and filesystem.image from the AVM firmware file?

Otherwise, you could try using Wine or alternatively using YourFritz scripts (I think just the last step, i.e. creating an in-memory image using image2ram and loading it with eva_to_memory would be enough in that case, as TFFS should still be intact).

Nope, he didn't digest the image files. I used the adam loader, like I installed Openwrt. It was a .bin file I flashed for openwrt..

ftp> put /home/xanthippe/Downloads/kernel.image
227 Entering Passive Mode (192,168,178,1,12,14)
501 unknown variable /home/xanthippe/Downloads/kernel.image

I'll try to search the internet...

I think this command should include the partition name. See the 3370 wiki page, and try the commands exactly as listed (except for exchanging the file names for the two files you extracted from the AVM firmware image).

Yes you are right.
I managed to flash the FritzBox3370 but im hung in a reboot loop, PowerLED gets stable, then reboot with outer ones red, inner ones green.
I will have to do some work till end of weekend, i'll report back then.