The big problem is I don't see a way for a receiver to determine if a packet
wassent from a T1 stack or a T2 stack.
eric
2008/9/8 Michael Schippling <[EMAIL PROTECTED]>
>
> Wow! That new data obsfucation technique really works!
>
> So it looks like the main difference is in cc2420_header_t
> where, compared to the T1 micaZ AM.h, these:
> nxle_uint16_t src;
> nxle_uint8_t network;
> have been inserted before the AM message type. There is
> a 'permanent' message serial number added right after the
> header info, and I think the max length is 1 byte shorter.
> I also 'think' I remember that the T1 fields are little-end,
> which is what the "nxle_" would seem to indicate...whereas
> new improved nx_int is big-endian, just to expand the data
> obfuscation techniques all the way into the bit realm.
>
> Someone who was motivated to talk to T1 could probably
> translate all those nested structs into a congruent AM.h
> TOS_Msg definition and just ignore or default all the new
> fields. But it would mean re-compiling all the legacy apps.
>
> onward into the future
> MS
>
>
> Eric Decker wrote:
> > All paths are from the top of a current T2 source tree:
> >
> > tos/types/message.h contains the structure that pulls all the pieces
> > together.
> >
> > # 19 "/Users/cire/mm_t2/t2_cur/tinyos-2.x/tos/types/message.h"
> > typedef nx_struct message_t {
> > nx_uint8_t header[sizeof(message_header_t )];
> > nx_uint8_t data[28];
> > nx_uint8_t footer[sizeof(message_footer_t )];
> > nx_uint8_t metadata[sizeof(message_metadata_t )];
> > } __attribute__((packed)) message_t;
> >
> >
> > The header pieces are a union defined in platform_message.h. I have a
> > platform
> > called mm3 which is almost identical to the telosb (telosa is what
> > contains the
> > platform_message.h file).
> >
> > # 48 "/Users/cire/mm_t2/t2_mm3/tos/platforms/mm3/platform_message.h"
> > #line 45
> > typedef union message_header {
> > cc2420_header_t cc2420;
> > serial_header_t serial;
> > } message_header_t;
> >
> > typedef union TOSRadioFooter {
> > cc2420_footer_t cc2420;
> > } message_footer_t;
> >
> > #line 54
> > typedef union TOSRadioMetadata {
> > cc2420_metadata_t cc2420;
> > serial_metadata_t serial;
> > } message_metadata_t;
> >
> >
> >
> >
> > For the radio part we see:
> >
> > # 39 "/Users/cire/mm_t2/t2_cur/tinyos-2.x/tos/chips/cc2420/CC2420.h"
> > typedef uint8_t cc2420_status_t;
> > #line 66
> > #line 49
> > typedef nx_struct cc2420_header_t {
> > nxle_uint8_t length;
> > nxle_uint16_t fcf;
> > nxle_uint8_t dsn;
> > nxle_uint16_t destpan;
> > nxle_uint16_t dest;
> > nxle_uint16_t src;
> > nxle_uint8_t network;
> > nxle_uint8_t type;
> > } __attribute__((packed))
> >
> > cc2420_header_t;
> >
> >
> > #line 71
> > typedef nx_struct cc2420_footer_t {
> > } __attribute__((packed)) cc2420_footer_t;
> > #line 97
> > #line 81
> > typedef nx_struct cc2420_metadata_t {
> > nx_uint8_t rssi;
> > nx_uint8_t lqi;
> > nx_uint8_t tx_power;
> > nx_bool crc;
> > nx_bool ack;
> > nx_bool timesync;
> > nx_uint32_t timestamp;
> > nx_uint16_t rxInterval;
> > } __attribute__((packed))
> >
> > For the serial part we see:
> >
> > # 72 "/Users/cire/mm_t2/t2_cur/tinyos-2.x/tos/lib/serial/Serial.h"
> > #line 112
> > typedef nx_struct serial_header {
> > nx_am_addr_t dest;
> > nx_am_addr_t src;
> > nx_uint8_t length;
> > nx_am_group_t group;
> > nx_am_id_t type;
> > } __attribute__((packed)) serial_header_t;
> >
> >
> > #line 120
> > typedef nx_struct serial_packet {
> > serial_header_t header;
> > nx_uint8_t data[];
> > } __attribute__((packed)) serial_packet_t;
> >
> >
> > #line 125
> > typedef nx_struct serial_metadata {
> > nx_uint8_t ack;
> > } __attribute__((packed)) serial_metadata_t;
> >
> >
> > 2008/9/7 Michael Schippling <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]
> >>
> >
> > OK I found TEP 111
> http://www.tinyos.net/tinyos-2.x/doc/html/tep111.html
> > which does a nice job of explaining why we "need" so many levels
> > of data obfuscation, but doesn't actually show what the final
> > structs are and what's the difference. I presume the 2420 headers
> > must be identical because they are part of 802.11.14 (I think...).
> > It's hard to imagine that the low level radio code would need (much)
> > massaging in order to make T1&2 compatible for a one-off system.
> >
> > Since I'm not now nor ever have been a T2'er, could someone post
> > or point to the two structs for me?
> >
> > thanks
> > MS
> >
> > Eric Decker wrote:
> > >
> > >
> > > 2008/9/7 Renee Azhen <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>
> > > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]
> >>>
> > >
> > > yep, Eric, I want to communicate by radio.
> > > In T2, the message format_t is named msaage_t, and in T1, it
> is
> > > named TOS_msg, and it is almost different. So each nodes in
> > > different T# can't analyze other type radio message as
> expected.
> > >
> > >
> > > Not sure what you mean by "almost different". Slightly different?
> > >
> > >
> > > Can we revise the code in the mac-lay of T2 to receive and
> > analysze
> > > radio message send by T1 node?
> > >
> > >
> > > It is possible. It would have to be done at a fairly low level
> > in the
> > > stack. My gut feeling is you'd be biting
> > > off a lot. Asking for lots of problems.
> > >
> > > What problem are you trying to solve? In other words what are you
> > > trying to do with the node that
> > > is communicating using the T1 stack?
> > >
> > >
> > > Can we move on by some other method to resolve this problem,
> then
> > > let them communicate between different platform. Or
> > definitely no way?
> > >
> > >
> > > A different approach would be to build a T1-T2 gateway. A node
> > that has
> > > two radios or possibly one radio
> > > attached to two stacks. But this too seems like more trouble
> > then it is
> > > worth.
> > >
> > >
> > >
> > > thanks
> > > zhijian
> > > */Eric Decker <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>/* 写道：
> > >
> > > Communicate in what way? Using the radio?
> > >
> > > It is my understanding that there is a small difference
> > between
> > > the packet format in
> > > T2 vs. T1. I would recommend looking at message_t for the
> > > communications medium
> > > used for T2. I don't remember what the packet structure
> is
> > > called in T1 but that is
> > > what you want to compare against.
> > >
> > > That is where I would start.
> > >
> > > eric
> > >
> > >
> > > 2008/9/6 Renee Azhen <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>
> > > <mailto:[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>>>
> > >
> > > hi, all,
> > > Most of my nodes are programed with tinyos 2.0, but
> > there is
> > > a message sender is programed with tinyos 1.x.
> > >
> > > It is possble to let the nodes with tinyos 2.0
> > receive the
> > > msg sent by tinyos 1.x??
> > > thanks
> > > zhijian
> > >
> >
> ------------------------------------------------------------------------
> > > 雅虎邮箱，您的终生邮箱！ <http://cn.mail.yahoo.com/>
> > > _______________________________________________
> > > Tinyos-help mailing list
> > > [email protected]
> > <mailto:[email protected]>
> > > <mailto:[email protected]
> > <mailto:[email protected]>>
> > >
> >
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
> > >
> > >
> > >
> > >
> > > --
> > > Eric B. Decker
> > > Senior (over 50 :-) Researcher
> > > Autonomous Systems Lab
> > > Jack Baskin School of Engineering
> > > UCSC
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------
> > > 雅虎邮箱，您的终生邮箱！ <http://cn.mail.yahoo.com/>
> > >
> > >
> > >
> > >
> > > --
> > > Eric B. Decker
> > > Senior (over 50 :-) Researcher
> > > Autonomous Systems Lab
> > > Jack Baskin School of Engineering
> > > UCSC
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Tinyos-help mailing list
> > > [email protected]
> > <mailto:[email protected]>
> > >
> >
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
> >
> >
> >
> >
> > --
> > Eric B. Decker
> > Senior (over 50 :-) Researcher
> > Autonomous Systems Lab
> > Jack Baskin School of Engineering
> > UCSC
> >
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
Autonomous Systems Lab
Jack Baskin School of Engineering
UCSC
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
