Problem with StopDiscovery() via dbus-send

Problem with StopDiscovery() via dbus-send

[Проклов Александр Валерьевич]

  Hello All,

Thanks for your work. Since version bluez-5.50 start-stop discovery work 
from command line and scripts:
#bluetoothctl scan on
#bluetoothctl scan off
(see mail-list "Problem with StopDiscovery() via dbus-send")

--------------------------------------------

My next task is to do pair with device from bash script. I tried several 
ways:
1. #bluetoothctl pair 11:22:33:44:55:66 does not work because the agent 
is not created.
2. Make  agent via Dbus:
#dbus-send --system --print-reply --type=method_call --dest=org.bluez 
/org/bluez org.bluez.AgentManager1.RegisterAgent 
objpath:/org/bluez/agent1 string:KeyboardOnly
the command works, but I do not see in Dbus /org/bluez/agent1 created.
3. Make agent via bluetoothctl:
[bluetooth]#agent on
the command works, but I do not see in Dbus agent path!.

May be possible to set a default pin code via /etc/bluetooth/main.conf
if it is available, do not make a request for a pin from the command 
line? I think that then #bluetoothctl pair 11:22:33:44:55:66 will be 
able to work fine.

---------------------
Best regards,
Aleksandr Proklov

Re: Problem with StopDiscovery() via dbus-send

[Luiz Augusto von Dentz]

Hi,

On Fri, Aug 24, 2018 at 4:58 AM, =D0=9F=D1=80=D0=BE=D0=BA=D0=BB=D0=BE=D0=B2=
 =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 =D0=92=D0=B0=D0=BB=
=D0=B5=D1=80=D1=8C=D0=B5=D0=B2=D0=B8=D1=87
<ProklovAV@mail.zabtrans.ru> wrote:
>  Hello All,
>
> Thanks for your work. Since version bluez-5.50 start-stop discovery work
> from command line and scripts:
> #bluetoothctl scan on
> #bluetoothctl scan off
> (see mail-list "Problem with StopDiscovery() via dbus-send")
>
> --------------------------------------------
>
> My next task is to do pair with device from bash script. I tried several
> ways:
> 1. #bluetoothctl pair 11:22:33:44:55:66 does not work because the agent i=
s
> not created.
> 2. Make  agent via Dbus:
> #dbus-send --system --print-reply --type=3Dmethod_call --dest=3Dorg.bluez
> /org/bluez org.bluez.AgentManager1.RegisterAgent objpath:/org/bluez/agent=
1
> string:KeyboardOnly
> the command works, but I do not see in Dbus /org/bluez/agent1 created.
> 3. Make agent via bluetoothctl:
> [bluetooth]#agent on
> the command works, but I do not see in Dbus agent path!.

Im not sure Im following, you would like to have non-interactive mode
working for bluetoothctl pair? The point number 2 don't make much
sense since dbus-send normally disconnected after the reply that means
the agent would be gone, also regarding 3 if you use a more recent
version of bluetootctl it registers and agent automatically nowadays.

> May be possible to set a default pin code via /etc/bluetooth/main.conf
> if it is available, do not make a request for a pin from the command line=
? I
> think that then #bluetoothctl pair 11:22:33:44:55:66 will be able to work
> fine.

That is something I had in mind, lets see if I can come up with something.

> ---------------------
> Best regards,
> Aleksandr Proklov



--=20
Luiz Augusto von Dentz

Re: Problem with StopDiscovery() via dbus-send

[Luiz Augusto von Dentz]

Hi,

