Ethereal-users: Re: [Ethereal-users] Capture filters on 802.1Q links...

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, 14 Dec 2001 16:33:47 -0800 (PST)
> Apparently, capturing on an 802.1 link is a little stranger than capturing
> on an un-tagged link.  Basically, I have a Linux box set up with Ethereal.
> (RedHat 7.2, Ethereal 0.8.20, which has proven to be a bit unstable, I might
> add).

Which of those has proven to be a bit unstable - RH 7.2, or Ethereal
0.8.20, or both?

There's not much we can do about RH 7.2, of course - and there's not
much we can do about Ethereal, either, unless we are told what the
symptoms of the instability are.

> Capture filters do not appear to work properly.  I believe it's
> because I'm capturing on a tagged link.
> 
> Is this a known problem?  Are there workaround?  Do I need to have 802.1Q
> support compiled into the kernel and/or active on the interface for filters
> to work?

Is the box on which you're sniffing a member of a VLAN?  Or are you just
using it to passively sniff traffic on that VLAN?

If you're just using to passively sniff traffic on that VLAN, you'd need
libpcap 0.6 or later - 0.6 being the tcpdump.org release number, so it
*should* be reported by "ethereal -v" or "tethereal -v".  With that
version of libpcap, you can specify "vlan" in a capture filter to match
only 802.1Q VLAN packets, or "vlan [vlan ID]" to match only 802.1Q VLAN
packets for a particular VLAN.

As the tcpdump 3.6 man page says, "Note that the first vlan keyword
encountered in expression changes the decoding offsets for the remainder
of expression on the assumption that the packet is a VLAN packet".  If
you *don't* put a "vlan" keyword into the expression, the remainder of
the expression will assume that the packets are ordinary Ethernet
packets, *not* VLAN packets.

If, however, the machine *is* a member of a VLAN, then, unless you have
a networking card that does all the 802.1Q work itself, presenting a
fake Ethernet interface or interfaces to the host (in which case I'd
assume that packet sniffers would Just Work, and would have no idea why
not if they didn't), I'd assume you'd need to have 802.1Q support
compiled into the kernel for VLANs to work *at all*.

If you do have it in the kernel, the page at

	http://scry.wanfear.com/~greear/vlan.html

says:

	Features

     Now found in Linus' Linux kernel, as of version 2.4.14 
     Implements 802.1Q VLAN spec. 

		...

     Optional header-reordering, to make the VLAN interface look JUST
     LIKE an Ethernet interface. This fixes some problems with DHCPd and
     anything else that uses a SOCK_PACKET socket.  Default setting is
     off, which works for every other protocol I know about, and is
     slightly faster.

		...

     Release 1.5 (gz)   For Kernel: 2.4.12-pre5   October 22, 2001:

		...

          Add relatively large change by Nick Eggelston that makes VLAN
          devices more transparent to tools like tcpdump and other raw packet
          snoopers. This will only be enabled when the
          REORDER_HDR flag is set.

I suspect he meant to say "anything else that uses a SOCK_PACKET or
PF_PACKET socket".  In any case, anything that uses libpcap uses
PF_PACKET or SOCK_PACKET sockets; this includes tcpdump, and Ethereal,
and a bunch of other software that does packet capture.

Therefore, if you're trying to sniff on a VLAN device rather than on the
network device for the raw Ethernet, you may have to turn that feature
on.  I don't run Linux on any 802.1Q-ified networks, so I can't help you
on that.