Hi Xiao, On Sun, Dec 17, 2023 at 11:21 AM Xiao Yao <xiaokeqinhealth@xxxxxxx> wrote: > > From: Xiao Yao <xiaoyao@xxxxxxxxxxxxxx> > > Fixes: https://github.com/bluez/bluez/issues/686 > > Signed-off-by: Xiao Yao <xiaoyao@xxxxxxxxxxxxxx> > --- > src/adapter.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/src/adapter.c b/src/adapter.c > index ee70b00d2..b4628a411 100644 > --- a/src/adapter.c > +++ b/src/adapter.c > @@ -4347,7 +4347,17 @@ 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 = info->bdaddr_type; > + > + /* > + * According to the Bluetooth specification, the address > + * type of the link key is not fixed. However, the > + * load_link_keys function in the old kernel code requires > + * that the address type must be BREDR. Since the address > + * type is not actually used by the link key, to maintain > + * compatibility with older kernel versions, the addr.type > + * of the link key is set to BDADDR_BREDR. > + */ > + key->addr.type = BDADDR_BREDR; We probably want to find a way to detect if the kernel is capable of handling the addr type or not, maybe attempt to load with it set and in case it doesn't work then use BREDR. > key->type = info->type; > memcpy(key->val, info->key, 16); > key->pin_len = info->pin_len; > -- > 2.34.1 > > -- Luiz Augusto von Dentz
