PPP Problem - Next Steps?

I provide IT support in my area and ironically on occasion fix clients broadband (Filtered faceplate, remove bell wire, etc) Last Wednesday i was surfing away in my office when i got "page could not be loaded" and i haven't had a connection since. My Draytek 2820n router is syncing with good stats but it wont authenticate. I have tried 4 different routers in the NTE5 test socket with the same result, i have also tried my router at my neighbours house and it worked fine (using their BT ADSL details) My ISP is Namesco, been in touch with them went through all the usual script. One thing to note is that when i use bt_test@startup_domain with a blank password it still does NOT authenticate. Based on this Namesco advised sending a BT engineer. Had to agree to terms which involve a £160+VAT fee if they deem the issue to be my equipment.
I explained the "sync but no auth" symptoms to the engineer, showed him my router status, etc but he didn't inspire confidence. It was almost like he didn't know the difference between "sync" and "authentication", which i hope cannot be the case.
He "tested the line" from the master socket and told me that it was fine and was authenticating OK! Alarm bells rang becuase i could imagine he will report this back and i will get the £160 charge in addition to still having no connection! He did his tests with a fancy bit of BT kit (not sure what) rather than an off the shelf ADSL router. I asked him if his test was authenticating with Namesco or BT. He said BT, so i queried him that my problem is perhaps due to a Namesco server that is not working correctly. He said he thought that was likely the case. I asked if he could use my Namesco ADSL details in his equipment, hoping it would fail and so prove the issue is outside my premises. He said this was not possible. I asked if i could use the login details within his testgear on my router to prove it's UN/PW dependant. Again this was not possible. I then asked him why i could not authenticate using "bt_test@startup_domain". He said he wasn't sure becuase he doesn't "get into those kinds of usernames". I found this odd so asked him if he was a "telephone or broadband" engineer, he said "both". I really struggled with this guy, it was like getting blood from a stone! I have worked with other BT engineers in the past when sorting out my clients broadband and they were all more helpful and forthcoming with opinions/advice. I remember one engineer using a BT Voyager ADSL modem for part of his tests which in my mind is more thorough becuase he could use the customers ADSL details.
So, he left having made no real progress, i still have no broadband and i'm expecting a big bill for the pleasure!

I can see this being a nightmare to resolve so I have since been researching PPP authentication on ADSL connections trying to find a way forward. With this and looking at the logs from my router i believe i may have "stuck PPP session". My router log shows it's sending many "Protocol:LCP(c021) ConfReq Identifier:0xHH MRU: 1500 ##" requests (where the 0xHH starts at 0x00 and increases by 1 on each subsequent request). However, i believe there should be a "ConfAck" response by the peer and i'm getting no response at all. The router simply sends approx 13 of these requests before re-starting the cycle.

Unfortunately i don't know exactly how this should work in order to know who to shout at!
Can anyone help me with:

1. Is the peer that should respond with a "ConfAck" a BT responsibility or Namesco?
2. Does this look like a stuck PPP session? If so, how do i go about getting it fixed. (I have already sent a detailed support ticket off to Namesco with my observations and informing them i suspect a stuck PPP session but i'm awaiting a response and don't hold out much hope.
3. I think Namesco will say "BT reported the line/ADSL service is fine so it must be your equipment" and do nothing. Is there anything i can do to prove them wrong? It's been my experience that sometimes issues just "magically" resolve and the ISP doesn't admit anything. Normally, this isn't a major issue but i need them to own up so i can avoid the £160 charge.

Any advice anyone can offer would be more than welcome.

Is this 20CN (ADSL Max) or 21CN ?

You could try flipping to PPPoE as I have in the past had that wake things up.

It may be a rebuild of a virtual path has been done and messed up, such that your PPP session isn't going anywhere.

Stuck sessions usually disappear if you leave it off overnight and your ISP can also kill them off.

Further to Yarwell's question, especially if you are on 21cn, try bt_test_user@startup_domain again with no password (though your router may require something in this field.)

Sorry for your experience with the engineer, since ADSL became more widespread, they have given many more engineers the 'ADSL repair' skill. The training is basic at best, and some just seem not to want to learn any more on the subject other than the bare minimum.

You are not served by Monk Sherbourne exchange are you ? Long shot, but lots of PPP issues off there at the moment.

I'm on "up to 8Mb" so 20cn i guess.

Didn't mention it but I have already tried:
bt_test_user@strartup_domain
[email protected] (i.e. based on the domain my Namesco login uses)
all gave same result, no PPP acknowledge from peer.

My exchange is SLBOB, Burgh on Bain
see http://www.samknows.com/broadband/exchange/SLBOB

I tried PPPoE, again no PPP and PPPoA still didn't work once i switched back.
I have not tried leaving it disconnected overnight, i will do so tonight.

Namesco tech have been in touch after receiving my lengthy update to the support ticket.
I repeated much of that update (bascially what i have posted on here) to the tech guy.
He seemed to verbally glaze over when i mentioned the possibility of a "stuck PPP session".
He said he would contact BT again.

Yesterday i changed my ADSL password on the Namesco website as i had read this may help reset the PPP session. I have also left my router switched off all night.
This morning i set the new password into the router but got the same result.
Also tried the bt_test@startup_domain and bt_test_user@startup_domain to no avail.

Waiting for Namesco tech to get back to me now.

It's either a faulty DSLAM port in the exchange, or maybe you have the wrong line, does it ring in OK ?

No problems receiving calls on the line.

Am i right in thinking there is a single DSLAM port for each ADSL line?
If the port was faulty wouldn't the BT engineers kit also have failed to authenticate. He told me his kit authenticated fine, (whether what he and i call authentication are the same thing i'm not sure!)

