Hello,

I've been testing the filesystem ALP and I found some possible discrepancies between the functionality in alp_filedata.c and the specification. Especially in the response messages.

Read data message
The response message to Read data message contained only the read data in the payload, but according to the spec (draft 14 p. 80) the message should also always contain the File ID, Start Byte Offset & Bytes Accessing bytes as well. Here is my proposed fix to this:

else {
    limit = (limit > fp->length) ? fp->length : limit;

    if (inc_header) {
        if ((out_q->putcursor+6) >= out_q->back) {
            goto sub_filedata_overrun;
        }
        data_out += 10; /// AGAIDI. Add the offset & span bytes as well
        q_writeshort_be(out_q, vworm_read(header + 4)); // id & mod
        q_writeshort(out_q, vworm_read(header + 0));    // length
        q_writeshort(out_q, vworm_read(header + 2));    // alloc
    }
    else {
        /// AGAIDI. The response should always have the file ID, start offset & span according to the spec!
        data_out += 5;
        q_writebyte(out_q, file_id);
    }
    q_writeshort(out_q, offset);
    q_writeshort(out_q, limit/*span*/);
    for (; offset<limit; offset+=2, span-=2, data_out+=2) {

The read data message handling still has one bug that haven't fixed. According to the spec (p. 79) when the Bytes Accessing byte is 0, all bytes until the end of file should be accessed. This does not happen at the moment, instead no data is read.

Write Data message
According to the spec (p. 79) an error message should always be returned when the respond bit is on, even when no error has occurred. This was not the case though, instead a corrupt ALP message was sent. Here's my proposed fix:

sub_filedata_senderror:
/// AGAIDI. We must always send an error response when response bit is on AND a write message is being processed
/// regardless of the error value!
if (respond && ((err_code != 0) || (file_mod & VL_ACCESS_W))) {
    if ((out_q->putcursor+2) >= out_q->back) {
        goto sub_filedata_overrun;
    }
    q_writebyte(out_q, file_id);
    q_writebyte(out_q, err_code);
    q_markbyte(in_q, span);         // go past any leftover input data
    data_out += 2;
}


Were these actually bugs in the code or are the errors in the specification (which means I just wasted my time fixing these :D ) or am I completely wrong here?


Matti Nordström
Agaidi Oy