"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

Last edited by solamour on Thu Jul 10, 2014 3:50 am; edited 1 time in total

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._________________Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSDWhat am I supposed to be advocating?

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?

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:

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

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

Code:

arp

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

Code:

/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".

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?

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: