WOL, forward

Hi,

which IP PORT does the WOL feature use ? I want to make a forward of that
port in my router to my local network, port PPPP to XX.XX.XX.255 but I don't
know what port I must use.

thanks in advance

Ports are an artifact of TCP/IP. WOL doesn't run over TCP/IP but rather at a
lower layer. A WOL packet not only doesn't have a port, it doesn't have an
IP address. The packets that need to be passed won't go through an IP router
and need to originate on the same LAN as the computer you want to wake up.

If you are using an SMC Barricade, and if the computer you want to wake up
has gotten an IP address from the Barricade's DHCP server, you can send it a
WOL packet from the Barricade's DHCP Server / Clients List page. (This
assumes, of course, that you can get to the Barricade's administration web
from where you are.) There are probably other routers that have this
feature.

Alternatively, if there is a Windows computer on the same LAN as the one you
want to wake up and if you can run a program on it (perhaps it has VNC),
AMD's "PCnet Magic Packet(TM) Utility Revision 1.00" has always worked well
for me. Even thought it is from January 1999, I routinely use it with
Windows 2000 and I imagine it works with XP, too. It was available for free
from AMD at some point
(http://www.amd.com/us-en/Connectivit...rces/0,,50_233
4_2452_2456,00.html).

When I need to wake up a computer on a network that has a Linux box that I
can telnet to, I use a program on the Linux box called ether-wake. I don't
remember where I got it but it might have been
http://www.scyld.com/expert/wake-on-lan.html.

"User" <(E-Mail Removed)> wrote in message
news:brumc4$7r8ah$(E-Mail Removed)...
> Hi,
>
> which IP PORT does the WOL feature use ? I want to make a forward of that
> port in my router to my local network, port PPPP to XX.XX.XX.255 but I
don't
> know what port I must use.
>
> thanks in advance
>

In article <XYCEb.85715$8y1.291377@attbi_s52>,
John Roland Elliott <JohnRolandElliott-no-(E-Mail Removed)> wrote:
:Ports are an artifact of TCP/IP. WOL doesn't run over TCP/IP but rather at a
:lower layer.

True in one sense, not in another.

:A WOL packet not only doesn't have a port, it doesn't have an
:IP address.

True in one sense, not in another.

:The packets that need to be passed won't go through an IP router
:and need to originate on the same LAN as the computer you want to wake up.

But both parts of that are outright false.

http://gsd.di.uminho.pt/jpo/software...o-2.html#ss2.2

2.2 How does it work?

WOL is based on the following principle:

When the PC shuts down, the NIC still gets power, and keeps
listening on the network for a 'magic' packet to arrive. This
packet must contain a certain byte-sequence, but can be
encapsulated in any kind of packet (IPX, IP, anything). [...]

Magic sequence

If the Ethernet address of a target computer is 01:02:03:04:05:06
(6 bytes), then the LAN controller of that machine should be
looking for the following sequence

FFFFFFFFFFFF01020304050601020304050601020304050601 0203040506
01020304050601020304050601020304050601020304050601 0203040506
01020304050601020304050601020304050601020304050601 0203040506
010203040506010203040506

inside the frame.


Or read the AMD White Paper at
http://www.amd.com/us-en/assets/cont...docs/20213.pdf

Magic Packet Frame Detection

Once the LAN controller has been put into the Magic Packet mode, it
scans all incoming frames addressed to the node for a specific data
sequence, which indicates to the controller that this is a Magic
Packet frame. A Magic Packet frame must also meet the basic
requirements for the LAN technology chosen, such as SOURCE ADDRESS,
DESTINATION ADDRESS (which may be the receiving station's IEEE
address or a MULTICAST address which includes the BROADCAST
address), and CRC. [...]


There -is- an issue in sending such a packet from a remote location.
If you simply address remote system by its IP address, then when the
packet gets to the closest router to the host, that router is going to
ARP for the remote IP's MAC address, but the remote host isn't going to
answer because the remote host is dormant and the ARP packet isn't one
that matches the WOL criteria. But this is an issue when you are
sending out the packets locally too -- if you are sending out a packet
locally by its IP address then again the ARP will fail. The advantage
you have when sending locally is that you can go underneath the usual
layers and -directly- create a packet with the required MAC destination
(which you already have to know to create the Magic Sequence anyhow)
and that will be carried on the local segment. You can't just put in
the right destination MAC when you are remote, because even if you
managed to get the packet as far as a router, the router would rewrite
the destination MAC.

