[SOLVED] Seemingly random connection errors

ponsilio · 2025-08-27 16:55:15

In my case I experience the problems in 2 laptops. None of them use Nvidia drivers. Both use Intel integrated graphics albeit of different generations.

ponsilio · 2025-08-28 10:44:58

I downgraded another laptop to the 6.16.1 kernel and it seems to work well too.

mcloaked · 2025-08-28 11:47:08

I have seen this on four different machines recently - as a test I have downgraded one laptop back to kernel 6.15.6 with no other change and so far the problem has not recurred. Having seen other regressions for kernel 6.16.x I wonder if this is also a kernel regression?

seth · 2025-08-28 14:44:06

this here is a known bug:
https://bbs.archlinux.org/viewtopic.php … 9#p2258679

mcloaked · 2025-08-28 16:52:37

OK thanks - I should have read the thread more thoroughly. I will need to keep track of when the appropriate commits get to the next stable kernel version.

curve.cpp · 2025-08-28 23:01:40

I'm also having this problem recently. It's occurring on an existing install and did not happen before.
I've been experiencing it on `6.16.3.zen1-1` (Zen) as well as on `6.12.43-1` (LTS) kernels. I have tried both nvidia and nvidia-open but I encountered the problem with both.

curve.cpp · 2025-08-28 23:02:44

Sorry - I just now discovered the second page and overlooked the discussion here

ponsilio · 2025-08-29 14:10:47

Is there a way to follow when the patch will be applied in Arch Linux kernels?
Or is just a matter of trying them out as they are released?

idontgetit · 2025-08-29 14:16:34

ponsilio wrote:

Or is just a matter of trying them out as they are released?

Experimenting with fresh 6.16.4 just now:

> uname -a
Linux foo 6.16.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 28 Aug 2025 19:49:53 +0000 x86_64 GNU/Linux

> curl-test.sh
curl: (7) Failed to connect to google.com port 443 after 2 ms: Could not connect to server
curl: (7) Failed to connect to wikipedia.org port 443 after 2 ms: Could not connect to server
curl: (7) Failed to connect to ntp.org port 443 after 2 ms: Could not connect to server
curl: (7) Failed to connect to 1.1.1.1 port 443 after 0 ms: Could not connect to server

> mtr -4tb 8.8.8.8
mtr: Unexpected mtr-packet error

+ browser errors.

Edit:
Also, as mentioned in the kernel mailing-list post

The ethernet destination MUST be ff:ff:ff:ff:ff:ff for broadcast, but is
mangled with 9e30ecf23b1b applied.

> uname -a
Linux foo 6.16.4-arch1-1

> wakeonlan 46:3b:ad:61:e0:5d

> tshark -r cap6.16.4.cap -T fields -e eth.dst
10:7c:61:c3:5e:68

> uname -a
Linux foo 6.16.1-arch1-1

> wakeonlan 46:3b:ad:61:e0:5d

> tshark -r cap6.16.1.cap -T fields -e eth.dst
ff:ff:ff:ff:ff:ff

IF I managed to capture the right field with that tshark command...

So the newest kernel did not fix it for me.

Will be running 6.16.1 for the time being.

Last edited by idontgetit (2025-08-29 14:44:08)

Preycon · 2025-08-29 16:04:41

New kernel today made it so much worse (specially on firefox), I needed to downgrade too and change from nvidia-open to nvidia-open-dkms

jneri · 2025-08-29 16:56:03

I was able to fix it temporarily by switching to systemd-resolved for handling DNS instead of leaving everything to NetworkManager. This worked for both 6.16.3 and 6.16.4. However, connection would intermittently fail again when waking from suspend. I would have to restart systemd-resolved to get connections to work properly again. I also just reverted back to 6.16.1.

seth · 2025-08-29 17:59:57

https://cdn.kernel.org/pub/linux/kernel … Log-6.16.4 and then incremental versions.
You're looking for 9e30ecf23b1b as the offending patch will likely be referenced and also "Paolo Abeni" will most likely have signed off on the patch.
But according to the lkml status the patch hasn't even been proposed for inclusion because of some review hiccup - I guess 6.16.5 is a pretty safe bet, though.

bow · 2025-09-01 01:33:33

