Long timeouts for stale PPPoE connections

[#1]

Quote from: Anotherone

Thanks for your reply Bob. As some have been reporting modem reboots about as quick as 10 seconds or so, and SIN498v4p3 states retrain times can be between 10-60 seconds (para.2.1.6) wouldn't an 8 second timeout be more appropriate - what issues if any would that cause?

That's something we need a bit of time to look into.

[#2]

Always surreal when you come onto a post and see you've been quoted from elsewhere lol
What I was saying in that quote was more about the 8960n in that it had no means to do a graceful disconnect. However by opting to reboot the 8960n from its menu it rebooted very quickly and reestablished suggesting it was doing a graceful disconnect prior to the reboot?
I haven't as yet on the Asus I am now using had to reboot it soon idea if it will exhibit timeout. And I certainly don't want to try as that will No doubt jinx my current high and stable line speed lol.

[#3]

Sorry, I misread what you'd said, I'll go back and edit that post. (The distinction I was trying to make originally was that rebooting a modem/router on ADSL doesn't give a graceful disconnect - never mind - we will be going off topic).

[#4]

There's a bit more info in BT SIN 498:

Quote

2.1.6 Downstream shaping The CP is expected to shape the downstream traffic to match the actual VDSL2 line rate in order to avoid excessive traffic loss. CPs should be aware that the mechanism for reporting the downstream and upstream line rates relies on a line re-train causing the CP, or the CPE, to initiate a new PPP session or a new DHCP request. The success of this method of line rate reporting is down to the CP's choice of timers used around PPP/DHCP handling. If the PPP/DHCP survives a re-train, then the CP will be unaware of any change in the line rate and will not be able to shape appropriately. The line re-train time for VDSL2 can be anywhere between 10 and 60 seconds, with typical values in the 20-30 second range.

I appreciate this will not likely be an overnight fix, the above specifically explains why correct timing is important in keeping the Plusnet line speed setting correct to avoid dropped packets and other issues.

[#5]

It's not likely to be an overnight fix and I think that is why Bob has said they will need some time to look into it for example to make sure an 8 second timeout that I suggested might be more appropriate and doesn't cause other issues. Mind you, I only said 8 seconds because it's currently 8 minutes, I suppose 9.9 seconds would do!

[#6]

Ideally less than 10 but certainly less than 20 seeing as Sin495 specifically says it must be less than 20 seconds.

[#7]

If you read reply #18 where w23 has quoted para 2.1.6 from SIN498v4p3 in full, whereas I only referenced retrain times from that paragraph, it must be less than 10 seconds otherwise the bRAS profiles don't get updated on a quick resync unless you manually drop your PPP session and re-establish another.

[#8]

Indeed.
It would appear Sin498 contradicts itself as elsewhere it mentions the time should be no more than 20seconds despite as pointed out a retrain could be as little as 10seconds

[#9]

Morning guys,
I can try this myself when I get home this evening, but for the sake of speeding up our investigation is anybody able to replicate this problem today/this afternoon on their own line? i.e. powercycle the router so it gets into the state where it won't reconnect for ~8minutes. I need to consult BT's RADIUS logs however they only go back about a week.

[#10]

I can do this at say 11:30
Do you just want a reboot?

[#11]

I would say pull the powerplug on the Router, wait a 20 seconds and then plug it in again. A Reboot may allow it to drop the PPP session first which won't achieve what's needed.

[#12]

Yes understood, was proposing to switch off the mains for say 30 seconds then back on again.
BT box is followed by a Draytek Vigor 2130n so can monitor that to see when the link becomes live again.
Just waiting for Bob to reply...

[#13]

I just (around 11.15am) cycled my router twice; first time as per a standard openWRT reboot (not taking down the connection).  The second time I put back the utility which sniffs the connection and sends you the faked ethernet frame with the sniffed session ID to get you to kill the PPPoE session at your end.  You can probably see the difference in my sig graph in terms of reconnection time...

[#14]

Power off at 11:33:30
Power on at 11:34:00
PPP session starts at 11:40:24
Second PPP session starts at 11:40:58 - must be a Vigor thing...
CHAP completes at 11:41:00

[#15]

Thanks guys, I'm taking a look now ...