The ttylinkd.conf File

What the ttylinkd.conf file does...

This file directs the talk/chat program to a user, usually root, but it might be another user. 

# /etc/ax25/ttylinkd.conf : config file for ttylinkd(8)
#
# We just have one line, who gets the incoming ttylink calls.
# 01-29-00 kbn, added another key to this conf file: sysmsg
# It has the path to a message from the sysop.
#
# sysop=user@hostname.domain.name
# or:
# sysop=user
#
sysop=root

This config file may not be of much use to you unless you have the ttylinkd daemon code in place and in proper working order! You must have the above config file set up as shown, but you also must have the correct entry in the inetd.conf file so that it will be able to activate the link for incoming network requests... See below for details.


How to set up and use ttylinkd

Many of the newer OS packages come with the talk or ntalk daemons fully installed and configured. If this is the case, you will only have to set up the ttylinkd daemon. Ttylinkd depends on the talk daemons by connecting a pipe to one of them, essentially borrowing their services. If these talk daemons are not activated, then you will have to configure them as well...

Code Verification:

As a first step, you should verify that you actually have the piece of code that you need. It is called ttylinkd. If you do a "locate ttylinkd" or a "whereis ttylinkd," you should see a return with a valid path to the code in question. A typical response might be: /usr/sbin/ttylinkd. You also need talk or ntalk since ttylinkd sets up a pipe to (n)talk. (Check to see if they are there in /usr/bin.)


Configurations:

Now you need to edit two (2) config files: the inetd.conf and the services files. Both are found in /etc. In the inetd.conf file enter the line between the quotes:

  • "ttylink stream  tcp    nowait  root   /usr/sbin/ttylinkd ttylinkd"

I usually place this near or under the entry for ntalk. (Use tabs or spaces to achieve a suitable column alignment.) And be sure that ntalk is activated in the inet.conf file as well, i.e., no leading #'s, since ttylinkd depends on ntalk! In most cases, it is already activated.

In the services file, enter this line:

  • "link     87/tcp     ttylink"

Again, use tabs or spaces to align with other entries. And place it in numerical order in the list.

Activating:

To activate these new entries, you must issue a "kill -HUP <inetd PID>" on the inetd pid. So list out the PID table with "ps ax" and find the PID number for inetd. (You may use "ps ax | grep inetd" to see just those lines pertining to inetd.) Let's say it is 50. So the command would be:

  • "kill -HUP 50"

Inetd will re-read the inetd.conf file and apply the changes made. In theory, the ttylinkd is now good to go!


Testing:

So how do we test this TTY Chat service? The command would be:

  • "telnet localhost 87"

You may use the hostname if you like instead of localhost. Ttylinkd will now be called into action by inetd on port 87. Ttylinkd creates a pipe to a program named "talk" or "ntalk." The user will be asked for a callsign as the requestor, but it does not filter for a callsign specifically, so a first name may be used! Below is a sample message "notice" from the Talk_Daemon. (A callsign was used here, but nearly anything without spaces will work OK too.) In this case, user ka1fsb wants to talk to user root and this message below appears in root's login session ... 


"Message from Talk_Daemon@ka1fsb-12 at 11:02 ...
talk: connection requested by ka1fsb@ka1fsb-12.ampr.org.
talk: respond with:  talk ka1fsb@ka1fsb-12.ampr.org"

—
You (root) would respond by entering "talk ka1fsb". You may enter the entire "caller@domain name," but it is usually not required.

If you are testing locally, then be sure to have another tty session going so that you can "talk" to yourself. (Login as another user.) Ttylinkd will ask the caller for some kind of ID, as mentioned either a callsign or a name. After entry, a notice is posted to your original or root session, see above, that you (root) have a caller (ka1fsb) "on-line." The recipient, you in this case, responds with "talk caller" where caller has been identified in the notice. The screen on the local systems goes into split mode and the transfer is character by character. (Either party may end by using a Ctrl-C.)


Application:

This begins to get interesting when you realize that the localhost above can be any hostname or IP! Anyone may telnet to you on port 87 and have a chat! It doesn't have to be resticted to a ham! (At least, the code I am using so far does not make this distinction.) And these talk facilitiies send character by character which is how most telnets communicate over the internet.

NOTE:

If you can't seem to get ntalk or ttylinkd to work, it may be because you need to have the dummy0 interface configured. It has been my experience that I needed this interface to get these daemons working. You might not need them on your system, or they might already be in place.

Begin with an ifconfig request to attach your hostname to the dummy0 interface. If it works, you may then add a single route, again your hostname, attached to the device. (If this fails, you may need to insert dummy.o as a module, and then repeat the network configurations commands just mentioned here.) For more information, see the talk server .



(Courtesy KBNorton Computer Services)