I started noticing the issue after recent updates because firefox kept randomly getting the "NS_ERROR_CONNECTION_REFUSED". So I tried to investigate using wireshark, and I go to the point where I started to use 'ping' to try to find out if there was something wrong with the network, and I noticed there was weird random outbound ICMP packets:

No.     Time                          Source                Destination           Protocol Length Info
    233 2025-08-30 18:26:33,885396132 <my ip addr>          1.1.1.1               ICMP     98     Echo (ping) request  id=0x0008, seq=41/10496, ttl=64 (reply in 234)
    234 2025-08-30 18:26:33,888211726 1.1.1.1               <my ip addr>          ICMP     98     Echo (ping) reply    id=0x0008, seq=41/10496, ttl=59 (request in 233)
    235 2025-08-30 18:26:34,886429401 <my ip addr>          1.1.1.1               ICMP     98     Echo (ping) request  id=0x0008, seq=42/10752, ttl=64 (reply in 236)
    236 2025-08-30 18:26:34,889074934 1.1.1.1               <my ip addr>          ICMP     98     Echo (ping) reply    id=0x0008, seq=42/10752, ttl=59 (request in 235)
    237 2025-08-30 18:26:35,888269047 <my ip addr>          1.1.1.1               ICMP     98     Echo (ping) request  id=0x0008, seq=43/11008, ttl=64 (reply in 238)
    238 2025-08-30 18:26:35,890841363 1.1.1.1               <my ip addr>          ICMP     98     Echo (ping) reply    id=0x0008, seq=43/11008, ttl=59 (request in 237)
    239 2025-08-30 18:26:36,889376813 <my ip addr>          1.1.1.1               ICMP     98     Echo (ping) request  id=0x0008, seq=44/11264, ttl=64 (reply in 240)
    240 2025-08-30 18:26:36,892082233 1.1.1.1               <my ip addr>          ICMP     98     Echo (ping) reply    id=0x0008, seq=44/11264, ttl=59 (request in 239)
    241 2025-08-30 18:26:37,890396250 <my ip addr>          1.1.1.1               ICMP     98     Echo (ping) request  id=0x0008, seq=45/11520, ttl=64 (reply in 242)
    242 2025-08-30 18:26:37,892845237 1.1.1.1               <my ip addr>          ICMP     98     Echo (ping) reply    id=0x0008, seq=45/11520, ttl=59 (request in 241)
    243 2025-08-30 18:26:38,892042389 <my ip addr>          1.1.1.1               ICMP     98     Echo (ping) request  id=0x0008, seq=46/11776, ttl=64 (reply in 244)
    244 2025-08-30 18:26:38,895861863 1.1.1.1               <my ip addr>          ICMP     98     Echo (ping) reply    id=0x0008, seq=46/11776, ttl=59 (request in 243)
    245 2025-08-30 18:26:39,893368939 <my ip addr>          1.1.1.1               ICMP     98     Echo (ping) request  id=0x0008, seq=47/12032, ttl=64 (reply in 246)
    246 2025-08-30 18:26:39,896784868 1.1.1.1               <my ip addr>          ICMP     98     Echo (ping) reply    id=0x0008, seq=47/12032, ttl=59 (request in 245)
    247 2025-08-30 18:26:40,393824573 <my ip addr>          3.162.247.87          ICMP     590    Destination unreachable (Port unreachable)
    248 2025-08-30 18:26:40,393863142 <my ip addr>          3.162.247.87          ICMP     590    Destination unreachable (Port unreachable)
    249 2025-08-30 18:26:40,393869504 <my ip addr>          3.162.247.87          ICMP     590    Destination unreachable (Port unreachable)
    250 2025-08-30 18:26:40,393875513 <my ip addr>          3.162.247.87          ICMP     590    Destination unreachable (Port unreachable)
    251 2025-08-30 18:26:40,894408599 <my ip addr>          1.1.1.1               ICMP     98     Echo (ping) request  id=0x0008, seq=48/12288, ttl=64 (reply in 252)
    252 2025-08-30 18:26:40,897422845 1.1.1.1               <my ip addr>          ICMP     98     Echo (ping) reply    id=0x0008, seq=48/12288, ttl=59 (request in 251)
    253 2025-08-30 18:26:41,109558417 <my ip addr>          18.67.130.58          ICMP     590    Destination unreachable (Port unreachable)
    254 2025-08-30 18:26:41,109567713 <my ip addr>          18.67.130.58          ICMP     590    Destination unreachable (Port unreachable)
    255 2025-08-30 18:26:41,396049999 <my ip addr>          3.164.6.123           ICMP     590    Destination unreachable (Port unreachable)
    256 2025-08-30 18:26:41,396064984 <my ip addr>          3.164.6.123           ICMP     590    Destination unreachable (Port unreachable)
    257 2025-08-30 18:26:41,895360235 <my ip addr>          1.1.1.1               ICMP     98     Echo (ping) request  id=0x0008, seq=49/12544, ttl=64 (reply in 258)

