Message-ID: <CANR=AhRM7YHHXVxJ4DmrTNMeuEOY87K2mLmo9KMed1JMr20p6g@mail.gmail.com>
Date: Sun, 29 Jun 2025 14:40:27 +0800
From: Aiden Yang <ling@...dove.com>
To: netdev@...r.kernel.org
Cc: kuba@...nel.org, pabeni@...hat.com, davem@...emloft.net, 
	MoeDove NOC <noc@...dove.com>
Subject: [BUG] net: gre: IPv6 link-local multicast is silently dropped (Regression)

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

Powered by blists - more mailing lists