You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Been chasing a couple startup issues with Fast-RTPS based programs, and found one that seems a bug in Fast-RTPS.
The offending line is in src/cpp/utils/IPFinder.cpp ...
if (ifa->ifa_addr == NULL || (ifa->ifa_flags & IFF_RUNNING) == 0)
The issue is that the code should use IFF_UP, instead of IFF_RUNNING. Basically, IFF_RUNNING contains a number of other checks including whether or network cables are plugged in. See This Discussion on Stack Overflow for some more details.
In our system, the interface is up and has an address assigned, but that flag flicks off for a brief moment, around the time that the Fast-RTPS applications start. Fast-RTPS doesn't see the flag, skips that locator, and discovery with other CPU's does not take place.
So, we've changed that line to this in our copy of the library, and seems much more stable.
if (ifa->ifa_addr == NULL || (ifa->ifa_flags & IFF_UP) == 0)
The text was updated successfully, but these errors were encountered:
Fast DDS 2.5.1 includes the dynamic network interfaces feature which currently has limited support (UDPv4 without whitelisting). Fast DDS 2.6.0 will include complete support for TCP and UDP transports. Consequently, even if the network interface is not found while Fast DDS is initialized, you can use this feature to trigger a rescan of the network interfaces by Fast DDS. I hope this is helpful with your use case.
Been chasing a couple startup issues with Fast-RTPS based programs, and found one that seems a bug in Fast-RTPS.
The offending line is in src/cpp/utils/IPFinder.cpp ...
The issue is that the code should use IFF_UP, instead of IFF_RUNNING. Basically, IFF_RUNNING contains a number of other checks including whether or network cables are plugged in. See This Discussion on Stack Overflow for some more details.
In our system, the interface is up and has an address assigned, but that flag flicks off for a brief moment, around the time that the Fast-RTPS applications start. Fast-RTPS doesn't see the flag, skips that locator, and discovery with other CPU's does not take place.
So, we've changed that line to this in our copy of the library, and seems much more stable.
The text was updated successfully, but these errors were encountered: