KA9Q TCP is an implementation of TCP/IP for the PC. This is a Unix port based on a version from mid-1989. Unfortunately the more recent versions of KA9Q are harder to port to Linux. I don't have a manual for this exact version. There's builtin help. The commands primarily set parameters (the ip and tcp commands), or start services. In general the same command is used to set and examine parameters. When you type the command with no value, it shows the current value. To use KA9Q, put startup.net and possibly domain.txt in your home directory, and run "net". You will probably need to tailor startup.net for your configuration. See the section at the end of this document on configuration. Note that you can give an argument to the "net" command. It will be used as the startup file in place of startup.net. By default, startup.net and other files are in your home directory (the value of the environment variable HOME). You can put them somewhere else by using the environment variable NETHOME. If you are using SLIP, note that you must first dial the modem and establish a SLIP connection. The exact details on doing this are different at each site. Unfortunately you're probably going to need help from system or network support staff in order to use SLIP. Because SLIP effectively connects you to someone's local network, using it normally requires logging in with a password. I recommend using kermit's script facility to dial and set up SLIP. It did not seem work adding a similar facility to KA9Q. If your site does not current support SLIP, they will probably have to do a bit of systems work. For Unix systems, typically this will involve adding a SLIP device driver, and then enabling routing. (An appropriate driver is available for the Sun, although I don't know where. I believe it can be installed without Sun source.) Many terminal servers will support SLIP directly, so enabling it will merely involve changing a configuration file. Aside from configuration commands (which typically go into startup.net), the most common commands are probably telnet and ftp. Both take a host name. Once you are connected, the "escape character" (initially ^]) lets you do some special things. You type it followed by another character. Except for the escape character, the characters are folded, so that c, C, and ^C are equivalent. Here's a list of the special characters: escape character (i.e. two in a row) - send a real escape character x or ^x - return to command mode b or ^b - send break c or ^c - send interrupt process o or ^c - abort output t or ^t - are you there? h or ^h - send telnet erase character u or ^u - send telnet erase line ? - print this help message Once you return to command mode, the "session" command can be used to switch between connections. With no arguments, it shows the current sessions. With a number, it will reconnect you to that session. There's a disconnect command to kill a session (also some stronger ways of doing it). Telnet normally operates in full duplex, with the other system echoing. However if that system refuses echoing, or if you use the command "echo refuse", KA9Q will echo locally. In this case you have the normal line editing functions. Several control characters have special functions. Note that in local echo mode, you do not need to hit the escape character first. escape character - return to command mode ^v - quote the next character ^b - send break ^c - send interrupt process ^o - abort output ^t - are you there? Telnet will pass your TERM environment variable as the terminal type if the other end asks for it. It will implement flow control locally if the other end understand the remote flow control option. If the other end does a "telnet sync" correctly, it will suppress output when appropriate. E.g. when talking to a Unix system, if you type ^C or ^O in the middle of a large output, output should stop immediately. However there may be a pause before getting the next prompt, as some previously buffered data is probably still going to be transmitted. The "ip stat" and "tcp stat" commands are useful to get statistics. "Ip stat" shows both the IP and SLIP level. If header compression is being used, it will show how many packets were compressed and how many were oot. FTP is sort of odd. It looks like you are in an interactive conversation with the FTP server at the other end, with no local command prompt. Most commands are passed directly to the remote server, but in fact there is a local command parser, which will intervene for a few commands: cd, dir, list, get, ls, mkdir, nlst, rmdir, put, type get and put should be used to transfer files. There's very minimal support for X11. If you are running under X on your Linux system, you can use the command "start x". This will cause KA9Q to front-end the Linux X11 software, so that you can run X-based software on other hosts. As usual, you set a DISPLAY environment variable of the form myhost:0.0 where myhost is the host name or IP address of your Linux system (i.e. the address that KA9Q is using). This function is currently very primitive. There is no access control -- once you've started X, anyone can connect to your display from anywhere on the network. KA9Q will put out a message whenever someone connects, so at least you'll know. If people find this feature useful, I'll put in access control. With the current implementation, there are still two things you could do: (1) use xauth, (2) turn on the X server only when you actually want to start up X software. You can do "stop x". This will not close down existing X connections. It will just prevent new ones, until the next "start x". Unfortunately, X involves a lot of network traffic. Over a 9600 bps line -- which is the primary audience for this implementation -- it's probably too slow to be useful. It's possible to run a server which others can connect to, though I haven't tried it except for ftp. The command is "start ftp", etc. For ftp, a login is required. The file ftpusers, in your home directory, contains a list of users and passwords. Here's a list of commands: ! - call a recursive shell arp - set arp parameters ax25 - configure ham interface attach - define an interface - must be used for each interface bootp - request our IP address from a server connect - for AX25, define call sign for interface cd close disconnect dir - do a directory on the local system domain - configure domain name system eaglestat echo - refuse or accept - request to disable telnet remote echo eol - Unix or standard end of line options [standard is recommended, even for use on Unix systems] escape - change escape character etherstat exit finger forward - divert packets from one interface to another ftp - open an ftp connection hapnstat help - print command list hostname - set/examine host name kick log ip - set/examine IP level parameters memstat mbox, mode - AX25 commands mulport netrom nrstat param - set/examine interafce parameters ping - send ping to a host pwd rdate [offset] [host] - set date/time from UDP time daemon. see below record remote reset - kill connection route - set up routes session - see above: move to a different session shell - call a subshell smtp - mail handling start - start server stop - stop server tcp - set/examine tcp parameters telnet - open telnet connection trace - enable low-level debugging (no arguments - show current status) trace to - put trace output on file (use "con" for console) trace [] - trace packets on device device is typically "sl0" or "loopback" bits are in hex: 1 - output, 10 - input (else no tracing) 100 - dump data in ascii, 200 - hex (else headers only) trace cmdmode|allmode - show trace just when at command level? trace telnet [on | off] - show telnet options and urgent data udp - set/examine udp parameters upload wait - control mail select The rdate command uses the old-style time protocol (often known as "rdate"), on UDP port 37, to get the date and time, and then sets the system clock. Note that the protocol always gives time in GMT. If your system clock is running on GMT (which is the normal way Unix should run), this is fine. Otherwise, you'll need to specify the offset in minutes. For time zones west of GMT, this should be a negative number. For the Eastern U.S., when not in daylight time, the offset is -300, because EST is 5 hours (300 minutes) west of GMT. If no host is specified, a UDP broadcast is used. This configuration of KA9Q has been tested only with SLIP. Code is also included for the KISS device (for ham radio) and Linux generic Ethernet support using /dev/eth. /dev/eth should either work or come close to working: it's based on diffs made from a recent version of KA9Q. I don't know of anyone who has tested KISS. Past experience suggests that users will prefer Kermit to SLIP unless you use SLIP with header compression. Note that this program depends up non-blocking I/O and the select system call. In Linux 0.12, these did not work. There are patches, nonblock.tar.Z and select.patch, on the major distribution machines. Don't forget: after patching a kernel source file, you must do a make in each directory where you changed a file. The main make file doesn't rebuild things all the time when it should. Linux 0.95 and later has all the necessary patches. CONFIGURATION: Here's some advice on preparing a configuration file. I assume you're planning to use SLIP (dialup IP) or Ethernet. I'm going to explain my configuration file line by line, as it's likely to be close to what you need: attach asy 0 /dev/tty64 cslip sl0 2048 1500 9600 You must include an attach command in every configuration file. It defines the device. For SLIP, the line above should be about right. Some variationos: - /dev/tty64 is the serial line. Obviously you can adjust this to use a different line. - cslip specifies SLIP with Van Jacobsen header compression. If you're using normal slip, use "slip" instead of "cslip". In my opinion, response on normal SLIP is too slow for it to be very useful. - 9600 is the line speed. Use whatever speed you are set for. If you have a "smart" modem, we recommend turning off any error correction or compression. These features introduce enough delay to be objectionable. The following attach command could be used for Linux generic Ethernet (/dev/eth) attach linux arpa eth0 1500 1.2.3.fa.fb.fc The last item is your Ethernet hardware address, in hex. It should be printed when your system boots. E.g. if it prints 01 02 03 04 05 06 then you put in 1.2.3.4.5.6. Each of the six numbers is in hex, and may be one or two digits. wait 0 This should only be needed with older version of the kernel. It disables the select system call. Instead, runs in a tight loop continuously testing for input. Unfortunately select has a history of problems under Linux. It appears to be fine in version 0.96. However in earlier version, select did not work properly when there was another program running. (In some cases it works OK unless the other program uses select. E.g. if you enter emacs in another window, your FTP comes to a halt.) If you are trying to use KA9Q while another program is running, and you find that the connection hangs, you might try "wait 0". Otherwise, you should leave the default setting, which is "wait 100". The argument to wait is in milliseconds. It's the amount of time to wait in the main loop. The select will trigger if input arrives on the serial line, or you hit a key. Otherwise it waits this amount of time. I don't recommend values larger than 100. Smaller values might possibly be useful in some siuations. route add default sl0 This says that all packets should be sent out the SLIP line. Presumably this is what you want. If you are using Ethernet, of course you'd use the name of your Ethernet device instead of sl0, e.g. route add default eth0 bootp This says that the system will find out its IP address by sending a BOOTP request out the serial line. Since dialups are normally in "hunt groups", you will probably get a different line each time you dial up. Thus your IP address will probably not be the same. BOOTP is a way of asking the terminal server (or whatever else you're connected to) to tell you your IP address. If your terminal server does not support BOOTP, you explicitly set your IP address using a command of the form ip address [1.2.3.4] where 1.2.3.4 is your IP address. You would use this command instead of the BOOTP command. tcp mss 64 tcp window 256 These commands set TCP performance parameters. These control a tradeoff between overall throughput, jerkiness of output, etc. These parameters seem to give good performance for interactive connectionos. For FTP you might want larger values, particularly if you are going over a long-haul network like the Internet. For FTP the best value for mss is at least 512, and probably more like 1024, with window between 2 and 4 times mss. However Linux has fairly small buffers for the serial line, so you may not be able to get away with parameters much larger than the ones shown here. If you are using Ethernet, of course you'll want larger values. I suggest starting with tcp mss 1460 tcp window 5840 This should work for traffic on the local Ethernet. If your traffic tends to go through routers, a safer set of values is tcp mss 512 tcp window 2048 domain suffix rutgers.edu domain add [128.6.4.4] These parameters control the domain system. That's the set of servers you use to look up host names. You'll need to adjust these for your campus. The suffix is tacked onto all host names you type, unless they already have a dot in them. This lets you type "athos" instead of "athos.rutgers.edu". Set it for the domain you most commonly use. The address 128.6.4.4 should be the address of a domain server on your campus. All name lookups will be directed to that server. You can define more than one, by using several "domain add" lines. If your campus does not support the domain system, you can use a host table instead. In that case you would omit the "domain" commands. The host table is called "domain.txt", in your home directory. It's in the format of a domain master file. The most important entries look like athos.rutgers.edu. IN A 128.6.4.4 Note that IN and A must be in upper case, and the name must include the whole suffix, and end in a dot. Note that this is a very old domain implementation, and is not up to the level of the current MS/DOS version. It does not use TTL's. Every time you type a name, it first looks in domain.txt. If there's an entry there, it will be used. Otherwise, it will query the domain server you specified. If it gets an answer, that information will be added to domain.txt. If a host changes its address, you'll be in trouble, because you'll continue getting the old information from domain.txt. Thus it's probably a good idea to remove domain.txt now and then. start finger start telnet These start daemons to respond to incoming finger and telnet connections. This is optional, but most people will probably find them useful to help people find you. The finger server uses files stored in a subdirectory "finger" of your home directory. Files should have names of the form xxx.txt, where xxx is a user name. Finger with no arguments will list all users on the system (i.e. it will look for all files ~/finger/*.txt, and list the names). Finger with a specific user name will display the text of that file, i.e. ~/finger/xxx.txt. The telnet server is really more like a talk link. When someone telnets to your machine, you'll get a message saying that there is an incoming telnet connection. At that point you should escape to the coommand level (using ^] or whatever your escape character is), do "session" to see the session number of the incoming connection and do "session NN" to connect to it. At that point you'll be in an interactive link with the person. There is also a server designed to allow "real" telnet connections, i.e. connections that create a real login session. It is activated with the command "start telunix". However that code is incomplete, and currently does nothing useful.