Remote Support¶
A robot stands in a corridor two hundred kilometres away and does something nobody expected. Someone has to look at it without driving there — and the same person must not be able to make it drive. Those two sentences are the whole design problem, and everything on this page follows from holding both at once.
1. The decision, and the option we did not take¶
The obvious answer is a remote desktop agent on the control computer. It is the answer most houses already know, and it was seriously considered.
| Remote desktop agent on the Gateway | AWS IoT Secure Tunneling — chosen | |
|---|---|---|
| Direction of the connection | Outbound, to the vendor's relay | Outbound, to the region our own cloud already runs in |
| Ports | 5938 TCP, falling back to 443 and then 80 | 443 TCP, already open for telemetry |
| What the technician gets | The screen of the computer, and with it everything the logged-in user can do | Three named local services, over a byte stream, nothing else |
| Can the technician drive the robot? | Yes. Nothing prevents opening the operator surface and pressing drive | No. The full-scope port is on a deny list, and the tunnel only ever sees a read-only socket |
| Who can open a session | Anyone holding the agent's credentials | Only an identity in our own AWS account, and every session is recorded |
| Third party in the data path | The vendor's relay infrastructure | The same account and region that already holds the device's certificate |
| Extra software on the device | A full agent with a service and a UI stack | mosquitto_sub, jq and AWS's localproxy |
The decisive row is the fourth. A remote desktop that shows the operator surface makes the
promise "the robot only moves when somebody is standing next to it" untrue, and that
promise is part of what the product is sold on. It cannot be restored by a house rule,
because over TCP a request from a tunnel and a request from the tablet are
indistinguishable: both arrive from 127.0.0.1.
The port facts, for the firewall request that was already drafted
A remote desktop agent of the usual kind wants 5938 TCP outbound to its vendor's master and router hosts, falls back to 443, and as a last resort to 80. If your IT department has already been asked for those, the request can be withdrawn: the design below needs 443 only, to the destination that is on the list anyway.
2. How a session actually runs¶
Six steps, and the device is the one that connects in every one of them.
- A technician opens a tunnel in our AWS account for one serial number, naming which of the three services it may carry and for how long.
- AWS publishes a notification on a reserved topic of exactly that device.
- The Gateway is already listening there — outbound, 443, ALPN
x-amzn-mqtt-ca, with its own device certificate. It checks three things before doing anything: that it is being asked to be the destination of the tunnel and not its source, that the region is the one our cloud runs in, and that the named services exist in its own target list. - It starts the local proxy for at most the configured duration. The access token is passed as an environment variable, never as a command-line argument — on the process list it would otherwise be readable by anyone logged into the Gateway.
- The technician reaches the read-only socket. Nothing else.
- The session ends by itself. Two independent clocks close it: the one AWS set when opening the tunnel, and the Gateway's own. If one fails, the other still ends the session.
Start and end of every session are written twice: into a local line file that survives a network outage, and into the cloud, where it becomes the record that can be shown to the customer. If the cloud write fails the line is buffered and sent later — the same principle that governs telemetry, because a remote-access record that quietly goes missing is worse than none.
3. Why the technician cannot drive¶
Because the server listens twice.
| Socket | Bound to | Scope |
|---|---|---|
| 5173 | all interfaces | The full operator surface, for the tablet at the robot |
| 5174 | 127.0.0.1, not configurable |
Read-only. This, and only this, is what the tunnel may see |
Which socket a request arrived on is not read from a header — a header is set by the caller, and in the case this is built for the caller is the adversary. It comes from the operating system: each socket runs its requests inside its own context, and the server reads that.
On the read-only socket two independent barriers apply. The socket itself refuses anything
that is not GET or HEAD, before the application is asked at all. And inside the
application an allow list decides which paths exist there — not a deny list, because a
deny list forgets the endpoint somebody adds next week, and that would be exactly the open
one. An allow list forgets it in the safe direction: a new endpoint is closed until a person
enters it and thinks about it while doing so.
Measured on 27.08.2026¶
Both sockets of the current build, against the chassis simulator. The left column is what the tablet sees, the right what the tunnel sees.
| Request | Tablet socket | Read-only socket |
|---|---|---|
GET / — the operator surface |
200 | 200 |
GET /service — the technician page |
200 | 200 |
GET /api/nachbarn — the other robots |
200 | 200 |
GET /api/chassis/device/info — chassis state |
200 | 200 |
GET /api/chassis/maps/11.png — the floor plan as an image |
200 | 403 |
GET /api/medien — the media library |
200 | 403 |
GET /api/chatbot/config — the voice service |
409 | 403 |
GET /api/uiot/status — the building module |
409 | 403 |
GET /anmeldung — the sign-in form |
200 | 403 |
POST /api/touren/lauf — start a tour |
400 | 403 |
POST /api/anmeldung — sign in |
409 | 403 |
DELETE /api/anmeldung — sign out |
200 | 403 |
MEASURED Four of those refusals deserve their reason in one line each:
- The floor plan as an image is what a hospital does not want leaving the building. The map as data stays readable — the technician still sees points, zones and the robot's position, which is what a diagnosis needs.
- The media library carries files up to 200 MB with no diagnostic value, and a tunnel is a narrow pipe.
- The voice service and the building module are proxies to foreign devices in the customer's network. Through the tunnel they would be a stepping stone into the rest of that network — precisely what the customer's IT department was promised would not exist.
- The sign-in form is absent so that nobody types a device password into a path where it is not end-to-end encrypted: the tunnel is TLS to AWS and TLS onwards, not TLS through.
The honest consequence, which belongs in the same breath: because signing in is a write, the remote technician has no session, and the endpoints behind the door answer 401 rather than with data. That is the design working as intended, not a defect. Changing it means deciding on a separate read-only session for the tunnel — a decision for a person, not for a configuration file.
4. What the customer's IT department is told¶
Remote access to the robot is established by the robot itself, outbound, on port 443, and only while a session is running. Nothing has to be opened towards the robot. During a session, three services on the robot's own control computer are reachable, all of them read-only; neither the drive system nor your remaining network can be reached. Start and end of every session are recorded and can be shown to you. If you want the access gone, disconnect the control computer — there is no second way in that anybody could have forgotten.
That last sentence is the one worth keeping. A remote access path that can only be turned off by us is a path a customer has to trust; one that ends when a cable is pulled is a path they can verify.
5. State, honestly¶
| Piece | State |
|---|---|
| The device-side tunnel service, its target-list check, the session record | Written, reviewed, not yet run on hardware |
| The second, read-only socket in the operator surface | Built and measured on 27.08.2026 — the table in section 3 is that measurement |
| The tunnel itself against a real device | OPEN — needs a Gateway with a certificate and one deliberate session |
| Which of our people may open a session | OPEN — belongs into the cloud roles, not into this page |