What compiler did you use (this is primarily just a curiosity item)
> that the tcp code is fine. The lack of a problem over
> ethernet'd ppp suggests that the ppp code is fine. This
> leaves the serial code to take the blame, though likely
> in a complicated interaction.
PPP frames have their own CRC's. Are you seeing IP or PPP CRC
errors.
> I would reocmmend checknig boundary conditions on the
> checksum code, it seems impossible that 327 packets in
This is the same checksum code you say works for ethernet, for
ppp over ethernet and for everything else. Some background here
TCP/IP checksums are extremely simplistic (that doesnt mean you
cant misimplement one, in fact getting the end around carry causes carry
case wrong is common in OS's. The IP checksum is simply a sum with carry
wrap over the header, and the tcp one over the tcp data/header and bits of
IP header. All of them are simple and device independant.
Also as regards the 327 packets - the ip ident of an ip header changes each
frame. The tcp header and thus tcp checksum might be constant however.
> [2] 3k checksums resulting in about 0.1 kernel
> messages each, makes a sizable chunk of syslog. Luckily
> they compress well.
Right - you know 2.0.x doesnt print checksum messages, and
I dont know if mklinux does either.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/