Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1552759 > unrolled thread

Re: [PATCH net-next] bridge: multicast to unicast

Started byJohannes Berg <johannes@sipsolutions.net>
First post2017-01-06 14:00 +0100
Last post2017-01-11 10:20 +0100
Articles 7 on this page of 27 — 7 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH net-next] bridge: multicast to unicast Johannes Berg <johannes@sipsolutions.net> - 2017-01-06 14:00 +0100
    Re: [PATCH net-next] bridge: multicast to unicast Felix Fietkau <nbd@nbd.name> - 2017-01-06 15:00 +0100
      Re: [PATCH net-next] bridge: multicast to unicast Johannes Berg <johannes@sipsolutions.net> - 2017-01-06 15:00 +0100
        Re: [PATCH net-next] bridge: multicast to unicast Felix Fietkau <nbd@nbd.name> - 2017-01-06 15:40 +0100
        Re: [PATCH net-next] bridge: multicast to unicast "M. Braun" <michael-dev@fami-braun.de> - 2017-01-07 11:50 +0100
          Re: [PATCH net-next] bridge: multicast to unicast Linus Lüssing <linus.luessing@c0d3.blue> - 2017-01-07 16:00 +0100
            Re: [PATCH net-next] bridge: multicast to unicast Johannes Berg <johannes@sipsolutions.net> - 2017-01-09 09:10 +0100
              Re: [PATCH net-next] bridge: multicast to unicast "M. Braun" <michael-dev@fami-braun.de> - 2017-01-09 13:00 +0100
                Re: [PATCH net-next] bridge: multicast to unicast Johannes Berg <johannes@sipsolutions.net> - 2017-01-09 13:20 +0100
                  Re: [PATCH net-next] bridge: multicast to unicast michael-dev <michael-dev@fami-braun.de> - 2017-01-09 16:30 +0100
                    Re: [PATCH net-next] bridge: multicast to unicast Johannes Berg <johannes@sipsolutions.net> - 2017-01-09 16:50 +0100
                Re: [PATCH net-next] bridge: multicast to unicast Linus Lüssing <linus.luessing@c0d3.blue> - 2017-01-09 22:30 +0100
                  Re: [PATCH net-next] bridge: multicast to unicast Stephen Hemminger <stephen@networkplumber.org> - 2017-01-09 22:40 +0100
                    Re: [PATCH net-next] bridge: multicast to unicast Linus Lüssing <linus.luessing@c0d3.blue> - 2017-01-10 05:20 +0100
                      Re: [PATCH net-next] bridge: multicast to unicast Johannes Berg <johannes@sipsolutions.net> - 2017-01-10 12:00 +0100
                        Re: [PATCH net-next] bridge: multicast to unicast Dave Taht <dave.taht@gmail.com> - 2017-01-10 18:20 +0100
                          Re: [PATCH net-next] bridge: multicast to unicast Felix Fietkau <nbd@nbd.name> - 2017-01-10 18:30 +0100
                            Re: [PATCH net-next] bridge: multicast to unicast Dave Taht <dave.taht@gmail.com> - 2017-01-10 19:30 +0100
                        Re: [PATCH net-next] bridge: multicast to unicast Felix Fietkau <nbd@nbd.name> - 2017-01-10 22:30 +0100
                          Re: [PATCH net-next] bridge: multicast to unicast Felix Fietkau <nbd@nbd.name> - 2017-01-11 12:40 +0100
                            Re: [PATCH net-next] bridge: multicast to unicast Felix Fietkau <nbd@nbd.name> - 2017-01-11 13:30 +0100
    Re: [PATCH net-next] bridge: multicast to unicast Linus Lüssing <linus.luessing@c0d3.blue> - 2017-01-07 16:20 +0100
      Re: [PATCH net-next] bridge: multicast to unicast Johannes Berg <johannes@sipsolutions.net> - 2017-01-09 09:10 +0100
        Re: [PATCH net-next] bridge: multicast to unicast Linus Lüssing <linus.luessing@c0d3.blue> - 2017-01-09 13:50 +0100
          Re: [PATCH net-next] bridge: multicast to unicast Johannes Berg <johannes@sipsolutions.net> - 2017-01-09 13:50 +0100
            Re: [PATCH net-next] bridge: multicast to unicast Linus Lüssing <linus.luessing@c0d3.blue> - 2017-01-10 00:20 +0100
              Re: [PATCH net-next] bridge: multicast to unicast Johannes Berg <johannes@sipsolutions.net> - 2017-01-11 10:20 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1556446

