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
| ||
|
Date: Sat, 20 Jun 2020 07:32:28 +0200 From: Daniel Mack <daniel@...que.org> To: Andrew Lunn <andrew@...n.ch> Cc: netdev@...r.kernel.org, Ido Schimmel <idosch@...sch.org>, Jiri Pirko <jiri@...nulli.us>, Ivan Vecera <ivecera@...hat.com>, Florian Fainelli <f.fainelli@...il.com> Subject: Re: Question on DSA switches, IGMP forwarding and switchdev Hi Andrew, Thanks a lot for the quick reply! On 6/19/20 11:58 PM, Andrew Lunn wrote: > On Fri, Jun 19, 2020 at 11:31:04PM +0200, Daniel Mack wrote: >> When an IGMP query enters the switch, it is redirected to the CPU port >> as all 'external' ports are configured for IGMP/MLP snooping by the >> driver. The issue that I'm seeing is that the Linux bridge does not >> forward the IGMP frames to any other port, no matter whether the bridge >> is in snooping mode or not. This needs to happen however, otherwise the >> stations will not see IGMP queries, and unsolicited membership reports >> are not being transferred either. > > I think all the testing i've done in this area i've had the bridge > acting as the IGMP queirer. Hence it has replied to the query, rather > than forward it out other ports. Yes, if the bridge is itself generating the queries, this works. > To get this far, has the bridge determined it is not the elected > querier? I guess it must of done. Otherwise it would not be > forwarding it. No, the querier is connected to one of the switch ports in a larger topology. But the bridge must still forward such frames, otherwise IGMP queries won't reach the senders, and membership reports won't reach the querier. > The problem here is: > > https://elixir.bootlin.com/linux/v5.8-rc1/source/net/dsa/tag_edsa.c#L159 Ah, right! > Setting offload_fwd_mark means the switch has forwarded the frame as > needed to other ports of the switch. If the frame is an IGMP query > frame, and the bridge is not the elected quierer, i guess we need to > set this false? Or we need an FDB in the switch to forward it. What > group address is being used? If such a frame is ingressing, the software bridge must be able to forward it again. So I suppose we need to set the forward flag to false here, yes. Thanks, Daniel
Powered by blists - more mailing lists