Getting Qemu’s NetWare 3.12 onto the LAN with Tun/Tap

I could also call this ‘going with the flow’… So instead of fighting the system, like I usually do today we are going to do things the way everyone else enjoys doing things, and that is building stuff with tun/tap and bridges.

YUCK.

Ok, so I’m using Windows, and that is what I’m assuming you are as well for this ‘guide’.

The first thing you’ll need is the tun/tap driver for Windows, and the easiest way to get that is via OpenVPN.  The next thing you’ll need is Qemu, again I’m just using the pre-compiled stuff right here.

Go ahead, and install them both.  With OpenVPN installed, when you open your control panel, and check out your network interfaces you’ll see something like this:

One NIC, One Tap

One NIC, One Tap

Good.

Now for my example, I’m going to add another TAP interface.  TAP’s are only good for a 1:1 relationship with the VMs.  Yes, that is why I prefer something else, but again we are going to do things today the way everyone else does them.

Now for me, I run the ‘addtap’ batch file located in the C:\Program Files\TAP-Windows\bin folder as Administrator, and this now gives me two TAP adapters.  I highly recommend disabling TCP/IP v4 and v6 on the TAP adapters, along with the MS client/server stuff.  We are only using these for bridging the VMs so we dont’ need the host computer to participate in this network.

Now for the fun part.  I’m assuming you have your NetWare server and client images all ready to go (I guess I can go over installation again some other day), and now we get to bind each one to a SINGLE TAP instance.  Also don’t forget that each machine needs a UNIQUE MAC address.  One of them can use the default settings, but the other one cannot.

I’m going to start my server like this:

\Progra~1\qemu\qemu-system-i386.exe -m 16 -hda netware312.disk -device ne2k_isa,netdev=usernet,mac=52:43:aa:00:00:11,irq=10,iobase=0x300 -netdev “tap,ifname=Local Area Connection 2,id=usernet”

As you can see, this gives me a NE2000 on port 0x300, IRQ 10 and sets the MAC address to 52:43:aa:00:00:11 .  And this sets it on the first TAP adapter, lovingly called “Local Area Connection 2″ because the primary adapter is called “Local Area Connection“.  Also take note of the quotes in this command line, as it’ll encapsulate the full default name of the TAP adapter.  The other alternative is to just rename the adapters, but where is the fun in that?

Now for my client:

\Program Files\qemu\qemu-system-i386.exe” -m 16 -hda client.disk -soundhw sb16,adlib,pcspk -device ne2k_isa,irq=10,iobase=0x300,netdev=usernet -netdev “tap,ifname=Local Area Connection 3,id=usernet”

As you can see the primary difference here is that it’s connected to “Local Area Connection 3” which is my second TAP interface.

Now with both virtual machines running the interfaces will turn on!

But as you’ll quickly discover, neither machine can talk to each-other, as they are islands so to speak.

Two virtual machines on islands.

Two virtual machines on islands.

Now for the fun part, we highlight the two TAP interfaces, right click, and turn on the built in bridge function of Windows!

highlight and select

highlight and select

And once that is done, a new Network Bridge interface will show up, transfer what layer 3 settings there are, and then setup the layer 2 bridge between the TAP interfaces.

Bridge activating...

Bridge activating…

And once the bridge interface has gone live, give spanning tree 15 seconds to do it’s thing, and YES you can now login to the NetWare server!

Logging in from the MS-DOS VM to the NetWare 3.12 VM

Logging in from the MS-DOS VM to the NetWare 3.12 VM

And there you go!  This is the ‘approved’ way to do virtual networking with Qemu.

Now I know what you are thinking, this is great for VM’s and all that jazz, but what if I say have an office FULL of old PC’s and I want them onto my new fangled ancient server?

No problem, right click on the bridge, and select delete.  This will put everything back the way it was, sending the VMs back to their own TAP interfaces.  Now select all the interfaces, and then setup a bridge (I suppose you could edit the existing one to include the physical interface…) and now once the bridge has been setup, it’ll now be talking out the local Ethernet interface.

