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]
Date:   Fri, 14 Jul 2017 11:30:54 -0400
From:   Vivien Didelot <vivien.didelot@...oirfairelinux.com>
To:     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

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?

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?


Regards,

        Vivien

Powered by blists - more mailing lists