[Tinyos-devel] problem over writing metadata

Eric Decker cire831 at gmail.com
Sun Jul 5 01:28:45 PDT 2009


The message structure looks like:

typedef nx_struct message_t {
  nx_uint8_t header[sizeof(message_header_t)];
  nx_uint8_t data[TOSH_DATA_LENGTH];
  nx_uint8_t footer[sizeof(message_footer_t)];
  nx_uint8_t metadata[sizeof(message_metadata_t)];
} message_t;


In the serial receive code we have:

      case RECV_STATE_DATA:
        if (recvIndex < sizeof(message_t)) {
          receiveBuffer[recvIndex] = b;
          recvIndex++;
        }

Which says to keep receiving even though we have run over the end of the
data area and into the metadata.
I'd assert that this is a bug.  And that the size of received data should be
limited to only those fields that are
truely network data.

In the encaps work that I'm doing I've redefined the message structure to be


/*
 * We split out metadata and encap datacells.  Only network data
 * is a nx type.  Having metadata and encap non-nx generates better
 * code.
 */

typedef nx_struct netdata_t {
  nx_uint8_t  header[sizeof(message_header_t)];
  nx_uint8_t  data[TOSH_DATA_LENGTH];
  nx_uint8_t  footer[sizeof(message_footer_t)];
} netdata_t;

typedef struct {
  netdata_t netdata;
  uint8_t   metadata[sizeof(message_metadata_t)];
  uint8_t   encap;
  uint16_t  encap_size;
  uint16_t  encap_offset;
  uint8_t   pak_len;
} message_t;


And I limit the receive to the size of network data (netdata_t).

At some point the platform code will define a union or structure that will
define the metadata in native
types.  This will generate better code than having the metadata be a
nx_type.  I haven't done that yet
because I didn't want to deal with it just yet.


eric

-- 
Eric B. Decker
Senior (over 50 :-) Researcher
Autonomous Systems Lab
Jack Baskin School of Engineering
UCSC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090705/86c72da1/attachment.htm 


More information about the Tinyos-devel mailing list