For a small document telling how to sense the ip address from which a telnet connection was made, click here.
Many people ask, "is there more overhead for a Telnet connection than there is for a modem based connection?" I suppose that they realize that individual keystrokes coming in, and small fragments of screen output going out, are all encapsulated in TCP/IP packets, and that this seems wasteful and network-hostile. To those people, I can emphatically state, "quit worrying so much!". TSX can pass so many TCP/IP packets around in a second, and the speed of ethernet is so fast, that the additional "overhead" for Telnet based traffic is impossible to measure. Telnet is fine! Feel good about it!
Next, let's plunge right into the detailed sequence of events which take place surrounding an incoming telnet connection. Knowing how it works is the only way you will ever be able to fix it if it's broken or make it work better if it's not.
The network server program, NETSERVE.EXP, is responsible for accepting connection requests on behalf of the remote Telnet client. It does this because it's directed to by the files SY:SERVICES.NET and SY:INETD.NET. in the SY:SERVICES.NET, there needs to be a line that looks like this:
This means that there is a service named telnet which will be using port 23 for connection requests; that is uses tcp, and that the name of the service to run is TELNET. This TELNET service is defined by the corresponding entry in SY:INETD.NET:
If your system is not servicing incoming telnet requests, obvious things to check from what you've read so far are to verify that the network server is running (it should normally be in a WAIT state), check to see if the SY:SERVICES.NET and SY:INETD.NET files contain the needed entries, and check to be sure that SY:TSXTLD.EXP is there. If you've checked all that out and remote clients can't connect, we suggest you look in the NETSERVE event log. Do you possibly have a trusted host list that's preventing the connections? Could it be that your system job limit is maxed out? Could the remote end be dropping the connection immediately after making the request? You can find all these things out int he NETSERVE event log.
If you are still stumped, you might want to reboot the system and look at the FIRST entries that go into the NETSERVE event log, because it might have reported errors binding to the telnet port which got washed away by the newer entries written to the event log while the system has been up.
Once the network server accepts a remote connection request from a telnet client it detaches the SY:TSXTLD program (which stands for TSX Telnet Daemon). This modest program has a short lived, but important, purpose in life. It creates a new network virtual terminal for the incoming job to log in to. Network virtual terminals are described in the article on terminal types. This network virtual terminal, or NVT, will be given a terminal type of ANSI for a system whose licensing restricts it to TSX-Online usage or VT100 for other systems, and it normally has the startup command file SY:NETLOGON.CMD. What this means is that the new incoming job is going to start running on this terminal and it will execute the commands in SY:NETLOGON.CMD as its startup file. This is analagous to the way the modem lines run SY:BBS.CMD or SY:START.CMD. From this point on, the NVT will show up in various places like the SYSOP dashboard display and the SHOW TERM command. The job running on that terminal will show up on the SHOW SYSTEM and JMAN displays.
An interactive telnet user counts against your licensed maximum number of simultaneous users, so if your system is licensed for 9 users and 9 people are already logged on, the client might see "Sorry, the maximum number of users are already logged on" flash up. After this, TSX will disconnect, so the poor user might not see that at all.
Interactive jobs are also limited by the total job slot count, specified by the all important TSGEN parameter, VMAXJOBS. If VMAXJOBS is hit, the network server won't even be able to create the job on the network virtual terminal; this will only show in the NETSERVE event log.
Let's talk some now about the contents of SY:NETLOGON.CMD. This is critical, because if this file contained nothing but an "EXIT" statement, incoming telnet users would drop to a command prompt in your system directory with full privileges. Actually, if the system is restricted to TSX-Online, getting to the command prompt logs the job off, but the danger does exist for a fully licensed system. TSX-Online systems probably want to have the SY:NETLOGON.CMD just execute SY:BBS.CMD, which runs TPR and tells it to execute LOGON.TPL. You could do this by having SY:NETLOGON.CMD contain just this line:
Users of fully licensed sytems probably want the SY:NETLOGON.CMD to run the standard logon program with a statement like this:
The file SY:NETLOGON.CMD is used for two different types of network virtual terminals: those created by incoming telnet connections and those created by a native TSX peer to peer network logon. This second type of NVT session happens when you use the SET HOST command to log onto another computer of your LAN (or WAN) and also happens when TSX-Term connects through the network. You might well want the SY:NETLOGON.CMD file to distinguish between these two types of connections and do different things. Most likely, you want the incoming telnet users to go straight into TSX-Online, but you might want the native connections to run the LOGON program or even just drop to a prompt so you can manage your system over the network. To accomplish this distinction, use the $TERMINFO lexical function. Here's a fragment from a SY:NETLOGON.CMD file which does this:
!Another thing that people like to do with incoming telnet connections has to do with hosting multiple domains on one computer. When you do this you create virtual terminals that become TCP/IP interfaces associated with the IP addresses assigned to each domain. The network server accepts incoming telnet connections on behalf of all these interfaces. The trouble is that the same SY:NETLOGON.CMD file is used for all the interfaces on your system. Dan was convinced he had a way around this when he first started writing this, but he's gonna have to get help! Beam me up, scotty, I'm in trouble here!
OK, on to the final topic about controlling incoming telnet connections. Telnet clients don't always use the standard telnet port (23) to connect to the server. In particular, it's common for MUD games to accept telnet connections for players on higher ports. The first customer that tried to do this with TSX motivated us to design a new mechanism by which the standard SY:NETLOGON.CMD could be overridden as a function of the port on which the connection was accepted. Doing this would require additional entries in SY:SERVICES.NET for the higher port numbers used by the MUD. For example, a MUD might use port 5000. This still needs be associated with the Telnet service so it will create an NVT and start a job on that line. SY:SERVICES.NET thus has these two entries about telnet, the first of which is the standard one and the second of which is the one for the MUD:
The network server works in conjunction with the SY:TSXTLD.EXP program to communicate the port number on which the connection was accepted. You don't need to worry about how this works; suffice it to say that its purpose is that TSXTLD checks for file named SY:PORTnnn.CMD where "nnn" matches the port number used for the connection. Hence, if you want telnet jobs created by connections to port 5000 to run a different startup file than SY:NETLOGON.CMD, just make a file named SY:PORT5000.CMD and put the commands in there to run the MUD.