Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #91569 > unrolled thread
| Started by | Alejandro Olivan Alvarez <alejandro.olivan.alvarez@gmail.com> |
|---|---|
| First post | 2026-03-11 11:10 +0100 |
| Last post | 2026-04-22 11:30 +0200 |
| Articles | 11 — 5 participants |
Back to article view | Back to linux.debian.kernel
Bug#1130336: linux-image-6.12.73+deb13-amd64: Network failure beyond first connection Alejandro Olivan Alvarez <alejandro.olivan.alvarez@gmail.com> - 2026-03-11 11:10 +0100
Bug#1130336: linux-image-6.12.73+deb13-amd64: Network failure beyond first connection Salvatore Bonaccorso <carnil@debian.org> - 2026-03-11 11:20 +0100
Processed: Re: Bug#1130336: linux-image-6.12.73+deb13-amd64: Network failure beyond first connection "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-03-11 11:20 +0100
Processed: Re: Bug#1130336: linux-image-6.12.73+deb13-amd64: Network failure beyond first connection "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-03-11 12:20 +0100
Processed: Re: Bug#1130336: linux-image-6.12.73+deb13-amd64: Network failure beyond first connection "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-03-11 17:20 +0100
Bug#1130336: linux-image-6.12.73+deb13-amd64: Network failure beyond first connection Salvatore Bonaccorso <carnil@debian.org> - 2026-03-11 17:50 +0100
Processed: Re: Bug#1130336: linux-image-6.12.73+deb13-amd64: Network failure beyond first connection "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-03-11 17:50 +0100
Processed: [regression] Network failure beyond first connection after 69894e5b4c5e ("netfilter: nft_connlimit: update the count if add was skipped") "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-03-14 15:10 +0100
Bug#1130336: [regression] Network failure beyond first connection after 69894e5b4c5e ("netfilter: nft_connlimit: update the count if add was skipped") Florian Westphal <fw@strlen.de> - 2026-03-14 20:40 +0100
Bug#1130336: [regression] Network failure beyond first connection after 69894e5b4c5e ("netfilter: nft_connlimit: update the count if add was skipped") Salvatore Bonaccorso <carnil@debian.org> - 2026-03-18 14:00 +0100
Bug#1130336: [regression] Network failure beyond first connection after 69894e5b4c5e ("netfilter: nft_connlimit: update the count if add was skipped") Thorsten Leemhuis <regressions@leemhuis.info> - 2026-04-22 11:30 +0200
| From | Alejandro Olivan Alvarez <alejandro.olivan.alvarez@gmail.com> |
|---|---|
| Date | 2026-03-11 11:10 +0100 |
| Subject | Bug#1130336: linux-image-6.12.73+deb13-amd64: Network failure beyond first connection |
| Message-ID | <MxoFP-6CU8-7@gated-at.bofh.it> |
Package: linux-image-6.12.73+deb13-amd64
Version: 6.12.73-1
Severity: normal
X-Debbugs-Cc: alejandro.olivan.alvarez@gmail.com
Dear Maintainer,
* What led up to the situation?
apt-get dist-upgrade
* What exactly did you do (or not do) that was effective (or
ineffective)?
reboot to previous linux-image-6.12.41+deb13-amd64 makes networking
work again.
* What was the outcome of this action?
Seems like TCP connections do not work beyond the first connection.
For example, two apt-get update commands fail on the second one:
root@marcamalaga:~# uname -r
6.12.73+deb13-amd64
root@marcamalaga:~# date
Wed Mar 11 10:22:19 AM CET 2026
root@marcamalaga:~# apt-get update
Get:1 http://security.debian.org/debian-security trixie-security InRelease
[43.4 kB]
Hit:2 http://ftp.es.debian.org/debian trixie InRelease
Get:3 http://ftp.es.debian.org/debian trixie-updates InRelease [47.3 kB]
Hit:4 https://www.deb-multimedia.org trixie InRelease
Fetched 90.7 kB in 1s (152 kB/s)
Reading package lists... Done
root@marcamalaga:~#
root@marcamalaga:~# date
Wed Mar 11 10:22:28 AM CET 2026
root@marcamalaga:~#
root@marcamalaga:~# apt-get update
Hit:1 http://security.debian.org/debian-security trixie-security InRelease
Hit:2 http://ftp.es.debian.org/debian trixie InRelease
Hit:3 http://ftp.es.debian.org/debian trixie-updates InRelease
Ign:4 https://www.deb-multimedia.org trixie InRelease
Ign:4 https://www.deb-multimedia.org trixie InRelease
Ign:4 https://www.deb-multimedia.org trixie InRelease
Err:4 https://www.deb-multimedia.org trixie InRelease
Cannot initiate the connection to www.deb-multimedia.org:443
(2607:5300:120:e71::1). - connect (101: Network is unreachable) Could not
connect to www.deb-multimedia.org:443 (158.69.254.113), connection timed out
Cannot initiate the connection to www.deb-multimedia.org:443
(2607:5300:120:e71::1). - connect (101: Network is unreachable)
Reading package lists... Done
W: Failed to fetch https://www.deb-multimedia.org/dists/trixie/InRelease
Cannot initiate the connection to www.deb-multimedia.org:443
(2607:5300:120:e71::1). - connect (101: Network is unreachable)
W: Some index files failed to download. They have been ignored, or old ones
used instead.
root@marcamalaga:~#
Similarly, for illustration, here two probes of an HTTP stream, works
only once:
administrator@marcamalaga:~$ uname -r
6.12.73+deb13-amd64
administrator@marcamalaga:~$ date
Wed Mar 11 10:19:23 AM CET 2026
administrator@marcamalaga:~$ ffprobe http://10.20.10.80:8130/malagafmmobile
ffprobe version 7.1.3 Copyright (c) 2007-2025 the FFmpeg developers
built with gcc 14 (Debian 14.2.0-19)
configuration: --disable-decoder=amrnb --disable-gnutls --disable-liblensfun
--disable-libopencv --disable-podpages --disable-sndio --disable-stripping
--disable-omx --enable-avfilter --enable-chromaprint --enable-frei0r --enable-
gcrypt --enable-gpl --enable-ladspa --enable-libaom --enable-libaribb24
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-
libcdio --enable-libcodec2 --enable-libdav1d --enable-libdavs2 --enable-
libdc1394 --enable-libdrm --enable-libdvdnav --enable-libdvdread --enable-
libfdk-aac --enable-libflite --enable-libfontconfig --enable-libfreetype
--enable-libfribidi --enable-libgme --enable-libgsm --enable-libharfbuzz
--enable-libiec61883 --enable-libilbc --enable-libjack --enable-libjxl
--enable-libklvanc --enable-libkvazaar --enable-libmp3lame --enable-libmysofa
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264
--enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo
--enable-libpulse --enable-librabbitmq --enable-librist --enable-librsvg
--enable-librubberband --enable-libshine --enable-libsmbclient --enable-
libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libsvtav1
--enable-libtesseract --enable-libtheora --enable-libtwolame --enable-
libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libwebp --enable-libwebp --enable-libx264 --enable-
libx265 --enable-libxavs2 --enable-libxml2 --enable-libxvid --enable-libzimg
--enable-libzmq --enable-libzvbi --enable-lv2 --enable-nonfree --enable-openal
--enable-opencl --enable-opengl --enable-openssl --enable-postproc --enable-
pthreads --enable-shared --enable-version3 --incdir=/usr/include/x86_64-linux-
gnu --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --toolchain=hardened
--enable-vaapi --enable-libvpl --cc=x86_64-linux-gnu-gcc --cxx=x86_64-linux-
gnu-g++ --disable-altivec --shlibdir=/usr/lib/x86_64-linux-gnu
libavutil 59. 39.100 / 59. 39.100
libavcodec 61. 19.101 / 61. 19.101
libavformat 61. 7.100 / 61. 7.100
libavdevice 61. 3.100 / 61. 3.100
libavfilter 10. 4.100 / 10. 4.100
libswscale 8. 3.100 / 8. 3.100
libswresample 5. 3.100 / 5. 3.100
libpostproc 58. 3.100 / 58. 3.100
Input #0, mp3, from 'http://10.20.10.80:8130/malagafmmobile':
Metadata:
icy-br : 170
icy-description : : Radio MARCA MA :
icy-genre : Sport Radio
icy-name : : Radio MARCA MA :
icy-pub : 1
icy-url : www.radiomarca.com
StreamTitle :
Duration: N/A, start: 0.000000, bitrate: 191 kb/s
Stream #0:0: Audio: mp3 (mp3float), 44100 Hz, stereo, fltp, 191 kb/s
administrator@marcamalaga:~$
administrator@marcamalaga:~$
administrator@marcamalaga:~$ date
Wed Mar 11 10:19:44 AM CET 2026
administrator@marcamalaga:~$ ffprobe http://10.20.10.80:8130/malagafmmobile
ffprobe version 7.1.3 Copyright (c) 2007-2025 the FFmpeg developers
built with gcc 14 (Debian 14.2.0-19)
configuration: --disable-decoder=amrnb --disable-gnutls --disable-liblensfun
--disable-libopencv --disable-podpages --disable-sndio --disable-stripping
--disable-omx --enable-avfilter --enable-chromaprint --enable-frei0r --enable-
gcrypt --enable-gpl --enable-ladspa --enable-libaom --enable-libaribb24
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-
libcdio --enable-libcodec2 --enable-libdav1d --enable-libdavs2 --enable-
libdc1394 --enable-libdrm --enable-libdvdnav --enable-libdvdread --enable-
libfdk-aac --enable-libflite --enable-libfontconfig --enable-libfreetype
--enable-libfribidi --enable-libgme --enable-libgsm --enable-libharfbuzz
--enable-libiec61883 --enable-libilbc --enable-libjack --enable-libjxl
--enable-libklvanc --enable-libkvazaar --enable-libmp3lame --enable-libmysofa
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264
--enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo
--enable-libpulse --enable-librabbitmq --enable-librist --enable-librsvg
--enable-librubberband --enable-libshine --enable-libsmbclient --enable-
libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libsvtav1
--enable-libtesseract --enable-libtheora --enable-libtwolame --enable-
libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libwebp --enable-libwebp --enable-libx264 --enable-
libx265 --enable-libxavs2 --enable-libxml2 --enable-libxvid --enable-libzimg
--enable-libzmq --enable-libzvbi --enable-lv2 --enable-nonfree --enable-openal
--enable-opencl --enable-opengl --enable-openssl --enable-postproc --enable-
pthreads --enable-shared --enable-version3 --incdir=/usr/include/x86_64-linux-
gnu --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --toolchain=hardened
--enable-vaapi --enable-libvpl --cc=x86_64-linux-gnu-gcc --cxx=x86_64-linux-
gnu-g++ --disable-altivec --shlibdir=/usr/lib/x86_64-linux-gnu
libavutil 59. 39.100 / 59. 39.100
libavcodec 61. 19.101 / 61. 19.101
libavformat 61. 7.100 / 61. 7.100
libavdevice 61. 3.100 / 61. 3.100
libavfilter 10. 4.100 / 10. 4.100
libswscale 8. 3.100 / 8. 3.100
libswresample 5. 3.100 / 5. 3.100
libpostproc 58. 3.100 / 58. 3.100
[tcp @ 0x561036562fc0] Connection to tcp://10.20.10.80:8130 failed: Connection
timed out
http://10.20.10.80:8130/malagafmmobile: Connection timed out
The problem happens on VIRTUAL MACHINES (PROXMOX 9 guests) using virtio
drivers.
I have experienced same behaviour on dist-upgraded Bookworm VMs with
latest kernel.
All VMs worked as expected and are inproduction without any issues
before dist-upgrading them.
Machines still not dist-upgraded work flawless.
The problem is fully consistent with kernel upgrade... just reboot to
previous kernel to resume work.
* What outcome did you expect instead?
Regular operation of the networking stack
-- System Information:
Debian Release: 13.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.63+deb13-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages linux-image-6.12.73+deb13-amd64 depends on:
ii initramfs-tools [linux-initramfs-tool] 0.148.3
ii kmod 34.2-2
ii linux-base 4.12
Versions of packages linux-image-6.12.73+deb13-amd64 recommends:
ii apparmor 4.1.0-1
Versions of packages linux-image-6.12.73+deb13-amd64 suggests:
pn debian-kernel-handbook <none>
pn firmware-linux-free <none>
ii grub-efi-amd64 2.12-9
pn linux-doc-6.12 <none>
[toc] | [next] | [standalone]
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2026-03-11 11:20 +0100 |
| Message-ID | <MxoPv-6CYq-1@gated-at.bofh.it> |
| In reply to | #91569 |
Control: tags -1 + moreinfo upstream
Hi
On Wed, Mar 11, 2026 at 11:02:42AM +0100, Alejandro Olivan Alvarez wrote:
> Package: linux-image-6.12.73+deb13-amd64
> Version: 6.12.73-1
> Severity: normal
> X-Debbugs-Cc: alejandro.olivan.alvarez@gmail.com
>
> Dear Maintainer,
>
> * What led up to the situation?
> apt-get dist-upgrade
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
> reboot to previous linux-image-6.12.41+deb13-amd64 makes networking
> work again.
>
> * What was the outcome of this action?
>
> Seems like TCP connections do not work beyond the first connection.
> For example, two apt-get update commands fail on the second one:
>
> root@marcamalaga:~# uname -r
> 6.12.73+deb13-amd64
> root@marcamalaga:~# date
> Wed Mar 11 10:22:19 AM CET 2026
> root@marcamalaga:~# apt-get update
> Get:1 http://security.debian.org/debian-security trixie-security InRelease
> [43.4 kB]
> Hit:2 http://ftp.es.debian.org/debian trixie InRelease
> Get:3 http://ftp.es.debian.org/debian trixie-updates InRelease [47.3 kB]
> Hit:4 https://www.deb-multimedia.org trixie InRelease
> Fetched 90.7 kB in 1s (152 kB/s)
> Reading package lists... Done
> root@marcamalaga:~#
> root@marcamalaga:~# date
> Wed Mar 11 10:22:28 AM CET 2026
> root@marcamalaga:~#
> root@marcamalaga:~# apt-get update
> Hit:1 http://security.debian.org/debian-security trixie-security InRelease
> Hit:2 http://ftp.es.debian.org/debian trixie InRelease
> Hit:3 http://ftp.es.debian.org/debian trixie-updates InRelease
> Ign:4 https://www.deb-multimedia.org trixie InRelease
> Ign:4 https://www.deb-multimedia.org trixie InRelease
> Ign:4 https://www.deb-multimedia.org trixie InRelease
> Err:4 https://www.deb-multimedia.org trixie InRelease
> Cannot initiate the connection to www.deb-multimedia.org:443
> (2607:5300:120:e71::1). - connect (101: Network is unreachable) Could not
> connect to www.deb-multimedia.org:443 (158.69.254.113), connection timed out
> Cannot initiate the connection to www.deb-multimedia.org:443
> (2607:5300:120:e71::1). - connect (101: Network is unreachable)
> Reading package lists... Done
> W: Failed to fetch https://www.deb-multimedia.org/dists/trixie/InRelease
> Cannot initiate the connection to www.deb-multimedia.org:443
> (2607:5300:120:e71::1). - connect (101: Network is unreachable)
> W: Some index files failed to download. They have been ignored, or old ones
> used instead.
> root@marcamalaga:~#
>
> Similarly, for illustration, here two probes of an HTTP stream, works
> only once:
>
> administrator@marcamalaga:~$ uname -r
> 6.12.73+deb13-amd64
> administrator@marcamalaga:~$ date
> Wed Mar 11 10:19:23 AM CET 2026
> administrator@marcamalaga:~$ ffprobe http://10.20.10.80:8130/malagafmmobile
> ffprobe version 7.1.3 Copyright (c) 2007-2025 the FFmpeg developers
> built with gcc 14 (Debian 14.2.0-19)
> configuration: --disable-decoder=amrnb --disable-gnutls --disable-liblensfun
> --disable-libopencv --disable-podpages --disable-sndio --disable-stripping
> --disable-omx --enable-avfilter --enable-chromaprint --enable-frei0r --enable-
> gcrypt --enable-gpl --enable-ladspa --enable-libaom --enable-libaribb24
> --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-
> libcdio --enable-libcodec2 --enable-libdav1d --enable-libdavs2 --enable-
> libdc1394 --enable-libdrm --enable-libdvdnav --enable-libdvdread --enable-
> libfdk-aac --enable-libflite --enable-libfontconfig --enable-libfreetype
> --enable-libfribidi --enable-libgme --enable-libgsm --enable-libharfbuzz
> --enable-libiec61883 --enable-libilbc --enable-libjack --enable-libjxl
> --enable-libklvanc --enable-libkvazaar --enable-libmp3lame --enable-libmysofa
> --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264
> --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo
> --enable-libpulse --enable-librabbitmq --enable-librist --enable-librsvg
> --enable-librubberband --enable-libshine --enable-libsmbclient --enable-
> libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libsvtav1
> --enable-libtesseract --enable-libtheora --enable-libtwolame --enable-
> libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-libvorbis
> --enable-libvpx --enable-libwebp --enable-libwebp --enable-libx264 --enable-
> libx265 --enable-libxavs2 --enable-libxml2 --enable-libxvid --enable-libzimg
> --enable-libzmq --enable-libzvbi --enable-lv2 --enable-nonfree --enable-openal
> --enable-opencl --enable-opengl --enable-openssl --enable-postproc --enable-
> pthreads --enable-shared --enable-version3 --incdir=/usr/include/x86_64-linux-
> gnu --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --toolchain=hardened
> --enable-vaapi --enable-libvpl --cc=x86_64-linux-gnu-gcc --cxx=x86_64-linux-
> gnu-g++ --disable-altivec --shlibdir=/usr/lib/x86_64-linux-gnu
> libavutil 59. 39.100 / 59. 39.100
> libavcodec 61. 19.101 / 61. 19.101
> libavformat 61. 7.100 / 61. 7.100
> libavdevice 61. 3.100 / 61. 3.100
> libavfilter 10. 4.100 / 10. 4.100
> libswscale 8. 3.100 / 8. 3.100
> libswresample 5. 3.100 / 5. 3.100
> libpostproc 58. 3.100 / 58. 3.100
> Input #0, mp3, from 'http://10.20.10.80:8130/malagafmmobile':
> Metadata:
> icy-br : 170
> icy-description : : Radio MARCA MA :
> icy-genre : Sport Radio
> icy-name : : Radio MARCA MA :
> icy-pub : 1
> icy-url : www.radiomarca.com
> StreamTitle :
> Duration: N/A, start: 0.000000, bitrate: 191 kb/s
> Stream #0:0: Audio: mp3 (mp3float), 44100 Hz, stereo, fltp, 191 kb/s
> administrator@marcamalaga:~$
> administrator@marcamalaga:~$
> administrator@marcamalaga:~$ date
> Wed Mar 11 10:19:44 AM CET 2026
> administrator@marcamalaga:~$ ffprobe http://10.20.10.80:8130/malagafmmobile
> ffprobe version 7.1.3 Copyright (c) 2007-2025 the FFmpeg developers
> built with gcc 14 (Debian 14.2.0-19)
> configuration: --disable-decoder=amrnb --disable-gnutls --disable-liblensfun
> --disable-libopencv --disable-podpages --disable-sndio --disable-stripping
> --disable-omx --enable-avfilter --enable-chromaprint --enable-frei0r --enable-
> gcrypt --enable-gpl --enable-ladspa --enable-libaom --enable-libaribb24
> --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-
> libcdio --enable-libcodec2 --enable-libdav1d --enable-libdavs2 --enable-
> libdc1394 --enable-libdrm --enable-libdvdnav --enable-libdvdread --enable-
> libfdk-aac --enable-libflite --enable-libfontconfig --enable-libfreetype
> --enable-libfribidi --enable-libgme --enable-libgsm --enable-libharfbuzz
> --enable-libiec61883 --enable-libilbc --enable-libjack --enable-libjxl
> --enable-libklvanc --enable-libkvazaar --enable-libmp3lame --enable-libmysofa
> --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264
> --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo
> --enable-libpulse --enable-librabbitmq --enable-librist --enable-librsvg
> --enable-librubberband --enable-libshine --enable-libsmbclient --enable-
> libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libsvtav1
> --enable-libtesseract --enable-libtheora --enable-libtwolame --enable-
> libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-libvorbis
> --enable-libvpx --enable-libwebp --enable-libwebp --enable-libx264 --enable-
> libx265 --enable-libxavs2 --enable-libxml2 --enable-libxvid --enable-libzimg
> --enable-libzmq --enable-libzvbi --enable-lv2 --enable-nonfree --enable-openal
> --enable-opencl --enable-opengl --enable-openssl --enable-postproc --enable-
> pthreads --enable-shared --enable-version3 --incdir=/usr/include/x86_64-linux-
> gnu --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --toolchain=hardened
> --enable-vaapi --enable-libvpl --cc=x86_64-linux-gnu-gcc --cxx=x86_64-linux-
> gnu-g++ --disable-altivec --shlibdir=/usr/lib/x86_64-linux-gnu
> libavutil 59. 39.100 / 59. 39.100
> libavcodec 61. 19.101 / 61. 19.101
> libavformat 61. 7.100 / 61. 7.100
> libavdevice 61. 3.100 / 61. 3.100
> libavfilter 10. 4.100 / 10. 4.100
> libswscale 8. 3.100 / 8. 3.100
> libswresample 5. 3.100 / 5. 3.100
> libpostproc 58. 3.100 / 58. 3.100
> [tcp @ 0x561036562fc0] Connection to tcp://10.20.10.80:8130 failed: Connection
> timed out
> http://10.20.10.80:8130/malagafmmobile: Connection timed out
>
> The problem happens on VIRTUAL MACHINES (PROXMOX 9 guests) using virtio
> drivers.
> I have experienced same behaviour on dist-upgraded Bookworm VMs with
> latest kernel.
> All VMs worked as expected and are inproduction without any issues
> before dist-upgrading them.
> Machines still not dist-upgraded work flawless.
> The problem is fully consistent with kernel upgrade... just reboot to
> previous kernel to resume work.
>
> * What outcome did you expect instead?
> Regular operation of the networking stack
I suspect this then depends on the underlaying virtualisation,
otherwise we would have I think more such reports. As you have a
fairly straightforward reproducer, can you please bisect the changes
between 6.12.41 and 6.12.73? (Ideally you test first the kernels
inbetween up to 6.12.69-1 so we have a closer range, you can get other
images earlier in the archive from the snapshots service. This should
be done as first step, because there were a a couple of releases in
Debian between 6.12.41-1 and 6.12.73-1). So assume you have 6.12.69-1
which is good, and 6.12.73-1 which is not anymore, bisecting would
involve:
git clone --single-branch -b linux-6.12.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
cd linux-stable
git checkout v6.12.69
cp /boot/config-$(uname -r) .config
yes '' | make localmodconfig
make savedefconfig
mv defconfig arch/x86/configs/my_defconfig
# test 6.12.69 to ensure this is "good"
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm problem does not exist
# test 6.12.73 to ensure this is "bad"
git checkout v6.12.73
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm the problem exists.
With that confirmed, the bisection can start:
git bisect start
git bisect good v6.12.69
git bisect bad v6.12.73
In each bisection step git checks out a state between the oldest
known-bad and the newest known-good commit. In each step test using:
make my_defconfig
make -j $(nproc) bindeb-pkg
... install, verify if problem exists
and if the problem is hit run:
git bisect bad
and if the problem doesn't trigger run:
git bisect good
. Please pay attention to always select the just built kernel for
booting, it won't always be the default kernel picked up by grub.
Iterate until git announces to have identified the first bad commit.
Then provide the output of
git bisect log
In the course of the bisection you might have to uninstall previous
kernels again to not exhaust the disk space in /boot. Also in the end
uninstall all self-built kernels again.
Regards,
Salvatore
[toc] | [prev] | [next] | [standalone]
| From | "Debian Bug Tracking System" <owner@bugs.debian.org> |
|---|---|
| Date | 2026-03-11 11:20 +0100 |
| Subject | Processed: Re: Bug#1130336: linux-image-6.12.73+deb13-amd64: Network failure beyond first connection |
| Message-ID | <MxoPv-6CYq-11@gated-at.bofh.it> |
| In reply to | #91569 |
Processing control commands: > tags -1 + moreinfo upstream Bug #1130336 [src:linux] linux-image-6.12.73+deb13-amd64: Network failure beyond first connection Added tag(s) moreinfo and upstream. -- 1130336: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1130336 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
[toc] | [prev] | [next] | [standalone]
| From | "Debian Bug Tracking System" <owner@bugs.debian.org> |
|---|---|
| Date | 2026-03-11 12:20 +0100 |
| Subject | Processed: Re: Bug#1130336: linux-image-6.12.73+deb13-amd64: Network failure beyond first connection |
| Message-ID | <MxpLz-6DAW-5@gated-at.bofh.it> |
| In reply to | #91569 |
Processing control commands: > found -1 6.12.63-1 Bug #1130336 [src:linux] linux-image-6.12.73+deb13-amd64: Network failure beyond first connection Marked as found in versions linux/6.12.63-1. -- 1130336: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1130336 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
[toc] | [prev] | [next] | [standalone]
| From | "Debian Bug Tracking System" <owner@bugs.debian.org> |
|---|---|
| Date | 2026-03-11 17:20 +0100 |
| Subject | Processed: Re: Bug#1130336: linux-image-6.12.73+deb13-amd64: Network failure beyond first connection |
| Message-ID | <MxurU-6GGS-11@gated-at.bofh.it> |
| In reply to | #91569 |
Processing control commands: > tags -1 + moreinfo upstream Bug #1130336 [src:linux] linux-image-6.12.73+deb13-amd64: Network failure beyond first connection Added tag(s) moreinfo. -- 1130336: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1130336 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
[toc] | [prev] | [next] | [standalone]
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2026-03-11 17:50 +0100 |
| Message-ID | <MxuUV-6GS4-1@gated-at.bofh.it> |
| In reply to | #91569 |
Control: tags -1 - moreinfo Control: tags -1 + confirmed Control: found -1 6.19.6-1 Hi Alejandro, On Wed, Mar 11, 2026 at 05:32:00PM +0100, Alejandro Oliván Alvarez wrote: > Hi. > > I probably will succeed installing a given kernel from backports. OTOH > I've never messed with unstable (I have never though on bring a kernel > to a stable system). > > Notice though that I CAN FULLY REPRODUCE the exact same issue on > oldstable Bookworm: > Until 6.1.0-42, iptables connection limit DoS rule worked as always > did, whereas from 6.1.0-43 upgrading results in unusable networking. > commenting out the rule and reloading iptables makes networking work > again. > > Will report as (if) I have something. > Cheers. No need to test 6.19.6-1 explicitly, with your rule I can reproduce the problem on my own and looks to be present as well on 6.19.6-1. Will double-check once more and then possibly approach upstream with your report. Regards, Salvatore
[toc] | [prev] | [next] | [standalone]
| From | "Debian Bug Tracking System" <owner@bugs.debian.org> |
|---|---|
| Date | 2026-03-11 17:50 +0100 |
| Subject | Processed: Re: Bug#1130336: linux-image-6.12.73+deb13-amd64: Network failure beyond first connection |
| Message-ID | <MxuUW-6GS4-11@gated-at.bofh.it> |
| In reply to | #91569 |
Processing control commands: > tags -1 - moreinfo Bug #1130336 [src:linux] linux-image-6.12.73+deb13-amd64: Network failure beyond first connection Removed tag(s) moreinfo. > tags -1 + confirmed Bug #1130336 [src:linux] linux-image-6.12.73+deb13-amd64: Network failure beyond first connection Added tag(s) confirmed. > found -1 6.19.6-1 Bug #1130336 [src:linux] linux-image-6.12.73+deb13-amd64: Network failure beyond first connection Marked as found in versions linux/6.19.6-1. -- 1130336: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1130336 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
[toc] | [prev] | [next] | [standalone]
| From | "Debian Bug Tracking System" <owner@bugs.debian.org> |
|---|---|
| Date | 2026-03-14 15:10 +0100 |
| Subject | Processed: [regression] Network failure beyond first connection after 69894e5b4c5e ("netfilter: nft_connlimit: update the count if add was skipped") |
| Message-ID | <MyxQJ-7sKq-3@gated-at.bofh.it> |
| In reply to | #91569 |
Processing control commands: > forwarded -1 https://lore.kernel.org/regressions/177349610461.3071718.4083978280323144323@eldamar.lan Bug #1130336 [src:linux] linux-image-6.12.73+deb13-amd64: Network failure beyond first connection Set Bug forwarded-to-address to 'https://lore.kernel.org/regressions/177349610461.3071718.4083978280323144323@eldamar.lan'. > tags -1 + upstream Bug #1130336 [src:linux] linux-image-6.12.73+deb13-amd64: Network failure beyond first connection Ignoring request to alter tags of bug #1130336 to the same tags previously set -- 1130336: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1130336 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
[toc] | [prev] | [next] | [standalone]
| From | Florian Westphal <fw@strlen.de> |
|---|---|
| Date | 2026-03-14 20:40 +0100 |
| Subject | Bug#1130336: [regression] Network failure beyond first connection after 69894e5b4c5e ("netfilter: nft_connlimit: update the count if add was skipped") |
| Message-ID | <MyD05-7w3L-3@gated-at.bofh.it> |
| In reply to | #91569 |
Fernando Fernandez Mancera <fmancera@suse.de> wrote:
> On 3/14/26 5:13 PM, Fernando Fernandez Mancera wrote:
> > Hi,
> >
> > On 3/14/26 3:03 PM, Salvatore Bonaccorso wrote:
> > > Control: forwarded -1
> > > https://lore.kernel.org/ regressions/177349610461.3071718.4083978280323144323@eldamar.lan
> > > Control: tags -1 + upstream
> > >
> > > Hi
> > >
> > > In Debian, in https://bugs.debian.org/1130336, Alejandro reported that
> > > after updates including 69894e5b4c5e ("netfilter: nft_connlimit:
> > > update the count if add was skipped"), when the following rule is set
> > >
> > > iptables -A INPUT -p tcp -m
> > > connlimit --connlimit-above 111 -j
> > > REJECT --reject-with tcp-reset
> > >
> > > connections get stuck accordingly, it can be easily reproduced by:
> > >
> > > # iptables -A INPUT -p tcp -m connlimit
> > > --connlimit-above 111 -j REJECT
> > > --reject-with tcp-reset
> > > # nft list ruleset
> > > # Warning: table ip filter is managed by iptables-nft, do not touch!
> > > table ip filter {
> > > chain INPUT {
> > > type filter hook input priority filter; policy accept;
> > > ip protocol tcp xt
> > > match "connlimit" counter packets 0
> > > bytes 0 reject with tcp reset
> > > }
> > > }
> > > # wget -O /dev/null
> > > https://git.kernel.org/torvalds/t/linux-7.0-
> > > rc3.tar.gz
> > > --2026-03-14 14:53:51--
> > > https://git.kernel.org/torvalds/t/linux-7.0-
> > > rc3.tar.gz
> > > Resolving git.kernel.org
> > > (git.kernel.org)... 172.105.64.184,
> > > 2a01:7e01:e001:937:0:1991:8:25
> > > Connecting to git.kernel.org
> > > (git.kernel.org)|172.105.64.184|:443...
> > > connected.
> > > HTTP request sent, awaiting response... 301 Moved Permanently
> > > Location: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
> > > linux.git/snapshot/linux-7.0-rc3.tar.gz
> > > [following]
> > > --2026-03-14 14:53:51--
> > > https://git.kernel.org/pub/scm/linux/kernel/ git/torvalds/linux.git/snapshot/linux-7.0-rc3.tar.gz
> > > Reusing existing connection to git.kernel.org:443.
> > > HTTP request sent, awaiting response... 200 OK
> > > Length: unspecified [application/x-gzip]
> > > Saving to: ‘/dev/null’
> > >
> > > /dev/null [
> > > <=> ] 248.03M
> > > 51.9MB/s in 5.0s
> > >
> > > 2026-03-14 14:53:56 (49.3 MB/s) - ‘/dev/null’ saved [260080129]
> > >
> > > # wget -O /dev/null
> > > https://git.kernel.org/torvalds/t/linux-7.0-
> > > rc3.tar.gz
> > > --2026-03-14 14:53:58--
> > > https://git.kernel.org/torvalds/t/linux-7.0-
> > > rc3.tar.gz
> > > Resolving git.kernel.org
> > > (git.kernel.org)... 172.105.64.184,
> > > 2a01:7e01:e001:937:0:1991:8:25
> > > Connecting to git.kernel.org
> > > (git.kernel.org)|172.105.64.184|:443...
> > > failed: Connection timed out.
> > > Connecting to git.kernel.org
> > > (git.kernel.org)|
> > > 2a01:7e01:e001:937:0:1991:8:25|:443...
> > > failed: Network is unreachable.
> > >
> > > Before the 69894e5b4c5e ("netfilter: nft_connlimit: update the count
> > > if add was skipped") commit this worked.
> > >
> >
> > Thanks for the report. I have reproduced
> > this on upstream kernel. I am working on it.
> >
>
> This is what is happening:
>
> 1. The first connection is established and
> tracked, all good. When it finishes, it goes to
> TIME_WAIT state
> 2. The second connection is established, ct is
> confirmed since the beginning, skipping the
> tracking and calling a GC.
> 3. The previously tracked connection is cleaned
> up during GC as TIME_WAIT is considered closed.
This is stupid. The fix is to add --syn or use
OUTPUT. Its not even clear to me what the user wants to achive with this rule.
> +static inline bool tcp_syn_sent_or_recv(const struct nf_conn *conn)
> +{
> + if (nf_ct_protonum(conn) == IPPROTO_TCP)
> + return conn->proto.tcp.state == TCP_CONNTRACK_SYN_SENT ||
> + conn->proto.tcp.state == TCP_CONNTRACK_SYN_RECV;
> + else
> + return false;
> +}
We're adding ever more complex checks in the conncount backend.
I don't like any of the solutions.
What about reverting the offending commit, at least for tree_count?
That way it continues to work as it did in the past.
[toc] | [prev] | [next] | [standalone]
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2026-03-18 14:00 +0100 |
| Subject | Bug#1130336: [regression] Network failure beyond first connection after 69894e5b4c5e ("netfilter: nft_connlimit: update the count if add was skipped") |
| Message-ID | <MzYFb-8s7S-9@gated-at.bofh.it> |
| In reply to | #91569 |
Hi Alejandro,
On Sun, Mar 15, 2026 at 02:09:33AM +0100, Fernando Fernandez Mancera wrote:
> On 3/14/26 8:25 PM, Florian Westphal wrote:
> > Fernando Fernandez Mancera <fmancera@suse.de> wrote:
> > > On 3/14/26 5:13 PM, Fernando Fernandez Mancera wrote:
> > > > Hi,
> > > >
> > > > On 3/14/26 3:03 PM, Salvatore Bonaccorso wrote:
> > > > > Control: forwarded -1
> > > > > https://lore.kernel.org/ regressions/177349610461.3071718.4083978280323144323@eldamar.lan
> > > > > Control: tags -1 + upstream
> > > > >
> > > > > Hi
> > > > >
> > > > > In Debian, in https://bugs.debian.org/1130336, Alejandro reported that
> > > > > after updates including 69894e5b4c5e ("netfilter: nft_connlimit:
> > > > > update the count if add was skipped"), when the following rule is set
> > > > >
> > > > > iptables -A INPUT -p tcp -m
> > > > > connlimit --connlimit-above 111 -j
> > > > > REJECT --reject-with tcp-reset
> > > > >
> > > > > connections get stuck accordingly, it can be easily reproduced by:
> > > > >
> > > > > # iptables -A INPUT -p tcp -m connlimit
> > > > > --connlimit-above 111 -j REJECT
> > > > > --reject-with tcp-reset
> > > > > # nft list ruleset
> > > > > # Warning: table ip filter is managed by iptables-nft, do not touch!
> > > > > table ip filter {
> > > > > chain INPUT {
> > > > > type filter hook input priority filter; policy accept;
> > > > > ip protocol tcp xt
> > > > > match "connlimit" counter packets 0
> > > > > bytes 0 reject with tcp reset
> > > > > }
> > > > > }
> > > > > # wget -O /dev/null
> > > > > https://git.kernel.org/torvalds/t/linux-7.0-
> > > > > rc3.tar.gz
> > > > > --2026-03-14 14:53:51--
> > > > > https://git.kernel.org/torvalds/t/linux-7.0-
> > > > > rc3.tar.gz
> > > > > Resolving git.kernel.org
> > > > > (git.kernel.org)... 172.105.64.184,
> > > > > 2a01:7e01:e001:937:0:1991:8:25
> > > > > Connecting to git.kernel.org
> > > > > (git.kernel.org)|172.105.64.184|:443...
> > > > > connected.
> > > > > HTTP request sent, awaiting response... 301 Moved Permanently
> > > > > Location: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
> > > > > linux.git/snapshot/linux-7.0-rc3.tar.gz
> > > > > [following]
> > > > > --2026-03-14 14:53:51--
> > > > > https://git.kernel.org/pub/scm/linux/kernel/ git/torvalds/linux.git/snapshot/linux-7.0-rc3.tar.gz
> > > > > Reusing existing connection to git.kernel.org:443.
> > > > > HTTP request sent, awaiting response... 200 OK
> > > > > Length: unspecified [application/x-gzip]
> > > > > Saving to: ‘/dev/null’
> > > > >
> > > > > /dev/null [
> > > > > <=> ] 248.03M
> > > > > 51.9MB/s in 5.0s
> > > > >
> > > > > 2026-03-14 14:53:56 (49.3 MB/s) - ‘/dev/null’ saved [260080129]
> > > > >
> > > > > # wget -O /dev/null
> > > > > https://git.kernel.org/torvalds/t/linux-7.0-
> > > > > rc3.tar.gz
> > > > > --2026-03-14 14:53:58--
> > > > > https://git.kernel.org/torvalds/t/linux-7.0-
> > > > > rc3.tar.gz
> > > > > Resolving git.kernel.org
> > > > > (git.kernel.org)... 172.105.64.184,
> > > > > 2a01:7e01:e001:937:0:1991:8:25
> > > > > Connecting to git.kernel.org
> > > > > (git.kernel.org)|172.105.64.184|:443...
> > > > > failed: Connection timed out.
> > > > > Connecting to git.kernel.org
> > > > > (git.kernel.org)|
> > > > > 2a01:7e01:e001:937:0:1991:8:25|:443...
> > > > > failed: Network is unreachable.
> > > > >
> > > > > Before the 69894e5b4c5e ("netfilter: nft_connlimit: update the count
> > > > > if add was skipped") commit this worked.
> > > > >
> > > >
> > > > Thanks for the report. I have reproduced
> > > > this on upstream kernel. I am working on it.
> > > >
> > >
> > > This is what is happening:
> > >
> > > 1. The first connection is established and
> > > tracked, all good. When it finishes, it goes to
> > > TIME_WAIT state
> > > 2. The second connection is established, ct is
> > > confirmed since the beginning, skipping the
> > > tracking and calling a GC.
> > > 3. The previously tracked connection is cleaned
> > > up during GC as TIME_WAIT is considered closed.
> >
> > This is stupid. The fix is to add --syn or use
> > OUTPUT. Its not even clear to me what the user wants to achive with this rule.
> >
>
> Yes, the ruleset shown does not make sense. Having said this, it could
> affect to a soft-limit scenario as the one described on the blamed commit..
Alejandro, can you describe what you would like to achieve with the
specific rule?
Regards,
Salvatore
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Leemhuis <regressions@leemhuis.info> |
|---|---|
| Date | 2026-04-22 11:30 +0200 |
| Subject | Bug#1130336: [regression] Network failure beyond first connection after 69894e5b4c5e ("netfilter: nft_connlimit: update the count if add was skipped") |
| Message-ID | <MMC49-h64Q-5@gated-at.bofh.it> |
| In reply to | #91569 |
Lo! Top-posting on purpose to make this easy to process.
What happened to this regression? It looks a bit like things stalled and
fell through the cracks. Or Fernando, did you post a patch like you
mentioned? I looked for one referring the commit or the reporter, but
could not find anything -- but maybe I missed it.
Ciao, Thorsten
On 3/19/26 09:59, Fernando Fernandez Mancera wrote:
> On 3/19/26 9:44 AM, Alejandro Oliván Alvarez wrote:
>> Hi folks.
>>
>> On Wed, 2026-03-18 at 13:49 +0100, Salvatore Bonaccorso wrote:
>>> Hi Alejandro,
>>>
>>> On Sun, Mar 15, 2026 at 02:09:33AM +0100, Fernando Fernandez Mancera
>>> wrote:
>>>> On 3/14/26 8:25 PM, Florian Westphal wrote:
>>>>> Fernando Fernandez Mancera <fmancera@suse.de> wrote:
>>>>>> On 3/14/26 5:13 PM, Fernando Fernandez Mancera wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 3/14/26 3:03 PM, Salvatore Bonaccorso wrote:
>>>>>>>> Control: forwarded -1
>>>>>>>> https://lore.kernel.org/
>>>>>>>> regressions/177349610461.3071718.4083978280323144323@eldama
>>>>>>>> r.lan
>>>>>>>> Control: tags -1 + upstream
>>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> In Debian, in https://bugs.debian.org/1130336, Alejandro
>>>>>>>> reported that
>>>>>>>> after updates including 69894e5b4c5e ("netfilter:
>>>>>>>> nft_connlimit:
>>>>>>>> update the count if add was skipped"), when the following
>>>>>>>> rule is set
>>>>>>>>
>>>>>>>> iptables -A INPUT -p tcp -m
>>>>>>>> connlimit --connlimit-above 111 -j
>>>>>>>> REJECT --reject-with tcp-reset
>>>>>>>>
>>>>>>>> connections get stuck accordingly, it can be easily
>>>>>>>> reproduced by:
>>>>>>>>
>>>>>>>> # iptables -A INPUT -p tcp -m connlimit
>>>>>>>> --connlimit-above 111 -j REJECT
>>>>>>>> --reject-with tcp-reset
>>>>>>>> # nft list ruleset
>>>>>>>> # Warning: table ip filter is managed by iptables-nft, do
>>>>>>>> not touch!
>>>>>>>> table ip filter {
>>>>>>>> chain INPUT {
>>>>>>>> type filter hook input priority filter;
>>>>>>>> policy accept;
>>>>>>>> ip protocol tcp xt
>>>>>>>> match "connlimit" counter packets 0
>>>>>>>> bytes 0 reject with tcp reset
>>>>>>>> }
>>>>>>>> }
>>>>>>>> # wget -O /dev/null
>>>>>>>> https://git.kernel.org/torvalds/t/linux-7.0-
>>>>>>>> rc3.tar.gz
>>>>>>>> --2026-03-14 14:53:51--
>>>>>>>> https://git.kernel.org/torvalds/t/linux-7.0-
>>>>>>>> rc3.tar.gz
>>>>>>>> Resolving git.kernel.org
>>>>>>>> (git.kernel.org)... 172.105.64.184,
>>>>>>>> 2a01:7e01:e001:937:0:1991:8:25
>>>>>>>> Connecting to git.kernel.org
>>>>>>>> (git.kernel.org)|172.105.64.184|:443...
>>>>>>>> connected.
>>>>>>>> HTTP request sent, awaiting response... 301 Moved
>>>>>>>> Permanently
>>>>>>>> Location:
>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
>>>>>>>> linux.git/snapshot/linux-7.0-rc3.tar.gz
>>>>>>>> [following]
>>>>>>>> --2026-03-14 14:53:51--
>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/ git/torvalds/l
>>>>>>>> inux.git/snapshot/linux-7.0-rc3.tar.gz
>>>>>>>> Reusing existing connection to git.kernel.org:443.
>>>>>>>> HTTP request sent, awaiting response... 200 OK
>>>>>>>> Length: unspecified [application/x-gzip]
>>>>>>>> Saving to: ‘/dev/null’
>>>>>>>>
>>>>>>>> /dev/null [
>>>>>>>> <=> ] 248.03M
>>>>>>>> 51.9MB/s in 5.0s
>>>>>>>>
>>>>>>>> 2026-03-14 14:53:56 (49.3 MB/s) - ‘/dev/null’ saved
>>>>>>>> [260080129]
>>>>>>>>
>>>>>>>> # wget -O /dev/null
>>>>>>>> https://git.kernel.org/torvalds/t/linux-7.0-
>>>>>>>> rc3.tar.gz
>>>>>>>> --2026-03-14 14:53:58--
>>>>>>>> https://git.kernel.org/torvalds/t/linux-7.0-
>>>>>>>> rc3.tar.gz
>>>>>>>> Resolving git.kernel.org
>>>>>>>> (git.kernel.org)... 172.105.64.184,
>>>>>>>> 2a01:7e01:e001:937:0:1991:8:25
>>>>>>>> Connecting to git.kernel.org
>>>>>>>> (git.kernel.org)|172.105.64.184|:443...
>>>>>>>> failed: Connection timed out.
>>>>>>>> Connecting to git.kernel.org
>>>>>>>> (git.kernel.org)|
>>>>>>>> 2a01:7e01:e001:937:0:1991:8:25|:443...
>>>>>>>> failed: Network is unreachable.
>>>>>>>>
>>>>>>>> Before the 69894e5b4c5e ("netfilter: nft_connlimit: update
>>>>>>>> the count
>>>>>>>> if add was skipped") commit this worked.
>>>>>>>>
>>>>>>>
>>>>>>> Thanks for the report. I have reproduced
>>>>>>> this on upstream kernel. I am working on it.
>>>>>>>
>>>>>>
>>>>>> This is what is happening:
>>>>>>
>>>>>> 1. The first connection is established and
>>>>>> tracked, all good. When it finishes, it goes to
>>>>>> TIME_WAIT state
>>>>>> 2. The second connection is established, ct is
>>>>>> confirmed since the beginning, skipping the
>>>>>> tracking and calling a GC.
>>>>>> 3. The previously tracked connection is cleaned
>>>>>> up during GC as TIME_WAIT is considered closed.
>>>>>
>>>>> This is stupid. The fix is to add --syn or use
>>>>> OUTPUT. Its not even clear to me what the user wants to achive
>>>>> with this rule.
>>>>>
>>>>
>>>> Yes, the ruleset shown does not make sense. Having said this, it
>>>> could
>>>> affect to a soft-limit scenario as the one described on the blamed
>>>> commit..
>>>
>>> Alejandro, can you describe what you would like to achieve with the
>>> specific rule?
>>>
>>> Regards,
>>> Salvatore
>>
>> The intended use of that rule was to prevent (limit) a single host from
>> establishing too many TCP connections to given host (Denial of
>> Service... particularly on streaming servers).
>>
>> I learnt about it in several IPtables guides/howtos (maaaany years
>> ago!), and never was an issue on itself.
>> Was it stupid? ... possibly... It 'seemed' to work, or, at least, when
>> checking iptables -L -v one could see packet counter for the rule
>> catching some traffic, without ever noticing it being troublesome, so,
>> at the very least it 'didn't hurt', and, since DoS ever happened over
>> the years...well, I tended to think it was indeed working the way I
>> read it did.
>>
>> Certainly, I never (the authors of those guides at their time indeed)
>> though about the possibility of just target the TCP syn.
>> I have given a try to adding the --syn option to the rule to see the
>> difference, and well, it is way less disruptive that way, but it still
>> breaks things (I saw postfix queues hanging, for instance).
>>
>
> The current problem with the ruleset is that it mixes both, incoming and
> outgoing connections. This should probably use --syn flag so it targets
> connections established against your host only.
>
> Anyway, I am sending a patch fixing this as it makes sense to do it IMO.
> We just want to understand what is the real use-case and how the ruleset
> can be improved.
>
> In addition, I would recommend you to transition to nftables because it
> would be ideal for your use-case. With nftables it would be easy to
> combine this with sets and probably quota expression to limit the usage.
>
> What is wrong with the current ruleset? (Even before the blammed
> commit), if you reach the connlimit limit **ALL** TCP connections will
> be rejected (including legit ones), I do not think that is what you want
> to achieve.
>
> Thanks,
> Fernando.
>
>> So, I have but screwed the idea of using connlimit anymore anyways.
>> Sorry for the noise. Lesson learned.
>>
>> Cheers!
>
>
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web