With the 3Com 3C501 EtherLink emulation in hand, I thought I’d see if it works with the SCO TCP/IP stack for SCO XENIX/UNIX. That particular stack, which actually consists of separate STREAMS and a TCP/IP packages, comes with whopping two device drivers: One for Western Digital WD8003, and the other for 3Com 3C501 EtherLink.
I located the requisite floppy images on my NAS and physical floppies in the basement, and installed 386 XENIX 2.3.1a (September 1988), STREAMS Runtime 1.0.0c (August 1988), and TCP/IP Runtime 1.0.0c (December 1988) in a VM. Thankfully, the EtherLink driver worked the first time and created a 3comA device:
The TCP/IP stack was developed for SCO by Lachman Associates, in cooperation with Convergent Technologies. Configuring it was not easy, because the extant documentation only covers newer versions for SCO UNIX. Fortunately someone has already been there, and the SCO-supplied 3C501 driver had no problem with the route command. Thanks, Jason!
After starting the TCP/IP stack and configuring it for VirtualBox NAT networking, I was able to ping my router and random servers on the Internet (like 8.8.8.8). So, basic connectivity was there. Can this TCP/IP stack do anything else?
The answer is yes, but not a lot. The SCO/Lachman TCP/IP stack comes with a number of usual clients and servers like telnet, FTP, TFTP, sendmail, rlogin. In other words, tools that are obsolete and not supported by modern systems.
In 1988 the situation was obviously different and telnet, FTP, rsh/rcp/rlogin were standard tools allowing good interoperability. Nowadays not so much, but still it’s nice to see a 1988 OS being at least somewhat able to work in the world of 30 years later.
There is unfortunately no file sharing with XENIX SCO TCP/IP. There was an NFS kit from SCO, but that required SCO UNIX, not XENIX.
One of the things that does work is telnet into the XENIX VM. With the VirtualBox NAT and port forwarding, it’s reasonably easy and works well with PuTTY on a Windows host.
All in all, an interesting but not hugely practical exercise.
> All in all, an interesting but not hugely practical exercise.
This is always the end result of Xenix experiments. Although it is always fun to kick those obscure Xenix tyres.
Glad I could be of help
Yeah, obscure is right. I’ve seen a lot of *nix TCP/IP stacks but the XENIX one manages to be quite different. Then again, back in ’88 TCP/IP was not exactly built into every OS out there.
The Microsoft CIFS documentation says this: “The “xenix1.1″ dialect is documented in [MSFT-XEXTNP]. This dialect provides a set of extensions to SMB to support the XENIX operating system. Also known as the XENIX dialect.” And it also says “XENIX CORE Another dialect supporting XENIX extensions, possibly the same as “xenix1.1”. The “XENIX CORE” dialect string is sent in protocol negotiation performed by Windows NT and OS/2, among others.”
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/80850595-e301-4464-9745-58e4945eb99b
Were SMB for Xenix a separate product?
Have you had a look to see if any ssh client or server compiles on Xenix?
Everything was a separate product on Xenix. I’m off hand not sure if there was SMB networking for SCO XENIX (there was for SCO UNIX); there was Intel OpenNET which was a Xenix-based SMB server (and client).
I’ve not tried building a ssh server for XENIX. It ought to be possible in theory.
Update: There are references to “SCO LM/X” in other SCO UNIX manuals (LM/X = LAN Manager for UNIX). I’m still not sure if that was ever available for SCO XENIX; quite possibly not. But it was available for SCO UNIX.
FWIW…the 3c501 is a *terrible* network card. Really small buffers and hardware bugs meant anything involving back-to-back packets were on the best days dog slow, and usually just plain unreliable. We had so many problems on SCO with it we pretty much told customers not to use it, and all kinds of problems disappeared when we replaced a 3c501 with most anything else. Not sure how bad a virtualized 3c501 would be.
OTOH…the WD8003 was a pretty solid card.
Not buffers–buffer. The 3C501 is a really, really old design. I actually suspect that the 3C501 might not be too bad when it talks to another 3C501 (otherwise I don’t know why 3Com would sell it for so long), but if there’s a faster card on the other end then it just falls apart. I’m also not entirely sure there are serious hardware bugs in the 3C501, but the design is such that the card just can’t receive two back-to-back packets (or more accurately, it’s not possible to read the first packet from the buffer without losing the second).
A virtualized 3C501 so far appears to be much less bad than a real one.
Good to know that the WD8003 was solid. It’s perhaps the most widely supported 1980s Ethernet card, similar to the NE2000 but older.
You could always try to port an SSH implementation to XENIX next. 🙂 While mbedTLS assumes GNU make, it should be easy to write your own platform specific Makefile, and then you’ll have a TLS stack that some SSH implementations can sit atop.
There is a binary of samba for Xenix, and it works 🙂
ftp://ftp.celestial.com/pub/sco-ports/xnx
Proof: https://photos.app.goo.gl/1hGiMZ8KTJEFTAgo6
not terribly useful, but it works!
I am wondering if the network support is limited to the 386 variant or would it work for Xenix 286 2.3.2 as well?
As far as I know, all the SCO networking packages for XENIX including STREAMS, TCP/IP, and NFS are 386 only. It is likely that this came out when SCO was about to drop XENIX and switch to SysV UNIX, which was 386 only anyway, so 286 support wasn’t considered important. It’s also quite possible that the source code they had would have been difficult to port to the 286 and they just didn’t want to bother.
I’ve been using xenix 2.3.4 with the 3c503 (3comB) emulation in 86Box, a full machine emulator. I don’t think I’ve seen 3c503 emulation anywhere outside of (the now defunct?) PCem and its descendants (86Box, PCBox). I’ve seen references to MESS but that seems to be defunct as well?
I didn’t know VirtualBox emulated any of the NICs for which Xenix 2.3 drivers were available! My attempts at networking Xenix 2.3 in VirtualBox were utter failures. The DE-200 driver (basically NE2000) is utterly broken in that even the route command, a basic mechanism to manage routes in the routing table, doesn’t work — this ruled out using libvirt/QEMU/kvm sadly. So XENIX 2.3 could only be run networked beyond just the local network in full emulation.
Ah! Looks like since I last tried the DE-200 driver with QEMU/kvm, someone in the comments on the VirtuallyFun post linked in your write-up worked out how to get the route command working. Excellent and I think I need to revisit this option (as I prefer using hardware virtualization over full emulation if I can help it).
“FYI: I found the reason why adding routes does not work after dlink installation. For some reason in /etc/strcf the line tp /dev/inet/rip is commented out. Just enable this line and reboot, and adding routes should work …”
The D-Link DE-200 driver is set up extremely poorly by default and needs considerable tweaking to get it working properly, this is another aspect of that fact.