Bluetooth Mesh friendship is cleared due to no Friend response reception #22088
Comments
|
CC @jhedberg |
|
@DHortelano, what configuration values do you use for I am not sure what should be the exact values, it seems that the error happens when the scanning phase starts too close to the end of the advertisement phase, although I haven't really debugged more than testing different values. |
|
Hi @aurel32, I used
I completely agree with you, and I think it could be due to the change of address type when the scan starts. I have added a check to do that only when the |
|
It sounds like this is all related to the fact that we don't have super precise control of advertising timing due to our use of standard HCI (and legacy 4.0 HCI at that). This should all hopefully get fixed once we start using Mesh vendor extensions for HCI. Meanwhile, the only thing I can think of improving is to change the default values of these Kconfig options. |
|
Looks like this is just a symptom of a bug in hci_core. I made a PR for skipping the address setting when using a passive scanner, like in the mesh, as it's not used. This should remove the call generating the error. @joerchan plans on fixing the overarching problem in his AE work. @DHortelano #22313 should fix the problem, even for your original timing parameters. |
To clarify, this problem can be avoided if the controller supports AE :) It is still something we have to deal with when AE commands are not available. |
When privacy is disabled by default the scanner still protects it's identity with the use of NRPA addresses. We should not set the identity address for the passive scanner unless the Kconfig option to scan with the identity has been enabled. This makes passive scanner behave the same way as an active scanner since none of them will report directed advertising reports towards the scanners identity. This also enables the advertiser to switch out the random address which is needed for the Bluetooth Mesh LPN case. Fixes zephyrproject-rtos#22088. Signed-off-by: Trond Einar Snekvik <[email protected]>
When privacy is disabled by default the scanner still protects it's identity with the use of NRPA addresses. We should not set the identity address for the passive scanner unless the Kconfig option to scan with the identity has been enabled. This makes passive scanner behave the same way as an active scanner since none of them will report directed advertising reports towards the scanners identity. This also enables the advertiser to switch out the random address which is needed for the Bluetooth Mesh LPN case. Fixes #22088. Signed-off-by: Trond Einar Snekvik <[email protected]>
Describe the bug
In the friendship established between a Friend Node (FN) and a Low Power Node (LPN) in a Bluetooth Mesh, the LPN generates and sends the Friend Poll message, which is correctly received by the FN. However, after that, the LPN is not able to start the scanning, with the following debug output:
[00:00:32.176,910] bt_mesh_adv: starting scan failed (err -5)
This produces the FN response is not received, and after some retries the friendship is cleared.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The LPN receives the Friend response
Screenshots or console output
Debugging output from LPN using CONFIG_BT_MESH_DEBUG_LOW_POWER and CONFIG_BT_MESH_DEBUG_ADV options:
Environment (please complete the following information):
Additional context
Tracking the error, it is generated, apparently, in hci_core.c, when the function "start_le_scan(u8_t scan_type, u16_t interval, u16_t window)" uses the "err = set_random_address(&bt_dev.id_addr[0].a);" function.
The text was updated successfully, but these errors were encountered: