[PATCH] Install avinfo utility

[PATCH] Install avinfo utility

[Pali Rohár]

This utility is very useful for determining which A2DP codecs are supported
by remote side. So install it to system as part of bluez package.
---
 Makefile.tools | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile.tools b/Makefile.tools
index 9b9236609..d52721612 100644
--- a/Makefile.tools
+++ b/Makefile.tools
@@ -176,9 +176,9 @@ endif
 if TOOLS
 bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \
 			tools/bluemoon tools/hex2hcd tools/mpris-proxy \
-			tools/btattach
+			tools/btattach tools/avinfo
 
-noinst_PROGRAMS += tools/bdaddr tools/avinfo tools/avtest \
+noinst_PROGRAMS += tools/bdaddr tools/avtest \
 			tools/scotest tools/amptest tools/hwdb \
 			tools/hcieventmask tools/hcisecfilter \
 			tools/btinfo tools/btconfig \
-- 
2.20.1

Re: [PATCH] Install avinfo utility

[Pali Rohár]

On Wednesday 06 May 2020 21:34:35 Pali Rohár wrote:
> This utility is very useful for determining which A2DP codecs are supported
> by remote side. So install it to system as part of bluez package.
> ---
>  Makefile.tools | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Ping?

> diff --git a/Makefile.tools b/Makefile.tools
> index 9b9236609..d52721612 100644
> --- a/Makefile.tools
> +++ b/Makefile.tools
> @@ -176,9 +176,9 @@ endif
>  if TOOLS
>  bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \
>  			tools/bluemoon tools/hex2hcd tools/mpris-proxy \
> -			tools/btattach
> +			tools/btattach tools/avinfo
>  
> -noinst_PROGRAMS += tools/bdaddr tools/avinfo tools/avtest \
> +noinst_PROGRAMS += tools/bdaddr tools/avtest \
>  			tools/scotest tools/amptest tools/hwdb \
>  			tools/hcieventmask tools/hcisecfilter \
>  			tools/btinfo tools/btconfig \
> -- 
> 2.20.1
> 

Re: [PATCH] Install avinfo utility

[Marcel Holtmann]

Hi Pali,

> This utility is very useful for determining which A2DP codecs are supported
> by remote side. So install it to system as part of bluez package.
> ---
> Makefile.tools | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile.tools b/Makefile.tools
> index 9b9236609..d52721612 100644
> --- a/Makefile.tools
> +++ b/Makefile.tools
> @@ -176,9 +176,9 @@ endif
> if TOOLS
> bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \
> 			tools/bluemoon tools/hex2hcd tools/mpris-proxy \
> -			tools/btattach
> +			tools/btattach tools/avinfo
> 
> -noinst_PROGRAMS += tools/bdaddr tools/avinfo tools/avtest \
> +noinst_PROGRAMS += tools/bdaddr tools/avtest \
> 			tools/scotest tools/amptest tools/hwdb \
> 			tools/hcieventmask tools/hcisecfilter \
> 			tools/btinfo tools/btconfig \

I had no intention to install that tool since it is too limited and makes too many assumption. In addition it has a bad name with no Bluetooth prefix.

If we think it is useful to have such a test utility, then we need to clean this up first and put this into a larger btinfo work to gather appropriate information from a remote device for debug purposes.

Regards

Marcel

Re: [PATCH] Install avinfo utility

[Pali Rohár]

On Wednesday 10 June 2020 10:27:25 Marcel Holtmann wrote:
> Hi Pali,
> 
> > This utility is very useful for determining which A2DP codecs are supported
> > by remote side. So install it to system as part of bluez package.
> > ---
> > Makefile.tools | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Makefile.tools b/Makefile.tools
> > index 9b9236609..d52721612 100644
> > --- a/Makefile.tools
> > +++ b/Makefile.tools
> > @@ -176,9 +176,9 @@ endif
> > if TOOLS
> > bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \
> > 			tools/bluemoon tools/hex2hcd tools/mpris-proxy \
> > -			tools/btattach
> > +			tools/btattach tools/avinfo
> > 
> > -noinst_PROGRAMS += tools/bdaddr tools/avinfo tools/avtest \
> > +noinst_PROGRAMS += tools/bdaddr tools/avtest \
> > 			tools/scotest tools/amptest tools/hwdb \
> > 			tools/hcieventmask tools/hcisecfilter \
> > 			tools/btinfo tools/btconfig \
> 
> I had no intention to install that tool since it is too limited

Sorry, but I have not seen any limitations with this tool yet. I'm using
it very often. And also other people who use it have not mentioned any
limitations or problems.

So could you be more specific what are those limitations?

Also it is the first thing which I'm saying people that should run and
send me output of it if something related to A2DP does not work.

And because linux distributions do not package this utility and bluez
developers (for me for unknown reasons) decided to not install it,
result is that people have to always compile bluez from source to run
this utility if their A2DP audio does not work or "remote" debugging of
A2DP is needed.

So result is that who want to know why A2DP audio does not work is
forced to compile & install bluez from sources and not to use from
distribution package. And this probably not the expected state.

In any case, nobody reported to me any limitation with one exception
that it cannot decode capabilities of some custom vendor codecs. But
most of them are already supported as I sent needed patches in past.

> and makes too many assumption.

For example which assumptions?

> In addition it has a bad name with no Bluetooth prefix.

So, lets rename it. What about "btavinfo"?

> If we think it is useful to have such a test utility, then we need to clean this up first

What exactly to clean up first?

Note that I have already done cleanup of this utility.

> and put this into a larger btinfo work to gather appropriate information from a remote device for debug purposes.

I do not see how btinfo can be used for A2DP purposes. Seems this is
utility for local controller info and not for remove A2DP.

Re: [PATCH] Install avinfo utility

[Marcel Holtmann]

Hi Pali,

