Re: [RFC] Bluetooth: Retry configure request if result is L2CAP_CONF_UNKNOWN

[Florian Dollinger]

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