- dev - passt

[PATCH v3] tcp: Store the owner connections for flags frames
by Yumei Huang 11 Sep '25

11 Sep '25

There is an issue reported by Volker Diels-Grabsch and Boleyn Su. A segmentation fault occurs when executing the following command: (sleep 0.1; ssh -p 22000 127.0.0.1) & passt -f -t 22000:22 It's caused by commit 78da088f7bab ("tcp: unify payload and flags l2 frames array"). Fix it by storing the owner connections of flags frames into tcp_frame_conns[] array. Reported-by: Volker Diels-Grabsch <v(a)njh.eu> Reported-by: Boleyn Su <boleyn.su(a)gmail.com> Suggested-by: David Gibson <david(a)gibson.dropbear.id.au> Fixes: 78da088f7bab ("tcp: unify payload and flags l2 frames array") Signed-off-by: Yumei Huang <yuhuang(a)redhat.com> --- tcp_buf.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tcp_buf.c b/tcp_buf.c index bc898de..d63c18d 100644 --- a/tcp_buf.c +++ b/tcp_buf.c @@ -209,13 +209,14 @@ int tcp_buf_send_flag(const struct ctx *c, struct tcp_tap_conn *conn, int flags) if (ret <= 0) return ret; - tcp_payload_used++; + tcp_frame_conns[tcp_payload_used++] = conn; l4len = optlen + sizeof(struct tcphdr); iov[TCP_IOV_PAYLOAD].iov_len = l4len; tcp_l2_buf_fill_headers(conn, iov, NULL, seq, false); if (flags & DUP_ACK) { - struct iovec *dup_iov = tcp_l2_iov[tcp_payload_used++]; + struct iovec *dup_iov = tcp_l2_iov[tcp_payload_used]; + tcp_frame_conns[tcp_payload_used++] = conn; memcpy(dup_iov[TCP_IOV_TAP].iov_base, iov[TCP_IOV_TAP].iov_base, iov[TCP_IOV_TAP].iov_len); -- 2.47.0

3 2

[PATCH v4 0/8] tcp: Fixes for issues uncovered by tests with 6.17-rc1 kernels
by Stefano Brivio 11 Sep '25

11 Sep '25

Starting from Linux kernel commit 1d2fbaad7cd8 ("tcp: stronger sk_rcvbuf checks"), window limits are enforced more aggressively with a bigger amount of zero-window updates compared to what happened with e2142825c120 ("net: tcp: send zero-window ACK when no memory") alone, and occasional duplicate ACKs can now be seen also for local transfers with default (208 KiB) socket buffer sizes. Paul reports that, with 6.17-rc1-ish kernels, Podman tests for the pasta integration occasionally fail on the "TCP/IPv4 large transfer, tap" case. While playing with a reproducer that seems to be matching those failures: while true; do ./pasta --trace -l /tmp/pasta.log -p /tmp/pasta.pcap --config-net -t 5555 -- socat TCP-LISTEN:5555 OPEN:/tmp/large.rcv,trunc & (sleep 0.3; socat -T2 OPEN:large.bin TCP:88.198.0.164:5555; ); wait; diff large.bin /tmp/large.rcv || break; done and a kernel including that commit, I hit a few different failures, that should be fixed by this series. Paul tested v1 of this series and found an additional failure (transfer timeout), which I could reproduce with a slightly different command: while true; do ./pasta --trace -l /tmp/pasta.log -p /tmp/pasta.pcap --config-net -t 5555 -- socat TCP-LISTEN:5555 EXEC:./write.sh & (sleep 0.3; socat -T2 OPEN:large.bin TCP:88.198.0.164:5555; ); wait; diff large.bin /tmp/large.rcv || break; done where write.sh is simply: #!/bin/sh cat > /tmp/large.rcv so that the connection is not half-closed starting from the beginning, because socat can't make assumptions about the unidirectional nature of the traffic. This should now be fixed as well by the new version of patch 3/8. v4: - add patch 8/8 v3: - add patch 6/7 - in 7/7, check dlen <= 1 for keep-alive segments, instead of len <= 1 v2: in 3/6, rewind sequence also if the zero-window update comes in the middle of a batch with non-zero window updates Stefano Brivio (8): tcp: FIN flags have to be retransmitted as well tcp: Factor sequence rewind for retransmissions into a new function tcp: Rewind sequence when guest shrinks window to zero tcp: Fix closing logic for half-closed connections tcp: Don't try to transmit right after the peer shrank the window to zero tcp: Cast operands of sequence comparison macros to uint32_t before using them tcp: Fast re-transmit if half-closed, make TAP_FIN_RCVD path consistent tcp: Don't send FIN segment to guest yet if we have pending unacknowledged data tcp.c | 142 ++++++++++++++++++++++++++++++++++++++----------- tcp_buf.c | 5 +- tcp_internal.h | 12 +++-- 3 files changed, 122 insertions(+), 37 deletions(-) -- 2.43.0

