On Nov 9, 2005, at 9:59 AM, Rick Jones wrote:
Vossie wrote:
Sorry guys. I was typing too fast. I mean HTTP packets (that
transfer the
data) and not the TCP ACK's :-)
Looking at a stream of HTTP carried in TCP segments without looking
at the ACKs seems a bit odd, but if you really don't want to see
the bare ACKs, you could probably filter on packet size - a bare
ACK would just be the TCP, IP and link-level headers.
...which might be variable-length.
A TCP ACK-only packet (which is presumably what he wants to filter
out, as he probably wants to see packets that contain HTTP data *and*
an ACK) would be one where the IP total length was equal to the sum
of the IP header length and the TCP header length, so that you have
only IP and TCP headers, no TCP payload.
I.e.:
tcp && (ip[2:2] > (((ip[0]&0xF) + (tcp[12] >> 4)) << 2))
"ip[2:2]" is the 2-octet big-endian quantity at an offset of 2 octets
from the beginning of the IP header; that's the "total length" field.
"ip[0]" is the version/header length octet at the beginning of the
header; "ip[0]&0xF" masks out the version, leaving only the IP header
length. "tcp[12]" is the octet at an offset of 12 octets from the
beginning of the TCP header; that has the TCP header length in the
upper 4 bits, so we shift it right 4 bits. We add those two to get
the sum of the lengths of the IP and TCP headers. Both of those
lengths are in units of 4 octets, but the IP total length is in units
of octets, so we have to multiply the sum of the lengths by 4 before
comparing them - shifting it left by 2 is a cheap way of doing that.
"tcp &&" is necessary because, for whatever reason, "tcp[12]" doesn't
add the "is this packet TCP?" check you might expect it to add.
Note that libpcap doesn't support this for IPv6, just IPv4.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
