"ip maddr show" prints three kinds of entries: link-layer, IPv4 and
IPv6. The IPv4 and IPv6 ones can be read over netlink today: IPv6 has
had RTM_GETMULTICAST for a long time and IPv4 got it in eb4e17a1d915
("netlink: support dumping IPv4 multicast addresses"), with IFA_MC_USERS
added later so the user count no longer has to come from procfs.

The link-layer list is the missing piece. dev->mc, the addresses
programmed into the device filter, is only exported via
/proc/net/dev_mcast, so iproute2 still carries a procfs parser just for
that. This series closes the gap so that "ip maddr show" can be served
from rtnetlink alone.

Patch 1 handles RTM_GETMULTICAST dumps with ifa_family set to AF_PACKET
and walks dev->mc under netif_addr_lock_bh(), no RTNL. The reply reuses
the ifaddrmsg format of the IPv4 and IPv6 dumps: IFA_MULTICAST carries
the raw link-layer address, IFA_MC_USERS the reference count, and
IFA_F_PERMANENT is set for entries added with SIOCADDMULTI, which is the
"static" column /proc/net/dev_mcast has and "ip maddr" prints. A
non-zero ifa_index in a strict request limits the dump to one device.

Patch 2 updates the rt-addr spec and patch 3 adds a selftest that
checks the filter, the user count and the permanent flag on a dummy
device.

Nothing changes for other families. AF_PACKET dumps returned
-EOPNOTSUPP before, so iproute2 can keep the procfs fallback for older
kernels. I have the iproute2 side ready and will post it once this is
in; with it, "ip maddr show" does not open /proc/net at all.

Yuyang Huang (3):
  rtnetlink: add AF_PACKET multicast dumps
  netlink: specs: rt-addr: document AF_PACKET multicast dumps
  selftests: net: test AF_PACKET multicast dumps

 Documentation/netlink/specs/rt-addr.yaml |   7 +-
 net/core/rtnetlink.c                     | 132 +++++++++++++++++++++++
 tools/testing/selftests/net/rtnetlink.py |  58 +++++++++-
 3 files changed, 193 insertions(+), 4 deletions(-)

-- 
2.43.0

Le 05/09/2026 à 11:39, Yuyang Huang a écrit :
> "ip maddr show" prints three kinds of entries: link-layer, IPv4 and
> IPv6. The IPv4 and IPv6 ones can be read over netlink today: IPv6 has
> had RTM_GETMULTICAST for a long time and IPv4 got it in eb4e17a1d915
> ("netlink: support dumping IPv4 multicast addresses"), with IFA_MC_USERS
> added later so the user count no longer has to come from procfs.
> > The link-layer list is the missing piece. dev->mc, the addresses
> programmed into the device filter, is only exported via
> /proc/net/dev_mcast, so iproute2 still carries a procfs parser just for
These addresses could be listed with 'bridge fdb' (RTM_GETNEIGH on AF_BRIDGE).
Instead of having a new message to get the missing info (users), maybe it would
be better to update the current API.

> that. This series closes the gap so that "ip maddr show" can be served
> from rtnetlink alone.
> 
> Patch 1 handles RTM_GETMULTICAST dumps with ifa_family set to AF_PACKET
FWIW, AF_PACKET seems strange to me. Isn't AF_UNSPEC (like for interface, cf
rtnl_fill_ifinfo) more appropriate?

Regards,
Nicolas

> These addresses could be listed with 'bridge fdb' (RTM_GETNEIGH on AF_BRIDGE).
> Instead of having a new message to get the missing info (users), maybe it would
> be better to update the current API.

I looked at the FDB dump based on the suggestion and I don't think
that path works well. The missing users count is not the only problem:

It doesn't list dev->mc for every device. Only ndo_dflt_fdb_dump()
walks dev->mc, and rtnl_fdb_dump() calls it only for Ethernet devices
that have no ndo_fdb_dump of their own. So bridge, vxlan, macvlan and
IPoIB devices never show their multicast filter in "bridge fdb show",
while /proc/net/dev_mcast lists them. Fixing that means calling the
default dump for those devices too, which adds new entries to
"bridge fdb show" output on every one of them.

User space can't reliably tell the entries apart either. "ip maddr"
would keep NTF_SELF entries with a multicast lladdr, but it seems vxlan's own
FDB entries seems also carry NTF_SELF, so a multicast MAC added there as a
forwarding rule (bridge fdb add ... dev vxlan0 dst ...) would show up
as a device multicast address, while the real dev->mc of that vxlan
device is missing. And since a dump can't be limited to self entries,
on a host with bridges "ip maddr show" would receive the whole learned
FDB of every port and drop it.

