GitHub - ClusterM/open-bambu-networking: Open-source drop-in replacement for Bambu Studio's proprietary `bambu_networking` plugin.

Open-source drop-in replacement for Bambu Studio's proprietary bambu_networking plugin.

Table of contents

• Why this project exists
• Supported platforms
• Supported Bambu Studio versions
• Developer Mode requirement
• What works
  • Basics (model-independent)
  • Printing
  • Camera liveview
  • File browser (Device → Files)
  • Status / Device tab
  • Firmware / model-specific fix-ups
  • Platforms
  • Hardware reality (what each model actually does)
  • Model specifics
• Workaround reference
• Cloud sign-in
• What is not implemented
  • MQTT command signing (err_code: 84033543)
  • MakerWorld integration
  • FileTransfer module (ft_* C ABI)
  • PrinterFileSystem (SD/USB browser UI in Studio)
  • TUTK / Agora cloud p2p transports
• Build and install
  • Dependencies (Linux)
  • Video backend
  • Configure, build, install
  • [./configure options](#configure-options)
  • First-time Studio configuration
  • Flatpak problems
• Logging
  • libBambuSource.so logging
• License
• Support the Developer and the Project

Why this project exists

Bambu Studio is an excellent open-source slicer, but every piece of code that actually talks to a Bambu Lab printer — LAN discovery, MQTT telemetry, file transfer, camera, OTA, cloud — lives in a closed-source shared library (libbambu_networking.so, shipped as a "Network Plugin" Studio downloads on first start). There's nothing inherently wrong with a cloud product; the problem is the implementation:

• The stock plugin ships an unaligned atomic that triggers the kernel's split_lock detector on every modern Intel CPU. Startup stalls for 25-60 seconds while the kernel walks each trap; every Device-tab click hits it again. The workaround (sysctl kernel.split_lock_mitigate=0) degrades system-wide performance and still misbehaves in LAN-only mode. Reported to Bambu over a year ago and still open: bambulab/BambuStudio#8605.
• No ARM or non-x86_64 build. The plugin is only published as Linux x86_64 (plus Windows and macOS). You can't use Studio or any third-party tool that reuses the plugin on a Raspberry Pi, an Ampere workstation, or any other aarch64 / riscv host, even though the rest of Studio builds cleanly.
• Cloud chatter on every action, even in LAN-only mode. Even when the printer is sitting on the same subnet as Studio in Developer Mode, the stock plugin keeps reaching out to api.bambulab.com / MakerWorld for things like bind status and task metadata. That's extra latency on every click, a hard dependency on the account infrastructure being up, and a surveillance footprint a lot of users didn't opt in to.

This project is a drop-in replacement for that library: same dlsym ABI, same file name, same install location, but open source, aligned-atomic-clean, cross-architecture-buildable, and strictly LAN-first (the cloud is only ever contacted for sign-in, so that Studio's preset sync works — the rest is straight to the printer).

Protocol knowledge comes from OpenBambuAPI and the reference implementations in bambulabs_api and ha_bambu_lab; everything else is reverse-engineered from MITM captures of the stock plugin.

For the technical reference — how Studio loads, validates and calls the plugin, and the full list of ABI symbols and their semantics — see NETWORK_PLUGIN.md. For a per-function implementation status of this plugin against that ABI, see STATUS.md.

Please note:

This project has been built entirely through the author's enthusiasm, with a tremendous personal investment of time, effort, and financial resources. If this work helps you, please consider supporting its further development in the Support the Developer and the Project section.

Supported platforms

• Linux x86_64 (primary target, gcc 13+/15+, libstdc++new C++11 ABI).
• Linux aarch64 (primary target, cross-compile-friendly, see cmake/toolchains/).

Windows and macOS are architected for but not yet built and tested: the ABI uses std::string/std::map/std::function across the boundary, which means we would need to match MSVC's STL on Windows and Xcode/libc++ on macOS. Studio also enforces a matching code-signing publisher on those OSes unless the user sets ignore_module_cert = 1.

Supported Bambu Studio versions

• Minimum supported: Bambu Studio 02.05.00.xx
• Maximum supported: Bambu Studio 02.06.01.xx

Developer Mode requirement

Recent (2024+) printer firmware cryptographically verifies every MQTT command it receives when the printer is paired with the Bambu cloud. The verification uses a per-installation RSA key that the stock plugin ships as obfuscated data and which we do not reproduce. Symptom on the printer screen when an unsigned command arrives:

MQTT Command verification failed
err_code: 84033543

To use this plugin, put the printer in Developer Mode:

1. On the printer: Gear icon -> Settings -> LAN Only Mode -> enable "LAN Only", "LAN Only liveview" and "Developer mode".
2. In Bambu Studio: Device -> Connect via LAN with access code.

In this mode the printer skips MQTT verification and accepts plain LAN commands. All LAN features of the plugin (discovery, telemetry, printing, filename browsing, file transfer, camera) work normally.

Non-developer / hybrid / cloud-only modes are only partially implemented and remain severely limited: the plugin can still sign you into the cloud, fetch presets, and show telemetry, but you cannot reliably start a print — the printer expects MQTT commands to carry the stock plugin's RSA signature, which we do not ship. Without Developer Mode every print / project_file / similar command is rejected (err_code: 84033543). Fully replicating that signing chain is out of scope for an open-source project. MakerWorld task history is likewise out of scope.

What works

The author only owns a P2S, so the "Tested" column in the table below means "exercised with a real printer"; everything else is reviewed against the stock plugin's disassembly, the OpenBambuAPI protocol notes, and the ha_bambu_lab reference implementation. Most features are protocol-level (same SSDP / LAN MQTT / FTPS on every Bambu printer) so hardware differences only matter for a handful of rows — see "Applies to" for each row and the hardware matrix further down.

Community help is essential. If you use another printer model or CPU architecture, please try the plugin and open an issue on github.com/ClusterM/open-bambu-networking with what works, what fails, and your firmware / OS / Studio version — that is how we turn "not tested" into documented reality. Bug reports, regressions, and small compatibility notes all belong in Issues.

The tables below are a feature-level view. For an ABI-level view — every single function Studio resolves from the plugin, with per-symbol implementation status and notes — see STATUS.md.

Legend:

The Impl column distinguishes:

• Native — the plugin speaks the same wire protocol the stock bambu_networking.so does. Drop-in behaviour.
• Workaround — the plugin reaches the same user-visible outcome over a different transport. Listed individually in Workaround reference below; all of them can be compiled out together with -DOBN_ENABLE_WORKAROUNDS=OFF.
• Passthrough — the plugin just forwards MQTT / REST payloads; Studio does the work.

Basics (model-independent)

Printing

Camera liveview

Camera protocol differs by model (see the hardware matrix). Both paths share the same libBambuSource.so tunnel API towards Studio; the difference is what happens inside.

File browser (Device → Files)

All four operations run in a worker thread inside libBambuSource.so, serviced against FTPS (port 990) on the printer. Same transport for every Bambu LAN firmware, so this row is identical across models except for the storage-root layout (see hardware matrix).

Status / Device tab

Firmware / model-specific fix-ups

Platforms

Hardware reality (what each model actually does)

Use this to figure out which rows above apply to your printer. The plugin doesn't hard-code any of this — it auto-detects storage layout and camera transport at runtime and speaks the right protocol per printer. The table exists only to tell you which cell of the tables above applies.

¹ Specs for newer / not-yet-widely-available models are best-effort from public product pages and Studio's built-in model enum; the protocol parts (camera port, FTPS layout) are auto-detected at runtime, so the plugin itself doesn't rely on the table being exact. Corrections welcome from anyone with the actual hardware.

Model specifics

Storage on the printer depends on the model: X1 / P1P / A1 (and A1 mini) use a microSD slot, while P2S has a USB port instead (no SD slot). The plugin auto-detects which mount is available and uploads to the right path:

• X1 / P1P / A1: FTPS exposes /sdcard/ and (sometimes) /usb/; the ft_* fast-path probes both with CWD and reports whatever answers.
• P2S: FTPS has no /sdcard or /usb subdirectory — the FTPS root is the USB stick, so files sit right at /. The plugin detects this (both probes fail, root is reachable) and still advertises "sdcard" to Studio so the Send-to-Printer radio shows "External Storage"; uploads go to /<dest_name> (no prefix).

There's one more P2S-specific twist: the printer reports home_flag with NO_SDCARD bits because, strictly speaking, it has no SD slot. Studio's DeviceManager parses those bits into DevStorage::SdcardState, which turns the Send button grey and shows a red "Please check the network …" tile in the Device/Storage panel. Since we can write to the USB over FTPS, the plugin rewrites bits 8-9 of home_flag from NO_SDCARD (00) to HAS_SDCARD_NORMAL (01) on every push_status frame. Real error states (ABNORMAL=10, READONLY=11) and printers that already report HAS_SDCARD are passed through unchanged.

⚠️ soft-fail means the step logs a warning and continues with task_id="0". Printing works; the job does not show up in the cloud's job history and the timelapse/record-on-printer cloud flags have no effect. Local print records on the printer itself still work.

Workaround reference

Everything marked Workaround in the table above is a deliberate non-stock path chosen to get a Developer-Mode printer usable without the proprietary secrets the stock plugin carries. All of them are gated behind one CMake flag, -DOBN_ENABLE_WORKAROUNDS (default ON). Build with =OFF if you want a strict drop-in that only exposes the native paths from the "What works" table above — Studio will transparently lose the affected features (Send greys out on P2S, file browser stays empty on Dev-Mode printers, "Print from Device" errors out with "start_sdcard_print disabled", RTSPS liveview refuses to open, etc.), but nothing half-done runs at runtime.

The first five rows are gated by OBN_ENABLE_WORKAROUNDS; the last three — firmware info synthesis, cross-device preset sync, and the thumbnail cover — always run, because they either cannot cause runtime regressions vs. stock behaviour (there is no stock path at all under Developer Mode) or the stock behaviour they replace is silent data loss rather than a graceful degradation. The ft_* fastpath has its own flag because stock-compatible builds may want to keep Send-to-Printer's UI progress working while turning everything else off.

Cloud sign-in

Even though every print path is local, the plugin still implements Bambu's cloud account login. The reason is that Studio's UI and preset machinery are heavily wired to a logged-in user_id: without a session a number of features quietly degrade. With a session they behave as they did under the stock plugin.

What login gives you:

After sign-in, Studio may show a Synchronization dialog asking whether to pull personal data from Bambu Cloud. The stock UI lists exactly three categories — the same ones the account machinery is built around:

1. Process presets (print / process profiles)
2. Filament presets
3. Printer presets (machine profiles)

• User presets sync. On startup Studio calls preset_bundle->load_user_presets(agent->get_user_id(), ...) and scans <config_dir>/user/<uid>/ for the three preset kinds above (plus AMS material mappings and anything else tied to the account). A background worker then pushes each dirty preset to the cloud under /v1/iot-service/api/slicer/setting — POST for new presets, PATCH for edits, DELETE for removals — and periodically lists the server catalogue back via get_setting_list2 to pull in changes made on other devices. Without a session Studio falls back to DEFAULT_USER_FOLDER_NAME and your custom profiles are invisible.
• Avatar and nickname in the sidebar. The "Sign in" button turns into your profile widget.
• Cloud device list / bind status. Studio queries /v1/iot-service/api/user/bind with your accessToken to show which printers are paired with your account. Used for the device picker and the "Bind to cloud" dialog; LAN discovery still works without it.
• Filament CDN metadata. Some OEM filament entries pull extra data (colour swatches, recommended profiles) from authenticated cloud endpoints. Missing these shows up as a generic filament name.

What login does not give you:

• It does not enable MQTT command signing — the printer still refuses unsigned commands outside Developer Mode regardless of who you are signed in as (see MQTT command signing).
• It does not register your prints on MakerWorld. create_task soft-fails (see the table below).
• It does not unlock the TUTK/Agora cloud-p2p transports. Those need a separate proprietary library.

How the flow works:

1. Studio opens the account portal in the system browser or its embedded wxWebView. The URL Studio uses is composed from web_host(region) (which the plugin reports) and a callback query string pointing at http://localhost:<port>/.
2. After the user authenticates, the portal redirects the browser to http://localhost:<port>/?ticket=<T>&redirect_url=.... Studio's in-process HTTP server picks up the ticket.
3. Studio calls into the plugin: bambu_network_get_my_token(ticket) runs POST /v1/user-service/user/ticket/<T>; we get back {accessToken, refreshToken, expiresIn, ...}.
4. Studio then calls bambu_network_get_my_profile → we run GET /v1/user-service/my/profile with Authorization: Bearer ….
5. Studio assembles {"data":{"token":"…","refresh_token":"…", "expires_in":"…","user":{"uid":"…","name":"…", …}}}and feeds it back viabambu_network_change_user. Agent::apply_login_info accepts both that envelope and the raw API shape.
6. The session is persisted to <config_dir>/obn.auth.json with mode 0600. On next Studio start the plugin loads it and reports is_user_login() == true without prompting again. The plugin rotates the access token via POST /v1/user-service/user/refreshtoken as the expiry approaches.
7. Logout (Studio menu → "Log Out") calls bambu_network_user_logout, which clears obn.auth.json and the in-memory session.

Running without sign-in is fully supported: go straight to "Device → Connect via LAN with access code", and LAN printing / camera / discovery / FTPS all work. You'll just lose the Studio features in the second list above.

What is not implemented

These are deliberate scope choices, not bugs. Each one is either out of reach without cryptographic secrets we don't have, or hidden behind a proprietary transport we haven't reversed:

MQTT command signing (err_code: 84033543)

Newer firmware requires every MQTT command sent to the printer to carry a per-installation RSA signature. The stock plugin ships the keys as obfuscated data. Without those, the printer rejects commands with "MQTT Command verification failed" on screen. Workaround: put the printer in Developer Mode (above), which disables verification.

MakerWorld integration

POST /v1/user-service/my/task (create cloud task record) and the related tracking endpoints all require the signing chain above plus client-side certification headers (x-bbl-app-certification-id, x-bbl-device-security-sign) that the stock plugin computes in native code. We log the 40x and continue, so the print itself completes. Scope: out of scope permanently — this is a closed network service.

FileTransfer module (ft_* C ABI)

Used by Studio for the "Send to Printer" dialog (upload without printing), the eMMC pre-flight check in the regular Print job, and a handful of media-ability queries. The proprietary plugin serves these over a port-6000 TLS tunnel with a JSON command framer we haven't reimplemented. See NETWORK_PLUGIN.md § 6.14 for the ABI contract and STATUS.md § 6.14 for the per-symbol status of the two modes below.

We have two modes, toggled at configure time with -DOBN_FT_FTPS_FASTPATH=ON|OFF (default ON):

**OBN_FT_FTPS_FASTPATH=ON (default).** For bambu:///local/* URLs the plugin serves the ABI over the same FTPS connection the print job uses:

• cmd_type=7 (media ability) is answered by probing CWD /sdcard and CWD /usb on the printer. X1/P1P/A1 and first-gen A1 mini have the SD-card mount; P2S has a USB port instead. Printers with both will get both back. If neither path answers but the FTPS login itself succeeded (the P2S case), the fastpath treats the FTPS root as the storage mount and reports ["sdcard"] so Studio's picker lights up. emmc is never reported — on Bambu firmware that storage is for system files, not user uploads.
• cmd_type=5 (upload) runs STOR /<dest_storage>/<dest_name> with byte-level progress forwarded to Studio as {"progress":N} via msg_cb (skipping 99, which Studio reserves as a timeout tripwire). When the tunnel is in root-is-storage mode the STOR target is just /<dest_name>.
• TUTK/Agora URLs still return FT_EIO — we don't speak the cloud p2p transport.

Net effect: the "Send to Printer" dialog walks through the same UI states as with the stock plugin (Reading storage → picker → sending with real % progress), the eMMC pre-flight in the regular Print job gets a clean ["sdcard"] / ["usb"] answer and Studio stops logging a fallback every time.

**OBN_FT_FTPS_FASTPATH=OFF.** Every ft_* entry point is a polite-failure stub that fires its callback synchronously with FT_EIO and a "fall back to FTP" message. Studio's internal fallback kicks in and the 3mf is uploaded through bambu_network_start_send_gcode_to_sdcard, which also uses FTPS. Same file lands in the same place — the UI just skips the media- ability step and the per-percent progress comes from the fallback instead.

Scope: the fastpath is a deliberate shortcut, not a clean reimplementation of the proprietary port-6000 protocol. If you need MakerWorld-style project metadata, eMMC-as-primary-storage, or the "Send to multiple machines" batch UI to work end-to-end, you'll still be limited to what the fallback path supports.

PrinterFileSystem (SD/USB browser UI in Studio)

Studio's MediaFilePanel opens a port-6000 tunnel through libBambuSource.so and then switches it to a CTRL channel via Bambu_StartStreamEx(CTRL_TYPE). From there it sends JSON request/response messages (LIST_INFO, SUB_FILE, FILE_DOWNLOAD, FILE_DEL, REQUEST_MEDIA_ABILITY, TASK_CANCEL) that Studio renders as the Device → Files panel (timelapses, camera recordings, printed models with thumbnails).

libBambuSource.so does not speak the proprietary CTRL wire protocol; instead it runs a worker thread per tunnel that services those JSON requests over FTPS (the same service we use for "Print via LAN" uploads). That gives Studio the full file browser on every printer we can reach over TLS on port 990, regardless of whether the firmware implements the CTRL protocol itself.

Supported operations:

• REQUEST_MEDIA_ABILITY — probe /sdcard and /usb; if neither exists we treat the FTPS root as the storage mount (P2S-style USB-only) and report it as "sdcard" to Studio.
• LIST_INFO — LIST (Bambu firmware does not implement MLSD) on: <prefix>/timelapse/ for the timelapse tab, <prefix>/ipcam/ for the manual video tab, <prefix>/ for the model tab. Files are filtered by extension (.mp4, .3mf, .gcode.3mf).
• SUB_FILE thumbnails — for timelapses we fetch the sidecar .jpg; for .3mf files we download the archive, parse the central directory, and inflate Metadata/plate_1.png (or plate_no_light_1.png) using zlib's raw deflate — no external ZIP dependency.
• FILE_DOWNLOAD — streaming RETR with 256 KB chunks, each chunk delivered as a separate CONTINUE reply so Studio's progress bar updates smoothly. The final reply is SUCCESS.
• FILE_DEL — DELE per path (modern form {"paths":[…]} only; the legacy {"delete":[…]} form isn't used by current Studio releases).
• TASK_CANCEL — marks a sequence number; the worker aborts the relevant multi-chunk response cleanly at the next check point.

FILE_UPLOAD is intentionally not implemented here: Studio's "Send to Printer" dialog uses the separate ft_* ABI (see above), which already has an FTPS fastpath.

For printers whose firmware does send ipcam.file in its MQTT push_status (X1 / P1S class), the plugin passes it through untouched — those printers speak the real CTRL protocol to their stock BambuSource, and we don't want to clobber a capability we don't match exactly.

For printers that don't advertise ipcam.file (P2S, A-series, some firmware revisions) the plugin injects "file":{"local":"local","remote":"none","model_download":"enabled"} into every LAN ipcam block. That's what makes Studio open the port-6000 tunnel in the first place; without it, MediaFilePanel would short-circuit with "Browsing file in storage is not supported in current firmware." and never give us a CTRL channel to service.

Storage root layout:

The P2S variant uses the "FTPS root == USB stick" convention from our ft_* implementation. We re-advertise it as "sdcard" because Studio's storage dropdown treats anything that isn't "emmc" as removable media.

Limitations: Studio still refuses to open the browser in LAN Only Mode for X1/P1S/P2S ("Browsing file in storage is not supported in LAN Only Mode") — that check lives inside Studio itself, ahead of the plugin. Developer Mode (which is what we target anyway) bypasses it.

TUTK / Agora cloud p2p transports

Used by Studio as a fallback when LAN is unavailable and for the X1 family in non-LAN mode. Closed-source proprietary libraries (libBambuTUTK / libBambuAgora) implement them. We don't wrap either. Scope: out of scope — use LAN/Developer Mode instead.

Build and install

Dependencies (Linux)

You need CMake ≥ 3.20, a C++17 compiler, pkg-config, and development headers for everything the project links against:

Note
libcjson-dev and uthash-dev are required for --vendor-mosquitto option only (see below).

Image decode/encode for both the thumbnail letterbox path AND the RTSPS pipeline's per-frame JPEG re-encode are handled by the vendored stb_image / stb_image_write headers under stubs/third_party/, so no libpng-dev / libjpeg-dev is required. We deliberately do not link those libraries into libBambuSource.so — see the comment block at the top of stubs/image_io.hpp for the rationale (mostly: avoiding Wrong JPEG library version: library is 80, caller expects 62 abort()s from libjpeg-turbo when Studio's own image-decoding plugins load under our globally-mapped libjpeg).

One-shot install examples:

# Debian / Ubuntu (default ffmpeg backend)
sudo apt install build-essential cmake pkg-config \
  libmosquitto-dev libcjson-dev uthash-dev libcurl4-openssl-dev libssl-dev zlib1g-dev \
  libavcodec-dev libavutil-dev libswscale-dev

# Fedora (default ffmpeg backend; ffmpeg-free is in the standard repo,
# the full ffmpeg-devel comes from RPM Fusion)
sudo dnf install gcc-c++ cmake pkgconf-pkg-config \
  mosquitto-devel cjson-devel uthash-devel libcurl-devel openssl-devel zlib-devel \
  ffmpeg-free-devel

The none backend has no extra runtime dependency.

Video backend

libBambuSource.so ships an IVideoPipeline abstraction that demuxes RTSP(S) H.264, decodes it, and re-encodes each frame as MJPEG so Studio's media widget on Linux/Windows and wxMediaCtrl2 on macOS both see one wire format regardless of printer model. Pick the implementation at configure time:

The C-ABI consumer sees the same JPEG bytes either way; the backend is only visible in obn-bambusource.log (libav: / rtsp: / h264: line tags) and in the set of shared libraries the dylib pulls in (none, in the FFmpeg case).

No libav linkage at all. With OBN_VIDEO_BACKEND=ffmpeg (the default) libBambuSource.so carries zero DT_NEEDED entries on the libav family and does not dlopen system libav either. Instead, on the first RTSPS pipeline start the plugin resolves the libavcodec / libavutil / libswscale function pointers it needs via dlsym(RTLD_DEFAULT, ...) -- i.e. it binds to whatever copies of those libraries are already in the host process. Bambu Studio's AppImage / macOS bundle DT_NEEDEDs them off the main bambu-studio binary, so they are always already in process by the time our plugin runs.

This is by design. Earlier versions of the plugin tried to dlopen / dlmopen system libavformat as a fallback. That kept failing with undefined symbol av_mastering_display_metadata_alloc_size, version LIBAVUTIL_59 because system libavformat was built against a newer libavutil minor than the AppImage already had loaded -- and glibc's link model deduplicates by SONAME across dlmopen() namespaces, so even an isolated namespace ended up reusing the older libavutil. The reliable fix is to not mix libav copies: use only the set Studio already has loaded (matching minors guaranteed) and implement the RTSP / RTSPS protocol ourselves so we never need libavformat. See stubs/rtsp_client.cpp for the protocol layer and stubs/ffmpeg_dyn.cpp for the loader.

If Studio is built without libavcodec for some reason (theoretical; we have not seen it in the wild), the RTSPS camera widget reports "ffmpeg_dyn: libavcodec is not loaded in this process" in obn-bambusource.log and the rest of the plugin keeps working (MJPG-on-port-6000 path for A1/P1, FTPS file browser, etc.).

The build still uses pkg-config to find the libav headers (we need the type definitions like AVFrame, AVCodecContext, AV_PIX_FMT_YUVJ420P), so libavcodec-dev / libavutil-dev / libswscale-dev are required at compile time. No libavformat-dev is needed -- we wrote the protocol layer ourselves.

Configure, build, install

From the repository root, the usual three commands:

./configure
make
make install

No sudo needed — the default install prefix is inside your home directory.

Important!
If Studio runs in an isolated environment where **libmosquitto is not available or not visible** at runtime (Flatpak, Docker/OCI images, minimal sandboxes), add **--vendor-mosquitto** to ./configure (see the [./configure options](#configure-options) table below).

That's it. ./configure is a thin wrapper around CMake that writes the build tree into build/ and picks sensible defaults for a typical Linux user: install prefix ~/.config/BambuStudio (the same directory Bambu Studio uses), release build. make install then:

1. copies the four shared objects + manifest into that directory:

• ~/.config/BambuStudio/plugins/libbambu_networking.so
• ~/.config/BambuStudio/plugins/libBambuSource.so (stub)
• ~/.config/BambuStudio/plugins/liblive555.so (stub)
• ~/.config/BambuStudio/ota/plugins/network_plugins.json

2. edits ~/.config/BambuStudio/BambuStudio.conf so Studio trusts this plugin and stops trying to re-download its own on every launch — sets "installed_networking": "1" and "update_network_plugin": "false" under the "app" object, with a .obn-bak backup next to the original. This step is skipped when the install prefix is not the default BambuStudio dir (staging trees stay clean), or you can turn it off explicitly with ./configure --no-conf-patch.

make uninstall walks the install manifest and removes whatever was put down; make clean / make distclean drop build artefacts; make test runs the smoke tests via ctest.

./configure options

./configure --help prints the full list; the most useful ones:

./configure --help also lists less common flags (including Mosquitto linking options). Driving CMake directly works the same way; see OBN_* and other cache variables in CMakeLists.txt.

First-time Studio configuration

make install edits ~/.config/BambuStudio/BambuStudio.conf for you on the first run (see the list above). If you skipped that step — or if Studio has never been launched on this machine so the file does not exist yet — add these two keys to the "app" object by hand:

"installed_networking": "1",
"update_network_plugin": "false"

Flatpak problems

Bambu Studio is often installed from Flathub. That layout is workable for this plugin, but the Flatpak sandbox and runtime introduce pitfalls the default make install path does not cover.

Install prefix. Studio loads plugins from <data_dir>/plugins/ (see NETWORK_PLUGIN.md). Under Flatpak, data_dir is usually under ~/.var/app/<ApplicationId>/config/, not ~/.config/BambuStudio. For the common Flathub id com.bambulab.BambuStudio, configure and install like this (adjust the id if yours differs — check flatpak list --app):

./configure --prefix="Ё/.var/app/com.bambulab.BambuStudio/config/BambuStudio" --vendor-mosquitto
make && make install

FFmpeg / camera. libBambuSource.so calls into libavcodec, libavutil, and libswscale for the LAN camera path on its default OBN_VIDEO_BACKEND=ffmpeg setting (the RTSP / RTSPS protocol itself is implemented in-process by stubs/rtsp_client.cpp; libavformat is not used, and the per-frame JPEG re-encode goes through stb_image_write rather than a libavcodec encoder). The plugin does not dlopen system libav: instead it resolves the libav function pointers it needs via dlsym(RTLD_DEFAULT, ...), binding to whatever copies of those libraries are already in the host process. Bambu Studio's AppImage / Flatpak runtime DT_NEEDEDs them off the main bambu-studio binary, so they are always already in process by the time our plugin runs. There is therefore no "host-versus-sandbox FFmpeg version mismatch" failure mode on Flatpak / AppImage. OBN_VIDEO_BACKEND=none opts out of RTSPS entirely.

Recommendation. For the fewest surprises, run a native Studio package from your distribution or an official AppImage, or build Studio from source yourself so the plugin, wxWidgets, and multimedia stack all target the same environment.

AppImage compared to Flatpak. They are not the same problem set. An AppImage typically carries Studio’s dependencies next to the binary and still uses the normal user **~/.config/BambuStudio** data directory on Linux, so the default ./configure prefix is often correct without Flatpak’s ~/.var/app/… rewiring. You may still need **--vendor-mosquitto** if the AppImage’s namespace does not expose a usable libmosquitto to the plugin. FFmpeg in the default OBN_VIDEO_BACKEND=ffmpeg build is not affected by either container's namespace quirks: the plugin doesn't link or dlopen libav at all, it binds to the AppImage's / Flatpak's already-loaded libav copies via dlsym(RTLD_DEFAULT, ...). So the RTSPS path works identically inside or outside a container as long as Studio has libav loaded (it does on every release we have looked at). When in doubt about the rest of the toolchain, prefer matching Studio’s release environment (same distro packages or same upstream build instructions) or building both Studio and the plugin from source.

Logging

The plugin writes a printf-style log of ABI calls and MQTT / FTPS / HTTP activity. Defaults: severity info, output only to stderr (the terminal that launched Bambu Studio). No log file is opened unless you opt in — this keeps disk noise down for everyday use.

Where it goes.

• Default: stderr only (OBN_LOG_STDERR=1), each line prefixed with [obn] so it is easy to grep apart from Bambu Studio’s own stderr.
• File next to Studio’s data directory: set OBN_LOG_TO_FILE=1 to append to <data_dir>/obn.log, where data_dir is the path Studio passes to bambu_network_create_agent (typically ~/.config/BambuStudio/obn.log on Linux).
• Explicit path: set OBN_LOG_FILE to an absolute path. Use /dev/null to disable the file sink while keeping stderr. An empty OBN_LOG_FILE= means “no file from env” (stderr only unless OBN_LOG_TO_FILE=1).

Log levels. trace < debug < info < warn < error < off. The default is info. Use debug or trace when diagnosing issues (trace adds per-MQTT-frame and per-FTPS-command noise).

Configuration via environment variables (read once, on first log call — export them before launching Studio):

Example — default behaviour (info to terminal only):

Example — persistent file next to Studio data, no stderr spam:

OBN_LOG_TO_FILE=1 OBN_LOG_LEVEL=info OBN_LOG_STDERR=0 bambu-studio

Example — full wire-level trace to a dedicated file:

OBN_LOG_LEVEL=trace OBN_LOG_FILE=/tmp/obn-session.log bambu-studio

Line format:

On stderr, each line starts with [obn] , then:

YYYY-mm-dd HH:MM:SS.uuuuuu [LVL] [tid] file.cpp:line func_name: message

The file sink (if any) omits the [obn] prefix — the file is plugin-only.

where tid is the OS thread id — useful to correlate MQTT background-thread activity with Studio main-thread ABI calls.

Secrets — be careful before sharing a log. The plugin does not currently auto-redact secrets. At debug and trace levels the log can contain: printer access codes (MQTT password), session bearer / refresh tokens from obn.auth.json, raw MQTT push_status payloads (which include serial numbers and filament metadata), FTPS file paths, and device IPs. Before pasting a log into a bug report, grep out access_code, Bearer, accessToken, refreshToken, password, and your printer's serial / WAN IP. (Tightening this up into a proper redacting logger is on the TODO list.)

libBambuSource.so logging

libBambuSource.so is dlopen'd separately from the main plugin and runs inside the camera / file-browser code path that Studio's media widget (Linux/Windows) or wxMediaCtrl2.mm (macOS) drives. It keeps its own log mirror so you can see RTSP / TLS / FFmpeg failures even when the parent Studio process funnels its log somewhere unhelpful.

The mirror file rolls every line through [level] plus a timestamp. Lines are tagged with libav: (RTSP control plane), rtsp: (handshake / DESCRIBE / SETUP / PLAY), and h264: (decoder + JPEG encoder). Any libav internal output appears under [av WARN]. The dynamic libav loader emits one line at startup confirming it bound to the host process's already-loaded libav (ffmpeg_dyn: resolved libav* via RTLD_DEFAULT (in-process libavcodec/libavutil/libswscale)); when that fails the same line says exactly which symbol was missing, which is almost always "this Studio build does not bundle libavcodec at all" since the AppImage variant we support always does.

License

MIT — see LICENSE.

Support the Developer and the Project

• GitHub Sponsors
• Patreon
• Buy Me A Coffee
• Sber
• Donation Alerts
• Boosty