Microsoft’s Netware emulators

First thing to take care of, is if you have the old pcap on Windows running around. If you have it, you’ll know as you’ll get spammed with “FATAL Bad Memory Block.”, although things will continue to operate just fine.

Win10Pcap!
C:\dynamips\netware\qemu-0.90-pcap-client>qemu -m 16 -L pc-bios -M isapc -hda client.disk -soundhw sb16,adlib -net nic,macaddr=52:24:00:22:00:01 -net pcap,devicename={BFA868ED-E508-4436-B085-EC815C4C544C}
Eth: opened {BFA868ED-E508-4436-B085-EC815C4C544C}
Could not open '\\.\kqemu' - QEMU acceleration layer not activated
FATAL Bad Memory Block.
FATAL Bad Memory Block.
FATAL Bad Memory Block.
FATAL Bad Memory Block.

So be sure to dump that for the one over on npcap!

The old times, actually running Netware 3.12

There was a time when Windows NT didn’t dominate the 1990’s data centre. Instead as a carryover from the 1980’s the majority of corporate LANS were instead based on Netware. And the only way Windows NT was going to make space in this environment was to dress up in sheep’s clothes and mingle among them unnoticed. That brings us to this GEM:

Services for NetWare

This fun CD will let our NT 4.0 server emulate a NetWare server! The first thing in one of these stealth migrations was to just join the existing network.

The existing network is 0C0FFCAB

In order to do this, the two bits of information we need is the frame type, since NetWare supports so many, and the network address. In this case its 0C0FFCAB.

default IPX is no good

By default the NT server will just listen to the network, and participate on what it sees. This is fine if you are just playing along as a dynamic node, but being a NetWare node requires you to step it up, and have these values set, as it is very possible that you could be the first one (or only one) live on the network, and you don’t want clients trying to think on their own.

I also gave mine an internal network number of 1381, because you know, it’s NT 4.0.

To add the FPNW, you need to add it as a new service. Just tell it you have a disk

You’ll then have to point it to the path of the install. This is honestly the hardest part.

Selecting the first option will install the NetWare Server emulation on the NT server.

I went ahead and named my NetWare emulation as SHEEP, as I NT to blend into the existing NetWare network, with nobody being the wiser.

indeed, on our client that was already connected to the Qemu server before I built WOLF, I ran an slist command to show all the servers on the network, and there is my Wolf in Sheep’s clothes.

Creating NetWare compatible volumes is done in the Server Manager, under the FPNW option. It’s pretty self explanatory, nothing too exciting there.

The truth is during the period where this was important the NT 3.51-40 timeframe, NetWare was still a dominant force. But once Windows 95 had launched, and the explosion of people wanting MORE, the natural interest of people going to NT was just amazing to see in corporate space. While there was an early beta of the newshell for NT 3.51, when NT 4.0 shipped it was just amazing as all the reservations for running NT had just evaporated. We’d gone from hiding among the sheep to full on eating them all. It was staggering how fast we were backing up NetWare volumes to only re-format the servers to NT, and get people converted to using them. Before NT 4, the consensus was that rolling out the client config was going to be a nightmare, and that being able to emulate NetWare was the way to go, as it would just work (see the MS-DOS VM talking to NT with an unmodified NetWare client). Instead we saw a massive drive to Windows 95, which ended up changing the client landscape and upending NetWare completly.

About the most difficult thing was user mappings, there was tools to do this kind of thing, and I believe we had something to even proxy passwords, but it was easier to make people just login to the NT side.

Of course this is ONE of the emulators, you might be asking, okay, what is the other?

Why, it’s WINDOWS 95.

YES.

I’m joining the NT domain for the full experence, but the NetWare emulation relies on NetWare servers for authentication. You could use an actual NetWare server, or of course a FPNW server.

Adding file and printer sharing for NetWare workgroups under Windows 95 is done by adding a Service to the network stack. It’s even on the floppy version.

To maximize the functionality and the pain, be sure to turn on SAP Advertising. This way it’ll appear in server lists.

SAP on!