It would still need a new uAPI. All self entries are NUD_PERMANENT, so
the users count and the SIOCADDMULTI (static) bit would be new NDA_*
attributes. On the other hand, this series adds no new attributes;
IFA_MULTICAST, IFA_MC_USERS and IFA_F_PERMANENT already exist for the
IPv4 and IPv6 dumps.

Covering this with RTM_GETNEIGH would need the default dump for
devices with their own ndo_fdb_dump, a way to tell filter entries from
a device's own
NTF_SELF FDB entries, a self-only request filter, and new NDA_*
attributes for users and the static bit. That is more new uAPI than
this series for the same result.

Therefore, I feel that my original proposal seems cleaner and causes
less chrun. But feel free to let me know if I have any
misunderstanding on the suggestion.

> FWIW, AF_PACKET seems strange to me. Isn't AF_UNSPEC (like for interface, cf
> rtnl_fill_ifinfo) more appropriate?

For address dumps AF_UNSPEC already means "all families" (RTM_GETADDR
goes through rtnl_dump_all()), so I'd rather keep it available for
RTM_GETMULTICAST. AF_PACKET is what iproute2 already uses for the link
family: "ip -0" sets preferred_family = AF_PACKET and sends it in
RTM_GETLINK, and ipmaddr.c has always tagged the /proc/net/dev_mcast
entries as AF_PACKET.

Thanks,

Yuyang

Le 08/09/2026 à 04:56, Yuyang Huang a écrit :
>> These addresses could be listed with 'bridge fdb' (RTM_GETNEIGH on AF_BRIDGE).
>> Instead of having a new message to get the missing info (users), maybe it would
>> be better to update the current API.
> 
> I looked at the FDB dump based on the suggestion and I don't think
> that path works well. The missing users count is not the only problem:
> 
> It doesn't list dev->mc for every device. Only ndo_dflt_fdb_dump()
> walks dev->mc, and rtnl_fdb_dump() calls it only for Ethernet devices
> that have no ndo_fdb_dump of their own. So bridge, vxlan, macvlan and
> IPoIB devices never show their multicast filter in "bridge fdb show",
> while /proc/net/dev_mcast lists them. Fixing that means calling the
> default dump for those devices too, which adds new entries to
> "bridge fdb show" output on every one of them.
> 
> User space can't reliably tell the entries apart either. "ip maddr"
> would keep NTF_SELF entries with a multicast lladdr, but it seems vxlan's own
> FDB entries seems also carry NTF_SELF, so a multicast MAC added there as a
> forwarding rule (bridge fdb add ... dev vxlan0 dst ...) would show up
> as a device multicast address, while the real dev->mc of that vxlan
> device is missing. And since a dump can't be limited to self entries,
> on a host with bridges "ip maddr show" would receive the whole learned
> FDB of every port and drop it.
> 
> It would still need a new uAPI. All self entries are NUD_PERMANENT, so
> the users count and the SIOCADDMULTI (static) bit would be new NDA_*
> attributes. On the other hand, this series adds no new attributes;
> IFA_MULTICAST, IFA_MC_USERS and IFA_F_PERMANENT already exist for the
> IPv4 and IPv6 dumps.
> 
> Covering this with RTM_GETNEIGH would need the default dump for
> devices with their own ndo_fdb_dump, a way to tell filter entries from
> a device's own
> NTF_SELF FDB entries, a self-only request filter, and new NDA_*
> attributes for users and the static bit. That is more new uAPI than
> this series for the same result.
> 
> Therefore, I feel that my original proposal seems cleaner and causes
> less chrun. But feel free to let me know if I have any
> misunderstanding on the suggestion.
Ok, I agree, it seems easier to have another entry point.

> 
>> FWIW, AF_PACKET seems strange to me. Isn't AF_UNSPEC (like for interface, cf
>> rtnl_fill_ifinfo) more appropriate?
> 
> For address dumps AF_UNSPEC already means "all families" (RTM_GETADDR
> goes through rtnl_dump_all()), so I'd rather keep it available for
> RTM_GETMULTICAST. AF_PACKET is what iproute2 already uses for the link
> family: "ip -0" sets preferred_family = AF_PACKET and sends it in
> RTM_GETLINK, and ipmaddr.c has always tagged the /proc/net/dev_mcast
> entries as AF_PACKET.
I hadn't looked at iproute2. It uses AF_PACKET for link-layer addresses, so that
seems OK too.

Nicolas