[Tinyos-help] Bug in Tossim 2.0?

Omprakash Gnawali gnawali at usc.edu
Wed Sep 19 08:11:52 PDT 2007



Good catch! I changed the type of my_ll_addr to am_addr_t and
committed to the CVS.

- om_p

-----------------

Date: Wed, 19 Sep 2007 12:47:26 +0800
From: "Hao Shuai" <shuai.hao at gmail.com>
Subject: [Tinyos-help] Bug in Tossim 2.0?
To: tinyos-help at Millennium.Berkeley.EDU
Message-ID:
        <1d789a810709182147j6275f778yfd5a144d62862f59 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi all,

I'm not sure whether any of you notice the bug in Tossim under Tinyos 2.0.2.
When you increase the numbers of nodes in simulation (say from 200 to 500),
something strange happens in nodes' neighbor table. I digged a bit and found
it might due to inappropriate data type casting. The bug is in:

/opt/tinyos-2.x/lib/net/le/LinkEstimatorP.nc, line 657. "uint8_t i,
my_ll_addr;"

It should be "am_addr_t my_ll_addr". Casting am_addr_t (16 bits now) to
uint8_t just messes up everything, because this is called when a node
receives LEEP beacons and wants to update its outquality.

Actually I was working on Tinyos1.1.15 before release of 2.0.2.
Tinyos1.1.15also has similar bugs in Multihop Routing. The bug is in:

/opt/tinyos-1.x/tos/lib/Route/MultiHopLEPSM.nc, line 131. "uint8_t
findEntry(uint8_t id) {"

The "id" should be "uint16_t". When node ids go beyond 255, something
strange should happen also, because findEntry() is called to locate node
entry in neighbor table.

I like the use of am_addr_t in 2.0, which can reduce quite a lot chances to
misuse node ids. We should consist on this rather than a mix. :)

Regards,
Shuai


More information about the Tinyos-help mailing list