Re: [BlueZ PATCH v2 1/3] error: BR/EDR and LE connection failure reasons

On Fri, Jul 23, 2021 at 4:20 AM Szymon Janc [off-list ref] wrote:

Hi,

On Friday, 23 July 2021 09:38:40 CEST Marcel Holtmann wrote:

quoted

quoted

quoted

quoted

quoted

quoted

What is the intention to split BR/EDR and LE here. You do know
up-front what connection type you are. Trying to figure out from the
error code what connection you have been trying to establish is plain
wrong.>>>>

In fact the up-front connection type is not necessarily known. In the
case of dual-mode devices, such as Bose QC35, a D-Bus client can issue
Connect(), and it depends on the timing of connection request (adv
usually arrive first compared to inquiry result), it can be either
BR/EDR or LE link being established. Another aspect of this is the
metrics collection, where knowing transport can be handy. For
instance, we can associate the certain error to particular use cases
at application layer, and that can help targeting the bottleneck to
tackle.

Then we need to find a different way to convey the transport chosen.
Doing this by error message is a bad idea.>>>

quoted

quoted

The description is that you want to know exactly where the connection
failed. And I think that can be established independent from the
transport.>>>>

Indeed the intention is to know where it failed exactly. However, as
mentioned above, transport information is also an important piece of
information to know.

We need to find a different way to inform about which transport failed
(or better which was chosen in the first place).>

I would love to hear your thoughts on an alternative.  Many of the
Apis are transport agnostic (Connect/Pair may end up connecting to
either available transports for dual mode devices), but yet the error
that results from them are not.  Errors from one transport doesn't
make sense for one and vice versa.  A platform wanting to leverage
telemetry and metrics to drive ecosystem improvements would ultimately
need to know the difference even if the applications may not need to
care.

and we might have made a mistake in the API design and should have given the
caller more control. We need to review the API design and see if things
have to change. Just glueing things on at the end makes me suspicious.

Some (5, wow!) years back I've loosely proposed split for org.bluez.Device API
that was meant to handle some of the dual mode devices issues we've been
seeing [1] [2].

We never got time to fully implement it (mostly due to hacking around device.c
instead of properly splitting internal implementation into device_le.c and
device_bredr.c) but got some very initial PoC running.

With new interfaces old Device1 could be simply super-set of two for legacy
applications purposes.

Maybe such approach is worth re-considering?


[1] https://marc.info/?l=linux-bluetooth&m=145710680912268&w=2
[2] https://marc.info/?l=linux-bluetooth&m=145973293118003&w=2

Definitely worth reconsidering.  We've recently introduced a ConnectLE
Api as a stop gap measure for something very similar.  I'd love to see
the equivalent of a ConnectClassic / ConnectLE distinction.

However, I still believe the "Generic" Connect serves its purpose as
you alluded to above.  Even if it could be built using layers, I still
believe there is value from a telemetry POV to understand the errors
from the field better and there, the distinction between the specific
transport matter.  Just like today, I suspect many applications will
continue to use the generic "Connect" as to not replicate the logic it
ultimately implements for dealing with dual mode devices, yet
results/metrics would be important.

The team strives to improve interoperability at a large scale in the
ecosystem, I believe these data point distinctions are a critical
enabler to get better insights into the specific errors customers are
seeing.  A counter proposal that would be acceptable to you, achieves
the objectives and that the team can implement would be a nice next
step.

Thanks!
Alain

--
pozdrawiam
Szymon Janc