To diagnose this problem, yes I do. Disks are big, modems are slow.
> The CCP et.al. packets you see in your PPP
> log when you enable debug are never seen by the TCP/IP stack, they are
> passed directly between the kernel driver and pppd. Although they have
> their own checksum (the PPP link layer crc16) which is checked, packets
> that fail the csum test are properly thrown away without logging them
> (except for device error counter shown by ifconfig).
The packets causing problems are passing the crc16 just fine, as well as
the IP header checksum. Only the TCPv4 checksum is faulty (plus
misrouting etc.). They are not bit errors, so they indicate a serious
problem somewhere. Normal networks do not have _any_ IP or TCP checksum
errors because, as you know, most link layers implement a CRC or similar.
> Also it is not the full picture, the current kernel only prints the
> debugging message when the UDP/TCP checksum fails - for ICMP checksums
> (except during masquerading) or IP headers there is only a counter.
Good point. I've just looked at my /proc/net/snmp, and it looks like
Demon are sending me some packets with faulty IP headers too. But they
were never logged.
With VJ header compression reenabled, some packets fail the PPP CRC16
too. But some still get through and have faulty TCPv4 checksums. Ho hum.
> > 2. It is useful to see which IP addresses are causing errors.
>
> If you want that write a user mode daemon - it is a trivial modification
> of tcpdump.
It is? I've never found a tcpdump that works with PPP and current
kernels. Anyway, having seen how many errors I've missed because
they're not logged (the faulty IP headers), I'll be looking at the SNMP
data in future.
-- Jamie
-
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/