The current version of the wake command (/usr/sbin/wake) sends an improperly formatted WOL packet. It is "improper" due to the fact that it sends to the broadcast address of ff:ff:ff:ff:ff:ff instead of the address(es) specified on the command line. Because of this, the packet never makes it to the target host and thus, does not wake up the "sleeping" target.
I believe, in my case, the packet isn't even leaving the FreeBSD host.
Fix: Send the packet to the target MAC address instead of the broadcast MAC. The patch I have attached makes this change. I have tested it, and it works as expected.
Additionally, I have modified the ether_type value to use 0x0842 as this is recognized by tools such as Wireshark and is also used by some other WOL utilities. Also, emits a message to the screen when it sends a packet.
Patch attached with submission follows:
How-To-Repeat: Run tcpdump on the target host: (tcpdump -i <IF> -nne not tcp and not udp and not icmp) - or use Wireshark on a Windows host.
Use "wake" to send a WOL packet to the target's MAC address (e.g.: wake xl0 00:11:22:33:44:55)
The packet will not be received on the target.
I just tried:
wake <local_interface> <target_mac>
and both worked just fine.
Am I missing anything here? Are you experiencing any driver specific issues?
It's been awhile but, I don't believe it's a driver issue. Probably more of
a WOL implementation issue since there are various interpretations of how
it's supposed to work. I know Linux' implementation uses the destination
MAC rather than broadcasting.
I have a few Windows machines I've tried to wake using the original version
of FreeBSD's "wake" and neither responds - but they do when their own MAC
is in the destination field of the ethernet frame.
Perhaps a command line switch to alter the behaviour of wake?
wake -d interface lladdr ...
On Mon, May 13, 2013 at 7:05 PM, hiren panchasara <email@example.com> wrote:
> I just tried:
> wake <target_mac>
> wake <local_interface> <target_mac>
> and both worked just fine.
> Am I missing anything here? Are you experiencing any driver specific
Cy looked into WoL recently and I don't have the bandwidth/hardware.
Created attachment 158062 [details]
WOL implementation for bge.
This patch works. The only caveat is that when the system is shut down, e.g. halt -p, it will reboot (even without the cable connected), after which you can power off for good. I'm not sure if my hardware (Acer laptop) is at fault or if I'm missing something in the patch. Other than that it works flawlessly.
Created attachment 158065 [details]
Same patch but for stable/10
WOL patch for stable/10 bge.
I can't say who is the master of bge(4) anymore. But if we can't get anyone to review this, I'll probably just commit it to head.
(In reply to Sean Bruno from comment #7)
I recall I got similar patches from various users, FreeBSD
developers in the past. I'm afraid that WOL on Broadcom
controllers require considerable amount of driver improvements
before turning on PME in PCI configuration space. For instance,
I think driver has to:
- Make sure to let firmware know current driver state. Broadcom
controllers with ASF/IPMI features require handshaking with the
firmware for load/unload/reset/suspend/resume/wol events.
- Not all controllers support WOL so it should explicitly enable
WOL capability based on ASIC/Chip ids(i.e. Old controllers with
TBI wouldn't work/support WOL) or firmware capability.
- If WOL is activated for 1000baseT, it will draw too much current
from PCI/PCIe bus which in turn will completely shutdown
controller or shall damage your motherboard or controller.
Even if the controller uses less current with 1000baseT link, it
will consume much more power than 10/100Mbps link and it costs
a lot if you have to manage large number of systems.
AFAIK, Broadcom controllers seem to require manual speed down to
10/100Mbps before entering into WOL state.
- Suspend/resume should be fixed before enabling WOL. You should
be able to wake your box by sending a magic packet after
bge(4) is one of few controllers that suspend/resume does not
reliably work due to lack of publicly available firmware
I guess the hard part is to understand/know what are required steps
to make firmware know various host driver state(i.e. reset,
suspend, resume, wol etc) in different stage. It seems various
bge(4) controllers require different firmware interactions and
undocumented register accesses not to draw more current that
mentioned in PCI specification.
Unfortunately public data sheet is almost useless in this regard.
It does not mention interactions between host driver and its
The patch may work on consumer grade controllers which lacks
ASF/IPMI features but I think WOL shouldn't be blindly enabled for
bge(4) controllers. If you limit WOL for specifically tested
ASIC/Chip ids I'm fine with the patch though. Alternatively we
can add a sysctl variable which controls driver's WOL (default off)
and have end users control the feature. In that case we probably
need a man update for possible damage on over-current triggered
As stated before the patch works but Pyun makes some good points.
*** Bug 177184 has been marked as a duplicate of this bug. ***
Created attachment 191146 [details]
Updated patch for if_bge.
This patch resolves the advertised speed issue. As per standard and recommended for bge cards it now listens at 100 Mb.
However the problem still remains that halt -p following WOL to boot the machine will result in reboot and not poweroff. (Though subsequent to normal reboot poweroff will work.)
DUP of 218579.
*** This bug has been marked as a duplicate of bug 218579 ***