OpenBSD Journal

New Wake-on-Lan command

Contributed by mitja on from the I-want-to-wake-up-with-you dept.

Update (Mon Feb 09 09:51:00 CET 2009): This command has been removed.

Some days ago Marc Balmer (mbalmer@) committed /usr/sbin/wake to base:

CVSROOT:        /cvs
Module name:    src
Changes by:     mbalmer@cvs.openbsd.org 2009/01/28 06:40:48

Added files:
       usr.sbin/wake  : Makefile wake.8 wake.c

Log message:
wake is a command to send wake on lan frames over an ethernet to wake on lan
capable machines, remote powering them up.

ok claudio, sthen, "I like this a lot" & ok dlg

To paraphrase the man page, the purpose of this command is to send Wake on LAN (WoL) frames over a local Ethernet network to one or more hosts using their link layer (hardware) addresses. This functionality is generally enabled in a machine's BIOS and can be used to power on machines from a remote system without having physical access to them.

Though this functionality was previously available in ports, having a simple and clean BSD-licensed utility in the base system is great news!

(Comments are closed)

Comments

  1. By tobiasu (193.175.27.217) on

    Thanks Marc. I like it alot, now my backup box boots up whenever there's a need to push something to it and shuts down afterwards :-)

  2. By Anonymous Coward (67.69.227.99) on

    Will this work on 4.4-stable and if so, how would one go about pulling just this down to compile it?

    The one from ports seems to work sometimes and not others, this is good news to see this.

    Comments

    1. By Anonymous Coward (93.158.65.234) on


      > The one from ports seems to work sometimes and not others, this is good news to see this.

      I've gotten the impression that such problems are more related to what state the driver leaves your nic in and by what method the machine is powered down.

      anyhoo, this is yet another useful little thing I won't have to bother getting post-install. great work!

      Comments

      1. By Anonymous Coward (67.69.227.99) on

        >
        > > The one from ports seems to work sometimes and not others, this is good news to see this.
        >
        > I've gotten the impression that such problems are more related to what state the driver leaves your nic in and by what method the machine is powered down.
        >
        > anyhoo, this is yet another useful little thing I won't have to bother getting post-install. great work!

        Thanks for the insight.

        It's an onboard nfe(4). The BIOS supports it and enabled accordingly... Other than shutdown -h now or shutdown -hp now is there another way to be sure the WoL will work after a graceful shutdown? It seems to work only when it feels like it. Would it be related to the driver having to set the NIC in a certain state after shutdown?

        Comments

        1. By teepeezee (84.245.2.191) on

          > It's an onboard nfe(4). The BIOS supports it and enabled accordingly... Other than shutdown -h now or shutdown -hp now is there another way to be sure the WoL will work after a graceful shutdown? It seems to work only when it feels like it. Would it be related to the driver having to set the NIC in a certain state after shutdown?


          I think it also would not hurt to check your motherboard manufacturer's website for BIOS updates and their changelogs. I've seen WOL related isues being fixed in BIOS updates more than once.

    2. By Renaud Allard (renaud) on

      > Will this work on 4.4-stable and if so, how would one go about pulling just this down to compile it?
      >
      > The one from ports seems to work sometimes and not others, this is good news to see this.


      Yes, it compiles fine on 4.4-stable (at least on i386). Just download the source code from the CVS, go into src.sbin/wake and type make && make install

    3. By Anonymous Coward (88.89.221.109) on

      > Will this work on 4.4-stable

      I don't know, but maybe ...

      > and if so, how would one go about pulling just this down
      > to compile it?

      cd /usr/src
      cvs -d anoncvs@anoncvs.openbsd.org:/cvs/src/usr.sbin checkout wake

  3. By clvrmnky (69.196.152.39) clvrmnky@gmail.com on

    Cool. Til now I've been using a home-grown script to do this.

  4. By Anonymous Coward (205.201.1.224) on

    Which nics are supported (on the wake up side)?

    Comments

    1. By Mitja Muzenic (mitja) on .

      > Which nics are supported (on the wake up side)?

      Wake-on-lan support of the client mostly depends on the target's motherboard and BIOS, not NIC. They both have to know how to shut down while keeping the NIC powered up and to wake up when the NIC receives the magic packet. Pretty much every NIC made in last 10 years should know how to detect this magic packet.

      Comments

      1. By Anonymous Coward (85.158.44.149) on

        > > Which nics are supported (on the wake up side)?
        >
        > Wake-on-lan support of the client mostly depends on the target's motherboard and BIOS, not NIC. They both have to know how to shut down while keeping the NIC powered up and to wake up when the NIC receives the magic packet. Pretty much every NIC made in last 10 years should know how to detect this magic packet.

        they sometimes need to be set in a certain mode by the OS for this to work.

        Comments

        1. By Anonymous Coward (85.19.213.88) on

          > > > Which nics are supported (on the wake up side)?
          > >
          > > Wake-on-lan support of the client mostly depends on the target's
          > > motherboard and BIOS, not NIC.
          >
          > they sometimes need to be set in a certain mode by the OS for this
          > to work.

          And sometimes you need a WoL cable for power (on older systems).

  5. By leffe (85.224.147.166) on

    Really nice, the ports wol app if im remember correctly had quite a lot of dependencies. this is a most wanted addition to the base system.

    Comments

    1. By markus (80.152.237.153) on

      > Really nice, the ports wol app if im remember correctly had quite a lot of dependencies. this is a most wanted addition to the base system.

      You can get a simple wake on lan app running with just libnet as a dependency. See http://www.markus-hennecke.de/wakeup_en.html for an example (there is a link to a port that should work on OpenBSD). But no dependencies are far better than one!

    2. By Anonymous Coward (85.19.213.88) on

      > Really nice, the ports wol app if im remember correctly had quite
      > a lot of dependencies. this is a most wanted addition to the base
      > system.

      Just gettext, but it's about 1000 lines of code plus all the autofoo
      crap, compared to a BSD licensed 200 line program that does the same.

      net/wol worked great, but having wake in base is even better. Thanks!

  6. By Peter J. Philipp (2001:a60:f074::2) on http://solarscale.de

    I just read some of this code online through the web interface. I noticed that when the packet is assembled that the source ethernet address is not filled in. Does the kernel add that when the packet is injected into bpf, or is it left null padded or garbled (stack)? (excuse me I'm not sure if stack space is null padded). Anyhow I think this is a nice utility, thanks Marc!

    Oh one more thing. I think someone has a patch for this in -tech where when the usage() is displayed it exits with 1 instead of 0.

    Comments

    1. By Peter J. Philipp (2001:a60:f074::2) on http://solarscale.de

      > Does the kernel add that when the packet is injected into bpf, or is it left null padded or garbled (stack)? (excuse me I'm not sure if stack space is null padded). Anyhow I think this is a nice utility, thanks Marc!

      Never mind answering, I tried it out and it answered for me. Sorry for that slackerness.

      -peter

  7. By Marc Balmer (2001:8a8:1001:0:223:32ff:fec2:7d18) on

    I just removed wake(8) from the tree. The bin directories are already full and we should not add new commands.

    Comments

    1. By Anonymous Coward (71.140.104.126) on

      > I just removed wake(8) from the tree. The bin directories are already full and we should not add new commands.

      Are there any plans to release it as a port instead?

    2. By c2 (208.191.177.19) on

      Damn, guys...I realize this is email and we can't see your facial expressions, but this kind of response is a bit much, even if it's "in jest".

      In Marc's defense, I'm not sure what "full" means, but the ability to send WOL packets is not an essential feature for most newly-installed systems. I can see the logic in keeping base to a "small as possible, but no smaller" size. I do hope it appears in ports, though, as I may need this capability to work around an issue I may have at work.

      Comments

      1. By Marc Balmer (2001:8a8:1001:0:223:32ff:fec2:7d18) on

        In my own defense, and since people are calling me an ass for removing this little program, I must say that it was not my idea to remove it, I just did the committ. (If I did not need the wake(8) functionality, I would not have committet it in the first place, right... ?).

        Comments

        1. By Daniel Ouellet (66.63.10.83) daniel@presscom.net on

          > In my own defense, and since people are calling me an ass for removing this little program, I must say that it was not my idea to remove it, I just did the committ. (If I did not need the wake(8) functionality, I would not have committed it in the first place, right... ?).
          >

          This is just to bad. I was actually using it already and even trying to get it to work with a web interface as to wake up computer needed in remote office work. Was pretty nice to have it in base like this.

          May be there is more reason, and not my place to asked or say, however, the program wasn't big at all in size. 25,284 as is, and 782,835 when compile all static as inside the chroot, I didn't want to have to put the link library with it.

          Not sure really what bin being full really mean?

          May not be the same, but hard disk space is cheap and many times for users asking how to remove xbase for example, the answer is leave it, no need to remove it as space is not a problem these days.

          Shouldn't it apply to this as well, specially considering the size of it?

          It was a very nice addition and judging by the quick reactions and thanks for many so far even without a message on misc@, I guess may use it in various ways and welcome it as well?

          Really to bad Marc! I thought it was a really nice addition and it happened that just last week I actually was looking on how to do this and was all excited seeing it and even went on explaining to others that once more OpenBSD came right on time again. Many just smile at it and thought it was to funny.

          In any case, I am very sorry anyone would even call you an ass, it's not wanted and I apologies to you on their behalf, in no way you deserved this comment!

          For what ever reason, I would need to assume they are good reason, but at the same time if I may I would urge the power to be to reconsider if possible!

          It really is a good tools to have and useful to many judging by the quick reactions to both the additions and removal of it!

          Thanks for thinking about it again if possible.

          It sure would be welcome in base, or may be even in port if that's the best it could be.

          Many thanks either way for your contributions never the less and hopefully wake will be back.

          Best,

          Daniel

    3. By tedu (udet) on

      > > I just removed wake(8) from the tree. The bin directories are already full and we should not add new commands.
      >
      > ..and what do you mean they are "full", if they are "full".. then why keep working? your let's stop improving the system attitude is disgraceful.
      >
      > You best hope we never meet in real life, ass.

      you must be retarded. someone removes a not quite week old program (that they added!) and you respond like they killed your kitten? get some perspective. wake was at most equivalent to a puppy, not a kitten.

  8. By Anonymous Coward (216.68.198.73) on

    Wake would be great when in comes around or by ports/pkg. Helps for power savings and some remote fileserver setups.

    There are some scary WoL exploits out there.

    I got hit over ADSL by a freaky exploit on a Dell server, computer powered off, connected to ADSL, and unit would respond to ADSL, without turning on, weird! Kind of like radar, came over ADSL, computer blip on, and drive blip as well! GRR.

    Point, I'm happy to go with developers judgement on wake.

  9. By Anonymous Coward (67.159.44.138) on

    ifconfig fxp0 wake 00:00:00:00:00:00

    Comments

    1. By Anonymous Coward (67.69.227.99) on

      > ifconfig fxp0 wake 00:00:00:00:00:00

      What's this mean? This feature still needs to be added for wake(8) to work locally?

    2. By Brynet (Brynet) on

      > ifconfig fxp0 wake 00:00:00:00:00:00

      I just send such a patch on @misc.

      http://marc.info/?l=openbsd-misc&m=123430784406939&w=2
      http://marc.info/?l=openbsd-misc&m=123430700105730&w=2

  10. By Wake (70.173.172.194) on

    with all this talk about wake being added and being removed, net/wol having too many dependencies, net/p5-Net-Wake gets no love.

    perl -MNet::Wake -e "Net::Wake::by_udp(undef, '00:00:00:00:00:00')"

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]