netdev - Re: VLAN packets silently dropped in promiscuous mode

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:	Thu, 30 Sep 2010 14:21:15 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Roger Luethi <rl@...lgate.ch>
Cc:	netdev@...r.kernel.org, Patrick McHardy <kaber@...sh.net>
Subject: Re: VLAN packets silently dropped in promiscuous mode

On Thu, Sep 30, 2010 at 1:07 AM, Roger Luethi <rl@...lgate.ch> wrote:
> On Wed, 29 Sep 2010 10:44:26 -0700, Jesse Gross wrote:
>> On Wed, Sep 29, 2010 at 4:37 AM, Roger Luethi <rl@...lgate.ch> wrote:
>> > I noticed packets for unknown VLANs getting silently dropped even in
>> > promiscuous mode (this is true only for the hardware accelerated path).
>> > netif_nit_deliver was introduced specifically to prevent that, but the
>> > function gets called only _after_ packets from unknown VLANs have been
>> > dropped.
>>
>> Some drivers are fixing this on a case by case basis by disabling
>> hardware accelerated VLAN stripping when in promiscuous mode, i.e.:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5f6c01819979afbfec7e0b15fe52371b8eed87e8
>>
>> However, at this point it is more or less random which drivers do
>> this.  It would obviously be much better if it were consistent.
>
> My understanding is this. Hardware VLAN tagging and stripping can always be
> enabled. The kernel passes 802.1Q information along with the stripped
> header to libpcap which reassembles the original header where necessary.
> Works for me.

Sorry, I misread your original post as saying that the VLAN header
gets dropped, rather than the entire packet.  I agree that this is how
it should work but not necessarily how it does work (again, depending
on the driver).  Here's the problem that I was talking about:

Most drivers have a snippet of code that looks something like this
(taken from ixgbe):

if (adapter->vlgrp && is_vlan && (tag & VLAN_VID_MASK))
	vlan_gro_receive(napi, adapter->vlgrp, tag, skb);
else
	napi_gro_receive(napi, skb);

At this point the VLAN has already been stripped in hardware.  If
there is no VLAN group configured on the device then we hit the second
case.  The VLAN header was removed from the SKB and the tag variable
is unused.  It is no longer possible for libpcap to reconstruct the
header because the information was thrown away (even the fact that
there was a VLAN tag at all).

There are a couple ways to fix this:

* Turn off VLAN stripping when in promiscuous mode (as done by the ixgbe driver)
* Reconstruct the VLAN header when there is no VLAN group (as done by
the tg3 driver)

A bunch of drivers do neither (bnx2x, for example) and exhibit this
problem.  It's getting better but it seems like a common issue.
--
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