SUMMARY: PPP 2.4.1 on Solaris 2.5.1 fails to negotiate/authenticate on startup

This is in two parts: first is the new material since the partial summary;
this is followed by a reprint of the partial summary so that archivers keying
off the string "SUMMARY" at the beginning of the "Subject" line will find it.
(I didn't get any responses to my question from the list, which is why you
don't see a list of thank-yous here.)

1. The crashes (see last paragraph below) were solved by putting "novj"
in the /etc/ppp/options file.  This disables Van Jacobson header compression
and made the crashes stop.  (Why did I choose this option?  Because the syslog'd
messages during the crash included

	Mar 26 19:43:00 cheech unix: pid=0, pc=0xf5d61124(vj_uncompress_uncomp+30), sp=0xfbe2bca0, psr=0x49000c4, context=0

which led me to the subroutine vj_uncompress_uncomp() inside PPPD, and I
guessed (apparently correctly) that disabling VJ compression would do the trick.)

(No, I haven't debugged the code and sent in a fix.  Given that this is
under Solaris 2.5.1, I'm not sure it's worth it.  If the problem shows
up later under Solaris 9, I will.)

2. Here's the partial summary:

On Wed, Mar 26, 2003 at 08:22:03PM -0500, Rich Kulawiec wrote:
> On Wed, Mar 26, 2003 at 12:04:27PM -0500, Rich Kulawiec wrote:
> > Problem: The entire subsystem (PPP et.al.) is known to work when dialing
> > ISP #1; in fact, it works like a champ.  I believe this indicates that
> > PPP is installed correctly, that the modem is functioning properly, etc.
> > However, it does not work when dialing ISP #2; it appears to be having an
> > issue trying to negotiate PPP options.
> 
> This statement is mostly incorrect.  It isn't failing while trying to
> negotiate PPP options: it has already failed by this point.  So the
> syslog'd messages of the form:
> 
> > Mar 26 11:14:24 cheech pppd[709]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x99e22c89> <pcomp> <accomp>]
> 
> represent my end of the PPP connection sending LCP packets to a remote end
> that isn't listening: it's not that negotiations are failing, it's that
> negotiations are not taking place.
> 
> And this is apparently because newer implementations of PPP servers
> do not expect to have an ASCII exchange of login/password/etc. as older
> ones do; they expect the caller's end (my end) to start up PPP as soon as
> a connection is established and to carry out authentication from within PPP.
> 
> In other words, the old way was:
> 
> 	<dial a number>
> 	Hello, you have reached your ISP.
> 	Login:
> 	<send login>
> 	Password:
> 	<send password>
> 	[PPP starts up]
> 
> The new way is:
> 
> 	<dial a number>
> 	[PPP starts up]
> 
> So the core of the problem is contained here:
> 
> > 	/usr/local/bin/pppd debug connect \'/usr/local/bin/chat -v \"\" ATDT123456789
> > 	CONNECT \"\"\' /dev/cua/d 57600 defaultroute user USER@RADIUSDOMAIN debug kdebug 7"
> 
> 
> See the \"\" after the CONNECT?  It sends a newline after the modem signals
> that it has established a connection to the remote system.  If this were
> one of the older PPP implementations like the example I showed above, then
> this would cause the remote end to emit "Hello, you have reached your ISP"
> and "Login:".  But this is a newer PPP implementation, and it doesn't expect
> this: it expects me to start PPP immediately.  So the newline that's in
> there messes this up -- it doesn't need to be sent, in fact, it shouldn't
> be sent, because the remote end starts ignoring me from that point forward.
> 
> Modifying the script to make this change now allows me to connect.
> However, I now have the problem that my Solaris 2.5.1 system crashes
> within 30 seconds to 2 minutes after starting a connection to ISP #2,
> while running rock-solid indefinitely while connected to ISP #1.  I suspect
> that I may need to revert to PPP 2.3.11 or that I may need to shut off
> some of the debugging code, hence my labeling this as a partial summary. ;-)
> 
> ---Rsk
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers