On Fri, 27 Jun 1997, Ken Nakata wrote:

> On Fri, 27 Jun 1997 15:05:35 -0500 (CDT),
> "David A. Gatwood" <marsmail@globegate.utm.edu> wrote:
> > whenever I connect the PB145 (NetBSD) to the 7100 (MkLinux), I get
> > errors....  Initially, I was getting problems with vjc compression,
> > which I turned off, leaving only one that I can't figure out....
> > ppp0: bad fcs 71a2 (twice) followed by a couple with da10, etc.
> 
> Fcs stands for Frame Check Sequence.  A fancy name for a CRC.  So, I'd
> guess the PB can't quite keep up with the data rate thus drops a char
> here and there, making discripancies between calculated and received
> fcs.

Makes sense, though it looks like it's dropping a lot more than a
character here and there....  An nfs session ground for a good 5 minutes
before the laptop crashed with a vnode error, and didn't even write a
single block to disk, so I'm guessing it's getting some huge losses.
Tried tcpdump, indicates the kernel's getting every packet....  Dunno.  I
guess that's after the ppp driver thumbs its nose and asks for a hundred
retransmissions....

> > I know I can change the syslogd.conf to trash these or redirect to a
> > file, but what's causing these errors, and is there a way to keep
> > the errors from happening, rather than just masking the symptoms?
> 
> Make connection at a slower speed, like 19200 or something.  Or, fix

Ironically, that was at 19,200.  I just slowed down to 9600, and it seems
even worse.  I'm even getting those errors at... get this... 1200 baud! 
:-) I also notice an occasional packet too big message.  Since both should
have default mtu's/mru's of 1500 bytes, I'm a little confused about that.

> the linux serial driver so that it'll do hand-shake properly ;-)

What's odd is, it seems to happen a second or two after a large amount of
data flows across as well, not just during.  The weirdest one is whan I've
logged off and it gives me a couple of those errors ten or fifteen seconds
later....  Weird.

BTW, why won't pppd die on its own?  I have to send it two signals (and
the second one seems to have to be kill -INT) to get it to die after the
connection's already closed.  It's getting stuck in tcsetattr() and maybe
some other place as well, WCHAN from a ps -axl yields "ttyout".


Ideas?
David

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/CC/FA/H/L/MC/M/MU/PA/TW d-@ s:>- a-- C++++>$ UBLAS*++++>$
P+?>$ L+++>$ !E--- W+++>$ N++(+++)>+++$ !o? K-? !w--- !O
M++>$ !V-- PS+>$ !PE- Y+>$ PGP+>$ t+++>$ 5+>++++$ !X- !R tv+>$
b++>$ !DI !D- G++(+++)>$ e>++++ h--! r--- !y-
------END GEEK CODE BLOCK------