robust user-mode networking

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

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.

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.

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.

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

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!

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.