DOS ain't dead

Does anybody know how to configure my system (host: Windows 2000, guest: some DOS, QEMU 0.9.1 + TAP-Win32 Virtual Network Driver) for Internet access from a QEMU DOS session? DHCP would be nice. I already read lots of web pages w/o success.

---
Forum admin

> Does anybody know how to configure my system (host: Windows 2000, guest:
> some DOS, QEMU 0.9.1 + TAP-Win32 Virtual Network Driver) for Internet
> access from a QEMU DOS session? DHCP would be nice. I already read
> lots of web pages w/o success.

I find the DOS NIC drivers (or perhaps QEMU's emulation of the NICs...) to be a bit buggy.

Use:

qemu -net nic,model=ne2k_isa

The NE2000 packet driver should then work.

Note that with this setup, the network is sort of emulated as well. DHCP will give you an IP of 10.0.2.15, and your host PC will be 10.0.2.2. Keep in mind that the host can't contact the emulated PC directly.

You need to use '-net socket' if you want to do the more complicated networking :)

> I find the DOS NIC drivers (or perhaps QEMU's emulation of the NICs...) to
> be a bit buggy.

What problems did you have?

> qemu -net nic,model=ne2k_isa

That ne2k_isa was a big step forward. Before, packet driver loaded "successfully", but showed all FF for the MAC address.

Did anybody try model "rtl8319"? I tried, but packet driver version 3.44 hung.

> The NE2000 packet driver should then work.

I use the one from "pktd11.zip".

> Note that with this setup, the network is sort of emulated as well. DHCP
> will give you an IP of 10.0.2.15, and your host PC will be 10.0.2.2. Keep
> in mind that the host can't contact the emulated PC directly.

I use -net nic,model=ne2k_isa -net tap,ifname=tap0 now, but I'm still not satisfied, because there are too many things hard-coded now. I had to turn off DHCP for my real NIC (192.168.0.176), because I had to tell my real router (192.168.0.20) how to find QEMU's subnet (route traffice for 192.168.200.1/255.255.255.0 over 192.168.0.176). That would be OK for one network, but I'm connected to two networks at least (one at work, the other at home).

Here's my current configuration:

Host OS

Broadcom NetXtreme Gigabit Ethernet:
IP address     : 192.168.0.176
Subnet mask    : 255.255.255.0
Default gateway: 192.168.0.20
DNS server     : 192.168.0.20

TAP-Win32 Adapter V8:
IP address     : 192.168.200.1
Subnet mask    : 255.255.255.0
Default gateway: 192.168.0.20
DNS server     : 192.168.0.20

Guest OS

NE2000:
IP address     : 192.168.200.2
Subnet mask    : 255.255.255.0
Default gateway: 192.168.200.1
DNS server     : 192.168.0.20

I would like to remove this permanent route from my real router to get DHCP back for my real NIC. Any idea?

---
Forum admin

> Does anybody know how to configure my system (host: Windows 2000, guest:
> some DOS, QEMU 0.9.1 + TAP-Win32 Virtual Network Driver) for Internet
> access from a QEMU DOS session? DHCP would be nice. I already read
> lots of web pages w/o success.

Networking with QEMU in a Windows host is relatively easy I think. IIRC, after installing the Win32 tap driver, making some small adjustments to the network, and then installing Network Client for DOS (with NDIS2PKT converter; I didn't use the packet driver directly), both Internet and LAN access (TCP/IP over DHCP) should work fine in a QEMU DOS session. I don't really remember some of the details now (which was done about 2 years ago), but I hope it will help to some extent.

The real challenge is how to get networking with QEMU to work in a DOS host (i.e. when running QEMU under HX in DOS). Although I have tried to find a DOS tap driver, there does not seem to exist one. Any suggestions are welcome.

> > be a bit buggy.
>
> What problems did you have?

Same as you. NE2000 driver shows FF:FF:FF:FF:FF:FF for ne2k_pci, and the rtl8139 driver locks up. I find that I have to use rtl8139 for FreeBSD and ne2k_isa for DOS. Annoying.

> I use -net nic,model=ne2k_isa -net tap,ifname=tap0 now, but
> I'm still not satisfied, because there are too many things hard-coded now.
> I had to turn off DHCP for my real NIC (192.168.0.176), because I had to
> tell my real router (192.168.0.20) how to find QEMU's subnet (route
> traffice for 192.168.200.1/255.255.255.0 over 192.168.0.176). That would
> be OK for one network, but I'm connected to two networks at least (one at
> work, the other at home).

