Wake on LAN - Can wake from GUI but not from outside
-
You might want to summarize what your point is, I tried skimming through the first link be couldn't guess what tactic you thought would be useful. Setting a machines MAC to FF:FF:FF:FF:FF:FF is entertaining, but not really a great strategy.
Josh -
Setting a machine's MAC to all FF's is the point. So you got it. Then forward WoL to that machine will result in a broadcast. It works, but would be better to do it all within pfSense rather than having another piece of hardware though.
The last 3 links are methods of configuring a couple of old 'routers' with all FF MAC to turn them in to sort of a "broadcast agent" that could be used with WoL.
A static ARP entry may work too. That's what we used to do with the Actiontec.
Will need a script to run at start up for the ARP entry to survive a reboot though.arp -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -an to viewAdd static host or DNS entry if name resolution desired.
ff:ff:ff:ff:ff:ff 192.168.1.254 Broadcast -
ARP age.
Where is port 9 being forwarded to?
Unless it is a broadcast, it won’t work once the target machine has been aged out of the ARP table. And since it is not on it won’t respond to any ARPs.Is it possible to configure forward target to be 255.255.255.255? That way the WoL packet will be seen by all machines. (assuming WoL Magic Packet is being used).
Port 9 is forwarded to a computer with static IP.
There's another twist I've tried this morning. I have 2nd computer that is HTPC (Win 7 Pro) and when I try to wake it up with cell phone it worked!
Tried same with desktop and it does not work :(
Used pfSense GUI and it woke it up right away.
I went thru and compered all settings that are on the NIC and everything pretty much matches. One difference is that HTPC has Gigabyte GA-H67A-UD3H-B3 MB and desktop has Asus Sabertooth x58 both are using built in NIC. -
WOL sometimes needs to be enabled in BIOS.
-
JBG,
Before trying to wake them with the cell phone, go to Diagnostics - ARP Table. Is MAC and IP listed for machine? If not, that is why it won't wake up. It has been aged out of the ARP table. So that being the case the WoL 'Magic Packet' must be forwarded as a broadcast rather than to a specific machine. Try this…
Drop to a shell ( option 8 )
arp -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -an (should see above entry)Configure Firewall NAT Rule to forward your cell phone WoL to 192.168.1.254
Obviously replace above ip address with one appropriate for your network. Doesn't really matter what it is so long as it is valid for your subnet, unused and ARP table has it listed with MAC of all FF's.
Now try waking with cell phone.
-
JBG,
Before trying to wake them with the cell phone, go to Diagnostics - ARP Table. Is MAC and IP listed for machine? If not, that is why it won't wake up. It has been aged out of the ARP table. So that being the case the WoL 'Magic Packet' must be forwarded as a broadcast rather than to a specific machine. Try this…
Drop to a shell ( option 8 )
arp -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -an (should see above entry)Configure Firewall NAT Rule to forward your cell phone WoL to 192.168.1.254
Obviously replace above ip address with one appropriate for your network. Doesn't really matter what it is so long as it is valid for your subnet, unused and ARP table has it listed with MAC of all FF's.
Now try waking with cell phone.
NOYB,
I will give it a try in the morning.
-
JBG,
Before trying to wake them with the cell phone, go to Diagnostics - ARP Table. Is MAC and IP listed for machine? If not, that is why it won't wake up. It has been aged out of the ARP table. So that being the case the WoL 'Magic Packet' must be forwarded as a broadcast rather than to a specific machine. Try this…
Drop to a shell ( option 8 )
arp -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -an (should see above entry)Configure Firewall NAT Rule to forward your cell phone WoL to 192.168.1.254
Obviously replace above ip address with one appropriate for your network. Doesn't really matter what it is so long as it is valid for your subnet, unused and ARP table has it listed with MAC of all FF's.
Now try waking with cell phone.
NOYB,
You are the man! It works great now! Thank you!
Diagnostics - ARP Table shows each ip with all f's. I have not had a chance to check if HTPC was in ARP table before trying to wake it up.
-
Diagnostics - ARP Table shows each ip with all f's.
No, no, no. Each machine IP should not have all F's MAC. Each machine should still have it's ordinary unique MAC address.
Only a dedicated IP address, that is otherwise unused, should have all F's MAC in ARP Table.
That IP address / MAC pair can then be used to forward WoL packets as an ethernet broadcast.Such as 192.168.1.254 which is established by command: arp -s 192.168.1.254 ff:ff:ff:ff:ff:ff
And your firewall NAT rule should be config'd to forward the WoL packets to that address.Hope that is what you actually did and not assign each machine an all F's MAC.
-
Diagnostics - ARP Table shows each ip with all f's.
No, no, no. Each machine IP should not have all F's MAC. Each machine should still have it's ordinary unique MAC address.
Only a dedicated IP address, that is otherwise unused, should have all F's MAC in ARP Table.
That IP address / MAC pair can then be used to forward WoL packets as an ethernet broadcast.Such as 192.168.1.254 which is established by command: arp -s 192.168.1.254 ff:ff:ff:ff:ff:ff
And your firewall NAT rule should be config'd to forward the WoL packets to that address.Hope that is what you actually did and not assign each machine an all F's MAC.
That’s exactly what I did :)
I’ve assigned all F’s to each machine and it still worked. I was able to wake each machine individually but I was not able to browse that machine
Shared folder. Then I used
Arp –d 192.168.1.101
And deleted arp record then I added it again but this time with real IP and MAC.
I did not used this arp -s 192.168.1.254 ff:ff:ff:ff:ff:ff command and it still worked!
I’ll test in the morning to see if works after being in standby over night.
It should because when I do arp –an each ip has this ? (192.168.1.101) at 1c:6f:65
xx:xx on em0 permanent [ethernet] -
Those ARP table entries will not survive a router reboot nor some router config changes.
To make static ARP table entries and have them survive a router reboot and interfaces config changes, try this little attached patch. It's very small and simple enough to do by hand if desired.
Then just put ARP entries (IP MAC pairs) in /var/etc/Static_ARPs.conf and the ARP entries will be created at boot up or when an interface change is made.
I'd dedicate an IP address to being an ethernet broadcast (all F's MAC) rather than making a permanent ARP entry for each machine. Then just forward WoL to that IP address and the WoL Magic Packet is broadcast on the LAN as it should be, and the machine who’s MAC is in the Magic Packet payload wakes up.
-
Those ARP table entries will not survive a router reboot nor some router config changes.
To make static ARP table entries and have them survive a router reboot and interfaces config changes, try this little attached patch. It's very small and simple enough to do by hand if desired.
Then just put ARP entries (IP MAC pairs) in /var/etc/Static_ARPs.conf and the ARP entries will be created at boot up or when an interface change is made.
I'd dedicate an IP address to being an ethernet broadcast (all F's MAC) rather than making a permanent ARP entry for each machine. Then just forward WoL to that IP address and the WoL Magic Packet is broadcast on the LAN as it should be, and the machine who’s MAC is in the Magic Packet payload wakes up.
You were right. It did not survive reboot.
I've tried to follow your instructions but after reboot I don't get any permanent arp tables with command: arp an
I've placed attached file Static.ARP.Entries.patch in /var/etc
then I created new file Static_ARPs.conf in /var/etc with following entries (last four have been masked for the security)
arp -s 192.168.1.101 1c:6f:65xx:xx
arp -s 192.168.1.100 bc:ae:c5:18:xx:xx
arp -s 192.168.1.102 00:18:f3:76:xx:xxAppreciate your help!
-
The patch has to be applied by either using the patch command or manually adding the appropriate contents to /etc/inc/interfaces.inc and /var/etc/Static_ARPs.conf.
For example: patch -p0 -i Static.ARP.Entry.patch.txt
-
Sorry for the late response….
Here's what I did:
Inside /var/etc/Static_ARPs.conf placed 3 entires in this format
192.168.1.101 1c:6f:65xx:xx
192.168.1.100 bc:ae:c5:18:xx:xx
192.168.1.102 00:18:f3:76:xx:xxThen I run patch command here's the output:
[2.0-RC3][root@pfsense.router]/root(6): patch -p0 -i Static.ARP.Entries.patch.txt Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- /etc/inc/interfaces.inc 2011-08-31 12:32:37.000000000 -0700 |+++ /etc/inc/interfaces.inc.patched 2011-08-31 21:52:13.000000000 -0700 -------------------------- Patching file /etc/inc/interfaces.inc using Plan A... Hunk #1 succeeded at 3959 (offset -13 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- /var/etc/Static_ARPs.conf 1969-12-31 16:00:00.000000000 -0800 |+++ /var/etc/Static_ARPs.conf.patched 2011-08-31 20:29:06.000000000 -0700 -------------------------- Patching file /var/etc/Static_ARPs.conf using Plan A... Hunk #1 succeeded at 1. done [2.0-RC3][root@pfsense.router]/root(7):I will give it a test tomorrow morning.
-
In order for the Static ARP entries to be applied to the ARP table at least one of the following must occur.
Reboot
An Interface Config Change
DNSMASQ Service Restart (Status: Services)To verify run shell command arp -an and look for permanent entries.
I see Hunk #1 succeeded ant 3959 (offset -13 lines). Patch has been updated with correct target line number (3814) so that shouldn't happen anymore. Unless your interfaces.inc has other previous modifications.
To verify the patch applied correctly check the end of /etc/interfaces.inc. If patch applied correctly, it should look like this.
/* Enable staticarp, if enabled */ if(isset($config['dhcpd'][$if]['staticarp'])) { mwexec("/sbin/ifconfig " . escapeshellarg($ifcfg['if']) . " staticarp " ); mwexec("/usr/sbin/arp -d -i " . escapeshellarg($ifcfg['if']) . " -a > /dev/null 2>&1 "); if (is_array($config['dhcpd'][$if]['staticmap'])) { foreach ($config['dhcpd'][$if]['staticmap'] as $arpent) { mwexec("/usr/sbin/arp -s " . escapeshellarg($arpent['ipaddr']) . " " . escapeshellarg($arpent['mac'])); } } } else { mwexec("/sbin/ifconfig " . escapeshellarg($ifcfg['if']) . " -staticarp " ); mwexec("/usr/sbin/arp -d -i " . escapeshellarg($ifcfg['if']) . " -a > /dev/null 2>&1 "); } exec("/usr/sbin/arp -f /var/etc/Static_ARPs.conf"); // This is the new line for Static ARPs. return 0; } -
It works!
I did reboot and after issuing arp -an I see each ip with permanent at the end
? (192.168.1.100) at bc:ae:c5:18:xx:xx on em0 permanent [ethernet]I've also checked /etc/inc/interfaces.inc and it shows on the bottom what you've quoted above.
Would you know if this is something that would be implemented in pfSense 2.0 final or that's just a nature of the beast?
Thank you for your help!!!
-
I am not the authority, but no, it won't be part of 2.0.
I for one would like to see GUI support for such a static ARP capability feature. But far as I know it is not planned for any future version. But I'm not in the loop about such things, so even if it was I probably would not know.
Recommend submitting a feature request if you would like to see static ARP capability such as or similar to this in a future version.
-
I am not the authority, but no, it won't be part of 2.0.
I for one would like to see GUI support for such a static ARP capability feature. But far as I know it is not planned for any future version. But I'm not in the loop about such things, so even if it was I probably would not know.
Recommend submitting a feature request if you would like to see static ARP capability such as or similar to this in a future version.
No problem. I've created new feature request here http://redmine.pfsense.org/issues/1878 hopefully it gets considered.
Thanks!
-
Just wanted to note that there is built in support for running commands at boot time. You have to download the config, then edit it, then reload the modified config.
http://doc.pfsense.org/index.php/Executing_commands_at_boot_timeBut it looks like from the following post, that it won't work for this function.
http://forum.pfsense.org/index.php?topic=27359.0;prev_next=nextJust thought I would post in case anyone else has the same thought.
Josh