From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ERKLE-0002fm-3x for qemu-devel@nongnu.org; Sun, 16 Oct 2005 22:03:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ERKLC-0002fZ-Hv for qemu-devel@nongnu.org; Sun, 16 Oct 2005 22:03:07 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ERKLC-0002fV-Ct for qemu-devel@nongnu.org; Sun, 16 Oct 2005 22:03:06 -0400 Received: from [206.46.252.48] (helo=vms048pub.verizon.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ERKLC-0008Oe-41 for qemu-devel@nongnu.org; Sun, 16 Oct 2005 22:03:06 -0400 Received: from [192.168.1.2] ([70.109.242.150]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IOH00D7JF0WQRV0@vms048.mailsrvcs.net> for qemu-devel@nongnu.org; Sun, 16 Oct 2005 21:02:57 -0500 (CDT) Date: Sun, 16 Oct 2005 22:02:18 -0400 From: John Coiner In-reply-to: <1129175662.13382.111.camel@aragorn> Message-id: <4353062A.1060106@stanfordalumni.org> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit References: <434DC79D.5040100@stanfordalumni.org> <1129175662.13382.111.camel@aragorn> Subject: [Qemu-devel] Re: [patch] robust user-mode DHCP 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 John R. Hogerhuis wrote: > I have no idea what 'frozen state' means in this context. Do you? > > I guess not, since I suppose as soon as you really knew you would be in > a position to kill the fly with a fly swatter rather than running over > it with your car :-). > > Not a criticism just a nudge... this sounds like a tiny bug somewhere > that deserves squashing rather than hiding. Tell me about it :) It was a tiny bug... Windows does not like QEMU's DHCP server. Windows always issues DHCPDISCOVER and DHCPREQUEST packets in pairs: first the DHCPDISCOVER, followed by a DHCPREQUEST. The DHCPREQUEST is a sanity check. Windows wants the DHCP server to reply with the same IP for both requests, otherwise it does not consider the DHCP operation successful. QEMU's DHCP server will reply with a new IP for each DHCPDISCOVER. However, for a DHCPREQUEST, it replies with the first IP it ever gave out on the first DHCPDISCOVER. As a consequence, Windows' first DHCPDISCOVER/DHCPREQUEST pair succeeds, and every subsequent pair fails. That is why disabling and reenabling the NIC does not work, and why using the "ipconfig" program to renew the DHCP also does not work. Here's a patch to fix this: http://people.brandeis.edu/~jcoiner/qemu_idedma/qemu_dma_patch.html#dhcp This patch also forces QEMU to reread the host's DNS info on any guest DHCP request, this is useful for users whose host DNS changes often. > What happens in the normal case to the software stack when a network > card is reset? Would all TCP connections that hadn't timed out yet time > out? That is, would the set of allocated sockets be freed back to the > pool? Slirp maintains context about every connection passing through it > since it is a proxy server. So if you reset it all those connections > would be dropped. So even if the socket was left open on the guest, it > would definitely be dropped in slirp. Yeah, all the stateful connections have some kind of timeout attached, after which they vaporize. So I'd agree that there's never a need to throw away one copy of slirp and set up another one. Thanks. -- John