netdev - Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state"

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: <20130501154904.0ea31991@nehalam.linuxnetplumber.net>
Date:	Wed, 1 May 2013 15:49:04 -0700
From:	Stephen Hemminger <stephen@...workplumber.org>
To:	Felix Fietkau <nbd@...nwrt.org>
Cc:	Krishna Chaitanya <chaitanya.mgit@...il.com>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	Sebastian Gottschall <s.gottschall@...wrt.com>,
	Johannes Berg <johannes@...solutions.net>,
	netdev <netdev@...r.kernel.org>
Subject: Re: Regression in 3.9 caused by "bridge: respect RFC2863
 operational state"

On Wed, 01 May 2013 23:06:16 +0200
Felix Fietkau <nbd@...nwrt.org> wrote:

> On 2013-05-01 10:21 PM, Stephen Hemminger wrote:
> > What about using AF_PACKET bound to underlying wireless device and the
> > packet type. You can even use BPF to filter.
> As far as I know, AF_PACKET only works when not binding it to the packet
> type (otherwise it get stolen by the rx handler).

You can do AF_PACKET and it gets handle before rx_handler.

> Not binding it to the packet type and using BPF to filter is expensive
> on small embedded devices with small caches. Still, this requires
> userspace changes, so we need a different solution.
> 
> > Another alternative would be to have bridge accept control frames on
> > dormant device but not send.
> Sounds good, will you send a patch for that?
> 
> - Felix
> 

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