Bug 171744 - [PATCH] Fix wake(8) command not sending proper WOL packet
Summary: [PATCH] Fix wake(8) command not sending proper WOL packet
Status: Closed DUPLICATE of bug 218579
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 9.0-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Cy Schubert
URL:
Keywords:
: 177184 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-09-18 14:30 UTC by Stephen Workman
Modified: 2020-03-13 20:17 UTC (History)
5 users (show)

See Also:


Attachments
file.diff (919 bytes, patch)
2012-09-18 14:30 UTC, Stephen Workman
no flags Details | Diff
WOL implementation for bge. (2.77 KB, patch)
2015-06-26 01:42 UTC, Cy Schubert
no flags Details | Diff
Same patch but for stable/10 (2.71 KB, patch)
2015-06-26 03:14 UTC, Cy Schubert
no flags Details | Diff
Updated patch for if_bge. (4.97 KB, patch)
2018-03-02 17:49 UTC, Cy Schubert
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stephen Workman 2012-09-18 14:30:10 UTC
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.
Comment 1 Hiren Panchasara freebsd_committer 2013-05-13 23:44:05 UTC
Responsible Changed
From-To: freebsd-bugs->hiren

Grab.
Comment 2 Hiren Panchasara freebsd_committer 2013-05-14 00:05:35 UTC
Stephen,

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 issues?

cheers,
Hiren
Comment 3 Stephen Workman 2013-05-31 12:10:40 UTC
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 <hiren@freebsd.org> wrote:

> Stephen,
>
> 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
> issues?
>
> cheers,
> Hiren
>
Comment 4 Hiren Panchasara freebsd_committer 2015-06-26 00:01:25 UTC
Cy looked into WoL recently and I don't have the bandwidth/hardware.
Comment 5 Cy Schubert freebsd_committer 2015-06-26 01:42:01 UTC
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.
Comment 6 Cy Schubert freebsd_committer 2015-06-26 03:14:36 UTC
Created attachment 158065 [details]
Same patch but for stable/10

WOL patch for stable/10 bge.
Comment 7 Sean Bruno freebsd_committer 2016-09-28 23:04:12 UTC
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.
Comment 8 Pyun YongHyeon freebsd_committer 2016-09-29 01:49:22 UTC
(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
   suspend.
   bge(4) is one of few controllers that suspend/resume does not
   reliably work due to lack of publicly available firmware
   interface.

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
firmware/APE.

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
by WOL.
Comment 9 Cy Schubert freebsd_committer 2016-09-29 02:53:11 UTC
As stated before the patch works but Pyun makes some good points.
Comment 10 Cy Schubert freebsd_committer 2017-01-30 04:02:11 UTC
*** Bug 177184 has been marked as a duplicate of this bug. ***
Comment 11 Cy Schubert freebsd_committer 2018-03-02 17:49:02 UTC
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.)
Comment 12 Cy Schubert freebsd_committer 2020-03-13 20:17:22 UTC
DUP of 218579.

*** This bug has been marked as a duplicate of bug 218579 ***