In article <369D6B65.794BDF32@spacestar.net> ginsbach@spacestar.net (Brian Ginsbach) writes:
>After several years of connecting to my ISP using kermit to
>dial and then starting pppd, I've finally taken the time to set
>up a chat script.  This is definitely more convient (when the ISP
>is not busy)!  But when I do this I get the following messages
>from the kernel ppp device driver.
>
>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...

>The first is from ppp_tty.c, while the second two are from if_ppp.c.
>Just what exactly do they mean?  I get them every time I
>use the pppd/chat method to establish a ppp connection.  But if
>I use kermit to dial and then start pppd after I have logged
>in and the remote has already sent a bunch of "ppp stuff", I
>don't get these messages.
>
>I have also gotten these messages; after which my connection
>was dropped.  (I've only seen this once but again only with
>the pppd/chat combo as far as I know).
>
>Jan  6 21:23:18 jerrican /netbsd: ppp0: bad fcs 66f0
>Jan  6 21:23:42 jerrican /netbsd: ppp0: bad fcs a490
>
>These are also from ppp_tty.c.  Again what do they mean?

This happens when you drop a packet. It is printed only when
you have kernel debugging turned on on the ppp interface.

>I have another problem that may or may not be related to this.
>After waiting almost a year to upgrade from 1.2.1 to 1.3.2
>(hey things were stable and worked and other things were more
>pressing), I upgraded to 1.3.2 at the end of November.
>(I'm currently in the process of upgrading to 1.3.3 - rebooting
>with 1.3.3 kernel after I send this.)
>
>My 1.3.2 upgrade has not be exactly smooth. It has been by far
>the roughest upgrade I've made (or can remember).  I seemed to
>hit quite a few surprises like a changed eithernet driver from
>ed -> we;  new if_config.xxx instead of hostname.xxx; routed
>doesn't work with pppd the same as it did with 1.2.1 and earlier
>-- who knew I didn't really need to be running it since I had
>been running it since 0.9 days!); removal of 
>route add $hostname localhost from network startup; etc....  
>I think a better job of  describing changes that will affect
>upgraders needs to be done.

Yeah, some of the problems were discovered but not documented in
the upgrade process. The routed change has been fixed recently so
you can now run again routed + pppd, the hostname -> ifconfig.???
came with the new startup scripts. 

>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 :-)

>After long winded explaination, he gets to the point.  Could
>this be releated to the ppp problems above?  Or is it a new
>problem?  I tend to think it is a new one but maybe I have
>something configured wrong.  I did notice that the com driver
>has changed quite a bit since 1.2.1.  Below is the dmesg output.

Yeah, the com driver changed quite a lot, but it should have much
better performance now thanks to Charles' work. It should not be
causing you those problems though.

christos