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: [email protected]
[[email protected]] för Silvan Nellen
[[email protected]]
Skickat: den 8 november 2010 15:01
Till: Stephen Dawson-Haggerty
Kopia: [email protected]
Ä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: [email protected] [mailto:[email protected]] On Behalf Of Stephen
Dawson-Haggerty
Sent: November 6, 2010 1:41 AM
To: Silvan Nellen
Cc: [email protected]
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 <[email protected]> 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
> [email protected]
> 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
[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
