The java listen app should display all bytes. For debugging you could use the printf library (see apps/tests/TestPrintf) on the BaseStation and make a hexdump of your entire message_t. Maybe also make sure message_t payload is big enough (e.g. for cc2420 put "CFLAGS += -DTOSH_DATA_LENGTH=X", where X is max payload, in Makefile), and, of course, message_t definition must be the same on sender and basestation.
Jan On Tue, Feb 5, 2013 at 7:04 PM, Filip Jurnečka <[email protected]> wrote: > Thanks, > > i've already seen that tutorial and yes, it works fine. The problem I am > having is most likely somewhere deeper. I am using the hardware in-line > security. I have specified the requested parameters for the SECCTRL > registers so that they would add 4-byte CBC-MAC (using some specified key) > to the message, but when I catch the message with the BS app, it overrides > the last byte. I was thinking about deeper examination with the ListenRaw > tool, but didn't get it working as expected. Is the BS/Listen app > displaying all the received bytes? > > Oh and I am specifying the the length of the message to send (via the > AMSend.send()) to be the size of my payload data. > > Filip > > On Tue, 05 Feb 2013 18:11:36 +0100, Jan Hauer <[email protected]> > wrote: > >> Hi Filip, >> >> the structure of serial AM packets is explained here: >> http://docs.tinyos.net/tinywiki/index.php/Mote-PC_serial_communication_and_SerialForwarder#BaseStation_and_net.tinyos.tools.Listen >> About the last byte: check once more that you pass the correct payload >> length, because in the example it seems that msg len field is 3 (not >> 4). >> >> Jan >> >> >> On Tue, Feb 5, 2013 at 3:05 PM, Filip Jurnečka >> <[email protected]> wrote: >>> Ok, I did that. I know the byte 80 is in fact my defined AM type. Now it >>> is still an open question for me why does the CBC-MAC override the last >>> byte in the packet? >>> >>> Best, >>> Filip Jurnecka >>> >>> On Tue, 05 Feb 2013 14:58:18 +0100, wasif masood <[email protected]> >>> wrote: >>> >>>> Checkout the CC2420 datasheet for details regarding the 802.15.4 header >>>> strucutre. >>>> >>>> On Tue, Feb 5, 2013 at 2:17 PM, Filip Jurnečka >>>> <[email protected]>wrote: >>>> >>>>> Hi there. >>>>> >>>>> I wonder how the packet delimiters work. Say I have two packets. If >>>>> sent >>>>> normally, the BS app displays them as: >>>>> 00 FF FF 00 01 00 22 80 >>>>> 00 FF FF 00 01 01 22 80 00 >>>>> >>>>> Now I don't know what the first 00 is, but the next FFFF is the >>>>> broadcast >>>>> address, the 0001 should be my address, the next 00/01 defines the >>>>> length >>>>> of the packet data. What is the 22? What is the 80? Is it the >>>>> delimiter >>>>> of >>>>> the data to follow? Obviously, the last 00 is the data sent. >>>>> >>>>> Now it gets more interesting, if I enable the in-line CBC-MAC with 4 >>>>> bytes >>>>> output, I get the following. >>>>> 00 FF FF 00 01 03 22 B7 E2 4C FB >>>>> 00 FF FF 00 01 04 22 80 71 36 57 EE >>>>> >>>>> The question is mainly about the fact that the output is overriding >>>>> the >>>>> last byte of the unauthenticated message, i.e. the delimiter or the >>>>> payload byte. Any ideas why and how to fix it? >>>>> >>>>> Best regards, >>>>> Filip Jurnecka >>>>> _______________________________________________ >>>>> Tinyos-help mailing list >>>>> [email protected] >>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> Tinyos-help mailing list >>> [email protected] >>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
