ARP Tables...Most Static Addresses are No Longer Permanent
-
I can also validate that Regression #14374 is present on my 3.7.0 installation.
I noticed that simply opening and saving each DHCP entry with static ARP assigned (without making any changes) will resolve the issue for that specific entry. Rebooting the DHCP service has no impact.
Another interesting note - when I create an XML backup of my pfSense config and inspect it, all the proper static ARP entries are present. In other words, the configuration is present, it's just not being initialized properly on reboot. Note that I haven't had a chance to test the secondary symptom -- the eventual erasure of static ARP entries for inactive devices.
Setting up an hourly cron job / shellcmd which sets "arp -s <ip> <mac>" for each entry is the best solution until a patch has been issued.
-
Here's a script which leverages python3.11 to search for and set static arp entries:
Step 1. Create a shell script called "arp.sh" in the
/usr/local/etc/rc.d/
directory:#!/bin/sh python3.11 - <<EOF import xml.etree.ElementTree as ET import subprocess # Load the XML file tree = ET.parse("/conf/config.xml") root = tree.getroot() # Extract the IP and MAC addresses using list comprehension results = [{'mac': staticmap.find("mac").text, 'ip': staticmap.find("ipaddr").text} for staticmap in root.iter("staticmap") if staticmap.find("arp_table_static_entry") is not None] # Execute the arp commands for result in results: command = f"arp -s \"{result['ip']}\" \"{result['mac']}\"" print("Command:", command) completed_process = subprocess.run(command, shell=True, executable="/bin/sh", capture_output=True, text=True) if completed_process.returncode == 0: print("Command executed successfully.") print("Output:", completed_process.stdout) else: print("Command execution failed.") print("Error:", completed_process.stderr) EOF
Step 2. Run:
chmod +x /usr/local/etc/rc.d/arp.sh
Step 3. In the pfSense UI, navigate toServices > Cron
and create the following job:0 * * * * root /bin/sh /usr/local/etc/rc.d/arp.sh
Step 4. To execute the command manually, run
/bin/sh /usr/local/etc/rc.d/arp.sh
. Upon checking the pfSense UIDiagnostics > ARP Table
, you should see that all of the entries are now "Permanent". -
@zkhcohen so your script looks to what is in the arp table and makes them all static - ie perm? That would be a horrible idea
-
@johnpoz No. It looks for a pre-existing permanent static arp mapping in the DHCP config and then reapplies it via the CLI.
-
A patch was just issued (extremely quickly, I might add), and I can confirm that it fixes the issue in my environment:
https://redmine.pfsense.org/projects/pfsense/repository/2/revisions/5082edf92795fe8266be49905fe4f07eb682449d
-
The patch does not appear to work on 2.7.0.
-
@ARAMP1 I just tested this on my 2.7 vm and seems to be working..
So I created a static arp and it was there.
I then rebooted and it was gone.
I then applied the patch, and rebooted again and now its there.
-
Must have been user error....I got it working. After a couple restarts and wondering what I did wrong, I reinstalled the patch and everything is working.
Appreciate the help, gents.
-
I’m seeing this behavior in 23.09. ARP table shows dynamic (expires in <time>) ARP entry instead of static (permanent).
If I uncheck, “Create an ARP Table Static Entry for this MAC & IP Address pair” and then save.
Then recheck “Create an ARP Table Static Entry for this MAC & IP Address pair” and then save.
Then go back to ARP table, almost all the dynamic entries are flipped to static (permanent)
Anyone else seeing this?
-
@32G3LiQxu8 there seems to be an issue with when clients update their lease - there is this thread.
https://forum.netgate.com/topic/184155/static-arp-in-dhcp-overwritten
And this redmine
https://redmine.pfsense.org/issues/14970
So yeah if it has flipped to dynamic, a resave of the dhcp page where you set it as static will turn it back to perm, but it seems when client updates its lease again it will go back to dynamic.. See the thread linked to above, where you can duplicate it doing it by just having your client release and renew its lease.
From the redmine it seems to be correct in the upcoming 24.03 and 2.8 CE releases
"This is not reproducible on the latest builds of 2.8.0 and 24.03"
-
@johnpoz Thank you for the information. I will wait for a fix.