Bad UX when ign-transport is misconfigured

[peci1]

I've spent an hour today figuring out why my ign topic -l output is empty while gazebo is running right next to it. Today it was IGN_TRANSPORT_TOPIC_STATISTICS. Earlier, I spent a day finding a forgotten remnant of ign-citadel (gazebosim/gz-sim#294).

In both cases, ign topic -l just sits there with its empty result and tells you everything's fine. With no clue whatsoever why is that.

I see two possible ways to improve this:

1. Prepare a static stderr message that would be printed every time the output of ign topic -l is empty.
2. Implement some clever fallback/autodetection that would automatically try different installed versions of ign-transport, different values of IGN_TRANSPORT_TOPIC_STATISTICS and whatever is added in the future. If it succeeds with some of these fallback settings, it should tell the user exactly what are his/her options to fixing that.

This is just about ign topic -l (and also ign service -l). Maybe there are other CLI tools that would make use of such improvement. But from my experience, when things go haywire, ign topic -l is among the first things I try to diagnose the problem.

[malcolmst]

Spent a couple hours with gdb tonight figuring out the IGN_TRANSPORT_TOPIC_STATISTICS issue, wish I saw your post earlier 😃 . At a minimum, it would be nice to have some error indicating there is a version mismatch rather than silently dropping the mismatching discovery packets with no indication of error.

[malcolmst]

Had one thought on this: maybe the existing IGN_VERBOSE environment variable could be used to enable more detailed debug information such as a version mismatch (e.g. by setting IGN_VERBOSE=2).

[peci1]

Another unexpected case:

1. run simulator with IGN_IP=127.0.0.1
2. call a service from the same computer via ign service without configuring IGN_IP
3. the service isn't called, probably because the CLI chooses a non-localhost IP as the source IP for the call

[caguero]

Another unexpected case:

1. run simulator with IGN_IP=127.0.0.1
2. call a service from the same computer via ign service without configuring IGN_IP
3. the service isn't called, probably because the CLI chooses a non-localhost IP as the source IP for the call

Hmm, that works for me with the example/requester and example/responser from the examples/ directory.

[peci1]

Another unexpected case:

1. run simulator with IGN_IP=127.0.0.1
2. call a service from the same computer via ign service without configuring IGN_IP
3. the service isn't called, probably because the CLI chooses a non-localhost IP as the source IP for the call

Hmm, that works for me with the example/requester and example/responser from the examples/ directory.

I tried that with https://github.com/osrf/subt/wiki/Breadcrumbs-and-communication-visualization-tutorial . If I run competition.ign with IGN_IP=127.0.0.1, then the service call as written on the wiki page doesn't work.

[caguero]

I tried that with https://github.com/osrf/subt/wiki/Breadcrumbs-and-communication-visualization-tutorial . If I run competition.ign with IGN_IP=127.0.0.1, then the service call as written on the wiki page doesn't work.

Just checking, did you set IGN_TRANSPORT_TOPIC_STATISTICS in the terminal where you're running ign service?

[peci1]

Yes, in both. Just prepending IGN_IP=127.0.0.1 before the ign service call fixes the issue.

[caguero]

I can't reproduce it with the basic responser/requester example. Maybe there's something else in the mix.

[peci1]

Okay, the breadcrumb visualization service has the HOST advertise option set. If you add it to the basic responser/requester example, it behaves exactly as I describe.

[peci1]

It seems to me this check:

https://github.com/ignitionrobotics/ign-transport/blob/133dcf0379e1d6231e30dc6cb0bf1692fe13c4f1/include/ignition/transport/Discovery.hh#L1053-L1054

needs to be more like _fromIP in this->hostAddresses for it to work. Am I right? Should I report it as a new issue?

[caguero]

It seems to me this check:

https://github.com/ignitionrobotics/ign-transport/blob/133dcf0379e1d6231e30dc6cb0bf1692fe13c4f1/include/ignition/transport/Discovery.hh#L1053-L1054

needs to be more like _fromIP in this->hostAddresses for it to work. Am I right? Should I report it as a new issue?

You are, I'll take a look at it soon. No need to create a new issue, I got it. Thanks!

[caguero]

@peci1 , could you give it a shot? #245

[peci1]

Fixed by #245 and released in 9.1.1 .