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

This is a discussion on 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 ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: MS-DOS Kermit client, Kermit-95 server, REMOTE DIRECTORY

  1. MS-DOS Kermit client, Kermit-95 server, REMOTE DIRECTORY

    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?


  2. Re: MS-DOS Kermit client, Kermit-95 server, REMOTE DIRECTORY

    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


  3. Re: MS-DOS Kermit client, Kermit-95 server, REMOTE DIRECTORY

    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

  4. Re: MS-DOS Kermit client, Kermit-95 server, REMOTE DIRECTORY

    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


  5. Re: MS-DOS Kermit client, Kermit-95 server, REMOTE DIRECTORY

    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

  6. Re: MS-DOS Kermit client, Kermit-95 server, REMOTE DIRECTORY

    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

  7. Re: MS-DOS Kermit client, Kermit-95 server, REMOTE DIRECTORY

    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

  8. Re: MS-DOS Kermit client, Kermit-95 server, REMOTE DIRECTORY


    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


+ Reply to Thread