[Bug 290221] [netlink] default build of /usr/sbin/arp is broken for proxyarp

[email protected]
Newsgroups gmane.os.freebsd.devel.net
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290221

--- Comment #4 from [email protected] ---
A commit in branch stable/14 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=f7937053fd0899e7b808bab3a0576ff16f3e943d

commit f7937053fd0899e7b808bab3a0576ff16f3e943d
Author:     Andrey V. Elsukov <[email protected]>
AuthorDate: 2025-10-17 07:53:35 +0000
Commit:     Andrey V. Elsukov <[email protected]>
CommitDate: 2025-10-26 11:21:14 +0000

    arp: fix adding proxy entries for P2P interfaces

    The old rtsock implementation used in-kernel workaround to do so.
    When route to specified destination address used P2P interface, the
    kernel did the search with ifa_ifwithnet() for most suitable network
    and then add proxy entry to this interface.

    Use similar approach with netlink implementation. We already have
    get_ether_addr() function that does almost the same thing as
    ifa_ifwithnet(). Use it when we find that destination route uses
    P2P interface and then try to guess suitable interface. This should
    fix the use of netlink-based arp(8) in mpd5.

    Rename get_ether_addr() to get_ifinfo(), since now it is used to find
    only ifindex in case when hwaddr is specified by user.
    Also make set_nl() and delete_nl() prototype similar to rtsock.
    And allow '-i' to be used with '-S', since we already allow the same
    for '-s'.

    PR:             290221
    Reported by:    eugen
    Reviewed by:    eugen
    Differential Revision:  https://reviews.freebsd.org/D53113

    (cherry picked from commit c26d6bf9da013e839d9a696746ea1741569e619e)

 usr.sbin/arp/arp.c         | 32 ++++++++++++++++++++------------
 usr.sbin/arp/arp.h         |  9 ++++-----
 usr.sbin/arp/arp_netlink.c | 20 ++++++++++++++++----
 3 files changed, 40 insertions(+), 21 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.