Help with xmodem over Ethernet Terminal Server/SunOS 4.0

[Charles Hedrick]

Ah yes, xmodem fails on block 13.  13 == '\r'.  The block number appears
in the xmodem header.  What is happening is that your combination of
terminal server and telnetd are turning CR into something else.  Maybe
CRLF.  Maybe LF.  Here's what is supposed to happen.

  terminal server may send CR as CR NUL or CR LF (vendor's choice --
	I prefer CR LF).
  telnetd turns both CR NUL and CR LF back into CR
  telnetd sends CR LF as CR LF, any other CR gets a NUL added after it
  terminal server removed NUL after CR

Sorry for the wierd rules, but that's what the protocol requires, at least
as currently interpreted.  As far as I can tell from looking at the
source, 4.0 telnetd does the right thing. (We run a telnetd based on
Berkeley's code, but that part of the code seems to be the same as Sun's.)
Probably the problem is with the CS/100.  However you might want to do a
test with telnet on your Sun, turning on "toggle netdata" to see whether
in fact this mapping is being done correctly by your telnetd.  Note that
xmodem requires a transparent 8-bit path.  It is quite legitimate for
telnet implementations to truncate to 7 bits.  I don't know whether the
CS/100 does or not.  Unix does not.

There is a "binary mode" of telnet that is supposed to guarantee 8 bits
transparent.  See if you can find a way for the CS/100 to set binary mode.
You might also see whether there are any configuration options that affect
how CR is processed.

We do xmodem and UUCP via telnet to Suns, but we use cisco terminal
servers.  However I had to beat cisco up a year or so ago to get them to
make this stuff work right.  If you have software support from Bridge, you
may have to do the same with them.

You might consider using kermit.  With big packets it is almost as fast as
xmodem.  And it isn't sensitive to the CR problem.