jim@eda.com (Jim Budler) (11/01/88)
Here's the script I use to configure my Telebit TB+. It's based on an earlier
posting whiched used 'cu' scripts. My version of 'cu' couldn't hack it.
Some other variations are based on a How To Technote from Telebit. I still
wonder about that "no flow control" statement below, but they oughta know.
#! /bin/sh
# $Header: /files/home/staff/jim/etc/RCS/tbreset,v 1.2 88/10/18 15:48:29 jim Exp Locker: jim $
#
speed=19200
remote=disabled
case "$1" in
-9600) speed=9600
# The -9600 option is
# for those times when it has to be manually reset first
# the phone numbers will not be set, run it a second time without
# the -9600 option
;;
"") ;;
*) echo "usage: `basename $0` args..."
exit 1;;
esac
(stty $speed -echo
sleep 2
echo "at&fs7=100s51=5s52=2s54=3s110=1s111=30s45=255s58=0s53=3s66=1q6x0m0&w1"
#
# (&F) recalls factory defaults (start with known configuration).
# (S7=100) longer wait for carrier. Too many dropped lines
# (S51=5) sets the serial port to 19200 bps.
# (S52=2) says drop the connection when DTR is dropped to the modem
# and reload the modem's stored EEPROM values (do a soft reset).
# (S54=3) says pass BREAKs through the modem transparently.
# (S110=1) enables data compression between TrailBlazers.
# If desired, S110=0 will disable this feature.
# (S111=30) enables UUCP "g" protocol support in the TrailBlazer.
# (S45=0) disables remote access.
# (S58=0) disables flow control.
# The UUCP protocol support handles flow control instead.
# (S53=3) sets DSR "ON" when modem is off-hook.
# It also sets DCD "ON" when carrier is detected.
# (S66=1) locks the interface speed.
# (Q6) silences the modem when an inbound call arrives.
# This prevents getty battles between the RING result code and
# getty's echo of the same.
# (M0) Turns off speaker
# (&W1) writes these new values into the EEPROM, configuration A)
# This saves the new values as the modem's power on defaults from
# now until you change them again.
sleep 2
echo "atn2=xxxxxxxxxx\\decwrlfast\\"
sleep 1
echo "atn3=xxxxxxxxxx\\decwrlslow\\"
sleep 1
echo "atn4=xxxxxxxxxx\\uunet\\"
sleep 1
echo "atn5=xxxxxxxxxx\\uunetld\\"
sleep 1
# add additional phone numbers here, as desired
echo "at&w1"
# (W1) writes phone numbers into EEPROM.
sleep 1
echo "atm1&w2"
# (M1) turns speaker on.
# (&W2) writes everything into EEPROM configuration B.
# This last in effect makes the A/B switch a speaker switch.
) </dev/cua0 > /dev/cua0
--
uucp: {decwrl,uunet}!eda!jim Jim Budler
internet: jim@eda.com EDA Systems, Inc.terry@wsccs.UUCP (Every system needs one) (11/10/88)
In article <260@eda.com>, jim@eda.com (Jim Budler) writes: > I still > wonder about that "no flow control" statement below, but they oughta know. > > > > # (S58=0) disables flow control. > # The UUCP protocol support handles flow control instead. Wonder no longer. Since the uucp protocol is what is called an ACK-NAK protocol... that is, it must receive an ACK before it transmits the next packet or a NAK before it retransmits the current one, it is possible to implement flow control by simply not sending the ACK or NAK back from the modem to uucp. If you don't send back the ACK, it won't send you any more data. Another reason to avoid flow control is the fact that IXON is handled at the kernel level. What this means to you is that if you get XOFFed by the modem, you will hang in your read or write until you receive an XON. The period of time you wait depends only on how long the interval is before you get an XON. Since you are hanging in the kernel, any signals you have used to interrupt your read will be queued until that time. If, then, you receive an XOFF and the line drops, you are stuck. Forever. This is why you will never see a Zmodem implementation for Xenix that works worth a darn. Sliding windows require the capability for flow control. With the current Zmodem code, this cannot be easily handled in user-mode code, as it may be swapped and Zmodem provides no mechanism for being clever about avoiding swapping in the user-mode code handling XON/XOFF. Not using XON/XOFF is also a good bet with binary protocols. Xmodem, for example, discounting that 1 out of 128 characters is a flow control character and that most implementations of flow control ignore the 8th bit (making it 1 out of every 64 character - 2 times a packet), the packet sequence numbers on packets 17 and 19 are ^Q and ^S, respectively. Given a modem intercepting these, all hell breaks loose. In the best case, the ^S is passed through delayed. In the worst case, it is never sent to the other machine. The protocol breaks. Nobody wanting to transfer files reliably will use a modem with flow control turned on... On the other hand, since these very fast modems really aren't, if you drive the modem at it's advertised speed, you will certainly overrun it's buffer. You have to hold it down to the throughput the line is minimally capable of. This is a dilema. Unfortunately, it won't be resolved until one of four things happen: 1) Communications software is all 6-bit quoted, non-binary alphanumeric protocols, like kermit. This will never happen. The protocols are orders of magnatude slower than binary protocols. 2) Communications bandwith is limited to the throughput the line and modulation technique is minimally capable of, given worst-case compression, etc. This will never happen. Not doing this sells modems. 3) Manufacturers adopt a standard method of altering flow control parameters via software. This is hard, and probably won't happen; one manufacturer is never going to agree with another on how his modem can tell the other guys modem at the other end of the line to turn off flow control (this is necessary; in terminal sessions, if only one end supports flow control it doesn't work for terminal sessions). This still ignores the problems of using high speed modems for TCP/IP SLIP links or any other multiplexed terminal-session-while-you-transfer scheme. 4) End users realize they can't have real fast modems doing binary protocols and terminal sessions without reconfiguring both ends in between. This, really, will never happen. So you accept the rocks and live with them, one way or another until you discover a tradeoff that is acceptable to your situation. Oh well. | Terry Lambert UUCP: ...{ decvax, uunet } ...utah-cs!century!terry | | @ Century Software OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'I have an eight user poetic liscence' - me |
james@bigtex.cactus.org (James Van Artsdalen) (11/13/88)
In <773@wsccs.UUCP>, terry@wsccs.UUCP (Every system needs one) wrote: > Since the uucp protocol is what is called an ACK-NAK protocol... that > is, it must receive an ACK before it transmits the next packet or a > NAK before it retransmits the current one, This is a little deceptive. uucp 'g' (there is more than one protocol in uucp but only 'g' is universal) actually has a window size: several packets can be outstanding. The sender doesn't wait for an ACK on the last packet, but conceptually waits on the ACK from three or so packets back (as many as seven). Indeed, my 'g' driver does precisely this: it sends the window size of packets, and then at each further packet waits explicitly on an ACK N - window_size old. > Another reason to avoid flow control is the fact that IXON is handled > at the kernel level. [...] Since you are hanging in the kernel, any > signals you have used to interrupt your read will be queued until that > time. If, then, you receive an XOFF and the line drops, you are > stuck. Forever. Such a device driver would not be useful. Presumably alarm(2) would interrupt any such "hanging". > This is why you will never see a Zmodem implementation for Xenix that > works worth a darn. Sliding windows require the capability for flow > control. Zmodem doesn't really use sliding windows, certainly not in the Kermit sense. Zmodem also coexists with XON/XOFF even with binary transfers. > On the other hand, since these very fast modems really aren't, I would think I would have long since noticed if my very fast modem really wasn't. > if you drive the modem at it's advertised speed, you will certainly > overrun it's buffer. You have to hold it down to the throughput the > line is minimally capable of. You appear to neglect hardware handshake. My system talks to my TB+ at 19.2Kbps even when the modem is connected at 2400bps: Xmodem and other binary applications work fine because the handshake is done via RTS/CTS, out of band. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Home: 512-346-2444 Work: 338-8789 9505 Arboretum Blvd Austin TX 78759