This issue does not, however, mean that you are retstricted to local
creation of WOL packets. Look back at the AMD description and notice
the bit about the BROADCAST address, which in the layer 2 context is
ff:ff:ff:ff:ff:ff . Thus if you can remotely inject any packet onto the
LAN segment that ends up having ff:ff:ff:ff:ff:ff as its destination
MAC, then provided the packet contains the WOL Magic Sequence, the
destination will wake up. And it turns out that there -are- ways to
remotely inject such packets. All you have to do when you are creating
the packets remotely is to address them to the subnet directed
broadcast IP for any subnet that shares the same segment as the
destination system. For example, if the destination segment happens to
be shared by computers in 14.11.9.16/28 and 9.33.84.0/25 then sending
to -either- 14.11.9.31 or 9.33.84.127 would work -- because when the
remote router sees these destinations, it is going to know that they
are subnet broadcast IPs and the remote router itself is going to
create packets with MAC destination ff:ff:ff:ff:ff:ff. Those created
packets are going to have the destination IP the same as whatever was
sent to, but the WOL technology ignores the destination IP address so
it doesn't matter to WOL which of the subnet broadcast IPs you use --
any one that covers a segment that includes the target host will do.

Of course, there might have been security measures put in place to
disallow remote sending to the subnet directed broadcast IPs, but
that's a different situation than saying, as you did, that the packets
involved "won't go through an IP router and need to originate on the
same LAN as the computer you want to wake up." Security measures
are subject to negotiation: if you have the appropriate
authorization, you *can* do remote WOL.
--
"Mathematics? I speak it like a native." -- Spike Milligan

Thanks, Walter, for a digestible treatment of the subject ... I think I know
quite a bit more about the underpinnings than I knew before, and that's
always a good thing.

In my defense, your honor, I do suspect that my misconceptions and resulting
misrepresentations pretty faithfully represented the state of things in the
overwhelming majority of extant networks, n'est pas? While my statement "the
packets that need to be passed won't go through an IP router" isn't strictly
true, "packets that need to be passed won't go through any IP router that
you're likely to encounter" probably is. In any case, you're right, I was
guilty of passing off as fact statements which were outright false (except
in any relevant real-world instance, where they were uniformly true.)

Incidentally, do you happen to know of software --- commercial or open ---
that embodies the concepts you describe? A utility, for example, that will
construct a Magic Packet for a machine (given its MAC address) and address
the packet to the broadcast address of a remote LAN (given the IP address of
the LAN)? Even though the packet would probably never reach its destination,
it might be fun to have such a utility. I still have an EISA token-ring
adaptor, I think, even though it is of no earthly use.

Cheers.