>>> This utility is very useful for determining which A2DP codecs are supported
>>> by remote side. So install it to system as part of bluez package.
>>> ---
>>> Makefile.tools | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/Makefile.tools b/Makefile.tools
>>> index 9b9236609..d52721612 100644
>>> --- a/Makefile.tools
>>> +++ b/Makefile.tools
>>> @@ -176,9 +176,9 @@ endif
>>> if TOOLS
>>> bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \
>>> 			tools/bluemoon tools/hex2hcd tools/mpris-proxy \
>>> -			tools/btattach
>>> +			tools/btattach tools/avinfo
>>> 
>>> -noinst_PROGRAMS += tools/bdaddr tools/avinfo tools/avtest \
>>> +noinst_PROGRAMS += tools/bdaddr tools/avtest \
>>> 			tools/scotest tools/amptest tools/hwdb \
>>> 			tools/hcieventmask tools/hcisecfilter \
>>> 			tools/btinfo tools/btconfig \
>> 
>> I had no intention to install that tool since it is too limited
> 
> Sorry, but I have not seen any limitations with this tool yet. I'm using
> it very often. And also other people who use it have not mentioned any
> limitations or problems.
> 
> So could you be more specific what are those limitations?
> 
> Also it is the first thing which I'm saying people that should run and
> send me output of it if something related to A2DP does not work.
> 
> And because linux distributions do not package this utility and bluez
> developers (for me for unknown reasons) decided to not install it,
> result is that people have to always compile bluez from source to run
> this utility if their A2DP audio does not work or "remote" debugging of
> A2DP is needed.
> 
> So result is that who want to know why A2DP audio does not work is
> forced to compile & install bluez from sources and not to use from
> distribution package. And this probably not the expected state.
> 
> In any case, nobody reported to me any limitation with one exception
> that it cannot decode capabilities of some custom vendor codecs. But
> most of them are already supported as I sent needed patches in past.
> 
>> and makes too many assumption.
> 
> For example which assumptions?

that nothing else is happening right now. It backstabs the actual AVDTP and A2DP implementation.

>> In addition it has a bad name with no Bluetooth prefix.
> 
> So, lets rename it. What about "btavinfo"?

Lets extend btinfo with all sort of capabilities. Make the av portion just one of. I want to remove the multitudes of test utilities anyway. We have to many tiny utilities that are just scattered around and avinfo is just one of them.

> 
>> If we think it is useful to have such a test utility, then we need to clean this up first
> 
> What exactly to clean up first?
> 
> Note that I have already done cleanup of this utility.
> 
>> and put this into a larger btinfo work to gather appropriate information from a remote device for debug purposes.
> 
> I do not see how btinfo can be used for A2DP purposes. Seems this is
> utility for local controller info and not for remove A2DP.

This needs a bit thinking, but pretty much simple things like this:

	btinfo local
	btinfo avdtp <remote_bdaddr>

We can create a module handling system so that you can easily links existing tiny utilities into one.

Regards

Marcel

Re: [PATCH] Install avinfo utility

[Pali Rohár]

On Wednesday 10 June 2020 19:31:47 Marcel Holtmann wrote:
> Hi Pali,
> 
> >>> This utility is very useful for determining which A2DP codecs are supported
> >>> by remote side. So install it to system as part of bluez package.
> >>> ---
> >>> Makefile.tools | 4 ++--
> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>> 
> >>> diff --git a/Makefile.tools b/Makefile.tools
> >>> index 9b9236609..d52721612 100644
> >>> --- a/Makefile.tools
> >>> +++ b/Makefile.tools
> >>> @@ -176,9 +176,9 @@ endif
> >>> if TOOLS
> >>> bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \
> >>> 			tools/bluemoon tools/hex2hcd tools/mpris-proxy \
> >>> -			tools/btattach
> >>> +			tools/btattach tools/avinfo
> >>> 
> >>> -noinst_PROGRAMS += tools/bdaddr tools/avinfo tools/avtest \
> >>> +noinst_PROGRAMS += tools/bdaddr tools/avtest \
> >>> 			tools/scotest tools/amptest tools/hwdb \
> >>> 			tools/hcieventmask tools/hcisecfilter \
> >>> 			tools/btinfo tools/btconfig \
> >> 
> >> I had no intention to install that tool since it is too limited
> > 
> > Sorry, but I have not seen any limitations with this tool yet. I'm using
> > it very often. And also other people who use it have not mentioned any
> > limitations or problems.
> > 
> > So could you be more specific what are those limitations?
> > 
> > Also it is the first thing which I'm saying people that should run and
> > send me output of it if something related to A2DP does not work.
> > 
> > And because linux distributions do not package this utility and bluez
> > developers (for me for unknown reasons) decided to not install it,
> > result is that people have to always compile bluez from source to run
> > this utility if their A2DP audio does not work or "remote" debugging of
> > A2DP is needed.
> > 
> > So result is that who want to know why A2DP audio does not work is
> > forced to compile & install bluez from sources and not to use from
> > distribution package. And this probably not the expected state.
> > 
> > In any case, nobody reported to me any limitation with one exception
> > that it cannot decode capabilities of some custom vendor codecs. But
> > most of them are already supported as I sent needed patches in past.
> > 
> >> and makes too many assumption.
> > 
> > For example which assumptions?
> 
> that nothing else is happening right now. It backstabs the actual AVDTP and A2DP implementation.

Marcel, but this is not a problem. For that one purpose which avinfo
provides it ideal and works fine. Personally I do not see any problem
with it.

> >> In addition it has a bad name with no Bluetooth prefix.
> > 
> > So, lets rename it. What about "btavinfo"?
> 
> Lets extend btinfo with all sort of capabilities. Make the av portion just one of. I want to remove the multitudes of test utilities anyway. We have to many tiny utilities that are just scattered around and avinfo is just one of them.

This looks like a not-so-trivial task and moreover independent of
providing current version of avinfo to users.

avinfo already exists, is already part of bluez project, it is already
compiling during bluez build and is already used by me and lot of other
users and works for that one purpose as expected.

> > 
> >> If we think it is useful to have such a test utility, then we need to clean this up first
> > 
> > What exactly to clean up first?
> > 
> > Note that I have already done cleanup of this utility.
> > 
> >> and put this into a larger btinfo work to gather appropriate information from a remote device for debug purposes.
> > 
> > I do not see how btinfo can be used for A2DP purposes. Seems this is
> > utility for local controller info and not for remove A2DP.
> 
> This needs a bit thinking, but pretty much simple things like this:
> 
> 	btinfo local
> 	btinfo avdtp <remote_bdaddr>
> 
> We can create a module handling system so that you can easily links existing tiny utilities into one.

I'm not against this change. But this is additional work which needs to
be done. And it would not happen today or tomorrow unless you have
already patches which implement it.

As I said avinfo is already there, implemented, it is working and is
part of bluez source code. And is basically the first step when
debugging issues with A2DP audio.

So what is the real issue with not only compiling this avinfo tool
during building bluez but also installing it?

Re: [PATCH] Install avinfo utility

[Pali Rohár]

