I'm having a similar problem although, in my case I'm just trying to wake from LAN hosts (not WAN) or from the router's GUI. I've installed etherwake and the luci add-on for waking hosts from the GUI, which is perfectly suitable for my scenario. But it seems packets are somehow not being broadcast or the host is not receiving them. Running nc --udp --listen --local-port=9 --hexdump (as suggested on the Arch wiki) on the host I'm trying to wake shows no output when I issue etherwake MAC, whether from a LEDE ssh session or from another host on my LAN. And yes, I've enabled wake on PCI event in the computer's BIOS and have /usr/bin/ethtool -s interface wol g in a start-up file on the host (running ethtool interface on the host shows "g") I'm trying to wake.
I found this thread a while ago when I was trying to troubleshoot this and it seemed like a solution was found via the terse comment "Just install opkg update; opkg install ip-tiny; /sbin/ip n add ...." But I cannot decipher what solution was being offered. Ok, I know how to update the package repository and I can see that a package is being installed. But what, exactly, is this package doing? I already have /sbin/ip on this router but "ip n add" is no kind of valid command. And besides, what is ip-tiny? A binary that replaces /sbin/ip or something?
Further input on the issue of wake-on-lan will be appreciated. Btw, I formerly had wake-on-lan working under the DD-WRT router I replaced a few months ago wirth one running LEDE.
Normally there is just the reduced-functionality "ip" built-in into busybox binary. "ip-tiny" package is the proper iproute2 "ip" but with just the core functionality of it. "ip-full" is the full large "ip" from iproute2.
The offered solution is to install "ip-tiny", so that your system offers more functionality than just the busybox ip. Likely busybpox "ip" is not enough, but you need at least "ip-tiny" which installs ip binary.
opkg update
opkg install ip-tiny
(In basic situation, /sbin/ip is just a symlink into busybox. With ip-tiny it is symlink to /sbin/ip-tiny)
Thanks for the further clarifications. So the advice to run "/sbin/ip n add ...." was wrong since the poster was implying that, despite having installed ip-tiny, the busybox verision (/sbin/ip) was still to be used? And btw, having installed now ip-tiny on my LEDE, I believe the new binary is located at /usr/bin/ip: I find no /sbin/ip-tiny on this system (which ip-tiny brings no results). So, terse directives that contain basic mistakes are part of what had me confused about the initial proposed solution, it seems.
Now I can look into adding the static ARP entry mentioned by jow: perhaps that will resolve the issue for me
Yes, 17.01.04. Still not having any luck with WoL, even after having installed ip-tiny: so far as I can tell, no magic packets are being received at the target machine. Running tcpdump -i eth0 -x port 9 on the target host shows no output when sending the packet, whether it's sent from the router or from another host on my LAN. Could it somehow be a firewall issue? Hard to imagine since all hosts share the same private subnet. In any case, here's some informative reading on the issue of WoL that's geared toward those (such as myself) who have only a rudimentary understanding of more technical apsects of computer networking: https://forums.freenas.org/index.php?threads/wake-on-lan-wol-why-it-works-why-it-doesnt-and-frustration.18354/
Continuing to try and troubleshoot this issue. I'm beginning to believe that magic packets are simply not traveling on my LAN, perhaps due to some misconfiguration on the router? Any things I can check in settings to ascertain whether there might be some configuration issue that prevents magic packets being sent/received?
I've tried now from a couple of hosts on my LAN, to recieve magic packets--receive both from the router and/or from each other. None of those tests have succeeded. Just to make sure my tests are valid, I'll describe what I've been doing.
On the host that is to receive the magic packet (output of sudo ethtool ethX reads "Wake-on: g"), I run one of two commands (I've tried both) in a terminal: sudo tcpdump -i eth0 -x port 9 or sudo nc --udp --listen --local-port=9 --hexdump. Then, I'll run, on another host on my LAN, either the sudo wol MAC or sudo etherwake MAC (MAC being a stand-in for the MAC address of the host that should be receiving the magic packet), or I will issue the wake-on-lan command from the router itself specifying the MAC address of the target host. When I check the terminal in which I've left the tcpdump or nc commands running, I subsequently see no output. I've tried this with 3 different hosts now on my LAN, none of which show any output for the tcpdump/nc commands after I've issued the wol command or similar from another host or from the router. To me, this indicates that there must be a problem with the router passing the magic packets (unicast packet issue?)
If anyone can offer correctives to my perhaps flawed assumptions about these tests and their results, I would appreciate it. In any case, input of any sort will be appreciated.
NOTE: possible flawed assumption--so far as I can recall, only one of the hosts I've tested has wake-up enabled in BIOS, that host being the real target of this project. I've assumed that, since I'm not really trying to wake up the two test hosts--the ones I'm using to try and troubleshoot with--not having wake enabled in BIOS won't matter. So long as they're powered on, they should be able to detect magic packets, whether wake has been enabled in BIOS or not.
I ran across some archived OpenWRT wiki pages that, while related, do not seem to address very specifically the issues I'm experiencing of magic packets apparently not traversing the network. See https://wiki.openwrt.org/doc/uci/wol and https://wiki.openwrt.org/doc/uci/etherwake . Those articles discuss some wake-on-lan config files but, so far as I understand it, those would be applicable to waking hosts when the router boots or perhaps via cron jobs. Whereas what I'm trying to do is to wake hosts manually, preferably through the router GUI (Network > Wake on LAN, select interface and host), though I'd settle for issuing etherwake MAC from an ssh session on the router or from a terminal running in another host on my LAN.
I need to do a bit of retracting of my assertion that magic packets seem not to be moving across my network. Noting in the wol man page that it is possible to specify a port number, I decided, after having issued sudo tcpdump -i eth0 -x port 9 in a terminal on a host I'll call host1 on my LAN, to issue sudo wol -p 9 MAC (MAC being the MAC address of host1) on another host I'll call host2 on my LAN. The result was that the magic packet sent by host2 was, in fact, received by host1, as ouput in the host1 tcpdump terminal indicated:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:34:07.728200 IP (tos 0x0, ttl 64, id 52826, offset 0, flags [DF], proto UDP (17), length 130)
1.2.3.4.36086 > 255.255.255.255.9: [udp sum ok] UDP, length 102
This test doesn't give me much of an idea of what to try next, but it does prove that a magic packet can travel over my LAN.
I got these issues sorted. I decided to set up a little test LAN using my old DD-WRT router, since I knew that wake-on-lan had worked fine when I was using it. I could not manage to wake the target machine on the little DD-WRT test LAN either. Since I had been suspecting, even though the onboard NIC was supposed to support WoL, that it might be the cause of my problems, and since I had a spare add-in gigabit card laying around, I decided to take the onboard NIC out of the picture and try the add-in card. Using that card, WoL began working fine on the little test LAN.
I then hooked the target machine by its new NIC to my LEDE router and began WoL testing there. WoL began working on the LEDE LAN as well--first subsequent to issuing WoL MAC from another host on the LAN, then via the router's GUI, so long as I selected the correct network interface from which to broadcast the magic packet (br-lan, in my case).
I don't have anything enlightening to post regarding my failed magic packet tests. And I do not plan on further analysing the results, since the goal to which those tests were tangential has now been acheived.