"Walter Roberson" <(E-Mail Removed)> wrote in message
news:brvco9$jq5$(E-Mail Removed)...
> In article <XYCEb.85715$8y1.291377@attbi_s52>,
> John Roland Elliott <JohnRolandElliott-no-(E-Mail Removed)> wrote:
> :Ports are an artifact of TCP/IP. WOL doesn't run over TCP/IP but rather
at a
> :lower layer.
>
> True in one sense, not in another.
>
> :A WOL packet not only doesn't have a port, it doesn't have an
> :IP address.
>
> True in one sense, not in another.
>
> :The packets that need to be passed won't go through an IP router
> :and need to originate on the same LAN as the computer you want to wake
up.
>
> But both parts of that are outright false.
>
>
http://gsd.di.uminho.pt/jpo/software...o-2.html#ss2.2
>
> 2.2 How does it work?
>
> WOL is based on the following principle:
>
> When the PC shuts down, the NIC still gets power, and keeps
> listening on the network for a 'magic' packet to arrive. This
> packet must contain a certain byte-sequence, but can be
> encapsulated in any kind of packet (IPX, IP, anything). [...]
>
> Magic sequence
>
> If the Ethernet address of a target computer is 01:02:03:04:05:06
> (6 bytes), then the LAN controller of that machine should be
> looking for the following sequence
>
> FFFFFFFFFFFF01020304050601020304050601020304050601 0203040506
> 01020304050601020304050601020304050601020304050601 0203040506
> 01020304050601020304050601020304050601020304050601 0203040506
> 010203040506010203040506
>
> inside the frame.
>
>
> Or read the AMD White Paper at
>
http://www.amd.com/us-en/assets/cont...docs/20213.pdf
>
> Magic Packet Frame Detection
>
> Once the LAN controller has been put into the Magic Packet mode, it
> scans all incoming frames addressed to the node for a specific data
> sequence, which indicates to the controller that this is a Magic
> Packet frame. A Magic Packet frame must also meet the basic
> requirements for the LAN technology chosen, such as SOURCE ADDRESS,
> DESTINATION ADDRESS (which may be the receiving station's IEEE
> address or a MULTICAST address which includes the BROADCAST
> address), and CRC. [...]
>
>
> There -is- an issue in sending such a packet from a remote location.
> If you simply address remote system by its IP address, then when the
> packet gets to the closest router to the host, that router is going to
> ARP for the remote IP's MAC address, but the remote host isn't going to
> answer because the remote host is dormant and the ARP packet isn't one
> that matches the WOL criteria. But this is an issue when you are
> sending out the packets locally too -- if you are sending out a packet
> locally by its IP address then again the ARP will fail. The advantage
> you have when sending locally is that you can go underneath the usual
> layers and -directly- create a packet with the required MAC destination
> (which you already have to know to create the Magic Sequence anyhow)
> and that will be carried on the local segment. You can't just put in
> the right destination MAC when you are remote, because even if you
> managed to get the packet as far as a router, the router would rewrite
> the destination MAC.
>
> This issue does not, however, mean that you are retstricted to local
> creation of WOL packets. Look back at the AMD description and notice
> the bit about the BROADCAST address, which in the layer 2 context is
> ff:ff:ff:ff:ff:ff . Thus if you can remotely inject any packet onto the
> LAN segment that ends up having ff:ff:ff:ff:ff:ff as its destination
> MAC, then provided the packet contains the WOL Magic Sequence, the
> destination will wake up. And it turns out that there -are- ways to
> remotely inject such packets. All you have to do when you are creating
> the packets remotely is to address them to the subnet directed
> broadcast IP for any subnet that shares the same segment as the
> destination system. For example, if the destination segment happens to
> be shared by computers in 14.11.9.16/28 and 9.33.84.0/25 then sending
> to -either- 14.11.9.31 or 9.33.84.127 would work -- because when the
> remote router sees these destinations, it is going to know that they
> are subnet broadcast IPs and the remote router itself is going to
> create packets with MAC destination ff:ff:ff:ff:ff:ff. Those created
> packets are going to have the destination IP the same as whatever was
> sent to, but the WOL technology ignores the destination IP address so
> it doesn't matter to WOL which of the subnet broadcast IPs you use --
> any one that covers a segment that includes the target host will do.
>
> Of course, there might have been security measures put in place to
> disallow remote sending to the subnet directed broadcast IPs, but
> that's a different situation than saying, as you did, that the packets
> involved "won't go through an IP router and need to originate on the
> same LAN as the computer you want to wake up." Security measures
> are subject to negotiation: if you have the appropriate
> authorization, you *can* do remote WOL.
> --
> "Mathematics? I speak it like a native." -- Spike Milligan

In article <QmIEb.402344$Dw6.1250326@attbi_s02>,
John Roland Elliott <JohnRolandElliott-no-(E-Mail Removed)> wrote:
:Incidentally, do you happen to know of software --- commercial or open ---
:that embodies the concepts you describe? A utility, for example, that will
:construct a Magic Packet for a machine (given its MAC address) and address
:the packet to the broadcast address of a remote LAN (given the IP address of
:the LAN)?

Sorry, I don't. It shouldn't be too hard to construct in Perl.


:Even though the packet would probably never reach its destination,
:it might be fun to have such a utility.

Ah, but once you know that it -is- possible to pass appropriate
packets remotely, there are all kinds of different ways to get
such packets passed. For example, if the machine to be woken
were behind a NAT'ing firewall, then the firewall could perhaps
be configured to map a public IP address to the broadcast IP of
the internal machine. Could be tuned to be very specific, e.g.,
that it only maps UDP port 22351 (decimal for 'WO') to the
broadcast IP and lets other ports through directly.
--
WW{Backus,Church,Dijkstra,Knuth,Hollerith,Turing,v onNeumann}D ?

