Wireshark · Wireshark-users: Re: [Wireshark-users] capture filter

[Guy Harris <guy@xxxxxxxxxxxx>]

On Sep 28, 2011, at 7:18 PM, Andrej van der Zee wrote:

>> IPv4
>> ip[12:4] != ip[16:4]
> 
> This seems to work indeed.
> 
> Should I read this as "4 bytes from offset 12 != 4 bytes from offset
> 16", relative to the start of the IP-header?

Yes:

$ man pcap-filter
PCAP-FILTER(7)                                                  PCAP-FILTER(7)



NAME
       pcap-filter - packet filter syntax

DESCRIPTION
       pcap_compile()  is used to compile a string into a filter program.  The
       resulting filter program can then be applied to some stream of  packets
       to  determine  which packets will be supplied to pcap_loop(), pcap_dis-
       patch(), pcap_next(), or pcap_next_ex().

       The filter expression consists of one or more  primitives.   Primitives
       usually consist of an id (name or number) preceded by one or more qual-
       ifiers.  There are three different kinds of qualifier:

		...

       Allowable primitives are:

		...

       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.  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 indicates  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, rela-
              tive 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 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
              intervening 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-echore-
              ply,  icmp-unreach, icmp-sourcequench, icmp-redirect, icmp-echo,
              icmp-routeradvert,  icmp-routersolicit,   icmp-timxceed,   icmp-
              paramprob,  icmp-tstamp,  icmp-tstampreply, icmp-ireq, icmp-ire-
              qreply, icmp-maskreq, icmp-maskreply.

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

(On UN*Xes with pre-1.0 libpcaps, do "man tcpdump" and scan through it for that information.)