4 26

[PATCH v2] tcp: Store the owner connections for flags frames
by Yumei Huang 11 Sep '25

11 Sep '25

There is an issue reported by Volker Diels-Grabsch and Boleyn Su. A segmentation fault occurs when executing the following command: (sleep 0.1; ssh -p 22000 127.0.0.1) & passt -f -t 22000:22 It's caused by commit 78da088f7bab ("tcp: unify payload and flags l2 frames array"). Fix it by storing the owner connections of flags frames into tcp_frame_conns[] array. Reported-by: Volker Diels-Grabsch <v(a)njh.eu> Reported-by: Boleyn Su <boleyn.su(a)gmail.com> Suggested-by: David Gibson <david(a)gibson.dropbear.id.au> Fixes: 78da088f7bab ("tcp: unify payload and flags l2 frames array") Signed-off-by: Yumei Huang <yuhuang(a)redhat.com> --- tcp_buf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tcp_buf.c b/tcp_buf.c index bc898de..d351c20 100644 --- a/tcp_buf.c +++ b/tcp_buf.c @@ -209,13 +209,14 @@ int tcp_buf_send_flag(const struct ctx *c, struct tcp_tap_conn *conn, int flags) if (ret <= 0) return ret; - tcp_payload_used++; + tcp_frame_conns[tcp_payload_used++] = conn; l4len = optlen + sizeof(struct tcphdr); iov[TCP_IOV_PAYLOAD].iov_len = l4len; tcp_l2_buf_fill_headers(conn, iov, NULL, seq, false); if (flags & DUP_ACK) { struct iovec *dup_iov = tcp_l2_iov[tcp_payload_used++]; + tcp_frame_conns[tcp_payload_used - 1] = conn; memcpy(dup_iov[TCP_IOV_TAP].iov_base, iov[TCP_IOV_TAP].iov_base, iov[TCP_IOV_TAP].iov_len); -- 2.47.0

2 2

[PATCH] Send an initial ARP request to resolve the guest IP address
by Volker Diels-Grabsch 10 Sep '25

10 Sep '25

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 a 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 request to resolve the guest's MAC address via its IP 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, and/or on the very first start right after qemu started. But in those cases, we just wouldn't get an ARP response, and can't do anything until we receive the guest's DHCP request - just as before. In other words, in the worst case an ARP request would be harmless. Signed-off-by: Volker Diels-Grabsch <v(a)njh.eu> --- arp.c | 34 ++++++++++++++++++++++++++++++++++ arp.h | 1 + tap.c | 15 +++++++++++++-- 3 files changed, 48 insertions(+), 2 deletions(-) diff --git a/arp.c b/arp.c index 44677ad..561581a 100644 --- a/arp.c +++ b/arp.c @@ -112,3 +112,37 @@ int arp(const struct ctx *c, struct iov_tail *data) return 1; } + +/** + * send_initial_arp_req() - Send initial ARP request to retrieve guest MAC address + * @c: Execution context + */ +void send_initial_arp_req(const struct ctx *c) +{ + struct { + struct ethhdr eh; + struct arphdr ah; + struct arpmsg am; + } __attribute__((__packed__)) req; + + /* Ethernet header */ + req.eh.h_proto = htons(ETH_P_ARP); + memcpy(req.eh.h_dest, c->guest_mac, 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_REQUEST); + 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, c->our_tap_mac, sizeof(req.am.sha)); + memcpy(req.am.sip, &c->ip4.our_tap_addr, sizeof(req.am.sip)); + memcpy(req.am.tha, c->guest_mac, sizeof(req.am.tha)); + memcpy(req.am.tip, &c->ip4.addr, sizeof(req.am.tip)); + + info("sending initial ARP request to retrieve guest MAC address after reconnect"); + tap_send_single(c, &req, sizeof(req)); +} diff --git a/arp.h b/arp.h index 86bcbf8..5490144 100644 --- a/arp.h +++ b/arp.h @@ -21,5 +21,6 @@ struct arpmsg { } __attribute__((__packed__)); int arp(const struct ctx *c, struct iov_tail *data); +void send_initial_arp_req(const struct ctx *c); #endif /* ARP_H */ diff --git a/tap.c b/tap.c index 7ba6399..47dedd5 100644 --- a/tap.c +++ b/tap.c @@ -1355,6 +1355,16 @@ static void tap_start_connection(const struct ctx *c) ev.events = EPOLLIN | EPOLLRDHUP; ev.data.u64 = ref.u64; epoll_ctl(c->epollfd, EPOLL_CTL_ADD, c->fd_tap, &ev); + + switch (c->mode) { + case MODE_PASST: + send_initial_arp_req(c); + break; + case MODE_PASTA: + break; + case MODE_VU: + break; + } } /** @@ -1504,8 +1514,9 @@ void tap_backend_init(struct ctx *c) tap_sock_unix_init(c); /* In passt mode, we don't know the guest's MAC address until it - * sends us packets. Use the broadcast address so that our - * first packets will reach it. + * sends us packets (e.g. responds to our initial ARP request). + * Until then, use the broadcast address so that our first + * packets will reach it. */ memset(&c->guest_mac, 0xff, sizeof(c->guest_mac)); break; -- 2.47.2

