[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <12918.1353190488@obiwan.sandelman.ca>
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
Powered by blists - more mailing lists