11 Replies Latest reply on Jun 2, 2014 3:55 AM by mhahn

    BlueZ 5 on Intel Galileo?

    BillyCW

      Has anyone gotten BlueZ 5.xx to work on the Galileo board?

       

      I've recently tried to compile and install BlueZ 5.17 using the following configuration:

      --prefix=/usr \

      --sysconfdir=/etc \

      --localstatedir=/var \

      --mandir=/usr/share/man \

      --disable-cups \

      --with-udevdir=/usr/lib \

      --enable-library \

      --with-systemdsystemunitdir=/lib/system/system \

      --with-systemduserunitdir=/usr/lib/systemd/user

       

      Seems like all the tools including hciconfig, hcitools, hciattach, sdptool, rfcomm, and the Bluetooth client (bluetoothclt) were installed. I can also perform sampling pairing using rfcomm but the Bluetooth daemon (bluetoothd) and OBEX daemon (obexd) are missing.

       

      Anyone else manage to get BlueZ 5 working? I'm interested in using BlueZ 5 since there are some obex tools which can facilitate FTP data transfer over Bluetooth. I've tried to do this with BlueZ 4.101 but haven't had any luck so far.

        • 1. Re: BlueZ 5 on Intel Galileo?
          LarsR

          What do you mean by "daemons missing"?

           

          Are their binaries missing or are they not starting because there's no init.d scripts for them?

           

          I couldn't help noting your systemd options .. are you sure you want that for a Galileo build?

          I'd have to look again, but aren't we using the older SystemV init-scripts?

          • 2. Re: BlueZ 5 on Intel Galileo?
            BillyCW

            Hi Lars,

             

            What I mean by the 'daemons missing' is that the binaries are missing completely. In other words, when I go to /usr/bin/, I can see bluetoothclt, hcitool, etc... but no obexd and no bluetoothd.

             

            Regarding the use of systemd options, I've tried to install BlueZ 5 with and without systemd options. Neither seems to make a difference. I'm not sure about SystemV vs systemd, I'm not super familiar with linux so I really can't comment on that.

            • 3. Re: BlueZ 5 on Intel Galileo?
              LarsR

              Ok. Did they even get built then? I.e. are they inside your build tree somewhere?

               

              Found http://www.linuxfromscratch.org/blfs/view/svn/general/bluez.html. Perhaps this can be of some use.

               

              You don't mention your build environment. There are experimental recipes for Yocto if you want to try that.

               

              Looking at Google, there seems to be at least some other people with your problem.

              Is BlueZ 5 even in a production ready state?

               

              You gotta forgive me if I'm making no sense; I'm not using BlueZ at all, but one place I'd go to look

              would be in some of the autotools logs to see if the missing daemons are even mentioned in there.

              • 4. Re: BlueZ 5 on Intel Galileo?
                BillyCW

                Hi Lars,

                 

                I built BlueZ 5.17 on my Intel Galileo board running a 0.7.5-2 dev build (more information here: https://communities.intel.com/thread/48360?start=15&tstart=0).

                 

                Thanks for suggesting the Linux from scratch link. That's actually how I got started which was a few days before the latest 5.18 version was posted.

                 

                Regarding whether or not the daemons were built to begin with, I went back to my build directory (./bluez-5.17/src/) and noticed that the bluetoothd was built. Correspondingly, obexd was also built in (./bluez-5.17/obexd/src). So perhaps it was not copied over during the make install process.

                • 5. Re: BlueZ 5 on Intel Galileo?
                  BillyCW

                  Also, with regards to your comment on the production readiness of BlueZ 5, it seems like it is still in the early stages of making it fully production ready. That being said, the reason I'm interested in getting BlueZ 5 to work is that it looks like it comes with some useful OBEX tools for testing out the FTP file transfer capability. I haven't managed to install any other BlueZ 4 compatible tools that has allowed me to do this but would love to be proven wrong if such tools exists.

                   

                  I've tried to install ussp-push, obexftp, and a few others but so far haven't managed to get them installed properly and working. That being said, I know my tool chain does work since I've managed to build many other libraries, including BlueZ 4 successfully on the Galileo board.

                  • 6. Re: BlueZ 5 on Intel Galileo?
                    BillyCW

                    Just on some further probing, it appears that:

                    • my bluetoothd and obexd were copied to /usr/libexec/Bluetooth/
                    • /etc/dbus-1/system.d/bluetooth.conf makes references to <allow send_interface=...> for org.bluez.* for a bunch of different items but makes no reference to obex

                     

                    My bluetooth.conf file contains the following:

                     

                    <!-- This configuration file specifies the required security policies
                      for Bluetooth core daemon to work. -->
                    <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
                     "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
                    <busconfig>
                      <!-- ../system.conf have denied everything, so we just punch some holes -->
                      <policy user="root">
                      <allow own="org.bluez"/>
                      <allow send_destination="org.bluez"/>
                      <allow send_interface="org.bluez.Agent1"/>
                      <allow send_interface="org.bluez.MediaEndpoint1"/>
                      <allow send_interface="org.bluez.MediaPlayer1"/>
                      <allow send_interface="org.bluez.ThermometerWatcher1"/>
                      <allow send_interface="org.bluez.AlertAgent1"/>
                      <allow send_interface="org.bluez.Profile1"/>
                      <allow send_interface="org.bluez.HeartRateWatcher1"/>
                      <allow send_interface="org.bluez.CyclingSpeedWatcher1"/>
                      <allow send_interface="org.freedesktop.DBus.ObjectManager"/>
                      </policy>
                      <policy at_console="true">
                      <allow send_destination="org.bluez"/>
                      </policy>
                      <!-- allow users of lp group (printing subsystem) to
                      communicate with bluetoothd -->
                      <policy group="lp">
                      <allow send_destination="org.bluez"/>
                      </policy>
                      <policy context="default">
                      <deny send_destination="org.bluez"/>
                      </policy>
                    </busconfig>
                    
                    

                     

                     

                    Another point of concern that I have is that my /usr/share/dbus-1/system-services/org.bluez.service contains the following:

                     

                    [D-BUS Service]
                    Name=org.bluez
                    Exec=/bin/false
                    SystemdService=dbus-org.bluez.service
                    
                    

                     

                    Note the Exec=/bin/false part.

                     

                    Similar thing appears in my /usr/share/dbus-1/services/org.bluez.obex.service file:

                     

                    [D-BUS Service]
                    Name=org.bluez.obex
                    Exec=/bin/false
                    SystemdService=dbus-org.bluez.obex.service
                    

                     

                    Note again the Exec=/bin/false part

                     

                    Message was edited by: Billy Chan

                    • 7. Re: BlueZ 5 on Intel Galileo?
                      LarsR

                      Perhaps you could try to re-run ./configure with --disable-systemd and see if it produces an init.d script for you instead.

                      I'm pretty sure thats why the daemon doesn't start on a Galileo.

                       

                      Also, just for kicks, can the bluetoothd binary in libexec be started? Perhaps in another terminal session?

                      I don't know for sure, but most daemons have a "don't fork" switch so you can see if it spits out some logs.

                       

                      Sounds to me like you're almost there.

                      As a last resort, perhaps the init.d script from BlueZ 4 can be adapted to start the version 5 daemon.

                      1 of 1 people found this helpful
                      • 8. Re: BlueZ 5 on Intel Galileo?
                        BillyCW

                        Hi LarsR,

                         

                        Prior to my current install, I did try an install of BlueZ 5 with --disable-systemd. It was because I couldn't get it to work that I decided to enable system.

                         

                        Thanks for the suggestion on the calling the bluetoothd in libexec. I'll give that a shot.

                        • 9. Re: BlueZ 5 on Intel Galileo?
                          AlexanderMerz

                          Newer versions of BlueZ support systemd only. According to the maintainer of BlueZ, distributions still using sysinit-style have to provide their own code to bring back the sysinit support.

                           

                          The configure switch -disable-systemd does only stop BlueZ 5 to install the daemon as Systemd-daemon, but nothing else.

                           

                          On a 0.7.5 Galileo-Yocto-full this means: If you compile BlueZ 5, the old BlueZ binaries remain untouched, the new binaries are in the libexec dir and never called by the "old" sysinit script. If you did a BlueZ 5 "make install"  only, your system will still use the old BlueZ stuff.

                           

                          I tried to get this stuff working, but - finally - ended just with starting the Bluez5 daemon manually (and manually starting dbus for unknown reasons) every time.

                           

                          But other problems with Bluez5 will show up: BlueZ 5 is a API breaking version. There is a good chance other tools will fail. There is a good chance you will fail due to dbus policy things. Not a single python&co library for BlueZ will work.

                           

                          TL;DR: You will waste a lot of time with BlueZ. BlueZ 5 will make it even worse.

                          1 of 1 people found this helpful
                          • 10. Re: BlueZ 5 on Intel Galileo?
                            BillyCW

                            Thanks for the insight Alexander,

                             

                            Prior to installing BlueZ 5, I did try to uninstall BlueZ 4 using opkg. I would assume that would completely remove all the leftover stuff from the original BlueZ4 package but I could be wrong.

                             

                            In any case, you're right in that BlueZ5 will break all existing tools. For me, it's more of a last ditch attempt at testing the OBEX FTP transfer on Galileo.

                             

                            That being said, has anyone managed to get OBEX FTP transfers working with BlueZ4?

                            • 11. Re: BlueZ 5 on Intel Galileo?
                              mhahn

                              you might be interested in devkit-daisy-multilibc branch of meta-intel-iot-devkit - Intel IoT Developer Kit metadata which comes with BlueZ 5