3 13

[PATCH] tcp: Add flags frames to payload frames arrays
by Yumei Huang 10 Sep '25

10 Sep '25

There is an issue reported by Volker Diels-Grabsch and Boleyn Su. A segmentation fault occurs when executing the following command: (sleep 0.1; ssh -p 22000 127.0.0.1) & passt -f -t 22000:22 It's caused by commit 78da088f7bab ("tcp: unify payload and flags l2 frames array"). Fix it by adding flags frames to payload frames arrays. Signed-off-by: Yumei Huang <yuhuang(a)redhat.com> --- tcp_buf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tcp_buf.c b/tcp_buf.c index bc898de..d351c20 100644 --- a/tcp_buf.c +++ b/tcp_buf.c @@ -209,13 +209,14 @@ int tcp_buf_send_flag(const struct ctx *c, struct tcp_tap_conn *conn, int flags) if (ret <= 0) return ret; - tcp_payload_used++; + tcp_frame_conns[tcp_payload_used++] = conn; l4len = optlen + sizeof(struct tcphdr); iov[TCP_IOV_PAYLOAD].iov_len = l4len; tcp_l2_buf_fill_headers(conn, iov, NULL, seq, false); if (flags & DUP_ACK) { struct iovec *dup_iov = tcp_l2_iov[tcp_payload_used++]; + tcp_frame_conns[tcp_payload_used - 1] = conn; memcpy(dup_iov[TCP_IOV_TAP].iov_base, iov[TCP_IOV_TAP].iov_base, iov[TCP_IOV_TAP].iov_len); -- 2.47.0

2 2

[PATCH] test: Fix the download link for debian-11-generic-ppc64el image
by Yumei Huang 10 Sep '25

10 Sep '25

Signed-off-by: Yumei Huang <yuhuang(a)redhat.com> --- test/Makefile | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/test/Makefile b/test/Makefile index a774285..4938827 100644 --- a/test/Makefile +++ b/test/Makefile @@ -15,7 +15,7 @@ DEBIAN_IMGS = debian-8.11.0-openstack-amd64.qcow2 \ debian-10-generic-ppc64el-20220911-1135.qcow2 \ debian-11-nocloud-amd64.qcow2 \ debian-11-generic-arm64.qcow2 \ - debian-11-generic-ppc64el.qcow2 \ + debian-11-generic-ppc64el-20250703-2162.qcow2 \ debian-sid-nocloud-amd64-daily.qcow2 \ debian-sid-nocloud-arm64-daily.qcow2 \ debian-sid-nocloud-ppc64el-daily.qcow2 @@ -169,6 +169,9 @@ debian-11-nocloud-%.qcow2: debian-11-generic-%.qcow2: $(WGET) -O $@ https://cloud.debian.org/images/cloud/bullseye/latest/debian-11-generic-$*.… +debian-11-generic-ppc64el-20250703-2162.qcow2: + $(WGET) -O $@ https://cloud.debian.org/images/cloud/bullseye/20250703-2162/debian-11-gene… + debian-sid-nocloud-%-daily.qcow2: $(WGET) -O $@ https://cloud.debian.org/images/cloud/sid/daily/latest/debian-sid-nocloud-$… -- 2.47.0

