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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ee946686-699c-da64-4932-f58e3f1a83ad@quantenna.com>
Date:   Wed, 11 Jan 2017 15:15:30 +0300
From:   IgorMitsyanko <igor.mitsyanko.os@...ntenna.com>
To:     Felix Fietkau <nbd@....name>,
        Johannes Berg <johannes@...solutions.net>,
        Linus Lüssing <linus.luessing@...3.blue>,
        Stephen Hemminger <stephen@...workplumber.org>
CC:     <netdev@...r.kernel.org>, <bridge@...ts.linux-foundation.org>,
        <linux-wireless@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        "M. Braun" <michael-dev@...i-braun.de>
Subject: Re: [PATCH net-next] bridge: multicast to unicast

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).

"Client bridge" approach should not concern us here I think, it will
seem to AP and AP's bridge as a single client.

>
> - Felix