TNT - A UNIX Packet-Radio Terminal Program

----------------------------------------------------------------------------

Introduction
Version of TNT described
License, copying, warranty
About Packet Radio and TNT
Why this program?
What's needed?
Mailbox program DPBox

1. Screen layout
1.1. Virtual screens
1.2. Types of virtual screens
1.3. Main statusline

2. Commands
2.1. Keyboard-commands
2.1.1. Cursor movement and miscellaneous
2.1.2. Window movement and control
2.1.3. Screen switching
2.1.4. Keyboard macros
2.2. Commands in command mode
2.2.1. TNC-commands
2.2.2. External commands
2.2.2.1. Saving data to files
2.2.2.2. Sending files
2.2.2.3. Shell,Run,Redirect and Sockets
2.2.2.4. Directory
2.2.2.5. Miscellaneous
2.2.2.6. Routing scripts
2.2.2.7. Extended monitor and boxlist
2.2.2.8. Interface commands
2.2.2.9. DPBox-interface commands
2.2.2.10. Password generation commands
2.2.2.11. Remote-command permissions and access levels
2.2.2.12. Broadcast transmission/receiption

3. Detailled description
3.1. Remote commands
3.1.1. Default access levels for remote-commands
3.1.2. Sysop password validation (//SYSOP)
3.1.3. Shell with root-permissions (//ROOTSH)
3.1.4. Socket connection (//SOCKET)
3.1.5. Dangerous //ECHO command
3.1.6. Handling of unknown remote commands
3.1.7. Extended remote commands
3.2. Umlaut conversion
3.2.1. Display
3.2.2. Sending text
3.2.3. File-receive
3.2.4. File-send
3.3. Using UNIX-features
3.3.1. Shell-login
3.3.2. Redirection
3.3.3. Running programs
3.3.4. Socket server
3.3.4.1. AX25-Server
3.3.4.2. Netcmd
3.3.5. Socket connect
3.4. File transfer methods
3.4.1. AutoBIN file transfer
3.4.2. YAPP file transfer
3.4.3. 7Plus file reception
3.5. Special connect text and files with macros, Name-database
3.6. Routing scripts
3.7. Call update
3.8. Logbook
3.9. Keyboard macros
3.10. Boxlist
3.10.1. General description
3.10.2. Using boxlist
3.10.3. Using keyboard macros
3.10.4. Recognized formats
3.11. Extended monitor
3.12. Use of DPBox
3.12.1. General description
3.12.2. Using unix socket interface
3.12.3. Mailbox screen
3.12.4. Using DPBox via Packet Radio
3.12.5. Autobox and monbox feature
3.12.6. Unproto list handling
3.13. Automatic password generation
3.13.1. General description
3.13.2. DIEBOX
3.13.3. FlexNet
3.13.4. TheNet
3.13.5. Baycom
3.13.6. MD2
3.14. Huffman compression
3.15. Handling Flexnet connection quality checks
3.16. Operating different software with same callsign
3.17. PACSAT broadcast operation
3.18. Autostart on connect
3.19. TNT as daemon, TNTC

4. Description of configuration files
4.1. Main configuration file
4.1.1. Serial and general configuration
4.1.2. Security
4.1.3. Directories, Files and Sockets
4.1.3.1. Directories
4.1.3.2. Files
4.1.3.3. Sockets and Boxfiles
4.1.4. Lines of virtual screens
4.1.5. Display configuration
4.1.6. Screen attributes
4.1.6.1. Color attributes
4.1.6.2. Monochrom attributes
4.1.7. Packet assembly timeout
4.1.8. Additional options
4.2. TNC-configuration files
4.3. Cookie file
4.4. Files for remote commands
4.5. Files for connect text
4.6. Files for names database and routing scripts
4.6.1. Names database
4.6.2. Routing database
4.7. User-Id's and security
4.8. Logfile for resynchronisation
4.9. File for keyboard macros
4.10. File for password generation
4.11. File for sysop authentification
4.12. File for remote commands disabling
4.13. File containing not own callsigns
4.14. File containing Flexnet digipeaters
4.15. File for AX25-server access
4.16. File for autostart on connect
4.17. File for extended remote commands
4.18. Files for BBS features
4.19. Configuration file for TNTC

5. Additional Information
5.1. Options at startup
5.2. Running under X11
5.3. Porting of TNT

6. Credits and Contact

A. Appendix
A.1. Static huffman compression table

----------------------------------------------------------------------------

Introduction

----------------------------------------------------------------------------

Version of TNT described

This documentation describes TNT V1.0 dated 97/01/26. The last update of the
documentation was done at 97/01/26.

----------------------------------------------------------------------------

License, copying, warranty

TNT is Copyright (c) 1993-1997 by Mark Wahl, DL4YBG

This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation;

This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details (contained in file 'license').

You should have received a copy of the GNU General Public License along with
this program; if not, write to the Free Software Foundation, Inc., 675 Mass
Ave, Cambridge, MA 02139, USA.

----------------------------------------------------------------------------

About Packet Radio and TNT

Packet-Radio is a special mode used by Radio Amateurs to transfer text and
data. It is packet orientend and uses the AX.25-protocol (a special version
of X.25 to fit Ham Radio needs).

There are some single board computers which implement the AX.25-protocol and
contain the modem-interface to the radio-transceiver. The terminal or
computer with terminalprogram is connected via a RS232-interface. These
single board computers are called Terminal Node Controller (TNC).

For most of these TNCs a special software is available (WA8DED-Software or
The Firmware by NORD><LINK) which can be switched to a special protocol
(hostmode) at the RS232-interface. If hostmode is selected it is not
possible to operate the TNC using a simple terminal, a computer with a
special terminalprogram is needed.

The advantage of hostmode is that the terminalprogram can implement virtual
screens for the different connections, the command mode and monitor mode.
All these will be displayed together on a normal terminal which leads to
confusion of the operator.

TNT is such a terminalprogram (TNT stands for TNc Terminalprogram).

----------------------------------------------------------------------------

Why this program?

There are some implementations of the AX.25-protocol available for UNIX
(KA9Q, WAMPES, e.t.c.). They all use the TNC as a simple modem (KISS-mode)
and have TCP/IP protocol implemented (using AX.25). But the operator
frontend is very poor, there are no virtual screens and scroll back buffers.
So my intention was to write a program which has a powerful operator
frontend and uses the TNC not as a modem but as a Terminal Node Controller.

----------------------------------------------------------------------------

What's needed?

The program is developed for LINUX and a VT100-compatible terminal. It
further needs a TNC with WA8DED-software or The Firmware by NORD><LINK
connected to a serial port of the computer. The Firmware by NORD><LINK is
available for TNC2, all TNC2-clones and for AEA PK232 and PK88.
WA8DED-software is available for TAPR-TNC1.

If you don't have a TNC with The Firmware or you don't want to change the
Software of your TNC, TFKISS may be used. TFKISS is a program running under
Linux, which emulates a TNC with The Firmware. It only needs a TNC running
KISS or a device which behaves like a TNC using KISS. TFKISS supports
standart KISS, KISS with checksum (SMACK) and KISS with checksum used in
Flexnet-digipeaters (RMNC-KISS).

Although LINUX is the development platform a porting of TNT to other UNIXes
shall be possible because no special functions are used. Other terminals can
be used if they have at least line insert and line delete and an entry in
/etc/termcap.

----------------------------------------------------------------------------

Mailbox program DPBox

Joachim, DL8HBS has written a very powerful packet radio program called
DigiPoint for ATARI computers. It contains a packet radio host terminal,
satellite calculations and a bulletin board system.

The BBS contains almost all features of the known BBS-systems and is capable
of performing store and forward with many other systems including packed s&f
with F6FBB-BBS's. In addition it can be filled by simply monitoring the
frequency. So you will get an up-to-date mailbox without transmitting
yourself.

So I decided to try a port of the BBS-part of DP to Linux. Joachim gave me
his Pascal-sourcecode and I translated it with P2C by Dave Gillespie
(contained in most Linux-distributions) to C. P2C did a terrific job, thanks
Dave! Only some minor prework at the sources was needed and P2C created
almost executable code. An unix socket interface was added on both sides,
TNT and DPBox and the first successful tests were performed.

Many improvements were done since then, even the PACSAT broadcast
transmitter/ receiver is included now. The combination TNT and DPBox is
running currently in some german full time BBS's and performing good and
stable. For more information please consult the DPBox-Documentation.

----------------------------------------------------------------------------

1. Screen layout

----------------------------------------------------------------------------

1.1. Virtual screens

In simple other programs all commands and the data for all channels are
displayed on one screen. This is not easy to handle and often leads to
confusion of the user. Therefore TNT uses a 'virtual' screen for every kind
of data. Because only one real display is available the operator must choose
which of the several virtual screens he wants to see. He can switch between
them by using special codes or keys on the keyboard.

To see which screen and channel is active and to give global information a
statusline is displayed at the bottom of the screen.

All virtual screens (or the two parts of the connect screen) can be
configured larger than the real display on the screen. Therefore only a
small window of the virtual screen is displayed. The window can be moved by
the operator.

----------------------------------------------------------------------------

1.2. Types of virtual screens

It is possible to operate several connection on the same frequency.
Therefore a screen for every connection is implemented. The connect screen
is splitted to a part where all input is typed and a part where all received
data will be displayed. A statusline with all information about the
connection is located between these two parts. Optionally some lines
displaying the activity on the frequency can be displayed (command MONLINES,
'lines_moncon' in tnt.ini).

To change parameters or give commands to the TNC a command screen is
available. To simplify operation all commands can be entered in the connect
screens, too by using a colon (:) as the first character.

It is possible to monitor all activity of other stations on the frequency.
To display these information a monitor screen is available.

In addition there are some additional screens for special purposes. A screen
for the heard stations list, for the extended monitor feature, for the
online-help and for the box read generator. If a link to DPBox is active,
there is a screen for the box operator- console, too.

----------------------------------------------------------------------------

1.3. Main statusline

The statusline at the bottom of the screen shows the main status of the
program. It shows the screen type (connect, command or monitor) and the
current channel. In addition any open file (send or receive) on the current
channel will be displayed.

If huffman compression is active on the selected channel CONNECT is replaced
by CONN(H) and EXTMONI by EXTM(H).

In addition a 'P' will be displayed if the data output is paused, a 'I' if
insert mode is active. If the hostmode synchronisation is lost a 'S' will be
displayed. If the TNC was busy and a resend of data from the computer is
done, a 'B' will be displayed. If a routing script is active a 'X' will be
displayed.

If data is received on a channel which is not displayed the channel number
will be displayed until it is switched to the connect screen of this
channel. If a connection is active on a channel it is displayed by a '+' at
the channel position.

If a file is open on the displayed channel, a two-character file type
identifier and the filename (only last 14 charcters) will be displayed in
the statusline. Files which receive data will be displayed in the first file
field, files which transmit data will be displayed in the second file field.
The two-character file type identifier will be explained in the file command
chapter.

----------------------------------------------------------------------------

2. Commands

----------------------------------------------------------------------------

2.1. Keyboard-commands

Notes:

The combination Alt and key generates the code <ESC>key in normal console
mode. Under X the Alt-key is not supported in that way. Therefore to
activate for example the monitor screen with X you have to type first <ESC>
and then M instead of Alt-M.

(*1) : Input part of connect or mailbox screen.
(*2) : Command screen and input part of extended monitor screen.
(*3) : Monitor screen, receive part of connect, extended monitor or
       mailbox screen.
(*4) : Command, boxlist, heard and help screen
(*5) : Only on monitor screen

----------------------------------------------------------------------------

2.1.1. Cursor movement and miscellaneous

CR, LF, <CNTL>M, <CNTL>J
     The line from the beginning up to the cursor position is transmitted on
     the current channel (*1) or will be transferred to the command
     interpreter (*2). If the first character of (*1) is a colon (":"), the
     line will be sent to the command interpreter (without the colon). A
     colon as the first character of (*2) will be ignored and removed. If
     WHOLElin is set to on, the whole line will be used and the cursor
     position is ignored.

Arrow key left, <CNTL>S
     Move the cursor one character to the left, if not on the start of the
     line (*1,*2).

Arrow key right, <CNTL>D
     Move the cursor one character to the right, if not on the end of the
     line (*1,*2).

Arrow key up, <CNTL>E
     Move the cursor one line up, if not on the top of the screen
     (*1,*2,*4).

Arrow key down, <CNTL>X
     Move the cursor one line down, if not on the bottom of the screen
     (*1,*2,*4).

<CNTL>A
     Move the cursor to the start of the line (for command screen and input
     part of connect screen).

<CNTL>F
     Move the cursor to the last non-space character of the line (for
     command screen and input part of connect screen).

INSERT, <CNTL>N
     Toggle insert-mode. If insert-mode is active a 'I' is displayed in the
     statusline at the bottom. In normal mode all characters are
     overwritten, in insert mode all characters from cursor position to the
     end of the line will be shifted one position right (*1,*2).

DEL, <CNTL>H
     Delete character left of cursor and move cursor one position left. If
     insert-mode is active, all characters from cursor-position to the end
     of the line is moved one position left (*1,*2).

<CNTL>L
     The character at the cursor position will be deleted, all characters
     right of the cursor up to the end of the line will be shifted one
     position left (*1,*2).

<CNTL>Y
     Delete all characters from the cursor position to the end of the line
     (*1,*2).

<CNTL>V
     The pass character. If for example you want to send cntl-T to the
     connected station first type cntl-V and then a 'T'. A different
     attribute of the character shows that it is a control character (*1).

----------------------------------------------------------------------------

2.1.2. Window movement and control

<CNTL>R, Arrow key up (*5)
     Move the display window of the virtual screen one line up, if not on
     top of virtual screen (*3).

<CNTL>C, Arrow key down (*5)
     Move the display window of the virtual screen one line down, if not on
     bottom of virtual screen (*3).

Page up, <CNTL>W
     Move the display window of the virtual screen one page up, if not on
     top of virtual screen (*3,*4).

Page dwn, <CNTL>Z
     Move the display window of the virtual screen one page down, if not on
     bottom of virtual screen (*3,*4).

HOME
     Move to the beginning of the window (*3,*4).

END
     Move to the end of the window (*3,*4).

<CNTL>P, <ALT>P, <ESC>P
     Toggle stop of data-output on the current screen, only possible on
     connect and monitor screen. Stop is indicated by a 'P' in the
     statusline at the bottom (Monitor screen and receive part of connect
     screen).

----------------------------------------------------------------------------

2.1.3. Screen switching

F1 - F9
     Switch to connect screen of channel 1 to 9. If the key is pressed again
     and the currently selected channel plus 10 exists, these 10 is added to
     the actual channel (2 two times F1 lead to channel 11).

F10
     Switch to connect screen of channel 0 (unproto channel). If pressed
     again switch to channel 10, 20, ... if they exist.

F11, <ALT>M, <ESC>M
     Switch to monitor screen, if in monitor screen switch back to last
     selected screen.

F12, <ALT>C, <ESC>C
     Switch to command screen.

<ALT>Q, <ESC>Q
     Switch to connect screen of current channel.

TAB, <CNTL>I
     Select a new channel, a '??' as the channelnumber in the statusline
     indicates this. A number between 00 to 99 for channels 00 to 99 must be
     entered. Only existing channelnumbers are accepted. If the extended
     monitor is active, the channelnumber of the extended monitor channel (0
     to 4) is selected instead of the connect channel.

<ALT>H, <ESC>H
     Switch to help screen.

<ALT>X, <ESC>X
     Switch to extended monitor screen.

<ALT>S, <ESC>S
     Update heard stations list and display heard list screen.

<ALT>L, <ESC>L
     Switch to box read generator (only if activated on current channel). If
     already in read generator screen switch back to screen before
     selection.

<ALT>B, <ESC>B
     If DPBox is connected, switch to box operator console.

----------------------------------------------------------------------------

2.1.4. Keyboard macros

<ALT>0 - <ALT>9, <ESC>0 -<ESC>9
     User definable function keys for either text or commands.

----------------------------------------------------------------------------

2.2. Commands in command mode

----------------------------------------------------------------------------

2.2.1. TNC-commands

Most commands in hostmode consist of one character. It is difficult to
remember the charcter for a not often needed command. Therefore more verbose
command names were created for every TNC command. But it is still possible
to use the original command characters. Only the known commands are
implemented, if you have a TNC software which has additional commands, the
command 'TNC' must be used.

More information about the commands can be found in the documentation of the
TNC software (TNC commands of NORD><LINK The Firmware 2.6a). Some of these
commands are no longer existing in newer versions (TF 2.7).

DAMAdis,"B"     : DAMA timeout
Version,"V"     : Shows version of TNC-software
CHeck,"@T3"     : Connection timer T3
Connect,"C"     : Start connection
CText,"U"       : Response text if connect is received by TNC
DIGIpeat,"R"    : Digipeat function
Disconne,"D"    : End connection
DAYTIme,"K"     : Time and date functions
Frack,"F"       : Start value of round trip timer for retry timing
FUlldup,"@D"    : Fullduplex on modem side
MAXframe,"O"    : Maximum number of outstanding packets
Monitor,"M"     : Frequency monitor functions
MYcall,"I"      : Callsign of the local operator
                  With MYCALL the call sign is set permanently on this
                  channel, with "I" only up to the next disconnect.
                  A permanent MYCALL can be removed by using "$" as call
                  sign.
Persist,"P"     : Persistance value for transmitter keyup
RESptime,"@T2"  : Delay before Info-frame will be confirmed (timer T2)
REtry,"N"       : Maximum number of retries
SLottime,"W"    : Slottime value for transmitter keyup
Txdelay,"T"     : Time after transmitter keyup to sending of data
USers,"Y"       : Number of channel open for connection
Xmitok,"X"      : Locking of transmitter
BUFfers,"@B"    : Free buffers of TNC
A1SRTT,"@A1"    : A1-value for smoothed round trip timer
A2SRTT,"@A2"    : A2-value for smoothed round trip timer
A3SRTT,"@A3"    : A3-value for smoothed round trip timer
IPOll,"@I"      : Packet length up to which I-Poll mode is used
VALcall,"@V"    : Check callsign in connect command

All verbose commands can be abbreviated, the upcase part is mandatory.

----------------------------------------------------------------------------

2.2.2. External commands

Most of the commands can be abbreviated, the upcase part of the command is
mandatory.

2.2.2.1. Saving data to files

LOGQso <filename>
     A file will be openend and all transmitted and received data on the
     selected channel will be saved. If no directory was specified, the file
     will be stored in 'download_dir'. If 'download_dir' is empty, the
     current directory is used. A CR will be translated to a LF and
     control-codes will be translated to ^X. Umlaut-conversion will be done,
     too. The file type ID is 'RN', receive normal.

LOGRec <filename>
     Same as LOGQSO but only received data will be saved. The file type ID
     is 'RN', receive normal.

LOGSnd <filename>
     Same as LOGQSO but only transmitted data will be saved. The file type
     ID is 'RN', receive normal.

READ <filename>
     A file will be openend and all received data will be saved. If no
     directory was specified, the file will be stored in 'download_dir'. If
     'download_dir' is empty, the current directory is used. Only a CR to LF
     translation is done. READ shall be used to receive 7PLUS files. The
     file type ID is 'RP', receive plain.

READBin <filename>
     Same as READ but no translation of characters is done. The file type ID
     is 'RB', receive binary.

READAbin <filename>
     Start receiving a file using the AutoBIN-protocol. If no directory was
     specified, the file will be stored in 'download_dir'. If 'download_dir'
     is empty, the current directory is used. The file type ID is 'RA',
     receive AutoBIN.

LOGAbin <filename>
     Same as READABIN except that at the end of transmission the transfer
     statistics are only displayed, but not sent (useful for receiving
     binary files from BBSs which get confused by the statistics). The file
     type ID is 'RQ', receive AutoBIN, quiet mode.

READYapp [filename]
     Start receiving a file using the YAPP-protocol. If no filename was
     given, the name transmitted will be used, a directory contained in the
     name will be removed. If no directory was specified, the file will be
     stored in 'download_dir'. If 'download_dir' is empty, the current
     directory is used. The file type ID is 'RY', receive YAPP.

CLose
     Close the active receive-file.

LOGMon <filename>
     A file will be openend and all received data on the monitor screen will
     be saved. If no directory was specified, the file will be stored in
     'download_dir'. If 'download_dir' is empty, the current directory is
     used. A CR will be translated to a LF and control-codes will be
     translated to ^X. Umlaut-conversion will be done, too. The file type ID
     is 'RN', receive normal.

RDMON <filename>
     Same as LOGMON but only a CR to LF translation is done. The file type
     ID is 'RP', receive plain.

RDMONBin <filename>
     Same as RDMON but no translation of characters is done. The file type
     ID is 'RB', receive binary.

CLOSEMon
     Close the active receive-file on the monitor screen.

LOGXmon <filename> (on extended monitor screen)
LOGXmon <xmon-channel> <filename> (on other screens)
     A file will be openend and all received data on the current (on
     extended monitor screen) or on the specified (on other screens)
     extended monitor channel will be saved. If no directory was specified,
     the file will be stored in 'download_dir'. If 'download_dir' is empty,
     the current directory is used. A CR will be translated to a LF and
     control-codes will be translated to ^X. Umlaut-conversion will be done,
     too. The file type ID is 'RN', receive normal.

RDXMON <filename> (on extended monitor screen)
RDXMON <xmon-channel> <filename> (on other screens)
     Same as LOGXMON but only a CR to LF translation is done. The file type
     ID is 'RP', receive plain.

RDXMONBi <filename> (on extended monitor screen)
RDXMONBi <xmon-channel> <filename> (on other screen)
     Same as RDXMON but no translation of characters is done. The file type
     ID is 'RB', receive binary.

CLOSEXmo (on extended monitor screen)
CLOSEXmo <xmon-channel> (on other screens)
     Close the active receive-file on the current (on extended monitor
     screen) or on the specified (on other screens) extended monitor
     channel.

APPend [ON/OFF]
     Flag if data shall be appended to existing files (only valid for
     LOGQSO, LOGREC, LOGSND, LOGMON and LOGXMON).

AUTOBIn [ON/OFF]
     Flag if AutoBIN-receive shall start autonomously on reception of a
     valid AutoBIN-Header (AutoBIN-receive is performed in quiet mode like
     started with LOGABIN-command).

AUTOYApp [ON/OFF]
     Flag if YAPP-receive shall start autonomously on reception of a valid
     YAPP-Header.

AUTO7Pl [ON/OFF]
     Flag if 7Plus-receive shall start autonomously on reception of a valid
     7Plus-Header. To indicate 7Plus reception a file type ID of 'A7' will
     be displayed at the bottom statusline.

2.2.2.2. Sending files

SEND <filename>
     Send a file on the selected channel, a LF will be translated to CR. If
     no directory was specified, the file will be fetched from 'upload_dir'.
     If 'upload_dir' is empty, the current directory is used. SEND shall be
     used to send 7PLUS files. The file type ID is 'TP', transmit plain.

SENDLog <filename>
     Same as SEND but control-codes will be translated to ^X and
     Umlaut-conversion will be done. The file type ID is 'TN', transmit
     normal.

SENDBin <filename>
     Same as SEND but no LF to CR translation. The file type ID is 'TB',
     transmit binary.

SENDAbin <filename>
     Send a file using the AutoBIN-protocol. If no directory was specified,
     the file will be fetched from 'upload_dir'. If 'upload_dir' is empty,
     the current directory is used. The file type ID is 'TA', transmit
     autoBIN.

SENDQbin <filename>
     Same as SENDAbin, but it is not waited for #OK# after transmitting the
     #BIN#-header and the statistics are not transmitted. The file type ID
     is 'TQ', transmit autoBIN, quiet mode.

SENDYapp <filename>
     Send a file using the YAPP-protocol. If no directory was specified, the
     file will be fetched from 'upload_dir'. If 'upload_dir' is empty, the
     current directory is used. The file type ID is 'TY', transmit YAPP.

BReak
     Abort sending of a file.

FPACLen
     Maximum packet length used for file sending. If SENDLog is used, the
     length is divided by two because of possible Umlaut-conversion. The
     allowed range is between 20 and 256 characters. If static huffman
     compression is activated the maximum value is reduced to 255
     characters. Changes are global for all channels.

2.2.2.3. Shell,Run,Redirect and Sockets

SHell
     Open a shell on the current channel. The call sign of the remote
     station is used as a user-id. If the user-id does not exist in the
     system, it depends on 'unix_new_user', whether 'remote_user' is used
     instead (0) or the user-id is created (1). All received data on the
     current channel will be sent to the shell, all data from the shell will
     be sent on the current channel. All line feed characters sent by the
     shell will be translated to carriage return . All carriage return
     characters received from the remote station will be translated to line
     feed prior to sending to the shell.
     (This command is available only if TNT is invoked by root.)

TSHell
     Same as SHELL, but no conversion of linefeed and carriage return will
     be done.

ROOTSH
     Same as SHELL, but a shell with superuser privileges (root) is started.

TROOTSH
     Same as ROOTSH, but no conversion of linefeed and carriage return will
     be done.

ENDShell
     End the shell on the current channel.

RUN <program>
     On the current channel the specified program will be executed. All
     received data on the current channel will be used as standard input of
     the program, all data sent to standard output by the program will be
     sent on the current channel. Only programs contained in 'tnt_bin_dir' can
     be executed. All line feed characters sent by the program will be
     translated to carriage return. All carriage return characters received
     from the remote station will be translated to line feed prior to
     sending to the program.

RUNT <program>
     Same as RUN, but no conversion of linefeed and carriage return will be
     done.

ENDRun
     Abort execution of the program on the current channel.

REDir <device>
     Redirection of input/output. All received data on the current channel
     will be sent to <device>, all data received from <device> will be sent
     on the current channel.

ENDRedir
     End the redirection of the current channel.

SOCKCon <socket address>
     The socket specified will be connected and all data received from the
     socket will be transmitted on the current channel and vice versa. All
     line feed characters received from the socket will be translated to
     carriage return. All carriage return characters received from the
     remote station will be translated to line feed prior to sending to the
     socket. More information can be found in the chapter 'Detailled
     Description'.

TSOCKCon <socket address>
     Same as SOCKCON, but no conversion of linefeed and carriage return will
     be done.

ENDSOCKC
     End the socket connection on the current channel.

SOCket AXSERV <socket address>
     An AX25 server will be installed on the specified socket. From now on a
     connection to this socket is possible and after authentification AX25-
     connections can be started (for example internet-access to packet
     radio). More information can be found in the chapter 'Detailled
     Description'.

SOCket AXSPEC <socket address>
     Same as SOCKET AXSERV, except data from the client to AX25 will be
     transmitted directly on occurence of line feed or carriage return
     without waiting for 'pty_timeout'.

SOCket NETCMD <socket address> <default callsign>
     A Wampes-compatible AX25 server will be started on the specified
     socket. If no own callsign is given in the connect command the default
     callsign is used. More information can be found in the chapter
     'Detailled Description'.

ENDSock <socket address>
     End the socket server on the specified socket address. All connections
     to the server are disconnected.

2.2.2.4. Directory

CD <dir>
     Change the working directory to <dir>. If <dir> is empty, the
     HOME-directory will be used.

CWD
     Displays the current working directory.

2.2.2.5. Miscellaneous

TNC <command>
     <command> is sent as a command to the TNC without any conversion.

CHANnel <x> or S <x>
     Switch to connect screen of channel x. If included in a command script,
     no changing of screens is performed, it simply specifies the channel
     used for the following commands.

CONCall <callsign>
     If the updated callsign in the statusline is corrupted by a connect
     message in normal text, the callsign can be restored using this
     command.

CStatus
     A list of all connected channels with starttime of connect and
     callsigns will be displayed.

SENDCom <filename>
     Execute a file containing TNC or external commands (command script).

CBell [ON/OFF/OTHER]
     Beep if the state of a connection changes (connect bell). If other,
     then a beep will only be generated if a station connects on a different
     than the current channel.

INFObell [ON/OFF/OTHER]
     Beep if a new packet is received on any channel (information bell). If
     other, then a beep will only be generated if a new packet is received
     on a different than the current channel.

COOKie [ON/OFF]
     Send a cookie if connected from a remote station.

UMLaut [ON/OFF]
     Umlaut conversion.

CONText [ON/OFF]
     Send a special connect text, using macros, overrides COOKIE.

TXEcho [ON/OFF]
     Echo all sent data from input part to part with received data.

PTYEcho [ON/OFF]
     Echo all data received and send on a channel on which SHELL, RUN,
     SOCKET or REDIR is active.

NAME <name>
     Set the name of the call on the current channel to <name>, if <name> is
     not specified, the stored name is displayed (only if channel
     connected).

STIme
     Send time and date on the current channel.

SCOokie
     Send a cookie on the current channel.

TIMESET
     Send time of computer to TNC.

DATESET
     Send date of computer to TNC.

RESYnc
     Displays the number of hostmode resynchronisations since program start
     and, if applicable, some additional information concerning the problem.

LAYer3 [ON/OFF]
     Enables or disables the analysis of NETROM/TheNet headers (pid CF) in
     monitored frames.

HEArd [ON/OFF]
     Enables or Disables the heard list. If disabled, the heard list is not
     updated any longer.

KMAcro
     Reload the keyboard macro file 'func_key_file' defined in the
     init-file.

MSEnd <filename>
     Send a file, using macros. The file is fetched from 'macrotext_dir'
     defined in the init-file.

WORDWrap [ON/OFF]
     Enables the wordwrap-function. An incomplete word at the end of the
     line will automatically be copied to the next line.

WHOLElin [ON/OFF]
     If set to on, the whole line will be transmitted, if set to off only
     the part of the line up to the current cursor position.

LINelen <value>
     Set the linelength at which additional input characters are ignored or
     wordwrap will be executed. This value shall normally be set to 80
     characters. The default value can be specified by 'input_linelen' in
     the init-file.

MONLines <value>
     If you like to see a part of the monitor screen on the connect screen
     the number of monitor lines can be specified here. Set to 0 if you
     don't want monitor lines. The default value can be specified by
     'lines_moncon' in the init-file.

CONDiv <value>
     Changes the input/output-lines ratio on the connect screen. For further
     details see 'scr_divide' in the init-file.

XMONDiv <value>
     Changes the input/output-lines ratio on the extended monitor screen.
     For further details see 'xmon_scr_divide' in the init-file.

MBOXDiv <value>
     Changes the input/output-lines ratio on the mailbox screen. For further
     details see 'mbscr_divide' in the init-file.

COMP [ON/OFF]
     Huffman compression is enabled/disabled on the current channel.
     'CONN(H)' in the bottom statusline indicates an enabled huffman
     compression. If no value is given the current status is returned. To
     synchronize the switching to huffman compression between local and
     remote station the remote command //COMP shall be used instead.

BSCRHold [ON/OFF]
     If enabled, no scrolling of the displayed window will be done if the
     last line of the screen buffer is not displayed (backscroll active) and
     the first displayed line is still in the screen buffer.

TABExp [ON/OFF]
     If enabled, a TAB-character is expanded to position the cursor on the
     next tab-stop. A tab-stop is defined every 8 characters. If disabled
     '^I' is displayed instead.

FREE
     This command will display the number of free buffers in the TNC. The
     command does not execute a '@B'-command, but it displays the value of
     the last periodical polling.

SIGNon
     Display version and copyright information of TNT.

LOGBOOK [ON/OFF]
     This command can disable the writing to the logbook-file.

EXit
     Leave TNT.

QUIT
     Leave TNTC without termination of the TNT-daemon.

2.2.2.6. Routing scripts

XConnect [portheader:]<callsign>
     Start of a routing script for the specified callsign. An active script
     can be ended by using 'OFF' as callsign. If a routing script is active,
     a 'X' in the main statusline will be displayed. If the callsign is not
     found in the routing database, a simple connect is started. If a
     multiport-TNC is used, a valid portheader entered with command QRG can
     be used in front of the callsign to select the port where the first
     connect shall be started. Using this command an automatic allocation of
     a free SSID for the source call is performed. So multiple connects to
     the same digipeater are possible.

QRG [<port> <frequency>] [portheader:]
     With this command the operating frequency of the program is defined.
     The specified frequency is used to select valid routing data out of the
     routing database. <frequency> can be any string up to 19 characters.
     For TNCs with one port use 0 as <port> and omit <portheader:>: QRG 0
     438.300 For multiport-TNCs for each port a frequency and the portheader
     must be defined: QRG 0 438.300 1: QRG 1 430.900 2: Without arguments
     the current frequency definition is displayed.

LSNOTOWN
     This command lists all callsigns for which an entry in 'tnt_notownfile'
     was found. These callsigns are not allowed to be used as source calls
     for a xconnect. So you are able to define some SSID's of your call
     which TNT will not use (needed if different software is operated with
     the same callsign).

LDNOTOWN
     If 'tnt_notownfile' was changed while TNT is running, it can be
     reloaded with this command. A reload is necessary because TNT only
     reads the file at startup and copies the data to memory.

2.2.2.7. Extended monitor and boxlist

XMON [ON/OFF]
     Enables or Disables the extended monitor function. If disabled,
     received monitor frames are not analysed any longer.

EXTmon <call1> <call2> [<call3> <call4>] (extended monitor screen)
EXTmon <xmon-channel> <call1> <call2> [<call3> <call4>] (other screens)
     On the current (extended monitor screen) or on the specified (other
     screens) channel a connection shall be monitored. If only <call1> and
     <call2> is specified, frames from <call1> to <call2> and <call2> to
     <call1> are monitored, otherwise frames from <call1> to <call2> and
     <call3> to <call4>.

EXTAmon <call1> <call2> [<call3> <call4>]
     Same as EXTMON except that the next free xmon-channel will be used. The
     resulting channel will be displayed as command response.

ENDEXtm (extended monitor screen)
ENDEXtm <xmon-channel> (other screens)
     The extended monitor on the current (extended monitor screen) or the
     specified (other screens) channel will be closed. The connection will
     be no longer monitored.

EXTComp [ON/OFF]
     Huffman compression is enabled/disabled on the current extended monitor
     screen. 'EXTM(H)' in the bottom statusline indicates an enabled huffman
     compression. If no value is given the current status is returned.

LOGBlist
     On the current channel or on the mailbox screen a file is openend and
     all received data is saved. The command is similar to LOGREC except a
     unique filename is generated (in /tmp directory) and the file will be
     removed during exit of TNT.

BLIst [<filename>]
     On the current channel or on the mailbox screen the last active file is
     used for the boxlist screen and feature. If the file is not closed up
     to now, it will be closed. Optionally a filename can be specified. In
     this case this file will be loaded into the boxlist screen.

XBList
     Finish boxlist and close the boxlist screen on the current channel.

2.2.2.8. Interface commands

IFAce <socket-name>
     Build up a socket connection to an external program via an UNIX-socket
     <socket-name>.

ENDIFace <socket-name>
     Disconnect the socket connection to an external program via an
     UNIX-socket <socket-name>.

FINIFace <socket-name>
     Same as ENDIFACE, except that the external program get the command to
     terminate its execution.

ACTIf <socket-name>
     Activate the external program on the current channel using the already
     built up socket connection.

DEACtif <socket-name>
     Deactivate the external program on the current channel.

SNOCONN <string>
     String which will be sent, if a program was remotely activated via the
     Interface and the activation was not successful.

2.2.2.9. DPBox-interface commands

ACTBox
     Build up a socket connection to DPBox via an UNIX-socket specified by
     'box_socket' in the init-file.

DEACTBox
     Disconnect the socket connection to DPBox.

FINBox
     Disconnect the socket connection to DPBox and terminate DPBox.

BOX [callsign]
     Activate DPBox on the current channel using the already built up socket
     connection. If a callsign is specified at the mailbox console this
     callsign is used for the boxsession instead of the box callsign.

ENDBox
     Deactivate DPBox on the current channel.

AUTOBOx [ON/OFF]
     If activated, all connections are scanned for mail-headers. A valid
     mail-header leads to saving the following mail. If the end is reached,
     the mail will be sent via the interface to DPBox.

MONBox [ON/OFF]
     If activated, all monitored frames are scanned for mail-headers. A
     valid mail-header leads to an extended monitoring of the connection. If
     no frames are lost and the mail-end is reached, the monitored mail will
     be sent via the interface to DPBox.

LMONbox
     All mails which are currently received using the MONBOX-feature are
     displayed.

SNOBOX <string>
     String which will be sent, if DPBox was remotely activated and the
     activation was not successful.

SCANMBEA [<source> <destination> <own_call> <connectcall> [<timeout>]] [$]
     TNT can monitor mail-beacons and if it finds your call in it, it can
     activate store and forward to get your new mail. To activate this
     feature you have to give source and destination of the expected
     mail-beacon (which will be the callsign of your bbs and MAIL as
     destination), your own call (this call is searched in the beacon data)
     and a connectcall with an optional timeout. The connection is built up
     using the xconnect-feature giving connectcall and timeout as
     parameters. If the connection is established store and forward will
     begin. The command without parameters will give the current data. If
     you want to deactivate this feature, give a '$' as a single argument.

LDBOXFil
     All files concerning the box configuration ('autobox_dir',
     'tnt_boxender' and 'f6fbb_box') will be reread. So changes in these
     files can be made without the need of leaving TNT.

ACCUIReq [ON/OFF]
     If ON, unproto list requests to the callsign defined by ACCUICal will
     be sent to DPBox. DPBox will then take the needed action.

ACCUICal <BBS-callsign>
     If an unproto list request is received with the callsign (including
     SSID) defined here, the request will be sent to DPBox. To clear the
     callsign the value '$' can be used.

2.2.2.10. Password generation commands

PRIV
     This command starts the password generation sequence. The command is
     rejected if the channel is not connected or the callsign of the
     connected station is not contained in 'tnt_pwfile'. The taken action is
     dependent on the type of the password generation defined for the
     callsign.

LISTPRIV
     This command lists all callsigns for which an entry in 'tnt_pwfile' was
     found. In addition for every callsign the type of password generation
     and the file containing the password data is listed.

LOADPRIV
     If 'tnt_pwfile' was changed while TNT is running, it can be reloaded
     with this command. A reload is necessary because TNT only reads the
     file at startup and copies the data to memory.

2.2.2.11. Remote-command permissions and access levels

REMOte [ON/OFF]
     Enables or disables remote commands for ALL channels. If disabled
     commands with status ALWAYS are not available.

REMAllow [ON/OFF]
     Enables or disables remote commands on the current channel. If disabled
     commands with status ALWAYS are available. This command is allowed only
     if connected. In addition the current status is changed at a new
     connect according to tnt_noremfile.

SETACC <remote-command> [NORMAL/SYSOP/ROOT/ALWAYS]
     defines which access-level a remote-station needs to execute a remote-
     command. NORMAL means the command is available for everyone, commands
     with SYSOP status only after a successful validation with //sys. If the
     root-sysop flag was set in tnt_sysfile, commands with ROOT status are
     available after validation. The ALWAYS status means that this command
     is available even if the connected station is contained in
     tnt_noremfile.

NOACC [ON/OFF]
     If set to ON, only remote stations contained in tnt_sysfile can connect
     the station. All other will receive the string defined by SNOACC and
     will be disconnected afterwards.

SNOACC <string>
     defines the string which is sent to a station not authorized to
     connect.

LISTSYS
     This command lists all callsigns for which an entry in 'tnt_sysfile'
     was found. In addition for every callsign the file containing the
     password data is listed and if the sysop-status can be achieved after
     password validation (0: not root-sysop, 1: root-sysop).

LOADSYS
     If 'tnt_sysfile' was changed while TNT is running, it can be reloaded
     with this command. A reload is necessary because TNT only reads the
     file at startup and copies the data to memory.

LSTNOREM
     This command lists all callsigns for which an entry in 'tnt_noremfile'
     was found. For these callsigns remote-commands are disabled except the
     commands with status ALWAYS. The disabling of remote-commands remains
     until the channel is disconnected, so connecting or reconnecting to a
     different station will not enable remote-commands any more. A change is
     possible using the command REMALLOW.

LDNOREM
     If 'tnt_noremfile' was changed while TNT is running, it can be reloaded
     with this command. A reload is necessary because TNT only reads the
     file at startup and copies the data to memory.

LSTFLCHK
     This command lists all callsigns for which an entry in 'tnt_flchkfile'
     was found. Connections from these callsigns will get no connect-text,
     no remote access and will not be linked to DPBox or other programs
     using the interface. In addition no entry will be included in the
     logbook.

LDFLCHK
     If 'tnt_flchkfile' was changed while TNT is running, it can be reloaded
     with this command. A reload is necessary because TNT only reads the
     file at startup and copies the data to memory.

LSEXTREM
     This command lists all currently active extended remote commands, their
     access level, the number of significant characters and the related
     command with parameters. This data is read from 'tnt_extremotefile' at
     startup of TNT.

LDEXTREM
     If 'tnt_extremotefile' was changed while TNT is running, it can be
     reloaded with this command. A reload is necessary because TNT only
     reads the file at startup and copies the data to memory.

AUTOStrt [ON/OFF]
     Enables or disables the autostart feature.

LSAUTOST
     This command lists all currently active callsign/SSID combinations, for
     which autostart commands are defined. This data is read from
     'tnt_autostartfile' at startup of TNT.

LDAUTOST
     If 'tnt_autostartfile' was changed while TNT is running, it can be
     reloaded with this command. A reload is necessary because TNT only
     reads the file at startup and copies the data to memory.

2.2.2.12. Broadcast transmission/receiption

SENDBC <filename>
     The specified file will be sent using PACSAT broadcast protocol.

BCRQST [ON/OFF]
     If set to on, broadcast requests for missing data are generated, if off
     it is just waited for a retransmission.
SHPACSAT [ON/OFF]
     If set to on, broadcast frames are displayed, if off, no display is
     done.

DECBCAST [ON/OFF]
     If set to on, broadcast-frames are decoded. If set to off, broadcast
     frames are not decoded.

BCRXstat
     Display of the already received or currently received files by the
     broadcast receiver including some status information.

BCTXstat
     Display of the files currently transmitted by the broadcast transmitter
     including some status information.

----------------------------------------------------------------------------

3. Detailled description

----------------------------------------------------------------------------

3.1. Remote commands

If remote is enabled the remote station can give some commands to the
program. All remote commands start with a double slash '//'. This double
slash must be entered directly at the beginning of a line, otherwise the
command is not recognized.

The following remote commands are recognized:

 //COMP on/off          Enable/disable huffman compression
 //NAME <name>          Store name in database
 //CSTAT                Show all active connections
 //SHELL                Start a UNIX-shell session
 //TSHELL               Start a UNIX-shell session without CR/LF translation
 //RUN <program>        Execute a program
 //RUNT <program>       Execute a program without CR/LF translation
 //RUN                  Directory of all available programs
 //BOX                  Start DigiPoint Box
 //COOKIE               Send a cookie
 //DIR <filter>         Show directory
 //DIRLONG <filter>     Show directory in long format
 //FREE                 Shows space on disks
 //INFO                 Info about station
 //HELP                 This help-information
 //NEWS                 Display news about this station
 //READ <file>          Read a file
 //BREAK                Abort reading file
 //WRITE <file>         Write file to disk
 //CLOSE                End writing file
 //WPRG <file>          Write file to disk using AUTOBIN-protocol
 //WPRG <file> <rfile>  Same as above, but send back //RPRG <rfile>
 //RPRG <file>          Read a file using AUTOBIN-protocol
 //RPRG <file> <rfile>  Same as above, but send back //WPRG <rfile>
 //WYAPP <file>         Write file to disk using YAPP-protocol
 //RYAPP [file]         Read a file using YAPP-protocol
 //VERSION              Show version of software
 //ECHO <string>        Send back string
 //TIME                 Send time
 //RTT [timestring]     Calculate round trip timer
 //RING                 Ring the bell (call for sysop)
 //QUIT                 Disconnect
 //DISC                 Disconnect

 //SYSOP                Start sysop password validation
 //ROOTSH               Start a shell with root-permissions
 //TROOTSH              Same as above without CR/LF translation
 //SOCKET <sock addr>   Start a connection to a socket
 //TSOCKET <sock addr>  Same as above without CR/LF translation
 //COMMAND <command>    Execute a valid TNT command

----------------------------------------------------------------------------

3.1.1. Default access levels for remote-commands

All remote commands are available for everyone (status NORMAL) except for
//SHELL, //TSHELL, //ECHO, //COMMAND (status SYSOP), //ROOTSH, //TROOTSH,
//SOCKET and //TSOCKET (status ROOT). The command //COMP is available if
remote is disabled on the current channel (status ALWAYS). This default
configuration can be changed by the command SETACC.

----------------------------------------------------------------------------

3.1.2. Sysop password validation (//SYSOP)

If the remote-command //sys is received, a sysop password validation
sequence is started. TNT will pick 5 random numbers with values up to the
length of the stored password string for the remote station. The remote
station must answer with the corresponding 5 characters. The characters can
be contained at every position inside a random string to make a hacking of
the password more difficult. In addition there is no response if the //sys
command was successful or not, the status is changed only internally.
Therefore it is advisable to send //sys 3 or more times with only one
correct answer. This will make the hacking of the password quite impossible.
The algorithm used is compatible to the TheNet password validation.

----------------------------------------------------------------------------

3.1.3. Shell with root-permissions (//ROOTSH)

This command is very dangerous, please be sure that it is available only for
the right people after password validation. If you don't want to allow this
command, set it to status ROOT and set the root-sysop flag in tnt_sysfile
for all callsigns to 0.

----------------------------------------------------------------------------

3.1.4. Socket connection (//SOCKET)

This command allows to connect to every socket in your system. Therefore it
is quite dangerous, too. Change to a different status as ROOT is not
recommended. If you want to allow the connect to specific sockets, use the
extended remote commands ('tnt_extremotefile').

----------------------------------------------------------------------------

3.1.5. Dangerous //ECHO command

There are some pirat bulletins floating around in the BBS-network which use
the remote-command //ECHO to let you send a bulletin with offending
contents. Therefore I changed the access level of //ECHO to SYSOP level. If
you put all the BBS's your are working with in tnt_noremfile or if you are
using command REMALLOW to disable the remote commands on the channel you are
connected to a BBS, you can change back the access level of //ECHO to
NORMAL. But be very careful with it! Otherwise there may be an offending
bulletin forwarded worldwide with YOUR callsign as sender!

----------------------------------------------------------------------------

3.1.6. Handling of unknown remote commands

To easily add new remote commands an unknown remote command will be used as
a parameter for //RUN. For example the command //FOOBAR will be translated
to //RUN FOOBAR. If the program FOOBAR is existing in 'tnt_bin_dir', it will be
executed. If the program is not existing, the user will be informed about an
invalid remote command.

----------------------------------------------------------------------------

3.1.7. Extended remote commands

The behaviour described in the last section allows an easy extenstion of the
available remote commands by providing programs in the 'tnt_bin_dir'. If an
extension is needed, which cannot be implemented with a program or the
program needs specific parameters, the extended remote commands feature can
be used.

A new extended remote command consists of a valid remote command plus
parameters. In addition the access level and the number of significant
characters is defined. All data is stored in 'tnt_extremotefile'.

The contents of this file can be displayed by command LSEXTREM. When the
file was updated, it can be reread using command LDEXTREM.

----------------------------------------------------------------------------

3.2. Umlaut conversion

----------------------------------------------------------------------------

3.2.1. Display

If the LINUX-console control codes are used, for a display on the screen the
IBM-characterset is used. No umlaut-conversion will be done. If termcap is
used a received IBM-umlaut is converted depending on UMLAUT. If UMLAUT is
on, the IBM-umlaut is converted into the 8-bit Latin-1 umlaut. If UMLAUT is
off, it is converted to a two character representation ("ae").

----------------------------------------------------------------------------

3.2.2. Sending text

If UMLAUT is off, all entered umlauts are converted to a two character
representation ("ae"). If UMLAUT is on, umlauts will not be converted and
sent as an IBM-umlaut.

----------------------------------------------------------------------------

3.2.3. File-receive

Only log-files (LOGREC, LOGSND, LOGQSO, LOGMON and LOGXMON) are affected by
umlaut conversion. If UMLAUT is on, the IBM-umlaut is converted into the
8-bit Latin-1 umlaut. If UMLAUT is off, it is converted to a two character
representation ("ae").

----------------------------------------------------------------------------

3.2.4. File-send

Only log-files (SENDLOG) are affected by umlaut conversion. If UMLAUT is on,
the 8-Bit Latin-1 umlaut is converted into the IBM-umlaut. If UMLAUT is off,
it is converted to a two character representation ("ae").

----------------------------------------------------------------------------

3.3. Using UNIX-features

----------------------------------------------------------------------------

3.3.1. Shell-login

TNT allows a remote user to log into UNIX as a normal user. All received
data is treated as shell input, all data from the shell is transmitted to
the remote station. To use the shell-login it is necessary to invoke TNT by
the superuser root. Otherwise the shell-login is disabled. The shell can be
started by the operator using command SHELL or TSHELL or by the remote
station using command //SHELL or //TSHELL. It is possible to execute all
programs which are permitted to use from the shell.

To be in line with the end of line convention used in Packet Radio, all line
feed characters from the shell will be translated to carriage return and all
received carriage return characters will be translated to line feed. This
translation can be disabled by using the command TSHELL instead of SHELL or
//TSHELL instead of //SHELL as a remote command.

At login time, it is checked, if the callsign of the remote station is a
valid user-id. If it does not exist, depending on 'unix_new_user' in the
initfile a new user-id is created or the user-id specified by 'remote_user'
is used. In all cases the callsign is stored on the environment variable
'CALLSIGN'.

For some configurations it is useful to be able to get a shell with root
permissions. This can be done using the command ROOTSH and remote command
//ROOTSH or command TROOTSH and remote command //TROOTSH for disabled
CR/LF-translation. As giving superuser access to the system is very
dangerous, extra care must be taken.

To increase performance, all data will be buffered. This means that data is
not sent directly, but if the buffer contains 256 Bytes (the AX25 maximum
packetlength) or if for a specific time no new characters were received.
This time ('pty_timeout') can be configured in the initialisation file.

----------------------------------------------------------------------------

3.3.2. Redirection

A connect screen of TNT does not accept any of the standart control
characters used for screen oriented programs. If you use an AX25 connection
to work with such a program (for example using a TSHELL on another stations
TNT) you can use redirection (command REDIR) to one of the Linux virtual
consoles. Now all control codes are handled correctly and you can work with
the program like you were directly connected to the remote system.

REDIR allows to redirect all data of an AX25-channel to any device which is
known in the system. Examples are the Linux virtual consoles /dev/ttyX or
one part of a tty/pty-pair.

There is no translation of the characters, all data received is given
transparently to the device and vice versa. Like for the shell-login all
data will be buffered before transmission.

----------------------------------------------------------------------------

3.3.3. Running programs

For users who are not familiar with UNIX, the use of a shell is quite
complicated. Therefore a RUN command is implemented, which will execute a
specified program using a shell. If you don't like running TNT under
root-permissions and therefore the shell-login is disabled, the RUN command
allows to execute specific programs by a remote station.

A special directory 'tnt_bin_dir' contains all executable programs. Programs in
other directories cannot be executed by this command. Because no login is
performed, the program is executed using the default user specified by
'remote_user'. If TNT was invoked not by the superuser root, the user can't
be changed. In this case the program is executed under the permission of the
userid from which TNT was started. The callsign of the user is stored in the
environment variables 'CALLSIGN' and 'LOGNAME'. The callsign including the
SSID will be available in the environment variable 'CALLSSID'.

In most cases it is wanted to translate the UNIX-linefeed to Packet-Radio
carriage return and vice versa. If no translation of the characters sent and
received by the program shall be done, the command RUNT must be used. Like
for the shell-login all data will be buffered before transmission.

----------------------------------------------------------------------------

3.3.4. Socket server

If your system is used by several people or is part of a network, you may
want to give access to Packet Radio to these users. Or you want to use
programs on your system, which must be able to perform an outgoing
AX25-connect. To handle these requirements the socket server feature
(command SOCKET) was implemented.

There are three type of servers, AXSERV, AXSPEC and NETCMD. AXSERV and
AXSPEC are almost identical, both define an AX25-server. AXSPEC does not use
the usual buffering method for data described for shell-login, but sends
data directly on occurence of a line feed or carriage return character.
NETCMD is a Wampes-compatible server which allows the usage of programs
designed for Wampes (like conversd) together with TNT.

All types of servers need a socket address. This socket address can have
different formats.

  a. UNIX-sockets
     The format for a UNIX-socket is 'unix:<socket path>' or 'local:<socket
     path>'. The path can be an absolute path beginning with a '/' or a
     relative path to 'tnt_dir'.
     Example:

     unix:/tcp/sockets/convers

  b. INET-sockets
     The format for a INET-socket is 'ip-address:port'. ip-address can be a
     hostname, an ip-address or a '*' for any ip-address. Port can be any
     valid port number or a name for a service.
     Example:

     *:3600
     199.199.10.10:ftp
     foo.bar.com:2000

3.3.4.1. AX25-Server

A local user can connect to this server with 'telnet localhost
<portnumber>'. Then a login with callsign and password is executed. After a
successful login the user is connected to the AX25-server and may use one
channel of the TNC for Packet Radio connections. The usage is quite simple,
help for the user is available. The login information is kept in
'sock_passfile' and is independent of the passwd file.

3.3.4.2. Netcmd

The Netcmd-server works compatible to Wampes. So after connect to the
socket, the server is in command mode and accepts three commands: ASCII,
BINARY and CONNECT. Any other input or wrong arguments lead to a closing of
the connection.

ASCII selects a translation from line feed to carriage return before
transmitting data on the AX25 side and vice versa. This is the default mode.

BINARY selects a transparent connection without any character translation.

CONNECT starts an AX25 connection on a free channel. It needs additional
parameters, the syntax is:

CONNECT <transport mode> <destination callsign> [source callsign]

The only valid value for 'transport mode' is AX25, other modes will lead to
a closing of the connection. The destination callsign must not contain any
digipeaters. TNT uses the xconnect-feature to build up the connection,
therefore the path must be defined in the routing database. Normally the
default callsign entered with the SOCKET command will be used. If a source
callsign is given in the CONNECT command, this will be used instead. There
will be an automatic SSID-update to allow several connections with the same
destination.

After a successful link setup the server will switch to data mode, all
received data will be sent to the socket, all data from the socket will be
transmitted on the AX25 side.

When the link setup was not successful, the socket connection will be simply
disconnected without any further information.

----------------------------------------------------------------------------

3.3.5. Socket connect

You may have installed some socket servers on the system. To give Packet
Radio users access to these, the socket connect feature is available. The
only Argument needed is the socket address of the socket which shall be
connected. The socket address uses the same syntax as the socket server.

Like for the other UNIX-features there is an option to translate carriage
return into line feed and vice versa (command SOCKCON, remote command
//SOCKET) or the possibility for a transparent connection (command TSOCKCON,
remote command //TSOCKET).

Because there is no access restriction to a socket, you have to be careful
with this command. A full connectivity of all sockets shall be allowed only
for a sysop. Users shall get only specific sockets by defining extended
remote commands ('tnt_extremotefile').

----------------------------------------------------------------------------

3.4. File transfer methods

----------------------------------------------------------------------------

3.4.1. AutoBIN file transfer

To transfer binary files easily without much overhead but with a security
check, the AutoBIN-'protocol' was defined. It is implemented in many
PR-programs. Therefore it is implemented in TNT, too. To use AutoBIN the
commands SENDABIN, READABIN and LOGABIN are available for the operator and
//WPRG and //RPRG for a remote user. In addition with AUTOBIN the protocol
is autonomously started after reception of a valid AutoBIN-header.

At the end of a successful transfer the elapsed time and the effective
Baudrate is displayed. If a file was received, the received checksum and the
calculated checksum will be displayed, too. Normally these statistical
information will be send to the remote station, too. In case of LOGABIN or
AUTOBIN enabled the statistical information will only be displayed (to avoid
confusion of some BBSs).

If the transfer was aborted, the connection was disconnected or the
calculated checksum is not equal to the received checksum, the received file
will be moved to a special directory (abin_dir). In addition the name is
changed to a unique name. From time to time it is needed to clean up this
directory. Although in most cases these corrupted files are of no interest,
for the rare cases where they are needed they are kept in this directory.

----------------------------------------------------------------------------

3.4.2. YAPP file transfer

The AutoBIN-'protocol' is used widely in Germany. The rest of the world
usually use the YAPP-protocol. From the technical point of view YAPP and its
extension YAPP-C is the better approach to binary transfer and shall be
preferred.

In TNT for YAPP the commands READYAPP and SENDYAPP are available, a remote
user can use //RYAPP and //WYAPP. To enable the automatic reception of a
YAPP-file, you can set AUTOYAPP to on. All files automatically received will
be stored in 'yapp_dir' defined in tnt.ini.

----------------------------------------------------------------------------

3.4.3. 7Plus file reception

If you receive large numbers of 7Plus files, you might want to store them
directly in a special directory (without any character before and after).
This can be done by setting AUTO7PL to on. Now all received 7Plus files will
be stored in 'tnt_7plus_dir' defined in tnt.ini.

----------------------------------------------------------------------------

3.5. Special connect text and files with macros, Name-database

To be able to send a special connect text to a connecting station, macros
can be included in the connect text file. The connect text file will be sent
on a connect if CONTEXT was set to ON. For default the connect text file
(tnt_ctextfile) in the tnt directory will be used, but you can put for some
users a personal connect text in the connect text directory (ctext_dir). The
file must be named <callsign>.ctx .

In addition a file containing macros can be sent every time you like, not
only on connect (command MSEND). All these files must reside in the macro
text directory 'macrotext_dir'.

To be more personal and to help remembering the name of the operator of the
remote station a name database is included. A name can be entered by the
operator using the NAME command or with //NAME given by the remote station.
If no name is specified after the command, the current name will be
reported.

Following macros are expanded, if found in a connect text or macro file:

%v: Version of TNT running
%c: Call of other station
%n: Name of other station (extract from names database)
%y: Call of own station
%k: Channel number
%t: Current time
%d: Current date
%b: Bell (^G)
%i: Include news-file ('news_file_name')
%z: Timezone
%_: CR/LF
%o: Include a cookie
%?: Send a message if name of other station not contained in
    names database
%%: '%' itself

----------------------------------------------------------------------------

3.6. Routing scripts

The structure of the Packet Radio Network is quite different compared to the
internet. In the internet you can directly specify your destination and the
routing will be done automatically. In the Packet Radio Network there exist
different systems with incompatible routing mechanisms. To connect to a
destionation there may be needed several steps. Suppose the following
example:

You want to connect DL7ZZZ which is standby on the frequency of the
digipeater DB0LUC. Your local digipeater is DB0BLO. Therefore your first
command is to connect DB0BLO:

:c db0blo

If the link setup was successful you will send the line

c db0ber

to the digipeater which then will build up a connection to DB0BER, which is
the next digipeater towards DB0LUC. If the connection is established, DB0BLO
will send you the message:

*** connected to DB0BER'

Now you enter the line

c db0luc db0bln

which means DB0LUC can be reached from DB0BER via DB0BLN. DB0BLN is not
connected, because it uses hop-to-hop acknowledge instead of simple
digipeating. Now if the connection was successful, you get the line

BSUED:DB0BER> Connected to DB0LUC via DB0BLN

and you can at last try to connect your destination with the line:

c dl7zzz

The successful connection is indicated by the line

*** connected to DL7ZZZ

If you do this manually, you must look at your screen and after each
successful connect-message you must enter the new line. The connect-script
facility (command XCONNECT) now does all these steps automatically, if you
have given the routing information to the program. The routing information
will be searched in the routing-database file (route_file_name) and reads
for the example as follows:

T>DL7ZZZ Joe; N>DB0LUC T>DL7ZZZ
N>DB0LUC Digi Luckau; N>DB0BER F>DB0BLN N>DB0LUC
N>DB0BER Digi Tempelhof; N>DB0BLO N>DB0BER
N>DB0BLO Digi 9K6

As you can see the routing entries are recursive, you don't have to specify
the whole routing for the destination. The characters before the callsigns
give the information to the connect script shall connect the digipeater ( N>
) or if the digipeater shall be used in the via path ( F>, D> ). To identify
a normal user T> is used, for mailboxes B> can be used.

Some programs used by normal users allow a connect with the command //c
<callsign>. If you want to use such a user as part of your path, put a T> in
front of the callsign and a '//c <callsign>'-line will be send by the
routing script.

If you frequently change your operating frequency, you may want to use the
QRG command and want to define routing data only valid for a special
frequency ('<IF xxxx> <END>'-clause).

----------------------------------------------------------------------------

3.7. Call update

If you use routing scripts or if you connect manually through a large number
of digipeaters, you easily loose the orientation, where you are. Therefore,
every 'connected to' line will update the callsign displayed in the
statusline.

'reconnected to' lines will update the call in the statusline, too, but
routing scripts will not send the next command line and the logbook call
will not be updated.

If the callsign is changed by a 'connected to' string in normal text, it can
be restored by using the CONCALL command.

----------------------------------------------------------------------------

3.8. Logbook

All connections performed by the station are written into a logbook-file.
Each line contains starttime and endtime of the connection and the callsign
of the remote station. If the destination was connected directly only this
call is logged, if the destination was connected using several digipeaters
or by a routing script, the first digipeater used is logged, too. The name
of the logfile can be specified in the init-file (tnt_logbookfile). The
command LOGBOOK can be used to enable or disable the logbook function.

Example:

   Starttime   |    Endtime     |          Callsign
------------------------------------------------------------------
16.03.94 18:08 | 16.03.94 18:09 | DB0BLO
17.03.94 21:32 | 17.03.94 21:37 | GEHREN:DB0LUC, Uplink: DB0BLO

----------------------------------------------------------------------------

3.9. Keyboard macros

With the keyboard macro feature some often used commands or texts can be
executed or sent by only one keycode. You may define up to 10 keycodes
(<ALT>0 to <ALT>9 or <ESC>0 to <ESC>9) with either text patterns or TNT
commands in a file specified by 'func_key_file' in the init-file.

Each line has to begin with a two digit number specifying the keycode and a
colon. (01: for <ALT>1 / <ESC>1, 10: for <ALT>0 / <ESC>0). A text line must
follow directly after the colon. If the last character of the line is an
asterisk '*' a CR will be sent instead of it, otherwise no CR will be sent.
A command must be preceeded by an additional colon, a CR is always appended
to the command line. The length of the text or command must not exceed the
length of the line.

If the length of one line is not sufficient for your text or you want to
send a text containing macros like time and callsign, you must specify the
commands 'send' or 'msend' instead of a textline. The keyboard macro file is
loaded at startup. If you change this file during execution of TNT, you can
reload the file with the command 'kmacro'.

----------------------------------------------------------------------------

3.10. Boxlist

----------------------------------------------------------------------------

3.10.1. General description

If you get a list of files from a BBS, you will have to write down the files
you are interested in or you must store the list in a file and look through
this file afterwards. In both cases you have to type the filename or number
of the file to get it from the BBS.

The boxlist-feature allows to fetch a file from the BBS by selecting the
file (with cursor keys) from the filelist and simply pressing CR.

If an Interface-connection to a DPBox is active and a 'check'-command with
bulletin-ID in the list is given, all bulletins which are in the bulletin-ID
pool of the DPBox are displayed with a special attribute/colour. That means
you get an overview about the bulletins already contained in your own BBS.

----------------------------------------------------------------------------

3.10.2. Using boxlist

How does it work?

  a. Before requesting the filelist open a logfile. If you are not
     interested in keeping the list, simply use the command 'logblist'. A
     temporary file with a unique name will be used. This file will be
     erased when you exit TNT. If you want to keep the list, use 'logrec
     <filename>'.

  b. If the end of the filelist is received, use the command 'blist'. This
     command closes the logfile and loads it into the boxlist screen. If no
     file was open the last logfile on the current channel will be loaded
     into the boxlist screen.

  c. Use <ALT>L or <ESC>L to toggle connect and boxlist screen. In boxlist
     screen you can use the cursor commands to select a file. Pressing CR
     will send a read command to the BBS. All already fetched files will be
     displayed with a different attribute.

  d. If you have read all files from the filelist you can close the boxlist
     screen by the command 'xblist'.

----------------------------------------------------------------------------

3.10.3. Using keyboard macros

To use the boxlist feature without typing in the commands, it is advisable
to use keyboard macros. For example:

<ALT>8 / <ESC>8 : 'logblist'
<ALT>9 / <ESC>9 : 'blist'
<ALT>0 / <ESC>0 : 'xblist'

These keyboard macros are already included in the sample keyboard macro
file.

----------------------------------------------------------------------------

3.10.4. Recognized formats

At the moment the following list formats are recognized:

  a. DIEBOX check

     7 DL4BCU > TERMINE...16 24.09.94 DL 2214 5 2m Mobilfuchsjagd I05 08.

     -> R TERMINE 16

  b. DIEBOX list

     263 DL1ZAX 02.11.94 18:03 6763 DL-RUNDSPRUCH NR. 39/94

     -> R 263

  c. DIEBOX checklist with BID

     85 DH3FBI > KENWOOD..423 055514DB0GV DL 851 5 LF & VLF Empfang mit TS-5

     -> R KENWOOD 423

  d. RUN C with option D=CRD$@L

     DG0XC DIGI......17 28.04.95 2845DB0BALWE DL 1 DB0BRO-1 wieder ok.

     -> R DIGI 17

----------------------------------------------------------------------------

3.11. Extended monitor

The extended monitor feature allows the monitoring of specific connections
on the frequency with automatic removal of headers and resent packets. There
are 5 (0 to 4) different extended monitor channels available. <ALT>X or
<ESC>X will switch to the extended monitor screens and TAB can be used to
change the channel.

The command EXTMON is used to activate the extended monitor. If you have
given the command from an extended monitor screen, the current channel will
be taken. On other screens you must give the channel number as an additional
parameter before specifying the callsigns. The next free extended monitor
channel will be taken if the command EXTAMON is used.

As command parameters you have to specify the callsigns of the connection
you want to monitor. Normally this will be 2 callsigns and both directions
will be monitored (in different attributes).

Using digipeaters like NETROM/TheNet or RMNC/Flexnet a connection is build
up out of 2 connections. First the connection from station 1 to the
digipeater (DL9xxx <> DB0xxx) and second the connection from the digipeater
to station 2 (DL9xxx-15 <> DG1xxx). In most cases you can only monitor
frames sent by the digipeater. In this case you can specify 4 callsigns
(DB0xxx DL9xxx DL9xxx-15 DG1xxx) and both directions of the connection will
be monitored in the extended monitor screen.

If the monitored connection is huffman-coded, decoding can be activated by
command
EXTCOMP.

The extended monitoring can be finished by the ENDEXTM command.

----------------------------------------------------------------------------

3.12. Use of DPBox

----------------------------------------------------------------------------

3.12.1. General description

DPBox is a daemon which is totally independent of TNT. The daemon must be
activated before using any of the DPBox-commands of TNT.

----------------------------------------------------------------------------

3.12.2. Using unix socket interface

To build up the connection from TNT to DPBox the command 'actbox' must be
used. If the connection shall be closed 'deactbox' must be used.

The command 'finbox' not only closes the connection like 'deactbox', it
gives a termination command to the DPBox daemon.

The unix socket name of DPBox must be defined in 'box_socket' in the
initfile.

----------------------------------------------------------------------------

3.12.3. Mailbox screen

If the connection to DPBox is activated, the mailbox screen (<ALT>B or
<ESC>B) can be used as a sysop-console by executing the 'box' command.

You can either 'quit' or give the command 'endbox' to end your sysop-
session.

All features of a normal connect screen are provided including the boxlist.
In boxlist mode there is an additional feature. If you select a file and
press 'e' instead of CR, the file will erased. 'k' for kill and 'l' for list
are available, too. 't' generates a transfer line where you can add an new
board name, '0' sets the lifetime of the message to 0.

----------------------------------------------------------------------------

3.12.4. Using DPBox via Packet Radio

DPBox can be activated on a normal connect channel by the command 'box', by
the remote command //box or by connecting a channel which SSID of the
callsign is equal to 'tnt_box_ssid' in the initfile.

DPBox is activated only, if the channel is connected.

The 'endbox' command, 'quit' to the box or a disconnect will terminate the
box-session.

----------------------------------------------------------------------------

3.12.5. Autobox and monbox feature

If you set 'autobox' to on, all mails you will receive on any channel will
be sent to DPBox and will be stored in the corresponding board. This
includes personal mail and bulletins.

If you set 'monbox' to on and 'xmon' is on, all monitored frames will be
searched for mail headers. If one is found, it is tried to receive the whole
mail similar to the extended monitor function. If packets are lost or if any
other error occurs, the mail is not accepted. If the mail was correctly
received it will be sent to DPBox and will be stored in the corresponding
board. All bulletins and all personal mail which contains a callsign out of
'autobox_dir' as sender or receiver will be treated in this way. All mails
which will currently be received can be displayed with the 'lmonbox'
command.

----------------------------------------------------------------------------

3.12.6. Unproto list handling

Unproto list handling, a feature know from F6FBB-BBS's,is now available
together with DPBox 5.03.00 upwards. The BBS will send an unproto frame for
every newly arrived mail. This frame contains a message number which can be
used for a mail request by an user programm like TPK or TSTHOST.

If some unproto frames were lost, a listening station can request a resend
of older messages. To send these requests to DPBox, you have to activate the
feature using command ACCUIREQ und you have to define the BBS's callsign
with command ACCUICAL. This callsign must be equal to the source-callsign of
the unproto frames the BBS is sending.

All these configurations are needed to enable unproto list handling in a
real BBS. The other direction, TNT handling unproto lists as a client like
TPK or TSTHOST is not implemented up to now.

----------------------------------------------------------------------------

3.13. Automatic password generation

----------------------------------------------------------------------------

3.13.1. General description

In the packet radio network many different password systems are used at the
moment. Therefore a configuration file 'tnt_pwfile' is provided. In this
file for any callsign including SSID a password type and a file containing
the password can be defined. Depending on the password type a different
action is taken and the contents of the password file are different.

Up to now only few password systems are implemented in TNT, but it is
planned to increase the number of supported systems. If you have added any
password system, please contribute!

----------------------------------------------------------------------------

3.13.2. DIEBOX

If the password type is DIEBOX, after a connect to the specified callsign
was done, every text is scanned for the string 'Login: '. If the string was
found, the following date and time is recorded and the scan for the string
will be stopped.

If you invoke the command 'priv', a 4 character password will be generated
out of the logintime and your password file and as a result 'PRIV xxxx' will
be sent (xxxx stands for generated password).

The password may contain CR and LF, CR, LF or none of both. TNT will detect
this from the length of the file.

----------------------------------------------------------------------------

3.13.3. FlexNet

If the password type is FLEXNET and the connection to the wanted station is
established, the command 'priv' starts the password sequence. A string
containing 'SYS' is sent to the remote station which will respond with a
string like '(xyz) abcde>'. An answer is calculated out of this response
together with the specified password. This answer is sent to the remote
station and sysop-status will be available.

Unlike the other password systems the third value in the configuration file
is not the filename where the password is stored, but directly the password
number.

There is some other software which uses the same password algorithm as
FlexNet, but need a different activation string than SYS. In this case a
fourth (optional) value can be used to define this activation string.

----------------------------------------------------------------------------

3.13.4. TheNet

If the password type is TheNet and the connection to the wanted station is
established, the command 'priv' starts the password sequence. A string
defined by the fifth value in the configuration file is sent to the remote
station which will respond with a string like 'NODE:NO1DE: a b c d e' or
simply 'a b c d e'. This response defines which characters out of the
password file must be sent as an answer. This answer is generated and is
sent to the remote station and sysop status will be available.

The third value in the configuration file defines the file where the
password is stored.

The fourth value in the configuration file defines if some additional
features shall be used. If Bit 0 is set, the password generation is done 3
times, but only one ramdomly selected time the password generation is
correct. The other two 2 times a random string is sent instead of the right
answer. If Bit 1 is set, the answer is hidden in a 72 character string. If
Bit 2 ist set, perfect hiding is used. This means that only characters out
of the password string will be used to generate the line. Alternatively you
can add a second line to the password file. In this case only characters out
of this line will be used.

The TheNet-type password generation is used by other software, too (for
example Baycom, DigiPoint).

----------------------------------------------------------------------------

3.13.5. Baycom

The Baycom password system is almost identical to TheNet, except that no
activation string is needed and right after connect you will receive the 5
random numbers.

The syntax is the same as for TheNet, except the fifth parameter (the
activation string) can be omitted. The default will be SYS. Because the
string is needed only if you defined a special configuration for the user
profile in BayBox, it is normally not of any importance.

There is another small difference to the TheNet syntax, the option '3 tries,
where only one answer is correct', is not allowed.
----------------------------------------------------------------------------

3.13.6. MD2

After connect a similar like the following string will be received:

XXXBBS> [ABCDEFGHIL]

Out of this string an answer is generated, the password algorithm used is
'RSA Data Security, Inc. MD2 Message Digest Algorithm'.

----------------------------------------------------------------------------

3.14. Huffman compression

The huffman data compression implemented in some other programs is
available, too. It can be activated by the remote command //COMP or via
command COMP. The compression will lead to a data reduction of about 30% for
plain ASCII text. For binary files the compression is not useful.

To read a QSO in extended monitor which uses huffman compression the command
EXTComp is provided.

The MONBOX feature detects huffman compression and will in most cases catch
mails even if they are read in //COMP mode.

Compression is available only if tnt_comp in the configuration file is set.
In this case the maximum allowed packet length (file_paclen in configuration
file, command FPACLEN) for file sending is 255 Bytes.

The //comp - method was first used by DK4NB in SP 9.00, the translation
table is his setup.

----------------------------------------------------------------------------

3.15. Handling Flexnet connection quality checks

The Flexnet digipeater protocol uses connects to determine the connection
quality and availability. These connects leads to unnecessary activation of
connect-texts, DPBox or other programs connected at the interface. In
addition the logbook will be flooded with these connections.

So TNT provides a file where the callsigns of Flexnet-digipeaters performing
these connection quality checks can be stored (tnt_flchkfile). If a callsign
found in this file is connecting, it will get no connect-text, no remote-
access and no connection via interface will be started. The logbook will not
contain this connection.

The contents of this file can be displayed by command LSTFLCHK. When the
file was updated, it can be reread using command LDFLCHK.

----------------------------------------------------------------------------

3.16. Operating different software with same callsign

If you want to operate different software with the same callsign, you want
to define what SSID's of your call TNT must not use. This can be done in the
file defined by 'tnt_notownfile'. Calls contained in this file will not be
used for connecting using routing scripts.

The contents of this file can be displayed by command LSNOTOWN. When the
file was updated, it can be reread using command LDNOTOWN.

----------------------------------------------------------------------------

3.17. PACSAT broadcast operation

TNT includes a PACSAT broadcast compatible receiver and transmitter. The
code is mainly based on the pascal source code written by Joachim, DL8HBS.

The receiver is enabled by setting DECBCAST to ON. All files received in
frames in PACSAT broadcast protocol will be decoded. Depending on the type
of the file, a complete file will be stored in 'tnt_bcsavedir' (normal
files) or will be sent to DPBox (BBS-files).

If parts of the received file are missing and the broadcast-transmitter
allows it by a not permanent transmission, the missing parts can be
requested. This is enabled by setting BCRQST to ON.

The status of the broadcast receiver can be displayed by BCRXSTAT. All files
successfully received or currently in receiption will be displayed. Some
statistical information shows the progress.

The broadcast transmitter is controlled either by DPBox to do a broadcast of
BBS-files. More information can be found in the DPBox-documentation. In
addition a broadcast transmission of normal files (command SENDBC) is
possible, too.

The status of the broadcast transmitter can be displayed by BCTXSTAT. All
files currently transmitted are listed including some statistical
information.

As the TheFirmware and WA8DED-software does not allow to change the PID used
for transmitted frames, the broadcast transmission will be sent using PID
F0. This can lead to problems using other software (WISP) as a receiver.
TFKISS and a special version of TheFirmware (ask me or DL8HBS for it) allows
the change of the PID and therefore the correct broadcast transmission
according to the protocol.

----------------------------------------------------------------------------

3.18. Autostart on connect

There are many possibilities in TNT (RUN, SOCKET) to allow a remote user to
use other software on the system. But to start these applications you first
have to give a special command when connected to TNT.

To make these application easily accessible and to hide that TNT is doing
the work, you can define for specific callsign/SSID combinations an
autostart command. This command, which contains any valid remote command
plus parameters, will be executed, when the callsign/SSID combination will
be connected.

The autostart-feature must be enabled using command AUTOSTRT, by default
autostart is disabled.

To be able to connect the callsign/SSID combination, you have to define one
or more channels of your TNC to use this callsign (use MYCALL in tnt.up).

The callsign/SSID combinations and the autostart commands are defined in
'tnt_autostartfile'. The actual data can be displayed using LSAUTOST, if the
file was changed, it can be reread using LDAUTOST.

----------------------------------------------------------------------------

3.19. TNT as daemon, TNTC

Normally, TNT will use a console for the user interface. But there are some
cases where this is not wanted or needed:

- TNT user interface needed on different host
- changing between X and terminalmode without terminating TNT
- no user interface needed

Therefore TNT can be started as a daemon using the command line parameter
'-d' on startup. TNT then accepts socket connect requests on the socket
address specified after 'frontend_socket' in tnt.ini. This socket address
can have different formats (equal to the definition for socket servers):

  a. UNIX-sockets
     The format for a UNIX-socket is 'unix:<socket path>' or 'local:<socket
     path>'. The path can be an absolute path beginning with a '/' or a
     relative path to 'tnt_dir'.
     Example:

     unix:tntsock
     unix:/tcp/sockets/convers

  b. INET-sockets
     The format for a INET-socket is 'ip-address:port'. ip-address can be a
     hostname, an ip-address or a '*' for any ip-address. Port can be any
     valid port number or a name for a service.
     Example:

     *:3600
     199.199.10.10:ftp
     foo.bar.com:2000

To connect TNT, a remote console program is available: TNTC. It uses its own
configuration file tntc.ini, where the home directory and the socket to
connect is stored. At start TNTC sends the terminal type (environment entry
TERM) and the lines and columns of the display to TNT. Except for the number
of columns which are fixed to the value specified after 'input_linelen' in
tnt.ini, these values are taken to provide correct screen positioning and
attributing.

TNTC can be finished without terminating TNT by giving command QUIT. With
EXIT both TNT and TNTC will be terminated.

----------------------------------------------------------------------------

4. Description of configuration files

----------------------------------------------------------------------------

4.1. Main configuration file

The configuration of the program is done by the main configuration file.
This file called 'tnt.ini' is searched at the current directory or at the
home directory of the user (other filenames can be specified by using the -i
option at startup).

sample tnt.ini:

# defines if select() shall be used, normally 1, put to 0, if you are
# using old kernels (select() produces there a higher CPU-load).
use_select 1

# --------------------------------------------------------------------------

# 0 for real TNC at serial port, 1 for TFKISS on a UNIX-socket,
# 2 for TFKISS on other socket
soft_tnc 0

# serial port to which TNC is connected, UNIX-socket of TFKISS or
# other socket for TFKISS
device /dev/cua0

# lockfile for serial port or TFKISS
tnt_lockfile /usr/spool/uucp/LCK..cua0

# baudrate used, only used if TNC at serial port
speed 19200

# timinig parameters for interface to tfkiss (soft_tnc is 1)
# 1: fixed wait (10ms) after each hostmode-packet sent to tfkiss
fixed_wait 1
# if fixed_wait == 0, number of sent characters to tfkiss after which
# tnt will wait 10ms
amount_wait 20

# --------------------------------------------------------------------------

# number of channels of TNC
tnc_channels 10

# first channel with reduced backscroll buffer
r_channels 4

# --------------------------------------------------------------------------

# enable static huffman compression (//COMP)
tnt_comp 1

# packet length for transmission of files
file_paclen 255

# set to 1 to disconnect all channels on startup
disc_on_start 0

# --------------------------------------------------------------------------

# UNIX-user for remote permissions
remote_user guest

# If set to 1, new users will be created, if set to 0, all new users will
# be logged in as user defined by 'remote_user'.
unix_new_user 1

# lowest user-id for creation of new users
unix_first_uid 410

# group-id for new users
unix_user_gid 101

# --------------------------------------------------------------------------

# timeout packet assembly (in seconds) for SHELL/REDIR and interface
pty_timeout 2

# --------------------------------------------------------------------------

# set to 1 for request of R:-headers in boxlist read command
blist_add_plus 0

# --------------------------------------------------------------------------

# SSID of DPBox (A channel with this SSID must exist in TNC!)
tnt_box_ssid 7

# Call and SSID of DPBox (A channel with this Call and SSID
# must exist in TNC!)
# (If this parameter is used, 'tnt_box_ssid' will be ignored)
#tnt_box_call

# SSID of a node connect (not yet ready)
tnt_node_ssid 9

# Call and SSID of a node connect (not yet ready)
#tnt_node_call

# --------------------------------------------------------------------------

# main directory
tnt_dir /work/tnt/
# remote directory
remote_dir remote/
# ctext directory
ctext_dir ctext/
# directory for corrupt autobin-files
abin_dir abin/
# directory for uploads
upload_dir up/
# directory for downloads
download_dir down/
# directory for 7plus
tnt_7plus_dir 7plus/
# directory for YAPP
yapp_dir yapp/
# directory for executable programs
tnt_bin_dir bin/
# home-dir for new users
unix_user_dir tntusers/
# dir for macro-texts
macrotext_dir macro/
# dir for box-broadcastfiles
tnt_bcnewmaildir bcast/newmail/
# dir for broadcastfiles
tnt_bcsavedir bcast/save/
# dir for temporary broadcastfiles
tnt_bctempdir /tmp/

# upfile
tnt_upfile tnt.up
# downfile
tnt_downfile tnt.dwn
# file containing process id
proc_file tnt.pid
# remote infofile
rem_info_file tntrem.inf
# remote helpfile
rem_help_file tntrem.hlp
# tnthelpfile
tnt_help_file tnt.hlp
# cookiefile
tnt_cookiefile /usr/games/fortunes/startrek
# namesfile
name_file_name names.tnt
# routesfile
route_file_name routes.tnt
# newsfile
news_file_name news.tnt
# connect text
tnt_ctextfile ctext.tnt
# logbook file
tnt_logbookfile log.tnt
# password file
tnt_pwfile pw.tnt
# sysop access files
tnt_sysfile sys.tnt
# calls with remote disabled
tnt_noremfile norem.tnt
# calls which do flexnet-linkquality-check
tnt_flchkfile flchk.tnt
# own call/SSID not allowed for xconnect
tnt_notownfile notown.tnt
# resync logfile
resy_log_file resy.log
# broadcast logfile
bcast_log_file bcast.log
# socket passwordfile
sock_passfile netpass.tnt
# file for keyboard macros
func_key_file fkeys.tnt
# file for extended remote commands
tnt_extremotefile extrem.tnt
# file for autostart on connect
tnt_autostartfile autostrt.tnt

# socket for digipoint box
box_socket /work/box/stat/socket
# directory for newmail
newmaildir newmail/
# file holding monitored folders
autobox_dir autobox.dir
# file for boxfile endings
tnt_boxender boxender.tnt
# file for f6fbb-definitions
f6fbb_box /work/box/system/f6fbb.box

# socket for tntnode (not yet ready)
node_socket /work/tntnode/socket

# socket for frontend
frontend_socket unix:tntsock

# --------------------------------------------------------------------------

# maximum length of input line
input_linelen 80

# set to 1 if insertmode shall be active after startup
insertmode 0

# maximum number of entries in heardlist
num_heardentries 100

# number of lines for backscroll

# command-screen
lines_command 50
# monitor-screen
lines_monitor 400

# input area of connect-screens
lines_input 20
# output area of connect-screens
lines_output 100
# input area of connect-screens (reduced backscroll)
lines_r_input 5
# output area of connect-screens (reduced backscroll)
lines_r_output 20
# input/output-lines ratio on real screen (connect)
scr_divide 5
# monitor lines on connect-screens
lines_moncon 0

# input area of mailbox-screen
lines_mbinput 10
# output area of mailbox-screen
lines_mboutput 200
# input/output-lines ratio on real screen (mailbox)
mbscr_divide 8

# input area of extended monitor screens
lines_xmon_pre 10
# output area of extended monitor screens
lines_xmon 100
# input/output-lines ratio on real screen (extended monitor)
xmon_scr_divide 5

# --------------------------------------------------------------------------

# 0: monochrom, 1: use color attributes if TERM = 'linux' or 'conXXX',
# otherwise use monochrom attributes and termcap, 2: use color attributes,
# 3: use color attributes and termcap if TERM = 'xterm'
color 1

# 0: don't use termcap, 1: use termcap
termcap 0

# 1: alternative channel status line
altstat 0

# --------------------------------------------------------------------------

# attributes for color

# normal characters
attc_normal 0x07
# characters in bottom statusline
attc_statline 0x10
# characters in monitor-headers
attc_monitor 0x06
# characters in channel statusline
attc_cstatline 0x1F
# control-characters
attc_controlchar 0x0F
# remote-answers
attc_remote 0x06
# special features
attc_special 0x01

# --------------------------------------------------------------------------

# attributes for monochrom

# normal characters
attm_normal 0x00
# characters in bottom statusline
attm_statline 0x08
# characters in monitor-headers
attm_monitor 0x10
# characters in channel statusline
attm_cstatline 0x10
# control-characters
attm_controlchar 0x10
# remote-answers and own transmitted text
attm_remote 0x10
# special features
attm_special 0x10

# --------------------------------------------------------------------------

# these values must remain unchanged using LINUX

# 1: terminal puts cursor to a new line after character in last column
auto_newline 0

# 1: don't display characters 128-160
supp_hicntl 0

# --------------------------------------------------------------------------
<EOF>

----------------------------------------------------------------------------

4.1.1. Serial and general configuration

'use_select'
     Defines if select() shall be used, normally 1, put to 0, if you are
     using old kernels (select() produces there a higher CPU-load)

'soft_tnc'
     Defines if a real TNC (0) is connected or TFKISS (1,2).

'device'
     Device, to which the TNC is connected, must be specified. If TFKISS is
     used and soft_tnc is 1, device must contain the path and filename of
     the UNIX-socket. If soft_tnc is 2, device must contain a general socket
     description like explained in the Detailled description of the socket
     servers.

'speed'
     Baudrate of the serial port, only used if configured for a real TNC

'tnt_lockfile'
     Filename to lock the port. Shall follow the usual conventions: for
     device /dev/cua0 specify the lockfile /usr/spool/uucp/LCK..cua0. For
     TFKISS use a pseudo-lockfile like /usr/spool/uucp/tfkiss or similar.

'fixed_wait'
     Only valid if TFKISS is used: Normally set to 1, which means a fixed
     wait of 10ms after each hostmode-packet sent to TFKISS. If 0,
     'amount_wait' defines the waiting.

'amount_wait'
     Only valid if TFKISS is used and 'fixed_wait' set to 0: Number of
     characters sent to TFKISS after which TNT will wait 10ms (can be used
     to optimize the timing).

'tnc_channels'
     Number of channels of TNC.

'r_channels'
     First channel with reduced backscroll buffer.

'tnt_comp'
     If not 0, static huffman compression is activated. In this case the
     maximum file packet length ('file_paclen') is 255 characters.

'file_paclen'
     Defines the maximum length of a packet. Valid values are 20 up to 256
     characters. If huffman compression is activated ('tnt_comp'), the
     maxmimum value is 255 characters. The value can be changed by command
     FPACLEN.

'disc_on_start'
     If 1, all established connection are disconnected on startup of TNT, if
     0, connections remain active.

'blist_add_plus'
     If not set to 0, a '+' is appended to the boxlist read command. As a
     result the mail will contain full R: lines.

'tnt_box_ssid'
     If the SSID of the own call on the current channel is equal to this
     SSID, DPBox is started on connect.

'tnt_box_call'
     If the own call (plus SSID) on the current channel is equal to this
     call (plus SSID), DPBox is started on connect. This parameter will
     override 'tnt_box_ssid'. It can be used, if different callsigns with
     the same SSID shall be used and DPBox shall be activated only for one
     of the calls.

'tnt_node_ssid'
     If the SSID of the own call on the current channel is equal to this
     ssid, TNTNODE is started on connect. (function currently under
     development).

'tnt_node_call'
     If the own call on the current channel is equal to this call, TNTNODE
     is started on connect. This parameter will override 'tnt_node_ssid'. It
     can be used, if different callsigns with the same SSID shall be used
     and TNTNODE shall be activated only for one of the calls. (function
     currently under development).

----------------------------------------------------------------------------

4.1.2. Security

'remote_user'
     User-Id for remote access.

If TNT was started by root, prior to every remote file command the user-id
is changed to restrict the file permissions of the remote user. If TNT was
started by a normal user, the user-id is not changed. Therefore a remote
user has the same file permissions as the user himself.

'unix_new_user'
     1: A new user gets an entry in /etc/passwd and a directory is created.
     0: A new user is logging in as specified in 'remote_user'.

'unix_first_uid'
     First user-ID which will be taken for new users.

'unix_user_gid'
     Group-ID used for new users.

----------------------------------------------------------------------------

4.1.3. Directories, Files and Sockets

The directory 'tnt_dir' must always contain the complete path. For all other
files and directories it depends on the first character of the path. If the
first character is a '/', then the path is taken as the complete path. If
the first character is not '/', 'tnt_dir' is put in front of the path.

4.1.3.1. Directories

'tnt_dir'
     Directory which contains tnt-files

'remote_dir'
     Directory used for remote access

'ctext_dir'
     Directory used for personal connect texts

'abin_dir'
     Directory for files of unsuccessful AutoBIN-transfers

'upload_dir'
     Directory for sending files (SEND/SENDLOG/...) if no directory was
     specified.

'download_dir'
     Directory for receiving files (READ/LOGQSO/...) if no directory was
     specified.

'yapp_dir'
     Directory for receiving files using AUTOYAPP.

'tnt_7plus_dir'
     Directory for receiving files using AUTO7PL.

'tnt_bin_dir'
     Directory for executable programs (//RUN).

'unix_user_dir'
     Root-directory for directories of new users.

'macrotext_dir'
     Directory for files containing text-macros (MSEND)

'tnt_bcnewmaildir'
     Directory where received broadcast-files of type BBS will be stored.

'tnt_bcsavedir'
     Directory where other received broadcast-files will be stored.

'tnt_bctempdir'
     Directory for temporary files generated by broadcast receiver.

'newmaildir'
     Directory where mails read by AUTOBOX and MONBOX are stored for DPBox

4.1.3.2. Files

'tnt_upfile'
     Command script executed at startup of program

'tnt_downfile'
     Command script executed before exit of program

'proc_file'
     File which will contain the process ID of the running TNT process

'rem_info_file'
     File transmitted if remote command //info is received

'rem_help_file'
     File transmitted if remote command //help is received

'tnt_help_file'
     File which is displayed if help screen is selected

'tnt_cookiefile'
     File which contains database for fortune cookies

'name_file_name'
     File for names database

'route_file_name'
     File for routing database

'news_file_name'
     File for news message, transmitted if //news is received or if %i macro
     is found in a connect text file

'tnt_ctextfile'
     File containing common connect text

'tnt_logbookfile'
     File for logbook

'tnt_pwfile'
     File for generation of passwords

'tnt_sysfile'
     File for access restriction and sysop authentification

'tnt_noremfile'
     File containing calls for which remote-commands are disabled

'tnt_flchkfile'
     File containing calls which do flexnet-linkquality-check

'tnt_notownfile'
     File containing call plus SSID which are not allowed for xconnect

'resy_log_file'
     Logfile if a resync occured

'bcast_log_file'
     Logfile for errors/warnings from broadcast receiver/transmitter

'sock_passfile'
     Socket login database

'func_key_file'
     Definition of keyboard macros

'tnt_extremotefile'
     File defining extended remote commands

'tnt_autostartfile'
     File defining autostart commands executed on connect

4.1.3.3. Sockets and Boxfiles

'box_socket'
     Path and name of the UNIX-socket used for connection to DPBox.

'autobox_dir'
     File containing boards which shall be monitored using MONBOX-feature.

'tnt_boxender'
     File containing strings indicating end or abort of message (MONBOX and
     AUTOBOX).

'f6fbb_box'
     File containing strings which are used by the F6FBB-Box you are using.
     This file is used by DPBox, too and shall be placed in the
     DPBox-system-directory. A correct definition is needed for the
     AUTOBOX-feature.

'node_socket'
     Path and name of the UNIX-socket used for connection to TNTNODE
     (currently under development).

'frontend_socket'
     Name of the socket used by frontend TNTC if TNT is started as a daemon.
     The syntax is identical to the socket definition in the detailled
     description of the socket servers.

----------------------------------------------------------------------------

4.1.4. Lines of virtual screens

'input_linelen'
     Maximum length of input line at which additional characters are ignored
     or wordwrap is executed. The value can be changed with command LINelen.

'insertmode'
     Set to 1 if insertmode shall be active on all screens after startup.

'num_heardentries'
     Number of entries in heardlist.

'lines_command'
     Number of lines of the command screen.

'lines_monitor'
     Number of lines of the monitor screen.

'lines_input'
     Number of lines of the input part of the connect screen.

'lines_output'
     Number of lines of the output part of the connect screen.

'lines_r_input'
     Number of lines of the input part of the connect screen (reduced
     backscroll buffer).

'lines_r_output'
     Number of lines of the output part of the connect screen (reduced
     backscroll buffer).

'scr_divide'
     Input/output-lines ratio on real screen (connect). The value can be
     changed with command CONDiv. Example: Real screen has 25 Lines,
     scr_divide is 5. 25 Lines - 2 Statuslines = 23 lines for input/output.
     23 / 5 = 4.6 -> 4 lines on input. 23 - 4 = 19 lines for output.

'lines_moncon'
     Number of lines of monitor screen additionally displayed on the connect
     screen. Set to 0, if no monitor lines shall be displayed. The value can
     be changed with command MONLines (The lines of the real screen will be
     reduced by the number of monitor lines, before the lines of input and
     output part will be calculated using scr_divide)

'lines_mbinput'
     Number of lines of the input part of the mailbox screen.

'lines_mboutput'
     Number of lines of the output part of the mailbox screen.

'mbscr_divide'
     Input/output-lines ratio on real screen (mailbox). The value can be
     changed with command MBOXDiv.

'lines_xmon'
     Number of lines of the output part of the extended monitor screen.

'lines_xmon_pre'
     Number of lines of the input part of the extended monitor screen.

'xmon_scr_divide'
     Input/output-lines ratio on real screen (extended monitor screen). The
     value can be changed with command XMONDiv.

----------------------------------------------------------------------------

4.1.5. Display configuration

'color'
     non color attributes (0), color attributes if LINUX- console (1) or
     color attributes always (2)
'termcap'
     use LINUX-console control codes (0) or /etc/termcap (1)

'altstat'
     Set to 1 if you want to use the alternative statusline on
     connect-screens.

if color == 1 and LINUX-console control codes are selected, but the TERM
entry in the environment is not "con..." or "linux", no color and termcap is
used.

----------------------------------------------------------------------------

4.1.6. Screen attributes

Depending on the selected mode (color) the color or monochrom attributes are
used. Important notice: The attributes for normal text and for
controlcharcters in the input field MUST be different, otherwise no
control-characters can be sent.

4.1.6.1. Color attributes

'attc_normal'
     For normal text.

'attc_statline'
     For main statusline at the bottom of the screen.

'attc_monitor'
     For monitor headers.

'attc_cstatline'
     For statusline of channel in connect screen.

'attc_controlchar'
     For controlcharacters in the input field.

'attc_remote'
     For text transmitted because of remote functions.

'attc_special'
     For special features.

The attributes are coded in the following manner:

    X    X    X    X    X    X    X    X
  Blink BCo2 BCo1 BCo0 FCo3 FCo2 FCo1 FCo0
          Background-      Foreground-
            Colour           Colour

Blink:
0:off, 1:on

Background Color:
        BCo2 BCo1 BCo0
Black     0    0    0
Red       0    0    1
Green     0    1    0
orange    0    1    1
blue      1    0    0
magenta   1    0    1
cyan      1    1    0
white     1    1    1

Foreground Color:
              FCo3 FCo2 FCo1 FCo0
Black           0    0    0    0
Red             0    0    0    1
Green           0    0    1    0
Orange          0    0    1    1
Blue            0    1    0    0
Magenta         0    1    0    1
Cyan            0    1    1    0
White           0    1    1    1
Grey            1    0    0    0
Light red       1    0    0    1
Light green     1    0    1    0
yellow          1    0    1    1
Light blue      1    1    0    0
Light magenta   1    1    0    1
Light cyan      1    1    1    0
Light white     1    1    1    1

4.1.6.2. Monochrom attributes

'attm_normal'
     For normal text.

'attm_statline'
     For main statusline at the bottom of the screen.

'attm_monitor'
     For monitor headers.

'attm_cstatline'
     For statusline of channel in connect screen.

'attm_controlchar'
     For controlcharacters in the input field.

'attm_remote'
     For text transmitted because of remote functions.

'attm_special'
     For special features.

The attributes are coded in the following manner:

    X    X    X    X    X    X    X    X
             Att5 Att4 Att3 Att2 Att1 Att0

Att0: Standout    (termcap so/se)
Att1: Underline   (termcap us/ue)
Att2: Blink       (termcap mb/me)
Att3: Reverse     (termcap mr/me)
Att4: Bold        (termcap md/me)
Att5: Halfbright  (termcap mh/me)

0: off, 1: on

----------------------------------------------------------------------------

4.1.7. Packet assembly timeout

'pty_timeout'
     Time for packet assembly

All characters received by a shell or redirection are buffered. If the
buffer reaches the maximum packetsize (256 bytes) the buffer is transmitted.
After each new character pty_timeout seconds are waited for the next
character. If during this time no character is given, the buffer will be
sent even if the maximum packetsize is not reached.

----------------------------------------------------------------------------

4.1.8. Additional options

The following switches are available to customize TNT to a different
terminal or operating system. For use with linux, both must be set to 0.

'auto_newline'
     Set to 1 if terminal performs a newline after last character in a line

'supp_hicntl'
     Set to 1 if characters in range 128-160 shall be substituted by a
     period (.)

----------------------------------------------------------------------------

4.2. TNC-configuration files

At the startup of the program a command script is executed. It can be used
to initialize some parameters in the TNC. The filename must be specified
after 'tnt_upfile' in the init file.

To set up different callsigns on specific channels the following command
sequence can be used:

...
CHANNEL 4
MYCALL DL4YBG-4
CHANNEL 5
MYCALL DL4YBG-5
CHANNEL 6
MYCALL DL4YBG-6
...

After the EXIT command is given another command script is executed before
the termination of the program. The filename must be specified after
'tnt_downfile' in the init file.

----------------------------------------------------------------------------

4.3. Cookie file

If fortune cookie sending is active (command COOKIE) and someone is
connecting to the station a randomly selected cookie out of the cookie file
will be sent.

The cookie file consists of cookie texts delimited by a line containg a '-'
or a '%' as the first character (the rest of the line will be ignored). The
minimal size of a cookie file is 2048 bytes.

The data files contained in the 'fortunes' package in most
Linux-distributions can be used.

The filename of the cookie file must be given after 'tnt_cookiefile' in the
init file.

----------------------------------------------------------------------------

4.4. Files for remote commands

If the remote command //help is received a file specified after
'rem_help_file' in the init file is transmitted. The file shall contain an
overview and an explanation of the possible remote commands.

If the remote command //info is received a file specified after
'rem_info_file' in the init file is transmitted. The file shall contain a
description of the station and the used equipment.

If the remote command //news is received a file specified after
'news_file_name' in the init file is transmitted. The file shall contain any
news about the station.

----------------------------------------------------------------------------

4.5. Files for connect text

If connect text sending is active (command CONTEXT) and someone is
connecting to the station a special connect text will be sent. The connect
text is fetched from the file specified after 'tnt_ctextfile'. Any macros
contained in the file will be expanded. It is possible to send several users
a personal connect text. To achieve this a file called <callsign>.ctx must
be put to the directory specified after 'ctext_dir', where <callsign> is the
call of the user.

----------------------------------------------------------------------------

4.6. Files for names database and routing scripts

----------------------------------------------------------------------------

4.6.1. Names database

For use with the connect text feature a names database is included. The
database itself is contained in the file specified after 'name_file_name'.

All entries in the names database use the following format: T>DL4YBG Mark

If the command NAME or the remote command //NAME is used to update a name,
the names database file will be updated.

----------------------------------------------------------------------------

4.6.2. Routing database

For routing scripts the routing database is contained in a file with a
similar layout like the names database. The filename of the routing database
is specified after 'route_file_name'.

Unlike the names database file, the routing database is not updated by tnt,
any updates must be done with an text editor.

The entries for routing scripts can be recursive, it is not needed to
specify the whole path for each callsign. The path is assembled using the
relevant entries in the database.

If you frequently change the frequency and the uplink digipeater, you may
want to specify for every frequency a different routing database. Therefore
<IF xxxxxx> and <END> is included. If for example you operate on 438.300
Mhz, you can specify all routing information valid only on this frequency
by:

<IF 438.300>
...
<END>

All routing information which is not surrounded by <IF xxxxxx> and <END> is
valid on all frequencies. The frequency you are operating on can be
specified using the command QRG.

The format of each database entry is as follows:

In front of the callsign a letter specifies the type of the station:

T : Normal user
N : Network node

All other characters are accepted. The only difference is the treatment of
the call in routing scripts.

The database is a text file containing lines like the following:

T>DL4YBG Mark
     -> The name of the operator of station DL4YBG is Mark, no routing
     information given or station can be reached directly.

T>DL7ZZZ Joe; N>DB0LUC T>DL7ZZZ
     -> The name of the operator of station DL7ZZZ is Joe, the station can
     be connected from digipeater DB0LUC.

N>DB0BLO Digi 9K6
     -> The digipeater DB0BLO can be connected directly.

N>DB0BER Digi Tempelhof; N>DB0BLO N>DB0BER
     -> The digipeater DB0BER can be connected from digipeater DB0BLO.

N>DB0LUC Digi Luckau; N>DB0BER F>DB0BLN N>DB0LUC
     -> The digipeater DB0LUC can be connected from digipeater DB0BER via
     DB0BLN.

----------------------------------------------------------------------------

4.7. User-Id's and security

For every user it is possible to log into the UNIX-system by using //SHELL
or if the operator uses the SHELL command for the channel. The callsign of
the connected station is used as the user-id. If there is no user-id
existing with this call sign and 'unix_new_user' is not set, the user-id
"guest" is used. Because at the moment there is no security for the
password, no passwords are used. If you don't use 'unix_new_user' you must
prepare the user-id's of the authorized users yourself. Therefore the
entries in /etc/passwd shall look like:

guest::407:109::/home/guest:
dl4ybg::405:101::/home/dl4ybg:

These user-id's must not appear in /etc/shadow (only if shadow passwords are
used).

Hint:
     The user guest can be created using 'useradd -m guest', then
     /etc/passwd must be adapted and the password-entry in /etc/shadow (only
     if shadow passwords are used) must be erased. Try a login from a
     virtual terminal prior to logging in via remote command.

IMPORTANT:
Check the file permissions on your system and use a password for root, now
you are not alone any longer!

----------------------------------------------------------------------------

4.8. Logfile for resynchronisation

If during operation a resynchronisation is frequently started, it might be
useful to track down the reason for it. This can be achieved by specifying
'resy_log_file' in the init-file. The full path to the file must be given.
If left blank no resync log file is written. Have a look at the size of the
resync file, it is advisable to remove it from time to time to regain disc
space.

----------------------------------------------------------------------------

4.9. File for keyboard macros

sample fkeys.tnt:

#
# Function-Key-File
#
# XX:text
# XX::command
#
# '*' at end sends CR after a text
#
01::send .signature
02:***end*
03::c db0abc
04::c db0zzz-8
08::logblist
09::blist
10::xblist
<EOF>

----------------------------------------------------------------------------

4.10. File for password generation

sample pw.tnt:

# sample password file
# all lines must use the following format:
# DIEBOX:
# <callsign> <password-type> <password-file>
# FLEXNET:
# <callsign> <password-type> <secret-number> [priv-string]
# THENET:
# <callsign> <password-type> <password-file> <flags> <priv-string>
# BAYCOM:
# <callsign> <password-type> <password-file> <flags> [priv-string]
# MD2:
# <callsign> <password-type> <password-file>
#
# DieBox DB0XXX
DB0XXX-3 DIEBOX /work/tnt/db0xxx_3.pw
# FlexNet DB0YYY
DB0YYY FLEXNET 02345
# FlexNet DB0YYZ-8 with different activation string
DB0YYZ-8 FLEXNET 02345 /SYSop
# TheNet DB0ZZZ
DB0ZZZ THENET /work/tnt/db0zzz.pw 0 SYS
# TheNet DB0ZZA-2 with 3 tries
DB0ZZA-2 THENET /work/tnt/db0zza_2.pw 1 SYS
# TheNet DB0ZZB with password hiding
DB0ZZB THENET /work/tnt/db0zzb.pw 2 SYS
# TheNet DB0ZZC-15 with password hiding and 3 tries
DB0ZZC-15 THENET /work/tnt/db0zzc_15.pw 3 SYS
# TheNet DB0ZZB-1 with perfect password hiding
DB0ZZB-1 THENET /work/tnt/db0zzb_1.pw 6 SYS
# TheNet DB0ZZC-14 with perfect password hiding and 3 tries
DB0ZZC-14 THENET /work/tnt/db0zzc_14.pw 7 SYS
# Baycom DB0ZZE-5
DB0ZZE-5 BAYCOM /work/tnt/db0zze_5.pw 0
# Baycom DB0ZZD with password hiding and different activation string
DB0ZZD BAYCOM /work/tnt/db0zzd.pw 2 SYS
# Baycom DB0ZZD-1 with perfect password hiding and different activation string
DB0ZZD-1 BAYCOM /work/tnt/db0zzd_1.pw 6 SYS
# MD2 password for DB0ZZF
DB0ZZF MD2 /work/tnt/db0zzf.pw
<EOF>

----------------------------------------------------------------------------

4.11. File for sysop authentification

sample sys.tnt:

# sample access restriction and sysop authentification file
# format:
# <callsign> <password-file> <sysop-level>
#
# DL7ZZZ with root access
DL7ZZZ /work/tnt/dl7zzz.pw 1
# DL7ZZY with no root access
DL7ZZY /work/tnt/dl7zzy.pw 0
<EOF>

----------------------------------------------------------------------------

4.12. File for remote commands disabling

sample norem.tnt:

# sample file for remote commands disabling
# format:
# <callsign with SSID>
#
DB0GR
DB0BLO-8
DB0JES-3
DB0TEM-8
<EOF>

----------------------------------------------------------------------------

4.13. File containing not own callsigns

sample notown.tnt:

# sample file for call/SSID-combinations which are not allowed as
# source callsign for xconnects
# format:
# <callsign with SSID>
#
DL4YBG
DL4YBG-7
<EOF>

----------------------------------------------------------------------------

4.14. File containing Flexnet digipeaters

sample flchk.tnt:

# sample file for ignoring Flexnet connection quality checks
# format:
# <callsign with SSID>
#
DB0BNO
DB0BLN
<EOF>

----------------------------------------------------------------------------

4.15. File for AX25-server access

sample netpass.tnt:

# netpass.tnt - file
# Syntax is:
# CALL PASSWORD AUTOCONNECT-CALL LEVEL
#
# Examples
#
# Next line sets user/pass=dl7zzz/geheim, no default connect, level=9
dl7zzz geheim none 9
#
# Next line sets user/pass=dl7zzy/secret, autoconnects
# to DB0ZZZ-8 always, and he has command-access-level=3
# This autoconnect-callsign means that dl7zzy CAN'T connect
# any other station than DB0ZZZ-8 ! - Excluding if he has level=9 !
dl7zzy secret DB0ZZZ-8 3
<EOF>

----------------------------------------------------------------------------

4.16. File for autostart on connect

sample autostrt.tnt:

# sample autostart file
# format:
# <callsign+SSID> <tnt command>
#
# connect dl4ybg-5 -> start convers user-client
dl4ybg-5 convers
# connect dl4ybg-12 -> get a channel status
dl4ybg-12 cs
# connect dl4ybg-13 -> get a unix shell
dl4ybg-13 shell
# connect dl4ybg-14 -> connect to convers-server
dl4ybg-14 socket unix:/tcp/sockets/convers
<EOF>

----------------------------------------------------------------------------

4.17. File for extended remote commands

sample extrem.tnt:

# sample file for extended remote commands
# format:
# <remote command> <access level> <significant chars> <tnt command>
#
# //SCONvers : connect convers (Unix-)socket
sconvers 0 4 socket unix:/tcp/sockets/convers
# //AXSERv : connect local ax25 server on port 2001 (only for sysop)
axserv 1 5 socket localhost:2001
<EOF>

----------------------------------------------------------------------------

4.18. Files for BBS features

sample boxender.tnt:

#
# additional strings to detect the end of a mailbox-message
#
# format: 'xy string'
# x: 1 = message complete, 2 = message aborted
# y: value from 1 to 4 (up to 4 strings)
#
# one prompt of baycom-box
11 Help Dir Read Erase Check REPly Send Alter Quit
# prompt of diebox, if message read cancelled
21 (H)elp (C)heck (L)ist (R)ead (S)end (E)rase (D)ir (U)sage (Q)uit
# flexnet-reconnect
22 *** reconnected to
<EOF>

sample f6fbb.box:

#
# Definition of F6FBB-Fileheaders for the MonitorCut-Feature of DP
# YOU WILL HAVE TO ALTER THESE SETTINGS!
# BUT: NEVER CHANGE THE ORDER OF THE DEFINITIONS!
# Unfortunately, the f6fbb-soft has two basic types of fileheaders
# The first one consists of 5 lines, the second (and newer one) of 7.
# Additionally those headers exist in many different lingual versions.
# Therefore you are obliged to setup this file for your personal use...
#
# If the Header Format of your local F6FBB doesn't match to these,
# please write me a msg.
#
# THE '#' STARTS A COMMENT LINE... THE FIRST FOUR UNCOMMENTED LINES
# ARE KEPT AS THE KEYWORDS, THE FOLLOWING 12 UNCOMMENTED LINES ARE
# THE MONTH IDENTIFIERS AS USED IN YOUR LOCAL F6FBB-BOX
#
#
# An old-style (and dutch language) fbb-header may look like this:
#
# Van : DC6OQ  voor IBM   @DL
# Type/Status : B$
# Datum/tijd  : 21-Mrt 13:55
# Bericht #   : 72618
# Titel       : hilfe aastor
#
# Now the definitions:
#
# first word in header (all signs until the senders callsign):
Van :
# third word in header
voor
#
#
# A new-style (and german language) fbb-header may look like this:
#
# Von        : DG8NBR
# Nach       : YAESU @EU
# Typ/Status : B$
# Datum      : 18-Jun 06:44
# BID/MID    : 17630BDB0BOX
# Meldung #  : 85385
# Titel      : info > FT 530
#
# Now the definitions:
#
# Denotator in first line:
#Von        :
# Denotator in second line:
#Nach       :
#
#
#
# A new-style (and german language) fbb-header may look like this:
#
#Von         : DG1RFG
#An          : WINGT@DL
#Typ/Status  : BF
#Datum/Zeit  : 28-Apr 08:26
#BID (MID)   : DQKBUMDB0BLO
#Msg #       : 457242
#Titel       : TNX ! WinGT und Passwort wer...
#
# Now the definitions:
#
# Denotator in first line:
Von         :
# Denotator in second line:
An          :
#
#
#
# month identifiers as used in your local f6fbb-bbs:
# (they depend on the selected language, too)
#
Jan
Feb
Mar
Apr
Mai
Jun
Jul
Aug
Sep
Okt
Nov
Dez

<EOF>

----------------------------------------------------------------------------

4.19. Configuration file for TNTC

sample tntc.ini:

# main directory
tntc_dir /work/tnt/
# socket for frontend
frontend_socket unix:tntsock
<EOF>

----------------------------------------------------------------------------

5. Additional Information

----------------------------------------------------------------------------

5.1. Options at startup

Usage : tnt [-i <init-file>] [-l <log-file>] [-u] [-d]

TNT has four startup options. A file after -i is taken as the init file and
a file after -l is opened on channel 1 equal to a LOGREC command. The -l
option is useful if the TNC holds data from the time without a terminal. If
the program was not normally ended and the serial port is locked, the
lockfile can be ignored with -u. If TNT shall be started as a daemon without
terminal the paramter -d must be specified. A connection to TNT can be
established with TNTC.

Usage : tntc [-i <init-file>] [-s <tnt-socket>]

TNTC has two startup options. A file after -i is taken as the init file. A
socket specified after -s will be used instead of the 'frontend_socket'
defined in tntc.ini.

----------------------------------------------------------------------------

5.2. Running under X11

TNT needs a XTERM or RXVT console for execution under X11. Therefore TNT can
be started from every XTERM or RXVT shell. As XTERM does not allow the use
of the <ALT> keysequences, I suggest the usage of RXVT, which will provide
the same handling as a linux-console. A sample script file 'xtnt' can be
used to create a new window for TNT. To change the parameters in 'xtnt' see
the manual entry for RXVT.

----------------------------------------------------------------------------

5.3. Porting of TNT

In config.h several options can be defined or undefined. Create a new entry
in config.h and a new makefile for your operating system. At the moment
Linux and Interactive UNIX (ISC) are supported. The codes generated by
function and special keys are defined in keys.h and must be adapted. Because
in most cases not all keys are listed in the /etc/termcap entry the keycodes
are defined in this way. If your porting was successful, please send me your
changes. They will be included then in the next release.

----------------------------------------------------------------------------

6. Credits and Contact

Thanks to Dieter, DK5SG / N0PRA for wampes. The source code contains many
interesting things and I took some parts of the shell-functions out of the
wampes-code.

Thanks to Joerg, DD8FR for providing the code for macro expansion in the
connect text and for using more than 80 characters per line.

Patrick (ex DL7AUC), who has ported TNT to ISC Unix and has contributed many
ideas and additional code for the socket feature, lost his life in an
accident. His work and support was very much appreciated and will be missed
very much. He will always be remembered.

Thanks to Joachim, DL8HBS (author of DigiPoint for ATARI) for providing me
with his sourcecode. Thanks also for the hours of discussing and planning
the porting of the box-part of DP to Linux and for the support during the
debugging sessions.

Thanks to Gert, DK3NY for the implementation of the password generation for
DIEBOX-BBS's and for several bug reports.

Thanks to Andreas, DK9HE for analysing and fixing the startup problem if TNT
was not invoked by root.

Thanks to Werner, DL4NER for code and ideas for the FlexNet password
generation.

Thanks to Mario, DL5MLO for providing the code for the alternative
statusline, the 'insertmode'-flag in tnt.ini, AUTO7PL and several bugfixes.

Thanks to Oliver, DL8NEG for code for the baycom password, for perfect
password hiding and for //RTT.

Thanks to Hansi, DL9RDZ for a bug report concerning unsuccessful socket
connect and the solution for it.

Thanks to Claudio, IW0FBB for code for the MD2 password.

Thanks to Martin, DL3FCC for providing a TeX-version of the documentation
(this was the trigger to leave the path of a clean ASCII-doc).

Thanks to Bruno, F1IRW and Daniel, F1RMB for the french translation of the
documentation.

Thanks to Matthias, DL2SUT for fixes in the daemon code.

The code for YAPP is based on work of Jeff Jacobsen, WA7MBL, Jonathan
Naylor, G4KLX and S N Henson.

Thanks to Sanne Graaf for code for //RTT and //RING.

Thanks to Gerd, DK3NZ and Jonny, DG4MMI for bug reports.

Thanks to all who have tested TNT and have given comments.

And last but not least thanks to Linus and all of the Linux-community for
giving us a superb operating system. Special thanks to Joseph H. Allen for
the JOE-editor and Dave Gillespie for the P2C Pascal to C translator.

If you have questions, comments or bug reports, just write a mail:

Ham Radio : DL4YBG @ DB0GR.#BLN.DEU.EU
Internet  : wahlm@berlin.snafu.de

73, Mark Wahl (DL4YBG)

----------------------------------------------------------------------------

A. Appendix

----------------------------------------------------------------------------

A.1. Static huffman compression table

This table was set up by DK4NB for SP 9.00

      ASCII:  HUFFMAN                ASCII:  HUFFMANN

      <  0>:  101010110010110        <128>:  100111111110110
      <  1>:  101010101000010        <129>:  00100001
      <  2>:  100111111100010        <130>:  100111111101110
      <  3>:  101010110011110        <131>:  100111111100110
      <  4>:  101010110001110        <132>:  111100000
      <  5>:  101010101111110        <133>:  011111010111110
      <  6>:  101010101110110        <134>:  011111010110110
      <  7>:  101010101101010        <135>:  00111010010000
      <  8>:  101010101011010        <136>:  101010110100000
      <  9>:  1111001101             <137>:  101010110011100
      < 10>:  101010101010010        <138>:  101010110011000
      < 11>:  011111010110010        <139>:  101010110010100
      < 12>:  101010101101110        <140>:  101010110010000
      < 13>:  1111010                <141>:  101010110001100
      < 14>:  101010101001010        <142>:  1010101101110
      < 15>:  100111111111010        <143>:  101010110001000
      < 16>:  100111111101010        <144>:  101010110000100
      < 17>:  011111010111010        <145>:  101010110000000
      < 18>:  101010110100010        <146>:  101010101111100
      < 19>:  101010110011010        <147>:  101010101111000
      < 20>:  101010110010010        <148>:  001110110
      < 21>:  101010110001010        <149>:  101010101110100
      < 22>:  101010110000010        <150>:  101010101110000
      < 23>:  101010101111010        <151>:  101010101101100
      < 24>:  101010101110010        <152>:  101010101101000
      < 25>:  10101011011000         <153>:  10101011011001
      < 26>:  101010110000110        <154>:  011111010011
      < 27>:  101010101100110        <155>:  101010101100100
      < 28>:  101010101011110        <156>:  101010101100000
      < 29>:  101010101010110        <157>:  101010101011100
      < 30>:  101010101001110        <158>:  101010101011000
      < 31>:  101010101000110        <159>:  101010101010100

      ASCII:  HUFFMAN                ASCII:  HUFFMANN

           :  110                    <160>:  101010101010000
          !:  001110101              <161>:  101010101001100
          ":  1010101111             <162>:  101010101001000
          #:  00000000011            <163>:  101010101000100
          $:  011111010100           <164>:  101010101000000
          %:  10101011010111         <165>:  100111111111100
          &:  000000000000           <166>:  100111111111000
          ':  10101011010110         <167>:  100111111110100
          (:  011111000              <168>:  100111111110000
          ):  001111001              <169>:  100111111101100
          *:  01111101000            <170>:  100111111101000
          +:  000000000001           <171>:  100111111100100
          ,:  0001001                <172>:  100111111100000
          -:  0111101                <173>:  011111010111100
          .:  101110                 <174>:  011111010111000
          /:  0011001                <175>:  0011101001011
          0:  0010001                <176>:  011111010110100
          1:  11110110               <177>:  011111010110000
          2:  00111101               <178>:  101010110100011
          3:  100111100              <179>:  101010110100001
          4:  101111011              <180>:  101010110011111
          5:  011111001              <181>:  101010110011101
          6:  000000001              <182>:  101010110011011
          7:  101010100              <183>:  101010110011001
          8:  101111010              <184>:  101010110010111
          9:  100111110              <185>:  101010110010101
          ::  00000011               <186>:  101010110010011
          ;:  1010101101111          <187>:  101010110010001
          <:  1010101101101          <188>:  101010110001111
          =:  001111000              <189>:  101010110001101
          >:  001100000              <190>:  101010110001011
          ?:  00000000001            <191>:  101010110001001

      ASCII:  HUFFMAN                ASCII:  HUFFMANN

          @:  011111010101           <192>:  101010110000111
          A:  0011100                <193>:  101010110000101
          B:  0111100                <194>:  101010110000011
          C:  1001110                <195>:  101010110000001
          D:  1111111                <196>:  101010101111111
          E:  001001                 <197>:  101010101111101
          F:  10111100               <198>:  101010101111011
          G:  00000010               <199>:  101010101111001
          H:  00000001               <200>:  101010101110111
          I:  11110001               <201>:  101010101110101
          J:  00000000010            <202>:  101010101110011
          K:  00110001               <203>:  101010101110001
          L:  11110010               <204>:  101010101101111
          M:  0011010                <205>:  101010101101101
          N:  0001110                <206>:  101010101101011
          O:  0001111                <207>:  101010101101001
          P:  1011111                <208>:  101010101100111
          Q:  10101011101            <209>:  101010101100101
          R:  0011111                <210>:  101010101100011
          S:  000101                 <211>:  101010101100001
          T:  0011011                <212>:  101010101011111
          U:  111100111              <213>:  101010101011101
          V:  111100001              <214>:  101010101011011
          W:  00100000               <215>:  101010101011001
          X:  11111100               <216>:  101010101010111
          Y:  1001111110             <217>:  101010101010101
          Z:  100111101              <218>:  101010101010011
          [:  101010111001           <219>:  101010101010001
          \:  001110111              <220>:  101010101001111
          ]:  101010111000           <221>:  001110100111
          ^:  10101011010101         <222>:  101010101001101
          _:  0011101001010          <223>:  101010101001011

      ASCII:  HUFFMAN                ASCII:  HUFFMANN

          `:  10101011010100         <224>:  101010101001001
          a:  10100                  <225>:  001100001
          b:  000110                 <226>:  101010101000111
          c:  100110                 <227>:  101010101000101
          d:  01110                  <228>:  101010101000011
          e:  010                    <229>:  101010101000001
          f:  000001                 <230>:  100111111111111
          g:  101011                 <231>:  100111111111101
          h:  111110                 <232>:  100111111111011
          i:  0110                   <233>:  100111111111001
          j:  0011101000             <234>:  100111111110111
          k:  11111101               <235>:  100111111110101
          l:  00101                  <236>:  100111111110011
          m:  101100                 <237>:  100111111110001
          n:  1000                   <238>:  100111111101111
          o:  101101                 <239>:  100111111101101
          p:  0001000                <240>:  100111111101011
          q:  011111010010           <241>:  100111111101001
          r:  11100                  <242>:  100111111100111
          s:  10010                  <243>:  100111111100101
          t:  11101                  <244>:  100111111100011
          u:  00001                  <245>:  100111111100001
          v:  11110111               <246>:  011111010111111
          w:  1010100                <247>:  011111010111101
          x:  011111011              <248>:  011111010111011
          y:  1111001100             <249>:  011111010111001
          z:  0111111                <250>:  011111010110111
          {:  10101011010010         <251>:  011111010110101
          |:  0011101001001          <252>:  011111010110011
          }:  10101011010011         <253>:  011111010110001
          ~:  001110100110           <254>:  001110100100011
      <127>:  100111111111110        <255>:  001110100100010

----------------------------------------------------------------------------
