PPP LCP Auth Failure

[#1]

Low SNRM could have caused a high error rate, which would have manifested itself as the inability to successfully transmit any data over the DSL link, this can cause the PPP session to drop and not re-establish, and yes, this can happen without the DSL itself disconnection.

[#2]

Would also be useful to know what router is being used here, regardless as to whether or not swapping it out doesn't help things.

[#3]

@ejs yes of course, but with zero SES, a vanishingly-low ES:uptime ratio, that's fantastically unlikely in this cases -- especially the case where it failed to auth for several hours.

[#4]

@bobpullen thanks for your interest. It's a Billion 7800NXL on firmware 2.32e. The backup router is a Netgear DG834GT with DGteam (I also have an old Plusnet-branded TG582n in the drawer, but the PSU has gone AWOL).

[#5]

I guess the long overnight outage could have been a Major Service Outage affecting your exchange or some part of it, and everything else sounds like a non-issue really.

[#6]

Respectfully, I beg to differ. I don't live anywhere near Dunblane.

And let's not forget the multi-hour authentication outage almost two months ago. And even the 2-minute outage caused by nine consecutive PPP/LCP auth timeouts is surely indicative of an underlying problem. 

I just can't understand why Plusnet is being so cavalier about this.

[#7]

Update: Plusnet want me to agree to a BTOR engineer visit (to fix a problem with BTW's authentication service!)

And of course Plusnet expect me to pay for BTOR to knock on the door and say everything's working fine. Uh, no: This is not an ADSL nor a telephony issue.

Next steps: I request someone investigate the root cause of the PPP/LCP auth timeouts.

[#8]

Yet more PPP/LCP timeouts this evening. Plusnet continue to ask me to pay £175 for an engineer visit (when they can be bothered to answer the ticket).

[#9]

Are you running some sort of DSL stats monitoring, recording and graphing program?

Plusnet might be able to click a button to do a "port flex", but I'd be very surprised if it solved anything.

[#10]

I keep an eye on the stats reported by my Billion router. It's reporting a downstream SES every couple of hours, which seems quite acceptable for a 3km rural line. (That's higher than it has been, because Plusnet thought it would be a neat idea to reset DLM, which caused interleaving to be switched off.)

I also run this Thinkbroadband BQM. I see a small spike of packet-loss at around 2:30, which is unusual. (I've not enabled my static IP option, so it starts late morning today, after I power-cycled the router.)

I have the logging on my router turned all the way up. Here's a typical burst of three attempts to auth from yesterday:

Feb 13 22:14:47 daemon notice syslog: PPP: Start to connect ...
Feb 13 22:14:47 daemon warn kernel: netdev path : pppoa0
Feb 13 22:14:47 daemon info kernel: ->
Feb 13 22:14:47 daemon info kernel: atm0
Feb 13 22:14:47 daemon notice syslog: pppd:Using interface pppoa0
Feb 13 22:14:47 daemon notice syslog: pppd:Connect: pppoa0 <-->
Feb 13 22:14:56 daemon notice syslog: pppd:LCP: timeout sending Config-Requests
Feb 13 22:14:56 daemon notice syslog: pppd:Connection terminated.
Feb 13 22:14:59 daemon notice syslog: PPP: Start to connect ...
Feb 13 22:14:59 daemon warn kernel: netdev path : pppoa0
Feb 13 22:14:59 daemon info kernel: ->
Feb 13 22:14:59 daemon info kernel: atm0
Feb 13 22:14:59 daemon notice syslog: pppd:Using interface pppoa0
Feb 13 22:14:59 daemon notice syslog: pppd:Connect: pppoa0 <-->
Feb 13 22:15:08 daemon notice syslog: pppd:LCP: timeout sending Config-Requests
Feb 13 22:15:08 daemon notice syslog: pppd:Connection terminated.
Feb 13 22:15:11 daemon notice syslog: PPP: Start to connect ...
Feb 13 22:15:11 daemon warn kernel: netdev path : pppoa0
Feb 13 22:15:11 daemon info kernel: -> atm0
Feb 13 22:15:11 daemon notice syslog: pppd:Using interface pppoa0
Feb 13 22:15:11 daemon notice syslog: pppd:Connect: pppoa0 <-->
Feb 13 22:15:11 daemon crit syslog: PPP LCP UP.
Feb 13 22:15:12 daemon crit syslog: PPP LCP UP.
Feb 13 22:15:12 daemon notice syslog: pppd:local IP address 87.112.[redacted]
Feb 13 22:15:12 daemon notice syslog: pppd:remote IP address 195.166.130.255
Feb 13 22:15:12 daemon notice syslog: pppd:primary DNS address 212.159.6.10
Feb 13 22:15:12 daemon notice syslog: pppd:secondary DNS address 212.159.6.9
Feb 13 22:15:12 daemon crit syslog: Received valid IP address from server. Connection UP.

Note the 9-second timeouts. If this was an occasional problem, I wouldn't worry, but this happens roughly half of the time it re-auths (either because the DMT layer drops or because Plusnet kicks me off a gateway).

And then there have been two multi-hour auth outages since early December, which is what really motivated me to open the ticket.

[#11]

What happens when you manually disconnect and re-connect the PPP session?

Could you show us your DSL stats?

---

And then there have been two multi-hour auth outages since early December, which is what really motivated me to open the ticket.

---

These were probably some planned work at the exchange, or some one-off problem at the exchange, and nothing to do with anything else you've reported.

I'm pretty sure it can take my router longer than 30 seconds to re-connect the PPP after the DSL drops. Not because it retries a few times, but because it tends to wait a while before doing it.

So basically your issue is that the connection drops, and it takes a completely normal amount of time to re-connect!

[#12]

@ejs thanks for your thoughts. In fact, that was a manual PPP disconnect/reconnect (without DMT retrain). Some of the other logs I have for the problem were also manual. Others were planned router reboots. One other was when a Plusnet gateway appeared to kick me off, presumably for routine maintenance.

Again, there's nothing wrong with the DMT layer. It's superbly balanced and low noise for a rural 3 km loop (now 15 Mb/s at 6 dB target, but if I wanted to really push it, my router will hold a rock-solid sync for days at 18 Mb/s with a 1.5 dB target and a small helping hand of INP/FEC).

The long outages I referred to were PPP/LCP auth outages, not at the DMT layer. As I said before, three attempts to auth isn't in itself a huge deal, but is indicative of a problem that should be investigated before I suffer another 9-hour outage (of what's supposed to be a Business service).

In fact, I think I have one or possibly two workarounds for "my" problem. Or perhaps a port rebuild would help. But it seems wrong to just hide an underlying issue -- one that others also seem to have experienced, judging by posts going back months on here, on Thinkbroadband, and on Kitz.

Sadly, Plusnet refuses to investigate, preferring to crank the DMT handle over and over again. Somebody manually tweaks my margin; somebody else pokes DLM; somebody else tries to schedule an engineer visit (for which I'll be charged £175), etc., etc...

(I'm trying not to rant, really! But as a BT shareholder, I'm also unhappy about the waste of money that could be invested in providing a more reliable service!)

Everyone at Plusnet is very polite, but we're back to banging my head against a brick wall, just like five years ago when nobody at Plusnet would do anything about the exchange's 20CN congestion issue. That problem took 10 months to solve (and only after I sought help from the very wonderful @Pettitto).

[#13]

You should have said earlier if you are a business customer, then this thread would have been moved to the business board, probably someone else would have looked at it, and I would probably have ignored it. Without seeing any DSL stats, I have nothing further to contribute.

[#14]

An unusual reply. That's not the stated aim of the Business forum. Neither are my stats relevant to this thread.

But thanks for your interest anyway.

[#15]

@AlexD @HarryB @adamwalker @MatthewWheeler - tagged as requested - no PN touch for 2 weeks.  What does the PPP session history look like here?  Is there any evidence from resync history which supports the claim that there is no xDSL down associated with the loss of PPP sessions?

@richi

I think I have one or possibly two workarounds for "my" problem. Or perhaps a port rebuild would help. But it seems wrong to just hide an underlying issue -- one that others also seem to have experienced, judging by posts going back months on here, on Thinkbroadband, and on Kitz.

Sadly, Plusnet refuses to investigate, preferring to crank the DMT handle over and over again. Somebody manually tweaks my margin; somebody else pokes DLM; somebody else tries to schedule an engineer visit (for which I'll be charged £175), etc., etc...

(I'm trying not to rant, really! But as a BT shareholder, I'm also unhappy about the waste of money that could be invested in providing a more reliable service!)

Can you explain how you think a port rebuild will help resolve what you believe to be a RAS issue, rather than an xDSL stability issue?  I believe RAS authentication is performed a long way past the exchange port and unless you have a fixed IP address or are on 20CN that function is performed within BTw's domain, not Plusnet's.

As a BT Share holder, I would hope that you are directing your frustration on wasted cost towards the BT group as a whole and BTOR in particular.  There is a lot of wasted effort where BTw demands ISPs do unproductive activity (such as to require two engineer visits which find no line fault) before BTw will even consider to start to look elsewhere (within their own domain) for an issue.  <rant>So please, don't come here complaining that it is Plusnet who are wasting money, when in fact its internal BTw / BTOR problem passing that's the real issue.</rant>

Though not central to your issue, in terms of getting complex issues resolved, BTw/BTOR are very poor at owning complex failures end to end and will never do so until such time as there are commercial penalties for failing to resolve issues in a timely fashion.  However, to a shareholder that would be a threat to profits and dividends, so I guess such accountability is not something you'll be voting for?

In the meantime, all ISPs (including Plusnet) are faced with undertaking nugatory fundamental checks in areas which you, I and they might have good reason to believe the problem does not exist before those responsible for where the problem is more likely to exist will even 'get out of bed'.