Check valid source in client status callback for server status message

[Armin]

In the On Off Client Model in the nRF5 SDK for Mesh 15.0.0 (nRF5-SDK-for-Mesh/models/simple_on_off/src/simple_on_off_client.c) there is a check in the client callback handler handle_status_cb() for a valid source address.

According to the comment of the function is_valid_source() it is checked "if the message received was from the address corresponding to the clients publish address". As can be seen in the code in line 100 (publish_address.value != p_message->meta_data.src.value) the check actually takes the unique address of the node id of the server resp. the element of the server that published the status message and compares it with the publish address that is associated with the client model to which the callback belongs to.

Obviously, this only works if the client directly addresses the server via Unicast. If the client uses Groupcast, this check will never succeed!

To make this work also with Groupcasts I have to comment out the call of is_valid_source() in handle_status_cb() which of course is only a workaround. The correct fix would be to add the Groupcast case also in is_valid_source(). As I don't know exactly how to do that I would recommend you to make up your mind and add an appropriate fix in the next release of the Mesh Models.

[Hung Bui]

Hi Armin, 

 

Sending reliable message to a group address is not recommended by spec. 

If an element transmits a message to more than one element, for example it has set the destination address to a group address, the element may not know how many elements may respond to the message. It is not recommended to send an acknowledged message to the all-nodes address. To increase the probability of successful delivery of messages, the sending element should determine how many message retransmissions are required before it considers that all the nodes that should have received the message have actually received it.

Instead the client can wait for a status broadcast from  servers. The server can be configured to send automatically after receiving a non-reliable message from the client. 

[Armin]

That's exactly what I do: my client waits for a status broadcast from a server. Both client subscription and server publication are configured to the same group address. Server sends the status using the function generic_on_off_server_status_publish() from the Generic On Off Server Model. This leads to a call of the mentioned function handle_status_cb() in the Generic On Off Client Model.

[Hung Bui]

Hi Armin, 

 

You are right. We will ignore the message if it's not from the publication address of the client. It's only because in our design we don't plan to process status from a group address. 

 

I guess it wouldn't harm to process all packets sent to the subscribed group addresses or the unicast address of the client. 

Basically the is_valid_source() can be removed. We will check with the Mesh team to see if it's really needed. 

[qmorrison]

Hi, I'm a little confused here... From the Bluetooth Model Spec:

According to the spec, a Status message is an unacknowledged message, aka NOT a reliable message...

[Hung Bui]

Yes it's a unacknowledge message. But we are checking if the unacknowledge message was from the server that we expected to receive that status or not.