Summary of "Remote Access using IP KVMs! Full Comparison JetKVM vs NanoKVM vs Comet vs PiKVM"

Summary — Remote Access IP‑KVM comparison

Devices compared: JetKVM (JKVM) vs Nano KVM (Cyped) vs GL.iNet Comet vs PiKVM (PyCast board used in tests).

What these devices do (common capabilities)

Capture HDMI output so you can view a remote PC’s screen over LAN/Internet.
Act as a USB gadget device: keyboard and mouse emulation; virtual media (USB/CD) for mounting ISOs to reinstall/repair OS.
Offer web UIs / WebRTC (DTLS) video and cloud relay options. Some support Power over Ethernet (PoE) or can be powered from the target PC’s USB.

Devices tested

JetKVM (JKVM)
- Paid Kickstarter product, metal case, mini‑HDMI, USB‑C HID/power to target, RJ45 Ethernet.
- Open‑source (GPLv2) with active fixes. Includes touchscreen and virtual‑media features/extensions.
GL.iNet Comet
- Compact KVM from GL.iNet; eMMC internal storage (advertised 8GB), HDMI + USB data.
- Required external power in these tests. Early firmware was unfinished.
Cyped (Nano) KVM
- Small device based on RISC‑V board with small SD card; HDMI capture, Ethernet, USB emulation and front‑panel status screen.
- Earlier builds had major security and stability issues.
PiKVM (PyCast board used in tests)
- Open‑source PiKVM project; flexible hardware options (Raspberry Pi + capture dongles up to rack solutions).
- Mature software but more of a DIY/project than a consumer appliance.

Test approach (high level)

Updated firmware to latest available and performed factory resets where possible.
Ran a series of tests:
- UI/functionality overview
- BIOS/virtual‑media test (mount ISO, boot installer)
- Image upload performance
- Boot latency from mounted image
- Packet captures to inspect network/telemetry behavior and IPv6 behavior
- Quick audit of open‑source repos/security fixes since earlier reviews

Key findings — functionality and UX

All four devices provide basic remote KVM (screen + HID) and present virtual media, but behavior and performance vary substantially.
Virtual media modes differ:
- URL/stream (partial HTTP) vs upload to local storage. Partial streaming can start faster, but may be slower overall depending on implementation.
Power behavior:
- Some devices can be powered from the target PC’s USB, but many systems don’t output USB power consistently across power states. This can cause reboots or connectivity issues.
- JetKVM historically provided a USB power splitter to mitigate this.
Feature set:
- PiKVM offers the most features and flexibility (OCR, paste, scripting, recording) and has the most mature software base. It’s positioned as a project/platform rather than a polished appliance.

Measured performance (BIOS / image upload and boot)

Upload time (copying an ISO from local machine to device storage):
- JetKVM: 9 min 05 s (best)
- PiKVM: 13 min 10 s
- GL.iNet Comet: 16 min 08 s
- Nano KVM: 69 minutes (worst; no progress bar; extremely slow)
Time from mounting image to reaching installer on target (boot time):
- PiKVM: 1 min 37 s (fastest)
- JetKVM: 1 min 40 s (very close)
- Nano KVM: 2 min 29 s (slower)
- GL.iNet Comet: DNF — failed to boot the ISO in the test (insufficient usable storage + very slow eMMC behavior)

Hardware / storage issues observed

GL.iNet Comet
- eMMC advertised as 8GB but usable space was <6GB. Could not reliably host a modern desktop ISO.
- Very slow read performance; TLS CPU load combined with slow MMC made transfers and boots slow or fail.
Nano KVM
- SD card is replaceable but buried under internal components — replacement requires partial disassembly.
- USB copy mode (mounting the device as a USB drive) worked as an alternative.
JetKVM
- Included mini‑HDMI cable; straightforward hardware experience and stable power/operation in tests.
PiKVM
- Supports PoE on some boards and easy microSD access.

Network / telemetry / security analysis (packet capture)

