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] 0x00000000 >>LCP: MRU[4] 1500 >>LCP: MAGICNUM[6] 0xcf3614cc >>LCP: QUALPROTO[8] proto c025, interval 30000ms >>LCP: deflink: State change Stopped --> Req-Sent >>LCP: deflink: RecvConfigReq(1) state = Req-Sent >>LCP: MRU[4] 1524 >>LCP: ACCMAP[6] 0x000a0000 >>LCP: PROTOCOMP[2] >>LCP: ACFCOMP[2] >>LCP: deflink: SendConfigAck(1) state = Req-Sent > >>sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x419fcd5a> <pcomp> <accomp>] >>sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x419fcd5a> <pcomp> <accomp>] >>rcvd [LCP ConfReq id=0x1 < 00 04 00 00> <mru 1524> <asyncmap 0xa0000> <auth >>pap >> <pcomp> <accomp> <mrru 1524> <endpoint [MAC:00:d0:52:04:23:6d]>] >>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.
