Serial communication over BT using the DBus API

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

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

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]

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]

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?

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