So with all of this in place, yes you can map drives from the MS-DOS client to the Windows 95 workstation acting as a server.

Mapping a drive on 95, authenticated by the WOLF hiding as a SHEEP

And there we go, I can now see the Windows 95 workstation on the SLIST, and connect and map drives. My user account of course exists on the NT side.

While professionally I didn’t rely too much on this feature, but it was nice in that era where you still had MS-DOS/MacOS/OS2 desktops with NetWare clients to quickly share stuff. But in a large organisation this would lead to major issues.

The fundamental flaw in NetWare is that there is no directory service. Instead, all the servers have to broadcast that they exist, along with what services they provide.

On my tiny demo network this isn’t that much traffic. But on a larger network that spans continents this becomes a problem. With thousands of servers there can be an incredible amount of this SAP announcement traffic. Since there is no directory service, the other problem is that when a new client is booted up, it’ll do what is known as a GNS or Get Nearest Server request in order to find the closest server to attach to, in order to facilitate a login. And EVERY server will reply.

And as you can see some servers even will reply more than once. And this can have other effects where people reboot servers during the day, something that is very natural for a Windows 95 user, which could create issues for other users, even forcing them to reboot! And yes, anecdotally I ran into this so many times where people with laptops with this feature turned on, and they would screw up the local office building (impacting hundreds of people). Even when they weren’t winning the GNS elections.they are still generating extra traffic, and occasionally they will win. This was another problem we had with all these wolves hiding in sheep’s clothing.

In the end, NetWare was utterly removed from the data center’s by the end of 1997. Windows NT just scaled too well for SMP and large disks (I had one server with 1TB! It was using 4GB disks it was massive!), along with being able to easily install stuff like SQL Server & SNA Server, unlike NetWare where any NLM conflict will bring the entire thing down. Not having a name lookup server was a giant pain, but the final nail was also in 1997 with the rise of the internet, and normal people now getting involved the entire LAN/WAN was going TCP/IP, where it had only been a fringe protocol used for managing cisco routers, and tftp/ftp some files around, Windows NT’s ability to encapsulate named pipes, and NETBIOS over TCP/IP let them embrace this new world where the TCP/IP stack on NetWare 3.12/4.11 was only good for sending SNMP alerts.

But don’t cry for NetWare, they made so much money they were able to coast for decades before being bought out in 2010 by a Mainframe Terminal Emulation company of all things, The Attachmate Group, who was later in turn bought out by Micro Focus, a COBOL language company. I guess in the end, the Mainframes won?

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:

[table id=1 /]

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…..

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.

16 and a half years of uptime

As much as the whole ‘uptime’ wars passed with the ever increasing need for patching, this is pretty amazing.

Over on arstechnica a Novell Netware 3.12 server by the name Intel had to be finally shut down after 16 and a half years.  Apparently the bearings in the two SCSI disks had gotten so loud it sounded like a car dragging it’s muffler.

xx days!

6030 days of uptime!

It’s still pretty impressive, and in some ways that was one thing Novell got right with Netware was that it was unstoppable.  Of course their big ‘goof’ was in the application space.  While there was a version of Oracle for Novell Netware, it was a major pain to deal with, and the GUI simplicity of Windows NT pretty much put an end to Netware.

But in some shops they don’t fix it until it’s broke.  Even if it takes a decade and a half.

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!!!

Dead end on the ISA disks.

Well I really thought I was going to make some headway on this.

But the answer was no.

However for the sake of completeness, let me at least document what I did.. The IBMPC hardware is initalized in hw/pc_piix.c

You’ll find this little GEM:

if (pci_enabled) {
PCIDevice *dev;
dev = pci_piix3_ide_init(pci_bus, hd, piix3_devfn + 1);
idebus[0] = qdev_get_child_bus(&dev->qdev, “ide.0”);
idebus[1] = qdev_get_child_bus(&dev->qdev, “ide.1”);
} else {
for(i = 0; i < MAX_IDE_BUS; i++) { ISADevice *dev; dev = isa_ide_init(ide_iobase[i], ide_iobase2[i], ide_irq[i], hd[MAX_IDE_DEVS * i], hd[MAX_IDE_DEVS * i + 1]); idebus[i] = qdev_get_child_bus(&dev->qdev, “ide.0”);
}
}

