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: Serial communication over BT using the DBus API

[Sylvain Leroux]

On 10/09/2018 11:09 PM, Barry Byford wrote:
>> I'm currently investigating how I could use `busctl` to reproduce that
>> behavior.
> 
> Not my area of expertise but it seems like it might be difficult
> because there would be no event loop.

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'
----

I'm not 100% confident with the syntax. I also tried using
`bluetoothctl` for that, but I'm even less confident with the syntax:

----
bluetoothctl << EOF
register-profile 'osa{sv}' /bluez "00001101-0000-1000-8000-00805f9b34fb"
3 'Role' s server 'Channel' u 1 Name s 'SerialPort'
EOF
----


Nevertheless, as you suggested, each of these solutions seems doomed
since, according to the documentation:


(from https://github.com/pauloborges/bluez/blob/master/doc/profile-api.txt)
> If an application disconnects from the bus all
> its registered profiles will be removed.


If I understand it well, that means even if I was able to register a new
profile, it will be removed as soon as `busctl` or `bluetoothctl`
terminate. Or did I misunderstand the whole thing?

Re: Serial communication over BT using the DBus API

[Barry Byford]

On Tue, 9 Oct 2018 at 21:56, Sylvain Leroux <sylvain@chicoree.fr> wrote:
>
> Hi Barry,
>
> Thanks for the reply:
>
> On 10/09/2018 10:30 PM, Barry Byford wrote:
> > You might want to take a look at the Bluedot library that has used the
> > DBus API to communicate over the Serial Port Profile.
> > Server:
> > https://github.com/martinohanlon/BlueDot/blob/master/bluedot/btcomm.py#L141
> > Client:
> > https://github.com/martinohanlon/BlueDot/blob/master/bluedot/btcomm.py#L466
> >
> > The main section using DBus is in:
> > https://github.com/martinohanlon/BlueDot/blob/master/bluedot/utils.py
>
> I started to explore the bluedot sources. From what I understand, I need
> in the shell something like the `register_spp` function
> (https://github.com/martinohanlon/BlueDot/blob/master/bluedot/utils.py#L101)
>
>
> I'm currently investigating how I could use `busctl` to reproduce that
> behavior.

Not my area of expertise but it seems like it might be difficult
because there would be no event loop.
Hopefully someone else can jump in on that point.

>
> I noticed the function mostly send some XML description to the
> `org.bluez.ProfileManager1` interface (see code below).

The author has decided to do it that way. You don't have to. Here is a
different example:
https://gist.github.com/ukBaz/217875c83c2535d22a16ba38fc8f2a91#file-spp-profile

> There are a
> couple of hard coded constants in the code, including the UUID
> "00001101-0000-1000-8000-00805f9b34fb". Are those "well known" values I
> can blindly use?

That UUID refers to the Serial Port Profile. You can see the full list
of assigned numbers at:
https://www.bluetooth.com/specifications/assigned-numbers/service-discovery


>
>
> - Sylvain
>
>
> ----
> def register_spp(port):
>
>     service_record = """
>     <?xml version="1.0" encoding="UTF-8" ?>
>     <record>
>       <attribute id="0x0001">
>         <sequence>
>           <uuid value="0x1101"/>
>         </sequence>
>       </attribute>
>       <attribute id="0x0004">
>         <sequence>
>           <sequence>
>             <uuid value="0x0100"/>
>           </sequence>
>           <sequence>
>             <uuid value="0x0003"/>
>             <uint8 value="{}" name="channel"/>
>           </sequence>
>         </sequence>
>       </attribute>
>       <attribute id="0x0100">
>         <text value="Serial Port" name="name"/>
>       </attribute>
>     </record>
>     """.format(port)
>
>     bus = dbus.SystemBus()
>
>     manager = dbus.Interface(bus.get_object(SERVICE_NAME, "/org/bluez"),
> PROFILE_MANAGER)
>
>     path = "/bluez"
>     uuid = "00001101-0000-1000-8000-00805f9b34fb"
>     opts = {
> #        "AutoConnect" : True,
>         "ServiceRecord" : service_record
>     }
>
>     try:
>         manager.RegisterProfile(path, uuid, opts)
>     except dbus.exceptions.DBusException as e:
>         #the spp profile has already been registered, ignore
>         if str(e) != "org.bluez.Error.AlreadyExists: Already Exists":
>             raise(e)
> ----

Re: Serial communication over BT using the DBus API

[Sylvain Leroux]

Hi Barry,

Thanks for the reply:

On 10/09/2018 10:30 PM, Barry Byford wrote:
> You might want to take a look at the Bluedot library that has used the
> DBus API to communicate over the Serial Port Profile.
> Server:
> https://github.com/martinohanlon/BlueDot/blob/master/bluedot/btcomm.py#L141
> Client:
> https://github.com/martinohanlon/BlueDot/blob/master/bluedot/btcomm.py#L466
> 
> The main section using DBus is in:
> https://github.com/martinohanlon/BlueDot/blob/master/bluedot/utils.py

I started to explore the bluedot sources. From what I understand, I need
in the shell something like the `register_spp` function
(https://github.com/martinohanlon/BlueDot/blob/master/bluedot/utils.py#L101)


I'm currently investigating how I could use `busctl` to reproduce that
behavior.

I noticed the function mostly send some XML description to the
`org.bluez.ProfileManager1` interface (see code below). There are a
couple of hard coded constants in the code, including the UUID
"00001101-0000-1000-8000-00805f9b34fb". Are those "well known" values I
can blindly use?


- Sylvain


----
def register_spp(port):

    service_record = """
    <?xml version="1.0" encoding="UTF-8" ?>
    <record>
      <attribute id="0x0001">
        <sequence>
          <uuid value="0x1101"/>
        </sequence>
      </attribute>
      <attribute id="0x0004">
        <sequence>
          <sequence>
            <uuid value="0x0100"/>
          </sequence>
          <sequence>
            <uuid value="0x0003"/>
            <uint8 value="{}" name="channel"/>
          </sequence>
        </sequence>
      </attribute>
      <attribute id="0x0100">
        <text value="Serial Port" name="name"/>
      </attribute>
    </record>
    """.format(port)

    bus = dbus.SystemBus()

    manager = dbus.Interface(bus.get_object(SERVICE_NAME, "/org/bluez"),
PROFILE_MANAGER)

    path = "/bluez"
    uuid = "00001101-0000-1000-8000-00805f9b34fb"
    opts = {
#        "AutoConnect" : True,
        "ServiceRecord" : service_record
    }

    try:
        manager.RegisterProfile(path, uuid, opts)
    except dbus.exceptions.DBusException as e:
        #the spp profile has already been registered, ignore
        if str(e) != "org.bluez.Error.AlreadyExists: Already Exists":
            raise(e)
----

Re: Serial communication over BT using the DBus API

[Barry Byford]

Hello Sylvain,

On Tue, 9 Oct 2018 at 20:50, Sylvain Leroux <sylvain@chicoree.fr> wrote:
>
> Hi everyone,
>
> I'm trying to establish a serial communication between two hosts over
> Bluetooth.
>
> Things go well if I start the `bluetoothd` on the server in
> _compatibility mode_. That way, I can attach the "serial port" profile
> to the channel. Then, using `rfcomm watch` and `rfcomm connect` to
> establish the connection between the server and the client, I can
> receive "raw" data sent by the server:
>
> ----
> # Server side
> /usr/lib/bluetooth/bluetoothd -C
> sdptool add --channel=1 SP
> rfcomm watch hci0 1 bash -c 'cat somefile > /dev/rfcomm0'
> ----
>
> ----
> #Client side
> sudo rfcomm connect /dev/rfcomm0 BB:CC:DD:EE:FF:11 1
> sudo cat /dev/rfcomm0
> -----
>
> If I do _not_ run the `bluetoothd` server in compatibility mode, SDP is
> no longer supported and the data I receive seems to modified by the BT
> stack, leading to my data being mixed with garbage--exactly like when I
> don't set the "serial port" profile while running in compatibility mode.
>
>
> I don't like the idea of depending on a deprecated interface. And from
> what I read, I understand the new way to go is to use the DBus API.  Any
> solution using bluetoothctl, busctl, dbus-send or similar tools would do
> the trick. But I can't manage to understand the sequence of operations
> required to transmit raw data between the server and the client *from a
> shell script* using that new API.
>
> Could you give me some example or point me to the relevant documentation?

You might want to take a look at the Bluedot library that has used the
DBus API to communicate over the Serial Port Profile.
Server:
https://github.com/martinohanlon/BlueDot/blob/master/bluedot/btcomm.py#L141
Client:
https://github.com/martinohanlon/BlueDot/blob/master/bluedot/btcomm.py#L466

The main section using DBus is in:
https://github.com/martinohanlon/BlueDot/blob/master/bluedot/utils.py


Hope that helps.

>
> Regards,
> - Sylvain Leroux

Serial communication over BT using the DBus API

[Sylvain Leroux]

Hi everyone,

I'm trying to establish a serial communication between two hosts over
Bluetooth.

Things go well if I start the `bluetoothd` on the server in
_compatibility mode_. That way, I can attach the "serial port" profile
to the channel. Then, using `rfcomm watch` and `rfcomm connect` to
establish the connection between the server and the client, I can
receive "raw" data sent by the server:

----
# Server side
/usr/lib/bluetooth/bluetoothd -C
sdptool add --channel=1 SP
rfcomm watch hci0 1 bash -c 'cat somefile > /dev/rfcomm0'
----

----
#Client side
sudo rfcomm connect /dev/rfcomm0 BB:CC:DD:EE:FF:11 1
sudo cat /dev/rfcomm0
-----

If I do _not_ run the `bluetoothd` server in compatibility mode, SDP is
no longer supported and the data I receive seems to modified by the BT
stack, leading to my data being mixed with garbage--exactly like when I
don't set the "serial port" profile while running in compatibility mode.


I don't like the idea of depending on a deprecated interface. And from
what I read, I understand the new way to go is to use the DBus API.  Any
solution using bluetoothctl, busctl, dbus-send or similar tools would do
the trick. But I can't manage to understand the sequence of operations
required to transmit raw data between the server and the client *from a
shell script* using that new API.

Could you give me some example or point me to the relevant documentation?

Regards,
- Sylvain Leroux