Wake on Lan is working with core 160?

Hi everyone.

Can someone with the Core 160 check if the WakeOnLAN works ?.

Before, with the 159 the PC could turn on perfectly, but as a result of updating to the 160, it does not turn on.

Thank you :call_me_hand:

Greetings.

I am running Core Update 160 and use wake on lan with fcron and that is still working.

I have just checked the wake on lan page of the WUI and can confirm that it just started my desktop machine.

So everything looks working to me.

What do your logs say?

Hi @roberto,

I hope you are well.

I just tried with my IPFire core update 160 (stable) and it works perfectly.

Kinds regards,
Stéphane

Thanks Adolf and Steph.

I forgot to say that I updated the PC with Windows 11, but the power I think is before the OS. Which is in the BIOS. Well, thanks to your answers I know that it is not the IPFire and it will be something else.

Now I will try to determine what the problem is by eliminating the suspicion of problems in my IPFire.

Thanks to both of you.

Greetings and have a good weekend.

@bonnietwin , @steph78630
Do you have the option to check WOL in WUI, on a fresh core 160 installation?

Regards
Tom

Hi.

It is already solved, the problem was that when I turned off the PC, the lights of the network card were off when they should be on to attend to the WOL.

Looking at Google I have found the solution. You have to deactivate the “Activate fast start”:

Saludos y gracias a todos.

1 Like

Hi @tphz .
No I can’t easily do a fresh install test of wol.

When I am doing tests with a fresh installation I am using my vm testbed network but wol doesn’t work in my virtualbox vm’s.

Hello,
I jumped from core 158 to core 162 and noticed that WOL no longer works for me.
The machines are the same: 2x APU boxes. One is APU1 and the second is APU2. Both running core 162 (upgraded from 158)
APU2 has eth1 and eth2 in bridge mode.
APU1 has all 3 cards (eth0, eth1, eth2) in bridge mode - this box has only green network in it.
APU2 wakes APU1 that has samba add-on on it and is used as “file server” for some backups.

I also tried the etherwake -i green0 mad_address but no success.
Cable works - I see that after manual power on I get 1Gbit link negotiated and network speed is ok, no packet drops. I tried different cable, no improvements.
I turned off STP everywhere (in APU1 and APU2) but no success to make WOL working.

Any tests I could perform do detect where the problem is?

I already upgraded APU2 to latest firmware, but no success.

Board : PC Engines apu2
HW Version : 1.0
Serial : 1109091
BIOS Version: v4.15.0.1 (11/23/2021)

APU1 also upgraded to latest firmware:

Board : PC Engines apu1
HW Version : 1.0
Serial : -64
BIOS Version: v4.15.0.1 (11/23/2021)

Late edit: I replaced the APU1 box with an laptop and same story: APU2 Wake On LAN fails to wake it although I see the laptop LEDs on …

And, every time I connect APU1 I do NOT see the port on APU2 to go on forwarding state.
But when I connect the Laptop it goes on forwarding state, but no chenge: WOL does not work on either of the machines

