nmos-cpp icon indicating copy to clipboard operation
nmos-cpp copied to clipboard

Errors on Raspberry Pi

Open jwpwh opened this issue 5 years ago • 11 comments

I am trying to use the registry on a Raspberry Pi and having an issue.

First, some notes I made while following the Raspberry Pi instructions:

  • Under the Boost Libraries, the ./b2 command is missing a backslash at the end of the --prefix line
  • When trying to build the C++ Rest SDK, it complained about not being able to find websockets and said I should run git submodule update --init Then it was fine.
  • Under Avahi, it complained about intltool and said I should run sudo apt-get install intltool.
  • Under Avahi, I needed to add a PKG_CONFIG_PATH=${RPI_LIBS}/lib/pkgconfig to the ./configure line so it could find the dbus-1 information.
  • On the Raspberry Pi itself, a message came out saying the following needed to be done sudo apt-get update sudo apt-get install libnss-mdns

The cross-compile build was done in a VirtualBox using a ubuntu image from osboxes.org

When running the registry on the Raspberry Pi, the output is as shown in the attached file.

There is an error -65537 when trying to register an advertisement. This error seems to be a generic "Unknown" error so it doesn't seem real useful.

The avahi-daemon seems to be running.

Any lucky guesses as to what might be wrong?

Thanks.

ps.txt

reg.txt

jwpwh avatar Sep 18 '19 22:09 jwpwh

Thank you for your information.

I think the problem may be because nmos-cpp-registry is linking with the wrong libdns_sd.so (provided by libnss-mdns?). nmos-cpp-registry is needed to be linked with the one we cross-compiled in the Avavhi build step, with avahi-compat-libdns_sd set.

  1. Can you do ldd nmos-cpp-registry to verify which libdns_sd.so is trying to use?
  2. Are you running the cross-compiled Avahi daemon?

libnss-mdns - nss-mdns is a plugin for the GNU Name Service Switch (NSS) functionality of the GNU C Library (glibc) providing host name resolution via Multicast DNS (using Zeroconf, aka Apple Bonjour / Apple Rendezvous ), effectively allowing name resolution by common Unix/Linux programs in the ad-hoc mDNS domain .local.

lo-simon avatar Sep 19 '19 09:09 lo-simon

I ran ldd before but did not include the output. It looks like all the libraries are coming from the right place. See attached file.

I was not running the cross-compiled Avahi daemon. The Raspberry Pi came with avahi and that daemon was running (with the same avahi-daemon.conf as produced on the cross-compile side). I killed that daemon, copied the cross-compiled daemon over and ran it with

sudo ./sbin/avahi-daemon -D -f /etc/avahi/avahi-daemon.conf

This produced the same results as before with regards to the Unknown error when trying to register something.

If it is important to run the cross-compiled avahi-daemon, the instructions should probably include the steps for copying and installing the daemon and any needed config files.

I am considering modifying the code so that instead of mapping to an Unknown error it prints a message as to what the actual error is and maybe that will provide some insight.

jwpwh avatar Sep 19 '19 14:09 jwpwh

Forgot the file.

ldd.txt

jwpwh avatar Sep 19 '19 14:09 jwpwh

If it is important to run the cross-compiled avahi-daemon, the instructions should probably include the steps for copying and installing the daemon and any needed config files.

I think Simon suggested the cross-compiled daemon in case the daemon might need to be the same version as the 'compat' library that probably isn't already installed.

I am considering modifying the code so that instead of mapping to an Unknown error it prints a message as to what the actual error is and maybe that will provide some insight.

I suppose a kDNSServiceErr_Unknown (-65537) is coming from either our https://github.com/sony/nmos-cpp/blob/master/Development/mdns/dns_sd_impl.cpp or Avahi's https://github.com/lathiat/avahi/blob/master/avahi-compat-libdns_sd/compat.c

garethsb avatar Sep 19 '19 14:09 garethsb

I changed the avahi-compat-libdns_sd/dns_sd.h to include some more error codes:

    kDNSServiceErr_NoNetwork           = -65560, 
    kDNSServiceErr_OS                  = -65561, 
    kDNSServiceErr_InvalidConfig       = -65562, 
    kDNSServiceErr_Timeout             = -65563, 
    kDNSServiceErr_DbusError           = -65564, 
    kDNSServiceErr_Disconnected        = -65565, 
    kDNSServiceErr_NoDaemon            = -65566
