Project

General

Profile

Actions

Regression #14374

closed

Static ARP entries are not configured at boot

Added by Jeff Kuehl 12 months ago. Updated 6 months ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
Aliases / Tables
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.09
Release Notes:
Default
Affected Version:
2.7.0
Affected Architecture:
amd64

Description

Not Sure if Category of "Aliases / Tables" is correct for ARP issues, or otherwise we could put on "DHCP Server" category issue

At least on Reboot, if not also during extended times when client is not active on the Interface's network, DHCP reserved clients (with "Create an ARP Table Static Entry for this MAC & IP Address pair") Static entries are not Permanent and disappear.

Actions #1

Updated by Jeff Kuehl 12 months ago

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.

Actions #2

Updated by Kris Phillips 11 months ago

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?

Actions #3

Updated by Jeff Kuehl 11 months ago

Yes that is correct.

Actions #4

Updated by Jeff Kuehl 11 months ago

I can provide logs or diagnostics to help?

Actions #5

Updated by Danilo Zrenjanin 11 months ago

  • Status changed from New to Confirmed

I was able to replicate the issue. After reboot, the arp entry didn't stay in the permanent status.

Tested on the:

23.01-RELEASE (amd64)
built on Fri Feb 10 20:06:33 UTC 2023
FreeBSD 14.0-CURRENT

Actions #6

Updated by Jeff Kuehl 11 months ago

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

Actions #7

Updated by aleksei prokofiev 11 months ago

I've tested on 23.05

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

I can confirm such behaviour on 23.05. After reboot the status in ARP table switch from permanent to expires.

Actions #8

Updated by Jim Pingle 11 months ago

  • Related to Regression #14451: Not create static ARP when have additional DHCP pool added
Actions #9

Updated by Kris Phillips 11 months ago

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

Actions #10

Updated by Evgeny Korostelev 10 months ago

pfSense 2.7.0 problem with static arp after reboot still exists.

Actions #11

Updated by JohnPoz _ 10 months ago

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.

Actions #12

Updated by Steve Wheeler 10 months ago

  • Tracker changed from Bug to Regression
  • Project changed from pfSense Plus to pfSense
  • Subject changed from 23.01 keeps clearing "Static Arp Entries" to Static ARP Entries are cleared at boot
  • Category changed from Aliases / Tables to Aliases / Tables
  • Target version set to CE-Next
  • Affected Plus Version deleted (23.01)
  • Plus Target Version set to 23.01
  • Affected Version set to 2.7.0
Actions #13

Updated by Steve Wheeler 10 months ago

  • Plus Target Version changed from 23.01 to 23.09
Actions #14

Updated by Jim Pingle 10 months ago

  • Target version changed from CE-Next to 2.8.0
Actions #15

Updated by Zachary Cohen 10 months ago

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

Step 4. To execute the command manually, run "/bin/sh /usr/local/etc/rc.d/arp.sh". Upon checking the pfSense UI "Diagnostics > ARP Table", you should see that all of the entries are now "Permanent".

Actions #16

Updated by Jim Pingle 10 months ago

  • Assignee set to Jim Pingle

I can reproduce this in my lab as well.

Actions #17

Updated by Jim Pingle 10 months ago

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.

Actions #18

Updated by Jim Pingle 10 months ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100
Actions #19

Updated by Zachary Cohen 10 months ago

Jim Pingle wrote in #note-18:

Applied in changeset 5082edf92795fe8266be49905fe4f07eb682449d.

Confirmed that this patch resolves the issue.

Thanks for fixing this so quickly!

Actions #20

Updated by Jordan G 10 months ago

patch works on 23.05.1 as advertised

Actions #21

Updated by Jim Pingle 10 months ago

  • Status changed from Feedback to Resolved
Actions #22

Updated by ARAMP1 _ 10 months ago

Does not appear to work on 2.7.0.

Actions #23

Updated by Jim Pingle 10 months ago

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.

Actions #24

Updated by JohnPoz _ 10 months ago

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

I posted details of the test here.

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

Actions #25

Updated by Jim Pingle 9 months ago

  • Subject changed from Static ARP Entries are cleared at boot to Static ARP entries are not configured at boot

Updating subject for release notes.

Actions #26

Updated by Jim Pingle 6 months ago

  • Target version changed from 2.8.0 to 2.7.1
Actions

Also available in: Atom PDF