Re: [BUG] net: gre: IPv6 link-local multicast is silently dropped (Regression)

[Ido Schimmel <idosch@idosch.org>]

On Mon, Jun 30, 2025 at 01:54:58PM +0200, Guillaume Nault wrote:
> On Sun, Jun 29, 2025 at 05:49:36PM +0300, Ido Schimmel wrote:
> > + Guillaume
> > 
> > Report is here: https://lore.kernel.org/netdev/CANR=AhRM7YHHXVxJ4DmrTNMeuEOY87K2mLmo9KMed1JMr20p6g@mail.gmail.com/
> > 
> > On Sun, Jun 29, 2025 at 02:40:27PM +0800, Aiden Yang wrote:
> > > This report details a regression in the Linux kernel that prevents
> > > IPv6 link-local all-nodes multicast packets (ff02::1) from being
> > > transmitted over a GRE tunnel. The issue is confirmed to have been
> > > introduced between kernel versions 6.1.0-35-cloud-amd64 (working) and
> > > 6.1.0-37-cloud-amd64 (failing) on Debian 12 (Bookworm).
> > 
> > Apparently 6.1.0-35-cloud-amd64 is v6.1.137 and 6.1.0-37-cloud-amd64 is
> > v6.1.140. Probably started with:
> > 
> > a51dc9669ff8 gre: Fix again IPv6 link-local address generation.
> > 
> > In v6.1.139.
> > 
> > It skips creating an IPv6 multicast route for some ipgre devices. Can
> > you try the following diff?
> > 
> > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> > index ba2ec7c870cc..d0a202d0d93e 100644
> > --- a/net/ipv6/addrconf.c
> > +++ b/net/ipv6/addrconf.c
> > @@ -3537,12 +3537,10 @@ static void addrconf_gre_config(struct net_device *dev)
> >  	 * case). Such devices fall back to add_v4_addrs() instead.
> >  	 */
> >  	if (!(dev->type == ARPHRD_IPGRE && *(__be32 *)dev->dev_addr == 0 &&
> > -	      idev->cnf.addr_gen_mode == IN6_ADDR_GEN_MODE_EUI64)) {
> > +	      idev->cnf.addr_gen_mode == IN6_ADDR_GEN_MODE_EUI64))
> >  		addrconf_addr_gen(idev, true);
> > -		return;
> > -	}
> > -
> > -	add_v4_addrs(idev);
> > +	else
> > +		add_v4_addrs(idev);
> >  
> >  	if (dev->flags & IFF_POINTOPOINT)
> >  		addrconf_add_mroute(dev);
> 
> I believe that should fix the problem indeed. But, to me, the root
> cause is that addrconf_gre_config() doesn't call addrconf_add_dev().
> 
> Ido, What do you think of something like the following (untested,
> hand-written) diff:
> 
>  #if IS_ENABLED(CONFIG_NET_IPGRE)
>  static void addrconf_gre_config(struct net_device *dev)
>  {
>  	struct inet6_dev *idev;
>  
>  	ASSERT_RTNL();
>  
> -	idev = ipv6_find_idev(dev);
> -	if (IS_ERR(idev)) {
> -		pr_debug("%s: add_dev failed\n", __func__);
> -		return;
> -	}
> +	idev = addrconf_add_dev(dev);
> +	if (IS_ERR(idev))
> +		return;
>  
>  	/* Generate the IPv6 link-local address using addrconf_addr_gen(),
>  	 * unless we have an IPv4 GRE device not bound to an IP address and
>  	 * which is in EUI64 mode (as __ipv6_isatap_ifid() would fail in this
>  	 * case). Such devices fall back to add_v4_addrs() instead.
>  	 */
>  	if (!(*(__be32 *)dev->dev_addr == 0 &&
>  	      idev->cnf.addr_gen_mode == IN6_ADDR_GEN_MODE_EUI64)) {
>  		addrconf_addr_gen(idev, true);
>  		return;
>  	}
>  
>  	add_v4_addrs(idev);
> -
> -	if (dev->flags & IFF_POINTOPOINT)
> -		addrconf_add_mroute(dev);
>  }
>  #endif
> 
> This way, we would create the multicast route and also respect
> disable_ipv6. That would bring GRE yet a bit closer to normal IPv6
> lladdr generation code.

Makes sense. So you will submit it to net and extend gre_ipv6_lladdr.sh
to test for the presence of a multicast route?

> 
> Note: this diff is based on net-next, but, without all the extra
> context lines, a real patch would probably apply to both net and
> next-next and could be backported to -stable.
> 
> > Guillaume, AFAICT, after commit d3623dd5bd4e ("ipv6: Simplify link-local
> > address generation for IPv6 GRE.") in net-next an IPv6 multicast route
> > will be created for every ip6gre device, regardless of IFF_POINTOPOINT.
> > It should restore the behavior before commit e5dd729460ca ("ip/ip6_gre:
> > use the same logic as SIT interfaces when computing v6LL address"). We
> > can extend gre_ipv6_lladdr.sh to test this once the fix is in net-next.
> 
> Yes, I fully agree.
> 
> Long term, I'd really like to remove these special GRE and SIT cases
> (SIT certainly has the same problems we're currently fixing on GRE).
>