Running Netware 3.12 on Qemu / KVM 2.8.0

So yeah, let’s build a NetWare 3.12 server! I’ve covered this over and over and over, but heh let’s do it again!

First things first, the default position of the NE2000 card at 0x300/IRQ 9 does NOT WORK.  This is the biggest stumbling block, and time waster right there.  I loaded a PCnet driver, and it didn’t lock, but it didn’t work.  I loaded 2 ne2000’s thinking the second would come up in the correct position but that didn’t work either.  The solution of course is to dive into the parameters for QEMU to drive devices.

So for the fun of it, here is how I’m going to run this in a nested VM.  It’s also why I didn’t bother enabling the ‘-enable-kvm’ flag.  Although on a real machine I would.

qemu-system-i386 -m 16 \
-cpu 486 \
-net none \
-vnc :1 \
-device ne2k_isa,mac=00:2e:3c:92:11:01,netdev=lan,irq=11,iobase=0x320  \
-netdev vde,id=lan,sock=/tmp/local \
-hda netware312.qcow2 \
-hdb netware312_data.qcow2 \
-parallel none \
-monitor tcp::4400,server,nowait

So the key portion here is the iobase & irq.  This let’s me sidestep the IRQ 9, port 0x300 issue.  Talking to the monitor and running ‘info qtree’ I’m able to look at the parameters that I can pass the network card:
bus: isa.0
type ISA
dev: ne2k_isa, id ""
  iobase = 800 (0x320)
  irq = 11 (0xb)
  mac = "00:2e:3c:92:11:01"
  vlan = 
  netdev = "lan"
  isa irq 11

As you can see there is actually a few further things I could have set, but the key ones here being the iobase, the irq, the mac address, and then assigning it to a netdev, in this case I then bind it to a VDE.

Now the fun part goes back to the old days of Netware when your network could run several possible frame times.  If you have 2 machines with different frames, they will not see each-other.  it was a cheap way to hide networks well until the wide spread availability of sniffers.  Naturally cisco and Novell have different terms for the same things.  Below are the ones that are relevant to Ethernet:

Frame Types
Novell cisco
ETHERNET_802.3 novell-ether
ETHERNET_802.2 sap
ETHERNET_Snap snap
ETHERNET_II arpa

So in my case on my Netware server I simply load my NE2000 like this:

LOAD NE2000 PORT=320 INT=A FRAME=ETHERNET_802.3
BIND IPX TO NE2000 NET=800852

Next on my cisco router I simply need:
ipx routing ca00.06a3.0000

interface FastEthernet0/0
ipx network 800852

And now I can see my server from the router:
HKOffice#sho ipx servers
Codes: S - Static, P - Periodic, E - EIGRP, N - NLSP, H - Holddown, + = detail
U - Per-user static
1 Total IPX Servers

Table ordering is based on routing and server info

Type Name Net Address Port Route Hops Itf
P 4 HONGKONG 852.0000.0000.0001:0451 2/01 1 Fa0/0
HKOffice#

And the interface looks busy on NetWare

NetWare 3.12

NetWare servers advertise their internal networks, much like how people should be using loopback adapters in OSPF, or EIGRP … So if you check the IPX routing table, you’ll see the wire route to the internal network:

HKOffice#sho 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, N - NLSP, X - External, A - Aggregate
s - seconds, u - uses, U - Per-user static/Unknown, H - Hold-down

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

No default route known.

C 800852 (NOVELL-ETHER), Fa0/0
R 852 [02/01] via 800852.002e.3c92.1101, 150s, Fa0/0

Just like that!

One thing to note, on VDE, I had an issue where the NetWare server takes about a minute before it’ll see traffic.  It could be my IOS for all I know…..

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!

Qemu vs KVM with Novell Netware 3.12

So I received an interesting tip, talking about the latest Qemu version, when it was mentioned that it isn’t the hardware that is at fault with Netware not running, but rather something in the emulated CPU.

Because, get this, Novell Netware runs in KVM.

Novell Netware 3.12

Novell Netware 3.12

I was taken back, all this time I thought it was something in the -M isapc definition that broke, but it’s the CPU!  I even rebuilt Qemu with the TCG interpreter, and it too breaks.  I even went one more crazy step, and installed with the ancient isadisk controller, and NE2000 on the ISA bus, and it works!

So for now my old copy of Netware I bought a million years ago lives in the cloud!

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.