Wake on LAN - Can wake from GUI but not from outside
-
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:65xx: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