One quick note, bridging and WiFi tend to not go hand in hand.  Some interfaces will work, but the rule seems to be the vast majority of setups will not.  So don’t complain if yours didn’t work, you are just part of the 99.99999%.  And if you did get yours to work, well good for you.

Novell Netware 3.12 once more runs on Qemu!

This version of Qemu seems to be one of the better ones in a LONG LONG time.

Netware 3.12

Netware 3.12

Much to my amazement, as I fully expected this to crash much like all the other versions, it actually runs.

qemu-system-i386.exe -m 16 -hda netware312.disk -device ne2k_isa,irq=10,iobase=0x300 -soundhw pcspk -serial none -parallel none -k en-us

I’m just more amazed it works.  Now I did try it on my old setup of a NE2000 on 0x300 Interrup 2/9 but I was getting some IRQ issues.  So I went ahead and reconfigured Netware for IRQ ‘A’, and set the CLI for 10. Of course I haven’t actually tested networking, this is really a ‘wow it did something’ statement.  No doubt I’ll have to build a new GNS3 test bed with this Qemu, and see how Netware performs.

Announcing HECnetNT!

HECnetNT in action!

HECnetNT in action!

So I have my little project working well enough to let it out into the world.  I call it HECnetNT, and it’s available out on sourceforge.

It’s a port of  Johnny Billquist‘s bridge program to Windows.  This isn’t a MinGW or Cygwin build, but rather, a native build, compiled in Visual Studio 2003.  I’ve been able to run this build on NT 4.0, 2000 and Windows 7.

I also made some additions to the bridge program, by allowing it to bridge IPX/SPX Ethernet_II frames, so you can now build legacy networks that let you logon to NetWare servers, or even play those old IPX/SPX games.

Back when I first got DOOM v1.1 working on IPX/SPX I noticed that it sent an incredible amount of packets that were mostly empty.  To work around this, I incorporated LZSS to compress data between HECnetNT bridges.  Even better, I don’t see any significant CPU utilization, even with DOOM blasting packets like crazy!

The best part is that you can mix compressed & uncompressed bridges.  So you can have an uncompressed connection to one host, and a compressed connection to another.

I’ve been able to bridge CTERM with SIMH to hosts using compressed, and uncompressed links, and this also includes a LINUX box with the original bridge software!

To take it one more step, I also setup a Windows NT box with an ethernet adapter, and the MS LOOPBack adapter, setup TCP/IP on both interfaces (a dummy address on the loopback is enough, but there needs to be something there), and then installed DEC Pathworks 7, on NT, bound it to the loopback adapter, ran the HECnetNT software, and I’ve been able to connect my NT instance.  Logically I could go one more step, and install PPTP support, so I the NT server could then use PPTP to VPN to a HECnet bridge, and then join it.

So the larger question is, the DECnet enthusiasts have their hecnet, is anyone interested in making a Novell like equivalent?  With older Linux that supports IPX/SPX or even NT we could even do routers, and build a large-ish sized network.

GNS3 + VMWare +Netware 3.12

So continuing from where I left off, I thought I’d setup a small Netware network onto my GNS3 testbed.

Netware was once the big dog in the networking world, but now it’s just a footnote in obscurity.  Long gone are the days of syscon, rconsole, and all the frametypes that Netwaer supported in equally incompatible ways.  So maybe it’s a good thing.

But I digress, years ago I paid good money for a 50 user version of Netware 3.12.  I don’t know why either, but I occasionally like to get it running so I don’t feel like I completely wasted the thing.

With the right lan drivers, installation is a snap.  Or if you don’t have the right lan drivers, create a MS-DOS VM, so it’ll have an IDE hard disk.  You can install netware without lan drivers just fine.  I just installed netware by itself, then added in some patches for the network card & the idle program so it wouldn’t eat 100% of my CPU.  For the network though the command line was a little weird but I worked it out

