Hi Samuel, Thanks for the clarification! I missed the email so didn't reply in time, but was able to figure it out.
Hi everyone, IPv6 guestfwd works in my local test but it has a weird bug: if you send two requests, the first one gets the correct response, but the second one gets stuck. I am using a simple http server for this test, and just noticed this bug also exists in IPv4 guestfwd. I've documented it in https://gitlab.com/qemu-project/qemu/-/issues/1835. Just want to check if anyone has seen the same issue before. Thanks! Felix On Thu, Jul 20, 2023 at 7:54 AM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > Hello, > > Felix Wu, le mar. 18 juil. 2023 18:12:16 -0700, a ecrit: > > 02 == SYN so it looks good. But both tcpdump and wireshark (looking into > packet > > dump provided by QEMU invocation) > > Which packet dump? > > > I added multiple prints inside slirp and confirmed the ipv6 version of > [1] was > > reached. > > in tcp_output function [2], I got following print: > > qemu-system-aarch64: info: Slirp: AF_INET6 out dst ip = > > fdb5:481:10ce:0:8c41:aaff:fea9:f674, port = 52190 > > qemu-system-aarch64: info: Slirp: AF_INET6 out src ip = fec0::105, port > = 54322 > > It looks like there should be something being sent back to the guest, > > That's what it is. > > > unless my understanding of tcp_output is wrong. > > It looks so. > > > To understand the datapath of guestfwd better, I have the following > questions: > > 1. What's the meaning of tcp_input and tcp_output? My guess is the > following > > graph, but I would like to confirm. > > No, tcp_input is for packets that come from the guest, and tcp_output is > for packets that are send to the guest. So it's like that: > > > tcp_input write_cb host send() > > QEMU --------> slirp -----------> QEMU --------------------> host > > <-------- <--------- <----------------- > > tcp_output slirp_socket_recv host recv() > > > 2. I don't see port 6655 in the above process. How does slirp know 6655 > is the > > port that needs to be visited on the host side? > > Slirp itself *doesn't* know that port. The guestfwd piece just calls the > SlirpWriteCb when it has data coming from the guest. See the > documentation: > > /* Set up port forwarding between a port in the guest network and a > * callback that will receive the data coming from the port */ > SLIRP_EXPORT > int slirp_add_guestfwd(Slirp *slirp, SlirpWriteCb write_cb, void *opaque, > struct in_addr *guest_addr, int guest_port); > > and > > /* This is called by the application for a guestfwd, to provide the data > to be > * sent on the forwarded port */ > SLIRP_EXPORT > void slirp_socket_recv(Slirp *slirp, struct in_addr guest_addr, int > guest_port, > const uint8_t *buf, int size); > > Samuel >
