From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EeCar-0007HP-IG for qemu-devel@nongnu.org; Mon, 21 Nov 2005 09:24:30 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EeC9U-0008PR-CA for qemu-devel@nongnu.org; Mon, 21 Nov 2005 08:56:14 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EeBXv-0006s1-Cd for qemu-devel@nongnu.org; Mon, 21 Nov 2005 08:17:27 -0500 Received: from [64.233.162.203] (helo=zproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EeBXu-0005Wk-O6 for qemu-devel@nongnu.org; Mon, 21 Nov 2005 08:17:23 -0500 Received: by zproxy.gmail.com with SMTP id z3so669237nzf for ; Mon, 21 Nov 2005 05:15:41 -0800 (PST) Message-ID: <2ad73a0511210515i46099f45y4adef0261088a59d@mail.gmail.com> Date: Mon, 21 Nov 2005 11:15:41 -0200 From: =?ISO-8859-1?Q?Andr=E9_Braga?= Subject: Re: [Qemu-devel] user-net -redir working? In-Reply-To: <1132554880.6973.155.camel@aragorn> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4380FC9D.2020706@hermes.cam.ac.uk> <1132554880.6973.155.camel@aragorn> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Disabling the Nagle algorithm (i.e., enabling TCP_NODELAY) or typing a lot of garbage just to fill the buffer with enough data can help, also. And IIRC, netcat has a UDP mode as well. I see no reason for this to happen, but is there any chance it's using UDP by default, and you're only redirecting TCP? Good luck! -- "The user-friendly computer is a red herring. The user-friendliness of a book just makes it easier to turn pages. There's nothing user-friendly about learning to read." -Alan Kay On 11/21/05, John R. Hogerhuis wrote: > On Sun, 2005-11-20 at 22:45 +0000, Richard Neill wrote: > > This connection is accepted (Netcat doesn't say connection refused), > > but then no data is ever transferred. [8<] > Without more data, I'd vote for (a). It sounds like netcat is behaving > normally to me. Since you are typing this at the prompt, netcat is > dutifully waiting for you to type something to send over the link. > > Perhaps if you type something on the client side and hit ? Then > see if it shows up on the server side. > > If you don't get any output on the server side, a network sniffer > (tcpdump) on both sides of the connection should be illuminating. >