Jan 12 09:30:24 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Jan 12 09:30:24 silver-x86-64 kernel: green0: port 2(green0p1) entered blocking state
Jan 12 09:30:24 silver-x86-64 kernel: green0: port 2(green0p1) entered forwarding state
Jan 12 09:30:41 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Down
Jan 12 09:30:41 silver-x86-64 kernel: green0: port 2(green0p1) entered disabled state
Jan 12 09:30:44 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Jan 12 09:30:44 silver-x86-64 kernel: green0: port 2(green0p1) entered blocking state
Jan 12 09:30:44 silver-x86-64 kernel: green0: port 2(green0p1) entered forwarding state
Jan 12 09:34:07 silver-x86-64 kernel: perf: interrupt took too long (2541 > 2500), lowering kernel.perf_event_max_sample_rate to 78000
Jan 12 09:36:14 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Down
Jan 12 09:36:14 silver-x86-64 kernel: green0: port 2(green0p1) entered disabled state
Jan 12 09:36:16 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Up 10 Mbps Full Duplex, Flow Control: RX/TX
Jan 12 09:36:16 silver-x86-64 kernel: green0: port 2(green0p1) entered blocking state
Jan 12 09:36:16 silver-x86-64 kernel: green0: port 2(green0p1) entered forwarding state
Jan 12 09:38:19 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Down
Jan 12 09:38:19 silver-x86-64 kernel: green0: port 2(green0p1) entered disabled state
Jan 12 09:38:22 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Jan 12 09:38:22 silver-x86-64 kernel: green0: port 2(green0p1) entered blocking state
Jan 12 09:38:22 silver-x86-64 kernel: green0: port 2(green0p1) entered forwarding state
Jan 12 09:38:27 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Down
Jan 12 09:38:27 silver-x86-64 kernel: green0: port 2(green0p1) entered disabled state
Jan 12 09:38:29 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Up 10 Mbps Full Duplex, Flow Control: RX
Jan 12 09:38:29 silver-x86-64 kernel: green0: port 2(green0p1) entered blocking state
Jan 12 09:38:29 silver-x86-64 kernel: green0: port 2(green0p1) entered forwarding state
Jan 12 09:42:32 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Down
Jan 12 09:42:32 silver-x86-64 kernel: green0: port 2(green0p1) entered disabled state
Jan 12 09:42:35 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Jan 12 09:42:35 silver-x86-64 kernel: green0: port 2(green0p1) entered blocking state
Jan 12 09:42:35 silver-x86-64 kernel: green0: port 2(green0p1) entered forwarding state
Jan 12 09:42:40 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Down
Jan 12 09:42:40 silver-x86-64 kernel: green0: port 2(green0p1) entered disabled state
Jan 12 09:42:41 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Up 10 Mbps Full Duplex, Flow Control: RX
Jan 12 09:42:41 silver-x86-64 kernel: green0: port 2(green0p1) entered blocking state
Jan 12 09:42:41 silver-x86-64 kernel: green0: port 2(green0p1) entered forwarding state
Jan 12 09:45:54 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Down
Jan 12 09:45:54 silver-x86-64 kernel: green0: port 2(green0p1) entered disabled state
Jan 12 09:45:57 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Jan 12 09:45:57 silver-x86-64 kernel: green0: port 2(green0p1) entered blocking state
Jan 12 09:45:57 silver-x86-64 kernel: green0: port 2(green0p1) entered forwarding state
Jan 12 09:46:02 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Down
Jan 12 09:46:02 silver-x86-64 kernel: green0: port 2(green0p1) entered disabled state
Jan 12 09:46:04 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Up 10 Mbps Full Duplex, Flow Control: RX
Jan 12 09:46:04 silver-x86-64 kernel: green0: port 2(green0p1) entered blocking state
Jan 12 09:46:04 silver-x86-64 kernel: green0: port 2(green0p1) entered forwarding state

I can’t help with understanding the log messages you have but whenever I have wol problems with a machine trying to be woken I go through the following checks.
First check the wol status to make sure that the nic has been turned on for wol.

So on APU1 run
ethtool red0

In the info that comes out you should find something like

Supports Wake-on: pumbg
Wake-on: g

If your nic shows g in the Wake-on line then wol is enables. If it has d then it has been disabled.

On my archlinux systems a while back I found that a kernel/driver update the wol status was no longer persistent over reboots… I had to add a systemd service in to set the nic to g when starting up.

IPFire has just had some changes in kernel versions. I don’t know if this will have changed things or not.

If it shows g then it should be able to be woken. I would then confirm that by connecting your laptop to APU1 and sending a magic packet using whatever wol tool you have on the laptop, or installing one.

If the laptop successfully starts APU1 then that machine is out of the frame.

Then I would connect your laptop to APU2 and run netcat, or something equivalent, on the laptop to look at udp traffic coming in on port 9 and then try and send the wol command from APU2.
You should then see on the laptop terminal running netcat if the wol magic packet comes across.
The magic packet frame contains 6 bytes of FF followed by 16 repetitions of the target computer’s MAC (6 bytes each) for a total of 102 bytes.

If that is not being sent then there is some problem with the sending of the magic packet in APU2. Try both the wui wol and a command line magic packet command.

If all of the above looks fine then I have no idea what the problem could be.

2 Likes

