rosotacom-dev 2.5.dev62__tar.gz → 2.5.dev66__tar.gz

{rosotacom_dev-2.5.dev62 → rosotacom_dev-2.5.dev66}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: rosotacom-dev
-Version: 2.5.dev62
+Version: 2.5.dev66
 Summary: Host CLI for ROS OTA communication sessions.
 Author: develNor
 License-Expression: BSD-3-Clause
@@ -367,7 +367,7 @@ Peer reachability is opt-in because some valid networks block ICMP and peers may
 be started in either order. `rosotacom start` accepts the same
 `--require-peer-reachable` policy when a deployment does require it.
 
-`rosotacom` reads the static session input and creates generated files under `session-instances/<date>/<session>_<timestamp>_<id>/config/`, including per-peer plugin/session specs, topic lists, optional QoS, and optional `domain_bridge.yaml`. Catmux pane output is logged under the same instance in `logs/<peer>/catmux/`.
+`rosotacom` reads the static session input and creates generated files under `session-instances/<date>/<session>_<timestamp>_<id>/config/`, including per-peer plugin/session specs, topic lists, optional QoS, and optional `domain_bridge.yaml`. The instance's `manifest.yaml` records what produced it: `rosotacom_version`, the effective config SHA, and `source_revision` — the commit, branch and tracked-dirtiness of the session source directory at creation time, so a recording stays attributable to a revision after the checkout has moved on (`null` when the source is not a git repository). Catmux pane output is logged under the same instance in `logs/<peer>/catmux/`.
 
 What else a run leaves under `logs/<peer>/`, and which file to open first when a
 peer looked healthy but did nothing:

{rosotacom_dev-2.5.dev62 → rosotacom_dev-2.5.dev66}/README.md

@@ -322,7 +322,7 @@ Peer reachability is opt-in because some valid networks block ICMP and peers may
 be started in either order. `rosotacom start` accepts the same
 `--require-peer-reachable` policy when a deployment does require it.
 
-`rosotacom` reads the static session input and creates generated files under `session-instances/<date>/<session>_<timestamp>_<id>/config/`, including per-peer plugin/session specs, topic lists, optional QoS, and optional `domain_bridge.yaml`. Catmux pane output is logged under the same instance in `logs/<peer>/catmux/`.
+`rosotacom` reads the static session input and creates generated files under `session-instances/<date>/<session>_<timestamp>_<id>/config/`, including per-peer plugin/session specs, topic lists, optional QoS, and optional `domain_bridge.yaml`. The instance's `manifest.yaml` records what produced it: `rosotacom_version`, the effective config SHA, and `source_revision` — the commit, branch and tracked-dirtiness of the session source directory at creation time, so a recording stays attributable to a revision after the checkout has moved on (`null` when the source is not a git repository). Catmux pane output is logged under the same instance in `logs/<peer>/catmux/`.
 
 What else a run leaves under `logs/<peer>/`, and which file to open first when a
 peer looked healthy but did nothing:

{rosotacom_dev-2.5.dev62 → rosotacom_dev-2.5.dev66}/docs/findings/README.md

@@ -31,6 +31,8 @@ living verification hook.
 - [Sender-side transit rows made a dead link report zero loss](sender-rows-make-a-dead-link-look-loss-free.md) - `delivered = rows - lost` counted the sender's own `sent` rows as deliveries, so a topic the receiver never saw summarised as `delivered == expected` at 0.0% loss, with the publisher's timer reported as arrival spacing.
 - [A bridge that learns types from the graph cannot use a transport that does not carry the graph](graph-derived-types-block-a-non-graph-transport.md) - over `zenoh_ros2dds` the payload topic never arrived in either run: the bridge routes a topic once a local reader exists and the reader waited for the bridge, leaving only `Pending=1` in a log.
 - [A Fast DDS datagram cap stops every message larger than it](fastdds-datagram-cap-drops-large-samples.md) - copying CycloneDDS's 1200 B fragment size into the Fast DDS OTA profile makes every sample above the cap never arrive, at 1200 B and at 8192 B, sync and async — while the 84 B heartbeat keeps flowing at 10 Hz.
