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

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

[Aiden Yang]

Hello,

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).

On affected kernels, the ping utility reports 100% packet loss, and a
tcpdump on the underlying physical interface confirms that the kernel
is silently dropping the encapsulated GRE packets instead of sending
them. The sendto() system call does not return an error to the
userspace application in the default namespace.

===================================================================

Regression Point:

Last Known Good Version: 6.1.0-35-cloud-amd64 (on Debian 12)

First Failing Version: 6.1.0-37-cloud-amd64 (on Debian 12)

The regression is also present in later kernels tested, including
6.12.33 and 6.15.x on Debian 13 (Trixie).

===================================================================

Steps to Reproduce:

Use a Debian system with an affected kernel (e.g., >= 6.1.0-37).

Establish a GRE tunnel. Replace [PEER_IP] and [LOCAL_IP] with actual
endpoint addresses.

ip tunnel add tun_gre mode gre remote [PEER_IP] local [LOCAL_IP] ttl
255 ip link set tun_gre up

In one terminal, start a tcpdump on the physical interface that
provides the local IP, to monitor for outgoing GRE packets (GRE is IP
protocol 47).

tcpdump -i [PHYSICAL_IFACE] -n 'proto gre'

In a second terminal, attempt to ping the link-local all-nodes
multicast address via the GRE tunnel interface.

ping ff02::1%tun_gre -c 4

===================================================================

Observed Behavior (The Bug):

The ping command runs and reports "4 packets transmitted, 0 received,
100% packet loss".

The tcpdump window on the physical interface shows NO outgoing GRE
packets. This proves the kernel is silently dropping the packets.

===================================================================

Expected Behavior (as observed on kernel 6.1.0-35):

The ping command runs.

The tcpdump window shows outgoing GRE packets being sent from
[LOCAL_IP] to [PEER_IP] for each ICMPv6 echo request. (Receiving a
reply is dependent on the peer configuration, but the packet should be
transmitted).

===================================================================

Additional Diagnostic Information:

VRF Context: When the failing GRE interface (tun_gre) is placed within
a VRF, the failure mode changes. The ping or sendto() system call
fails immediately with an ENETUNREACH (Network is unreachable) error.
This is likely because the VRF routing table does not have a route to
the tunnel's physical peer address, and the kernel correctly
identifies this dependency issue.

veth Control Test: The issue is specific to the gre tunnel interface
type. A control test using a veth pair inside a VRF works perfectly
for link-local multicast, proving the core VRF and multicast logic is
sound.

This detailed bracketing of the regression should provide a strong
starting point for identifying the specific commit that introduced
this behavior.

Thanks,
Aiden Yang

-- 

WARNING: *This email (including its attachments) may contain confidential 
information protected by confidentiality agreements or other rights, and is 
intended only for the designated recipient or individuals who need to know 
it for the stated purpose. The recipient is prohibited from disclosing this 
information to unauthorized parties without prior permission from MoeDove 
LLC. If you have received this email in error, please notify the sender 
immediately and delete this email and its attachments from your system. Any 
use, dissemination, transmission, or copying of this email by someone other 
than the intended recipient is prohibited and may be unlawful.*

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

[Ido Schimmel]

+ 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);

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.

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

[Guillaume Nault]

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.

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).

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

[Ido Schimmel]

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).
> 

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

[Guillaume Nault]

On Tue, Jul 01, 2025 at 01:13:22PM +0300, Ido Schimmel wrote:
> Makes sense. So you will submit it to net and extend gre_ipv6_lladdr.sh
> to test for the presence of a multicast route?

Yes. I'd just like to have a confirmation from Aiden first.

Aiden, can you confirm that the following patch fixes the issue on your
side?

---- >8 ----

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index ba2ec7c870cc..870a0bd6c2ba 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3525,11 +3525,9 @@ static void addrconf_gre_config(struct net_device *dev)
 
 	ASSERT_RTNL();
 
