On linux 6.16.2.arch1-1 wakeonlan and wol are broken

gianter · 2025-08-23 17:50:28

On linux 6.16.2.arch1-1 wake on lan and wol doesn't work anymore, to get they working again needs downgrade to 6.12.42-1-lts (6.12.43-1-lts doesn't even work)

Last edited by gianter (2025-08-23 17:57:11)

Roken · 2025-08-24 09:44:49

I can confirm, but only on the machine issuing the magic packet. The kernel on the machine being woken makes no difference.

Also happens with zen-6.16.2 upwards. zen-16.16.1 works.

I should add, thank you for posting. Got me thinking after I spent an hour troubleshooting the target machine that it may be the host.

Last edited by Roken (2025-08-24 10:05:36)

seth · 2025-08-24 12:53:13

Using wol?
Does it print any errors (in verbose mode)?
Same hardware? Wifi? Rj45?

loqs · 2025-08-24 13:52:39

https://lore.kernel.org/regressions/202 … ecast.net/

gianter · 2025-08-24 17:03:02

Checked with wol and wakeonlan
No any error in verbose mode
Same hardware
Not matter WIFI or RJ45

Discovered by accident because everything was working fine from a Debian 12 virtual machine (Kernel 6.1).
As Roken said, the problem is the host.
Downgraded the sender to Linux 6.16.1.arch1-1; Linux Zen-16.16.1; Linux-lts 6.12.42-1, everything worked fine again.

seth wrote:

Using wol?
Does it print any errors (in verbose mode)?
Same hardware? Wifi? Rj45?

Last edited by gianter (2025-08-24 17:10:28)

gianter · 2025-08-24 17:11:21

Thanks for your post. Very interesting, although I don't have any "route.c" file to edit as indicated.

loqs wrote:

https://lore.kernel.org/regressions/202 … ecast.net/

Last edited by gianter (2025-08-24 17:11:42)

loqs · 2025-08-24 17:55:13

gianter wrote:

Thanks for your post. Very interesting, although I don't have any "route.c" file to edit as indicated.

Please see Patching_packages#Applying_patches as the linux PKGBUILD automatically applies all sources with a .patch extension you only need to do steps 1 and 2 so the total changes made would be:

