From d0c85e36e4de67af628d54e9ab577cc3fad7796a Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Thu, 3 Jul 2025 07:27:52 +0000 Subject: add deepseek and gemma results --- results/classifier/deepseek-2-tmp/reasoning/network/1835 | 13 ------------- 1 file changed, 13 deletions(-) delete mode 100644 results/classifier/deepseek-2-tmp/reasoning/network/1835 (limited to 'results/classifier/deepseek-2-tmp/reasoning/network/1835') diff --git a/results/classifier/deepseek-2-tmp/reasoning/network/1835 b/results/classifier/deepseek-2-tmp/reasoning/network/1835 deleted file mode 100644 index d4293096..00000000 --- a/results/classifier/deepseek-2-tmp/reasoning/network/1835 +++ /dev/null @@ -1,13 +0,0 @@ - -Okay, so I need to classify this bug report into one of the given categories for QEMU. The problem described is about IPv4 guest outbound port forwarding not working correctly. Let me go through the details step by step. - -The user reports that a Python HTTP server on the host receives the first request from the guest but gets stuck with subsequent requests. They also mention that packets aren't seen in `tcpdump` on the host, which suggests something's wrong with how the networking is handled between the guest and host. - -Looking at the reproduction steps: they built libslirp and QEMU with user network enabled using slirp. Then, they set up a server on the host and configured port forwarding in QEMU. When running `curl` from the guest, it works once but gets stuck on the second attempt. - -The additional information points towards an issue within QEMU's side, possibly related to how Slirp handles subsequent requests or connections. They also provided a packet capture showing that after the initial response, there are keep-alive requests but no further data, indicating a possible state where the connection isn't being handled properly. - -Looking at the categories: network seems relevant because it's about port forwarding and HTTP requests over TCP. Other categories like device, graphic, or kernel don't fit here since the issue is specific to network traffic handling between guest and host via Slirp. - - -network \ No newline at end of file -- cgit v1.2.3