[Bug] D555 (PoE) cold-boot network hang — 1-2 of 4 cameras fail to enumerate on the network (firmware network-ready hang suspected)

Camera Model

D555

LibRealSense SDK Version

2.58.2

Firmware Version

7.58.38066.8032

Operating System

Nvidia Jetson JP7

Kernel Version (Linux Only)

No response

MIPI Driver Version (NVIDIA Jetson Only)

No response

Platform

NVIDIA Jetson Orin AGX

Connection Type

Ethernet/DDS

Language

ROS2

Application Segment

Robotics

Issue Description

Issue Description

On host cold boot (power off → on), 1–2 of 4 PoE-connected D555 cameras randomly fail to appear on the network, while the corresponding NIC link is perfectly healthy. A single PoE port power-cycle recovers it immediately. Reproduces ~80% of cold boots (4 of 5). Host, network and software have been ruled out — this points to the camera firmware failing to reach network-ready (hang) during cold boot.

Symptoms

• rs-enumerate-devices -s → 3/4 or 2/4 (1–2 cameras missing)
• ip neigh for the missing camera IP → FAILED / arping → 0 replies
• But the NIC for that camera shows: carrier=1, 1000 Mbps Full Duplex, Link detected: yes (physical link is up)

Key evidence — device hang, not PoE budget

Boot dmesg (example, one failing port):

02:35:43  <iface>  NIC Link is Up 1000 Mbps Full Duplex   ← all 4 NICs up within 4 s of boot
(no link down / flap until the PoE cycle at 02:46)

• The link stays up for 10+ minutes with power applied, yet the camera never responds to ARP/DDS.
• No link flap → not an SoC bootloop / brownout → suggests the camera firmware hangs before reaching network-ready.
• A PoE budget shortfall would show carrier=0 or link flap — neither is observed.

Steps to reproduce

1. Connect 4× D555 (PoE) to the host's 4 PoE NICs with static host IPs.
2. Cold boot the host (full power off → on; not a warm reboot).
3. After boot, run rs-enumerate-devices -s and ip neigh.
4. → 1–2 cameras missing (ARP FAILED), random which ones. ~80% of cold boots.

Expected vs Actual

• Expected: all 4 cameras enumerate on the network after cold boot (as they do after a warm reboot).
• Actual: 1–2 randomly absent despite healthy NIC link; only a PoE port power-cycle brings them back.

Workaround

• Power-cycle the affected PoE port once → link re-negotiates, ARP/DDS responds, and the ROS 2 composable node self-recovers (no driver restart needed).

Host/SW ruled out (over 5 cold boots)

• All 4 NICs reach 1000 Mbps within ~4 s of boot; static host IPs, 0 DAD conflicts.
• DDS control.reply-timeout-ms = 10000; driver supervisor performs 0 respawns.
• docker restart and rs-dds-config reset have no effect — the camera is simply not present on the network, so nothing in software can recover it.
• Warm reboot / docker restart do not trigger the issue — it is specific to cold power-up.

Questions / requested investigation

• Is there a known cold-boot sequencing issue in FW 7.58.38066.8032?
• Could simultaneous 4-port PoE inrush at power-up affect the camera SoC bring-up? (Would sequential/staggered power-up reduce the rate?)
• Is there a way to log firmware boot → network-ready timing to distinguish a slow boot from a true hang?

Steps to Reproduce

1. Connect 4× D555 (PoE) to the host's 4 PoE NICs with static host IPs.
2. Cold boot the host (full power off → on; not a warm reboot).
3. After boot, run rs-enumerate-devices -s and ip neigh.
4. → 1–2 cameras missing (ARP FAILED), random which ones. ~80% of cold boots.

Expected Behavior

No response

Actual Behavior

No response

Relevant Log Output

Additional Context

No response