I think in essence this is the same as my patch from Jan 2018 here:
https://raw.githubusercontent.com/atar-axis/xpadneo/master/misc/kernel_patches/0001-fix_bluetooth_reconnect.patch
Right? That's maybe why I am in CC :D
If yes, then I can fully confirm that this works as one would expect.
Let me copy&paste my patch description here:
---
The current L2CAP implementation does not change any options if the
other side respons with "unknown options", but does if "unaccepted
options" is the answer. It is up to the implementation to decide on the
effort spent on config negotiations, therefore the current
implementation is correct at this point - but [...] devices like [the]
Xbox One S controller [is] not useable this way.
A workaround for many users therefore is to disable_ertm, since this
is [in this case] the option which is unknown. I would prefer to try it
again with altered options instead of globally disable ERTM.
In result, I suggest the following patch. It simply adds a new case
(L2CAP_CONF_UNKNOWN), which does nothing but falling through to
L2CAP_CONF_UNACCEPT.
---
Cheers,
Florian Dollinger (atar-axis)
On 21.03.19 00:08, Andrey Smirnov wrote:
On Mon, Feb 18, 2019 at 8:57 PM Andrey Smirnov <andrew.smirnov@xxxxxxxxx> wrote:
On Mon, Feb 18, 2019 at 4:58 AM Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
Hi Andrey,
Due to:
- current implementation of l2cap_config_rsp() dropping BT
connection if sender of configuration response replied with unknown
option failure (Result=0x0003/L2CAP_CONF_UNKNOWN)
- current implementation of l2cap_build_conf_req() adding
L2CAP_CONF_RFC(0x04) option to initial configure request sent by
the Linux host.
devices that do no recongninze L2CAP_CONF_RFC, such as Xbox One S
controllers, will get stuck in endless connect -> configure ->
disconnect loop, never connect and be generaly unusable.
To avoid this problem add code to do the following:
1. Store a mask of supported conf option types per connection
2. Parse the body of response L2CAP_CONF_UNKNOWN and adjust
connection's supported conf option types mask
3. Retry configuration step the same way it's done for
L2CAP_CONF_UNACCEPT
Signed-off-by: Andrey Smirnov <andrew.smirnov@xxxxxxxxx>
Cc: Pierre-Loup A. Griffais <pgriffais@xxxxxxxxxxxxxxxxx>
Cc: Florian Dollinger <dollinger.florian@xxxxxx>
Cc: Marcel Holtmann <marcel@xxxxxxxxxxxx>
Cc: Johan Hedberg <johan.hedberg@xxxxxxxxx>
Cc: linux-bluetooth@xxxxxxxxxxxxxxx
Cc: linux-kernel@xxxxxxxxxxxxxxx
---
Everyone:
I marked this as an RFC, since I don't have a lot of experience with
Bluetooth subsystem and don't have hight degree of confidence about
choices made in this patch. I do, however, thins is is good enough to
start a discussion about the problem.
can you take a btmon -w trace.log protocol trace so that I can see where it fails. This seems a really odd behavior of the Xbox controller. We have to be careful in not breaking Bluetooth qualification to just workaround some buggy remote device.
Sure, n/p, both "failure" (behavior before this patch) and "success"
(behavior with the patch) cases on my machine are available here:
https://gist.github.com/ndreys/2b74094933601978e200af1ff0a55372
Let me know if that's not accessible to you.
Marcel, did you have a chance to look at the logs?
Thanks,
Andrey Smirnov
