Wake on LAN - Can wake from GUI but not from outside

JohnnyBeGood

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.

NOYB

@JohnnyBeGood:

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.

JohnnyBeGood

@NOYB:

@JohnnyBeGood:

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]

NOYB

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.

Static.ARP.Entries.patch.txt

JohnnyBeGood

@NOYB:

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:xx

Appreciate your help!

NOYB

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

JohnnyBeGood

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:xx

Then 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.

NOYB

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;
}

JohnnyBeGood

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!!!

NOYB

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.

JohnnyBeGood

@NOYB:

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!

stompro

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_time

But 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=next

Just thought I would post in case anyone else has the same thought.
Josh