Troubleshoot ROS 2 Firewall, QoS, and Network Compatibility Issues

R2026b

This topic shows how to unblock ROS 2 node discovery by creating Windows® Firewall rules for the MATLAB® ROS 2 background process (libmwros2server.exe) and how to verify that Quality of Service (QoS) policies and custom message, service, and action definitions are compatible between MATLAB and external ROS 2 nodes.

If MATLAB is still unable to communicate with external ROS 2 nodes after you have verified network adapter modes, environment variables, and DDS middleware configuration, as described in Troubleshoot ROS 2 Discovery Issues in Virtual Environments and Troubleshoot ROS 2 Cross-Subnet Discovery Issues Using DDS Profiles, the remaining causes are typically one of the following:

  • The Windows Firewall is blocking the multicast traffic that ROS 2 uses for node discovery.

  • QoS policies or custom message definitions are mismatched between MATLAB and the external environment.

Configure Windows Firewall Rules for ROS 2

The MATLAB ROS 2 server runs as a background process (libmwros2server.exe) that handles DDS discovery and message transport. On public or restricted network profiles, Windows Defender Firewall may block this process by default, preventing node discovery even when all other configuration is correct.

Locate Background Process

Find the path to the ROS 2 server executable within your MATLAB installation. Replace <matlabroot> with your MATLAB installation folder, for example, C:\Program Files\MATLAB\R2026b.

<matlabroot>\toolbox\ros\bin\win64\libmwros2server.exe

Create Inbound and Outbound Firewall Rules

Create inbound and outbound rules in Windows Defender Firewall with Advanced Security to allow the MATLAB ROS 2 server process to send and receive traffic:

  1. Open Windows Defender Firewall with Advanced Security.

  2. Under Inbound Rules, create New Rule and apply the following settings:

    • Rule Type: Program

    • Program Path: Paste the path to libmwros2server.exe

    • Action: Allow the connection

    • Profile: Select Domain, Private, and Public

    • Name: MATLAB ROS 2 Server Inbound (for example)

  3. Under Outbound Rules, create a new rule with the same settings to allow outgoing traffic. Name it, for example, MATLAB ROS 2 Server Outbound.

After configuring the firewall rules, test communication again by repeating the publisher-subscriber diagnostic test described in the Clean Communication Environment and Verify Two-Way Communication section, or start your application to verify that MATLAB connects to ROS 2 nodes.

Verify ROS 2 Environment and Compatibility

Even when network connectivity and firewall settings are correct, ROS 2 communication can fail due to environment mismatches or incompatible interface definitions. This section covers basic reachability verification, QoS policy alignment, and message definition consistency.

Verify Network Reachability

Before investigating higher-level compatibility issues, confirm basic network connectivity between MATLAB and the external ROS 2 device:

  • Ping the remote device to confirm that the network path is open and reachable.

  • Verify that the ROS_DOMAIN_ID environment variable is set to the same value on both systems. Nodes on different Domain IDs cannot discover each other.

  • Confirm that both systems run the same ROS 2 distribution (for example, Humble or Iron). Mismatched distributions can cause incompatible DDS wire-protocol versions or message serialization differences.

Verify QoS Policy Compatibility

Ensure that all communicating nodes use compatible QoS settings. Incompatible QoS policies, for example, a publisher using "besteffort" reliability while a subscriber requires "reliable" cause the subscriber to silently reject the publisher, resulting in no message delivery.

For more information on compatible QoS policies, see Manage Quality of Service Policies in ROS 2.

Validate Message, Service, and Action Definitions

Ensure that the message, service, and action definitions are identical between MATLAB and the external ROS 2 environment. Differences in type definitions or missing custom messages prevent communication even when the firewall is open and nodes are mutually discoverable.

Specifically, verify that:

  • Custom message packages are generated and registered in both environments.

  • The field names, field types, and field order in each message definition match exactly.

  • Service and action definitions such as, request/response/goal/result/feedback types are consistent.

If you use custom messages, regenerate them on both sides using the same .msg, .srv, or .action definition files to ensure consistency.

See Also

Topics