@database telnetd_device.guide @Master telnetd.texinfo @Width 72 This is the AmigaGuideŽ file telnetd_device.guide, produced by Makeinfo-1.55 from the input file telnetd.texinfo. This file documents `telnetd.device', a `serial.device' look-a-like that allows serial applications on the Amiga to accept telnet connections. Copyright (C) 1993 by Christopher A. Wichura. All rights reserved. @Node Main "telnetd_device.guide" `telnetd.device' **************** `telnetd.device' is a `serial.device' look-a-like that allows Amiga serial applications, such as BBS programs, to accept telnet connections. @{" Legal Information " Link "Legal Information"} Various legal matters regarding the use of `telnetd.device'. @{" Supplied Files " Link "Supplied Files"} A description of the files included with in this package. @{" System Requirements " Link "System Requirements"} What must you have in order to use `telnetd.device'? @{" Theory of Operation " Link "Theory of Operation"} Why have a `telnetd.device' and how does it work? @{" Installation Procedures " Link "Installation Procedures"} How to install `telnetd.device' on your system. @{" Implementation Details " Link "Implementation Details"} Technical information on how `telnetd.device' was implemented. @{" Credits " Link "Credits"} The author would like to thank... @{" Contacting the Author " Link "Contacting the Author"} How to contact the author. @{" Concept Index " Link "Concept Index"} Index of important concepts. @EndNode @Node "Legal Information" "telnetd_device.guide/Legal Information" @Next "Supplied Files" @Prev "Main" @Toc "Main" Legal Information ***************** `telnetd.device' is not in the public domain. All source files, along with the resulting executable, are Copyright (C) 1993 by Christopher A. Wichura. You may not sell `telnetd.device'. Only the demo version of `telnetd.device' may be freely redistributed. Registered versions may not be redistributed. If someone is found redistributing a registered version of `telnetd.device', their registration will be revoked and legal action to collect damages will ensue. The demo version of `telnetd.device' may be freely redistributed via BBSs, InterNet/Usenet, and disk libraries such as Fred Fish's, as long as the archive is not modified. Disk magazines and services that charge extra for file transfers may not distribute `telnetd.device'. In using `telnetd.device', you accept the responsibility for any damage or loss of productivity/money that may occur through or during its use. Christopher A. Wichura is not and cannot be held accountable. @{" Registering telnetd.device " Link "Registering telnetd.device"} Information on how to register your own copy of telnetd.device. @EndNode @Node "Registering telnetd.device" "telnetd_device.guide/Registering telnetd.device" @Toc "Legal Information" Registering `telnetd.device' ============================ `telnetd.device' is shareware. The demo version of the device is restricted in several ways (see @{"Creating the configuration file" Link "Creating the configuration file"}). Registering `telnetd.device' will provide you with a personalized version of the device which does not have any of these restrictions. Supporting the author will also help to insure that improvements on the device are made. The most recent information on how to register will always be found in `telnetd.device', itself. To get this information, open the device with a regular terminal program, open a capture file, and then type `ATI1 RET'(1). You can now close the capture file and print out the registration form. ---------- Footnotes ---------- (1) In registered versions of the device, the `ATI1' command displays who the device has been registered to. @EndNode @Node "Supplied Files" "telnetd_device.guide/Supplied Files" @Next "System Requirements" @Prev "Legal Information" @Toc "Main" Supplied Files ************** Included you should find the following files: `telnetd_device.guide' `telnetd_device.guide.info' `AmigaGuide' format documentation for `telnetd.device', including Workbench icon. `telnetd_device.dvi' `DVI' format documentation for `telnetd.device'. Using a suitable `DVI' driver, you can print a hardcopy version of this documentation. `telnetd.AS225.device' `telnetd.device' compiled for use with CBM's AS225 TCP/IP software. This requres AS225 Release 2, which, at the time of this writing, is only available to registered developers. `telnetd.AmiTCP.device' `telnetd.device' compiled for use with the freely redistributable AmiTCP TCP/IP software. This requires version 2 or higher of AmiTCP to operate. `ReleaseNotes' `ReleaseNotes.info' This ASCII file (and it's associated Workbench icon) contains release notes regarding changes from one version of `telnetd.device' to the next. @EndNode @Node "System Requirements" "telnetd_device.guide/System Requirements" @Next "Theory of Operation" @Prev "Supplied Files" @Toc "Main" System Requirements ******************* In order to use `telnetd.device' on your system, you must have: 1. Workbench 2.04 or higher 2. One of the following TCP/IP protocol stacks: 1. AS225 Release 2 This is Commodore's TCP/IP protocol stack. At the time of this writing, Release 2 is only available to developers registered with Commodore. AS225 is the prefered stack to use with `telnetd.device' at this time, however. 2. AmiTCP/IP Version 2 (or higher) This is a freely redistributable TCP/IP protocol stack for the Amiga. 3. Some form of network It would be rather pointless to install `telnetd.device' if one does not have a network connection. No specific hardware is required, though. `telnetd.device' will work equally well over a slip connection or ethernet, for example. @EndNode @Node "Theory of Operation" "telnetd_device.guide/Theory of Operation" @Next "Installation Procedures" @Prev "System Requirements" @Toc "Main" Theory of Operation ******************* @{" Incentive for telnetd.device " Link "Incentive for telnetd.device"} Why is `telnetd.device' needed? @{" The telnet protocol " Link "The telnet protocol"} The network protocol `telnetd.device' supports. @{" How telnetd.device works " Link "How telnetd.device works"} The basic premise `telnetd.device' operates under. @EndNode @Node "Incentive for telnetd.device" "telnetd_device.guide/Incentive for telnetd.device" @Next "The telnet protocol" @Toc "Theory of Operation" Incentive for `telnetd.device' ============================== Networking is becoming more and more popular on the Amiga. Thus, people are now looking for ways to make their Amigas more accessable to others on a network. One common desire expressed many times on Usenet is for a way to allow people on the net to connect into their bulletin board system (BBS), for example. Unfortunately, most BBS software is written to talk only to modems and generally lacks support for network protocols. `telnetd.device' was written to allow people to connect into an Amiga running a serial-aware application from the net. @EndNode @Node "The telnet protocol" "telnetd_device.guide/The telnet protocol" @Next "How telnetd.device works" @Prev "Incentive for telnetd.device" @Toc "Theory of Operation" The `telnet' protocol ===================== In the world of TCP/IP, there are two main protocols widely used to log into other machines on a network. These are `rlogin' and `telnet'. Most platforms with a TCP/IP stack support these protocols. `telnetd.device' was written to accept `telnet' connections from other machines in a way such that software that only understands modems can be accessed from the net. @EndNode @Node "How telnetd.device works" "telnetd_device.guide/How telnetd.device works" @Prev "The telnet protocol" @Toc "Theory of Operation" How `telnetd.device' works ========================== `telnetd.device' is written to look like the standard Amiga `serial.device'. `serial.device' is the driver which serial applications use to actually talk to the serial hardware. It provides a high level abstraction from the hardware, simplifying the application's job of handling serial data. Because of this abstraction, it is possible to write `serial.device' look-a-likes that talk to something other than the Amiga's build in serial hardware. Expansion serial boards for the Amiga, such as Commodore's A2232 multi-port io board or GVP's ioExternder board, are examples of the use of `serial.device' clones to talk to expansion serial hardware. By looking like `serial.device', `telnetd.device' can be used by serial applications. However, looking like `serial.device' is not enough. Most BBS programs, for example, assume that they are talking to a modem, and look for certain messages generated by modems to indicate a call coming in, etc. Thus, `telnetd.device' also emulates a Hayes compatible modem to a limited degree. In conclusion, by telling serial applications (such as BBSs) to use `telnetd.device' instead of `serial.device', it is possible for the application to receive `telnet' connections. @EndNode @Node "Installation Procedures" "telnetd_device.guide/Installation Procedures" @Next "Implementation Details" @Prev "Theory of Operation" @Toc "Main" Installation Procedures *********************** @{" Installing the device " Link "Installing the device"} How to install the device properly. @{" Creating the configuration file " Link "Creating the configuration file"} Creating the configuration file `telnetd.device' needs. @{" Testing the installation " Link "Testing the installation"} How to make sure the device has been properly installed. @EndNode @Node "Installing the device" "telnetd_device.guide/Installing the device" @Next "Creating the configuration file" @Toc "Installation Procedures" Installing the device ===================== There are two different versions of the `telnetd.device' load module. One has been compiled for use with AS225r2, and is named `telnetd.AS225.device'. The other, compiled for AmiTCP, is named `telnetd.AmiTCP.device'. When installing the proper device for your stack, you must rename the load module to `telnetd.device'. Thus, to install the AS225 version, from a shell you would enter: `copy `telnetd.AS225.device' to `devs:telnetd.device'' The equivalent command for the AmiTCP version would be: `copy `telnetd.AmiTCP.device' to `devs:telnetd.device'' @EndNode @Node "Creating the configuration file" "telnetd_device.guide/Creating the configuration file" @Next "Testing the installation" @Prev "Installing the device" @Toc "Installation Procedures" Creating the configuration file =============================== Before using `telnetd.device', you must create a configuration file that lets `telnetd.device' know what TCP/IP ports to service, etc. For the AS225 version of `telnetd.device', this configuration file is called `inet:db/telnetd_device.conf'. For the AmiTCP version, the name is `AmiTCP:db/telnetd_device.conf'. In either case, the format of the configuration file is the same. Each line of the configuration file describes one TCP/IP port that `telnetd.device' should monitor. Configuration entries have the template (a description of the fields in this template as well as sample configuration entries follows this section): PORT UNITS [`PACERATE' BPS] ACCESSLIST [`BLACKLIST' LIST] Blank lines may be included in the configuration file. Everything that follows a `;' will be treated as a comment. The `;' can occur anywhere on the line. *Demo Version Note:* The demo version of `telnetd.device' does not look for or read the configuration file. It is hard coded to two units on port 5432 and a pace rate of 9600 baud. The demo version also only allows connections from your local network. @{" TCP-IP Port Number " Link "TCP-IP Port Number"} Selecting the port number to accept connections on. @{" Units per TCP-IP Port " Link "Units per TCP-IP Port"} How many units will be available for the selected port. @{" Pace Rate " Link "Pace Rate"} Pacing the flow of data output to the client. @{" Restricting Access " Link "Restricting Access"} Restricting access to certain sites or nets as well as blacklisting sites and nets. @{" Sample Configuration Entries " Link "Sample Configuration Entries"} A few sample configuration entries. @EndNode @Node "TCP-IP Port Number" "telnetd_device.guide/TCP-IP Port Number" @Next "Units per TCP-IP Port" @Toc "Creating the configuration file" The TCP/IP port number ---------------------- There are many different services available over a network. To make it possible for services to be used in a sane manner, the concept of ports was added to the TCP/IP protocol. Different services use different port numbers. The `telnet' protocol normally uses port 23. However, this is not a requirement. Thus, `telnetd.device' allows you to specify the port number that it should accept connections on. By watching multiple port numbers, it is possible to have different serial applications available on the same machine. Specify a port number as an integer value. For example, use `23' if you want `telnetd.device' to accept connections on the normal `telnet' port. When using other ports, you should choose a port number greater than 5000 (the reasoning behind this is beyond the scope of this document, and has to do with the way TCP/IP port allocation was designed to be used). *Please note:* You may not specify more than one configuration entry with the same port number. @EndNode @Node "Units per TCP-IP Port" "telnetd_device.guide/Units per TCP-IP Port" @Next "Pace Rate" @Prev "TCP-IP Port Number" @Toc "Creating the configuration file" Units per TCP/IP port --------------------- Unlike a modem, which can only accept one connection at a time, TCP/IP ports can have many connections open on the same port number. This is what allows you to have multiple `telnet' connections to the same Unix machine, for example. BBS software(1), being written for modems, doesn't know how to handle this. To get around this, `telnetd.device' lets you specify the number of units to allocate for a particular port number. You can then run multiple copies of the BBS software, specifying different unit numbers of `telnetd.device' as the device to use. Like port numbers (see @{"TCP-IP Port Number" Link "TCP-IP Port Number"}), the number of units is specified as an integer value. If you wanted five units available, for example, `5' would be specified. These five units would then be available as units 0 through 4 when opening `telnetd.device'. As indicated above, `telnetd.device' maps the first port's units starting with the device's unit 0. If more than one configuration entry is specified in the configuration file, subsequent TCP/IP ports will have their units mapped such that they follow the preceeding port's units. I.e., if your first port has 5 units allocated to it and the second port has 3 units, then the first port's units would be accessed as `telnetd.device' units 0 through 4 and the second port's units would be accessed as `telnetd.device' units 5 through 7. If a third port was specified, it's first unit would be accessed as `telnetd.device' unit 8. ---------- Footnotes ---------- (1) While this document refers to BBS software, the discussion applies to any serial application one wishes to run on top of `telnetd.device' @EndNode @Node "Pace Rate" "telnetd_device.guide/Pace Rate" @Next "Restricting Access" @Prev "Units per TCP-IP Port" @Toc "Creating the configuration file" Pacing outgoing data flow ------------------------- The TCP/IP protocol will try to deliver data from one point to another as quickly as it can. Usually this is the desired behavior, and does not cause any problems, even over slow network links, because the protocol also implements a form of flow control. However, there may be cases where it is desirable to limit the flow of data. For example, many people reading large text files at breakneck speed could bog the system down. Since people generally can't read text scrolling by at incredible speeds, pacing the output may 1) make it easier for the reader to read data and 2) reduce system load. `telnetd.device' provides a way to pace data output to the client on a per-port number basis (incoming data from the client is not paced). Thus, one might provide a few units on port 23 (the standard `telnet' port) with no pace rate, while making another port available that paces data at slower rates for those who want it. To specify a pace rate, in your configuration entry you must include the keyword `PACERATE' followed by the baud rate your want data paced at. If no `PACERATE' keyword is specified then no pacing will occur. If the baud rate specified is 0 then pace will occur at the baud rate reported by the `telnet' client. Since not all clients support informing the daemon of the user's connect speed(1), `telnetd.device' also lets you manually specify a pace rate. Thus, entering a pace rate of `19200' would pace at 19200 baud, regardless of the speed reported by the client. *Please note:* `telnetd.device' does not pace between characters. Instead, within each second, `telnetd.device' will allow no more than the appropriate number of characters to be transmitted. Thus, pacing will appear as quick blasts of data at the beginning of each second, followed by dead time. ---------- Footnotes ---------- (1) When a client does not know how to tell `telnetd.device' what the connection speed is, `telnetd.device' uses 19200 by default. @EndNode @Node "Restricting Access" "telnetd_device.guide/Restricting Access" @Next "Sample Configuration Entries" @Prev "Pace Rate" @Toc "Creating the configuration file" Restricting access ------------------ Security issues are becoming increasingly more important as more and more information is made available via networking. Because of this, many institutions may wish to limit access to certain networks or even specific hosts. There are also those who abuse their network privledges, thus creating the need for an ability to blacklist specific machines or even entire networks. `telnetd.device' supports limiting access on a per-port basis. `telnetd.device' first verifies that a site belongs to one of the networks or machines allowed. If the machine network the client is connecting from is ok, `telnetd.device' then check the blacklist (if specified) to see if the particular machine (or even the entire network it belongs to) should be rejected. @{" Access List " Link "Access List"} Specifying networks or sites which are allowed to connect. @{" Blacklist " Link "Blacklist"} Specifying networks or sites which are to be blacklisted. @EndNode @Node "Access List" "telnetd_device.guide/Access List" @Next "Blacklist" @Toc "Restricting Access" The Access List ............... At least one access entry must be specified in a configuration entry. Access entries are specified in IP form only. If you wish to allow any site to connect, specify an access of `255.255.255.255'. To limit access to a specific network, specify the network's IP. For example, if your network is 128.135, you would specify `128.135'. At this time, subnets are not supported, and attempting to specify one will cause access attempts to fail (except from the machine with address 0 within the subnet you tried to specify). If you wish to allow access from specific machines, then specify the full IP address for the machine(s) desired. @EndNode @Node "Blacklist" "telnetd_device.guide/Blacklist" @Prev "Access List" @Toc "Restricting Access" Blacklisting specific machines or networks .......................................... Blacklist entries are not required. If you wish to specify a blacklist entry, however, you must include the `BLACKLIST' keyword in the configuration entry. *Caution:* The *only* thing that may follow the `BLACKLIST' keyword in the configuration entry is actual blacklist entries. Anything else will cause a parse error. Blacklist entries are specified in the same format that access entries (see @{"Access List" Link "Access List"}) are specified. @EndNode @Node "Sample Configuration Entries" "telnetd_device.guide/Sample Configuration Entries" @Prev "Restricting Access" @Toc "Creating the configuration file" Sample configuration entries ---------------------------- The most simple configuration entry might look something like `23 5 255.255.255.255'. This would allocate five units for use on port number 23. Since 255.255.255.255 is specified as the access list, connections would be accepted from any machine on any network. Working with the above example, suppose someone was harassing you, connecting from a machine with an IP address of 200.199.198.1. To prevent this person from harassing you, you could add a blacklist entry for this machine, making the configuration entry become `23 5 255.255.255.255 blacklist 200.199.198.1'. If the person harassing you has access on other machines on the net his machine belongs to, and starts connecting in from a different machine, you could blacklist the entire net by changing the configuration entry to be `23 5 255.255.255.255 blacklist 200.199.198'. Now suppose you want to make a second serial application available on the net. For whatever reason, you don't want the general public to be able to connect to this application. You could add a second configuration entry that would open units on a second port number, with access restricted to your local net (198.147.221 will be used as the local net in this example). Your configuration file might be changed to look something like this: `23 5 255.255.255.255 ; allow anyone to connect on the normal `telnet' port' `6543 2 198.147.221' A configuration file such as this would allow anyone to connect on the normal `telnet' port, for which there are five units available. These units are accessed as units 0 through 4 of `telnetd.device'. People whose machines are on the net 198.147.221 would also be able to connect to port 6543, which only has two units available. These two units would be accessed as units 5 and 6 of `telnetd.device'. @EndNode @Node "Testing the installation" "telnetd_device.guide/Testing the installation" @Prev "Creating the configuration file" @Toc "Installation Procedures" Testing the Installation ======================== Once you have installed `telnetd.device' and created a configuration file, you will probably want to make sure that the device is working properly. This is most easily done by opening the device with a terminal program. If all goes well, you should be able to enter Hayes style AT commands and have the device respond back as if it was a modem. For example, `AT$ RET' can be used to get a list of the AT commands that `telnetd.device' understands. If you are able to enter AT commands properly, you should now try `telnet'ing into the port number you specified in the configuration file. You should see `RING' messages in your terminal window. Entering `ATA RET' should cause `telnetd.device' to `answer' the connection. You can then hang the connection up by dropping DTR. If there is a problem with the configuration file, an error requester will appear telling you which line has a syntax error. Other error requesters may occur, but are much less likely. For example, if `telnetd.device' complains that it "Couldn't bind name to initial socket", then there is probably already something else (i.e., some other daemon) listing on the port number you specified. Once you have determined that `telnetd.device' is properly installed, you can set up your BBS (or whatever) software. Since `telnetd.device' does not emulate the NVRAM most modern modems have, you must specify all needed parameters in an init string that your software will send out each time it opens the unit. For example, `telnetd.device' defaults to not `auto-answering' a connection. If your software expects the modem to do `auto-answer', you will have to specify an init string such as `ATS0=1'. @EndNode @Node "Implementation Details" "telnetd_device.guide/Implementation Details" @Next "Credits" @Prev "Installation Procedures" @Toc "Main" Implementation Details ********************** *Please note:* This section contains technical information about how various aspects of `telnetd.device' were implemented. Information in this section is not needed to install or use `telnetd.device'. This section is provided mainly for those who may be writing a serial application and wish to know how `telnetd.device' differs from `serial.device' at the device level. @{" AT Commands " Link "AT Commands"} Information about the Hayes AT commands `telnetd.device' supports. @{" Processes Used " Link "Processes Used"} Information about how the supervisor and unit processes interact. @{" IO Requests " Link "IO Requests"} Information about the `serial.device' IO requests supported. @EndNode @Node "AT Commands" "telnetd_device.guide/AT Commands" @Next "Processes Used" @Toc "Implementation Details" The Hayes AT Commands supported =============================== `telnetd.device' supports a relatively small number of the standard AT commands defined by Hayes. A list of the AT commands `telnetd.device' knows is available by entering `AT$ RET' from a terminal program. Most commands supported are directly related to the needs of an application that wishes to act in answer mode only. For example, S Register 0 is used to determine if the device should `auto-answer' the connection or not. Commands not recognized by the device, or which syntactically incorrect, will generate an `ERROR' message. The device supports a form of "caller id". The information returned includes the machine the connection was initiated from and the time of the connection. The IP address of the machine is always supplied. If the hostname can be determined, it will also be returned. Otherwise, the hostname will be reported as "???". Two forms of the "caller id" output are available. The verbose form generates output suitable for humans to read. The terse form is intended to be machine readable, and is output as: SECONDS MINUTE HOUR DAY MONTH YEAR DAY-OF-WEEK IP-ADDRESS HOST-NAME *Caution:* The "caller id" information does not supply you with the login account of the client. Since it is possible for many different accounts on the same machine to telnet in, using the "caller id" information to do any form of automatic login would be a huge security hole. Be careful when deciding what you wish to use the "caller id" information for. `telnetd.device' does not emulate the NVRAM most moderm modems have. Thus, any options you require must be specified in an init string whenever a unit is opened. `telnetd.device' does *not* support the "`+++'" escape sequence for returning to command mode. Thus, in order to drop a connection, one must do a DTR drop. This can be accomplished by closing and re-opening the device, or by using the ASDG extension IO Request `SIOCMD_SETCTRLLINES'. @EndNode @Node "Processes Used" "telnetd_device.guide/Processes Used" @Next "IO Requests" @Prev "AT Commands" @Toc "Implementation Details" Processes Used ============== When `telnetd.device' is opened for the first time, it reads in the configuration file and starts a supervisor process for each TCP/IP port that is to be monitored. Each unit that is opened also has a process associated with it. When a connection comes in on a port, the supervisor for that port first checks for any access violations. If the site is note allowed for some reason, an access restriction message will be sent to the client and the connection will be closed. Otherwise, it will look for a unit which is 1) opened and 2) not servicing a connection. If it doesn't find a free unit, it sends a message to the client indicating that there are no free units and closes the connection. If there is a free unit, the supervisor hands the connection off to the unit's process. At this time, the supervisor no longer touches the connection, except in the case that the unit experiences a fatal problem trying to initialize the connection. If this happens, the supervisor will send a message to the client that a fatal error has occurred and the connection will be closed. When the unit process receives a connection from its supervisor, it first trys to negotiate several `telnet' options with the client. These include asking the client to operate in character-at-a-time mode (rather than line-by-line mode), asking the client what the actual connection speed is, etc. Once these `telnet' options have been negotiated, the unit will start generating `RING' messages. At this time, the client will receive a message that the device is waiting for the unit to answer. Depending on the setting of S Register 0, `telnetd.device' will either wait for the application to issue an `ATA' command or will `auto-answer' the connection. Once the unit has answered the ring (either by `ATA' or by `auto-answer'), the device will respond with a `CONNECT BAUD' message. The client will also receive a message indicating which unit the connection has been answered by. The baud rate reported to the application in the `CONNECT' message is the speed reported by the client. If the client does not support the `TELOPT_TSPEED' negotation (and many don't), the device reports the speed as 19200 baud. @EndNode @Node "IO Requests" "telnetd_device.guide/IO Requests" @Prev "Processes Used" @Toc "Implementation Details" IO Requests Supported ===================== `telnetd.device' understands all the standard `serial.device' IO Requests. It also knows about ASDG's `SIOCMD_SETCTRLLINES' extension that allows the DTR line to be controlled without having to close the device and re-open it. `SDCMD_SETPARAMS' is treated mainly as a no-op. All settings are ignored. This includes baud rate, SERF_XDISABLED, etc. SERF_EOFMODE *is* honored, however. The buffer size can not be changed; it is fixed at 16k. `SDCMD_SENDBREAK' sends a `telnet' `BREAK' sequence over the wire. Some clients may panic if they receive this signal. `telnetd.device', when it sees a `telnet' `BREAK', `AO', or `IP' will flag that a break has been received. If there is a read request pending, it will be returned with IO_ERROR set to `SerErr_DetectedBreak'. Otherwise, the `IO_STATF_READBREAK' bit in IO_STATUS will be set `TRUE' when a `SDCMD_QUERY' is performed. `CMD_RESET' will not cause the current connection to be dropped. @EndNode @Node "Credits" "telnetd_device.guide/Credits" @Next "Contacting the Author" @Prev "Implementation Details" @Toc "Main" Credits ******* Brian Vargyas for getting me started on writing `telnetd.device' and for providing the extra machine used in testing, as well as beta testing the device with the C-Net BBS software. William Coldwell for beta testing the device with the BBX BBS software and for providing a few comments on the operation of the device itself. @EndNode @Node "Contacting the Author" "telnetd_device.guide/Contacting the Author" @Next "Concept Index" @Prev "Credits" @Toc "Main" Contacting the Author ********************* If you happen to find a bug, want to register, or have a suggestion for `telnetd.device', or even just want to say "hey, cool program", please contact me using one of the ways listed below (registrations are limited to US Mail, obviously, since you can't e-mail money). Even if you want to say "`telnetd.device' sucks", let me know and be sure to say why you feel this way so that I might be able to fix what you think is wrong with the program. These electronic forms are the most prefered means of contacting me. They will get you a response pretty quick. `e-mail: caw@miroc.chi.il.us' `BIX: caw' My US Mail address is: Christopher A. Wichura 5450 East View Park Chicago, Il. 60615 USA You can also reach me by phone. However, please try to limit your calling to evening hours (I'm in the central time zone). If I'm not home and you leave a message, call back again anyway. Around here, one tends to get maybe 5% of the messages left for them, if lucky... (312)/684-2941 @EndNode @Node "Concept Index" "telnetd_device.guide/Concept Index" @Prev "Contacting the Author" @Toc "Main" Concept Index ************* @Index "Concept Index" @{" serial.device " Link "How telnetd.device works"} How telnetd.device works @{" Access entries " Link "Access List"} Access List @{" Access list " Link "Access List"} Access List @{" Access restrictions " Link "Restricting Access"} Restricting Access @{" AT Commands supported " Link "AT Commands"} AT Commands @{" Author Information " Link "Contacting the Author"} Contacting the Author @{" Blacklist entries " Link "Blacklist"} Blacklist @{" Blacklisting sites " Link "Blacklist"} Blacklist @{" Configuration file " Link "Creating the configuration file"} Creating the configuration file @{" Configuration file samples " Link "Sample Configuration Entries"} Sample Configuration Entries @{" Configuring the TCP/IP port number " Link "TCP-IP Port Number"} TCP-IP Port Number @{" Contacting the Author " Link "Contacting the Author"} Contacting the Author @{" Creating the configuration file " Link "Creating the configuration file"} Creating the configuration file @{" Credits " Link "Credits"} Credits @{" Device installation " Link "Installing the device"} Installing the device @{" Distribution Files " Link "Supplied Files"} Supplied Files @{" E-Mailing the Author " Link "Contacting the Author"} Contacting the Author @{" Files Supplied " Link "Supplied Files"} Supplied Files @{" Hayes AT Commands supported " Link "AT Commands"} AT Commands @{" How telnetd.device works " Link "How telnetd.device works"} How telnetd.device works @{" Implementation Details " Link "Implementation Details"} Implementation Details @{" Incentive for telnetd.device " Link "Incentive for telnetd.device"} Incentive for telnetd.device @{" Installation Procedures " Link "Installation Procedures"} Installation Procedures @{" Installing the device " Link "Installing the device"} Installing the device @{" IO Requests Supported " Link "IO Requests"} IO Requests @{" Legal Information " Link "Legal Information"} Legal Information @{" Mailing the Author " Link "Contacting the Author"} Contacting the Author @{" Number of units " Link "Units per TCP-IP Port"} Units per TCP-IP Port @{" Pace Rate " Link "Pace Rate"} Pace Rate @{" Pacing outgoing data flow " Link "Pace Rate"} Pace Rate @{" Port numbers " Link "TCP-IP Port Number"} TCP-IP Port Number @{" Processes Used " Link "Processes Used"} Processes Used @{" Purpose of telnetd.device " Link "Theory of Operation"} Theory of Operation @{" Registering telnetd.device " Link "Registering telnetd.device"} Registering telnetd.device @{" Restricting access " Link "Restricting Access"} Restricting Access @{" Sample configuration entries " Link "Sample Configuration Entries"} Sample Configuration Entries @{" Shareware benifits " Link "Registering telnetd.device"} Registering telnetd.device @{" Supplied Files " Link "Supplied Files"} Supplied Files @{" System Requirements " Link "System Requirements"} System Requirements @{" TCP/IP port numbers " Link "TCP-IP Port Number"} TCP-IP Port Number @{" Testing the installation " Link "Testing the installation"} Testing the installation @{" Theory of Operation " Link "Theory of Operation"} Theory of Operation @{" Units per TCP/IP port " Link "Units per TCP-IP Port"} Units per TCP-IP Port @EndNode