nmos-cpp
nmos-cpp copied to clipboard
Errors on Raspberry Pi
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.
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.
- Can you do
ldd nmos-cpp-registry
to verify which libdns_sd.so is trying to use? - 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.
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.
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
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?
I'll check this in another environment tomorrow, but I wonder if it needs the DBUS daemon running also.
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.
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.
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.
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.
Good investigation, thanks for the update, glad it's working! We'll confirm and update the build instructions.