netdev - Re: [PATCH 1/3] vlan: Do not support clearing VLAN_FLAG_REORDER

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: <4DDB5A3F.8050007@gmail.com>
Date:	Tue, 24 May 2011 09:11:59 +0200
From:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
To:	Ben Greear <greearb@...delatech.com>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	David Miller <davem@...emloft.net>,
	shemminger@...ux-foundation.org, jpirko@...hat.com,
	xiaosuo@...il.com, netdev@...r.kernel.org, kaber@...sh.net,
	fubar@...ibm.com, eric.dumazet@...il.com, andy@...yhouse.net,
	jesse@...ira.com
Subject: Re: [PATCH 1/3] vlan: Do not support clearing VLAN_FLAG_REORDER_HDR

Le 24/05/2011 06:20, Ben Greear a écrit :
<snip>

> Then I think we should put it back with pf_packet logic. Possibly with
> a per-socket option to disable this and send it as only aux data if that
> is more efficient.

Why would we need a per-socket option for that?

If the socket listen on eth0, it probably expect to receive the raw packet. If it happens to expect 
the untagged packet, it should listen on vlan2000.

The only reason I can imagine to listen on eth0 while expecting the packet to be untagged is to 
listen to several VLAN at the same time on a single socket, while still expecting the kernel or the 
NIC to extract the vlan ID for us. But I don't have a real life use case for this in mind.

And maybe, for that particular situation, we should have a special vlan interface, with wildcard 
vlan ID:

        +--eth0.100
        |
eth0 --+--eth0.200
        |
        +--eth0.any

- Someone listening on eth0 would receive raw packet.
- Someone listening on eth0.100/eth0.200 would receive untagged packets originally having 100/200 as 
the VLAN ID.
- Someone listening on eth0.any would receive untagged packets originally having any VLAN ID and 
would not receive non-originally-tagged packets.

> If it turns out the NIC is not stripping VLAN tags for whatever reason,
> we might be able to optimize things so that it never does the HW emulation
> so that it never has to un-do it later.

It might be very tricky to avoid any do-undo-redo situation. I will latter try and describe all the 
possible situations: with/without hw-accel, with/without a protocol handler registered on the parent 
interface, with/without a child interface build on top of a particular parent interface and with the 
corresponding VLAN ID...

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