+- [A fragment sized exactly like the datagram cap stops every fragmented sample](cyclone-fragment-equal-to-max-drops-fragmented-samples.md) - CycloneDDS 11.0.1 delivers nothing above one fragment when `FragmentSize` equals `MaxMessageSize`, where 0.10.5 delivers everything on the identical profile; a 40 B string still crosses, and discovery, endpoint announcement and proxy-writer matching all succeed while no sample arrives.
+- [Two CycloneDDS configurations on one domain stop interoperating](one-domain-two-cyclone-configs-stop-interoperating.md) - on 11.0.1 a publisher and a subscriber on the same host and domain deliver nothing when one carries the local profile and the other the OTA profile, where 0.10.5 delivers in all four combinations; discovery, endpoint announcement and matching all succeed while no sample moves.
 - [A lost keyframe silences exactly the next gop_size−2 deltas](keyframe-loss-kills-the-next-deltas.md) - libavcodec emits nothing for them, the last delta decodes with artifacts, the next keyframe restores clean decode; a lost delta never blocks decode — so the display hole is gop_size × frame period, deterministically.
 - [Any transport element in a Fast DDS profile doubles every sample on the wire](a-transport-element-doubles-every-fastdds-sample.md) - 366 datagrams for 180 samples against 183 without it; `<builtinTransports>DEFAULT` is a no-op selection and doubles too, so the trigger is the element's presence — removing it takes the shipped OTA profile from 2.10x the payload to 1.04x at identical delivery.
 - [Lifespan is enforced by one DDS reader and not the other](lifespan-is-enforced-by-one-reader-and-not-the-other.md) - under the same 20% oversubscription both stacks queue alike (472 and 433 delivered at ~1.1-1.2 s); with `lifespan: 0.7` CycloneDDS is unchanged and delivers 9.1% inside the bound, while Fast DDS drops to 4 delivered and never exceeds 570 ms — the policy decides shown-vs-suppressed, not how long the wait is.

rosotacom_dev-2.5.dev66/docs/findings/cyclone-fragment-equal-to-max-drops-fragmented-samples.md

