Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Capture filter for MAC addresses

From: "Frank Bulk" <frnkblk@xxxxxxxxx>
Date: Fri, 25 Jan 2008 23:33:55 -0600
Thanks, that helps a lot.  

Now, to take it one step farther, I need to apply that capture filter to the
client field (labeled in the display filter 'bootp.hw.mac_addr').  
Is that possible in a capture filter?  And if you're going to ask if the
offset from the start of the packet is consistent, it's not.

Basically what I'm trying to do here is capture the DHCP packets for a
certain brand of devices in the field, but they're behind a DHCP relay so I
can't use the frame's hardware MAC address because it's always the DHCP
relay device.

Frank

-----Original Message-----
From: Guy Harris [mailto:guy@xxxxxxxxxxxx] 
Sent: Friday, January 25, 2008 8:22 PM
To: frnkblk@xxxxxxxxx; Community support list for Wireshark
Subject: Re: [Wireshark-users] Capture filter for MAC addresses


On Jan 25, 2008, at 4:24 PM, Frank Bulk wrote:

> I've looked at the wiki page (http://wiki.wireshark.org/Ethernet)
> but it's
> not entirely clear to me how I would capture the traffic from all
> those
> devices that share the same OUI.
>
> For example, if the OUI of interest was Cisco (00:1b:0d), I have
> tried this:
>       ether[0:4]=0x001B0D
> but it didn't seem to work.  I suspect I don't full understand the
> usage of
> the square brackets, and perhaps I need to use a mask of some kind.

Capture filters can only test 1-byte, 2-byte, or 4-byte fields:

$ 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.

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

                ...

               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.

so, yes, you'd have to either

        1) do "ether[0] == 0x00 and ether[1] == 0x1B and ether[2] == 0x0D"

or

        2) use a mask - "(ether[0:4] & 0xFFFFFF00) == 0x001B0D00"

(the latter generates less BPF code, and would run a little faster).