[nSLUG] Troubleshooting LCP & PAP on a Telus dialup NAS

Dop Ganger nslug at fop.ns.ca
Mon Dec 8 14:14:47 AST 2014


On Sun, 7 Dec 2014, Mike Spencer wrote:

> ATI6 says, "Disconnect Reason is DTR dropped". Excerpts from the ppp
> log below.

OK, so your end gave up and dropped the line on purpose. Still doesn't 
hint at a line issue.

> But I don't see that.  Instead, the sniffer reports that, after
> CONNECT, the first bytes going out to the serialport are:
>
>     7e 7d df 7d 23 c0 21 7d   21 7d 21 7d 20 7d 34 7d
>     22 7d 26 7d 22 7d 2a 7d   20 7d 20 7d 25 7d 26 ac
>     ba 83 7d 27 7d 27 7d 22   7d 28 7d 22 ba 7d 2c 7e
>
> to which the server replies:
>
>     7e 7d 5f 7d 23 40 21 7d   21 7d 21 7d 20 7d 34 7d
>     22 7d 26 7d 22 7d 2a 7d   20 7d 20 7d 25 7d 26 2c
>     3a
>
> Two points here:
>
>    + What do I not understand about serial comm?  Why don't I see
>      recognizable LCP in the sniffer data?
>
>    + It looks like the remote NAS is replying with bytes similar to
>      mine but with all bit-7  == 0.

Also it's giving up on the 33rd character, which says to me the remote end 
is echoing back what you're sending it in ASCII mode and is trying to do a 
script based login - with 32 characters being the point at which it gives 
up, assuming your username is too long. The garbled output replied back is 
confusing pppd at your end enough to give up and throw in the towel.

> And pppd sometimes (but not always) remarks on the 7-bit incoming
> data (See 2nd ppp log, infra)

Which means, in short, the remote end wasn't expecting you to start a PPP 
session.

>> Have you tried logging in by hand using something like minicom? It
>> might be expecting a script based username and password login before
>> kicking in with PPP.
>
> Oh, yes. The server presents a banner, then:
>
>    Username: Login:
>
> (why both?) and responds to a manually entered username with:
>
>    Password:
>
> but replies, after manually entered password, "% Authentication
> failed". Times out or, after 3rd try, quits.

This says to me that the remote end is failing because the back-end 
authentication server (probably a RADIUS box somewhere) is rejecting your 
authentication attempt. Until the ISP fixes that, I don't think you're 
going to go anywhere. I think you should be able to cut and paste the 
login procedure and auth failure in an email to your provider and that 
would be enough to fire it off. They may want to try changing your 
password to see if that populates on the back end (and probably wouldn't 
be a bad idea to request anyway - if the ISP can't change your password 
there's something pretty wonky going on right there).

Cheers... Dop.


More information about the nSLUG mailing list