Hello, After upgrade from 13-stable to 14-stable server stop to enforce static/permanent ARP entries. E.g: # arp -s 100.65.4.30 78:a3:51:61:94:d2 make static entrie: (100.65.4.30) at 78:a3:51:61:94:d2 on vlan86 permanent [vlan] but when router recevied ARP, server change to expires: (100.65.4.30) at 78:a3:51:61:94:d2 on vlan86 expires in 153 seconds [vlan] the worst thing is that arp can come with any mac and will be changed as received
and also during check arp for specyfic host sometime its return a wired value (-1707995908 seconds) #arp -n 100.65.4.30 (100.65.4.30) at 78:a3:51:61:94:d2 on vlan86 permanent [vlan] #arp -n 100.65.4.30 (100.65.4.30) at 78:a3:51:61:94:d2 on vlan86 permanent [vlan] #arp -n 100.65.4.30 (100.65.4.30) at 78:a3:51:61:94:d2 on vlan86 expires in -1707995908 seconds [vlan] #arp -n 100.65.4.30 (100.65.4.30) at 78:a3:51:61:94:d2 on vlan86 permanent [vlan]
problem occurred also on fresh installation of 14-stable
Hello, I am new here ! can i work on this bug ?
I want to contribute to freeBSD in the networking domain, I have experience with l3-udp and tcp(beginner) and in l2 with ARP and bridging protocols. I would love to contribute to this, I would start debugging this by looking at the arp table design, and also check if the command line options while setting static entries are parsed correctly.
(In reply to Apoorv Sachan from comment #3) Yes, absolutely! It's of course up to you how you approach this, but I'd be inclined to start with a test case, both because a reproduction case will make debugging easier, but also because adding the test too will ensure this doesn't regress later. Current test cases live in tests/sys/netinet/arp.sh Also, even if you only get the test case to work and don't solve the bug itself, please do post the test. That's at least half of the work already.
Please let me put my two cents in. I confirm this regression, but it's not 100% reproducible. I noticed two facts after the upgrade from 13.2-STABLE to 14.0-STABLE: 1. Messages like "arp: 00:aa:bb:cc:dd:ee trying to modify permanent entry for w.x.y.z on vlanQ" disappeared from Syslog even though the net.link.ether.inet.log_arp_permanent_modify parameter is set to 1. 2. When traffic from an IP address protected by a static ARP entry is received from a spoofed host with the same IP address that violates this policy, the ARP entry for that IP address looks a bit strange: ? (w.x.y.z) at aa:bb:cc:dd:00:11 on vlan2 expires in -1708011502 seconds [vlan], but when the bogus traffic stops, the entry looks as expected ? (w.x.y.z.) at aa:bb:cc:dd:00:11 on vlan2 permanent [vlan].
(In reply to Marek Zarychta from comment #6) >I confirm this regression, but it's not 100% reproducible. It should have been "It is 100% reproducible". After the takeover of the IP by a bogus host, the Syslog logs only a notification of ARP change: arp: w.x.y.z moved from aa:bb:cc:dd:00:11 to 00:aa:bb:cc:dd:ee on vlan0
if build arp binary with options WITHOUT_NETLINK, everythink work as expected
Created attachment 248591 [details] bandaid for static arp Bandaid for setting static arp. Let's revert to rtsosck code until this feature gets properly implemented in netlink.
The above patch doesn't fix the issue. There is still something wrong with timers and permanent entries expire after some time.
https://reviews.freebsd.org/D43983
Tested on a couple of hosts. D43983 fixes the issue and makes that static arp violations are logged again: "arp: %x:%x:%x:%x:%x:%x attempts to modify permanent entry for %d.%d.%d.%d on %s". Thank you !
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=6a3e87e1306d5058d63f7552a25ed6376422f658 commit 6a3e87e1306d5058d63f7552a25ed6376422f658 Author: Gleb Smirnoff <glebius@FreeBSD.org> AuthorDate: 2024-02-20 18:31:05 +0000 Commit: Gleb Smirnoff <glebius@FreeBSD.org> CommitDate: 2024-02-20 18:31:05 +0000 arp: fix arp -s/-S When setting a permanent ARP entry, the route(4) would use rtm->rtm_rmx.rmx_expire == 0 as a flag for installing a static entry, but netlink(4) is looking for explicit NTF_STICKY flag in the request. The arp(8) utility was adopted to use netlink(4) by default, but it has lots of route-era guts internally. Specifically there is global variable 'opts' that shares configuration for both protocols, and it is still initialized with route(4) specific RTF_xxx flags. In set_nl() these flags are translated to netlink(4) parameters. However, RTF_STATIC is a flag that is never set by default, so attempt to use it as a proxy flag manifesting -s/-S results in losing it. Use zero opts.expire_time as a manifest of -s/-S operation. This is a minimal fix. A better one would be to fully get rid of route(4) legacy. The change also corrects the logic to set NUD_PERMANENT flag for consistency. This flag is ignored by our kernel (now). Reviewed by: melifaro, tuexen, emaste PR: 277063 Fixes: 6ad73dbf65048b0950a1ba6ff25607f6708c8954 Differential Revision: https://reviews.freebsd.org/D43983 usr.sbin/arp/arp_netlink.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=1e74fc950419f2b2482d313fc664cc03aa46f13c commit 1e74fc950419f2b2482d313fc664cc03aa46f13c Author: Gleb Smirnoff <glebius@FreeBSD.org> AuthorDate: 2024-02-20 18:31:05 +0000 Commit: Gleb Smirnoff <glebius@FreeBSD.org> CommitDate: 2024-02-25 18:03:17 +0000 arp: fix arp -s/-S When setting a permanent ARP entry, the route(4) would use rtm->rtm_rmx.rmx_expire == 0 as a flag for installing a static entry, but netlink(4) is looking for explicit NTF_STICKY flag in the request. The arp(8) utility was adopted to use netlink(4) by default, but it has lots of route-era guts internally. Specifically there is global variable 'opts' that shares configuration for both protocols, and it is still initialized with route(4) specific RTF_xxx flags. In set_nl() these flags are translated to netlink(4) parameters. However, RTF_STATIC is a flag that is never set by default, so attempt to use it as a proxy flag manifesting -s/-S results in losing it. Use zero opts.expire_time as a manifest of -s/-S operation. This is a minimal fix. A better one would be to fully get rid of route(4) legacy. The change also corrects the logic to set NUD_PERMANENT flag for consistency. This flag is ignored by our kernel (now). Reviewed by: melifaro, tuexen, emaste PR: 277063 Fixes: 6ad73dbf65048b0950a1ba6ff25607f6708c8954 Differential Revision: https://reviews.freebsd.org/D43983 (cherry picked from commit 6a3e87e1306d5058d63f7552a25ed6376422f658) usr.sbin/arp/arp_netlink.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
*** Bug 279208 has been marked as a duplicate of this bug. ***