| Firmware base & current version (Klipper fork / Marlin fork / proprietary) | Vendor fork of Klipper (+ Moonraker + Fluidd) on embedded Linux, with a separate Elegoo touchscreen firmware and a separate STM32 MCU firmware. Config examined: Current configuration version: V1.6, Date: 2024-6-24 inside the firmware 1.1.3.2 package. Release history for ribbon-cable Pro units: 1.1.2.28 -> 1.1.2.41 -> 1.1.2.53 (2023-12-15) -> 1.1.3.1 (2024-07-05) -> 1.1.3.2 (2024-10-30). Screen firmware versioned separately (1.2.14, 1.2.21). Type-C units run a different line - 1.3.1.2 observed | 1 source |
|---|
| Source code availability (repos, GPL compliance status, last update date) | Source now published but incomplete, and it arrived very late. github.com/elegooofficial/Neptune4 was created 2025-12-17 (~2 years 4 months after launch), last pushed 2026-07-29, 4.5 MB, containing klipper/ and moonraker/. The repository has no LICENSE file (license: null via the GitHub API), although the vendored klipper/COPYING is present. Verified gaps between the published source and the shipped product: the stock printer.cfg requires [gcode_shell_command] and calls clear_last_file, but neither exists anywhere in the published klippy/; the [include plr.cfg] file is not in the repo; the config/ directory contains example configs only for the Neptune 2 and Neptune 3 Pro, not the Neptune 4 family; and the update package ships a closed binary c_helper.so (302 KB) with no corresponding source. Prior status: Klipper maintainer Sineos, September 2023: "I did not find any released sources for these modifications -> Elegoo is in violation of the GPL" | 1 source |
|---|
| Root/SSH access: possible? official or community method | Yes. SSH over Ethernet with default credentials user mks / password makerbase; also a serial console on the front USB-C at 1,500,000 baud. Community-documented, not officially supported | 1 source |
|---|
| Moonraker / Mainsail / Fluidd or other open API available (stock vs after mods)? | Fluidd + Moonraker are present and reachable on the stock machine over LAN at http://<printer-ip> - no mods needed. The manual documents browsing to the IP in Chrome for movement control, temperature, console, fans/output, printer limits and a task list. Elegoo's own wiki instructs users to edit printer.cfg from Fluidd's Configuration menu. Mainsail is not stock (added by OpenNept4une). Caveat: Elegoo forbids user-initiated Klipper/Moonraker/Fluidd updates | 1 source |
|---|
| Notable community firmware/mods (names, repos, what they add) | OpenNept4une (OpenNeptune3D) - full "de-Elegoo": custom Armbian 25.11 trixie / Linux 6.16.12, Klipper v0.13, all Elegoo services removed, simplified printer.cfg, KAMP adaptive meshing, screws_tilt_adjust, axis_twist_compensation, firmware_retraction, host/MCU temperature reporting, improved mainboard fan control, display_connector for the stock touchscreen, mjpg-streamer webcam script, Orca profiles, easy MCU flashing, USB-Wi-Fi support. mairyj/Neptune-4-Series - archived official firmware + per-motor printer.cfg variants + French video tutorials + Pico/FYSETC input-shaper kit (PIS.cfg + klipper.uf2) + Obico and webcam guides. Hardware mods: Micro Swiss FlowTech all-metal hotend, MGN9H X-axis and dual-Y linear-rail kits, eMMC upgrade, E1-driver independent dual Z | 2 sources |
|---|
| Firmware update mechanism (OTA/USB) & update cadence history | Depends on which variant you own, and the dossier's original flat "no OTA" was wrong for the machine now sold. Ribbon-cable units: USB flash drive only, no OTA (firmware-verified below). Type-C units: Elegoo advertises OTA. The live us.elegoo.com listing — the only place this printer is still sold new, and it sells only the Type-C variant (A4) — carries a variant note verbatim *"Note : This is the Type-C version with OTA updates. Please make sure any parts you buy are compatible with this model."* plus a dedicated feature panel headed "OTA Firmware Upgrade": *"Keep your machine at its peak with seamless OTA updates that deliver new features and performance enhancements the moment they're ready."* (re-fetched 2026-08-19; the older, out-of-stock elegoo.com global listing contains no OTA mention anywhere, consistent with OTA being a Type-C-era addition). No OTA payload, changelog or client for the Type-C line was obtained, so the mechanism, transport and rollback behaviour are. For the ribbon-cable machine the USB flow is as follows: copy an ELEGOO_UPDATE_DIR folder to a cleared USB stick and boot; screen and MCU firmware update separately; a distinct "fix pack" must be applied first if coming from below 1.1.2.53, and applying it wipes the local task list. Firmware must match both the printhead cable type and (ribbon-cable units) the stepper-motor current variant. Cadence: 5 releases across 2023-09 -> 2024-10, then nothing for ribbon-cable units. A downgrade-protection compatibility check was added in 1.1.3.1 | 2 sources |
|---|
| G-code flavor & notable custom G-codes/macros | Klipper G-code with Marlin-compatibility overrides. Elegoo-specific commands compiled into toolhead.py/fan.py: PRINT_MODE SET=0/1/2 (Normal/Silent/Berserk - rewrites elegoo_conf.ini, changes max_velocity/max_accel/max_accel_to_decel and toggles spreadCycle), FAN_MODE SET=0/1/2, MKS_M106. Macro overrides in printer.cfg: M104/M109 (clamped 300 C), M140/M190/M191 (clamped 110 C, all three drive both bed zones), M141 (outer zone heater_bed1 ONLY), M17/M84 (per-axis enable/disable), M106 (fan-mode duty clamp), M300 (beeper on PA2), m600 (-> PAUSE), G29 (36-point mesh + re-home + park centre), G31 (clear PLR), FLASHLIGHT_ON/OFF/SWITCH, MODLELIGHT_ON/OFF/SWITCH, PRINT_START/PRINT_END/CANCEL_PRINT/PAUSE/RESUME, RESUME_INTERRUPTED, save_last_file/clear_last_file, LOG_Z. [gcode_arcs] resolution: 0.1 and [exclude_object] are enabled stock | 1 source- .../ELEGOO_UPDATE_DIR/printer.cfg lines 556-773 (all macros); M104 637-647, M109 649-660, M191 663-674, M190 676-688, M140 690-701, M141 703-712, m600 719-724, M106 726-7 · 2026-08 · local
|
|---|
| Root shell: exact method (official setting toggle / vendor-documented / community exploit / none). Is root persistent across OTA firmware updates, or wiped each update? | Not an official feature; no vendor toggle. Two community routes: (1) SSH as user mks over Ethernet on the stock image, then sudo (see N11); (2) serial console on the front USB-C at 1,500,000 baud (fallback 115200). True root login is not documented; privilege escalation is via sudo. On OTA persistence: THE QUESTION IS LIVE AND UNANSWERED This row previously read "not applicable in the usual sense - there is no OTA". That is wrong for the only variant still sold: Elegoo advertises "seamless OTA updates" for the Type-C version on the live product page (see N6, re-fetched 2026-08-19). Since the checklist gates on *"Is root persistent across OTA firmware updates, or wiped each update?"*, the honest answer for a 2026 buyer is, and it is the single biggest unresolved risk to this buyer's requirement — an OTA channel is precisely what silently reverts an on-device tailscaled install, and no OTA payload, changelog or client for the Type-C line was obtained. For ribbon-cable units the picture is the documented one: updates are USB-flash ELEGOO_UPDATE_DIR payloads that overwrite specific files, and extra_update.tar demonstrably ships /etc/fstab and /etc/init.d/taskset-client.sh as root-owned members, so an update *can* overwrite system files outside /home/mks. Elegoo additionally publishes "Image Installation Methods", i.e. a full-image reflash that wipes everything. Whether an update disables SSH or resets the password: - no changelog entry and no community report addresses it | 3 sources |
|---|
| Userland: OS base (Debian/Ubuntu/Buildroot/OpenWrt/busybox-only), package manager present (`apt`/`opkg`/`ipkg`/none), CPU architecture (armv7 / aarch64 / mips / x86), and free space on the writable partition. A busybox/no-apt rootfs with a few MB free is a red flag — say so. | Arch: arm64 / aarch64 - hard-verified: the Armbian board family for this board is BOARDFAMILY="rockchip64" and rockchip64_common.inc line 10 sets ARCH=arm64; SoC is RK3328 (quad Cortex-A53). OS base: Debian-family. Stock: the update package ships a.deb (ELEGOO_APP_factory.deb) and SysV-style /etc/init.d/ scripts, and the vendor's own paths (/home/mks/, /home/mks/Desktop/) indicate a desktop-flavoured Armbian/Debian build - but the exact stock release and whether apt is usable is, never published and not verified here. Community image: Armbian 25.11 "trixie", Linux 6.16.12, with apt and sudo and armbian-config all confirmed working. Storage: 8 GB eMMC (community-reported); free space on the writable partition is the red flag - the sibling Neptune 4 Max is reported at ~1.8 GB free with a low-disk warning at 1 GB, which is why the standard community mod is a 32 GB eMMC swap | 3 sources |
|---|
| Native Tailscale feasibility: can `tailscaled` run persistently on-device? Cite concrete evidence — community guides, wiki entries, forum posts, or repos of people actually doing it on THIS model. Note whether it needs `/dev/net/tun` (kernel TUN support) and whether the kernel provides it, plus whether userspace-networking mode is the only option. Distinguish "someone did it" from "should theoretically work." | Kernel prerequisites VERIFIED PRESENT; nobody has been found who has actually done it on this model. Evidence, from the kernel configs that build the community image for this exact board: CONFIG_TUN=y in OpenNept4une's own userpatches/linux-rockchip64-current.config (built into the kernel, so /dev/net/tun exists without loading a module) and CONFIG_TUN=m in the upstream config/kernel/linux-rockchip64-current.config; plus CONFIG_WIREGUARD=m, CONFIG_NF_TABLES=m, CONFIG_IP_NF_IPTABLES=m, CONFIG_VETH=m, CONFIG_OVERLAY_FS=y. With aarch64 + Debian + apt + systemd + TUN + nftables, tailscaled in normal (kernel-networking) mode should run natively; userspace-networking mode is not forced. What is NOT established: (a) no guide, wiki page, forum post, issue or repo was found of anyone running Tailscale on a Neptune 4/4 Pro - searched repeatedly; (b) the stock Elegoo kernel's TUN support is (its kernel config is not published and lives only inside a binary image, which was not extracted per resource policy). So: "should work, prerequisites proven, on the community image" - explicitly NOT "someone did it" | 2 sources |
|---|
| SSH daemon: present by default or must be installed/enabled? Default credentials if documented. Does an OTA update disable it or reset the password? | Community consensus: sshd is reachable on the stock image over Ethernet with mks / makerbase, and no vendor documentation of any kind confirms or denies it. The username mks is firmware-proven (every path in the shipped update package is under /home/mks/, and extra_update.tar members are owned mks/mks); the password makerbase is not - it appears in community write-ups, and the OpenNept4une wiki presents mks/makerbase in the context of its own image, so applying it to stock is an inference that multiple third parties assert but no primary source establishes. Elegoo publishes no SSH instructions, no credential list, and no way to change or disable it from the UI. Whether an update disables SSH or resets the password: | 3 sources |
|---|
| Filesystem persistence: is the rootfs read-only or overlay-mounted? Do user-installed binaries and init/systemd services survive reboot and survive firmware updates? Is there a supported place to persist customizations? | Writable ext4 rootfs on eMMC - not read-only, not overlay-protected. Direct evidence: the stock design writes state to plain files at runtime ([save_variables] filename = /home/mks/klipper_config/saved_variables.cfg, and PRINT_MODE rewrites elegoo_conf.ini in place), which is only possible on a writable rootfs; the community image runs apt install and persistent systemd units. So user-installed binaries and services survive reboot. They do not reliably survive vendor maintenance: a USB update overwrites named files anywhere on disk (extra_update.tar carries root-owned /etc/fstab and /etc/init.d/taskset-client.sh), the pre-1.1.2.53 "fix pack" deletes the local task list by design, and Elegoo's documented recovery path is a full image reflash. There is no vendor-supported place to persist customisations - no /opt convention, no user-data partition, no documented exclusion list. CONFIG_OVERLAY_FS=y exists in the kernel but nothing in stock or community configuration mounts the rootfs as an overlay | 1 source |
|---|