On Fri, Aug 24, 2018 at 11:19 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Fri, Aug 24, 2018 at 4:58 AM, =D0=9F=D1=80=D0=BE=D0=BA=D0=BB=D0=BE=D0=
=B2 =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 =D0=92=D0=B0=D0=
=BB=D0=B5=D1=80=D1=8C=D0=B5=D0=B2=D0=B8=D1=87
> <ProklovAV@mail.zabtrans.ru> wrote:
>>  Hello All,
>>
>> Thanks for your work. Since version bluez-5.50 start-stop discovery work
>> from command line and scripts:
>> #bluetoothctl scan on
>> #bluetoothctl scan off
>> (see mail-list "Problem with StopDiscovery() via dbus-send")
>>
>> --------------------------------------------
>>
>> My next task is to do pair with device from bash script. I tried several
>> ways:
>> 1. #bluetoothctl pair 11:22:33:44:55:66 does not work because the agent =
is
>> not created.
>> 2. Make  agent via Dbus:
>> #dbus-send --system --print-reply --type=3Dmethod_call --dest=3Dorg.blue=
z
>> /org/bluez org.bluez.AgentManager1.RegisterAgent objpath:/org/bluez/agen=
t1
>> string:KeyboardOnly
>> the command works, but I do not see in Dbus /org/bluez/agent1 created.
>> 3. Make agent via bluetoothctl:
>> [bluetooth]#agent on
>> the command works, but I do not see in Dbus agent path!.
>
> Im not sure Im following, you would like to have non-interactive mode
> working for bluetoothctl pair? The point number 2 don't make much
> sense since dbus-send normally disconnected after the reply that means
> the agent would be gone, also regarding 3 if you use a more recent
> version of bluetootctl it registers and agent automatically nowadays.
>
>> May be possible to set a default pin code via /etc/bluetooth/main.conf
>> if it is available, do not make a request for a pin from the command lin=
e? I
>> think that then #bluetoothctl pair 11:22:33:44:55:66 will be able to wor=
k
>> fine.
>
> That is something I had in mind, lets see if I can come up with something=
.

Actually it doesn't seems to be possible with the current IO
capabilities even if I set KeyboardOnly the phone end up displaying
the passcode on its end, so it seems there is no combination where the
acceptor would be asked to enter a passkey and the initiator to enter
it. I wonder if that is on purpose though, because right now the only
options in case of headless solution would be to use just works and
switch Adapter.Pairable on demand.

--=20
Luiz Augusto von Dentz

Re: Problem with StopDiscovery() via dbus-send

[Проклов Александр Валерьевич]

24.08.2018 16:19, Luiz Augusto von Dentz пишет:

>> May be possible to set a default pin code via /etc/bluetooth/main.conf
>> if it is available, do not make a request for a pin from the command line? I
>> think that then #bluetoothctl pair 11:22:33:44:55:66 will be able to work
>> fine.
>
> That is something I had in mind, lets see if I can come up with something.
>

Yes. Non-interactive mode needed.
But I think in bluez 3 was main.conf parameter to specify the default 
PIN code.

Re: Problem with StopDiscovery() via dbus-send

[Luiz Augusto von Dentz]

Hi,

On Mon, Aug 27, 2018 at 2:58 AM, =D0=9F=D1=80=D0=BE=D0=BA=D0=BB=D0=BE=D0=B2=
 =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 =D0=92=D0=B0=D0=BB=
=D0=B5=D1=80=D1=8C=D0=B5=D0=B2=D0=B8=D1=87
<ProklovAV@mail.zabtrans.ru> wrote:
> 24.08.2018 16:19, Luiz Augusto von Dentz =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
>
>>> May be possible to set a default pin code via /etc/bluetooth/main.conf
>>> if it is available, do not make a request for a pin from the command
>>> line? I
>>> think that then #bluetoothctl pair 11:22:33:44:55:66 will be able to wo=
rk
>>> fine.
>>
>>
>> That is something I had in mind, lets see if I can come up with somethin=
g.
>>
>
> Yes. Non-interactive mode needed.
> But I think in bluez 3 was main.conf parameter to specify the default PIN
> code.

Afaik that only works for legacy pairing, normally devices without any
input/output should rely on just works pairing which is what you would
usually see in headset, etc, though that are not always pairable so
you have to switch it on with a button or something like it.

--=20
Luiz Augusto von Dentz

Re: Problem with StopDiscovery() via dbus-send

[Проклов Александр Валерьевич]

27.08.2018 15:24, Luiz Augusto von Dentz пишет:
> Afaik that only works for legacy pairing, normally devices without any
> input/output should rely on just works pairing which is what you would
> usually see in headset, etc, though that are not always pairable so
> you have to switch it on with a button or something like it.

Now my pair process with non-android phone:
#bluetoothctl
[bluetooth] pair 11:22:33:44:55:66

I intering pin code in command shell: 1234
Phone shows a window for entering the code.
I intering pin code on phone. Device pair.

Step with the input of the code in the terminal can be skipped if the 
code is given in main.conf

the reverse process, when the code transmits the phone to the computer, 
I have not considered so far. I think this through the script will be 
difficult to implement.

