netdev - Re: [PATCH v3 net-next 0/5] IGMP snooping for local traffic

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: <20171107175849.GB15028@lunn.ch>
Date:   Tue, 7 Nov 2017 18:58:49 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Egil Hjelmeland <privat@...l-hjelmeland.no>
Cc:     David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH v3 net-next 0/5] IGMP snooping for local traffic

> Hi Andrew!
> 
> I tested this series today on my board with lan9303, and it does seem to
> work. But no extensive testing though.

Cool, thanks. I've only been able to test on Marvell hardware.

> Some observations, not meant to delay the series:
> 
> When local application join multicast; the driver get 2 X .port_mdb_prepare
> + 4 x .port_mdb_add for the address.

Humm, i would expect equal numbers of those.

> "bridge mdb" does not list local multicast memberships, is that a "feature"?

Yes. The br0 interface is not really a port of the bridge. It is
special. And hence many of the bridge commands don't list it.

> While I had an application joined on a multicast address; I restarted the
> networking: meaning deleting the bridge and setting it up again. No
> .port_mdb_del on the multicast address. Stopped the application. Still no
> .port_mdb_del on the multicast address. So the multicast address stays in
> the HW fdb, until I started and stopped the application again. Not really a
> problem, just an observation.

The bridge is working by snooping joins/leaves. When the application
joined the group, the kernel would of sent an IGMP report. This
triggers the snooping code to request the hardware to start forwarding
frames to the hardware. When the application quits, it might send a
leave. But it is not required. The bridge however has a timer. The
IGMP querier in your network should cause all active groups to send a
report every so often. This keeps the timer alive. If the timer
expires, the bridge should then delete the group from the hardware.

So try stopping your application, and waiting a while.

> Then finally, there is a more serious issue related to IGMPv2. As I
> suspected, with "IGMP snooping for local traffic", I have to activate "IGMP
> trapping" in the lan9303 HW in order to get it to work with a IGMPv2
> querier.

For Marvell hardware, it detects all IGMP frames and forwards them to
the CPU. It does not matter if they are IGMPv2 or v3.

> (Remember, unlike IGMPv3, IGMPv2 reports are "inband" in the
> group). The HW allows me to select which ports receive IGMP packets. The
> best is to only send to CPU, so the SW bridge can do the right thing in all
> situations. However, then we must make sure skb->offload_fwd_mark is zero
> for IGMP packets. Which was easy to do in my proof-of-concept test, but I
> suspect a proper test on ip->protocol is more complicated?

Humm, interesting. Not thought about that. And my testing has been
limited to a single switch. I will try to find a setup with multiple
switches and see what happens with the Marvell hardware.

Thanks
	Andrew