On Wed, 30 Dec 1998, Jonathan Marsden wrote:

> > 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?

Jonathan & others...

No, the remote PPP is not expecting me to request authentication. My chat
script gets me through a server which does authentication for me.

> 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!

Right... I understand this...

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

I've seen it, but I'm waiting for Andrew Suns book to come out so that I
can compare the two and determine which is best for me. However, each time
I check the O'Reilly web site it seems like the release date for Sun's
book keeps getting moved into the future (now it is March 1999).

> 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'm thinking it is a timing issue... My previous connections to their
server always used IPCP.

> 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.

I can hack the code.. I'm just not sure where to look. I guess I'll browse
around the code sometime today and see what I can do.

> > 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!

I can try this... but it is set to 115200 because I have a Hayes Enhanced
Serial Port (ESP) card and I'm using a Hayes Optima 56K modem. Those two
products can talk to each other at high rates.

> 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.

It didn't.

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

Did that, but didn't make a difference. I tried setting the rate to 28800
and 115200 and performed several tests. Neither one worked.

> After that, you are left with the more difficult, but quite doable:
> 
> (3) Add a delay after ConfAck to your (NetBSD) PPP implementation.

I looked at the code, but really wasn't sure here to make the
modification.


All of the above comments were written a couple of days ago when I first
received your response. I got busy and didn't have time to send the
message right away. Now, I've resurrected the response from my draft
folder and in the meantime, I have done some more testing and now things
are working much better. Here are some comments...:

About 98% of the time when I dial my ISP I would encounter some type of
authentication system that I needed to pass before any PPP negotiation
would begin. During the other 2% of the time I would somehow bypass that
authentication system and PPP negotiations would begin. During these times
I often saw requests for PAP and CHAP from the ISP side. I have a
pap-secrets file, but PAP would never work in those cases.

The logging ability of my Win95 system does not appear to be as
comprehensive as my NetBSD. It is hard for me to know how Win95 handles
the login sequence w/o source code, and because I do not have a
Win95 PPP script associated with my ISP. Since most of the time I never
see the PAP authorization requests using NetBSD I am going to assume that
the Win95 log I included for comparison is not really a good choice for
comparison.

Now things have changed... It appears that my ISP has made some more
changes to their side. Now when I connect to my ISP I never see the user
authentication messages that my chat script expects. Instead, PPP
negotiation begins immeadiately. My ISP is now always requesting PAP
authentication and my system responds with the appropriate information
from the pap-secrets file. In addition, I am now seeing requests for
options that my ISP never supported -- such as VJ compression, predictor 1
and a couple of CCP protocols that pppd doesn't recognize. In addition to
my ISP's upgrade of their modems, it appears that they have also updated
their PPP software.

The good news is that now my PPP connection to my ISP is working properly,
and the only change I had to make was to my chat script so that it did
not look for a "Username" and "Password" prompt anymore. I then also
decided to re-enable some of the options that I had previously commented
out, but that was not necessary to make things work.

I probably could have avoided this frustrating mess if my ISP had taken
the time to notify its customers of the upgrade. I guess now all I can do
is send them a complaint about this and hope they don't upgrade their
stuff again in the near future...


Regards,

Brian

-------------------------------------------------------------------------
| Brian Stark                       | Internet : bstark@siemens-psc.com |
| Siemens PT&D, LLC                 | Voice    : +1 612 536-4697        |
| Power Systems Control Division    | Fax      : +1 612 536-4919        |
| 7225 Northland Drive, Brooklyn Park, Minnesota 55428   USA            | 
-------------------------------------------------------------------------