On 30 Dec 1998, Brian Stark writes:

> On the NetBSD system, this is what I see when calling my ISP:
 
> Dec 29 13:50:28 callisto pppd[8250]: Connect: ppp0 <--> /dev/tty02
> Dec 29 13:50:28 callisto pppd[8250]: sent [LCP ConfReq id=0x1 <magic 0xc641dac6> <pcomp> <accomp>]
> Dec 29 13:50:28 callisto pppd[8250]: rcvd [LCP ConfReq id=0x6 <asyncmap 0xa0000> <magic 0xfbcf440b> <pcomp> <accomp>]
> Dec 29 13:50:28 callisto pppd[8250]: sent [LCP ConfAck id=0x6 <asyncmap 0xa0000> <magic 0xfbcf440b> <pcomp> <accomp>]
> Dec 29 13:50:28 callisto pppd[8250]: rcvd [LCP ConfAck id=0x1 <magic 0xc641dac6> <pcomp> <accomp>]

Hmmm, you didn't negotiate any authentication at all.  not necessarily
wrong, but something a poor remote PPP implementation may not be
expectng?

> Dec 29 13:50:28 callisto pppd[8250]: sent [IPCP ConfReq id=0x1 <addr 192.168.2.1>]
> Dec 29 13:50:28 callisto pppd[8250]: rcvd [LCP ProtRej id=0x7 80 21 01 01 00 0a 03 06 c0 a8 02 01]

You sent IPCP, which is an NCP thing, but the remote responded with
LCP... that's a layering conflict or the remote thinks you are not
allowed to use IPCP!

The book "PPP Design and Debugging" by James Carlson is almost a
necessity in debugging this sort of thing.  Highly recommended.

My strong suspicion is that your ISP has a new PPP implementation (ie
they didn't just swap modems, they probably swapped terminal servers
or equivalent).

The LCP ProtRej message means that either LCP is giving up because it
received totally incomprehensible information from you, or it receoved
a protocol from you it can't or won't handle.  That incomprehensible
or rejected info is included in the LCP ProtRej message.  It is (as
you sort of noticed but didn't take quite far enough) actually just
the IPCP ConfReq that your own system had just sent out.

So, what happened was that your system sent the IPCP ConfReq after
sending and receiving an LCP ConfAck... cool.  But somehow the ISP's
PPP implementation either did not switch out of LCP and into NCP fast
enough for you... or it decided you arenot allowed to use IPCP.

I can't think of a good reason for denying IPCP completely at this
stage (unless the provider was not an ISP but a 'Netware Provider'
offering IPX over PPP or something equally bizarre).  So, it looks
like a timing issue at the layer transition, one that has a
particularly bad result in your case.

Carlson suggests that if you see this sort of timing problem, you may
be able to work around it by introducing a short delay after sending
ConfAck in each layer.  In this (common) case, after sending the LCP
ConfAck.

The effect is to just hang around and wait for the buggy PPP
implementation on the remote site to get with the program and switch
into listening for NCP negotiation).  If you know enough to insert
such a delay into the NetBSD PPP implementation, go for it...!  I
don't think there is a way to use an option to ask NetBSD to do that,
so you'd probably have to actually go hack the source code.

Otherwise, about all you can do complain long and loud that your ISPs
PPP implementation is buggy.  Or switch ISPs :-)

> If you convert the last 4 hex codes of the LCP ProtRej message to
> decimal you will see that they match the IP address used when my
> system sent a IPCP ConfReq message.

The entire LCP ProtRej message after the ID byte is an exact copy of
the message that caused the rejection.  The 80 21 at the start was the
big clue for me... I recognized it as the IPCP protocol identifier.

So I figured somehow the two systems were probably getting out of sync
regarding whether they were doing LCP or IPCP, and then grabbed
Carlson and confirmed that this is a known problem with some PPP
implementations, and noted his idea for working around it.  if you get
the book, read Chapter 7, Interpreting races, especially the section
on pages 148-149 subtitled "LCP to NCP Transition Race Conditions".
This describes exactly what I believe your trace shows.

> However, I am really confused as to why the remote system is
> responding with a LCP ProtRej message.

See above :-)  The other option is that the remote system is refusing
to do IPCP with you for some reason.

> I know that there can sometimes be problems with the asyncmap
> setting, and I have tried different settings for that that (asyncmap
> 0, asyncmap 0xfffff, asyncmap 0xa0000, default-asyncmap) and all to
> no avail.

No, by the time the problem occurs, LCP has already sucessfully
negotiated in both directions (LCP ConfAck sent and received), so no
LCP negotiated options (like asyncmap) should affect it.

> tty02 115200

Hmmm, would a lower DTE speed slow things down enough to work around
the problem??  Might be interesting to set say 9600 here and see if
things work??  Just a thought, not really a practical long term
solution!

> 12-29-1998 14:33:43.25 - LCP : Layer up.
> 12-29-1998 14:33:43.25 - PAP : Layer started.
> 12-29-1998 14:33:46.22 - PAP : Login was successful.
> 12-29-1998 14:33:46.22 - PAP : Layer up.
> 12-29-1998 14:33:46.22 - IPCP : Layer started.

Ahah!  Authentication happened here.  PAP.  PAP was not negotiated or
used by the BSD connection at all.  Maybe (??) using PAP under NetBSD
would change things enough to make a difference?  I'm guessing... but
it's easy to try!  Perhaps the ISP's system really requires
authentication but is not smart enough to tell your system that during
LCP negotiation?  Anyway, since you apparently have a username/secret
pair that will work for PAP authentication with this ISP, try using it
from NetBSD just as you did from MS Windows.

>From my perspective, then, the two immediate things to try are:

(1) Turn on PAP authentication.  Might help.

(2) Slow down the DTE.  Unlikely to help, but easy to try.

After that, you are left with the more difficult, but quite doable:

(3) Add a delay after ConfAck to your (NetBSD) PPP implementation.

Caveat: I'm definitely not the world's top PPP expert.  I'm pretty
sure I've described what is happening correctly, but don't make any
million dollar deals on that basis, or sue anyone, etc... :-)

Hoping this helps,

Jonathan
--
Jonathan Marsden   | Internet: jonathan@xc.org  | Making electronic 
1849 N. Wabash Ave.| Phone: +1 (909) 794 1151   | communications work 
Redlands, CA 92374 | FAX:   +1 (909) 794 3016   | reliably for Christian 
USA                | http://www.xc.org/jonathan | missions worldwide