So I did the obvious thing and just wrapped it with a ‘pci_enabled=0;’ and a ‘pci_enabled=1’, basically turning off PCI for the IDE initialization so it’d load the isa_ide_init proc. Well that just then crashed Qemu when it was reconciling geometry for the NVRAM. 20 minutes with GDB and I figure that the code has morphed enough that it’s basically expecting 2 IDE controllers, and the ISA thing just isn’t building out what it wants so it’s just a quick fix in hw/pc.c

static void pc_cmos_init_late(void *opaque)

ide_get_bs(hd_table, arg->idebus0);
ide_get_bs(hd_table + 2, arg->idebus1);

So I comment out the second ide_get_bs and lo Qemu doesn’t crash anymore! But the BIOS says there is no hard disks?! So I’m figuring it’s a SeaBIOS issue, so checking their changelog, I see that there is something about not trusting ISA controllers on PCI systems.

So I’ll just have to back out that change, or just hack the thing to re-enable ISA IDE controllers. Luckily this was kind of easy to spot, as someone had left the magical words ‘isapc’ in ata.c

if (!CONFIG_COREBOOT && !pcicount) {
// No PCI devices found – probably a QEMU “-M isapc” machine.
// Try using ISA ports for ATA controllers.
init_controller(0, -1, IRQ_ATA1
, PORT_ATA1_CMD_BASE, PORT_ATA1_CTRL_BASE, 0);
init_controller(1, -1, IRQ_ATA2
, PORT_ATA2_CMD_BASE, PORT_ATA2_CTRL_BASE, 0);
}

So all I had to do was ensure that this was called, no matter what (comment out the if, leave the block). Sadly MinGW couldn’t build SeaBIOS so I spent the better part of an hour downloading Slackware 13.37 (which was … less then expected) fighting with it’s frame buffer, then the linker gave me this exciting bit.

cannot move location counter backwards (from 00000000000067e0 to 0000000000000000)

Good grief.

The fix is to apparently use binutils 2.20.51 . Slackware came with 2.21.51 .. Which apparently broke this needed function (again). So I wound up downloading the source from the MinGW project of all things (I know, wth?) having fun with p7zip (it installs a 7za?!) then I could FINALLY build my BIOS. First a generic test to make sure it works, then the modified one.

And into the crash. To verify I at least was doing what I thought, I turned on some debugging in the BIOS, which seamed normal, and then just fired up qemu with this flag:

-monitor telnet:127.0.0.1:2023,server,nowait

So I can telnet in, and capture the full device tree. Which you get with…

info qtree

And you can see, the IDE is indeed on the ISA bus.