On Thursday 11 June 2020 14:53:04 Pali Rohár wrote:
> On Wednesday 10 June 2020 19:31:47 Marcel Holtmann wrote:
> > Hi Pali,
> > 
> > >>> This utility is very useful for determining which A2DP codecs are supported
> > >>> by remote side. So install it to system as part of bluez package.
> > >>> ---
> > >>> Makefile.tools | 4 ++--
> > >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> > >>> 
> > >>> diff --git a/Makefile.tools b/Makefile.tools
> > >>> index 9b9236609..d52721612 100644
> > >>> --- a/Makefile.tools
> > >>> +++ b/Makefile.tools
> > >>> @@ -176,9 +176,9 @@ endif
> > >>> if TOOLS
> > >>> bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \
> > >>> 			tools/bluemoon tools/hex2hcd tools/mpris-proxy \
> > >>> -			tools/btattach
> > >>> +			tools/btattach tools/avinfo
> > >>> 
> > >>> -noinst_PROGRAMS += tools/bdaddr tools/avinfo tools/avtest \
> > >>> +noinst_PROGRAMS += tools/bdaddr tools/avtest \
> > >>> 			tools/scotest tools/amptest tools/hwdb \
> > >>> 			tools/hcieventmask tools/hcisecfilter \
> > >>> 			tools/btinfo tools/btconfig \
> > >> 
> > >> I had no intention to install that tool since it is too limited
> > > 
> > > Sorry, but I have not seen any limitations with this tool yet. I'm using
> > > it very often. And also other people who use it have not mentioned any
> > > limitations or problems.
> > > 
> > > So could you be more specific what are those limitations?
> > > 
> > > Also it is the first thing which I'm saying people that should run and
> > > send me output of it if something related to A2DP does not work.
> > > 
> > > And because linux distributions do not package this utility and bluez
> > > developers (for me for unknown reasons) decided to not install it,
> > > result is that people have to always compile bluez from source to run
> > > this utility if their A2DP audio does not work or "remote" debugging of
> > > A2DP is needed.
> > > 
> > > So result is that who want to know why A2DP audio does not work is
> > > forced to compile & install bluez from sources and not to use from
> > > distribution package. And this probably not the expected state.
> > > 
> > > In any case, nobody reported to me any limitation with one exception
> > > that it cannot decode capabilities of some custom vendor codecs. But
> > > most of them are already supported as I sent needed patches in past.
> > > 
> > >> and makes too many assumption.
> > > 
> > > For example which assumptions?
> > 
> > that nothing else is happening right now. It backstabs the actual AVDTP and A2DP implementation.
> 
> Marcel, but this is not a problem. For that one purpose which avinfo
> provides it ideal and works fine. Personally I do not see any problem
> with it.
> 
> > >> In addition it has a bad name with no Bluetooth prefix.
> > > 
> > > So, lets rename it. What about "btavinfo"?
> > 
> > Lets extend btinfo with all sort of capabilities. Make the av portion just one of. I want to remove the multitudes of test utilities anyway. We have to many tiny utilities that are just scattered around and avinfo is just one of them.
> 
> This looks like a not-so-trivial task and moreover independent of
> providing current version of avinfo to users.
> 
> avinfo already exists, is already part of bluez project, it is already
> compiling during bluez build and is already used by me and lot of other
> users and works for that one purpose as expected.
> 
> > > 
> > >> If we think it is useful to have such a test utility, then we need to clean this up first
> > > 
> > > What exactly to clean up first?
> > > 
> > > Note that I have already done cleanup of this utility.
> > > 
> > >> and put this into a larger btinfo work to gather appropriate information from a remote device for debug purposes.
> > > 
> > > I do not see how btinfo can be used for A2DP purposes. Seems this is
> > > utility for local controller info and not for remove A2DP.
> > 
> > This needs a bit thinking, but pretty much simple things like this:
> > 
> > 	btinfo local
> > 	btinfo avdtp <remote_bdaddr>
> > 
> > We can create a module handling system so that you can easily links existing tiny utilities into one.
> 
> I'm not against this change. But this is additional work which needs to
> be done. And it would not happen today or tomorrow unless you have
> already patches which implement it.
> 
> As I said avinfo is already there, implemented, it is working and is
> part of bluez source code. And is basically the first step when
> debugging issues with A2DP audio.
> 
> So what is the real issue with not only compiling this avinfo tool
> during building bluez but also installing it?

Because nobody presented any real issue for more then month and I'm not
aware of any, could be avinfo finally enabled during installation?

Re: [PATCH] Install avinfo utility

[Pali Rohár]

