A
Member
On a private 5G or CPE-style ARM gateway, the radio dashboard can show a healthy RSRP and SINR while the PLC, camera or SSH session still stalls. The missing time is often on the Linux side of the modem: USB or PCIe enumeration, the wwan interface coming up without a default route, DNS pointing at an unreachable core, or the application reconnecting slower than the radio reattach.
Start with the modem path. Does the kernel see the module (cdc_mbim, qmi_wwan, mhi, or the vendor driver)? dmesg around insertion should show a wwan or usb0 interface, not a repeating firmware-load failure. ModemManager or a vendor tool should report a packet data session. ip route and resolv.conf need to match what the core actually hands out; a leftover Ethernet default route will black-hole traffic even when the RF link is up. If you use a VLAN or a policy rule to send only some prefixes over the radio, test that table, not just ping from the box.
Next, measure application recovery separately from radio attach. A brief beam switch or handover may take tens of milliseconds on the air interface and seconds in userspace if TCP connections die and the client waits on its own timeout. Capture timestamps for: modem attach, interface UP, default route installed, first successful DNS, first successful TCP handshake. Those four numbers usually explain the “RF is fine, UX is not” reports.
Keep RF and IP acceptance tests apart. RF: RSRP/SINR/BLER under the real antenna and cable plant. IP: bind the service to the wwan address, fail a session on purpose, and measure how long the application takes to come back. Mixing the two makes it look like you need a better radio when you actually need a tighter reconnect path on the ARM board.
Start with the modem path. Does the kernel see the module (cdc_mbim, qmi_wwan, mhi, or the vendor driver)? dmesg around insertion should show a wwan or usb0 interface, not a repeating firmware-load failure. ModemManager or a vendor tool should report a packet data session. ip route and resolv.conf need to match what the core actually hands out; a leftover Ethernet default route will black-hole traffic even when the RF link is up. If you use a VLAN or a policy rule to send only some prefixes over the radio, test that table, not just ping from the box.
Next, measure application recovery separately from radio attach. A brief beam switch or handover may take tens of milliseconds on the air interface and seconds in userspace if TCP connections die and the client waits on its own timeout. Capture timestamps for: modem attach, interface UP, default route installed, first successful DNS, first successful TCP handshake. Those four numbers usually explain the “RF is fine, UX is not” reports.
Keep RF and IP acceptance tests apart. RF: RSRP/SINR/BLER under the real antenna and cable plant. IP: bind the service to the wwan address, fail a session on purpose, and measure how long the application takes to come back. Mixing the two makes it look like you need a better radio when you actually need a tighter reconnect path on the ARM board.
