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] [day] [month] [year] [list]
Date:   Sun, 16 Jul 2017 11:17:54 +0300
From:   Yotam Gigi <yotamg@...lanox.com>
To:     Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        Andrew Lunn <andrew@...n.ch>, Elad Raz <eladr@...lanox.com>,
        Ido Schimmel <idosch@...lanox.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Cc:     netdev <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: IGMP snooping, switchdev and local multicast receiver on br
 interface

On 07/14/2017 06:30 PM, Vivien Didelot wrote:
> Hi All,
>
> Andrew Lunn <andrew@...n.ch> writes:
>
>> I've been testing IGMP snooping support with DSA, putting MDB entries
>> into the switch so that traffic only goes out ports where there has
>> been an interest indicated via IGMP. It mostly works, but i've come
>> across one use case which does not.
>>
>> I have a multicast listener running on the host, performing a
>> setsockopt(IP_ADD_MEMBERSHIP) on the bridge interface. It is not an
>> unreasonable thing to want to do, e.g. a WiFi access point listening
>> to mDNS, or running other multicast protocols, a STB wanting to
>> receive a multicast video stream to display on the set, etc.
>>
>> I'm not seeing any switchdev operations when the IP_ADD_MEMBERSHIP is
>> called. So there is no indication that the switch should add an MDB
>> entry to forward traffic to the host.
>>
>> Im i missing something, or is this not implemented?

You are not missing, we did not add that support yet. Currently the hardware MDB
does not get updated with mcast_routers. The flood tables does get updated
though.

> I follow Andrew's question with another multicast issue I'm having:
>
> It seems like there is no way to add a multicast group via its MAC
> address. All iproute2 and kernel bridge code assumes IP multicast
> (0x0800 IPv4 and 0x86DD IPv6.)
>
> But there are valid cases where you might want to add an L2 multicast
> group on a specific VLAN ID, e.g. for 0x88F7 PTP, 0x88BA Multicast
> sampled values, one of the 802.1D reserved 01-80-C2-* addresses, or any
> proprietary protocol addresses.
>
> There is the ip-maddress VLAN-unaware tool using RTM_NEWADDR which isn't
> bound to switchdev, or bridge-mdb which only accepts a IPv4 or IPv6 grp.
>
> I tried to hack a PoC in iproute2 (http://ix.io/yuJ) but the kernel
> counterpart is not trivial at all. *br_mdb_entry only play with br_ip...
>
> Any thoughts on this?

We did not have this usecase yet, but what you say make perfect sense :)

It is weird for me too that one can not configure MDB with MAC address.

>
> Regards,
>
>         Vivien

Powered by blists - more mailing lists