I recently acquired a used Bay Networks MicroAnnex XL terminal server. I found it rather difficult to find information about the Annex product line and this particular model, so I thought I'd collect what I did find to make it easier for others.
It seems that the Annex product line was originally produced by a company called Xylogics. Xylogics was bought by Bay Networks sometime before my Annex was manufactured, as my Annex has the Bay Networks name and logo on it. More recently, Bay Networks was purchased by Nortel Networks. I have heard that the Annex product line has been End Of Lifed by Nortel.
My MicroAnnex XL has 8 serial ports (RJ-45), and AUI and RJ-45 network jacks on the back. On the front is a variety of LEDs and a "Test" button. It looks like the RJ-45 jack is on an addon card.
Dennis Boone sent me this additional info:
In addition to the micro, Annex II and Annex III units, there are some others with which I'm familiar: RA4000 (like an upgraded Annex III), the RAC8000 (fed with T1 circuits, and includes digital modems), as well as the 5399 family which is a backplane/blade system. The operating images for each model are different, but the host software can talk to nearly all of them. (There are some version dependencies.) I was once told by a Bay/Nortel engineer that the operating image is a hacked version of older BSD unix. The micro Annex is a pretty old product. At the new end of the line, end of life for the RAC8000 units was announced somewhere between one and two years ago.
Going to http://www.nortelnetworks.com/ and looking for information about the Annex product line hasn't been very fruitful in my experience. (Although it has improved somewhat recently. The Annex products now show up in the product support selection areas, but the pages don't link to nearly as many documents as the pages below.) However, searching on Google turned up the following sites on www.support.baynetworks.com that are still live (most links to sites within baynetworks.com forward to generic sites in nortelnetworks.com).
It turns out that www25.nortelnetworks.com is the same as www.support.baynetworks.com, so these URLs work just the same:
The most interesting manuals that I've found there are the "Hardware Installation Guide" and the "Administrator's Guide for UNIX" (Book A and Book C). Pick the one for your hardware or as close as you can find. Note that the link to Book A for the Annex 2000 on the first page above actually is a link to Book B. The link is correct on the second page. The Notes for Supported Versions of Software by Annex from the R11.1 section is also useful, as it tells you what is the latest firmware version for your hardware.
There are three major pieces of software related to the Annex product line. The first is the firmware that runs on the Annex itself. It seems that most Annex boxes have the firmware in flash memory so it can be upgraded. The second is Annex Manager, a GUI application that you run on your desktop to manage your Annex boxes via SNMP. The third is rtelnet, a command line tool to manage your Annex remotely.
This is the one thing I have been able to find on the Nortel site. If you go to http://www.nortelnetworks.com/ and click on Customer Support and then Software Distribution you'll end up at a page where you can select the product you are interested in. At least for the XL, on the resulting page are some links to some of the documentation mentioned about, but also a link to a tarball (ftp://ftp-support.baynetworks.com/pub/swcode/remacc/microannex_xl/R10.0B-R2.3.tar.Z).
That tarball contains all sorts of interesting goodies, and looks to be a dump of most Annex related software (presumably when the Annex support group was shut down). In the bfs/ directory are firmware images. In the gui_am/ appears to be a tarball of the Annex Manager software. There are also man pages, scripts, source code to a number of things, etc. I haven't looked through much of it yet, as I was primarily interested in an updated firmware and manage my Annex via telnet.
The Bay FTP site now allows directory listings (thanks to Joe Reid for pointing out this change), so you might be able to find other interesting bits by looking around.
Dennis Boone sent me some additional info:
There are some other software components for a host supporting an Annex, including some printing tools, a command-line style remote configuration tool, a time-of-day daemon, and the important one, erpcd. Erpcd is a file service (download operating images, config files, etc.) and authentication/authorization server. Most of this host-side stuff has been able to run on various unices, as well as NT. Support for specific platforms has come and gone. The microannex tarball you found on ftp-support is an older version of the host tools distribution which was either included with most Annexes, or was at least a cost-extra option. The latest version I'm aware of is 18.0.
I recently received an email from Darrell Hamilton with some info about getting rtelnet to compile on a recent version of Red Hat. Here is his email. Similarly, I got email from Vincent Sanders about compiling on Debian. And another email from Chuck Cranor about compiling and using na.
And I received an email from Zaib Kaleem pointing to ftp://ftp.xylogics.com/annex/release/ which seems to have some older versions of software.
The simplest way to administer an Annex is to telnet to it and use the CLI. 'help' will show you the available commands, except for 'su'. 'su' is similar to 'enable' on a Cisco product, it allows you to modify the configuration of the Annex. From there you can use the admin command to change system-wide configuration like the IP address, etc. The syntax is a little non-obvious. Use 'show annex' to show all of the system-wide variables. Then use 'set annex <parameter> <value>' to change something. Most of the values in here require reseting the Annex to get them to take effect. You can reboot the Annex remotely using 'boot'. Just hit return for the filename and enter a message if you wish.
Here's the output from 'show port' for the port that I have my VT-220 hooked to. This isn't perfect (for my purposes) because I would prefer that the user is presented with a menu like what you get if you telnet to the Annex (i.e. a list of rotaries and the CLI), but instead this dumps you straight into the CLI. If you want to connect to a port/rotary you have to 'telnet localhost' to get the menu. I know I could setup the port to just do the telnet, but it seems like there ought to be a better way.
By the way, these parameters are documented in Book C of the UNIX admin guide mentioned above.
admin : show port=1
port asy1:
Port Generic Parameters
mode: cli location: ""
type: hardwired term_var: ""
prompt: "" cli_interface: uci
speed: 9600 autobaud: N
data_bits: 8 stop_bits: 1
parity: none max_session_count: 3
allow_broadcast: Y broadcast_direction: port
imask_7bits: N cli_imask7: Y
ps_history_buffer: 0 banner: Y
tcp_keepalive: 0 dedicated_address: 0.0.0.0
dedicated_port: telnet type_of_modem: ""
default_session_mode: interactive dedicated_arguments: ""
resolve_protocol: connect
Flow Control and Signal Parameters
control_lines: none input_flow_control: bell
input_start_char: ^Q input_stop_char: ^S
output_flow_control: start/stop output_start_char: ^Q
output_stop_char: ^S input_buffer_size: 1
ixany_flow_control: N need_dsr: N
forward_key: "" backward_key: ""
Here's the output from 'show port' for one of my ports that is hooked to the serial port of a computer. The parameter you are most likely to want to change is the ps_history_buffer. I have it set to record 8k worth of messages, which you are then given the option of viewing when you connect. This allows me to see the boot messages, etc. if the machine is booted when I'm not connected. You can set it to 0 to disable this feature.
admin : show port=2
port asy2:
Port Generic Parameters
mode: slave location: ""
type: dial_in term_var: ""
prompt: "" cli_interface: uci
speed: 9600 autobaud: N
data_bits: 8 stop_bits: 1
parity: none max_session_count: 3
allow_broadcast: Y broadcast_direction: port
imask_7bits: N cli_imask7: Y
ps_history_buffer: 8096 banner: Y
tcp_keepalive: 0 dedicated_address: 0.0.0.0
dedicated_port: telnet type_of_modem: ""
default_session_mode: interactive dedicated_arguments: ""
resolve_protocol: connect
Flow Control and Signal Parameters
control_lines: none input_flow_control: bell
input_start_char: ^Q input_stop_char: ^S
output_flow_control: start/stop output_start_char: ^Q
output_stop_char: ^S input_buffer_size: 1
ixany_flow_control: N need_dsr: N
forward_key: "" backward_key: ""
And here's the syntax for config.annex to setup a menu of ports when
telneting to the Annex. Just type edit config.annex when
in su mode to edit the file. The number before the @ is the port number,
the number after it is the IP address of the Annex itself.
%rotary host1: 2@192.168.1.2 host2: 3@192.168.1.2 host3: 4@192.168.1.2
The pinout of the MicroAnnex XL ports can be found here. Looking at the RJ-45 serial ports on the Annex, pin 1 is on the left. See this page for diagrams illustrating the pin numbering. I use standard Ethernet patch cables and RJ-45 to DB-9 or RJ-45 to DB-25 adapters to connect my computers to the Annex. When you buy the RJ-45 to DB-* adapters they will generally come "un-pin'd", leaving it up to you to pin them out how you want them. Below is the complete pinout to make fully formed null-modem adapters. The ones highlighted in red I don't do because they require connecting one pin on one side to two pins on the other, which is difficult in an RJ-45 to DB-* adapter. For most applications the lack of these connections won't matter.
Annex signal Annex pin DB-9 DB-25 Computer signal
RTS 1 8 5 CTS
DTR 2 6,1 6,8 DCD,DSR
TXD 3 2 3 RXD
DCD 4 4 20 DTR
RXD 5 3 2 TXD
GND 6 5 7 GND
DSR 7 4 20 DTR
CTS 8 7 4 RTS
According to Brad Segal, the following is the syntax to add to config.annex in order to setup a default route:
%gateway net default gateway 146.125.58.126 metric 1 hardwired end
I've had no problem using the Annex as a term server for Linux or Solaris. However, with my FreeBSD boxes I experienced some unusual behavior. Namely, I had my FreeBSD boxes configured to spawn a getty on the serial port (via /etc/ttys as documented in the FreeBSD Handbook) but not to send boot messages to the serial port. With this configuration I did not see the login prompt when connected to the appropriate port on the Annex. I knew the FreeBSD configuration was right, since I previously had these same boxes hooked to another term server. After fiddling with a number of things, I tried also sending the boot messages to the serial port (by creating /boot.config with the contents of "-h" as documented in the FreeBSD Handbook). For reasons that I still don't understand, this made everything work. Not only do I get the boot messages, the getty login prompt also works. If you have experience with FreeBSD and Annex boxes, I'd love to hear if you had similar problems.
Joerg Wunsch sent me the following info on this subject:
Your description somewhat sounds like some missing wires in the null modem cable, namely the RTS <-> CTS crossover. FreeBSD by default uses hardware handshake except if the port is run as a console port (which explains why it worked for you once you used boot -h). You can change this behaviour by replacing the getty label std.9600 by 3wire.9600 in /etc/ttys. But see above, with the fully wired cable, this is not strictly required.
At this point, most new Annex owners are going to be acquiring used equipment like I did. In which case you may not have any clue how it was previously configured. There are two things you probably need to figure out/change: the IP configuration and the su password.
First the IP address. Connect a terminal (9600, 8N1) to port 1 on the Annex. Power cycle the term server and hit the test button right after you turn it on. The Annex will drop to a ROM monitor mode after a few seconds. You will be greeted with a "monitor::" prompt on the terminal. From there you can configure the IP address, etc. (Thanks to Karl Buschhaus for information about this.)
Next the su password. Annex boxes default to using their IP address as the su password. If you're lucky, nobody has changed it on yours. If that doesn't work, you can try the "erase" command in the ROM monitor mode mentioned above. I believe this will clear the entire Annex configuration, so hopefully you don't need to do this. :)
I didn't know anything about the Annex when I got mine, so I didn't use the "official" method above. In case it helps (or amuses) anyone, I thought I'd mention how I initially "broke in" to mine.
I plugged in my Annex and turned it on. It blinked away, looking like it was booting. Hmm, so far so good but I have no idea what IP address it is using. So I looked at the Ethernet address on a sticker on the Annex and fired up tcpdump like such: 'tcpdump ether host xx:xx:xx:xx:xx:xx'. Then I power-cycled the Annex so it would boot up again. tcpdump captured a RIP request that the Annex sent out, showing the IP address it was using. Of course it wasn't in the network that my machine was on, but I added a virtual interface on my Linux box on that network like such "ifconfig eth0:1 nnn.nnn.nnn.nnn" where nnn.nnn.nnn.nnn is some IP address in the same network as the Annex is using. (Other OSs have similar, but usually subtly different, syntax for creating virtual interfaces.) Boom, I was able to ping the Annex and telnet into it.
I got lucky on the su password (IP address), so I didn't have to try the erase command mentioned above.