| Message ID | 20200506193435.3746-1-pali@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Install avinfo utility | expand |
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 >
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
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.
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
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?
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?
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?
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.
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.
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.
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.
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 \