On Monday 13 July 2020 11:09:13 Pali Rohár wrote:
> On Thursday 11 June 2020 14:53:04 Pali Rohár wrote:
> > On Wednesday 10 June 2020 19:31:47 Marcel Holtmann wrote:
> > > Hi Pali,
> > > 
> > > >>> This utility is very useful for determining which A2DP codecs are supported
> > > >>> by remote side. So install it to system as part of bluez package.
> > > >>> ---
> > > >>> Makefile.tools | 4 ++--
> > > >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >>> 
> > > >>> diff --git a/Makefile.tools b/Makefile.tools
> > > >>> index 9b9236609..d52721612 100644
> > > >>> --- a/Makefile.tools
> > > >>> +++ b/Makefile.tools
> > > >>> @@ -176,9 +176,9 @@ endif
> > > >>> if TOOLS
> > > >>> bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \
> > > >>> 			tools/bluemoon tools/hex2hcd tools/mpris-proxy \
> > > >>> -			tools/btattach
> > > >>> +			tools/btattach tools/avinfo
> > > >>> 
> > > >>> -noinst_PROGRAMS += tools/bdaddr tools/avinfo tools/avtest \
> > > >>> +noinst_PROGRAMS += tools/bdaddr tools/avtest \
> > > >>> 			tools/scotest tools/amptest tools/hwdb \
> > > >>> 			tools/hcieventmask tools/hcisecfilter \
> > > >>> 			tools/btinfo tools/btconfig \
> > > >> 
> > > >> I had no intention to install that tool since it is too limited
> > > > 
> > > > Sorry, but I have not seen any limitations with this tool yet. I'm using
> > > > it very often. And also other people who use it have not mentioned any
> > > > limitations or problems.
> > > > 
> > > > So could you be more specific what are those limitations?
> > > > 
> > > > Also it is the first thing which I'm saying people that should run and
> > > > send me output of it if something related to A2DP does not work.
> > > > 
> > > > And because linux distributions do not package this utility and bluez
> > > > developers (for me for unknown reasons) decided to not install it,
> > > > result is that people have to always compile bluez from source to run
> > > > this utility if their A2DP audio does not work or "remote" debugging of
> > > > A2DP is needed.
> > > > 
> > > > So result is that who want to know why A2DP audio does not work is
> > > > forced to compile & install bluez from sources and not to use from
> > > > distribution package. And this probably not the expected state.
> > > > 
> > > > In any case, nobody reported to me any limitation with one exception
> > > > that it cannot decode capabilities of some custom vendor codecs. But
> > > > most of them are already supported as I sent needed patches in past.
> > > > 
> > > >> and makes too many assumption.
> > > > 
> > > > For example which assumptions?
> > > 
> > > that nothing else is happening right now. It backstabs the actual AVDTP and A2DP implementation.
> > 
> > Marcel, but this is not a problem. For that one purpose which avinfo
> > provides it ideal and works fine. Personally I do not see any problem
> > with it.
> > 
> > > >> In addition it has a bad name with no Bluetooth prefix.
> > > > 
> > > > So, lets rename it. What about "btavinfo"?
> > > 
> > > Lets extend btinfo with all sort of capabilities. Make the av portion just one of. I want to remove the multitudes of test utilities anyway. We have to many tiny utilities that are just scattered around and avinfo is just one of them.
> > 
> > This looks like a not-so-trivial task and moreover independent of
> > providing current version of avinfo to users.
> > 
> > avinfo already exists, is already part of bluez project, it is already
> > compiling during bluez build and is already used by me and lot of other
> > users and works for that one purpose as expected.
> > 
> > > > 
> > > >> If we think it is useful to have such a test utility, then we need to clean this up first
> > > > 
> > > > What exactly to clean up first?
> > > > 
> > > > Note that I have already done cleanup of this utility.
> > > > 
> > > >> and put this into a larger btinfo work to gather appropriate information from a remote device for debug purposes.
> > > > 
> > > > I do not see how btinfo can be used for A2DP purposes. Seems this is
> > > > utility for local controller info and not for remove A2DP.
> > > 
> > > This needs a bit thinking, but pretty much simple things like this:
> > > 
> > > 	btinfo local
> > > 	btinfo avdtp <remote_bdaddr>
> > > 
> > > We can create a module handling system so that you can easily links existing tiny utilities into one.
> > 
> > I'm not against this change. But this is additional work which needs to
> > be done. And it would not happen today or tomorrow unless you have
> > already patches which implement it.
> > 
> > As I said avinfo is already there, implemented, it is working and is
> > part of bluez source code. And is basically the first step when
> > debugging issues with A2DP audio.
> > 
> > So what is the real issue with not only compiling this avinfo tool
> > during building bluez but also installing it?
> 
> Because nobody presented any real issue for more then month and I'm not
> aware of any, could be avinfo finally enabled during installation?

PING, two months passed and I have not received any new reply to this patch.

If there are really no problems, could it be applied?

Re: [PATCH] Install avinfo utility

[Luiz Augusto von Dentz]

Hi Pali,

On Sat, Aug 8, 2020 at 6:20 AM Pali Rohár <pali@kernel.org> wrote:
>
> On Monday 13 July 2020 11:09:13 Pali Rohár wrote:
> > On Thursday 11 June 2020 14:53:04 Pali Rohár wrote:
> > > On Wednesday 10 June 2020 19:31:47 Marcel Holtmann wrote:
> > > > Hi Pali,
> > > >
> > > > >>> This utility is very useful for determining which A2DP codecs are supported
> > > > >>> by remote side. So install it to system as part of bluez package.
> > > > >>> ---
> > > > >>> Makefile.tools | 4 ++--
> > > > >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > >>>
> > > > >>> diff --git a/Makefile.tools b/Makefile.tools
> > > > >>> index 9b9236609..d52721612 100644
> > > > >>> --- a/Makefile.tools
> > > > >>> +++ b/Makefile.tools
> > > > >>> @@ -176,9 +176,9 @@ endif
> > > > >>> if TOOLS
> > > > >>> bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \
> > > > >>>                       tools/bluemoon tools/hex2hcd tools/mpris-proxy \
> > > > >>> -                     tools/btattach
> > > > >>> +                     tools/btattach tools/avinfo
> > > > >>>
> > > > >>> -noinst_PROGRAMS += tools/bdaddr tools/avinfo tools/avtest \
> > > > >>> +noinst_PROGRAMS += tools/bdaddr tools/avtest \
> > > > >>>                       tools/scotest tools/amptest tools/hwdb \
> > > > >>>                       tools/hcieventmask tools/hcisecfilter \
> > > > >>>                       tools/btinfo tools/btconfig \
> > > > >>
> > > > >> I had no intention to install that tool since it is too limited
> > > > >
> > > > > Sorry, but I have not seen any limitations with this tool yet. I'm using
> > > > > it very often. And also other people who use it have not mentioned any
> > > > > limitations or problems.
> > > > >
> > > > > So could you be more specific what are those limitations?
> > > > >
> > > > > Also it is the first thing which I'm saying people that should run and
> > > > > send me output of it if something related to A2DP does not work.
> > > > >
> > > > > And because linux distributions do not package this utility and bluez
> > > > > developers (for me for unknown reasons) decided to not install it,
> > > > > result is that people have to always compile bluez from source to run
> > > > > this utility if their A2DP audio does not work or "remote" debugging of
> > > > > A2DP is needed.
> > > > >
> > > > > So result is that who want to know why A2DP audio does not work is
> > > > > forced to compile & install bluez from sources and not to use from
> > > > > distribution package. And this probably not the expected state.
> > > > >
> > > > > In any case, nobody reported to me any limitation with one exception
> > > > > that it cannot decode capabilities of some custom vendor codecs. But
> > > > > most of them are already supported as I sent needed patches in past.
> > > > >
> > > > >> and makes too many assumption.
> > > > >
> > > > > For example which assumptions?
> > > >
> > > > that nothing else is happening right now. It backstabs the actual AVDTP and A2DP implementation.
> > >
> > > Marcel, but this is not a problem. For that one purpose which avinfo
> > > provides it ideal and works fine. Personally I do not see any problem
> > > with it.
> > >
> > > > >> In addition it has a bad name with no Bluetooth prefix.
> > > > >
> > > > > So, lets rename it. What about "btavinfo"?
> > > >
> > > > Lets extend btinfo with all sort of capabilities. Make the av portion just one of. I want to remove the multitudes of test utilities anyway. We have to many tiny utilities that are just scattered around and avinfo is just one of them.
> > >
> > > This looks like a not-so-trivial task and moreover independent of
> > > providing current version of avinfo to users.
> > >
> > > avinfo already exists, is already part of bluez project, it is already
> > > compiling during bluez build and is already used by me and lot of other
> > > users and works for that one purpose as expected.
> > >
> > > > >
> > > > >> If we think it is useful to have such a test utility, then we need to clean this up first
> > > > >
> > > > > What exactly to clean up first?
> > > > >
> > > > > Note that I have already done cleanup of this utility.
> > > > >
> > > > >> and put this into a larger btinfo work to gather appropriate information from a remote device for debug purposes.
> > > > >
> > > > > I do not see how btinfo can be used for A2DP purposes. Seems this is
> > > > > utility for local controller info and not for remove A2DP.
> > > >
> > > > This needs a bit thinking, but pretty much simple things like this:
> > > >
> > > >   btinfo local
> > > >   btinfo avdtp <remote_bdaddr>
> > > >
> > > > We can create a module handling system so that you can easily links existing tiny utilities into one.
> > >
> > > I'm not against this change. But this is additional work which needs to
> > > be done. And it would not happen today or tomorrow unless you have
> > > already patches which implement it.
> > >
> > > As I said avinfo is already there, implemented, it is working and is
> > > part of bluez source code. And is basically the first step when
> > > debugging issues with A2DP audio.
> > >
> > > So what is the real issue with not only compiling this avinfo tool
> > > during building bluez but also installing it?
> >
> > Because nobody presented any real issue for more then month and I'm not
> > aware of any, could be avinfo finally enabled during installation?
>
> PING, two months passed and I have not received any new reply to this patch.
>
> If there are really no problems, could it be applied?

