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. _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
