[Solved] How to Wake-On-LAN from Different Subnet

[solamour]

Code: Select all

com1
    | 192.168.0.1
    |
    |
    | 192.168.0.254
gentoo
    | 192.168.1.254
    |
    |
    | 192.168.1.1
android

"gentoo" has 2 network interfaces (192.168.0.254 and 192.168.1.254). I can do Wake-On-LAN from "gentoo" to "com1" with "wakeonlan -i 192.168.0.255 MAC_ADDRESS_OF_COM1". Now, I'd like to do the same from "android", which is in a different subnet, but so far nothing seems to work.

Q1) Should I use the same command (i.e. "wakeonlan -i 192.168.0.255 MAC_ADDRESS_OF_COM1") or something else?

Q2) How should I configure "gentoo", so that the magic packet is passed to 192.168.0.255? "gentoo" is using shorewall, if that makes any difference.
__
sol

[eccerr0r]

The WOL packets are ethernet raw packets and these are not "routable" so you can't traverse the router, which is what I think you're doing with the Gentoo machine.

You'll have to either write a repeater program on the Gentoo box to recreate the WOL packet on the other network. There should be a way to get Shorewall to replicate the packet on the other network, which unfortunately I'm not familiar with. Or you could write an http cgi script of sorts to create a WOL packet on that side of the net.

Since this is a firewall I'm not sure this is a solution but if you bridge the two LAN segments to one big segment, this also gets around the routing issue.

[szatox]

According to wiki

The magic packet is a broadcast frame containing anywhere within its payload 6 bytes of all 255 (FF FF FF FF FF FF in hexadecimal), followed by sixteen repetitions of the target computer's 48-bit MAC address, for a total of 102 bytes.

Since the magic packet is only scanned for the string above, and not actually parsed by a full protocol stack, it may be sent as any network- and transport-layer protocol

So, it doesn't matter what kind of packet you send as long as it reaches target device and contains proper sequence.

Now, to send packet across a router, you must assign target IP from the other network. Unfortunately that's not enough yet.
Before IP4 packet is sent, router sends broadcast ARP request asking to what MAC that particular IP is assigned. And here we hit the wall, as no device would respond. To get response, you must target an existing, active device. Unfortunately, in switched network, once IP is assigned to MAC, it is also assigned to a particular socket. Hubs do not perform such sophisticated operations, so in this case it could work

Well, while not completely impossible, it's not a very effective way to handle it. I suppose it would be easier to login into router and trigger magic packet from there. Or, replace router with a switch. (Yes, several physical devices enslaved in a bridge will act as a switch) - obviously it would no longer be a firewall.

However, there is one more thing that MIGHT be worth checking: IPv6
Can anyone give a hint if it's possible to route IPv6 packet into the void?

[papahuhn]

One can hardwire the broadcast mac address (all F's) to some free IP on the router with arp -s and perform NAT to that IP. It's how I do WoL from WAN.

[solamour]

One can hardwire the broadcast mac address (all F's) to some free IP on the router with arp -s and perform NAT to that IP. It's how I do WoL from WAN.

After some investigation and experiments, here is how I made it work.

1) Pick an address that is not currently used in "192.168.0.x" and set its MAC address to all FFs. In this example, I picked "192.168.0.9".

Code: Select all

arp -s 192.168.0.9 FF:FF:FF:FF:FF:FF

2) Make sure the new bogus address is correctly defined.

Code: Select all

arp

3) Let the magic packet go through from "wlan" (192.168.1.x) to "loc" (192.168.0.x).

Code: Select all

/etc/shorewall/rules
    ...
    ACCEPT              wlan    loc     udp     9

4) From "192.168.1.x" side, I send the magic packet to the bogus address (192.168.0.9) with the MAC address of the target device I'd like to wake up.
5) If I ever want to remove the bogus address and stop Wake-on-Lan, I use "-d" flag. For my case, "enp0s14" is the network interface name for "192.168.0.254".

Code: Select all

arp -i enp0s14 -d 192.168.0.9

I think I can also use "ip" instead of "arp". The result is the same.

Code: Select all

ip neigh add 192.168.0.9 lladdr FF:FF:FF:FF:FF:FF nud permanent dev enp0s14
ip neigh show
ip neigh del 192.168.0.9 dev enp0s14

Thanks everyone for taking time to respond.
__
sol

[szatox]

1) Pick an address that is not currently used in "192.168.0.x" and set its MAC address to all FFs. In this example, I picked "192.168.0.9".

why not 192.168.0.255?
IP broadcast will never be occupied by a client so there is no reason not to bind it to arp broadcast, so you don't have to reserve it or guess every time you want it. Unless router cuts it short of course. But then, why would router drop incoming broadcast?

[papahuhn]

1) Pick an address that is not currently used in "192.168.0.x" and set its MAC address to all FFs. In this example, I picked "192.168.0.9".

why not 192.168.0.255?
IP broadcast will never be occupied by a client so there is no reason not to bind it to arp broadcast, so you don't have to reserve it or guess every time you want it. Unless router cuts it short of course. But then, why would router drop incoming broadcast?

DNAT has to be performed in the PREROUTING chain on a router. Then, however, it is processed as a local destined packet by the routing logic, as the trace shows:

Code: Select all

 3)               |            ip_rcv_finish() {
 3)   4.353 us    |              ip_route_input_noref();
 3)               |              ip_local_deliver() {
 3)               |                iptable_mangle_hook() {
 3)   0.248 us    |                  ipt_do_table();
 3)   0.719 us    |                }
 3)               |                iptable_filter_hook() {
 3)   0.389 us    |                  ipt_do_table();
 3)   0.944 us    |                }
 3)               |                ip_vs_reply4() {
 3)   0.246 us    |                  ip_vs_out.part.22.constprop.25();
 3)   0.792 us    |                }
 3)               |                ip_vs_remote_request4() {
 3)   0.240 us    |                  ip_vs_in.constprop.23();
 3)   0.784 us    |                }
 3)   0.165 us    |                nf_nat_ipv4_fn();
 3)   0.093 us    |                ipv4_helper();
 3)   0.473 us    |                ipv4_synproxy_hook();
 3)   0.105 us    |                ipv4_confirm();
 3)   1.636 us    |                ip_local_deliver_finish();
 3) + 10.972 us   |              }
 3) + 16.930 us   |            }