For the record I do intend to enable listing available endpoints in
bluetooth-player, which might actually get merged into bluetoothctl as
a new menu, recently there have been some vulnerabilities reported
against these kind of tools that are meant to only be used for testing
purposes so I would only be in favor of installing them with we add
some new build option i.e. --enable-testing and document that these
tools are meant for testing only (and shall probably be package
separately) so we avoid these pointless reports for tools that are not
really meant to be used in production.

-- 
Luiz Augusto von Dentz

Re: [PATCH] Install avinfo utility

[Pali Rohár]

On Saturday 08 August 2020 22:33:48 Luiz Augusto von Dentz wrote:
> Hi Pali,
> 
> On Sat, Aug 8, 2020 at 6:20 AM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Monday 13 July 2020 11:09:13 Pali Rohár wrote:
> > > On Thursday 11 June 2020 14:53:04 Pali Rohár wrote:
> > > > On Wednesday 10 June 2020 19:31:47 Marcel Holtmann wrote:
> > > > > Hi Pali,
> > > > >
> > > > > >>> This utility is very useful for determining which A2DP codecs are supported
> > > > > >>> by remote side. So install it to system as part of bluez package.
> > > > > >>> ---
> > > > > >>> Makefile.tools | 4 ++--
> > > > > >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > >>>
> > > > > >>> diff --git a/Makefile.tools b/Makefile.tools
> > > > > >>> index 9b9236609..d52721612 100644
> > > > > >>> --- a/Makefile.tools
> > > > > >>> +++ b/Makefile.tools
> > > > > >>> @@ -176,9 +176,9 @@ endif
> > > > > >>> if TOOLS
> > > > > >>> bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \
> > > > > >>>                       tools/bluemoon tools/hex2hcd tools/mpris-proxy \
> > > > > >>> -                     tools/btattach
> > > > > >>> +                     tools/btattach tools/avinfo
> > > > > >>>
> > > > > >>> -noinst_PROGRAMS += tools/bdaddr tools/avinfo tools/avtest \
> > > > > >>> +noinst_PROGRAMS += tools/bdaddr tools/avtest \
> > > > > >>>                       tools/scotest tools/amptest tools/hwdb \
> > > > > >>>                       tools/hcieventmask tools/hcisecfilter \
> > > > > >>>                       tools/btinfo tools/btconfig \
> > > > > >>
> > > > > >> I had no intention to install that tool since it is too limited
> > > > > >
> > > > > > Sorry, but I have not seen any limitations with this tool yet. I'm using
> > > > > > it very often. And also other people who use it have not mentioned any
> > > > > > limitations or problems.
> > > > > >
> > > > > > So could you be more specific what are those limitations?
> > > > > >
> > > > > > Also it is the first thing which I'm saying people that should run and
> > > > > > send me output of it if something related to A2DP does not work.
> > > > > >
> > > > > > And because linux distributions do not package this utility and bluez
> > > > > > developers (for me for unknown reasons) decided to not install it,
> > > > > > result is that people have to always compile bluez from source to run
> > > > > > this utility if their A2DP audio does not work or "remote" debugging of
> > > > > > A2DP is needed.
> > > > > >
> > > > > > So result is that who want to know why A2DP audio does not work is
> > > > > > forced to compile & install bluez from sources and not to use from
> > > > > > distribution package. And this probably not the expected state.
> > > > > >
> > > > > > In any case, nobody reported to me any limitation with one exception
> > > > > > that it cannot decode capabilities of some custom vendor codecs. But
> > > > > > most of them are already supported as I sent needed patches in past.
> > > > > >
> > > > > >> and makes too many assumption.
> > > > > >
> > > > > > For example which assumptions?
> > > > >
> > > > > that nothing else is happening right now. It backstabs the actual AVDTP and A2DP implementation.
> > > >
> > > > Marcel, but this is not a problem. For that one purpose which avinfo
> > > > provides it ideal and works fine. Personally I do not see any problem
> > > > with it.
> > > >
> > > > > >> In addition it has a bad name with no Bluetooth prefix.
> > > > > >
> > > > > > So, lets rename it. What about "btavinfo"?
> > > > >
> > > > > Lets extend btinfo with all sort of capabilities. Make the av portion just one of. I want to remove the multitudes of test utilities anyway. We have to many tiny utilities that are just scattered around and avinfo is just one of them.
> > > >
> > > > This looks like a not-so-trivial task and moreover independent of
> > > > providing current version of avinfo to users.
> > > >
> > > > avinfo already exists, is already part of bluez project, it is already
> > > > compiling during bluez build and is already used by me and lot of other
> > > > users and works for that one purpose as expected.
> > > >
> > > > > >
> > > > > >> If we think it is useful to have such a test utility, then we need to clean this up first
> > > > > >
> > > > > > What exactly to clean up first?
> > > > > >
> > > > > > Note that I have already done cleanup of this utility.
> > > > > >
> > > > > >> and put this into a larger btinfo work to gather appropriate information from a remote device for debug purposes.
> > > > > >
> > > > > > I do not see how btinfo can be used for A2DP purposes. Seems this is
> > > > > > utility for local controller info and not for remove A2DP.
> > > > >
> > > > > This needs a bit thinking, but pretty much simple things like this:
> > > > >
> > > > >   btinfo local
> > > > >   btinfo avdtp <remote_bdaddr>
> > > > >
> > > > > We can create a module handling system so that you can easily links existing tiny utilities into one.
> > > >
> > > > I'm not against this change. But this is additional work which needs to
> > > > be done. And it would not happen today or tomorrow unless you have
> > > > already patches which implement it.
> > > >
> > > > As I said avinfo is already there, implemented, it is working and is
> > > > part of bluez source code. And is basically the first step when
> > > > debugging issues with A2DP audio.
> > > >
> > > > So what is the real issue with not only compiling this avinfo tool
> > > > during building bluez but also installing it?
> > >
> > > Because nobody presented any real issue for more then month and I'm not
> > > aware of any, could be avinfo finally enabled during installation?
> >
> > PING, two months passed and I have not received any new reply to this patch.
> >
> > If there are really no problems, could it be applied?
> 
> For the record I do intend to enable listing available endpoints in
> bluetooth-player, which might actually get merged into bluetoothctl as
> a new menu,

