Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!husc6!rice!sun-spots-request From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.sys.sun Subject: Re: Help with xmodem over Ethernet Terminal Server/SunOS 4.0 Keywords: Hardware Message-ID: Date: 15 Mar 89 15:44:40 GMT References: <432@bbt.UUCP> Sender: usenet@rice.edu Organization: Rutgers Univ., New Brunswick, N.J. Lines: 34 Approved: Sun-Spots@rice.edu Original-Date: 6 Mar 89 01:25:48 GMT X-Sun-Spots-Digest: Volume 7, Issue 200, message 1 of 16 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.