From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Braun <michael-dev@fami-braun.de>,
"David S . Miller" <davem@davemloft.net>,
Felix Fietkau <nbd@nbd.name>
Subject: Re: [Bridge] [PATCH net-next] bridge: multicast to unicast
Date: Sat, 7 Jan 2017 16:15:30 +0100 [thread overview]
Message-ID: <20170107151530.GG3134@otheros> (raw)
In-Reply-To: <1483706872.4089.8.camel@sipsolutions.net>
On Fri, Jan 06, 2017 at 01:47:52PM +0100, Johannes Berg wrote:
> How does this compare and/or relate to the multicast-to-unicast feature
> we were going to add to the wifi stack, particularly mac80211? Do we
> perhaps not need that feature at all, if bridging will have it?
>
> I suppose that the feature there could apply also to locally generated
> traffic when the AP interface isn't in a bridge, but I think I could
> live with requiring the AP to be put into a bridge to achieve a similar
> configuration?
>
> Additionally, on an unrelated note, this seems to apply generically to
> all kinds of frames, losing information by replacing the address.
> Shouldn't it have similar limitations as the wifi stack feature has
> then, like only applying to ARP, IPv4, IPv6 and not general protocols?
(should all three be answered with Michael's and my reply to
Michael's mail, I think)
>
> Also, it should probably come with the same caveat as we documented for
> the wifi feature:
>
> Note that this may break certain expectations of the receiver,
> such as the ability to drop unicast IP packets received within
> multicast L2 frames, or the ability to not send ICMP destination
> unreachable messages for packets received in L2 multicast (which
> is required, but the receiver can't tell the difference if this
> new option is enabled.)
Actually, I do not quite understand that remark in the mac80211
multicast-to-unicast patch. IP should not care about the ethernet
header?
WARNING: multiple messages have this Message-ID (diff)
From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
Stephen Hemminger <stephen@networkplumber.org>,
bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, Felix Fietkau <nbd@nbd.name>,
Michael Braun <michael-dev@fami-braun.de>
Subject: Re: [PATCH net-next] bridge: multicast to unicast
Date: Sat, 7 Jan 2017 16:15:30 +0100 [thread overview]
Message-ID: <20170107151530.GG3134@otheros> (raw)
In-Reply-To: <1483706872.4089.8.camel@sipsolutions.net>
On Fri, Jan 06, 2017 at 01:47:52PM +0100, Johannes Berg wrote:
> How does this compare and/or relate to the multicast-to-unicast feature
> we were going to add to the wifi stack, particularly mac80211? Do we
> perhaps not need that feature at all, if bridging will have it?
>
> I suppose that the feature there could apply also to locally generated
> traffic when the AP interface isn't in a bridge, but I think I could
> live with requiring the AP to be put into a bridge to achieve a similar
> configuration?
>
> Additionally, on an unrelated note, this seems to apply generically to
> all kinds of frames, losing information by replacing the address.
> Shouldn't it have similar limitations as the wifi stack feature has
> then, like only applying to ARP, IPv4, IPv6 and not general protocols?
(should all three be answered with Michael's and my reply to
Michael's mail, I think)
>
> Also, it should probably come with the same caveat as we documented for
> the wifi feature:
>
> Note that this may break certain expectations of the receiver,
> such as the ability to drop unicast IP packets received within
> multicast L2 frames, or the ability to not send ICMP destination
> unreachable messages for packets received in L2 multicast (which
> is required, but the receiver can't tell the difference if this
> new option is enabled.)
Actually, I do not quite understand that remark in the mac80211
multicast-to-unicast patch. IP should not care about the ethernet
header?
WARNING: multiple messages have this Message-ID (diff)
From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Braun <michael-dev@fami-braun.de>,
"David S . Miller" <davem@davemloft.net>,
Felix Fietkau <nbd@nbd.name>
Subject: Re: [PATCH net-next] bridge: multicast to unicast
Date: Sat, 7 Jan 2017 16:15:30 +0100 [thread overview]
Message-ID: <20170107151530.GG3134@otheros> (raw)
In-Reply-To: <1483706872.4089.8.camel@sipsolutions.net>
On Fri, Jan 06, 2017 at 01:47:52PM +0100, Johannes Berg wrote:
> How does this compare and/or relate to the multicast-to-unicast feature
> we were going to add to the wifi stack, particularly mac80211? Do we
> perhaps not need that feature at all, if bridging will have it?
>
> I suppose that the feature there could apply also to locally generated
> traffic when the AP interface isn't in a bridge, but I think I could
> live with requiring the AP to be put into a bridge to achieve a similar
> configuration?
>
> Additionally, on an unrelated note, this seems to apply generically to
> all kinds of frames, losing information by replacing the address.
> Shouldn't it have similar limitations as the wifi stack feature has
> then, like only applying to ARP, IPv4, IPv6 and not general protocols?
(should all three be answered with Michael's and my reply to
Michael's mail, I think)
>
> Also, it should probably come with the same caveat as we documented for
> the wifi feature:
>
> Note that this may break certain expectations of the receiver,
> such as the ability to drop unicast IP packets received within
> multicast L2 frames, or the ability to not send ICMP destination
> unreachable messages for packets received in L2 multicast (which
> is required, but the receiver can't tell the difference if this
> new option is enabled.)
Actually, I do not quite understand that remark in the mac80211
multicast-to-unicast patch. IP should not care about the ethernet
header?
next prev parent reply other threads:[~2017-01-07 15:15 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-02 19:32 [Bridge] [PATCH net-next] bridge: multicast to unicast Linus Lüssing
2017-01-02 19:32 ` Linus Lüssing
2017-01-02 19:32 ` Linus Lüssing
2017-01-03 11:58 ` [Bridge] " Nikolay Aleksandrov
2017-01-03 11:58 ` Nikolay Aleksandrov via Bridge
2017-01-03 11:58 ` Nikolay Aleksandrov
2017-01-03 13:15 ` [Bridge] " Felix Fietkau
2017-01-03 13:15 ` Felix Fietkau
2017-01-06 12:47 ` [Bridge] " Johannes Berg
2017-01-06 12:47 ` Johannes Berg
2017-01-06 12:47 ` Johannes Berg
2017-01-06 13:52 ` [Bridge] " Felix Fietkau
2017-01-06 13:52 ` Felix Fietkau
2017-01-06 13:54 ` [Bridge] " Johannes Berg
2017-01-06 13:54 ` Johannes Berg
2017-01-06 13:54 ` Johannes Berg
2017-01-06 13:54 ` [Bridge] " Felix Fietkau
2017-01-06 13:54 ` Felix Fietkau
2017-01-07 10:32 ` [Bridge] " M. Braun
2017-01-07 10:32 ` M. Braun
2017-01-07 10:32 ` M. Braun
2017-01-07 14:55 ` [Bridge] " Linus Lüssing
2017-01-07 14:55 ` Linus Lüssing
2017-01-07 14:55 ` Linus Lüssing
2017-01-09 8:08 ` [Bridge] " Johannes Berg
2017-01-09 8:08 ` Johannes Berg
2017-01-09 8:08 ` Johannes Berg
2017-01-09 11:44 ` [Bridge] " M. Braun
2017-01-09 11:44 ` M. Braun
2017-01-09 11:44 ` M. Braun
2017-01-09 12:15 ` [Bridge] " Johannes Berg
2017-01-09 12:15 ` Johannes Berg
2017-01-09 12:15 ` Johannes Berg
2017-01-09 15:25 ` [Bridge] " michael-dev
2017-01-09 15:25 ` michael-dev
2017-01-09 15:47 ` [Bridge] " Johannes Berg
2017-01-09 15:47 ` Johannes Berg
2017-01-09 15:47 ` Johannes Berg
2017-01-09 21:23 ` [Bridge] " Linus Lüssing
2017-01-09 21:23 ` Linus Lüssing
2017-01-09 21:30 ` [Bridge] " Stephen Hemminger
2017-01-09 21:30 ` Stephen Hemminger
2017-01-09 21:30 ` Stephen Hemminger
2017-01-10 4:18 ` [Bridge] " Linus Lüssing
2017-01-10 4:18 ` Linus Lüssing
2017-01-10 4:18 ` Linus Lüssing
2017-01-10 10:56 ` [Bridge] " Johannes Berg
2017-01-10 10:56 ` Johannes Berg
2017-01-10 10:56 ` Johannes Berg
2017-01-10 17:17 ` [Bridge] " Dave Taht
2017-01-10 17:17 ` Dave Taht
2017-01-10 17:23 ` [Bridge] " Felix Fietkau
2017-01-10 17:23 ` Felix Fietkau
2017-01-10 17:23 ` Felix Fietkau
2017-01-10 18:24 ` [Bridge] " Dave Taht
2017-01-10 18:24 ` Dave Taht
2017-01-10 18:24 ` Dave Taht
2017-01-10 21:27 ` [Bridge] " Felix Fietkau
2017-01-10 21:27 ` Felix Fietkau
2017-01-10 21:27 ` Felix Fietkau
2017-01-11 11:26 ` [Bridge] " IgorMitsyanko
2017-01-11 11:26 ` IgorMitsyanko
2017-01-11 11:30 ` [Bridge] " Felix Fietkau
2017-01-11 11:30 ` Felix Fietkau
2017-01-11 12:15 ` [Bridge] " IgorMitsyanko
2017-01-11 12:15 ` IgorMitsyanko
2017-01-11 12:21 ` [Bridge] " Felix Fietkau
2017-01-11 12:21 ` Felix Fietkau
2017-01-07 15:15 ` Linus Lüssing [this message]
2017-01-07 15:15 ` Linus Lüssing
2017-01-07 15:15 ` Linus Lüssing
2017-01-09 8:05 ` [Bridge] " Johannes Berg
2017-01-09 8:05 ` Johannes Berg
2017-01-09 8:05 ` Johannes Berg
2017-01-09 12:42 ` [Bridge] " Linus Lüssing
2017-01-09 12:42 ` Linus Lüssing
2017-01-09 12:42 ` Linus Lüssing
2017-01-09 12:44 ` [Bridge] " Johannes Berg
2017-01-09 12:44 ` Johannes Berg
2017-01-09 12:44 ` Johannes Berg
2017-01-09 23:12 ` [Bridge] " Linus Lüssing
2017-01-09 23:12 ` Linus Lüssing
2017-01-09 23:12 ` Linus Lüssing
2017-01-11 9:17 ` [Bridge] " Johannes Berg
2017-01-11 9:17 ` Johannes Berg
2017-01-11 9:17 ` Johannes Berg
2017-01-07 3:13 ` [Bridge] " Stephen Hemminger
2017-01-07 3:13 ` Stephen Hemminger
2017-01-07 3:13 ` Stephen Hemminger
2017-01-07 3:13 ` Stephen Hemminger
2017-01-07 15:06 ` [Bridge] " Linus Lüssing
2017-01-07 15:06 ` Linus Lüssing
2017-01-07 15:06 ` Linus Lüssing
2017-01-09 8:36 ` [Bridge] " Jean-Pierre Tosoni
2017-01-09 8:36 ` Jean-Pierre Tosoni
2017-01-09 8:36 ` Jean-Pierre Tosoni
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=20170107151530.GG3134@otheros \
--to=linus.luessing@c0d3.blue \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=michael-dev@fami-braun.de \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
/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.