[nSLUG] Re: Troubleshooting LCP & PAP on a Telus dialup NAS
mspencer at tallships.ca
Sun Dec 7 18:11:20 AST 2014
> On Sat, 6 Dec 2014, Mike Spencer wrote:
>> No blers, no retrains, good SNR. Carried a laptop to a different
>> number in a different exchange. Same LCP failure.
> Not a problem with the line then.
> If ATI6 gives reason for disconnect as something like "Remote end
> send disconnect" it's their end hanging up so if anything, they have
> line issues.
ATI6 says, "Disconnect Reason is DTR dropped". Excerpts from the ppp
I can see that I'm sending data out and that I'm receiving data from
the NAS. (Blinken lights, y'know?) So I got slsnif, a serial port
sniffer and ran that.
What I expected to see was a recognizable LCP ConfReq packet going out
when the ppp log said that was happening. According to the RFCs, such
a packet should begin 0x01 0x01 because it's LCP code 1 and first
(ID #1) exchange in the LCP negotiation. Then there should be 2
octets for packet length and <length-4> octets of data.
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.
And pppd sometimes (but not always) remarks on the 7-bit incoming
data (See 2nd ppp log, infra)
> 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:
(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.
It is not unknown for a dialup server to present the ASCII
Login:/Password: authentication interface while expecting immediate
LCP/PPP negotiation. This appears to be described on the net as
"Stupid Mode". It is the mode implemented by the now defunct Telus
dialup servers and it took me days to figure it out when they switched
to that mode in 2012.
And there are other variations on the theme that I haven't encountered
1st hand, such as requiring username@<domain>%ppp or sending a
proprietary string after the text login. All of that is Old Stuff;
this should go directly from modem CONNECT to LCP.
Have to email Neil Clarke,  my guy at Fibernetics, to see if he can
determine *precisely* what the dialup interface expects and whether
it's stuck in 7-bit mode somehow.
 Neil Clarke, scroll down half way. They seem to have a mandatory
company policy of all staff being Happy Campers. Have to say, I'm
--- Begin /var/log/ppp excerpts ---
Dec 5 01:17:36 bogus pppd: sent [LCP ConfReq id=0x1 \
<asyncmap 0x20a0000> <magic 0xc87983ac> <pcomp> \
Dec 5 01:17:54 bogus last message repeated 6 times
Dec 5 01:17:56 bogus pppd: Hangup (SIGHUP)
Dec 5 01:17:56 bogus pppd: Modem hangup
Dec 5 01:17:56 bogus pppd: Connection terminated.
Dec 5 01:17:57 bogus pppd: Exit.
(actually, "repeated n times", 6<=n<=10) or
Dec 7 02:35:40 bogus pppd: sent [LCP ConfReq id=0x1
<asyncmap 0x20a0000> <magic 0xff88a17c> <pcomp>
Dec 7 02:36:07 bogus last message repeated 9 times
Dec 7 02:36:10 bogus pppd: LCP: timeout sending Config-Requests
Dec 7 02:36:10 bogus pppd: Connection terminated.
Dec 7 02:36:10 bogus pppd: Receive serial link is not 8-bit clean:
Dec 7 02:36:10 bogus pppd: Problem: all had bit 7 set to 0
Dec 7 02:36:11 bogus pppd: Hangup (SIGHUP)
Dec 7 02:36:11 bogus pppd: Modem hangup
Dec 7 02:36:11 bogus pppd: Exit.
--- End /var/log/ppp excerpts ---
Michael Spencer Nova Scotia, Canada .~.
mspencer at tallships.ca /( )\
More information about the nSLUG