This mail got stuck in the mailing list system for a few days.

Last week I read the changes from the Agaidi alp_filedata.c and I implemented them.  There were some holes in the filedata.c file... I must have been sleepy or something when I wrote it.  I'm preparing for a big commit along with some STM32 stuff.  If you are working on the filedata ALP right now, send me a personal email and I will attach the latest file I have.  Otherwise, it will go on git soon ... I still have some testing to do.


On 28 Nov 2011, at 21:32, Matti Nordström wrote:

Hi.

Yes, I am reading the draft 014 like I said in my email. And I noticed the bug you corrected there. That kinda why I asked that if these bugs were also in the spec and not in the code.

Matti Nordström
Agaidi Oy



On Tue, Nov 22, 2011 at 8:41 PM, JP Norair <jpnorair@gmail.com> wrote:
Somehow I missed this email.

Make sure you are looking at Draft 014 of the spec.  I remember that there was a small bug (in the spec) about one of these ALPs, which I corrected in Draft 014.  I will look at this a bit later and verify that everything is OK, but I just want to make sure anyone following this thread knows about the change in Draft 014.

On the DASH7 Kavi webspace, there is a change-list between 012-013-014 in the form of commented spec files (PDF).  You can view the comments in most PDF readers (I have tested Adobe Reader, Apple Preview, and Skim).

Best,
JPN


On 15 Nov 2011, at 03:26, Matti Nordström wrote:

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
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1_______________________________________________
Opentag-developers mailing list
Opentag-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opentag-developers


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Opentag-developers mailing list
Opentag-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opentag-developers