Thank you for the guide!
Conclusion: after core 162 the APU1 box no longer powers the network cards as result of halt -hp
Conclusion 2: APU2 also gave some problems to execute WOL - connecting to it a laptop that keep network cards powered on in power down mode, APU 2 still fails to wake it after upgrade to Core 162 (and worked fine with core 158).

Explanation & tests

Additional info: APU2 is “the router” that is always on and should wake up the APU1 which is “file server/backup server - samba”. Both run Ipfire core 162… Both upgraded from core 158 in same day.

And, because APU1 has some (old) LED problems (not powered on when machine powered off but cable connected) I have use an laptop to “see with my own eyes” that network card LED starts even when machine is powered off, plugged in AC adapter, and waiting for the WOL magic packet.

More, above logs show that only laptop put the APU2 cards in “forwarding state” - I am not an expert, but this is something that looks like APU1 in power off mode does not power (ANYMORE!) the network cards, therefore APU2 network cards are in “disabled state” while connected to APU1 cards…

To your test:
Both APU boxes have multiple network cards in bridge mode for GREEN network - therefore green0 is not a physical car in any of the machines.

Having said that, I have checked each physical card in each of the APU: green0p0, green0p1 for APU2 (router) and green0p0, green0p1 and green0p2 for APU1 (the “file server”)

All cards who the “g” status while card is connected to a box that powers the card (see below)

APU2 (the router): 2 network cards in bridge mode for GREEN:

Board : PC Engines apu2
HW Version : 1.0
Serial : 1109091
BIOS Version: v4.15.0.1 (11/23/2021)

Settings for green0p0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes

Settings for green0p1: THIS GOES TO APU1
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes

APU1 (the file server): all 3 network cards in bridge mode for GREEN:

Board : PC Engines apu1
HW Version : 1.0
Serial : 1012235
BIOS Version: v4.15.0.1 (11/23/2021)

Settings for green0p0: HERE IS THE CABLE FROM APU2
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
master-slave cfg: preferred slave
master-slave status: master
Port: Twisted Pair
PHYAD: 0
Transceiver: external
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: d
Link detected: yes

Settings for green0p1: NO CABLE CONNECTED
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Auto-negotiation: on
master-slave cfg: preferred slave
master-slave status: unknown
Port: Twisted Pair
PHYAD: 0
Transceiver: external
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: d
Link detected: no

Settings for green0p2: NO CABLE CONNECTED
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Auto-negotiation: on
master-slave cfg: preferred slave
master-slave status: unknown
Port: Twisted Pair
PHYAD: 0
Transceiver: external
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: d
Link detected: no

It seems everything looks fine.

I powered off APU1 with command halt -hp: APU2 port green0p1 status change to “d” while APU1 is in power down state.
Is like APU1 No longer powers on the network cards after I have upgraded it to core 162 and latest firmware 4.15

APU2 card status after APU1 was powered off with halt -hp

Settings for green0p1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Auto-negotiation: on
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: no

/var/log/messages confirms that: APU2 port green0p1 is in disabled state with APU1 in power off state. Again, this never happened until core 162! Up to core 158, halt -hp leave the network cards powered on on APU1 box.

Jan 13 07:48:24 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Down
Jan 13 07:48:24 silver-x86-64 kernel: green0: port 2(green0p1) entered disabled state

For APU2 you don’t have to worry about the Wake-on setting being at g as you are not trying to wake up APU2.

For APU1 I see that the setting is Wake-on: d which means that wake on lan is disabled on the APU1 cards. This needs to be changed to g before APU1 is turned off.
From Core Update 158 to 162 the Linux kernel is changed from 4.14.232 to 5.15.6 and in that range the wake on lan setting stopped being persistent. If you turn off the APU with the setting at d then it will not respond to any magic packets. You will need to create a script to set the wake on lan to g when the APU is booted up.

If the APU1 network card is not in a wake on lan semi powered state when APU1 has been turned off then that will be a function of the APU bios. There have been changes in the APU firmware between CU158 and CU162. Check the bios setting od APU1 to make sure that the default wake on lan setting of the cards has not been changed.

APU2 sends the magic packet via the etherwake package. This has not been changed since it was installed in 2009.
The only thing that was changed was in CU154 when the additional helper script that used to be in place was removed and etherwake is run directly.

