MS-DOS Kermit client, Kermit-95 server, REMOTE DIRECTORY - Protocols

This is certainly pilot error, but I'm at a loss.

MS-DOS Kermit 3.14 patch level 9 talking to Kermit-95+ 2.1.2.
Kermit-95 has been given SERVER, MS-DOS Kermit has been given REMOTE
DIRECTORY. The directory listing displayed has line feeds rather than
carriage return-line feed pairs separating entries, and so is very
difficult to read. 115.2Kbps, 8N1, all control characters prefixed.

Any hints as to what I should be looking for?

Brian Hetrick wrote:
> This is certainly pilot error, but I'm at a loss.

I'm not convinced it is pilot error. At least I don't what commands
would "fix" it.

> MS-DOS Kermit 3.14 patch level 9 talking to Kermit-95+ 2.1.2.
> Kermit-95 has been given SERVER, MS-DOS Kermit has been given REMOTE
> DIRECTORY. The directory listing displayed has line feeds rather than
> carriage return-line feed pairs separating entries, and so is very
> difficult to read. 115.2Kbps, 8N1, all control characters prefixed.

I've tried various combinations with MS-Kermit 3.14 patch level 9,
MS-Kermit 3.16 and Kermit 95 2.1.3 as client and Kermit 95 2.1.3,
C-Kermit 6.0.192 and C-Kermit 8.0.212 Dev.01 as server - all over
dial-up modem connections, but I think the results would be the same
over TCP/IP.

The only combinations that exhibit the problem are the MS-Kermit
clients and the Kermit-95 server.

I made packet logs with the MS-Kermit 3.16 client and Kermit-95 and
C-Kermit servers.

The issue seems to be that the K-95 server sends the listing with only
"#J" (prefixed line-feed) as a line terminator whereas C-Kermit sends
the listing with "#M#J" (prefixed CR-LF) as the line terminator. If
K-95 is the client, it understands the "#J" as a new-line and displays
the listing correctly whereas MS-Kermit displays the "#J" as a
line-feed only so the listing is "horizontally scrolled".

This appears to be a limitation on using MS-Kermit as a client with
K-95 as a server although I don't really know why there should be a
difference between K-95 and C-Kermit in this respect, but there clearly
is. Maybe there is some magic switch after all.

--
Mark Sapiro msapiro at value net The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan

Mark Sapiro wrote:

> I made packet logs with the MS-Kermit 3.16 client and Kermit-95 and
> C-Kermit servers.
>
> The issue seems to be that the K-95 server sends the listing with only
> "#J" (prefixed line-feed) as a line terminator whereas C-Kermit sends
> the listing with "#M#J" (prefixed CR-LF) as the line terminator. If
> K-95 is the client, it understands the "#J" as a new-line and displays
> the listing correctly whereas MS-Kermit displays the "#J" as a
> line-feed only so the listing is "horizontally scrolled".
>
> This appears to be a limitation on using MS-Kermit as a client with
> K-95 as a server although I don't really know why there should be a
> difference between K-95 and C-Kermit in this respect, but there clearly
> is. Maybe there is some magic switch after all.

There is no magic switch. The output comes from the ckcfns.c nxtdir()
function and it clearly outputs everything with only a "\n" as the
terminator. This is true for C-Kermit and Kermit 95. Now in the case
of MS-DOS Kermit connected to C-Kermit via a tty, the pseudoterminal
may expand the LF into CR-LF. This is not the result of anything that
C-Kermit is doing. If you were to connect MS-DOS Kermit to C-Kermit
over a raw connection, you would see the same behavior.

In the case of MS-DOS Kermit to Kermit over TCP/IP, you may very well
see different behavior because the newline in NVT mode would be
converted to CR-LF.

It is only over a serial connection that you would see the raw LF.

If someone is interested in a build of Kermit 95 that performs
this expansion, they can read the information available at

http://www.columbia.edu/~jaltman/

and hire me to make the change.

Jeffrey Altman
Secure Endpoints Inc.


--
-----------------
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu

Jeffrey Altman wrote:
>
> There is no magic switch. The output comes from the ckcfns.c nxtdir()
> function and it clearly outputs everything with only a "\n" as the
> terminator. This is true for C-Kermit and Kermit 95. Now in the case
> of MS-DOS Kermit connected to C-Kermit via a tty, the pseudoterminal
> may expand the LF into CR-LF. This is not the result of anything that
> C-Kermit is doing. If you were to connect MS-DOS Kermit to C-Kermit
> over a raw connection, you would see the same behavior.