In article <QmIEb.402344$Dw6.1250326@attbi_s02>,
John Roland Elliott <JohnRolandElliott-no-(E-Mail Removed)> wrote:
:Incidentally, do you happen to know of software --- commercial or open ---
:that embodies the concepts you describe? A utility, for example, that will
:construct a Magic Packet for a machine (given its MAC address) and address
:the packet to the broadcast address of a remote LAN (given the IP address of
:the LAN)?

Here goes. I have verified that the below produces valid looking
packets, and that the packets will indeed traverse routers, but
I do not have a Wake On Lan system around to see whether the
packet is truly recognized as per the AMD documentation.


#!/usr/bin/perl -w

# wol.pl, written 20031220 by Walter Roberson (E-Mail Removed)

# this program constructs a WOL (Wake on Lan) packet suitable for
# sending locally or over a net. The MAC of the system to be woken
# is required.
#
# The IP address the user supplies should NOT be
# the IP address of the system to be woken: instead it should be the
# subnet directed broadcast IP (e.g., 192.168.1.255) of any subnet
# known to be present on the segment of the target system. This
# would usually be the directed broadcast IP of the target system itself,
# but need not be in cases of multiple subnets that aren't carefully
# VLAN'd away from each other.
#
# To repeat: do NOT use the IP address of the target system. Not unless
# you are on the same subnet and you are using a static ARP entry.
# The target system is asleep, so it isn't going to answer an ARP
# from a router trying to find that particular address. Use a
# broadcast address, or some other packet forwarding trick.

use strict;
require 5.002;
use Socket;
use Sys::Hostname;

my ( $hisiaddr, $hispaddr, $hisMACtext,
$hisaddr, $hisport, $proto,
@MACbytes, $hisMACbin, $magicbody );

die "Syntax: $0 MAC ipaddr [port]" if @ARGV < 2;

$hisMACtext = shift @ARGV;
$hisaddr = shift @ARGV;
$hisport = shift @ARGV || 22357; # default 'WU', no significance

$magicbody = "\xff" x 6;
@MACbytes = split /[:-]/, $hisMACtext;
die "MAC wrong size" unless @MACbytes == 6;

$hisMACbin = pack "H*H*H*H*H*H*", @MACbytes;
$magicbody .= $hisMACbin x 16;

$proto = getprotobyname('udp');
socket(SOCKET, PF_INET, SOCK_DGRAM, $proto) || die "socket: $!";

$| = 1;
print "WOL packet being sent to udp port $hisport of ip $hisaddr\n";
$hisiaddr = inet_aton($hisaddr) || die "unknown host $hisaddr";
$hispaddr = sockaddr_in($hisport, $hisiaddr);

defined(send(SOCKET, $magicbody, 0, $hispaddr)) ||
die "send $hisaddr: $!";
--
Oh, to be a Blobel!

Walter is correct that the packets can traverse routers, but from my
limited experience you cannot simply send a WOL packet straight through.
If you know a little C++ and have knowledge of TCP/IP Routing you can
generate a packet that when it hits the router will have it's outter
wrapper destination stripped away to reveal a WOL packet. I have done this
myself with some help. We used linux for it support of raw packet
creation, and a SMC router.

Hope this helps Later

Okay, I'll put it through its paces when I get a chance. Say, would you post
a sample command line, please ... it's not obvious to me (a Perl virgin)
what format is appropriate for the MAC and IP addresses and port number on
the command line. Wait ... maybe I can figure it out ... is it

somename a1-fa-1f-aa-1f-a1 192.168.42.255 f1d0
or alternatively
somename a1:fa:1f:aa:1f:a1 192.168.42.255 f1d0

or should the port be decimal or 0x0f1d0

?

