I'm just starting to deal with T2's Listen and ListenRaw (under Ubuntu) and found that ListenRaw has some kind of timing and error issues. If I run it in a shell window it just hangs around and prints no message data, but if I step through it in Eclipse I get a few lines of output before (it appears) that the read() returns a -1 and the main loop exits. However the internal read thread is still running so the process just hangs at that point. I don't think I have the patience to compare its operation to Listen which seems to work OK, so I'm probably going to just drink the kool-aide and move on.
I did run across a mention of an extra byte in the message header when using some kind of secure messaging protocol, probably in one of the TEPs (111, 113, 116 seem to deal with messaging). That would offset your payload start, and maybe even mess up the length calculation. In the course of putzing with this I found that the tinyos.jar contains the net/tinyos/packet/Serial.class which is used by Packetizer, but the Serial.java file is missing from my source tree. I can re-compile the source I have if I include the given tinyos.jar but can't actually reconstruct the jar itself. I found a couple of instances on this list of previous complaints about this file being missing, but no offered solutions. I got my source tree from here: git clone -v git://github.com/tp-freeforall/prod tinyos-2.x as per E.Decker's instructions at: https://github.com/tp-freeforall/prod/blob/tp-master/00b_Development_Environment MS On 02/06/2013 02:59 AM, Jan Hauer wrote: > 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 > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