@@ -0,0 +1,89 @@
+# A Fragment Sized Exactly Like the Datagram Cap Stops Every Fragmented Sample
+
+## Claim
+
+Setting CycloneDDS's `FragmentSize` **equal to** `MaxMessageSize` makes every
+sample large enough to fragment **never arrive** on CycloneDDS 11.0.1, while the
+identical profile carries them on 0.10.5. Samples small enough to fit in one
+fragment keep flowing on the same link, which is what makes it dangerous: the
+endpoints match, neither side logs anything, and the reader simply never sees a
+sample.
+
+An RTPS message carries headers as well as the fragment, so a fragment of
+exactly `MaxMessageSize` cannot be put into a message of `MaxMessageSize`.
+0.10.5 evidently coped with that arithmetic; 11.0.1 does not, and drops
+silently.
+
+This is the CycloneDDS sibling of
+[the Fast DDS datagram cap](fastdds-datagram-cap-drops-large-samples.md), found
+from the opposite direction: there the cap was a value copied *from* this
+profile, here the profile's own two values were equal to each other.
+
+## Setup
+
+- Host pair / topology: two hosts joined by a point-to-point VPN (`/24`,
+  1.3 ms RTT, 0.0% loss measured with three probes each way), one container per
+  host from the packaged communication image, `--network host --ipc host`, one
+  ROS domain. Not the local smoke rig: on a single host nothing fragments far
+  enough to show it.
+- Session: none. A bare `ros2 topic pub -r 1` of a 64 kB
+  `std_msgs/msg/String` against a subscriber given the type explicitly — with
+  `EnableTopicDiscoveryEndpoints false` a bare `ros2 topic echo <topic>`
+  resolves no type and reports nothing, in both versions, which is a trap worth
+  naming because it looks exactly like the failure under test.
+- rosotacom SHA: measured on the packaged 2.5.dev61 images; re-runs record
+  theirs.
+- Profile: none — no impairment. The failure needs none, which is what makes it
+  attributable to the configuration rather than to the link.
+- Seed policy: deterministic (no netem, no random load), `n=1` per variant; the
+  effect is present/absent, not a distribution.
+- Stacks: `ros-kilted-cyclonedds` 0.10.5-2noble against
+  `ros-lyrical-cyclonedds` 11.0.1-4resolute.
+
+## Evidence
+
+| profile | 0.10.5 | 11.0.1 |
+|---|---|---|
+| `FragmentSize` 1200 B, `MaxMessageSize` 1200 B | arrives | **nothing** |
+| no size limits at all | — | arrives |
+| `FragmentSize` 1024 B, `MaxMessageSize` 1200 B | — | arrives |
+
+- A 40 B string crosses on 11.0.1 with the 1200/1200 profile, so the trigger is
+  fragmentation and not the link.
+- The discovery trace of a failing run rules out everything above the data path:
+  both participants discover each other across the hosts, both sides announce
+  their endpoints, the reading side builds proxy writers for the remote
+  participants, and neither side logs a QoS incompatibility or a rejection.
+
+Verification: automated:
+`pytest tests/unit/test_ota_link_configs.py::test_only_cyclone_caps_the_datagram_and_fast_dds_must_not`
+asserts the fragment stays strictly below the datagram cap, which is the
+invariant the two numbers exist for. Manual, for the effect itself: one
+container per host from the communication image on one ROS domain, the shipped
+OTA profile with only the three size elements varied, a 64 kB string at 1 Hz,
+and `ros2 topic echo <topic> std_msgs/msg/String --once` on the other side.
+
+## Status
+
+confirmed, 2026-08-20.
+
+Fixed by making `FragmentSize` strictly smaller than `MaxMessageSize` (1024 B
+against 1200 B) in `cyclonedds_tuned.xml.template`. The datagram stays inside
+the same MTU budget the 1200 B was chosen for — only the header room is added —
+and the value works on both versions, so it is one number rather than a branch
+on the distribution.
+
+## Publication notes
+
+A distribution bump silently changed what a profile *means*, and the profile
+text did not move. That is the reportable part: measurements taken under one ROS
+distribution cannot be presented as the other's on the strength of an identical
+configuration file, because identical configuration is not identical behaviour
+across a DDS major version. State the middleware version beside the profile
+wherever OTA numbers are reported.
+
+The second consequence is about what counts as evidence that a link works. A
+heartbeat crossing at 10 Hz with 0.0% loss certified nothing here — the small
+samples were exactly the ones that could not fail. A link check that does not
+include a sample past the fragment threshold does not test the transport the
+payload uses.

{rosotacom_dev-2.5.dev62 → rosotacom_dev-2.5.dev66}/docs/findings/fastdds-datagram-cap-drops-large-samples.md

@@ -10,7 +10,7 @@ this dangerous: an 84 B heartbeat crossing at 10 Hz with 0.0% loss is a link
 that looks alive from every direction except the one that matters.
 
 The obvious reason to set it is symmetry with CycloneDDS, whose OTA profile
-carries this link at `FragmentSize`/`MaxMessageSize` 1200 B and works. The
+carries this link at a 1024 B fragment inside a 1200 B datagram and works. The
 symmetry does not transfer: on ROS 2 Kilted with Fast DDS 3.2.4 the cap is the
 single knob that breaks the link, at 1200 B and at 8192 B, with a synchronous
 writer and with an asynchronous one.

rosotacom_dev-2.5.dev66/docs/findings/one-domain-two-cyclone-configs-stop-interoperating.md

