The cable swap alone did not fix it. A probe immediately after fitting a genuine
FTDI cable (lsusb 0403:6001, FT232) returned the same "connected, no reply".
A COLD BOOT of the unit was also required -- power button held five seconds
through the two-stage battery-disconnect prompt, powered back up with the cable
already attached. THOR connected the moment it finished booting, and an
independent probe returned UM12947, idle, over cellular.
So the Micromate's USB host does not rescan on hot-swap: it enumerates that port
at boot and, having once failed to identify a device, does not try again.
Changing the cable is a power-cycle operation -- and anyone swapping one in the
field who probes immediately will conclude the new cable is faulty too. Full
chain: an FTDI or CDC-ACM cable, AND a cold boot with it attached.
SEPARATELY CONFIRMED, by accident: these modems bridge ONE TCP session to serial
at a time. With THOR connected, the probe got "TCP ok, NO REPLY"; with THOR
disconnected and nothing else changed, the same probe returned the serial number.
The PAD accepts a second connection and then never forwards it -- it does not
refuse and does not close.
That makes "connected but no reply" ambiguous between a broken serial path and
somebody else already holding the unit, and mm_probe reported only the former --
which would push a diagnosis in exactly the wrong direction, on the very fault we
spent two days chasing. Its verdict now names both causes, tells you to
eliminate contention first, and includes the cable-chipset and cold-boot steps.
Recorded as an SFM design constraint: our receiver and THOR cannot both hold a
unit, and during any migration both will exist. "Another client holds this unit"
has to be a distinct visible state.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
THOR reports every failed connection as "disconnected" and nothing more. That
one word covers at least four distinct faults with four different fixes, and
telling them apart is the difference between a modem reboot and a site visit.
Nobody had a way to do that during the 2026-09-22 outage, which is the actual gap
that incident exposed -- not a missing THOR feature, but a missing tool.
connection refused something answered and said no -- wrong port, or the
modem refusing a further session
connect timed out nothing answered -- trusted-IP whitelist, firewall, or
the modem is off the network. A whitelist DISCARDS
rather than refuses, so this is its signature
connected, no reply the MODEM answered but the unit did not. TCP is fine;
the modem is not forwarding to serial. This is what a
wedged transparent-TCP session looks like, and it is
the case THOR cannot distinguish from the others
replied the unit is alive; the fault is upstream software
Each verdict prints what to try next. The no-reply case points at ACEmanager's
TCP Idle Timeout first, since a stale session holds a single-slot modem's only
connection until that timeout frees it.
--slots N opens N simultaneous connections and reports how many the far end
accepts, which directly tests the single-session hypothesis against a real modem.
Read-only throughout: POLL, SERIAL and the 0x49 state read -- the same three
commands THOR's own connection check uses. Sends the correct per-SUB data
offsets (POLL 0x0030, SERIAL 0x000A, 0x49 0xFFFF); offset 0 returns only the
short probe reply.
Works for both series and says which answered: a Series III reply opens DLE STX,
a Micromate reply opens with a bare STX.
Verified against UM12947 through the bench relay, and against a closed port for
the refused path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
serversdownandClaude Opus 5