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]

Date:   Wed, 8 Nov 2017 16:11:12 +0100
From:   Egil Hjelmeland <privat@...l-hjelmeland.no>
To:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Cc:     David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH v3 net-next 0/5] IGMP snooping for local traffic

On 07. nov. 2017 18:58, Andrew Lunn wrote:
>> Hi Andrew!
>>
>> 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.
> 

To be precise: it is (1 .port_mdb_prepare + 2 x .port_mdb_add), two times.

I see that the outer repeat is due to netdev_for_each_lower_dev() in 
br_mdb_switchdev_host(). So that means we get one notification for each 
dsa-port which is joined to the bridge.

But _all_ .port_mdb_add are repeated twice as well. This is more 
interesting. I suspect that there is a missing "return 0;" in 
dsa_switch_mdb_add(), at the end of the "if 
(switchdev_trans_ph_prepare(trans)) {". Dating back to
a1a6b7ea7f2de270a51360cc48e7c49f7a283dda.

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

I waited 10 minutes after stopping the application, still no cleanup. 
That was the case when restarted the networking while the application 
was running.

But when stopping the application having not restarted the networking, 
the .port_mdb_del happen within few seconds.

Cheers
Egil