I can not see that the ntoh/hton mixup that I found is fixed in r5216 - IPAddressP.nc If this is a bug, as was indicated the headers will be wrong but work due to a double fault... (and the removal of dependency of CC2420 is not done either, maybe the panid/saddr should be cached, and maybe there need to be some atomic blocks)
/RogerL Index: IPAddressP.nc =================================================================== --- IPAddressP.nc (revision 5215) +++ IPAddressP.nc (working copy) @@ -29,7 +29,7 @@ module IPAddressP { provides interface IPAddress; uses { - interface CC2420Config; + interface ActiveMessageAddress; interface LocalIeeeEui64; } } implementation { @@ -37,14 +37,14 @@ command bool IPAddress.getLLAddr(struct in6_addr *addr) { // ieee_eui64_t eui = call LocalIeeeEui64.getId(); // memcpy(&addr->s6_addr[8], eui.data, 8); - ieee154_panid_t panid = call CC2420Config.getPanAddr(); - ieee154_saddr_t saddr = call CC2420Config.getShortAddr(); + ieee154_panid_t panid = call ActiveMessageAddress.amGroup(); + ieee154_saddr_t saddr = call ActiveMessageAddress.amAddress(); memclr(addr->s6_addr, 16); addr->s6_addr16[0] = htons(0xfe80); addr->s6_addr16[4] = htons(panid); - addr->s6_addr16[5] = ntohs(0x00FF); - addr->s6_addr16[6] = ntohs(0xFE00); + addr->s6_addr16[5] = htons(0x00FF); + addr->s6_addr16[6] = htons(0xFE00); addr->s6_addr16[7] = htons(saddr); return TRUE; @@ -73,7 +73,7 @@ } command error_t IPAddress.resolveAddress(struct in6_addr *addr, ieee154_addr_t *link_addr) { - ieee154_panid_t panid = call CC2420Config.getPanAddr(); + ieee154_panid_t panid = call ActiveMessageAddress.amGroup(); if (addr->s6_addr16[0] == htons(0xfe80)) { if (addr->s6_addr16[5] == htons(0x00FF) && @@ -103,13 +103,13 @@ command bool IPAddress.isLocalAddress(struct in6_addr *addr) { ieee_eui64_t eui = call LocalIeeeEui64.getId(); - ieee154_panid_t panid = call CC2420Config.getPanAddr(); - ieee154_saddr_t saddr = call CC2420Config.getShortAddr(); + ieee154_panid_t panid = call ActiveMessageAddress.amGroup(); + ieee154_saddr_t saddr = call ActiveMessageAddress.amAddress(); if (addr->s6_addr16[0] == htons(0xfe80)) { // link-local - if (addr->s6_addr16[5] == ntohs(0x00FF) && - addr->s6_addr16[6] == ntohs(0xFE00)) { + if (addr->s6_addr16[5] == htons(0x00FF) && + addr->s6_addr16[6] == htons(0xFE00)) { if (ntohs(addr->s6_addr16[4]) == panid && ntohs(addr->s6_addr16[7]) == saddr) { return TRUE; @@ -131,8 +131,7 @@ return FALSE; } - event void CC2420Config.syncDone( error_t err ) { - + async event void ActiveMessageAddress.changed() { + /* As long as we do not cache address and group this can be empty */ } - } Index: IPAddressC.nc =================================================================== --- IPAddressC.nc (revision 5215) +++ IPAddressC.nc (working copy) @@ -25,9 +25,9 @@ provides interface IPAddress; } implementation { - components IPAddressP, CC2420ControlC, LocalIeeeEui64C; + components IPAddressP, ActiveMessageAddressC, LocalIeeeEui64C; IPAddress = IPAddressP; - IPAddressP.CC2420Config -> CC2420ControlC; + IPAddressP.ActiveMessageAddress -> ActiveMessageAddressC; IPAddressP.LocalIeeeEui64 -> LocalIeeeEui64C; } -- Roger Larsson, Research Engineer Division of Mobile Networking and Computing Luleå University of Technology SE-931 87 Skellefteå Phone: +46 (0)910 58 53 18 Mobile: +46 (0)70 531 72 58 ________________________________________ Från: tinyos-help-boun...@millennium.berkeley.edu [tinyos-help-boun...@millennium.berkeley.edu] för Silvan Nellen [nel...@cmc.ca] Skickat: den 8 november 2010 15:01 Till: Stephen Dawson-Haggerty Kopia: tinyos-help@millennium.berkeley.edu Ämne: Re: [Tinyos-help] CC2420: length field in 802.15.4 header is used without initialisation, fcf field not set in any case Hi Stephen Yes, the problems are fixed in revision 5215. Thank you! Silvan -----Original Message----- From: sdh...@gmail.com [mailto:sdh...@gmail.com] On Behalf Of Stephen Dawson-Haggerty Sent: November 6, 2010 1:41 AM To: Silvan Nellen Cc: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] CC2420: length field in 802.15.4 header is used without initialisation, fcf field not set in any case Yes, you are correct. Thanks for suggesting the changes -- can you check out 5215 and verify that this fixes the problem? Thanks, Steve On Thu, Nov 4, 2010 at 9:34 PM, Silvan Nellen <nel...@cmc.ca> wrote: > Hello, > > > > I have two issues regarding revision 5214 (the newest at the time of > writing) of the trunk (https://tinyos-main.googlecode.com/svn/trunk): > > > > 1. > > After updating from revision 5160 to 5214, Zigbee communication stopped > working on Shimmer. Using a Zigbee packet sniffer I found out that all > updated nodes send packets with the length field of the header set to an > invalid value. After looking at the source code of the CC2420 driver > (Shimmer uses CC2420) I found the reason why: the code that sets the length > field in the header had been commented out > (/trunk/tos/chips/cc2420/csma/CC2420CsmaP.nc, line 136)! The change was > introduced in r5174. > > > > Am I missing something or is this a serious bug that needs to be fixed ? > > > > 2. > > Another CC2420 related issue is that the fcf field in the header is not set > in some cases. In the current version of the trunk the fcf field is set in > the RadioResource.granted() event handler in > /trunk/tos/chips/cc2420/csma/CC2420ActiveMessageP.nc. However this event is > not triggered if access to the radio is granted immediately (line 104), in > this case fcf remains uninitialized! > > > > Why was the initialization fcf code moved from the Send.send() command in > tos/chips/cc2420/csma/CC2420CsmaP.nc to RadioResource.granted() ? What would > be the cleanest way to fix this ? Move the initialization code back to > CC2420CsmaP.nc? > > > > Regards, > > Silvan Nellen > > _______________________________________________ > Tinyos-help mailing list > Tinyos-help@millennium.berkeley.edu > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > -- stephen dawson-haggerty http://cs.berkeley.edu/~stevedh uc berkeley wireless and embedded systems lab berkeley, ca 94720 _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help