From: Patrick Ruddy <hidden> Date: 2018-08-31 00:36:09
This patch is an update to https://patchwork.ozlabs.org/patch/571127/. The
previous patch was based on sending multicast MAC addresses in the
netlink messages to allow the programming of hardware. It was agreed to
rework this to use RTM_NEW/DELLINK messages which were more appropriate
for layer 2 addresses.
In the interim period it has become apparent that the applications actually
needs to see the L3 multicast addresses which are joined for FORUS
processing so this patch has been reworked to send the L3 multicast
addresses using RTM_NEW/DELADDR.
These new multicast L3 netlink notifications should use the IFA_MULTICAST
address type but this has been dropped in favour of IFA_ADDRESS as during
testing it was noticed that some applications - notably getaddrinfo in
lib6c assume that there is an IFA_ADDRESS in a RTM_NEW/DELADDR and
blindly dereference it.
Finally the RTM_GETADDR for both address families has been modified to
include the multicast l3 addresses.
Patrick Ruddy (2):
netlink: ipv4 IGMP join notifications
netlink: ipv6 MLD join notifications
include/linux/igmp.h | 2 +
net/ipv4/devinet.c | 39 +++++++++++++------
net/ipv4/igmp.c | 90 ++++++++++++++++++++++++++++++++++++++++++++
net/ipv6/addrconf.c | 44 ++++++++++++++++------
net/ipv6/mcast.c | 66 ++++++++++++++++++++++++++++++++
5 files changed, 218 insertions(+), 23 deletions(-)
--
2.17.1
From: Patrick Ruddy <hidden> Date: 2018-08-30 14:53:03
Some userspace applications need to know about MLD joins from the
kernel for 2 reasons:
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWADDR and RTM_DELADDR messages. It also provides
the RTM_GETADDR extension to allow multicast join state to be read
from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
net/ipv6/addrconf.c | 44 +++++++++++++++++++++---------
net/ipv6/mcast.c | 66 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 98 insertions(+), 12 deletions(-)
@@ -5029,16 +5031,34 @@ static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,staticintinet6_dump_ifaddr(structsk_buff*skb,structnetlink_callback*cb){-enumaddr_type_ttype=UNICAST_ADDR;+enumaddr_type_ttype;+intret;++type=cb->args[3];+if(type==UNICAST_ADDR){+ret==inet6_dump_addr(skb,cb,type,RTM_NEWADDR);+if(ret>0)+gotodone;-returninet6_dump_addr(skb,cb,type);+/* reset indices and move on to multicast*/+cb->args[0]=0;+cb->args[1]=0;+cb->args[2]=0;+type=MULTICAST_ADDR;+}++/* do the RTM_NEWADDR notifications for multicast type */+ret=inet6_dump_addr(skb,cb,type,RTM_NEWADDR);+done:+cb->args[3]=type;+returnret;}staticintinet6_dump_ifmcaddr(structsk_buff*skb,structnetlink_callback*cb){enumaddr_type_ttype=MULTICAST_ADDR;-returninet6_dump_addr(skb,cb,type);+returninet6_dump_addr(skb,cb,type,RTM_GETMULTICAST);}
From: Patrick Ruddy <hidden> Date: 2018-08-30 15:07:47
Some userspace applications need to know about IGMP joins from the kernel
for 2 reasons
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWADDR and RTM_DELADDR messages. It also provides
the RTM_GETADDR extension to allow multicast join state to be read
from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
include/linux/igmp.h | 2 +
net/ipv4/devinet.c | 39 +++++++++++++------
net/ipv4/igmp.c | 90 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 120 insertions(+), 11 deletions(-)
From: Patrick Ruddy <hidden> Date: 2018-08-30 20:47:36
Don't know what happened to the 0/2 cover for this series so here it
is:
This patch is an update to https://patchwork.ozlabs.org/patch/571127/.
The
previous patch was based on sending multicast MAC addresses in the
netlink messages to allow the programming of hardware. It was agreed to
rework this to use RTM_NEW/DELLINK messages which were more appropriate
for layer 2 addresses.
In the interim period it has become apparent that the applications
actually
needs to see the L3 multicast addresses which are joined for FORUS
processing so this patch has been reworked to send the L3 multicast
addresses using RTM_NEW/DELADDR.
These new multicast L3 netlink notifications should use the
IFA_MULTICAST
address type but this has been dropped in favour of IFA_ADDRESS as
during
testing it was noticed that some applications - notably getaddrinfo in
lib6c assume that there is an IFA_ADDRESS in a RTM_NEW/DELADDR and
blindly dereference it.
Finally the RTM_GETADDR for both address families has been modified to
include the multicast l3 addresses.
Patrick Ruddy (2):
netlink: ipv4 IGMP join notifications
netlink: ipv6 MLD join notifications
include/linux/igmp.h | 2 +
net/ipv4/devinet.c | 39 +++++++++++++------
net/ipv4/igmp.c | 90 ++++++++++++++++++++++++++++++++++++++++++++
net/ipv6/addrconf.c | 44 ++++++++++++++++------
net/ipv6/mcast.c | 66 ++++++++++++++++++++++++++++++++
5 files changed, 218 insertions(+), 23 deletions(-)
--
2.17.1
On Thu, 2018-08-30 at 10:35 +0100, Patrick Ruddy wrote:
quoted hunk
Some userspace applications need to know about IGMP joins from the kernel
for 2 reasons
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWADDR and RTM_DELADDR messages. It also provides
the RTM_GETADDR extension to allow multicast join state to be read
from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
include/linux/igmp.h | 2 +
net/ipv4/devinet.c | 39 +++++++++++++------
net/ipv4/igmp.c | 90 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 120 insertions(+), 11 deletions(-)
From: kbuild test robot <hidden> Date: 2018-08-31 08:30:15
Hi Patrick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Patrick-Ruddy/netlink-ipv4-IGMP-join-notifications/20180831-105548
config: i386-randconfig-s0-201834 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from net//ipv4/udp.c:92:0:
quoted
include/linux/igmp.h:133:58: warning: 'struct netlink_callback' declared inside parameter list will not be visible outside of this definition or declaration
extern int ip_mc_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb,
^~~~~~~~~~~~~~~~
vim +133 include/linux/igmp.h
108
109 extern int ip_check_mc_rcu(struct in_device *dev, __be32 mc_addr, __be32 src_addr, u8 proto);
110 extern int igmp_rcv(struct sk_buff *);
111 extern int ip_mc_join_group(struct sock *sk, struct ip_mreqn *imr);
112 extern int ip_mc_join_group_ssm(struct sock *sk, struct ip_mreqn *imr,
113 unsigned int mode);
114 extern int ip_mc_leave_group(struct sock *sk, struct ip_mreqn *imr);
115 extern void ip_mc_drop_socket(struct sock *sk);
116 extern int ip_mc_source(int add, int omode, struct sock *sk,
117 struct ip_mreq_source *mreqs, int ifindex);
118 extern int ip_mc_msfilter(struct sock *sk, struct ip_msfilter *msf,int ifindex);
119 extern int ip_mc_msfget(struct sock *sk, struct ip_msfilter *msf,
120 struct ip_msfilter __user *optval, int __user *optlen);
121 extern int ip_mc_gsfget(struct sock *sk, struct group_filter *gsf,
122 struct group_filter __user *optval, int __user *optlen);
123 extern int ip_mc_sf_allow(struct sock *sk, __be32 local, __be32 rmt,
124 int dif, int sdif);
125 extern void ip_mc_init_dev(struct in_device *);
126 extern void ip_mc_destroy_dev(struct in_device *);
127 extern void ip_mc_up(struct in_device *);
128 extern void ip_mc_down(struct in_device *);
129 extern void ip_mc_unmap(struct in_device *);
130 extern void ip_mc_remap(struct in_device *);
131 extern void ip_mc_dec_group(struct in_device *in_dev, __be32 addr);
132 extern void ip_mc_inc_group(struct in_device *in_dev, __be32 addr);
> 133 extern int ip_mc_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb,
134 struct net_device *dev);
135 int ip_mc_check_igmp(struct sk_buff *skb, struct sk_buff **skb_trimmed);
136
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
From: kbuild test robot <hidden> Date: 2018-08-31 09:04:05
Hi Patrick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Patrick-Ruddy/netlink-ipv4-IGMP-join-notifications/20180831-105548
config: i386-randconfig-a1-201834 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from net//bridge/br_multicast.c:16:0:
quoted
include/linux/igmp.h:134:16: warning: 'struct netlink_callback' declared inside parameter list
struct net_device *dev);
^
quoted
include/linux/igmp.h:134:16: warning: its scope is only this definition or declaration, which is probably not what you want
vim +134 include/linux/igmp.h
108
109 extern int ip_check_mc_rcu(struct in_device *dev, __be32 mc_addr, __be32 src_addr, u8 proto);
110 extern int igmp_rcv(struct sk_buff *);
111 extern int ip_mc_join_group(struct sock *sk, struct ip_mreqn *imr);
112 extern int ip_mc_join_group_ssm(struct sock *sk, struct ip_mreqn *imr,
113 unsigned int mode);
114 extern int ip_mc_leave_group(struct sock *sk, struct ip_mreqn *imr);
115 extern void ip_mc_drop_socket(struct sock *sk);
116 extern int ip_mc_source(int add, int omode, struct sock *sk,
117 struct ip_mreq_source *mreqs, int ifindex);
118 extern int ip_mc_msfilter(struct sock *sk, struct ip_msfilter *msf,int ifindex);
119 extern int ip_mc_msfget(struct sock *sk, struct ip_msfilter *msf,
120 struct ip_msfilter __user *optval, int __user *optlen);
121 extern int ip_mc_gsfget(struct sock *sk, struct group_filter *gsf,
122 struct group_filter __user *optval, int __user *optlen);
123 extern int ip_mc_sf_allow(struct sock *sk, __be32 local, __be32 rmt,
124 int dif, int sdif);
125 extern void ip_mc_init_dev(struct in_device *);
126 extern void ip_mc_destroy_dev(struct in_device *);
127 extern void ip_mc_up(struct in_device *);
128 extern void ip_mc_down(struct in_device *);
129 extern void ip_mc_unmap(struct in_device *);
130 extern void ip_mc_remap(struct in_device *);
131 extern void ip_mc_dec_group(struct in_device *in_dev, __be32 addr);
132 extern void ip_mc_inc_group(struct in_device *in_dev, __be32 addr);
133 extern int ip_mc_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb,
> 134 struct net_device *dev);
135 int ip_mc_check_igmp(struct sk_buff *skb, struct sk_buff **skb_trimmed);
136
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
From: kbuild test robot <hidden> Date: 2018-08-31 09:41:53
Hi Patrick,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Patrick-Ruddy/netlink-ipv4-IGMP-join-notifications/20180831-105548
config: i386-randconfig-s0-201834 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net/ipv6/addrconf.c: In function 'inet6_dump_ifaddr':
quoted
net/ipv6/addrconf.c:5039:10: error: expected expression before '=' token
ret = = inet6_dump_addr(skb, cb, type, RTM_NEWADDR);
^
vim +5039 net/ipv6/addrconf.c
5031
5032 static int inet6_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
5033 {
5034 enum addr_type_t type;
5035 int ret;
5036
5037 type = cb->args[3];
5038 if (type == UNICAST_ADDR) {
5039 ret = = inet6_dump_addr(skb, cb, type, RTM_NEWADDR);
5040 if (ret > 0)
5041 goto done;
5042
5043 /* reset indices and move on to multicast*/
5044 cb->args[0] = 0;
5045 cb->args[1] = 0;
5046 cb->args[2] = 0;
5047 type = MULTICAST_ADDR;
5048 }
5049
5050 /* do the RTM_NEWADDR notifications for multicast type */
5051 ret = inet6_dump_addr(skb, cb, type, RTM_NEWADDR);
5052 done:
5053 cb->args[3] = type;
5054 return ret;
5055 }
5056
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
From: Patrick Ruddy <hidden> Date: 2018-08-31 15:27:43
Some userspace applications need to know about IGMP joins from the kernel
for 2 reasons
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWADDR and RTM_DELADDR messages. It also provides
the RTM_GETADDR extension to allow multicast join state to be read
from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
v2: fix kbuild warnings.
include/linux/igmp.h | 4 ++
net/ipv4/devinet.c | 39 +++++++++++++------
net/ipv4/igmp.c | 90 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 122 insertions(+), 11 deletions(-)
From: Patrick Ruddy <hidden> Date: 2018-08-31 15:27:52
Some userspace applications need to know about MLD joins from the
kernel for 2 reasons:
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWADDR and RTM_DELADDR messages. It also provides
the RTM_GETADDR extension to allow multicast join state to be read
from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
v2: fix kbuild issues.
net/ipv6/addrconf.c | 44 +++++++++++++++++++++---------
net/ipv6/mcast.c | 66 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 98 insertions(+), 12 deletions(-)
@@ -5029,16 +5031,34 @@ static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,staticintinet6_dump_ifaddr(structsk_buff*skb,structnetlink_callback*cb){-enumaddr_type_ttype=UNICAST_ADDR;+enumaddr_type_ttype;+intret;++type=cb->args[3];+if(type==UNICAST_ADDR){+ret=inet6_dump_addr(skb,cb,type,RTM_NEWADDR);+if(ret>0)+gotodone;-returninet6_dump_addr(skb,cb,type);+/* reset indices and move on to multicast*/+cb->args[0]=0;+cb->args[1]=0;+cb->args[2]=0;+type=MULTICAST_ADDR;+}++/* do the RTM_NEWADDR notifications for multicast type */+ret=inet6_dump_addr(skb,cb,type,RTM_NEWADDR);+done:+cb->args[3]=type;+returnret;}staticintinet6_dump_ifmcaddr(structsk_buff*skb,structnetlink_callback*cb){enumaddr_type_ttype=MULTICAST_ADDR;-returninet6_dump_addr(skb,cb,type);+returninet6_dump_addr(skb,cb,type,RTM_GETMULTICAST);}
On Fri, Aug 31, 2018 at 4:20 AM, Patrick Ruddy
[off-list ref] wrote:
Some userspace applications need to know about IGMP joins from the kernel
for 2 reasons
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWADDR and RTM_DELADDR messages. It also provides
the RTM_GETADDR extension to allow multicast join state to be read
from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
v2: fix kbuild warnings.
I am still going through the series, but AFAICT, user-space caches listening to
RTNLGRP_IPV4_IFADDR will now also get multicast addresses by default ?
From: Patrick Ruddy <hidden> Date: 2018-09-02 15:34:26
Hi Roopa
inline
thx
-pr
On Fri, 2018-08-31 at 09:29 -0700, Roopa Prabhu wrote:
On Fri, Aug 31, 2018 at 4:20 AM, Patrick Ruddy
[off-list ref] wrote:
quoted
Some userspace applications need to know about IGMP joins from the kernel
for 2 reasons
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWADDR and RTM_DELADDR messages. It also provides
the RTM_GETADDR extension to allow multicast join state to be read
from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
v2: fix kbuild warnings.
I am still going through the series, but AFAICT, user-space caches listening to
RTNLGRP_IPV4_IFADDR will now also get multicast addresses by default ?
Yes that's the crux of this change. It's unfortunate that I could not
use IFA_MULTICAST to distinguish the SAFI. I suppose the other option
would be to create a set of new NEW/DEL/GETMULTICAST messages but the
partial code for RTM_GETMULTICAST in ipv6/mcast.c complicates that
slightly. Happy to look at it if you think that would be be better.
On Sun, Sep 2, 2018 at 4:18 AM, Patrick Ruddy
[off-list ref] wrote:
Hi Roopa
inline
thx
-pr
On Fri, 2018-08-31 at 09:29 -0700, Roopa Prabhu wrote:
quoted
On Fri, Aug 31, 2018 at 4:20 AM, Patrick Ruddy
[off-list ref] wrote:
quoted
Some userspace applications need to know about IGMP joins from the kernel
for 2 reasons
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWADDR and RTM_DELADDR messages. It also provides
the RTM_GETADDR extension to allow multicast join state to be read
from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
v2: fix kbuild warnings.
I am still going through the series, but AFAICT, user-space caches listening to
RTNLGRP_IPV4_IFADDR will now also get multicast addresses by default ?
Yes that's the crux of this change. It's unfortunate that I could not
use IFA_MULTICAST to distinguish the SAFI. I suppose the other option
would be to create a set of new NEW/DEL/GETMULTICAST messages but the
partial code for RTM_GETMULTICAST in ipv6/mcast.c complicates that
slightly. Happy to look at it if you think that would be be better.
yeah, true. Thinking about this some more, you are adding an interface
for multicast entries learnt via igmp.
There is already a netlink channel for layer2 mc addresses via igmp. I
can't see why that cannot be used.
It is RTM_*MDB msgs. It is currently only available for the bridge.
But, I have a requirement for it to be
available via a vxlan dev...so, I am looking at making it available on
other devices.
Can you check if RTM_*MDB msgs can be made to work for your case ?.
The reason I think it should be possible is because this is similar to
bridge fdb entries.
The bridge fdb api (RTM_NEWNEIGH with AF_BRIDGE) is overloaded to
notify and dump netdev unicast addresses.
similarly I think the mdb api can be overloaded to notify and dump
netdev multicast addresses (statically added or learnt via igmp)
From: Patrick Ruddy <hidden> Date: 2018-09-04 12:18:24
On Mon, 2018-09-03 at 16:12 -0700, Roopa Prabhu wrote:
On Sun, Sep 2, 2018 at 4:18 AM, Patrick Ruddy
[off-list ref] wrote:
quoted
Hi Roopa
inline
thx
-pr
On Fri, 2018-08-31 at 09:29 -0700, Roopa Prabhu wrote:
quoted
On Fri, Aug 31, 2018 at 4:20 AM, Patrick Ruddy
[off-list ref] wrote:
quoted
Some userspace applications need to know about IGMP joins from the kernel
for 2 reasons
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWADDR and RTM_DELADDR messages. It also provides
the RTM_GETADDR extension to allow multicast join state to be read
from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
v2: fix kbuild warnings.
I am still going through the series, but AFAICT, user-space caches listening to
RTNLGRP_IPV4_IFADDR will now also get multicast addresses by default ?
Yes that's the crux of this change. It's unfortunate that I could not
use IFA_MULTICAST to distinguish the SAFI. I suppose the other option
would be to create a set of new NEW/DEL/GETMULTICAST messages but the
partial code for RTM_GETMULTICAST in ipv6/mcast.c complicates that
slightly. Happy to look at it if you think that would be be better.
yeah, true. Thinking about this some more, you are adding an interface
for multicast entries learnt via igmp.
There is already a netlink channel for layer2 mc addresses via igmp. I
can't see why that cannot be used.
It is RTM_*MDB msgs. It is currently only available for the bridge.
But, I have a requirement for it to be
available via a vxlan dev...so, I am looking at making it available on
other devices.
The reason I think it should be possible is because this is similar to
bridge fdb entries.
The bridge fdb api (RTM_NEWNEIGH with AF_BRIDGE) is overloaded to
notify and dump netdev unicast addresses.
similarly I think the mdb api can be overloaded to notify and dump
netdev multicast addresses (statically added or learnt via igmp)
From: Patrick Ruddy <hidden> Date: 2018-09-04 21:03:00
On Mon, 2018-09-03 at 16:12 -0700, Roopa Prabhu wrote:
On Sun, Sep 2, 2018 at 4:18 AM, Patrick Ruddy
[off-list ref] wrote:
quoted
Hi Roopa
inline
thx
-pr
On Fri, 2018-08-31 at 09:29 -0700, Roopa Prabhu wrote:
quoted
On Fri, Aug 31, 2018 at 4:20 AM, Patrick Ruddy
[off-list ref] wrote:
quoted
Some userspace applications need to know about IGMP joins from the kernel
for 2 reasons
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWADDR and RTM_DELADDR messages. It also provides
the RTM_GETADDR extension to allow multicast join state to be read
from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
v2: fix kbuild warnings.
I am still going through the series, but AFAICT, user-space caches listening to
RTNLGRP_IPV4_IFADDR will now also get multicast addresses by default ?
Yes that's the crux of this change. It's unfortunate that I could not
use IFA_MULTICAST to distinguish the SAFI. I suppose the other option
would be to create a set of new NEW/DEL/GETMULTICAST messages but the
partial code for RTM_GETMULTICAST in ipv6/mcast.c complicates that
slightly. Happy to look at it if you think that would be be better.
yeah, true. Thinking about this some more, you are adding an interface
for multicast entries learnt via igmp.
There is already a netlink channel for layer2 mc addresses via igmp. I
can't see why that cannot be used.
It is RTM_*MDB msgs. It is currently only available for the bridge.
But, I have a requirement for it to be
available via a vxlan dev...so, I am looking at making it available on
other devices.
Can you check if RTM_*MDB msgs can be made to work for your case ?.
The reason I think it should be possible is because this is similar to
bridge fdb entries.
The bridge fdb api (RTM_NEWNEIGH with AF_BRIDGE) is overloaded to
notify and dump netdev unicast addresses.
similarly I think the mdb api can be overloaded to notify and dump
netdev multicast addresses (statically added or learnt via igmp)
If I'm reading this correctly I think overloading this channel is
possible.
What you're suggesting is overloading the RTM_***MDB messages with
AF_INET and AF_INET6 to carry the per-interfaces joined l3 multicast
addresses.
I've thrown together a quick test of this and it looks good. I can
polish this up and resubmit if you're happy with the approach. FWIW
isolating the multicast addresses this was seems safer and it's a
smaller patchset.
thx
-pr
From: Patrick Ruddy <hidden> Date: 2018-09-06 13:45:45
Some userspace applications need to know about IGMP joins from the
kernel for 2 reasons:
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWMDB and RTM_DELMDB messages with AF_INET. It also
provides the RTM_GETMDB extension to allow multicast join state to
be read from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
v3 rework to use RTM_***MDB messages as per review comments.
net/ipv4/igmp.c | 139 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 139 insertions(+)
From: Patrick Ruddy <hidden> Date: 2018-09-06 13:45:50
Some userspace applications need to know about MLD joins from the
kernel for 2 reasons:
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWMDB and RTM_DELMDB messages with AF_INET6. It also
provides the RTM_GETMDB extension to allow multicast join state to
be read from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
v3 rework to use RTM_***MDB messages as per review comments.
net/ipv6/addrconf.c | 34 ++++++++++++++++-------
net/ipv6/mcast.c | 66 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 90 insertions(+), 10 deletions(-)
On Thu, Sep 6, 2018 at 2:10 AM, Patrick Ruddy
[off-list ref] wrote:
Some userspace applications need to know about IGMP joins from the
kernel for 2 reasons:
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWMDB and RTM_DELMDB messages with AF_INET. It also
provides the RTM_GETMDB extension to allow multicast join state to
be read from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
v3 rework to use RTM_***MDB messages as per review comments.
Patrick, this version seems to be using RTM_***MDB msgs with the
RTM_*ADDR format.
We cant do that...because existing RTM_MDB users will be confused.
My request was to evaluate RTM_***MDB msg format. see
nlmsg_populate_mdb_fill for details.
If you can wait a day or two I can share some experimental code that
moves high level RTM_*MDB msg handling into net/core/rtnetlink.c
similar to RTM_*FDB
On Thu, Sep 6, 2018 at 8:40 PM, Roopa Prabhu [off-list ref] wrote:
On Thu, Sep 6, 2018 at 2:10 AM, Patrick Ruddy
[off-list ref] wrote:
quoted
Some userspace applications need to know about IGMP joins from the
kernel for 2 reasons:
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWMDB and RTM_DELMDB messages with AF_INET. It also
provides the RTM_GETMDB extension to allow multicast join state to
be read from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
v3 rework to use RTM_***MDB messages as per review comments.
Patrick, this version seems to be using RTM_***MDB msgs with the
RTM_*ADDR format.
We cant do that...because existing RTM_MDB users will be confused.
My request was to evaluate RTM_***MDB msg format. see
nlmsg_populate_mdb_fill for details.
If you can wait a day or two I can share some experimental code that
moves high level RTM_*MDB msg handling into net/core/rtnetlink.c
similar to RTM_*FDB
I was trying to get a default per interface (non bridge) RTM_*MDB
working, but realized that the dev->mc
entries are already getting dumped as part of RTM_*FDB msgs instead of
RTM_*MDB. (see net/core/rtnetlink.c:ndo_dflt_fdb_dump).
This adds another wrench.
so, that puts us back to your use of RTM_NEWADDR.
Instead of using IFA_ADDRESS, you could introduce a new one
IFA_IGMP_MULTICAST (since IFA_MULTICAST is already taken).
To keep existing users of RTM_NEWADDR unaffected. I think you can use
the IPMR family with RTM_NEWADDR.
We can introduce new notification group. (We can choose to add a new
family too, but that seems unnecessary)
since you only need dumps:
rtnl_register(RTNL_FAMILY_IPMR, RTM_GETADDR, NULL, igmp_rtm_dumpaddrs, 0);
For notifications, since we already have many variants for routes, I
don't see a problem adding similar addr variants
RTNLGRP_IPV4_MCADDR
(Others on the list may have more feedback).
From: Patrick Ruddy <hidden> Date: 2018-09-13 23:00:02
On Thu, 2018-09-13 at 10:03 -0700, Roopa Prabhu wrote:
On Thu, Sep 6, 2018 at 8:40 PM, Roopa Prabhu [off-list ref] wrote:
quoted
On Thu, Sep 6, 2018 at 2:10 AM, Patrick Ruddy
[off-list ref] wrote:
quoted
Some userspace applications need to know about IGMP joins from the
kernel for 2 reasons:
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWMDB and RTM_DELMDB messages with AF_INET. It also
provides the RTM_GETMDB extension to allow multicast join state to
be read from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
v3 rework to use RTM_***MDB messages as per review comments.
Patrick, this version seems to be using RTM_***MDB msgs with the
RTM_*ADDR format.
We cant do that...because existing RTM_MDB users will be confused.
My request was to evaluate RTM_***MDB msg format. see
nlmsg_populate_mdb_fill for details.
If you can wait a day or two I can share some experimental code that
moves high level RTM_*MDB msg handling into net/core/rtnetlink.c
similar to RTM_*FDB
I was trying to get a default per interface (non bridge) RTM_*MDB
working, but realized that the dev->mc
entries are already getting dumped as part of RTM_*FDB msgs instead of
RTM_*MDB. (see net/core/rtnetlink.c:ndo_dflt_fdb_dump).
This adds another wrench.
so, that puts us back to your use of RTM_NEWADDR.
Instead of using IFA_ADDRESS, you could introduce a new one
IFA_IGMP_MULTICAST (since IFA_MULTICAST is already taken).
To keep existing users of RTM_NEWADDR unaffected. I think you can use
the IPMR family with RTM_NEWADDR.
We can introduce new notification group. (We can choose to add a new
family too, but that seems unnecessary)
since you only need dumps:
rtnl_register(RTNL_FAMILY_IPMR, RTM_GETADDR, NULL, igmp_rtm_dumpaddrs, 0);
For notifications, since we already have many variants for routes, I
don't see a problem adding similar addr variants
RTNLGRP_IPV4_MCADDR
(Others on the list may have more feedback).
Thanks for looking at this Roopa - I'll rehash as suggested.
-pr
From: Patrick Ruddy <hidden> Date: 2018-09-18 18:45:39
On Thu, 2018-09-13 at 10:03 -0700, Roopa Prabhu wrote:
On Thu, Sep 6, 2018 at 8:40 PM, Roopa Prabhu [off-list ref] wrote:
quoted
On Thu, Sep 6, 2018 at 2:10 AM, Patrick Ruddy
[off-list ref] wrote:
quoted
Some userspace applications need to know about IGMP joins from the
kernel for 2 reasons:
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWMDB and RTM_DELMDB messages with AF_INET. It also
provides the RTM_GETMDB extension to allow multicast join state to
be read from the kernel.
Signed-off-by: Patrick Ruddy <redacted>
---
v3 rework to use RTM_***MDB messages as per review comments.
Patrick, this version seems to be using RTM_***MDB msgs with the
RTM_*ADDR format.
We cant do that...because existing RTM_MDB users will be confused.
My request was to evaluate RTM_***MDB msg format. see
nlmsg_populate_mdb_fill for details.
If you can wait a day or two I can share some experimental code that
moves high level RTM_*MDB msg handling into net/core/rtnetlink.c
similar to RTM_*FDB
I was trying to get a default per interface (non bridge) RTM_*MDB
working, but realized that the dev->mc
entries are already getting dumped as part of RTM_*FDB msgs instead of
RTM_*MDB. (see net/core/rtnetlink.c:ndo_dflt_fdb_dump).
This adds another wrench.
so, that puts us back to your use of RTM_NEWADDR.
Instead of using IFA_ADDRESS, you could introduce a new one
IFA_IGMP_MULTICAST (since IFA_MULTICAST is already taken).
To keep existing users of RTM_NEWADDR unaffected. I think you can use
the IPMR family with RTM_NEWADDR.
We can introduce new notification group. (We can choose to add a new
family too, but that seems unnecessary)
since you only need dumps:
rtnl_register(RTNL_FAMILY_IPMR, RTM_GETADDR, NULL, igmp_rtm_dumpaddrs, 0);
For notifications, since we already have many variants for routes, I
don't see a problem adding similar addr variants
RTNLGRP_IPV4_MCADDR
(Others on the list may have more feedback).
I've hit a small snag with adding the new groups. The number of defined
groups currently sits at 31 so I can only add one before hitting the
limit defined by the 32 bit groups bitmask in socakddr_nl. I can use 1
group for both v4 and v6 notifications which seems like the sensible
options since the AF is carried separately, but it breaks the precedent
where there are separate IPV4 and IPV6 groups for IFADDR.
I have the combined group patches ready and can share them if that's
the preference.
Has there been any previous discussion about extending the number of
availabel groups?
From: David Ahern <hidden> Date: 2018-09-20 10:27:43
On 9/18/18 6:12 AM, Patrick Ruddy wrote:
I've hit a small snag with adding the new groups. The number of defined
groups currently sits at 31 so I can only add one before hitting the
I believe you have no more available. RTNLGRP_* has been defined from 0
(RTNLGRP_NONE) to 31 (RTNLGRP_IPV6_MROUTE_R) which covers the u32 range.
limit defined by the 32 bit groups bitmask in socakddr_nl. I can use 1
group for both v4 and v6 notifications which seems like the sensible
options since the AF is carried separately, but it breaks the precedent
where there are separate IPV4 and IPV6 groups for IFADDR.
I have the combined group patches ready and can share them if that's
the preference.
Has there been any previous discussion about extending the number of
availabel groups?
I have not tried it, but from a prior code review I believe you have you
use setsockopt to add groups > 31.
From: Patrick Ruddy <hidden> Date: 2018-09-25 15:41:04
On Wed, 2018-09-19 at 21:47 -0700, David Ahern wrote:
On 9/18/18 6:12 AM, Patrick Ruddy wrote:
quoted
I've hit a small snag with adding the new groups. The number of defined
groups currently sits at 31 so I can only add one before hitting the
I believe you have no more available. RTNLGRP_* has been defined from 0
(RTNLGRP_NONE) to 31 (RTNLGRP_IPV6_MROUTE_R) which covers the u32 range.
quoted
limit defined by the 32 bit groups bitmask in socakddr_nl. I can use 1
group for both v4 and v6 notifications which seems like the sensible
options since the AF is carried separately, but it breaks the precedent
where there are separate IPV4 and IPV6 groups for IFADDR.
I have the combined group patches ready and can share them if that's
the preference.
Has there been any previous discussion about extending the number of
availabel groups?
I have not tried it, but from a prior code review I believe you have you
use setsockopt to add groups > 31.
I can certainly join the new groups using setsockopt and
NETLINK_ADD_MEMBERSHIP.
I can't see any examples of extending the defined group list within the
kernel so I assume I just add to the RTNLGRP enum list with a suitable
comment to indicate that later groups must be joined with the mechanism
above or am I missing some other way of dynamically adding groups?
thanks
-pr
On Tue, Sep 25, 2018 at 2:34 AM, Patrick Ruddy
[off-list ref] wrote:
On Wed, 2018-09-19 at 21:47 -0700, David Ahern wrote:
quoted
On 9/18/18 6:12 AM, Patrick Ruddy wrote:
quoted
I've hit a small snag with adding the new groups. The number of defined
groups currently sits at 31 so I can only add one before hitting the
I believe you have no more available. RTNLGRP_* has been defined from 0
(RTNLGRP_NONE) to 31 (RTNLGRP_IPV6_MROUTE_R) which covers the u32 range.
quoted
limit defined by the 32 bit groups bitmask in socakddr_nl. I can use 1
group for both v4 and v6 notifications which seems like the sensible
options since the AF is carried separately, but it breaks the precedent
where there are separate IPV4 and IPV6 groups for IFADDR.
I have the combined group patches ready and can share them if that's
the preference.
Has there been any previous discussion about extending the number of
availabel groups?
I have not tried it, but from a prior code review I believe you have you
use setsockopt to add groups > 31.
I can certainly join the new groups using setsockopt and
NETLINK_ADD_MEMBERSHIP.
I can't see any examples of extending the defined group list within the
kernel so I assume I just add to the RTNLGRP enum list with a suitable
comment to indicate that later groups must be joined with the mechanism
above or am I missing some other way of dynamically adding groups?
With a quick look, there are other subsystem specific groups:
xfrm_nlgroups, nfnetlink_groups ...which i see apps registering using
NETLINK_ADD_MEMBERSHIP.
seems like an overkill to add something like this for your case.
yet another option to consider:
use family: RTNL_FAMILY_IPMR/ RTNL_FAMILY_IP6MR with RTM_GETADDR/DELADDR
and use the existing groups: RTNLGRP_IPV4_IFADDR / RTNLGRP_IPV6_IFADDR
(pls check if this will break any existing users)
precedence is ipmr fib rules.
On Wed, Sep 26, 2018 at 10:23 AM Roopa Prabhu [off-list ref] wrote:
On Tue, Sep 25, 2018 at 2:34 AM, Patrick Ruddy
[off-list ref] wrote:
quoted
On Wed, 2018-09-19 at 21:47 -0700, David Ahern wrote:
quoted
On 9/18/18 6:12 AM, Patrick Ruddy wrote:
quoted
I've hit a small snag with adding the new groups. The number of defined
groups currently sits at 31 so I can only add one before hitting the
I believe you have no more available. RTNLGRP_* has been defined from 0
(RTNLGRP_NONE) to 31 (RTNLGRP_IPV6_MROUTE_R) which covers the u32 range.
quoted
limit defined by the 32 bit groups bitmask in socakddr_nl. I can use 1
group for both v4 and v6 notifications which seems like the sensible
options since the AF is carried separately, but it breaks the precedent
where there are separate IPV4 and IPV6 groups for IFADDR.
I have the combined group patches ready and can share them if that's
the preference.
Has there been any previous discussion about extending the number of
availabel groups?
I have not tried it, but from a prior code review I believe you have you
use setsockopt to add groups > 31.
I can certainly join the new groups using setsockopt and
NETLINK_ADD_MEMBERSHIP.
I can't see any examples of extending the defined group list within the
kernel so I assume I just add to the RTNLGRP enum list with a suitable
comment to indicate that later groups must be joined with the mechanism
above or am I missing some other way of dynamically adding groups?
With a quick look, there are other subsystem specific groups:
xfrm_nlgroups, nfnetlink_groups ...which i see apps registering using
NETLINK_ADD_MEMBERSHIP.
scratch that. These groups are for different netlink protocols and the
limit on netlink groups per protocol seems to be 32.
We seem to have hit the max on groups for NETLINK_ROUTE protocol. we
will have to rework the group handling
to make room for more groups. We do need room for more groups in the
future and not just for this patchset.
seems like an overkill to add something like this for your case.
yet another option to consider:
use family: RTNL_FAMILY_IPMR/ RTNL_FAMILY_IP6MR with RTM_GETADDR/DELADDR
and use the existing groups: RTNLGRP_IPV4_IFADDR / RTNLGRP_IPV6_IFADDR
(pls check if this will break any existing users)
precedence is ipmr fib rules.