From: Stephen Hemminger <stephen@networkplumber.org>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: Arend van Spriel <arend.vanspriel@broadcom.com>, BROADCOM
Subject: Re: [Bridge] Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw
Date: Mon, 12 Mar 2018 16:01:03 -0700 [thread overview]
Message-ID: <20180312160103.1a043936@xeon-e3> (raw)
In-Reply-To: <a7a21b04-025f-19e1-ec09-69cc355b9215@gmail.com>
On Mon, 12 Mar 2018 23:42:48 +0100
Rafał Miłecki <zajec5@gmail.com> wrote:
> 2) Blame bridge + mcast-to-ucast + hairpin for 802.11f incompatibility
>
> If we agree that 802.11f support in FullMAC firmware is acceptable, then
> we have to make sure Linux's bridge doesn't break it by passing 802.11f
> (broadcast) frames back to the source interface. That would require a
> check like in below diff + proper code for handling such packets. I'm
> afraid I'm not familiar with bridge code enough to complete that.
>
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index edae702..9e5d6ea 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> @@ -126,6 +126,27 @@ static void br_do_proxy_arp(struct sk_buff *skb, struct net_bridge *br,
> }
> }
>
> +static bool br_skb_is_iapp_add_packet(struct sk_buff *skb)
> +{
> + const u8 iapp_add_packet[6] __aligned(2) = {
> + 0x00, 0x01, 0xaf, 0x81, 0x01, 0x00,
> + };
> +#if !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
> + const u16 *a = (const u16 *)skb->data;
> + const u16 *b = (const u16 *)iapp_add_packet;
> +#endif
> +
> + if (skb->len != 6)
> + return false;
> +
> +#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
> + return !(((*(const u32 *)skb->data) ^ (*(const u32 *)iapp_add_packet)) |
> + ((*(const u16 *)(skb->data + 4)) ^ (*(const u16 *)(iapp_add_packet + 4))));
> +#else
> + return !((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2]));
> +#endif
> +}
> +
> /* note: already called with rcu_read_lock */
> int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
> {
> @@ -155,6 +176,8 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
> if (is_multicast_ether_addr(dest)) {
> /* by definition the broadcast is also a multicast address */
> if (is_broadcast_ether_addr(dest)) {
> + if (br_skb_is_iapp_add_packet(skb))
> + pr_warn("This packet should not be passed back to the source interface!\n");
> pkt_type = BR_PKT_BROADCAST;
> local_rcv = true;
> } else {
Don't like bridge doing special case code for magic received values directly in input path.
Really needs to be generic which is why I suggested ebtables.
next prev parent reply other threads:[~2018-03-12 23:01 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 ` [Bridge] " Linus Lüssing
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 ` Stephen Hemminger [this message]
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=20180312160103.1a043936@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=arend.vanspriel@broadcom.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.