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: <4DD9F81D.6070806@candelatech.com>
Date:	Sun, 22 May 2011 23:01:01 -0700
From:	Ben Greear <greearb@...delatech.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	David Miller <davem@...emloft.net>, Jiri Pirko <jpirko@...hat.com>,
	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>, Changli Gao <xiaosuo@...il.com>,
	netdev@...r.kernel.org, shemminger@...ux-foundation.org,
	kaber@...sh.net, fubar@...ibm.com, eric.dumazet@...il.com,
	andy@...yhouse.net, Jesse Gross <jesse@...ira.com>
Subject: Re: [PATCH 1/3] vlan: Do not support clearing VLAN_FLAG_REORDER_HDR

On 05/22/2011 03:38 PM, Eric W. Biederman wrote:
> Ben Greear<greearb@...delatech.com>  writes:
>
>> On 05/22/2011 12:39 PM, Eric W. Biederman wrote:
>>>
>>> Simplify the vlan handling code by not supporing clearing of
>>> VLAN_FLAG_REORDER_HDR.  Which means we always make the vlan handling
>>> code strip the vlan header from the packets, and always insert the vlan
>>> header when transmitting packets.
>>>
>>> Not stripping the vlan header has alwasy been broken in combination with
>>> vlan hardware accelleration.  Now that we are making everything look
>>> like accelerated vlan handling not stripping the vlan header is always
>>> broken.
>>>
>>> I don't think anyone actually cares so simply stop supporting the broken
>>> case.
>>
>> I've lost track of the VLAN code a bit.  Is there any documentation
>> somewhere about what happens in these various cases:
>
> Other than the code I don't know about documentation.

These cases are tricky and probably have changed over
the years.  It would be nice to have it written down
somewhere, even if just in comments somewhere in the
VLAN code.

>
>> *  Open a raw packet socket on eth0.
> I assume you mean a pf_packet socket.

Yes.

>>    *  Do we get tagged VLAN packets?  (I'd expect yes.)
> yes.
>
>>    *  If we sent a tagged VLAN packet, it's sent without modification?  (I'd expect yes.)
>>    **  Without "yes" to the two above, one cannot do user-space bridging properly.
>
> This is sort of.  If you set the PACKET_AUXDATA option and use recv_cmsg
> you get the priority and the vlan identifier in the auxdata.
>
> I think that is a pretty horrible answer myself but it has been that way
> since sometime mid 2008.  So I'm not immediately prepared to call it
> a regression, or a bug.

I believe we have been getting tagged VLAN packets properly
in our test cases.  We would not be creating any VLAN devices
in this case, so perhaps the NIC isn't doing any stripping.

To me, it seems like we should get the fully tagged packet
without having to go muck with aux-data, though it would
be fine if it were *also* in aux-data.

I'll try to test this again this coming week to make sure
it's working like I think it is.

Thanks,
Ben

-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com
--
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