mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: andrei radulescu-banu <iubica2@yahoo.com>
To: linux-kernel@vger.kernel.org
Subject: Linux, tcpdump and vlan
Date: Wed, 18 Jul 2007 12:34:33 -0700 (PDT)	[thread overview]
Message-ID: <878246.51044.qm@web56608.mail.re3.yahoo.com> (raw)

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
  

If no vlan interfaces are used, the e1000 driver configures the mac in default mode (A). The system will only receive vlan traffic, and not transmit any. Tcpdump then gets the entire rx vlan buffers, and displays them correctly.
  

Suppose now that at least one vlan interface is used - say eth0 is the main physical interface, and eth0.2 is an interface created on vlan id 2. The e1000 driver then switches to vlan hw accelerated mode (B). Furthermore, even if set promiscuous, the e1000 will filter out any rx vlan frames of id other than 2, which breaks tcpdump (bug 1).
  

Suppose in our scenario with eth0 and eth0.2 we're running tcpdump on eth0 - which uses a packet socket. The rx vlan frames with id 2 are then assigned by the driver to eth0.2, and are therefore not passed to the packet socket and to tcpdump (bug 2). The tx vlan frames on eth0.2 are passed to the packet socket without any vlan information, and tcpdump does not display the vlan header (bug 3)
  

In conclusion, here is the buglist:  
1). If set promiscuous, the e1000 should disable any vlan rx filtering, so that it can receive vlan frames of other vlan id's. Other ethernet drivers probably need fixed as well.
  2). The packet layer should change the rx skb device from the vlan 'fake' device (eth0.2) to the corresponding physical device (eth0), so when we run tcpdump on eth0 we see all vlan-tagged and non-vlan-tagged frames
  3). The packet socket layer should insert the vlan tag header before passing frames to the upper layer, so tcpdump can display them.
  

Open issue:  
4). What is the expected behavior when running 'tcpdump -I eth0.2'? Perhaps the packet socket should silently display all frames on eth0, so running 'tcpdump -i eth0' is equivalent to 'tcpdump -i eth0.2'

  

Thoughts? Comments? Please cc iubica2@yahoo.com, I am not subscribed. 
  

Andrei Radulescu-Banu  
Brix Networks 





      ____________________________________________________________________________________
Luggage? GPS? Comic books? 
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz

             reply	other threads:[~2007-07-18 19:41 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-18 19:34 andrei radulescu-banu [this message]
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
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=878246.51044.qm@web56608.mail.re3.yahoo.com \
    --to=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®