If this is all there is to it, perhaps you can explain the following
packet log captured by MS-Kermit 3.16 connected as client to C-Kermit.
Since the linefeeds are escaped as "#J" in the Kermit Packets, it seems
clear to me that the pseudoterminal is not changing them to "#M#J", so
what is? I seems to me it must be C-Kermit since C-Kermit is the one
creating and ckecksumming these packets and if anything else were
changing their contents, the checksums wouldn't be correct.

Spack: ^A7 I~( @-#Y3~^!5% ___D!0M^M
Rpack: ^A9 Y~/ @-#Y3~^#J)0___O"U1@3^M
Spack: ^A% GD S^M
Rpack: ^A9 S~/ @-#Y3~^#J)0___M"U1@+^M
Spack: ^A7 Y~( @-#Y3~^#5% ___D!0_^M
Rpack: ^A2!XDIRECTORY ./*.XN^M
Spack: ^A)!Y CON(]B^M
Rpack: ^AF"A."U1"#AMJ*!A#120050823 20:36:40@ $#/^M
Spack: ^A%"Y.5!^M
Rpack: ^A #D"NZ-rw-r--r--~( 28 1997-12-02 16:25:14 -#M#J-rw-r--r--~&
1032 2002-10-10 09:03:22 Directions#M#J-rw~'-~' 702 1996-03-03 16:
07:28 Happy_Birthday#M#Jdrwx~&-~( 96 2004-07-27 17:31:28 Mail#M#J-r
w-r--r--~( 48 2~#0-01-01 09:19:21 Mi&PF^M
Spack: ^A%#Y/R9^M
Rpack: ^A $D"N[llenium#M#J-rw-r--r--~' 643 1997-11-24 15:16:06 addre
ss#M#Jdrwxr-xr-x~& 1024 2005-02-20 09:17:46 bin#M#Jdrwxr-xr-x~( 11
2005-06-04 17:05:21 bm -> public_html#M#J-rw~'-~& 8917 1996-08-20 17
:01:33 engr#M#J-rw-r--r--~& ~#62 200+:!^M
Spack: ^A%$Y+&1^M
Rpack: ^A %D"N\5-08-16 10:58:47 iftest#M#Jdrwxr-xr-x~& 3072 2005-08-
20 16:19:47 k#M#J-rwxr-xr-x~' 506 2005-08-16 11:43:35 kt1#M#J-rw-r-
-r--~' 876 2005-08-16 11:46:13 kt2#M#J-rw-r--r--~' 700 2005-08-16 1
1:48:56 kt3#M#J-rw-r--r--~& 1354 200,H7^M
Spack: ^A%%Y*A)^M
Rpack: ^A &D%%75-08-16 11:59:28 kt4#M#J-rw-r--r--~' 757 1998-04-20 1
2:54:57 lynx_bookmarks.html#M#Jdrwx~&-~& 1024 2004-11-03 19:22:03 m
ail#M#J-rw-r--r--~& 1061 1997-10-02 20:02:05 map#M#J-rw~'-~& 2467 1
996-06-22 07:39:32 maps#M#J-rw-r--r--~& 1884 2005-04-21 09:33:57 me
ss#M#J-rw~'-~% 13462 1996-07-25 12:40:35 nerd#M#Jdrwxr-xr-x~& 2048
2005-06-04 17:05:21 public_html#M#Jdrwxr-xr-x~( 96 2004-02-29 16:52:
51 slirp#M#J-rw~'-~& 4547 1996-10-16 07:59:54 stretching#M#J-rw-r--
r-,3]^M
Spack: ^A%&Y((A^M
Rpack: ^A 'D#IZ-~& 1401 2~#0-06-11 12:07:17 supertour_all#M#J-rw-r--
r--~& 2356 2004-09-05 18:44:14 t0#M#J-rw-r--r--~& 2355 2004-09-05 1
8:45:49 t1#M#J-rw~'-~& 2402 1996-06-30 09:31:05 toast#M#J-rw-r--r--
~& 1038 2004-06-15 15:38:50 z1#M#J-rw-r--r--~& 1374 2004-06-15 16:0
6:17 z2#M#J-rw-r--r--~' 773 2005-08-21 16:06:16 ~$z#M#J$J_^M
Spack: ^A%'Y)OY^M
Rpack: ^A 'D#IZ-~& 1401 2~#0-06-11 12:07:17 supertour_all#M#J-rw-r--
r--~& 2356 2004-09-05 18:44:14 t0#M#J-rw-r--r--~& 2355 2004-09-05 1
8:45:49 t1#M#J-rw~'-~& 2402 1996-06-30 09:31:05 toast#M#J-rw-r--r--
~& 1038 2004-06-15 15:38:50 z1#M#J-rw-r--r--~& 1374 2004-06-15 16:0
6:17 z2#M#J-rw-r--r--~' 773 2005-08-21 16:06:16 ~$z#M#J$J_^M
Spack: ^A%'Y)OY^M
Rpack: ^A%(Z"JJ^M
Spack: ^A%(Y!@Q^M
Rpack: ^A%)B*^[^M
Spack: ^A%)Y 'I^M

--
Mark Sapiro msapiro at value net The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan

Mark Sapiro wrote:

> If this is all there is to it, perhaps you can explain the following
> packet log captured by MS-Kermit 3.16 connected as client to C-Kermit.
> Since the linefeeds are escaped as "#J" in the Kermit Packets, it seems
> clear to me that the pseudoterminal is not changing them to "#M#J", so
> what is? I seems to me it must be C-Kermit since C-Kermit is the one
> creating and ckecksumming these packets and if anything else were
> changing their contents, the checksums wouldn't be correct.

C-Kermit is detecting that MS-DOS Kermit is not a compatible system
from an EOL perspective and transfers the data in TEXT mode.
Kermit 95 and MS-DOS Kermit have matching EOLs, and therefore sends
the data in BINARY mode. Since the source data is LF only in both
cases it gets translated by C-Kermit to MS-DOS Kermit but does not
get translated when sending Kermit 95 to MS-DOS Kermit.

Jeffrey Altman

On 2005-08-24, Jeffrey Altman wrote:
:> This appears to be a limitation on using MS-Kermit as a client with
:> K-95 as a server although I don't really know why there should be a
:> difference between K-95 and C-Kermit in this respect, but there clearly
:> is. Maybe there is some magic switch after all.
:
: There is no magic switch. The output comes from the ckcfns.c nxtdir()
: function and it clearly outputs everything with only a "\n" as the
: terminator. This is true for C-Kermit and Kermit 95.
:
This is a mistake. When Kermit is sending data using Kermit protocol in
text mode, it is supposed to use CRLF as the line terminator. I'll fix
this in C-Kermit, but the fix won't appear in K95 until the next release
happens, about which see:

http://www.columbia.edu/kermit/support.html

In the meantime, K95 fixes are available only directly from Jeff.

For those who haven't noticed, there has been some progress on C-Kermit in
the last couple months. See:

http://www.columbia.edu/kermit/ckdaily.html

Check this page every soften for new builds.

- Frank

On 2005-08-25, Mark Sapiro wrote:
: ...
: If this is all there is to it, perhaps you can explain the following
: packet log captured by MS-Kermit 3.16 connected as client to C-Kermit.
: Since the linefeeds are escaped as "#J" in the Kermit Packets, it seems
: clear to me that the pseudoterminal is not changing them to "#M#J", so
: what is? I seems to me it must be C-Kermit since C-Kermit is the one
: creating and ckecksumming these packets and if anything else were
: changing their contents, the checksums wouldn't be correct.
:
: Spack: ^A% GD S^M
: ...
: Rpack: ^A2!XDIRECTORY ./*.XN^M
: Spack: ^A)!Y CON(]B^M
: Rpack: ^AF"A."U1"#AMJ*!A#120050823 20:36:40@ $#/^M
: Spack: ^A%"Y.5!^M
: Rpack: ^A #D"NZ-rw-r--r--~( 28 1997-12-02 16:25:14 -#M#J-rw-r--r--~&
: 1032 2002-10-10 09:03:22 Directions#M#J-rw~'-~' 702 1996-03-03 16:
: 07:28 Happy_Birthday#M#Jdrwx~&-~( 96 2004-07-27 17:31:28 Mail#M#J-r
: w-r--r--~( 48 2~#0-01-01 09:19:21 Mi&PF^M
: ...
I have no clue but I'll look into it. I ran packet logs myself and I get
only #J without #M, in both directions, between C-Kermit and K95. Anyway
I'm surprised this phonomenon was never noticed before.

- Frank

Frank da Cruz wrote:

> I have no clue but I'll look into it. I ran packet logs myself and I get
> only #J without #M, in both directions, between C-Kermit and K95. Anyway
> I'm surprised this phonomenon was never noticed before.


Just to be clear on what we're talking about here, I've run some tests
with MS-Kermit, K-95 and C-Kermit as clients and K-95 and C-Kermit as
servers. The only problem case seems to be a dialed modem connection
with MS-Kermit as client and K-95 as server. In the other cases I
tried, the client and server seem to be able to negotiate what they
need from each other.

Note that I did NOT test MS-Kermit client and K-95 server over tcp/ip.

Based on clues from Jeff and Frank in this thread, I did try giving

rem set file type text
set file type text
rem dir

from MS-Kermit with a K-95 server, but this didn't help.

--
Mark Sapiro msapiro at value net The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan