3
votes

I need to capture packets with length equal to 16 bytes

The closer i came with is this:

tcpdump -ni lo -ttt dst port 1337 and greater 16

if I add other filters to match my will like :

tcpdump -ni lo -ttt dst port 1337 and greater 16 and not greater 17
tcpdump -ni lo -ttt dst port 1337 and \(greater 16 and not greater 17\)
tcpdump -ni lo -ttt dst port 1337 and greater 16 and less 16

It just doesn't show any packets at all.

Althought, using :

tcpdump -ni lo -ttt dst port 1337 and less 16

doesn't seem to work neither, i'm actually wandering if the less filter works...

Any help is welcome :)

1
I think the length includes all the headers, not just the TCP data. I don't think you're likely to see any packets that are only 16 bytes. A TCP segment in an Ethernet frame has at 18 bytes of Ethernet header and trailer, and at least 16 bytes of TCP header (usually more because of TCP options).Barmar
I should precise that tcpdump sees the packets i send as packets with 16 bytes length. That's why i want to filter them using the packet length. I guess he removes the usual TCP layer from the total length no ? Or is it showing an unrelated length ?naab
Yes, tcpdump does lots of decoding before it displays things to you, and displays protocol-specific data. But the filters are implemented by a lower-level library that doesn't know so much about protocols.Barmar
You're right, my packet length is actually at 68 and not 16 like I thought it was. Thank you a lot.naab

1 Answers

3
votes

As Barry Margolin indicated, the greater operator checks the length of the entire packet, including all headers. 16 bytes of TCP payload plus 20 bytes of TCP header (that's the minimum TCP header length, without options) plus 20 bytes of IPv4 header (that's the minimum IPv4 header length, without options) plus 14 bytes of Ethernet header, for example, is 70 bytes.

I'm guessing from "lo" that you're capturing on Linux and capturing on the loopback interface, in which case packets have a (fake) Ethernet header.

68 bytes was the default snapshot length in older versions of tcpdump, when built without IPv6 support, so perhaps the length being reported as 68 is the captured length, with the last 2 bytes being cut off. Try running tcpdump with the flags -o 0 (unless it's a really old version of tcpdump, a snapshot length of 0 will mean "set the snapshot length really high so that packets don't get cut off).