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. 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. Thank you, Charles On Sun, Jul 6, 2025, at 15:33, Salvatore Bonaccorso wrote: > Control: reassign -1 src:linux 6.1.135-1 > Control: tags -1 + upstream moreinfo > Control: found -1 6.12.32-1 > > Hi Charles, > > On Sun, Jul 06, 2025 at 12:57:41PM +0000, Charles Bordet wrote: >> Package: linux-image-6.1.0-34-amd64 >> Severity: important >> >> Dear Maintainer, >> >> What led up to the situation? >> We run a production environment using Debian 12 VMs, with a network >> topology involving VXLAN tunnels encapsulated inside Wireguard >> interfaces. This setup has worked reliably for over a year, with MTU set >> to 1500 on all interfaces except the Wireguard interface (set to 1420). >> Wireguard kernel fragmentation allowed this configuration to function >> without issues, even though the effective path MTU is lower than 1500. >> >> What exactly did you do (or not do) that was effective (or ineffective)? >> We performed a routine system upgrade, updating all packages include the >> kernel. After the upgrade, we observed severe network issues (timeouts, >> very slow HTTP/HTTPS, and apt update failures) on all VMs behind the >> router. SSH and small-packet traffic continued to work. >> >> To diagnose, we: >> >> * Restored a backup (with the previous kernel): the problem disappeared. >> * Repeated the upgrade, confirming the issue reappeared. >> * Systematically tested each kernel version from 6.1.124-1 up to >> 6.1.140-1. The problem first appears with kernel 6.1.135-1; all earlier >> versions work as expected. >> * Kernel version from the backports (6.12.32-1) did not resolve the >> problem. >> >> What was the outcome of this action? >> >> * With kernel 6.1.135-1 or later, network timeouts occur for >> large-packet protocols (HTTP, apt, etc.), while SSH and small-packet >> protocols work. >> * With kernel 6.1.133-1 or earlier, everything works as expected. >> >> What outcome did you expect instead? >> We expected the network to function as before, with Wireguard handling >> fragmentation transparently and no application-level timeouts, >> regardless of the kernel version. > > Thanks for the report and narrowing down the version where the issue > is introduced on Debian side. > > Since you seem to reliably reproduce the issue, would it be possible > that you bisect the changes between 6.1.133 upstream and 6.1.135 now > that we can find the offending commit and make a report upstream? > > Additionally, would it be possible that you try directly as well the > kernel from unstable 6.12.35-1 and 6.15.4-1~exp1 from experimental to > determine if the issue is unresolved there? > > Regards, > Salvatore
