[PATCH iproute2-next, v3 1/2] iproute2: expose netlink constants in UAPI

[PATCH iproute2-next, v3 1/2] iproute2: expose netlink constants in UAPI

[Yuyang Huang]

This change adds the following multicast related netlink constants to
the UAPI:

* RTNLGRP_IPV4_MCADDR and RTNLGRP_IPV6_MCADDR: Netlink multicast
  groups for IPv4 and IPv6 multicast address changes.
* RTM_NEWMULTICAST and RTM_DELMULTICAST: Netlink message types for
  multicast address additions and deletions.

Exposing these constants in the UAPI enables ip monitor to effectively
monitor and manage multicast group memberships.

Cc: Maciej Żenczykowski <maze@google.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Yuyang Huang <yuyanghuang@google.com>
---

Changelog since v2:
- Align RTM_NEWMULTICAST and RTM_GETMULTICAST enum definitions with
  existing code style.

 include/uapi/linux/rtnetlink.h | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 4e6c8e14..04be20ee 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -93,7 +93,11 @@ enum {
 	RTM_NEWPREFIX	= 52,
 #define RTM_NEWPREFIX	RTM_NEWPREFIX
 
-	RTM_GETMULTICAST = 58,
+	RTM_NEWMULTICAST = 56,
+#define RTM_NEWMULTICAST RTM_NEWMULTICAST
+	RTM_DELMULTICAST,
+#define RTM_DELMULTICAST RTM_DELMULTICAST
+	RTM_GETMULTICAST,
 #define RTM_GETMULTICAST RTM_GETMULTICAST
 
 	RTM_GETANYCAST	= 62,
@@ -772,6 +776,10 @@ enum rtnetlink_groups {
 #define RTNLGRP_TUNNEL		RTNLGRP_TUNNEL
 	RTNLGRP_STATS,
 #define RTNLGRP_STATS		RTNLGRP_STATS
+	RTNLGRP_IPV4_MCADDR,
+#define RTNLGRP_IPV4_MCADDR	RTNLGRP_IPV4_MCADDR
+	RTNLGRP_IPV6_MCADDR,
+#define RTNLGRP_IPV6_MCADDR    RTNLGRP_IPV6_MCADDR
 	__RTNLGRP_MAX
 };
 #define RTNLGRP_MAX	(__RTNLGRP_MAX - 1)
-- 
2.47.0.338.g60cca15819-goog

[PATCH iproute2-next, v3 2/2] iproute2: add 'ip monitor mcaddr' support

[Yuyang Huang]

Enhanced the 'ip monitor' command to track changes in IPv4 and IPv6
multicast addresses. This update allows the command to listen for
events related to multicast address additions and deletions by
registering to the newly introduced RTNLGRP_IPV4_MCADDR and
RTNLGRP_IPV6_MCADDR netlink groups.

This patch depends on the kernel patch that adds RTNLGRP_IPV4_MCADDR
and RTNLGRP_IPV6_MCADDR being merged first.

Here is an example usage:

root@uml-x86-64:/# ip monitor mcaddr
8: nettest123    inet6 mcast ff01::1 scope global
8: nettest123    inet6 mcast ff02::1 scope global
8: nettest123    inet mcast 224.0.0.1 scope global
8: nettest123    inet6 mcast ff02::1:ff00:7b01 scope global
Deleted 8: nettest123    inet mcast 224.0.0.1 scope global
Deleted 8: nettest123    inet6 mcast ff02::1:ff00:7b01 scope global
Deleted 8: nettest123    inet6 mcast ff02::1 scope global

Cc: Maciej Żenczykowski <maze@google.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Yuyang Huang <yuyanghuang@google.com>
---

Changelog since v1:
- Move the UAPI constants to a separate patch.
- Update the commit message.
- Fix the indentation format.

 ip/ipaddress.c | 17 +++++++++++++++--
 ip/ipmonitor.c | 25 ++++++++++++++++++++++++-
 2 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index d90ba94d..373f613f 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -1504,7 +1504,10 @@ int print_addrinfo(struct nlmsghdr *n, void *arg)
 
 	SPRINT_BUF(b1);
 
-	if (n->nlmsg_type != RTM_NEWADDR && n->nlmsg_type != RTM_DELADDR)
+	if (n->nlmsg_type != RTM_NEWADDR
+	    && n->nlmsg_type != RTM_DELADDR
+	    && n->nlmsg_type != RTM_NEWMULTICAST
+	    && n->nlmsg_type != RTM_DELMULTICAST)
 		return 0;
 	len -= NLMSG_LENGTH(sizeof(*ifa));
 	if (len < 0) {
@@ -1564,7 +1567,7 @@ int print_addrinfo(struct nlmsghdr *n, void *arg)
 
 	print_headers(fp, "[ADDR]");
 
-	if (n->nlmsg_type == RTM_DELADDR)
+	if (n->nlmsg_type == RTM_DELADDR || n->nlmsg_type == RTM_DELMULTICAST)
 		print_bool(PRINT_ANY, "deleted", "Deleted ", true);
 
 	if (!brief) {
@@ -1639,6 +1642,16 @@ int print_addrinfo(struct nlmsghdr *n, void *arg)
 						   rta_tb[IFA_ANYCAST]));
 	}
 
