Hi all,
Our radio stack checks that packet buffers are not modified in the
window between send() and sendDone() to prevent coding bugs from sending
out Very Nasty Packets (for example, the AM address and type of one
packet, (part of) payload of another). This check is getting triggered
regularly in an application that relies heavily on dissemination
(tos/net/lib/drip) and I think I've narrowed it down to
DisseminationEngineImplP's send buffer, m_buf.
Both DisseminationCache.newData and TrickleTimer.fired first check
whether the buffer is currently locked (m_bufBusy), but both
Receive.receive and ProbeReceive.receive blindly call sendObject without
checking. The comment at line 210 reads:
// Still not sure which of these is the best. Immediate send for
now.
sendObject( key );
// call TrickleTimer.reset[ key ]();
Why not call TrickleTimer.reset() and go through the regular machinery?
Alternatively, sendObject() could (should?) test m_bufBusy before
modifying the payload. That seems to me to be the most straightforward
solution, but I'm not certain of the reasoning behind the current
implementation.
Best,
Michiel
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
