No stable connection with VDSL(vectoring)+TD-W8970B/9980B

Background:
I live in Germany and have a VDSL50 contract with 1und1.
Line is realized via Telekom.
Telekom has switched "my" DSLAM to vectoring, therefore my VDSL line has max 100Mb .
DSLAM is running on Broadcom 177.191 .
The 50Mbit limit is done on another layer.

Problem:
The VDSL connection is (with TD-W8970B/9980B) not stable.
Depending on the used Firmware file the modem is online for max. 5 days before a reconnect occurs.
(I am not sure if initiated each time by the router or the linecard)

What I have tried:

  • I am using OpenWrt Trunk (I wanted to be able to use software offloading)
  • First I tried a TD-W8970B. Because I was not sure if it is a HW issue, I bought a TD-W9980B.
    Now it seems the W8970B is a little bit better though.
  • I have tested 3 different vectoring capable FW-files:
    • 6.8.6.: not usable, line drops after ~20 seconds
    • 7.8.9.: VDSL is online for 3 to 5 days. After some hours the SNR is decreasing till ~3dB. Other values from status information seems to be stable.
    • 9.1.4.: VDSL is online for a few hours to one day. SNR seems to be more stable, before line drops SNR is going down.
  • I tested SNR offset of one and two dB.
  • I have now a Fritzbox 7412 (with vanilla FW) running for 3 days.(Box has also a Lantiq chipset)
    The SNR has not changed since the first hour (10 down/11 up) while it has connected with a higher download rate compared to W8970B.
    Also there are no errors tracked (ES/CRC), neither up or down.

Is it possible to raise the loglevel for the VDSL connection to get more information? At the moment it shows only "enter/leaving showtime"in the log.
Or something like the graphical spectrum in Fritzbox?
I wonder that the SNR only goes down, never up. If there would be a noise from a washing machine or whatever I thought it would go back to normal again.
Or is my problem maybe related to the 50Mbit that I get in real? Because, Fritzbox is telling me about the 50Mbit in the logfile, I wonder where the information is submitted and if maybe OpenWrt can't deal with that.

Here a example of the VDSL-line values with FW 7.8.9 and one dB SNR offset:
(the "error seconds" at the beginning are from last connection, were not resetted)

Mon Feb  4 05:00:00 CET 2019
Forward Error Correction Seconds (FECS):  Near: 0 / Far: 68027
Errored seconds (ES):                     Near: 47024 / Far: 1
Severely Errored Seconds (SES):           Near: 31 / Far: 0
Loss of Signal Seconds (LOSS):            Near: 0 / Far: 0
Unavailable Seconds (UAS):                Near: 423 / Far: 423
Data Rate:                                Down: 96.112 Mb/s / Up: 28.557 Mb/s
Noise Margin (SNR):                       Down: 7.0 dB / Up: 9.7 dB
Max. Attainable Data Rate (ATTNDR):       Down: 102.224 Mb/s / Up: 30.665 Mb/s
Line Uptime:                              13m 41s

.
.
.
Mon Feb  4 10:00:00 CET 2019
Forward Error Correction Seconds (FECS):  Near: 0 / Far: 68035
Errored seconds (ES):                     Near: 47024 / Far: 1
Severely Errored Seconds (SES):           Near: 31 / Far: 0
Loss of Signal Seconds (LOSS):            Near: 0 / Far: 0
Unavailable Seconds (UAS):                Near: 423 / Far: 423
Data Rate:                                Down: 96.112 Mb/s / Up: 28.557 Mb/s
Noise Margin (SNR):                       Down: 4.7 dB / Up: 9.9 dB
Max. Attainable Data Rate (ATTNDR):       Down: 94.276 Mb/s / Up: 30.665 Mb/s
Line Uptime:                              5h 6m 38s

.
.
.

Tue Feb  5 05:30:00 CET 2019
Forward Error Correction Seconds (FECS):  Near: 0 / Far: 81261
Errored seconds (ES):                     Near: 47025 / Far: 1
Severely Errored Seconds (SES):           Near: 31 / Far: 0
Loss of Signal Seconds (LOSS):            Near: 0 / Far: 0
Unavailable Seconds (UAS):                Near: 423 / Far: 423
Data Rate:                                Down: 96.112 Mb/s / Up: 28.557 Mb/s
Noise Margin (SNR):                       Down: 3.2 dB / Up: 8.8 dB
Max. Attainable Data Rate (ATTNDR):       Down: 84.451 Mb/s / Up: 30.665 Mb/s
Line Uptime:                              1d 0h 9m 8s

.
.
.