For what reason do you not think it's a stuck PPP session?

Namesco didn't get back to me today, no surprise there!

Am i right in thinking there is a single DSLAM port for each ADSL line?

Yes.

If the port was faulty wouldn't the BT engineers kit also have failed to authenticate. He told me his kit authenticated fine, (whether what he and i call authentication are the same thing i'm not sure!)

At a guess, based on your first posts description, he didn't know his job too well, or maybe his tester isn't set up to make a PPP session to the test login.

For what reason do you not think it's a stuck PPP session?

I don't think it's 'stuck' as such, just borked. Sync but no PPP is a reasonably common fault.

if it's a stuck session your ISP will see you as logged in on their RADIUS logs.

I have seen similar symptoms reported when VPs were reorganised and a circuit was directed to the wrong place (or nowhere).

I guess you'll have to persist with the ISP and if you get another engineer have them show you the BT movie or test page to demonstrate it's connected properly with a PPP session and an IP address.

Yes there's one port per line on a multi-port card.

if you get another engineer have them show you the BT movie or test page to demonstrate it's connected properly with a PPP session and an IP address.

The 'BT Movie' ? Not for many a year Phil, since they stopped testing with a USB modem and laptop. The current JDSU and Exfo testers can be configured to make test logins, and the JDSU can even be used for very basic browsing, (not sure about an Exfo.) However, this is not briefed out on the training, as seen by some as non-equivalent to some CP's.

Even rarer are engineers who have their kit set up to test PPP on VDSL circuits, had been wholly unsuccessful in doing this until I read one of the original threads in the fibre forum mentioning VLAN priorities. Works now though .

presumably you can get to something on bt.net via the test login ?

Yes, normally the BT Wholesale 'error' page, which states you have been directed here because you are logged in with bt_test, etc,etc.

But normally you are just looking for a green light next to the sync like on your tester, no more than this required 9 times out of 10.

So, let me get this clear in my head...

1. Ask my ISP if my username is logged on in their Radius server.
If so, then its a messed up PPP session which needs clearing?
However, Namesco tech have already confirmed they could see my "connection dropped" on Wed 27th at 9:15am, will they be getting this info from their Radius server? If so, then have they already confirmed i am not logged in, (i.e. no PPP session is in progress)?

2. I have read that there are two Radius servers requiring authentication to achieve an internet connection, the first by BT and if this is OK then the 2nd by the ISP. I'm not sure of the details here but could it be the trouble is with the BT RAS rather than my ISP? Would that explain why the bt_test login's also fail?

3. If i get a BT engineer back i need to get him to use his JDSU with the bt_test or bt_test_user login and show me the BT wholesale error page. Since my router cannot login via these details i need to know for sure whether the JDSU can. I hope it doesn't becuase otherwise i think i'm at a dead end.

4. Zarjaz, you seem very knowledgeable about what BT test gear can and cannot do. So, is it possible the the BT engineer can use my Namesco UN & PW in his JDSU?

5. Also, Zarjaz, can the engineer's test equipment "listen in" on the PPP handshaking between my router and the Radius servers?

6. Question the engineer whether it could be the port on the DSLAM
------

By the way, thanks for you help, it is much appreciated.

1. The Weds 27th log off sounds like it's from RADIUS logs, typically they log connect / disconnect events and sometimes hourly updates of traffic volume.

2. Sort of, the first RADIUS checks for a valid username and routes to the relevant provider - for example it will send ISP traffic to the ISP and other domains elsewhere @startup_domain perhaps. If your router logged these things you would see if the first RADIUS was contacted and rejected the session or if it got to the ISP. Or if it got nowhere.

