Long timeouts for stale PPPoE connections

[#1]

(reposting as it seems my other topic has been missed by plusnet staffers)
Could someone from Plusnet please look into why the timeout for stale PPPoE connections on FTTC is so long (over 6 minutes), when it looks like according to BT SIN495 it should really be configured to time out much quicker.
http://community.plus.net/forum/index.php/topic,114576.msg986509.html#msg986509
I have the technology to fix this for myself on my own router on OpenWRT with a program that hunts out the stale connections and kills them at your end, but anyone using an off-the-shelf router using rp-pppoe and pppd (many routers, including the ASUS models from looking at the logs posted in some other threads) will experience 6+ minutes before they can reconnect their connection in the event of router being powercycled or possibly DLM kicking in.
Having your PPP timeouts so high will lead to customers with lines which DLM kicks in on being quite unhappy as everytime it happens they will lose their connection for 6 minutes or more.  I can see several posts on here which look like this kind of thing going on.
If it is deliberately configured to time out so slowly it would be nice to understand why.

[#2]

A number of people have reported it as being about 8 minutes. However if you drop your own PPP session by clicking Disconnect, you can reconnect again immediately.
Edit: I don't know if Kelly may be one of the best to respond to this.

[#3]

Yes, but there are many situations where you don't have the option to drop the connection nicely.  It does seem that this behaviour goes against Openreach's advice for implementation of FTTC, and will inevitably lead to support questions.  As a service provider I'd try and do anything I could to reduce support issues and improve customer satisfaction, so either this is a misconfiguration (and should probably be fixed) or it is trying to achieve some goal (such as preventing denial of service attacks on authentication servers).
  Would like to see some comment from Plusnet staff on why it is configured like this. 

[#4]

Not all routers allow you to drop the PPP connection via the router Webpage.
My TP-Link 8960n didnt although admittedly that was an ADSL modem/router which had been reconfigured to use a LAN port as a WAN. The only way to drop it was to hit the reboot option in the menu which I hope did actually disconnect 1st before rebooting. I suspect it may have as the PPP connection re established way quicker than 6/8mins.

[#5]

Yes some ADSL modem/routers are a bit of a pain in that respect as it doesn't allow a graceful disconnect.  A power off for 10 minutes is generally the next best option.
I would certainly expect that something that was configured as just a router where the broadband username and password were entered on it, when rebooted would drop the PPP session and automatically reconnect as the reboot completed.
On Fibre this isn't the same as the connection being dropped modem side, where this 8 minutes seems to come into play.
I've been led to believe that Dave from Plusnet is looking into this "feature".

[#6]

Quote from: Anotherone

Yes some ADSL modem/routers are a bit of a pain in that respect as it doesn't allow a graceful disconnect.  A power off for 10 minutes is generally the next best option. I would certainly expect that something that was configured as just a router where the broadband username and password were entered on it, when rebooted would drop the PPP session and automatically reconnect as the reboot completed.

OpenWRT (up to Attitude Adjustment at least) doesn't cleanly close PPPoE sessions on reboot either, though disconnect on their webUI does work.
The biggest issue is that having lost the session (however that may have happened, be it server side or at the customers premisess) most customers don't have any way to kill the session as their router no longer has the details in it required to close the session after a reboot!  (specifically the session ID) which can only be recovered by sniffing the WAN interface.
As I have a solution for my own purposes which is robust now I don't very much care, but I can see how life would be much easier for many customers, if this timeout value were reduced.  I'm going to have to patch up my router every time I firmware upgrade, which is a bit of a pain.  And I could have done with getting some sleep the last few nights instead of hacking ethernet frames in my pyjamas! 

[#7]

Quote from: Anotherone

Yes some ADSL modem/routers are a bit of a pain in that respect as it doesn't allow a graceful disconnect.  A power off for 10 minutes is generally the next best option. I would certainly expect that something that was configured as just a router where the broadband username and password were entered on it, when rebooted would drop the PPP session and automatically reconnect as the reboot completed. On Fibre this isn't the same as the connection being dropped modem side, where this 8 minutes seems to come into play. I've been led to believe that Dave from Plusnet is looking into this "feature".

Not quite sure what distinction you are making?
I used the 8960n on my Fibre connection and although I didn't have the opporitunity to do the preferred disconnect from 8960n's webpage which I could do with the 582n (similar arrangement what were originally ADSL mode/routers being firmware modified for use on Fibre) I didn't experience any difference in reconnection times with the 8960n reconnecting automatically once it had rebooted, a process that took under 2mins from initiating reboot in menu to being back up and browsing t'internet
Interestingly I have An Asus n66u and I haven't disconnected or rebooted that yet so who knows if that will exhibit any symptoms? Something that was seen by another member when they rebooted their Asus router and sufferred 5-7min timeout on WAN reconnect?

[#8]

I've registered a support ticket for this as I've not seen any input from Plusnet staff.  I realise this forum isn't the official channel for support so hopefully I'll get some info via the ticket system.

[#9]

Hi there,
I'm sorry we've not replied to you yet. This is something we're already aware of and are looking into at the moment.
I understand you've raised a ticket but the CSC agents probably won't be aware of this issue. I'll make sure one of us gets back to you when there's some development.
Adam

[#10]

Thanks for the reply Adam.  FYI the ticket number is 69514911, and indeed the CSC agent wasn't aware of the issue.
It's good that you are looking into it as I'm sure it will help out many in future if you can solve it.  In my case it caused me a right headache when trying to get a different router up and running, and I know you say in the guides that you should wait 15 minutes etc after plugging in the router, but the reality is that is an "eternity" when you are trying to get something up and running, and really no-one can believe there is any sane reason why a router would need to be on a fibre connection for 15 minutes to "set up" when my ADSL would sort itself out in seconds.
For my own purposes I have a solution as mentioned which hunts out the stale session on the WAN interface and builds a PADT for it so you tear down the session.  If anyone wants the source for the modified version of pppoesk which I have made then give me a shout.  I can't give much support for it though, just know it works for me!

[#11]

I'd be interested if you could PM with some details jimbof. By the way don't get confused with the 15 minutes that it suggests you wait for allowing the TR-069 ACS to configure your username and password - you can short cut that and do it manually, you can also turn off the function. This is different from the issue of this PPPoE timeout.

[#12]

OK I wasn't aware of the autoconfig setup; but the comment still stands that anything taking that long on a fibre line seems suboptimal at best, and probably broken if you're feeling ungenerous!

[#13]

Further to what Adam's posted, we've an internal problem open to track progress for this one (ref: 75285). As far as I know the PPP timeout's set to eight minutes which I think stems from back in the dial-up days. The current situation isn't ideal as it's likely to cause certain customers confusion, something that's been proved by the multiple threads that have cropped up here. It could also drive support contacts from the less technically minded.
Thanks for bringing it to our attention and thanks for the investigative work. It's appreciated
More news as we have it ...

[#14]

Thanks Bob, appreciate the reply.  Seems that the recommendation from BT (from SIN495 details provided by user njay) is less than 20secs, which is going to be less than most routers take to boot up so probably makes all these issues disappear.

[#15]

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?
@njay

Quote from: njay

I used the 8960n on my Fibre connection and although I didn't have the opporitunity to do the preferred disconnect from 8960n's webpage which I could do with the 582n (similar arrangement what were originally ADSL mode/routers being firmware modified for use on Fibre) I didn't experience any difference in reconnection times with the 8960n reconnecting automatically once it had rebooted, a process that took under 2mins from initiating reboot in menu to being back up and browsing t'internet Interestingly I have An Asus n66u and I haven't disconnected or rebooted that yet so who knows if that will exhibit any symptoms? Something that was seen by another member when they rebooted their Asus router and sufferred 5-7min timeout on WAN reconnect?

Ah, I hadn't seen that, sorry, so the Asus doesn't seem to do a graceful disconnect then if that's the way it's behaving.
Edit: correction due to misreading of quote    as they say, should have gone to specsavers