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

1. Build libslirp, I am using HEAD @ master.
2. Build your QEMU with user network enabled to use slirp (./configure -target-list=x86_64-softmmu --enable-slirp).
3. Ran a Python server on host listening to port 6655 (python3 -m http.server --bind :: 6655).
4. 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.
5. 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.
6. 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.