linux-kernel - Linux, tcpdump and vlan

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <878246.51044.qm@web56608.mail.re3.yahoo.com>
Date:	Wed, 18 Jul 2007 12:34:33 -0700 (PDT)
From:	andrei radulescu-banu <iubica2@...oo.com>
To:	linux-kernel@...r.kernel.org
Subject: Linux, tcpdump and vlan

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@...oo.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/