[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tcpdump-workers
Subject:    Re: [tcpdump-workers] Endianness issue with selecting non-fragmented packets
From:       Guy Harris <gharris () sonic ! net>
Date:       2018-07-27 20:32:54
Message-ID: B7CFD8F0-192D-4537-8B93-6572F126867A () sonic ! net
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]