file server name vmware
ipx internal net 538787d
mount all
load c:\server.312\nw4-idle.nlm
load c:\server.312\pcntnw slot=10001 FRAME=Ethernet_802.2
BIND IPX to pcntnw NET=cab2
load remote password
load rspx

Which gets me networking, and rconsole support.  With the server running, I just then had to enable IPX routing on my cisco routers.
R1

ipx routing ca00.1b00.0008
interface FastEthernet0/1
ipx encapsulation SAP
ipx network CAB1
interface Serial1/0
mtu 2000
ipx network CAB0

R2

ipx routing ca08.140c.0008
interface FastEthernet0/1
ipx encapsulation SAP
ipx network CAB2
interface Serial1/0
mtu 2000
ipx network CAB0

 Now with this all in place I can see the IPX routes from R1, including the one that goes directly into the server:

R1#show ipx route
Codes: C – Connected primary network, c – Connected secondary network
S – Static, F – Floating static, L – Local (internal), W – IPXWAN
R – RIP, E – EIGRP, X – External, A – Aggregate
s – seconds, u – uses, U – Per-user static/Unknown, H – Hold-down

4 Total IPX routes. Up to 1 parallel paths and 16 hops allowed.

No default route known.

C CAB0 (HDLC), Se1/0
C CAB1 (SAP), Fa0/1
R CAB2 [07/01] via CAB0.ca08.140c.0008, 56s, Se1/0
R 5383787D [08/02] via CAB0.ca08.140c.0008, 56s, Se1/0

And of course I can see the server!

R1#show ipx servers
Codes: S – Static, P – Periodic, E – EIGRP, H – Holddown, + = detail
U – Per-user static
2 Total IPX Servers

Table ordering is based on routing and server info

Type Name Net Address Port Route Hops Itf
P 4 VMWARE 5383787D.0000.0000.0001:0451 8/02 2 Se1/0
P 107 VMWARE 5383787D.0000.0000.0001:8104 8/02 3 Se1/0

Now if you remember from the bad old days of Netware, each service running on a server is advertised.  So in this case, type 4 is a file/print server, and 107 is a server running the ‘remote’ facility so you can rconsole into it.

Another thing to take note, is that because I configured IPX on serial interfaces is that their encapsulation is always HDLC.  Also because IPX cannot fragment like TCP/IP the MTU on the serial interface *MUST* be larger than ethernet’s 1500.  I like 2000 as I avoid all frame overhead this way.

Now I’m using the old netware client with the drivers I found here, and it works fine, as long as I had the MTU bumped up on the serial interface.  Now I could have used ethernet, and it’d achieve the same thing, except I’m not in some weird MTU war.

IPX network

IPX network

SA-COMP/1

SA-COMP/1

At the same time, it is very slow.  If you want to do anything reasonably fast, you really need to move your client to the same VNet as the server.  But if you want to feel like the old days when connections were slow, well you’ll enjoy a max 400k connection.  I tried enabling stacker compression on the interface, but it resulted in packet corruption.  I think it’s an IOS thing though, so if you play with this, you may have better luck.  Back before MPLS was everyone’s latest wan joy, I ran stacker compression, and the speed boost was really noticeable, with a 1.5:1 or 2:1 compression not being uncommon.  Although on lower routers it could be a killer (the 2500…) or a 7000 with multiple interfaces doing compression it could also bring a router to it’s knees.  Also looking at the support table for the  SA-COMP/1  SA-COMP/4 I doubt 12.4 would support stacker compression properly.

Platform Recommended Minimum Cisco IOS Release
Cisco 7000 series and Cisco 7500 series With VIP2-40(=) Cisco IOS Release 11.1(6)CA or a later release of Cisco IOS Release 11.1 CA
Cisco 7000 series and Cisco 7500 series With VIP2-50(=) Cisco IOS Release 11.1(14)CA or a later release of Cisco IOS Release 11.1 CA
Cisco 7204 and Cisco 7206 Cisco IOS Release 11.1(6)CA or a later release of Cisco IOS Release 11.1 CA1
Cisco 7204 and Cisco 7206 Cisco IOS Release 12.2(4)B or a later release of Cisco IOS Release 12.2 B

