open-bamboo-networking: replacing Bambu Studio's closed printer networking layer

What it replaces, and why the drop-in framing matters

open-bamboo-networking is an open source drop-in replacement for the proprietary bambu_networking plugin that Bambu Studio uses to talk to a printer, and the drop-in claim is precise rather than loose.

The project states it is the same dlsym ABI, the same file name and the same install location. That matters because Bambu Studio does not call the printer through a documented protocol API of its own. It dynamically loads a shared library that Studio downloads on first start, a Network Plugin, and the plugin's exported symbols are the interface. Replacing the library is therefore a much smaller intervention than replacing Studio, and it also means the replacement inherits whatever the studio side of the interface expects, including its version handling.

The problem being solved is described with unusual bluntness. Bambu Studio is called an excellent open source slicer, but every piece of code that actually talks to a Bambu Lab printer, meaning LAN discovery, MQTT telemetry, file transfer, camera, OTA and cloud, lives in a closed-source shared library, libbambu_networking.so, shipped as a Network Plugin that Studio downloads on first start. The README is careful to say there is nothing inherently wrong with a cloud product, and that the problem is the implementation.

Three specific complaints are listed. The stock plugin ships an unaligned atomic that triggers the kernel's split_lock detector on every modern Intel CPU, so startup stalls for 25 to 60 seconds while the kernel walks each trap, and every Device tab click hits it again, with the workaround of sysctl kernel.split_lock_mitigate=0 degrading system-wide performance and still misbehaving in LAN-only mode. There is no ARM or non-x86_64 build, so the plugin is published for x86_64 only and cannot be used on a Raspberry Pi or an Ampere workstation even though the rest of Studio builds cleanly. And there is cloud chatter on every action even in LAN-only mode, because the plugin keeps reaching out to api.bambulab.com and MakerWorld for bind status and task metadata, which adds latency, creates a hard dependency on the account infrastructure being up, and produces a surveillance footprint many users did not opt in to.

The first complaint has been reported to Bambu over a year ago and is still open as an issue on the BambuStudio repository.

The project is written in C++, the last push was on 2026-10-21, and the releases are v2.2.0 on 2026-09-24, v2.1.0 on 2026-09-10 and v2.0.1 on 2026-08-18.

The three complaints and what the replacement does instead

Each of the three problems has a corresponding change in the replacement, and it is worth reading them together because the design follows directly from the complaints.

The split_lock stall is addressed by shipping an aligned-atomic-clean build. The stock plugin's atomic instruction sequence is what the kernel's split_lock detector traps on, and the kernel responds to each trap by walking mitigations, which is why startup takes 25 to 60 seconds on a modern Intel CPU. A build that does not use the offending sequence does not trigger the detector, so the walk never happens. That is a performance property of the compiled code rather than a configuration change, which is why the sysctl workaround is described as degrading the whole system for a problem that only affects one library.

The architecture gap is addressed by building for more targets. The project adds Linux aarch64 and Windows ARM64 on top of the x86_64 and x64 builds, and the supported platform list marks Linux x86_64, Linux aarch64 and Windows x64 as primary targets with Windows ARM64, macOS ARM64 and macOS x64 as experimental. The README notes that Windows ARM64 is experimental with no video, and all of these are built and smoke-tested in CI for every supported ABI.

The cloud chatter is addressed by making LAN the default. The replacement is LAN-first by default, with block_cloud = 1, meaning the cloud is only contacted for sign-in and preset sync and the rest goes straight to the printer. The cloud path still exists for when you deliberately opt in, through a documented option that runs without Developer Mode.

The three changes together describe a library that behaves the way a local network device driver should, and that is a different proposition from the stock plugin even when the stock plugin is not broken.

Where the protocol knowledge came from, and what the research directory holds

Reverse engineering a printer protocol is the honest description of how this project was built, and the README is clear about the sources.

Protocol knowledge comes from OpenBambuAPI and from the reference implementations in bambulabs_api and ha_bambu_lab, and everything else is reverse-engineered from MITM captures of the stock plugin. The MITM in the middle is the notable detail, since it means the protocol details were observed on the wire rather than guessed from a binary.

Beyond that, there is a research directory whose index collects everything the author was able to establish about how the stock network plugin is integrated, validated and invoked, including the full C ABI and related wire behaviour. That is a reference document in its own right, and it is the piece that makes the replacement possible for anyone else.

The repository layout supports that picture. There is a research/ directory, a NETWORK_PLUGIN.md file, a STATUS.md, BUILDING.md, and a stubs/ directory, which is presumably where the exported symbols are declared so the compiler can check the ABI matches what Studio expects. There is a src/ directory, include/ for public headers, tests/, a tools/ directory, a packaging/ directory, and a scripts/ directory.

There is also a CMakeLists.txt, a vcpkg.json for dependency management, a configure script and a configure.ps1 for Windows, and a Makefile that exists purely to make the build feel conventional.

The last point deserves a mention because it is a small kindness to anyone arriving at a C++ project with expectations set by other C++ projects. The Makefile is described as a thin wrapper around CMake so the usual configure and make and make install sequence works, with every target shelling out to cmake and nothing else going on.

Building it, and the configure wrapper that does the work