The wui wake on lan worked for me when I tested it in December, waking up my desktop machine, and the etherwake command is working fine from the command line as I use it in a script, run via fcron, to turn on my file and mail server each morning and that has not stopped working at all.

WOL is a function of the BIOS also. A system in standby is started by the BIOS.
The test descriptions for the coreboot firmware of APUs [PC Engines] Regression test results - Google Tabellen state problems with WOL since v4.14.0.4

2 Likes

Well found Bernhard. :+1:

Unfortunately it is not fixed in v4.15.0.1 which will be in CU163.

It is also not fixed in v4.15.0.2 which is the latest released version so it is an ongoing problem.

So only solution is to install v4.14.0.3 which is the last version without any wol issues flagged.

1 Like

Thank you very much @bonnietwin and @bbitsch

I have set ALL network cards in APU1 to wol=g and powered down the box:

On APU1 I did executed these commands:

ethtool -s green0p0 wol g
ethtool -s green0p1 wol g
ethtool -s green0p2 wol g

APU2 card connected to APU1 now goes in forwarding state after APU1 halts/power off:

Jan 13 22:10:05 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Down
Jan 13 22:10:05 silver-x86-64 kernel: green0: port 2(green0p1) entered disabled state
Jan 13 22:10:06 silver-x86-64 kernel: igb 0000:02:00.0 green0p1: igb: green0p1 NIC Link is Up 10 Mbps Full Duplex, Flow Control: RX/TX
Jan 13 22:10:06 silver-x86-64 kernel: green0: port 2(green0p1) entered blocking state
Jan 13 22:10:06 silver-x86-64 kernel: green0: port 2(green0p1) entered forwarding state

And, as expected, the WOL command from APU2 to APU1 now works: my script that powers it on and check that samba is up reported success: :+1:

./RedFire up
is_alive: ping a.b.c.d attempt 6. smbclient:Seems samba on a.b.c.d is up

Thank you - I will try to go back to 4.14.03, BUT the APU1 needs flashrom 0.9 to accomplish that.
And, up to now, I failed to find a binary - I know I had a TinyCore bootable USB somewhere, but I did not found it yet.

The flashrom 1.2 that is shipped now in core 162 does not work - see this post on errors thrown on APU1. How update the BIOS from IPFire with PC Engines APUx - #15 by hjkl

So until I found the flashrom 0.9 I will have to run a cron job to set wol=g on all cards from APU1

Thank you again!

Late edit: found my TinyCore USB Boot and that had on it FLashROM v0.9.7-r1711-APU: I have downgraded APU1 bios to v4.12.0.6. that was on the USB disk with TinyCore.

Board : PC Engines apu1
HW Version : 1.0
Serial : -64
BIOS Version: v4.12.0.6 (10/29/2020)

Later edit: neither BIOS Version: v4.12.0.6 (10/29/2020) or BIOS Version: v4.14.0.3 (08/10/2021) put Wake-on: g

Board : PC Engines apu1
HW Version : 1.0
Serial : 1012235
BIOS Version: v4.14.0.3 (08/10/2021)

I tested both - all 3 network cards go with Wake-on: d after reboot.

So I have added in /etc/sysconfig/rc.local these lines.

ethtool -s green0p0 wol g
ethtool -s green0p1 wol g
ethtool -s green0p2 wol g

It seems that new kernel does that and not the BIOS firmware…
But I am not an expert…

Thank you very much!

Sorry for any confusion. The bios recommendation was because it looked like your network card was powering off and not putting itself into the semi powered mode required for wol to be usable.

There are two steps to having wol working. First the bios has to have the wol capability setup so that the network card maintains some power for it to be able to wake up.
Then you need to have the network card setup to respond to magic packets.

If when you have manually set wol to g you can wake up APU1 with the latest firmware/bios installed then stay with that latest version. No need to revert to an earlier version.
Sorry for any confusion.

The wol being reset back to d when the system reboots is coming from the kernel as you say and came in somewhere in the kernel 5 series I believe. Your use of the rc.local is perfect for setting the network cards to ensure that you have the wol set to g being persistent.

Glad it all seems to be working again now.

1 Like