Re: Problem with StopDiscovery() via dbus-send

[Проклов Александр Валерьевич]

24.08.2018 16:19, Luiz Augusto von Dentz пишет:

>> May be possible to set a default pin code via /etc/bluetooth/main.conf
>> if it is available, do not make a request for a pin from the command line? I
>> think that then #bluetoothctl pair 11:22:33:44:55:66 will be able to work
>> fine.
>
> That is something I had in mind, lets see if I can come up with something.
>


Can be implemented such an option:
#bluetoothctl pair 11:22:33:44:55:66 [pin_code] --timeout 15

bluetoothctl register agent and send pin_code to device.
--timeout time for user response, enter pin_code on device.


NOW I use pair my Aftershokz Trekz headphones without request pin_code 
via Dbus command from script:
#dbus-send --system --type=method_call --dest=org.bluez 
/org/bluez/55:55:55:55:55:55/dev_11:22:33:44:55:66 org.bluez.Device1.Pair


-----------
Best regards,
Aleksandr Proklov

Non intheractive request pin-code

[Проклов Александр Валерьевич]

Dear developers, this proposal can be implemented?



24.08.2018 16:19, Luiz Augusto von Dentz пишет:

>> May be possible to set a default pin code via /etc/bluetooth/main.conf
>> if it is available, do not make a request for a pin from the command line? I
>> think that then #bluetoothctl pair 11:22:33:44:55:66 will be able to work
>> fine.
>
> That is something I had in mind, lets see if I can come up with something.
>

Yes. Non-interactive mode needed.
But I think in bluez 3 was main.conf parameter to specify the default 
PIN code.

Re: Serial communication over BT using the DBus API

[Проклов Александр Валерьевич]

Hi Sylvain Leroux,

Some time ago I also asked this question here.
I think no one knows how to do it without rfcomm util.

I use dbus-send for read dbus properties and now work non-interactive 
mode bluetoothctl.



> I tried something like that:
>
>
> ----
> busctl call \
>     org.bluez /org/bluez org.bluez.ProfileManager1 RegisterProfile \
>     'osa{sv}' \
>     /bluez \
>     "00001101-0000-1000-8000-00805f9b34fb" \
>     3 'Role' s server 'Channel' u 1 Name s 'SerialPort'
> ----


-----------
Best regards,
Aleksandr Proklov

Re: Problem with StopDiscovery() via dbus-send

[Проклов Александр Валерьевич]

>>> 15.09.2017 16:46, Luiz Augusto von Dentz пишет:
>>>>
>>>> Ive just a set of patches adressing race condition with StartDiscovery
>>>> and StopDiscovery, please have a try. Also it is not a good idea to
>>>> mix usage of D-Bus with btmgmt, they might not play well together
>>>> especially when it comes to discovery.
>>>>
>>>
>
> May be add time delay after the StarDiscovery (for example 60 sec) and bluetoothd automatically turn off the Discovery process?  I do not know when it would be required to start the process for a time longer than 60 seconds.
>
> This will help solve the problem with the call StartDiscovery through the script via dbus-send. My method through power off, power on not help me, after power off founded adapters deleted from dbus tree.
>
> My script is finished at 80%. It remains only to make the Discovery and network connection via bluetooth (GN, PANU, PAN).


Dear Luiz Augusto von Dentz, please consider the possibility of 
implementing this option.

Re: Problem with StopDiscovery() via dbus-send

[Проклов Александр Валерьевич]

>
>> 15.09.2017 16:46, Luiz Augusto von Dentz пишет:
>>>
>>> Ive just a set of patches adressing race condition with StartDiscovery
>>> and StopDiscovery, please have a try. Also it is not a good idea to
>>> mix usage of D-Bus with btmgmt, they might not play well together
>>> especially when it comes to discovery.
>>>
>>

May be add time delay after the StarDiscovery (for example 60 sec) and 
bluetoothd automatically turn off the Discovery process?  I do not know 
when it would be required to start the process for a time longer than 60 
seconds.

This will help solve the problem with the call StartDiscovery through 
the script via dbus-send. My method through power off, power on not help 
me, after power off founded adapters deleted from dbus tree.

My script is finished at 80%. It remains only to make the Discovery and 
network connection via bluetooth (GN, PANU, PAN).

Re: Problem with StopDiscovery() via dbus-send

[Проклов Александр Валерьевич]

