Re: pppd failures
u...@earthlink.net ("CK") writes:
>First, thank you for taking time to help. My reply:
>1. You appear to say that FreeBSD *is* asked to do PAP
>authentication in the 1st LCP response, but I fail to
>see this (I am also no PPP expert).
No, according to your logs FreeBSD isn't asked to do PAP even when
FreeBSD and NetBSD start the PPP protocol (almost) the same. There
must be a difference so that PAP is requested.
>4. I don't think anything is happening before pppd starts,
>and at least,
Before the PPP protocol starts, there is the chat dialog.
>The chat conversation on both FreeBSD and NetBSD is the same.
>Same expect/send pairs, same timeouts, etc. There's nothing
>special to see in chat(1) logs - just the basic expect/send
>pairs ending with the password prompt - when it was used.
Please show the chat logs for the working FreeBSD session and
the failing NetBSD session.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: pppd failures
First, thank you for taking time to help. My reply: 1. You appear to say that FreeBSD *is* asked to do PAP authentication in the 1st LCP response, but I fail to see this (I am also no PPP expert). 2. I don't know if NetBSD sends the initial packet 2x, because they both occur in the same second, so I thought perhaps it might be an error in duplicate-logging, since it never appears to happen after the 1st entry. 3. I tried the MRU pppd option setting to 1524 to comply with the peer, but it didn't change any results - but it seemed to have been set. I would say this has no effect on the connection problem. 4. I don't think anything is happening before pppd starts, and at least, I don't know of any way to capture that data excepting tcpdump (if it has a full 8-bit display mode of traffic, but I haven't been able to play with that since I have never had a working connection with pppd). But I can say this: after the password is entered, nothing visible occurs - even using cu(1) - the screen simply stays exactly the same with the non-echoed password and prompt. And the chat script expects nothing after it sends the password - and if it did try to expect something, it would not get it, at least, based on all other things I can determine. Even if no login/password entries are made - the screen just stays the same with a Login: prompt until a timeout occurs on the peers side and disconnects. After the chat(1) script is run, and it operates without error, pppd is immediately started - or more accurately, pppd IS RUNNING chat(1), so there should be no delay in characters received after chat sends a password, and also, as stated, the login/password expect/send pairs were removed, and that data was provided as well. The chat conversation on both FreeBSD and NetBSD is the same. Same expect/send pairs, same timeouts, etc. There's nothing special to see in chat(1) logs - just the basic expect/send pairs ending with the password prompt - when it was used. Thank you for helping me see that the Terminate Request only pplied to the CCP layer in the FreeBSD log; I didn't notice that. Anyway, this is perhaps the largest dialup ISP in the USA, and pppd should be able to connect to it, and the pppd-source site stated that no questions are taken from the public since the author gets too many "how do i ..." questions and cannot answer them all, but pppd does seem to be actively developed and millions of people still need PPP dialup access, so if nobody can help make this work, I wish someone would fix it. I don't know how such things like simple standard protocols can be broken after over 20 years of development, excepting that human nature often finds temporary satisfactions in engaging complexities regardless of the wisdom in doing so. Why it was/is it too complex for NetBSD to maintain a functional pppd itself? It must have had one at one time. It seems that all energy is being placed into things to satisfy commercial funding, and none into things that non-commercial use requires - but that was the whole point of beginning BSDs/Linuxs; to get away from the commercial crap (MacOS/MS Windows+DOS) that was being shoved down everybody's throat. It seems that the commercial sector has secretly leveraged coding resources into private slave-labor, when they were originally people that just wanted to share something they took pride and satisfaction in, creating a better-than-commercial product themselves. >mlelstv%serpens.de@localhost: > >Both systems start (almost) the same way, but FreeBSD >isn't asked to do PAP authentication. That already happens >in the first LCP reponse. > >>LCP: deflink: SendConfigReq(1) state = Stopped >>LCP: ACFCOMP[2] >>LCP: PROTOCOMP[2] >>LCP: ACCMAP[6] 0x >>LCP: MRU[4] 1500 >>LCP: MAGICNUM[6] 0xcf3614cc >>LCP: QUALPROTO[8] proto c025, interval 3ms >>LCP: deflink: State change Stopped --> Req-Sent >>LCP: deflink: RecvConfigReq(1) state = Req-Sent >>LCP: MRU[4] 1524 >>LCP: ACCMAP[6] 0x000a >>LCP: PROTOCOMP[2] >>LCP: ACFCOMP[2] >>LCP: deflink: SendConfigAck(1) state = Req-Sent > >>sent [LCP ConfReq id=0x1] >>sent [LCP ConfReq id=0x1] >>rcvd [LCP ConfReq id=0x1 < 00 04 00 00> >pap >>] >>No auth is possible > >NetBSD sends the packet twice and doesn't negotiate MRU (probably >because 1500 is the default). But the peer answers differently >although the ConfReq doesn't give a reason for this difference. > >So I can only guess that anything happening before PPP starts already >tries to authenticate with the peer and that's where both systems behave >differently (and FreeBSD succeeded). > >>lock debug kdebug 4 >>tty00 57600 crtscts >>connect '/usr/sbin/chat -vf /etc/ppp/chat' >>defaultroute > >You could try to log the initial conversation done by 'chat' and >the FreeBSD equivalent. > >N.B. according to your log FreeBSD only gets a Terminate Request >for the CCP protocol, not for LCP. That's why the there is no >disconnect.
Re: pppd failures
u...@earthlink.net ("CK") writes:
>Basically, it appears that when a login-only attempt
>is done with pppd, there is a failure+disconnect due
>to not agreeing with PAP authentication, yet when PAP
>authentication is done, both with and without a login
>and password prompt, the ISP disconnects with a
>REQUEST DENIED. However, the FreeBSD user-ppp never
>gets any request to do PAP authentication, and isn't
>disconnected even after receiving Terminate Requests.
Both systems start (almost) the same way, but FreeBSD
isn't asked to do PAP authentication. That already happens
in the first LCP reponse.
>LCP: deflink: SendConfigReq(1) state = Stopped
>LCP: ACFCOMP[2]
>LCP: PROTOCOMP[2]
>LCP: ACCMAP[6] 0x
>LCP: MRU[4] 1500
>LCP: MAGICNUM[6] 0xcf3614cc
>LCP: QUALPROTO[8] proto c025, interval 3ms
>LCP: deflink: State change Stopped --> Req-Sent
>LCP: deflink: RecvConfigReq(1) state = Req-Sent
>LCP: MRU[4] 1524
>LCP: ACCMAP[6] 0x000a
>LCP: PROTOCOMP[2]
>LCP: ACFCOMP[2]
>LCP: deflink: SendConfigAck(1) state = Req-Sent
>sent [LCP ConfReq id=0x1]
>sent [LCP ConfReq id=0x1]
>rcvd [LCP ConfReq id=0x1 < 00 04 00 00> pap>]
>No auth is possible
NetBSD sends the packet twice and doesn't negotiate MRU (probably
because 1500 is the default). But the peer answers differently
although the ConfReq doesn't give a reason for this difference.
So I can only guess that anything happening before PPP starts already
tries to authenticate with the peer and that's where both systems behave
differently (and FreeBSD succeeded).
>lock debug kdebug 4
>tty00 57600 crtscts
>connect '/usr/sbin/chat -vf /etc/ppp/chat'
>defaultroute
You could try to log the initial conversation done by 'chat' and
the FreeBSD equivalent.
N.B. according to your log FreeBSD only gets a Terminate Request
for the CCP protocol, not for LCP. That's why the there is no
disconnect.
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
pppd failures
This regards a NetBSD pppd problem in connecting to a national ISP in the USA via dial-up. First, the log showing FreeBSD successfully establishing a PPP connection with its user-ppp. Then 3 types of NetBSD pppd attempts, which all fail (and many more types of options were attempted - but the 3 listed serve to demonstrate the same problem which is in need of some kind of resolution). Potential trivial mistakes such as bad user/password information in PAP configurations were double-checked 10x over, as well as swapping the login name with the local host name, and many other possible option adjustments to establish a PPP connection. FBSD=11.0-RC3 NBSD=7.0.1 Basically, it appears that when a login-only attempt is done with pppd, there is a failure+disconnect due to not agreeing with PAP authentication, yet when PAP authentication is done, both with and without a login and password prompt, the ISP disconnects with a REQUEST DENIED. However, the FreeBSD user-ppp never gets any request to do PAP authentication, and isn't disconnected even after receiving Terminate Requests. = FreeBSD user-ppp log (logs in and functions without PAP). = Command: isp: enable lqr echo Command: isp: disable ipv6cp Command: isp: disable mppe Phase: PPP Started (ddial mode). Phase: bundle: Establish Phase: deflink: closed -> opening Phase: deflink: Connected! Phase: deflink: opening -> dial Phase: deflink: login -> lcp LCP: FSM: Using "deflink" as a transport LCP: deflink: State change Initial --> Closed LCP: deflink: State change Closed --> Stopped LCP: deflink: LayerStart LCP: deflink: SendConfigReq(1) state = Stopped LCP: ACFCOMP[2] LCP: PROTOCOMP[2] LCP: ACCMAP[6] 0x LCP: MRU[4] 1500 LCP: MAGICNUM[6] 0xcf3614cc LCP: QUALPROTO[8] proto c025, interval 3ms LCP: deflink: State change Stopped --> Req-Sent LCP: deflink: RecvConfigReq(1) state = Req-Sent LCP: MRU[4] 1524 LCP: ACCMAP[6] 0x000a LCP: PROTOCOMP[2] LCP: ACFCOMP[2] LCP: deflink: SendConfigAck(1) state = Req-Sent LCP: MRU[4] 1524 LCP: ACCMAP[6] 0x000a LCP: PROTOCOMP[2] LCP: ACFCOMP[2] LCP: deflink: State change Req-Sent --> Ack-Sent LCP: deflink: SendConfigReq(1) state = Ack-Sent LCP: ACFCOMP[2] LCP: PROTOCOMP[2] LCP: ACCMAP[6] 0x LCP: MRU[4] 1500 LCP: MAGICNUM[6] 0xcf3614cc LCP: QUALPROTO[8] proto c025, interval 3ms LCP: deflink: RecvConfigRej(1) state = Ack-Sent LCP: QUALPROTO[8] proto c025, interval 3ms LCP: deflink: SendConfigReq(2) state = Ack-Sent LCP: ACFCOMP[2] LCP: PROTOCOMP[2] LCP: ACCMAP[6] 0x LCP: MRU[4] 1500 LCP: MAGICNUM[6] 0xcf3614cc LCP: deflink: RecvConfigAck(2) state = Ack-Sent LCP: ACFCOMP[2] LCP: PROTOCOMP[2] LCP: ACCMAP[6] 0x LCP: MRU[4] 1500 LCP: MAGICNUM[6] 0xcf3614cc LCP: deflink: State change Ack-Sent --> Opened LCP: deflink: LayerUp LCP: deflink: SendEchoRequest(0) state = Opened CCP: FSM: Using "deflink" as a transport CCP: deflink: State change Initial --> Closed CCP: deflink: LayerStart. CCP: deflink: SendConfigReq(1) state = Closed CCP: DEFLATE[4] win 15 CCP: PRED1[2] CCP: deflink: State change Closed --> Req-Sent Phase: deflink: lcp -> open Phase: bundle: Network IPCP: FSM: Using "deflink" as a transport IPCP: deflink: State change Initial --> Closed IPCP: deflink: LayerStart. IPCP: deflink: SendConfigReq(1) state = Closed IPCP: IPADDR[6] 72.251.118.0 IPCP: COMPPROTO[6] 16 VJ slots with slot compression IPCP: deflink: State change Closed --> Req-Sent IPCP: deflink: RecvConfigReq(1) state = Req-Sent IPCP: COMPPROTO[6] 16 VJ slots with slot compression IPCP: IPADDR[6] 4.34.24.78 IPCP: deflink: SendConfigAck(1) state = Req-Sent IPCP: COMPPROTO[6] 16 VJ slots with slot compression IPCP: IPADDR[6] 4.34.24.78 IPCP: deflink: State change Req-Sent --> Ack-Sent CCP: deflink: RecvConfigReq(1) state = Req-Sent CCP: MPPE[6] value 0x0001 (0 bits, stateful, compressed) CCP: MPPE: Not usable without CHAP81 CCP: deflink: SendConfigRej(1) state = Req-Sent CCP: MPPE[6] value 0x0001 (0 bits, stateful, compressed) LCP: deflink: RecvEchoReply(0) state = Opened CCP: deflink: RecvConfigRej(1) state = Req-Sent CCP: DEFLATE[4] win 15 CCP: PRED1[2] CCP: deflink: SendConfigReq(2) state = Req-Sent CCP: [EMPTY] IPCP: deflink: RecvConfigNak(1) state = Ack-Sent IPCP: IPADDR[6] 72.251.111.152 IPCP: IPADDR[6] changing address: xxx.xxx.xxx.xxx --> yyy.yyy.yyy.yyy IPCP: deflink: SendConfigReq(2) state = Ack-Sent IPCP: IPADDR[6] 72.251.111.152 IPCP: COMPPROTO[6] 16 VJ slots with slot compression CCP: deflink: RecvConfigReq(2) state = Req-Sent CCP: STAC[5] CCP: deflink: SendConfigRej(2) state = Req-Sent CCP: STAC[5] CCP: deflink: RecvConfigRej(2) state = Req-Sent CCP: [EMPTY] CCP: deflink: SendConfigReq(3) state = Req-Sent CCP: [EMPTY] IPCP: deflink: RecvConfigAck(2) state = Ack-Sent IPCP: IPADDR[6] 72.251.111.152 IPCP: COMPPROTO[6] 16 VJ slots with slot
