Multicast / WiFi
RC7 preparation: this page retains historical investigations and measurements, not approval of the current candidate. Runtime file contracts were checked against current source; historical interoperability, performance and platform claims were not remeasured by that review.
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
Runtime settings below belong in the base file and sorted drop-ins, not environment overrides.
Remove the multicast dependency entirely, and announce only the interface you mean.
- Zero multicast traffic.
discovery.no_multicast: true+transport.user_multicast: false+discovery.peersgives full discovery over plain unicast UDP: ZeroDDS sends no multicast datagram and announces no multicast locator, so multicast rate limits and drops do not touch the traffic. The SPDP receive socket still joins the group. Unicast UDP can still be filtered or rate-limited by the network. - 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.
transport.interface: <ip>selects the IP interface and advertised locators. SHM/UDS are not IP transports. Correct peer addresses and network routing remain deployment responsibilities. - 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, configured through explicit runtime files.
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
RC7-Vorbereitung: Diese Seite enthält historische Untersuchungen und Messwerte, keine Freigabe des aktuellen Kandidaten. Die Runtime-Dateiverträge wurden mit dem aktuellen Quellstand abgeglichen; historische Interop-, Performance- und Plattformbehauptungen dadurch nicht erneut vermessen.
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
Die folgenden Runtime-Werte gehören in Basisdatei und sortierte Ergänzungen, nicht in Umgebungs-Overrides.
Entferne die Multicast-Abhängigkeit komplett, und announce nur das Interface, das du meinst.
- Kein Multicast-Verkehr.
discovery.no_multicast: true+transport.user_multicast: false+discovery.peersgibt volle Discovery über reines Unicast-UDP: ZeroDDS sendet kein Multicast-Datagramm und kündigt keinen Multicast-Locator an, Rate-Limits und Verluste von Multicast berühren den Verkehr nicht. Der SPDP-Empfangssocket tritt der Gruppe weiterhin bei. Unicast-UDP kann weiterhin gefiltert oder begrenzt werden. - 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.
transport.interface: <ip>wählt das IP-Interface und angekündigte Locators. SHM/UDS sind keine IP-Transporte. Korrekte Peer-Adressen und Netzrouten bleiben Aufgaben des Deployments. - 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 Setup mit expliziten Runtime-Dateien.
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