+ Linus Lüssing Original patch: https://lore.kernel.org/netdev/[email protected]/
On Mon, Sep 15, 2025 at 06:41:19PM -0400, Huang, Joseph wrote: > It seems that inet6addr_notifier_call_chain() can be called when the address > is still tentative, which means br_ip6_multicast_alloc_query() is still > going to fail (br_ip6_multicast_alloc_query() calls ipv6_dev_get_saddr(), > which calls __ipv6_dev_get_saddr(), which does not consider tentative source > addresses). > > What the bridge needs really is a notification after DAD is completed, but I > couldn't find such notification. Or did you mean reusing the same > notification inet6addr_notifier_call_chain() but with a new event after DAD > is completed? Adding a new event to the inet6addr notification chain makes more sense than adding a new event to the netdev notification chain. But before making changes, I want to better understand the problem you are seeing. Is it specific to the offloaded data path? I believe the problem was fixed in the software data path by this commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0888d5f3c0f183ea6177355752ada433d370ac89 And Linus is working [1][2] on reflecting it to device drivers so that the hardware data path will act like the software data path and flood unregistered multicast traffic to all the ports as long as no querier was detected. As a temporary workaround, you can either configure an IPv6 link-local address on the bridge before opening it: # ip -6 address add fe80::1/64 dev br0 nodad Or enable optimistic DAD: # sysctl -wq net.ipv6.conf.br0.optimistic_dad=1 [1] https://lore.kernel.org/netdev/[email protected]/ [2] https://lore.kernel.org/netdev/[email protected]/
