fix: remove TCP port probe from verify_port_forwarding after restore#558
fix: remove TCP port probe from verify_port_forwarding after restore#558claude-claude[bot] wants to merge 1 commit intofix-pasta-restore-probefrom
Conversation
The verify_port_forwarding() method called wait_for_port_forwarding() after the ping succeeded, which did a bare TcpStream::connect() + immediate drop through pasta's L2 port forwarding. Even though the guest was alive and ARP was resolved at this point, the connect-then- drop created a half-open entry in pasta's connection tracking table that poisoned subsequent data connections on the same port — causing 0-byte HTTP responses in the bench clone_http test on both x64 and arm64. The ping already confirms the full L2/L3 path through pasta's bridge is working (namespace → bridge → guest). Pasta is listening on the loopback ports (confirmed at startup). Together these guarantee the forwarding chain is functional without needing a TCP port probe. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5cbbc1e2dd
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // Do NOT call wait_for_port_forwarding() here. | ||
| // A bare TcpStream::connect() + immediate drop through pasta's | ||
| // L2 translation creates a half-open entry in pasta's connection | ||
| // tracking table that poisons subsequent connections on the same | ||
| // port (0-byte responses). The ping already confirms L2 |
There was a problem hiding this comment.
After snapshot restore, this method now returns success after ping/ARP and explicitly skips wait_for_port_forwarding(). Because post_start() already skips that wait when restore_mode is set, rootless restores with port_mappings now have no check that host TCP forwards are actually accepting connections before health monitoring proceeds. wait_for_port_forwarding() in the same file still documents that pasta binds ports asynchronously (PID file/bridge readiness is not enough), so this change can reintroduce post-restore races where clones look ready but 127.x.y.z:<host_port> is not yet reachable.
Useful? React with 👍 / 👎.
|
Closing: fix already incorporated in PR #555. |
1 participant
CI Fix
Fixes CI #22660134211
Problem
The
clone_http/rootless/nginxbenchmark panicked on both x64 and arm64 with 0-byte HTTP responses after 10 retry attempts. TCP connections to pasta succeeded but no data was returned.Root cause:
verify_port_forwarding()calledwait_for_port_forwarding()after the ping-based ARP verification succeeded.wait_for_port_forwarding()does a bareTcpStream::connect()to the loopback port (127.0.0.3:8080), which goes through pasta's L2 port forwarding to the guest. The connection immediately drops (stream goes out of scope, sending FIN) without exchanging any data. This connect-then-drop pattern creates a half-open entry in pasta's internal connection tracking table that poisons subsequent connections on the same port — causing the next HTTP request to receive 0 bytes.The original
with_restore_mode()fix correctly skipped the port probe inpost_start()(before the VM is loaded), butverify_port_forwarding()(called after restore, after ARP resolution) still ran the same poisoning probe.Solution
Removed the
wait_for_port_forwarding()call fromverify_port_forwarding(). The ping already confirms the full L2/L3 path through pasta's bridge is working (namespace → bridge → guest). Pasta is listening on the loopback ports (confirmed at startup). Together these guarantee the forwarding chain is functional without needing a TCP port probe that poisons pasta's state.Generated by Claude | Fix Run