-	idev = ipv6_find_idev(dev);
-	if (IS_ERR(idev)) {
-		pr_debug("%s: add_dev failed\n", __func__);
+	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
@@ -3543,9 +3541,6 @@ static void addrconf_gre_config(struct net_device *dev)
 	}
 
 	add_v4_addrs(idev);
-
-	if (dev->flags & IFF_POINTOPOINT)
-		addrconf_add_mroute(dev);
 }
 #endif
 

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

[Gary Guo]

On Wed, 2 Jul 2025 12:12:22 +0200, Guillaume Nault wrote:
> Aiden, can you confirm that the following patch fixes the issue on your
> side?

Not Aiden, but I get hit with the same regression after updating kernel on my
router from v6.12.28 to v6.12.35 today. Symptom for me is bird complaining
about "Socket error: Network is unreachable", and strace shows that it's sending
packets to ff02::1:6 and get hit with ENETUNREACH.

I can confirm that applying this patch on top of v6.12.35 fixes the issue for me.
I also took a look of the code, not a net expert, but this approach does look
like a proper fix to me.

Reviewed-by: Gary Guo <gary@garyguo.net>
Tested-by: Gary Guo <gary@garyguo.net>

> 
> ---- >8 ----
> 
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index ba2ec7c870cc..870a0bd6c2ba 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -3525,11 +3525,9 @@ static void addrconf_gre_config(struct net_device *dev)
>  
>  	ASSERT_RTNL();
>  
> -	idev = ipv6_find_idev(dev);
> -	if (IS_ERR(idev)) {
> -		pr_debug("%s: add_dev failed\n", __func__);
> +	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
> @@ -3543,9 +3541,6 @@ static void addrconf_gre_config(struct net_device *dev)
>  	}
>  
>  	add_v4_addrs(idev);
> -
> -	if (dev->flags & IFF_POINTOPOINT)
> -		addrconf_add_mroute(dev);
>  }
>  #endif

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

[Guillaume Nault]

On Sun, Jul 06, 2025 at 04:40:30PM +0100, Gary Guo wrote:
> On Wed, 2 Jul 2025 12:12:22 +0200, Guillaume Nault wrote:
> > Aiden, can you confirm that the following patch fixes the issue on your
> > side?
> 
> Not Aiden, but I get hit with the same regression after updating kernel on my
> router from v6.12.28 to v6.12.35 today. Symptom for me is bird complaining
> about "Socket error: Network is unreachable", and strace shows that it's sending
> packets to ff02::1:6 and get hit with ENETUNREACH.
> 
> I can confirm that applying this patch on top of v6.12.35 fixes the issue for me.
> I also took a look of the code, not a net expert, but this approach does look
> like a proper fix to me.

Thanks Gary, it's good to have such feedback.
I'm going to formally send the patch soon.

> Reviewed-by: Gary Guo <gary@garyguo.net>
> Tested-by: Gary Guo <gary@garyguo.net>
> 
> > 
> > ---- >8 ----
> > 
> > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> > index ba2ec7c870cc..870a0bd6c2ba 100644
> > --- a/net/ipv6/addrconf.c
> > +++ b/net/ipv6/addrconf.c
> > @@ -3525,11 +3525,9 @@ static void addrconf_gre_config(struct net_device *dev)
> >  
> >  	ASSERT_RTNL();
> >  
> > -	idev = ipv6_find_idev(dev);
> > -	if (IS_ERR(idev)) {
> > -		pr_debug("%s: add_dev failed\n", __func__);
> > +	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
> > @@ -3543,9 +3541,6 @@ static void addrconf_gre_config(struct net_device *dev)
> >  	}
> >  
> >  	add_v4_addrs(idev);
> > -
> > -	if (dev->flags & IFF_POINTOPOINT)
> > -		addrconf_add_mroute(dev);
> >  }
> >  #endif
>