From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ERZFa-0006e1-U7 for qemu-devel@nongnu.org; Mon, 17 Oct 2005 13:58:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ERZFa-0006dj-1E for qemu-devel@nongnu.org; Mon, 17 Oct 2005 13:58:18 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ERZFZ-0006dg-TY for qemu-devel@nongnu.org; Mon, 17 Oct 2005 13:58:17 -0400 Received: from [69.17.117.30] (helo=mail28.sea5.speakeasy.net) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1ERZFZ-0001h7-WC for qemu-devel@nongnu.org; Mon, 17 Oct 2005 13:58:18 -0400 Received: from dsl081-088-222.lax1.dsl.speakeasy.net (HELO [192.168.111.2]) (jhoger@[64.81.88.222]) (envelope-sender ) by mail28.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 17 Oct 2005 17:57:43 -0000 Subject: Re: [Qemu-devel] Re: [patch] robust user-mode DHCP From: "John R. Hogerhuis" In-Reply-To: <4353062A.1060106@stanfordalumni.org> References: <434DC79D.5040100@stanfordalumni.org> <1129175662.13382.111.camel@aragorn> <4353062A.1060106@stanfordalumni.org> Content-Type: text/plain Date: Mon, 17 Oct 2005 10:58:55 -0700 Message-Id: <1129571935.20565.15.camel@aragorn> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: jhoger@pobox.com, 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 On Sun, 2005-10-16 at 22:02 -0400, John Coiner wrote: > 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. > I seem to recall this coming up for an IP sharing router I worked on the firmware for. There were several compatibility glitches with Windows and the DHCP implementation we had bought from General Software, and I believe this was one of them. Good find! > 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. Actually, I think what you did would be nice to have if it was available as a command from the monitor rather than triggered off a network card reset. A proxy server is much like a firewall. In real life, I have had to reset my firewalls on occasion, so I can imagine it would come in handy with Slirp too. -- John.