wake-on-lan

Archived from groups: alt.internet.wireless (More info?)

Hello

is there any solution that would allow me to remotely turn on a
computer that is off (not in stand-by mode) using a wireless lan?

Thanks
4 answers Last reply
More about wake
  1. Archived from groups: alt.internet.wireless (More info?)

    On 13 Aug 2004 02:12:23 -0700, bighouse@email.it (Lorenzo) wrote:

    >is there any solution that would allow me to remotely turn on a
    >computer that is off (not in stand-by mode) using a wireless lan?

    Sure. It's easy from the LAN side since all the radios and computahs
    are in the same IP broadcast domain. Just fire up your favorite WOL
    utility and it should work.

    Coming in from the internet (WAN side) through a router is impossible.
    I've tried it a few times and failed every time. The problem is that
    magic packets are "directed broadcast" packets, which are commonly
    used for DOS attacks. Cisco routers default with:
    no ip directed-broadcast
    set and that will block any magic packet from going through their
    routers.

    See:
    http://www.depicus.com/wake-on-lan/what-is-wake-on-lan.asp
    in the section:
    Wake on Lan over the Internet (or why is it such a pain in the ****)

    --
    Jeff Liebermann jeffl@comix.santa-cruz.ca.us
    150 Felker St #D http://www.LearnByDestroying.com
    Santa Cruz CA 95060 AE6KS 831-336-2558
  2. Archived from groups: alt.internet.wireless (More info?)

    In article <qvpph0pjl6bhp623l6lh6p44jr3qmrlmgj@4ax.com>,
    Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
    :On 13 Aug 2004 02:12:23 -0700, bighouse@email.it (Lorenzo) wrote:

    :>is there any solution that would allow me to remotely turn on a
    :>computer that is off (not in stand-by mode) using a wireless lan?

    :Coming in from the internet (WAN side) through a router is impossible.
    :I've tried it a few times and failed every time. The problem is that
    :magic packets are "directed broadcast" packets, which are commonly
    :used for DOS attacks. Cisco routers default with:
    : no ip directed-broadcast
    :set and that will block any magic packet from going through their
    :routers.

    It isn't impossible. I've posted code to do it. WOL packets
    are NOT inherently directed broadcast packets. They don't even
    have to be -directed- broadcast packets: they can be any MAC address
    that the system is set up to look for. You just need to find a way
    to get the system at the other end to decapsulate a non-broadcast
    packet and push it out onto the appropriate segment.

    To put it in more concrete terms: static map a public IP address to
    one of the broadcast addresses listened to on the segment the WOL system
    is on. In PIX terminology, this might be

    static (inside, outside) 201.52.93.4 192.168.1.255

    and then if the packet with the proper WOL *payload* (not header!)
    is sent to the public 201.52.93.4 address then the desired system will
    wake up.


    Of course if you don't have enough a PIX under your control to
    listen to the public IP, then you are going to have some difficulties
    getting a remote system to wake up if the remote network admin
    has taken basic security precautions.
    --
    Can a statement be self-referential without knowing it?
  3. Archived from groups: alt.internet.wireless (More info?)

    On 13 Aug 2004 19:40:02 GMT, roberson@ibd.nrc-cnrc.gc.ca (Walter
    Roberson) wrote:

    >It isn't impossible. I've posted code to do it.

    This code?
    http://groups.google.ca/groups?selm=bs125b%24do5%241%40canopus.cc.umanitoba.ca

    >WOL packets
    >are NOT inherently directed broadcast packets. They don't even
    >have to be -directed- broadcast packets: they can be any MAC address
    >that the system is set up to look for. You just need to find a way
    >to get the system at the other end to decapsulate a non-broadcast
    >packet and push it out onto the appropriate segment.
    >
    >To put it in more concrete terms: static map a public IP address to
    >one of the broadcast addresses listened to on the segment the WOL system
    >is on. In PIX terminology, this might be
    >
    >static (inside, outside) 201.52.93.4 192.168.1.255

    Methinks (not sure) that it dumps everything from 201.52.93.4 to the
    LAN broadcast address. That would give an outside system access to
    the DHCP server and could theoreticaly be assigned a DHCP address on
    the LAN. They might also spoof a DHCP server. I dunno about this...

    >and then if the packet with the proper WOL *payload* (not header!)
    >is sent to the public 201.52.93.4 address then the desired system will
    >wake up.
    >
    >Of course if you don't have enough a PIX under your control to
    >listen to the public IP, then you are going to have some difficulties
    >getting a remote system to wake up if the remote network admin
    >has taken basic security precautions.

    Methinks an ACL that blocks broadcasts from the outside interface
    would effectively block it.

    Of course a VPN would solve the problem easily as broadcasts through
    the tunnel are not a problem.

    The way I kludged it on a Unix box was to setup a program that accepts
    input from a telnet connection to an IP socket run from inetd. The
    input is the MAC address of the target system. The packet is sent to
    the broadcast address of the LAN with a payload in magic packet
    format. It worked just fine 3 year ago, but I haven't done anything
    since then. I'm also a lousy programmer.

    There were a few problems. The big one is absolutely zero security.
    If I exposed the IP socket to the internet, any hacker could easily
    spray garbage all over my network. I have a router ACL rule to limit
    access to only my home system, but I would prefer an authorization
    system so I can use it anywhere.

    Argh... incoming customers.

    --
    # Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
    # 831.336.2558 voice http://www.LearnByDestroying.com
    # jeffl@comix.santa-cruz.ca.us
    # 831.421.6491 digital_pager jeffl@cruzio.com AE6KS
  4. Archived from groups: alt.internet.wireless (More info?)

    In article <56jqh055buov29uj52fu9t2t1sbb72s0dr@4ax.com>,
    Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
    :On 13 Aug 2004 19:40:02 GMT, roberson@ibd.nrc-cnrc.gc.ca (Walter
    :Roberson) wrote:

    :>It isn't impossible. I've posted code to do it.

    :This code?
    :http://groups.google.ca/groups?selm=bs125b%24do5%241%40canopus.cc.umanitoba.ca

    That's the one.


    :>To put it in more concrete terms: static map a public IP address to
    :>one of the broadcast addresses listened to on the segment the WOL system
    :>is on. In PIX terminology, this might be

    :>static (inside, outside) 201.52.93.4 192.168.1.255

    :Methinks (not sure) that it dumps everything from 201.52.93.4 to the
    :LAN broadcast address. That would give an outside system access to
    :the DHCP server and could theoreticaly be assigned a DHCP address on
    :the LAN. They might also spoof a DHCP server. I dunno about this...

    On the Cisco PIX, this sets up an address translation, but you still
    need to set up an ACL on the outside interface in order for the packet
    to be permitted through. One could eliminate the worries about DHCP
    and so on by restricting the access by source IP, source port,
    destination port [presuming TCP or UDP], ICMP major type [presuming
    ICMP] or IP protocol [if you wanted to get more exotic and obscure
    but not necessarily more secure.]

    :Methinks an ACL that blocks broadcasts from the outside interface
    :would effectively block it.

    No, at the time the ACL is checked on the PIX, it is the *public*
    IP that is examined. If the public IP is not one of the broadcast
    ones for the network of the PIX outside interface, then the PIX doesn't
    know at ACL checking time that the destination is a broadcast address.

    On the PIX, if you want to block sending broadcasts inwards, you
    have to either do so explicitly, or be careful with your 'permit'
    statements and let the ACL fall off the end so that the traffic is
    denied implicitly. There is no "no ip directed-broadcast" directive
    on the PIX.

    There is a circumstance under which the PIX checks for broadcast
    addresses: if it sees a packet with a -source- IP that it believes is
    a broadcast IP, then it will block it (at least if it's an inside
    packet going out.) This blockage can happen accidently: if one
    uses a 'static' command with a netmask other than 255.255.255.255
    then the PIX treates the highest and lowest induced IPs as being
    broadcast IPs and blocks packets sourced for them. This is nearly
    the only place on the PIX where an IP mask is truely a netmask and
    not just a [CIDR] bitmask, so this feature bites people from time to time.


    :The way I kludged it on a Unix box was to setup a program that accepts
    :input from a telnet connection to an IP socket run from inetd. The
    :input is the MAC address of the target system. The packet is sent to
    :the broadcast address of the LAN with a payload in magic packet
    :format. It worked just fine 3 year ago, but I haven't done anything
    :since then. I'm also a lousy programmer.

    :There were a few problems. The big one is absolutely zero security.
    :If I exposed the IP socket to the internet, any hacker could easily
    :spray garbage all over my network. I have a router ACL rule to limit
    :access to only my home system, but I would prefer an authorization
    :system so I can use it anywhere.

    Might I suggest using a http or https form with a small CGI backend
    that checks the input for plausibility (e.g., isn't a broadcast
    or multicast MAC, perhaps allows only ARIN-known manufacturer's prefixes]?
    Going http or https would allow you to use a username/password system
    for authorization; https would add encryption on top of that.

    Coding it up to accept IPv6 would be a bit more work.
    --
    Scintillate, scintillate, globule vivific
    Fain would I fathom thy nature specific.
    Loftily poised on ether capacious
    Strongly resembling a gem carbonaceous. -- Anon
Ask a new question

Read More

Wireless LAN Wireless Lan Internet Wireless Networking