Update - It's now fixed!!

Still not heard from Namesco, my support ticket status says "Awaiting BT".

Here is the syslog for the period when it started working. Anyone care to speculate on what had been done to fix it? I'd be interested to know for future ref with my clients.
It wasn't me as i had not touched the router since yesterday.

Looks to my untrained eye that something external to my premises was reset. Looks like it caused a resync so possibly the DSLAM?

Yarwell, Zarjaz thanks again!


09:59:43Jan 1 09:12:58 WAN1 PPPoE ==> V:1 T:1 PADT ID:6
09:59:43Jan 1 09:12:58 WAN1 PPPoE ==> V:1 T:1 PADI ID:0
09:59:43Jan 1 09:12:58 WAN1 PPPoE <== V:1 T:1 PADO ID:0
09:59:46Jan 1 09:13:01 WAN1 PPPoE <== V:1 T:1 PADO ID:0
09:59:46Jan 1 09:13:01 WAN1 PPPoE ==> V:1 T:1 PADR ID:0
09:59:46Jan 1 09:13:01 WAN1 PPPoE <== V:1 T:1 PADS ID:6
09:59:49Jan 1 09:13:04 WAN1 PPPoE <== V:1 T:1 PADS ID:6
09:59:49Jan 1 09:13:04 WAN1 PPPoE ==> Protocol:LCP(c021) ConfReq Identifier:0x00 MRU: 1500 ##
09:59:57Jan 1 09:13:11 WAN1 PPPoE ==> Protocol:LCP(c021) ConfReq Identifier:0x01 MRU: 1500 ##
10:00:05Jan 1 09:13:19 WAN1 PPPoE ==> Protocol:LCP(c021) ConfReq Identifier:0x02 MRU: 1500 ##
10:00:13Jan 1 09:13:27 WAN1 PPPoE ==> Protocol:LCP(c021) ConfReq Identifier:0x03 MRU: 1500 ##
10:00:16Jan 1 09:13:31 DSL: LineFailure Update: DSL_G997_LINEFAILURE_LOS!
10:00:17Jan 1 09:13:31 DSL: NE Loss of Signal, rebooting DSL state machine
10:00:17Jan 1 09:13:31 DSL: LineFailure Update: DSL_G997_LINEFAILURE_LOS
10:00:17Jan 1 09:13:31 DSL: DSL Rebooting...
10:00:17Jan 1 09:13:31 DSL: Modem Shut Down from ADSL Phy Layer (0)
10:00:31Jan 1 09:13:45 DSL: DSL Rebooting...
10:00:48Jan 1 09:14:03 DSL: DSL SHOWTIME
10:00:51Jan 1 09:14:06 WAN1 PPPoE ==> V:1 T:1 PADT ID:6
10:00:51Jan 1 09:14:06 WAN1 PPPoE ==> V:1 T:1 PADI ID:0
10:00:51Jan 1 09:14:06 WAN1 PPPoE <== V:1 T:1 PADO ID:0
10:00:54Jan 1 09:14:09 WAN1 PPPoE <== V:1 T:1 PADO ID:0
10:00:54Jan 1 09:14:09 WAN1 PPPoE ==> V:1 T:1 PADR ID:0
10:00:54Jan 1 09:14:09 WAN1 PPPoE <== V:1 T:1 PADS ID:6
10:00:57Jan 1 09:14:12 WAN1 PPPoE <== V:1 T:1 PADS ID:6
10:00:57Jan 1 09:14:12 WAN1 PPPoE ==> Protocol:LCP(c021) ConfReq Identifier:0x00 MRU: 1500 ##
10:00:58Jan 1 09:14:13 WAN1 PPPoE <== Protocol:LCP(c021) ConfReq Identifier:0xF7 Authentication Type: CHAP 05 Magic Number: 0xd1c9d2a ##
10:00:58Jan 1 09:14:13 WAN1 PPPoE ==> Protocol:LCP(c021) ConfAck Identifier:0xF7 Authentication Type: CHAP 05 Magic Number: 0xd1c9d2a ##
10:01:01Jan 1 09:14:16 WAN1 PPPoE <== Protocol:LCP(c021) ConfReq Identifier:0xF8 Authentication Type: CHAP 05 Magic Number: 0xd1c9d2a ##
10:01:01Jan 1 09:14:16 WAN1 PPPoE ==> Protocol:LCP(c021) ConfAck Identifier:0xF8 Authentication Type: CHAP 05 Magic Number: 0xd1c9d2a ##
10:01:04Jan 1 09:14:19 WAN1 PPPoE <== Protocol:LCP(c021) ConfReq Identifier:0xF9 Authentication Type: CHAP 05 Magic Number: 0xd1c9d2a ##
10:01:04Jan 1 09:14:19 WAN1 PPPoE ==> Protocol:LCP(c021) ConfAck Identifier:0xF9 Authentication Type: CHAP 05 Magic Number: 0xd1c9d2a ##
10:01:05Jan 1 09:14:19 WAN1 PPPoE ==> Protocol:LCP(c021) ConfReq Identifier:0x01 MRU: 1500 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE <== Protocol:LCP(c021) ConfAck Identifier:0x01 MRU: 1500 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE <== Protocol:CHAP(c223) Challenge Identifier:0x00 10 8e 97 d7 75 c8 56 16 37 48 0d cd e7 6f fc e7 fa 45 52 58 31 35 2e 53 68 65 66 66 69 65 6c 64 32 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE ==> Protocol:CHAP(c223) Response Identifier:0x00 10 f6 12 8c 85 3f be c2 c4 a1 d1 01 28 ad b9 51 19 31 32 33 30 30 35 32 40 64 73 6c 2d 6c 6f 67 69 6e 32 2e 63 6f 6d ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE <== Protocol:LCP(c021) ConfReq Identifier:0x01 Authentication Type: CHAP 05 Magic Number: 0x23f26a64 MRRU: 1524 Endpoint Discriminator Locally Assigned Address: 61 72 32 2e 74 68 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE ==> Protocol:LCP(c021) ConfReq Identifier:0x02 MRU: 1500 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE ==> Protocol:LCP(c021) ConfAck Identifier:0x01 Authentication Type: CHAP 05 Magic Number: 0x23f26a64 MRRU: 1524 Endpoint Discriminator Locally Assigned Address: 61 72 32 2e 74 68 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE <== Protocol:LCP(c021) ConfAck Identifier:0x02 MRU: 1500 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE <== Protocol:CHAP(c223) Challenge Identifier:0x01 10 3a 24 16 67 14 a1 8d ff 1b 79 64 22 57 b9 bc ec 61 72 32 2e 74 68 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE ==> Protocol:CHAP(c223) Response Identifier:0x01 10 68 0b f6 33 ea a1 8f 00 30 ec 96 e6 eb 1a f9 ee 31 32 33 30 30 35 32 40 64 73 6c 2d 6c 6f 67 69 6e 32 2e 63 6f 6d ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE <== Protocol:CHAP(c223) Success Identifier:0x01 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE ==> Protocol:IPCP(8021) ConfReq Identifier:0x00 Vendor Specific: 00 00 0c 01 00 00 00 00 IP Address: 0 0 0 0 Primary Domain Name Server: 0 0 0 0 Secondary Domain Name Server: 0 0 0 0 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE <== Protocol:IPCP(8021) ConfReq Identifier:0x01 IP Address: 195 7 254 131 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE ==> Protocol:IPCP(8021) ConfAck Identifier:0x01 IP Address: 195 7 254 131 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE <== Protocol:IPCP(8021) ConfRej Identifier:0x00 Vendor Specific: 00 00 0c 01 00 00 00 00 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE ==> Protocol:IPCP(8021) ConfReq Identifier:0x01 IP Address: 0 0 0 0 Primary Domain Name Server: 0 0 0 0 Secondary Domain Name Server: 0 0 0 0 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE <== Protocol:IPCP(8021) ConfNak Identifier:0x01 IP Address: 213 246 85 98 Primary Domain Name Server: 195 7 224 57 Secondary Domain Name Server: 195 7 224 143 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE ==> Protocol:IPCP(8021) ConfReq Identifier:0x02 IP Address: 213 246 85 98 Primary Domain Name Server: 195 7 224 57 Secondary Domain Name Server: 195 7 224 143 ##
10:01:05Jan 1 09:14:20 WAN1 PPPoE <== Protocol:IPCP(8021) ConfAck Identifier:0x02 IP Address: 213 246 85 98 Primary Domain Name Server: 195 7 224 57 Secondary Domain Name Server: 195 7 224 143 ##
10:01:05Jan 1 09:14:20 WAN 1 is up.

So, is it possible the the BT engineer can use my Namesco UN & PW in his JDSU?

Yes, but you'd need to be a bit 'lucky' and get a slightly more clued up engineer. Do what you ask is not actually a required part of the LLU SFI visit, so they could just decline.

can the engineer's test equipment "listen in" on the PPP handshaking between my router and the Radius servers?

Not as far as I am aware.


Glad to hear it's fixed. At a guess, the port has been flexed or reset.