netdev - Re: [tcpdump-workers] vlan tagged packets and libpcap breakage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 17 Nov 2012 17:14:48 -0500
From:	Michael Richardson <mcr@...delman.ca>
To:	tcpdump-workers@...ts.tcpdump.org,
	ebiederm@...ssion.com (Eric W. Biederman)
cc:	Ani Sinha <ani@...stanetworks.com>, netdev@...r.kernel.org,
	Francesco Ruggeri <fruggeri@...stanetworks.com>
Subject: Re: [tcpdump-workers] vlan tagged packets and libpcap breakage

Thank you for this reply.

>>>>> "Eric" == Eric W Biederman <ebiederm@...ssion.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...

    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.

The major concern is that if the 802.1q header is gone, although we can
retrieve it somehow (I'm not sure how the AUXDATA is presented on the
MMAP PF_PACKET interface...) we will have to reconstruct it in order to
save it properly to a savefile.  Many entities, including most major
Network Telescopes (http://en.wikipedia.org/wiki/Network_telescope) use
libpcap (and often tcpdump itself) to capture packets on probe points,
and having good performance matters here... 

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@...delman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 

Content of type "application/pgp-signature" skipped