Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #88259 > unrolled thread

Bug#1108860: linux-image-6.1.0-34-amd64: Wireguard fragmentation fails with VXLAN since kernel 6.1.0-34, causing network timeouts

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1108860: linux-image-6.1.0-34-amd64: Wireguard fragmentation fails with VXLAN since kernel 6.1.0-34, causing network timeouts Salvatore Bonaccorso <carnil@debian.org> - 2025-07-06 21:10 +0200
    Bug#1108860: linux-image-6.1.0-34-amd64: Wireguard fragmentation fails with VXLAN since kernel 6.1.0-34, causing network timeouts Salvatore Bonaccorso <carnil@debian.org> - 2025-07-10 21:00 +0200
      Bug#1108860: linux-image-6.1.0-34-amd64: Wireguard fragmentation fails with VXLAN since kernel 6.1.0-34, causing network timeouts Salvatore Bonaccorso <carnil@debian.org> - 2025-07-14 21:40 +0200

#88259 — Bug#1108860: linux-image-6.1.0-34-amd64: Wireguard fragmentation fails with VXLAN since kernel 6.1.0-34, causing network timeouts

Hi Charles,

On Sun, Jul 06, 2025 at 07:43:35PM +0200, rough.rock3059@datachamp.fr wrote:
> Hi,
> 
> Thank you for the quick reply.
> 
> We tried kernel versions 6.12.35-1 from unstable and 6.15.4-1 from
> experimental and the issue still appears on both versions.

Ack, thanks for confirming that, I just updated the bug metadata to
reflect that.

> We are currently bisecting the changes to identify the commit. This
> will take several days as the server is used in production and we
> need to minimize downtime during working hours. I will get back to
> this issue as soon as the commit is identified.

Yes that is fully understandable. Would be ideal if that can be
reproduced under lab conditions, but then this takes just the time it
needs. 

Ping us back once you have identified the breaking commit.

Thanks for your debugging.

Regards,
Salvatore

[toc] | [next] | [standalone]

#88339

control: tags -1 + moreinfo

Hi Charles,

On Sun, Jul 06, 2025 at 08:59:46PM +0200, Salvatore Bonaccorso wrote:
> Hi Charles,
> 
> On Sun, Jul 06, 2025 at 07:43:35PM +0200, rough.rock3059@datachamp.fr wrote:
> > Hi,
> > 
> > Thank you for the quick reply.
> > 
> > We tried kernel versions 6.12.35-1 from unstable and 6.15.4-1 from
> > experimental and the issue still appears on both versions.
> 
> Ack, thanks for confirming that, I just updated the bug metadata to
> reflect that.
> 
> > We are currently bisecting the changes to identify the commit. This
> > will take several days as the server is used in production and we
> > need to minimize downtime during working hours. I will get back to
> > this issue as soon as the commit is identified.
> 
> Yes that is fully understandable. Would be ideal if that can be
> reproduced under lab conditions, but then this takes just the time it
> needs. 
> 
> Ping us back once you have identified the breaking commit.
> 
> Thanks for your debugging.

I'm not sure where you are right now at the bisect. But yesterday in
our weekly kernel-team meeting we talked about your issue. And Ben
pointed out that he saw recently a PMTU related change.

And in fact htere is 8930424777e4 ("tunnels: Accept PACKET_HOST in
skb_tunnel_check_pmtu().") which is from 6.15-rc1. And it got
backported to various stable series, for your report of interest is
that it was backported to 6.1.134, which falls exactly in the range
you noticed of breaking.

Thus: are you able to test first at all 6.1.y and a revert of the
given commit on top and see if that fixes your issue?

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#88408

Control: tags -1 - moreinfo
Control: tags -1 + confirmed

Hi Charles,

On Sun, Jul 13, 2025 at 08:41:39AM +0200, rough.rock3059@datachamp.fr wrote:
> Hi Salvatore,
> 
> Thank you for your guidance and for pointing out the relevant commit.
> 
> I have tested, checking out from tag 6.1.134:
> - With the revert of commit b88786ea2c8f ("tunnels: Accept PACKET_HOST in skb_tunnel_check_pmtu()"): the issue does not appear and everything works as expected
> - With the commit included (no revert), the issue reappears exactly as before.
> 
> This confirms that the regression is directly linked to this commit.
> 
> Is there anything else I can do or provide to help with the resolution?

Thanks a lot that is great news, so we have isolated the regression
commit already. I will try to assemble a regression report upstream
soon (after checking if it is already known, hopefully not missing a
report) and keep you in the loop.

Regards,
Salvatore

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web