Otherwise, yeah it works fine.  I also loaded up a Windows NT client, and it works too!

Yet another update for Novell Netware 3.12

I managed to come across this link, which details some installation experience with Netware 3.12 on VMWare.

What is more interesting is that someone mentions that it’ll run on VirtualBOX!

So downloading their toolset and whatnot I proceed to install on VirtualBOX, and get a booting Netware 3.12 system using the ISADISK driver… I couldn’t find the IDEHAM thing but you get the idea, it actually WORKS!

Novell Netware 3.12 on VirtualBOX!

I’ve got to admit I’m really surprised!  So for the heck of it I try the same disk image on Qemu and get…

CRASH...

The usual panic/crash after mounting a disk volume.  Its a damned shame, but hell at least there is something out there that can run Novell Netware!!!

Someone had mentioned dinosaurs …

ROAR!

Once upon a time Novell had been an unstoppable force.  Then something happened they stopped innovating, and laughed as a ‘desktop’ unix killer did just that and ate the mid range/server PC market.

With all that’s been happening to RIM and all the cash they are sitting on I wonder if they’ll end up like Novell.

Time will tell no doubt.

 

 

AMD PCNet with Netware 3.12

Well I found out that the AMD PCnet driver will work on Netware 3.12 on Qemu 0.9.0 with a little cajouling. So to switch from the NE2000, I first downloaded the following files:

*odi33g.exe
*odi_ahsm_svr3x.zip
*nw4-idle.nlm

From odi33g.exe, copy out the following files to your server directory

\server\33spec\ethertsm.nlm
\server\33spec\312\msm31x.nlm
\server\33spec\312\nbi31x.nlm

Your server directory should contain…

nbi31x.nlm
ethertsm.nlm
msm31x.nlm
pcntnw.lan
pcntnw.ldi
nw4-idle.nlm

Then configure your autoexec.ncf like this…

load c:\server.312\msm31x
load c:\server.312\pcntnw slot=2 frame=ETHERNET_II
bind ipx to pcntnw net=c0ffcab
load c:\server.312\nw4-idle

I’m not sure about the speed, but the idle NLM is fantastic, it means that your VM won’t run at 100% cpu…

Wasn’t that fun?

Revisiting Netware 3.12

I know this is one of the really ‘hot issue’ things out there. Sadly the thing is that Qemu ran Netware 3.12 back in the 0.90 release, but not any release since then has been able to run it.

And after testing Netware 4.1 & 4.11 they too only run acceptably under Qemu 0.90

Otherwise on the newer versions, I get nothing but disk errors, even trying to used some 3rd party updated IDE drivers, it still does not work.

It’s very perplexing, and at the same point I know it’s not a burning priority for the Qemu team….

Proxmox/VE gets much further but ultimately I couldn’t get it all working…

Apparently it’ll run on VMWare, more information here.

One thing is for sure, Netware 3.12 and it’s “patching” system is a major nightmare.

Any Qemu higher then 0.9.0 gives this error….

“Abend: A directory buffer with no dirty bits set was encountered on the dirty list”

qemu 0.14.0 netware abend

qemu 0.14.0 netware abend

While there is the ‘scsi option’ for Qemu 0.12 and higher, you’ll need a BIOS… However for 3.12 it hinges on the DOS driver, which when loaded… crashes out Qemu.

Some fun networking with MS-DOS & Novell Netware.

Ok I wanted to do this eventually but now I’ve finally done it. I have constructed something a little complex but it works surprisingly well.

Let me draw a picture so it’ll be a little easier to follow:

proxmox Netware diagram

proxmox Netware diagram

 

All of the machines in clouds are virtual…

Ok I’m going to assume you can install & configure OpenVPN on your own. I did a really simple install on Proxmox VE, just be sure to use the e1000 network adapters. All the others gave me tones of errors with any sizable traffic. Also I should point out that I’m using OpenBSD 4.3 which is the latest as of today.