Why not also assign your TAP device to a network of 192.168.0.x, rather than having your router switch to that of the TAP device? Mind you, I've never played with TAP stuff, so no idea.

I'd have used socket instead of tap.

> > What problems did you have?
>
> Same as you. NE2000 driver shows FF:FF:FF:FF:FF:FF for ne2k_pci, and the

I think that's a combined driver/QEMU issue. Crynwr driver is for ISA cards only, so it should fail for `ne2k_pci´, but there's probably some ISA code left over in QEMU, which makes the driver think it found an ISA card.

For `ne2k_pci´ you need pk-8029(110).zip. You can get it from Realtek.

> rtl8139 driver locks up. I find that I have to use rtl8139 for FreeBSD

I'm working on that. As a work around change rtspkt.com at file offset 0x53D7 from 76 F9 to 90 90.

> Why not also assign your TAP device to a network of 192.168.0.x, rather

How to route between 192.168.0.x and 192.168.0.x? Subnets must be different for routing. Meanwhile I found another interesting idea (bridging), but I still have to test it further.

> I'd have used socket instead of tap.

But this way you can't access a QEMU guest from another PC in your network.

---
Forum admin

> I think that's a combined driver/QEMU issue. Crynwr driver is for ISA
> cards only, so it should fail for `ne2k_pci´, but there's probably some
> ISA code left over in QEMU, which makes the driver think it found an ISA
> card.

That was my thought as well...

> For `ne2k_pci´ you need pk-8029(110).zip. You can get it from
> Realtek.

Cool, I'll replace the crynwr driver with this. It's not like I'll ever be using a PC with ISA in it.

> > rtl8139 driver locks up. I find that I have to use rtl8139 for FreeBSD
>
> I'm working on that. As a work around change rtspkt.com
> at file offset 0x53D7 from 76 F9 to 90 90.

Interesting. What's the reasoning behind the change?

> How to route between 192.168.0.x and 192.168.0.x? Subnets must be
> different for routing. Meanwhile I found another interesting idea
> (bridging), but I still have to test it further.

There wouldn't be any need to route if you can get all the devices on the same network as your router. You set everything to use your router as its "default router" and assign them all IPs from the same subnet. Should all be able to access each other.

> > I'd have used socket instead of tap.
>
> But this way you can't access a QEMU guest from another PC in your
> network.

Mrm...

I guess I see the problem with this. I guess you can't really treat emulated environments as individual network devices, since everything has to pass through your PC, which can really only have one mac address.

I'm afraid bridging does sound like the only good answer.

> I guess I see the problem with this. I guess you can't really treat
> emulated environments as individual network devices, since everything has
> to pass through your PC, which can really only have one mac address.
>
> I'm afraid bridging does sound like the only good answer.

Although, I wonder why the PC can't just act like a switch would...

Would this be a good place to mention that QEMU/Win32 has been updated?

http://www1.interq.or.jp/~t-takeda/qemu/

> QEMU on Windows
>
> This is the tentative page to provide QEMU windows port binaries as
> Kazu's proxy.
> Snapshot binaries will be provided every month.
>
> * QEMU on Windows Ver 0.9.1 (2/4/2007)
> * QEMU on Windows Snapshot (12/13/2007)

> Would this be a good place to mention that QEMU/Win32 has been updated?
>
> http://www1.interq.or.jp/~t-takeda/qemu/

At least I already knew. But I built my own QEMU binary.

---
Forum admin

> > I'm working on that. As a work around change
> rtspkt.com
> > at file offset 0x53D7 from 76 F9 to 90 90.
>
> Interesting. What's the reasoning behind the change?

The packet driver tries to read the "Timer Count Register" (TCTR), which is not emulated by QEMU's default configuration. You have to uncomment macro RTL8139_ONBOARD_TIMER in hw/rtl8139.c to activate it.

Here's Igor Kovalenko's "explanation" () for any drawbacks: IIRC it needs to fire interrupt if timer expires; currently the code just checks value at PCI timer frequency. It is possible to make that lower overhead than checking each clock cycle but it is not so now.

My patch just ends the loop that checks the card's return value.

---
Forum admin