Method: packet captures with a MikroTik Hex S router to inspect outbound connections (MDNS/LLMNR, DHCP, NTP, STUN, cloud services).
Common behaviors:
- Devices publish MDNS/LLMNR, perform DHCP, and often use WebRTC/DTLS for video streams.
JetKVM
- Uses DTLS/WebRTC for video (encrypted). Cloud paths use TLS.
- Earlier local web UI initially used HTTP; vendor has been moving endpoints toward HTTPS.
- Had an earlier IPv6 binding bug (loopback not up) which was later fixed.
GL.iNet Comet
- Reached out to multiple NTP and STUN servers and several third‑party domains — sometimes excessive (7+ NTP servers observed).
- Initially used a PyKVM/Ganis backend without clear disclosure. Repo publication later looked like large “dump” commits rather than a transparent development history.
- When forced to IPv6 only, many extra outbound queries stopped and the web UI still worked.
Nano KVM
- Historically downloaded a per‑device shared object from vendor server and executed it as root without proper validation (this was later removed/fixed).
- Other earlier issues: default SSH account (root:root), SSH exposed by default, Tailscale enabled IP forwarding by default. Vendor has since:
  - Disabled tailscale by default
  - Disabled default SSH (now opt‑in)
  - Removed proprietary per‑device binary dependency
  - Fixed DNS bugs and other items
- Still exhibited flaky behavior in tests (required reboots).
- WebRTC/DTLS video worked and could operate over IPv6.
PiKVM
- Mature, well‑audited open‑source project. WebRTC/DTLS and IPv6 behaved well and transparently.

Open‑source compliance and codebase observations

JetKVM
- Published code (kernel/build root, native components) under GPLv2. Addressed earlier issues, improved build reproducibility and exposed native app sources for touchscreen/C parts.
Nano KVM
- Vendor addressed the most serious security issues (removed per‑device binary fetching, disabled default SSH). Fixes were incremental and took months, but major problems were resolved.
GL.iNet Comet
- Initially shipped with a PyKVM backend without providing source changes. Later published a repo, but history shows large dumps instead of incremental commits. The reviewer notes this as poor practice and potentially non‑transparent.
PiKVM
- Fully open source and actively developed. Many vendors build on it, but it remains more of a DIY platform than a finished consumer appliance.

Stability and usability notes

Nano KVM
- Tends to be flaky and sometimes needs a local reboot to recover. Long ISO upload times and UI lacked progress reporting.
JetKVM
- Felt most responsive in cursor tracking and had better virtual‑media ergonomics.
GL.iNet Comet
- Multiple practical problems: insufficient usable storage, slow eMMC, long/failed ISO boots. Not recommended for practical admin use without confirmed hardware/firmware fixes.
PiKVM
- Best for feature completeness and flexibility if you’re comfortable with DIY and customization. Less appealing if you want an appliance that “just works” out of the box.

Reviewer’s practical recommendations / conclusions

Best overall as a consumer appliance: JetKVM — stable, responsive, open source, active fixes. Best for hobbyists/lab builders: PiKVM — maximum flexibility, open‑source project. Nano KVM: improved substantially and acceptable if JetKVM isn’t available, but watch for flaky behavior and long image downloads. GL.iNet Comet: not recommended based on these tests — verify firmware/storage updates first if you consider it.

Notes: JetKVM may have shipping/availability issues to some countries (tariff/fulfillment complications mentioned).

Guides, tests and tutorials referenced (by chapter in video)

Overview/demo of each unit’s UI and features (virtual keyboard, OCR, paste, virtual media).
BIOS test: mounting ISO as virtual media and booting to installer.
Image upload performance test (local upload and URL download methods).
Boot time benchmark (image mounted → installer).
Packet capture / telemetry analysis (device outbound behavior, IPv4 vs IPv6, WebRTC/DTLS).
Open‑source/code audit follow‑up (verification of previously reported fixes, repo availability and build reproducibility).
Earlier PiKVM tutorial (Raspberry Pi + raw HDMI capture and an 8‑port rack mount KVM build).

Important security takeaways

Check default credentials and whether SSH is enabled by default. Prefer devices that require key‑based SSH or force first‑boot password changes.
Inspect whether the vendor performs remote code fetching (per‑device binaries) and whether code signatures/validation are used. Fetching and executing unsigned code is a critical risk — Nano KVM had this and removed it.
Watch for devices that reach out to many external servers (NTP, STUN, telemetry). Prefer vendors that use TLS for control/video paths and disclose what servers are contacted.
Prefer open source or transparent vendors where you can inspect code changes and verify fixes.

Tools used in testing

MikroTik Hex S for test LAN, PoE and packet captures.
Packet captures analyzed for MDNS/LLMNR, DHCP, NTP, STUN and HTTP/HTTPS/DTLS flows.

Main speakers / sources

Video host / reviewer (channel owner; conducted hands‑on tests, security analysis and open‑source audits).
Device vendors/projects: JetKVM team, GL.iNet (Comet), Cyped / Nano KVM, PiKVM project (PyCast board / PyKVM).
Test infra: MikroTik Hex S (used for packet capture and routing).

If you want specific chapter timestamps (BIOS test, upload/boot times, packet capture, open‑source audit), the video includes chapter markers referenced in the description.