dev tun0
dev-type tap
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
dh /etc/openvpn/dh1024.pem
key /etc/openvpn/server.key
server-bridge 192.168.6.33 255.255.255.224 192.168.6.50 192.168.6.62
push “route 192.168.6.0 255.255.255.0”
push “dhcp-option DNS 192.168.6.34”
client-to-client
duplicate-cn
keepalive 10 120
max-clients 100
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 3
tun-mtu 1500
fragment 1300
mssfix
float

Again I just followed the example from the OpenVPN site to set this up. What makes this different though is the fact that I’m using this in a bridge mode. As you can see I have told OpenVPN that it is to use the tun0 interface as a ‘tap’ driver.

My hostname.tun0 is this:
Link0 up

Likewise the bridgename.bridge0 is:
add em1
add tun0
up

And finally for this example my bridgename.em1 is:
inet 192.168.6.33 255.255.255.224 NONE

So using this setup I have a ‘private’ 192.168.6.32/27 network in which I’ve got a few virtual machines running and space for my laptop to VPN into. Now one of the virtual servers on my Proxmox server is Windows NT 4.0 Terminal Server… Yeah I know I got it cheap on ebay, and I kind of like it. Anyways I’m running Qemu on it, which is running Netware 3.12. I installed the libpcap then I had to find out what my Ethernet devices are called. I used wireshark (it was ethereal) and it’s a cool program to have around. The last version to run under Windows NT 4.0 was 0.99.4 so that’s the one I used. Once I have done this I found my device and was able to setup a string for Qemu (which was \Device\NPF_RTL80291)

Here is what I’m using:

Qemu –had netware.disk –m 16 –M isapc –L pc-bios –net nic –net pcap,devicename=”\Device\NPF_RTL80291”

This sets up an ISA computer with 16 megaybtes of ram and a single ISA nic that will utilize libpcap to send out frames on the rtl80291 that’s being emulated to my NT terminal server by proxmox.

On the ‘client’ side of things, I’m running the 64 bit version of Vista. So I’ve installed the OpenVPN that not only has 64 bit device drivers, but has a nice little GUI to connect & disconnect from the networks. Here is the OpenVPN config that is on my laptop.

dev tap
ca ca.crt
cert client1.crt
key client1.key
client
proto udp
remote 192.168.1.75 1194
resolv-retry infinite
nobind
persist-key
persist-tun
;comp-lzo
mssfix
tun-mtu 1500
fragment 1300

Ok, so far so good. Now I do have Virtual PC 2007 on my laptop, and I have made sure that the “Virtual Machine Network Services” were bound to the “TAP-Win32 Adapter V9” interface.

The it’s a simple matter of connecting to the VPN, then loading up the virtual PC with MS-DOS & the Novell Netware client.

Then you should be able to ‘bind’ to the server & login!

dos netware client

dos netware client

The ‘cool’ thing about this setup is that it will work over things like wifi, and easily allow you to add clients near & far. Oh and the best part for the wifi crowd is that it will use REAL encryption since WEP/WPA have all been shown to be useless. Oh yes, and it should allow you to host your DOOM, Quake 1, Rise of the Triad, Warcraft II, and Descent games…. Along with people playing at home! Using this you too can build your own IPX/Internet network!

I do hope this clears some of the uses & versility of Virtual servers, Qemu & Virtual Networking.

Netware 3.12 with Qemu

Ok I’m getting more requests on this which means I’ll finally do it.. I didn’t mean to put it off THIS long, honestly!

I have issues with Qemu 0.91 under Vista so this will all be with Qemu 0.90.

I have built a version with the libpcap compiled in, and placed a copy of the winpcap that I’m using in with this zip.

You can download the libpcap enable Qemu for Win32 right HERE.

I’m using the enclosed 1.cmd to run the thing, and I’ll go over more of it tomorrow.