Guy Harris wrote:
On Jan 18, 2005, at 7:18 AM, Jeff Morriss wrote:
I've been looking at a weird capture behavior on Linux (Redhat Enterprise Linux with kernel 2.4.21-27.0.1.ELsmp and libpcap libpcap-0.7.2-7.E3.2 though I've also tried tcpdump 3.8.3 and libpcap 0.8.3).
We have an SCTP implementation that runs in the kernel; as one would expect, it lives above IP (basically with some SOCK_RAW's).
What's weird is that if I run 'tcpdump' or 'ethereal' and capture some (IPv4) SCTP packets, quite a few (but not all) of the received packets have an invalid (set to 0) SCTP checksum. The checksum is correct on the sending side (as shown in 'tcpdump' or 'ethereal') and they're valid on the wire (as seen by a Solaris machine which was connected via a hub).
My (feeble) understanding of the way capturing works tells me our SCTP can't be the problem here (since it's above IP and capturing is done at or below IP) but then I also don't see how the capturing system can be broken since it works for TCP and UDP.
Does anyone have any thoughts on what I should be looking at (Linux kernel, libpcap, or our SCTP)?
Your SCTP isn't modifying the skbuffs in-place, is it? I think some versions of AppleTalk, Token Ring, and NFS implementations for Linux do so, and, in all cases, this results in bogus packets being captured (Ethereal has code to compensate for the first two; the third cannot, as I remember, be worked around).
Hmmm, I think I see what you mean: it's possible to have 2 references to a given sk_buff (or its data). (I "grew up" in STREAMS where I'm pretty sure that's not possible.) I'll take a look--thanks for the pointer!
- This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
