Project

General

Profile

Actions

Regression #14970

open

Static ARP assignments lose ``permanent`` flag in ARP table

Added by Denny Page 4 months ago. Updated 1 day ago.

Status:
Feedback
Priority:
Normal
Category:
Operating System
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
24.03
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

Arp flips back and forth between reporting static arp entries as permanent or having timeouts with large negative values, and eventually looses the concept that entries are static at all.

[23.09-RELEASE][root@fw]/root: arp -s 192.168.230.202 70:b3:d5:e3:d0:40
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in 938 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 938 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in 938 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -s 192.168.230.201 70:b3:d5:e3:d0:22
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in 841 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 841 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -s 192.168.230.203 70:b3:d5:e3:d0:23
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 816 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]

[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 812 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735173 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735173 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 808 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735173 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 802 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 797 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735254 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735254 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 727 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735254 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735261 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735261 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 720 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735261 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735265 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735265 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 716 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735265 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 690 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: 

[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 660 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735329 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735329 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 652 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735329 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 649 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735337 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735337 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 644 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735337 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 641 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735343 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735343 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 638 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735343 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735345 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735345 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 636 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735345 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 635 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735351 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735351 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 630 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735351 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735353 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735353 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 628 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735353 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in 1140 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in 1140 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 1140 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in 1140 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in 1113 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in 1113 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 1113 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in 1113 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in 1112 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in 1112 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 1112 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in 1112 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: 

Related issues

Related to Regression #15105: Static ARP entries "converted" to expiring ARPDuplicate

Actions
Has duplicate Bug #15010: Some strange with arp tableDuplicate

Actions
Has duplicate Bug #15269: DHCP static ARP entries are not staticDuplicate

Actions
Actions #1

Updated by Denny Page 4 months ago

Just for completeness, I tested with -S (rather than-s) with similar result.

[23.09-RELEASE][root@fw]/root: arp -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in 1086 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in 1086 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 1086 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in 1086 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -S 192.168.230.201 70:b3:d5:e3:d0:22
192.168.230.201 (192.168.230.201) deleted
[23.09-RELEASE][root@fw]/root: arp -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in 1066 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in 1066 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 1066 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -S 192.168.230.202 70:b3:d5:e3:d0:40
192.168.230.202 (192.168.230.202) deleted
[23.09-RELEASE][root@fw]/root: arp -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in 1045 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 1045 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expired [ethernet]
[23.09-RELEASE][root@fw]/root: arp -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699744409 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in 1028 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 1028 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -S 192.168.230.203 70:b3:d5:e3:d0:23
192.168.230.203 (192.168.230.203) deleted
[23.09-RELEASE][root@fw]/root: arp -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 999 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expired [ethernet]
[23.09-RELEASE][root@fw]/root: arp -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 994 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expired [ethernet]
[23.09-RELEASE][root@fw]/root: arp -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699744450 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699744450 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 987 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 974 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expired [ethernet]
[23.09-RELEASE][root@fw]/root: arp -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in 1180 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in 1180 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 1180 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in 1180 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: 
Actions #2

Updated by Jim Pingle 4 months ago

  • Tracker changed from Bug to Regression
  • Target version set to 2.8.0
  • Plus Target Version set to 24.03
Actions #3

Updated by Jim Pingle 4 months ago

  • Assignee set to Christian McDonald
Actions #4

Updated by Christian McDonald 4 months ago

  • Status changed from New to Feedback

This is not reproducible on the latest builds of 2.8.0 and 24.03.

(I was able to reproduce it on 23.09 to some extent. I see the flapping permanent and expires in -1699744450 seconds but I have not seen an entry lose its static-ness outright)

Actions #5

Updated by Denny Page 4 months ago

How does the kernel in 24.03 compare with that of 23.09?

Actions #6

Updated by Marcos M 3 months ago

  • Has duplicate Bug #15010: Some strange with arp table added
Actions #7

Updated by Johan Belmans 3 months ago

Denny Page wrote:

Arp flips back and forth between reporting static arp entries as permanent or having timeouts with large negative values, and eventually looses the concept that entries are static at all.

[...]

Can anyone solve this issue? It would help me on a daily base.
I use the "permanent license" to wake up devices on remote locations.

Thanks

Johan

Actions #8

Updated by Marcos M 2 months ago

Is this still happening on 23.09.1?

Actions #9

Updated by Johan Belmans 2 months ago

Unfortunately yes. This is still happening in 23.09.1
If I am not mistaken it started happening two or three releases ago.

Actions #10

Updated by Jim Pingle 2 months ago

Actions #11

Updated by Boycee . 2 months ago

The issue I opened (#15105) was a decided to be a duplicate of this one. Just pasting in the detail I added. Personally the poor (cosmetic) output would be a much lower priority than the fact the static ARP entires are lost once the device is active on the network, meaning unicast WOL only works once i.e a functional problem. Could someone create a patch that keeps re-adding the static ARP perhaps as a workaround?

Under pfsense 2.7.2, it appears that static ARP entries can be created (for example when a host is offline) however the entries are converted into regular ARP entries (which expire) once a host is present on the network. Removing the static ARP flag from the DHCP entry, applying the configuration, and then reconfiguring it and applying again appears to recreate the static ARP entry, however, if the host is present on the network it is converted into an expiring ARP entry.

Once the (now temporary) ARP entry expires, when removing the static ARP entry via the DHCP config page, I see the following in the system log:

php-fpm /services_dhcp_edit.php: The command '/usr/sbin/arp -d '192.168.5.5'' returned exit code '1', the output was 'arp: delete 192.168.5.5: No such file or directory'

I assume this is because the static ARP entry is no longer present to be removed from the backend?

I also observe that all user added devices with static ARP (i.e not the pfSense interfaces which are consistently in permanent state) can appear in various states in ARP table diagnostics page, switching between a missing/blank status, permanent, and a huge negative expiry time progressively getting more and more negative, and the regular expiry time once the device is present on the network.

The issue presented immediately after upgrading to pfsense 2.7.2.

Actions #12

Updated by Marcos M 2 months ago

Thank you for confirming. The 24.03 dev snaps for plus are now available, testing on that would be appreciated (the Boot Environments feature is very handy here!).

Actions #13

Updated by Jonathan Lee 2 months ago

This could be also related

https://redmine.pfsense.org/issues/15104

I am having one broadcast domain now the previous version had separated intra interface broadcast domains, I never showed intra interface layer 2 traffic until 23.09

Actions #14

Updated by Jonathan Lee 2 months ago

This could, could also cause broadcast arp storms and VLAN hopping vulnerabilities. Prior versions had broken up the layer 2 broadcast domains.

Actions #15

Updated by Denny Page 2 months ago

Jonathan Lee wrote in #note-13:

This could be also related

https://redmine.pfsense.org/issues/15104

For my part, after reading the other report I don't see how.

Actions #16

Updated by Zachary Cohen about 2 months ago

Boycee . wrote in #note-11:

The issue I opened (#15105) was a decided to be a duplicate of this one. Just pasting in the detail I added. Personally the poor (cosmetic) output would be a much lower priority than the fact the static ARP entires are lost once the device is active on the network, meaning unicast WOL only works once i.e a functional problem. Could someone create a patch that keeps re-adding the static ARP perhaps as a workaround?

Under pfsense 2.7.2, it appears that static ARP entries can be created (for example when a host is offline) however the entries are converted into regular ARP entries (which expire) once a host is present on the network. Removing the static ARP flag from the DHCP entry, applying the configuration, and then reconfiguring it and applying again appears to recreate the static ARP entry, however, if the host is present on the network it is converted into an expiring ARP entry.

Once the (now temporary) ARP entry expires, when removing the static ARP entry via the DHCP config page, I see the following in the system log:

php-fpm /services_dhcp_edit.php: The command '/usr/sbin/arp -d '192.168.5.5'' returned exit code '1', the output was 'arp: delete 192.168.5.5: No such file or directory'

I assume this is because the static ARP entry is no longer present to be removed from the backend?

I also observe that all user added devices with static ARP (i.e not the pfSense interfaces which are consistently in permanent state) can appear in various states in ARP table diagnostics page, switching between a missing/blank status, permanent, and a huge negative expiry time progressively getting more and more negative, and the regular expiry time once the device is present on the network.

The issue presented immediately after upgrading to pfsense 2.7.2.

I can confirm this exact behavior you described and pfSense 2.7.2 being the origination point.

Actions #17

Updated by Christian McDonald about 2 months ago

If someone can provide me with two versions as closely related in time as possible along with a reproducer I can bisect this

Actions #18

Updated by Zachary Cohen about 2 months ago

Christian McDonald wrote in #note-17:

If someone can provide me with two versions as closely related in time as possible along with a reproducer I can bisect this

Not exactly sure what you're asking for, but I did a pretty extensive comparison between v 2.7.0 (unaffected) and 2.7.2 (affected) and can't seem to identify a cause.

My only guess is that arp_flush() is being triggered when delete_old_routes() is triggered by another event... but nothing has been changed around that processing, from what I can find.

The only other references I've seen to similar behavior on FreeBSD are due to interface-level events, not individual leases getting renewed.

Actions #19

Updated by Christian McDonald about 2 months ago

Basically someone (likely me) just needs to start producing test builds at various points in time between a known good version and a known broken version. By doing a bisect you can generally land on the exact commit where the behavior changed. The key here is having a reliable reproducer to check for said behavior.

Ideally the reproducer would be a script that can be run under automation that produces a binary result...broken or not broken. It's the best way to do root cause analysis on issues like this. We can beat around the bush trying to find the root cause organically which might save time in the long run, but a bisect is a pretty mechanical way of definitely landing at the problem commit. It's just time consuming.

Actions #20

Updated by Jim Pingle 23 days ago

  • Subject changed from 23.09 arp issues with static assignment to Static ARP assignments lose ``permanent`` flag in ARP table
  • Status changed from Feedback to New
Actions #21

Updated by Jim Pingle 8 days ago

  • Has duplicate Bug #15269: DHCP static ARP entries are not static added
Actions #22

Updated by Christian McDonald 8 days ago

Looks like this might have gotten some attention upstream, will track.

https://reviews.freebsd.org/D43983

Actions #23

Updated by Denny Page 8 days ago

It seems like an interim fix would be to build arp with "WITHOUT_NETLINK" defined.

Actions #24

Updated by Michele D'A. 5 days ago

Is there a workaround?

Actions #25

Updated by Christian McDonald 5 days ago

We pulled in a patch that might fix this. Check out the latest 24.03 development snapshots.

Actions #26

Updated by Michele D'A. 1 day ago

Christian McDonald wrote in #note-25:

We pulled in a patch that might fix this. Check out the latest 24.03 development snapshots.

I have the community version, is there a patch for version 2.7.2?

Actions #27

Updated by Christian McDonald 1 day ago

  • Status changed from New to Feedback
Actions #28

Updated by Christian McDonald 1 day ago

Michele D'Alessio wrote in #note-26:

Christian McDonald wrote in #note-25:

We pulled in a patch that might fix this. Check out the latest 24.03 development snapshots.

I have the community version, is there a patch for version 2.7.2?

No patch for 2.7.2, this patch is included in CE development snapshots though.

Actions

Also available in: Atom PDF