Skip to content

SET SEND PACKET-LENGTH doesn't work properly #19

@davidrg

Description

@davidrg

This is one was found by someone trying to interface with an HP calculator. Apparently C-Kermit would still send packets larger than the set maximum packet length causing problems.

I did a little investigation into it a few months back and I think I found the issue, though I've been hesitant to do anything about it so far as I'm less familiar with this part of the application and I don't want to accidentally break something else in the process. I suspect reason for the change which introduced the issue is described by the "26-29 Oct 2021" entry in the C-Kermit Update History.

The SET SEND PACKET-LENGTH command sets the spsiz variable here:

ckermit/ckuus7.c

Line 6691 in 0c0c21f

spsiz = spmax = spsizr = y; /* Set it and flag that it was set */

sdata() passes spsiz into getpkt() and bgetpkt() here:

ckermit/ckcfns.c

Line 4776 in 0c0c21f

len = getpkt(spsiz,1);

In C-Kermit 6, getpkt() just subtracted 5 from that value, while C-Kermit 7 and 8 instead throw it away and ask maxdata() for the maximum data length, and this function looks at spsiz to work that out:

ckermit/ckcfns.c

Lines 1633 to 1649 in 0c0c21f

maxdata() { /* Get maximum data length */
int n, len;
debug(F101,"maxdata spsiz 1","",spsiz);
if (spsiz < 0) /* How could this happen? */
spsiz = DSPSIZ;
debug(F101,"maxdata spsiz 2","",spsiz);
n = spsiz - 5; /* Space for Data and Checksum */
if (n > 92 && n < 96) n = 92; /* "Short" Long packets don't pay */
if (n > 92 && lpcapu == 0) /* If long packets needed, */
n = 92; /* make sure they've been negotiated */
len = n - bctl; /* Space for data */
if (n > 92) len -= 3; /* Long packet needs header chksum */
debug(F101,"maxdata len 1","",len);
if (len < 0) len = 10;
debug(F101,"maxdata len 2","",len);
return(len);
}

In C-Kermit 305(alpha05), the call to maxdata() was commented out so now getpkt() and bgetpkt() always use the passed in value of spsiz without reducing it to account for the checksum, etc, like C-Kermit 6 did. I think this has effectively turned set send packet-length into more of a "set send data-length":

ckermit/ckcfns.c

Lines 1683 to 1686 in 0c0c21f

#ifdef COMMENT
/* No - bufmax is a parameter */
bufmax = maxdata(); /* Get maximum data length */
#endif

I think spsiz might also get set during the negotiation phase, so if the far end says the maximum packet it will receive is 50, then there is a possibility C-Kermit may send packets slightly larger than that. My notes from when I looked at this a few months back are a little vague here and I haven't had time to double check this.

A call to maxdata() in rpar() has also been commented out, with the maximum data field length hard-coded to 94 - this was perhaps the real fix for the issue mentioned in the update history:

ckermit/ckcfns.c

Lines 4952 to 4956 in 0c0c21f

#ifdef COMMENT
max = maxdata(); /* Biggest data field I can send */
#else
max = 94;
#endif /* COMMENT */

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions