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]

Message-ID: <1285884253.2705.25.camel@edumazet-laptop>
Date:	Fri, 01 Oct 2010 00:04:13 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Jesse Gross <jesse@...ira.com>
Cc:	Roger Luethi <rl@...lgate.ch>, netdev@...r.kernel.org,
	Patrick McHardy <kaber@...sh.net>
Subject: Re: VLAN packets silently dropped in promiscuous mode

Le jeudi 30 septembre 2010 à 14:21 -0700, Jesse Gross a écrit :
> 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.

tg3 is not perfect, because it does the reconstruction of VLAN header
even if device is not in promiscuous mode.

It could drop the frame instead.

I wonder which SNMP counter is incremented in this case.

Apparently, none :(



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