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  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]
Date:	Sun, 22 May 2011 12:33:36 -0700
From: (Eric W. Biederman)
To:	Jesse Gross <>
Cc:	Jiri Pirko <>,
	Nicolas de Peslo√ľan 
	<>, Changli Gao <>,
	David Miller <>,,,,,,
Subject: Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel (Eric W. Biederman) writes:

> Jesse Gross <> writes:
>> On Sat, May 21, 2011 at 11:34 PM, Eric W. Biederman
>> <> wrote:
>>> Jiri Pirko <> writes:
>>>> Sun, May 22, 2011 at 04:59:49AM CEST, wrote:
>>>> <snip>
>>>>>And because some setups may still require the skb not to be untagged,
>>>>>may be we need the ability to re-tag the skb in some situations...
>>>>>When a protocol handler or rx_handler is explicitly registered on a
>>>>>net_device which expect to receive tagged skb, we should deliver
>>>>>tagged skb to it... Arguably, this may sound incredible for the
>>>>>general case, but may be required for not-so-special cases like
>>>>>bridge or protocol analyzer.
>>>> Wait, what setups/code require the skb not to be untagged? If there's
>>>> such, it should be fixed.
>>> tcpdump on the non-vlan interface for one.
>> There are some drivers still using the old vlan model that will drop
>> tags or packets when no vlan group is configured but that's a driver
>> problem, not one with networking core or tcpdump.
> On receive if we have stripped the vlan header and then we go to deliver
> the interrupt to a pf_packet socket (on a non-vlan interface) before
> or as part of the deliver of the packet to user space we need to
> re-add the vlan header.  Additionally the socket filter on a pf_packet
> socket needs to behave as though we have a vlan header.

Hmm.  Taking a second look the pf_packet code and with hardware vlan
header removal isn't completely broken.  It is possible to receive
packet auxdata and get the information from the vlan header.

It stills seems like a pretty messed up interface to me.  Especially
since the socket filter can't get at the information in the stripped
vlan header, but that is another matter entirely.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists