[PATCH v9 0/9] Use true MAC address of LAN local remote hosts
Bug #120 asks us to use the true MAC addresses of LAN local remote hosts, since some programs need this information. These commits introduces this for ARP, NDP, UDP, TCP and ICMP. --- v3: Updated according to feedback from Stefano and David: - Made the ARP/NDP lookup call filter out the requested address by itself, qualified by the index if the template interface - Moved the flow specific MAC address from struct flowside to struct flow_common. v4: - Updated according to feedback from David and Stefan - Added a cache table for ARP/NDP table contents v5: - Updated according to feedback from David and Stefan - Added cache table entries to FIFO/LRU queue - New criteria for when to consult ARP/NDP v6: - Simplified and merged mac cache table commits - Other changes after feedback from David. v7: - Fixes in patch #2 based on feedback from David and Stefano. v8: - Redesigned netlink and cache table part to be based on a subscription model. v8: - Small fix to patch #2 so that we cover the case when a MAC addess for a host has changed. - Added a commit where we send a gratuitous ARP/ unsolicitated NA to the guest when a new host is added to the neighbour cache table. Jon Maloy (8): netlink: add subsciption on changes in NDP/ARP table fwd: Add cache table for ARP/NDP contents arp/ndp: respond with true MAC address of LAN local remote hosts flow: add MAC address of LAN local remote hosts to flow udp: forward external source MAC address through tap interface tcp: forward external source MAC address through tap interface tap: change signature of function tap_push_l2h() icmp: let icmp use mac address from flowside structure arp.c | 9 ++- conf.c | 1 + epoll_type.h | 2 + flow.c | 2 + flow.h | 2 + fwd.c | 167 +++++++++++++++++++++++++++++++++++++++++++++++-- fwd.h | 9 +++ icmp.c | 8 ++- inany.c | 1 + ndp.c | 10 ++- netlink.c | 119 +++++++++++++++++++++++++++++++++++ netlink.h | 4 ++ passt.c | 17 +++-- passt.h | 3 +- pasta.c | 2 +- tap.c | 24 ++++--- tap.h | 7 ++- tcp.c | 18 ++++-- tcp.h | 2 +- tcp_buf.c | 37 +++++------ tcp_internal.h | 4 +- tcp_vu.c | 5 +- udp.c | 57 ++++++++++------- udp.h | 2 +- 24 files changed, 429 insertions(+), 83 deletions(-) -- 2.50.1
The solution to bug https://bugs.passt.top/show_bug.cgi?id=120
requires the ability to translate from an IP address to its
corresponding MAC address in cases where those are present in
the ARP or NDP tables.
To keep track of the contents of these tables we add a netlink
based neighbour subscription feature.
Signed-off-by: Jon Maloy
We add a cache table to keep track of the contents of the kernel ARP
and NDP tables. The table is fed from the just introduced netlink based
neigbour subscription function. The new table eliminates the need for
explicit netlink calls to find a host's MAC address.
Signed-off-by: Jon Maloy
When communicating with remote hosts on the local network, some guest
applications want to see the real MAC address of that host instead
of PASST/PASTA's own tap address. The flow_common structure is a
convenient location for storing that address, so we do that in this
commit.
Note that we don´t add actual usage of this address here, that will
be done in later commits.
Signed-off-by: Jon Maloy
We forward the incoming MAC address through the tap interface when
receiving incoming packets from network local hosts.
This is a part of the solution to bug
https://bugs.passt.top/show_bug.cgi?id=120
Signed-off-by: Jon Maloy
When we receive an ARP request or NDP neigbor solicitation over
the tap interface for a host on the local network segment attached
to the template interface, we respond with that host's real MAC
address.
Signed-off-by: Jon Maloy
We forward the incoming mac address through the tap interface when
receiving incoming packets from network local hosts.
This is a part of the solution to bug
https://bugs.passt.top/show_bug.cgi?id=120
Signed-off-by: Jon Maloy
In the next commit it must be possible for the callers of function
tap_push_l2h() to specify which source MAC address should be
added to the ethernet header sent over the tap interface. As a
preparation, we now add a new argument to that function, still
without any logical changes.
Signed-off-by: Jon Maloy
Even ICMP needs to be updated to use the external MAC address instead
of just the own tap address when applicable. We do that here.
Signed-off-by: Jon Maloy
Gratuitious ARP and unsolicitated NA should be handled with caution
because of the risk of malignant users emitting them to disturb
network communication.
There is however one case we where we know it is legitimate
and safe for us to send out such messages: The one time we switch
from using ctx->own_tap_mac to a MAC address received via the
recently added neigbour subscription function. Later changes to
the MAC address of a host in an existing entry cannot be fully
trusted, so we abstain from doing it in such cases.
When sending this type of messages, we notice that the guest accepts
the update, but also asks for a confirmation in the form of a regular
ARP/NS request. This is responded to with the new value, and we have
exactly the effect we wanted.
This commit adds this functionality.
Signed-off-by: Jon Maloy
On Tue, Sep 23, 2025 at 09:13:23PM -0400, Jon Maloy wrote:
We add a cache table to keep track of the contents of the kernel ARP and NDP tables. The table is fed from the just introduced netlink based neigbour subscription function. The new table eliminates the need for explicit netlink calls to find a host's MAC address.
Signed-off-by: Jon Maloy
--- v5: - Moved to earlier in series to reduce rebase conflicts v6: - Sqashed the hash list commit and the FIFO/LRU queue commit - Removed hash lookup. We now only use linear lookup in a linked list - Eliminated dynamic memory allocation. - Ensured there is only one call to clock_gettime() - Using MAC_ZERO instead of the previously dedicated definitions v7: - NOW using MAC_ZERO where needed - I am still using linear back-off for empty cache entries. Even an incoming, flow-creating packet from a local host gives no guarantee that its MAC address is in the ARP table, so we must allow for a few new attempts at first possible occasions. Only after several failed lookups can we conclude that we probably never will succeed. Hence the back-off. - Fixed a bug that David inadvertently made me aware of: I only intended to set the initial expiry value to MAC_CACHE_RENEWAL when an ARP/NDP table lookup was successful. - Improved struct and function description comments. v8: - Total re-design of table, adapting to the new, subscription based way of updating it. v9: - Catering for MAC address change for an existing host. --- conf.c | 1 + fwd.c | 162 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ fwd.h | 7 +++ netlink.c | 15 +++-- 4 files changed, 180 insertions(+), 5 deletions(-)
diff --git a/conf.c b/conf.c index 66b9e63..cc491c3 100644 --- a/conf.c +++ b/conf.c @@ -2133,6 +2133,7 @@ void conf(struct ctx *c, int argc, char **argv) c->udp.fwd_out.mode = fwd_default;
fwd_scan_ports_init(c); + fwd_neigh_cache_init();
if (!c->quiet) conf_print(c); diff --git a/fwd.c b/fwd.c index 250cf56..491303d 100644 --- a/fwd.c +++ b/fwd.c @@ -32,6 +32,168 @@ static in_port_t fwd_ephemeral_min = (1 << 15) + (1 << 14); static in_port_t fwd_ephemeral_max = NUM_PORTS - 1;
#define PORT_RANGE_SYSCTL "/proc/sys/net/ipv4/ip_local_port_range" +#define MAC_CACHE_SIZE 1024
Nit: you use "mac cache" some places, "neigh cache" others.
+ +/** + * mac_cache_entry - Entry in the ARP/NDP table cache + * @next: Next entry in slot or free list + * @addr: IP address of represented host + * @mac: MAC address of represented host + */ +struct mac_cache_entry { + struct mac_cache_entry *next;
Hash buckets might be overkill, but they're pretty easy and cheap, so whatever.
+ union inany_addr addr; + uint8_t mac[ETH_ALEN]; +}; + +/** + * mac_cache_table - Cache of ARP/NDP table contents + * @entries: Entries to be plugged into the hash slots when allocated + * @slots: Hash table slots + * @free: Linked list of unused entries + */ +struct mac_cache_table { + struct mac_cache_entry entries[MAC_CACHE_SIZE]; + struct mac_cache_entry *slots[MAC_CACHE_SIZE];
There's no inherent reason these two tables need the same size (and indeed some reasons they might not want to have the same size).
+ struct mac_cache_entry *free; +}; + +static struct mac_cache_table mac_cache; + +/** + * fwd_mac_cache_slot_idx() - Hash key to a number within the table range + * @c: Execution context + * @key: The key to be used for the hash + * + * Return: The resulting hash value + */ +static inline size_t fwd_mac_cache_slot_idx(const struct ctx *c, + const union inany_addr *key)
Maybe just neigh_hash_bucket()?
+{ + struct siphash_state st = SIPHASH_INIT(c->hash_secret); + uint32_t i; + + inany_siphash_feed(&st, key); + i = siphash_final(&st, sizeof(*key), 0); + + return ((size_t)i) & (MAC_CACHE_SIZE - 1);
This subtly depends on MAC_CACHE_SIZE being a power of 2. If you use (... % MAC_CACHE_SIZE) it will work regardless, and the compiler will still optimize if it _is_ a power of 2.
+} + +/** + * fwd_mac_cache_find() - Find a MAC cache table entry + * @c: Execution context + * @addr: Neighbour address to be used as key for the lookup + * + * Return: The found entry, if any. Otherwise NULL. + */ +static struct mac_cache_entry *fwd_mac_cache_find(const struct ctx *c, + const union inany_addr *addr) +{ + size_t idx = fwd_mac_cache_slot_idx(c, addr); + struct mac_cache_entry *e = mac_cache.slots[idx]; + + while (e && !inany_equals(&e->addr, addr)) + e = e->next; + + return e; +} + +/** + * fwd_mac_cache_alloc() - Allocate a mac cache table entry from the free list + * @c: Execution context + * @addr: Address used to determine insertion slot and store in entry + * @mac: The MAC address associated with the neighbour address + */ +void fwd_neigh_mac_cache_alloc(const struct ctx *c, + const union inany_addr *addr, uint8_t *mac)
This can update as well as allocating. Maybe fwd_neigh_cache_set()?
+{ + struct mac_cache_table *t = &mac_cache; + struct mac_cache_entry *e; + ssize_t idx; + + /* MAC address might change sometimes */ + e = fwd_mac_cache_find(c, addr); + if (e) { + memcpy(e->mac, mac, ETH_ALEN); + return; + } + + e = t->free; + if (!e) + return; + t->free = e->next; + + idx = fwd_mac_cache_slot_idx(c, addr); + e->next = t->slots[idx]; + t->slots[idx] = e; + + memcpy(&e->addr, addr, sizeof(*addr)); + memcpy(e->mac, mac, ETH_ALEN); +} + +/** + * fwd_mac_cache_free() - Remove an entry from a slot and add it to free list + * @c: Execution context + * @addr: Neighbour address used to find the slot for the entry + */ +void fwd_neigh_mac_cache_free(const struct ctx *c, const union inany_addr *addr) +{ + ssize_t idx = fwd_mac_cache_slot_idx(c, addr); + struct mac_cache_table *t = &mac_cache; + struct mac_cache_entry *e, **prev; + + prev = &t->slots[idx]; + e = t->slots[idx]; + while (e && !inany_equals(&e->addr, addr)) { + prev = &e->next; + e = e->next; + } + if (!e) + return; + + *prev = e->next; + e->next = t->free; + t->free = e; + memset(&e->addr, 0, sizeof(*addr)); + memset(e->mac, 0, ETH_ALEN); +} + +/** + * fwd_neigh_mac_get() - Lookup MAC address in the ARP/NDP cache table + * @c: Execution context + * @addr: Neighbour address used as lookup key + * @mac: Buffer for Ethernet MAC to return, found or default value. + * + * Return: true if real MAC found, false if not found or if failure + */ +bool fwd_neigh_mac_get(const struct ctx *c, const union inany_addr *addr, + uint8_t *mac) +{ + struct mac_cache_entry *e = fwd_mac_cache_find(c, addr); + + if (e) + memcpy(mac, e->mac, ETH_ALEN); + else + memcpy(mac, c->our_tap_mac, ETH_ALEN); + + return !!e; +} + +/** + * fwd_neigh_cache_init() - Initialize the neighbor ARP/NDP cache table + */ +void fwd_neigh_cache_init(void) +{ + struct mac_cache_table *t = &mac_cache; + struct mac_cache_entry *e; + + memset(t, 0, sizeof(*t)); + for (int i = 0; i < MAC_CACHE_SIZE; i++) { + e = &t->entries[i]; + e->next = t->free; + t->free = e; + } +}
/** fwd_probe_ephemeral() - Determine what ports this host considers ephemeral * diff --git a/fwd.h b/fwd.h index 65c7c96..a0e8fbc 100644 --- a/fwd.h +++ b/fwd.h @@ -56,5 +56,12 @@ uint8_t fwd_nat_from_splice(const struct ctx *c, uint8_t proto, const struct flowside *ini, struct flowside *tgt); uint8_t fwd_nat_from_host(const struct ctx *c, uint8_t proto, const struct flowside *ini, struct flowside *tgt); +void fwd_neigh_mac_cache_alloc(const struct ctx *c, + const union inany_addr *addr, uint8_t *mac); +void fwd_neigh_mac_cache_free(const struct ctx *c, + const union inany_addr *addr); +bool fwd_neigh_mac_get(const struct ctx *c, const union inany_addr *addr, + uint8_t *mac); +void fwd_neigh_cache_init(void);
#endif /* FWD_H */ diff --git a/netlink.c b/netlink.c index 1faf3da..1e1ec43 100644 --- a/netlink.c +++ b/netlink.c @@ -131,6 +131,8 @@ int nl_neigh_subscr_init(struct ctx *c) */ void nl_neigh_subscr_handler(struct ctx *c) { + union inany_addr addr; + uint8_t mac[ETH_ALEN]; struct nlmsghdr *nh; char buf[NLBUFSIZ]; ssize_t n; @@ -183,17 +185,20 @@ void nl_neigh_subscr_handler(struct ctx *c) dstlen != sizeof(struct in6_addr)) continue;
- char abuf[INET6_ADDRSTRLEN]; + if (!lladdr || lladdr_len != ETH_ALEN) + continue; + + memcpy(mac, lladdr, ETH_ALEN);
if (dstlen == sizeof(struct in_addr)) - inet_ntop(AF_INET, dst, abuf, sizeof(abuf)); + addr = inany_from_v4(*(struct in_addr *) dst); else - inet_ntop(AF_INET6, dst, abuf, sizeof(abuf)); + addr.a6 = *(struct in6_addr *) dst;
if (nh->nlmsg_type == RTM_NEWNEIGH) - debug("neigh: NEW %s lladdr_len=%zu", abuf, lladdr_len); + fwd_neigh_mac_cache_alloc(c, &addr, mac); else - debug("neigh: DEL %s", abuf); + fwd_neigh_mac_cache_free(c, &addr);
I think the debug() messages could still be useful. They could move into the functions of course, and might want to be demoted to trace(). -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On Tue, Sep 23, 2025 at 09:13:22PM -0400, Jon Maloy wrote:
The solution to bug https://bugs.passt.top/show_bug.cgi?id=120 requires the ability to translate from an IP address to its corresponding MAC address in cases where those are present in the ARP or NDP tables.
To keep track of the contents of these tables we add a netlink based neighbour subscription feature.
Signed-off-by: Jon Maloy
Reviewed-by: David Gibson
The change to a subscription model is large enough that I think it warrants dropping pre-existing reviews.
--- v3: - Added an attribute contianing NDA_DST to sent message, so that we let the kernel do the filtering of the IP address and return only one entry. - Added interface index to the call signature. Since the only interface we know is the template interface, this limits the number of hosts that will be seen as 'network segment local' from a PASST viewpoint. v4: - Made loop independent of attribute order. - Ignoring L2 addresses which are not of size ETH_ALEN. v5: - Changed return value of new function, so caller can know if a MAC address really was found. v6: - Removed warning printout which had ended up in the wrong commit. v8: - Changed to neighbour event subscription model
netlink: arp/ndp table subscription --- epoll_type.h | 2 + netlink.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++ netlink.h | 4 ++ passt.c | 8 ++++ 4 files changed, 128 insertions(+)
diff --git a/epoll_type.h b/epoll_type.h index 12ac59b..a90ffb6 100644 --- a/epoll_type.h +++ b/epoll_type.h @@ -44,6 +44,8 @@ enum epoll_type { EPOLL_TYPE_REPAIR_LISTEN, /* TCP_REPAIR helper socket */ EPOLL_TYPE_REPAIR, + /* Netlink neighbour subscription socket */ + EPOLL_TYPE_NL_NEIGH,
EPOLL_NUM_TYPES, }; diff --git a/netlink.c b/netlink.c index c436780..1faf3da 100644 --- a/netlink.c +++ b/netlink.c @@ -53,6 +53,7 @@ int nl_sock = -1; int nl_sock_ns = -1; static int nl_seq = 1; +static int nl_sock_neigh = -1;
/** * nl_sock_init_do() - Set up netlink sockets in init or target namespace @@ -84,6 +85,119 @@ static int nl_sock_init_do(void *arg) return 0; }
+/** + * nl_neigh_subscr_init() - Open a NETLINK_ROUTE socket and subscribe to neighbor events + * + * Return: 0 on success, -1 on failure + */ +int nl_neigh_subscr_init(struct ctx *c) +{ + struct epoll_event ev = { 0 }; + union epoll_ref ref = { .type = EPOLL_TYPE_NL_NEIGH, .fd = 0 };
You overwrite the .fd field, so there's not need to include it in the initializer. (Also 0 is a bad placeholder, since 0 is a valid fd).
+ + struct sockaddr_nl addr = { + .nl_family = AF_NETLINK, + .nl_groups = RTMGRP_NEIGH, + }; + + if (nl_sock_neigh >= 0) + return 0; + + nl_sock_neigh = socket(AF_NETLINK, SOCK_RAW | SOCK_CLOEXEC, NETLINK_ROUTE); + if (nl_sock_neigh < 0) + return -1; + + if (bind(nl_sock_neigh, (struct sockaddr *)&addr, sizeof(addr)) < 0) { + close(nl_sock_neigh); + nl_sock_neigh = -1; + return -1; + } + + ref.fd = nl_sock_neigh; + ev.events = EPOLLIN;
You could set this in the initializer.
+ ev.data.u64 = ref.u64; + if (epoll_ctl(c->epollfd, EPOLL_CTL_ADD, nl_sock_neigh, &ev) == -1) { + close(nl_sock_neigh); + nl_sock_neigh = -1; + return -1; + } + + return 0; +} + +/** + * nl_neigh_subscr_handler() - Non-blocking drain of pending neighbor updates + * @c: Execution context + */ +void nl_neigh_subscr_handler(struct ctx *c) +{ + struct nlmsghdr *nh; + char buf[NLBUFSIZ]; + ssize_t n; + + if (nl_sock_neigh < 0) + return; + + for (;;) { + n = recv(nl_sock_neigh, buf, sizeof(buf), MSG_DONTWAIT); + if (n <= 0) + return;
EAGAIN correctly results in a silent return, but you probably want to report other errors and EOF (n == 0) since those are not expected.
+ + nh = (struct nlmsghdr *)buf; + for (; NLMSG_OK(nh, n); nh = NLMSG_NEXT(nh, n)) { + struct ndmsg *ndm = NLMSG_DATA(nh); + struct rtattr *rta = (struct rtattr *)(ndm + 1); + size_t na = NLMSG_PAYLOAD(nh, sizeof(*ndm)); + const uint8_t *lladdr = NULL; + const void *dst = NULL; + size_t lladdr_len = 0; + size_t dstlen = 0; + + if (nh->nlmsg_type == NLMSG_DONE || + nh->nlmsg_type == NLMSG_ERROR) + continue;
IIUC, NLMSG_ERROR would also be unexpected, so should probably be reported.
+ if (nh->nlmsg_type != RTM_NEWNEIGH && + nh->nlmsg_type != RTM_DELNEIGH) + continue;
Should we filter on ndm->ndm_ifindex for neighbours on the template interface only? I'm not sure. It seems like we probably should filter on ndm->ndm_state.
+ for (; RTA_OK(rta, na); rta = RTA_NEXT(rta, na)) { + switch (rta->rta_type) { + case NDA_DST: + dst = RTA_DATA(rta); + dstlen = RTA_PAYLOAD(rta); + break; + case NDA_LLADDR: + lladdr = RTA_DATA(rta); + lladdr_len = RTA_PAYLOAD(rta); + break; + default: + break; + } + }
It seems like somewhere there ought to be something specifying the address type of both DST and LLADDR, but I'm not sure exactly where. We should check those, just in case some weirdo runs us on a host with IPX over Token Ring.
+ if (!dst) + continue; + + if (dstlen != sizeof(struct in_addr) && + dstlen != sizeof(struct in6_addr)) + continue; + + char abuf[INET6_ADDRSTRLEN]; + + if (dstlen == sizeof(struct in_addr)) + inet_ntop(AF_INET, dst, abuf, sizeof(abuf)); + else + inet_ntop(AF_INET6, dst, abuf, sizeof(abuf)); + + if (nh->nlmsg_type == RTM_NEWNEIGH) + debug("neigh: NEW %s lladdr_len=%zu", abuf, lladdr_len); + else + debug("neigh: DEL %s", abuf); + } + } +} + /** * nl_sock_init() - Call nl_sock_init_do(), won't return on failure * @c: Execution context diff --git a/netlink.h b/netlink.h index b51e99c..a7d3506 100644 --- a/netlink.h +++ b/netlink.h @@ -17,6 +17,8 @@ int nl_route_dup(int s_src, unsigned int ifi_src, int s_dst, unsigned int ifi_dst, sa_family_t af); int nl_addr_get(int s, unsigned int ifi, sa_family_t af, void *addr, int *prefix_len, void *addr_l); +bool nl_neigh_mac_get(int s, const union inany_addr *addr, int ifi, + unsigned char *mac); int nl_addr_set(int s, unsigned int ifi, sa_family_t af, const void *addr, int prefix_len); int nl_addr_get_ll(int s, unsigned int ifi, struct in6_addr *addr); @@ -28,5 +30,7 @@ int nl_link_set_mac(int s, unsigned int ifi, const void *mac); int nl_link_set_mtu(int s, unsigned int ifi, int mtu); int nl_link_set_flags(int s, unsigned int ifi, unsigned int set, unsigned int change); +int nl_neigh_subscr_init(struct ctx *c); +void nl_neigh_subscr_handler(struct ctx *c);
#endif /* NETLINK_H */ diff --git a/passt.c b/passt.c index 31fbb75..e20bbad 100644 --- a/passt.c +++ b/passt.c @@ -53,6 +53,7 @@ #include "vu_common.h" #include "migrate.h" #include "repair.h" +#include "netlink.h"
#define EPOLL_EVENTS 8
@@ -79,6 +80,7 @@ char *epoll_type_str[] = { [EPOLL_TYPE_VHOST_KICK] = "vhost-user kick socket", [EPOLL_TYPE_REPAIR_LISTEN] = "TCP_REPAIR helper listening socket", [EPOLL_TYPE_REPAIR] = "TCP_REPAIR helper socket", + [EPOLL_TYPE_NL_NEIGH] = "netlink neighbour subscription socket", }; static_assert(ARRAY_SIZE(epoll_type_str) == EPOLL_NUM_TYPES, "epoll_type_str[] doesn't match enum epoll_type"); @@ -322,6 +324,9 @@ int main(int argc, char **argv)
pcap_init(&c);
+ if (nl_neigh_subscr_init(&c) < 0) + warn("Failed to subscribe to RTMGRP_NEIGH"); + if (!c.foreground) { if ((devnull_fd = open("/dev/null", O_RDWR | O_CLOEXEC)) < 0) die_perror("Failed to open /dev/null"); @@ -414,6 +419,9 @@ loop: case EPOLL_TYPE_REPAIR: repair_handler(&c, eventmask); break; + case EPOLL_TYPE_NL_NEIGH: + nl_neigh_subscr_handler(&c); + break; default: /* Can't happen */ ASSERT(0); -- 2.50.1
-- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On Wed, Sep 24, 2025 at 12:47:22PM +1000, David Gibson wrote:
On Tue, Sep 23, 2025 at 09:13:22PM -0400, Jon Maloy wrote: [snip]
+ for (; RTA_OK(rta, na); rta = RTA_NEXT(rta, na)) { + switch (rta->rta_type) { + case NDA_DST: + dst = RTA_DATA(rta); + dstlen = RTA_PAYLOAD(rta); + break; + case NDA_LLADDR: + lladdr = RTA_DATA(rta); + lladdr_len = RTA_PAYLOAD(rta); + break; + default: + break; + } + }
It seems like somewhere there ought to be something specifying the address type of both DST and LLADDR, but I'm not sure exactly where. We should check those, just in case some weirdo runs us on a host with IPX over Token Ring.
Looked into this a bit more. The LLADDR type is a property of the link. I don't know if we get an RTM_NEWLINK before RTM_NEWNEIGH on the subscription channel. If so, we can check that and give up if it's not ARPHRD_ETHER. If not, we should probably probe the LLADDR type via our normal netlink socket and only subscribe if it is ARPHRD_ETHER. For the protocol address type, it looks to be in ndm->ndm_family, though rtnetlink(7) doesn't make that very clear. We should check that, not just the address length. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On Tue, Sep 23, 2025 at 09:13:30PM -0400, Jon Maloy wrote:
Gratuitious ARP and unsolicitated NA should be handled with caution because of the risk of malignant users emitting them to disturb network communication.
There is however one case we where we know it is legitimate and safe for us to send out such messages: The one time we switch from using ctx->own_tap_mac to a MAC address received via the recently added neigbour subscription function. Later changes to the MAC address of a host in an existing entry cannot be fully trusted, so we abstain from doing it in such cases.
So, I think you're right that the gratuitous ARP is safe in this case. But it concerns me that (other that some edge cases) we're sending data to the guest under own_tap_mac before we get the real MAC. At the point we send data from a flow to the guest, I would have expected to already have an entry in the host neighbour table (because by definition the host is talking to the peer), therefore in our cache, by the subscriber. I'm wondering if it could be as simple as both the neighbour update and the actual data coming in the same epoll batch, and we could avoid the temporary use of own_tap_mac by prioritising processing of the neighbour events.
When sending this type of messages, we notice that the guest accepts the update, but also asks for a confirmation in the form of a regular ARP/NS request. This is responded to with the new value, and we have exactly the effect we wanted.
This commit adds this functionality.
Signed-off-by: Jon Maloy
--- arp.c | 39 +++++++++++++++++++++++++++++++++++++++ arp.h | 2 ++ fwd.c | 11 +++++++++++ ndp.c | 10 ++++++++++ ndp.h | 1 + 5 files changed, 63 insertions(+) diff --git a/arp.c b/arp.c index 442faff..259f736 100644 --- a/arp.c +++ b/arp.c @@ -151,3 +151,42 @@ void arp_send_init_req(const struct ctx *c) debug("Sending initial ARP request for guest MAC address"); tap_send_single(c, &req, sizeof(req)); } + +/** + * arp_send_gratuitous() - Send a gratuitous ARP announcement for an IPv4 host + * @c: Execution context + * @ip: IPv4 address we announce as owned by @mac + * @mac: MAC address to advertise for @ip + */ +void arp_send_gratuitous(const struct ctx *c, struct in_addr ip, + const unsigned char *mac) +{ + char ip_str[INET_ADDRSTRLEN]; + struct { + struct ethhdr eh; + struct arphdr ah; + struct arpmsg am; + } __attribute__((__packed__)) req;
'req' is not a great name, since this is an ARP response, not a request (but see below).
+ /* Ethernet header */ + req.eh.h_proto = htons(ETH_P_ARP); + memcpy(req.eh.h_dest, MAC_BROADCAST, sizeof(req.eh.h_dest)); + memcpy(req.eh.h_source, c->our_tap_mac, sizeof(req.eh.h_source)); + + /* ARP header */ + req.ah.ar_op = htons(ARPOP_REPLY); + req.ah.ar_hrd = htons(ARPHRD_ETHER); + req.ah.ar_pro = htons(ETH_P_IP); + req.ah.ar_hln = ETH_ALEN; + req.ah.ar_pln = 4; + + /* ARP message */ + memcpy(req.am.sha, mac, sizeof(req.am.sha)); + memcpy(req.am.sip, &ip, sizeof(req.am.sip)); + memcpy(req.am.tha, MAC_BROADCAST, sizeof(req.am.tha)); + memcpy(req.am.tip, &ip, sizeof(req.am.tip));
So, I was trying to check if it made sense to use the same IP for both source and target here, and came across https://www.rfc-editor.org/rfc/rfc5227#section-3 Which suggests we should (counter intuitively) be using ARP requests, not ARP replies for announcements.
+ inet_ntop(AF_INET, &ip, ip_str, sizeof(ip_str)); + debug("Sending gratuitous ARP for %s", ip_str); + tap_send_single(c, &req, sizeof(req)); +} diff --git a/arp.h b/arp.h index d5ad0e1..b0dbb56 100644 --- a/arp.h +++ b/arp.h @@ -22,5 +22,7 @@ struct arpmsg {
int arp(const struct ctx *c, struct iov_tail *data); void arp_send_init_req(const struct ctx *c); +void arp_send_gratuitous(const struct ctx *c, struct in_addr ip, + const unsigned char *mac);
#endif /* ARP_H */ diff --git a/fwd.c b/fwd.c index c6348ab..879a351 100644 --- a/fwd.c +++ b/fwd.c @@ -26,6 +26,8 @@ #include "passt.h" #include "lineread.h" #include "flow_table.h" +#include "arp.h" +#include "ndp.h"
/* Empheral port range: values from RFC 6335 */ static in_port_t fwd_ephemeral_min = (1 << 15) + (1 << 14); @@ -129,6 +131,15 @@ void fwd_neigh_mac_cache_alloc(const struct ctx *c,
memcpy(&e->addr, addr, sizeof(*addr)); memcpy(e->mac, mac, ETH_ALEN); + + /* Send gratuitous ARP / unsolicited NA for the new mapping */
AFAICT this doesn't actually implement what the commit message describes - it seems to always send an ARP/NA when the neighbour table is updated.
+ if (inany_v4(addr)) { + struct in_addr ip4 = *inany_v4(addr); + + arp_send_gratuitous(c, ip4, e->mac); + } else { + ndp_send_unsolicited_na(c, &addr->a6); + } }
/** diff --git a/ndp.c b/ndp.c index 70b68aa..8914f31 100644 --- a/ndp.c +++ b/ndp.c @@ -226,6 +226,16 @@ static void ndp_na(const struct ctx *c, const struct in6_addr *dst, ndp_send(c, dst, &na, sizeof(na)); }
+/** + * ndp_send_unsolicited_na() - Send unsolicited NA + * @c: Execution context + * @addr: IPv6 address to advertise + */ +void ndp_send_unsolicited_na(const struct ctx *c, const struct in6_addr *addr) +{ + ndp_na(c, &in6addr_ll_all_nodes, addr); +} + /** * ndp_ra() - Send an NDP Router Advertisement (RA) message * @c: Execution context diff --git a/ndp.h b/ndp.h index 781ea86..320009c 100644 --- a/ndp.h +++ b/ndp.h @@ -12,5 +12,6 @@ int ndp(const struct ctx *c, const struct in6_addr *saddr, struct iov_tail *data); void ndp_timer(const struct ctx *c, const struct timespec *now); void ndp_send_init_req(const struct ctx *c); +void ndp_send_unsolicited_na(const struct ctx *c, const struct in6_addr *addr);
#endif /* NDP_H */ -- 2.50.1
-- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On 2025-09-23 22:47, David Gibson wrote:
On Tue, Sep 23, 2025 at 09:13:22PM -0400, Jon Maloy wrote:
The solution to bug https://bugs.passt.top/show_bug.cgi?id=120 requires the ability to translate from an IP address to its corresponding MAC address in cases where those are present in the ARP or NDP tables.
To keep track of the contents of these tables we add a netlink based neighbour subscription feature.
Signed-off-by: Jon Maloy
Reviewed-by: David Gibson The change to a subscription model is large enough that I think it warrants dropping pre-existing reviews.
--- v3: - Added an attribute contianing NDA_DST to sent message, so that we let the kernel do the filtering of the IP address and return only one entry. - Added interface index to the call signature. Since the only interface we know is the template interface, this limits the number of hosts that will be seen as 'network segment local' from a PASST viewpoint. v4: - Made loop independent of attribute order. - Ignoring L2 addresses which are not of size ETH_ALEN. v5: - Changed return value of new function, so caller can know if a MAC address really was found. v6: - Removed warning printout which had ended up in the wrong commit. v8: - Changed to neighbour event subscription model
netlink: arp/ndp table subscription --- epoll_type.h | 2 + netlink.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++ netlink.h | 4 ++ passt.c | 8 ++++ 4 files changed, 128 insertions(+)
diff --git a/epoll_type.h b/epoll_type.h index 12ac59b..a90ffb6 100644 --- a/epoll_type.h +++ b/epoll_type.h @@ -44,6 +44,8 @@ enum epoll_type { EPOLL_TYPE_REPAIR_LISTEN, /* TCP_REPAIR helper socket */ EPOLL_TYPE_REPAIR, + /* Netlink neighbour subscription socket */ + EPOLL_TYPE_NL_NEIGH,
EPOLL_NUM_TYPES, }; diff --git a/netlink.c b/netlink.c index c436780..1faf3da 100644 --- a/netlink.c +++ b/netlink.c @@ -53,6 +53,7 @@ int nl_sock = -1; int nl_sock_ns = -1; static int nl_seq = 1; +static int nl_sock_neigh = -1;
/** * nl_sock_init_do() - Set up netlink sockets in init or target namespace @@ -84,6 +85,119 @@ static int nl_sock_init_do(void *arg) return 0; }
+/** + * nl_neigh_subscr_init() - Open a NETLINK_ROUTE socket and subscribe to neighbor events + * + * Return: 0 on success, -1 on failure + */ +int nl_neigh_subscr_init(struct ctx *c) +{ + struct epoll_event ev = { 0 }; + union epoll_ref ref = { .type = EPOLL_TYPE_NL_NEIGH, .fd = 0 };
You overwrite the .fd field, so there's not need to include it in the initializer. (Also 0 is a bad placeholder, since 0 is a valid fd). ok
+ + struct sockaddr_nl addr = { + .nl_family = AF_NETLINK, + .nl_groups = RTMGRP_NEIGH, + }; + + if (nl_sock_neigh >= 0) + return 0; + + nl_sock_neigh = socket(AF_NETLINK, SOCK_RAW | SOCK_CLOEXEC, NETLINK_ROUTE); + if (nl_sock_neigh < 0) + return -1; + + if (bind(nl_sock_neigh, (struct sockaddr *)&addr, sizeof(addr)) < 0) { + close(nl_sock_neigh); + nl_sock_neigh = -1; + return -1; + } + + ref.fd = nl_sock_neigh; + ev.events = EPOLLIN;
You could set this in the initializer. ok
+ ev.data.u64 = ref.u64; + if (epoll_ctl(c->epollfd, EPOLL_CTL_ADD, nl_sock_neigh, &ev) == -1) { + close(nl_sock_neigh); + nl_sock_neigh = -1; + return -1; + } + + return 0; +} + +/** + * nl_neigh_subscr_handler() - Non-blocking drain of pending neighbor updates + * @c: Execution context + */ +void nl_neigh_subscr_handler(struct ctx *c) +{ + struct nlmsghdr *nh; + char buf[NLBUFSIZ]; + ssize_t n; + + if (nl_sock_neigh < 0) + return; + + for (;;) { + n = recv(nl_sock_neigh, buf, sizeof(buf), MSG_DONTWAIT); + if (n <= 0) + return;
EAGAIN correctly results in a silent return, but you probably want to report other errors and EOF (n == 0) since those are not expected.
Ok. But EOF is never returned from netlink. I can issue a warn_perror() for all other negative return values than EAGAIN.
+ + nh = (struct nlmsghdr *)buf; + for (; NLMSG_OK(nh, n); nh = NLMSG_NEXT(nh, n)) { + struct ndmsg *ndm = NLMSG_DATA(nh); + struct rtattr *rta = (struct rtattr *)(ndm + 1); + size_t na = NLMSG_PAYLOAD(nh, sizeof(*ndm)); + const uint8_t *lladdr = NULL; + const void *dst = NULL; + size_t lladdr_len = 0; + size_t dstlen = 0; + + if (nh->nlmsg_type == NLMSG_DONE || + nh->nlmsg_type == NLMSG_ERROR) + continue;
IIUC, NLMSG_ERROR would also be unexpected, so should probably be reported.
+ if (nh->nlmsg_type != RTM_NEWNEIGH && + nh->nlmsg_type != RTM_DELNEIGH) + continue;
Should we filter on ndm->ndm_ifindex for neighbours on the template interface only? I'm not sure.
Yes. I was wondering about this, because most events are state changes we aren't really interested in. My research indicates I can ignore all states except NUD_VALID (==up) and (INCOMPLETE | FAILED) (== down). This cannot be set in the subscription itself unless I want to involve eBPF (I don't), so the right place is to filter it here. That will save at least some cycles.
It seems like we probably should filter on .
+ for (; RTA_OK(rta, na); rta = RTA_NEXT(rta, na)) { + switch (rta->rta_type) { + case NDA_DST: + dst = RTA_DATA(rta); + dstlen = RTA_PAYLOAD(rta); + break; + case NDA_LLADDR: + lladdr = RTA_DATA(rta); + lladdr_len = RTA_PAYLOAD(rta); + break; + default: + break; + } + }
It seems like somewhere there ought to be something specifying the address type of both DST and LLADDR, but I'm not sure exactly where. We should check those, just in case some weirdo runs us on a host with IPX over Token Ring.
There is (ndm_family == AF_INET/6) for DST, and (lladdr_len == ETH_ALEN). The latter sounds like a good idea, while the fist sounds slightly paranoid. OK, we do have AF_TIPC when giving it a second thought ;-) ///jon
+ if (!dst) + continue; + + if (dstlen != sizeof(struct in_addr) && + dstlen != sizeof(struct in6_addr)) + continue; + + char abuf[INET6_ADDRSTRLEN]; + + if (dstlen == sizeof(struct in_addr)) + inet_ntop(AF_INET, dst, abuf, sizeof(abuf)); + else + inet_ntop(AF_INET6, dst, abuf, sizeof(abuf)); + + if (nh->nlmsg_type == RTM_NEWNEIGH) + debug("neigh: NEW %s lladdr_len=%zu", abuf, lladdr_len); + else + debug("neigh: DEL %s", abuf); + } + } +} + /** * nl_sock_init() - Call nl_sock_init_do(), won't return on failure * @c: Execution context diff --git a/netlink.h b/netlink.h index b51e99c..a7d3506 100644 --- a/netlink.h +++ b/netlink.h @@ -17,6 +17,8 @@ int nl_route_dup(int s_src, unsigned int ifi_src, int s_dst, unsigned int ifi_dst, sa_family_t af); int nl_addr_get(int s, unsigned int ifi, sa_family_t af, void *addr, int *prefix_len, void *addr_l); +bool nl_neigh_mac_get(int s, const union inany_addr *addr, int ifi, + unsigned char *mac); int nl_addr_set(int s, unsigned int ifi, sa_family_t af, const void *addr, int prefix_len); int nl_addr_get_ll(int s, unsigned int ifi, struct in6_addr *addr); @@ -28,5 +30,7 @@ int nl_link_set_mac(int s, unsigned int ifi, const void *mac); int nl_link_set_mtu(int s, unsigned int ifi, int mtu); int nl_link_set_flags(int s, unsigned int ifi, unsigned int set, unsigned int change); +int nl_neigh_subscr_init(struct ctx *c); +void nl_neigh_subscr_handler(struct ctx *c);
#endif /* NETLINK_H */ diff --git a/passt.c b/passt.c index 31fbb75..e20bbad 100644 --- a/passt.c +++ b/passt.c @@ -53,6 +53,7 @@ #include "vu_common.h" #include "migrate.h" #include "repair.h" +#include "netlink.h"
#define EPOLL_EVENTS 8
@@ -79,6 +80,7 @@ char *epoll_type_str[] = { [EPOLL_TYPE_VHOST_KICK] = "vhost-user kick socket", [EPOLL_TYPE_REPAIR_LISTEN] = "TCP_REPAIR helper listening socket", [EPOLL_TYPE_REPAIR] = "TCP_REPAIR helper socket", + [EPOLL_TYPE_NL_NEIGH] = "netlink neighbour subscription socket", }; static_assert(ARRAY_SIZE(epoll_type_str) == EPOLL_NUM_TYPES, "epoll_type_str[] doesn't match enum epoll_type"); @@ -322,6 +324,9 @@ int main(int argc, char **argv)
pcap_init(&c);
+ if (nl_neigh_subscr_init(&c) < 0) + warn("Failed to subscribe to RTMGRP_NEIGH"); + if (!c.foreground) { if ((devnull_fd = open("/dev/null", O_RDWR | O_CLOEXEC)) < 0) die_perror("Failed to open /dev/null"); @@ -414,6 +419,9 @@ loop: case EPOLL_TYPE_REPAIR: repair_handler(&c, eventmask); break; + case EPOLL_TYPE_NL_NEIGH: + nl_neigh_subscr_handler(&c); + break; default: /* Can't happen */ ASSERT(0); -- 2.50.1
On 2025-09-23 23:03, David Gibson wrote:
On Tue, Sep 23, 2025 at 09:13:23PM -0400, Jon Maloy wrote:
We add a cache table to keep track of the contents of the kernel ARP and NDP tables. The table is fed from the just introduced netlink based neigbour subscription function. The new table eliminates the need for explicit netlink calls to find a host's MAC address.
Signed-off-by: Jon Maloy
--- v5: - Moved to earlier in series to reduce rebase conflicts v6: - Sqashed the hash list commit and the FIFO/LRU queue commit - Removed hash lookup. We now only use linear lookup in a linked list - Eliminated dynamic memory allocation. - Ensured there is only one call to clock_gettime() - Using MAC_ZERO instead of the previously dedicated definitions v7: - NOW using MAC_ZERO where needed - I am still using linear back-off for empty cache entries. Even an incoming, flow-creating packet from a local host gives no guarantee that its MAC address is in the ARP table, so we must allow for a few new attempts at first possible occasions. Only after several failed lookups can we conclude that we probably never will succeed. Hence the back-off. - Fixed a bug that David inadvertently made me aware of: I only intended to set the initial expiry value to MAC_CACHE_RENEWAL when an ARP/NDP table lookup was successful. - Improved struct and function description comments. v8: - Total re-design of table, adapting to the new, subscription based way of updating it. v9: - Catering for MAC address change for an existing host. --- conf.c | 1 + fwd.c | 162 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ fwd.h | 7 +++ netlink.c | 15 +++-- 4 files changed, 180 insertions(+), 5 deletions(-)
diff --git a/conf.c b/conf.c index 66b9e63..cc491c3 100644 --- a/conf.c +++ b/conf.c @@ -2133,6 +2133,7 @@ void conf(struct ctx *c, int argc, char **argv) c->udp.fwd_out.mode = fwd_default;
fwd_scan_ports_init(c); + fwd_neigh_cache_init();
if (!c->quiet) conf_print(c); diff --git a/fwd.c b/fwd.c index 250cf56..491303d 100644 --- a/fwd.c +++ b/fwd.c @@ -32,6 +32,168 @@ static in_port_t fwd_ephemeral_min = (1 << 15) + (1 << 14); static in_port_t fwd_ephemeral_max = NUM_PORTS - 1;
#define PORT_RANGE_SYSCTL "/proc/sys/net/ipv4/ip_local_port_range" +#define MAC_CACHE_SIZE 1024
Nit: you use "mac cache" some places, "neigh cache" others.
Good. point, and something I have been thinking about myself. I think I will change to neigh_cache all over the line.
+ +/** + * mac_cache_entry - Entry in the ARP/NDP table cache + * @next: Next entry in slot or free list + * @addr: IP address of represented host + * @mac: MAC address of represented host + */ +struct mac_cache_entry { + struct mac_cache_entry *next;
Hash buckets might be overkill, but they're pretty easy and cheap, so whatever.
In theory there might be hundreds or even thousands of neighbors. Maybe not often, but this is cheap as you say.
+ union inany_addr addr; + uint8_t mac[ETH_ALEN]; +}; + +/** + * mac_cache_table - Cache of ARP/NDP table contents + * @entries: Entries to be plugged into the hash slots when allocated + * @slots: Hash table slots + * @free: Linked list of unused entries + */ +struct mac_cache_table { + struct mac_cache_entry entries[MAC_CACHE_SIZE]; + struct mac_cache_entry *slots[MAC_CACHE_SIZE];
There's no inherent reason these two tables need the same size (and indeed some reasons they might not want to have the same size).
I know, but I decided in the end to give them the same size. It might make sense to make the slot array larger than the entry array to reduce risk of collisions, but this risk and its consequences are really minimal in my view.
+ struct mac_cache_entry *free; +}; + +static struct mac_cache_table mac_cache; + +/** + * fwd_mac_cache_slot_idx() - Hash key to a number within the table range + * @c: Execution context + * @key: The key to be used for the hash + * + * Return: The resulting hash value + */ +static inline size_t fwd_mac_cache_slot_idx(const struct ctx *c, + const union inany_addr *key)
Maybe just neigh_hash_bucket()?
Yeah. Maybe.
+{ + struct siphash_state st = SIPHASH_INIT(c->hash_secret); + uint32_t i; + + inany_siphash_feed(&st, key); + i = siphash_final(&st, sizeof(*key), 0); + + return ((size_t)i) & (MAC_CACHE_SIZE - 1);
This subtly depends on MAC_CACHE_SIZE being a power of 2. If you use (... % MAC_CACHE_SIZE) it will work regardless, and the compiler will still optimize if it _is_ a power of 2.
Absolutely. I believe I had a comment about this at the #define line in earlier versions, but it seems to have disappeared. I will re-introduce it.
+} + +/** + * fwd_mac_cache_find() - Find a MAC cache table entry + * @c: Execution context + * @addr: Neighbour address to be used as key for the lookup + * + * Return: The found entry, if any. Otherwise NULL. + */ +static struct mac_cache_entry *fwd_mac_cache_find(const struct ctx *c, + const union inany_addr *addr) +{ + size_t idx = fwd_mac_cache_slot_idx(c, addr); + struct mac_cache_entry *e = mac_cache.slots[idx]; + + while (e && !inany_equals(&e->addr, addr)) + e = e->next; + + return e; +} + +/** + * fwd_mac_cache_alloc() - Allocate a mac cache table entry from the free list + * @c: Execution context + * @addr: Address used to determine insertion slot and store in entry + * @mac: The MAC address associated with the neighbour address + */ +void fwd_neigh_mac_cache_alloc(const struct ctx *c, + const union inany_addr *addr, uint8_t *mac)
This can update as well as allocating. Maybe fwd_neigh_cache_set()?
Ok
+{ + struct mac_cache_table *t = &mac_cache; + struct mac_cache_entry *e; + ssize_t idx; + + /* MAC address might change sometimes */ + e = fwd_mac_cache_find(c, addr); + if (e) { + memcpy(e->mac, mac, ETH_ALEN); + return; + } + + e = t->free; + if (!e) + return; + t->free = e->next; + + idx = fwd_mac_cache_slot_idx(c, addr); + e->next = t->slots[idx]; + t->slots[idx] = e; + + memcpy(&e->addr, addr, sizeof(*addr)); + memcpy(e->mac, mac, ETH_ALEN); +} + +/** + * fwd_mac_cache_free() - Remove an entry from a slot and add it to free list + * @c: Execution context + * @addr: Neighbour address used to find the slot for the entry + */ +void fwd_neigh_mac_cache_free(const struct ctx *c, const union inany_addr *addr) +{ + ssize_t idx = fwd_mac_cache_slot_idx(c, addr); + struct mac_cache_table *t = &mac_cache; + struct mac_cache_entry *e, **prev; + + prev = &t->slots[idx]; + e = t->slots[idx]; + while (e && !inany_equals(&e->addr, addr)) { + prev = &e->next; + e = e->next; + } + if (!e) + return; + + *prev = e->next; + e->next = t->free; + t->free = e; + memset(&e->addr, 0, sizeof(*addr)); + memset(e->mac, 0, ETH_ALEN); +} + +/** + * fwd_neigh_mac_get() - Lookup MAC address in the ARP/NDP cache table + * @c: Execution context + * @addr: Neighbour address used as lookup key + * @mac: Buffer for Ethernet MAC to return, found or default value. + * + * Return: true if real MAC found, false if not found or if failure + */ +bool fwd_neigh_mac_get(const struct ctx *c, const union inany_addr *addr, + uint8_t *mac) +{ + struct mac_cache_entry *e = fwd_mac_cache_find(c, addr); + + if (e) + memcpy(mac, e->mac, ETH_ALEN); + else + memcpy(mac, c->our_tap_mac, ETH_ALEN); + + return !!e; +} + +/** + * fwd_neigh_cache_init() - Initialize the neighbor ARP/NDP cache table + */ +void fwd_neigh_cache_init(void) +{ + struct mac_cache_table *t = &mac_cache; + struct mac_cache_entry *e; + + memset(t, 0, sizeof(*t)); + for (int i = 0; i < MAC_CACHE_SIZE; i++) { + e = &t->entries[i]; + e->next = t->free; + t->free = e; + } +}
/** fwd_probe_ephemeral() - Determine what ports this host considers ephemeral * diff --git a/fwd.h b/fwd.h index 65c7c96..a0e8fbc 100644 --- a/fwd.h +++ b/fwd.h @@ -56,5 +56,12 @@ uint8_t fwd_nat_from_splice(const struct ctx *c, uint8_t proto, const struct flowside *ini, struct flowside *tgt); uint8_t fwd_nat_from_host(const struct ctx *c, uint8_t proto, const struct flowside *ini, struct flowside *tgt); +void fwd_neigh_mac_cache_alloc(const struct ctx *c, + const union inany_addr *addr, uint8_t *mac); +void fwd_neigh_mac_cache_free(const struct ctx *c, + const union inany_addr *addr); +bool fwd_neigh_mac_get(const struct ctx *c, const union inany_addr *addr, + uint8_t *mac); +void fwd_neigh_cache_init(void);
#endif /* FWD_H */ diff --git a/netlink.c b/netlink.c index 1faf3da..1e1ec43 100644 --- a/netlink.c +++ b/netlink.c @@ -131,6 +131,8 @@ int nl_neigh_subscr_init(struct ctx *c) */ void nl_neigh_subscr_handler(struct ctx *c) { + union inany_addr addr; + uint8_t mac[ETH_ALEN]; struct nlmsghdr *nh; char buf[NLBUFSIZ]; ssize_t n; @@ -183,17 +185,20 @@ void nl_neigh_subscr_handler(struct ctx *c) dstlen != sizeof(struct in6_addr)) continue;
- char abuf[INET6_ADDRSTRLEN]; + if (!lladdr || lladdr_len != ETH_ALEN) + continue; + + memcpy(mac, lladdr, ETH_ALEN);
if (dstlen == sizeof(struct in_addr)) - inet_ntop(AF_INET, dst, abuf, sizeof(abuf)); + addr = inany_from_v4(*(struct in_addr *) dst); else - inet_ntop(AF_INET6, dst, abuf, sizeof(abuf)); + addr.a6 = *(struct in6_addr *) dst;
if (nh->nlmsg_type == RTM_NEWNEIGH) - debug("neigh: NEW %s lladdr_len=%zu", abuf, lladdr_len); + fwd_neigh_mac_cache_alloc(c, &addr, mac); else - debug("neigh: DEL %s", abuf); + fwd_neigh_mac_cache_free(c, &addr);
I think the debug() messages could still be useful. They could move into the functions of course, and might want to be demoted to trace().
Yes. Good point. ///jon
On 2025-09-23 23:22, David Gibson wrote:
On Tue, Sep 23, 2025 at 09:13:30PM -0400, Jon Maloy wrote:
Gratuitious ARP and unsolicitated NA should be handled with caution because of the risk of malignant users emitting them to disturb network communication.
There is however one case we where we know it is legitimate and safe for us to send out such messages: The one time we switch from using ctx->own_tap_mac to a MAC address received via the recently added neigbour subscription function. Later changes to the MAC address of a host in an existing entry cannot be fully trusted, so we abstain from doing it in such cases.
So, I think you're right that the gratuitous ARP is safe in this case.
But it concerns me that (other that some edge cases) we're sending data to the guest under own_tap_mac before we get the real MAC. At the point we send data from a flow to the guest, I would have expected to already have an entry in the host neighbour table (because by definition the host is talking to the peer), therefore in our cache, by the subscriber.
I'm wondering if it could be as simple as both the neighbour update and the actual data coming in the same epoll batch, and we could avoid the temporary use of own_tap_mac by prioritising processing of the neighbour events.
I experimented a bit with this. My test program is a simple UDP client-server pair, exchanging first 3 UDP messages client->server, followed by 3 messages server->client. First, I changed the main() loop a bit, so that netlink events are handled before all other events, if any. (Basically, I added an extra loop before the main loop, only handling netlink events, before moving on to the main loop (where netlink events had been excluded.) This should secure absolute priority of netlink events before any other events. As you will see below, this made no difference to the scenarios I describe. 1: When starting the container, I notice that there is no subscription event in PASTA, even though I can see the entry for the remote host is present in the host's ARP table. There is never any event coming up even if I wait for 10+ minutes. 2: The first UDP is attempted sent from the guest. An ARP request is sent to PASTA, and responded to with the 9a:9a: address. 3: The UDP, and two more UDPs, are sent via PASTA to the remote host. Those are responded to and sent back to the guest. 4: I now receive a neigbour event, and can update my cache, but since there is still no new ARP request from the guest, even if I wait for many minutes, he continues in the belief the old address is confirmed. 5: If I run the same test again after a few minutes, the guest *does* send out an ARP request a few seconds after the message exchange, and is now updated with the correct address. - If i run this sequence in the opposite direction everything seems to work ok, at least if the ARP entry is already present on the local host. - When I delete that ARP entry before running the sequence, a neigbour event shows up after some seconds, but it can take up to a minute, at least. If I run my sequence from the remote host before that happens, there will be an ARP request from the guest (for the response UDPs), responded to with the default tap mac, and it will remain like that for a long time, since the guest considers the mac address confirmed. It doesn't help much that a neigbour event shows up some seconds after the exchange. In brief, the guest *will* be updated eventually, but depending on luck and timing it may take a long time, at least several minutes. My gratuitous ARPs/ non-solicitated NAs doesn't completely solve this issue, but it significantly reduces the potential time gap before the guest gets properly updated.
When sending this type of messages, we notice that the guest accepts the update, but also asks for a confirmation in the form of a regular ARP/NS request. This is responded to with the new value, and we have exactly the effect we wanted.
This commit adds this functionality.
Signed-off-by: Jon Maloy
--- arp.c | 39 +++++++++++++++++++++++++++++++++++++++ arp.h | 2 ++ fwd.c | 11 +++++++++++ ndp.c | 10 ++++++++++ ndp.h | 1 + 5 files changed, 63 insertions(+) diff --git a/arp.c b/arp.c index 442faff..259f736 100644 --- a/arp.c +++ b/arp.c @@ -151,3 +151,42 @@ void arp_send_init_req(const struct ctx *c) debug("Sending initial ARP request for guest MAC address"); tap_send_single(c, &req, sizeof(req)); } + +/** + * arp_send_gratuitous() - Send a gratuitous ARP announcement for an IPv4 host + * @c: Execution context + * @ip: IPv4 address we announce as owned by @mac + * @mac: MAC address to advertise for @ip + */ +void arp_send_gratuitous(const struct ctx *c, struct in_addr ip, + const unsigned char *mac) +{ + char ip_str[INET_ADDRSTRLEN]; + struct { + struct ethhdr eh; + struct arphdr ah; + struct arpmsg am; + } __attribute__((__packed__)) req;
'req' is not a great name, since this is an ARP response, not a request (but see below).
+ /* Ethernet header */ + req.eh.h_proto = htons(ETH_P_ARP); + memcpy(req.eh.h_dest, MAC_BROADCAST, sizeof(req.eh.h_dest)); + memcpy(req.eh.h_source, c->our_tap_mac, sizeof(req.eh.h_source)); + + /* ARP header */ + req.ah.ar_op = htons(ARPOP_REPLY); + req.ah.ar_hrd = htons(ARPHRD_ETHER); + req.ah.ar_pro = htons(ETH_P_IP); + req.ah.ar_hln = ETH_ALEN; + req.ah.ar_pln = 4; + + /* ARP message */ + memcpy(req.am.sha, mac, sizeof(req.am.sha)); + memcpy(req.am.sip, &ip, sizeof(req.am.sip)); + memcpy(req.am.tha, MAC_BROADCAST, sizeof(req.am.tha)); + memcpy(req.am.tip, &ip, sizeof(req.am.tip));
So, I was trying to check if it made sense to use the same IP for both source and target here, and came across https://www.rfc-editor.org/rfc/rfc5227#section-3
Which suggests we should (counter intuitively) be using ARP requests, not ARP replies for announcements.
Instead of gratuitous ARP, you mean? I can try it. ///jon
+ inet_ntop(AF_INET, &ip, ip_str, sizeof(ip_str)); + debug("Sending gratuitous ARP for %s", ip_str); + tap_send_single(c, &req, sizeof(req)); +} diff --git a/arp.h b/arp.h index d5ad0e1..b0dbb56 100644 --- a/arp.h +++ b/arp.h @@ -22,5 +22,7 @@ struct arpmsg {
int arp(const struct ctx *c, struct iov_tail *data); void arp_send_init_req(const struct ctx *c); +void arp_send_gratuitous(const struct ctx *c, struct in_addr ip, + const unsigned char *mac);
#endif /* ARP_H */ diff --git a/fwd.c b/fwd.c index c6348ab..879a351 100644 --- a/fwd.c +++ b/fwd.c @@ -26,6 +26,8 @@ #include "passt.h" #include "lineread.h" #include "flow_table.h" +#include "arp.h" +#include "ndp.h"
/* Empheral port range: values from RFC 6335 */ static in_port_t fwd_ephemeral_min = (1 << 15) + (1 << 14); @@ -129,6 +131,15 @@ void fwd_neigh_mac_cache_alloc(const struct ctx *c,
memcpy(&e->addr, addr, sizeof(*addr)); memcpy(e->mac, mac, ETH_ALEN); + + /* Send gratuitous ARP / unsolicited NA for the new mapping */
AFAICT this doesn't actually implement what the commit message describes - it seems to always send an ARP/NA when the neighbour table is updated.
+ if (inany_v4(addr)) { + struct in_addr ip4 = *inany_v4(addr); + + arp_send_gratuitous(c, ip4, e->mac); + } else { + ndp_send_unsolicited_na(c, &addr->a6); + } }
/** diff --git a/ndp.c b/ndp.c index 70b68aa..8914f31 100644 --- a/ndp.c +++ b/ndp.c @@ -226,6 +226,16 @@ static void ndp_na(const struct ctx *c, const struct in6_addr *dst, ndp_send(c, dst, &na, sizeof(na)); }
+/** + * ndp_send_unsolicited_na() - Send unsolicited NA + * @c: Execution context + * @addr: IPv6 address to advertise + */ +void ndp_send_unsolicited_na(const struct ctx *c, const struct in6_addr *addr) +{ + ndp_na(c, &in6addr_ll_all_nodes, addr); +} + /** * ndp_ra() - Send an NDP Router Advertisement (RA) message * @c: Execution context diff --git a/ndp.h b/ndp.h index 781ea86..320009c 100644 --- a/ndp.h +++ b/ndp.h @@ -12,5 +12,6 @@ int ndp(const struct ctx *c, const struct in6_addr *saddr, struct iov_tail *data); void ndp_timer(const struct ctx *c, const struct timespec *now); void ndp_send_init_req(const struct ctx *c); +void ndp_send_unsolicited_na(const struct ctx *c, const struct in6_addr *addr);
#endif /* NDP_H */ -- 2.50.1
On 2025-09-24 18:18, Jon Maloy wrote:
On 2025-09-23 23:22, David Gibson wrote:
On Tue, Sep 23, 2025 at 09:13:30PM -0400, Jon Maloy wrote:
[...]
--- a/fwd.c +++ b/fwd.c @@ -26,6 +26,8 @@ #include "passt.h" #include "lineread.h" #include "flow_table.h" +#include "arp.h" +#include "ndp.h" /* Empheral port range: values from RFC 6335 */ static in_port_t fwd_ephemeral_min = (1 << 15) + (1 << 14); @@ -129,6 +131,15 @@ void fwd_neigh_mac_cache_alloc(const struct ctx *c, memcpy(&e->addr, addr, sizeof(*addr)); memcpy(e->mac, mac, ETH_ALEN); + + /* Send gratuitous ARP / unsolicited NA for the new mapping */
AFAICT this doesn't actually implement what the commit message describes - it seems to always send an ARP/NA when the neighbour table is updated.
No. Check the code again. ///jon
+ if (inany_v4(addr)) { + struct in_addr ip4 = *inany_v4(addr);
On Wed, Sep 24, 2025 at 06:18:52PM -0400, Jon Maloy wrote:
On 2025-09-23 23:22, David Gibson wrote:
On Tue, Sep 23, 2025 at 09:13:30PM -0400, Jon Maloy wrote:
Gratuitious ARP and unsolicitated NA should be handled with caution because of the risk of malignant users emitting them to disturb network communication.
There is however one case we where we know it is legitimate and safe for us to send out such messages: The one time we switch from using ctx->own_tap_mac to a MAC address received via the recently added neigbour subscription function. Later changes to the MAC address of a host in an existing entry cannot be fully trusted, so we abstain from doing it in such cases.
So, I think you're right that the gratuitous ARP is safe in this case.
But it concerns me that (other that some edge cases) we're sending data to the guest under own_tap_mac before we get the real MAC. At the point we send data from a flow to the guest, I would have expected to already have an entry in the host neighbour table (because by definition the host is talking to the peer), therefore in our cache, by the subscriber.
I'm wondering if it could be as simple as both the neighbour update and the actual data coming in the same epoll batch, and we could avoid the temporary use of own_tap_mac by prioritising processing of the neighbour events.
I experimented a bit with this. My test program is a simple UDP client-server pair, exchanging first 3 UDP messages client->server, followed by 3 messages server->client.
With the client on the guest, and server outside? How is the outside machine arranged - is it a physically separate host? A bridged VM or container on the same host? Something else?
First, I changed the main() loop a bit, so that netlink events are handled before all other events, if any. (Basically, I added an extra loop before the main loop, only handling netlink events, before moving on to the main loop (where netlink events had been excluded.) This should secure absolute priority of netlink events before any other events. As you will see below, this made no difference to the scenarios I describe.
Drat.
1: When starting the container, I notice that there is no subscription event in PASTA, even though I can see the entry for the remote host is present in the host's ARP table. There is never any event coming up even if I wait for 10+ minutes.
Huh.... do we need to do something to ensure we get events for existing entries in the host ARP table, not just ones that are added or updated after we're running?
2: The first UDP is attempted sent from the guest. An ARP request is sent to PASTA, and responded to with the 9a:9a: address.
Maybe we still need to explicitly ask for an ARP resolution when the guest ARPs.
3: The UDP, and two more UDPs, are sent via PASTA to the remote host. Those are responded to and sent back to the guest. 4: I now receive a neigbour event, and can update my cache, but since there is still no new ARP request from the guest, even if I wait for many minutes, he continues in the belief the old address is confirmed. 5: If I run the same test again after a few minutes, the guest *does* send out an ARP request a few seconds after the message exchange, and is now updated with the correct address.
- If i run this sequence in the opposite direction everything seems to work ok, at least if the ARP entry is already present on the local host.
- When I delete that ARP entry before running the sequence,
Delete it from the host ARP table, you mean?
a neigbour event shows up after some seconds, but it can take up to a minute, at least.
Oof. I guess some delay is inevitable, but that's way longer than I would have expected.
If I run my sequence from the remote host before that happens, there will be an ARP request from the guest (for the response UDPs), responded to with the default tap mac, and it will remain like that for a long time, since the guest considers the mac address confirmed. It doesn't help much that a neigbour event shows up some seconds after the exchange.
In brief, the guest *will* be updated eventually, but depending on luck and timing it may take a long time, at least several minutes. My gratuitous ARPs/ non-solicitated NAs doesn't completely solve this issue, but it significantly reduces the potential time gap before the guest gets properly updated.
When sending this type of messages, we notice that the guest accepts the update, but also asks for a confirmation in the form of a regular ARP/NS request. This is responded to with the new value, and we have exactly the effect we wanted.
This commit adds this functionality.
Signed-off-by: Jon Maloy
--- arp.c | 39 +++++++++++++++++++++++++++++++++++++++ arp.h | 2 ++ fwd.c | 11 +++++++++++ ndp.c | 10 ++++++++++ ndp.h | 1 + 5 files changed, 63 insertions(+) diff --git a/arp.c b/arp.c index 442faff..259f736 100644 --- a/arp.c +++ b/arp.c @@ -151,3 +151,42 @@ void arp_send_init_req(const struct ctx *c) debug("Sending initial ARP request for guest MAC address"); tap_send_single(c, &req, sizeof(req)); } + +/** + * arp_send_gratuitous() - Send a gratuitous ARP announcement for an IPv4 host + * @c: Execution context + * @ip: IPv4 address we announce as owned by @mac + * @mac: MAC address to advertise for @ip + */ +void arp_send_gratuitous(const struct ctx *c, struct in_addr ip, + const unsigned char *mac) +{ + char ip_str[INET_ADDRSTRLEN]; + struct { + struct ethhdr eh; + struct arphdr ah; + struct arpmsg am; + } __attribute__((__packed__)) req;
'req' is not a great name, since this is an ARP response, not a request (but see below).
+ /* Ethernet header */ + req.eh.h_proto = htons(ETH_P_ARP); + memcpy(req.eh.h_dest, MAC_BROADCAST, sizeof(req.eh.h_dest)); + memcpy(req.eh.h_source, c->our_tap_mac, sizeof(req.eh.h_source)); + + /* ARP header */ + req.ah.ar_op = htons(ARPOP_REPLY); + req.ah.ar_hrd = htons(ARPHRD_ETHER); + req.ah.ar_pro = htons(ETH_P_IP); + req.ah.ar_hln = ETH_ALEN; + req.ah.ar_pln = 4; + + /* ARP message */ + memcpy(req.am.sha, mac, sizeof(req.am.sha)); + memcpy(req.am.sip, &ip, sizeof(req.am.sip)); + memcpy(req.am.tha, MAC_BROADCAST, sizeof(req.am.tha)); + memcpy(req.am.tip, &ip, sizeof(req.am.tip));
So, I was trying to check if it made sense to use the same IP for both source and target here, and came across https://www.rfc-editor.org/rfc/rfc5227#section-3
Which suggests we should (counter intuitively) be using ARP requests, not ARP replies for announcements.
Instead of gratuitous ARP, you mean? I can try it.
It suggests that what's traditionally meant by "gratuitous ARP" is actually ARP requests, not responses as you might expect. There's some detailed reasoning there, I'd give it a read. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On Wed, Sep 24, 2025 at 07:32:43PM -0400, Jon Maloy wrote:
On 2025-09-24 18:18, Jon Maloy wrote:
On 2025-09-23 23:22, David Gibson wrote:
On Tue, Sep 23, 2025 at 09:13:30PM -0400, Jon Maloy wrote:
[...]
--- a/fwd.c +++ b/fwd.c @@ -26,6 +26,8 @@ #include "passt.h" #include "lineread.h" #include "flow_table.h" +#include "arp.h" +#include "ndp.h" /* Empheral port range: values from RFC 6335 */ static in_port_t fwd_ephemeral_min = (1 << 15) + (1 << 14); @@ -129,6 +131,15 @@ void fwd_neigh_mac_cache_alloc(const struct ctx *c, memcpy(&e->addr, addr, sizeof(*addr)); memcpy(e->mac, mac, ETH_ALEN); + + /* Send gratuitous ARP / unsolicited NA for the new mapping */
AFAICT this doesn't actually implement what the commit message describes - it seems to always send an ARP/NA when the neighbour table is updated.
No. Check the code again.
Still not seeing it, I'm going to need a more specific pointer to what I've missed. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On Wed, Sep 24, 2025 at 02:40:33PM -0400, Jon Maloy wrote:
On 2025-09-23 22:47, David Gibson wrote:
On Tue, Sep 23, 2025 at 09:13:22PM -0400, Jon Maloy wrote:
The solution to bug https://bugs.passt.top/show_bug.cgi?id=120 requires the ability to translate from an IP address to its corresponding MAC address in cases where those are present in the ARP or NDP tables.
To keep track of the contents of these tables we add a netlink based neighbour subscription feature.
Signed-off-by: Jon Maloy
Reviewed-by: David Gibson The change to a subscription model is large enough that I think it warrants dropping pre-existing reviews.
--- v3: - Added an attribute contianing NDA_DST to sent message, so that we let the kernel do the filtering of the IP address and return only one entry. - Added interface index to the call signature. Since the only interface we know is the template interface, this limits the number of hosts that will be seen as 'network segment local' from a PASST viewpoint. v4: - Made loop independent of attribute order. - Ignoring L2 addresses which are not of size ETH_ALEN. v5: - Changed return value of new function, so caller can know if a MAC address really was found. v6: - Removed warning printout which had ended up in the wrong commit. v8: - Changed to neighbour event subscription model
netlink: arp/ndp table subscription --- epoll_type.h | 2 + netlink.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++ netlink.h | 4 ++ passt.c | 8 ++++ 4 files changed, 128 insertions(+)
diff --git a/epoll_type.h b/epoll_type.h index 12ac59b..a90ffb6 100644 --- a/epoll_type.h +++ b/epoll_type.h @@ -44,6 +44,8 @@ enum epoll_type { EPOLL_TYPE_REPAIR_LISTEN, /* TCP_REPAIR helper socket */ EPOLL_TYPE_REPAIR, + /* Netlink neighbour subscription socket */ + EPOLL_TYPE_NL_NEIGH, EPOLL_NUM_TYPES, }; diff --git a/netlink.c b/netlink.c index c436780..1faf3da 100644 --- a/netlink.c +++ b/netlink.c @@ -53,6 +53,7 @@ int nl_sock = -1; int nl_sock_ns = -1; static int nl_seq = 1; +static int nl_sock_neigh = -1; /** * nl_sock_init_do() - Set up netlink sockets in init or target namespace @@ -84,6 +85,119 @@ static int nl_sock_init_do(void *arg) return 0; } +/** + * nl_neigh_subscr_init() - Open a NETLINK_ROUTE socket and subscribe to neighbor events + * + * Return: 0 on success, -1 on failure + */ +int nl_neigh_subscr_init(struct ctx *c) +{ + struct epoll_event ev = { 0 }; + union epoll_ref ref = { .type = EPOLL_TYPE_NL_NEIGH, .fd = 0 };
You overwrite the .fd field, so there's not need to include it in the initializer. (Also 0 is a bad placeholder, since 0 is a valid fd). ok
+ + struct sockaddr_nl addr = { + .nl_family = AF_NETLINK, + .nl_groups = RTMGRP_NEIGH, + }; + + if (nl_sock_neigh >= 0) + return 0; + + nl_sock_neigh = socket(AF_NETLINK, SOCK_RAW | SOCK_CLOEXEC, NETLINK_ROUTE); + if (nl_sock_neigh < 0) + return -1; + + if (bind(nl_sock_neigh, (struct sockaddr *)&addr, sizeof(addr)) < 0) { + close(nl_sock_neigh); + nl_sock_neigh = -1; + return -1; + } + + ref.fd = nl_sock_neigh; + ev.events = EPOLLIN;
You could set this in the initializer. ok
+ ev.data.u64 = ref.u64; + if (epoll_ctl(c->epollfd, EPOLL_CTL_ADD, nl_sock_neigh, &ev) == -1) { + close(nl_sock_neigh); + nl_sock_neigh = -1; + return -1; + } + + return 0; +} + +/** + * nl_neigh_subscr_handler() - Non-blocking drain of pending neighbor updates + * @c: Execution context + */ +void nl_neigh_subscr_handler(struct ctx *c) +{ + struct nlmsghdr *nh; + char buf[NLBUFSIZ]; + ssize_t n; + + if (nl_sock_neigh < 0) + return; + + for (;;) { + n = recv(nl_sock_neigh, buf, sizeof(buf), MSG_DONTWAIT); + if (n <= 0) + return;
EAGAIN correctly results in a silent return, but you probably want to report other errors and EOF (n == 0) since those are not expected.
Ok. But EOF is never returned from netlink.
Right. Which is exactly why it's important to know if it somehow happens (it could mean, for example that we somehow clobbered our socket fd).
I can issue a warn_perror() for all other negative return values than EAGAIN.
+ + nh = (struct nlmsghdr *)buf; + for (; NLMSG_OK(nh, n); nh = NLMSG_NEXT(nh, n)) { + struct ndmsg *ndm = NLMSG_DATA(nh); + struct rtattr *rta = (struct rtattr *)(ndm + 1); + size_t na = NLMSG_PAYLOAD(nh, sizeof(*ndm)); + const uint8_t *lladdr = NULL; + const void *dst = NULL; + size_t lladdr_len = 0; + size_t dstlen = 0; + + if (nh->nlmsg_type == NLMSG_DONE || + nh->nlmsg_type == NLMSG_ERROR) + continue;
IIUC, NLMSG_ERROR would also be unexpected, so should probably be reported.
+ if (nh->nlmsg_type != RTM_NEWNEIGH && + nh->nlmsg_type != RTM_DELNEIGH) + continue;
Should we filter on ndm->ndm_ifindex for neighbours on the template interface only? I'm not sure.
Yes. I was wondering about this, because most events are state changes we aren't really interested in. My research indicates I can ignore all states except NUD_VALID (==up) and (INCOMPLETE | FAILED) (== down). This cannot be set in the subscription itself unless I want to involve eBPF (I don't), so the right place is to filter it here. That will save at least some cycles.
Ok, good.
It seems like we probably should filter on .
+ for (; RTA_OK(rta, na); rta = RTA_NEXT(rta, na)) { + switch (rta->rta_type) { + case NDA_DST: + dst = RTA_DATA(rta); + dstlen = RTA_PAYLOAD(rta); + break; + case NDA_LLADDR: + lladdr = RTA_DATA(rta); + lladdr_len = RTA_PAYLOAD(rta); + break; + default: + break; + } + }
It seems like somewhere there ought to be something specifying the address type of both DST and LLADDR, but I'm not sure exactly where. We should check those, just in case some weirdo runs us on a host with IPX over Token Ring.
There is (ndm_family == AF_INET/6) for DST, and (lladdr_len == ETH_ALEN). The latter sounds like a good idea, while the fist sounds slightly paranoid. OK, we do have AF_TIPC when giving it a second thought ;-)
Right. I really like to actually check assumptions like this. Checking lladdr_len isn't technically correct, since in theory it could be a link that has 6-byte addresses that aren't Ethernet MACs. Or even, theoretically, a link with variable length addresses, and this one just happens to have 6 bytes. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On 2025-09-25 02:38, David Gibson wrote:
On Wed, Sep 24, 2025 at 07:32:43PM -0400, Jon Maloy wrote:
On 2025-09-24 18:18, Jon Maloy wrote:
On 2025-09-23 23:22, David Gibson wrote:
On Tue, Sep 23, 2025 at 09:13:30PM -0400, Jon Maloy wrote:
[...]
--- a/fwd.c +++ b/fwd.c @@ -26,6 +26,8 @@ #include "passt.h" #include "lineread.h" #include "flow_table.h" +#include "arp.h" +#include "ndp.h" /* Empheral port range: values from RFC 6335 */ static in_port_t fwd_ephemeral_min = (1 << 15) + (1 << 14); @@ -129,6 +131,15 @@ void fwd_neigh_mac_cache_alloc(const struct ctx *c, memcpy(&e->addr, addr, sizeof(*addr)); memcpy(e->mac, mac, ETH_ALEN); + + /* Send gratuitous ARP / unsolicited NA for the new mapping */
AFAICT this doesn't actually implement what the commit message describes - it seems to always send an ARP/NA when the neighbour table is updated.
No. Check the code again.
Still not seeing it, I'm going to need a more specific pointer to what I've missed.
Look in fwd_neigh_mac_cache_alloc(). If the entry already exists, the function updates the mac address just to be on the safe side, but then returns without sending any ARP/NA. Or do I misunderstand your question? /jon
On 2025-09-25 02:36, David Gibson wrote:
On Wed, Sep 24, 2025 at 06:18:52PM -0400, Jon Maloy wrote:
[...]
I experimented a bit with this. My test program is a simple UDP client-server pair, exchanging first 3 UDP messages client->server, followed by 3 messages server->client.
With the client on the guest, and server outside? How is the outside machine arranged - is it a physically separate host? A bridged VM or container on the same host? Something else?
It is a physically separate host.
First, I changed the main() loop a bit, so that netlink events are handled before all other events, if any. (Basically, I added an extra loop before the main loop, only handling netlink events, before moving on to the main loop (where netlink events had been excluded.) This should secure absolute priority of netlink events before any other events. As you will see below, this made no difference to the scenarios I describe.
Drat.
1: When starting the container, I notice that there is no subscription event in PASTA, even though I can see the entry for the remote host is present in the host's ARP table. There is never any event coming up even if I wait for 10+ minutes.
Huh.... do we need to do something to ensure we get events for existing entries in the host ARP table, not just ones that are added or updated after we're running?
It doesn't seem to be possible, but even if it were it wouldn't help us much if the entry isn't here, which is also a problematic case. See below.
2: The first UDP is attempted sent from the guest. An ARP request is sent to PASTA, and responded to with the 9a:9a: address.
Maybe we still need to explicitly ask for an ARP resolution when the guest ARPs.
I think so. If we limit this to ARP and NDP, this should be unproblematic.
3: The UDP, and two more UDPs, are sent via PASTA to the remote host. Those are responded to and sent back to the guest. 4: I now receive a neigbour event, and can update my cache, but since there is still no new ARP request from the guest, even if I wait for many minutes, he continues in the belief the old address is confirmed. 5: If I run the same test again after a few minutes, the guest *does* send out an ARP request a few seconds after the message exchange, and is now updated with the correct address.
- If i run this sequence in the opposite direction everything seems to work ok, at least if the ARP entry is already present on the local host.
- When I delete that ARP entry before running the sequence,
Delete it from the host ARP table, you mean?
Yes.
a neigbour event shows up after some seconds, but it can take up to a minute, at least.
Oof. I guess some delay is inevitable, but that's way longer than I would have expected.
If I run my sequence from the remote host before that happens, there will be an ARP request from the guest (for the response UDPs), responded to with the default tap mac, and it will remain like that for a long time, since the guest considers the mac address confirmed. It doesn't help much that a neigbour event shows up some seconds after the exchange.
In brief, the guest *will* be updated eventually, but depending on luck and timing it may take a long time, at least several minutes.
[...]
+ memcpy(req.am.tha, MAC_BROADCAST, sizeof(req.am.tha)); + memcpy(req.am.tip, &ip, sizeof(req.am.tip));
So, I was trying to check if it made sense to use the same IP for both source and target here, and came across https://www.rfc-editor.org/rfc/rfc5227#section-3
Which suggests we should (counter intuitively) be using ARP requests, not ARP replies for announcements.
Instead of gratuitous ARP, you mean? I can try it.
It suggests that what's traditionally meant by "gratuitous ARP" is actually ARP requests, not responses as you might expect. There's some detailed reasoning there, I'd give it a read.
So will I. It sounds interesting. ///jon
On Thu, Sep 25, 2025 at 08:48:51AM -0400, Jon Maloy wrote:
On 2025-09-25 02:38, David Gibson wrote:
On Wed, Sep 24, 2025 at 07:32:43PM -0400, Jon Maloy wrote:
On 2025-09-24 18:18, Jon Maloy wrote:
On 2025-09-23 23:22, David Gibson wrote:
On Tue, Sep 23, 2025 at 09:13:30PM -0400, Jon Maloy wrote:
[...]
--- a/fwd.c +++ b/fwd.c @@ -26,6 +26,8 @@ #include "passt.h" #include "lineread.h" #include "flow_table.h" +#include "arp.h" +#include "ndp.h" /* Empheral port range: values from RFC 6335 */ static in_port_t fwd_ephemeral_min = (1 << 15) + (1 << 14); @@ -129,6 +131,15 @@ void fwd_neigh_mac_cache_alloc(const struct ctx *c, memcpy(&e->addr, addr, sizeof(*addr)); memcpy(e->mac, mac, ETH_ALEN); + + /* Send gratuitous ARP / unsolicited NA for the new mapping */
AFAICT this doesn't actually implement what the commit message describes - it seems to always send an ARP/NA when the neighbour table is updated.
No. Check the code again.
Still not seeing it, I'm going to need a more specific pointer to what I've missed.
Look in fwd_neigh_mac_cache_alloc(). If the entry already exists, the function updates the mac address just to be on the safe side, but then returns without sending any ARP/NA.
Uh... no, no it doesn't. I applied all the patches on a branch and here's what I see in fwd_neigh_mac_cache_alloc(): memcpy(&e->addr, addr, sizeof(*addr)); memcpy(e->mac, mac, ETH_ALEN); /* Send gratuitous ARP / unsolicited NA for the new mapping */ if (inany_v4(addr)) { struct in_addr ip4 = *inany_v4(addr); arp_send_gratuitous(c, ip4, e->mac); } else { ndp_send_unsolicited_na(c, &addr->a6); } If it updates, it ARPs. Do you have something in your tree that didn't make it into the published patches? -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On Thu, Sep 25, 2025 at 09:14:42AM -0400, Jon Maloy wrote:
On 2025-09-25 02:36, David Gibson wrote:
On Wed, Sep 24, 2025 at 06:18:52PM -0400, Jon Maloy wrote:
[...]
I experimented a bit with this. My test program is a simple UDP client-server pair, exchanging first 3 UDP messages client->server, followed by 3 messages server->client.
With the client on the guest, and server outside? How is the outside machine arranged - is it a physically separate host? A bridged VM or container on the same host? Something else?
It is a physically separate host.
First, I changed the main() loop a bit, so that netlink events are handled before all other events, if any. (Basically, I added an extra loop before the main loop, only handling netlink events, before moving on to the main loop (where netlink events had been excluded.) This should secure absolute priority of netlink events before any other events. As you will see below, this made no difference to the scenarios I describe.
Drat.
1: When starting the container, I notice that there is no subscription event in PASTA, even though I can see the entry for the remote host is present in the host's ARP table. There is never any event coming up even if I wait for 10+ minutes.
Huh.... do we need to do something to ensure we get events for existing entries in the host ARP table, not just ones that are added or updated after we're running?
It doesn't seem to be possible,
Can we do an RTM_GETNEIGH, with no address specified? It's something like that we do to get all our links and addresses in other places.
but even if it were it wouldn't help us much if the entry isn't here, which is also a problematic case. See below.
2: The first UDP is attempted sent from the guest. An ARP request is sent to PASTA, and responded to with the 9a:9a: address.
Maybe we still need to explicitly ask for an ARP resolution when the guest ARPs.
I think so. If we limit this to ARP and NDP, this should be unproblematic.
I just realised this is harder than I thought, though. At least if we want to get the right answer for the first guest ARP. It's not just a netlink request, we'd need to wait for the host to ARP, which means timeouts, and state we need to track, and ... -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On 2025-09-25 20:47, David Gibson wrote:
On Thu, Sep 25, 2025 at 08:48:51AM -0400, Jon Maloy wrote:
On 2025-09-25 02:38, David Gibson wrote:
On Wed, Sep 24, 2025 at 07:32:43PM -0400, Jon Maloy wrote:
On 2025-09-24 18:18, Jon Maloy wrote:
On 2025-09-23 23:22, David Gibson wrote:
On Tue, Sep 23, 2025 at 09:13:30PM -0400, Jon Maloy wrote:
[...]
> --- a/fwd.c > +++ b/fwd.c > @@ -26,6 +26,8 @@ > #include "passt.h" > #include "lineread.h" > #include "flow_table.h" > +#include "arp.h" > +#include "ndp.h" > /* Empheral port range: values from RFC 6335 */ > static in_port_t fwd_ephemeral_min = (1 << 15) + (1 << 14); > @@ -129,6 +131,15 @@ void fwd_neigh_mac_cache_alloc(const struct ctx *c, > memcpy(&e->addr, addr, sizeof(*addr)); > memcpy(e->mac, mac, ETH_ALEN); > + > + /* Send gratuitous ARP / unsolicited NA for the new mapping */
AFAICT this doesn't actually implement what the commit message describes - it seems to always send an ARP/NA when the neighbour table is updated.
No. Check the code again.
Still not seeing it, I'm going to need a more specific pointer to what I've missed.
Look in fwd_neigh_mac_cache_alloc(). If the entry already exists, the function updates the mac address just to be on the safe side, but then returns without sending any ARP/NA.
Uh... no, no it doesn't. I applied all the patches on a branch and here's what I see in fwd_neigh_mac_cache_alloc():
memcpy(&e->addr, addr, sizeof(*addr)); memcpy(e->mac, mac, ETH_ALEN);
/* Send gratuitous ARP / unsolicited NA for the new mapping */ if (inany_v4(addr)) { struct in_addr ip4 = *inany_v4(addr);
arp_send_gratuitous(c, ip4, e->mac); } else { ndp_send_unsolicited_na(c, &addr->a6); }
If it updates, it ARPs. Do you have something in your tree that didn't make it into the published patches?
This was introduced already in patch #1, not #9. The final function looks like this: void fwd_neigh_mac_cache_alloc(const struct ctx *c, const union inany_addr *addr, uint8_t *mac) { struct mac_cache_table *t = &mac_cache; struct mac_cache_entry *e; ssize_t idx; /* MAC address might change sometimes */ e = fwd_mac_cache_find(c, addr); if (e) { memcpy(e->mac, mac, ETH_ALEN); ====> return; } e = t->free; if (!e) return; t->free = e->next; idx = fwd_mac_cache_slot_idx(c, addr); e->next = t->slots[idx]; t->slots[idx] = e; memcpy(&e->addr, addr, sizeof(*addr)); memcpy(e->mac, mac, ETH_ALEN); /* Send gratuitous ARP / unsolicited NA for the new mapping */ if (inany_v4(addr)) { struct in_addr ip4 = *inany_v4(addr); arp_send_gratuitous(c, ip4, e->mac); } else { ndp_send_unsolicited_na(c, &addr->a6); } }
On 2025-09-25 20:55, David Gibson wrote:
On Thu, Sep 25, 2025 at 09:14:42AM -0400, Jon Maloy wrote:
On 2025-09-25 02:36, David Gibson wrote:
On Wed, Sep 24, 2025 at 06:18:52PM -0400, Jon Maloy wrote:
[...]
I experimented a bit with this. My test program is a simple UDP client-server pair, exchanging first 3 UDP messages client->server, followed by 3 messages server->client.
With the client on the guest, and server outside? How is the outside machine arranged - is it a physically separate host? A bridged VM or container on the same host? Something else?
It is a physically separate host.
First, I changed the main() loop a bit, so that netlink events are handled before all other events, if any. (Basically, I added an extra loop before the main loop, only handling netlink events, before moving on to the main loop (where netlink events had been excluded.) This should secure absolute priority of netlink events before any other events. As you will see below, this made no difference to the scenarios I describe.
Drat.
1: When starting the container, I notice that there is no subscription event in PASTA, even though I can see the entry for the remote host is present in the host's ARP table. There is never any event coming up even if I wait for 10+ minutes.
Huh.... do we need to do something to ensure we get events for existing entries in the host ARP table, not just ones that are added or updated after we're running?
It doesn't seem to be possible,
It actually *is* possible, and I just implemented it. It doesn't solve all problems, but makes a huge difference. I will add it in v10.
Can we do an RTM_GETNEIGH, with no address specified? It's something like that we do to get all our links and addresses in other places.
but even if it were it wouldn't help us much if the entry isn't here, which is also a problematic case. See below.
2: The first UDP is attempted sent from the guest. An ARP request is sent to PASTA, and responded to with the 9a:9a: address.
Maybe we still need to explicitly ask for an ARP resolution when the guest ARPs.
I think so. If we limit this to ARP and NDP, this should be unproblematic.
I just realised this is harder than I thought, though. At least if we want to get the right answer for the first guest ARP. It's not just a netlink request, we'd need to wait for the host to ARP, which means timeouts, and state we need to track, and ...
Yes. I think with the above it is as good as it gets, and it isn't bad. ///jon
On 2025-09-23 23:22, David Gibson wrote:
On Tue, Sep 23, 2025 at 09:13:30PM -0400, Jon Maloy wrote:
Gratuitious ARP and unsolicitated NA should be handled with caution because of the risk of malignant users emitting them to disturb network communication.
[...]
+ req.ah.ar_op = htons(ARPOP_REPLY); + req.ah.ar_hrd = htons(ARPHRD_ETHER); + req.ah.ar_pro = htons(ETH_P_IP); + req.ah.ar_hln = ETH_ALEN; + req.ah.ar_pln = 4; + + /* ARP message */ + memcpy(req.am.sha, mac, sizeof(req.am.sha)); + memcpy(req.am.sip, &ip, sizeof(req.am.sip)); + memcpy(req.am.tha, MAC_BROADCAST, sizeof(req.am.tha)); + memcpy(req.am.tip, &ip, sizeof(req.am.tip));
So, I was trying to check if it made sense to use the same IP for both source and target here, and came across https://www.rfc-editor.org/rfc/rfc5227#section-3
Which suggests we should (counter intuitively) be using ARP requests, not ARP replies for announcements.
I have now read through it, and it seems to come to the conclusion that this is not advisable. In principle it should work, if all implementations stick to standard, but there might be stacks which are not stateless in this regard, i.e., they only accepts ARP replies as a response to a sent request. In short, I think I will stick to my current approach, since it is evidently harmless and is proven to work. ///jon
+ inet_ntop(AF_INET, &ip, ip_str, sizeof(ip_str)); + debug("Sending gratuitous ARP for %s", ip_str); + tap_send_single(c, &req, sizeof(req)); +} diff --git a/arp.h b/arp.h index d5ad0e1..b0dbb56 100644 --- a/arp.h +++ b/arp.h @@ -22,5 +22,7 @@ struct arpmsg {
int arp(const struct ctx *c, struct iov_tail *data); void arp_send_init_req(const struct ctx *c); +void arp_send_gratuitous(const struct ctx *c, struct in_addr ip, + const unsigned char *mac);
#endif /* ARP_H */ diff --git a/fwd.c b/fwd.c index c6348ab..879a351 100644 --- a/fwd.c +++ b/fwd.c @@ -26,6 +26,8 @@ #include "passt.h" #include "lineread.h" #include "flow_table.h" +#include "arp.h" +#include "ndp.h"
/* Empheral port range: values from RFC 6335 */ static in_port_t fwd_ephemeral_min = (1 << 15) + (1 << 14); @@ -129,6 +131,15 @@ void fwd_neigh_mac_cache_alloc(const struct ctx *c,
memcpy(&e->addr, addr, sizeof(*addr)); memcpy(e->mac, mac, ETH_ALEN); + + /* Send gratuitous ARP / unsolicited NA for the new mapping */
AFAICT this doesn't actually implement what the commit message describes - it seems to always send an ARP/NA when the neighbour table is updated.
+ if (inany_v4(addr)) { + struct in_addr ip4 = *inany_v4(addr); + + arp_send_gratuitous(c, ip4, e->mac); + } else { + ndp_send_unsolicited_na(c, &addr->a6); + } }
/** diff --git a/ndp.c b/ndp.c index 70b68aa..8914f31 100644 --- a/ndp.c +++ b/ndp.c @@ -226,6 +226,16 @@ static void ndp_na(const struct ctx *c, const struct in6_addr *dst, ndp_send(c, dst, &na, sizeof(na)); }
+/** + * ndp_send_unsolicited_na() - Send unsolicited NA + * @c: Execution context + * @addr: IPv6 address to advertise + */ +void ndp_send_unsolicited_na(const struct ctx *c, const struct in6_addr *addr) +{ + ndp_na(c, &in6addr_ll_all_nodes, addr); +} + /** * ndp_ra() - Send an NDP Router Advertisement (RA) message * @c: Execution context diff --git a/ndp.h b/ndp.h index 781ea86..320009c 100644 --- a/ndp.h +++ b/ndp.h @@ -12,5 +12,6 @@ int ndp(const struct ctx *c, const struct in6_addr *saddr, struct iov_tail *data); void ndp_timer(const struct ctx *c, const struct timespec *now); void ndp_send_init_req(const struct ctx *c); +void ndp_send_unsolicited_na(const struct ctx *c, const struct in6_addr *addr);
#endif /* NDP_H */ -- 2.50.1
On 2025-09-26 19:25, Jon Maloy wrote:
On 2025-09-23 23:22, David Gibson wrote:
On Tue, Sep 23, 2025 at 09:13:30PM -0400, Jon Maloy wrote:
Gratuitious ARP and unsolicitated NA should be handled with caution because of the risk of malignant users emitting them to disturb network communication.
[...]
+ req.ah.ar_op = htons(ARPOP_REPLY); + req.ah.ar_hrd = htons(ARPHRD_ETHER); + req.ah.ar_pro = htons(ETH_P_IP); + req.ah.ar_hln = ETH_ALEN; + req.ah.ar_pln = 4; + + /* ARP message */ + memcpy(req.am.sha, mac, sizeof(req.am.sha)); + memcpy(req.am.sip, &ip, sizeof(req.am.sip)); + memcpy(req.am.tha, MAC_BROADCAST, sizeof(req.am.tha)); + memcpy(req.am.tip, &ip, sizeof(req.am.tip));
So, I was trying to check if it made sense to use the same IP for both source and target here, and came across https://www.rfc-editor.org/rfc/rfc5227#section-3
Which suggests we should (counter intuitively) be using ARP requests, not ARP replies for announcements.
I have now read through it, and it seems to come to the conclusion that this is not advisable. In principle it should work, if all implementations stick to standard, but there might be stacks which are not stateless in this regard, i.e., they only accepts ARP replies as a response to a sent request. In short, I think I will stick to my current approach, since it is evidently harmless and is proven to work.
///jon
My response above may look confusing. I had actually experimented with both methods, and had in my mind that it was the "ARP Announcement" implementation I had posted. It is now fixed. That said, further investigation indicates that the other method is fully legit, and actually widely used (Windows, Cisco), although not by Linux. ///jon
+ inet_ntop(AF_INET, &ip, ip_str, sizeof(ip_str)); + debug("Sending gratuitous ARP for %s", ip_str); + tap_send_single(c, &req, sizeof(req)); +} diff --git a/arp.h b/arp.h index d5ad0e1..b0dbb56 100644 --- a/arp.h +++ b/arp.h @@ -22,5 +22,7 @@ struct arpmsg { int arp(const struct ctx *c, struct iov_tail *data); void arp_send_init_req(const struct ctx *c); +void arp_send_gratuitous(const struct ctx *c, struct in_addr ip, + const unsigned char *mac); #endif /* ARP_H */ diff --git a/fwd.c b/fwd.c index c6348ab..879a351 100644 --- a/fwd.c +++ b/fwd.c @@ -26,6 +26,8 @@ #include "passt.h" #include "lineread.h" #include "flow_table.h" +#include "arp.h" +#include "ndp.h" /* Empheral port range: values from RFC 6335 */ static in_port_t fwd_ephemeral_min = (1 << 15) + (1 << 14); @@ -129,6 +131,15 @@ void fwd_neigh_mac_cache_alloc(const struct ctx *c, memcpy(&e->addr, addr, sizeof(*addr)); memcpy(e->mac, mac, ETH_ALEN); + + /* Send gratuitous ARP / unsolicited NA for the new mapping */
AFAICT this doesn't actually implement what the commit message describes - it seems to always send an ARP/NA when the neighbour table is updated.
+ if (inany_v4(addr)) { + struct in_addr ip4 = *inany_v4(addr); + + arp_send_gratuitous(c, ip4, e->mac); + } else { + ndp_send_unsolicited_na(c, &addr->a6); + } } /** diff --git a/ndp.c b/ndp.c index 70b68aa..8914f31 100644 --- a/ndp.c +++ b/ndp.c @@ -226,6 +226,16 @@ static void ndp_na(const struct ctx *c, const struct in6_addr *dst, ndp_send(c, dst, &na, sizeof(na)); } +/** + * ndp_send_unsolicited_na() - Send unsolicited NA + * @c: Execution context + * @addr: IPv6 address to advertise + */ +void ndp_send_unsolicited_na(const struct ctx *c, const struct in6_addr *addr) +{ + ndp_na(c, &in6addr_ll_all_nodes, addr); +} + /** * ndp_ra() - Send an NDP Router Advertisement (RA) message * @c: Execution context diff --git a/ndp.h b/ndp.h index 781ea86..320009c 100644 --- a/ndp.h +++ b/ndp.h @@ -12,5 +12,6 @@ int ndp(const struct ctx *c, const struct in6_addr *saddr, struct iov_tail *data); void ndp_timer(const struct ctx *c, const struct timespec *now); void ndp_send_init_req(const struct ctx *c); +void ndp_send_unsolicited_na(const struct ctx *c, const struct in6_addr *addr); #endif /* NDP_H */ -- 2.50.1
On Fri, Sep 26, 2025 at 06:59:40PM -0400, Jon Maloy wrote:
On 2025-09-25 20:47, David Gibson wrote:
On Thu, Sep 25, 2025 at 08:48:51AM -0400, Jon Maloy wrote:
On 2025-09-25 02:38, David Gibson wrote:
On Wed, Sep 24, 2025 at 07:32:43PM -0400, Jon Maloy wrote:
On 2025-09-24 18:18, Jon Maloy wrote:
On 2025-09-23 23:22, David Gibson wrote: > On Tue, Sep 23, 2025 at 09:13:30PM -0400, Jon Maloy wrote:
[...]
> > --- a/fwd.c > > +++ b/fwd.c > > @@ -26,6 +26,8 @@ > > #include "passt.h" > > #include "lineread.h" > > #include "flow_table.h" > > +#include "arp.h" > > +#include "ndp.h" > > /* Empheral port range: values from RFC 6335 */ > > static in_port_t fwd_ephemeral_min = (1 << 15) + (1 << 14); > > @@ -129,6 +131,15 @@ void fwd_neigh_mac_cache_alloc(const struct ctx *c, > > memcpy(&e->addr, addr, sizeof(*addr)); > > memcpy(e->mac, mac, ETH_ALEN); > > + > > + /* Send gratuitous ARP / unsolicited NA for the new mapping */ > > AFAICT this doesn't actually implement what the commit message > describes - it seems to always send an ARP/NA when the neighbour table > is updated.
No. Check the code again.
Still not seeing it, I'm going to need a more specific pointer to what I've missed.
Look in fwd_neigh_mac_cache_alloc(). If the entry already exists, the function updates the mac address just to be on the safe side, but then returns without sending any ARP/NA.
Uh... no, no it doesn't. I applied all the patches on a branch and here's what I see in fwd_neigh_mac_cache_alloc():
memcpy(&e->addr, addr, sizeof(*addr)); memcpy(e->mac, mac, ETH_ALEN);
/* Send gratuitous ARP / unsolicited NA for the new mapping */ if (inany_v4(addr)) { struct in_addr ip4 = *inany_v4(addr);
arp_send_gratuitous(c, ip4, e->mac); } else { ndp_send_unsolicited_na(c, &addr->a6); }
If it updates, it ARPs. Do you have something in your tree that didn't make it into the published patches?
This was introduced already in patch #1, not #9. The final function looks like this:
void fwd_neigh_mac_cache_alloc(const struct ctx *c, const union inany_addr *addr, uint8_t *mac)
{ struct mac_cache_table *t = &mac_cache; struct mac_cache_entry *e; ssize_t idx;
/* MAC address might change sometimes */ e = fwd_mac_cache_find(c, addr); if (e) { memcpy(e->mac, mac, ETH_ALEN); ====> return;
Ah, yes, sorry. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On Fri, Sep 26, 2025 at 07:05:56PM -0400, Jon Maloy wrote:
On 2025-09-25 20:55, David Gibson wrote:
On Thu, Sep 25, 2025 at 09:14:42AM -0400, Jon Maloy wrote:
On 2025-09-25 02:36, David Gibson wrote:
On Wed, Sep 24, 2025 at 06:18:52PM -0400, Jon Maloy wrote:
[...]
I experimented a bit with this. My test program is a simple UDP client-server pair, exchanging first 3 UDP messages client->server, followed by 3 messages server->client.
With the client on the guest, and server outside? How is the outside machine arranged - is it a physically separate host? A bridged VM or container on the same host? Something else?
It is a physically separate host.
First, I changed the main() loop a bit, so that netlink events are handled before all other events, if any. (Basically, I added an extra loop before the main loop, only handling netlink events, before moving on to the main loop (where netlink events had been excluded.) This should secure absolute priority of netlink events before any other events. As you will see below, this made no difference to the scenarios I describe.
Drat.
1: When starting the container, I notice that there is no subscription event in PASTA, even though I can see the entry for the remote host is present in the host's ARP table. There is never any event coming up even if I wait for 10+ minutes.
Huh.... do we need to do something to ensure we get events for existing entries in the host ARP table, not just ones that are added or updated after we're running?
It doesn't seem to be possible,
It actually *is* possible, and I just implemented it. It doesn't solve all problems, but makes a huge difference. I will add it in v10.
Hooray! I thought there ought to be a way. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On Sat, Sep 27, 2025 at 03:32:38PM -0400, Jon Maloy wrote:
On 2025-09-26 19:25, Jon Maloy wrote:
On 2025-09-23 23:22, David Gibson wrote:
On Tue, Sep 23, 2025 at 09:13:30PM -0400, Jon Maloy wrote:
Gratuitious ARP and unsolicitated NA should be handled with caution because of the risk of malignant users emitting them to disturb network communication.
[...]
+ req.ah.ar_op = htons(ARPOP_REPLY); + req.ah.ar_hrd = htons(ARPHRD_ETHER); + req.ah.ar_pro = htons(ETH_P_IP); + req.ah.ar_hln = ETH_ALEN; + req.ah.ar_pln = 4; + + /* ARP message */ + memcpy(req.am.sha, mac, sizeof(req.am.sha)); + memcpy(req.am.sip, &ip, sizeof(req.am.sip)); + memcpy(req.am.tha, MAC_BROADCAST, sizeof(req.am.tha)); + memcpy(req.am.tip, &ip, sizeof(req.am.tip));
So, I was trying to check if it made sense to use the same IP for both source and target here, and came across https://www.rfc-editor.org/rfc/rfc5227#section-3
Which suggests we should (counter intuitively) be using ARP requests, not ARP replies for announcements.
I have now read through it, and it seems to come to the conclusion that this is not advisable. In principle it should work, if all
What "this" refers to here is not clear to me.
implementations stick to standard, but there might be stacks which are not stateless in this regard, i.e., they only accepts ARP replies as a response to a sent request. In short, I think I will stick to my current approach, since it is evidently harmless and is proven to work.
///jon
My response above may look confusing.
Yes.. and I'm still confused. Without knowing what "this" is above, I'm not clear what "it" or "the other" are below either.
I had actually experimented with both methods, and had in my mind that it was the "ARP Announcement" implementation I had posted. It is now fixed.
That said, further investigation indicates that the other method is fully legit, and actually widely used (Windows, Cisco), although not by Linux.
My understanding of that RFC is that it is advising _against_ sending unsolicited ARP replies (as your earlier posted versions did). Instead, it advises sending ARP requests in order to announce a MAC to the networm. The history is confusing because "ARP announcements" and "gratuitous ARP" can and have been used to refer to both variants. Does that match your current understanding? -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On Mon, 29 Sep 2025 14:08:27 +1000
David Gibson
Instead, it advises sending ARP requests in order to announce a MAC to the networm.
Network, you meant network! The other plan is not public yet. :) -- Stefano
On Tue, Sep 30, 2025 at 12:23:44AM +0200, Stefano Brivio wrote:
On Mon, 29 Sep 2025 14:08:27 +1000 David Gibson
wrote: Instead, it advises sending ARP requests in order to announce a MAC to the networm.
Network, you meant network! The other plan is not public yet. :)
Turns out the only portable way to do ARP announcements is to infect the other hosts and fix the bugs in their ARP handling. :) -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
participants (3)
-
David Gibson
-
Jon Maloy
-
Stefano Brivio