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
Perhaps I am totally in the wrong here as I started out with Zenoh a couple of days ago, but I have encountered the following inconsistency. I setup one ROS 2 node that publishes and one that subscribes. The first node publishes two topics, /topic and /topic_denied, and the second subscribes to them. The first is on ROS_DOMAIN_ID=1 and the second on ROS_DOMAIN_ID=2.
If any of these topics is in the allow or deny list of the publisher in its zenoh .json5 configuration file (mutually exclusively) then their messages appear on the subscriber, contrary to what is intended.
If any of the topics is in the allow or deny list of the subscriber, then they do/do not appear on the subscriber, exactly as intended.
To reproduce
Follow the instructions of this repo. Both .json5 files do not allow or deny anything at this state. Denying or allowing topics /topic or /topic_denied on the publisher results in no difference.
In the sample output of the terminal where the publisher's Zenoh bridge runs you can see that topic topic_denied does end up in the deny list:
[2024-02-14T14:09:38Z INFO zenoh_bridge_ros2dds] zenoh-bridge-ros2dds v0.11.0-dev-26-gfdf9a1a built with rustc 1.72.1 (d5c2e9c34 2023-09-13) (built from a source tarball)
[2024-02-14T14:09:38Z INFO zenoh::net::runtime] Using PID: e0458ce77601d0a72358779565ae335
[2024-02-14T14:09:38Z INFO zenoh::net::runtime::orchestrator] Zenoh can be reached at: tcp/127.0.0.1:7448
[2024-02-14T14:09:38Z INFO zenoh::net::runtime::orchestrator] zenohd listening scout messages on 224.0.0.224:7446
[2024-02-14T14:09:38Z WARN zenoh::net::runtime::orchestrator] Unable to connect to any locator of scouted peer e95b712d1b1db65a48c6d36e3bcad460: [tcp/127.0.0.1:7447]
[2024-02-14T14:09:38Z INFO zenoh_plugin_ros2dds] ROS2 plugin Config { id: Some("id_publisher"), namespace: "/", nodename: "zenoh_bridge_ros2dds_id_publisher", domain: 2, ros_localhost_only: false, allowance: Some(Deny(ROS2InterfacesRegex { publishers: Some(Regex("^/topic_denied$")), subscribers: None, service_servers: None, service_clients: None, action_servers: None, action_clients: None })), pub_max_frequencies: [], transient_local_cache_multiplier: 10, queries_timeout: None, reliable_routes_blocking: true, pub_priorities: [], __required__: None, __path__: None }
[2024-02-14T14:09:38Z INFO zenoh_plugin_ros2dds] New ROS 2 bridge detected: id_subscriber
BTW I can see that there is a warning in the output, but is it relevant to this issue? It does not seem to obstruct message delivery.
Describe the bug
Perhaps I am totally in the wrong here as I started out with Zenoh a couple of days ago, but I have encountered the following inconsistency. I setup one ROS 2 node that publishes and one that subscribes. The first node publishes two topics,
/topic
and/topic_denied
, and the second subscribes to them. The first is onROS_DOMAIN_ID=1
and the second onROS_DOMAIN_ID=2
.If any of these topics is in the allow or deny list of the publisher in its zenoh
.json5
configuration file (mutually exclusively) then their messages appear on the subscriber, contrary to what is intended.If any of the topics is in the allow or deny list of the subscriber, then they do/do not appear on the subscriber, exactly as intended.
To reproduce
Follow the instructions of this repo. Both
.json5
files do not allow or deny anything at this state. Denying or allowing topics/topic
or/topic_denied
on the publisher results in no difference.In the sample output of the terminal where the publisher's Zenoh bridge runs you can see that topic
topic_denied
does end up in the deny list:BTW I can see that there is a warning in the output, but is it relevant to this issue? It does not seem to obstruct message delivery.
System info
Platform: Ubuntu 22.04, 64 bit
zenoh-plugin-ros2dds commit fdf9a1a
The text was updated successfully, but these errors were encountered: