Month: April 2017

It still boots single user mode, one of the source projects has a nice rm -rf $DSTROOT so it nuked what little progress I made during the week.

But I have the compiler running and lots more. It has issues with netinfo which is really the only thing blocking it from multiuser boot. Some syscall not found, and I need to dig into the kernel to see if it even exists…

I’ll re-build all the libs and headers. Oddly enough the disk image I can build libraries and programs can’t build driverkit or the kernel…

There is no games, nothing fun to do, I didn’t even build a compiler. It’s just enough to show that it’ll boot up. If you manually conifgure the loop back you can ping yourself, launch inetd you can even try to telnet in, but control break is .. broken, and there is no NetInfo running so no passwords.

Of course for anyone finding this site today there are more newer, and capable images on my sourceforge page:

Well I put out a cry for help all over the place, looking for Darwin 0.3

And much to my amazement, when I woke up, I not only got a reply but a link to a toast image. Great, what is toast? Well simply put toast is a format made popular by then Adaptec Toast. Obviously the sane thing to do is to find Toast, install it, and mount the disk image inside of a Macintosh.

Adaptec toast 4.0

But, honestly, where is the fun in that?

Instead let’s have Cockatrice III do it! Now I never did get around to writing proper CD-ROM emulation, nor integrating it, but that doesn’t matter! Instead I’m going to rely on Daemon tools Lite, to do all the heavy lifting. DTL will create a virtual SCSI adapter, add in a SCSI CD-ROM device, and mount the image. Needless to say, I’m on Windows and that is where that part of the adventure ends, as Windows 10 cannot read HFS.

Now back to Cockatrice!

All I had to do was assign the SCSI 6 position to the mounted drive letter, and I’m set! Just add this to the CockatriceIII_Prefs file:

scsi6 \\.\e:

And now I can mount the image from within Cockatrice III

Darwin 0.3 toast mounted

And there we go, now I can copy the files of just like having a real Mac.

So I finally got it running, after some inspiration from NCommanderover at nextcomputers.org forums, that the Darwin 0.1 kernel is infact build able, I went ahead and took a stab at it. While he was trying to start from OPENSTEP, I tried it from something as close as I could to the target, which was Rhapsody DR2.

Back in the days of the NeXT / Apple merger, there was hope that OPENTSTEP could become the next great OS for the Apple Macintosh. It had been a while since NeXT had the OS running so things had rotten somewhat, as time had passed on. However the first and most viable platform would of course be the x86. Back in 1993 while feeling increased pressure in the hardware space, NeXT was forced to start porting away from their black m68k based hardware, and this was an opportunity to get their software running on different platforms. And sadly in 1993, the NRW aka NeXT RISC Workstation that was in development with dual m88000 processors was killed along with all hardware projects. In the end it didn’t matter as much as the only processor from the early 90’s that has a vibrant future is the i386.

So back again to this transitional time before OS X 10, there were developer versions of this OS seeded out that required you to have an intel machine as OPENSTEP was being ported to the PowerPC machines that Apple was selling.

So on May 14, 1998, the last public version for the Intel processor was released, DR2.

However two interesting things happened along the way to what would become OS X Server 1.0 . The first is that Apple gave up on the ‘yellow box‘ portable API, and to satisfy the GPL requirement to release changes to source code, Apple would go one further and release the source code to many of the internal system utilities, along with the kernel in what was known as Darwin.

This was a big deal for many of us, as the cost of getting the source code to any UNIX was incredibly prohibitive, and OS’s like Linux, NetBSD/OpenBSD/FreeBSD were picking up steam, OPENSTEP being awaken from it’s cryonic hibernation but with the promise of being free and open software was pretty great! Back in the day it sure looked promising!

Obviously things didn’t work out as everyone had hoped as Apple either straight up ignored anyone on the outside, or they hired people who showed promise, made them sign NDA’s and were basically never heard from again.

So the recently recovered source code to Darwin 0.1 corresponds with the release of the PowerPC only OS X Server 1.0. However as we all found out, Darwin will still built and maintained on Intel, as it was a very secretive plan B, in case something went wrong with the PowerPC platform. Being portable had saved NeXT before, and now it would save Apple.

