diff options
Diffstat (limited to 'results/classifier/118/graphic/1835')
| -rw-r--r-- | results/classifier/118/graphic/1835 | 48 |
1 files changed, 48 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/1835 b/results/classifier/118/graphic/1835 new file mode 100644 index 000000000..3e550f958 --- /dev/null +++ b/results/classifier/118/graphic/1835 @@ -0,0 +1,48 @@ +graphic: 0.978 +network: 0.923 +performance: 0.903 +x86: 0.893 +device: 0.838 +ppc: 0.824 +architecture: 0.820 +peripherals: 0.801 +boot: 0.760 +PID: 0.750 +semantic: 0.743 +debug: 0.728 +vnc: 0.707 +hypervisor: 0.693 +permissions: 0.683 +assembly: 0.670 +socket: 0.658 +virtual: 0.630 +VMM: 0.623 +files: 0.623 +i386: 0.620 +user-level: 0.610 +risc-v: 0.525 +arm: 0.400 +TCG: 0.399 +kernel: 0.372 +register: 0.364 +mistranslation: 0.342 +KVM: 0.218 + +IPv4 guest/outbound port forwarding not working +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: +1. Build libslirp, I am using HEAD @ master. +1. Build your QEMU with user network enabled to use slirp (`./configure -target-list=x86_64-softmmu --enable-slirp`). +1. Ran a Python server on host listening to port `6655` (`python3 -m http.server --bind :: 6655`). +1. 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. +1. 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 just `ls` the directory. +5. 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. + + + + + |