On Jul 27, 2018, at 11:21 AM, Richard Clayton <rich...@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
