Re: vlan tagged packets and libpcap breakage

[Daniel Borkmann <danborkmann () iogearbox net>]

On Sat, Nov 17, 2012 at 11:14 PM, Michael Richardson <mcr () sandelman ca> wrote:
> Thank you for this reply.
>
> > > > > > "Eric" == Eric W Biederman <ebiederm () xmission com> writes:
>     Eric> I don't see any need to add any kernel code to allow checking
>     Eric> if vlan tags are stripped.  Vlan headers are stripped on all
>     Eric> kernel interfaces today.  Vlan headers have been stripped on
>     Eric> all but a handful of software interfaces for 6+ years.  For
>     Eric> all kernels if the vlan header is stripped it is reported in
>     Eric> the auxdata, upon packet reception.  Careful code should also
>     Eric> look for TP_STATUS_VLAN_VALID which allows for distinguishing
>     Eric> a striped vlan header of 0 from no vlan header.
>
> I can regularly see vlan tags on raw dumps from the untagged ("eth0")
> today, running 3.2 (debian stable):
>
> obiwan-[~] mcr 4848 %sudo tcpdump -i eth0 -n -p -e | grep -i vlan
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 17:05:15.404909 38:60:77:38:e6:47 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 3800, p 0, 
> ethertype ARP, Request who-has 172.30.42.1 tell 172.30.42.11, length 28
>
> So, I'm curious about the statement that vlan tags have been stripped
> for some time, because I don't see them stripped today.  My desktop has
> an Intel 82579V NIC in it...

Speaking of netsniff-ng where we don't reconstruct VLAN headers, users
have reported that depending on the NIC/driver resp. ethtool setting,
they can come in stripped or not (in the pf_packet's rx_ring buffer).
However, I assume VLAN AUXDATA is always consistent (and so the
BPF/BPF JIT filtering).

>     Eric> For old kernels that do not support the new extensions it is
>     Eric> possible to generate code that looks at the ethernet header
>     Eric> and sees if the ethertype is 0x8100 and then does things with
>     Eric> it, but that will only work on a small handful of software
>     Eric> only interfaces.
>
> at tcpdump.org, our concern is to release code that works on both new,
> and what for kernel.org folks would be considered "ancient" systems,
> such as Centos5/RHEL5 machines which are regularly still in production
> in the field (sadly...), but often need the latest diagnostics.
>
> What I hear you saying is that our existing code will work on older
> kernels, and that once we have new code to use the VLAN tag extensions,
> we should simply attempt to load it, and either it loads, or we get an
> error, and we go back to the code we had before.   That's great news.

Yes, this should be handled in such a way.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers