linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Jul 2007 16:22:57 -0700
From:	Ben Greear <greearb@...delatech.com>
To:	Patrick McHardy <kaber@...sh.net>
CC:	andrei radulescu-banu <iubica2@...oo.com>,
	linux-kernel@...r.kernel.org,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: Linux, tcpdump and vlan

Patrick McHardy wrote:
> andrei radulescu-banu wrote:
>   
>> [...]
>>
>> 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.
>>     
> Put another way, once you enable VLAN header stripping, you
> won't see the headers for *any* VLAN, not only for those you're
> actually running locally. This is also a problem for devices
> like macvlan, where it would be desirable to make use of
> hardware VLAN accerlation. I was thinking about storing the
> information somewhere in the packets meta-data on both RX and
> TX paths, that would also allow tcpdump to properly display
> packets.
>   
MAC-VLAN could gather this information based on it's parent
device (ie, if parent-dev has VID 7, then add VID 7 to the meta
data.  There would be no need for any driver changes I think.

Other than TCP-dump, or some other raw protocol that wants to see
the VLAN header in user-space, I can't think of what use this would
be, however.  And, if you just disable VLAN accel in the NIC (see below),
that would make this mac-vlan hackery not needed at all?
> I have planned to look into this when I find some time.
> Your suggestion of disabling VLAN acceleration in promiscous
> mode sounds like a reasonable solution until then ..
>   
I think a better method would be to allow disabling VLAN HW accel for a 
NIC with
ethtool.  Then, the packets will be received by the software stack with 
the vlan
header intact.  Something sniffing on the physical dev will 
automatically get the
VLAN header.

Thanks,
Ben

-- 
Ben Greear <greearb@...delatech.com> 
Candela Technologies Inc  http://www.candelatech.com


-
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/