Alrighty, so from what I've read, FreeBSD/Nas may be the problem in the first place.
Maybe. However, setting up FreeBSD/FreeNAS correctly is where I started the research. I dug as deeply into getting that to work, with details of specifics - hardware, setup, releases, and diagnostics - as I did the router. In fact, I came to question the router only after I had pounded the OS and its setup in great depth.
Here is a link about the bios setting specific to your board:
http://superuser.com/questions/339416/wol-for-asus-m5a97-built-in-realtek-network-adapter
Yep, been there. That was one of the data points I pounded while messing with the OS setup.
There's a good chance you've seen these next few links already, but here goes:
Yes, I've been there; but thanks for the additional research. That's the kind of thing that will eventually solve this, or give me the clue.
One way to rule out if it's the router would be to setup a windows machine and try waking that. That way you can at least verify it works over the network.
I thought about that, but once I could get properly formed magic packets for *some* machine detectable on the subnet, I reasoned that I could save the additional time getting another OS running with WOL.
Given that you are using FreeNas I'm not going to be much help. To me, it sounds like an issue with the machine and not the router itself, especially since Wireshark is seeing the packets.
Probably so.
I've come to a much fuller understanding of WOL issues. It's fairly amazing that it works at all. Here are some of the underlying requirements for it to work that are not apparent.
- The power supply in your machine has to have +5 standby, and have to have enough of it to keep the portion of the motherboard that's involved in wake up alive, as well as enough to keep the NI and NIC if any, alive to see the magic packet. The Intel card included the note that (roughly) "your power supply must provide at least 1A of +5V Standby power to support Wake On LAN". Most power supplies these days do, but it's a hard requirement that can negate all further work if not satisfied. A quick-and-dirty indicator if this is happening is if the external LED on the NI port is lit when the machine is down.
- The motherboard chip sets must support keeping the NI chips alive if the on-motherboard NI is used, and must support a WOL or PME wake up. Further the motherboard must actually have traces or wire connectors from the NI or NIC to allow the WOL signal to be pulled. If that wire's not there, it ain't gonna wake. This is why NICs and motherboards used to have plug-in connectors for this process. It's now in the PCI and PCIe busses.
- The BIOS must support configuring WOL.
- The OS must support leaving the NI or NIC in a WOL-ready state.
- Connection must be wired, not wireless. Wireless packets are not correct format in some fashion I didn't dig to the bottom of, as it's not what I want to do anyway.
- The router must actually send usable magic packets to the machine. This was a hidden sleeper after I dug through a lot of the others, and how I came to post here. It was apparently not working, but I find now for other reasons.
- The magic packets *may* be rifle shots to the specific MAC or IP address, but this only works until the shutdown machine falls out of the ARP table. Some routers support static DHCP addresses to keep it in the ARP table, but it is by no means certain. Broadcast addresses are the right way to do this to be sure the shutdown machine gets its packet. This requires setting up the router to receive broadcast requests and actually send the broadcast, which is a big issue for packets from the internet, but not for packets already sent on the desired subnet.
- Broadcast packets already on the subnet need to be sent to a broadcast address that the router will actually broadcast. This is somewhat interactive between the magic packet sender software and the router's DHCP setup. It's why I posted the issue with DHCP reservations and sending to n.n.n.127. This may not be an issue for the default broadcast address when purely within the subnet. Not sure on this one. But I do get packets now.
- The sender software has to actually make magic packets, and these have to get through the sender machine's OS to the wires. This runs into compatibility issues on Windows 7 with some senders.
- To do any useful debug, you have to be able to detect packets, and the free WOL software is inconsistent about whether it tells you what's on the wire versus inside the sending machine.
I've fought my way through that stuff, and I think I now need to go back to the the target OS setup. As I said, I now believe the DIR-655 is innocent, at least with my current knowledge of the setup.
By the way, I want to issue some explicit thanks for all of you who've taken the time to reply here. Education is always worthwhile to me, and you've helped. I'll be back when I have either success or more data/questions on the router.