* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
@ 2019-02-06 8:27 ` bugzilla-daemon
2019-02-06 8:27 ` bugzilla-daemon
` (15 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-06 8:27 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
--- Comment #1 from Mathias Tillman (master.homer@gmail.com) ---
I should mention that I'm trying to pair it with an Elecom DEFT Pro trackball
mouse. It works perfectly in Windows and in linux when using the legacy Create
Command, so something definitely seems to be broken with the Extended Create
Command.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
2019-02-06 8:27 ` [Bug 202515] " bugzilla-daemon
@ 2019-02-06 8:27 ` bugzilla-daemon
2019-02-06 9:07 ` bugzilla-daemon
` (14 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-06 8:27 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
--- Comment #2 from Johan Hedberg (johan.hedberg@gmail.com) ---
According to the Bluetooth core spec, HCI_LE_Extended_Create_Connection is
octet 37, bit 7 in the supported commands mask. In the supported commands that
your controller returns octet 37 is 0xdf which does have bit 7 set, i.e. it's
claiming to support the extended version of the command. The way this kind of
issues are normally worked around is by introducing a so-called quirk flag that
gets set (usually by the HCI driver) when a problematic controller is
identified. It might be worth checking first however if there's a newer
firmware available for your controller - perhaps the issue has already been
fixed.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
2019-02-06 8:27 ` [Bug 202515] " bugzilla-daemon
2019-02-06 8:27 ` bugzilla-daemon
@ 2019-02-06 9:07 ` bugzilla-daemon
2019-02-06 9:42 ` bugzilla-daemon
` (13 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-06 9:07 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
--- Comment #3 from Mathias Tillman (master.homer@gmail.com) ---
I believe it is using the latest firmware, I haven't been able to find a later
one than the one mentioned in the kernel log anyway:
[ 6.478466] Bluetooth: hci0: Found device firmware: intel/ibt-18-16-1.sfi
[ 8.361085] Bluetooth: hci0: Found Intel DDC parameters:
intel/ibt-18-16-1.ddc
And yeah, the controller clearly reports that the Extended Create Connection
command is available, so it is a bit odd that it's not working correctly. I
suppose the only way to find out why would be to debug the controller, but I
have no idea how one would go about doing that.
I haven't found this issue being reported at all, so I don't know if it's just
my card, or if all of them have this issue. I know the 9260 is commonly used in
laptops, but I couldn't say to what extent. Perhaps there is someone who has
this card that could test, and if it is in fact broken, add a quirk as you
suggested that would force legacy mode?
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
` (2 preceding siblings ...)
2019-02-06 9:07 ` bugzilla-daemon
@ 2019-02-06 9:42 ` bugzilla-daemon
2019-02-06 11:11 ` bugzilla-daemon
` (12 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-06 9:42 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
Emil Lenngren (emil.lenngren@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |emil.lenngren@gmail.com
--- Comment #4 from Emil Lenngren (emil.lenngren@gmail.com) ---
Command Disallowed does not mean unsupported hci command.
"COMMAND DISALLOWED (0x0C)
The Command Disallowed error code indicates that the command requested cannot
be executed because the Controller is in a state where it cannot process this
command at this time. This error shall not be used for command OpCodes where
the error code Unknown HCI Command is valid."
It's usually sent if the controller is busy with some operation which can't be
combined with the one you're trying to execute. For example, some controllers
only support either BLE scanning or BLE initiating at a time (exposed through
LE Read Supported States). In that case, it will send Command Disallowed if
scanning is already active. It could also be that you already have an active
connection attempt outstanding, in that case it will also send Command
Disallowed.
You should use the new "btmon" tool which I assume supports decoding LE
Extended Connect packets. Also try capture the packets before (ideally all the
way from the hci is brought up) so one knows the whole state and can determine
if we actually send a command that we are not allowed to in this state.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
` (3 preceding siblings ...)
2019-02-06 9:42 ` bugzilla-daemon
@ 2019-02-06 11:11 ` bugzilla-daemon
2019-02-06 11:11 ` bugzilla-daemon
` (11 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-06 11:11 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
--- Comment #5 from Mathias Tillman (master.homer@gmail.com) ---
Created attachment 281015
--> https://bugzilla.kernel.org/attachment.cgi?id=281015&action=edit
Non-working btmon log
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
` (4 preceding siblings ...)
2019-02-06 11:11 ` bugzilla-daemon
@ 2019-02-06 11:11 ` bugzilla-daemon
2019-02-06 11:19 ` bugzilla-daemon
` (10 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-06 11:11 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
--- Comment #6 from Mathias Tillman (master.homer@gmail.com) ---
Created attachment 281017
--> https://bugzilla.kernel.org/attachment.cgi?id=281017&action=edit
Working btmon log
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
` (5 preceding siblings ...)
2019-02-06 11:11 ` bugzilla-daemon
@ 2019-02-06 11:19 ` bugzilla-daemon
2019-02-06 11:58 ` bugzilla-daemon
` (9 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-06 11:19 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
--- Comment #7 from Mathias Tillman (master.homer@gmail.com) ---
Thank you for pointing me towards the btmon tool, that does seem to support
decoding the LE Extended Connect packets. I've attached two logs, one working
and one non-working. In the working one I used a kernel I compiled myself with
the use_ext_conn patched out.
I started btmon, then restarted the bluetooth service and then tried to connect
the mouse - I'm hoping that's enough to catch the hci initialisation? Seems
like it from the log anyway.
I had a look at the logs, and it seems to disable scanning right before it
tries to connect, so I'm not sure that's the problem. However, I'm not familiar
with how LE works at all, so I probably shouldn't start speculating.
Let me know if you need anything else, and thank you for the help so far.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
` (6 preceding siblings ...)
2019-02-06 11:19 ` bugzilla-daemon
@ 2019-02-06 11:58 ` bugzilla-daemon
2019-02-06 12:18 ` bugzilla-daemon
` (8 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-06 11:58 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
--- Comment #8 from Emil Lenngren (emil.lenngren@gmail.com) ---
What I can see the host side (Linux system) did nothing wrong. It's not sending
the command in an illegal state. Hence, it seems the BT chip is behaving
incorrectly. Maybe someone from Intel can check what's going on here?
Just to be sure, is this the firmware you have?
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=ae90c3bce108ac623bc0bae44a7b411e4fa42e7c
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
` (7 preceding siblings ...)
2019-02-06 11:58 ` bugzilla-daemon
@ 2019-02-06 12:18 ` bugzilla-daemon
2019-02-06 19:36 ` bugzilla-daemon
` (7 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-06 12:18 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
--- Comment #9 from Mathias Tillman (master.homer@gmail.com) ---
I compared those firmware files against what I had, and while their hashes were
different I am unfortunately getting the same results using those. So yes, I am
using those firmware files.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
` (8 preceding siblings ...)
2019-02-06 12:18 ` bugzilla-daemon
@ 2019-02-06 19:36 ` bugzilla-daemon
2019-02-07 12:59 ` bugzilla-daemon
` (6 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-06 19:36 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
--- Comment #10 from Mathias Tillman (master.homer@gmail.com) ---
Do you know if intel have an email address for Bluetooth bugs I can cc? I know
they have one for WiFi bugs, but couldn't find one for bt bugs. Just in case
they don't check bugzilla.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
` (9 preceding siblings ...)
2019-02-06 19:36 ` bugzilla-daemon
@ 2019-02-07 12:59 ` bugzilla-daemon
2019-02-07 22:55 ` bugzilla-daemon
` (5 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-07 12:59 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
--- Comment #11 from Mathias Tillman (master.homer@gmail.com) ---
Created attachment 281037
--> https://bugzilla.kernel.org/attachment.cgi?id=281037&action=edit
Btmon extended working log
This is pretty odd, all of a sudden it has decided to start working without me
doing anything. Looking at the log, I can see it has started to use LE Set
Extended Scan Enable instead of LE Set Scan Enable - and sure enough, the Local
Supported Commands now lists LE Set Extended Scan Parameters (Octet 37 - Bit
5).
I haven't done anything to try and fix it - I even reverted to the bt firmware
that's included in my distro, and it's still working.
Any idea what might have caused the Extended Scan command to suddenly appear in
the supported list?
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
` (10 preceding siblings ...)
2019-02-07 12:59 ` bugzilla-daemon
@ 2019-02-07 22:55 ` bugzilla-daemon
2019-02-07 23:05 ` bugzilla-daemon
` (4 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-07 22:55 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
--- Comment #12 from Mathias Tillman (master.homer@gmail.com) ---
Right, so it went back to not reporting the LE Set Extended Scan Parameters
(Octet 37 - Bit 5) in the supported commands list after shutting off my
computer and turning it on again after a short while. So while the card does
seem to be a bit buggy, should the kernel actually check for the parameters bit
when enabling or disabling ext scanning? From what I can tell, the ext scanning
parameters and enabling are two different commands, so shouldn't it check just
the ext scanning bit when sending the ext scan enable command, and check the
ext scan params bit only when sending the ext scan params command?
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
` (11 preceding siblings ...)
2019-02-07 22:55 ` bugzilla-daemon
@ 2019-02-07 23:05 ` bugzilla-daemon
2019-02-07 23:48 ` bugzilla-daemon
` (3 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-07 23:05 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
--- Comment #13 from Mathias Tillman (master.homer@gmail.com) ---
Created attachment 281053
--> https://bugzilla.kernel.org/attachment.cgi?id=281053&action=edit
Check if ext scanning and ext params are supported independently
As a test I created a patch that removes the set ext scanning params check, and
instead only checks it when actually sending the appropriate command (which is
once in the code).
It's working perfectly now, and it's using the ext scan command, instead of the
regular scan command - which is what caused the Command Disallowed error.
Like I said before, I'm not too familiar with how bt le works, but is there any
case where the set ext scanning params would be a requirement for ext scanning
to work? Of course, working around buggy firmware that sometimes reports a
command as supported, and other times not is far from ideal - but seeing as it
is working for me now, I can't see any reason why the commands should depend on
each other.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
` (12 preceding siblings ...)
2019-02-07 23:05 ` bugzilla-daemon
@ 2019-02-07 23:48 ` bugzilla-daemon
2019-02-08 16:16 ` bugzilla-daemon
` (2 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-07 23:48 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
--- Comment #14 from Mathias Tillman (master.homer@gmail.com) ---
Sorry, was too quick to reply. As it turns out, the set ext scanning params
command *is* required, or it won't find any LE devices properly when scanning -
it will connect to already paired devices though.
As a test I decided to try and remove the set ext scanning params check
completely, and just send it even though it's reported as being not supported -
oddly enough this works, and scans are again working properly, so it definitely
seems like a problem with the controller.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
` (13 preceding siblings ...)
2019-02-07 23:48 ` bugzilla-daemon
@ 2019-02-08 16:16 ` bugzilla-daemon
2019-02-08 17:35 ` bugzilla-daemon
2019-02-08 21:39 ` bugzilla-daemon
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-08 16:16 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
Szymon Janc (szymon.janc@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |szymon.janc@gmail.com
--- Comment #15 from Szymon Janc (szymon.janc@gmail.com) ---
Extended Advertising command are mutually exclusive with legacy commands and
controller will reject ones if others were already issued. So if one did
'hcitool lescan' before kernel issued any EA commands, it would lead to
described behavior of rejecting EA commands with 'Command Disallowed' status
code.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
` (14 preceding siblings ...)
2019-02-08 16:16 ` bugzilla-daemon
@ 2019-02-08 17:35 ` bugzilla-daemon
2019-02-08 21:39 ` bugzilla-daemon
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-08 17:35 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
--- Comment #16 from Mathias Tillman (master.homer@gmail.com) ---
Yeah, that does seem to be the case - it works perfectly fine when it uses the
extended le Scan command instead of the legacy one. The problem really is that
the controller only sometimes reports that it supports the set le extended scan
params command, which causes it to use legacy scan instead. This is most likely
due to a bug in the firmware.
However, I am wondering if there realistically are any controllers that only
support the le extended scan command and not the params one, since they are
both required to work properly.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug 202515] Bluetooth LE Extended Connect returning Command Disallowed
2019-02-06 0:01 [Bug 202515] New: Bluetooth LE Extended Connect returning Command Disallowed bugzilla-daemon
` (15 preceding siblings ...)
2019-02-08 17:35 ` bugzilla-daemon
@ 2019-02-08 21:39 ` bugzilla-daemon
16 siblings, 0 replies; 18+ messages in thread
From: bugzilla-daemon @ 2019-02-08 21:39 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=202515
Mathias Tillman (master.homer@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #17 from Mathias Tillman (master.homer@gmail.com) ---
To make a long story short, I've managed to figure it out: the latest firmware
actually fixes it, but for some reason it's not actually loaded on to the
controller until I shut down the computer and leave it off for around 10
seconds or so. A simple reboot isn't enough for it to load the new firmware.
I verified this by doing a cold boot with the distro firmware, copying over the
new firmware then rebooting several times. None of these times was the LE Set
Extended Scan Parameters reported as being supported. I then shut down the
computer and turned it on again after roughly 10 seconds, and after that the
command was reported. I then copied over the distro firmware, rebooted several
times and it was still working. Turned off the computer and on again, and it no
longer worked.
So aside from that odd firmware loading requiring a cold boot, it seems to be
working as expected without a patched kernel.
Thanks for the replies everyone, and sorry for all of the long-winded messages.
I will be marking this as resolved now.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 18+ messages in thread