Bluetooth: Mesh: Friend node not cache ALL_Node Address or different app_idx

[LingaoM]

Set up there nodes, call publish node, friend node ,lpn node.

All node share single network key, but friend & lpn node with different application key,
the lpn node has same application key will publish node.

when publish node periodic send model message with the dst = 0xffff, lpn node not receive all of them.

[LingaoM]

zephyr/subsys/bluetooth/mesh/transport.c

Lines 905 to 914 in c98652b

	bt_mesh_model_recv(rx, &sdu);
	return 0;
	}
	BT_WARN("No matching AppKey");
	return -EINVAL;
	}
	static int sdu_recv_seg(struct seg_rx *seg, u8_t hdr, u8_t aszmic,

and sdu_recv_seg

should be change as return 0 ?

[LingaoM]

zephyr/subsys/bluetooth/mesh/friend.c

Lines 1387 to 1411 in c98652b

	static bool friend_lpn_matches(struct bt_mesh_friend *frnd, u16_t net_idx,
	u16_t addr)
	{
	int i;
	if (!frnd->established) {
	return false;
	}
	if (net_idx != frnd->net_idx) {
	return false;
	}
	if (BT_MESH_ADDR_IS_UNICAST(addr)) {
	return is_lpn_unicast(frnd, addr);
	}
	for (i = 0; i < ARRAY_SIZE(frnd->sub_list); i++) {
	if (frnd->sub_list[i] == addr) {
	return true;
	}
	}
	return false;
	}

should add judgement for ALL_NODE_ADDRESS ?

[jhedberg]

I remember seeing some discussion in the Mesh WG about this, with the conclusion that LPNs need to explicitly subscribe to these addresses, so based on that it's not a bug. @trond-snekvik can you confirm?

[trond-snekvik]

I remember this too, according to spec, the LPN has to explicitly subscribe to 0xffff. There's no public API for doing this in zephyr though, as it's controlled by the config server, which won't accept 0xffff. Perhaps it could be compile time option to automatically subscribe to 0xffff when the friendship is established?

[LingaoM]

well, it's still another problem, friend node has different appkey with lpn node , but currently call sud_recv return -EINVAL when local node unable find appkey,
so, even the friend node known its dst is lpn node, and not store this to friend queue.

[jhedberg]

@LingaoMeng let's not mix multiple issues into a single GitHub issue. Open a new one since I already categorised this based on the 0xffff address concern.