[nSLUG] Troubleshooting LCP & PAP on a Telus dialup NAS
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
> 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
>> 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:
> 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).
More information about the nSLUG