richmond@ucbast.berkeley.edu (Stupendous Man) (05/18/91)
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.
In short, we're stumped. If you can tell me how YOU successfully
transfer files with a setup similar to ours, I'd be very happy to
hear from you - at least that way I'll know where I should spend all
my time and effort. Thanks in advance.
Michael Richmond
-- Michael Richmond
"This is the heart that broke my finger." richmond@bkyast.berkeley.edurobin@pensoft.uucp (Robin Wilson) (05/21/91)
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 | +-----------------------------------------------------------------------------+
herb@ajfcal.uucp (Herb Peyerl) (05/21/91)
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 Sounds like you're having flow control problems... I just overcame the same thing when I upgraded the OS on my RT.. (CorrSrvc 1773). I just couldn't get hardware flow control working to save my life but this weekend I sat down for a couple of hours and got it working with my "DCA Fastlink" (Trailblazer Clone). In "devices", I have: pro dc ixp false dvam 0 sns false aa false and in the telebit, I have: E0 F1 M0 Q1 T V1 X3 Version AA3.00-AB3.00 S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=060 S08=002 S09=006 S10=007 S11=070 S12=050 S45=000 S47=004 S48=001 S49=000 S50=000 S51=005 S52=002 S53=001 S54=003 S55=003 S56=017 S57=019 S58=002 S59=000 S60=000 S61=099 S62=003 S63=001 S64=000 S65=000 S66=001 S67=000 S68=002 S90=000 S91=000 S92=000 S95=000 S100=000 S101=000 S102=000 S104=000 S110=255 S111=255 S112=001 S121=000 Other Pertinent information: 6150-25, IBM 4 port async, and standard IBM Modem cable. There's still a problem with Carrier Detect and getty... It seemed to a choice between having hardware flow control or having getty work right... But if you're using it to dial out only, then you shouldn't have to worry about that... Good Luck. -- -------------------------------------------------------------------------- UUCP: herb@ajfcal.UUCP || #define Janitor Administrator I brew, therefore I am.. || Apollo System_Janitor, Novatel Communications "I spilled spot remover on my dog and now he's gone..." <Steven Wright>