@@ -0,0 +1,94 @@
+# Two CycloneDDS Configurations on One Domain Stop Interoperating
+
+## Claim
+
+On CycloneDDS 11.0.1 two participants on the **same host and the same domain**
+exchange no data when they are given different configurations. On 0.10.5 they
+do. Discovery is unaffected in the failing combination — the topic appears in
+`ros2 topic list`, both sides announce their endpoints, the reader builds its
+proxy writers — and no sample is delivered.
+
+This is what a session relies on without saying so. A peer renders two whole
+configurations, a local one and an OTA one, and exports `CYCLONEDDS_URI` twice,
+so the second replaces the first: processes started after it view the *local*
+domain through the *OTA* profile while the relay and the application containers
+view it through the local one. Under 0.10.5 that mixture worked. Under 11.0.1
+the bridge subscribes on the local domain, receives nothing, forwards nothing
+into the OTA domain, and the far peer receives nothing — with every stage
+reporting itself healthy.
+
+## Setup
+
+- Host pair / topology: for the effect itself, one host is enough — two
+  containers from the same communication image, `--network host`, one ROS
+  domain, one publisher and one subscriber. The session it was found in runs
+  across two hosts joined by a point-to-point VPN.
+- Session: none for the isolated measurement; a `std_msgs/msg/String` at 2 Hz
+  and `ros2 topic echo … --once`. The two configurations are the ones a session
+  renders: `cyclonedds_local_participants.xml` and `cyclonedds_tuned.xml`.
+- rosotacom SHA: measured on the packaged 2.5.dev61 images; re-runs record
+  theirs.
+- Profile: none — no impairment; the effect needs none.
+- Seed policy: deterministic (no netem, no random load), `n=1` per cell; the
+  effect is present/absent, not a distribution.
+- Stacks: `ros-kilted-cyclonedds` 0.10.5-2noble against
+  `ros-lyrical-cyclonedds` 11.0.1-4resolute.
+
+## Evidence
+
+| publisher / subscriber | 0.10.5 | 11.0.1 |
+|---|---|---|
+| local / local | 12 B | 12 B |
+| local / **ota** | 12 B | **0** |
+| **ota** / local | 12 B | **0** |
+| ota / ota | 12 B | 12 B |
+
+Inside a failing session, one topic the relay publishes on the local domain:
+
+```
+/com/out/<peer>/can/twist/max10hz/ota_stamped, domain 47
+  subscriber with local_dds.xml : 512 B received
+  subscriber with ota_dds.xml   :   0 B
+domain 47 seen through local_dds.xml : 103 topics
+domain 47 seen through ota_dds.xml   :  29 topics
+```
+
+Ruled out on the way to it, each measured with the real images on the same
+hosts: cross-host delivery, same-host delivery under one profile,
+`com_msgs/msg/OtaStamped`, the container's IPC namespace, `domain_bridge`
+itself (minimal config, the session's full 27-topic config, with and without the
+OTA profile, with and without `ROS_DOMAIN_ID` set), participant count (0, 6 and
+12 extra participants), and adding the local profile's
+`ParticipantIndex`/`MaxAutoParticipantIndex` to the OTA profile.
+
+Verification: automated:
+`pytest tests/unit/test_ota_xml.py::test_shipped_scoped_template_carries_both_domains_and_only_ota_restrictions`
+holds the shape of the configuration that avoids the mixture — OTA restrictions
+scoped to the OTA domain, the local domain left with default discovery. Manual,
+for the effect itself: two containers on one host and one domain, one publisher
+and one subscriber, each given one of the two rendered profiles, all four
+combinations.
+
+## Status
+
+confirmed, 2026-08-20.
+
+Addressed by `cyclonedds_scoped.xml.template`, which carries both domains in one
+file with each section scoped by `Domain Id`, so one configuration can be shared
+by every process on the host. It is an additional template: the two-file
+arrangement is unchanged, and a session that does not name the new one behaves
+exactly as before.
+
+## Publication notes
+
+The reportable part is not "a DDS version changed". It is that a configuration
+which was *never* uniform became load-bearing without anybody choosing it: the
+mixture had been there all along and was harmless, so nothing recorded it as a
+property of the deployment. A measurement stack should state, beside the
+middleware version, whether every process on a domain was configured
+identically — because on one side of that version boundary the answer does not
+matter and on the other it decides whether any data moves.
+
+Second, it is another instance of the same trap as the datagram cap: a link that
+passes discovery, endpoint matching and a heartbeat check while carrying
+nothing. Neither check tests what the payload uses.

