TikMan v2.1.8
Everything since 2.0.2, and nearly all of it came from using the thing: a device that wouldn't update,
a list full of rows that could never do anything, a marker that marked nothing, and a summary that
claimed work it hadn't done.
🔓 The update check falls back to SSH
A broken RouterOS HTTPS handshake is the whole reason TikMan's SSH read path exists — monitoring,
topology, Wi-Fi names, logs and the config export all fall back to it. The update check was the one
that didn't, so on exactly the devices that need the fallback most it failed at the first step and
took the whole run down with it:
Update check failed: The SSL connection could not be established.
→ An existing connection was forcibly closed by the remote host.
Setting the channel and checking now go HTTPS REST → SSH CLI, like everything else. Not via the
plain-HTTP fallback, even when you've allowed it: this writes a setting with your password attached.
🧭 Backup and updates: only what can actually happen
- Pick what to save. Two tickboxes — configuration (
.rsc) and binary backup (.backup) — and
each device gets the intersection of what you asked for and what it can produce. Start is only
offered when that intersection isn't empty, so a disabled button tells you there's nothing to do
before the click instead of the log telling you after. - The lists hold what qualifies. The update list used to contain every device TikMan knows —
printers, IoT plugs, the lot. Updating is/system package update; those rows existed to be
scrolled past. Devices that can't be backed up grey out and say why on hover. - The runs count honestly. "2 updated" for a run that installed one update and left the other
device alone — because it was already current — is now "1 updated, 1 skipped, 0 failed". A backup
where the config saved but the binary didn't is partial, not saved: it was rounding to "done". - The binary backup is no longer silent. It was fetched and never mentioned: the log named the
.rscand the.backupsat next to it on disk, unlogged. Only failures were ever logged. - The folder is asked for every time. For something that writes files, confirming where they go
beats silently reusing a folder from an hour ago. - Both lists lead with type and vendor, and their columns share the width instead of being fixed
and clipped. Per-device progress lives in the log, which scrolls and can be read afterwards.
⬆️ The update channel says what you'd get
The channel dropdown reads 2026-06-02 7.23.1 (stable) — version and release date, in the place
where you choose, so the separate "Latest" column is gone. That's a read from MikroTik's public
server: it touches no device. Your device's channel is still only ever written when you install, and
the log now says which way it went (channel switched: "stable" → "long-term").
The bulk-update warning claimed edge-devices-first as if it were a law. It's a rule of thumb, and
CAPsMAN inverts it when the controller is set to carry its CAPs along (upgrade-policy). Both the
warning and the README say so now.
🚀 A calmer app
- The update check runs first, before anything touches the network, and the download gets a real
progress window instead of a status line that looked like a hang. - "No scan at startup" now means it. TikMan still queried every device on launch to refresh
monitoring — exactly what the setting turns off. Restored devices stay grey ("not checked yet")
instead of showing a green dot nobody verified. - The bottom bar is a banner that wraps, because most of what TikMan has to say is a sentence.
- The detail pane folds away with a chevron, and doesn't appear at all under the backup and update
assistants, which bring their own device list.
🐛 A PC running Spotify is not a speaker
mDNS was trusted ahead of everything, so any workstation with Spotify open — it advertises
_spotify-connect._tcp so you can cast to it — was filed as a "speaker", ahead of the RDP/WMI+SMB
signature that exists to say "this is a PC". An mDNS model is what a device is; an mDNS service is
only what happens to be running. Real speakers are unaffected.
Downloads
| File | Platform | Runtime |
|---|---|---|
TikMan-2.1.8-win-x64.exe |
Intel/AMD 64-bit | none (self-contained, ~68 MB) |
TikMan-2.1.8-win-x64-fdd.exe |
Intel/AMD 64-bit | .NET 10 Desktop Runtime (~12 MB) |
TikMan-2.1.8-win-arm64.exe |
ARM64 | none (self-contained, ~65 MB) |
TikMan-2.1.8-win-arm64-fdd.exe |
ARM64 | .NET 10 Desktop Runtime (~12 MB) |
When in doubt, take the self-contained build (-x64 or -arm64). The exes are unsigned, so Windows
SmartScreen shows an "unknown publisher" notice on first run — More info → Run anyway.