Install avinfo utility
Subsystems (2)
PATCH 1/1 Install avinfo utility
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(-)
Makefile.tools +2 -2
@@ -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 \
Signature · 1 line
2.20.1
Quoted 5 lines · 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?
Quoted 19 lines
Makefile.tools +2
-2@@ -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 \Signature · 1 line
2.20.1
Marcel Holtmann
maintainerHi Pali,
Quoted 19 lines
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(-)Makefile.tools +0
-0@@ -176,9 +176,9 @@ endifif TOOLS
bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \ tools/bluemoon tools/hex2hcd tools/mpris-proxy \Makefile.tools +2
-2- tools/btattach + tools/btattach tools/avinfo -noinst_PROGRAMS += tools/bdaddr tools/avinfo tools/avtest \ +noinst_PROGRAMS += tools/bdaddr tools/avtest \
Quoted 3 lines
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
Quoted 19 lines · On Wednesday 10 June 2020 10:27:25 Marcel Holtmann wrote:
Hi Pali,
Quoted 17 lines
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(-)Makefile.tools +0
-0@@ -176,9 +176,9 @@ endifif TOOLS
bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \ tools/bluemoon tools/hex2hcd tools/mpris-proxy \Makefile.tools +1
-1- tools/btattach + tools/btattach tools/avinfo
Quoted 7 lines
Quoted 5 lines
Makefile.tools +1
-1-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.
Quoted 1 line
and makes too many assumption.
For example which assumptions?
Quoted 1 line
In addition it has a bad name with no Bluetooth prefix.
So, lets rename it. What about "btavinfo"?
Quoted 1 line
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.
Quoted 1 line
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.
Marcel Holtmann
maintainerHi Pali,
Quoted 44 lines
Quoted 17 lines
Quoted 17 lines
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(-)Makefile.tools +0
-0@@ -176,9 +176,9 @@ endifif TOOLS
bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \ tools/bluemoon tools/hex2hcd tools/mpris-proxy \Makefile.tools +1
-1- tools/btattach + tools/btattach tools/avinfoQuoted 7 lines
Quoted 5 lines
Makefile.tools +1
-1-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.
Quoted 7 lines
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.
Quoted 1 line
and makes too many assumption.
For example which assumptions?
that nothing else is happening right now. It backstabs the actual AVDTP and A2DP implementation.
Quoted 3 lines
Quoted 1 line
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.
Quoted 11 lines
Quoted 2 lines
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.
Quoted 1 line
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
Quoted 50 lines · On Wednesday 10 June 2020 19:31:47 Marcel Holtmann wrote:
Hi Pali,
Quoted 48 lines
Quoted 17 lines
Quoted 17 lines
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(-)Makefile.tools +0
-0@@ -176,9 +176,9 @@ endifif TOOLS
bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \ tools/bluemoon tools/hex2hcd tools/mpris-proxy \Makefile.tools +1
-1- tools/btattach + tools/btattach tools/avinfoQuoted 7 lines
Quoted 5 lines
Makefile.tools +1
-1-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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 12 lines
Quoted 11 lines
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 6 lines
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?
Quoted 97 lines · On Thursday 11 June 2020 14:53:04 Pali Rohár wrote:
Quoted 50 lines · On Wednesday 10 June 2020 19:31:47 Marcel Holtmann wrote:
Hi Pali,
Quoted 48 lines
Quoted 17 lines
Quoted 17 lines
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(-)Makefile.tools +0
-0@@ -176,9 +176,9 @@ endifif TOOLS
bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \ tools/bluemoon tools/hex2hcd tools/mpris-proxy \Makefile.tools +1
-1- tools/btattach + tools/btattach tools/avinfoQuoted 7 lines
Quoted 5 lines
Makefile.tools +1
-1-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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 12 lines
Quoted 11 lines
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 6 lines
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.
Quoted 6 lines
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?
Quoted 102 lines · On Monday 13 July 2020 11:09:13 Pali Rohár wrote:
Quoted 101 lines · On Thursday 11 June 2020 14:53:04 Pali Rohár wrote:
Quoted 50 lines · On Wednesday 10 June 2020 19:31:47 Marcel Holtmann wrote:
Hi Pali,
Quoted 48 lines
Quoted 17 lines
Quoted 17 lines
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(-)Makefile.tools +0
-0@@ -176,9 +176,9 @@ endifif TOOLS
bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \ tools/bluemoon tools/hex2hcd tools/mpris-proxy \Makefile.tools +1
-1- tools/btattach + tools/btattach tools/avinfoQuoted 7 lines
Quoted 5 lines
Makefile.tools +1
-1-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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 12 lines
Quoted 11 lines
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 6 lines
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.
Quoted 5 lines
Quoted 2 lines
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?
Luiz Augusto von Dentz
maintainerHi Pali,
Quoted 107 lines · Pali Rohár
Quoted 105 lines · On Monday 13 July 2020 11:09:13 Pali Rohár wrote:
Quoted 103 lines · On Thursday 11 June 2020 14:53:04 Pali Rohár wrote:
Quoted 50 lines · On Wednesday 10 June 2020 19:31:47 Marcel Holtmann wrote:
Hi Pali,
Quoted 48 lines
Quoted 17 lines
Quoted 17 lines
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(-)Makefile.tools +0
-0@@ -176,9 +176,9 @@ endifif TOOLS
bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \ tools/bluemoon tools/hex2hcd tools/mpris-proxy \Makefile.tools +1
-1- tools/btattach + tools/btattach tools/avinfoQuoted 7 lines
Makefile.tools
Quoted 5 lines
Makefile.tools +1
-1-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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 12 lines
Quoted 11 lines
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 6 lines
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?
Quoted 6 lines
Quoted 2 lines
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.
Signature · 1 line
Luiz Augusto von Dentz
Quoted 113 lines · On Saturday 08 August 2020 22:33:48 Luiz Augusto von Dentz wrote:
Hi Pali,
Quoted 110 lines · Pali Rohár
Quoted 107 lines · On Monday 13 July 2020 11:09:13 Pali Rohár wrote:
Quoted 97 lines · On Thursday 11 June 2020 14:53:04 Pali Rohár wrote:
Quoted 50 lines · On Wednesday 10 June 2020 19:31:47 Marcel Holtmann wrote:
Hi Pali,
Quoted 48 lines
Quoted 17 lines
Quoted 17 lines
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(-)Makefile.tools +0
-0@@ -176,9 +176,9 @@ endifif TOOLS
bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \ tools/bluemoon tools/hex2hcd tools/mpris-proxy \Makefile.tools +1
-1- tools/btattach + tools/btattach tools/avinfoQuoted 7 lines
Makefile.tools
Quoted 5 lines
Makefile.tools +1
-1-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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 12 lines
Quoted 11 lines
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 6 lines
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.
Quoted 6 lines
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?
Quoted 7 lines
Quoted 3 lines
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?
Quoted 3 lines
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.
Quoted 5 lines
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.
Luiz Augusto von Dentz
maintainerHi Pali,
Quoted 117 lines · Pali Rohár
Quoted 115 lines · On Saturday 08 August 2020 22:33:48 Luiz Augusto von Dentz wrote:
Hi Pali,
Quoted 112 lines · Pali Rohár
Quoted 102 lines · On Monday 13 July 2020 11:09:13 Pali Rohár wrote:
Quoted 101 lines · On Thursday 11 June 2020 14:53:04 Pali Rohár wrote:
Quoted 50 lines · On Wednesday 10 June 2020 19:31:47 Marcel Holtmann wrote:
Hi Pali,
Quoted 48 lines
Quoted 17 lines
Quoted 17 lines
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(-)Makefile.tools +0
-0@@ -176,9 +176,9 @@ endifif TOOLS
bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \ tools/bluemoon tools/hex2hcd tools/mpris-proxy \Makefile.tools +1
-1- tools/btattach + tools/btattach tools/avinfoQuoted 7 lines
Makefile.tools
Quoted 5 lines
Makefile.tools +1
-1-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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 12 lines
Quoted 11 lines
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 6 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 3 lines
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.
Quoted 9 lines
It is the only issue? If yes, I'm going to fix it once I receive details about it.
Quoted 5 lines
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.
Quoted 6 lines
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.
Quoted 2 lines
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.
Quoted 3 lines
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.
Signature · 1 line
Luiz Augusto von Dentz
Quoted 122 lines · On Sunday 09 August 2020 11:22:53 Luiz Augusto von Dentz wrote:
Hi Pali,
Quoted 119 lines · Pali Rohár
Quoted 117 lines · On Saturday 08 August 2020 22:33:48 Luiz Augusto von Dentz wrote:
Hi Pali,
Quoted 113 lines · Pali Rohár
Quoted 102 lines · On Monday 13 July 2020 11:09:13 Pali Rohár wrote:
Quoted 101 lines · On Thursday 11 June 2020 14:53:04 Pali Rohár wrote:
Quoted 50 lines · On Wednesday 10 June 2020 19:31:47 Marcel Holtmann wrote:
Hi Pali,
Quoted 48 lines
Quoted 17 lines
Quoted 17 lines
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(-)Makefile.tools +0
-0@@ -176,9 +176,9 @@ endifif TOOLS
bin_PROGRAMS += tools/rctest tools/l2test tools/l2ping tools/bccmd \ tools/bluemoon tools/hex2hcd tools/mpris-proxy \Makefile.tools +1
-1- tools/btattach + tools/btattach tools/avinfoQuoted 7 lines
Makefile.tools
Quoted 5 lines
Makefile.tools +1
-1-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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 12 lines
Quoted 11 lines
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 6 lines
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.
Quoted 5 lines
Quoted 2 lines
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?
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
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.
Quoted 10 lines
Quoted 5 lines
Quoted 3 lines
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.
Quoted 13 lines
Quoted 13 lines
It is the only issue? If yes, I'm going to fix it once I receive details about it.
Quoted 5 lines
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 3 lines
Quoted 3 lines
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.