sam/dev_arc_aws
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update RDP handoff doc: connection now succeeds, blank screen is new symptom

Browse source
This commit is contained in:
Claude 2026-06-22 18:30:12 +00:00
parent d1fefd3a63
commit a47583a8e4
No known key found for this signature in database
1 changed files with 28 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
docs/rdp-debug-handoff.md
View file

@ -143,22 +143,44 @@ machine's logs turned out to be wrong once the other machine's logs were checked
`grdctl status --show-credentials` now consistently shows `Unit status: active`, `grdctl status --show-credentials` now consistently shows `Unit status: active`,
`RDP: Status: enabled`, `Username: sam`, `Password: happy2026`. `RDP: Status: enabled`, `Username: sam`, `Password: happy2026`.
## The unresolved problem ## UPDATE: connection now succeeds, but screen is blank
Despite all of the above being fixed and verified consistent, connecting through ArchNest The "Server refused connection (wrong security type?)" failure described below has since
(browser → backend → guacd → Fedora VM) still fails with: been resolved (cause not fully pinned down before it started working — likely one of the
cert/credential/security-mode fixes finally lined up). The ArchNest Guacamole viewer now
shows **"Connected"** in the top-right status, with the session named `Fedora-WS` — but the
viewport is **solid black**, no desktop content ever renders. Confirmed NOT a lock-screen
issue (user confirmed gnome is unlocked). `journalctl --user -u gnome-remote-desktop -n 50`
checked at the time showed the daemon has been running continuously since 10:34:45 with no
crash (unlike earlier attempts where "RDP server started" was immediately followed by
"RDP server stopped") — so this is a *different* failure mode than the original refusal:
**negotiation and session start now succeed, but no frame data is ever captured/sent.**
This is strong evidence for the EGL/Mesa/Zink theory below — the daemon accepts the
connection and starts the RDP server but apparently cannot capture real screen content,
producing a connected-but-blank session instead of crashing outright. Next diagnostic step
(not yet completed): tail `journalctl --user -u gnome-remote-desktop -f` AND
`journalctl --user -f | grep -i -E "pipewire|portal|screencast|monitor"` *live*, while the
black-screen session is open and the user clicks/moves the mouse in the Guacamole viewport,
to catch any PipeWire/portal screencast error that doesn't appear in the regular unit log.
## Original unresolved problem (superseded by the above, kept for history)
Connecting through ArchNest (browser → backend → guacd → Fedora VM) used to fail outright
with:
``` ```
Error: Server refused connection (wrong security type?) Error: Server refused connection (wrong security type?)
``` ```
This has been tried with `security` set to `any`, `nla`, `tls`, and `rdp` — **identical This was tried with `security` set to `any`, `nla`, `tls`, and `rdp` — **identical
failure every time**, regardless of mode. That's suspicious: if it were a genuine security failure every time**, regardless of mode. That's suspicious: if it were a genuine security
negotiation mismatch, different modes should fail differently (or some should succeed). negotiation mismatch, different modes should fail differently (or some should succeed).
The fact that they all fail identically suggests the real failure might be happening The fact that they all failed identically suggested the real failure might be happening
*after* security negotiation succeeds — e.g. at session-start/framebuffer-creation time — *after* security negotiation succeeds — e.g. at session-start/framebuffer-creation time —
and FreeRDP's client-side error message is a generic/misleading bucket for "the connection and FreeRDP's client-side error message is a generic/misleading bucket for "the connection
didn't complete," not literally a security-type mismatch. didn't complete," not literally a security-type mismatch. This symptom is no longer
reproducing (see UPDATE above) — leave this section for historical context only.
### Open theory (unconfirmed) ### Open theory (unconfirmed)