[Guy Harris <guy@xxxxxxxxxxxx>]

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

        expression
              selects  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 expr
                     True 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[0] & 1 != 0'  catches  all   
multicast
                     traffic.   The  expression `ip[0] & 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[0] 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.