On Jul 13, 2004, at 11:51 AM, Guy Harris wrote:
whereas the traffic from 62.225.140.214 to 217.234.111.121 has
Linux cooked capture IP with a protocol type of IP-inside-IP IP (with a bogus version number of 3 and a bogus header length of 8)
The second capture is similar - and in both cases, the packets with a problem have a bad IP header checksum. The packets are being received by the host doing the capturing, so that's presumably not a result of checksum offloading. I suspect that the Linux networking stack is "helpfully" rewriting the headers to have IPIP rather than ESP as the protocol, and not changing the checksum (it'd be interesting to see whether changing the protocol field back to 0x32 makes the checksum correct), as I'd suggested in my previous message.
It might be that the Linux IPsec implementation is doing that. Several pieces of Linux networking code appear to have the annoying habit of updating skbuffs in place without somehow arranging to do a copy-on-write if the traffic is being handed to a PF_PACKET socket, so that tcpdump and Ethereal and other packet capture applications don't see packets as they were received by the machine, they see them as modified in-place by the networking stack. I think that's been seen for the Token Ring, AppleTalk, and NFS code (there are workarounds in Ethereal for Token Ring and AppleTalk; there is, as I remember, no workaround even *possible* for NFS); IPsec might be another offender here.
- This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
