Wireshark · Ethereal-users: RE: [Ethereal-users] Capture filters on 802.1Q links...

["McNutt, Justin M." <McNuttJ@xxxxxxxxxxxx>]

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

Ethereal 0.8.20 on RedHat 7.2, specifically.  We have several RedHat 7.2
boxen that themselves appear to be stable enough.  I also have several
machines running Ethereal 0.8.20 which are also stable.

The specific problem is that when I do a capture on the RedHat box on an
802.1Q link and then try to use 'ip.addr eq a.b.c.d' (display filter),
Ethereal aborts.  Transfer the capture file to a Slackware box and do the
same display filter (same version of Ethereal) and it works fine.

I don't expect some magic answer.  :-)  What other information is pertinent
here?

> 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?

Passive.

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

There was another bug in libpcap 0.6.2 that caused packet filters to be
applied only after a certain amount of time (<1s) that causes some weirdness
on a highly-utilized link.  Has that bug been repaired?

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

Hmmm...  So what would be the syntax for "vlan any"?

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

I don't believe it's compiled into the kernel, but in this case I don't
believe I need it.

The ethereal box(en) have a management interface (eth0) and two capture
interfaces (eth1 and eth2).  Eth1 and eth2 get 802.1Q traffic steered to
them for capture and analysis, but don't need to actually function on the
network.  Eth0 is the opposite.

> If you do have it in the kernel, the page at
> 
> 	http://scry.wanfear.com/~greear/vlan.html

[snip]

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

Hmmm... that's pretty cool.  It doesn't apply here, but thanks for
mentioning it.  I'll probably want to use that in the future (on other
machines).

In this case, though, I don't have 802.1Q enabled on those interfaces, nor
have I enabled any kind of re-ordering in the kernel.  Ethereal/libpcap is
getting the raw data.

Incidentally, I just checked my version of libpcap.  I have libpcap 0.6.2.
Also:

tethereal 0.8.20, with GLib 1.2.10, with libpcap 0.6, with libz 1.1.3, with
UCD SNMP 4.2.1

I will try that 'vlan' keyword and see what I get, but it doesn't help the
abort during decode.  What other libraries are pertinent to *that* problem?

--J