So with this little background, and a lot of stumbling around in the dark, I came up with some steps, that have permitted me to build the Darwin 0.1 kernel under DR2.

However it was not perfect, and the biggest glaring issue was due to the software that was recovered, the layer known as driverkit, (driverkit-139.1-1.tar.gz) turns out to be from another, later release of Darwin, the 0.2 release, which the only thing surviving is the driver kit. It doesn’t build cleanly, and In order to get it to build I had to break the mach PCI bus. This means that yes, PCI devices will not load at runtime, only at boottime by sald.

After a lot of fighting I was able to produce a system that could boot into both single user and multiuser mode, although it was unable to load drivers so there was no networking, and no UI.

In a fit of boredrom, I built a bunch of the command line tools for Darwin, and a few libraries, and then went to see why the driverkit had a problem finding the reason why KernBus was undefined, or even with some attempts at helping all the methods were unknown, I stumbled onto the fact that during compilation it will generate new headers, and in those headers are the correct interface for driverkit to call into the KernBus. So I was able to quickly rebuild driverkit, then re-link into the kernel and now I could load drivers! Thrilled with this much, I did something more aggressive, I made a dump of my install ‘target’ and then restored it onto an image of my dev VM. And much to my amazement it booted up to the graphical login. I now had PCI working correctly.

Darwin 0.1

This kind of thing is not for casual users, but if you install DR2 into a VM, you ought to be able to then use this ISO image, and follow these instructions, and you will then have a DR2 OS from 1998 with the OS X 1.0 kernel from 1999 running. The biggest difference I’ve noticed is that the newer kernel can use 512MB of RAM, a nice bump up from 192 which was the prior limit.

Obviously there is a lot more work to be done, it’d be nice to find some source to an IDE or other block controller and modify it to work with the massive disks of today, along with the filesystem code to handle partitions larger than 2GB.

Maybe it will be possible to port in the driverkit to XNU, so we can get things like existing drivers, and SMP, massive filesystems etc.. It’s great to see we are going the right way.

Back in 1995, 2 really neat things happened. First is that 32bit computing to the masses finally happened. The second is that lousy audio compression started to really really take off.

And like many other people, who weren’t lucky enough to have a SUN or NeXT workstation, we got our first taste through Real Audio.

Back in the day, I was lucky enough to have a ST4766N 676MB SCSI disk, that was actually large enough to decompress a CD-ROM audio disc to, which in the mid 90’s was a rarity!

Big disks making transcoding possible

So with enough disk space, I was able to rip the CD-ROM to uncompress WAV files. Oddly enough today, this is a trival thing to do. In this day and age to re-create it, however I’m going to take a FLAC, and downsample it to a 44100Hz WAV file using Audacity.

Once you’ve opened up your source material, in the bottom left drop it down to 44100…

And this will let you start the export process

And this let’s you set it to a signed 16-bit PCM WAV which Real Audio can happily transcode.

437MB of uncompressed audio

And this is why for most people transcoding a CD-ROM would be out of reach, as ripping a CD-ROM would require an enormous amount of hard disk space for someone circa 1995.

Using the encoder, it’s a simple matter of opening up the WAV file, select a destination name, and set the encoder. In this case I want the smallest file possible, so Im using RealAudio version 2, suitable for 14.4 modem.

And just hit the ‘Start Encoding’ button, and you are good to go! In the day this whole process would take HOURS and HOURS… I think the encoding ran over night. But today this only takes a few seconds.

And now it’s super easy to load it up on a player, and listen to it’s…. semi awesomeness.

Side 1 in under 1.44MB

And just as I recalled, I was able to transcode the first 5 tracks in under 1.2MB, enough to fit onto a 5 1/4″ diskette, or a 3 1/2″ disk.

Once Windows 95 was a shipping thing, things like the media player started to get better and more versatile codecs to support u-law, a-law, MPEG-2, and even MP3. But thanks to an early start Real Audio was up there with flash as one of the first ‘must have’ programs to unleash the new and exciting. Real couldn’t make the jump to mobile devices, and once MP3 streaming via shoutcast and other ‘DIY’ free solutions took over the market and obliterated the very expensive and proprietary RealAudio servers. While progressive networks is still around, they are the Yahoo of audio.

