|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: T U
Length: 38104 (0x94d8)
Types: TextFile
Notes: Uncompressed file
└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
└─⟦df3d31044⟧ »EurOpenD3/network/modems/telebit/UNIX.setup.Z«
└─⟦this⟧
========================================================================================
Telebit Corporation Revision 1.02 01 APRIL 1990
========================================================================================
TELEBIT MODEM CONFIGURATION
FOR
UNIX DIAL-UP, UUCP, TCP/SLIP, AND POINT-TO-POINT PROTOCOL
ENVIRONMENTS
Written by C. E. Castillo, UNIX Communications Specialist, TELEBIT Corporation
This document is meant to simplify configuration of Telebit modems for use in UNIX
dial-up and UUCP applications on a wide variety of systems. The configuration hints and
examples presented in this document are meant to supplement the system specific
configuration guides available from TELEBIT, as well as the TELEBIT modem reference
manuals.
Note that there are currently several configuration guides for specific systems. These
configuration guides are available from TELEBIT and UUNET Communications Services
via the U.S. Internet. The following networks and systems contain these documents as
well:
INTERNET: UUNET.UU.NET [192.48.96.2]
EUNET: MCSUN.EU.NET [192.16.202.1]
JUNET: FTP.CS.TITECH.AC.JP [131.112.16.39]
ACSNET: DITMELA.CNG.DIT.CSIRO.AU [128.250.1.81]
Internationally, on the European network, EUnet; on the Japanese network, JUnet; and in
Australia via ACSnet. A listing of the archive is available by requesting the SETUPS.list
or PRODUCTS.list files from TELEBIT and most of these systems via "anonymous" UUCP
or FTP. Documentation on warranty, upgrades, Data Communications protocols, and a
technical overview of TELEBIT product technology are also available.
UUNET Communications Services makes these documents available via "anonymous"
UUCP at 1-900-GOT-SRCS in the U.S.. This services is always available and carries a
caller charge of $ .40 US per minute.
UNIX DIAL-UP
The first step in configuring a TELEBIT modem for use in either a UNIX dial-up or UUCP
application is to connect to the modem through the system hardware and operating
system. It is not enough to use a dumb terminal to configure the modem and then attach it
to the system. While this may be the easiest method of configuration and integration of
the modem, it does not provide for future maintenance and/or systems administrations
capabilities. It is highly recommended that the operating system be used to access the
modem through the systems hardware.
Once this is accomplished, a login process (getty) can be established on the modem port
to allow for dial-up interactive or UUCP usage.
\f
1. THE HARDWARE
TELEBIT modems use a DB25 (female), RS-232C interface. A modem cable comprised of
two DB25 (one male and one male/female) connectors and 25 conductors end-to-end is
usually required. Some systems may have a DB9 connector on the serial I/O port with
which a modem cable comprised of one DB25 (male) and one DB9 (male/female) must
be used. These cables are available (pre-assembled) in most computer supply and
electronic parts stores or are supplied with the system. DB9-to-DB25 cables are a
standard cable that is also readily available. Although a cable with conductors connecting
the DB25/DB9 pins end-to-end is highly recommended, it may not always be possible.
In pre-wired office or lab environments, a 25-conductor wire may not be available.
In cases such as these, the modem cable may be modified to contain only the necessary
conductors for modem use. The following table contains RS-232C signals and their
corresponding DB25/DB9 pin assignments:
RS-232C DB25 DB9
===================================
TD 2 3
RD 3 2
RTS 4 7
CTS 5 8
DSR 6 6
GND 7 5
DCD 8 1
DTR 20 4
In some cases, the modem cable may be reduced to a minimum of four conductors. Full
modem control necessitates the use of at least eight conductors. If XON/XOFF flow control
is enabled in the modem, the RTS/CTS signal leads may not be necessary, thus the
conductors and corresponding pins may be removed. If the system does not require
status signals from the modem, the DSR and DCD signal leads may not be necessary, thus
the conductors and corresponding pins may be removed. Some systems may require
cable modifications in order to provide special RS-232C signaling needed by the
operating system. In such cases, the RS-232C signals between the modem and the
systems serial I/O ports may require re-routing. If this is necessary, your system
reference manuals or systems administrations manual may provide the correct modem
cable configuration for your system. The TELEBIT modem reference manuals also
contain common and custom wiring diagrams. An RS-232C break-out box may also be
used to arrive at the final cable configuration.
2. USING THE OPERATING SYSTEM TO CONNECT TO THE MODEM
Once the proper cable has been used to connect your TELEBIT modem and system, the
operating system must be set-up to connect to the modem via the system hardware. The
"tip" and/or "cu" commands are available in most UNIX systems to accomplish this.
The KERMIT share software from Columbia University is also highly recommended,
when available, in order to by-pass problems caused by system configuration files.
KERMIT does not require the same operating system device description files that "tip"
and/or "cu" are dependent upon. KERMIT's ability to attempt the use of the targeted
modem port may result in the most immediate use of the modem. Error messages
generated by the KERMIT software may also allow for better diagnosis of operating
system or hardware problems related to the host systems inability to operate at high
baud rates or possible cable configuration problems.
\f
NOTE: Not all systems may be capable of using serial I/O port speeds
at or above 9600 bps. Some systems may require operating
system or hardware modifications. Please refer to you systems
manual or manufacturer for assistance if this is so. It is highly
recommended that TELEBIT modems be connected to the serial I/O
ports of the system cpu. Use of serial I/O multiplexors may limit
modem speed to 9600 bps or lower due to flow control, cpu/bus
interrupt, or memory buffering problems.
USING TIP
In systems where the "tip" command is available for connecting to serial I/O ports, the
following entries to the /etc/remote file may be used as guidelines (all characters are
literal, i.e. the ^ is 'shift 6' on most keyboards):
tb9600:dv=/dev/TTTT:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:
tb19200:dv=/dev/TTTT:br#19200:el=^C^S^Q^U^D:ie=%$:oe=^D:
The following /etc/remote may be used for autodialing:
Note: Register X0 should be set when using this feature.
TELEBIT|Autodial TELEBIT:\
:el=^D^U^C^S^Q^O@:du:at=hayes:ie=#$%:oe=^D:br#SSSSS:\
:pn=NNNNNNN:dv=/dev/TTTT:
Where: TTTT = serial I/O port (tty)
SSSSS = baud rate [9600/19200]
NNNNNNN = phone number
A direct connection to the modem or autodial is achieved by issuing the following
command:
tip tb9600 or tip hostname
NOTE: Some systems may require an entry in L-devices (or Devices) that corresponds
to the serial I/O port used in the /etc/remote entry. Please see the following
section on entry guidelines for this file.
USING CU
In systems using the "cu" command to access the serial I/O ports, the/usr/lib/uucp/L-
devices (or /usr/lib/uucp/Devices) contain the required serial I/O port definitions
needed to access a direct connection. The following examples may be used as entry
guidelines for these files:
DIR tty000 0 9600
or
Direct tty000 - 9600 direct
\f
A direct connection to the modem is achieved by issuing the following command:
cu -s 9600 -l /dev/tty000
or
cu -s 9600 -l /dev/tty000 dir
If the modem can not be accessed through the operating system, there may be a cable or
serial I/O port problem or operating system problem. Be sure to check for processes
occupying the targeted serial I/O port or lock files (see section 4 on HDB UUCP). A good
test of the serial I/O port-to-modem connection is to list the contents of an ASCII file and
re-direct the output to the modem port. Create an ASCII text file comprised of
alphanumeric characters (no special characters or metacharacters). This file should
be be about fifty lines in length. Place the modem where the TD and RD lights on the
front panel are visible to you as you type. While monitoring the TD and RD lights on the
modem, execute the following command:
cat ascii.file > /dev/tty &
If the TD and RD lights do not register the data passing through the modem, it is possible
that the wrong serial I/O port name is being used, the port permissions may be set
wrong, a LCK..tty000 may exist in /usr/spool/locks or /usr/spool/uucp, a serial I/O
port problem may be present, or a cable problem may exist. The DTR light should also
be lit as data passes through the modem. Note any error messages printed to the console
for possible clues as to the problem and for use when referencing the problem to a UNIX
Technical Support group. The "&" places the processing of this command in the
background. Should this command hang or lock-up, a "kill -9 proc_num" may be done to
cancel the command.
3. MODEM CONFIGURATION
Contrary to popular belief, there are only 70 to 75 configurable S-registers in a
TELEBIT modem. Only a dozen of these registers are required to configure the modem for
use in a UNIX dial-up or UUCP environment. TELEBIT modems are most easily
understood when they are divided into two parts. One half of the modem being the RS-
232C serial I/O port interface and the other half, the RJ11/RJ45 PSTN (phone line)
interface.
\f
THE SERIAL I/O PORT RS-232C INTERFACE
The following table lists registers which define the RS-232C serial I/O port interface:
S-REGISTER DESCRIPTION
=================================================================
S48 Eight Bit Comparison
S51 Interface Speed
S52 DTR Interpretation
S53 * DCD & DSR Interpretation
S54 Break Signal Interpretation
S55 Escape Char./Seq. Interpretation
S56 XON Character
S57 XOFF Character
S58 Flow Control used by DTE
S64 Dial/Answer Sequence Abort
S65 XON/XOFF Failsafe
S66 Lock Interface Speed
S67 CTS Interpretation
S68 Flow Control used by DCE
S69 XON Signal Handling
S130 * DSR Interpretation
S131 * DCD Interpretation
S150 Asynchronous/Synchronous Mode Selection
* = New releases of modem firmware are made to be backwards compatible with
previous releases. If an "S" register is missing, the feature has either been removed or
the old register number maps to a new one(s). An "ERROR" message should not result
from using re-mapped registers.
THE RJ11/RJ45 PSTN (PHONE LINE) INTERFACE
The following table lists registers which define the RJ11/RJ45 PSTN interface:
S-REGISTER DESCRIPTION
=================================================================
S0 Answer On Ring Number
S7 Wait For Carrier Time
S9 Carrier Detect Time (slow mode)
S10 Carrier Loss To Detect Time (slow mode)
S41 Inactivity Timer
S50 Transmission Mode (PEP/V.32/V.22bis/...)
S90 CCITT/BELL Mode Select (bell212a/V.22)
S91 Guard Tone Selection (V.22 only)
S92 Answer Sequence Selection (PEP/9600/...)
S94 Transmission Speed Negotiation (fallback)
S95 MNP Operating Mode (MNP4 or 5)
S96 MNP Data Compression Enable (MNP5)
S110 PEP Mode Data Compression Enable (Lempel-Ziv)
S121 Echo Suppression Compensation
\f
MODEM TO SYSTEM INTERFACE
The remainding registers are used to set the dialog and enable features to be used between
the modem and system:
S-REGISTER DESCRIPTION
=====================================================================
En Echo ON/OFF
Mn Speaker ON/OFF
Qn Quiet Enable
Vn Verbose ON/OFF
Xn Result Code Basic/Extended
S45 Remote Access Enable
S61 Speaker Volume
S100 Reverse Answer/Originate Mode
S101 Continuous Answer/Originate (leased line)
S104 Automatic Dialing Options
S105 T/D (talk/data) Switch Enable
S111 Asynchronous Protocols Support
S112 Kermit Mark Character
\f
EXPLANATION OF TYPICAL REGISTER SETTINGS:
Please use the chart below to select the most appropriate options for your UNIX
environment and application.
RESPONSE FLAGS
==========================================================================================
Q6 For Dial-in -- modem result codes may cause a getty battle.
X1 In HDB, it doesn't matter. In BSD, X0 is set in L.sys and /etc/remote.
S-REGISTERS
==========================================================================================
S45 "security" demands 0, debugging demands 255.
S50 Most cases set S50=0. If the other modem has S92=1, set your modem to
have S50=255 to send only PEP tones.
S51 For autobauding, use either S51=255 or 254 and an -- A-pause-A-
pause-A-pause . . . works every time. 255 presents data at
9600 bps for inbound calls. 254 presents data at 19200 bps for inbound
calls. It is best to use a "hard set" baud rate (ie S51=5).
S52 Recommend value of 2 (reset modem when DTR drops)
S53 Recommend value of 3 (System V HDB systems may need 1 or 4). This
register maps to S130/S131 when not listed in modem.
S54 Recommend value of 3 (see modem reference manual)
S58 Sets flow control. S58=2 (RTS/CTS) is recommended, when possible.
S68=255 should also be set. S68=3 may be used whenever S58=0 for
flow control during interactive use.
S61 Volume of speaker. If it's an office environment, try a value of 45. If
machine room, try 200.
S66 S66=1 locks the interface speed and uses flow control for non-PEP
modems. Hard setting the interface speed to 9600 or 19200 with
S66=1 is highly recommended.
S92 If low speed modems are also dialing in, set S92=1. Incoming PEP modem
should have S50=255 set.
S110 If you are sending/receiving text, set S110=1 to enable data compression.
Otherwise, if sending news or binary files that are uncompressible (or
pre-compressed), leave compression off by setting S110=0.
S111 Use S111=30 or 255. At least one modem must have 30 for UUCP
protocol support.
\f
CONFIGURATIONS FOR BSD4.2, BSD4.3, AND SYSTEM V UNIX SYSTEMS
Below is a chart of the factory settings, along with typical BSD and SYSTEM V settings.
Registers not shown are to be left at the factory settings:
REG FACT BSD4.2 BSD4.3 HDB DESCRIPTION
==========================================================================================
Ex E1 E0 E0 E0 Echo ON/OFF
Mx M1 M1 M1 M1 Speaker ON/OFF
Qx Q0 Q4 Q4 Q6 Quiet Enable
Vx V1 V1 V1 V1 Verbose ON/OFF
Xx X1 X1 X0 X3 Result Code Basic/Extended
S45 000 255 255 255 Remote Access Enable
S50 000 000 000 000 Transmission Mode
S51 255 005 005 005 Interface Speed
S52 000 002 002 002 DTR Interpretation
S53 000 001 003 000 DCD & DSR Interpretation *
S54 000 003 003 003 Break Signal Interpretation
S55 000 000 000 000 Escape Char./Seq. Interp.
S56 017 017 017 017 XON Character
S57 019 019 019 019 XOFF Character
S58 003 000 000 002 Flow Control used by DTE
S130 002 002 004 002 DSR Interpretation *
S131 002 001 001 003 DCD Interpretation *
S64 000 000 000 000 Dial/Answer Sequence Abort
S65 000 000 000 000 XON/XOFF Failsafe
S66 000 001 001 001 Lock Interface Speed
S67 000 000 000 000 CTS Interpretation
S68 255 003 003 255 Flow Control used by DCE
S90 000 000 000 000 V.22 Emulation Mode Enable
S91 000 000 000 000 Guard Tone Selection
S92 000 000 000 000 PEP tones before slow tones
S95 000 000 000 000 MNP Error Correction
S96 001 001 001 001 MNP Data Compression
S110 255 255 255 255 Data Compression (PEP)
S111 255 030 030 030 Protocol Support
S112 001 001 001 001 Kermit Mark Character
* = New releases of modem firmware are made to be backwards compatible with
previous releases. If an "S" register is missing, the feature has either been removed or
the old register number maps to a new one(s). An "ERROR" message should not result
from using re-mapped registers.
NOTE: Set S50=255 when calling UUNET Communications Services for
UUCP use. S92=1 is set on ALL UUNET-TELEBIT modems.
\f
4. DEFINING THE DIAL-IN PORT CHARACTERISTICS (GETTY/STTY)
Once a direct connection to the modem through the operating system is operational and
the modem registers are configured for your system and use, the dial-in port
characteristics can be defined. These definitions can be altered upon succesful login by
using the "stty" command which is standard to all UNIX systems..
The port on which the modem will be connected should be configured to run at either
9600 or 19200 bps. Use hardware (RTS/CTS) flow control where possible. Use
software XON/XOFF flow control if RTS/CTS isn't available. Make sure that the flags in
/etc/gettydefs (or /etc/gettytab) look something like:
19200m # B19200 CS8 ECHO IXON IXOFF HUPCL # B19200 CLOCAL IXON IXOFF IXON IXOFF
TAB3 BRKINT OPOST ONCLR CS8 ISIG ICANON ECHO HUPCL #login: #19200m
(note that the above should be entered as ONE line of data)
or
z|std.19200|19200-baud:\
:sp#19200:
The use of a rotary or autobaud in getty is not recommended due to the modems ability to
lock interface speed (S66=1). The modem can then arbitrate a slow modem connection
to the hard-set interface speed without the need for interface speed matching. You should
modify the baud rate entries to 9600 if your system only supports 9600 bps. In some
systems this entry may be called "EXTA" or something similar. Keep in mind that every
system may have slightly different names for the flags.
If you do use a rotary or autobaud getty entry, don't forget to set the getty up to include
19200 in its cycle. You may have it trying 19.2 first and moving to 2400 on the first
receipt of a break signal and to 1200 on the second receipt of a break. The order of the
cycle is not important so long as the calling system knows to send breaks until it sees the
login sequence.
\f
5. ESTABLISHING A LOGIN PROCESS (GETTY)
The getty is established on the modem port by editing the /etc/ttys, /etc/ttytab, or
/etc/inittab in order to add the modem port settings (described above) and to enable the
getty.
BSD UNIX GETTY
These entry samples may be used in either the /etc/ttys or /etc/ttytab files to enable
the modem port getty:
1zttya
or
name getty type status comments
ttya "/usr/etc/getty std.19200" dialup on secure
The process does not execute until "init" is restarted to include the new process. This is
accomplished by issuing the command:
kill -1 1
The new process (getty) may be verified by using the "ps" command.
SYSTEM V GETTY
This entry sample may be used in the /etc/inittab file to enable the modem port getty:
00:2:respawn:/etc/getty tty00 19200m
The process does not execute until "init" is restarted to include the new process. This is
accomplished by issuing the command:
init q
or
telinit q
The new process (getty) may be verified by using the "ps" command.
NOTE: It is highly recommended that /etc/getty be used instead of
/usr/lib/uucp/uugetty, due to various problems reported
in the use of uugetty. The use of getty instead of uugetty does
not prevent the modem port for dial-in and dial-out use.
When getty is used on the modem port, the system init levels
should be used to stop and restart the getty as needed for dial-out
purposes. The following script give an example of how this may
be done:
#! /bin/sh
init 3
chmod 666 /dev/tty
cu -s 19200 -l /dev/tty (or uucico -r1 -x9 -ssys)
init 2
\f
UUCP
Configuration of UUCP consists of additions and modifications to the UUCP files contained
in /usr/lib/uucp or /etc/uucp. There are two UUCP environments available in BSD
UNIX systems. These environments are Version2 UUCP and HoneyDANBER (HDB) UUCP.
HoneyDANBER is native to SYSTEM V UNIX, but may also be found in some BSD UNIX
systems. Version2 UUCP is found only in BSD UNIX systems. SYSTEM V UNIX has only
one UUCP environment, HDB. Each environment has different file names, but basically
the same workings in the execution of a UUCP session utilizing the "uucico" command.
When working with UUCP, we have found the most useful resource for UUCP information
has been the book "Managing UUCP and Usenet", published by O'Reilly & Associates. The
book can be ordered directly from O'Reilly by calling their toll-free number, 1-
(800)-338-6887 USA or 1-(800)-533-6887 CA. Their direct numbers are 1-
(707)-829-0515 and 1-(707)-829-0104 FAX. The book costs $21.95 (US) and
may save you hours of time when installing and troubleshooting your UUCP. These books
are also available from UUNET Communications Services at 1-703-876-5050.
"Managing UUCP and Usenet" covers both standard BSD and SYSTEM V UUCP. It is highly
recommended for both novices to the UUCP environment and experienced UUCP System
Administrators.
Use the guidelines below as a starting point. Realize that many slight variations in UUCP
behavior may require you to modify these instructions for your application.
NOTE: Not all systems may be capable of using serial I/O port speeds
at or above 9600 bps. Some systems may require operating system
or hardware modifications. This includes the ability of UUCP
(ie uucico) to function properly at 19200 bps. Please refer to
your systems manual or manufacturer for assistance if this is so.
It is highly recommended that TELEBIT modems be connected to the
serial I/O ports of the system cpu. Use of serial I/O multiplexors
may limit modem speed to 9600 bps or lower, when using UUCP,
due to flow control, cpu/bus interrupt, or memory buffering problems.
\f
VERSION2 UUCP
1. MODIFY /usr/lib/uucp/L-devices (or /etc/uucp/L-devices)
The L-devices file contains information that describes what types of devices the system
has available for use in dialing other systems, and identifies the port(s) they are
connected to. It also contains information about baud rate, and may also contain
instructions for the modem on how to dial, or what dialer script (or program) to use.
If you are running BSD or XENIX UUCP, you may need to modify the dialer for use with
TELEBIT modems at high speeds. A good starting point is usually the Hayes dialer, either
in script form or the program form. The dial program may be called "hayes", or
"hayestone".
If you have SCO XENIX, contact SCO Technical Support and ask for theTELEBIT utilities
(on 5 1/4" or 3.5" floppy). These are available for SCO XENIX releases needing the
"dialTBIT" dialer and new versions of the "uucico" and "cu" programs that have been
enhanced to run at 19200 bps. This is not necessary for SCO UNIX 3.2 systems.
If you think that your computer may need enhancements in order to run UUCP at high
speeds, contact your vendor's Technical Support line for such information.
Some examples of these entries are given below. Your system entries may appear
slightly different. Use the guidelines below as a starting point.
- ACU entries are for automatic dialing (using L.sys entries).
- DIR entries are usually associated with "direct" connections from "cu" or "tip".
- Modify the port number for the appropriate modem port on your system.
- Use a standard dialer such as "hayes" or "hayestone" where available.
- Use a custom dial program such as "dialTBIT" in XENIX.
- Use "A\dA\dA\d" to synchronize the modem to different speeds when autobauding on
outgoing calls, if necessary.
- Set S50 to the appropriate speed when dialing out at low speeds, if necessary.
EXAMPLE 1: /usr/lib/uucp/L-devices (XENIX, BSD 4.2 and 4.3 UUCP):
ACU tty1A /usr/lib/uucp/dialTBIT 19200
DIR tty1A 0 19200
or
ACU cua0 cua0 19200
DIR cua0 0 19200
\f
2. MODIFY /usr/lib/uucp/L.sys (or /etc/uucp/L.sys)
The only changes most systems require are to increase the baud rate from 1200 or
2400 up to 9600 or 19200. Everything else in the chat script should remain the same.
Below is a typical L.sys entry, including the chat script. Do not copy this literally.
Modify the information for your application:
hostname Any ACU 19200 NNNNNNNNNN ogin:--ogin: Usysname ssword: XXXXXXXX
NOTES:
hostname = THEIR System name
NNNNNNNNNN = THEIR System phone number
Usysname = Your UUCP account on THEIR machine
XXXXXXXX = Your UUCP passwd on THEIR machine
The "chat" script is the most common point of wasted connection time and login failure.
Be sure to test this entry rigorously to verify a successful login in the fastest time
possible.
3. TEST UUCP
UUCP can now be tested by issuing the following commands. The debugging level can be
either -x4 or -x9:
/usr/bin/uucp -r1 test.file testhost\!/test.directory [queue file transfer]
/usr/lib/uucp/uucico -r1 -x4 -stesthost [start file transfer]
Upon success or failure of the UUCP session, the status file must be removed before
another UUCP session can be started with the above command:
rm /usr/spool/uucp/STST.testhost
It is also possible that a "lock" file may continue to exist if the process was aborted or
did not complete execution properly. The following commands may be used to remove the
"lock file before the next UUCP session is started:
rm /usr/spool/locks/LCK..tty00
or
rm /usr/spool/uucp/LCK..tty00
\f
HONEYDANBER UUCP
1. MODIFY /usr/lib/uucp/Devices
The Devices file contains information that describes what type of devices the system has
available for use in dialing other systems, and identifies the port(s) they are connected
to. It also contains information about baud rate, and may also contain instructions to the
modem on how to dial, or what dialer script (or program) to use.
Some examples of these entries are given below. Your system entries may appear
slightly different. Use the guidelines below as a starting point.
- ACU entries are for automatic dialing (using Systems entries).
- DIR entries are usually associated with "direct" connections from "cu".
- Modify the port number for the appropriate modem port on your system.
- Use a standard dialer such as "hayes" or "hayestone" where available.
- Use a custom dial script such as "tbfast" in HoneyDANBER .
- Use "A\dA\dA\d" to synchronize the modem to different speeds when autobauding on
outgoing calls, if necessary.
- Set S50 to the appropriate speed when dialing out at low speeds, if necessary.
EXAMPLE 2: /usr/lib/uucp/Devices
ACU ttyxx - 2400 tb2400
ACU ttyxx - 9600 tbfast
ACU ttyxx - 19200 tbfast
DIR ttyxx - 19200 direct
2. MODIFY /usr/lib/uucp/Dialers
The following example entries may be used in the Dialers file:
tb2400 =W-, "" A\pA\pA\pT OK ATS50=3DT\T CONNECT\s2400
tbfast =W-, "" A\pA\pA\pT OK ATS50=255DT\T CONNECT\sFAST
You should have no trouble dialing out at any speed.
3. MODIFY /usr/lib/uucp/Systems
The only changes most systems require are to increase the baud rate from 1200 or
2400 up to 9600 or 19200. Everything else in the chat script should remain the same.
Below is a typical System entry example, including the chat script:
hostname Any ACU 19200 NNNNNNNNNN ogin:--ogin: Usysname ssword: XXXXXXXX
NOTES:
hostname = THEIR System name
NNNNNNNNNN = THEIR System phone number
Usysname = Your UUCP account on THEIR machine
XXXXXXXX = Your UUCP passwd on THEIR machine
The "chat" script is the most common point of wasted connection time and login failure.
Be sure to test this entry rigorously to verify a successful login in the fastest time
possible.
\f
4. TEST UUCP
UUCP can now be tested by issuing the following commands. The debugging level can be
either -x4 or -x9:
/usr/bin/uucp -r test.file testhost\!/test.directory [queue file transfer]
/usr/lib/uucp/uucico -r1 -x4 -stesthost [start file transfer]
Upon success or failure of the UUCP session, the status file must be removed before
another UUCP session can be started with the above command:
rm /usr/spool/uucp/.Status/testhost
It is also possible that a "lock" file may continue to exist if the process was aborted or
did not complete execution properly. The following commands may be used to remove the
"lock file before the next UUCP session is started:
rm /usr/spool/locks/LCK..tty00
or
rm /usr/spool/uucp/LCK..tty00
You should now be able to run UUCP between two machines attached to yourmodems just
as you always have with slower modems. Typical throughputs should be in the range of
10Kbps to 16K bps (1000 to 1600 cps). Enjoy the new world of of high speed UUCP "g"
protocol file transfer.
\f
TCP/SLIP
Serial Line Internet Protocol (SLIP) was developed and distributed for Berkeley 4.3
BSD (Berkeley Standard Distribution) systems. This program allowed the network
routing code to send any IP packet through a serial port as opposed to an ethernet port.
The profound difference was performance. Ethernets run typically at 10 megabits per
second as opposed to typical top speeds of 19.2K bps (bits per second) on asynchronous
serial ports. Nevertheless, it works.
TCP and IP are two cooperating methods that work together to encapsulate data for
passage across a network. Just like placing a letter in an envelope, the receiver may
discard the envelope after safely receiving the contents. The envelope served only to
transport the contained information.
Likewise, applications in a network environment become the senders and receivers of
electronic letters packaged in TCP/IP envelopes. These applications, FTP (File Transfer
Protocol), SMTP (Simple Mail Transfer Protocol), TELNET (virtual terminal emulation
access across the network), PING (a "hello" message to any host on the net to validate its
healthy presence), RLOGIN (similar to TELNET providing remote login to other host
computers on the net), RCP (similar to FTP providing file transfer to other host
computers on the net) and many others, all envelope their cross-net traffic inside
TCP/IP envelopes.
TCP's contribution to the data envelope is 20 bytes of overhead. Likewise IP contributes
its own 20 bytes. SLIP prepends and appends another 2 bytes for a grand total of 42
bytes of overhead. FTP file transfers, today, run well with TELEBIT modems achieving
12,000-14,000 bps throughput. This is true for all bulk data applications.
However, a problem arises when interactive terminal emulation applications like
RLOGIN or TELNET operate. When running a TELNET or RLOGIN session, that is simply
typing on a screen to a host somewhere on the network, each character typed is enveloped
in 42 bytes and mailed to the remote machine. When running across a 10 megabit per
second ethernet (the medium this whole process was designed for) enduring that much
overhead is not elegant, however, it is functional. At 9600 bps on a high-speed modem,
the overhead is impeding.
TELEBIT Micro-short packets potentially hold about 10 data bytes. Once the first ten
bytes of a TCP/SLIP packet fill the first micro-short modem packet, the modem builds a
256 byte long packet to house the following plus or minus 32 bytes. This inefficiently
stuffed packet travels the link consuming unnecessary transmission time. The action of
sending packets back and forth causes the modem to thrash between micro-short and long
packets and the resulting interactive TCP/SLIP performance is poor.
These interactive applications currently run with about a 1.2 to 2.0 second round trip
character echo delay. This interactive performance is unacceptable. Nevertheless,
many TELEBIT modem users are today running SLIP. The resources available through
TCP/SLIP are forcing them to accept the unacceptable.
TELEBIT modems do not contain TCP/SLIP or Point-to-Point Protocol protocol support.
As stated above, these protocols consist of rather large datagrams which make the use of
high-speed modems a necessity.
\f
POINT-TO-POINT PROTOCOL
Point-to-point circuits in the form of asynchronous and synchronous lines have long
been the mainstay of data communications. Even with the growing popularity of local
area networks, wide area connections are still made using various point-to-point
circuits. Over time the data link levels used have settled to a few standards. However,
the method use of the data link by upper level protocols, such as IP, has been largely
implementation dependent. This resulted in requiring a single vendor's equipment for
both ends of a point-to-point circuit.
The Point-to-Point Protocol (PPP) seeks to remedy this problem by proposing a
standard method of encapsulating IP datagrams, as well as other network layer protocol
information, over point-to-point links. PPP also specifies the means for line and
protocol operation and maintenance by providing the means for testing and configuring
the line and each of the upper level protocols. PPP is designed to be easily extensible for
adding new protocols and features.
PHYSICAL LAYER
PPP is capable of operating across virtually any DTE/DCE interface. The most common
examples of interfaces are RS-232-C, EIA RS-423 and CCITT V.35. The only absolute
requirement for PPP is that a duplex circuit be provided. While control signals are not
required for the use of PPP, it should be recognized that they do add functionality and it
is recommended that they be fully utilized when they are available from the interface.
DATA LINK LAYER
PPP specifies for synchronous and asynchronous circuits ISO that 3309-1979 as
modified by ISO 3309:1984/PDAD1 be used. The framing specified by this document is
more commonly known as HDLC and the 1984 addendum defines HDLC for asynchronous
circuits. PPP describes the values to be used in the standard HDLC fields and adds a
protocol field to indicate for which protocol the data is destined. There are three major
types of protocols, link control, upper level protocol control, and upper level protocol
data.
TELEBIT MODEM CONFIGURATION FOR POINT-TO-POINT CIRCUITS
Configuring a TELEBIT modem for use in a BSD4.3 TCP/SLIP, Compressed TCP/SLIP
(TCP/CSLIP; BSD4.4), or Point-to-Point Protocol (PPP RFC 1134) application is
merely a case of configuring the modem to behave exactly like a direct RS-232c cable
connection between the two host systems in the circuit. That is, NO FLOW CONTROL!
Hardware flow control (EIA or RTS/CTS) is recommended where supported by the host
system. The following S-register settings should accommodate most point-to-point
circuit set-ups:
S-REGISTER SETTING DESCRIPTION
=================================================================
S58 000 No Flow Control. S68=255 also.
S58=2 For RTS/CTS. Optional.
S50 XXX Modulation. S50=255 is PEP
S50=6 is V.32. Optional.
S66 001 Lock Interface Speed.
S95 XXX MNP Error Correction or Data
Compression (4/5) for V.32.
Optional.
S110 XXX PEP Data Compression. Optional.
\f
AUTODIALING
The S104 register is used to cause the modem to go off-hook and dial one of the first two
telephone numbers in the modem telephone number directory. The number dialed is
dictated by the position of the A/B switch on the front of your TELEBIT modem (post-
1989 models). The following example is meant to illustrate the flexibility of this
feature, as well as that of modem modulation usage in the set-up of a point-to-point
circuit:
BANK A: AT S50=255 S52=2 S58=0 S66=1 S95=2 S104=1 S110=1 &W1
ATN0=nnnnnnn\TELEBIT_PEP_SLIP
BANK B: AT S50=6 S52=2 S58=0 S66=1 S95=2 S104=1 S110=1 &W2
AT N1=nnnnnnn\TELEBIT_V.32_SLIP
Where BANK A is configured to dial the telephone number stored at location N0: in the
modem and establish a compressed PEP connection with the remote TCP/SLIP host upon a
OFF-to-ON transition of DTR. This enables the modem to automatically dial the remote
TCP/SLIP host system as soon as DTR is raised (DTR "ON") on the modem port by the
execution of a SLIP attach command (slattach) on the originating TCP/SLIP system. The
need for a "tip" or "cu" process in order to affect dialing is eliminated.
The settings in BANK B accomplish this same task with the exception using V.32
modulation with MNP to establish the TCP/SLIP link. The telephone number in location
N1: could be the same or different from that of BANK A.
The A/B switch can now be used to set-up two distinct point-to-point circuits or one
point-to-point circuit with the ability to use two different modulation schemes.
The use of PEP or V.32 modulation allows for flexibility in the performance of the
point-to point circuit in relation to the task performed and data transferred. PEP is
highly recommended for use in long distance connections or low quality connections. PEP
will also yield the highest throughput in the transfer of binary files or compressible
bulk data files using FTP or rcp, as well as SMTP and NNTP connections. CCITT V.32 is a
full duplex modulation scheme which will facilitate better interactive response during
TELNET, rlogin, and rsh connections.
\f
This document is meant to take a VERY general approach to the configuration of TELEBIT
modems in interactive, file transfer, and networking applications on UNIX systems.
TELEBIT welcomes any questions, comments, and suggestions on this or any of our other
product or configuration documents at the following U.S. Mail address, telephone
number, or network account:
Michael Ballard/ Cerafin E. Castillo
Telebit Corporation
1315 Chesapeake Terrace
Sunnyvale, CA 94089
1-800-TELEBIT
UUCP: {uunet, sun, pyramid, ames, decwrl}!telebit!modem
INTERNET: modems@telebit.com