and then changed the map_error() routine to include these in compat.c rather than mapping all of them to Unknown.

        case AVAHI_ERR_NO_NETWORK:
            return kDNSServiceErr_NoNetwork;

        case AVAHI_ERR_OS:
            return kDNSServiceErr_OS;

        case AVAHI_ERR_INVALID_CONFIG:
            return kDNSServiceErr_InvalidConfig;

        case AVAHI_ERR_TIMEOUT:
            return kDNSServiceErr_Timeout;

        case AVAHI_ERR_DBUS_ERROR:
            return kDNSServiceErr_DbusError;

        case AVAHI_ERR_DISCONNECTED:
            return kDNSServiceErr_Disconnected;

        case AVAHI_ERR_NO_DAEMON:
            return kDNSServiceErr_NoDaemon;

    }

    return kDNSServiceErr_Unknown;

Now the error reported is the kDNSServiceErr_NoDaemon error (-65566).

The output of ps seems to indicate that the daemon is running:

avahi     1279     1  0 09:53 ?        00:00:13 avahi-daemon: running [raspberrypi.local]
pi        1601   888  0 11:22 pts/0    00:00:00 grep --color=auto avahi

Is there something to look for in the avahi configuration files or permissions that would lead the registry to think there isn't a daemon running?

jwpwh avatar Sep 19 '19 15:09 jwpwh

I'll check this in another environment tomorrow, but I wonder if it needs the DBUS daemon running also.

garethsb avatar Sep 19 '19 19:09 garethsb

My current theory is that the linux vm I am using as the host for the cross-compile does not have dbus-1 installed and this is causing the issues. As I noted before, I needed to add a PKG_CONFIG_PATH option to the configure for avahi in order to find the dbus build options. This is also a result of not having dbus-1 on the build machine. The libdbus-1.so has a reference to a path name on the build machine for the system_bus_socket. I am looking into options to change this.

Will let you know how it goes.

The DBUS daemon is running on the raspberry pi.

jwpwh avatar Sep 19 '19 19:09 jwpwh

FWIW - In the containers I build I have to have dbus running as a daemon for avahi to function.

Rich.

Sent from my iPhone. Please accept my apologies for any typo's.

rhastie avatar Sep 19 '19 19:09 rhastie

Success!!

When building D-Bus add one additional argument to the ./configure:

./configure --host=arm-linux-gnueabihf --prefix=${RPI_LIBS} \
  CPPFLAGS=-I${RPI_LIBS}/include \
  LDFLAGS=-L${RPI_LIBS}/lib \
  EXPAT_CFLAGS=" " \
  EXPAT_LIBS=-lexpat \
--with-system-socket=/var/run/dbus/system_bus_socket

When building Avahi, add 2 additional arguments:

./configure --host=arm-linux-gnueabihf --prefix=${RPI_LIBS} \
   CPPFLAGS=-I${RPI_LIBS}/include \
   LDFLAGS=-L${RPI_LIBS}/lib \
   --with-distro=none \
   --disable-glib --disable-gobject --disable-gdbm \
   --disable-qt3 --disable-qt4 \
   --disable-gtk --disable-gtk3 \
   --disable-mono --disable-monodoc --disable-python \
   --enable-compat-libdns_sd \
   --with-systemdsystemunitdir=no \
   LIBDAEMON_CFLAGS=" " \
   LIBDAEMON_LIBS=-ldaemon \
   PKG_CONFIG_PATH=${RPI_LIBS}/lib/pkgconfig \
   --with-dbus-system-address="unix:path=/var/run/dbus/system_bus_socket"

When run with these options, even though dbus was not running on the build system, the cross-compiles build and seem to work ok.

Apparently the above options are not needed if dbus is installed on the build system but the additional arguments should make the cross-compile process less dependent on what is installed on the build system.

jwpwh avatar Sep 19 '19 20:09 jwpwh

For what it is worth: The version of Dbus installed on the Raspberry Pi is 1.12.16 and the instructions here grab the source for 1.12.8. I think the main part we are interested in is the dns_sd library and it looks like that source has not changed in quite a while so there probably is not any real difference between the two versions.

jwpwh avatar Sep 19 '19 20:09 jwpwh

Good investigation, thanks for the update, glad it's working! We'll confirm and update the build instructions.

garethsb avatar Sep 20 '19 06:09 garethsb