On Sat, Nov 17, 2012 at 11:14 PM, Michael Richardson <m...@sandelman.ca> wrote:
>
> Thank you for this reply.
>
>>>>>> "Eric" == Eric W Biederman <ebied...@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
