cancel
Showing results for 
Search instead for 
Did you mean: 

Long timeouts for stale PPPoE connections

bobpullen
Community Gaffer
Community Gaffer
Posts: 16,932
Thanks: 5,024
Fixes: 317
Registered: ‎04-04-2007

Re: Long timeouts for stale PPPoE connections

Do people reckon we're safe to consider this fixed then (or at least significantly better compared to before)?

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵

Lorian
Grafter
Posts: 704
Thanks: 5
Registered: ‎31-07-2007

Re: Long timeouts for stale PPPoE connections

I'll try it again when I get home later
Lorian
Grafter
Posts: 704
Thanks: 5
Registered: ‎31-07-2007

Re: Long timeouts for stale PPPoE connections

Just over 2 minutes when I just tried it again. Would still like it to be less  Roll_eyes
bobpullen
Community Gaffer
Community Gaffer
Posts: 16,932
Thanks: 5,024
Fixes: 317
Registered: ‎04-04-2007

Re: Long timeouts for stale PPPoE connections

Well two minutes was what we were hoping for so I think we can assume the work to have been successful Smiley
I'll question the possibility of making the timeout lower but I can't guarantee anything.

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵

Lorian
Grafter
Posts: 704
Thanks: 5
Registered: ‎31-07-2007

Re: Long timeouts for stale PPPoE connections

Would there be a rationale for not reducing it further?
chrispurvey
Plusnet Alumni (retired)
Plusnet Alumni (retired)
Posts: 5,369
Fixes: 1
Registered: ‎13-07-2012

Re: Long timeouts for stale PPPoE connections

Bob's chasing this up, we'd have to apply this across the whole product set and not just FTTC based customers.
We'll have some answers soon if we able to bring this any lower.
bobpullen
Community Gaffer
Community Gaffer
Posts: 16,932
Thanks: 5,024
Fixes: 317
Registered: ‎04-04-2007

Re: Long timeouts for stale PPPoE connections

Quote from: Bob
Well two minutes was what we were hoping for so I think we can assume the work to have been successful Smiley
I'll question the possibility of making the timeout lower but I can't guarantee anything.

Transpires that 30 seconds is the lowest we can go. It's a limit set by the vendor of the kit we're using.

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵

w23
Pro
Posts: 6,347
Thanks: 96
Fixes: 4
Registered: ‎08-01-2008

Re: Long timeouts for stale PPPoE connections

If I'm permitted to quote from BT SIN 495:
Quote
Unlike other WBC access technologies, WBC FTTC accesses use the PPP (“Point-to-Point
Protocol”) session establishment to inform the BT Wholesale BRAS of the Openreach line
rate. It is therefore essential that the PPP session is re-started every time the VDSL line retrains.
To ensure this, the PPP / L2TP timeout values must be set to less than 20 seconds.
Call me 'w23'
At any given moment in the universe many things happen. Coincidence is a matter of how close these events are in space, time and relationship.
Opinions expressed in forum posts are those of the poster, others may have different views.
bobpullen
Community Gaffer
Community Gaffer
Posts: 16,932
Thanks: 5,024
Fixes: 317
Registered: ‎04-04-2007

Re: Long timeouts for stale PPPoE connections

Doesn't detract from the fact that the kit we're using can't do that.
Quote
Options
seconds—Keepalive timeout period, in the range 30–64800 seconds for high-density mode, 1–64800 seconds for POS uplink interfaces in low-density mode, or 10–64800 seconds for all other HDLC interfaces in low-density mode; default value is 30 seconds

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵

w23
Pro
Posts: 6,347
Thanks: 96
Fixes: 4
Registered: ‎08-01-2008

Re: Long timeouts for stale PPPoE connections

Can't argue with that.
Call me 'w23'
At any given moment in the universe many things happen. Coincidence is a matter of how close these events are in space, time and relationship.
Opinions expressed in forum posts are those of the poster, others may have different views.
jimbof
Grafter
Posts: 348
Thanks: 2
Registered: ‎02-05-2013

Re: Long timeouts for stale PPPoE connections

Wow it is amazing how dumbed-down (no offence meant!) the configuration for the Juniper kit is.  They don't allow you to tweak the number of LCP retries either it seems (must be hard coded to 3).  Shame.  I wonder how many other ISP's can't comply due to such issues?
pwatson
Rising Star
Posts: 2,470
Thanks: 8
Fixes: 1
Registered: ‎26-11-2012

Re: Long timeouts for stale PPPoE connections

Quote from: Bob
Doesn't detract from the fact that the kit we're using can't do that.

So it's not compliant then?  When is it due to be replaced with something that meets the BT spec? Smiley
bobpullen
Community Gaffer
Community Gaffer
Posts: 16,932
Thanks: 5,024
Fixes: 317
Registered: ‎04-04-2007

Re: Long timeouts for stale PPPoE connections

Not due to be replaced any time soon to my knowledge. We've a fair few of the things in the network and I've reason to believe that they're capable of scaling fairly well.

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵

deathtrap
Grafter
Posts: 1,064
Thanks: 4
Registered: ‎23-04-2013

Re: Long timeouts for stale PPPoE connections

I thought this problem had been fixed  or the time had been reduced, ? below is the result from being kicked from the Gateway i had been connected to for reasons unknown,  8minutes !!!!! .
But i do wish Plusnet systems that auto do this would do it a different time of the day, infact i wish  it would stop swapping me from gateway to gateway, i can do that myself, if and when i feel i need to BTW i checked the zen status for BT engineering works, nothing for my area code
Oct 07 00:50:04  daemon  pppd[16222]: No response to 6 echo-requests
 Oct 07 00:50:04  daemon  pppd[16222]: Serial link appears to be disconnected.
 Oct 07 00:50:04  daemon  pppd[16222]: Clear IP addresses.  Connection DOWN.
 Oct 07 00:50:04  daemon  pppd[16222]: Clear IP addresses.
 Oct 07 00:50:04  daemon  pppd[16222]: Couldn't increase MTU to 1500.
 Oct 07 00:50:04  daemon  pppd[16222]: Couldn't increase MRU to 1500
 Oct 07 00:50:05  user  syslog: begin: interface: ppp_ewan_1 go to down
 Oct 07 00:50:05  user  syslog: end: interface: ppp_ewan_1 go to down
 Oct 07 00:50:05  daemon  pppd[16222]: PPPoE: Terminating on signal 15.
 Oct 07 00:50:10  daemon  pppd[16222]: Connection terminated.
 Oct 07 00:50:10  daemon  pppd[16222]: Connect time 7924.3 minutes.
 Oct 07 00:50:10  daemon  pppd[16222]: Sent 6793888165 bytes, received 25838345197 bytes.
 Oct 07 00:50:11  user  kernel: dev_shutdown, dec ppp device refcnt, dev->refcnt=4
 Oct 07 00:50:11  user  kernel: unregister_netdevice: waiting for ppp_ewan_1 to become free. Usage count = -1
 Oct 07 00:50:11  user  kernel: dev->name = ppp_ewan_1, dev->refcnt=-1
 Oct 07 00:50:11  user  kernel: after reset to 0, dev->refcnt=0
 Oct 07 00:50:11  daemon  pppd[16222]: Doing disconnect
 Oct 07 00:50:14  daemon  pppd[16222]: Exit.
 Oct 07 00:50:15  daemon  pppd[16762]: pppd 2.4.1 started by admin, uid 0
 Oct 07 00:50:15  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:50:38  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:50:38  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:50:38  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:50:41  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:51:04  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:51:04  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:51:04  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:51:07  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:51:30  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:51:30  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:51:30  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:51:33  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:51:56  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:51:56  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:51:56  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:51:59  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:52:22  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:52:22  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:52:22  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:52:25  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:52:48  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:52:48  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:52:48  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:52:51  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:53:14  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:53:14  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:53:14  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:53:17  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:53:40  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:53:40  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:53:40  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:53:43  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:54:06  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:54:06  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:54:06  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:54:09  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:54:32  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:54:32  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:54:32  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:54:35  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:54:58  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:54:58  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:54:58  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:55:01  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:55:24  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:55:24  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:55:24  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:55:27  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:55:50  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:55:50  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:55:50  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:55:53  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:56:16  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:56:16  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:56:16  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:56:19  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:56:42  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:56:42  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:56:42  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:56:45  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:57:08  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:57:08  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:57:08  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:57:11  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:57:34  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:57:34  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:57:34  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:57:37  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:58:01  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:58:01  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:58:01  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:58:04  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:58:27  daemon  pppd[16762]: Couldn't get channel number: Transport endpoint is not connected
 Oct 07 00:58:27  daemon  pppd[16762]: PPP: PPP Server No Response !!!
 Oct 07 00:58:27  daemon  pppd[16762]: Doing disconnect
 Oct 07 00:58:30  daemon  pppd[16762]: PPP: Start to connect ...
 Oct 07 00:58:44  daemon  pppd[16762]: PPP server detected.
 Oct 07 00:58:44  daemon  pppd[16762]: PPP session established.
 Oct 07 00:58:44  daemon  pppd[16762]: Using interface pppewan_1
 Oct 07 00:58:44  daemon  pppd[16762]: Connect: ppp_ewan_1 <--> eth0
 Oct 07 00:58:44  daemon  pppd[16762]: Couldn't increase MTU to 1500.
 Oct 07 00:58:44  daemon  pppd[16762]: Couldn't increase MRU to 1500
 Oct 07 00:58:44  daemon  pppd[16762]: Couldn't increase MRU to 1500
 Oct 07 00:58:44  daemon  pppd[16762]: PPP LCP UP.
 Oct 07 00:58:44  daemon  pppd[16762]: Couldn't increase MTU to 1500.
 Oct 07 00:58:44  daemon  pppd[16762]: Couldn't increase MRU to 1500
 Oct 07 00:58:44  daemon  pppd[16762]: Couldn't increase MRU to 1500
 Oct 07 00:58:44  daemon  pppd[16762]: PPP LCP UP.
 Oct 07 00:58:45  daemon  pppd[16762]: local  IP address 212.159.XXX.XXX
 Oct 07 00:58:45  daemon  pppd[16762]: remote IP address 195.166.128.192
 Oct 07 00:58:45  daemon  pppd[16762]: primary   DNS address 212.159.6.9
 Oct 07 00:58:45  daemon  pppd[16762]: secondary DNS address 212.159.6.10
 Oct 07 00:58:45  daemon  pppd[16762]: Received valid IP address from server.  Connection UP.
 Oct 07 00:58:46  user  syslog: begin: interface: ppp_ewan_1 go to up
 Oct 07 00:58:49  user  syslog: end: interface: ppp_ewan_1 go to up
Kelly
Hero
Posts: 5,497
Thanks: 373
Fixes: 9
Registered: ‎04-04-2007

Re: Long timeouts for stale PPPoE connections

I don't think it was us that disconnected you.   We have a "Termination by server side (NAS) Modem" event on our side, and no profile change or forced disconnect logged on our side.
Kelly Dorset
Ex-Broadband Service Manager