{rosotacom_dev-2.5.dev62 → rosotacom_dev-2.5.dev66}/docs/forensics-report.md

@@ -37,7 +37,7 @@ gracefully when absent:
 |---|---|
 | `status.json` | declared topic types (FFMPEGPacket detection) |
 | `link_trace.jsonl` ([link trace recorder](link-trace.md)) | link state around each incident |
-| `manifest.yaml` | instance id + config SHA provenance |
+| `manifest.yaml` | instance id, config SHA, and `source_revision` — the commit of the session source at instance creation |
 | `--profile NAME --profiles-file FILE` | RFC 0004 environment context (static params or timeline steps) |
 | `state_transition` rows in `events.jsonl` | pipeline diagnoses around each incident |
 

{rosotacom_dev-2.5.dev62 → rosotacom_dev-2.5.dev66}/docs/link-trace.md

@@ -30,6 +30,16 @@ rosotacom ota-smoke 13_link_latency --link-trace
 `--link-trace-interval` and `--link-trace-modem-command` also enable the
 recorder and force `shared.use_status_overview: true` for the generated instance.
 
+`interval_s` is the period between rows, and the status-overview node is ticked
+at the same period when the trace is enabled. Those two being equal is what
+makes the trace continuous: each row's `passive_counter_delta` covers one tick,
+so consecutive rows meet rather than leaving traffic between them. The recorder
+therefore schedules against an advancing deadline with a small tolerance instead
+of a stopwatch since the last row — without that, a tick landing a hair early is
+rejected and waits a whole further period, which halves the trace and leaves
+every second interval described by no row at all (measured on a 5 h drive:
+1.984 s between rows carrying 1.002 s windows).
+
 ## Row Schema
 
 Each line is one JSON object:

{rosotacom_dev-2.5.dev62 → rosotacom_dev-2.5.dev66}/src/rosotacom/cli.py

@@ -882,6 +882,61 @@ def _append_log(path: Path, text: str) -> None:
             fp.write("\n")
 
 
+#: A provenance read must never be what makes an instance fail to start.
+_SOURCE_REVISION_TIMEOUT_S = 5.0
+
+
+def _source_revision(path: Path | str) -> dict[str, Any] | None:
+    """The VCS revision of the directory this session was taken from.
+
+    `rosotacom_version` pins the tool. This pins its *input*: the session source
+    is normally a checkout of a deployment repository, and that checkout moves.
+    A consumer reading the manifest later cannot recover the revision by looking
+    at the machine, because looking at the machine answers a different question —
+    on one two-machine drive the vehicle had been synced by the time the
+    recording was consolidated the next morning, so the only commit anybody
+    could still read was not the commit that ran. The manifest is written once
+    at creation and never rewritten, which is exactly what such a fact needs.
+
+    `dirty` deliberately ignores untracked files: deployment checkouts routinely
+    carry recordings, logs and scratch files that are not the code, so counting
+    them would make every real deployment permanently dirty and the flag
+    meaningless. What it reports is tracked content differing from the commit.
+
+    Best effort throughout — not a directory, no git, not a repository, a git
+    that hangs: all yield None.
+    """
+    directory = Path(path)
+    if not directory.is_dir():
+        return None
+
+    def git(*args: str) -> str | None:
+        try:
+            result = subprocess.run(
+                ["git", "-C", str(directory), *args],
+                capture_output=True,
+                text=True,
+                check=False,
+                timeout=_SOURCE_REVISION_TIMEOUT_S,
+            )
+        except (OSError, subprocess.SubprocessError):
+            return None
+        return result.stdout.strip() if result.returncode == 0 else None
+
+    commit = git("rev-parse", "HEAD")
+    if not commit:
+        return None
+    branch = git("rev-parse", "--abbrev-ref", "HEAD")
+    tracked_changes = git("status", "--porcelain", "--untracked-files=no")
+    return {
+        "vcs": "git",
+        "commit": commit,
+        "branch": None if branch in (None, "HEAD") else branch,
+        "dirty": None if tracked_changes is None else bool(tracked_changes),
+        "root": git("rev-parse", "--show-toplevel"),
+    }
+
+
 def _effective_config_sha256(cfg: dict[str, Any]) -> str:
     text = yaml.safe_dump(cfg, sort_keys=True, default_flow_style=False, allow_unicode=True)
     return hashlib.sha256(text.encode("utf-8")).hexdigest()
