Sign in with
Sign up | Sign in
Your question

wake-on-lan

Last response: in Wireless Networking
Share
Anonymous
a b F Wireless
August 13, 2004 6:12:23 AM

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

More about : wake lan

Anonymous
a b F Wireless
August 13, 2004 1:27:46 PM

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....
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
Anonymous
a b F Wireless
August 13, 2004 11:40:02 PM

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

In article <qvpph0pjl6bhp623l6lh6p44jr3qmrlmgj@4ax.com>,
Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
:o n 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?
Related resources
Can't find your answer ? Ask !
Anonymous
a b F Wireless
August 14, 2004 3:48:39 AM

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%40...

>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
Anonymous
a b F Wireless
August 14, 2004 6:49:38 PM

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

In article <56jqh055buov29uj52fu9t2t1sbb72s0dr@4ax.com>,
Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
:o n 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%40...

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
!