"Walter Roberson" <(E-Mail Removed)> wrote in message
news:bs125b$do5$(E-Mail Removed)...
> In article <QmIEb.402344$Dw6.1250326@attbi_s02>,
> John Roland Elliott <JohnRolandElliott-no-(E-Mail Removed)> wrote:
> :Incidentally, do you happen to know of software --- commercial or
open ---
> :that embodies the concepts you describe? A utility, for example, that
will
> :construct a Magic Packet for a machine (given its MAC address) and
address
> :the packet to the broadcast address of a remote LAN (given the IP address
of
> :the LAN)?
>
> Here goes. I have verified that the below produces valid looking
> packets, and that the packets will indeed traverse routers, but
> I do not have a Wake On Lan system around to see whether the
> packet is truly recognized as per the AMD documentation.
>
>
> #!/usr/bin/perl -w
>
> # wol.pl, written 20031220 by Walter Roberson (E-Mail Removed)
>
> # this program constructs a WOL (Wake on Lan) packet suitable for
> # sending locally or over a net. The MAC of the system to be woken
> # is required.
> #
> # The IP address the user supplies should NOT be
> # the IP address of the system to be woken: instead it should be the
> # subnet directed broadcast IP (e.g., 192.168.1.255) of any subnet
> # known to be present on the segment of the target system. This
> # would usually be the directed broadcast IP of the target system itself,
> # but need not be in cases of multiple subnets that aren't carefully
> # VLAN'd away from each other.
> #
> # To repeat: do NOT use the IP address of the target system. Not unless
> # you are on the same subnet and you are using a static ARP entry.
> # The target system is asleep, so it isn't going to answer an ARP
> # from a router trying to find that particular address. Use a
> # broadcast address, or some other packet forwarding trick.
>
> use strict;
> require 5.002;
> use Socket;
> use Sys::Hostname;
>
> my ( $hisiaddr, $hispaddr, $hisMACtext,
> $hisaddr, $hisport, $proto,
> @MACbytes, $hisMACbin, $magicbody );
>
> die "Syntax: $0 MAC ipaddr [port]" if @ARGV < 2;
>
> $hisMACtext = shift @ARGV;
> $hisaddr = shift @ARGV;
> $hisport = shift @ARGV || 22357; # default 'WU', no significance
>
> $magicbody = "\xff" x 6;
> @MACbytes = split /[:-]/, $hisMACtext;
> die "MAC wrong size" unless @MACbytes == 6;
>
> $hisMACbin = pack "H*H*H*H*H*H*", @MACbytes;
> $magicbody .= $hisMACbin x 16;
>
> $proto = getprotobyname('udp');
> socket(SOCKET, PF_INET, SOCK_DGRAM, $proto) || die "socket: $!";
>
> $| = 1;
> print "WOL packet being sent to udp port $hisport of ip $hisaddr\n";
> $hisiaddr = inet_aton($hisaddr) || die "unknown host $hisaddr";
> $hispaddr = sockaddr_in($hisport, $hisiaddr);
>
> defined(send(SOCKET, $magicbody, 0, $hispaddr)) ||
> die "send $hisaddr: $!";
> --
> Oh, to be a Blobel!

In article <WRVFb.460248$275.1351193@attbi_s53>,
John Roland Elliott <JohnRolandElliott-no-(E-Mail Removed)> wrote:
:Okay, I'll put it through its paces when I get a chance. Say, would you post
:a sample command line, please ... it's not obvious to me (a Perl virgin)
:what format is appropriate for the MAC and IP addresses and port number on
:the command line. Wait ... maybe I can figure it out ... is it

:somename a1-fa-1f-aa-1f-a1 192.168.42.255 f1d0
r alternatively
:somename a1:fa:1f:aa:1f:a1 192.168.42.255 f1d0

r should the port be decimal or 0x0f1d0

Decimal port if you put it in at all. You are right about : and -
except that at each group you have choice of separators, so you
could have a1-fa:1f:aa-1f-a1 if you chose.
--
This signature intentionally left... Oh, darn!

In article <(E-Mail Removed)>,
mike <(E-Mail Removed)> wrote:
:Walter is correct that the packets can traverse routers, but from my
:limited experience you cannot simply send a WOL packet straight through.
:If you know a little C++ and have knowledge of TCP/IP Routing you can
:generate a packet that when it hits the router will have it's outter
:wrapper destination stripped away to reveal a WOL packet.

I'd be interested in hearing more about how one send a packet to a
remote router and have it decapsulated at the other end. I can't think
of any way at the moment that does not involve a GRE or IPSec tunnel
(or IPX over IP tunnel) -- methods that require the active cooperation
of the remote equipment.

I am not a routing or TCP/IP expert, but networking and security
are important components of my work, and it seems to me that I
would have become aware of any non-tunneled methods of encapsulating
packets in the way you describe.
--
Most Windows users will run any old attachment you send them, so if
you want to implicate someone you can just send them a Trojan
-- Adam Langley