netdev - Re: accelerated vlan gives pcap tagged packets untagged

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]

Message-ID: <alpine.DEB.2.00.0907241743180.12037@callisto.malc.org.uk>
Date:	Fri, 24 Jul 2009 17:50:26 +0100 (BST)
From:	Malcolm Scott <linux-netdev@...c.org.uk>
To:	Patrick McHardy <kaber@...sh.net>
cc:	Pierre Ossman <drzeus-list@...eus.cx>,
	Francois Romieu <romieu@...zoreil.com>, netdev@...r.kernel.org
Subject: Re: accelerated vlan gives pcap tagged packets untagged

At 18:35 yesterday, Patrick McHardy wrote:

> Malcolm Scott wrote:
>
>> So to clarify: as of 2.6.28, an app (e.g. dhcpd) listening on eth0 will
>> by default see packets from all VLANs with tags removed; if it wishes to
>> do otherwise, it should query the kernel for the VLAN tag of every
>> packet and discard those with a tag?
>
> No, exactly the opposite. Starting with 2.6.28 and a recent libpcap,
> VLAN tags are present in userspace independant of whether the driver
> uses VLAN acceleration or not.

Sorry, I meant that the 802.1q header is removed from the packet, not 
discarded entirely.

>> In my case, this is manifesting as the DHCP misbehaviour which Pierre
>> mentioned.  (ISC dhcp3d does not use libpcap, and does not query the
>> packet socket for the VLAN tag, so it treats every VLAN's packets as for
>> the default VLAN.)
>
> It needs to get the VLAN tag from the auxilliary data.

Right.  But backwards compatibility with older apps is the issue.  An app 
which doesn't go looking for a VLAN tag in the auxiliary data -- because it 
didn't have to do so prior to 2.6.28 -- will start seeing packets from all 
VLANs rather than just the untagged ones.

Perhaps what's actually needed is another interface which sees _just_ the 
untagged packets, e.g. eth0.0 (0 being a reserved VLAN ID meaning 'no VLAN', 
i.e. equivalent to no 802.1q tag).

Malcolm

-- 
Malcolm Scott
University of Cambridge Computer Laboratory
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html