Had same problem here with my Beats Wireless 810(?) headphones.
Reverting to kernel 5.1.14 fixed the problem.

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

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.

(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.

Could you take btmon capture and attach output here?

Created attachment 283469 [details]
H800 headset turn on and try but fail to connect.

Created attachment 283475 [details]
btmon capture

KLIPSCH KMC 1 try to connect on 5.1.15 - "Resource temporarily unavailable". 
HCI trace from btmon.

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

Patch has been sent to linux-bluetooth mailing list: https://marc.info/?l=linux-bluetooth&m=156197961326737&w=2

Br,
Matias

Compiled 5.1.15 kernel with this patch and it indeed fixes the problem of pairing with KLIPSCH KMC 1. Thanks!

I can confirm that the patch fixes my original report for 5.1.15.
Thx for the quick fix!

For some reason the bug is fixed in 5.1.16 even though the proposed patch does not seem to be included....

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.

If you're running 5.1.16-arch1, please note that the patch has been backported into this release.

(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.

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-[]

Created attachment 284765 [details]
Traffic capture of a broken pairing

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?

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.

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.

Matias, I ordered an Intel ax200 wifi+bluetooth card for testing. It should arrive in a week or so.

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