Thread (2 messages) flat view 2 messages, 2 authors, 2026-02-13

ip6_tunnel.c question about https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=81c734dae203757fb3c9eee6f9896386940776bd

From: Froehlich, Dominik <hidden>
Date: 2026-02-13 17:31:19

Hello everyone,

We recently upgraded our kernels to 6.12.67 which contains this commit


commit df5ffde9669314500809bc498ae73d6d3d9519ac
Author: Eric Dumazet [off-list ref]
Date:   Wed Jan 7 16:31:09 2026 +0000

    ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()

    [ Upstream commit 81c734dae203757fb3c9eee6f9896386940776bd ]

    Blamed commit did not take care of VLAN encapsulations
    as spotted by syzbot [1].

    Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull().


We found out that it breaks our VPN setup that is based on passing IPv4 traffic through an ipv6 tunnel
network.

It seems that we run into the drop condition here:

      if (skb_vlan_inet_prepare(skb, true)) {
            DEV_STATS_INC(tunnel->dev, rx_length_errors);
            DEV_STATS_INC(tunnel->dev, rx_errors);
            goto drop;
      }

The previous version worked fine:

      if (!pskb_inet_may_pull(skb)) {
            DEV_STATS_INC(tunnel->dev, rx_length_errors);
            DEV_STATS_INC(tunnel->dev, rx_errors);
            goto drop;
      }

I don’t know if it’s related to the negation that is now missing..?


We are setting up the tunnel using a basic ip link command:

ip link add name bond0-ip6tnl0 type ip6tnl local fd8f:6d53:b97a:1::a:4120 remote fd8f:6d53:b97a:1::b:0 mode any


Where fd8f:6d53:b97a:1::a:4120 is the address of a local bond device enslaving two tap devices each connected to one VPN server for high availability.
fd8f:6d53:b97a:1::b:0 is the address of the remote bond device on the other end.
Both devices can ping each other just fine on IPv6, but when I try to send IPv4 packets through the ip6tnl device, they get dropped on the round trip.

We patched out the above fix for testing and confirmed that it works again.

I’ve attached a pcap file of a tcp SYN attempt  containing the ip6ip4 headers as they arrive at the ip6tnl device. The SYN-ACK returned is not showing and gets dropped, leading to SYN retransmission.

Can you give me some directions? I’m still trying to figure out if there is an error in our setup or the kernel.
This used to work for years so I’m a bit puzzled now.



Best regards,
Dominik Froehlich
SAP

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help