Multicast / WiFi

← Back to overview

The pain

DDS discovery defaults to UDP multicast, and the data path leans on broadcast assumptions that wireless networks do not honour (34 reports). On WiFi:

  • Multicast is rate-limited or dropped by access points, so discovery silently fails — the canonical “works on my desk, dies in the lab” failure.
  • Where multicast is allowed, discovery traffic over WiFi can fragment and behave like a self-inflicted mini-DDoS, causing second-long dropouts that crash multi-robot setups.
  • Unconfigured multi-interface hosts announce every interface, then stream point clouds and LiDAR to addresses that route off-network and saturate uplinks for days.

The community’s own conclusion: working out of the box on ordinary WiFi is “the minimum viable product” for ROS 2 — and stock DDS fails that bar.

Most recent example

turtlebot4#673 — “Configuring Fast DDS Discovery Server to use TCP to bypass firewall UDP flood protection” (2026-02-04). To get a TurtleBot 4 working on a managed wireless network, users have to stand up a Discovery Server and switch the transport to TCP, purely to get around the network’s UDP-flood protection tripping on DDS traffic.

Reference list (most recent)

Date Source Problem
2026-02-04 turtlebot4#673 Need Discovery Server + TCP to survive WiFi UDP-flood protection
2025-11-05 Cyclone WiFi gist Hand-tuned XML to make Cyclone work on enterprise WiFi+Ethernet
2025-08-15 arXiv 2508.11366 Whole paper on optimizing ROS 2 comms for wireless
2025-02-10 eProsima “ROS 2 Easy Mode” Vendor ships an “easy mode” to hide discovery/packet-loss pain
2022-11-25 ROS Discourse Multicast over WiFi → 1 s dropouts → drone crashes
2022-05-24 ROS Discourse Unconfigured DDS floods networks for days

How ZeroDDS solves it

Remove the multicast dependency entirely, and announce only the interface you mean.

  • Zero multicast on the wire. ZERODDS_NO_MULTICAST=1 + ZERODDS_PEERS gives full discovery over plain unicast UDP. There is nothing for the AP’s IGMP snooping, multicast rate-limiting, or UDP-flood protection to trip on.
  • TCP transport is native, not a workaround. Where a network only passes TCP, ZeroDDS has a first-class TCP transport — you select it, you don’t bolt a Discovery Server on to get there.
  • Interface pinning for multi-homed hosts. ZERODDS_INTERFACE=<ip> binds send/receive and announces exactly one interface across all transports (UDP/TCP/SHM/UDS), so a host with a real NIC plus Docker/VM virtual interfaces never announces or streams to addresses that route off-network — the “unconfigured DDS considered harmful” failure cannot happen.
  • Honest about the one remaining WiFi gotcha. Idle 802.11 power-save on a WiFi client can drop latency-sensitive unicast discovery frames until the NIC is woken. We root-caused this with a clean A/B packet capture; it is an OS/AP power-management artifact that affects every DDS vendor identically, and the mitigation lives at the OS/AP layer, not in the stack.

Why it no longer has to be a pain

Every WiFi failure in the corpus traces back to depending on multicast/broadcast behaviour the wireless layer does not guarantee, plus announcing interfaces you didn’t mean to. ZeroDDS’s default-capable unicast discovery plus interface pinning removes both — the same outcome teams reach after days of XML tuning and Discovery-Server deployment, available as a two-environment-variable setup.

Reproduce it yourself

# Large data over a real WiFi link, multicast-free, byte-perfect:
crates/ros2-rmw/interop/run_wifi_largedata.sh

# Multicast-free cross-vendor discovery (no multicast packet emitted at all):
crates/ros2-rmw/interop/run_multicast_free_xvendor.sh

→ Back to overview · Next: QoS silent no-match

Multicast / WiFi

← Zurück zur Übersicht

Der Schmerz

DDS-Discovery defaultet auf UDP-Multicast, und der Daten-Pfad lehnt sich an Broadcast-Annahmen, die drahtlose Netze nicht einhalten (34 Reports). Auf WiFi:

  • Multicast wird von Access Points rate-limitiert oder gedroppt, sodass Discovery still scheitert — der kanonische „funktioniert an meinem Schreibtisch, stirbt im Labor”-Fehler.
  • Wo Multicast erlaubt ist, kann Discovery-Traffic über WiFi fragmentieren und sich wie ein selbstverschuldeter Mini-DDoS verhalten, der sekundenlange Aussetzer verursacht, die Multi-Roboter-Setups crashen.
  • Unkonfigurierte Multi-Interface-Hosts announcen jedes Interface und streamen dann Punktwolken und LiDAR an Adressen, die off-network routen und Uplinks tagelang sättigen.