Will it provide everything which is avinfo provides?

> recently there have been some vulnerabilities reported
> against these kind of tools that are meant to only be used for testing
> purposes

Could you be more specific what is that vulnerability, so we can fix it?

It is the only issue? If yes, I'm going to fix it once I receive
details about it.

> so I would only be in favor of installing them with we add
> some new build option i.e. --enable-testing and document that these
> tools are meant for testing only (and shall probably be package
> separately) so we avoid these pointless reports for tools that are not
> really meant to be used in production.

As I said, avinfo is required tool for debugging A2DP audio transfers in
case there are problems and probably it is the only tool useful for such
purpose.

Lot of users are reporting that "audio does not work" and the only way
to debug is, is to ask users to provide full output of avinfo.

Well, it can be classified as "testing tool", but highly required in
case audio does not work.

So please provide information about that vulnerability and I will fix
it. As being silent for two months about existing vulnerability is not
really good.

Re: [PATCH] Install avinfo utility

[Luiz Augusto von Dentz]

Hi Pali,

On Sun, Aug 9, 2020 at 8:33 AM Pali Rohár <pali@kernel.org> wrote:
>
> On Saturday 08 August 2020 22:33:48 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> >
> > On Sat, Aug 8, 2020 at 6:20 AM Pali Rohár <pali@kernel.org> wrote:
> > >
> > > On Monday 13 July 2020 11:09:13 Pali Rohár wrote:
> > > > On Thursday 11 June 2020 14:53:04 Pali Rohár wrote:
> > > > > On Wednesday 10 June 2020 19:31:47 Marcel Holtmann wrote:
> > > > > > Hi Pali,
> > > > > >
> > > > > > >>> This utility is very useful for determining which A2DP codecs are supported
> > > > > > >>> by remote side. So install it to system as part of bluez package.
> > > > > > >>> ---
> > > > > > >>> Makefile.tools | 4 ++--
> > > > > > >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > >>>
> > > > > > >>> diff --git a/Makefile.tools b/Makefile.tools
> > > > > > >>> index 9b9236609..d52721612 100644
> > > > > > >>> --- a/Makefile.tools
> > > > > > >>> +++ b/Makefile.tools
> > > > > > >>> @@ -176,9 +176,9 @@ endif
> > > > > > >>> if TOOLS
> > > > > > >>> bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \
> > > > > > >>>                       tools/bluemoon tools/hex2hcd tools/mpris-proxy \
> > > > > > >>> -                     tools/btattach
> > > > > > >>> +                     tools/btattach tools/avinfo
> > > > > > >>>
> > > > > > >>> -noinst_PROGRAMS += tools/bdaddr tools/avinfo tools/avtest \
> > > > > > >>> +noinst_PROGRAMS += tools/bdaddr tools/avtest \
> > > > > > >>>                       tools/scotest tools/amptest tools/hwdb \
> > > > > > >>>                       tools/hcieventmask tools/hcisecfilter \
> > > > > > >>>                       tools/btinfo tools/btconfig \
> > > > > > >>
> > > > > > >> I had no intention to install that tool since it is too limited
> > > > > > >
> > > > > > > Sorry, but I have not seen any limitations with this tool yet. I'm using
> > > > > > > it very often. And also other people who use it have not mentioned any
> > > > > > > limitations or problems.
> > > > > > >
> > > > > > > So could you be more specific what are those limitations?
> > > > > > >
> > > > > > > Also it is the first thing which I'm saying people that should run and
> > > > > > > send me output of it if something related to A2DP does not work.
> > > > > > >
> > > > > > > And because linux distributions do not package this utility and bluez
> > > > > > > developers (for me for unknown reasons) decided to not install it,
> > > > > > > result is that people have to always compile bluez from source to run
> > > > > > > this utility if their A2DP audio does not work or "remote" debugging of
> > > > > > > A2DP is needed.
> > > > > > >
> > > > > > > So result is that who want to know why A2DP audio does not work is
> > > > > > > forced to compile & install bluez from sources and not to use from
> > > > > > > distribution package. And this probably not the expected state.
> > > > > > >
> > > > > > > In any case, nobody reported to me any limitation with one exception
> > > > > > > that it cannot decode capabilities of some custom vendor codecs. But
> > > > > > > most of them are already supported as I sent needed patches in past.
> > > > > > >
> > > > > > >> and makes too many assumption.
> > > > > > >
> > > > > > > For example which assumptions?
> > > > > >
> > > > > > that nothing else is happening right now. It backstabs the actual AVDTP and A2DP implementation.
> > > > >
> > > > > Marcel, but this is not a problem. For that one purpose which avinfo
> > > > > provides it ideal and works fine. Personally I do not see any problem
> > > > > with it.
> > > > >
> > > > > > >> In addition it has a bad name with no Bluetooth prefix.
> > > > > > >
> > > > > > > So, lets rename it. What about "btavinfo"?
> > > > > >
> > > > > > Lets extend btinfo with all sort of capabilities. Make the av portion just one of. I want to remove the multitudes of test utilities anyway. We have to many tiny utilities that are just scattered around and avinfo is just one of them.
> > > > >
> > > > > This looks like a not-so-trivial task and moreover independent of
> > > > > providing current version of avinfo to users.
> > > > >
> > > > > avinfo already exists, is already part of bluez project, it is already
> > > > > compiling during bluez build and is already used by me and lot of other
> > > > > users and works for that one purpose as expected.
> > > > >
> > > > > > >
> > > > > > >> If we think it is useful to have such a test utility, then we need to clean this up first
> > > > > > >
> > > > > > > What exactly to clean up first?
> > > > > > >
> > > > > > > Note that I have already done cleanup of this utility.
> > > > > > >
> > > > > > >> and put this into a larger btinfo work to gather appropriate information from a remote device for debug purposes.
> > > > > > >
> > > > > > > I do not see how btinfo can be used for A2DP purposes. Seems this is
> > > > > > > utility for local controller info and not for remove A2DP.
> > > > > >
> > > > > > This needs a bit thinking, but pretty much simple things like this:
> > > > > >
> > > > > >   btinfo local
> > > > > >   btinfo avdtp <remote_bdaddr>
> > > > > >
> > > > > > We can create a module handling system so that you can easily links existing tiny utilities into one.
> > > > >
> > > > > I'm not against this change. But this is additional work which needs to
> > > > > be done. And it would not happen today or tomorrow unless you have
> > > > > already patches which implement it.
> > > > >
> > > > > As I said avinfo is already there, implemented, it is working and is
> > > > > part of bluez source code. And is basically the first step when
> > > > > debugging issues with A2DP audio.
> > > > >
> > > > > So what is the real issue with not only compiling this avinfo tool
> > > > > during building bluez but also installing it?
> > > >
> > > > Because nobody presented any real issue for more then month and I'm not
> > > > aware of any, could be avinfo finally enabled during installation?
> > >
> > > PING, two months passed and I have not received any new reply to this patch.
> > >
> > > If there are really no problems, could it be applied?
> >
> > For the record I do intend to enable listing available endpoints in
> > bluetooth-player, which might actually get merged into bluetoothctl as
> > a new menu,
>
> Will it provide everything which is avinfo provides?

