Bluetooth developers,
To give some feedbacks on my problem and hopefully that could help
someone else who is also struggling...
I compared the connection with my desktop and my device using btmon and
noticed that during the connection, my desktop was configured as master
that is set to slave on my device:
# On host
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
Address: EC:83:50:DE:02:3C (Microsoft Corporation)
Role: Master (0x00)
# On target
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
Address: EC:83:50:DE:02:3C (OUI EC-83-50)
Role: Slave (0x01)
So I applied this quick and dirty patch and now I can change the link
supervision timeout without error:
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index e17aacbc5630..c83f66066ce0 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2286,10 +2286,7 @@ static void hci_conn_request_evt(struct hci_dev
*hdev, struct sk_buff *skb)
bacpy(&cp.bdaddr, &ev->bdaddr);
- if (lmp_rswitch_capable(hdev) && (mask & HCI_LM_MASTER))
- cp.role = 0x00; /* Become master */
- else
- cp.role = 0x01; /* Remain slave */
+ cp.role = 0x00; /* Become master */
hci_send_cmd(hdev, HCI_OP_ACCEPT_CONN_REQ, sizeof(cp), &cp);
} else if (!(flags & HCI_PROTO_DEFER)) {
It's weird that in the latest kernel, this part of the file didn't
change and there is for sure a better fix! bluetooth poeple?
Anyway, if this helps or gives some clue to someone else, I'm always
glad for a free beer, even virtually :D!
Happy hacking!
Guy
On Thu, Nov 21, 2019 at 6:37 PM Guy Morand <g.morand@xxxxxxxx> wrote:
>
> I found out that the hcitool lst command was working perfectly fine on
> my desktop and is doing what I expect!
>
> Unfortunately, on my device it only works after pairing, then I always
> get the "Command Disallowed" error. This is weird as I'm using the same
> USB dongle and bluez version (5.50). The only thing that changes is the
> kernel version that is why I think there is something weird here:
> * 4.9 (Yocto) -> Doesn't work
> * 4.14 (Yocto) -> Doesn't work
> * 4.19 (Debian) -> works!
> * 5.0.0 (Ubuntu) -> works!
>
> I know it's boring but updating the kernel is not straightforward, we
> use the kernel provided but our silicium vendor (embedded).
>
> I was just wondering if one of you remember a similar bug (and fix?) or
> this was just automagically solved without someone noticing it? Or maybe
> I'm just missing something else important...
>
> All the best!
>
> Guy
--
Guy Morand
Software Engineer
–
Scewo AG, Technoparkstrasse 2, 8406 Winterthur
Office +41 (0)44 500 86 03
www.scewo.ch
www.facebook.com/scewo
www.instagram.com/scewo_official
