wgd@rti.rti.org (03/06/89)
Blah! Here's the setup. Sun 3/160, running SunOS 4.0.1 with yapt5.4
patch. Terminal (actually a Mac or a PC) connected to a Bridge CS100
Ethernet Terminal Server, through which we log in to the Sun.
Problem: Xmodem transfer attempts fail on any file that requires more
than 12 blocks (of any size, on this case either 128 bytes or 1024 bytes).
Does fine until block 13, which results in transmission errors reported at
the micro. Happens for both IBMish PC and Macintosh.
Note that file transfers ARE successful if done using the serial port. I
transferred about 250K of stuff via modem at 1200 baud with NO problems at
all using xmodem and my Mac.
Has anyone experienced similar problems? If so, what's the resolution?
Thanks.
Wally Dixon
Broadband Technologies, Inc.
wgd@bbt
{...}!mcnc!rti!bbt!wgdhedrick@geneva.rutgers.edu (Charles Hedrick) (03/15/89)
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.
grandi@noao.edu (Steve Grandi) (03/16/89)
> Problem: Xmodem transfer attempts fail on any file that requires more > than 12 blocks (of any size, on this case either 128 bytes or 1024 bytes). > Does fine until block 13, which results in transmission errors reported at > the micro. Happens for both IBMish PC and Macintosh. Sounds like the terminal server is doing something "magic" when it sees a Ctrl-M character (decimal 13). Xmodem encodes a sequential block number in the data block, so it requires a TOTALLY transparent 8-bit path. See if you can tell the terminal server to give you a totally transparent connection. I have the exact problem with a CMC Transerver telnet server (also resold to the Sun market by Artecon); Ctrl-E is the "escape" character to talk to the box, hence all Xmodem transfers fail on the fifth block. As far as I can tell, one can configure the escape character on the CMC box to be anything one likes, but can't turn it off completely. Hence, Xmodem transfers are impossible. Steve (author of a dandy -- if I do say so myself -- version of Xmodem running on 4.3BSD and SunOS systems) Steve Grandi, National Optical Astronomy Observatories, Tucson AZ, 602-325-9228 UUCP: {arizona,decvax,ncar}!noao!grandi or uunet!noao.edu!grandi Internet: grandi@noao.edu SPAN/HEPNET: 5355::GRANDI or NOAO::GRANDI