Ethereal-users: Re: [Ethereal-users] filter question

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Fri, 13 Dec 2002 12:04:47 -0800
On Fri, Dec 13, 2002 at 01:11:08PM -0500, sspencer@xxxxxxxxxx wrote:
> How do I build a filter with the following criteria.
>  
> Filter a capture on a specified port , but only if there is a reset.

I.e., you want to see all RST packets sent to or from a particular
TCP port?

If you're talking about a display filter, let's check out the "Filter
Expression" dialog box, as popped up by the "Add Expression..." button
in the "Display Filter" dialog box popped up by the "Filter:" button on
the bottom of the display.

If we open up "TCP" in the "Field name" part of the "Filter Expression"
dialog box, it has a "Source or Destination Port" item; if we select
that, choose "==" as the operator, and supply 666 as the port number,
the expression is

	tcp.port == 666

It also has a "Reset" item; if we select that, and choose the "=="
operator, and select "Set" in the "Value" setion, we get

	tcp.flags.reset == 1

If we want to test for both, we'd do

	tcp.port == 666 && tcp.flags.reset == 1

However, if you're talking about a capture filter (i.e., capture only
RSTs to or from that port), it's different.

That is a bit of a pain with older versions of libpcap; the port part is
easy - "tcp port 666" - but the RST part has to be done by hand, using
the

	  expr relop expr
	       True if the relation holds, where relop is one  of
	       >,  <,  >=,  <=,	 =, !=,	and expr is an arithmetic
	       expression   composed   of    integer	constants
	       (expressed  in  standard	 C  syntax),  the  normal
	       binary operators	[+, -, *,  /,  &,  |],	a  length
	       operator,  and  special packet data accessors.  To
	       access data inside the packet, use  the	following
	       syntax:
		    proto [ expr : size	]
	       Proto is	one of ether, fddi, ip,	arp,  rarp,  tcp,
	       udp, or icmp, and indicates the protocol	layer for
	       the index operation.  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,  indicated by the keyword len,	gives the
	       length of the packet.

	       For example, `ether[0] &	1 != 0'	catches	all  mul-
	       ticast traffic.	The expression `ip[0] &	0xf != 5'
	       catches all IP packets with options.  The  expres-
	       sion  `ip[6:2]  & 0x1fff	= 0' catches only unfrag-
	       mented  datagrams  and  frag  zero  of  fragmented
	       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
	       intervening fragment.

feature.

The control bits are in the 13th byte of the TCP header, and the RST bit
is 0x04 in that byte; from RFC 793:

    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            TCP Header Format

          Note that one tick mark represents one bit position.

so that'd be
	
	tcp[13] & 0x04 != 0

and the combination expression would be

	tcp port 666 and (tcp[13] & 0x04 != 0)

Newer versions of libpcap let you do that a bit more nicely:

	       Some offsets and	field values may be expressed  as
	       names  rather than as numeric values.  The follow-
	       ing 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  avail-
	       able:	icmp-echoreply,	   icmp-unreach,    icmp-
	       sourcequench,  icmp-redirect,   icmp-echo,   icmp-
	       routeradvert,  icmp-routersolicit,  icmp-timxceed,
	       icmp-paramprob,	 icmp-tstamp,	icmp-tstampreply,
	       icmp-ireq,   icmp-ireqreply,  icmp-maskreq,  icmp-
	       maskreply.

	       The following TCP flags field  values  are  avail-
	       able:  tcp-fin,	tcp-syn,  tcp-rst, tcp-push, tcp-
	       push, tcp-ack, tcp-urg.

so if you have a newer version, it'd be

	tcp port 666 and tcp-rst

On UNIX, you'd have to do "man tcpdump" to see whether it documents
"tcp-rst".  On Windows, I think only the 3.0 alpha version of WinPcap
supports "tcp-rst", as I think 2.3 is based on an older version - the
WinDump man page at

	http://windump.polito.it/docs/manual.htm

doesn't mention tcp-rst.