@@ -908,6 +963,7 @@ def _write_instance_manifest(
             "instance_id": instance.instance_id,
             "rosotacom_version": __version__,
             "source_session_host_dir": str(session.host_dir),
+            "source_revision": _source_revision(session.host_dir),
             "source_session_container_dir": session.container_dir,
             "source": session.source,
             "config_dir": str(instance.config_host_dir),
@@ -962,6 +1018,7 @@ def _write_scenario_manifest(
             "instance_id": instance.instance_id,
             "rosotacom_version": __version__,
             "source_session_host_dir": str(session.host_dir),
+            "source_revision": _source_revision(session.host_dir),
             "source_session_container_dir": session.container_dir,
             "source": session.source,
             "config_dir": str(instance.config_host_dir),
@@ -1028,6 +1085,7 @@ def _write_interactive_smoke_manifest(
             "instance_id": instance.instance_id,
             "rosotacom_version": __version__,
             "source_session_host_dir": str(target.session.host_dir),
+            "source_revision": _source_revision(target.session.host_dir),
             "source_session_container_dir": target.session.container_dir,
             "source": target.session.source,
             "config_dir": str(instance.config_host_dir),
@@ -2445,6 +2503,7 @@ def _ota_write_manifest(
             "instance_id": instance.instance_id,
             "rosotacom_version": __version__,
             "source_session_host_dir": str(target.session.host_dir),
+            "source_revision": _source_revision(target.session.host_dir),
             "source_session_container_dir": target.session.container_dir,
             "source": target.session.source,
             "config_dir": str(instance.config_host_dir),

rosotacom_dev-2.5.dev66/src/rosotacom/resources/ws/ota_configs/cyclonedds_scoped.xml.template

@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+One CycloneDDS configuration for both of a peer's domains, each section scoped
+to the domain it belongs to.
+
+Set it as `shared.rmw.ota.cyclone.config` and leave the local one unset: this
+file already carries the local domain's section, so nothing has to overwrite
+anything.
+
+Why it exists. The two-file arrangement renders a local profile and an OTA
+profile and exports CYCLONEDDS_URI twice, so the second replaces the first and
+every process started after it views the *local* domain through the *OTA*
+profile. On CycloneDDS 0.10.5 that was survivable: participants configured
+differently on one host and one domain still exchanged data. On 11.0.1 they do
+not — they discover each other, announce their endpoints, match, and deliver
+nothing. Measured on one host, one domain, a publisher and a subscriber:
+
+  publisher / subscriber     0.10.5     11.0.1
+  local     / local          12 B       12 B
+  local     / ota            12 B       0
+  ota       / local          12 B       0
+  ota       / ota            12 B       12 B
+
+A session whose relay publishes under one profile and whose bridge subscribes
+under the other therefore hands nothing from the local domain into the OTA
+domain, and the link carries nothing while every stage looks healthy
+(docs/findings/one-domain-two-cyclone-configs-stop-interoperating.md).
+
+Scoping fixes the cause rather than the symptom: the OTA settings apply to the
+OTA domain, the local domain keeps default discovery with room for many
+participants, and one file can be shared by every process on the host.
+
+The two-file arrangement stays exactly as it was — this is an additional
+template, not a replacement, and a session that does not name it is unchanged.
+-->
+<CycloneDDS xmlns="https://cdds.io/config">
+  <!--
+  The OTA domain: interface-pinned, unicast-only, with the datagram caps the
+  provisioned link is sized for. Identical to cyclonedds_tuned.xml except that
+  it says which domain it is for.
+  -->
+  <Domain Id="#ota_domain">
+    <General>
+      <AllowMulticast>false</AllowMulticast>
+      <Interfaces>
+        <NetworkInterface address="#host_ip"/>
+      </Interfaces>
+      <MulticastRecvNetworkInterfaceAddresses>none</MulticastRecvNetworkInterfaceAddresses>
+      <!-- Strictly below MaxMessageSize; see cyclonedds_tuned.xml for what
+           making them equal cost. -->
+      <FragmentSize>1024B</FragmentSize>
+      <MaxMessageSize>1200B</MaxMessageSize>
+      <MaxRexmitMessageSize>1200B</MaxRexmitMessageSize>
+    </General>
+
+    <Discovery>
+      <Peers>
+        <!--peer-block--><Peer Address="#peer"/><!--/peer-block-->
+      </Peers>
+      <EnableTopicDiscoveryEndpoints>false</EnableTopicDiscoveryEndpoints>
+      <LeaseDuration>60s</LeaseDuration>
+      <SPDPInterval>#spdp_interval</SPDPInterval>
+    </Discovery>
+
+    <Internal>
+      <SquashParticipants>true</SquashParticipants>
+    </Internal>
+
+    <Tracing>
+      <Verbosity>config</Verbosity>
+      <OutputFile>/tmp/cyclonedds.log</OutputFile>
+    </Tracing>
+  </Domain>
+
+  <!--
+  The local domain: default discovery, more participants. It pins no interface,
+  disables no multicast and sets no peer list, because intra-host discovery has
+  to keep working — the same reasoning as cyclonedds_local_participants.xml,
+  including why 119 and not higher.
+  -->
+  <Domain Id="#local_domain">
+    <Discovery>
+      <ParticipantIndex>auto</ParticipantIndex>
+      <MaxAutoParticipantIndex>119</MaxAutoParticipantIndex>
+    </Discovery>
+  </Domain>
+</CycloneDDS>

{rosotacom_dev-2.5.dev62 → rosotacom_dev-2.5.dev66}/src/rosotacom/resources/ws/ota_configs/cyclonedds_tuned.xml.template

@@ -6,7 +6,18 @@
                 <NetworkInterface address="#host_ip"/>
             </Interfaces>
             <MulticastRecvNetworkInterfaceAddresses>none</MulticastRecvNetworkInterfaceAddresses>
-            <FragmentSize>1200B</FragmentSize>
+            <!-- Strictly below MaxMessageSize, and that is the whole point: an RTPS
+                 message carries headers as well as the fragment, so a fragment of
+                 exactly MaxMessageSize cannot be sent at all. Both were 1200B, which
+                 CycloneDDS 0.10.5 coped with and 11.0.1 does not — under Lyrical no
+                 fragmented sample crossed, silently: the endpoints matched and the
+                 reader never saw a sample, while a sample small enough not to
+                 fragment arrived normally. Measured between two hosts with a 64 kB
+                 sample: 1200/1200 delivers nothing on 11.0.1 and everything on
+                 0.10.5; 1024/1200 delivers on both. The datagram stays inside the
+                 same MTU budget the 1200B was chosen for; only the header room is
+                 added. -->
+            <FragmentSize>1024B</FragmentSize>
             <MaxMessageSize>1200B</MaxMessageSize>
             <MaxRexmitMessageSize>1200B</MaxRexmitMessageSize>
         </General>