tcpdump mailing list archives
Re: Endianness issue with selecting non-fragmented packets
From: Guy Harris <gharris () sonic net>
Date: Fri, 27 Jul 2018 13:32:54 -0700
On Jul 27, 2018, at 11:21 AM, Richard Clayton <richard () highwayman com> wrote:
I am running tcpdump under FreeBSD 11 on an AMD64. I have a file containing UDP packets and IP fragments. This command (the filter corresponds to the information on the man page): tcpdump -r file.pcap "(ip[6:2] & 0x1FFF = 0)" unexpectedly prints all of the packets :-( The command: tcpdump -r file.pcap "(ip[6:2] & 0xFF1F = 0)" skips all the fragments and only prints complete packets. This is clearly an endianness issue ... but shouldn't tcpdump/libpcap be hiding that from me ?
Yes. The BPF code generated for that expression is # load 2-byte value at offset 12, i.e. Ethernet type (000) ldh [12] # Compare for equality against 0x800, i.e. IPv4; if equal, # go to instruction 002, otherwise go to instruction 005. (001) jeq #0x800 jt 2 jf 5 # Load 2-byte value at offset 20, i.e. 14+6, so at an offset # of 6 from the beginning of the Ethernet payload, so at # an offset of 6 from the beginning of the IPv4 header, # so the flags and fragment offset. (002) ldh [20] # Test bits 0x1fff; if any are set, go to instruction 0005, # and if they're all clear, go to instruction 0004. (003) jset #0x1fff jt 5 jf 4 # Return the snapshot length, meaning "accept the packet # and return that many bytes of packet data". (004) ret #65535 # Return 0, meaning "reject the packet". (005) ret #0 The load instructions are all loading the data as big-endian, i.e. they don't load a machine word in its native byte order, they load it as if it were in network byte order, so the same value should be loaded on a little-endian x86 machine like yours or a big-endian machine such as a SPARC/{most}PowerPC/{S/390, z/Architecture} machine. And I tested its on my x86-64 Mac, using the tip-of-the-1.9-branch libpcap and the tip-of-the-4.9-branch tcpdump, with a capture file with some fragmented IP packets, and the filter "(ip[6:2] & 0x1FFF = 0)" rejected the fragmented packets. The filter "(ip[6:2] & 0xFF1F = 0)" rejected *all* the packets. Nothing was done to libpcap or tcpdump since the 1.9.0/4.9.2 releases to affect that. _______________________________________________ tcpdump-workers mailing list tcpdump-workers () lists tcpdump org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Current thread:
- Endianness issue with selecting non-fragmented packets Richard Clayton (Jul 27)
- Re: Endianness issue with selecting non-fragmented packets Guy Harris (Jul 27)