7 Commits

Include renames

Author	SHA1	Message	Date
jaap-jan	2d95366552	Stop a reconnect dialling a different machine of the same name ... A tab remembered what its host was called and nothing else, and the reconnect under a stopped tab looked the host up by that name: HostFor took the first row in the keychain whose label matched. Nothing in this application stops two hosts being called the same thing — a team's vault beside a personal one makes it ordinary, and "prod-db" is what the database server gets called in both — so the button dialled whichever namesake sat earliest in the list. A dropped session on one machine came back as a live shell on another, with the tab, the address and the status bar all still naming the first. There was nothing on screen to read the substitution off. The name match was not an oversight; it was an argument, written into the remark on HostFor and repeated on RefreshConnectedHosts: a tab outlives the vault that opened it, so it "cannot hold an entity id that would still mean anything after a lock". That is not so. EntityId is the item's own sync identity rather than a reference to a row object, so a vault that is locked and opened again rebuilds every row around the same ids. The one handle that was rejected as too fragile to survive a lock is the handle that survives it. So the id now travels with the connection. ConnectionAttemptEventArgs and TerminalSessionEventArgs carry it, taken from ConnectionTarget.HostId, which the connect path has had all along for the log; TerminalTabViewModel keeps it; and HostFor matches on it. A host renamed since the tab opened is found too, which a name match by definition cannot. Null is not missing data — it is the whole of what makes a typed-in address different, and it is why such a tab is refused a reconnect rather than offered one that would dial a stranger sharing its name. Three other lookups had grown their own copy of the same match and so had the same fault, where it is read rather than dialled: the green connected dot, which lit on every machine answering to the name and claimed a shell on hosts nobody had connected to; the pinned paths QUICK ACCESS offers, which come from whichever row that same match found; and the sidebar's "Pin folder" and the SFTP tab row, which would have edited and browsed the wrong host. All four now go through HostFor, so "which machine is this tab" has one answer. Both new tests assert on the address actually dialled rather than on anything the tab says about itself. The two rows agree on every string a tab carries, which is exactly why this went unnoticed: a test written against the label would have passed on the day the wrong machine was being opened.	2026-09-14 10:18:58 +02:00
jaap-jan	e2733e5cbc	Notice when a shell ends, say which way it ended, and offer the way back ... A terminal whose machine rebooted stayed green for ever. Not "went stale and recovered late" — for ever: the tab claimed CONNECTED, the elapsed timer went on counting, and the only thing that ever corrected it was closing the application. That is the defect this fixes, and it turned out to be two separate failures wearing one symptom. ◆ THE HANG IS IN SSH.NET, AND KEEP-ALIVE ALONE WOULD NOT HAVE FIXED IT. ShellStream ends a blocked read from exactly two places: its channel being closed, and the session raising Disconnected. A shell that exits gives the first. But Session raises Disconnected from one method only — OnDisconnectReceived, for a server that politely says goodbye — and a socket that simply fails goes down a different path entirely: RaiseError fires the error event, sets the disconnecting flag and disposes the socket, without ever raising Disconnected. So the stream was never disposed, its Monitor.Wait was never pulsed, and the read blocked until the process ended. The transport was gone, the client knew the transport was gone, and nothing woke the one thread that was waiting. That is why the first attempt at a test for this sat at thirty seconds and failed. Both halves are needed and neither is sufficient: - Keep-alive makes the failure HAPPEN. An idle SSH session is a socket nobody writes to, and TCP has no way to discover that the far end has gone without writing to it — nothing was asked, so nothing could fail. Thirty seconds, matching OpenSSH's own ServerAliveInterval examples. It is the write that matters and not a reply: SSH_MSG_IGNORE need not be answered, so this is traffic rather than a heartbeat with a deadline, and there is no timeout invented here to be wrong about a slow link. - Disposing the stream from the error handler makes it ARRIVE. Queued to the thread pool and not done inline, which is not tidiness: this runs on SSH.NET's message-listener thread, and closing a channel waits for the server's close — processed by that same thread — so an inline dispose is the listener thread waiting on itself. SFTP gets the keep-alive too. Its operations are request/response and bounded by ConnectionInfo.Timeout already, so it needs no equivalent wake-up. ◆ exit AND reboot ARE TOLD APART BY A LATCH, BECAUSE THE OBVIOUS WAY IS A RACE. Wait for the read to end and then ask whether the transport is still up, and against a real server the answer is wrong about half the time: this was the only channel on the connection, so sshd hangs up a millisecond after closing it. By the time anything could ask, the transport is gone either way — and a poll would report every ordinary `exit` as a dropped connection. So ISshShellSession.TransportFailure is set at the moment SSH.NET raises the failure, which its own ordering puts strictly before the disconnect that wakes the read. A read that has just returned zero consults a settled value: set if the transport failed, still null if the remote merely closed the channel. The pump turns that into a TerminalSessionOutcome — RemoteClosed, ConnectionLost, ClosedLocally — carried on SessionEnded, which used to hand over a session id and nothing else. A subscriber cannot work this out afterwards; by the time it hears, there is no transport left to interrogate. Deliberately no fourth value for "the remote rebooted". Nothing on the wire distinguishes a reboot from a cable being pulled, and a name this client cannot check would be a guess dressed as a fact. ◆ WHAT IS DRAWN, AND WHY IT IS NOT DRAWN OVER THE PANE. The status bar says DISCONNECTED or SHELL EXITED where it used to say NOT CONNECTED for both — a word that is honest about a tab still dialling and useless about one whose shell has stopped. Red for the first and grey for the second: one is a machine that stopped answering and the other is work finished, and crying wolf on the ordinary end of every session is its own bug. The tab strip's dot gains the same fourth state, on both heads. Under the terminal, a strip carrying the reason and two buttons. It takes its own Auto grid row rather than overlaying the renderer, and that is forced rather than chosen: the WebView is a native child view composited above everything Avalonia draws, so the alternative is collapsing the terminal — and the scrollback is precisely what the user wants to read, because the last thing the remote said is usually why it went. terminal.js already writes the same sentence into the pane; this is the copy that does not scroll away. RECONNECT reuses the tab in place, which is what the word means to somebody who pressed it: the terminal they were working in comes back, where it was. It dials through the vault's ordinary connect path, so every refusal — a key that has left the keychain, an unknown host key, a group default that has changed since — is decided in the one place that already decides them; what this adds is which tab the attempt belongs to. The old session is closed as part of it, because a dead shell still holds an authenticated connection this process has stopped reading, and its pane still holds an xterm, a scrollback and a WebGL context, of which a browser hands out about sixteen. Two refusals it makes rather than pretending: a host reached by typing an address has no keychain entry to redial, and one that wants a password typed goes to the keychain with the sheet raised rather than being dialled with an empty box. Both say so on the strip where the button was pressed, not only in the vault's status on a screen that surface is not. TRY AGAIN appears on a refused connection for the same reason, and it is worth as much: the commonest refusal is a host that was not up yet. ◆ WHAT IS ACTUALLY VERIFIED. Two tests against a real sshd in a container. `exit` is reported as the remote closing the session — the one a polling implementation fails, and a fake shell cannot show it because a fake has no server behind it deciding to hang up. And a live shell losing its transport is reported as a lost connection, produced by dialling through a plain TCP relay the test owns and then cutting it; the container is shared by the collection, so killing sshd was never an option. The first draft of that second test used LoopbackProxyTests' SOCKS forward and timed out: disconnecting the carrier of a ForwardedPortDynamic does not close the loopback socket it accepted. Recorded in the test, because it is a property of SSH.NET's forwarder rather than of anything here, and it is not what a dying machine looks like. What no test reproduces is the waiting. A relay that closes sends a FIN, so the socket reports itself at once; a machine switched off sends nothing, and finding that out is the keep-alive's business and the OS's retransmit budget's — neither of which a test can hurry along without a clock this code does not own. A reboot is prompt in practice because the machine comes back and RSTs. Beside those: three pump outcomes, three workspace announcements, and seven shell-flow tests covering the drop, the clean exit, reuse of the tab, retry after a refusal, and both ways a reconnect can honestly come to nothing. Also fixed in passing: SshNetShellSession.IsOpen read ShellStream.CanRead, which is documented as always true — the stream stays readable after disposal so buffered output can be drained — so it had answered "yes" for every shell that ever existed. It reads CanWrite now. And MainWindowViewModel's session- ended handler moved from Dispatcher.UIThread.Post to the injected post delegate, which is what makes any of the shell half testable at all; the remark listing the three unreachable posts is one shorter.	2026-08-24 10:36:15 +02:00
jaap-jan	8a77b7ca68	Say how far a connection has got while it is still being made ... The connecting card set its status string once, when the tab was created, and never touched it again. Every connection therefore looked identical from the outside: one three seconds into a key exchange, one waiting out a fifteen-second timeout against a machine that is asleep, and one that had hung all drew the same "connecting…". The card now draws the five steps of getting there, each lit at the moment the handshake reports reaching it, over an amber track that fills as they finish. ◆ NOTHING ON THE LIST IS INVENTED. Every row changes state because a layer below it said so, at the instant the thing it names actually began. That is the whole reason it is worth showing, and it is why most of this commit is plumbing rather than XAML: there was no progress reporting anywhere in the stack to hook a step list onto, and a card animating plausible progress would have been indistinguishable from one that had stopped receiving any. SshConnectionPhase names four phases and deliberately not more. SSH.NET runs the entire handshake inside one ConnectAsync and raises exactly one event from the middle of it — HostKeyReceived, once the key exchange has produced a key to show — so that event is the only interior moment there is to report. Everything before it is Reaching and everything after it is Authenticating. A fifth phase in that assembly would have to be a timer, so there is not one. OpeningShell is reported by TerminalWorkspace instead, because that is where it happens: the factory's work ends with an authenticated connection, and asking for a pseudo-terminal on one is a separate round trip. The SFTP path passes null — a second connection opened behind an already-open shell has nobody watching a step list for it. The card's fifth step, "Starting the terminal", is the renderer wait and lives in the shell rather than in the SSH assembly, which has never heard of a renderer. On the first connection after a cold start it is a real wait with a real failure mode of its own — a missing WebView2 runtime — so a list that began at "reaching the host" would leave the one wait most likely to hang unnamed. Amber for the step in flight, and that follows the palette's rule rather than bending it. Green is what is true and purple is what you can press; a step still happening is neither, and it is exactly the caveat-worth-reading that amber exists for. Steps behind it go green as they become true. Nothing animates, which is the argument TransfersScreen.axaml already makes for its own track, reaching a screen with far more reason to want a spinner: a spinner is furniture invented to fill a state nobody measured, and these states are measured, so the track fills to what has finished and then waits there. A refusal keeps the step it stopped on, in red, with the ones behind it still green. That is the half a progress bar could not do, and it is the difference between "that host is not there" and "that host is there and would not have me" — a question the reason sentence alone frequently does not settle. The strip's dot goes amber while a tab is connecting, on both heads. It was grey, and so is a tab whose shell has exited: the two states in that strip with the least in common, one worth waiting for and one over. PhoneShell's own comment already recorded half of this — the dot stopped being green before anything had answered — and this is the other half. Progress is raised inline rather than through System.Progress<T>, which captures whatever synchronisation context it was constructed on and posts to it. That reads like a convenience and is really a second place the marshalling decision gets made: silently, differently under a test with no context, and out of order with respect to the failure that follows a phase. The shell marshals once, in one handler, through a new optional post parameter on MainWindowViewModel — the same seam TransfersViewModel already uses, and for the reason its own remark gives. The three Dispatcher.UIThread.Post calls that predate it are the ones this suite's comments record as out of reach; they are left alone rather than swept in here. Both heads draw the list. They differ in one place: Phone.axaml's mono class sets a colour and a size along with the family, so the caption rule names its own family instead of composing the two and asking two rules for one Foreground. The desktop's mono sets the family alone, which is why ConnectingCard does compose them. Each head also gains SHOW LOGS beside the button that gives up — the step list is this attempt and the log is every other one, which is what a connection taking too long actually raises. Seven tests, and the two that matter most run against the container rather than a fake: a real handshake reports its phases in order, and a host-key refusal never claims to have authenticated. A fake asserting what it was written to assert would have established nothing about either. The rest cover the tab advancing while the connection is gated, the step a refusal stops on, and a phase reported after the user has given up on the tab. 1,861 tests, none failing. The Android head's layout is not verified by anything. It compiles, and compiled bindings mean every new binding path resolves, but that project is not in DodoSSH.slnx, there is no test project for it and no device here — so unlike the desktop card, whose shapes the layout harness measures, these rows have not been drawn. Vertical fit is reasoned, not observed.	2026-08-10 15:47:45 +02:00
jaap-jan	9d5ff9f23a	Draw what authenticated, and over what, on the session status bar ... The v5b design's own row: the negotiated cipher, then the host key's algorithm and the name of the key or credential that authenticated, as one mono run beside CONNECTED — on both surfaces, off MainWindowViewModel's surface-aware SessionCipher and SessionIdentityText, the same shape SessionAddress set. The identity's name comes out of TryBuildAuthentication, the one resolution point that always had it in scope and always threw it away; it rides HostAuthentication to the tab and to the SFTP connect alike. Three deviations, recorded in the gaps doc: the algorithm prints as negotiated rather than shortened, the run is plain text because no pin-details modal exists for an open session, and a typed password shows the algorithm alone — there is no item behind the dot. A dead terminal tab keeps its facts for the scrollback still on screen; an SFTP disconnect, with no scrollback, clears them.	2026-08-08 20:54:56 +02:00
jaap-jan	43c939b697	Give the window its v5b chrome and each session surface its own shell	2026-08-08 00:49:59 +02:00
jaap-jan	4300d917a8	Stop making people wait for a handshake, and give the host list a pointer ... Connecting held the vault's busy gate, which meant a window that did nothing visible for as long as a machine took to answer — and against one that is merely asleep, that is the whole timeout. The gate is gone from that one command. A tab now appears in the strip in the same turn as the click, carrying "connecting…" rather than a pane, and the terminal's rectangle draws a card naming the host and the address being dialled. Every other screen stays usable, and two connections can be in flight at once. That splits the vault's one connection event into three, carrying an attempt id, because "which tab is this about" can no longer be answered by "the most recent one". The id also buys the two kinds of not-connecting their different endings: a refusal stays in the strip as a tab holding its reason, since by then the user is quite likely three screens away and a status line they are not looking at is not where a failure should end; a host key question takes the tab away and puts the window back on HOSTS, because the prompt is drawn there and a tab claiming failure would be competing with the thing about to resume it. ConnectAsync takes no CancellationToken any more, and that is load-bearing rather than tidying. A [RelayCommand] over a method that takes one generates a command that cancels the previous execution's token on every invocation — so asking for a second machine silently abandoned the first, measured as the first tab disappearing with "Cancelled." the instant the second was asked for. Giving up on a connection is closing its tab, and a session that lands after that is adopted rather than dropped: a shell running with nothing naming it cannot be closed at all. A tab is marked active on IsShowing rather than IsSelected. The selection survives navigating away — that is what makes the strip a way back to a terminal instead of a way to lose one — so a tab lit while preferences filled the window was a second "you are here" mark pointing at something nobody could see. The nav rail's own entries have always made this distinction. The host list grows the two gestures it looked like it already had. A right click selects the row under the pointer before opening a menu of Connect, Edit and Delete — the menu is on the list rather than in the item template, so its entries are the vault's own commands and not a row's, and it is cancelled outright over a group heading. Dragging a host onto a heading files it there, onto a host files it beside that one, and onto UNGROUPED takes it out of a group; the write is one field of one host through the same repository a save uses, refused while the editor is open because a drop is a gesture on the list and not on a half-typed form. Clicking a result in the palette connects, which is what a list of hosts under a search box looks like it does. It went through the shell's own command, so the pointer and Enter take one path. And the files screen's two pickers followed the vault's lists once, at unlock: a host or a bucket created afterwards could not be picked until the keychain had been locked and opened again, with nothing on screen explaining why the machine plainly in the host list was missing. They follow the collections now, re-finding the selection by id across the rebuild a sync pass causes every minute. 165 shell tests and 69 layout tests green, including the connecting tab, both failure endings, two connections at once, a connection in flight across a lock, and the right click acting on the row under the pointer rather than on the selection. The drag itself is in docs/manual-checks.md with the rest of phase 7 — headless Avalonia has no platform drag, and a test that claimed to have dropped something would pass while confirming nothing.	2026-07-31 22:59:33 +02:00
jaap-jan	fe9d7fc289	Give DodoSSH a phone, and a shared shell for both heads to drive ... The Android head from docs/android-port.md, taken as far as its step 6. Step 3, the spike, is answered and its throwaway screen is gone: libsodium.so and libe_sqlite3.so are both in the arm64 APK, so NSec resolves its native half on Android despite shipping no Android build, and the local cache opens. Two findings the audit could not have had: Avalonia.Controls.WebView only ships net10.0-android36.0, which settles the open "which Android versions" question at targetSdk 36; and Android has blocked cleartext HTTP since API 28, so the terminal renderer needs a network security config scoped to 127.0.0.1 or the WebView loads nothing. DodoSSH.Client.Shell is new and is why the phone can exist: the view models, the terminal renderer files and the palette moved there so both heads drive one state machine and draw from one set of tokens. The desktop head is otherwise untouched and its 144 tests still pass. The platform pieces behind interfaces that already existed: the profile directory from filesDir, a device key wrapped by a StrongBox-backed key that a fingerprint releases, and a foreground service so a shell outliving a vault lock stays true on a platform that stops backgrounded processes. Sign-in is deliberately absent rather than approximated. It needs an app link, because reusing the desktop loopback listener is the attack RFC 8252 section 8.3 names.	2026-07-31 20:58:48 +02:00