baltobu-network-probe

A standalone test harness that verifies every entry point Bambu Studio's NetworkAgent looks up in libbambu_networking.so (or its macOS / Windows equivalents). For each of the 108 expected symbols the probe:

• declares a C++ function-pointer slot using the same typedef the slicer source uses,
• dlopens the plugin and dlsyms the symbol into that slot,
• reports whether the symbol resolved, with the typedef name so you can cross-reference against bambu_networking.hpp in the upstream BambuStudio tree.

A --call-safe mode additionally invokes the two parameterless, side-effect-free entry points (bambu_network_check_debug_consistent and bambu_network_get_version) so you can confirm the C++ ABI is genuinely compatible — not just that the names exist in the symbol table.

This is sibling tooling to baltobu-dl-network-plugins (GitHub · Codeberg), which actually downloads the binaries. This probe runs against whatever .so you point it at; it doesn't fetch anything.

This project is not affiliated with or endorsed by Bambu Lab.

Why this exists

Two reasons:

1. Diff-detection across plugin versions. When Bambu ships a new 02.0x.0x.xx build of libbambu_networking, this probe gives you a one-line answer to "did any of the entry points the slicer depends on disappear or get renamed?" If a symbol vanishes, the probe pinpoints which one — which is what the slicer itself would see at runtime as a silent feature degradation.

2. Groundwork for the SFC reverse-engineering effort. The Software Freedom Conservancy is currently building open-source replacements for these libraries (see SFC-AGPL-FINDINGS.md in the fetcher repo — GitHub · Codeberg). A complete, machine-readable inventory of the API surface — symbol → typedef → resolved status — is useful input for that work.

Requirements

• A C++17 compiler (g++ 7+, clang++ 5+).
• make.
• A copy of libbambu_networking.so (or .dylib / .dll) — the baltobu-dl-network-plugins fetcher will get one for you.

On AlmaLinux/RHEL-family:

sudo dnf install -y gcc-c++ make

On Debian/Ubuntu:

sudo apt install -y g++ make

Build

make

Produces ./baltobu-network-probe in the project root. The build has no third-party dependencies beyond libdl (POSIX) and libstdc++.

Usage

baltobu-network-probe [options] <path-to-libbambu_networking.so>

Options

Flag	Meaning
-v, --verbose	Print every symbol with its resolution status. Default prints only the missing ones.
--call-safe	After resolving symbols, invoke check_debug_consistent and get_version. See ABI caveat.
--json	Emit results as a JSON object on stdout.
-h, --help	Print usage.

Exit codes

• 0 — all 108 symbols resolved
• 1 — at least one symbol missing
• 2 — usage error (bad flag, missing path, etc.)

Example session

$ baltobu-network-probe ~/.config/BambuStudio/plugins/libbambu_networking.so
108 symbols expected, 108 resolved, 0 missing

$ baltobu-network-probe --call-safe ~/.config/BambuStudio/plugins/libbambu_networking.so
108 symbols expected, 108 resolved, 0 missing

--- safe invocations ---
check_debug_consistent(false) = 1
check_debug_consistent(true)  = 1
get_version()                 = "02.07.00.50"

$ baltobu-network-probe --json ~/.config/BambuStudio/plugins/libbambu_networking.so | jq '.symbols[] | select(.resolved == false)'
# (no output — everything resolved)

How it works

The probe uses an X-macro over a single symbols.def list of (slot, typedef, exported_symbol) triplets — 108 entries extracted from src/slic3r/Utils/NetworkAgent.cpp in the upstream slicer. The same list is expanded three times:

1. Slot declarations — generates a static type slot##_fn = nullptr; for each entry.
2. Metadata table — generates a {slot, type, symbol, false} row per entry for reporting.
3. Resolution loop — generates the slot##_fn = reinterpret_cast<type>(dlsym(lib, "symbol")) call per entry, and marks the metadata row resolved.

Adding or removing a symbol means editing one line in symbols.def; the typedefs, declarations, resolution, and reporting all stay in sync automatically.

Mismatched names

Five of the 108 entries have a typedef name and an exported symbol name that do not line up by pattern, faithfully reflecting what the slicer does today:

Slot	Typedef	Exported symbol
check_cert	func_check_cert	bambu_network_update_cert
start_publish	func_start_pubilsh (sic)	bambu_network_start_publish
get_my_token	func_get_my_profile (reused)	bambu_network_get_my_token
put_model_mall_rating_url	func_put_model_mall_rating_url	bambu_network_put_model_mall_rating
get_model_mall_rating_result	func_get_model_mall_rating_result	bambu_network_get_model_mall_rating

These are not bugs in this probe — they are quirks in the upstream slicer source. See the header comment in src/symbols.def for details.

ABI caveat

--call-safe invokes functions that return std::string by value (bambu_network_get_version). The C++ standard does not specify a stable ABI for std::string; the layout depends on which libstdc++ (or libc++) and which compiler the library was built against. In practice:

• libbambu_networking ships as a Linux ELF built against a recent libstdc++ (GNU C++11 ABI). Building this probe with the same major glibc / libstdc++ family — i.e. any modern g++ on a glibc Linux — has worked in testing.
• Across major libstdc++ generations or against libc++ (Clang's stdlib), calling these functions may crash or return corrupt data even if dlsym succeeds.

The presence test itself (no --call-safe) does not call anything across the ABI boundary — it just looks symbols up by name, which is ABI-agnostic. Use that mode whenever you're not on the same toolchain family that produced the binary.

License

This probe is licensed under the GNU Affero General Public License v3.0 or later. See LICENSE.

The function-pointer typedefs, struct definitions, callback types, and error-code constants in src/bambu_network_api.hpp are derived from src/slic3r/Utils/NetworkAgent.hpp and src/slic3r/Utils/bambu_networking.hpp in the upstream BambuStudio tree, both also AGPL-3.0-or-later. The header notice preserves attribution accordingly.

This project does not redistribute libbambu_networking.so or any other proprietary Bambu binary. It only loads them at runtime against a path the user supplies.