From: Robin Candau <antiz@archlinux.org>
To: Xiao Yao <xiaokeqinhealth@126.com>, linux-bluetooth@vger.kernel.org
Cc: Xiao Yao <xiaoyao@rock-chips.com>
Subject: Re: [PATCH 1/2] adapter: Fix addr_type for smp_irk/ltk_info/link_key
Date: Sat, 16 Dec 2023 01:59:51 +0100 [thread overview]
Message-ID: <55903fdb-e970-4b89-b620-daa93bad7811@archlinux.org> (raw)
In-Reply-To: <20231211162729.1183207-1-xiaokeqinhealth@126.com>
[-- Attachment #1.1.1.1: Type: text/plain, Size: 4200 bytes --]
On 12/11/23 17:27, Xiao Yao wrote:
> From: Xiao Yao<xiaoyao@rock-chips.com>
>
> According to BLUETOOTH CORE SPECIFICATION Version 5.4 | Vol 3,
> Part H, 2.4.24/2.4.25, The LE LTK and BR/EDR link keys can be
> converted between each other, so the addr type can be either
> BREDR or LE, so fix it.
>
> Signed-off-by: Xiao Yao<xiaoyao@rock-chips.com>
> ---
> src/adapter.c | 20 ++++++++++++++------
> 1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/src/adapter.c b/src/adapter.c
> index 86fff72bc..ee70b00d2 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -170,6 +170,7 @@ static GSList *conn_fail_list = NULL;
>
> struct link_key_info {
> bdaddr_t bdaddr;
> + uint8_t bdaddr_type;
> unsigned char key[16];
> uint8_t type;
> uint8_t pin_len;
> @@ -3964,7 +3965,9 @@ static bool is_blocked_key(uint8_t key_type, uint8_t *key_value)
> return false;
> }
>
> -static struct link_key_info *get_key_info(GKeyFile *key_file, const char *peer)
> +static struct link_key_info *get_key_info(GKeyFile *key_file, const char *peer,
> + uint8_t bdaddr_type)
> +
> {
> struct link_key_info *info = NULL;
> char *str;
> @@ -3976,6 +3979,7 @@ static struct link_key_info *get_key_info(GKeyFile *key_file, const char *peer)
> info = g_new0(struct link_key_info, 1);
>
> str2ba(peer, &info->bdaddr);
> + info->bdaddr_type = bdaddr_type;
>
> if (!strncmp(str, "0x", 2))
> str2buf(&str[2], info->key, sizeof(info->key));
> @@ -4343,7 +4347,7 @@ static void load_link_keys(struct btd_adapter *adapter, GSList *keys,
> struct link_key_info *info = l->data;
>
> bacpy(&key->addr.bdaddr, &info->bdaddr);
> - key->addr.type = BDADDR_BREDR;
> + key->addr.type = info->bdaddr_type;
> key->type = info->type;
> memcpy(key->val, info->key, 16);
> key->pin_len = info->pin_len;
> @@ -4598,14 +4602,18 @@ static void load_conn_params(struct btd_adapter *adapter, GSList *params)
> btd_error(adapter->dev_id, "Load connection parameters failed");
> }
>
> -static uint8_t get_le_addr_type(GKeyFile *keyfile)
> +static uint8_t get_addr_type(GKeyFile *keyfile)
> {
> uint8_t addr_type;
> char *type;
>
> + /* The AddressType is written to file only When dev->le is
> + * set to true, as referenced in the update_technologies().
> + * Therefore, When type is NULL, it default to BDADDR_BREDR.
> + */
> type = g_key_file_get_string(keyfile, "General", "AddressType", NULL);
> if (!type)
> - return BDADDR_LE_PUBLIC;
> + return BDADDR_BREDR;
>
> if (g_str_equal(type, "public"))
> addr_type = BDADDR_LE_PUBLIC;
> @@ -4914,9 +4922,9 @@ static void load_devices(struct btd_adapter *adapter)
> g_clear_error(&gerr);
> }
>
> - key_info = get_key_info(key_file, entry->d_name);
> + bdaddr_type = get_addr_type(key_file);
>
> - bdaddr_type = get_le_addr_type(key_file);
> + key_info = get_key_info(key_file, entry->d_name, bdaddr_type);
>
> ltk_info = get_ltk_info(key_file, entry->d_name, bdaddr_type);
>
Hello,
It seems like the above commit introduced a regression where the initial
auto-connect for Bluetooth devices doesn't work anymore.
Indeed, at system startup, starting a Bluetooth device will cause it to
go in a "connected/disconnected" state loop, requiring to initialize a
manual connection first (with sometimes multiple attempts needed) before
getting it connected correctly and working as intended.
`systemctl status bluetooth` reports the following error:
[...]
déc. 15 11:03:18 Arch-Desktop bluetoothd[592]: Failed to load link keys
for hci0: Invalid Parameters (0x0d)
[...]
**I bisected the bug with `git bisect` and it pointed out this commit
[1] as the "faulty" one.
I can confirm that reverting it solves the issue.
I reported this bug including details in the GitHub repo [2].
I remain available if any additional information are needed.
[1]
https://github.com/bluez/bluez/commit/d5536e0cd431e22be9a1132be6d4af2445590633
[2] https://github.com/bluez/bluez/issues/686|
|
--
Regards,
Robin Candau / Antiz
[-- Attachment #1.1.1.2: Type: text/html, Size: 4984 bytes --]
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3203 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2023-12-16 1:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-11 16:27 [PATCH 1/2] adapter: Fix addr_type for smp_irk/ltk_info/link_key Xiao Yao
2023-12-11 16:27 ` [PATCH 2/2] device: Add notifications when the bdaddr_type changes Xiao Yao
2023-12-11 18:17 ` [1/2] adapter: Fix addr_type for smp_irk/ltk_info/link_key bluez.test.bot
2023-12-11 18:40 ` [PATCH 1/2] " patchwork-bot+bluetooth
2023-12-16 0:59 ` Robin Candau [this message]
2024-08-26 21:12 ` Luiz Augusto von Dentz
2024-08-27 7:39 ` Yao Xiao
2024-08-27 12:52 ` Luiz Augusto von Dentz
2024-08-27 14:33 ` Yao Xiao
2024-08-27 15:47 ` Luiz Augusto von Dentz
2024-08-27 18:01 ` Yao Xiao
2024-08-27 18:30 ` Luiz Augusto von Dentz
2024-08-28 10:01 ` Yao Xiao
2024-08-28 14:37 ` Luiz Augusto von Dentz
2024-08-29 13:27 ` Yao Xiao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55903fdb-e970-4b89-b620-daa93bad7811@archlinux.org \
--to=antiz@archlinux.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=xiaokeqinhealth@126.com \
--cc=xiaoyao@rock-chips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.