linux-kernel - Re: TX VLAN acceleration on bridges broken in 2.6.37?

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] [day] [month] [year] [list]

Date:	Fri, 25 Feb 2011 17:22:15 -0800
From:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To:	Jesse Gross <jesse@...ira.com>,
	"Allan, Bruce W" <bruce.w.allan@...el.com>
Cc:	Jan Niehusmann <jan@...dor.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Tantilov, Emil S" <emil.s.tantilov@...el.com>
Subject: Re: TX VLAN acceleration on bridges broken in 2.6.37?

On Fri, 2011-02-25 at 17:16 -0800, Jesse Gross wrote:
> On Fri, Feb 25, 2011 at 4:19 PM, Jan Niehusmann <jan@...dor.com> wrote:
> > On Fri, Feb 25, 2011 at 02:53:21PM -0800, Jesse Gross wrote:
> >> is specific to the e1000e driver.  I know that some other Intel NICs
> >> require vlan stripping on receive to be enabled for vlan insertion on
> >> transmit to work.  Since this driver has not been converted over to
> >> use the new vlan model yet, it only enables these things if a vlan is
> >> directly configured on it.  To confirm this can you try a few things:
> >
> > My observations confirm your theory:
> 
> OK, thanks for confirming.  The right solution is convert the driver
> over to the new vlan model.  I don't know how soon I might get to
> this, maybe it's something that the Intel guys can take a look at?

I have made sure that Bruce is aware of the issue.

We will see what we can do to get some patches created and under
testing.

> 
> > - indeed, -e is necessary to show the vlan tags. So my prior observation
> >  regarding tag visibility in tcpdump was wrong. The packets are still
> >  have a vlan tag in the non-working case.
> >
> >  (What actually is affected by the txvlan flag is the ability to filter
> >  for vlan tags with tcpdump.  so 'tcpdump -e -i eth0' shows the packets,
> >  'tcpdump -e -i eth0 vlan' only shows them with txvlan off. However,
> >  filtering for the vlan tag also doesn't work with the vlan interface
> >  on eth0.1, while the tagging actually works, as verified above.)
> 
> Good to know, though that's a separate issue.



Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)