When Ethernet LiDAR packets appear in a capture but clouds lose sectors, confirm whether complete UDP datagrams reach the decoder before increasing ROS queues. IP fragmentation is one possible transport boundary, not a diagnosis that follows from a broken-looking cloud. Establish that fragmented traffic exists, preserve a representative capture and compare network, kernel and application observations during the same interval.
The decision is narrower than whether the sensor is publishing. The publish-rate diagnostic separates upstream reception from downstream cloud emission. This workflow focuses on a specific earlier question: does the receiving host reconstruct the intended network datagrams, and does the application receive their complete payloads?
Record the sensor model and operating mode, firmware, driver revision, host kernel, receiving interface and full network path. Do not assume every Ethernet LiDAR uses the same packet size or protocol. The official rs_driver architecture reference is an example of separate input and decoding stages; it does not establish the packet contract for another sensor.
Identify the transport contract before changing the host
Obtain the documented packet format and configuration for the deployed model. Distinguish an Ethernet frame, an IP packet, a UDP datagram and the sensor’s own logical packet. A vendor document may use the word packet for different layers. Write down which length is being measured, which headers are included and what the decoder expects to receive.
Inventory every interface and network device on the actual route, including switches, adapters, bridges, virtual interfaces and tunnels. Record effective MTU settings and the location at which a capture is made. A successful test through a direct bench cable does not prove the behavior of a deployed route containing additional encapsulation or a different receiving interface.
The Linux UDP manual describes datagram reception, truncation and path-MTU behavior. Treat its host behavior separately from a sensor’s sending implementation. A receiver-side tuning guide cannot prove how an embedded sender constructs its traffic. Keep the original sensor and network settings available for controlled comparison.
Prove that fragmentation is present
Capture at the receiving interface for a short identified test interval. Inspect the IP fields and group fragments that belong to the same original datagram rather than counting all visible frames as complete application messages. Record the addresses, protocol, identification and fragment information needed by the analyst. Keep the original capture instead of exporting only selected screenshots.
Choose a capture method that retains the evidence needed for this question. A capture filter built solely around an application port can omit relevant fragment traffic when that fragment does not carry the transport header. Validate the selection against a broader short capture in a controlled environment rather than assuming every displayed packet is the entire traffic stream.
The Wireshark reassembly documentation explains that the analyzer can reconstruct protocol data and show it separately from individual packets. Record the analyzer version and relevant preferences. Analyzer reconstruction is evidence about the saved capture; it is not proof that the live application’s socket received the same reconstructed datagram.
Separate a missing fragment from a missing observation
Review capture completeness before blaming the network. Preserve the capture tool’s loss summary, the recording location and the conditions under which the host was operating. A capture that drops traffic can produce an incomplete fragment set even when the application received data, while a complete capture can coexist with a later kernel or socket problem.
Where the project permits it, compare observations at identified points on the route. Keep their clocks and capture conditions explicit. Avoid subtracting unrelated timestamps to invent transit latency. When only the receiving host is available, state that the investigation cannot directly localize a missing fragment to a particular cable, switch or sending device.
If the expected stream is missing entirely, return to the viewer-versus-driver boundary checks. Verify interface identity and destination configuration. For multiple devices, the separate-network-port checklist helps establish which sensor and route each observation belongs to.
Compare reassembly and socket evidence in one interval
Collect relevant host network counters before and after the test and record their scope. A system-wide counter can include unrelated traffic. Keep the time window, active applications and interface workload in the record so an increase is not silently attributed to the LiDAR. Preserve the exact counter names and installed-kernel documentation used to interpret them.
The versioned Linux IPv4 sysctl reference describes fragment reassembly controls. It is a reference for that kernel version, not a universal tuning recipe. Match behavior to the deployed kernel and configuration before considering changes. Do not enlarge memory thresholds or waiting periods simply because an online example reports a larger number.
Then instrument the application’s receive boundary using the implementation’s supported diagnostic path. Record receive lengths, error or truncation indications and accepted or rejected sensor packets. Keep this separate from decoded point count. A complete UDP datagram can still fail a sensor-format check, and a valid decoded packet may later be excluded by application filtering.
| Evidence | Question it answers | What it does not prove |
|---|---|---|
| Frames visible at capture point | What the observer recorded there | Complete application delivery |
| Analyzer reassembled payload | Whether that capture supports reconstruction | Live kernel and socket success |
| Host reassembly counter change | Whether scoped host behavior changed | Which sensor caused a global change |
| Application receive length and result | What reached that receive boundary | Correct decoded geometry |
Test one bounded change and retain the baseline
Use a controlled network path or supported sensor setting to test a specific hypothesis. Define the observation that would support it before changing anything. Keep sensor mode, host workload and recording method stable where possible, and identify unavoidable differences. Do not combine several tuning changes and then attribute an improvement to whichever explanation seems convenient.
The Linux IP manual provides the host API context for IP and socket behavior. Any proposed adjustment must still fit the application’s requirements and the supported network path. A larger interface MTU on one machine is not evidence that all devices along the path support the intended traffic.
Repeat the original failing interval or an equivalent controlled workload after the change. Compare fragmentation evidence, capture loss, relevant counters, receive results and decoded output together. If complete datagrams were already reaching the decoder, move the investigation downstream rather than continuing to tune reassembly. The driver regression checklist helps preserve message-format evidence when software changes are involved.
Build a support record that identifies the failing layer
Include the topology, effective configuration, installed versions, test interval, original capture, observation limitations and receive-boundary results. Describe the earliest boundary that differs between the baseline and failing case. The reproducible support-bundle guide provides a structure for keeping those artifacts tied to one configuration.
Frequently asked questions
Does every missing cloud sector indicate fragmentation?
No. Sensor mode, packet loss, decoding, scan grouping and later filters can also affect output. Begin with evidence at the transport boundary rather than treating the visual symptom as proof of one network cause.
Can a packet analyzer repair the live data stream?
No. Its reassembly view helps inspect recorded traffic. It does not change what the application’s socket received during the original run. Compare both observations explicitly.
Should we publish a universal fragment-memory setting?
No. Choose any change from the deployed kernel, traffic evidence and resource requirements, and validate its effect. A LiDAR IP fragment reassembly investigation succeeds when it locates a reproducible failing boundary, not when it copies a larger number into a system configuration.