Die eigene Schlussfolgerung der Community: out of the box auf gewöhnlichem WiFi zu funktionieren ist „das Minimum Viable Product” für ROS 2 — und Stock-DDS reißt diese Latte.

Jüngstes Beispiel

turtlebot4#673 — „Configuring Fast DDS Discovery Server to use TCP to bypass firewall UDP flood protection” (2026-02-04). Um einen TurtleBot 4 in einem verwalteten drahtlosen Netz zum Laufen zu bringen, müssen Nutzer einen Discovery-Server aufsetzen und den Transport auf TCP umstellen, rein um die UDP-Flood-Protection des Netzes zu umgehen, die bei DDS-Traffic auslöst.

Referenzliste (jüngste zuerst)

Datum Quelle Problem
2026-02-04 turtlebot4#673 Braucht Discovery-Server + TCP gegen WiFi-UDP-Flood-Protection
2025-11-05 Cyclone-WiFi-Gist Hand-getuntes XML, damit Cyclone auf Enterprise-WiFi+Ethernet läuft
2025-08-15 arXiv 2508.11366 Ganzes Paper über Optimierung von ROS-2-Comms für Wireless
2025-02-10 eProsima „ROS 2 Easy Mode” Vendor liefert einen „Easy Mode”, um Discovery-/Packet-Loss-Schmerz zu verstecken
2022-11-25 ROS Discourse Multicast über WiFi → 1-s-Aussetzer → Drohnen-Crashes
2022-05-24 ROS Discourse Unkonfiguriertes DDS flutet Netze tagelang

Wie ZeroDDS es löst

Entferne die Multicast-Abhängigkeit komplett, und announce nur das Interface, das du meinst.

  • Null Multicast auf dem Draht. ZERODDS_NO_MULTICAST=1 + ZERODDS_PEERS gibt volle Discovery über reines Unicast-UDP. Es gibt nichts, woran das IGMP-Snooping, die Multicast-Rate-Limitierung oder die UDP-Flood-Protection des AP auslösen könnten.
  • TCP-Transport ist nativ, kein Workaround. Wo ein Netz nur TCP durchlässt, hat ZeroDDS einen First-Class-TCP-Transport — du wählst ihn, du schraubst keinen Discovery-Server dran, um dorthin zu kommen.
  • Interface-Pinning für Multi-Homed-Hosts. ZERODDS_INTERFACE=<ip> bindet Send/Receive und announct genau ein Interface über alle Transporte (UDP/TCP/SHM/UDS), sodass ein Host mit echter NIC plus Docker-/VM-Virtual-Interfaces nie an Adressen announct oder streamt, die off-network routen — der „unconfigured DDS considered harmful”-Fehler kann nicht passieren.
  • Ehrlich über den einen verbliebenen WiFi-Gotcha. Idle 802.11-Power-Save auf einem WiFi-Client kann latenz-sensitive Unicast-Discovery-Frames droppen, bis die NIC geweckt ist. Wir haben das mit einem sauberen A/B-Packet-Capture root-caused; es ist ein OS/AP-Power-Management-Artefakt, das jeden DDS-Vendor identisch betrifft, und die Mitigation liegt auf der OS/AP-Ebene, nicht im Stack.

Warum es kein Schmerz mehr sein muss

Jeder WiFi-Fehler im Korpus führt zurück auf die Abhängigkeit von Multicast-/Broadcast-Verhalten, das die Wireless-Ebene nicht garantiert, plus das Announcen von Interfaces, die du nicht meintest. Die default-fähige Unicast-Discovery von ZeroDDS plus Interface-Pinning entfernt beides — dasselbe Ergebnis, das Teams nach Tagen XML-Tuning und Discovery-Server-Deployment erreichen, verfügbar als Zwei-Umgebungsvariablen-Setup.

Selbst reproduzieren

# Large-Data über eine echte WiFi-Strecke, multicast-frei, byte-genau:
crates/ros2-rmw/interop/run_wifi_largedata.sh

# Multicast-freie Cross-Vendor-Discovery (kein Multicast-Paket überhaupt emittiert):
crates/ros2-rmw/interop/run_multicast_free_xvendor.sh

→ Zurück zur Übersicht · Weiter: QoS stilles No-Match