1988 Networking: 386 XENIX

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:

XENIX 2.3.1 booted with 3C501 driver

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?

XENIX 2.3.1 with TCP/IP 1.0.0 starting up

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.

This entry was posted in 3Com, Networking, PC hardware, SCO, TCP/IP, Virtualization. Bookmark the permalink.

11 Responses to 1988 Networking: 386 XENIX

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

  2. Michal Necasek says:

    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.

  3. MiaM says:

    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?

  4. Michal Necasek says:

    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.

  5. Michal Necasek says:

    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.

  6. KJ says:

    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.

  7. Michal Necasek says:

    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.

  8. Chris Hanson says:

    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.

  9. Lorenzo says:

    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!

  10. Dan Horák says:

    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?

  11. Michal Necasek says:

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.