open-bamboo-networking/research/06-channels.md

6. Printer channels

How a client talks to a Bambu printer (and when it talks to Bambu’s cloud instead). This chapter is the map of transports; ABI call tables, print orchestration, and on-wire MQTT command catalogues live elsewhere.

Contents

Section	File
6.1 SSDP discovery	06.01-ssdp.md
6.2 MQTT (LAN and cloud)	06.02-mqtt.md
6.3 FTPS	06.03-ftps.md
6.4 Port 6000	06.04-port-6000.md
6.5 RTSP / RTSPS	06.05-rtsp.md
6.6 Cloud REST API	06.06-cloud-rest.md
6.7 TUTK (cloud P2P)	06.07-tutk.md

Channel list

Channel	Direction	Role	Detail
SSDP	printer → LAN	Discover dev_id + LAN IP	§6.1
MQTT	bidirectional	Primary command / telemetry channel (LAN and/or cloud)	§6.2
FTPS	client → printer	File transfer to external/USB-style volume	§6.3
TCP :3000	client → printer	Plaintext framed JSON login/detect channel used by bind_detect / account bind (device ticket mint) — not HTTP	§8.6.2–§8.6.3
TCP :6000	bidirectional	CTRL file browser, ft_* model cache, MJPEG on some models	§6.4
TUTK (UDP)	bidirectional	Cloud-minted IOTC/AV session: live video, file browser and ft_* jobs (IOCtrl 0x3001); LAN P2P on UDP 32761 discovery, hole-punched or relayed otherwise	§6.7
RTSP(S)	printer → client	H.264 live view on RTSP-capable models	§6.5
Cloud REST	client ↔ Bambu API	Account, device list, access codes, cloud print, certs — not TCP to the printer IP	§6.6

Also noted under MQTT / :6000: plaintext MQTT :1883 on some firmware; MJPEG live view on :6000 for A1/P1-class (different handshake from CTRL). Printer HTTP /info is not used by stock bind_detect (that path is TCP :3000 login/detect).

Access code

LAN MQTT, FTPS, and :6000 (and RTSP(S) URLs) authenticate with username bblp and an 8-character access code generated by the printer. The printer can show the code on-screen in LAN-Only mode so the user can type it into Studio. The code changes only when the user changes it on the device — it is not rotated automatically by idle reconnects.

For a cloud-paired printer the same code is still what unlocks direct LAN services. Stock obtains it without re-typing via cloud REST as plaintext dev_access_code on the user’s printer list / bind payload (§6.6, §8.10). The LAN IP half of the credential pair comes from SSDP (§6.1), not from that REST field.

Optional certificate check (anti-MITM)

LAN TLS (MQTT :8883, FTPS :990, :6000, RTSPS :322) is meant to be checked with both:

1. CA / chain — Studio’s printer.cer (BBL CA bundle from set_cert_file) as trust store, typically with partial-chain allowed because the printer often sends only the device leaf.
2. Name — leaf CN=<serial> (dev_id / SSDP USN), SNI set to that serial (no IP/DNS SAN). That binds the session to the expected printer, not merely “any cert signed by BBL”.

On observed N7/P2S the leaf issuer (BBL Device CA N7-V2) is not in Studio’s printer.cer, so a strict chain to that CA bundle fails until the client also trusts the snapshotted leaf (TOFU / install_device_cert-style pin) alongside printer.cer. slicer_base64.cer is for cloud hosts, not LAN. Stock closed-source verify policy is not RE’d from the binary. PEM layout: §10.6.