🚀 go-pugleaf

In article <1991May17.200714.2695@agate.berkeley.edu> richmond@ucbast.berkeley.edu (Stupendous Man) writes:
>  We're having lots of problems trying to transfer data from one RT
>to another over telephone lines - can anybody help?  We're using the
>standup RTs, running AIX 2.2.1, with Telebit T1600 modems at each
>end.  We've tried using IBM's ATE program, but the XMODEM facility
>doesn't seem to work.  We then tried the ZModem 'rz' and 'sz' programs,
>both with ATE and with PComm (a public domain telecommunications
>program modeled after ProComm).  Short files are transferred fine,
>but longer ones inevitably suffer a CRC error, and neither the sender
>nor receiver seems to notice and call the transfer off; the machines
>just sit there and do nothing.  I've fiddled with the code a bit,
>and managed at one point to get almost all of a file transferred
>correctly - but when the last, smaller-than-normal-sized packet was
>sent, it wouldn't be received correctly and again things would hang up.

To me... this sounds like you have "XON/XOFF" flow control specified for some
part of the connection.  On the Telebits, if you are using "Conventional
Command Set" you will need to set the "&K" software register to "&K0".  If you
put the following entry in your "/usr/adm/uucp/Devices" file:

Direct tty<nnn> - Any direct

(Where <nnn> is the number of the tty to which your modem is attached.)

And then issue the command:

cu -ltty<nnn> -s<speed>

(Where <nnn> is the tty number you specified in the devices file for the modem
line, and <speed> is the speed in "bits per second" that you intend use when 
talking to the modem.)

This command will return (assuming the device is available, and not "locked"):

"Connected"

At this point you are attached to the modem, as though it were another system.
You can issue modem commands (or whatever) up to and including dialing into
another system (by issuing the command "ATDT<number_of_remote_system>").  This
is where you will want to modify all of the modem's software registers.  Issue 
the command:

AT&K0&W0&W1

The "&K0" sets the "&K" register to value "0", while the "&W0&W1" stores the 
modification into stored profile "0" and "1" respectively.  To view the change
you can type the command:

AT&V

Which will show you what is stored in the "ACTIVE", "PROFILE 0" and "PROFILE 1"
profiles.  Just find the "&K" register in the list, and see that it reads
"&K0" now.

If you are using the "Enhanced Command Set", the registers "S58", "S68", "S66",
"S50" and "S51" should be set as follows:

AT S58=0 S68=255 S66=0 S50=0 S51=254 &W1&W2

These settings mean the following things:

S58=0	means "Use NO FLOW CONTROL from the DTE (computer)"
S68=255 means "Use the setting from S58 for flow control from the other
     	modem" -- (In this case NONE)
S66=0	means "Change the speed of the interface between the modem and the
     	computer to match the speed of the connection" -- this is required
     	when the modem is not using flow control.
S50=0	means "Auto speed determination" -- the modem will try to figure out
     	what speed the remote modem can use to communicate.
S51=254 means "Allow the interface speed between the modem and the computer
    	to set to the speed of the connection, starting at 19200bps."
&W1&W2	means "Save these settings into stored profiles "1" and "2"
     	respectively."

This will turn off flow control in the "modem" part of the connection.  On the 
computer the "devices" setting for the tty in question should set "ixp" to 
"false".  This will turn off "software" flow control on the computer "part" of
the connection.  

Now, you say, "why is this neccessary?"  Well, it's like this:

The file transfer software you are using sends a small portion of a the file
in a "packet", and then waits for the receiving side to get the "packet" and 
send back a "CRC" or "Checksum" (depending on the transfer software).  The 
"CRC" or "Checksum" is a binary number (meaning a sequence of "1"'s and "0"'s)
that is based on the data in the packet; which means that it can be any value.
(The previous comment "...it can be any value" is crucial to understanding the
problem.)  The value can even be the same binary number as "XON" or "XOFF".
Since the device driver, and the modems are reading the incomming data, looking
for flow control characters, they will see the "XON" or "XOFF" values in the 
"CRC" or "Checksums" as "Flow control" characters.  When the modem or the tty
devices read a flow control character in the data, they strip them out, because
they are not supposed to be part of the data, but control characters to modify
the rate of data transmission.  When the modem or tty device strip out the 
"XON/XOFF" values from the CRC or Checksum, the CRC/Checksum value that the
sending modem gets back is suddenly invalid, so it resends the packet.  When
the CRC/Checksum value happens to be the "XOFF" character, the device that sees
it will stop transmission and wait for an XON character to restart.  So the 
end result is a hung transmission.  Either way (with XON or XOFF) the transfer
will fail (because the CRC/Checksum value for a given packet will always be 
the same), and you will see either a hung transfer, or alot of retries before
the transfer software gives up.  This of course will only occur on files which 
happen to just find the correct sequence of characters at the right place in 
the file to cause the bad CRC or Checksum.

Mail me directly if this is not yet clear.  Perhaps you could call me directly
at the number below for a "dynamic" discussion of file transfer on the RT.

+-----------------------------------------------------------------------------+
|The views expressed herein, are the sole responsibility of the typist at hand|
+-----------------------------------------------------------------------------+
|UUCP:     pensoft!robin                                                      |
|USNail:   701 Canyon Bend Dr.                                                |
|          Pflugerville, TX  78660                                            |
|          Home: (512)251-6889      Work: (512)343-1111                       |
+-----------------------------------------------------------------------------+