RetroChallenge 2012 – Designated Router

Did the work tonight to make the router become the Designated Router and send the Ethernet Router Hello message to the All End Nodes address when it is the designated router, and to stop doing so if it stops being the designated router because an adjacency in the same area gets a higher priority. To make this work I had to fix a bug in the timer code so that a timer callback can create new timers itself.

So I have reached the point where all but one feature of the Ethernet Initialization Sublayer is implemented. The one bit that is still missing is the clean closing down (section 9.1.4 of the Routing 2.0 spec).

Posted in Uncategorized | 2 Comments

RetroChallenge 2012 – Refactoring

I have been away a bit and not had my development environment available to carry on, so I decided to do some refactoring and attempt some other small but important changes while I was away. The changes were to add recognition of padding, so I can read Ethernet Router Hello messages from RSX too.

Of course when I got back home, I found I had broken the code and it took me a while to fix it.

Also made a start on the designated router logic but I really need to create a proper initialization layer to do that right.

I still need to fix my Network Monitor parser for DECnet to deal with padding too.

Posted in Uncategorized | Leave a comment

Retrochallenge 2012 – Adjacency Staying Up

I have been cleaning up the code and checking the specification for the Ethernet Router Hello message to make sure I have implemented it fully. In doing so I realised that I was not setting the router information in the router list correctly to indicate that I had established two-way communication with the routers that had sent Ethernet Router Hello messages to me. This is why the simulated VAX780 was immediately saying that the adjacency was down after saying it was up. Now that I am reporting the status and priority correctly the 780 says the adjacency is up and it stays up.

Posted in Uncategorized | Leave a comment

Retrochallenge 2012 – Adjacency Up

I have been working on the Ethernet Router Hello message. After fixing some problems with the lengths I was putting in the message I finally worked out why my simulated VAX780 was not “seeing” my router node. It was because I was not sending the packets to the All Routers address. Once I fixed this and processed the Ethernet Router Hello messages I received, I got this message on my simulated VAX780:

%%%%%%%%%%%  OPCOM   4-JUL-2012 21:31:02.94  %%%%%%%%%%%
Message from user DECNET
DECnet event 4.15, adjacency up
From node 5.8 (VAX780),  4-JUL-2012 21:31:02.83
Circuit UNA-0, Adjacent node = 5.99

Of course, nothing else works at the moment, I get a timeout shortly after because I don’t implement anything else. Next step is to make the code a bit more robust, there are some hard coded bits and I haven’t tried it on the Raspberry Pi recently, so I need to work in those areas for a bit now. Then I can move on to implement more parts of the protocol.

 

Posted in Uncategorized | Leave a comment

Retrochallenge 2012 – Getting Started

After thinking about it many times, I thought this time around I would enter RetroChallenge. My project is probably going to be a bit longer than the month allowed and I am not sure how much time I am going to have to dedicate to it this month, but here goes.

The idea is to write a portable DECnet router that can be used on HECnet. My aim is to write it for Windows (as a Windows service) and as a daemon for Debian on a Raspberry Pi. At the moment I run a SIMH emulation of the VAX780 for this purpose and that means that anytime the machine it is running on is shutdown I have to go and restart SIMH. With a service or daemon I won’t need to do that anymore. Writing my own means I should be able to interoperate with Johnny’s HECnet bridge, and also real CISCO routers. I may be able to connect to other types of interface too, for example async hosts using DDCMP.

So far I have created a shell for the service and the daemon and I have created a bit of infrastructure to allow me to talk transparently to different interfaces (LIBPCAP for the LAN and sockets for the HECnet bridge at the moment). This bit is currently working on both Windows and the Raspberry Pi.

I am writing this in C for maximum portability, so I am using function pointers to implement my own inheritance mechanism to make multi-interface support easier. My task at the moment is to get the Ethernet Router Hello message working to the point that other nodes recognise my router. I am sending out my node’s hello message, but it isn’t being acknowledged by my emulated VAX780 yet.

Posted in Uncategorized | Leave a comment

Current Activity

As I have not updated this blog for quite some time I thought I would just list some of the things I am up to at the moment.
 
The main thing I am doing is running TOPS-20 on SIMH. I have BASIC-PLUS-2 installed on it. I have the listing of a program I wrote in the late 1970s when I was at school, and I am slowly retyping it in so that I can get it running again. The one frustration I have at the moment with SIMH is that the actual date and time falls behind quite badly. I think this may be to do with some of the idling settings I have set, I really need to look at that. The thing that really impresses me is that TOPS-20 has no problems with dates after 2000.
 
I would love to find the ALGOL68C compiler I used to use on the DEC-20, I still have some ALGOL68C listings too.
 
I have two VAXstation 3100 Model 38s, one with an expansion storage box. I also have several VAXstation 4000 VLCs, although two of them have developed a power supply fault and I am beginning to wonder if I have used hard disks that require too much power. I am running VMS 7.3 under the hobbyist license on all these systems, but only tend to keep one of them switched on. I am in the gradual process of compiling and setting up SSH.
 
I have a TK50Z drive which I wanted to use to recover a TK50 tape from, but when I finally got the drive working I could not find the tape! Still, I used it to restore some tapes for a colleague who used VAX in the distant past too. I have recently acquired a TZ87 which I have yet to test and a TK70 which I later realised I could not use as it does not have a SCSI interface.
 
I also have an Alpha, a DEC 2000 Model 300 AXP (aka Jensen). I only switch this on occasionally, but it is the fastest of the machines I have.
Posted in Retro-Computing | 1 Comment

Getting a DECserver 200/MC Working

 

