After making the post/video about OSI, I found myself wallowing in a weird nostalgia about my early life experiences with networking. Back then, before the Internet, the experiences were limited to domestic modems and the various services that were available, which mainly consisted of BBSs, MUDs, and videotex. But, I was also aware of phone numbers that connected to strange systems; systems that allowed you to connect to other, powerful computers, a long way away in universities and private companies.
A few years later, I joined a university which was connected to a thing called the Joint Academic Network (JANET for short), which allowed us to connect from terminals in the college to any other system on the network, which included all of the universities in the UK, and to a few select commercial systems as well. There were also things called “gateways” that let you connect onward to other networks, and explore the entire world! Once I’d discovered this, it was pretty much the only thing I invested time in during my time there. Somehow, I scraped a pass, but all I really cared about was this magical land where you could hopscotch across the globe.
JANET was not, strictly speaking, part of the Internet at that time; like a lot of government and corporate networks of the period, it was based on OSI. Colloquially, it was known as an “X.25 network”, after one of the thousands of standards it used, but that was not an accurate description of the technology. Nonetheless, right up until the present day, when people refer to the networks of the period, they still tend to call them X.25.
TCP/IP, the protocols that are used by the Internet, were slowly becoming the standard for global networking and JANET supported this by running TCP/IP over the X.25 infrastructure. But it was a surprisingly short time before the old X.25 JANET network gave way to become purely TCP/IP. Fortunately, TCP/IP was surprisingly simple to comprehend, and that was partly down to the accessibility of the documentation, and the fact that our UNIX systems contained everything you needed to write code to use it. 1
As fascinated as I was by X.25 at the time, I never really managed to learn how it worked or what it was about. Finding out about this stuff was either very expensive, or involved finding books in technical libraries – and that required knowing what to ask about. I did understand enough to know about exotic things such as “PADs” (Packet Assembler/Disassembler) that let me connect to other computers over the network, but what was going on underneath was still a mystery. Additionally, I did get as far as sniffing the network to look at the packets, but all I cared about at the time was IP – so I lost interest and went no further.
Then thirty years elapsed. Out of the blue, I have become what can only be described as obsessed with it. The obsession became locked-in when I discovered that X.25 is, to some degree, still alive on the Internet. In the later days of the protocol’s fading empire, Cisco came up with a way to use X.25’s layer-3 protocol (creatively named “packet layer protocol”) over TCP and called it “XoT” (you can work it out). Additionally, I found someone had written a Rust implementation of an XoT PAD. It uses DNS as a way to look up X.25 addresses which sounded pretty interesting, especially as it meant there are people out there who are still interested in X.25!
The code compiled and ran first time, and I was able to connect to a remote X.25 service over the Internet immediately. That sealed the deal as far as obsession was concerned, and began a long and costly journey into possibly the most fun, yet pointless, projects I’ve ever embarked upon.
But what is X.25?
I spent way too long trying to describe my understanding of X.25 in a concise and comprehensible way but I failed. If you really care, which I doubt, let me know and I’ll have another go. Instead I’m just going to talk about the rabbit hole I’m currently down.
Hardware: The Obsession Begins
So, I bought a really old Cisco router. There was absolutely no need for this, beyond wanting some actual hardware that was designed to work with X.25. Fortunately, old Cisco routers are dirt cheap on Ebay, and it effectively formed a new playground for me. It didn’t take long to work out how to configure it, and within a couple of days I had my own XoT PAD available on the Internet. As exciting as this development was, it just made me want to explore more. OK, I have a way to play with X.25…but only layer 3, and only over the Internet. I was craving more. I wanted a “proper” X.25 connection.
The router only had a VoIP card. As exciting as I would have found that 20 years ago, I already have a fair amount of experience with VoIP and, without the space or resources to establish a Strowger telephone exchange, I’ve gone as far as I can with that. So, I thought I should buy a serial card so that I can mess with X.25 over a more traditional medium than ethernet. And so I picked up a dual “smart” serial card from ebay for about $20, and wandered around in impatient circles waiting for it to arrive. Unfortunately, getting involved with proprietary demons like Cisco meant I had to start dealing with proprietary connectors (and something called “licensing”? No idea what that is about.)
In preparation for the arrival of the serial card, I bought a special “smart” serial cable. The ETA turned out to be unacceptably long for my patience, which led to the first in a series of poor choices: buying another one that would arrive sooner. It didn’t. To add insult to injury, each cable cost more than the cocking router!
Ages later, I found myself with a serial port, a magic cable (it better be magic for that price) and a new RS232-USB adapter. I plugged it all in, hooked it up and got configuring.
Getting connected
It didn’t take long to get the the router and my old PC talking… but not in the way I was hoping. Networking-wise, at best all I could get going was a PPP connection. This did allow me to run IP between them, and then run X.25 over TCP, but as the computer was already plugged into the ethernet, it didn’t really provide anything different. Plus there was another problem: I couldn’t get the Cisco to route XoT from ethernet to the PC without going via a separate PAD call.
From the outside world, I could place a call to the Cisco, and then from its PAD place another call to my PC, over the PPP link (or ethernet). But I couldn’t make a call directly from the outside world directly to the PC. When I tried, the Cisco rejected the call.
I spent a great deal of time trying to work out why this didn’t work, and spent a lot of time with Gemini and ChatGPT trying to figure it out – both AIs were adamant that it *was* possible. To cut a long story short, I discovered that routing XoT to another XoT device was in fact not supported by the Cisco at all, and the AIs had been wrong. I asked them how they managed to get it wrong, and they both then apologised and confirmed that it wasn’t possible. Thanks.
But what would work, I discovered, is routing “proper” X.25, i.e. with layers 2 and 3. For this I would need a proper WAN connection. The layer-2 component of X.25 requires a bit-orientated connection, and the only option that was vaguely plausible for me was a *synchronous* serial connection.
Now, I have been messing with serial connections for 40 years, and know my way around UARTs, RS-232, RS-423, RS-485 etc etc, but never have I dealt with synchronous serial. The serial ports on the Cisco could, of course, handle synchronous connections, but I had nothing to connect them to. So, I naively thought, I’ll just buy a synchronous adapter for the PC. It was at this point I discovered I was dealing with specialist/rare equipment that was either ludicrously expensive, or impossible to get my hands on. Even the most basic devices were the thick end of a grand! Even used, they were outrageously expensive. How hard can it be to make a synchronous serial adapter? I even contemplated using an FPGA to make one…but then thought better of it.
Eventually I found a second hand one for under 100 bucks (some people were selling them for over $800!) and bought it. During the time I was waiting for it to arrive, I thought I’d have a go at getting everything else prepared; it helped with the impatience.
The card was PCI, and it hadn’t occurred to me that PCI is now, itself, old-tech. It also hadn’t occurred to me that I may not actually have any computers with PCI sockets – where did the time go? Fortunately, my dedication to cheapness and resistance to change meant we still use an old compact HP desktop machine for file-serving and Asterisk; I opened it up and was delighted to discover it had a variety of unused PCI slots, but the delight gave way to despair when it became apparent that the half-height compact case would not fit the full height card without some serious metalwork.
Nah. Instead, I took a look around for some kind of hack that would avoid proper work, and found it in the form of a PCIEx to PCI adapter that connected the two with a USB-style cable.
It was cheap enough that I ordered it without too much guilt, and it arrived before the card itself, so I had time to craft a professional working environment for it:
Sorted. Linux detected it on the first go. It didn’t know what to do with it, but that’s another story. So, I had the card, and a convenient cable adapter that came with it. But what I didn’t have was the proprietary cable that connected Cisco’s “smart port” to the RS-530 connector attached to the card. Again, I still have a treasure trove of ancient serial gear, but nothing that would work for this.
This kind of Cisco cable has probably always been expensive but now it’s also rare, so quite tricky to get for a sensible amount of money. Regardless, I bit the bullet and ordered what I believed to be the correct model, on the basis of advice from Gemini, and waited. Again, during the wait I had time to get things prepared and it was at this point I realised that the cable en-route to me was terminated with the wrong gender DB-25. Those of you familiar with the wonderful world of serial will probably be hearing alarm bells at this point, because the gender of serial cables has a hidden implication: DCE (Data Connection-terminating Equipment) vs DTE (Data Terminal Equipment), which is something that became less important in later years with asynchronous comms, because all cabling issues could generally be fixed with gender-changers and null-modems. But I was now dealing with a different beast: the synchronous connection, and things are a bit more complicated. In particular the data lines are no-longer single-ended; they are balanced, in a similar way to audio studio cables, where each tx and rx line is composed of two separate wires carrying the same signal, but inverted. After looking online and consulting some AI I decided to make my own synchronous null modem cable – the parts were cheap and available for quick delivery so I could have it ready by the time the expensive cable arrived.
In my haste, I made yet another mistake and ordered a pack of two DB-25 connectors that turned out to have different genders… Fortunately this time a simple gender changer should suffice and so I ordered a pack of them; they were the same price whether you ordered one or ten.
Here is the result of my precision engineering (sans extra gender changer):
Eventually, the Cisco cable arrived and I excitedly scrabbled to connect everything up. Despite all of my in-depth research and artisanal engineering, it didn’t work.
To be continued…(you lucky people).
- True story: I learned to use Berkeley sockets and write TCP/IP services purely from man pages. ↩︎