bus: main-system-bus
type System
dev: hpet, id “”
gpio-in 1
dev-prop: timers = 3
dev-prop: msi = off
mmio fed00000/00000400
dev: i440FX-pcihost, id “”
bus: pci.0
type PCI
dev: PIIX4_PM, id “”
dev-prop: smb_io_base = 45312
bus-prop: addr = 01.3
bus-prop: romfile =
bus-prop: rombar = 1
bus-prop: multifunction = off
bus-prop: command_serr_enable = on
class Bridge, addr 00:01.3, pci id 8086:7113 (sub 1af4:1100)
bus: i2c
type I2C
dev: smbus-eeprom, id “”
bus-prop: address = 87
dev: smbus-eeprom, id “”
bus-prop: address = 86
dev: smbus-eeprom, id “”
bus-prop: address = 85
dev: smbus-eeprom, id “”
bus-prop: address = 84
dev: smbus-eeprom, id “”
bus-prop: address = 83
dev: smbus-eeprom, id “”
bus-prop: address = 82
dev: smbus-eeprom, id “”
bus-prop: address = 81
dev: smbus-eeprom, id “”
bus-prop: address = 80
dev: PIIX3, id “”
bus-prop: addr = 01.0
bus-prop: romfile =
bus-prop: rombar = 1
bus-prop: multifunction = on
bus-prop: command_serr_enable = on
class ISA bridge, addr 00:01.0, pci id 8086:7000 (sub 1af4:1100)
bus: isa.0
type ISA
dev: isa-ide, id “”
dev-prop: iobase = 0x170
dev-prop: iobase2 = 0x376
dev-prop: irq = 15
isa irq 15
bus: ide.0
type IDE
dev: ide-drive, id “”
dev-prop: unit = 0
dev-prop: drive = ide1-cd0
dev-prop: logical_block_size = 512
dev-prop: physical_block_size = 512
dev-prop: min_io_size = 0
dev-prop: opt_io_size = 0
dev-prop: bootindex = -1
dev-prop: discard_granularity = 0
dev-prop: ver = “0.14.0”
dev-prop: serial = “QM00003”
dev: isa-ide, id “”
dev-prop: iobase = 0x1f0
dev-prop: iobase2 = 0x3f6
dev-prop: irq = 14
isa irq 14
bus: ide.0
type IDE
dev: ide-drive, id “”
dev-prop: unit = 0
dev-prop: drive = ide0-hd0
dev-prop: logical_block_size = 512
dev-prop: physical_block_size = 512
dev-prop: min_io_size = 0
dev-prop: opt_io_size = 0
dev-prop: bootindex = -1
dev-prop: discard_granularity = 0
dev-prop: ver = “0.14.0”
dev-prop: serial = “QM00001”
dev: isa-fdc, id “”
dev-prop: driveA = floppy0
dev-prop: driveB =
dev-prop: bootindexA = -1
dev-prop: bootindexB = -1
isa irq 6
dev: port92, id “”
dev: i8042, id “”
isa irqs 1,12
dev: isa-parallel, id “”
dev-prop: index = 0
dev-prop: iobase = 0x378
dev-prop: irq = 7
dev-prop: chardev = parallel0
isa irq 7
dev: isa-serial, id “”
dev-prop: index = 0
dev-prop: iobase = 0x3f8
dev-prop: irq = 4
dev-prop: chardev = serial0
isa irq 4
dev: mc146818rtc, id “”
dev-prop: base_year = 2000
dev: i440FX, id “”
bus-prop: addr = 00.0
bus-prop: romfile =
bus-prop: rombar = 1
bus-prop: multifunction = off
bus-prop: command_serr_enable = on
class Host bridge, addr 00:00.0, pci id 8086:1237 (sub 1af4:1100)
dev: ioapic, id “”
gpio-in 24
mmio fec00000/00001000
dev: fw_cfg, id “”
dev-prop: ctl_iobase = 0x510
dev-prop: data_iobase = 0x511
mmio ffffffff/00000002
mmio ffffffff/00000002
dev: apic, id “”
dev-prop: id = 0
mmio fee00000/00100000

So while it didn’t do what I wanted, this kind of was a good way to see that I could at least enable ISA IDE hard disks on Qemu.

I can only wonder why on earth they are still broken with regards to Netware.

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 cajoling. 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?

More failure on the Netware front….

Years ago Netware sold these 4.1 dev kits on the cheap, and I picked one up in College. Back then the selling point was that along with Watcom you could actually run Netware 4.1 along with OS/2, and do all the dev loading on the same machine!

What a time saver, not to mention you could simulate a LAN on the same PC as each MS-DOS VM could have it’s own virtual NIC and each VM could login independently.

Anyways, I thought I’d go ahead and give this thing a shot, since I haven’t run this in a while, so I installed OS/2 2.11 on Qemu 0.14.0, and … got this.

Qemu 0.14.0 OS/2 and Netware crash

Qemu 0.14.0 OS/2 and Netware crash

PNW0162: An internal error has occurred. The program cannot initialize the GDT information.

Which of course is the Global Descriptor Table, and I don’t know why it can’t play with it… Qemu limitation? OS/2?

Anyways afterwards, I get this.

Qemu 0.14.0 OS/2 and Netware trap

Qemu 0.14.0 OS/2 and Netware trap

Trap 000d

And you thought Windows NT blue screen of death was impossible to read…