IPv4 guest/outbound port forwarding not working
Host environment
-
Operating system: Debian GNU/Linux rodete
-
OS/kernel version: 6.3.11-1rodete1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.3.11-1rodete1 (2023-07-18) x86_64 GNU/Linux
-
Architecture: x86
-
QEMU flavor: qemu-system-x86_64
-
QEMU version: QEMU emulator version 8.0.2 (Debian 1:8.0.2+dfsg-3)
-
QEMU command line:
./build/qemu-system-x86_64 \ -enable-kvm \ -machine q35 \ -boot d \ -smp 4 \ -m 4G \ -object filter-dump,id=f1,file=netdump-$$.pcap,netdev=n1 \ -nic user,id=n1,model=e1000,guestfwd=tcp:10.0.2.100:6657-tcp:127.0.0.1:6655 \ -cdrom /usr/local/home/flwu/debug_imgs/fedora-38.iso
Emulated/Virtualized environment
- Operating system: Fedora 38 workstation
- OS/kernel version: 6.2.9-300.fc38.x86_64
- Architecture: x86
Description of problem
Python http server running on the host can receive the first http request from guest and provides correct response, but the resent request gets stuck. Package couldn't be seen in tcpdump
running on host.
Steps to reproduce
- Build libslirp, I am using HEAD @ master.
- Build your QEMU with user network enabled to use slirp (
./configure -target-list=x86_64-softmmu --enable-slirp
). - Ran a Python server on host listening to port
6655
(python3 -m http.server --bind :: 6655
). - Boot your QEMU with aforementioned QEMU command line, I am forwarding a server address to host's local address
guestfwd=tcp:10.0.2.100:6657-tcp:127.0.0.1:6655
. For image, I am using a ordinary Fedora 38 workstation live cdrom. - In your guest OS (emulated enviroment), open a terminal and run
curl http://10.0.2.100:6657
, this sends a http get to the slirp outbound forwarding server. You should see the Python http server gets the request and provides correct response::ffff:127.0.0.1 - - [17/Aug/2023 18:24:34] "GET / HTTP/1.1" 200 -
, nothing but justls
the directory. - Repeat step 4, you will see the
curl
command gets stuck.
Additional information
I've added a .pacp capturing line in QEMU command line and investigated it via Wireshark, noticed the slirp gets the http get, but after that being stuck in some place, I saw the guest sending keep alive request to slirp, so I think this could be something in the QEMU side.
![Screenshot_2023-08-17_at_11.45.02_AM](/-/project/11167699/uploads/2f93c50bba1105860f2b85226703d65b/Screenshot_2023-08-17_at_11.45.02_AM.png)