From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 20869C3DA66 for ; Wed, 23 Aug 2023 17:28:20 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qYre6-0002ps-Gk; Wed, 23 Aug 2023 13:27:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qYre5-0002pk-JZ for qemu-devel@nongnu.org; Wed, 23 Aug 2023 13:27:53 -0400 Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qYrdz-0005KE-Du for qemu-devel@nongnu.org; Wed, 23 Aug 2023 13:27:50 -0400 Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-31771bb4869so5249458f8f.0 for ; Wed, 23 Aug 2023 10:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692811664; x=1693416464; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3HVZlighhbdAt2+k8psWTUoYclNfefaHHKE7NVuFHH4=; b=G34nAXt596bUHnMUCFPojkuT6kQreAGLvS8Bl5oX5j1BKdPn69+jNDoWFEhsxjLXyc jY5adaCK5JFQUqjjXdNJRkwCySeCNfK6EthfSyth1ACylkTZxr2FWmZ60hs9flsBbHLG j7mp+bMroLsolfhKvTkm2+7Xue2O+6ICi6WOeKsmj/SZq/70lLj/RMjgv8kPFG5Ss2/Y dTdjAfthBPXm22HZkAHe6EJQL7iBoJ/LcV2aBgYWGO/RQKTWjFrcdM5xYje/60fIFpRM br8AB7gUvm8kWCccW7znkjrdw6KKPC5jn1SRtL3i4z6qsPG0DZLO7JfP36W6JPZdFt4U lzhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692811664; x=1693416464; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3HVZlighhbdAt2+k8psWTUoYclNfefaHHKE7NVuFHH4=; b=Kxs/+YodgPEhVeaXg3ST8+nJ+n72nf00hCugBeGMVErHy9fbQTA4Y8iBRbnMryvKHb 8oEj/3leAFlYG741hEnpz67nKdii+ztiPHcQ94TSQaSFssd+Hg79V0zncgvx9OT72usw BNqNioJBp1RexZGCk6edKiHMAupVuBjpFto+vupNlgN4BrUlfY3xfLP6VkIaUmJOLtBt 77ILcc+R90JPvWwejqOd2s/VEgSnHAtrrGFZET63QiTrOuEcmP7xL9TV5TpgdaNDc4+f C+5N+noTIt166cv2O47XaXsxpAliQwP2djTsiDXIwUcsaRIfGtogf2oitH9w6+W3chCb dQ8A== X-Gm-Message-State: AOJu0YwQd0tiwwBrFvFfmZTUYn10+ZL2WQSum2uM9TDA/chsjWBY062G +DJgeYaNr32+jlGCnBH8j0dJGBVrk6afOYXO7jFLdQ== X-Google-Smtp-Source: AGHT+IEe6MieqIk/+Ll4jcvdDxK1gKaAvcT5jl/GZ6K0XWCHDupF8P1erpKjmhAbBpM9rbOqioDAP1K92OJUIbcHihw= X-Received: by 2002:adf:fd44:0:b0:315:9676:c360 with SMTP id h4-20020adffd44000000b003159676c360mr8612518wrs.25.1692811664277; Wed, 23 Aug 2023 10:27:44 -0700 (PDT) MIME-Version: 1.0 References: <20230626114916.45355529@mobian.usb.local> <20230626100819.vtkuuvzg376hktk2@begin> <20230720145415.w7s3ystkrf5gc66y@begin> In-Reply-To: From: Felix Wu Date: Wed, 23 Aug 2023 10:27:33 -0700 Message-ID: Subject: Re: Tips for local testing guestfwd To: Samuel Thibault Cc: Lukas Straub , qemu-devel@nongnu.org, Jason Wang Content-Type: multipart/alternative; boundary="000000000000ec598606039a6d6e" Received-SPF: pass client-ip=2a00:1450:4864:20::433; envelope-from=flwu@google.com; helo=mail-wr1-x433.google.com X-Spam_score_int: -175 X-Spam_score: -17.6 X-Spam_bar: ----------------- X-Spam_report: (-17.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org --000000000000ec598606039a6d6e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Update on debugging this thing (already updated https://gitlab.com/qemu-project/qemu/-/issues/1835): I saw that `tcp_chr_free_connection` was called after the first response being successfully sent: ``` slirp_guestfwd_write guestfwd_write: size 80tcp_chr_write tcp_chr_write: s->state:2tcp_chr_write tcp_chr_write: len:80qemu_chr_write_parameter len: 80 // tracking qemu_chr_writeqemu_chr_write_res len: 80 // same thingtcp_chr_free_connection tcp_chr_free_connection: state: 2, changing it to disconnecttcp_chr_change_state tcp_chr_change_state: state: 2, next state: 0 // state 2=3D=3Dconnected, 0=3D=3Ddisconnected. ``` And after that, the state of `SocketChardev` remained disconnected, and when the 2nd request came in, the `tcp_chr_write` dropped it directly. Maybe this state machine should be reset after every connection? Not sure. On Thu, Aug 17, 2023 at 11:58=E2=80=AFAM Felix Wu wrote: > 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=E2=80=AFAM Samuel Thibault > wrote: > >> Hello, >> >> Felix Wu, le mar. 18 juil. 2023 18:12:16 -0700, a ecrit: >> > 02 =3D=3D SYN so it looks good. But both tcpdump and wireshark (lookin= g >> 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 =3D >> > fdb5:481:10ce:0:8c41:aaff:fea9:f674, port =3D 52190 >> > qemu-system-aarch64: info: Slirp: AF_INET6 out src ip =3D fec0::105, p= ort >> =3D 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 665= 5 >> 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 >> > --000000000000ec598606039a6d6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Update on debugging=C2=A0this thing (already updated=C2=A0= https://gitlab.com/qemu-project/= qemu/-/issues/1835):
I saw that `tcp_chr_free_connection` was calle= d after the first response being successfully sent:
```
slirp_guestfwd_write gues=
tfwd_write: size 80
tcp_chr_writ=
e tcp_chr_write: s->state:2
tcp_chr_writ=
e tcp_chr_write: len:80
qemu_chr_wri=
te_parameter len: 80 // tracking qemu_chr_write
qemu_chr_wri=
te_res len: 80 // same thing
tcp_chr_free=
_connection tcp_chr_free_connection: state: 2, changing it to disconnect
tcp_chr_chan=
ge_state tcp_chr_change_state: state: 2, next state: 0 // state 2=3D=3Dconn=
ected, 0=3D=3Ddisconnected.
```
And after that, the state of `SocketChardev`= remained disconnected, and when the 2nd request came in, the `tcp_chr_writ= e` dropped it directly.
Maybe this state machine should be reset = after every connection? Not sure.

On Thu, Aug 17, 2023 at 11:58=E2=80= =AFAM Felix Wu <flwu@google.com&g= t; wrote:
Hi Samuel,

Thanks for the clarification! I mi= ssed the email so didn't reply in time, but was able to figure it out.<= /div>

Hi everyone,
IPv6 guestfwd works in my l= ocal test but it has a weird bug: if you send two requests, the first one g= ets the correct response, but the second one gets stuck.
I am usi= ng a simple http server for this test, and just noticed this bug also=C2=A0= exists in=C2=A0IPv4 guestfwd. I've documented it in=C2=A0https://gitlab.com/qemu-project/qemu/-/issues/= 1835.

Just want to check if anyone has seen th= e same issue before.

Thanks! Felix

=
On Thu, Ju= l 20, 2023 at 7:54=E2=80=AFAM Samuel Thibault <samuel.thibault@gnu.org> wrote:<= br>
Hello,

Felix Wu, le mar. 18 juil. 2023 18:12:16 -0700, a ecrit:
> 02 =3D=3D SYN so it looks good. But both tcpdump and wireshark (lookin= g 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 =3D
> fdb5:481:10ce:0:8c41:aaff:fea9:f674, port =3D 52190
> qemu-system-aarch64: info: Slirp: AF_INET6 out src ip =3D fec0::105, p= ort =3D 54322
> It looks like there should be something being sent back to the guest,<= br>
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 qu= estions:
> 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:

> =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0tcp_input=C2=A0 =C2=A0 write_cb=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 host send()
> QEMU --------> slirp -----------> QEMU --------------------> = host
> =C2=A0 =C2=A0 <-------- =C2=A0=C2=A0 =C2=A0 =C2=A0 <---------=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<-----------------
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tcp_output =C2=A0slirp_socket_recv= =C2=A0 =C2=A0 host recv()

> 2.=C2=A0I don't see port 6655 in the above=C2=A0process. 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 th= e
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
=C2=A0* callback that will receive the data coming from the port */
SLIRP_EXPORT
int slirp_add_guestfwd(Slirp *slirp, SlirpWriteCb write_cb, void *opaque, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0struct in_addr *guest_addr, int guest_port);

and

/* This is called by the application for a guestfwd, to provide the data to= be
=C2=A0* sent on the forwarded port */
SLIRP_EXPORT
void slirp_socket_recv(Slirp *slirp, struct in_addr guest_addr, int guest_p= ort,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0const uint8_t *buf, int size);

Samuel
--000000000000ec598606039a6d6e--