serversdown/seismo-relay
1
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

docs(series4): no Micromate has ever been observed calling home

Browse Source 
Correcting an implication I made.  The 72 ach_inbound_* sessions in
bridges/captures/ are MiniMate Plus, and I framed the Series III ACH setup as
though it transfers to a Micromate.  It is not known to.

What we actually have for Series IV is prior, not observation:

- THOR manual 6.2 and the firmware's own strings
  (CMD_EXIT_CALL_HOME_DELETE_EVENTS_START_MONITORING, "Call Home Deleting
  Events") say the unit dials in and waits to be told what to do -- server-driven,
  the same shape as Series III's pull model.
- UM12947's 0x2C dial string reads literally "RADIO RING", which is modem ANSWER
  vocabulary rather than a destination.  With the RV50 debug string
  ATQ1 ATE0 ATS0=2 ... RADIO RING -- ATS0=2 being auto-answer-after-2-rings --
  that reads as the unit arranging to ACCEPT calls, i.e. the call-UP path.  Which
  argues the ACH destination lives in the modem, as it does for series III.

If both priors hold, mm_ach_server.py is just MicromateClient on an inbound
socket and the unknown evaporates.  But there is a specific failure mode worth
naming in advance:

THE MICROMATE DEMONSTRABLY TALKS AT TO ITS MODEM.  If it drives an AT dial for
call-home, that exchange happens on the SERIAL LINK and a TCP listener sees none
of it.  So the first experiment has an AMBIGUOUS NULL -- no connection could mean
the trigger did not fire, or that the interesting part is invisible from the
network.  The escalation is a serial-level capture between unit and modem, not
more fiddling with the server.

Recorded in both the protocol reference and the server's own docstring, so
whoever runs the experiment reads the caveat before being puzzled by a silence.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
This commit is contained in:
serversdown
2026-10-03 01:54:31 -04:00
co-authored by Claude Opus 5
parent 4579896b6d
commit bdf4909d2a
2 changed files with 53 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
bridges/mm_ach_server.py
+28 -5
View File
@@ -12,11 +12,34 @@ and an inbound session is the worst place to break that.
What this is for
----------------
The inbound call-home session is the last unmapped part of the Series IV
protocol — and it may well not be a separate protocol at all. Series III's
answer, from 72 captured sessions, is that the unit **dials in and then waits**:
the server runs the ordinary handshake and drives with the ordinary command set.
If Series IV behaves the same way, this file is just `MicromateClient` attached
to an inbound socket, and the "unknown" evaporates.
protocol.
⚠ **No Micromate has ever been observed calling home.** The 72 `ach_inbound_*`
sessions in `bridges/captures/` are **MiniMate Plus**, and the Series III setup
does not automatically transfer. What we have for Series IV is prior, not
observation:
* The THOR manual §6.2 and the firmware's own strings
(`CMD_EXIT_CALL_HOME_DELETE_EVENTS_START_MONITORING`, `Call Home Deleting
Events`) say the unit dials in and then **waits to be told what to do** —
server-driven, the same shape as Series III's pull model.
* UM12947's `0x2C` dial string reads literally `"RADIO RING"`, which is modem
*answer* vocabulary rather than a destination. With the RV50 debug string
`ATQ1 ATE0 ATS0=2 … RADIO RING` — `ATS0=2` being auto-answer-after-2-rings —
that reads as the unit configuring the modem to **accept** calls, i.e. the
call-*up* path. Which suggests the ACH destination lives in the **modem**,
as it does for Series III.
**If both priors hold, this file is just `MicromateClient` on an inbound socket
and the unknown evaporates.** But there is a specific way it can fail:
⚠ **Those AT strings prove the Micromate talks to the modem over serial.** If it
drives an AT dial for call-home, that exchange happens on the **serial link**,
where a TCP listener sees nothing whatsoever. So a null result here is
informative but ambiguous — it means *either* the trigger did not fire *or* the
interesting part is happening somewhere this tool cannot watch. **If nothing
arrives, the next step is a serial-level capture between the unit and the modem,
not more fiddling with this server.**
**The one question that matters is push vs pull**, and it cannot be answered by
sniffing — only by connecting and keeping quiet. So this server **says nothing
docs/micromate_protocol_reference.md
+25
View File
@@ -2256,6 +2256,31 @@ A server that never issues the delete simply re-reads the same events forever.
`ach_state.json` with `downloaded_keys` / `max_downloaded_key`, and erase as a
separate deliberate step. No new mechanism is needed for Series IV.
> #### ⚠ But no Micromate has ever been observed calling home (noted 2026-10-03)
>
> The 72 `ach_inbound_*` sessions in `bridges/captures/` are **MiniMate Plus**.
> The Series III setup is not known to transfer, and there is a concrete reason
> it might not:
>
> | | Series III (observed, 72 sessions) | Series IV (inferred) |
> |---|---|---|
> | who dials | the **modem** (destination set in ACEmanager) | unknown |
> | the unit's role | passive on serial until the socket exists | sends AT strings to the modem |
> | session | pull — server runs the ordinary command set | pull, per manual §6.2 + firmware strings |
>
> ⚠ **The Micromate demonstrably talks AT to its modem** —
> `ATQ1 ATE0 ATS0=2 … RADIO RING` from the RV50 debug, and `"RADIO RING"` is what
> `0x2C`'s dial-string field actually contains on UM12947. `ATS0=2` is
> auto-answer-after-2-rings, so that exchange is the unit arranging to *accept*
> calls — the call-*up* path — which argues the ACH destination lives in the
> modem after all.
>
> **But if the unit instead drives an AT dial for call-home, that exchange is on
> the serial link and a TCP listener sees none of it.** So the first experiment
> has an ambiguous null: no connection could mean the trigger did not fire, or
> that the interesting part is invisible from the network. The escalation is a
> **serial-level capture between unit and modem**, not more work on the server.
So a homebrew receiver needs: accept the connection, identify the unit, walk the
events (already solved — `0x08`/`0x1E`/`0x0A`/`0x5A`), keep our own high-water
mark, and *optionally* erase. **The erase opcodes are the only genuinely missing