Regarding endpoints yes, it is the endpoint information that has been
exposed via D-Bus objects.

> > recently there have been some vulnerabilities reported
> > against these kind of tools that are meant to only be used for testing
> > purposes
>
> Could you be more specific what is that vulnerability, so we can fix it?

It is not related to avinfo, it was gatttool if you are curious about
it, but most if not all our tools do tend to leak memory when they are
exiting which would trigger some analyzer, etc, to have pointless
reports about those leaks.

> It is the only issue? If yes, I'm going to fix it once I receive
> details about it.
>
> > so I would only be in favor of installing them with we add
> > some new build option i.e. --enable-testing and document that these
> > tools are meant for testing only (and shall probably be package
> > separately) so we avoid these pointless reports for tools that are not
> > really meant to be used in production.
>
> As I said, avinfo is required tool for debugging A2DP audio transfers in
> case there are problems and probably it is the only tool useful for such
> purpose.
>
> Lot of users are reporting that "audio does not work" and the only way
> to debug is, is to ask users to provide full output of avinfo.

Well if the issue is at the negotiation it avinfo is not the useful,
btmon traces are what I usually recommend having as you can figure out
what issues are 99% of the time.

> Well, it can be classified as "testing tool", but highly required in
> case audio does not work.

It is not a qualifiable implementation that is for sure, so
classifying it as a testing tool is the best we can do.

> So please provide information about that vulnerability and I will fix
> it. As being silent for two months about existing vulnerability is not
> really good.



-- 
Luiz Augusto von Dentz

Re: [PATCH] Install avinfo utility

[Pali Rohár]