3 4

[PATCH v6 0/8] Use true MAC address of LAN local remote hosts
by Jon Maloy 10 Sep '25

10 Sep '25

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. Jon Maloy (8): netlink: add function to extract MAC addresses from NDP/ARP table fwd: Added 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 + flow.c | 2 + flow.h | 2 + fwd.c | 184 +++++++++++++++++++++++++++++++++++++++++++++++-- fwd.h | 6 ++ icmp.c | 8 ++- inany.c | 1 + ndp.c | 10 ++- netlink.c | 82 ++++++++++++++++++++++ netlink.h | 2 + passt.c | 9 ++- 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 +- util.c | 12 ++++ util.h | 1 + 25 files changed, 407 insertions(+), 83 deletions(-) -- 2.50.1

2 13

[PATCH] Fix segfault on TCP connection before first passt socket connection
by Volker Diels-Grabsch 10 Sep '25

10 Sep '25

This issue can be reproduced by running passt with TCP forwarding and connecting to that TCP port before the first client (e.g. QEMU) connects to the passt socket. Example: (sleep 0.1; ssh -p 22000 127.0.0.1) & passt -f -t 22000:22 Although this commit likely doesn't fix the root cause of this issue, it does reliably fix the segfault. --- tcp_buf.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tcp_buf.c b/tcp_buf.c index bc898de..1a06f15 100644 --- a/tcp_buf.c +++ b/tcp_buf.c @@ -120,6 +120,9 @@ static void tcp_revert_seq(const struct ctx *c, struct tcp_tap_conn **conns, uint32_t seq = ntohl(th->seq); uint32_t peek_offset; + if (conn == NULL) + continue; + if (SEQ_LE(conn->seq_to_tap, seq)) continue; -- 2.47.3

2 1

[PATCH v5 00/10] Use true MAC address of LAN local remote hosts
by Jon Maloy 10 Sep '25

10 Sep '25

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 Jon Maloy (10): netlink: add function to extract MAC addresses from NDP/ARP table fwd: Added cache table for ARP/NDP contents fwd: Add entries of ARP/NDP cache table to a FIFO/LRU queue 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() tcp: make tcp_rst_no_conn() respond with correct MAC address icmp: let icmp use mac address from flowside structure arp.c | 9 +- conf.c | 2 + flow.c | 2 + flow.h | 2 + fwd.c | 303 ++++++++++++++++++++++++++++++++++++++++++++++++- fwd.h | 13 +++ icmp.c | 8 +- inany.c | 1 + ndp.c | 10 +- netlink.c | 82 +++++++++++++ netlink.h | 2 + passt.c | 9 +- passt.h | 3 +- pasta.c | 2 +- tap.c | 23 ++-- tap.h | 7 +- tcp.c | 26 ++++- tcp.h | 2 +- tcp_buf.c | 37 +++--- tcp_internal.h | 4 +- tcp_vu.c | 5 +- udp.c | 57 ++++++---- udp.h | 2 +- 23 files changed, 530 insertions(+), 81 deletions(-) -- 2.50.1

2 23

[PATCH 0/3] This series contains fixes and improvements to the vhost-user implementation
by Laurent Vivier 09 Sep '25

09 Sep '25

The first patch fixes a protocol compliance issue where VHOST_USER_GET_QUEUE_NUM was incorrectly returning the number of virtqueues instead of queue pairs. The vhost-user specification clearly states this should return the maximum number of queues supported by the backend. Since each queue consists of an RX/TX pair, the correct value is VHOST_USER_MAX_VQS / 2. This patch also renames the constant to better reflect its meaning. The second and third patches address virtqueue handling in the UDP and TCP receive paths. These changes pass the virtqueue pointer explicitly to the receive functions, enabling proper queue selection for future multiqueue support. This ensures packets are processed on the same virtqueue as the caller. These changes lay the groundwork for full multiqueue support while fixing existing protocol compliance issues. Laurent Vivier (3): vhost-user: Fix VHOST_USER_GET_QUEUE_NUM to return number of queues udp_vu: Pass virtqueue pointer to udp_vu_sock_recv() tcp_vu: Pass virtqueue pointer to tcp_vu_sock_recv() tcp_vu.c | 8 ++++---- udp_vu.c | 9 +++++---- vhost_user.c | 16 +++++++++------- virtio.h | 4 ++-- 4 files changed, 20 insertions(+), 17 deletions(-) -- 2.50.1

3 7