PPPoE error: Timeout - What's happening?

[#1]

Hi Plusnet, Everyone,

I'm wondering if anyone can shed any light on what might be happening here...

Every so often (every few weeks, if that?) I find that I've lost my Internet connection and the log from my Fritzbox 7530 includes messages along the lines of:

09.06.21 00:39:31 Internet connection established successfully. [..] Broadband PoP: acc-aln23.bs
09.06.21 00:24:37 PPoE error: Timeout. [5 messages since 09.06.21 00:23:42]
09.06.21 00:23:38 Internet connection cleared.
24.05.21 17:46:34 Internet connection established successfully. [..] Broadband PoP: acc-aln22.bs
24.05.21 17:46:29 Internet connection cleared.
24.05.21 17:46:29 PPPoE error: Timeout.

Generally speaking my connection is rock solid - I get a ~63/20 connection speed and with working from home am using my connection pretty much continuously for video calls etc without issue. In the evenings we do a lot of streaming and, again, no problems whatsoever. It's just every so often the - as above - we lose the connection and whilst a reset of the router instantly regains it I am wondering what might be happening here? The DSL layer remains connected - it is the Internet/IP connectivity over the top that drops out.

Interestingly I note that with the disconnection on 09.06.21 above the router reconnected itself after almost bang-on 15 minutes which makes me wonder if it (or something else elsewhere?) might've been acting in a timer to bring things back up. I haven't always seen this automatic reconnection though, instead requiring manual intervention from me, and given I run a mail+web server that I'd like 24/7 connectivity to I am a little worried there'll be a problem if I'm away on holiday etc and won't be able to reach.

I don't know the inner workings of how broadband works so would be grateful if anyone any ideas what these PPPoE timeouts are referring to and what might be causing them, assuming they are the cause of these disconnections and not an effect?

[#2]

Just to add something which might either be a clue or a complete red herring...

I am pretty sure that the two PPP disconnections above correlate with moments of high router activity. For the 09.06.21 time there'll have been an local LAN backup running and for 24.05.21 we'd just got back from holiday and was uploading a few hundred images to a local server. In both cases they wouldn't have been causing high WAN banwidth consumption but the transfers will have been via the NAT loopback and so the router's CPU will have been engaged in the process.

Might this point to something? I'm thinking along the lines of the timeouts being a result of something not happening due to being otherwise busy doing other things and not responding to something at the other end (or failing to see the response from the other end).

Again, could be red herring but thought I'd mention even if just to get it categorically ruled out as a contributory factor.

[#3]

Hi @MJN I've had a look into this for you and it doesn't look like there's anything this side causing the drops.

What we can see agrees with what you've said about the two drops and line tests are also showing all's OK. 

I've attached a copy of our testing below as well as the connection logs from the last 30 days or so:

It's difficult to investigate further as they're just singleton drops but I'd start by looking at the router.

Do you have another one you can try and see if it makes a difference?

[#4]

Hi @MJN I've had a look into this for you and it doesn't look like there's anything this side causing the drops.

What we can see agrees with what you've said about the two drops and line tests are also showing all's OK. 

I've attached a copy of our testing below as well as the connection logs from the last 30 days or so:

GEA Test Detail
Circuit ID	NA	Service ID	[redacted]

Test Outcome	Pass
Test Outcome Code	GTC_FTTC_SERVICE_0000
Description	GEA service test completed and no fault found .
Main Fault Location	OK
Sync Status	In Sync
Downstream Speed	63.2 Mbps
Upstream Speed	20.0 Mbps
Appointment Required	N
Fault Report Advised	N
NTE Power Status	PowerOn
Voice Line Test Result	Pass
Radio Frequency Ingress	Detected
Repetitive Electrical Impulse Noise	Not Detected
Cross Talk	Not Detected
Estimated Line Length In Metres	267.4
Upstream Rate Assessment	Very Good
Downstream Rate Assessment	Low
Interference Pattern	Not Detected
Service Impact	No Impact Observed
Home Wiring Problem	Not Detected
Downstream Policing Discard Rate	0.0
Customer Traffic Level	Upstream and Downstream traffic detected
Technology	VDSL
DP Type	External
Profile Name	0.128M-74M Downstream, Error Protection Off - 0.128M-20M Upstream, Error Protection Off
Time Stamp	2021-05-27T17:00:00

Parameters	MIN	MAX	AVG
Down Stream Line Rate	63.1 Mbps	63.1 Mbps	63.1 Mbps
Up Stream Line Rate	20.0 Mbps	20.0 Mbps	20.0 Mbps
Up Time	900.0 Sec	900.0 Sec	900.0 Sec
Retrains	0.0	0.0	0.0

Current and Last 15 Minute Bin Performance
Parameters	Last Traffic Count(Upto 15 mins)	Current Traffic Count(Upto 15 mins)
Start Time Stamp	2021-06-09T16:16:16.224+01:00	2021-06-09T16:31:16.224+01:00
Ingress Code Violation	0	0
Egress Code Violation	0	4
Errored Seconds	0	0
Severely Errored Seconds	0	0
Unavailable Seconds	0	0

It's difficult to investigate further as they're just singleton drops but I'd start by looking at the router.

Do you have another one you can try and see if it makes a difference?

[#5]

@MJN is the router a Fritz Box by any chance ? If so this https://translate.google.com/translate?hl=en&sl=nl&u=https://userbase.be/forum/viewtopic.php%3Ft%3D5... might be worth a read.

Your thoughts on high load being the issue agrees to some extent with the link. Looks like the router might not be processing the LC_ECHO requests in time

[#6]

Hi @Gandalf, really appreciate you looking into this for me, particularly as you say it doesn't really look like there's a problem on your side. Good to have some added evidence that this is the case though.

I must admit, a 'blip' like this every few weeks is nothing in the grand scheme of things and could be seen by many as verging on offensive given they might be suffering the consequences from being miles from cabinets, relying on old wiring etc. I should be counting my lucky stars really, and it's only the server aspect and the concern the router might not automatically reconnect if I'm away that concerns me - I need to keep a closer eye on what it does rather than manually resetting the connection when I happen to spot it whilst home. Fully appreciate that I'm on a residential connection so there's no expectation of five-9's uptime, at least contractually but you do a pretty good job of giving me that in practice so minor blips like this stand out!

Thanks again; I think I'll just keep an eye on things for now and try and see if there's a pattern (hard when it only happens every few weeks) and then perhaps look to swap in another router to help narrow things down. It's a shame though as I really like the Fritzbox, and always assumed it was a reasonably good bit of kit.

[#7]

---

@MisterW wrote:

@MJN is the router a Fritz Box by any chance ? If so this https://translate.google.com/translate?hl=en&sl=nl&u=https://userbase.be/forum/viewtopic.php%3Ft%3D5... might be worth a read.

Your thoughts on high load being the issue agrees to some extent with the link. Looks like the router might not be processing the LC_ECHO requests in time

---

Hi @MisterW, just seen your reply (thanks) after my first response. It is indeed a Fritzbox and the discussion and symptoms in that link do seem to resonate.

Interesting this snippet from the vendor's response:

In order to resolve this issue, we recommend that you contact your provider and have them check the stability of the LC-Echo Checks on their side.
On the other hand, this service for your extension could also be disabled by the provider in which case the FRITZ!Box will automatically adapt and not use this checking method.

Does that mean anything to you @Gandalf and a possible avenue to explore? I can't help but feel that AVM could include a user setting to ignore (or perhaps just adjust the parameters off?) this checking method - it would seem to me an easier route to resolution than expecting the ISP to disable things that are presumably in place for a good reason! Maybe there's a nuance that's being lost in translation.

[#8]

Hi @MJN 

No problem at all, as I was typing I was actually thinking along the lines of, it's two drops within a month...

Interesting this snippet from the vendor's response:

In order to resolve this issue, we recommend that you contact your provider and have them check the stability of the LC-Echo Checks on their side.
On the other hand, this service for your extension could also be disabled by the provider in which case the FRITZ!Box will automatically adapt and not use this checking method.

Does that mean anything to you @Gandalf and a possible avenue to explore? I can't help but feel that AVM could include a user setting to ignore (or perhaps just adjust the parameters off?) this checking method - it would seem to me an easier route to resolution than expecting the ISP to disable things that are presumably in place for a good reason! Maybe there's a nuance that's being lost in translation.

Never heard of LC-Echo, not something we're familiar with. 

[#9]

---

@Gandalf wrote:

Never heard of LC-Echo, not something we're familiar with. 

---

Could it be referring to LCP Echo? That seems to be 'a thing' when it comes to PPPoE...

[#10]

There's further info on Draytek's site about what it is, and how many alternative ways they have of performing a similar function (WAN connection status). Maybe I should just buy a Draytek... 😁

[#11]

Ah yeah. That'd make sense. Not sure though there's anything we can do to help stop the drops.

We could increase the stability profile of the line for the DLM software to prioritise stability over speed but that'll likely lower your speed, so for the sake of two drops, it may not be worth it.

[#12]

---

@Gandalf wrote:

Ah yeah. That'd make sense. Not sure though there's anything we can do to help stop the drops.

We could increase the stability profile of the line for the DLM software to prioritise stability over speed but that'll likely lower your speed, so for the sake of two drops, it may not be worth it.

---

Agreed. Let's not fix one problem and cause another! 😉

Leave it with me. At best it's a relatively minor occasional issue which if I ignore might even go away, at worst it's looking like a potential router issue and that's within my gift to sort out. I'm looking up Draytek's offering as we speak... they're not cheap though! ('reassuringly expensive' perhaps?!)

[#13]

Looking at the GEA test, there appears to be banding applied the line at 74mg.

[#14]

---

@Shep41 wrote:
Looking at the GEA test, there appears to be banding applied the line at 74mg.

---

Do you think that could cause me an issue (whether it's the one being discussed or another) or was it just an observation? Does it make any difference that my sync speed is somewhat below the 74mg and so no (or higher?) wouldn't make any difference in practice?

Again, notwithstanding these occasional hiccups (which I'm leaning towards the router being the cause of), my connection is otherwise a great performer and so it might be a case of 'if it aint broke dont fix it' before anyone goes tweaking anything!

[#15]

@MJN  As your sync speed is well below the line profile the banding will have no effect on your speeds.😊