Re: pppd failures

["CK" <un_x%earthlink.net@localhost>]

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.