netdev - Re: IGMP sent to Foreign 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]

Message-ID: <1223508896.24688.95.camel@deepthought.nh.local>
Date:	Wed, 8 Oct 2008 18:34:56 -0500
From:	Jarod Neuner <j.neuner@...workharbor.com>
To:	Patrick McHardy <kaber@...sh.net>
CC:	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: IGMP sent to Foreign VLAN

> Patrick McHardy wrote:
> We've been talking about an IFF_ALLVLAN flag on netdev a while
> ago, which would disable VLAN hardware filters, similar to
> IFF_ALLMULTI. An additional flag on the ethernet device could
> indicate that it should receive unknown VLANs directly. That
> would introduce some possible inconsistencies however since the
> flag could be set without the VLAN code even loaded, in which
> case it would not have any effect.

My original thought was to do something like this in net/core/dev.c
using a method similar to handle_bridge or handle_macvlen.  So, if the
packet doesn't get handled by the ptype_base list and IFF_ALLVLAN is
set, then strip the header and let the packet through.  The sticky point
would be whether or not this policy should be enabled by default, as it
seems to be in other network stacks.

> 
> Another possibility would be to use a catch-all VLAN device with
> VID 0xfff (reserved for implementation use). This would allow
> to configure priority mappings, header reordering etc. and have
> separate statistics. The drivers could just use the magic VID
> as an indication to disable filtering, but I would still suggest
> to add the IFF_ALLVLAN flag because its useful on its own.

Most switches treat VLAN 1 as the "Default" or "Administration" VLAN.
It might make sense to map VLAN 1 to the incoming interface, and then
use that as a catch all.  Then again, that might be a terrible idea as
well. =)

> This can't be right though, the packet needs to be passed
> up the stack. The same change will also be needed in
> __vlan_hwaccel_rx().

Duly noted - thanks.

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