18.09.2017 14:53, Luiz Augusto von Dentz пишет:
> Hi,
>
> On Mon, Sep 18, 2017 at 5:50 AM, Проклов Александр Валерьевич
> <ProklovAV@mail.zabtrans.ru> wrote:
>> 15.09.2017 16:46, Luiz Augusto von Dentz пишет:
>>>
>>> Ive just a set of patches adressing race condition with StartDiscovery
>>> and StopDiscovery, please have a try. Also it is not a good idea to
>>> mix usage of D-Bus with btmgmt, they might not play well together
>>> especially when it comes to discovery.
>>>
>>
>> Thank you, I add "patch v2 adapter: Refactor code around discovery" to
>> source bluez-5.47 and compile it.
>>
>> My test results:
>>
>> 1. btmgmt after "find" command NOT set org.bluez.Adapter1 string:Discovering
>> =1 . But the Discovery process is already running, why he does not do it?
>> btmgmt not use dbus for managment?
>
> btmgmt uses the kernel management interface not D-Bus, this is why I
> said it may not play well with bluetoothd.
>
>> 2. If i send method StartDiscovery via dbus-send command, i see
>> org.bluez.Adapter1 string:Discovering =1 status. But I can not stop the
>> process, method StopDiscovery - has no effect.
>
> The StopDiscovery can only stop discovery started by the client, if
> you use btmgmt to start then it can only be stopped by btmgmt.


No i not use btmgmt, I would like to stop the process through Dbus.
My btmgmt example only for show process.


>
>> "btmgmt stop-find" - has no effect, in therminal i see:
>> hci0 type 7 discovering off
>> hci0 type 7 discovering on
>> hci0 type 7 discovering off
>> hci0 type 7 discovering on
>> hci0 type 7 discovering off
>> hci0 type 7 discovering on
>>
>> after btmgmt power off and btmgmt power on
>> org.bluez.Adapter1 string:Discovering =0
>>
>> I assume that the method StopDiscovery must completely terminate the process
>> StartDiscovery, regardless of the way the scan was started (btmgmt,
>> dbus-send, hcitool, bluetoothctl or more other).
>
> Only if StartDiscovery was initiated by the same D-Bus
> connection/process, and in case you are wondering there is proper
> support for discovery in bluetoothctl which does use D-Bus to control
> the discovery.
>

Use Dbus from script is difficult, but now, it is not possible to use.


>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>

Re: Problem with StopDiscovery() via dbus-send

[Luiz Augusto von Dentz]

Hi,

On Mon, Sep 18, 2017 at 5:50 AM, =D0=9F=D1=80=D0=BE=D0=BA=D0=BB=D0=BE=D0=B2=
 =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 =D0=92=D0=B0=D0=BB=
=D0=B5=D1=80=D1=8C=D0=B5=D0=B2=D0=B8=D1=87
<ProklovAV@mail.zabtrans.ru> wrote:
> 15.09.2017 16:46, Luiz Augusto von Dentz =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
>>
>> Ive just a set of patches adressing race condition with StartDiscovery
>> and StopDiscovery, please have a try. Also it is not a good idea to
>> mix usage of D-Bus with btmgmt, they might not play well together
>> especially when it comes to discovery.
>>
>
> Thank you, I add "patch v2 adapter: Refactor code around discovery" to
> source bluez-5.47 and compile it.
>
> My test results:
>
> 1. btmgmt after "find" command NOT set org.bluez.Adapter1 string:Discover=
ing
> =3D1 . But the Discovery process is already running, why he does not do i=
t?
> btmgmt not use dbus for managment?

btmgmt uses the kernel management interface not D-Bus, this is why I
said it may not play well with bluetoothd.

> 2. If i send method StartDiscovery via dbus-send command, i see
> org.bluez.Adapter1 string:Discovering =3D1 status. But I can not stop the
> process, method StopDiscovery - has no effect.

The StopDiscovery can only stop discovery started by the client, if
you use btmgmt to start then it can only be stopped by btmgmt.

> "btmgmt stop-find" - has no effect, in therminal i see:
> hci0 type 7 discovering off
> hci0 type 7 discovering on
> hci0 type 7 discovering off
> hci0 type 7 discovering on
> hci0 type 7 discovering off
> hci0 type 7 discovering on
>
> after btmgmt power off and btmgmt power on
> org.bluez.Adapter1 string:Discovering =3D0
>
> I assume that the method StopDiscovery must completely terminate the proc=
ess
> StartDiscovery, regardless of the way the scan was started (btmgmt,
> dbus-send, hcitool, bluetoothctl or more other).

