BT Home Hub 5A an O2-DSL (Telekom) reconnect relatively often

For me, on a Telekom line and a Draytek Vigor 130 modem, it takes somewhere between 10-14 days for the line rates to recover after multiple DSL disconnects (e.g. a modem firmware upgrade).

1 Like

I don't know if is is useful, but this is what I get on a Telekom VDSL with the same hardware and the same Firmware:

Data Rate:                                Down: 63.668 Mb/s / Up: 12.735 Mb/s
Line Attenuation (LATN):                  Down: 13.5 dB / Up: 13.1 dB
Signal Attenuation (SATN):                Down: 13.5 dB / Up: 13.5 dB
Noise Margin (SNR):                       Down: 4.8 dB / Up: 25.6 dB
Aggregate Transmit Power (ACTATP):        Down: 0.5 dB / Up: 8.3 dB
Max. Attainable Data Rate (ATTNDR):       Down: 61.050 Mb/s / Up: 38.219 Mb/s
Line Uptime Seconds:                      13645821
Line Uptime:                              157d 22h 30m 21s

I pay for a 50/10 connection, thus I don't have much to complain about. If I look at the historical data, it seems that it was syncing at an higher max down rate initially and it stabilized to these values after a few reconnects and from what I can see it never tried to bump them up again. I don't remember if the higher data rates where with this firmware or another.

So when they introduced vectoring DT also tried to introduce "open profiles" that is they tried to configure all links to use (up to) the highest sync rates they allow (the exact numbers changed, but right now for profile 17a that would be something like 116/42? or so). It turned out that this was not working as well as hoped, so DT switched back to profiles tailored for the specific contract rates (50/10 in your case). BUT at the same time the German regulator also clarified that contract rates are to be interpreted as net TCP/IP goodput and ISPs started* to (over-)provision** plans such that the contract speed could actually be measured. And since there are also yearly reports about the level of "over-achievement/-provisioning" by ISPs, DT opted for generous sync corridors for a given contract rate, with your ~64/13 being close to the allowed maximum sync of the DSLAM/MSAN.

I would guess you might have looked at these values before and after the switching of the provisioned rates?

*) Well the DOCSIS ISPs traditionally configured enough gross speed so that end users actually could see the contracted speeds (and more) as goodput in speedtest results; IIRC this was based/codified in a CISCO note or whitepaper, but DSL ISPs tended to interpret contract speeds as gross rates....

**) Over-provisioning is one way of describing it, under-reporting is another way ;), but this is semantics as the consequence is that consumers git a slight speed increase without a price hike, so thanks EU!

Yes, that seems to be a number that comes up often, but according to DT there are no fixed intervals that a strictly enforced, so this is probably driven by the DLM's control law, which might also look at the derivative of the change of error rates or similarly (such that it carefully tries to approach what it considers to be the robustly sustainable sync rate from below, after all its main purpose seems not to be to stabilize links after they proved unstable, but ideally to pro-actively set each link's sync rate such that the link never gets unstable*)**.

*) With various degrees of success, seems to work well for some links and almost not at all for others....
**) Most users probably do not notice/care much about every individual Mbps of the sync rate, but almost everybody notices unenforced resyncs, especially if these happen during a video conference of a phone call, so the pro-active approach should result in a reduction in the costly support infrastructure (hotlines/technicians).

I am not sure I understand the question. This is on a new connection (I moved recently and DT had to sent a technician to connect some cables, thus I guess this is a new connection from their point of view too). I have been using the BT HH5A from day one, albeit with different firmwares in the first weeks. I was routinely getting higher sync max rates with another firmware but with frequent (a few per day) disconnect. I settled on the current firmware that seem to give adequate rates for my data plan.

I have a little RRDtool database that records the status of the DSL connection (via the monitoring framework included in OpenWRT and a custom data source) and I see that at the beginning of the monitoring period it was syncing at 116 Mbps downlink rate (but not significantly higher uplink rate). However, I didn't record the firmware version used (and I am too lazy to cross reference my notes to the data).

If trying a new firmware highly i recommend 60 days (2 months max)
30 days for the line to stable agan
30 days to test firmware

However i sold my bt homehub 5a in the end as FTTH was layed but when on VDSL2 (FTTC) i used a fritzbox 7530 in bridge mode (frizOS) and then used a tp link wdr3600 via PPPoE (OpenWrt) so was not double NATed.

