Repeated tid in received message does not throw out message but causes repeated app layer call

[Billy-IV]

I am working on developing an application where the app layer tries to throw out messages if the message parameters are not valid.  One the parameters to validate is a TID which uses the TID validation from the model_common.c . I found a weird interaction. If a message is a retransmission with the same TID from the same source node instead of throwing the message out as a repeated transaction, the message is sent to the model layer multiple times until after the TID_VALIDATION_INTERVAL_US has expired.  Then it treats it as a new transmission.  The log below is from a test with the generic on_off example from the mesh 3.2 sdk.  The only modification I made was to model_common.c to add the LOG statements in lines 142 and 147.

What is causing this repeated calls of the model layer? How do I prevent this from happening?  Is there a function to abort the process or is it a setting somewhere?

[Billy-IV]

Wait, there was a response here saying this looked like a bug.  Now there is no response.  Does that mean it is not a bug? The bug is fixed?

[Heidi-Irene Harvey Sollie]

Hi!

Sorry about that, I responded and then realized I was mistaken and was just waiting for confirmation from the developers of the example.

But what you're seeing is the correct behavior. It looks like you are logging calls to handel_set() and expecting this to be called only if the TID is valid. As handle_set() is where the TID validation is done, it is supposed to be like this. TID validation is indeed a model layer concept, the stack does not know anything about TIDs and will pass on repeated messages to the mode layer. The generic_on_off_server implementation provides a set_callback setting upon initialization, this callback will only be called when the TID is new.

Hope this clears up your issue.

Best regards,

Heidi

[Billy-IV]

Heidi,

No, it does not clear up my issue.  The problem is that there is no way for messages with prohibited or invalid parameters to stop the RX calls from the access layer.

I send 2 messages.  One being a repeat of the other about 0.5s apart.  When my light node receives the message. I get 4 calls to the model layer callback, handle_set().  The repeated message is NOT thrown out.  The last "TID is new" registers the message as a new transaction even though it is not a new transaction because the lower layers are sending the second message up to the model layer repeatedly until the TID timer for TID validation has triggered. The TID timer callback makes any TID valid as a new transaction.  As such the second message is held onto until it is valid.  Thus the conditions of this sentence are met, "the generic_on_off_server implementation provides a set_callback setting upon initialization, this callback will only be called when the TID is new"  and the server application callback is called... 

I could have the TID indicate different actions similar to how the experimental level example operates.  However, my issue is the following.  There are models that have values designated as “prohibited” in the BLE v1.0.1 specifications.  Based on the mesh profile page 20, …”unassigned values can be marked as ‘Prohibited.’ These values shall never be used by an implementation, and any message received that includes a Prohibited value shall be ignored and shall not be processed and shall not be responded to.” 

The following models have prohibited values:

Generic OnOff 
Generic OnPowerUp
Generic Power
Generic Battery
Generic User Property
Generic Client Property
Sensor Setting
Sensor Setting Access
Time (time role)
Scene
    Scene Register
    Scene Schedule Register
    Scene store
    Scene Recall
    Scheduler Action Get
Light Lightness
Light CTL

My company has some prohibited values as well in our custom models. When working on coding and testing the validation for various fields, we realized that the TID validation did not provide an example of aborting any actions from the lower layers.  Attempting to ignore an invalid message causes the issue from my original post. 

Simply, what is causing the repeated call of handle_set() with the sending of a single message?

When I set the TID parameter to never validate, all the repeated calls are ignored, and the access layer eventually stops calling handle_set().  What is causing this cancellation at the lower layer?  How do I call that function?

Thank You,

Billy Ivy

[Heidi-Irene Harvey Sollie]

I see. I will get back to you on Monday when the person responsible for the example is back in the office. Hopefully, he'll be able to answer you in more detail than I am!

Best regards,

Heidi

[Billy-IV]

Heidi-Irene Harvey Sollie,

Have you been able to contact the developer? I have done more development and research.  While the repeated calls of the model callback is inefficient, it only really affects data requiring validation related to time or timers. 

As such, the TID tracker is faulty. It can allow repeated messages to be considered valid which in the case of certain models or implementations would cause improper behavior.

Regards,
Billy Ivy