Bluetooth: Mesh: Friend node unable relay message for lpn

[LingaoM]

As defined by Mesh Specification 1.0.1 Section 3.6.6.2 Friendship security.

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. OutMsg2 is sent secured using the master security credentials and therefore theFriend node and any other Relay node within range of the Low Power node can relay the message.OutMsg2, when it is relayed, will be retransmitted using the master security credentials.

If low power node publish with unicast address other than friend address, the friend node not relayed this message, no matter friend cred used.

zephyr/subsys/bluetooth/mesh/net.c

Lines 797 to 805 in ba9fd65

	/* Relay if this was a group/virtual address, or if the destination
	* was neither a local element nor an LPN we're Friends for.
	*/
	if (!BT_MESH_ADDR_IS_UNICAST(rx.ctx.recv_dst) ||
	(!rx.local_match && !rx.friend_match)) {
	net_buf_simple_restore(&buf, &state);
	bt_mesh_net_relay(&buf, &rx);
	}
	}

Another problem in bt_mesh_net_relay

zephyr/subsys/bluetooth/mesh/net.c

Lines 614 to 618 in ba9fd65

	if (rx->net_if == BT_MESH_NET_IF_ADV &&
	bt_mesh_relay_get() != BT_MESH_RELAY_ENABLED &&
	bt_mesh_gatt_proxy_get() != BT_MESH_GATT_PROXY_ENABLED) {
	return;
	}

This implementation obviously prohibit relay message for low power node, even local is friend node.

[trond-snekvik]

I think I need a bit more details here. The check in the first code snippet will relay anything that has a group destination address or a unicast destination other than itself or the LPN. If LPN sends a message to a random unicast address, the friend node will check this, and find that !BT_MESH_ADDR_IS_UNICAST(rx.ctx.recv_dst) is !true and (!rx.local_match && !rx.friend_match) is (!false && !false) => true, then relay the message, using &rx->sub->keys[SUBNET_KEY_TX_IDX(rx->sub)].msg for encryption. The source address of the message never comes into play. What am I missing?

The friend's relay to the LPN is done in transport, and happens before the second snippet:

zephyr/subsys/bluetooth/mesh/transport.c

Lines 1558 to 1565 in ba9fd65

	if (IS_ENABLED(CONFIG_BT_MESH_FRIEND) && rx->friend_match && !err) {
	if (seq_auth == TRANS_SEQ_AUTH_NVAL) {
	bt_mesh_friend_enqueue_rx(rx, pdu_type, NULL,
	seg_count, buf);
	} else {
	bt_mesh_friend_enqueue_rx(rx, pdu_type, &seq_auth,
	seg_count, buf);
	}

[LingaoM]

You may have misunderstood what I mean, I need to emphasize that lpn can publish messages, for example with unicast address other than friend node and use friend cred, and this message can be relayed by friends, as defined by Mesh Specification 1.0.1 Section 3.6.6.2 Friendship security.
Even if the bt_mesh_net_relay function is called, the message may not be relayed by friend, because the local node may not support relay or proxy or disabled.

[LingaoM]

The friend's relay to the LPN is done in transport, and happens before the second snippet:

zephyr/subsys/bluetooth/mesh/transport.c

Lines 1558 to 1565 in ba9fd65

	if (IS_ENABLED(CONFIG_BT_MESH_FRIEND) && rx->friend_match && !err) {
	if (seq_auth == TRANS_SEQ_AUTH_NVAL) {
	bt_mesh_friend_enqueue_rx(rx, pdu_type, NULL,
	seg_count, buf);
	} else {
	bt_mesh_friend_enqueue_rx(rx, pdu_type, &seq_auth,
	seg_count, buf);
	}

What I want to saying is the problem of the message being relayed by the friend node, not the problem of the friend node being relayed to lpn.

[LingaoM]

I think I need a bit more details here. The check in the first code snippet will relay anything that has a group destination address or a unicast destination other than itself or the LPN. If LPN sends a message to a random unicast address, the friend node will check this, and find that !BT_MESH_ADDR_IS_UNICAST(rx.ctx.recv_dst) is !true and (!rx.local_match && !rx.friend_match) is (!false && !false) => true, then relay the message, using &rx->sub->keys[SUBNET_KEY_TX_IDX(rx->sub)].msg for encryption. The source address of the message never comes into play. What am I missing?

The friend's relay to the LPN is done in transport, and happens before the second snippet:

zephyr/subsys/bluetooth/mesh/transport.c

Lines 1558 to 1565 in ba9fd65

	if (IS_ENABLED(CONFIG_BT_MESH_FRIEND) && rx->friend_match && !err) {
	if (seq_auth == TRANS_SEQ_AUTH_NVAL) {
	bt_mesh_friend_enqueue_rx(rx, pdu_type, NULL,
	seg_count, buf);
	} else {
	bt_mesh_friend_enqueue_rx(rx, pdu_type, &seq_auth,
	seg_count, buf);
	}

@trond-snekvik Sorry to cause you trouble, I confuse friend_match and friend_cred. But I still think there are some problems in handling relay. I tried to solve this problem through PR. Please review.