This is an email to follow up on the update on our social network accounts (twitter and facebook: @hosthatch) that we are investigating an issue on SSDNode15. Instead of fixing this server, we have chose to restore from 1 hour old backups to some of our other stable servers running for 3+ months with no downtimes. SSDNode15 has unfortunately had very bad luck and has failed 3 times in the past month, which is why we are going to take it out of production, replace most of the parts, burn test it and then put it back into production.
Although I had time to check the log, it turns out I had over 250 users, but a good 150 of them couldn’t figure out the synchronet mandatory send a letter to sysop thing so they abandoned the process.
I don’t know why, but I still liked the idea of being the last OS/2 sysop on the planet, but this year has been ridiculous. Now that I have it running on VMWare, maybe it’s time I just buy a UPS, and run it on ESX from now on. But at the same time, I did like the idea of it running in a datacentre.
Well this has been driving me crazy for the longest time. The ‘latest’ drivers for the AMD Pcnet card I can find for VMware is 4.08. They load up on VMware like everything is normal but it doesn’t work. But now I have my super awesome GNS3 test bed, so I can take a deeper look.
NDIS2 Driver for OS2 MSLANMAN
NDIS2 driver for OS2 – Readme
Changes made in this version 4.08:
The receive buffer size has been increased from 1518 to 1536.
Changes made in this version 4.07:
Slow network performance when using Interrupt Sharing has been fixed.
After heavy stress for a few hours, a drastic reduction in data transmission was observed. This problem has now been fixed.
The maximum number of Transmit Buffers that the driver can support has now been increased from 16 to 32.
I’m using OS/2 2.0 with the XR06100 fix, along with TCP/IP 2.0 with UN64092 fix and MPLS WR06000 (I never did find a fixpack for this).
I installed AMD’s MSLANMAN OS2 driver, as MPLS picks this up, and lets me use the nice UI to add in the network card. But it never seemed to matter, as the blasted thing didn’t work.
Which is a pretty simple configuration. It’s just a simple lan adapter with TCP/IP. I’m not even going to try to do anything fancy, like trying to get the wildly incompatible NetWare client working
Now much to my surprise the machine does send gratuitous arp on the wire, to assert it’s ip address. Well that is interesting.
And as you can see, there is no ARP reply. Very strange.
So messing around with every possible option, I tried changing “PermaNet Server feature” in the network card settings.
And much to my surprise, it worked!
So yeah, this is pretty awesome! Now I just have to decide what to do with my BBS, maybe bring it home, and run it on ESXi.
As a strange update, I upgraded from OS/2 2.0 to 2.11 and then applied XR_B108 update to OS/2 2.11, and amazingly the value psfeature in protocol.ini had to be set to false. Obviously this later kernel in the XR06200 fixpack better supports PCI hooks.
I updated OS/2 because things like Qbasic were able to hang the system. I even tried the MS-DOS version of Qbasic thinking that somehow it was trying some weird hook to the BIOS for ROMBASIC, but that wasn’t the case, as both Qbasic from MS-DOS 5.0 and 6.22 hung the system by hitting alt+f. So with the upgrade in place it seems to be working fine now.
Well I’ve been back using GNS3 to simulate some networks professionally. And well, I hit a roadblock of a strange kind.
In my “LAB” I want to have a ESXi host talking to vCenter, and I wanted to setup a custom logging program which logs to MSSQL, and Maybe Oracle. For routing I need Junos and cisco IOS.
Now the problem is that takes a little bit of everything. The Qemu bundled with GNS3 horribly ancient, and my attempt to drop in Qemu 1.6.0 just fails. Also running things like Windows Server 2008r2 and ESXi run best under VMware. The SQL server stuff can be any version, so even NT 4.0/SQL 7 is fine which GNS3’s Qemu can run, but it is kind of slow. Which I know it isn’t fair to compare something like Virtual Box to VMWare.
So ideally the best bet is to tie them all together, and I found a way.
First I’m using VMWare Player version 6.0.1 build-1379776. The people financing this insane project have things like VMWare workstation but I have to download it through them, and their link is insanely slow, so I’m sticking with the player for now. But I was able to persuade a user to extract “VMware Workstation 10.0.2 build 1744117”, and retrieve two files for me, vmnetcfg.exe and vmnetcfglib.dll. So this way I can setup VMWare network interfaces which GNS3 can then latch onto with pcap.
The feature was available in earlier versions of VMWare Player, but the needed files were removed in the latest version. However I found if you have access to a new version of VMware Workstation you can just snag these two files, and run them like this (as administrator):
Now from what I have read online, the best thing to do is leave the default networks alone. However I found that if I left VMNet0 to the defaults I was unable to join any VM’s to the different networks. So I bind this to my physical Ethernet connection.
Now I want to have various network points to attach VMs onto. The best part that I’ve found is that pcap works on these networks for both listening and injection, so these make better ‘hub’ inspection points IMHO. Also this means you can run emulators that inject libpcap as a method of communication (SIMH, WinUAE, and even my ancient Qemu 0.9.0…)
The big thing is when adding networks, DISABLE DHCP. You can leave the rest where it is, it really doesn’t matter.
As you can see, I’ve now added VMnet2 – VMnet7. This should give me enough user networks for now to play with. I’ve also unchecked the local DHCP service, as I may want to run my own DHCP on an emulated server to make sure DHCP relay works through my virtual network. Once you are happy, you can hit Apply and it will create the network interfaces on your computer.
Now going into the control panel, and looking at the network adapters (search for “view network connections”), and you will see there are a bunch of these VMWare Network Adapters. The worst part is that they all have full networking enabled, which we don’t want. So starting with VMnet2, we need to unbind all high level access.
I unbind the ‘Client for Microsoft Networks’, ‘File and Printer Sharing for Microsoft Networks’, and TCP/IP version 4 and version 6. This the Link-Layer topology discovery stuff. I also enabled the VMware Bridge Protocol.
Now I just have to repeat this for each of the adapters that we installed, in this case VMNet2 – VMNet7. Remember to leave VMNet0, VMNet1 and VMNet8 alone!
Now for the real fun, you have to reboot for the changes to take effect.
After a reboot, if you run Wireshark, you should now see all the interfaces!
Ok so far, so good, but let’s tie this mess together!
So let’s build a network. Our “home” site will have a server network with the ESXi server serving some virtual servers, a user network which will contain our management workstation & a MS-DOS netware machine. We will then have a remote network with different machine types, which will be a 4.3BSD VAX, and an Amiga running NetBSD. We’ll also include a Novell Netware 3.12 server. Add in an ‘internet’ router, and we should be good.
The first step is to create some clouds. Each one of these will then be associated with a VMNetwork device.
Now you’ll notice that I’m assigning VMNet8 to the ‘internet’. If you remember the original VMWare table, the VMNet8 device is a ‘NAT’ device. So we can use that to get to the internet (well anything else the base device can access). Now I’ve gone ahead and added in two cisco routers, a single juniper router and a hub, as the juniper device cannot directly connect to the Internet cloud, but using the hub for the intermediary is ok.
Now it’s time to add some interfaces to the routers. I’m going to put the C7200-IO-2FE into both R1 & R2, along with a PA-4T+ serial adapter. Because I want to pretend to have a fast internet connection I’m also going to place a PA-GE interface into R1 in slot 2.
Now we need to bind each cloud to the corresponding VMnet interface.
Simply double click on the cloud, and select the VMNet interface from the drop-down list, then add it and the interface is now bound. Repeat for each of the clouds.
Now we can connect the interfaces.
So R1’s FA0/0 is connected to the SERVER cloud, FA0/1 is connected to the CLIENT cloud. Serial 1/0 is connected to R2’s Serial 1/0 interface. the G2/0 interface is connected to Junos1’s e1 interface
R2’s FA0/0 is connected to the VAX-AMIGA cloud, and the FA0/1 is connected to the NETWARESERVER cloud.
Junos1’s e0 is connected to HUB1, which is then connected to the INTERNET cloud.
Since I already have an ESXi VM on Player, I’m going to use this for my illustration. All I need to do here is change the existing network from being ‘bridged’ on my native network, to now being on VMnet2, which now places it inside of my GNS3 world. Likewise I take a Windows XP client, and place it on VMnet3.
And R2 like the following:
And now I can connect from my Client PC, the VMware ESXi server!
This gives me an easy way to ‘view’ into what is going on for my client to connect to the server.
Now some quick EIGRP to get R1 & R2 routing together..
router eigrp 1
network 192.168.255.0 0.0.0.3
And now we can check routs on R2, and see it’s learnt the routes from R1:
192.168.255.0/30 is subnetted, 1 subnets
C 192.168.255.0 is directly connected, Serial1/0
D 192.168.0.0/24 [90/2172416] via 192.168.255.1, 00:15:50, Serial1/0
C 192.168.1.0/24 is directly connected, FastEthernet0/0
D 192.168.2.0/24 [90/2172416] via 192.168.255.1, 00:15:50, Serial1/0
I was a little disappointed though, that Olive can’t do any flow based stuff like security policies or NAT.
So onward with SIMH. I’ve found that I have a LOT of Ethernet interfaces and some things cannot deal with that. I had to make a trivial change to sim_ether.h:
#define ETH_MAX_DEVICE 32 /* maximum ethernet devices */
SIMH had this value hard-coded to 10, and it crashed because I have… 11 interfaces. So it just took a quick re-compile and now I can see my interfaces!
So with SIMH I can now attach to eth8, which maps to VMnet3.
set xu ena
att xu eth8
And even better, it works!
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.15, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/15/28 ms
And the XP workstation can telnet to it…
Next I’ll have to add in some NetWare fun. For the heck of it. Good news is that it works!
One caveat I’ve found is that sometimes the ARP response time isn’t so hot, and it seems like everything times out.. So you may want to tweek the default arp age on the cisco side (interface bla/arp timeout 600..?).
No really, you read that right! You may remember my post about this emulator a while back, with a small mention how it’ll boot the diagnostic disk, and fail from there.
Well now, thanks to Andrew Warkentin’s hard work, the system now boots!
Using the 3.51 installation set from bitsavers, and the IMDU program to decompress the disk images the emulator can install UNIX onto a hard disk image (be sure to check the debug version, and the stderr.txt for the emulated geometry for your supplied hd.img).
I’ve got to say, it’s pretty cool! Although building the exe for Windows needed a little nudge, but my compile seems to be working, although the ‘release’ version still outputs far too much information.
At this point it’s stuck “working” .. I thought it’d be able to do more, but it did take down the new root password, and then say it’s “setting up the screen”. I ran a second copy on wine for the heck of it, and it’s doing the same thing.
I’ll update as I can, but I wanted to get this out there. For those who want to try, you can download my work here. Remember F10 will capture/uncapture the mouse.
The floppy disk file is called ‘discim’. Simply copy the RAW 409,600 byte file onto this filename, and freebee will pick this up as a disk change. You can make a hard disk file by simply creating a blank file (I used qemu-img create -f raw hd.img 65M) by providing a file of that size called hd.img . When freebee starts, if you look at stderr.txt it will tell you the geometry that it is going to use:
Which you then pass onto the diagnostic disk to format the hd.img.
(boot with the diagnostic/setup disk, 01.RAW)
Option #2 (Format Disk), then Option 12 (Others). Then using my information, 1040 cylinders, 8 tracks, 16 sectors per track (I guess it figures out heads on it’s own from the tracks?) I then let it setup the disk as multi-user and it’ll format the disk. It should only take a few seconds.
Installation of the OS starts with 02.RAW and it’s pretty self explanatory.
Apparently the best way to login the first time is to move the mouse frantically around, and it may let you into the system. Logon as root and try doing this:
I found this last night, and thought it was worth sharing.
This simple CP/M-68K simulator, is built around the famous Musashi MC68000 simulator core. So it’s a little more well debugged than the SIMH CP/M-68k. Namely that COM works!
I managed to build this under Window with MinGW, the only caveats were that it opens the disk files without explicitly in binary so on Windows it opens everything in ASCII and nothing works. Also MinGW doesn’t emulate a vt100 or provide termios so all of that had to be commented out. But for the full experience you’d want to run it on *NIX.
I suppose you could write an ANSI intercept, and manipulate the NT Console, but that is a lot of work.
On the plus side, this solution is more stable, faster and feels more robust with a 16MB hard disk, and a standard IBM 3740 floppy disk in the ‘a’ position.
One thing that was a snag to me, was the windows version of cpmtools is built to default to the apple-do type, aka Apple II CP/M skew for DOS 3.3 … So I was trying to setup a floppy image with too much work. Also the default size of the 3740 disk is 256,256 bytes.
But if you find z80/8080 CP/M too mainstream, give the 68k a shot!
the v86-64 patch, Allows you to enter v86 mode from long mode on a 64bit linux kernel.
Basically it works just like an old school DOS Extender, where it’ll switch from long mode, to 32bit compatible mode, then enter v86 mode run some code, then re-enter 32bit mode, to jump back into 64bit long mode.
This 64-bit DOSEMU compile runs substantially slower than the 32-bit compile
that I used previously on this computer. I have several rather large
<a href="http://www.powerbasic.com/products/pbdos/">PowerBASIC/DOS</a> programs that are, in fact, the main reason why I use DOSEMU.
Up until a couple of days ago, I had Fedora 7/i386 on this computer. I just
happen to still have the numbers when compiling one of those programs with
PowerBASIC/DOS under DOSEMU:
With F7/i386: 1686600 lines per minute -- total time to compile the program:
With F8/x86_64: 230400 lines per minute -- total time to compile the program:
The F8/x86_64 DOSEMU is running approximately 13 times slower.
Which I bet runs a bit faster than an old 386.
As he says, he likes Wordstar because it doesn’t try to think for him, and he likes MS-DOS because there is no distractions.
“I actually like it, it does everything I want a word processing program to do and it doesn’t do anything else,” Martin told Conan O’Brien. “I don’t want any help. I hate some of these modern systems where you type a lower case letter and it becomes a capital letter. I don’t want a capital. If I wanted a capital, I would have typed a capital. I know how to work the shift key.”
I do my writing on a completely different computer than the one I use for email and the internet, in part to guard against viruses, worms, and nightmares like this. My work machine does not even use Windows (which I loathe). I write with WordStar 4.0 on a pure DOS-based machine. Mock if you must… but WordStar and DOS are both stable as rocks, and never give me the sort of headaches I get from Windows. (I won’t even talk about Microsoft Word, about which I have nothing printable to say).
While messing around with SIMH & CP/M, I had some weird terminal issue, and wanted to try something that wasn’t ANSI. So I thought I’d try to find a free Wyse 50/60 emulator, and as I kind of expected this type of emulation isn’t cheap.
But then I found wyseterm.co.uk, and they made their Win16 stuff free as in beer ware. Well that sounds pretty good. Even better is that WINE can still run Win16 applications!
The only real catch I’ve found is that it ONLY will telnet to port 23.
But yeah, a free Wyse terminal emulator. So far as a CP/M console it seems to be running pretty well.