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

Hi,

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

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


-- 
pozdrawiam
Szymon Janc