On Sunday 09 August 2020 11:22:53 Luiz Augusto von Dentz wrote:
> Hi Pali,
> 
> On Sun, Aug 9, 2020 at 8:33 AM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Saturday 08 August 2020 22:33:48 Luiz Augusto von Dentz wrote:
> > > Hi Pali,
> > >
> > > On Sat, Aug 8, 2020 at 6:20 AM Pali Rohár <pali@kernel.org> wrote:
> > > >
> > > > On Monday 13 July 2020 11:09:13 Pali Rohár wrote:
> > > > > On Thursday 11 June 2020 14:53:04 Pali Rohár wrote:
> > > > > > On Wednesday 10 June 2020 19:31:47 Marcel Holtmann wrote:
> > > > > > > Hi Pali,
> > > > > > >
> > > > > > > >>> This utility is very useful for determining which A2DP codecs are supported
> > > > > > > >>> by remote side. So install it to system as part of bluez package.
> > > > > > > >>> ---
> > > > > > > >>> Makefile.tools | 4 ++--
> > > > > > > >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > > >>>
> > > > > > > >>> diff --git a/Makefile.tools b/Makefile.tools
> > > > > > > >>> index 9b9236609..d52721612 100644
> > > > > > > >>> --- a/Makefile.tools
> > > > > > > >>> +++ b/Makefile.tools
> > > > > > > >>> @@ -176,9 +176,9 @@ endif
> > > > > > > >>> if TOOLS
> > > > > > > >>> bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \
> > > > > > > >>>                       tools/bluemoon tools/hex2hcd tools/mpris-proxy \
> > > > > > > >>> -                     tools/btattach
> > > > > > > >>> +                     tools/btattach tools/avinfo
> > > > > > > >>>
> > > > > > > >>> -noinst_PROGRAMS += tools/bdaddr tools/avinfo tools/avtest \
> > > > > > > >>> +noinst_PROGRAMS += tools/bdaddr tools/avtest \
> > > > > > > >>>                       tools/scotest tools/amptest tools/hwdb \
> > > > > > > >>>                       tools/hcieventmask tools/hcisecfilter \
> > > > > > > >>>                       tools/btinfo tools/btconfig \
> > > > > > > >>
> > > > > > > >> I had no intention to install that tool since it is too limited
> > > > > > > >
> > > > > > > > Sorry, but I have not seen any limitations with this tool yet. I'm using
> > > > > > > > it very often. And also other people who use it have not mentioned any
> > > > > > > > limitations or problems.
> > > > > > > >
> > > > > > > > So could you be more specific what are those limitations?
> > > > > > > >
> > > > > > > > Also it is the first thing which I'm saying people that should run and
> > > > > > > > send me output of it if something related to A2DP does not work.
> > > > > > > >
> > > > > > > > And because linux distributions do not package this utility and bluez
> > > > > > > > developers (for me for unknown reasons) decided to not install it,
> > > > > > > > result is that people have to always compile bluez from source to run
> > > > > > > > this utility if their A2DP audio does not work or "remote" debugging of
> > > > > > > > A2DP is needed.
> > > > > > > >
> > > > > > > > So result is that who want to know why A2DP audio does not work is
> > > > > > > > forced to compile & install bluez from sources and not to use from
> > > > > > > > distribution package. And this probably not the expected state.
> > > > > > > >
> > > > > > > > In any case, nobody reported to me any limitation with one exception
> > > > > > > > that it cannot decode capabilities of some custom vendor codecs. But
> > > > > > > > most of them are already supported as I sent needed patches in past.
> > > > > > > >
> > > > > > > >> and makes too many assumption.
> > > > > > > >
> > > > > > > > For example which assumptions?
> > > > > > >
> > > > > > > that nothing else is happening right now. It backstabs the actual AVDTP and A2DP implementation.
> > > > > >
> > > > > > Marcel, but this is not a problem. For that one purpose which avinfo
> > > > > > provides it ideal and works fine. Personally I do not see any problem
> > > > > > with it.
> > > > > >
> > > > > > > >> In addition it has a bad name with no Bluetooth prefix.
> > > > > > > >
> > > > > > > > So, lets rename it. What about "btavinfo"?
> > > > > > >
> > > > > > > Lets extend btinfo with all sort of capabilities. Make the av portion just one of. I want to remove the multitudes of test utilities anyway. We have to many tiny utilities that are just scattered around and avinfo is just one of them.
> > > > > >
> > > > > > This looks like a not-so-trivial task and moreover independent of
> > > > > > providing current version of avinfo to users.
> > > > > >
> > > > > > avinfo already exists, is already part of bluez project, it is already
> > > > > > compiling during bluez build and is already used by me and lot of other
> > > > > > users and works for that one purpose as expected.
> > > > > >
> > > > > > > >
> > > > > > > >> If we think it is useful to have such a test utility, then we need to clean this up first
> > > > > > > >
> > > > > > > > What exactly to clean up first?
> > > > > > > >
> > > > > > > > Note that I have already done cleanup of this utility.
> > > > > > > >
> > > > > > > >> and put this into a larger btinfo work to gather appropriate information from a remote device for debug purposes.
> > > > > > > >
> > > > > > > > I do not see how btinfo can be used for A2DP purposes. Seems this is
> > > > > > > > utility for local controller info and not for remove A2DP.
> > > > > > >
> > > > > > > This needs a bit thinking, but pretty much simple things like this:
> > > > > > >
> > > > > > >   btinfo local
> > > > > > >   btinfo avdtp <remote_bdaddr>
> > > > > > >
> > > > > > > We can create a module handling system so that you can easily links existing tiny utilities into one.
> > > > > >
> > > > > > I'm not against this change. But this is additional work which needs to
> > > > > > be done. And it would not happen today or tomorrow unless you have
> > > > > > already patches which implement it.
> > > > > >
> > > > > > As I said avinfo is already there, implemented, it is working and is
> > > > > > part of bluez source code. And is basically the first step when
> > > > > > debugging issues with A2DP audio.
> > > > > >
> > > > > > So what is the real issue with not only compiling this avinfo tool
> > > > > > during building bluez but also installing it?
> > > > >
> > > > > Because nobody presented any real issue for more then month and I'm not
> > > > > aware of any, could be avinfo finally enabled during installation?
> > > >
> > > > PING, two months passed and I have not received any new reply to this patch.
> > > >
> > > > If there are really no problems, could it be applied?
> > >
> > > For the record I do intend to enable listing available endpoints in
> > > bluetooth-player, which might actually get merged into bluetoothctl as
> > > a new menu,
> >
> > Will it provide everything which is avinfo provides?
> 
> Regarding endpoints yes, it is the endpoint information that has been
> exposed via D-Bus objects.

Ok, please let me know know it is merged and I will try it.

> > > recently there have been some vulnerabilities reported
> > > against these kind of tools that are meant to only be used for testing
> > > purposes
> >
> > Could you be more specific what is that vulnerability, so we can fix it?
> 
> It is not related to avinfo, it was gatttool if you are curious about
> it, but most if not all our tools do tend to leak memory when they are
> exiting which would trigger some analyzer, etc, to have pointless
> reports about those leaks.

Ok, but this does not look like security issue. Just false positive
report of memory leak. Nothing highly critical.

> > It is the only issue? If yes, I'm going to fix it once I receive
> > details about it.
> >
> > > so I would only be in favor of installing them with we add
> > > some new build option i.e. --enable-testing and document that these
> > > tools are meant for testing only (and shall probably be package
> > > separately) so we avoid these pointless reports for tools that are not
> > > really meant to be used in production.
> >
> > As I said, avinfo is required tool for debugging A2DP audio transfers in
> > case there are problems and probably it is the only tool useful for such
> > purpose.
> >
> > Lot of users are reporting that "audio does not work" and the only way
> > to debug is, is to ask users to provide full output of avinfo.
> 
> Well if the issue is at the negotiation it avinfo is not the useful,
> btmon traces are what I usually recommend having as you can figure out
> what issues are 99% of the time.

In more cases it is needed to know what codecs and which their
configuration is supported. And dumping this is hard from btmon as it
produce tons of output (not related to this) and in some cases it does
not provide this information (e.g. when during handshake is not
enumerated all codecs).

So btmon is not replacement for avinfo. It is tool for diagnostic other
issues, e.g. those related to handshake / negotiation. So both are
required.

> > Well, it can be classified as "testing tool", but highly required in
> > case audio does not work.
> 
> It is not a qualifiable implementation that is for sure, so
> classifying it as a testing tool is the best we can do.

Ok, I have no problem to say it is "for testing" or "for debugging".
Distribution maintainers can decide where to put that package and how to
install it.

But important is that tool needs to be available to end users in some
form.

> > So please provide information about that vulnerability and I will fix
> > it. As being silent for two months about existing vulnerability is not
> > really good.