[GH-ISSUE #620] [Bug]: X1C Virtual Printer Error -1 #401

New issue

Closed

opened 2026-05-06 12:29:06 +02:00 by BreizhHardware · 2 comments

BreizhHardware commented

2026-05-06 12:29:06 +02:00

Owner

Originally created by @maziggy on GitHub (Mar 5, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/620

Originally assigned to: @maziggy on GitHub.

I ran into the same code=-1 issue connecting OrcaSlicer to the virtual printer proxying an X1C (firmware 01.11.02.00). Built 0.2.2b2 from source and the issue persisted.

Root cause: The Bind-TLS proxy (port 3002) was failing with SSL error connecting to <printer>:3002: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE]. The printer only supports plain RSA key exchange cipher suites (e.g. AES256-GCM-SHA384), but Python's OpenSSL 3.5 defaults exclude those in favor of forward-secrecy ciphers (ECDHE/DHE only). So the TLS handshake fails because client and server have no ciphers in common.

Confirmed by testing with openssl s_client from the same host — it connects fine because it offers a wider cipher set including plain RSA. Python's ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT) does not.

Fix: In backend/app/services/virtual_printer/tcp_proxy.py, add the RSA ciphers back to the client SSL context:
def _create_client_ssl_context(self) -> ssl.SSLContext:
    """Create SSL context for connecting to printer."""
    ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
    ctx.check_hostname = False
    ctx.verify_mode = ssl.CERT_NONE
    ctx.minimum_version = ssl.TLSVersion.TLSv1_2
    # Bambu printers use plain RSA key exchange (no ECDHE/DHE),
    # which modern OpenSSL defaults exclude. Add them back.
    ctx.set_ciphers("DEFAULT:AES256-GCM-SHA384:AES128-GCM-SHA256")
    return ctx
After rebuilding with this change, the Bind-TLS proxy connects successfully and OrcaSlicer can reach the virtual printer. Tested on X1C — not sure if the same cipher limitation applies to all Bambu printer models (A1, P1S, etc.) or even all production X1Cs, but it seems likely given the shared firmware TLS stack.

Originally posted by @begna112 in #618

Originally created by @maziggy on GitHub (Mar 5, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/620 Originally assigned to: @maziggy on GitHub. > I ran into the same `code=-1` issue connecting OrcaSlicer to the virtual printer proxying an X1C (firmware 01.11.02.00). Built 0.2.2b2 from source and the issue persisted. > > **Root cause:** The Bind-TLS proxy (port 3002) was failing with `SSL error connecting to <printer>:3002: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE]`. The printer only supports plain RSA key exchange cipher suites (e.g. `AES256-GCM-SHA384`), but Python's OpenSSL 3.5 defaults exclude those in favor of forward-secrecy ciphers (ECDHE/DHE only). So the TLS handshake fails because client and server have no ciphers in common. > > Confirmed by testing with `openssl s_client` from the same host — it connects fine because it offers a wider cipher set including plain RSA. Python's `ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)` does not. > > **Fix:** In `backend/app/services/virtual_printer/tcp_proxy.py`, add the RSA ciphers back to the client SSL context: > > ```python > def _create_client_ssl_context(self) -> ssl.SSLContext: > """Create SSL context for connecting to printer.""" > ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT) > ctx.check_hostname = False > ctx.verify_mode = ssl.CERT_NONE > ctx.minimum_version = ssl.TLSVersion.TLSv1_2 > # Bambu printers use plain RSA key exchange (no ECDHE/DHE), > # which modern OpenSSL defaults exclude. Add them back. > ctx.set_ciphers("DEFAULT:AES256-GCM-SHA384:AES128-GCM-SHA256") > return ctx > ``` > > After rebuilding with this change, the Bind-TLS proxy connects successfully and OrcaSlicer can reach the virtual printer. Tested on X1C — not sure if the same cipher limitation applies to all Bambu printer models (A1, P1S, etc.) or even all production X1Cs, but it seems likely given the shared firmware TLS stack. _Originally posted by @begna112 in [#618](https://github.com/maziggy/bambuddy/issues/618#issuecomment-4003418814)_

BreizhHardware

2026-05-06 12:29:06 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

2026-05-06 12:29:06 +02:00

Author

Owner

@maziggy commented on GitHub (Mar 5, 2026):

Good catch and spot on! Thanhs for pointing this out!

Fixed in branch 0.2.2b2.

If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!

@maziggy commented on GitHub (Mar 5, 2026): Good catch and spot on! Thanhs for pointing this out! Fixed in branch 0.2.2b2. ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/bambuman/bambuddy) — it helps others discover the project!

BreizhHardware commented

2026-05-06 12:29:07 +02:00

Author

Owner

@begna112 commented on GitHub (Mar 5, 2026):

Thanks for the quick cipher fix! Confirmed that resolves the Bind-TLS handshake failure.

Found a second issue in the same file after testing further with OrcaSlicer: FTP data connections fail with an SSL error when PROT P is active.

The FTP data proxy in tcp_proxy.py always starts the slicer-side data listener as cleartext, with a comment noting that Bambu Studio doesn't do TLS on data connections even after PROT P. However, OrcaSlicer does expect TLS on the data channel after PROT P, so the FTP file upload fails with an SSL handshake error.

Fix: In _start_data_proxy_server, pass the server SSL context to asyncio.start_server when use_tls is True:

# When PROT P is active, some slicers (e.g. OrcaSlicer) expect TLS
# on the data channel too. Offer TLS on the slicer side to support both.
slicer_data_ssl = self._server_ssl_context if use_tls else None

server = await asyncio.start_server(
    handle_data,
    "0.0.0.0",
    port,
    ssl=slicer_data_ssl,
)

With both fixes applied (cipher + FTP data TLS), the full proxy flow works end-to-end with OrcaSlicer and an X1C: MQTT, Bind-TLS, and FTP uploads all succeed. Printer control and print sending both work through the virtual printer.

edit: scratch that, i spoke to soon. allowed me to get to another new error after appearing to upload properly.

@begna112 commented on GitHub (Mar 5, 2026): Thanks for the quick cipher fix! Confirmed that resolves the Bind-TLS handshake failure. Found a second issue in the same file after testing further with OrcaSlicer: **FTP data connections fail with an SSL error when PROT P is active.** The FTP data proxy in `tcp_proxy.py` always starts the slicer-side data listener as cleartext, with a comment noting that Bambu Studio doesn't do TLS on data connections even after PROT P. However, OrcaSlicer *does* expect TLS on the data channel after PROT P, so the FTP file upload fails with an SSL handshake error. **Fix:** In `_start_data_proxy_server`, pass the server SSL context to `asyncio.start_server` when `use_tls` is True: ```python # When PROT P is active, some slicers (e.g. OrcaSlicer) expect TLS # on the data channel too. Offer TLS on the slicer side to support both. slicer_data_ssl = self._server_ssl_context if use_tls else None server = await asyncio.start_server( handle_data, "0.0.0.0", port, ssl=slicer_data_ssl, ) ``` With both fixes applied (cipher + FTP data TLS), the full proxy flow works end-to-end with OrcaSlicer and an X1C: MQTT, Bind-TLS, and FTP uploads all succeed. Printer control and print sending both work through the virtual printer. edit: scratch that, i spoke to soon. allowed me to get to another new error after appearing to upload properly.

BreizhHardware referenced this issue

2026-05-06 12:34:33 +02:00

[PR #401] [MERGED] feat(queue): display plate name alongside file name for multi-plate files #1026

BreizhHardware referenced this issue

2026-05-06 12:34:37 +02:00

[PR #411] [MERGED] v0.2.0 #1034