netdev - Re: [PATCH net-next] netlink: add igmp join/leave notifications

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]

Message-ID: <CADXeF1F7nR02ZDKBEa=SXDbfgP9ZGumuzZkf3WSeomhrsntfDw@mail.gmail.com>
Date: Thu, 14 Nov 2024 23:19:29 +0900
From: Yuyang Huang <yuyanghuang@...gle.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Hangbin Liu <liuhangbin@...il.com>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Simon Horman <horms@...nel.org>, David Ahern <dsahern@...nel.org>, roopa@...ulusnetworks.com, 
	jiri@...nulli.us, stephen@...workplumber.org, netdev@...r.kernel.org, 
	Maciej Żenczykowski <maze@...gle.com>, 
	Lorenzo Colitti <lorenzo@...gle.com>
Subject: Re: [PATCH net-next] netlink: add igmp join/leave notifications

>You are still focused or your narrow use case. Why is this only for
>WiFi? Why cannot i use it for other systems using IGMP? Switches? VPN
>servers? etc. We want a generic solution for all use cases, not just
>some obscure niche.

>And Linux does not care about commercial devices. And you would never
>implement this in the driver itself, that would immediately gets
>NACKed because it is not generic, but the concept should be generic.

Thanks for the further feedback! I've revised the commit message to
discuss more generic use cases without mentioning specific drivers or
devices. I also removed the discussion about commercial devices.
Please take another look and let me know if it needs further
adjustments.

```
netlink: add IGMP/MLD join/leave notifications

This change introduces netlink notifications for multicast address
changes. The following features are included:
* Addition and deletion of multicast addresses are reported using
  RTM_NEWMULTICAST and RTM_DELMULTICAST messages with AF_INET and
  AF_INET6.
* Two new notification groups: RTNLGRP_IPV4_MCADDR and
  RTNLGRP_IPV6_MCADDR are introduced for receiving these events.

This change allows user space applications (e.g., ip monitor) to
efficiently track multicast group memberships by listening for netlink
events. Previously, applications relied on inefficient polling of
procfs, introducing delays. With netlink notifications, applications
receive realtime updates on multicast group membership changes,
enabling more precise metrics collection and system monitoring.

This change also unlocks the potential for implementing a wide range
of sophisticated multicast related features in user space by allowing
applications to combine kernel provided multicast address information
with user space data and communicate decisions back to the kernel for
more fine grained control. This mechanism can be used for various
purposes, including multicast filtering, IGMP/MLD offload, and
IGMP/MLD snooping.
```

Thanks,
Yuyang

On Thu, Nov 14, 2024 at 10:26 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > This change also empowers user space applications to manage multicast
> > filters and IGMP/MLD offload rules using the same netlink notification
> > mechanism. This allows applications to dynamically adjust rules and
> > configurations via generic netlink communication with the Wi-Fi driver,
> > offering greater flexibility and updatability compared to implementing
> > all logic within the driver itself. This is a key consideration for some
> > commercial devices.
>
> You are still focused or your narrow use case. Why is this only for
> WiFi? Why cannot i use it for other systems using IGMP? Switches? VPN
> servers? etc. We want a generic solution for all use cases, not just
> some obscure niche.
>
> And Linux does not care about commercial devices. And you would never
> implement this in the driver itself, that would immediately gets
> NACKed because it is not generic, but the concept should be generic.
>
>         Andrew