Original author: jmatts...@dius.com.au (February 09, 2012 22:36:31)
What steps will reproduce the problem?
- Note the configured value of N_FRAGMENTS in IPDispatch.h
- Send the largest packet you can from TinyOS
- Observe that the number of fragments on the air is really N_FRAGMENTS-1, even though memory has been set aside for N_FRAGMENTS.
What is the expected output? What do you see instead?
All the memory reserved by the N_FRAGMENTS sized array of message_t should be available for use. Currently, IPDispatchP uses a round-about way of working out whether there are more fragments to send, and allocates a fragment buffer even if there are no fragments left to send, effectively wasting an entire message_t worth of RAM. The attached patch introduces a very small helper function in lib6lowpan_frag.c, and IPDispatchP is tweaked to check whether there are more fragments before allocating a fragment buffer. This allows BLIP to send packets using N_FRAGMENTS fragments, up from N_FRAGMENTS-1.
What version of the product are you using? On what operating system?
TinyOS 2.x, trunk/r5884
Please provide any additional information below.
Some fuzz possible, as we're using BLIP with an RF212 radio here and as such our tree has diverged slightly from trunk. Hand-merge should be trivial if it doesn't apply automatically.
Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=117
Original author: jmatts...@dius.com.au (February 09, 2012 22:36:31)
What steps will reproduce the problem?
What is the expected output? What do you see instead?
All the memory reserved by the N_FRAGMENTS sized array of message_t should be available for use. Currently, IPDispatchP uses a round-about way of working out whether there are more fragments to send, and allocates a fragment buffer even if there are no fragments left to send, effectively wasting an entire message_t worth of RAM. The attached patch introduces a very small helper function in lib6lowpan_frag.c, and IPDispatchP is tweaked to check whether there are more fragments before allocating a fragment buffer. This allows BLIP to send packets using N_FRAGMENTS fragments, up from N_FRAGMENTS-1.
What version of the product are you using? On what operating system?
TinyOS 2.x, trunk/r5884
Please provide any additional information below.
Some fuzz possible, as we're using BLIP with an RF212 radio here and as such our tree has diverged slightly from trunk. Hand-merge should be trivial if it doesn't apply automatically.
Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=117