Bug in Shared_Data_sendData or WP Stack

[E-Heerschap]

Hi,

There is unexpected behaviour occurring within the shared data library that I think may either be 1) a bug in the library or 2) a bug in the Wirepas stack.

I believe an issue in the Shared_Data_sendData function of the library. On line 479 the stack is requested to send the data. If the stack returns a APP_LIB_DATA_SEND_RES_ACCESS_DENIED response the library removes the tracking callback on line 484. A bug has just occurred because internally the Wirepas Stack has not removed the tracking id.

How does this cause unexpected behaviour?

If we make another call to Shared_Data_sendData the caller is returned a APP_LIB_DATA_SEND_RES_INVALID_TRACKING_ID response. Not from line 462 but from line 479. This occurs because the tracking id is replaced with the internal table's tracking id on line 471 which causes the tracking id to match the id previously used and still stored internally by the Wirepas Stack.

The conditions under which I have managed to make this occur is when sending a non-provisioning packet while the system is open joining / provisioning. This causes the provisioning process to fail sending packets using the shared data library and is the root cause of the issue outlined in #64. If the proposed solution is to not send non-provisioning packets while provisioning, then the positioning library may need some amendments as it is the culprit for sending a packet during the open joining / provisioning process. This is because it sends a packet after a scan ends which happens after the scanning for joining beacons occurs (and the joining network is joined).

---

Potential Solution

For now, I have implemented a solution which does not remove the tracking id from the internal table if APP_LIB_DATA_SEND_RES_INVALID_TRACKING_ID is returned by changing line 482 to:

if (res != APP_LIB_DATA_SEND_RES_SUCCESS && res != APP_LIB_DATA_SEND_RES_ACCESS_DENIED && sent_cb != NULL)

However, I am uncertain if this would be the "correct" solution and if this is even the intended behaviour by the Wirepas Stack.

---

Please let me know if I have overlooked anything or there are follow up questions.

[GwendalRaoul]

Hello,

Thanks for the very detailed description.
We are doing some further investigation and testing internally, but it seems that your are right, and that there is a bug in the stack.
Once investigation is done, I'll update the issue here.

Thanks again!
Gwendal