Shellcmd command doesn't get executed at boot
-
Hi, I use shellcmd to enable a static arp entry at boot (for wake on lan (over internet)).
In the latest snapshot the command doesn't seem to get executed at boot.
When issuing an "arp -a", the specific host doesn't carry any "permanent" flag…Snippet from config:
[...] <dnsallowoverride><shellcmd>arp -s xxx.xx.xx.xxx 00:17:f2:xx:xx:xx</shellcmd> <interfaces>[...]</interfaces></dnsallowoverride>
Any changes in pfsense 2.0 that may break this shellcmd command? Entering the command (after boot) through the webGUI or console works as expected.
2.0-BETA4-nanobsd
built on Sun Aug 8 11:22:28 EDT 2010
FreeBSD 8.1-RELEASE -
shellcmd works fine. May be some network things configured after that point that wipe it out. You can trace the boot source to find out what's happening.
-
It is probably the existing static ARP code. If static ARP isn't on for an interface, it clears all of the ARP entries for an interface when initializing the DHCP server, even if that interface isn't using DHCP. It might be possible the expand the logic there to not touch WAN-type interfaces.
-
Yes, I can confirm that a restart of either the dhcpd or dnsmasq service clears all (including my static) ARP entries.
It is probably the existing static ARP code. If static ARP isn't on for an interface, it clears all of the ARP entries for an interface when initializing the DHCP server, even if that interface isn't using DHCP. It might be possible the expand the logic there to not touch WAN-type interfaces.
I guess I'm out of luck with shellcmd? :(
Other ways of accomplish my static ARP? One thing that crossed my mind is to change the default (20min) ARP cache to, say … 125 minutes? It would be sufficient for my needs as the OS X 10.6 host wakes up for a short while every 2 hours (sleep proxy feature)...
-
Might be one way to do it, but as I said the logic that clears the arp entries should probably not run on WAN-type interfaces anyhow. It could be considered a bug.
-
Hmm, WAN-type.. ? Including LAN interfaces that has traffic through WAN ? ::)
Might be one way to do it, but as I said the logic that clears the arp entries should probably not run on WAN-type interfaces anyhow. It could be considered a bug.
-
No, Interfaces with a gateway (like WAN, OPT WAN, etc)
I thought that's what you meant by the "over the Internet", that it was hanging off the WAN subnet.
If it's for WOL on the LAN side, that's trickier. You might put a script in /usr/local/etc/rc.d/ that sleeps for a bit and then adds the static arp entry. Not sure if that would bypass this or not (it may just slow down the boot process) but it could be worth a shot.
-
Or hack in an exec call in services.inc to add the static arp entry after the arp entries are cleared.
-
Ok, my fault. I was unclear with the part of the whereabouts of the host. ;)
Thank you very much for your suggestions! I will look into it…
I'll have to weight in how often I use magic packets over internet. This way was just "easier", as in that I didn't need a very restricted firewall rule (as for the WebGUI) to be in place for WOL.
-
Have you checked the man page! Might just be syntax changed.
-
Yes, the command works. But all the ARP entries is cleared when the dhcpd/dnsmasq service starts (and that is after shellcmd is run).
As a quick workaround I set the ARP cache to 4 hours. Should be fine for a while in an home network environment…
I created an new entry under: System: Advanced: Miscellaneous: System Tunables
Tunable Name Description Value net.link.ether.inet.max_age ARP Cache 14400 seconds (default 1200 seconds) 14400