Only if StartDiscovery was initiated by the same D-Bus
connection/process, and in case you are wondering there is proper
support for discovery in bluetoothctl which does use D-Bus to control
the discovery.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth=
"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



--=20
Luiz Augusto von Dentz

Re: Problem with StopDiscovery() via dbus-send

[Проклов Александр Валерьевич]

15.09.2017 16:46, Luiz Augusto von Dentz пишет:
> Ive just a set of patches adressing race condition with StartDiscovery
> and StopDiscovery, please have a try. Also it is not a good idea to
> mix usage of D-Bus with btmgmt, they might not play well together
> especially when it comes to discovery.
>

Thank you, I add "patch v2 adapter: Refactor code around discovery" to 
source bluez-5.47 and compile it.

My test results:

1. btmgmt after "find" command NOT set org.bluez.Adapter1 
string:Discovering =1 . But the Discovery process is already running, 
why he does not do it? btmgmt not use dbus for managment?

2. If i send method StartDiscovery via dbus-send command, i see 
org.bluez.Adapter1 string:Discovering =1 status. But I can not stop the 
process, method StopDiscovery - has no effect.
"btmgmt stop-find" - has no effect, in therminal i see:
hci0 type 7 discovering off
hci0 type 7 discovering on
hci0 type 7 discovering off
hci0 type 7 discovering on
hci0 type 7 discovering off
hci0 type 7 discovering on

after btmgmt power off and btmgmt power on
org.bluez.Adapter1 string:Discovering =0

I assume that the method StopDiscovery must completely terminate the 
process StartDiscovery, regardless of the way the scan was started 
(btmgmt, dbus-send, hcitool, bluetoothctl or more other).

Re: Problem with StopDiscovery() via dbus-send

[Luiz Augusto von Dentz]

Hi Aleksandr,

On Fri, Sep 15, 2017 at 11:35 AM, =D0=9F=D1=80=D0=BE=D0=BA=D0=BB=D0=BE=D0=
=B2 =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 =D0=92=D0=B0=D0=
=BB=D0=B5=D1=80=D1=8C=D0=B5=D0=B2=D0=B8=D1=87
<ProklovAV@mail.zabtrans.ru> wrote:
> 15.09.2017 14:27, Luiz Augusto von Dentz =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
>>
>> Hi Aleksandr,
>>
>> On Fri, Sep 15, 2017 at 6:25 AM, =D0=9F=D1=80=D0=BE=D0=BA=D0=BB=D0=BE=D0=
=B2 =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 =D0=92=D0=B0=D0=
=BB=D0=B5=D1=80=D1=8C=D0=B5=D0=B2=D0=B8=D1=87
>> <ProklovAV@mail.zabtrans.ru> wrote:
>>>
>>>   Hello All,
>>>
>>> Maybe it's a bug?
>>>
>>> I'm trying to manage Bluetooth using dbus-send command,
>>> I send command for start discovery:
>>> dbus-send --system --reply-timeout=3D5000 --type=3Dmethod_call
>>> --dest=3Dorg.bluez
>>> /org/bluez/hci0 org.bluez.Adapter1.StartDiscovery
>>
>>
>> dbus-send disconnects from the bus so the discovery is stopped because
>> there is no client to report the devices found.
>>
>
> Discovery not stopped, see my log from btmgmt. I not start discovery via
> "btmgmt find". Command "btmgmt stop-find" not help me.
>
> Now i add to code for stop discovery process:
> btmgmt power off
> sleep 2
> btmgmt power on

Ive just a set of patches adressing race condition with StartDiscovery
and StopDiscovery, please have a try. Also it is not a good idea to
mix usage of D-Bus with btmgmt, they might not play well together
especially when it comes to discovery.

>
>
>>>
>>> Discovery process NOT stop!!! in btmgmt i see:
>>> hci0 type 7 discovering off
>>> hci0 type 7 discovering on
>>> hci0 type 7 discovering off
>>> hci0 type 7 discovering on
>>> hci0 type 7 discovering off
>>> hci0 type 7 discovering on
>>>
>>> and it goes on continuously!
>>> How can I stop the search process? "StopDiscovery" not work from
>>> dbus-send
>>> command.
>>>
>>>
>>> ---------------------
>>> Best regards,
>>> Aleksandr Proklov
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-bluetooth"
>>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth=
"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



