View previous topic :: View next topic |
Author |
Message |
solamour l33t
Joined: 21 Dec 2004 Posts: 698 Location: San Diego, CA
|
Posted: Tue Jul 08, 2014 5:43 am Post subject: [Solved] How to Wake-On-LAN from Different Subnet |
|
|
Code: | 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
Last edited by solamour on Thu Jul 10, 2014 3:50 am; edited 1 time in total |
|
Back to top |
|
|
eccerr0r Watchman
Joined: 01 Jul 2004 Posts: 9645 Location: almost Mile High in the USA
|
Posted: Wed Jul 09, 2014 12:25 am Post subject: |
|
|
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/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
Back to top |
|
|
szatox Advocate
Joined: 27 Aug 2013 Posts: 3104
|
Posted: Wed Jul 09, 2014 3:48 pm Post subject: |
|
|
According to wiki
Quote: | 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? |
|
Back to top |
|
|
papahuhn l33t
Joined: 06 Sep 2004 Posts: 626
|
Posted: Wed Jul 09, 2014 5:03 pm Post subject: |
|
|
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. _________________ Death by snoo-snoo! |
|
Back to top |
|
|
solamour l33t
Joined: 21 Dec 2004 Posts: 698 Location: San Diego, CA
|
Posted: Thu Jul 10, 2014 3:50 am Post subject: |
|
|
papahuhn wrote: | 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.
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".
Code: | arp -i enp0s14 -d 192.168.0.9 |
I think I can also use "ip" instead of "arp". The result is the same.
Code: | 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 |
|
Back to top |
|
|
szatox Advocate
Joined: 27 Aug 2013 Posts: 3104
|
Posted: Thu Jul 10, 2014 7:32 pm Post subject: |
|
|
Quote: | 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? |
|
Back to top |
|
|
papahuhn l33t
Joined: 06 Sep 2004 Posts: 626
|
Posted: Thu Jul 10, 2014 9:35 pm Post subject: |
|
|
szatox wrote: | Quote: | 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: |
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 | }
|
_________________ Death by snoo-snoo! |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|