Bluetooth: Mesh: Fixes Relay to frnd_cred message #29580
Conversation
LingaoM
requested review from
Vudentz,
jhedberg,
joerchan and
trond-snekvik
as code owners
subsys/bluetooth/mesh/net.c
Outdated
There was a problem hiding this comment.
I don't think the destination can be both an LPN and a proxy client at the same time, can it? I.e. this looks like an unnecessary check here.
There was a problem hiding this comment.
Sorry, obviously it should be friend_cred.
subsys/bluetooth/mesh/net.c
Outdated
There was a problem hiding this comment.
Please don't mix coding style cleanups into a patch with functional changes (you can still have them in the same PR but in separate commits)
subsys/bluetooth/mesh/net.c
Outdated
There was a problem hiding this comment.
Same here regarding coding style and functional changes
subsys/bluetooth/mesh/net.c
Outdated
There was a problem hiding this comment.
Could you explain this change a bit more? The protocol between LPN and Friend is timing and request-response based. Is there somewhere in the spec that says that it should use the RelayRetransmit state rather than the NetworkTransmit state?
There was a problem hiding this comment.
Please see Mesh Specification 1.0.1 Section 3.6.6.2 Friendship security for more information.
The Low Power node then decides to send two messages: OutMsg1 and OutMsg2. OutMsg1 is sentsecured using the friend security credentials and therefore only the Friend node will receive and relay thismessage. When the Friend node relays OutMsg1, the message will be retransmitted using the mastersecurity credentials.
subsys/bluetooth/mesh/net.c
Outdated
There was a problem hiding this comment.
Unless it breaks qualification, I think the old unicast address check should still be here. If a unicast message is going to a proxy node, there's no reason to relay it to the advertising bearer.
There was a problem hiding this comment.
Yes, it is suitable for white list, but if it is for black list, even unicast address does not mean it is required by proxy client.
There was a problem hiding this comment.
I am thinking, if blacklist filtering is enabled, if the unicast address is not in the blacklist, does it mean that the proxy client needs this unicast address? In this case, it does not need to be relayed through ADV bearer.
There was a problem hiding this comment.
Good point, I forgot the proxy puts the unicast addresses in the filters. I suppose we can only be sure of this check if the proxy is using a whitelist. Your original version was better, I didn't consider the blacklist.
If low power node publish with unicast address other than friend address, the friend node should relayed this message to all network interface. When Proxy feature enabled, message from gatt bearer should relay to adv bearer even relay feature disabled. Fixes: #29544 Signed-off-by: Lingao Meng <mengabc1086@gmail.com>
3 participants
If low power node publish with unicast address other
than friend address, the friend node should relayed
this message to all network interface.
Fixes: #29544
Signed-off-by: Lingao Meng mengabc1086@gmail.com