We need to investigate whether or not this affects multicast discovery or just the data packets. Ideally we'd want multicast discovery to have nonzero TTL but the data packets to have TTL zero for multicast and TTL nonzero for unicast.

In general, this needs to be tested a bit more to make sure this behaves as expected with respect to wireless network behavior and to obtain feedback from eProsima.

Let's try to change the locator list from rmw_fastrtps_cpp to just knock out the multicast locators for data. This is just a workaround until a future version of fastrtps which will be more judicious about when to multicast.

This comment is relevant:

By default a subscriber uses a multicast address and a unicast address. Right now writer writes samples to both addresses. Next release will be more clever and if it is possible only write to one. I configured the subscriber not to use the default addresses, and only use a multicast address. Then the writer will write samples only to that address.
-- #36 (comment)

I'll try to adapt the logic he provided there to do the opposite and disable multicast all together in favor of just unicast until we can better control it in a new pr.

That sounds great. Since unicast is the default behavior of ROS 1, I think that will be the expectation of users (for data, at least) unless there is a clear win that multicasting is better: for example, if >1 subscribers on the same subnet.

Holding until after Beta 1

Since the current version of Fast-RTPS has multicast disabled by default, I'll close this for now. We can do a better fix in the future when Fast-RTPS can automatically select between unicast and multicast.