FromFelix Fietkau <nbd@nbd.name>
Date2017-01-11 13:30 +0100
Message-ID<sYqcq-6Ty-5@gated-at.bofh.it>
In reply to#1556414
On 2017-01-11 13:15, IgorMitsyanko wrote:
> On 01/11/2017 02:30 PM, Felix Fietkau wrote:
>> On 2017-01-11 12:26, IgorMitsyanko wrote:
>>> On 01/11/2017 12:27 AM, Felix Fietkau wrote:
>>>> On 2017-01-10 11:56, Johannes Berg wrote:
>>>>> On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
>>>>>> On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
>>>>>>> I wonder if MAC80211 should be doing IGMP snooping and not bridge
>>>>>>> in this environment.
>>>>>> In the long term, yes. For now, not quite sure.
>>>>> There's no "for now" in the kernel. Code added now will have to be
>>>>> maintained essentially forever.
>>>> I'm not sure that putting the IGMP snooping code in mac80211 is a good
>>>> idea, that would be quite a bit of code duplication.
>>>> This implementation works, it's very simple, and it's quite flexible for
>>>> a number of use cases.
>>>>
>>>> Is there any remaining objection to merging this in principle (aside
>>>> from potential issues with the code)?
>>>>
>>>> - Felix
>>>>
>>>
>>> Hi Felix, can we consider two examples configurations with multicast
>>> traffic:
>>>
>>> 1. AP is a source of multicast traffic itself, no bridge on AP. For
>>> example, wireless video server streaming to several clients.
>>> In this situation, we can not make use of possible advantages given by
>>> mc-to-uc conversion?
>> You could simply put the AP interface in a bridge, no need to have any
>> other bridge members present.
>>
>>> 2. A configuration with AP + STA + 3 client devices behind STA.
>>>                               ----|client 1|
>>>                              |
>>> |  mc  |----|AP|----|STA|---|---|client 2|
>>> |server|                    |
>>>                               ----|client 3|
>>>
>>> Multicast server behind AP streams MC video traffic. All 3 clients
>>> behind the STA have joined the multicast group.
>>> I'm not sure if this case will be handled correctly with mc-to-uc
>>> conversion in bridge on AP?
>> What do you mean by "3 client devices behind STA"? Are you using a
>> 4-addr STA, multicast routing, or some kind of vendor specific "client
>> bridge" hackery?
> 
> 3 client devices connected by backbone Ethernet network. Generic
> case is probably STA/AP operating in 4-addr mode (more or less standard
> solution as far as I know).
If the AP is running in 4-addr mode, it will need to have a bridge
interface anyway, because the link to the STA will be split out into a
separate virtual interface (AP_VLAN iftype).

In this case you don't actually need any multicast-to-unicast
conversion, because the multicast traffic will be unicast on 802.11
already (due to use of 4-addr mode).

- Felix

[toc] | [prev] | [next] | [standalone]

#1553677

FromLinus Lüssing <linus.luessing@c0d3.blue>
Date2017-01-07 16:20 +0100
Message-ID<sX0WK-24A-19@gated-at.bofh.it>
In reply to#1552759
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?

[toc] | [prev] | [next] | [standalone]

#1554137

FromJohannes Berg <johannes@sipsolutions.net>
Date2017-01-09 09:10 +0100
Message-ID<sXDbI-1Ae-9@gated-at.bofh.it>
In reply to#1553677
On Sat, 2017-01-07 at 16:15 +0100, Linus Lüssing wrote:

> Actually, I do not quite understand that remark in the mac80211
> multicast-to-unicast patch. IP should not care about the ethernet
> header?

But it does, for example RFC 1122 states:

         When a host sends a datagram to a link-layer broadcast address,
         the IP destination address MUST be a legal IP broadcast or IP
         multicast address.

         A host SHOULD silently discard a datagram that is received via
         a link-layer broadcast (see Section 2.4) but does not specify
         an IP multicast or broadcast destination address.

You can probably find other examples too.

johannes

[toc] | [prev] | [next] | [standalone]

#1554277

FromLinus Lüssing <linus.luessing@c0d3.blue>
Date2017-01-09 13:50 +0100
Message-ID<sXHyF-4eL-7@gated-at.bofh.it>
In reply to#1554137
On Mon, Jan 09, 2017 at 09:05:49AM +0100, Johannes Berg wrote:
> On Sat, 2017-01-07 at 16:15 +0100, Linus Lüssing wrote:
> 
> > Actually, I do not quite understand that remark in the mac80211
> > multicast-to-unicast patch. IP should not care about the ethernet
> > header?
> 
> But it does, for example RFC 1122 states:
> 
>          When a host sends a datagram to a link-layer broadcast address,
>          the IP destination address MUST be a legal IP broadcast or IP
>          multicast address.
> 
>          A host SHOULD silently discard a datagram that is received via
>          a link-layer broadcast (see Section 2.4) but does not specify
>          an IP multicast or broadcast destination address.

This example is the other way round. It specifies how the IP
destination should look like in case of link-layer broadcast. Not
how the link-layer destination should look like in case of a
multicast/broadcast IP destination.

Any other examples?

[toc] | [prev] | [next] | [standalone]

#1554279

FromJohannes Berg <johannes@sipsolutions.net>
Date2017-01-09 13:50 +0100
Message-ID<sXHyF-4eL-9@gated-at.bofh.it>
In reply to#1554277
> >          A host SHOULD silently discard a datagram that is received via
> >          a link-layer broadcast (see Section 2.4) but does not specify
> >          an IP multicast or broadcast destination address.
> 
> This example is the other way round. It specifies how the IP
> destination should look like in case of link-layer broadcast. Not
> how the link-layer destination should look like in case of a
> multicast/broadcast IP destination.

You stopped reading too early - snipped the context part for you :)

johannes

[toc] | [prev] | [next] | [standalone]

#1554782

FromLinus Lüssing <linus.luessing@c0d3.blue>
Date2017-01-10 00:20 +0100
Message-ID<sXRol-1WC-3@gated-at.bofh.it>
In reply to#1554279
On Mon, Jan 09, 2017 at 10:42:46PM +0100, Johannes Berg wrote:
> On Mon, 2017-01-09 at 22:33 +0100, Linus Lüssing wrote:
> > On Mon, Jan 09, 2017 at 01:44:03PM +0100, Johannes Berg wrote:
> > > 
> > > > >          A host SHOULD silently discard a datagram that is
> > > > > received via
> > > > >          a link-layer broadcast (see Section 2.4) but does not
> > > > > specify
> > > > >          an IP multicast or broadcast destination address.
> > > > 
> > > > This example is the other way round. It specifies how the IP
> > > > destination should look like in case of link-layer broadcast. Not
> > > > how the link-layer destination should look like in case of a
> > > > multicast/broadcast IP destination.
> > > 
> > > You stopped reading too early - snipped the context part for you :)
> > 
> > Sorry for writing to you directly, but I still have some
> > difficulties. In pseudo-code that line says:
> > 
> > -----
> > if ll_dst(pkt) == bcast AND ip_dst(pkt) != mcast/bcast:
> > -> drop(pkt)
> > -----
> > 
> > But after multicast-to-unicast conversion, we have:
> > 
> > -----
> > ll_dst(pkt) == ucast AND ip_dst(pkt) == mcast
> > -----
> > 
> > So none of the two requirements for dropping are matched?
> > 
> 
> Exactly. My point is that this is breaking the expectation that hosts
> are actually able to drop such packets.

[readding CCs I removed earlier]

Ah! Thanks. I was worried about creating packetloss :D.

Hm, for this other other way round, I think it does not apply for
the bridge multicast-to-unicast patch if I'm not misreading the bridge code:

For a packet with a link-layer multicast address but a unicast IP
destination, the bridge MDB lookup will fail.
(http://lxr.free-electrons.com/source/net/bridge/br_multicast.c?v=4.8#L178
 returns NULL)

Case A): No multicast router on port:
-> bridge, br_multicast_flood(), will drop the packet already
   (no matter if multicast-to-unicast is enabled or not)

Case B): Multicast router present on port:
-> The new patch does not apply multicast-to-unicast but just floods
   packet unaltered
   ("else { port = rport; addr = NULL; }" branch)

Regards, Linus

[toc] | [prev] | [next] | [standalone]

#1556313

FromJohannes Berg <johannes@sipsolutions.net>
Date2017-01-11 10:20 +0100
Message-ID<sYney-565-21@gated-at.bofh.it>
In reply to#1554782
> > Exactly. My point is that this is breaking the expectation that
> > hosts are actually able to drop such packets.
> 
> [readding CCs I removed earlier]
> 
> Ah! Thanks. I was worried about creating packetloss :D.

Ah, well, no - at least not in this case.

> Hm, for this other other way round, I think it does not apply for
> the bridge multicast-to-unicast patch if I'm not misreading the
> bridge code:
> 
> For a packet with a link-layer multicast address but a unicast IP
> destination, the bridge MDB lookup will fail.
> (http://lxr.free-electrons.com/source/net/bridge/br_multicast.c?v=4.8
> #L178
>  returns NULL)
> 
> Case A): No multicast router on port:
> -> bridge, br_multicast_flood(), will drop the packet already
>    (no matter if multicast-to-unicast is enabled or not)
> 
> Case B): Multicast router present on port:
> -> The new patch does not apply multicast-to-unicast but just floods
>    packet unaltered
>    ("else { port = rport; addr = NULL; }" branch)

Ah, interesting. This is different then - the mac80211 code is not L3
aware at all.

johannes

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web