Bug 203997 - [REGRESSION] Unable to connect BT audio device on 5.1.15
Summary: [REGRESSION] Unable to connect BT audio device on 5.1.15
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Bluetooth (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: linux-bluetooth@vger.kernel.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-26 16:14 UTC by Martin
Modified: 2019-09-08 12:51 UTC (History)
12 users (show)

See Also:
Kernel Version: 5.1.15
Subsystem:
Regression: No
Bisected commit-id:


Attachments
H800 headset turn on and try but fail to connect. (5.27 KB, application/octet-stream)
2019-06-28 13:47 UTC, Søren Holm
Details
btmon capture (9.16 KB, application/octet-stream)
2019-06-29 06:13 UTC, Eivind Eide
Details
Traffic capture of a broken pairing (49.55 KB, application/x-pcapng)
2019-09-02 11:49 UTC, Pavel
Details
Capture of a mouse connection which leads to no mouse movement (6.16 KB, application/x-pcapng)
2019-09-03 12:45 UTC, Pavel
Details

Description Martin 2019-06-26 16:14:05 UTC
After upgrading my kernel to 5.1.15 I'm unable to connect to my BT audio amplifier. Booting 5.1.14 solves the problem.

The connections seems to succeed but then quickly disconnects (as interpreted from plasma BT user interface).

The error in syslog is:
bluetoothd[764]: connect error: Connection refused (111)

No errors on dmesg.
Comment 1 Ron Murray 2019-06-27 00:22:09 UTC
Had same problem here with my Beats Wireless 810(?) headphones.
Reverting to kernel 5.1.14 fixed the problem.
Comment 2 Eivind Eide 2019-06-27 08:14:42 UTC
I have exactly the same problem on kernel 5.1.15, connecting seems to succeed but are immediately disconnected with a connection not available message.
Reverting to kernel 5.1.14 solves the problem.
The device I'm trying to connect to are bluetooth loudspeaker KLIPSCH KMC 1 
http://images.klipsch.com/KMC_1_-_Spec_Sheet_635223699556466000.pdf
Comment 3 Daniel Ponte 2019-06-27 13:35:20 UTC
Seeing similar with Logitech H800 headphones. Sometimes it stays connected. Curiously enough, HFP profile sometimes works (using tanuk's pulseaudio-hfp patch), but A2DP absolutely will not activate. The headphones will even register with pulseaudio as a bare device but A2DP remains unavailable.
Comment 4 Søren Holm 2019-06-28 13:05:05 UTC
(In reply to Daniel Ponte from comment #3)
> Seeing similar with Logitech H800 headphones. Sometimes it stays connected.
> Curiously enough, HFP profile sometimes works (using tanuk's pulseaudio-hfp
> patch), but A2DP absolutely will not activate. The headphones will even
> register with pulseaudio as a bare device but A2DP remains unavailable.

I have the exact same problem also with H800 headset.
Comment 5 Matias Karhumaa 2019-06-28 13:19:01 UTC
Could you take btmon capture and attach output here?
Comment 6 Søren Holm 2019-06-28 13:47:14 UTC
Created attachment 283469 [details]
H800 headset turn on and try but fail to connect.
Comment 7 Eivind Eide 2019-06-29 06:13:47 UTC
Created attachment 283475 [details]
btmon capture

KLIPSCH KMC 1 try to connect on 5.1.15 - "Resource temporarily unavailable". 
HCI trace from btmon.
Comment 8 Matias Karhumaa 2019-07-01 07:15:23 UTC
Ah, I think recent regression fix [1] caused another bug:

--snip--
static bool l2cap_check_enc_key_size(struct hci_conn *hcon)
{
	/* The minimum encryption key size needs to be enforced by the
	 * host stack before establishing any L2CAP connections. The
	 * specification in theory allows a minimum of 1, but to align
	 * BR/EDR and LE transports, a minimum of 7 is chosen.
	 *
	 * This check might also be called for unencrypted connections
	 * that have no key size requirements. Ensure that the link is
	 * actually encrypted before enforcing a key size.
	 */
	return (!test_bit(HCI_CONN_ENCRYPT, &hcon->flags) ||
		hcon->enc_key_size > HCI_MIN_ENC_KEY_SIZE);
}
--snip--

If Encryption key size is 7, L2CAP connection will fail. I think it should be something like this:

In l2cap_core.c

static bool l2cap_check_enc_key_size(struct hci_conn *hcon)
{
	/* The minimum encryption key size needs to be enforced by the
	 * host stack before establishing any L2CAP connections. The
	 * specification in theory allows a minimum of 1, but to align
	 * BR/EDR and LE transports, a minimum of 7 is chosen.
	 *
	 * This check might also be called for unencrypted connections
	 * that have no key size requirements. Ensure that the link is
	 * actually encrypted before enforcing a key size.
	 */
	return (!test_bit(HCI_CONN_ENCRYPT, &hcon->flags) ||
		hcon->enc_key_size >= HCI_MIN_ENC_KEY_SIZE);
}
--snip--

Could you test the fix?

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/bluetooth?id=693cd8ce3f882524a5d06f7800dd8492411877b3
Comment 9 Matias Karhumaa 2019-07-01 11:15:48 UTC
Patch has been sent to linux-bluetooth mailing list: https://marc.info/?l=linux-bluetooth&m=156197961326737&w=2

Br,
Matias
Comment 10 Eivind Eide 2019-07-01 12:23:28 UTC
Compiled 5.1.15 kernel with this patch and it indeed fixes the problem of pairing with KLIPSCH KMC 1. Thanks!
Comment 11 Martin 2019-07-01 19:36:54 UTC
I can confirm that the patch fixes my original report for 5.1.15.
Thx for the quick fix!
Comment 12 Søren Holm 2019-07-07 11:10:37 UTC
For some reason the bug is fixed in 5.1.16 even though the proposed patch does not seem to be included....
Comment 13 Matias Karhumaa 2019-07-07 11:33:48 UTC
Eivind and Martin, thanks for testing!

Søren, could it be that for some reason now headset is able to create connection? In your previous btmon trace we can see that headset was trying to connect HFP but failed because your SDP records did not have record for HFP AG. Then your machine tried to connect but failed because of the bug introduced in 5.1.15.
Comment 14 Jan Steffens 2019-07-07 11:34:37 UTC
If you're running 5.1.16-arch1, please note that the patch has been backported into this release.
Comment 15 Søren Holm 2019-07-07 11:43:55 UTC
(In reply to Jan Steffens from comment #14)
> If you're running 5.1.16-arch1, please note that the patch has been
> backported into this release.

I do - then that is why. Sorry for the noise.
Comment 16 Pavel 2019-09-02 11:44:17 UTC
Hello,

I'm afraid you are not out of the woods yet. I tried 5.2 and still can't pair a lot of BT LE products based on MXCHIP chipset, including my mouse. My fear is that they do use a key size of 1 by default 8-[]
Comment 17 Pavel 2019-09-02 11:49:20 UTC
Created attachment 284765 [details]
Traffic capture of a broken pairing
Comment 18 Matias Karhumaa 2019-09-03 10:22:56 UTC
Hi Pavel,

I think this is different problem. Original problem affected only BREDR devices, this is LE. Also here pairing seems to be fine, link gets encrypted but apparently gets disconnected due to Connection timeout.

Any chance to get capture from working scenario for comparison?
Comment 19 Pavel 2019-09-03 12:37:59 UTC
Matias, I'm afraid this also happening with all BT LE devices I have, including ones not MXCHIP based like Microsoft mouses.

I'm very sure it is a BT related issues as when I switch to non-le 3.0 mode, the mouse works fine. It started happening at some time during the 5.1 release cycle.

I would better try to use a usb dongle for BT, trying to confirm if this is not a modem (Qualcomm) issue.
Comment 20 Pavel 2019-09-03 12:45:37 UTC
Created attachment 284773 [details]
Capture of a mouse connection which leads to no mouse movement

I attached one more capture.

I see that connection lights up in the blueman UI, and then times out when I stop pressing the mouse buttons after 30 seconds. All without a sign of mouse movement.

Were there any changes to BTLE during 5.1, 5.2 release cycle?

I think this worth a separate bug report.
Comment 21 Pavel 2019-09-08 12:19:56 UTC
Matias, I ordered an Intel ax200 wifi+bluetooth card for testing. It should arrive in a week or so.
Comment 22 Leif Liddy 2019-09-08 12:51:25 UTC
Something definitely occurred in a recent kernel release that affected BT LE devices. 

https://bugzilla.kernel.org/show_bug.cgi?id=204585

https://bbs.archlinux.org/viewtopic.php?id=248133

Note You need to log in before you can comment on or make changes to this bug.