Bluetooth: Mesh: PTS Test failed in friend node

[LingaoM]

There are two issues related to friend.

- 1: MESH/NODE/FRND/FN/BV-14-C MESH/NODE/FRND/FN/BV-15-C

Both the above two tests require IUT to cache the data(netkey_update) sent by LT2 to LPN as a friend node. However, according to the log, LPN does not receive valid data, resulting in LT2(waiting for netkey_status) timeout exit.

• 2: Latest PTS 7.6.2 Add new testcase MESH/NODE/FRND/FN/BV-23-C

From the simple description of PTS, it can be inferred that the test friend relay the LPN message(refer #29580). However, this item also failed. The reason for the failure was that Low Tester did not receive the specified data. I read the log from the IUT and IUT has already relayed(?_?).

[LingaoM]

zephyr/subsys/bluetooth/mesh/subnet.c

Lines 616 to 620 in 41b7e5d

	struct bt_mesh_friend *frnd = &bt_mesh.frnd[i];
	if (!frnd->established) {
	continue;
	}

@trond-snekvik
Here is a bug that I have found. I plan to submit PR together to solve these problems, but it is necessary to tell you. It will lead to the failure to establish a friendship relationship at all. The reason is that the friend node will set established to 1 only after receiving the poll from LPN, but the message has passed through friend_cred encryption. LPN message decryption also has this problem.

[LingaoM]

zephyr/subsys/bluetooth/mesh/transport.c

Lines 1446 to 1447 in 41b7e5d

	/* Decrypt with seqAuth */
	net_rx->seq = (rx->seq_auth & 0xffffff);

In this way, the sequence number of each segment is changed, and the segment packets of the same sequence number are saved to the friend cache, resulting in LPN replay attack.

@trond-snekvik first issue has been solved, i'll submit pr for this. But until now, I haven't solved the second problem.

[jhedberg]

Did #30260 fix this?

[LingaoM]

Did #30260 fix this?

Yes, But it is only a part, so it cannot be closed.

[carlescufi]

Did #30260 fix this?

Yes, But it is only a part, so it cannot be closed.

Will you post a PR to fix the second part?