From: Florian Lohoff <flo@rfc822.org>
To: andrei radulescu-banu <iubica2@yahoo.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Linux, tcpdump and vlan
Date: Fri, 20 Jul 2007 12:50:03 +0200 [thread overview]
Message-ID: <20070720105003.GB24536@paradigm.rfc822.org> (raw)
In-Reply-To: <878246.51044.qm@web56608.mail.re3.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]
On Wed, Jul 18, 2007 at 12:34:33PM -0700, andrei radulescu-banu wrote:
>
> Dear kernel networking gurus,
>
> I am trying to understand why tcpdump does not work properly for vlan packets on linux. Here is the existing behavior, observed with:
> - kernel 2.6.16,
> - e1000 driver
> - libpcap 0.9.6
> - tcpdump 3.9.6
>
>
> The e1000 driver has two modes when handling vlan frames:
> (A) Default mode, when
> - on rx, the mac includes vlan headers
> - on tx, the mac expects tx frames to include vlan headers.
> (B) Vlan hw accelerated mode, when:
> - on rx, the mac does not include vlan headers, and instead passes vlan tag information in the status field of the ring buffer
> - on tx, the mac expects no vlan headers, and instead expects vlan tag information to be passed in the status field of the ring buffer
I have seen similar behaviour. Once the kernel is compiled with VLAN
support the e1000 driver drops the vlan tag completely even when no
vlans are configured on that port. I would consider this beeing a bug
that enableing a kernel option changes behaviour even if the feature is
not in use.
As i was tracing dot1qinq i could actually see that only the outer
vlan tag was beeing dropped.
Flo
--
Florian Lohoff flo@rfc822.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-07-20 11:25 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-18 19:34 andrei radulescu-banu
2007-07-18 22:57 ` Patrick McHardy
2007-07-18 23:22 ` Ben Greear
2007-07-18 23:34 ` Patrick McHardy
2007-07-19 0:01 ` Ben Greear
2007-07-19 0:19 ` Patrick McHardy
2007-07-19 13:28 ` Krzysztof Halasa
2007-07-19 13:41 ` Stephen Hemminger
2007-07-19 14:00 ` Patrick McHardy
2007-07-19 14:23 ` Krzysztof Halasa
2007-07-19 15:00 ` Stephen Hemminger
2007-07-19 15:45 ` Krzysztof Halasa
2007-07-19 15:20 ` Stephen Hemminger
2007-07-20 10:50 ` Florian Lohoff [this message]
2007-07-19 15:47 andrei radulescu-banu
2007-07-19 16:21 ` Stephen Hemminger
2007-07-19 16:33 ` Patrick McHardy
2007-07-19 16:47 ` Ben Greear
2007-07-19 16:02 andrei radulescu-banu
2007-07-20 19:58 ` Krzysztof Halasa
2007-07-20 20:34 ` Ben Greear
2007-07-21 11:32 ` Krzysztof Halasa
2007-07-21 17:57 ` Ben Greear
2007-07-21 21:15 ` Krzysztof Halasa
2007-07-19 17:46 andrei radulescu-banu
2007-07-19 18:20 andrei radulescu-banu
2007-07-19 19:28 ` Stephen Hemminger
2007-07-19 21:38 andrei radulescu-banu
2007-07-19 23:38 ` Ben Greear
2007-07-20 20:19 ` Krzysztof Halasa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070720105003.GB24536@paradigm.rfc822.org \
--to=flo@rfc822.org \
--cc=iubica2@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®