The Talk/Chat Server

All about talk...

The talk service supports a live, two-way TTY messaging system that is designed to facilitate communications among users on a network system. In the "old" days, it used the TTY (getty) lines branching out from a single machine, but today, it can talk to anyone anywhere! So, formerly, you asked to talk to a "user" on your local system, whereas you now ask to talk over the network to a user@domain, where domain is any machine that can "talk" to you or your OS. (But, if you are logged in somewhere and looking for a user on that machine, then you would only need "talk user.")

As set up now, talk does not require a login or a user account on your system for someone to reach you. Anyone may use the talk port to present a message on your screen and begin a chat. (Of course, the intended recipient, probably you, must be logged in.) On the Linux side, the screen is split into upper and lower areas, each party having their own messaging space. You type in your message lines and end the session with a Ctrl-C.

Non-Linux systems receive the data just as it comes in, all on one (telnet session) screen with a newline character beginning the next line. (This can be troublesome since what you are trying to type may be may be interfered with from the other party. It is best when it is Linux-to-Linux, or Linux-to-UNIX.) All data is sent character by character in the internet, telnet protocol. This is great for the split screen format, giving the appearance of full duplex, but not as readable when both partys' lines are interlaced on a single screen...

The talk daemons are not used as much as in the past since newer, more interesting, methods of messaging have evolved due to the stimulus of the internet. But talk is still used retrogressively since other daemons may also "tap into" the talk daemon(s); one being the ttylinkd used in ham radio and the AX25 Utilities. The ttylinkd uses port 87 and sets up a pipe to talk, essentially "borrowing" code. (That is one reason why ttylinkd is so "lightweight.")


A Little More About Talk

Introduction:

Most current Linux packages come with "talk" already installed and properly set up. There isn't much you need to do except verify that you have the code on-board and that it is working OK.


Code Location:

The talk service is implemented as client/server. So there are two programs that you must look for. One is "talk," the client, and the other is its daemon, "in.talkd."

To do this, you enter:

  • "whereis talk"
  • "whereis in.talkd"

and you should see the full path returned with the program names "talk" and "in.talkd" at the end. If you don't see this, then you don't have the code! You would then need to either download them from somewhere or install them from your CDROM disk package.


Code Verification:

To verify the operation of in.talkd, you need to search through the inetd.conf file. Use the following command:

  • "grep talk /etc/inetd.conf"

You should see at least one line: 

ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  in.talkd

There should be no comment mark (#) preceeding this line. You might also see a second line beginning with just talk; both are fine. If you see a comment mark, be sure to edit it out. Then restart the inetd daemon by issuing a "kill -HUP" on its PID number.

In the services file, you should look for both talk and ntalk entries.

  • "grep talk /etc/services"

This should return one or more lines as follows: 

talk            517/udp
ntalk           518/udp


Network Device, dummy0:

One more piece of the puzzle needs to be in place for the talk system to work and that is the dummy0 network device. It has been my experence that you need this in the config table and in the routing table to make talk work. These three (3) commands will show you the information you need:

  1. "lsmod | more"
  2. "ifconfig dummy0"
  3. "route -n | grep dummy0"

You should see a listing for dummy in the modules table. You should see an entry in the config table as well, and in the routing table. Most packages will ask you about this at install. So, there is every reason to believe that this information has already been entered. At this point, you are just checking.

However, if you are missing anything, you must then re-install the items you need. Probably, the best place to begin is the modules table. To insert the dummy.o module, use this command:

  • "/sbin/insmod /lib/modules/2.0.30/net/dummy.o"

When you issue the lsmod command again, you should see something like this table. (Remember, the contents of this table will vary greatly from machine to machine. This is my example only...) 

-----
Module:        #pages:  Used by:
dummy              1            1
ne                 2            1
8390               2    [ne]    0

You may have to hunt around for dummy.o. It might be some place other than /net. And, you will have to change my version of Linux to the one you are using. The config command is as follows:

  • "/sbin/ifconfig dummy0 ka1fsb.ampr.org"

Here is what your ifconfig dummy0 command should now show... 

------
dummy0    Link encap:10Mbps Ethernet  HWaddr 00:00:00:00:00:00
          inet addr:44.56.26.10  Bcast:44.255.255.255  Mask:255.0.0.0
          UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0
          TX packets:0 errors:0 dropped:0 overruns:0

You will have to change my host name to your host name. Finally, you will need to add a route to the routing table:

  • "/sbin/route add ka1fsb.ampr.org dev dummy0"

Be sure to change the host to your host name. When you run route -n again, you should see this, where the 44 address will be your address: 

44.56.26.10     0.0.0.0        255.255.255.255   0    0    0 dummy0

If you see this entry in the routing table, then you can be sure that all the above commands have been completed successfully.


Conclusion:

If you have all of the above mentioned items in the right places, then the talk facility has been properly set up, or verified, on your system.

NOTE:

If you don't have an AMPRNet 44 IP address yet, you probably could use a "reserved" internal address such as a 192.168.x.x. I have not verified this on any of my systems, but it "should" be doable... The reserved IP approach would work fine locally, on a LAN for example, for logged-in users. (The ttylinkd daemon, though, should still be able to communicate over the internet on its designated port 87, tapping back into the local talk daemon via its pipe, since the dialed-up IP or cable IP will be "reachable" externally from the inet.)



(Courtesy KBNorton Computer Services)