Telnet Spots in TR LOG

This describes a way to use a computer running the Linux operating system, with an Internet connection, to get DX spots from a PacketCluster with a telnet interface into the TR LOG bandmap. This assumes that TR LOG is running on a separate computer.

The basic idea is to connect the two computers together by a serial line and use that to log into the Linux computer from inside the packet window of TR LOG. Once logged into the Linux machine, the user can telnet to a PacketCluster with a telnet port. TR LOG is smart enough to "see" these spots even though there really isn't a TNC or a packet radio involved in any way!

The physical connection between the two machines is a "null-modem" serial cable. Connect this cable between COM1 [1] on the TR LOG computer and /dev/ttyS0 [2] on the Linux computer. Note that this uses no more serial ports on the TR LOG computer than connecting a TNC and packet radio would.

The next thing to do is set up the software, both on the Linux computer and the TR LOG computer. On the Linux computer, we want to associate a login prompt with the serial port, and on the TR LOG computer, we just need to make sure that TR LOG knows the correct serial port settings. On the Linux computer, the process that handles putting up a login prompt is called getty. You need to set up a getty process on /dev/ttyS0, so that when you launch TR LOG and do a Ctrl-B to get to the packet window, you see a login prompt for the Linux computer (which will behave more or less just like sitting in front of the Linux computer's own monitor and keyboard.) There are two files on the Linux system that will need editing. This must be done as root. Once these changes have been made, they can be committed by sending the HUP signal to the "init" process (the very first process that gets launched on a Linux system) with the command 'kill -HUP 1', which also must be done as root (or you can reboot the system, of course.) You only need to do this once.

# Run gettys in standard runlevels
1:12345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
S0:23:respawn:/sbin/getty ttyS0 DT4800 vt102
The important thing here is the last line. S0 is simply a label, and each label in this file must be unique. ttyS0 designates the first serial port on the Linux computer, DT4800 is a label in /etc/gettydefs (see below), and vt102 is a terminal emulation (defined in /etc/termcap.) vt102 is probably the best choice for most people, unless you really know what different terminal types are all about. For more information about the /etc/inittab file, type 'man inittab' at the Linux command line prompt.

# For TR LOG
DT4800# B4800 CS8 CSTOPB CLOCAL # B4800 SANE -ISTRIP CLOCAL #@S login: #DT4800
This line defines how the serial line is to be controlled. DT4800 is just a label of this particular definition. B4800 sets the baud rate at 4800. You could use 9600 instead, assuming of course that TR LOG is also set up to use 9600 baud. CS8 essentially means "send all eight bits" of every byte. CSTOPB adds an extra stop bit to the line. CS8 and CSTOPB together define the serial line as 8 bits, No parity, 2 stop bits (8-N-2). Understanding the rest of the line is less important. @S login: defines the login prompt to be the Linux computer hostname followed by " login: ". For more information on this file, type 'man gettydefs' and/or 'man termios' at the Linux command line prompt.

All of these commands are, of course, documented in the TR LOG manual. EIGHT BIT PACKET PORT = TRUE is the important one, though, as that tells TR LOG that the "packet" serial connection is 8-N-2. Also, the PACKET BAUD RATE must match the baud rate specified in /etc/gettydefs on the Linux computer.

Note 1:This could just as easily be COM2 - whichever serial port you have set up in the LOGCFG.DAT file.

Note 2:Linux machines refer to serial ports as devices /dev/ttyS0 (first serial port), /dev/ttyS1 (second serial port), etc. This could just as easily be /dev/ttyS1 if, for example, the Linux machine has a serial mouse on the first serial port.

Ken Harker WM5R
Last modified 21 June 2000.