+	if (rta_tb[IFA_MULTICAST]) {
+		print_string(PRINT_FP, NULL, "%s ", "mcast");
+		print_color_string(PRINT_ANY,
+				   ifa_family_color(ifa->ifa_family),
+				   "multicast",
+				   "%s ",
+				   format_host_rta(ifa->ifa_family,
+						   rta_tb[IFA_MULTICAST]));
+	}
+
 	print_string(PRINT_ANY,
 		     "scope",
 		     "scope %s ",
diff --git a/ip/ipmonitor.c b/ip/ipmonitor.c
index de67f2c9..4743b3e1 100644
--- a/ip/ipmonitor.c
+++ b/ip/ipmonitor.c
@@ -30,7 +30,7 @@ static void usage(void)
 	fprintf(stderr,
 		"Usage: ip monitor [ all | OBJECTS ] [ FILE ] [ label ] [ all-nsid ]\n"
 		"                  [ dev DEVICE ]\n"
-		"OBJECTS :=  address | link | mroute | neigh | netconf |\n"
+		"OBJECTS :=  address | link | mroute | mcaddr | neigh | netconf |\n"
 		"            nexthop | nsid | prefix | route | rule | stats\n"
 		"FILE := file FILENAME\n");
 	exit(-1);
@@ -152,6 +152,11 @@ static int accept_msg(struct rtnl_ctrl_data *ctrl,
 		ipstats_print(n, arg);
 		return 0;
 
+	case RTM_DELMULTICAST:
+	case RTM_NEWMULTICAST:
+		print_addrinfo(n, arg);
+		return 0;
+
 	case NLMSG_ERROR:
 	case NLMSG_NOOP:
 	case NLMSG_DONE:
@@ -178,6 +183,7 @@ static int accept_msg(struct rtnl_ctrl_data *ctrl,
 #define IPMON_LRULE		BIT(8)
 #define IPMON_LNSID		BIT(9)
 #define IPMON_LNEXTHOP		BIT(10)
+#define IPMON_LMCADDR		BIT(11)
 
 #define IPMON_L_ALL		(~0)
 
@@ -220,6 +226,8 @@ int do_ipmonitor(int argc, char **argv)
 			lmask |= IPMON_LNEXTHOP;
 		} else if (strcmp(*argv, "stats") == 0) {
 			lmask |= IPMON_LSTATS;
+		} else if (strcmp(*argv, "mcaddr") == 0) {
+			lmask |= IPMON_LMCADDR;
 		} else if (strcmp(*argv, "all") == 0) {
 			prefix_banner = 1;
 		} else if (matches(*argv, "all-nsid") == 0) {
@@ -326,6 +334,21 @@ int do_ipmonitor(int argc, char **argv)
 		exit(1);
 	}
 
+	if (lmask & IPMON_LMCADDR) {
+		if ((!preferred_family || preferred_family == AF_INET) &&
+		    rtnl_add_nl_group(&rth, RTNLGRP_IPV4_MCADDR) < 0) {
+			fprintf(stderr,
+				"Failed to add ipv4 mcaddr group to list\n");
+			exit(1);
+		}
+		if ((!preferred_family || preferred_family == AF_INET6) &&
+		    rtnl_add_nl_group(&rth, RTNLGRP_IPV6_MCADDR) < 0) {
+			fprintf(stderr,
+				"Failed to add ipv6 mcaddr group to list\n");
+			exit(1);
+		}
+	}
+
 	if (listen_all_nsid && rtnl_listen_all_nsid(&rth) < 0)
 		exit(1);
 
-- 
2.47.0.338.g60cca15819-goog

Re: [PATCH iproute2-next, v3 2/2] iproute2: add 'ip monitor mcaddr' support

[Nicolas Dichtel]

Le 04/12/2024 à 15:02, Yuyang Huang a écrit :
> Enhanced the 'ip monitor' command to track changes in IPv4 and IPv6
> multicast addresses. This update allows the command to listen for
> events related to multicast address additions and deletions by
> registering to the newly introduced RTNLGRP_IPV4_MCADDR and
> RTNLGRP_IPV6_MCADDR netlink groups.
> 
> This patch depends on the kernel patch that adds RTNLGRP_IPV4_MCADDR
> and RTNLGRP_IPV6_MCADDR being merged first.
> 
> Here is an example usage:
> 
> root@uml-x86-64:/# ip monitor mcaddr

Note that 'ip maddr' (see 'man ip-maddress') already exists. Using 'mcaddr' for
'ip monitor' is confusing.

You could also update man/man8/ip-monitor.8


Regards,
Nicolas

Re: [PATCH iproute2-next, v3 2/2] iproute2: add 'ip monitor mcaddr' support

[Yuyang Huang]

Thanks for the review feedback.

>Note that 'ip maddr' (see 'man ip-maddress') already exists. Using 'mcaddr' for
>'ip monitor' is confusing.

Please allow me to confirm the suggestion, would it be less confusing
if I use 'ip monitor maddr' here, or should I use a completely
different name?

> You could also update man/man8/ip-monitor.8

Acked, I will update the document in the next version of the patch.

Thanks,
Yuyang



On Wed, Dec 4, 2024 at 11:17 PM Nicolas Dichtel
<nicolas.dichtel@6wind.com> wrote:
>
> Le 04/12/2024 à 15:02, Yuyang Huang a écrit :
> > Enhanced the 'ip monitor' command to track changes in IPv4 and IPv6
> > multicast addresses. This update allows the command to listen for
> > events related to multicast address additions and deletions by
> > registering to the newly introduced RTNLGRP_IPV4_MCADDR and
> > RTNLGRP_IPV6_MCADDR netlink groups.
> >
> > This patch depends on the kernel patch that adds RTNLGRP_IPV4_MCADDR
> > and RTNLGRP_IPV6_MCADDR being merged first.
> >
> > Here is an example usage:
> >
> > root@uml-x86-64:/# ip monitor mcaddr
>
> Note that 'ip maddr' (see 'man ip-maddress') already exists. Using 'mcaddr' for
> 'ip monitor' is confusing.
>
> You could also update man/man8/ip-monitor.8
>
>
> Regards,
> Nicolas

Re: [PATCH iproute2-next, v3 1/2] iproute2: expose netlink constants in UAPI

[Stephen Hemminger]

On Wed,  4 Dec 2024 23:02:07 +0900
Yuyang Huang <yuyanghuang@google.com> wrote:

> This change adds the following multicast related netlink constants to
> the UAPI:
> 
> * RTNLGRP_IPV4_MCADDR and RTNLGRP_IPV6_MCADDR: Netlink multicast
>   groups for IPv4 and IPv6 multicast address changes.
> * RTM_NEWMULTICAST and RTM_DELMULTICAST: Netlink message types for
>   multicast address additions and deletions.
> 
> Exposing these constants in the UAPI enables ip monitor to effectively
> monitor and manage multicast group memberships.
> 
> Cc: Maciej Żenczykowski <maze@google.com>
> Cc: Lorenzo Colitti <lorenzo@google.com>
> Signed-off-by: Yuyang Huang <yuyanghuang@google.com>
> ---

This should get automatically picked up when David does header update.

Re: [PATCH iproute2-next, v3 1/2] iproute2: expose netlink constants in UAPI

[Yuyang Huang]

> This should get automatically picked up when David does header update.

Thanks for the suggestion, I need the header patch to make my patch
series build.
Based on the previous review feedback, when David merges the patch
series, this patch will be skipped.

Link: https://lore.kernel.org/netdev/c97dd18b-8f67-4d22-a088-d73268402261@kernel.org/

Thanks,
Yuyang


On Thu, Dec 5, 2024 at 1:29 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Wed,  4 Dec 2024 23:02:07 +0900
> Yuyang Huang <yuyanghuang@google.com> wrote:
>
> > This change adds the following multicast related netlink constants to
> > the UAPI:
> >
> > * RTNLGRP_IPV4_MCADDR and RTNLGRP_IPV6_MCADDR: Netlink multicast
> >   groups for IPv4 and IPv6 multicast address changes.
> > * RTM_NEWMULTICAST and RTM_DELMULTICAST: Netlink message types for
> >   multicast address additions and deletions.
> >
> > Exposing these constants in the UAPI enables ip monitor to effectively
> > monitor and manage multicast group memberships.
> >
> > Cc: Maciej Żenczykowski <maze@google.com>
> > Cc: Lorenzo Colitti <lorenzo@google.com>
> > Signed-off-by: Yuyang Huang <yuyanghuang@google.com>
> > ---
>
> This should get automatically picked up when David does header update.

Re: [PATCH iproute2-next, v3 2/2] iproute2: add 'ip monitor mcaddr' support

[Nicolas Dichtel]

Le 04/12/2024 à 15:48, Yuyang Huang a écrit :
> Thanks for the review feedback.
> 
>> Note that 'ip maddr' (see 'man ip-maddress') already exists. Using 'mcaddr' for
>> 'ip monitor' is confusing.
> 
> Please allow me to confirm the suggestion, would it be less confusing
> if I use 'ip monitor maddr' here, or should I use a completely
> different name?
It's not the same API (netlink vs /proc) but the same objects at the end. It
seems better to me to have the same name. It enables updating the netlink API
later to get the same info as the one get in /proc.


Regards,
Nicolas

Re: [PATCH iproute2-next, v3 2/2] iproute2: add 'ip monitor mcaddr' support

[Yuyang Huang]

>It's not the same API (netlink vs /proc) but the same objects at the end. It
>seems better to me to have the same name. It enables updating the netlink API
>later to get the same info as the one get in /proc.

Thanks for the confirmation. I will use 'ip monitor maddr' in the next
patch version.

Thanks,
Yuyang

On Thu, Dec 5, 2024 at 5:26 PM Nicolas Dichtel
<nicolas.dichtel@6wind.com> wrote:
>
> Le 04/12/2024 à 15:48, Yuyang Huang a écrit :
> > Thanks for the review feedback.
> >
> >> Note that 'ip maddr' (see 'man ip-maddress') already exists. Using 'mcaddr' for
> >> 'ip monitor' is confusing.
> >
> > Please allow me to confirm the suggestion, would it be less confusing
> > if I use 'ip monitor maddr' here, or should I use a completely
> > different name?
> It's not the same API (netlink vs /proc) but the same objects at the end. It
> seems better to me to have the same name. It enables updating the netlink API
> later to get the same info as the one get in /proc.
>
>
> Regards,
> Nicolas