W8SDZ@SIMTEL20.arpa (Keith Petersen) (08/10/86)
The following is relayed from GEnie's CP/M RoundTable.
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
uucp: {ihnp4,allegra,cmcl2,dual,decvax,mcnc,mcvax,vax135}!seismo!w8sdz
GEnie Mail: W8SDZ
RCP/M Royal Oak: 313-759-6569
---forwarded message---
TO: All PC Pursuit Users
WARNING: PC Pursuit will not upload certain files!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
As if the busy signals and disconnects were not enough (sigh),
listen to this...
Under certain circumstances, files may not be uploaded to a
remote system with Christensen ("XMODEM") protocol using the PC
Pursuit service of GTE Telenet. In particular, the three-byte
ASCII sequence <CR, '@', CR> (binary <0DH, 40H, 0DH>) is ALWAYS
interpreted as an escape to Telenet command level. If this
sequence occurs in an appropriate place within a file, that file
cannot be uploaded! The typical effect with most file transfer
programs is the occurrence of repeated local timeout errors, and
an apparent loss of connection when the user returns to terminal
mode to attempt recovery after the transfer is aborted.
I have verified the above with Telenet customer service and
engineering representatives. Their response was that this is an
unfortunate result of the established Telenet command structure,
and it is not likely that any attempt will be made to provide a
solution to this problem for PC Pursuit customers! (Considering
the difficulty of making network connections at almost any hour
of the night, I'm sure there must be A LOT of us PC Pursuers out
there... At $25 per month each, I had hoped we deserved a better
response than that.)
Note that this situation is unlikely to occur within an ASCII
text file produced on CP/M or MS-DOS systems, since CR is almost
always followed by LF in such files. But it is certainly
possible within a binary (e.g. .COM) file. (The high bit of each
byte is insignificant to Telenet, so there are actually eight
different 3-byte binary sequences which may cause this problem.)
Also, there is a small likelihood of this occurring even during a
text file transfer, due to the binary record count and checksum
or CRC bytes which are generated by the protocol. From my own
experience, the problem seems most likely to occur within
SQueezed files.
As a possible workaround to this problem, I would suggest trying
either of the following:
1. Change the file compression. I.e., (un)SQueeze or (un)CRUNCH
the file, as appropriate to its original form. Then leave a
message to the remote system's SysOp requesting that the file
be restored after it is received.
2. If you are using XMODEM-CRC mode, try Checksum mode (or vice-
versa). If you are using 1K-byte (YMODEM) transfers, try
using the slower 128-byte transfers instead. Either of these
changes may allow recovery from a small class of situations
which could cause the problem.
The following facts should also be noted:
1. This problem occurs only with uploads. Downloads from a
remote system are not affected.
2. Once such a file transfer has been aborted, you have NOT lost
your connection to the remote system! Simply issue the
command CONT (continue) at the Telenet @ prompt.
I hope this information will save others the hours of aggravation
it has caused me.
Bob Freed
Newton Centre, MA
August 6, 1986
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -johnso%tp5@RAND-UNIX.arpa (A. Ross Johnson) (08/11/86)
Is there really no way to disable the escape sequence with Telenet? Foreign data networks (about which I know more) all provide for this, with standard international paramater no. 1 for PAD (packet assembler and disassembler) protocols, according to a CCITT standard. When paramater no. 1 is set to 0, you cannot escape to net command level in that session and so can upload binary files. Ross Johnson
sbanner1@uvicctr.UUCP (S. John Banner) (08/12/86)
In article <2909@brl-smoke.ARPA> W8SDZ@SIMTEL20.arpa (Keith Petersen) writes: >The following is relayed from GEnie's CP/M RoundTable. >TO: All PC Pursuit Users > >WARNING: PC Pursuit will not upload certain files! >Under certain circumstances, files may not be uploaded to a >remote system with Christensen ("XMODEM") protocol using the PC >Pursuit service of GTE Telenet. In particular, the three-byte >ASCII sequence <CR, '@', CR> (binary <0DH, 40H, 0DH>) is ALWAYS >interpreted as an escape to Telenet command level. If this >sequence occurs in an appropriate place within a file, that file >cannot be uploaded! The typical effect with most file transfer >programs is the occurrence of repeated local timeout errors, and >an apparent loss of connection when the user returns to terminal >mode to attempt recovery after the transfer is aborted. > >Note that this situation is unlikely to occur within an ASCII >text file produced on CP/M or MS-DOS systems, since CR is almost >always followed by LF in such files. But it is certainly >possible within a binary (e.g. .COM) file. (The high bit of each >byte is insignificant to Telenet, so there are actually eight >different 3-byte binary sequences which may cause this problem.) >Also, there is a small likelihood of this occurring even during a >text file transfer, due to the binary record count and checksum >or CRC bytes which are generated by the protocol. From my own >experience, the problem seems most likely to occur within >SQueezed files. > >As a possible workaround to this problem, I would suggest trying >either of the following: [Work arounds deleted.] Another possibility (I don't use GTE Telnet, so I can't say it will work, but I don't see why it shouldn't), is simply to use the Kermit file transfer protocol. With the exception of line noise, the given sequence can never occur because all control characters in the file being transfered are encoded to printables (CR=="#M" I think), and any 'CR's in required by the protocol itself are immeadiately followed by H01 (Control A). That would solve all your problems, so long as the people on both ends are willing to support Kermit (and Kermit implimentations are free, so the only cost of suport is getting it [downloading costs?], disk space, and time to learn Kermit [it is quite easy to learn]). Hope this helps, S. John Banner.