Hi,
I've recently bought a new xbox one controller as the 2016 version has
bluetooth connectivity.
The controller is pairing and connecting well on a windows 10 computer
and an android 4.4 tablet. But I can"t make it connect under linux
(Debian unstable, kernel 4.6 and 4.7-rc7, bluez 5.40 from
experimental). The pairing is ok but when I try to connect to
controller, it stays connected for less than one second, then
disconnects, then connects again and so one until the controller goes
to sleep, because of the lack of a remote connection.
Any idea ?
Hi Anthony,
Anthony Bourguignon <[email protected]> writes:
> Hi,
>
> I've recently bought a new xbox one controller as the 2016 version has
> bluetooth connectivity.
>
> The controller is pairing and connecting well on a windows 10 computer
> and an android 4.4 tablet. But I can"t make it connect under linux
> (Debian unstable, kernel 4.6 and 4.7-rc7, bluez 5.40 from
> experimental). The pairing is ok but when I try to connect to
> controller, it stays connected for less than one second, then
> disconnects, then connects again and so one until the controller goes
> to sleep, because of the lack of a remote connection.
Can you produce the logs with L2CAP ERTM/Streaming mode disabled,
doing something like this before connecting this should work:
$ echo 1 > /sys/module/bluetooth/parameters/disable_ertm
Cheers,
--
Vinicius
Hi,
Le vendredi 19 août 2016 à 11:43 +0300, Luiz Augusto von Dentz a
écrit :
> Hi Anthony,
>
> On Thu, Aug 18, 2016 at 8:46 PM, Anthony Bourguignon <contact@toniob.
> net> wrote:
> >
> > Le jeudi 18 août 2016 à 19:20 +0300, Luiz Augusto von Dentz a écrit
> > :
> > >
> > > Hi Anthony,
> > >
> > > On Thu, Aug 18, 2016 at 5:52 PM, Anthony Bourguignon <contact@ton
> > > iob.
> > > net> wrote:
> > > >
> > > >
> > > > Le jeudi 18 août 2016 à 16:56 +0300, Luiz Augusto von Dentz a
> > > > écrit
> > > > :
> > > > >
> > > > >
> > > > > Hi Anthony,
> > > > >
> > > > > On Thu, Aug 18, 2016 at 1:11 PM, Anthony Bourguignon <contact
> > > > > @ton
> > > > > iob.
> > > > > net> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I've recently bought a new xbox one controller as the 2016
> > > > > > version
> > > > > > has
> > > > > > bluetooth connectivity.
> > > > > >
> > > > > > The controller is pairing and connecting well on a windows
> > > > > > 10
> > > > > > computer
> > > > > > and an android 4.4 tablet. But I can"t make it connect
> > > > > > under
> > > > > > linux
> > > > > > (Debian unstable, kernel 4.6 and 4.7-rc7, bluez 5.40 from
> > > > > > experimental). The pairing is ok but when I try to connect
> > > > > > to
> > > > > > controller, it stays connected for less than one second,
> > > > > > then
> > > > > > disconnects, then connects again and so one until the
> > > > > > controller
> > > > > > goes
> > > > > > to sleep, because of the lack of a remote connection.
> > > > > >
> > > > > > Any idea ?
> > > > >
> > > > > It seems there is some problem configuring the L2CAP
> > > > > connection
> > > > > (probably for SDP):
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ACL data: handle 256 flags 0x02 dlen 15
> > > > > L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 3
> > > > > clen 1
> > > > > Failure - unknown options
> > > > > RFC
> > > > > < ACL data: handle 256 flags 0x00 dlen 12
> > > > > L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
> > > >
> > > > So, is it a bug of bluez or of the controller firmware ? Why is
> > > > it
> > > > possible to make a connection with an android tablet ?
> > > >
> > > > Is there something more I can do to help ?
> > >
> > > Well perhaps we can compare to what other stacks are responding,
> > > but
> > > this seem quite weird given L2CAP_Config request is an essential
> > > part
> > > of setting up L2CAP connections so a response with unknown
> > > options
> > > sounds kind broken, but perhaps other stacks are ignoring it.
> >
> > I've juste made a capture with my android tablet. Maybe it'll help.
> > Association failed two times and succeded on the third one.
>
> It seems the configuration request works just fine here:
>
> < ACL Data TX: Handle 13 flags 0x02 dlen 12
>
> 83.379233
> L2CAP: Connection Request (0x02) ident 15 len 4
> PSM: 17 (0x0011)
> Source CID: 75
> >
> > HCI Event: Number of Completed Packets (0x13) plen
> > 5
> >
> > 83.381502
> Num handles: 1
> Handle: 13
> Count: 1
> >
> > ACL Data RX: Handle 13 flags 0x02 dlen
> > 16
> >
> > 83.383358
> L2CAP: Connection Response (0x03) ident 15 len 8
> Destination CID: 64
> Source CID: 75
> Result: Connection pending (0x0001)
> Status: No further information available (0x0000)
> >
> > ACL Data RX: Handle 13 flags 0x02 dlen
> > 16
> >
> > 83.384600
> L2CAP: Connection Response (0x03) ident 15 len 8
> Destination CID: 64
> Source CID: 75
> Result: Connection successful (0x0000)
> Status: No further information available (0x0000)
> < ACL Data TX: Handle 13 flags 0x02 dlen 16
>
> 83.385274
> L2CAP: Configure Request (0x04) ident 16 len 8
> Destination CID: 64
> Flags: 0x0000
> Option: Maximum Transmission Unit (0x01) [mandatory]
> MTU: 640
> >
> > ACL Data RX: Handle 13 flags 0x02 dlen
> > 16
> >
> > 83.385939
> L2CAP: Configure Request (0x04) ident 5 len 8
> Destination CID: 75
> Flags: 0x0000
> Option: Maximum Transmission Unit (0x01) [mandatory]
> MTU: 1480
> < ACL Data TX: Handle 13 flags 0x02 dlen 14
>
> 83.386624
> L2CAP: Configure Response (0x05) ident 5 len 6
> Source CID: 64
> Flags: 0x0000
> Result: Success (0x0000)
> >
> > HCI Event: Number of Completed Packets (0x13) plen
> > 5
> >
> > 83.387708
> Num handles: 1
> Handle: 13
> Count: 1
> >
> > ACL Data RX: Handle 13 flags 0x02 dlen
> > 14
> >
> > 83.388425
> L2CAP: Configure Response (0x05) ident 16 len 6
> Source CID: 75
> Flags: 0x0000
> Result: Success (0x0000)
>
> There is another difference here is that the connection to PSM 17 is
> started by the Android device while in our case it is started by the
> controller without doing any SDP(?) which sounds like the controller
> has been connected before or it is not behaving like a HID device. Is
> there a way to reset the controller to a state that it clears the
> paired devices?
Here is a new dump from the android device. I've paired the xbox
controller to another device before for it to change its bluetooth pair
(I hope it worked).
Hi Anthony,
On Thu, Aug 18, 2016 at 8:46 PM, Anthony Bourguignon <[email protected]> w=
rote:
> Le jeudi 18 ao=C3=BBt 2016 =C3=A0 19:20 +0300, Luiz Augusto von Dentz a =
=C3=A9crit :
>> Hi Anthony,
>>
>> On Thu, Aug 18, 2016 at 5:52 PM, Anthony Bourguignon <contact@toniob.
>> net> wrote:
>> >
>> > Le jeudi 18 ao=C3=BBt 2016 =C3=A0 16:56 +0300, Luiz Augusto von Dentz =
a =C3=A9crit
>> > :
>> > >
>> > > Hi Anthony,
>> > >
>> > > On Thu, Aug 18, 2016 at 1:11 PM, Anthony Bourguignon <contact@ton
>> > > iob.
>> > > net> wrote:
>> > > >
>> > > >
>> > > > Hi,
>> > > >
>> > > > I've recently bought a new xbox one controller as the 2016
>> > > > version
>> > > > has
>> > > > bluetooth connectivity.
>> > > >
>> > > > The controller is pairing and connecting well on a windows 10
>> > > > computer
>> > > > and an android 4.4 tablet. But I can"t make it connect under
>> > > > linux
>> > > > (Debian unstable, kernel 4.6 and 4.7-rc7, bluez 5.40 from
>> > > > experimental). The pairing is ok but when I try to connect to
>> > > > controller, it stays connected for less than one second, then
>> > > > disconnects, then connects again and so one until the
>> > > > controller
>> > > > goes
>> > > > to sleep, because of the lack of a remote connection.
>> > > >
>> > > > Any idea ?
>> > >
>> > > It seems there is some problem configuring the L2CAP connection
>> > > (probably for SDP):
>> > >
>> > > >
>> > > >
>> > > > ACL data: handle 256 flags 0x02 dlen 15
>> > > L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 3 clen 1
>> > > Failure - unknown options
>> > > RFC
>> > > < ACL data: handle 256 flags 0x00 dlen 12
>> > > L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
>> >
>> > So, is it a bug of bluez or of the controller firmware ? Why is it
>> > possible to make a connection with an android tablet ?
>> >
>> > Is there something more I can do to help ?
>>
>> Well perhaps we can compare to what other stacks are responding, but
>> this seem quite weird given L2CAP_Config request is an essential part
>> of setting up L2CAP connections so a response with unknown options
>> sounds kind broken, but perhaps other stacks are ignoring it.
>
> I've juste made a capture with my android tablet. Maybe it'll help.
> Association failed two times and succeded on the third one.
It seems the configuration request works just fine here:
< ACL Data TX: Handle 13 flags 0x02 dlen 12
83.379233
L2CAP: Connection Request (0x02) ident 15 len 4
PSM: 17 (0x0011)
Source CID: 75
> HCI Event: Number of Completed Packets (0x13) plen 5 =
=
83.381502
Num handles: 1
Handle: 13
Count: 1
> ACL Data RX: Handle 13 flags 0x02 dlen 16 =
=
83.383358
L2CAP: Connection Response (0x03) ident 15 len 8
Destination CID: 64
Source CID: 75
Result: Connection pending (0x0001)
Status: No further information available (0x0000)
> ACL Data RX: Handle 13 flags 0x02 dlen 16 =
=
83.384600
L2CAP: Connection Response (0x03) ident 15 len 8
Destination CID: 64
Source CID: 75
Result: Connection successful (0x0000)
Status: No further information available (0x0000)
< ACL Data TX: Handle 13 flags 0x02 dlen 16
83.385274
L2CAP: Configure Request (0x04) ident 16 len 8
Destination CID: 64
Flags: 0x0000
Option: Maximum Transmission Unit (0x01) [mandatory]
MTU: 640
> ACL Data RX: Handle 13 flags 0x02 dlen 16 =
=
83.385939
L2CAP: Configure Request (0x04) ident 5 len 8
Destination CID: 75
Flags: 0x0000
Option: Maximum Transmission Unit (0x01) [mandatory]
MTU: 1480
< ACL Data TX: Handle 13 flags 0x02 dlen 14
83.386624
L2CAP: Configure Response (0x05) ident 5 len 6
Source CID: 64
Flags: 0x0000
Result: Success (0x0000)
> HCI Event: Number of Completed Packets (0x13) plen 5 =
=
83.387708
Num handles: 1
Handle: 13
Count: 1
> ACL Data RX: Handle 13 flags 0x02 dlen 14 =
=
83.388425
L2CAP: Configure Response (0x05) ident 16 len 6
Source CID: 75
Flags: 0x0000
Result: Success (0x0000)
There is another difference here is that the connection to PSM 17 is
started by the Android device while in our case it is started by the
controller without doing any SDP(?) which sounds like the controller
has been connected before or it is not behaving like a HID device. Is
there a way to reset the controller to a state that it clears the
paired devices?
--=20
Luiz Augusto von Dentz
Le jeudi 18 août 2016 à 19:20 +0300, Luiz Augusto von Dentz a écrit :
> Hi Anthony,
>
> On Thu, Aug 18, 2016 at 5:52 PM, Anthony Bourguignon <contact@toniob.
> net> wrote:
> >
> > Le jeudi 18 août 2016 à 16:56 +0300, Luiz Augusto von Dentz a écrit
> > :
> > >
> > > Hi Anthony,
> > >
> > > On Thu, Aug 18, 2016 at 1:11 PM, Anthony Bourguignon <contact@ton
> > > iob.
> > > net> wrote:
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I've recently bought a new xbox one controller as the 2016
> > > > version
> > > > has
> > > > bluetooth connectivity.
> > > >
> > > > The controller is pairing and connecting well on a windows 10
> > > > computer
> > > > and an android 4.4 tablet. But I can"t make it connect under
> > > > linux
> > > > (Debian unstable, kernel 4.6 and 4.7-rc7, bluez 5.40 from
> > > > experimental). The pairing is ok but when I try to connect to
> > > > controller, it stays connected for less than one second, then
> > > > disconnects, then connects again and so one until the
> > > > controller
> > > > goes
> > > > to sleep, because of the lack of a remote connection.
> > > >
> > > > Any idea ?
> > >
> > > It seems there is some problem configuring the L2CAP connection
> > > (probably for SDP):
> > >
> > > >
> > > >
> > > > ACL data: handle 256 flags 0x02 dlen 15
> > > L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 3 clen 1
> > > Failure - unknown options
> > > RFC
> > > < ACL data: handle 256 flags 0x00 dlen 12
> > > L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
> >
> > So, is it a bug of bluez or of the controller firmware ? Why is it
> > possible to make a connection with an android tablet ?
> >
> > Is there something more I can do to help ?
>
> Well perhaps we can compare to what other stacks are responding, but
> this seem quite weird given L2CAP_Config request is an essential part
> of setting up L2CAP connections so a response with unknown options
> sounds kind broken, but perhaps other stacks are ignoring it.
I've juste made a capture with my android tablet. Maybe it'll help.
Association failed two times and succeded on the third one.
Thanks
Le jeudi 18 août 2016 à 16:56 +0300, Luiz Augusto von Dentz a écrit :
> Hi Anthony,
>
> On Thu, Aug 18, 2016 at 1:11 PM, Anthony Bourguignon <contact@toniob.
> net> wrote:
> >
> > Hi,
> >
> > I've recently bought a new xbox one controller as the 2016 version
> > has
> > bluetooth connectivity.
> >
> > The controller is pairing and connecting well on a windows 10
> > computer
> > and an android 4.4 tablet. But I can"t make it connect under linux
> > (Debian unstable, kernel 4.6 and 4.7-rc7, bluez 5.40 from
> > experimental). The pairing is ok but when I try to connect to
> > controller, it stays connected for less than one second, then
> > disconnects, then connects again and so one until the controller
> > goes
> > to sleep, because of the lack of a remote connection.
> >
> > Any idea ?
>
> It seems there is some problem configuring the L2CAP connection
> (probably for SDP):
>
> >
> > ACL data: handle 256 flags 0x02 dlen 15
> L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 3 clen 1
> Failure - unknown options
> RFC
> < ACL data: handle 256 flags 0x00 dlen 12
> L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
So, is it a bug of bluez or of the controller firmware ? Why is it
possible to make a connection with an android tablet ?
Is there something more I can do to help ?
Hi Anthony,
On Thu, Aug 18, 2016 at 5:52 PM, Anthony Bourguignon <[email protected]> w=
rote:
> Le jeudi 18 ao=C3=BBt 2016 =C3=A0 16:56 +0300, Luiz Augusto von Dentz a =
=C3=A9crit :
>> Hi Anthony,
>>
>> On Thu, Aug 18, 2016 at 1:11 PM, Anthony Bourguignon <contact@toniob.
>> net> wrote:
>> >
>> > Hi,
>> >
>> > I've recently bought a new xbox one controller as the 2016 version
>> > has
>> > bluetooth connectivity.
>> >
>> > The controller is pairing and connecting well on a windows 10
>> > computer
>> > and an android 4.4 tablet. But I can"t make it connect under linux
>> > (Debian unstable, kernel 4.6 and 4.7-rc7, bluez 5.40 from
>> > experimental). The pairing is ok but when I try to connect to
>> > controller, it stays connected for less than one second, then
>> > disconnects, then connects again and so one until the controller
>> > goes
>> > to sleep, because of the lack of a remote connection.
>> >
>> > Any idea ?
>>
>> It seems there is some problem configuring the L2CAP connection
>> (probably for SDP):
>>
>> >
>> > ACL data: handle 256 flags 0x02 dlen 15
>> L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 3 clen 1
>> Failure - unknown options
>> RFC
>> < ACL data: handle 256 flags 0x00 dlen 12
>> L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
>
> So, is it a bug of bluez or of the controller firmware ? Why is it
> possible to make a connection with an android tablet ?
>
> Is there something more I can do to help ?
Well perhaps we can compare to what other stacks are responding, but
this seem quite weird given L2CAP_Config request is an essential part
of setting up L2CAP connections so a response with unknown options
sounds kind broken, but perhaps other stacks are ignoring it.
--=20
Luiz Augusto von Dentz
Hi Anthony,
On Thu, Aug 18, 2016 at 1:11 PM, Anthony Bourguignon <[email protected]> wrote:
> Hi,
>
> I've recently bought a new xbox one controller as the 2016 version has
> bluetooth connectivity.
>
> The controller is pairing and connecting well on a windows 10 computer
> and an android 4.4 tablet. But I can"t make it connect under linux
> (Debian unstable, kernel 4.6 and 4.7-rc7, bluez 5.40 from
> experimental). The pairing is ok but when I try to connect to
> controller, it stays connected for less than one second, then
> disconnects, then connects again and so one until the controller goes
> to sleep, because of the lack of a remote connection.
>
> Any idea ?
It seems there is some problem configuring the L2CAP connection
(probably for SDP):
> ACL data: handle 256 flags 0x02 dlen 15
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 3 clen 1
Failure - unknown options
RFC
< ACL data: handle 256 flags 0x00 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
--
Luiz Augusto von Dentz
Hey,
I'm still working on getting some interesting information out of this.
The first thing is:
> ACL Data RX: Handle 256 flags 0x02 dlen 15 #38 [hci0] 7.314671
L2CAP: Configure Response (0x05) ident 3 len 7
Source CID: 64
Flags: 0x0000
Result: Failure - unknown options (0x0003)
04 .
This tells us that the pad doesn't like the RFC request (Retransmit and
Flow Control, not Request For Configuration, as I thought it might
mean).
The specification says[1]:
> The remote device proposes Basic L2CAP mode in a Configuration
> Request
> and the local device proposes Enhanced Retransmission mode or
> Streaming mode. The remote device rejects the local device's
> Configuration
> Request by sending a negative Configuration Response proposing Basic
> mode. The local device will send a second Configuration Request
> proposing
> Basic L2CAP mode or disconnect the channel. If the local device sends
> a
> second Configuration Request that does not propose Basic L2CAP mode
> then the remote device will disconnect the channel. If the local
> device rejects
> the remote device's Configuration Request then the remote device will
> disconnect the channel.
And[2]:
> The Basic L2CAP mode is the default. If Basic L2CAP mode is requested
> then all other parameters shall be ignored.
> Enhanced Retransmission mode should be enabled if a reliable channel
> has
> been requested. Enhanced Retransmission mode shall only be sent to an
> L2CAP entity that has previously advertised support for the mode in
> its
> Extended Feature Mask (see Section 4.12).
> Streaming mode should be enabled if a finite L2CAP Flush Time-Out is
> set
> on an L2CAP connection. Streaming mode shall only be sent to a device
> that has previously advertised support for the mode in the Extended
> Feature
> Mask (see Section 4.12).
But the code only ever sets the mode to BASIC if it was basic before,
never trying to upgrade the mode:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/bluetooth/l2cap_core.c#n3230
I'm also unclear on whether the current code checks whether the L2CAP
Flush Time-Out is set, which is required for Streaming Mode to be
enabled.
So I think that we should try to set a non-BASIC mode in when setting
the RFC config request in l2cap_build_conf_req() [3], and if the mode
is streaming, but only if L2CAP_CONF_FLUSH_TO is non-zero. Break out if
the remote device doesn't support ERTM or has a 0 flush timeout.
Am I on the right track?
[1]: BLUETOOTH SPECIFICATION Version 5.0 | Vol 3, Part A
page 1790
[2]: BLUETOOTH SPECIFICATION Version 5.0 | Vol 3, Part A
page 1785
[3]: How do I get the remote feature mask? I couldn't figure it out
On Thu, 2017-11-09 at 16:11 +0100, Bastien Nocera wrote:
> On Thu, 2017-11-09 at 15:28 +0100, Bastien Nocera wrote:
> >
>
> <snip>
> > Here's the btmon output of a pairing attempt.
>
> And this is a pairing attempt with disable_ertm set to 1.
>
> You will see a gap of about a minute between 2 events:
> @ MGMT Event: Device Disconnected (0x000c) plen
> 8
> {
> 0x0001} [hci0] 12.103542
> BR/EDR Address: C8:3F:26:80:BA:71 (Microsoft Corporation)
> Reason: Connection terminated by local host (0x02)
> > HCI Event: Connect Request (0x04) plen
> > 10
> >
> > #77 [hci0] 81.172351
>
> Address: C8:3F:26:80:BA:71 (Microsoft Corporation)
> Class: 0x000508
> Major class: Peripheral (mouse, joystick, keyboards)
> Minor class: 0x02
> Link type: ACL (0x01)
>
> The pad carried on blinking expecting "something". I turned the pad
> off
> by long pressing on the "XBox" button, and turned it on again. I got
> a
> service authentication request:
> [CHG] Device C8:3F:26:80:BA:71 Connected: yes
> Authorize service
> [agent] Authorize service 00001124-0000-1000-8000-00805f9b34fb
> (yes/no): yes
>
> And it's now connected and working.
On Thu, 2017-11-09 at 15:28 +0100, Bastien Nocera wrote:
>
<snip>
> Here's the btmon output of a pairing attempt.
And this is a pairing attempt with disable_ertm set to 1.
You will see a gap of about a minute between 2 events:
@ MGMT Event: Device Disconnected (0x000c) plen 8 {0x0001} [hci0] 12.103542
BR/EDR Address: C8:3F:26:80:BA:71 (Microsoft Corporation)
Reason: Connection terminated by local host (0x02)
> HCI Event: Connect Request (0x04) plen 10 #77 [hci0] 81.172351
Address: C8:3F:26:80:BA:71 (Microsoft Corporation)
Class: 0x000508
Major class: Peripheral (mouse, joystick, keyboards)
Minor class: 0x02
Link type: ACL (0x01)
The pad carried on blinking expecting "something". I turned the pad off
by long pressing on the "XBox" button, and turned it on again. I got a
service authentication request:
[CHG] Device C8:3F:26:80:BA:71 Connected: yes
Authorize service
[agent] Authorize service 00001124-0000-1000-8000-00805f9b34fb (yes/no): yes
And it's now connected and working.
On Thu, 2017-11-09 at 14:49 +0100, Bastien Nocera wrote:
> On Wed, 2016-08-24 at 11:02 -0300, Vinicius Costa Gomes wrote:
> > Hi,
> >
> > Anthony Bourguignon <[email protected]> writes:
> > > >
> > > > No. It could be a bug in the xbox controller. But I need to
> > > > take
> > > > a
> > > > closer look at the specification to be really sure.
> > >
> > > Can I be of any help ?
> >
> > Attached is a patch that disables negotiating Flow Control and
> > Retransmission parameters for the SDP channel only. This is a shot
> > in
> > the dark, as I could find nothing in the specification that advises
> > against the current BlueZ behaviour.
> >
> > Could you give it a try? (but I don't have high hopes for it)
> >
> > This is looking more like a bug in the controller.
>
> Hi,
>
> It's getting hit during pairing, but this isn't enough to get it
> working.
>
> I also combined it with vudentz' patch in the "Continuing the Xbox
> One
> Bluetooth controller debugging" thread (called "Bluetooth: L2CAP:
> Ignore Unknown option error for basic mode") and that wasn't enough
> to
> get it working either.
>
> I think that the fix would be to not try and upgrade the connection
> to
> ERTM at all on this device, but I don't know how I could pass this
> information down the stack to the l2cap code. Any ideas?
Here's the btmon output of a pairing attempt.
Cheers