Subject: Re: kernel ppp debug messages & com/tty weirdness
To: None <netbsd-help@netbsd.org>
From: Brian Ginsbach <ginsbach@spacestar.net>
List: netbsd-help
Date: 01/14/1999 22:02:31
Christos Zoulas wrote:
> In article <369D6B65.794BDF32@spacestar.net> ginsbach@spacestar.net (Brian Ginsbach) writes:
> >
> >Jan  4 22:44:34 jerrican /netbsd: ppp0: bad protocol 5050
> >Jan  4 22:44:34 jerrican /netbsd: ppp0: no compressor for [15 3 29], 3
> >Jan  4 22:44:34 jerrican /netbsd: ppp0: no compressor for [18 4 8], 4
> 
> Looks like your isp is printing some more ascii stuff after you login,
> and pppd is trying to negotiate with them.
> 0x50 = 'P'
> 
> So it could be that your isp is printing 'PPP session starting' or
> some crap like that. Just have chat swallow the next line...
> 

Yep.  The ISP is printing "PPP session from (xxx.xxx.xxx.xxx) to
xxx.xxx.xxx beginning...".  I told chat to swallow "beginning..."
and that got rid of the first one.  I'm still curious about the
second two.  I don't see any more ascii stuff coming from the ISP
after the "beginning..." (although it there does not seem to be
a LF or CR at the end of "beginning...".

> >But the kicker is that after upgrading to 1.3.2 I found that I
> >could not use the internal modem at all after the system booted
> >multiuser.  This system is a Zeos 486/33 with a Zoom 28.8 internal
> >modem as com3 since the Zeos has older UARTS.  I could use the
> >modem fine booting single user and either kermit or tip.  After
> >going multiuser it acted hung.  What I came to find out was that
> >the ttyflags command that is run at the start of the rc script
> >was hanging the port.  I had no such problem with 1.1, 1.2, or 1.2.1.
> >I now have the ttyflags stuff commented out.
> >
> >Now I thought that maybe it was setting some flag badly (or
> >changing the defaults that were there at boot) so I hacked
> >ttyflags to use the get ioctl instead of the set ioctl and
> >print out the results!  Woa! this hung the port too!  Now
> >I have not had much time to look at this one and looking at
> >the code did not provide any quick insights since this is
> >an area I'm not familiar with.
> 
> This is a thing that you should consider send-pr for. We need
> to examine and find what causes it. I hope your new kernel fixes it :-)
> 

I will after I look at it some more.  I have not tried with 1.3.3 yet.

Thanks for the help.

Brian
-- 
Brian Ginsbach                                  <ginsbach@spacestar.net>