diff --git a/PKGBUILD b/PKGBUILD
index 13d2741..f8c8476 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -37,6 +37,7 @@ _srctag=v${pkgver%.*}-${pkgver##*.}
 source=(
   https://cdn.kernel.org/pub/linux/kernel/v${pkgver%%.*}.x/${_srcname}.tar.{xz,sign}
   $url/releases/download/$_srctag/linux-$_srctag.patch.zst{,.sig}
+  net_ipv4_fix_regression_in_broadcast_routes.patch::https://lore.kernel.org/regressions/20250823121336.18492-4-bacs@librecast.net/raw
   config  # the main kernel config file
 )
 validpgpkeys=(
@@ -49,11 +50,13 @@ sha256sums=('80439ba055c12f541abf44b8fc3c9b825a8f42fc25ce67462ec7e556c5790b85'
             'SKIP'
             'dac2cc4f42bd1cef34c06538ae86384812ee700a0d95af075bf02438afb057be'
             'SKIP'
+            'deafda6e527ec2c1c3fe16fec19740b3a7a5a697a90b26de53bb64de8599530b'
             '164c6b3551c4e8e914277b76b0dae6ce5c82475bc5221e44b834932837b5a98f')
 b2sums=('3053226fdec6b69c3bb0a4c9cae0a2595c05a74e99a78d5a0fd9f5d016d192a3b057e72b8cb8471e5f4d021d7a1887bcd7713d33b00ba02ea7eee5f6a981db19'
         'SKIP'
         'ec408ecf0003895f1569b4f974c6d78f506ed1da410058924d36015ed45c133892e6ca8b4c19461172b775d29c15461e8089fec8a209ea6d2083a1f1da9a2e7c'
         'SKIP'
+        '1dd6765ca9403b8b3d31ef9236cf339c20bb64ba522f65ca8b2c964723cec7d5f13ed6a2e6c28ccdca805519f9e94874f9ae68565f81ca8ca90b4bde7f9fdd46'
         'a73a4cbb9629751edc4cbb376db0e267c1fbfe0da06598ac963853bc30a6fee296eb1fc0788bf5650b200f0cdac6b1b68281796814945efca6c8995dcb31a764')
 
 export KBUILD_BUILD_HOST=archlinux

gianter · 2025-08-25 12:59:28

Thanks for your input loqs.
I've never compiled a kernel before, so you've inspired me to do some research. I found the ArchWiki a bit complicated, but I found this page that explains all the steps wonderfully well. I'd like to share it with all my forum friends.

Patching The Arch Linux Kernel

loqs wrote:

gianter wrote:

Thanks for your post. Very interesting, although I don't have any "route.c" file to edit as indicated.

Please see Patching_packages#Applying_patches as the linux PKGBUILD automatically applies all sources with a .patch extension you only need to do steps 1 and 2 so the total changes made would be:

diff --git a/PKGBUILD b/PKGBUILD
index 13d2741..f8c8476 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -37,6 +37,7 @@ _srctag=v${pkgver%.*}-${pkgver##*.}
 source=(
   https://cdn.kernel.org/pub/linux/kernel/v${pkgver%%.*}.x/${_srcname}.tar.{xz,sign}
   $url/releases/download/$_srctag/linux-$_srctag.patch.zst{,.sig}
+  net_ipv4_fix_regression_in_broadcast_routes.patch::https://lore.kernel.org/regressions/20250823121336.18492-4-bacs@librecast.net/raw
   config  # the main kernel config file
 )
 validpgpkeys=(
@@ -49,11 +50,13 @@ sha256sums=('80439ba055c12f541abf44b8fc3c9b825a8f42fc25ce67462ec7e556c5790b85'
             'SKIP'
             'dac2cc4f42bd1cef34c06538ae86384812ee700a0d95af075bf02438afb057be'
             'SKIP'
+            'deafda6e527ec2c1c3fe16fec19740b3a7a5a697a90b26de53bb64de8599530b'
             '164c6b3551c4e8e914277b76b0dae6ce5c82475bc5221e44b834932837b5a98f')
 b2sums=('3053226fdec6b69c3bb0a4c9cae0a2595c05a74e99a78d5a0fd9f5d016d192a3b057e72b8cb8471e5f4d021d7a1887bcd7713d33b00ba02ea7eee5f6a981db19'
         'SKIP'
         'ec408ecf0003895f1569b4f974c6d78f506ed1da410058924d36015ed45c133892e6ca8b4c19461172b775d29c15461e8089fec8a209ea6d2083a1f1da9a2e7c'
         'SKIP'
+        '1dd6765ca9403b8b3d31ef9236cf339c20bb64ba522f65ca8b2c964723cec7d5f13ed6a2e6c28ccdca805519f9e94874f9ae68565f81ca8ca90b4bde7f9fdd46'
         'a73a4cbb9629751edc4cbb376db0e267c1fbfe0da06598ac963853bc30a6fee296eb1fc0788bf5650b200f0cdac6b1b68281796814945efca6c8995dcb31a764')
 
 export KBUILD_BUILD_HOST=archlinux

loqs · 2025-08-25 14:31:49

gianter wrote:

Patching The Arch Linux Kernel

Please be careful of bad advice in third party guides:

You will also have to add 'SKIP' to the end of the sha256sums and b2sums lists to disable integrity checking for the file.

Or you could read Patching_packages#Applying_patches to generate and add the checksums.

I like to make one final change to the build script before proceeding however, which is replacing the line reading make all with one reading make -j$(nproc) all.

Makepkg#Parallel_compilation.

The skippgpcheck flag disables checking the cryptographic signatures on the source files and is required because otherwise the build will fail when it discovers that our patch file has not been signed by any of the Linux or Arch developers (additionally I have had issues with this build failing with similar PGP errors even without any custom patch files, I am unsure why this is).

The first part is rubbish. Patches without a matching signature file are not checked and will not fail the signature check. The second part is most likely because the author has not read Makepkg#Signature_checking but has never bothered to investigate.

Salkay · 2025-08-27 12:43:43

Thanks all. I can confirm that I have this bug, and the patch for the PKGBUILD posted by loqs works perfectly for me on linux 6.16.3.arch1-1.

The kernel took 70 minutes to build on my system!

EDIT: And the update to linux 6.16.4.arch1-1 broke it again for me

Last edited by Salkay (2025-09-01 14:03:40)

Strangiato · 2025-09-01 13:46:31

I have a laptop running Arch with Gnome and a desktop computer running Arch with KDE Plasma, both running the default kernel 6.16.4.
I'm unable to turn the desktop on with the laptop via wake-on-lan.

seth · 2025-09-01 14:03:49

This isn't supposed to be fixed in 6.16.4, https://bbs.archlinux.org/viewtopic.php … 3#p2259213

loqs · 2025-09-01 15:15:28

net-ipv4-fix-regression-in-local-broadcast-routes.patch queued for 6.16.5.

Salkay · 2025-09-01 15:22:01

Thank @seth and @loqs. I just built linux 6.16.4.arch1-1 in the meantime, which took another 70 minutes, so definitely looking forward to the fix!

markg85 · 2025-09-01 17:25:39

Well, this was a nasty surprise. Putting my pc to sleep remotely, waking it up next day with wol... silence. Debugging it thinking "which setting got changed this time?".. nothing wrong, all seemed fine. Turns out it's an actual kernel bug! I think that's the first time in many many years that a kernel update has a regression that actually affects my workflow. Oh well, next kernel patch release. Not going to bother patching the kernel myself for this minor annoyance (hey, that server it affects is in the next room here, i can walk, lol)

Roken · 2025-09-05 07:43:41

I can confirm that this is fixed in zen 6.16.5. I assume (I haven't tested) it's also fixed in linux-lts 6.12.45-1

markg85 · 2025-09-07 16:44:01

Roken wrote:

I can confirm that this is fixed in zen 6.16.5. I assume (I haven't tested) it's also fixed in linux-lts 6.12.45-1

I can confirm that this is NOT fixed in the ZEN kernel, my default. And it runs on 6.16.5-zen1-1.1-zen right at this very moment. WOL when it's sleeping does not wake it up. I confirmed that it is in fact sleeping and waking up with the power button just fine.

My apologies! It does work (sender needs to be at 6.16.5)!

Last edited by markg85 (2025-09-07 17:25:11)

seth · 2025-09-07 16:48:21

tbc, the bug here would affect archlinux failing to *send* WOL packages to some other host, NOT the arch system to WOL.
That's either the BIOS/UEFI/ACPI or you didn't enable the feature w/ ethtool.

markg85 · 2025-09-07 17:10:10

seth wrote:

tbc, the bug here would affect archlinux failing to *send* WOL packages to some other host, NOT the arch system to WOL.
That's either the BIOS/UEFI/ACPI or you didn't enable the feature w/ ethtool.

Oh wow, i completely missed that little bit of quite important information! The sender, darn! That was still on .4. I'll know in ~10 minutes, updating now.

markg85 · 2025-09-07 17:26:24

It works!

My apologies for being wrong! Thank you for the clarification @seth! That is much appreciated!

mpausch · 2025-09-09 08:54:37

Maybe some other RPi users also have issues, sending Wake-On-Lan (WoL) packets to their computers, so they possibly find this note searching with their favorite search engine:

Had the same issue with ArchLinux for ARM and RPi kernel on my Raspberry Pi 4 Model B.
Don't know exactly, which version of linux-rpi introduced the issue (I think it was some 6.12.4x version).

But since upgrade to linux-rpi version 6.12.45-1 it works again to send WoL packets from my RPi.

Arch Linux

#1 2025-08-23 17:50:28

On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#2 2025-08-24 09:44:49

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#3 2025-08-24 12:53:13

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#4 2025-08-24 13:52:39

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#5 2025-08-24 17:03:02

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#6 2025-08-24 17:11:21

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#7 2025-08-24 17:55:13

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#8 2025-08-25 12:59:28

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#9 2025-08-25 14:31:49

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#10 2025-08-27 12:43:43

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#11 2025-09-01 13:46:31

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#12 2025-09-01 14:03:49

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#13 2025-09-01 15:15:28

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#14 2025-09-01 15:22:01

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#15 2025-09-01 17:25:39

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#16 2025-09-05 07:43:41

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#17 2025-09-07 16:44:01

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#18 2025-09-07 16:48:21

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#19 2025-09-07 17:10:10

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#20 2025-09-07 17:26:24

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

#21 2025-09-09 08:54:37

Re: On linux 6.16.2.arch1-1 wakeonlan and wol are broken

Board footer