The build is CMake, and the Makefile in front of it is a convenience layer that the README describes in unusually honest terms.

The Makefile is a thin wrapper around CMake so the usual configure, make and make install dance works, and every target there just shells out to cmake. It includes a config.mk if one exists, computes the job count from nproc with a fallback of 2, and defines all, build, configure, reconfigure, install, uninstall, test, clean, distclean and help.

There is a nicety in the build rule. If you run make before configure, it auto-configures with default flags, and it says so out loud: Makefile: no build tree at build, running ./configure with defaults. Users that want a specific prefix or flags are pointed at running ./configure themselves, with the options printed by ./configure --help. That avoids the usual failure mode where a new contributor types make, gets a confusing error, and gives up.

The install target does two things rather than one. It runs the cmake install step, and the description of the target says it installs into the configured prefix and patch, with the second word cut off in the visible text. The uninstall target is careful, and the care is worth noting: it checks for the install manifest, and if it exists it removes the files listed in it, and if it does not exist it says so and tells you to run make install first. The distclean target removes the build directory and config.mk.

The test target runs ctest against the build directory with the output-on-failure flag, so a failing test prints its output rather than just a pass or fail summary.

The build itself is CMake with a cmake/ directory for modules and a vcpkg.json for dependencies, and the presence of a stubs/ directory alongside it is the practical shape of an ABI compatibility project: you declare what you export so the compiler can tell you when you have changed a signature that Studio depends on.

Installing on the three platforms, and the interim builds

Every release and interim archive ships with an interactive installer, so you do not need to build anything to use the project. You download the archive for your platform, unpack it and run the bundled installer.

The table of platforms and installers is short:

| Platform | Archive | Installer | | --- | --- | --- | | Linux (x86_64 / aarch64) | `obn-linux-*.tar.gz` | `chmod +x install.sh && ./install.sh` | | Windows (x64 / ARM64) | `obn-windows-*.zip` | double-click `install.bat`, or `.\install.ps1` in PowerShell | | macOS (Apple Silicon / Intel) | `obn-macos-*.tar.gz` | double-click `install.command` in Finder, or `./install.sh` |

One instruction sits next to the table and matters: close the slicer before running the installer. That is because the installer has to replace a library that Studio has loaded, and replacing a loaded shared library on a running process is the kind of operation that behaves differently on each operating system. After installing you launch the slicer again and, optionally, tune the plugin through the obn.conf configuration file.

There are two download channels, and the README is careful to distinguish them. Stable releases are on GitHub Releases, described as tested and tagged versions recommended for general use. Interim builds are on GitHub Pages, automatically built from the latest commit on the main branch, and the warning about them is explicit: they may include new features and bug fixes ahead of the next release, but they can also be unstable, contain incomplete functionality, or introduce breaking changes that will be revised before the next stable release. Use them if you want the newest code and are comfortable reporting issues.

That is a sensible two-tier scheme for a project that has no formal release engineering, and it puts the choice squarely with the user rather than hiding the risk.

One binary for two slicers, and the difference between the targets

The supported slicers section makes a distinction that matters more than it first appears.

The same plugin binary drives both Bambu Studio and Orca Slicer, because they consume the same C ABI, and the installer handles the per-client conventions for you. But they are not equal targets.

Bambu Studio is the primary target, and the distinction is spelled out in terms of process. Development and testing happen there first, and every feature is verified against Studio. The supported ABI series is a long list of Studio versions, each given as a version number with a wildcard for the build suffix, running through the 02.03 series to 02.05, 02.06, 02.07 and 02.08 in the visible text.

The Orca Slicer situation is not detailed in the visible portion of the README, and the table of contents shows that the documentation has sections on what works and what does not, with a summary of what is not implemented, followed by more detail broken into basics that are model-independent, printing, camera liveview and file browser, and the status or device tab. The existence of a model-independent section in that breakdown is itself informative, since it implies some behaviour varies by printer model.

There is also a dedicated section on cloud sign-in in Developer or LAN-only mode, and the two installation options are named after that distinction. Option A is Developer Mode, and Option B is cloud mode without Developer Mode, which is the route for people who want cloud preset sync without the rest of the Studio sign-in flow.

The project also asks for support in unusually direct terms, saying it has been built entirely through the author's enthusiasm and a large personal investment of time, effort and financial resources, and asking readers to consider supporting further development.

For a project of this kind that request is not incidental. A closed-source component that blocks a slicer on ARM hardware and stalls for a minute on modern Intel CPUs is exactly the kind of thing a maintainer ends up replacing in their spare time, and the replacement then has to be kept in step with a vendor's own updates.

Editorial conclusion

Adopt open-bamboo-networking if you run Bambu Studio or Orca Slicer and want the printer networking layer to be open, buildable on ARM, and quiet on the network. Do not adopt it expecting the project to be a supported Bambu Lab product, because it is a third party replacement maintained on enthusiasm, and check the research notes and the known issues before you install it over a working setup. Before you run the installer, close the slicer, and after you install, read obn.conf and the block_cloud setting, since the default behaviour changes what leaves your machine.

Frequently asked questions

Official sources

1. ClusterM/open-bamboo-networking on GitHub
2. Issues
3. README
4. Releases