This is a discussion topic for the following Common Issue:
You can discuss the problem and its solutions here, but please note that debugging and technical feedback should primarily go to the issue trackers (e.g. Bugzilla) linked in the Common Issue, because that’s the place that developers watch, not here.
If there are any updates/changes/amendments for the Common Issue description, which you believe should be performed, please post it here.
Please see the Common Issue for solution/workarounds:
Hi, thanks for the info.
I’ve fixated my kernel to its previous version as per the official docs via
sudo grubby --set-default /boot/vmlinuz-6.15.10-200.fc42.x86_64
My question is, when the next kernel arrives, how do I set this back to its factory defaults, so that it wouldn’t be fixed to 6.15.10 version, but rather would flexibly pick up newly updated kernels at boot automatically, just as like it did before? sudo grubby --set-default-index 0 is the proper way for doing it so?
Edit, for anyone looking for the same answers in the future: The next kernel update actually solved my question: No need to monitor or do anything, the index will set itself back to 0 automagically, as soon as the kernel receives an upgrade. No need for manual intervention. I 
Yes - almost. According to the docs it’s sudo grubby --set-default-index=0 . But it might be fine to omit the =, like it is when you use --set-default.
Thanks for your reply,- and yepp it works without the =
I am having network connectivity issues yet, even using the workaround mentioned.
With kernel 6.15, when the issues occurs then I did do: $ sudo systemctl restart Network Manager; $ sudo systemctl restart systemd-resolved.service
That’s going to be a separate problem then, because this kernel bug isn’t in 6.15. You might want to start a separate thread with details of your issue.
Thanks for the workaround. The latest kernel screwed me pretty hard yesterday.
I’m very glad there’s a fix coming 
You’re very welcome! 
The new kernel v6.16.5 containing the fix to this regression has been released a few hours ago. You can find the changelogs here. It should become available in the Fedora repos relatively soon.
Indeed, this commit is included:
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.
Cc: stable@vger.kernel.org
Fixes: 9e30ecf23b1b ("net: ipv4: fix incorrect MTU in broadcast routes")
Reported-by: Brett A C Sheffield <bacs@librecast.net>
Closes: https://lore.kernel.org/regressions/20250822165231.4353-4-bacs@librecast.net
Signed-off-by: Oscar Maes <oscmaes92@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20250827062322.4807-1-oscmaes92@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
The Bodhi updates are already up, I’ll update the Common Issue description.
Thanks for your update, @martymarty004 .
2 hours ago I wrote a more thoroughly feedback in the bodhi page of the kernel [1], but in short, 6.16.5 massively improves the connectivity and thus mitigates the problem to a large extent, but it unfortunately does not solve it 
Discourse, which is I think the most complex page I regularly load, is where the problem still manifests regularly, though as mentioned much less than earlier. I tested USB-Ethernet and WiFi. It seems complex pages or so still don’t get all their data to work properly. I assume here that this is not a Discourse issue of course, but I presume it is not, given that the issue is the same as I had it on most pages before, just much less often occurring and with less intensity. I’m still testing.
If you reboot into 6.15 kernel and make no other change, do all the Discord Discourse operations suddenly work OK? Is this easily reproducible just by booting different kernels?
You meant *Discourse and not Discord, I guess 
I am no longer convinced that I experience the known kernel issue, though both issues have started to occur at least roughly at the same time so that I never considered that to be two different things…
First of all, I had no 6.15 kernel left, so I re-installed 6.15.10 through dnf, which means the kernel-tools*+python3-perf remained that of 6.16.5 as I can retain only one version of them: no change, same behavior as with 6.15.5 now. For the sake of completeness, I then downgraded also the kernel-tools* and python3-perf to 6.15.10: the same, no change. Since they always worked out the same, I tested just wifi and not USB-ethernet (I have no possibility to test native Ethernet for comparison).
What I just experienced when retrying on 6.16.5 (also again with updated 6.16.5 kernel-tools & python3-perf) and what was reproducible 100% when I tried each variant 5 times: when I open a Discourse topic from the main Discourse page with middle mouse click (= open in a new tab), it was always broken the way I mentioned (quotation function broken, dark-blue main reply button at the bottom broken, notification-level button broken, maybe more buttons as I was not testing all). When I refresh a broken page, it is also always broken the same way. But when I click with the left mouse button on the topic on the main Discourse page so that it opens in the same tab, then it always worked out fine including all functions. I would not yet make a bet that this is always the case, but it could explain that I sometimes experienced the issues to occur much less often, depending on how I currently worked.
I can say that the Discourse issues started at the same time all pages regularly started to become regularly broken, did not load completely or did not load at all with connection problems until I retried sometimes up to 3 times refresh with F5. However, now on 6.16.5 only issues within Discourse seem to remain, at least at first glance. And they seem kernel independent. I unfortunately forgot to test other pages on 6.15.10, so I can only say Discourse behaviors correlate among the kernels now.
I have an untainted kernel (taint level 0), only default repos except two packages from rpmfusion (mesa-va-drivers-freeworld & mesa-vdpau-drivers-freeworld are contained through includepkgs), browser is our default firefox 142.0.1 (F42 KDE, no flatpaks or so).
Does anyone else have Discourse issues at the moment? Or can reproduce the Discourse issues I have? @zbyszek I saw in the other topic that you currently also work often with Blockquotes (> text) rather than normal quotes of posts, do you experience something comparable? So that, e.g., the quotation function for marked text is broken?
Anyway, I will check out if I find some other pages that are broken, so far most I was testing was “much simpler” than Discourse. Let me know if we shall outsource this case to something separate.
Supplement, problem solved:
These correlations reminded me on the cross-site features of noscript, and I retried with noscript disabled → that’s it. With noscript disabled, Discourse works out fine now.
I presume some update of (or around) Discourse of the recent time, presumably roughly around the time of the kernel bug’s introduction, became incompatible to my noscript configuration (or vice versa) because this configuration used to not cause issues in the past, but so far I can no longer reproduce an issue with noscript disabled. I have to adjust it later somehow…
I will check this out a little more, but if it remains that way, I will update my bodhi comment to +1 at BZ#2390937. For now, presume my issue has been solved and so the connection issues around BZ#2390937. Sorry 
Hello,
I’ve been having connection issues on both of my Fedora 42 Workstation systems.
I have an Intel NUC 12 Pro with an Intel AX211 6E Wi-Fi card, and an HP ProBook 4540s laptop with a Qualcomm Wi-Fi card.
Both systems were disconnecting with Proton VPN Plus, on both kernel versions 6.16.2 and 6.16.3. I tried disabling the VPN, but the problem persisted.
Eventually, the issue on the Qualcomm Wi-Fi spontaneously resolved after a few reboots. On my PC, however, I was able to fix it by disabling power saving for the Wi-Fi AX211 6E.
On my side, the main issue I’ve identified is that wol (Wake on Lan packet sender) & Turn On Flatpak stopped working : I cannot wake my other devices with 6.16.3 & 6.16.4 kernels.
Sending magic packets through a python script also does not work either.
So something wrong with UDP port 9 broadcast packets.
Right, that’s exactly the problem that the kernel developer mentions in the post describing the regression and proposed patch.
I wish if there was a longterm variant of kernel in the official Fedora repos, so that users who vote for stability over being on the edge in terms of kernel, could use LTS instead. 