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.