passt/arp.c, branch bug165c

arp/ndp: don't send messages on uninitialized tap interface

2025-11-27T21:29:25+00:00

When running pasta without --config-net, the tap interface is opened
and assigned a valid file descriptor, but intentionally not brought
up in the namespace. This is the expected behavior when the user wants
to configure the namespace manually.

However, in PASTA mode the code is attempting to send ARP announcements
and NDP messages (initial requests and unsolicited NAs) based solely on
whether c->fd_tap is valid, without checking if the interface actually
is up and ready to transmit. This results in send failures, and when
debug is activated (pasta -d) we see error printouts for these early
messages.

We now add new function tap_is_ready() which checks both conditions:
- Whether fd_tap is valid (all modes)
- Whether the tap interface is up (pasta mode only). In this mode, we
  use the existing c->pasta_conf_ns flag, which indicates whether
  pasta_ns_conf() configured and brought up the interface. This test
  is simple, and good enough for now.

We update all functions that send unsolicited ARP/NDP messages to
check with the new function before making any send attempt.

This eliminates spurious send errors when starting pasta without
--config-net, while preserving correct behavior when the interface
is properly initialized.

Signed-off-by: Jon Maloy 
Signed-off-by: Stefano Brivio

arp/ndp: send ARP announcement / unsolicited NA when neigbour entry added

2025-10-30T11:01:01+00:00

ARP announcements and unsolicited NAs 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 shortly later 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 
Reviewed-by: David Gibson 
[sbrivio: Fix "announcment" typo in arp_announce()]
Signed-off-by: Stefano Brivio

arp/ndp: respond with true MAC address of LAN local remote hosts

2025-10-30T11:01:01+00:00

When we receive an ARP request or NDP neigbour 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, if available.

Signed-off-by: Jon Maloy 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

Send an initial ARP and NDP request to resolve the guest IP address

2025-09-17T11:51:28+00:00

When restarting passt while QEMU keeps running with a configured
"reconnect-ms" setting, the port forwardings will stop working until
the guest sends some outgoing network traffic.

Reason: Although QEMU reconnects successfully to the unix domain
socket of the new passt process, that one no longer knows the guest's
MAC address and uses instead the broadcast MAC address.  However, this
is ignored by the guest, at least if the guest runs Linux.  Only after
the guest sends some network package on its own initiative, passt will
know the MAC address and will be able to establish forwarded
connections.

This change fixes this issue by sending an ARP and an NDP request to
resolve the guest's MAC address via its IPv4 and IPv6 address, which
we do know, right after the unix domain socket (re)connection.

The only case where the IP is "wrong" would be if the configuration
changed, or on the very first start right after qemu started.  But in
those cases, we just wouldn't get an ARP/NDP response, and can't do
anything until we receive the guest's DHCP request - just as before.
In other words, in the worst case the ARP/NDP requests would be
harmless.

Signed-off-by: Volker Diels-Grabsch 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

arp: use iov_tail rather than pool

2025-09-03T18:43:37+00:00

The arp() function signature is changed to accept `struct iov_tail *data`
directly, replacing the previous `const struct pool *p` parameter.
Consequently, arp() no longer fetches packet data internally using
packet_data(), streamlining its logic.

This simplifies callers like tap4_handler(), which now pass the iov_tail
for the L2 ARP frame directly, removing intermediate pool handling.

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

packet: rename packet_data() to packet_get()

2025-09-03T18:43:35+00:00

As we have removed packet_get(), we can rename packet_data() to packet_get()
as the name is clearer.

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

arp: Convert to iov_tail

2025-09-03T18:42:26+00:00

Use packet_data() and extract headers using IOV_REMOVE_HEADER()
rather than packet_get().

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

arp: Don't mix incoming and outgoing buffers

2025-09-03T18:42:11+00:00

Don't use the memory of the incoming packet to build the outgoing buffer
as it can be memory of the TX queue in the case of vhost-user.

Moreover with vhost-user, the packet can be split across several
iovec and it's easier to rebuild it in a buffer than updating an
existing iovec array.

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

arp: Fix a handful of small warts

2024-10-18T18:27:04+00:00

This fixes a number of harmless but slightly ugly warts in the ARP
resolution code:
 * Use in4addr_any to represent 0.0.0.0 rather than hand constructing an
   example.
 * When comparing am->sip against 0.0.0.0 use sizeof(am->sip) instead of
   sizeof(am->tip) (same value, but makes more logical sense)
 * Described the guest's assigned address as such, rather than as "our
   address" - that's not usually what we mean by "our address" these days
 * Remove "we might have the same IP address" comment which I can't make
   sense of in context (possibly it's relating to the statement below,
   which already has its own comment?)

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

treewide: Rename MAC address fields for clarity

2024-08-21T09:59:54+00:00

c->mac isn't a great name, because it doesn't say whose mac address it is
and it's not necessarily obvious in all the contexts we use it.  Since this
is specifically the address that we (passt/pasta) use on the tap interface,
rename it to "our_tap_mac".  Rename the "mac_guest" field to "guest_mac"
to be grammatically consistent.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio