jmccabe
commented
4 years ago I've continued to look at this, and have found some interesting stuff using my debugger, well...
I've had a suggestion on the mailing list about adding a MulticastInterface=eht0:avahi entry into the discovery section of my rtps.ini, and also a multicast_interface=eth0:avahi into the transport section.
The latter makes no difference, and the former results in a segmentation fault. In trying to debug the segmentation fault, I think it's a side-effect of the multicast join not working, but I've been able to follow through to find that Spdp::SpdpTransport::join_multicast_group() is called 3 times. Debugging this bit of code:
void
Spdp::SpdpTransport::join_multicast_group(const DCPS::NetworkInterface& nic,
bool all_interfaces)
{
if (joined_interfaces_.count(nic.name()) != 0 || nic.addresses.empty() || !nic.can_multicast()) {
return; <<<< line 2418
}
if (!multicast_interface_.empty() && nic.name() != multicast_interface_) {
return; <<<<< line 2422
}I follow through with the following values in nic.name():
1) lo - which returns from line 2418 2) eth0 - which returns from line 2422 3) sit0 - which returns from line 2418
ifconfig doesn't show sit0 at all (see previous comment), and join_multicast_group is never passed eth0::avahi!
This bit of code is being executed in Sdpd.cpp, in the Spdp::SpdpTransport constructor:
DCPS::NetworkConfigMonitor_rch ncm = TheServiceParticipant->network_config_monitor();
if (ncm) {
const DCPS::NetworkInterfaces nics = ncm->add_listener(*this);
for (DCPS::NetworkInterfaces::const_iterator pos = nics.begin(), limit = nics.end(); pos != limit; ++pos) {
join_multicast_group(*pos);
}
} else {
which is where join_multicast_group() is being called from using the nics collection retrieved from the network_config_monitor(), so the network_config_monitor seems to think there are 3 nics, with names lo, eth0 and sit0.
Any ideas where sit0 is coming from, and why eth0:avahi isn't in there?
John
mitza-oci
jwillemsen
jrw972
(Note: I first posted this to https://sourceforge.net/p/opendds/mailman/opendds-main/?viewmonth=202006&style=flat, please delete/close if this is not the right place)
On OpenDDS 3.14, on an embedded target, I'm seeing "ERROR: Spdp::SpdpTransport::join_multicast_group() - failed to join multicast group 239.255.0.1:8400 ACE_SOCK_Dgram_Mcast::join: Unknown error -5" on an application that (other than a few updates to handle the C++11 style opendds_idl code generation) is the same as one that works with OpenDDS 3.13.3.
The target is an ARM-based embedded linux system with Avahi installed to acquire an mDNS IP address. It uses rtps with an ini file containing:
Using the OpenDDS 3.13.3 version of the code, with DCPSDebugLevel 10, I see:
With the 3.14 version, I see:
ifconfig on the embedded device shows:
As the 3.14 version is explicitly showing that it's trying to join a group using eth0 (not eth0:avahi), I've tried modifying the embedded linux device's network configuration to apply the 169.254.5.198 address as a static address on eth0 and restarting the eth0 device.
Now, when I run my 3.14 version, it works as it should do, however I have a need to use mDNS on the system I'm working on so this may not be a long term solution.
Is something known to have changed between 3.13.3 and 3.14 to have this effect and, if so, is there a configuration option (e.g. command line or rtps.ini file) I can use to overcome it?
I have tried explicitly specifying the SpdpLocalAddress in my rtps.ini, with no effect. I have also tried configuring the MulticastInterface setting in my rtps.ini to eth0:avahi, but the application just segfaults like that.