[Tinyos-devel] 2.0.2 CC2420

Jun yanjunrockets at gmail.com
Tue Feb 12 14:49:38 PST 2008


Phil,

Thank you very much for your clarification. I remember 802_11 is taking the
same approach by only including destination address in an ACK frame,
which suffers from the same problem you described.

We are trying to develop a "pure" software ACK now, but we don't know
how to "format" an ACK. The only information we have on the format is
from CC2420ReceiveP.nc as follows
      if (((( header->fcf >> IEEE154_FCF_ACK_REQ ) & 0x01) == 1)
          && (header->dest == call amAddress())
          && ((( header->fcf >> IEEE154_FCF_FRAME_TYPE ) & 7) ==
IEEE154_TYPE_DATA)) {
          ...
      }

In order to generate a legitimate ACK in software, is it enough to just fill
in
the header->fcf,  header->dest fields in cc2420_header_t structure as
indicated by the above code. Any advice or suggestion will be greatly
appreciated.

Thank you,

Jun

On Feb 12, 2008 3:20 PM, Philip Levis <pal at cs.stanford.edu> wrote:

>
> On Feb 12, 2008, at 12:58 PM, Jun wrote:
>
> > Hi David,
> >
> > Thank you very much for your prompt response.
> > Could you explain more on "the current ACK frame is inherently
> > broken"?
>
> The ACK does not contain the source address, only the sequence
> number. So you don't know who is acking. This means that you can get
> false positives. Some other node happened to receive a packet with
> the same sequence number and ACKs it; you think your destination
> received the packet when it didn't.
>
> Phil
>



-- 
--
Mailto: yanjunrockets at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080212/fcf6f274/attachment.htm


More information about the Tinyos-devel mailing list