Unfortunately this connetion breaks too. It was the longest time with about 870 minhtes, but after that reconnect it was only 89 min. I'll test the next firmware on monday.

Well, the sync is influenced by both the firmware blob, and by what the DLM system allows as maximum, the longer a link behaves unstable the lower the DLM system will configure the DSLAM's maximum sync profile, so the DSLAM will never negotiate a sync higher than that....

Again, if you find a firmware blob that is stable and does neither cause resyncs or larger error counts to accumulate, the DLM shoud relax the sync throttling.

Ah, thanks for this information, I had indeed become confused.

Now is running. It shows:

Latency [Interleave Delay]: 0.13 ms [Fast] 0.0 ms [Fast]
Data Rate: Down: 63.668 Mb/s / Up: 26.997 Mb/s
Line Attenuation (LATN): Down: 16.8 dB / Up: 18.6 dB
Signal Attenuation (SATN): Down: 16.8 dB / Up: 18.6 dB
Noise Margin (SNR): Down: 15.1 dB / Up: 14.1 dB
Aggregate Transmit Power (ACTATP): Down: 7.6 dB / Up: 14.5 dB
Max. Attainable Data Rate (ATTNDR): Down: 95.356 Mb/s / Up: 34.167 Mb/s

I hope so this will be better then the tests before.

Good Morning,

there was again a reconnect. Connect time 663.8 minutes.

Looking through the logs, I noticed a line that I hadn't seen before. Is this a problem?

Tue Jun 15 03:21:32 2021 pppd[21311]: Remote message: Pedo mellon a minno : ######DEU.DTAG.7E5S7# -

I cannot edit the post before. The log-line ends with "unknown" in <...>.

Its not issue with firmware ... others had this message in past so not down to the DSL firmware on openwrt

Could be

  1. DSLAM update? or LLU (local loop bundle) where it goes of to O2 for PPPoE / PPP
  2. IP renew if your on dynamic IP and not Static iP?

That is the normal message O2 sends in the PPPoE AuthACK Message field; nothing to worry about. I note that other German ISPs like Telekom and 1&1 actually use that message to inform the modem about the approximate settings of the traffic shaper, which is overall more useful than the cute Tolkien quote O2 uses...

If you add the keyword "debug" (without quotes and without a leading #) to /etc/ppp/options you will get slightly more verbose ppp output in the log (use logread | grep -e pppd to extract only the ppp related entries from the system log, but you probably knew that)...

Ok.Thank U both. I only meant if it is a message that the modem should use to take the correct values or something like this. I'll add "debug" to /etc/ppp/options and tell U the results when it reconnects the next time.

Okay, it has no specific meaning and is also not required by anything. It is just a few othe ISPs have started to use that field for something more useful :wink:

Only if you have questions; make sure to redact your pppoe username and password (I think the password does not end up in the log, but the username does).

Yes, that is a sign of LLU, especially the bitstream access variant, in this specific case the ISP operating the actual lines (Deutsche Telekom), routes these packets to PPPoE-termination nodes operated by telefonica/O2 and these are configured to use that message during the negotiation... I note that normally this message is not displayed anywhere, so I bet this was a small easter-egg the network techs at o2 left for their colleagues....

This message is emitted every time the PPPoE connection is established/re-established, which is at least every 24 hours...

Thanks for this hint. I'll make sure :slight_smile:

Even on my Fritzbox i get messages about PPP for authorization so i think is a wide use message rather then been sneaky about it.

Best @ste can do is buy or make a cat5e cable to DSL to keep any noise levels down however this wont affect outside of property to Cabinet > DSLAM that will be down to DT

1 Like

I don't even know if you can buy something like that, and if it makes sense. It is my DSL connection cable and the HH5A has only RF11 socket. I think I've never seen a cable like this in CAT5e. But I'll look for it right away.

Well, FritzBoxes are the only known modems (to me at least), that actually evaluate the PPPoE Auth ACK message to set their internal traffic shaper correctly, but as far as I understand (last time I used a FritzBox was 2008) they will not show this message prominently in the GUI (they do show the extracted and processed shaper values however).

Cleaning up the internal wiring is good advise. I would also always try to mount the modem as close to the line's entry point in an apartment/house, and I would retire anf PLC/power line networking in my house as that often interferes with DSL...

1 Like