One minor thing of interest is that VLC, can play RealAudio files. I thought it was interesting, although I guess not all that practical.

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.

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:

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:

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:

Continuing from my TACACS adventure, I also thought it would be nice to capture syslogs, and save them. Oddly enough this is a big business, with even low end products like Kiwi Syslog server costing some $295 USD!

Well that’s too much for me, so I figured that the most wide spread at the time must have been the 4.3BSD syslogd, so I’ll start with that.

Just as before this was a pretty straight forward port, I had to remove all the /dev/kmem and UNIX socket stuff, as they obviously don’t exist on Windows. Just as the same, you can’t “write to users” to send messages, so by default output is a file. I suppose I could use the net send functionality to pop up a message, but I find it just as annoying today as it was then.

At any rate in no time I was able to setup a simple config file, and then get my router to turn on full logging & enable full debugging to get a continuous stream of messages. The only ‘gotcha’ is that this sylogd wants to be able to do reverse lookups, so you really ought to have a DNS with reverse entries, or a good hosts file.

I’m sure it’s full of other bugs, but all I tested was that I could log to a file, and it’s doing that much just fine. If you feel so inclined you can download & compile it, the source is: syslogd_win32.c

So, in my fun and excitement I was putting together a ‘cisco’ network using dynamips that spans a few sites across the world. I’m using ancient copies of NT for some servers, although I plan on adding in some 386BSD, SunOS SPARC, and maybe even 68010 based, along with other stuff.

I have the routers running fine, but I felt like adding some kind of external authentication service, and TACACS certainly fits the bill! And to be all vintage as usual, I’m not going to use TACACS+ as it’s simply too new, and too big. So first things first, I need a copy of the source to TACACS as I’m certainly not going to write my own! I found this directory on ftp.funet.fi which has a bunch of old cisco related material, and sure enough there is a tacacsd.c

Even better it’s from 1989 which suits my need for something positively ancient, and simple enough to be a single C file.

Porting it to run on Winsock, really wasn’t all that hard, I had it running as a standalone program within a few minutes, however there is no password file in NT, so as a simple test, I had simply short circutied the username lookup to always suceeded, along with a password compare.

Since I have VMWare Player installed on my machine, I can use the VMNet 8 connection to talk to my host computer. The hard part of course is trying to figure out which NIC is which, but dynamips -e will give you a list like this:

This fails as Windows by default has it’s firewall on, which then blocks all incoming traffic. However to see that the ICMP would have succeded, you can look at the arp table, and the .1 address should have been learned:

We can either diable the firewall, or we can add a rule to permit ICMP. To do either you need to go to the firewall control panel in Windows. In this quick example, I’m going to build a rule using the firewall control pannel.

So hit the advanced settings to the left.

Click on the ‘Inbound Rules’, and now we are going to create a new rule.

Select a Custom Rule

Allow ‘All Programs’

Then set the protocol to ICMPv4

Now we can select the scope of the rule, in this case we are going to allow the 192.168.254.0/24 network to pass icmp traffic to us. Add it as a source and destination.

In this quick example I’m applying it everywhere. I suppose a better setup would be to make sure the VMNet 8 adapter is a ‘Private’ network, and ONLY apply this to the Private domain.

It’s not exciting, but as you can see it is attempting to look through the gecos to verify the user, but in this case I just allow anything. And besides just granting anyone the ability to login, let’s take a look on the wire:
WireShark capture of TACACS traffic

As you can see the username & password go over the wire in plain text. Even the response is simple enough to decode:

Access granted!

Needless to say this is something that you would NEVER EVER EVER run in a real network. Of course a system that sits on telnet is vulnerable anyways, but I suppose a TACACS server that lets anyone log in, makes either a VERY trusting network, or a good honeypot. Against my better judgement, here is tacacsd_win32.c Naturally it could be easily made to verify passwords against pretty much anything.