--=20
Luiz Augusto von Dentz

Re: Problem with StopDiscovery() via dbus-send

[Проклов Александр Валерьевич]

15.09.2017 14:27, Luiz Augusto von Dentz пишет:
> Hi Aleksandr,
>
> On Fri, Sep 15, 2017 at 6:25 AM, Проклов Александр Валерьевич
> <ProklovAV@mail.zabtrans.ru> wrote:
>>   Hello All,
>>
>> Maybe it's a bug?
>>
>> I'm trying to manage Bluetooth using dbus-send command,
>> I send command for start discovery:
>> dbus-send --system --reply-timeout=5000 --type=method_call --dest=org.bluez
>> /org/bluez/hci0 org.bluez.Adapter1.StartDiscovery
>
> dbus-send disconnects from the bus so the discovery is stopped because
> there is no client to report the devices found.
>

Discovery not stopped, see my log from btmgmt. I not start discovery via 
"btmgmt find". Command "btmgmt stop-find" not help me.

Now i add to code for stop discovery process:
btmgmt power off
sleep 2
btmgmt power on


>>
>> Discovery process NOT stop!!! in btmgmt i see:
>> hci0 type 7 discovering off
>> hci0 type 7 discovering on
>> hci0 type 7 discovering off
>> hci0 type 7 discovering on
>> hci0 type 7 discovering off
>> hci0 type 7 discovering on
>>
>> and it goes on continuously!
>> How can I stop the search process? "StopDiscovery" not work from dbus-send
>> command.
>>
>>
>> ---------------------
>> Best regards,
>> Aleksandr Proklov
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>

Re: Problem with StopDiscovery() via dbus-send

[Luiz Augusto von Dentz]

Hi Aleksandr,

On Fri, Sep 15, 2017 at 6:25 AM, =D0=9F=D1=80=D0=BE=D0=BA=D0=BB=D0=BE=D0=B2=
 =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 =D0=92=D0=B0=D0=BB=
=D0=B5=D1=80=D1=8C=D0=B5=D0=B2=D0=B8=D1=87
<ProklovAV@mail.zabtrans.ru> wrote:
>  Hello All,
>
> Maybe it's a bug?
>
> I'm trying to manage Bluetooth using dbus-send command,
> I send command for start discovery:
> dbus-send --system --reply-timeout=3D5000 --type=3Dmethod_call --dest=3Do=
rg.bluez
> /org/bluez/hci0 org.bluez.Adapter1.StartDiscovery

dbus-send disconnects from the bus so the discovery is stopped because
there is no client to report the devices found.

>
> Discovery process NOT stop!!! in btmgmt i see:
> hci0 type 7 discovering off
> hci0 type 7 discovering on
> hci0 type 7 discovering off
> hci0 type 7 discovering on
> hci0 type 7 discovering off
> hci0 type 7 discovering on
>
> and it goes on continuously!
> How can I stop the search process? "StopDiscovery" not work from dbus-sen=
d
> command.
>
>
> ---------------------
> Best regards,
> Aleksandr Proklov
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth=
"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



--=20
Luiz Augusto von Dentz

Problem with StopDiscovery() via dbus-send

[Проклов Александр Валерьевич]

  Hello All,

Maybe it's a bug?

I'm trying to manage Bluetooth using dbus-send command,
I send command for start discovery:
dbus-send --system --reply-timeout=5000 --type=method_call 
--dest=org.bluez /org/bluez/hci0 org.bluez.Adapter1.StartDiscovery


Discovery process NOT stop!!! in btmgmt i see:
hci0 type 7 discovering off
hci0 type 7 discovering on
hci0 type 7 discovering off
hci0 type 7 discovering on
hci0 type 7 discovering off
hci0 type 7 discovering on

and it goes on continuously!
How can I stop the search process? "StopDiscovery" not work from 
dbus-send command.


---------------------
Best regards,
Aleksandr Proklov

Re: Problem with StopDiscovery() via dbus-send

[Luiz Augusto von Dentz]

Hi,

On Thu, Jul 27, 2017 at 3:50 AM, =D0=9F=D1=80=D0=BE=D0=BA=D0=BB=D0=BE=D0=B2=
 =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 =D0=92=D0=B0=D0=BB=
