Re: [Ethereal-users] TCP statistics and capture filter fails for VLAN tagged frames (0 .9.9 windows)

[Guy Harris <guy@xxxxxxxxxx>]

On Mon, Feb 03, 2003 at 09:43:19PM +0100, Mads Nielsen (DXD) wrote:
> We often trace VLAN tagged frames (802.1Q) and noticed that the TCP
> stream analysis not is working (it says: "selected packet is not a TCP
> segment").  I guess it "forgets" to skip the VLAN tag when checking the
> contents of the packet.

The TCP stream analysis code has hardwired into it the notion that IP is
running directly atop either Ethernet or PPP, with no intervening
protocols - such as 802.1Q.

It could probably be rewritten to use the new "tap" mechanism, as
there's now a tap in the TCP dissector; that would make it independent
of the link layer.  (It would also go part of the way to making it
independent of the network layer, so it could work atop IPv6 as well,
although there's some code in it that "knows" that network-layer
addresses are IPv4 addresses - see, for example, "compare_headers()" -
so that would need to change as well.)

> Also the capture filter seems no longer to support "vlan" keyword
> (maybe somewhere in the BPF engine).

That's an issue of the version of libpcap you're using, not an issue of
Ethereal - the capture filter code is part of libpcap.  Support for
"vlan" first appeared in libpcap 0.6 (or 0.6.1, whatever the first 0.6.x
release was called).

If you're using some flavor of UNIX that comes with libpcap, you might
have to replace libpcap with a newer version.  Note that most if not all
of those flavors provide libpcap as a shared library, so you might have
to re-link Ethereal after configuring it to link with the version you
installed - the tcpdump.org version doesn't build shared libraries
(people occasionally contribute patches for that; unfortunately, the
patches they contributed are quick hacks that only work on systems using
the GNU linker, they're not more portable versions using libtool, so
those patches get discarded).

If you're using some flavor of UNIX that *doesn't* come with libpcap,
make sure the version on your system is 0.6 or later - the current
version from tcpdump.org is 0.7.1.

If you're using Windows, WinPcap 2.3 is based on libpcap 0.6.2, so it
should support "vlan"; at least some earlier versions were based on
pre-0.6 versions of libpcap, so they don't support "vlan".

> Previously (some versions ago) it was possible to write "vlan ..." to
> force it to jump over any VLAN header.

Your earlier version of Ethereal was using a different version of
libpcap, then; there is no BPF compiler code in Ethereal itself, so a
change of Ethereal version can't change the BPF compiler.

> I seem to remember that the Berkeley Packet Filter in vxworks
> contained "something" that allows
> 
> to make LOADs relative to headerLen+k, e.g.:
>     case BPF_LD|BPF_B|BPF_ABS|BPF_HLEN:
>       return "LD_B:a=[hlen+k]";

The VxWorks Network 5.4 Programmer's Guide at

	http://www.roe.ac.uk/atc/projects/vista/background/phase_b/software/VxWorks/VxWorks_5.4_Network_Programmer's_Guide.pdf

says:

	3.2.2 Additional Filter Syntax

	     Two additional statements are provided that augment the standard
	     BPF filter syntax.  Each can be used in a load context.  The
	     BPF_TYPE alias finds the type of link level frame and can be
	     used in statements such as:

		BPF_STMT(BPF_LD+BPF_TYPE,0) /* Save lltype in accumulator */

	     The BPF_HLEN alias determines the header length, independently
	     of the variety of link layer header in use.  It can be used in
	     statements like:

		BPF_STMT(BPF_LD+BPF_H+BPF_ABS+BPF_HLEN, 6) /* IP fragment field */

which is interesting, but not necessary to implement "vlan" as it's
implemented in libpcap from tcpdump.org; "vlan" causes everything after
it in the capture expression to assume VLAN tagged frames, so the
link-layer header length is still fixed, it just includes the VLAN
header.