BS> BTW Do you know what that  issue about MaxEd there 
 BS> is listed in TODO is about? I've been writing several 
 BS> messages using fullscreen editor in Maximus with no 
 BS> problems.

Hmmmm....   issue?  You mean the one about  to be
accepted as  pair?  Based on what I'm seeing in the
TODO file, I'm sure that was a note by Wes to support Unix style end of
lines along with DOS based end of lines.....  

 BS> [Our _dear_ filetransfer problem]

 BS> Not I don't believe it's the core of maximus, more the 
 BS> comdll, but It's definately a problem related to 
 BS> maximus, because the telnet clients I've used for 
 BS> testing is working very greate with other Telnet based 
 BS> boards.

 BS> The client is doing binary, but I the "server" does.. (Maximus)..

 BJ> Both ends should be doing binary, 8 bit clear channels. 

 BS> Maybe the "server" doesn't, it was what I was trying to write ;)

Ok.  And I would not be suprised about that.  If you are seeing double of
characters on the receiving end, that can also be a different problem
(local echo turned on in the telnet client, as well as Max providing
echo)....  But that wouldn't be a CRC problem for the (binary) file upload
and downloads....

 BJ>  Binary on a 7-bit channel will have problems.....  I'm 
 BJ> not sure what the telnet client does for binary with a 
 BJ> 7-bit channel, but I suspect it uses a flag character, 
 BJ> like the old CDC exted 6/12 bit character code.

 BS> Indeed, it'll.. 

I'm expecting to find that we didn't set a flag (or a set of flags) for
IOCTL on the TCP/IP session that is causing either character
interpretation, 7 bit (vs 8 bit clear) channel, or something similar.  

I may have to dig out an old program that allows one to hook a TCP/IP port
for testing.  It's been years since I've played at this level.

Take care.....

Bob Jones, 1:343/41



--- Maximus/2 3.01