pfSense

Found Work-around for Rebooting is to use the "ShellCmd" package to run "arp -s <IPAddr> <MAC_Addr>" on boot for each client this applies to.

The Issue occurs on both interfaces I use DHCP with Static Entries/Reservations on. Historical, this has not been an issue for years.

So, for clarification, if you have a static MAC and IP mapping, after some period of time of the client being inactive it will disappear from the Status --> DHCP Leases page?

Yes that is correct.

I can provide logs or diagnostics to help?

I also have re-experienced the arp entry disappearing with static arp after being in-active for less than a week.

I've tested on 23.05

23.05-RELEASE (amd64)
built on Mon May 22 15:04:36 UTC 2023
FreeBSD 14.0-CURRENT

Title should be updated, since this is no longer only relevant to 23.01.

pfSense 2.7.0 problem with static arp after reboot still exists.

Just to chime in - this came up in recent thread

https://forum.netgate.com/topic/181220/arp-tables-most-static-addresses-are-no-longer-permanent

I did see it on my 23.05.1 that a previous entry I had set to create static arp pair was not list as perm any more. A cycle of arp pair, save, recheck arp pair returned the perm to the arp table. Have not had chance to reboot as of yet, but poster in that thread did validate that his go away on reboot of his 2.7 system.

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 to "Services > Cron" and create the following job:

0     *     *     *     *     root     /bin/sh /usr/local/etc/rc.d/arp.sh

Looks like it was a simple change in a PHP test early in the static route setup function. Simple to fix by using a better test to check if an interface is enabled. Commit should show up here in a few minutes and can be applied via the patches package as usual.

Jim Pingle wrote in #note-18:

Applied in changeset 5082edf92795fe8266be49905fe4f07eb682449d.

Confirmed that this patch resolves the issue.

Thanks for fixing this so quickly!

patch works on 23.05.1 as advertised

Does not appear to work on 2.7.0.

ARAMP1 _ wrote in #note-22:

Does not appear to work on 2.7.0.

It works on 2.7.0 in my testing here. You will need to reboot after applying the patch.

Yeah I just tested this on my 2.7 and working..

I posted details of the test here.

https://forum.netgate.com/post/1114947