VNC, Telnet, Serial & File Transfer

Purpose

Connect to a VNC server or macOS Screen Sharing / Apple Remote Desktop, with a fully Rust-native RFB decoder built in — no external VNC viewer.

How to do it

1. 1Click VNC in the toolbar, then + Add VNC Host .
2. 2Fill in a Name , Host/IP , and Port (5900 default).
3. 3For macOS Screen Sharing / Apple Remote Desktop specifically, also fill in the macOS username field — leave it blank for plain Linux/Windows VNC servers.
4. 4Enter the Password (the VNC password, or the macOS account's password for Screen Sharing) — Save password in OS keystore is checked by default.
5. 5Click Add & Connect — like RDP (and unlike SSH), this both saves the host and opens the session in one click.

How to verify

1. 1Click Add & Connect and expect the remote screen to render within a few seconds, with the mouse cursor tracking your movements when you move the mouse over the session.
2. 2Type a few characters into any remote text field and confirm they appear correctly (not delayed, not duplicated) — this exercises the keyboard-input path separately from mouse.
3. 3If you control the remote display's resolution, change it while connected (e.g. resize the remote desktop) and confirm the MangoSSH session picks up the new size within a second or two rather than freezing or disconnecting.

Troubleshooting

• "Authentication failed" — for Apple Remote Desktop, confirm you're using the macOS account's actual login password, not a separate "VNC password" some Mac setups configure independently — try both if the first fails.
• Connects but screen is garbled/wrong colors — the server may be using an encoding MangoSSH's decoder set (Raw, CopyRect, RRE, HexTile, Tight subset, ZRLE) doesn't fully cover; check the VNC server's own encoding configuration if available.

Purpose

Connect to legacy network gear, BBSes, or public Telnet services that still only speak the original protocol — full RFC 854/1073/1091 option negotiation, not just a raw TCP passthrough.

How to do it

1. 1Open More → Telnet .
2. 2Enter a host (an IP, a hostname, or a well-known public Telnet service for testing, e.g. a MUD or BBS address) and connect.

How to verify

1. 1Enter a known-good test target (e.g. a public MUD or BBS address) and connect.
   • Expect a readable banner/login prompt to appear within a couple of seconds, with box-drawing characters and colors (if the service uses them) rendering correctly rather than as raw escape codes — this is what proves option negotiation actually completed, not just a bare TCP connect.
2. 2Type a command the service recognizes and press Enter; confirm the response comes back promptly with correct line wrapping.

Troubleshooting

• Garbled output / control characters visible as text — the remote service may expect a specific terminal type MangoSSH's negotiation doesn't match; this is more common with very old BBS software than modern network gear.
• Connects but nothing happens — some Telnet-only network devices require a specific line-ending or a wake-up keypress before showing their first prompt; this is device behavior, not a MangoSSH issue.

Purpose

Talk directly to a device over a physical serial (COM) port — the standard way to reach a switch/router/appliance's console port, or a headless embedded board, before it has any network configuration at all.

How to do it

1. 1Open More → Serial .
2. 2Pick the COM Port from the detected list, and set Baud , Data bits , and Parity to match the device's documented console settings (commonly 9600 8N1 for network gear).
3. 3Connect — a terminal opens bound directly to that serial port.

How to verify

1. 1Pick the correct COM port and the device's documented baud/data-bits/parity, connect, then press Enter a couple of times.
   • Expect a login prompt or command-line banner to appear within a second — a completely blank screen after several Enter presses means the baud rate (most likely) or port is wrong, not that the device is unresponsive.
2. 2Type a harmless command the device supports (e.g. show version on network gear) and confirm the output is readable text, not repeating garbage characters.

Troubleshooting

• Garbled text — almost always a baud-rate mismatch; try the device's documented rate, or the common defaults (9600, 19200, 38400, 115200) one at a time.
• COM port doesn't appear in the list — a driver issue for that USB-serial adapter, or another program already has the port open exclusively; close other terminal/serial tools and re-scan.

Purpose

Browse and transfer files against classic FTP servers, and against SSH servers via SFTP — either a standalone quick client, or a two-pane browser bound to an already-open SSH session.

How to do it

1. 1FTP : Toolbar → More → (FTP, if present) or its own entry — fill in Host, Port (21 default), User (blank defaults to anonymous ), Password, and leave Passive (PASV) checked unless the server specifically requires active mode.
2. 2Quick SFTP : Toolbar → SFTP — a standalone SFTP client independent of any saved SSH host, for a one-off file operation.
3. 3In-session SFTP browser : from an already-connected SSH session, open the Files view — a two-pane local « remote browser bound to that live session (reuses the session's own authentication, nothing to re-enter).

How to verify

1. 1Connect and browse to a directory you know has files in it.
   • Expect real filenames, sizes, and modified dates to render — an empty or malformed listing on a connection that otherwise "succeeded" is the classic sign of an active/passive mode mismatch (see below).
2. 2Upload a small test file from your local machine.
   • Confirm it appears in the remote listing with the correct size (not 0 bytes, not truncated).
3. 3Download that same file back to a different local folder and compare file sizes (or checksums, e.g. certutil -hashfile on Windows / shasum on macOS/Linux) between the original and the round-tripped copy — they should match exactly.

Troubleshooting

• FTP connects but directory listing hangs/fails — toggle Passive mode; this is the single most common FTP connectivity issue, driven by firewall/NAT interaction with active-mode's server-initiated data connection.
• SFTP "Permission denied" on a specific file/folder — a server-side filesystem permission issue for the authenticated user, not an MangoSSH/SFTP-protocol problem.

Purpose

Serve firmware/config files to network gear that only speaks TFTP (the standard pattern for switch/router firmware upgrades and config backup/restore), and/or pull or push files from an existing TFTP server as a client.

How to do it

1. 1Open More → Servers (or the dedicated TFTP entry) and check Run TFTP server .
2. 2Set the Root directory (files are served from here) and Port (69 default).
   • Check Allow incoming writes (PUT) only if you want devices to be able to upload files to you — leave it unchecked for a read-only firmware-serving setup.
3. 3As a client : enter the target TFTP Server and Port , pick a Direction (GET to download, PUT to upload), fill in the Remote file name and the Local file path, and click Start transfer .

How to verify

1. 1Server : place a small test file in the Root directory, check Run TFTP server, and note the port.
   • From a second machine (or a CLI TFTP client on the same machine), run tftp -i < your-IP > GET testfile.bin .
   • Expect the file to download successfully and the Activity log panel to show a success line for that transfer.
2. 2With "Allow incoming writes" left UNCHECKED, attempt a PUT from that same external client.
   • Expect it to be refused — this confirms the default is genuinely read-only, not just documented as such.
3. 3Client : point the Server field at a real TFTP server, pick GET, fill in a known remote filename and a local save path, click Start transfer.
   • Expect the Activity log to show a success line and the local file to appear at the path you specified, with a matching size to the source.

Troubleshooting

• Device can't see the TFTP server — TFTP has no discovery; confirm the device is configured with your machine's exact IP and the port you set (commonly 69, sometimes blocked by a local firewall — allow it explicitly).
• PUT (upload) rejected — Allow incoming writes must be checked server-side; it's off by default deliberately, since an open-write TFTP server is a real, well-known risk on untrusted networks.

Purpose

Pick a context/namespace/pod and drop into a live shell inside a pod, or tail its logs — driving your own already-installed kubectl binary rather than reimplementing the Kubernetes API.

How to do it

1. 1Open More → Kubectl .
2. 2Optionally set a Kubeconfig path (defaults to ~/.kube/config ), pick a Context (refresh re-scans available contexts), then a Namespace and Pod (refresh re-lists pods for the selected namespace).
3. 3Optionally set a specific Container (blank = the pod's default container) and a Command (defaults to /bin/sh ).
4. 4Click Connect to open an xterm.js session running kubectl exec -it , or use the log-tail action to stream kubectl logs -f instead.

How to verify

1. 1Pick a context, namespace, and pod you know is running, leave Command as /bin/sh , click Connect.
   • Expect an xterm.js shell prompt to open within a couple of seconds.
2. 2Run hostname and ls / inside that shell.
   • Expect the hostname to match the pod's own name (not your local machine's) and to see the pod's actual root filesystem — this is what proves you're really inside the container.
3. 3Separately, trigger the log-tail action against the same pod.
   • Expect existing log lines to appear immediately, and NEW lines to appear live as soon as the application inside the pod produces them (e.g. trigger a request against that pod's service from elsewhere and watch the corresponding log line arrive within a second or two).

Troubleshooting

• Context/pod lists are empty — confirm kubectl itself is installed, on PATH, and already configured (run kubectl get pods by hand first) — MangoSSH is driving your existing kubectl, not a bundled one.
• "exec" fails but the pod is clearly running — the pod's default shell may not be /bin/sh (e.g. a distroless image); try setting Command to something the image actually has, or use the log-tail path instead if a shell genuinely isn't available.

Purpose

Get a plain local shell (PowerShell/cmd on Windows, your default shell on macOS/Linux) inside the same MangoSSH window as everything else — no separate terminal app needed for quick local commands alongside your remote sessions.

How to do it

1. 1Open More → Terminal .
2. 2A local shell session opens immediately — there's no connect form, since there's nothing remote to configure.

How to verify

1. 1Open More → Terminal.
   • Expect a shell prompt to appear within a second, with no host/connect form ever shown first.
2. 2Run whoami (or echo $USER on macOS/Linux).
   • Expect your own local account name — not a remote username, and not blank.
3. 3Run cd to your home directory and list files ( dir or ls ).
   • Expect to see your actual local files, confirming this is a real local shell, not a sandboxed/fake one.

Troubleshooting

• Blank terminal that never shows a prompt — this was a known early race condition (session ID not yet assigned when the shell tried to attach); if it recurs, restarting the app once and reopening Terminal resolves it.