On Wed, Jun 27, 2001 at 01:03:13AM -0400, Joe Tomasone wrote:
> I don't have Ethereal handy to look at presently, but if I recall
> right, you can specify capture filters on the command line.
Yes.
> If so, you would use a filter like this:
>
> (wlan.fc.type eq 0) && (wlan.fc.subtype eq 8)
That's a display filter. Those do not work as capture filters; they
only work as display filters to show particular packets in a set of
packets you've captured.
There is currently no support in libpcap for filter expressions that
refer to 802.11 packet types; given that both tcpdump and Ethereal use
libpcap to capture packets, and to compile filter expressions, this
means there's no simple expression to look for beacon packets.
However, libpcap filter expressions compile into an interpreted "machine
language" that knows nothing of Ethernet/FDDI/Token Ring/ATM/802.11/...
or IP or TCP or UDP or... - it just does loads from the packet data -
and the libpcap expression language does let you construct filter
expressions that access particular bytes in the header.
The syntax for capture filters is documented in the tcpdump man page;
the particular expression type that would come into play here is:
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 proto-
col 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
multicast traffic. The expression `ip[0] &
0xf != 5' catches all IP packets with
options. The expression `ip[6:2] & 0x1fff =
0' catches only unfragmented 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.
"ether" and "fddi" and "ppp" and "slip" (and "tr" in current versions of
libpcap), as well as "link", all refer to the link-layer header; you can
use any of them to access fields in the 802.11 link-layer header. I'll
use "link" because 802.11 is neither Ethernet nor FDDI nor PPP nor SLIP
nor Token Ring.
The first byte of the frame header contains the Protocol Version, Type,
and Subtype fields; Type should be 0 and Subtype should be 8 - Protocol
Version could, in theory, be ignored, but 802.11-1997 says it should be
0.
This means the first byte of the frame should be 0x80.
Therefore, try the capture filter expression
link[0] == 0x80