Wireshark-users: Re: [Wireshark-users] how to get ACK only in handshake
From: Guy Harris <[email protected]>
Date: Wed, 11 Jun 2008 14:14:30 -0700
On Jun 11, 2008, at 12:37 PM, Chong Zhang wrote:
I am trying to use twireshark/tcpdump to get only the TCP 3way handshake packets. There are two tapped interfaces, one for each direction, so the SYN- ACK and ACK packets are on different interfaces. I am wondering if there is way to only capture the ACK belonging to a handshake, rather than all ACK packets for the whole session.
It should be easy to capture only the SYN+ACK: $ man tcpdump expressionselects which packets will be dumped. If no expression is given, all packets on the net will be dumped. Otherwise, only
packets for which expression is `true' will be dumped. ... expr relop exprTrue if the relation holds, where relop is one of >, <, >=, <=, =, !=, and expr is an arithmetic expression com- posed of integer constants (expressed in standard C syn- tax), the normal binary operators [+, -, *, /, &, |, <<, >>], a length operator, and special packet data acces- sors. Note that all comparisons are unsigned, so that, for example, 0x80000000 and 0xffffffff are > 0. To access data inside the packet, use the following syntax:
proto [ expr : size ]Proto is one of ether, fddi, tr, wlan, ppp, slip, link, ip, arp, rarp, tcp, udp, icmp, ip6 or radio, and indi- cates the protocol layer for the index operation. (ether, fddi, wlan, tr, ppp, slip and link all refer to the link layer. radio refers to the "radio header" added to some 802.11 captures.) Note that tcp, udp and other upper-layer protocol types only apply to IPv4, not IPv6 (this will be fixed in the future). The byte offset, relative to the indicated protocol layer, is given by expr. Size is optional and indicates the number of bytes in the field of interest; it can be either one, two, or four, and defaults to one. The length operator, indi- cated by the keyword len, gives the length of the packet.
For example, `ether & 1 != 0' catches all multicast traffic. The expression `ip & 0xf != 5' catches all IPv4 packets with options. The expression `ip[6:2] & 0x1fff = 0' catches only unfragmented IPv4 datagrams and frag zero of fragmented IPv4 datagrams. This check is implicitly applied to the tcp and udp index operations. For instance, tcp always means the first byte of the TCP header, and never means the first byte of an inter-
vening fragment.Some offsets and field values may be expressed as names rather than as numeric values. The following protocol header field offsets are available: icmptype (ICMP type field), icmpcode (ICMP code field), and tcpflags (TCP
flags field).The following ICMP type field values are available: icmp- echoreply, icmp-unreach, icmp-sourcequench, icmp-redi- rect, icmp-echo, icmp-routeradvert, icmp- routersolicit, icmp-timxceed, icmp-paramprob, icmp-tstamp, icmp-tstam- preply, icmp-ireq, icmp-ireqreply, icmp- maskreq, icmp-
maskreply.The following TCP flags field values are available: tcp-
fin, tcp-syn, tcp-rst, tcp-push, tcp-ack, tcp-urg. ... EXAMPLES ...To print the start and end packets (the SYN and FIN packets) of each
TCP conversation that involves a non-local host.tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'
So a filter of tcp[tcpflags] & (tcp-syn|tcp-ack) == (tcp-syn|tcp-ack) would capture all packets with SYN and ACK set.The harder part is capturing the ACK responding to the second SYN (the one in the SYN+ACK). Once the connection is established, pretty much *all* packets have ACK set; the trick is to catch the ACK from the three-way handshake.
RFC 793 says: The synchronization requires each side to send it's own initial sequence number and to receive a confirmation of it in acknowledgment from the other side. Each side must also receive the other side's initial sequence number and send a confirming acknowledgment. 1) A --> B SYN my sequence number is X 2) A <-- B ACK your sequence number is X 3) A <-- B SYN my sequence number is Y 4) A --> B ACK your sequence number is Y Because steps 2 and 3 can be combined in a single message this is called the three way (or three message) handshake.(Note, by the way, that they say "steps 2 and 3 *can* be combined in a single message", so there's no guarantee that it really *is* a 3-way handshake; the connected-to host might send a SYN in one packet and an ACK in a subsequent packet. Other than to test the robustness of TCP implementations, however, I'm not sure there's a good reason to do that, so, in practice, it's probably always SYN followed by SYN+ACK followed by ACK.)
This means that there's no guarantee what the sequence number is in the last ACK of the handshake, so you can't use that - and, as capture filters are stateless, you can't check against the sequence number from an earlier packet.
Checking for an ACK with no payload will capture other ACKs - and there is, as far as I know, nothing that prevents the final ACK of a connection handshake from containing data.
So, unless I've missed something, there's no capture filter that will just capture the ACKs from the handshake.
- [Wireshark-users] how to get ACK only in handshake
- From: Chong Zhang
- [Wireshark-users] how to get ACK only in handshake
- Prev by Date: Re: [Wireshark-users] [Wireshark-announce] What is a good average for malformed packets
- Next by Date: [Wireshark-users] Newb question please
- Previous by thread: [Wireshark-users] how to get ACK only in handshake
- Next by thread: [Wireshark-users] Newb question please