From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>,
Arend van Spriel <arend.vanspriel@broadcom.com>,
Network Development <netdev@vger.kernel.org>,
Chi-Hsien Lin <chi-hsien.lin@cypress.com>,
bridge@lists.linux-foundation.org,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
Hante Meuleman <hante.meuleman@broadcom.com>,
Wright Feng <wright.feng@cypress.com>,
Felix Fietkau <nbd@nbd.name>,
"open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
<brcm80211-dev-list.pdl@broadcom.com>,
" <brcm80211-dev-list@cypress.com>,
Franky Lin <franky.lin@broadcom.com>
Subject: Re: [Bridge] Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw
Date: Mon, 12 Mar 2018 12:40:17 +0100 [thread overview]
Message-ID: <20180312114017.GM2470@otheros> (raw)
In-Reply-To: <CACna6rxP4ATE2f6XJi7XKDLe2L_Z43aLreEHDCfGicksYTb0xg@mail.gmail.com>
On Mon, Mar 12, 2018 at 10:46:45AM +0100, Rafał Miłecki wrote:
> On 27 February 2018 at 18:05, Stephen Hemminger
[...]
> > ebtables is your friend in dealing with weird and broken devices.
>
> It may be weird, not sure if actually broken. Anyway I'd like to have
> some generic solution instead of telling every user to use ebtables to
> workaround the problem.
I agree that a "broken by default" in OpenWRT/LEDE for a variety
of Broadcom devices is not really acceptable.
Technically we could teach netifd in OpenWRT/LEDE to configure
ebtables accordingly, at least for a list of affected devices,
so that users would not have to. However, as ebtables is not
managed by the fw3 in OpenWRT/LEDE, that would probably interfer
with user provided ebtables rules and scripts...
> That said I think we still should look for a solution for existing
> firmwares. I guess it may takes months to years to never to release
> new firmwares for all supported chipsets.
Hm, we could change the default in OpenWRT/LEDE for
multicast-to-unicast (or more precisely bridge hairpinning) to
disabled again for now.
WARNING: multiple messages have this Message-ID (diff)
From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
Felix Fietkau <nbd@nbd.name>,
Arend van Spriel <arend.vanspriel@broadcom.com>,
Franky Lin <franky.lin@broadcom.com>,
Hante Meuleman <hante.meuleman@broadcom.com>,
Chi-Hsien Lin <chi-hsien.lin@cypress.com>,
Wright Feng <wright.feng@cypress.com>,
Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>,
Network Development <netdev@vger.kernel.org>,
bridge@lists.linux-foundation.org,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
<brcm80211-dev-list.pdl@broadcom.com>,"
<brcm80211-dev-list@cypress.com>
Subject: Re: Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw
Date: Mon, 12 Mar 2018 12:40:17 +0100 [thread overview]
Message-ID: <20180312114017.GM2470@otheros> (raw)
In-Reply-To: <CACna6rxP4ATE2f6XJi7XKDLe2L_Z43aLreEHDCfGicksYTb0xg@mail.gmail.com>
On Mon, Mar 12, 2018 at 10:46:45AM +0100, Rafał Miłecki wrote:
> On 27 February 2018 at 18:05, Stephen Hemminger
[...]
> > ebtables is your friend in dealing with weird and broken devices.
>
> It may be weird, not sure if actually broken. Anyway I'd like to have
> some generic solution instead of telling every user to use ebtables to
> workaround the problem.
I agree that a "broken by default" in OpenWRT/LEDE for a variety
of Broadcom devices is not really acceptable.
Technically we could teach netifd in OpenWRT/LEDE to configure
ebtables accordingly, at least for a list of affected devices,
so that users would not have to. However, as ebtables is not
managed by the fw3 in OpenWRT/LEDE, that would probably interfer
with user provided ebtables rules and scripts...
> That said I think we still should look for a solution for existing
> firmwares. I guess it may takes months to years to never to release
> new firmwares for all supported chipsets.
Hm, we could change the default in OpenWRT/LEDE for
multicast-to-unicast (or more precisely bridge hairpinning) to
disabled again for now.
WARNING: multiple messages have this Message-ID (diff)
From: "Linus Lüssing" <linus.luessing-djzkFPsfvsizQB+pC5nmwQ@public.gmane.org>
To: "Rafał Miłecki" <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Stephen Hemminger
<stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>,
Felix Fietkau <nbd-Vt+b4OUoWG0@public.gmane.org>,
Arend van Spriel
<arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
Franky Lin <franky.lin-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
Hante Meuleman
<hante.meuleman-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
Chi-Hsien Lin
<chi-hsien.lin-+wT8y+m8/X5BDgjK7y7TUQ@public.gmane.org>,
Wright Feng <wright.feng-+wT8y+m8/X5BDgjK7y7TUQ@public.gmane.org>,
Pieter-Paul Giesberts
<pieter-paul.giesberts-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
Network Development
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
bridge-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
"linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
<brcm80211-dev-list.pdl-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,"
<brcm80211-dev-list-+wT8y+m8/X5BDgjK7y7TUQ@public.gmane.org>
Subject: Re: Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw
Date: Mon, 12 Mar 2018 12:40:17 +0100 [thread overview]
Message-ID: <20180312114017.GM2470@otheros> (raw)
In-Reply-To: <CACna6rxP4ATE2f6XJi7XKDLe2L_Z43aLreEHDCfGicksYTb0xg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Mar 12, 2018 at 10:46:45AM +0100, Rafał Miłecki wrote:
> On 27 February 2018 at 18:05, Stephen Hemminger
[...]
> > ebtables is your friend in dealing with weird and broken devices.
>
> It may be weird, not sure if actually broken. Anyway I'd like to have
> some generic solution instead of telling every user to use ebtables to
> workaround the problem.
I agree that a "broken by default" in OpenWRT/LEDE for a variety
of Broadcom devices is not really acceptable.
Technically we could teach netifd in OpenWRT/LEDE to configure
ebtables accordingly, at least for a list of affected devices,
so that users would not have to. However, as ebtables is not
managed by the fw3 in OpenWRT/LEDE, that would probably interfer
with user provided ebtables rules and scripts...
> That said I think we still should look for a solution for existing
> firmwares. I guess it may takes months to years to never to release
> new firmwares for all supported chipsets.
Hm, we could change the default in OpenWRT/LEDE for
multicast-to-unicast (or more precisely bridge hairpinning) to
disabled again for now.
next prev parent reply other threads:[~2018-03-12 11:40 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-27 10:08 Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw Rafał Miłecki
2018-02-27 10:08 ` [Bridge] " Rafał Miłecki
2018-02-27 10:14 ` Rafał Miłecki
2018-02-27 10:14 ` [Bridge] " Rafał Miłecki
2018-02-27 10:14 ` Rafał Miłecki
2018-02-28 11:31 ` Arend van Spriel
2018-02-28 11:31 ` [Bridge] " Arend van Spriel
2018-02-28 11:31 ` Arend van Spriel via Bridge
2018-03-12 9:49 ` Rafał Miłecki
2018-03-12 9:49 ` [Bridge] " Rafał Miłecki
2018-03-12 9:49 ` Rafał Miłecki
2018-02-27 17:05 ` [Bridge] " Stephen Hemminger
2018-03-12 9:46 ` Rafał Miłecki
2018-03-12 9:46 ` [Bridge] " Rafał Miłecki
2018-03-12 9:46 ` Rafał Miłecki
2018-03-12 11:40 ` Linus Lüssing [this message]
2018-03-12 11:40 ` Linus Lüssing
2018-03-12 11:40 ` Linus Lüssing
2018-03-12 11:08 ` [Bridge] " Linus Lüssing
2018-03-12 11:08 ` Linus Lüssing
2018-03-12 11:08 ` Linus Lüssing
2018-03-12 11:48 ` [Bridge] " Linus Lüssing
2018-03-12 11:48 ` Linus Lüssing
2018-03-12 11:48 ` Linus Lüssing
2018-03-12 21:52 ` Rafał Miłecki
2018-03-12 21:52 ` [Bridge] " Rafał Miłecki
2018-03-12 21:52 ` Rafał Miłecki
2018-03-12 21:49 ` Rafał Miłecki
2018-03-12 21:49 ` [Bridge] " Rafał Miłecki
2018-03-12 21:49 ` Rafał Miłecki
2018-03-12 22:42 ` Rafał Miłecki
2018-03-12 22:42 ` [Bridge] " Rafał Miłecki
2018-03-12 22:42 ` Rafał Miłecki
2018-03-12 23:01 ` [Bridge] " Stephen Hemminger
2018-03-13 6:23 ` Rafał Miłecki
2018-03-13 6:23 ` [Bridge] " Rafał Miłecki
2018-03-13 6:23 ` Rafał Miłecki
2018-03-13 7:17 ` [Bridge] " Felix Fietkau
2018-03-13 7:17 ` Felix Fietkau
2018-03-13 7:20 ` [Bridge] " Felix Fietkau
2018-03-13 7:20 ` Felix Fietkau
2018-03-13 7:20 ` Felix Fietkau
2018-03-13 9:18 ` Arend van Spriel
2018-03-13 9:18 ` [Bridge] " Arend van Spriel
2018-03-13 9:18 ` Arend van Spriel
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=20180312114017.GM2470@otheros \
--to=linus.luessing@c0d3.blue \
--cc=arend.vanspriel@broadcom.com \
--cc=brcm80211-dev-list@cypress.com \
--cc=bridge@lists.linux-foundation.org \
--cc=chi-hsien.lin@cypress.com \
--cc=franky.lin@broadcom.com \
--cc=hante.meuleman@broadcom.com \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=pieter-paul.giesberts@broadcom.com \
--cc=wright.feng@cypress.com \
--cc=zajec5@gmail.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.