Sat Feb  9 07:45:00 CET 2019
Forward Error Correction Seconds (FECS):  Near: 0 / Far: 153528
Errored seconds (ES):                     Near: 74187 / Far: 1
Severely Errored Seconds (SES):           Near: 42 / Far: 0
Loss of Signal Seconds (LOSS):            Near: 0 / Far: 0
Unavailable Seconds (UAS):                Near: 423 / Far: 423
Data Rate:                                Down: 96.112 Mb/s / Up: 28.557 Mb/s
Noise Margin (SNR):                       Down: 2.2 dB / Up: 8.7 dB
Max. Attainable Data Rate (ATTNDR):       Down: 81.029 Mb/s / Up: 30.661 Mb/s
Line Uptime:                              5d 0h 5m 38s

Data from the Fritzbox after 3 days running:

Ausgehandelte Verbindungseigenschaften
		Empfangsrichtung 	Senderichtung
DSLAM-Datenrate Max.	kbit/s	109344	42000
DSLAM-Datenrate Min.	kbit/s	720	0
Leitungskapazität	kbit/s	124151	28028
Aktuelle Datenrate	kbit/s	104984	27910
Nahtlose Ratenadaption		aus	aus
 			
Latenz		fast	fast
Impulsstörungsschutz (INP)		27	30
G.INP		an	an
 			
Störabstandsmarge (SNR)	dB	11	10
Trägertausch (Bitswap)		an	an
Leitungsdämpfung	dB	12	12
 			
Profil	17a		
G.Vector		full	full
 			
Trägersatz		B43c	B43c

1 Like

The one firmware you haven't tried that may work is the 7.B.5 from the DM200 v1.0.0.52 (but is also in all the later DM200 firmware images as well).

Hi pythonic,
thank you for the info about the firmware.
I thought it would not be possible to use Annex A Firmware file on Annex B hardware - seems I was wrong :roll_eyes:
VDSL line is online since friday with 7.B.5. No errors so far, SNR has decreased from 7dB to 5.5db during first 12h, but seems to be stable now. Let's wait if it is still online on next friday.

Glad to hear that it seems to be hanging in there. Good luck!

The "new" firmware has not solved the problem. During the last week several reconnects occured, sometimes twice a day.
I am still wondering if there is an option to enable logging of the vdsl connection.
For example, on the Fritzbox screen you can see that there is Bitswap and G.INP enabled on the line, and I am not sure if both options are supported by OpenWrt.

Sorry to hear you still have a problem :(. Unfortunately in my experience the Lantiq chipset drivers don't hang on to lines with quite variable SNR very well, especially if SRA isn't active (even if SRA is enabled in the modem, it still has to be negotiated with the node/DSLAM). Anything less than about 5dB SNR is likely to cause a resync in the absence of SRA, whereas I have a Broadcom modem that will typically cope with short term (a few 10s of seconds) SNR drops to about 3.5-4dB without resyncing (that modem doesn't have SRA enabled either). I have a Fritz!Box 7490 too and that syncs at noticeably lower rates than the DM200 on my line - the FB firmware seems to be configured to operate with artificially more conservative SNR targets than other Lantiq based devices too, probably to try and promote stability at the cost of throughput.

Unfortunately adjusting the target SNR seems to only be possible for the downstream. My line is more problematic on the upstream and I'd have liked to try increasing the target upstream SNR to compensate...

If your Fritz!Box won't hold sync for considerably longer than the TP-Links, even with its likely more conservative settings, I'd suggest your real problem is your copper line to the node/DSLAM has problems - probably some corroded joins or the like (quite common problem here :frowning: ).

Unfortunately I'm not aware of one already existing :(. I have thought about trying to write an emulation of the Broadcom xdsltctl command complete enough to be used by the DSLstats program but that's a bigger project than I have time or energy for at the moment (especially as the Lantiq statistics don't really line up with the Broadcom statistics very well for some parameters :frowning: ...).

Bitswap and G.INP are entirely handled within the DSL chipset firmware, especially with the Netgear version which seems to have all the options enabled unlike some others (particularly from TP-Link). Does the Fritz!Box report that SRA is enabled? If so, do you ever see in the system event log a mention of the sync rates being adapted?

with my VDSL50
(TP-Link VR200v, Lantiq-VRX200, G.993.5 VDSL2)
i use OpenWrt18 and dsl firmware 5.8.1.5.0.7 from https://xdarklight.github.io/lantiq-xdsl-firmware-info/
(version:5.8.1.5.0.7-5.8.0.9.0.1, sha1sum:29de7210958de4ba57464685f680dd66e6fb5b36, file size:898856 bytes).

It works much better than 5.9.0.C.1.7-5.9.0.A.0.2.
it is up since 9 days and 4 hours.

here i found that one should change LCP settings in /etc/ppp/options in order to make the connection more sturdy:

good luck. :slight_smile:

-arne

1 Like