From b8736f4ac390bf2af291f84a41cac9cdca5d9bef Mon Sep 17 00:00:00 2001 From: Achmad Date: Wed, 24 Jun 2026 05:43:53 +0000 Subject: [PATCH] DEPLOY.md: also check what's bound to port 3452 when curl works If something else is also listening on :3452 (a leftover container, a systemd-managed socket, a proxy from an earlier session), the kernel can route new connects to it and that listener may RST. Curl from outside gets a clean response from the real listener; the agent's WS dial lands on the stale one and gets RST. Add ss -tlnp + lsof + systemctl list-sockets to the diagnostic ladder. --- DEPLOY.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/DEPLOY.md b/DEPLOY.md index db7a006..7306988 100644 --- a/DEPLOY.md +++ b/DEPLOY.md @@ -348,3 +348,17 @@ If the journal shows the agent connecting and immediately seeing RST again (a ti ``` Should return HTTP 101 Switching Protocols. If it does, the network is the issue. If it doesn't, the control plane binary has a problem (look at `sdp-control-plane.service` journal for a startup error). + +### Still failing after the curl test? Check what's bound to port 3452 + +The control plane is one listener on port 3452 — if systemd or another process is also bound, the kernel can RST connections to the "wrong" socket. On 186: + +```bash +ssh administrator@172.18.139.186 +sudo ss -tlnp 'sport = :3452' +sudo lsof -i :3452 +sudo systemctl list-sockets --no-legend 2>/dev/null | grep 3452 +exit +``` + +You should see only one listener: `control-plane` PID, IPv6 `*:3452` (dual-stack). If you see anything else — another systemd socket, a leftover container, a proxy — kill it. Then `sudo systemctl restart sdp-control-plane.service` on 186 and try the agent again.