=D0=B5=D1=80=D1=8C=D0=B5=D0=B2=D0=B8=D1=87
<ProklovAV@mail.zabtrans.ru> wrote:
> 26.07.2017 16:05, Luiz Augusto von Dentz wrote:
>
>> It probably has been stopped already since the connection used for
>> StartDiscovery has been terminated. Btw, there are better tools to
>> test this, for instance bluetoothctl> scan [on/off]
>>
>
> If the process "StartDiscovery" is stopped, why status "Discovering" not
> changed to "false"?

It may take some time until it has been stopped completely, but the
sessions is already released, and even if you could in fact leave it
running the next time you call dbus-sent it would create a new
connection so calling StopDiscovery will fail nevertheless.

> I need to start and stop scanning from the Bash script, bluetoothctl has =
the
> ability to manage from Bash scripts?

Currently it only runs in interactive mode, but it would have the same
result since the D-Bus connection would be lost in between runs of
bluetoothctl.

>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth=
"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



--=20
Luiz Augusto von Dentz

Re: Problem with StopDiscovery() via dbus-send

[Проклов Александр Валерьевич]

26.07.2017 16:05, Luiz Augusto von Dentz wrote:

 > It probably has been stopped already since the connection used for
 > StartDiscovery has been terminated. Btw, there are better tools to
 > test this, for instance bluetoothctl> scan [on/off]
 >

If the process "StartDiscovery" is stopped, why status "Discovering" not 
changed to "false"?

I need to start and stop scanning from the Bash script, bluetoothctl has 
the ability to manage from Bash scripts?

Re: Problem with StopDiscovery() via dbus-send

[Luiz Augusto von Dentz]

Hi Aleksandr,

On Wed, Jul 26, 2017 at 2:51 AM, =D0=9F=D1=80=D0=BE=D0=BA=D0=BB=D0=BE=D0=B2=
 =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 =D0=92=D0=B0=D0=BB=
=D0=B5=D1=80=D1=8C=D0=B5=D0=B2=D0=B8=D1=87
<ProklovAV@mail.zabtrans.ru> wrote:
>  Hello All,
>
> I'm trying to manage Bluetooth using dbus-send command,
>
> I send command for start discovery:
> dbus-send --system --reply-timeout=3D5000 --type=3Dmethod_call --dest=3Do=
rg.bluez
> /org/bluez/hci0 org.bluez.Adapter1.StartDiscovery

dbus-send exists so that would stop the discovery is there is no other
process discovering.

> I see that the scan started, the status is true:
> dbus-send --system --print-reply --dest=3Dorg.bluez --type=3Dmethod_call
> /org/bluez/hci0 org.freedesktop.DBus.Properties.Get
> string:org.bluez.Adapter1 string:Discovering
>
> But I can not stop scanning by a command:
> dbus-send --system --reply-timeout=3D5000 --type=3Dmethod_call --dest=3Do=
rg.bluez
> /org/bluez/hci0 org.bluez.Adapter1.StopDiscovery

It probably has been stopped already since the connection used for
StartDiscovery has been terminated. Btw, there are better tools to
test this, for instance bluetoothctl> scan [on/off]

> "Discovering" status true.
>
> Bluez version 5.45
>
> ---------------------
> Best regards,
> Aleksandr Proklov
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth=
"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



--=20
Luiz Augusto von Dentz

Problem with StopDiscovery() via dbus-send

[Проклов Александр Валерьевич]

  Hello All,

I'm trying to manage Bluetooth using dbus-send command,

I send command for start discovery:
dbus-send --system --reply-timeout=5000 --type=method_call 
--dest=org.bluez /org/bluez/hci0 org.bluez.Adapter1.StartDiscovery

I see that the scan started, the status is true:
dbus-send --system --print-reply --dest=org.bluez --type=method_call 
/org/bluez/hci0 org.freedesktop.DBus.Properties.Get 
string:org.bluez.Adapter1 string:Discovering

But I can not stop scanning by a command:
dbus-send --system --reply-timeout=5000 --type=method_call 
--dest=org.bluez /org/bluez/hci0 org.bluez.Adapter1.StopDiscovery

"Discovering" status true.

Bluez version 5.45

---------------------
Best regards,
Aleksandr Proklov