From: Felix Fietkau <nbd@openwrt.org>
To: Florian Westphal <fw@strlen.de>,
Zefir Kurtisi <zefir.kurtisi@neratec.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
OpenWrt Development List <openwrt-devel@lists.openwrt.org>,
netfilter-devel@vger.kernel.org
Subject: Re: [BUG] kernel crash in br_netfilter
Date: Tue, 8 Mar 2016 12:55:58 +0100 [thread overview]
Message-ID: <56DEBDCE.2070900@openwrt.org> (raw)
In-Reply-To: <20160308110600.GA1011@breakpoint.cc>
On 2016-03-08 12:06, Florian Westphal wrote:
>> My hot-fix to prevent the crash is to instead of passing the skb to NF_HOOK
>> directly pass it to br_handle_local_finish(). But having insufficient insight into
>> what is going on there, this is fighting the symptoms rather than solving the root
>> cause. Maybe it is even better to drop patch 120 (not tested yet)?
>
> Sorry, I don't know why this patch was not merged upstream and do not know why its
> in openwrt.
This patch exists, because it's otherwise impossible to bridge a client
mode (4addr) WLAN interface when encryption is enabled.
wpa_supplicant needs to receive EAP packets before it will change the
operstate to allow the bridge and the rest of the network stack to do
their thing.
This used to work in a while back, and I think it got broken by this
commit:
commit 576eb62598f10c8c7fd75703fe89010cdcfff596
Author: stephen hemminger <shemminger@vyatta.com>
Date: Fri Dec 28 18:15:22 2012 +0000
bridge: respect RFC2863 operational state
The bridge link detection should follow the operational state
of the lower device, rather than the carrier bit. This allows devices
like tunnels that are controlled by userspace control plane to work
with bridge STP link management.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Reviewed-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Back then I proposed a patch for upstream inclusion, got some feedback,
Stephen sent me this patch and I fixed it up a bit and re-submitted it.
I think it got lost somewhere in the process and after that I lost track
and didn't get around to re-submitting it.
So we kept the patch in OpenWrt because as far as I know, the regression
still exists in current kernels.
- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
prev parent reply other threads:[~2016-03-08 11:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-29 12:33 [BUG] kernel crash in br_netfilter Zefir Kurtisi
2016-03-07 17:43 ` Zefir Kurtisi
2016-03-08 11:06 ` Florian Westphal
2016-03-08 11:55 ` Felix Fietkau [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56DEBDCE.2070900@openwrt.org \
--to=nbd@openwrt.org \
--cc=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=openwrt-devel@lists.openwrt.org \
--cc=stephen@networkplumber.org \
--cc=zefir.kurtisi@neratec.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.