[Tinyos-devel] Re: [net2-wg] fwdbusy bug in LqiForwardingEngineP.nc

[Philip Levis]

On Feb 12, 2008, at 4:36 PM, Omprakash Gnawali wrote:

> On Feb 12, 2008 3:58 PM, Philip Levis <pal at cs.stanford.edu> wrote:
>>
>> On Feb 12, 2008, at 2:40 PM, Omprakash Gnawali wrote:
>>
>>> I see two problems with fwdbusy variable:
>>>
>>> 1. In static void forward(message_t* msg), if the send call fails,
>>> fwdbusy is set to TRUE but it can never be set to FALSE again. I  
>>> think
>>> we should set it to TRUE only if the send call returns a success.  
>>> The
>>> forward function was introduction in revision 1.2.
>>>
>>> 2. event void SubSend.sendDone(message_t* msg, error_t success),  
>>> if we
>>> haven't exhausted all the retries, we return regardless of the  
>>> outcome
>>> of send. If the send call fails, we won't get a chance to set  
>>> fwdbusy
>>> to FALSE. The return statement was added in version 1.4.
>>>
>>> It will be great if Phil, as an author, could take a look at these
>>> issues.
>>>
>>
>> What is causing the send call to fail? Is the problem here that LQI
>> is assuming the AM layer is on? If the LQI implementation is correct,
>> then it should not be calling Send.send when there is already a send
>> pending.
>>
>> Phil
>>
>
> Trying to send when the radio is off.
>

Right. Just setting fwdbusy properly won't fix the problem, because  
you won't start forwarding when the radio comes back on. The CTP  
answer to this is to monitor the radio state via SplitControl and act  
accordingly. I'll apply the same approach to MLQI.

Phil