Enhancements to the KA9Q/W9NK TCP/IP Version 890421.1 by KD8WK. Here is a compendium of the mods I have put into the NET program. Tnx to N8EMR for helping with this documentation. Several mods have been made to the tcp/ip "net" package. All of these mods were made for the AT&T Unix-PC (roughly Sys V Rel 2 Unix), but are designed to be portable to other systems and architectures. Here are some of the changes that differ from the "DOS" version of the code. COMPILING: I currently use the GCC 1.37 compiler to compile NET. I also use shared librarys on the Unix-PC, which require redefining any function which might exist in the library. These include echo() and noecho(). I redefined them in global.h to be Xecho() and Xnoecho(), and it works fine under gcc. I noticed this broke the default cc compiler on the Unix-PC, though. It is apparently not intelligent enough to know not to try to make the substitution when echo/noecho are used as variables/struct members as opposed to functions. You may have to change these defines. I also use a MSPTICK value of 1000, which vastly simplifies things under Unix, which has no sub-second granularity. Others have gone to great pains -- even writing device drivers -- to provide a more robust clock. I find a faster tick rate is entirely unnecessary in NET. You can hassle with another tick rate if you like. Note that the "heartbeat" rate of net is faster than a second, and is determined by the time delay values on the read() system calls, rather than the MSPTICK value. SETUP: The Unix(TM) version of "net" does not keep the necessary files in the same places as the DOS version. The exact location is specifiable at compile time from file.c. Here are the locations we chose: /usr/lib/net: (directory for system files) ftpusers (same format as dos version) hosts.net (same format as the dos version) net (the executable version of the code) netcron.hr* (script file to make sure net is running) startup.net (the Unix equivalent of autoexec.net) tcp.log (tcp log file, as specified via the "log" cmd) /usr/spool/net: (root directory of the mailer programs) /usr/spool/net/mail: (incomming mail is put here) .txt File bm will use to read mail /usr/spool/net/finger: files for finger command support .txt this file will have whatever info you want remote users to know about your users. This file is used whenever a remote user issues a finger @site or finger user@site command /usr/spool/net/mqueue: (outbound mail messages..) sequence.seq Contains number of outgoing messages xxx.txt text of message to send, xxx is msg number xxx.wrk where to send message (info for smtp) xxx.lck lock file is message is currently being sent. /usr/spool/net/public: (public directorys, put whatever publicly accessable files you want users to have. This location is specifiable in the ftpusers file.) /usr/spool/net/badjobs: (directorys of jobs that can't get resolved...) AX25/NETROM PAD: I have heavily modified the ax25/netrom mailbox. In addition to changing the prompt and some other msgs and internal details, I have added a PAD function to allow the ax25/netrom user to initiate a telnet session. The mbx user types telnet to initiate the session. addresses can be in the form [XX.XX.XX.XX] or aliases from the hosts.net file. The defaults to 23. Only the first character of "telnet" (or any mbx command) is significant. If it is capitalized, the "Established" and "Closed" messages are not printed. In addition, an alias feature was added, permitting any command character to be mapped to one of the internal commands. To init this, enter the commands such as: (probably in the startup.net file) mbox equate X tel n8emr 135 mbx equ S s kd8wk@kd8wk m e h T kd8wk 99 m e X for instance, to give the mbx user the X and S commands while redefining the "help" command. These commands invoke a telnet to n8emr port 135 in the first case, sends mail to me in the second, and invoke a telnet to kd8wk port 99 (presumably to cause a help file to be printed) in the last case. The last example deletes the X alias. By setting up shellscripts on spare tcp sockets, using the external socket code below, sophisticated mbx commands -- or even an entire bbs -- can be added to the mailbox. Needless to say, the NET "mbox" command syntax has been altered slightly, but it is easier to learn the rest of it by using it than to explain. One additional feature was added to telnet sessions originated from the mbox: The mbox user can type CNTL-Z to close the session. There is no way to defeat the special function of CNTL-Z. EXTERNAL SOCKETS: I have modified the telunix code I wrote last year, which is now part of the ka9q NET package, to allow a Unix command (with args) to be specified as part of the NET "start" command syntax. The specified command is invoked as a child process of NET to provide an external subprocess environment when someone connects to the specified TCP socket. Data flows between the subprocess and NET using pipes. This allows a great deal of flexibility in writing telnet servers on Unix systems -- essentially permitting them to be implemented as shell scripts. It would conceivably permit things such as smtp mail and ftp to be reimplemented as external processes, thus making the resident part of NET more compact. The telunix stuff still works, provided you have a pseudo-tty driver. The external environment stuff can be used in conjunction with telunix or alone, and does not require pseudo-ttys. Enclosed is a note I sent to Gary Sanders, n8emr, which describes in more detail how this may be used. Rob Stampfli, kd8wk osu-cis!kd8wk!res ========================================================================== >From res Fri Dec 1 23:46:55 1989 To: n8emr!gws Subject: new net Status: R Gary, Here is a test version of net with the external socket code in it. Play around with it and let me know if you find any problems. The first thing you'll have to do to make it work reasonably is enter the "eol unix" command to net. This makes net send nl instead of crnl as the end of line marker. I could hack in a mod to ignore cr, but then you couldn't send image files using this mechanism. Next, define some external sockets. For instance, an echo server can be made by issuing the command: start x 5 cat and undone by the command: stop x 5 The strings which follow the socket number above are preserved and used to invoke a subprocess on each instance of a telnet (or other connect) to that socket. A pipe to and from net is the subcommand's stdin and stdout. The command can be a shellscript, which allows the most flexibility. For example, create this script in net's home directory: $ cat >testscript echo "Enter $1 $2:\c" read name echo "Hello $name, Here is what you typed verbatim:" echo $name | od -c $ Then get into net and start up an external telnet server to invoke this script on connect: start x 99 ./testscript Your Name Then invoke it: telnet n8emr 99 SYN sent Established Enter Your Name: Gary Hello Gary, Here is what you typed verbatim: 00000 G a r y \n 00005 Close wait Last ACK Closed (Normal) REMOTE LOGINS: One popular addition to this version of net is the remote login capability. You can start a "telunix" server on a selected tcp port to permit incoming sessions to be directed to a pseudo-tty, permitting communications with the host Unix system as if you were talking to a half duplex serial port. Please note that this does not fully implement rlogin that is found on many Unix systems, but is only a first attempt. Also note that we are currently using the standard Unix getty, and therefore any passwords required to establish a login are transmitted over the air in the clear. More secure methods of login are available (in fact ka9q has released the rudiments of one) but have not been integrated into the code at this time. Don't use this for a secure system or secure user login, such as root. Also note that the communications path is, of necessity, half duplex. This is not much of a concern with the Unix shell, but visual editors, such as vi and emacs, cannot be used effectively over this server. You will need to have a pseudo-tty driver installed on your system for the remote login feature to work. The "pty" driver is standard on Berkley systems, and is available for a wide variety of Sys 5 systems. Versions for the Unix-PC and Xenix have been posted to Usenet. A subset of the available pty master/slave pairs should be allocated for gettys. Gettys are attached to the slave end of the pty by inserting an appropriate line in the /etc/inittab file. For instance, if the slave ptys selected for gettys are ttyp0 and ttyp1, the following would be the /etc/inittab entries for the Unix-PC: py0:2:respawn:/etc/getty ttyp0 9600 # TCP login enabled py1:2:off:/etc/getty ttyp1 9600 # TCP login disabled As currently compiled, net expects gettys to exist on /dev/ptyp[012]. Also, Unix must be set up to understand that this is a half duplex session. I automatically execute "stty -echo igncr" from /etc/profile when a login occurs on one of these ptys. To start up the login server you need to specify the following: start telunix This will startup the remote login server on socket number specified, defaulting to 23, the same as the telnet server. Of course, both telnet and telunix cannot exist on the same socket, but they both can be run concurrently. Locally, we run the telnet (chat) server on socket 23, and the telunix server on socket 22, although Brian Kantor indicates that socket 87 should be used for keyboard qsos and 23 for remote logins. To do a remote login type: telnet 22 A typical session is below. net> telnet n8emr 22 Established N8EMR's ham bbs Ham's login as hbbs (9.6kb)n8emr login: USERNAME USERNAME <- note echo of input Password: PASSWORD <- note password appears in clear, but not echoed {typical login message for your system} $ $ uname <- or whatever PC7300 n8emr 3 3.5.1.3 mc68k $ exit Close wait Last ACK Closed (Normal) net> REMOTE ACTIONS: We have implemented the "remote" server under Unix, permitting a few commands to be executed from remote locations. To start up the remote server you need to issue the command: start remote xxxx where xxxx is the socket number to start up the remote service. The default socket number is 1234. Keep in mind that the socket number you select is your only means of security which prevents someone from performing remote operations. In our local group, we have selectively standardized on a socket among the regulars to permit a peer to restart or take down a station which is misbehaving. The most useful remote command is the "reset" command. This command essentially re-executes the net program. It is useful for restarting the program after a glitch, or for loading a new version of net, or restarting after modifying the paramaters in the startup file. Command syntax is: remote xxxx reset where xxxx is the socket number as specified above. The "exit" command can be used to stop a running version of net. This is more drastic than reset, because once stopped it is impossible to do anything over the air to restart net. Again, the command syntax is: remote xxxx exit where xxxx is the socket number. The "nrbc" command is useful if your system had netrom routing enabled. Upon receipt of this command, the remote system will issue a netrom nodes broadcast. NOTE: The nodes broadcast is sent out on all attached netrom frequencys, not just the one where command came in on, and the netrom broadcast timer will be reset. Command syntax is: remote xxxx nrbc where xxxx is the socket number. An excellent time to use the "nrbc" option is when your node has just come up -- ie, insert this into your startup.net file to stimulate your local netrom gateway. The "smtpkick" command is useful if you would like to tell the SMTP client process on another machine to look for new SMTP traffic to forward. It causes the equivalent of "smtp kick" from the command line. Command sequence: remote xxxx smtpkick CROSS-BAND DIGIPEATING: Since net is typically run with the same callsign on each link, we use the following mechanism to indicate a cross-band request: If a NET node is called upon to digipeat a packet, the next entry in the digipeater list is checked to see if it matches one of the interface labels. If not, the packet is digipeated on the interface it came on on, as is done now. However, if the next entry corresponds to a label, the digipeat list is changed by replacing the callsign of the incoming link with its label, and the label which matches the outgoing link with its callsign. For example, suppose I (kd8wk) am on 2-meters and want to digipeat to Gary (n8emr) on 220 Mhz using a configuration of NET (w8zpf) with a link labeled ax0 on my frequency and another labeled ax1 on Garys.. My 2-meter interface is labeled xyz. I would specify the connect thusly: connect xyz n8emr w8zpf ax1 The ax25 header shows kd8wk attempting to connect to n8emr via two digipeaters: The first is "w8zpf", and the second is the pseudonym "ax1". Once w8zpf intercepts the packet, it sees that ax1 matches one of its interfaces, and infers that kd8wk wants to do a cross-band digipeat thru it. It then modifies the digipeater list by replacing the w8zpf with ax0, the interface the request came in on, and replacing ax1 by its call, w8zpf. n8emr receives the packet from kd8wk with the digipeater list "ax0 w8zpf". When n8emr responds, it inverts the list: "n8emr->kd8wk via w8zpf ax0". The process is reversed, producing a 2-meter packet: "n8emr->kd8wk via ax1 w8zpf", which is what we expect to see at kd8wk. The biggest downside to this is that, as a user, you need to know the internal labels for the links of the station being used to cross-band thru. This has not posed a problem in our local environment. Also, I could find no easy way to determine if a link is indeed an ax25 link, so you *can* specify, say, a slip link in the digipeat list. This results in the slip code seeing a bogus packet and bumping some counters. Not useful, but not particularly harmful, either. Interface names of up to five characters are allowed. Longer interface names cannot be digipeated thru ("netrom"). Here is the code. It is not sanctioned by anyone official, and no warrantees are given, but I hope you find it useful. We have. TRACE: The trace command has been enhanced. First, the format of the trace output is slightly different. When tracing, you now get a time and date stamp, along with an indented header for ease in recognizing discrete packets. One annoyance with the way trace works by default is that trace data tends to clutter the screen even if you are in a telnet, ax25, or ftp session. A new option to the trace command will produce trace output only when you are in command mode. When you drop into a session, the trace output is inhibited. The syntax for this option is: trace cmdmode To return to the original "trace at all times" mode, enter: trace allmode OTHER MODS: The SMTP mailer has been modified to return mail it can't route. In the official version, it just prints a message every time the smtp timer fires. Also, mail rejected by a remote is shown as being rejected by the remote. Previously, no indication was given as to who rejected the request. The ip address is now displayed as part of the mailbox banner. This will allow stations that connect to you via netrom or ax.25 to get the information they need to establish a tcp connection. Heavily modified sys5unix.c and sys5_io.c to correct many shortcomings. Opening of asy devices are done with NODELAY option to prevent net from hanging if carrier detect is not asserted. Modified the asy_read routine, a la code proposed by Mark Edwards to buffer the data. Makes net more efficient in a Unix environment, especially on high speed slip link transfers. Fixed several problems I observed with the netrom code. The netrom sessions appear fairly solid with true blue NETROM nodes now. Fixed many bugs, most of which have been reported to Bdale for inclusion in the latest release.