I do not understand why the destination is sometimes a random IP, and the packet length is different.

This was on 6.16.4. I had the same issue on 6.12.44-lts. Went back to 6.15.9 and it looks better but still happens sometimes.

Is this related?

Last edited by bow (2025-09-01 01:35:00)

seth · 2025-09-01 07:06:29

3.162.247.87 and 18.67.130.58 are amazon and the timestamps do not match the 1.1.1.1 frequency.
=> unrelated random side-traffic?

Edit: not sure why you get "Port unreachable" on an ICMP request nor why the request is this large - it looks a bit sketchy.

Last edited by seth (2025-09-01 07:08:41)

BLuBPoRK · 2025-09-01 10:17:58

Been fighting with this issue over the last few days, thinking it was related to my self-hosted DNS but a Windows machine on the same LAN didn't have issues and dropping the local DNS for cloudflare didn't resolve the issue.
First showed up via random git fetch failures when trying to update LazyVim packages. Would get random pages not loading on first try in Firefox but would "wake up" on the second/third try. I also was noticing (or I should say my friends were noticing) issues with Discord going garbled. If this is all related to UDP barf that seems to track. Given jneri's suggestion of using systemd-resolved, that does seem to work, but you not only have to restart the service when you wake or reboot but even if you disconnect your internet and reconnect.

Forgot to mention I am running 6.16.4. It feels like this just showed up with this patch version, but I could have easily just overlooked it in previous versions. Don't spend a ton of time in Discord voice and I would have probably shrugged off the random page load failures otherwise.

Last edited by BLuBPoRK (2025-09-01 10:20:26)

seth · 2025-09-01 11:46:42

https://bbs.archlinux.org/viewtopic.php … 3#p2259213
=> Do you have this w/ 6.16.1 ?

shmerl · 2025-09-01 23:40:57

Just registered to comment on this. There are two related fixes. One is in 6.16.4 and another one is not, it's only in Linux mainline so far. The second one fixes regression in the first:

* 6.16.4: https://gitlab.com/linux-kernel/stable/ … v4/route.c
* mainline: https://gitlab.com/linux-kernel/linux/- … v4/route.c

Note this fix: https://gitlab.com/linux-kernel/linux/- … 06675b88bd
net: ipv4: fix regression in local-broadcast routes

I tried applying it on top of 6.16.4 and it seems to be helping so far, I don't get these intermittent broken connections anymore. It should appear in 6.16.5 I think.

Last edited by shmerl (2025-09-01 23:41:47)

bow · 2025-09-02 01:59:59

seth wrote:

3.162.247.87 and 18.67.130.58 are amazon and the timestamps do not match the 1.1.1.1 frequency.
=> unrelated random side-traffic?
Edit: not sure why you get "Port unreachable" on an ICMP request nor why the request is this large - it looks a bit sketchy.

Well noted, so it seems that it was not generated by my ping command. According to this, the packet actually makes sense.

So I'm not sure anymore if this is related, or if I can even see the effect of the issue in wireshark dumps. It may be a coincidence, but I get a LOT less of this packets in 6.15.9, and still got no "NS_ERROR_CONNECTION_REFUSED" in firefox since I reverted to this version.

Last edited by bow (2025-09-02 02:01:07)

seth · 2025-09-02 06:54:45

I can ping those IPs fine - you might wanna check what's talking to amazon/aws there.
If you get initial (singular) connection errors on < 6.16.2 when open an archlinux address, that's because of the DDOS attack (and part of a mitigation)

bad63r · 2025-09-04 16:41:27

I am also affected by this bug. For me, downgrading (6.16.4.arch1-1 -> 6.16.1.arch1-1) seems to mitigate the issue. On current LTS kernel it is present as well.

mcloaked · 2025-09-04 19:23:46

I have been testing kernel 6.16.5 the past couple of hours - and have not had any recurrence of this issue on one test machine. So it is possible that the underlying problem has been fixed with new commits in 6.16,5.

The commit is in https://cdn.kernel.org/pub/linux/kernel … Log-6.16.5

Commit 018afe914b712fdb75a0f4999d7d3d1393a10d32
Author: Oscar Maes <oscmaes92@gmail.com>
Date: Wed Aug 27 08:23:21 2025 +0200

net: ipv4: fix regression in local-broadcast routes

[ Upstream commit 5189446ba995556eaa3755a6e875bc06675b88bd ]

Commit 9e30ecf23b1b ("net: ipv4: fix incorrect MTU in broadcast routes")
introduced a regression where local-broadcast packets would have their
gateway set in __mkroute_output, which was caused by fi = NULL being
removed.

Fix this by resetting the fib_info for local-broadcast packets. This
preserves the intended changes for directed-broadcast packets.

Last edited by mcloaked (2025-09-04 20:49:49)

AbsolutelyFree · 2025-09-05 08:00:47

I have been running the latest LTS kernel available in the repos (6.12.45-1-lts #1) and have not seen the network issues described in this thread manifesting anymore. I was experiencing these issues constantly since the update that introduced the issue, so I am glad this appears to be resolved.

darthrob · 2025-09-05 11:08:08

This has been driving me mad for a few weeks, I even went as far as replacing my WiFi card in my laptop before finding this thread. Oh well, it was an excuse to upgrade my WiFi. Glad to know it should be fixed in the next kernel update.

ponsilio · 2025-09-08 09:29:51

I've been trying 6.16.5 (in official repos already) and it seems it works fine.
I guess this issue can be considered solved.

idontgetit · 2025-09-08 21:38:38

I haven't had time for thorough experiments but quick tests seem to indicate 6.16.5 has fixed the issue. This seems to match with other observations in this thread. Thanks for your comments! Marking as solved.

Arch Linux

#26 2025-08-27 16:55:15

Re: [SOLVED] Seemingly random connection errors

#27 2025-08-28 10:44:58

Re: [SOLVED] Seemingly random connection errors

#28 2025-08-28 11:47:08

Re: [SOLVED] Seemingly random connection errors

#29 2025-08-28 14:44:06

Re: [SOLVED] Seemingly random connection errors

#30 2025-08-28 16:52:37

Re: [SOLVED] Seemingly random connection errors

#31 2025-08-28 23:01:40

Re: [SOLVED] Seemingly random connection errors

#32 2025-08-28 23:02:44

Re: [SOLVED] Seemingly random connection errors

#33 2025-08-29 14:10:47

Re: [SOLVED] Seemingly random connection errors

#34 2025-08-29 14:16:34

Re: [SOLVED] Seemingly random connection errors

#35 2025-08-29 16:04:41

Re: [SOLVED] Seemingly random connection errors

#36 2025-08-29 16:56:03

Re: [SOLVED] Seemingly random connection errors

#37 2025-08-29 17:59:57

Re: [SOLVED] Seemingly random connection errors

#38 2025-09-01 01:33:33

Re: [SOLVED] Seemingly random connection errors

#39 2025-09-01 07:06:29

Re: [SOLVED] Seemingly random connection errors

#40 2025-09-01 10:17:58

Re: [SOLVED] Seemingly random connection errors

#41 2025-09-01 11:46:42

Re: [SOLVED] Seemingly random connection errors

#42 2025-09-01 23:40:57

Re: [SOLVED] Seemingly random connection errors

#43 2025-09-02 01:59:59

Re: [SOLVED] Seemingly random connection errors

#44 2025-09-02 06:54:45

Re: [SOLVED] Seemingly random connection errors

#45 2025-09-04 16:41:27

Re: [SOLVED] Seemingly random connection errors

#46 2025-09-04 19:23:46

Re: [SOLVED] Seemingly random connection errors

#47 2025-09-05 08:00:47

Re: [SOLVED] Seemingly random connection errors

#48 2025-09-05 11:08:08

Re: [SOLVED] Seemingly random connection errors

#49 2025-09-08 09:29:51

Re: [SOLVED] Seemingly random connection errors

#50 2025-09-08 21:38:38

Re: [SOLVED] Seemingly random connection errors

Board footer