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 for Android: free password hash cracker in your pocket

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

Message-ID: <20100930080703.GA10827@core.hellgate.ch>
Date:	Thu, 30 Sep 2010 10:07:04 +0200
From:	Roger Luethi <rl@...lgate.ch>
To:	Jesse Gross <jesse@...ira.com>
Cc:	netdev@...r.kernel.org, Patrick McHardy <kaber@...sh.net>
Subject: Re: VLAN packets silently dropped in promiscuous mode

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.

Hardware VLAN filtering, on the other hand, must be disabled in promiscuous
mode. But doing that in the driver makes no difference now as the current
VLAN code drops the packets so preserved before they are passed to the pcap
interface. That appears to be a bug.

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