blob: c6104cb676119ebf1c30f6abf2b8e56cb4e4df97 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Alright, let me try to figure out whether this issue is related to user-mode or system-mode in QEMU.
The problem described involves port forwarding not working correctly after the first request. The setup uses Slirp for networking in a QEMU VM, with a Python HTTP server on the host listening on port 6655. The guest sends requests via curl to 10.0.2.100:6657, which is forwarded by Slirp.
From the steps, it seems like the issue is occurring when the second request gets stuck. The user used Wireshark to capture packets and noticed that after the initial successful request, subsequent ones aren't being seen in tcpdump on the host. This suggests a problem with how the networking layer handles multiple requests or connections.
Slirp operates within QEMU's user-mode networking stack. When using Slirp for port forwarding, it's part of the user-space network stack rather than the system's kernel networking. Issues here would typically relate to how the user-mode components (like Slirp) handle connections and traffic.
The fact that the guest sends a keep-alive request indicates that the connection might be hanging or not being properly closed by Slirp, leading to subsequent requests getting stuck. This points towards an issue within the user-mode networking setup rather than system-level drivers or hardware.
Therefore, this bug is likely related to the user-mode components of QEMU.
</think>
user
|