Recently I was given an old DECserver 200/MC. This is a device that connects serial ports on the DECserver over an Ethernet LAN to one or more VMS computers. It uses a protocol called LAT, which stands for Local Area Terminal. When I used VAXen many years ago I remember using LAT to connect from a terminal to various machines.

This particular DECserver has 8 25-pin serial ports and an AUI connector for the LAN. I found some information somewhere on the web that told me the first serial port was the console port, so I connected a VT420 to it and plugged in the power (there is no on/off switch). I got nothing on the screen. Then I connected the console port to my Windows PC and ran my terminal emulator, when I did this I got some garbage characters. I checked the serial line settings on the VT420 and on my PC, they were both set to 9600,N,8,1. At this point I was beginning to suspect a faulty DECserver.

Then, thanks to a posting on comp.os.vms, I discovered that there is a way to reset the DECserver to factory settings. To do this I pressed and held the reset button while I powered on the DECserver, I held the button down for a good 30 seconds and then let go. After that the console port burst into life. I learned several things at this point: The DECserver serial line settings can be changed, it can remember the settings for a very long time without power (I am guessing it uses NVRAM rather than a battery), and my VT420 is faulty!

I could now see from the console that the DECserver was trying to download firmware. It seems that the DECserver does not have all the software onboard. Instead it uses MOP (Maintenance and Operations Protocol) to download the firmware from a computer on the network. So my next challenge was to get it to do this. I went down some blind alleys before getting this right. Allow me to explain.

I found a Hoffman Labs web page at http://64.223.189.234/node/183 (please don’t ask me why the URL uses an IP address, I don’t know) that explained how to set up DECservers and I noticed that it mentioned DECnet. So, the first thing I did was to go and find out how to set that up. At first I thought I would use the most recent version, which is Phase V, but I found it somewhat impenetrable, and on the advice of experts on comp.os.vms, I decided to switch back to Phase IV instead. Phase IV is much easier to install, configure and maintain, and I am also told it uses a lot less memory.

The blind alley that I went down was that I did not apparently need to configure DECnet at all (I mean get it to the point where I can use SET HOST etc), but some DECnet components are used (in Phase IV at least). Nevertheless I decided to set up DECnet anyway and will add a blog entry about this another day. I am not sure what the minimum necessary steps are, I suspect that it might be to just install DECnet and then change SYSTARTUP_VMS.COM to uncomment the START/NETWORK DECNET line, but I have not tried this. One other thing to be aware of is that if, like me, you are also using TCP/IP, then you must not be running TCP/IP at the time that you start DECnet, and indeed this is the order in which things are done in SYSTARTUP_VMS.COM. This is apparently because DECnet Phase IV wants to change the physical address of the network interface to a number derived from SCSSYSTEMID, which is also related to the DECnet address.

So, now that I had DECnet up and running, I needed to set things up so that the DECserver could find and download the firmware. The Hoffman Labs web page http://64.223.189.234/node/232 lists the file names for various DECservers, including mine, which is PR0801ENG.SYS. I discovered, thanks once more to Hoffman Labs, that I needed to install a layered product to get this file, the product name is DECserver 200 for VMS and I found that the package was in directory DS2033 on disc 4 of a 1999 set of Software Product Library CDs. The command I used to install the package was:

$ @sys$update:vmsinstal ds2033 dka400:[ds2033.kit]

Once it was installed I had to run @SYS$COMMON:[DECSERVER]DSVCONFIG.COM. I selected the option Add a DECserver and then answered the questions as follows:

DECserver type? DS200
DECnet node name for unit? DS200
DECnet node address for unit? 13.1
Ethernet address of unit? 08-00-2b-11-c6-88
DECnet Service Circuit-ID [SVA-0]?

Of course you need to enter the MAC address printed on the back of your own DECserver. I also chose a DECnet address using an area different to all the other machines on my DECnet network (they all use area 1, I chose area 13).

At this point I turned on the DECserver, hopeful that it would now download the firmware. However, it still said that it could not download it. There were no OPCOM messages on the VAX console. So after another post to comp.os.vms I realised that I had to look in SYS$MANAGER:OPERATOR.LOG. Sure enough there were some error messages, here is what I found:

From node 1.1 (VAX1),  1-SEP-2007 21:21:07.94
Circuit SVA-0, Line open error, File open error, Load file
%MOM-E-OPENIN, error opening SYS$COMMON:[MOM$SYSTEM]PR0801ENG.SYS; as input
-RMS-E-FNF, file not found
Node = 13.1 (DS200), Ethernet address = 08-00-2B-11-C6-88

So DSVCONFIG did not set things up so that the firmware file could be found. It seems that this is because the DECserver software I have predates the MOM system that I appear to be running. The solution therefore was to add the directory containing the firmware to the MOM search list, so I added the following line to SYSTARTUP_VMS.COM:

$ DEFINE/SYSTEM MOM$SYSTEM_SOFTID MOM$SYSTEM, MOM$LOAD, SYS$COMMON:[DECSERVER]

Once I did this the DECserver was able to download its firmware at long last! Now all I needed to do was to set up LAT, which would allow me to use the DECserver to connect to any of the VAXen on the LAN. Again I went down a blind alley at first, thinking that I would have to tell the DECserver which VAXen it could connect to. But it turned out to be much simpler than that, all you need to do on the VAXen is to start LAT on each one with the following command:

@SYS$STARTUP:LAT$STARTUP.COM

And that is it, apart from making sure that this too was in SYSTARTUP_VMS.COM. Now from the DECserver I could list the nodes and services using SHOW NODES and SHOW SERVICES and just issue a CONNECT <service name> and I was in!

Posted in Retro-Computing | Leave a comment