[Qemu-devel] [patch] robust user-mode networking

[Qemu-devel] [patch] robust user-mode networking

[John Coiner]

OK, maybe "robust" should read "slightly less flimsy" :)

It'd be nice if these use cases worked, under user-mode networking:

  1. The user disables and re-enables a network interface in windows. 
Instead of hanging, it should come back up. (Does anyone else have this 
issue?)
  2. The host's DNS server changes. QEMU should reread the host's DNS, 
instead of requiring the user to quit QEMU and run it again. This is an 
issue on a laptop.

The patch below fixes both of these. Handling use case (2) is just a few 
lines -- It rereads host DNS info on each guest DHCP request.

The fix for use case (1) is thousands of lines, this may be controversial...

I transformed the slirp code into a reentrant version of itself. So, 
when bringing up a network card, we can dynamically allocate a slirp 
object for it. If that network card is reset, we can deallocate its 
slirp stack and allocate a fresh one.

   http://people.brandeis.edu/~jcoiner/qemu_idedma/usermode_net.patch

This required lots of typing and no thinking. When it was done, it worked.

The alternative would have been to debug the slirp stack, and understand 
how it works and why Windows leaves it in a frozen state, when disabling 
and reenabling the NIC. That might still be a good idea, considering 
Linux did not seem to have the same problem. Network experts: would you 
expect the slirp stack to be able to restart, mid-stream, without being 
explicitly told to restart? Is there a slirp design document that would 
shed light on this?

I tested the patch with Windows and Linux clients, with the '-smb' and 
'-tftp' options, on a linux host. The build is also tested on a Windows 
host.

This patch includes two other small changes in "vl.c" which I posted to 
the list a few days ago:
  * the fix to make "-smb" use the user's account rather than "nobody"
  * the fix for when the CPU tick counter leaps backward following 
suspend-to-disk.
Should I split those out?

Please let me know if this patch is helpful, or if it introduces bugs, 
or if there would have been an easier way :)

Thanks.

-- John

Re: [Qemu-devel] [patch] robust user-mode networking

[John R. Hogerhuis]

I don't know a lot about Slirp details other than what I generally know
about proxy server and NAT router implementation (I know a lot about
that). But perhaps I can raise some questions for you.

On Wed, 2005-10-12 at 22:34 -0400, John Coiner wrote:

> The alternative would have been to debug the slirp stack, and understand 
> how it works and why Windows leaves it in a frozen state, when disabling 
> and reenabling the NIC. 


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. Unless you can think of
other uses for a Slirp stack resettable independent of qemu itself, it
seems like overkill. However, such a feature might well have some
general utility though, so it seems like it would be a waste not to
include it. Maybe you could explain why you find a need to
disable/re-enable the network card...

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. Maybe that's what is supposed to
happen. Maybe it doesn't matter either way, since this is the kind of
thing firewalls do all the time. Applications are supposed to be able to
deal with it.


-- John.

[Qemu-devel] Re: [patch] robust user-mode DHCP

[John Coiner]

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

Re: [Qemu-devel] Re: [patch] robust user-mode DHCP

[John R. Hogerhuis]

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.