mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 05:35:30 +02:00
[GH-ISSUE #925] [Bug]: Bambuddy stops being able to connect to X1C's Camera after a couple hours. #638
Labels
No labels
A1
automated
automated
bug
bug
Closed due to inactivity
contrib
dependencies
dependencies
duplicate
enhancement
feedback
hold
invalid
Notes
P1S
pull-request
security
security
ThumbsUp
user-report
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/bambuddy#638
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lightmaster on GitHub (Apr 9, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/925
Originally assigned to: @maziggy on GitHub.
Bug Description
After a day or so of both the printer and Bambuddy being online, Bambuddy loses the ability to connect to the X1C's camera. It will go through connection attempts 6 out of 5 attempts (possible bug/bad numbering there too?) then give up trying. If I reboot the printer, Bambuddy will then be able to reconnect to the printer. This also prevents Bambuddy from being able to take a snapshot at the end of the print.
When Bambuddy is unable to connect to the printer's camera, OrcaSlicer is still able to connect without any issue.
Expected Behavior
Bambuddy should be able to connect to the camera at any point, regardless of how long the printer's been online. At the very least, it should be able to connect to the camera if another piece of software is able to connect to the camera.
Steps to Reproduce
Printer Model
X1 Carbon
Bambuddy Version
dev pulled April 8th
Printer Firmware Version
99.00.00.00
Installation Method
Manual (git clone)
Operating System
Linux (Ubuntu/Debian)
Relevant Logs / Support Package
bambuddy-support-20260409-040946.zip
Screenshots
No response
Additional Context
While the debug logs were being collected, I attempted to connect to the camera, waited for it to stop trying, then rebooted just the printer over SSH. Once the printer showed as online again in Bambuddy, I clicked the camera icon and it showed up almost right away.
Checklist
@maziggy commented on GitHub (Apr 9, 2026):
I've traced through the logs and I want to share what I found plus ask for one more round of diagnostics before I'm confident about the root cause.
What the logs show
Looking at bambuddy.log around the failure at 04:08:38–04:08:53:
About the "6 of 5" counter
Good catch — that's a real off-by-one bug in CameraPage.tsx. When the 5th retry fires, the state briefly shows reconnectAttempts=5 before the bail-out check runs, so the banner displays "6 of 5" for a moment. I'll fix that separately from this issue.
Bambuddy-side issues I'm going to fix regardless
Even if the root cause turns out to be the printer, the logs surfaced two things that make the experience much worse than it needs to be:
What I'd like to confirm before blaming the printer
The logs are consistent with a printer-side failure, but I can't fully rule out:
Next time you hit the failure state, before rebooting the printer, could you run these? They take about 30 seconds:
From the bambuddy host — does it see the camera port as refused?
nc -zv <printer_ip> 322
From a DIFFERENT machine on the same LAN (laptop, phone via termux, another Pi…)
nc -zv <printer_ip> 322
Refused from both → printer-side, firmware/resource issue (case closed)
Refused from bambuddy only → something path- or host-specific
Is MQTT still alive on the printer?
nc -zv <printer_ip> 8883
Still open → only the camera subsystem is dead — strong firmware/resource signal
Also closed → whole network stack is degraded
Does OrcaSlicer work at that exact moment (not just "in general")?
Open it, connect to the same printer, try to view the camera.
(Optional, most informative) Run this on the bambuddy host
while clicking the camera button in the UI:
sudo tcpdump -ni any host <printer_ip> and port 322
SYN → RST (instant) = port actively refused
SYN → (silence) = stealth-dropped
SYN → SYN/ACK → TLS error = daemon half-alive
If 2) also fails from another host and #3 MQTT is still up, that's strong evidence the camera daemon on the printer crashed and we can't fix it in software — only mitigate with better retry/backoff and surface a clearer error. If #4 succeeds while bambuddy is refused at the same moment, then the path between bambuddy and the printer is the suspect, not the printer firmware, and I have more work to do.
@lightmaster commented on GitHub (Apr 9, 2026):
Will do.
@lightmaster commented on GitHub (Apr 9, 2026):
Just a follow up, camera still working as of right now.
@lightmaster commented on GitHub (Apr 10, 2026):
Bambuddy can't connect to the camera right now. It ran for well over a day without issue, but stopped connecting to the camera during a 10 hour print and didn't get the picture at the end of the print. About to restart the printer to get it working again and will do a 5 hour print with debug on to see if that shows anything about the moment that it stops connecting. Doubt it matters, but the printer and bambuddy are on different VLANs, but allow full connection between them with no filtering. In the following commands, bambuddy is on IP 10.14.166.201, bamboozle (printer) is on 10.0.0.227. Orcaslicer can see the camera this entire time, and doesn't seem to make a difference if OrcaSlicer is connected to the camera or not, Bambuddy can't connect to camera.
Side note, I just updated to the current dev branch and still see reconnect attempt 6/5.
OrcaSlicer can currently see the camera while Bambuddy can't. Also homed the printhead to make sure that the camera feed is live and not a frozen image.
10.14.166.201 is bambuddy, 10.0.0.227 is printer.
@lightmaster commented on GitHub (Apr 11, 2026):
Camera shut off right after the 35 minute mark of the debug timer and won't reconnect. Bambuddy still sees the print is going and print time/progress are still going. OrcaSlicer can connect to the camera.
bambuddy-support-20260410-202439.zip
@maziggy commented on GitHub (Apr 11, 2026):
Thanks for the detailed tcpdump and support bundle, that made this much easier to pin down.
The capture is very clear: on every new camera attempt the TCP three-way handshake to port 322 succeeds, bambuddy pushes ~1555 bytes (the TLS ClientHello), and the printer ACKs it at the TCP layer but never sends a TLS ServerHello back. That's the camera service on the printer being hung at the TLS layer — not a network issue and not something bambuddy can fix from the outside. It also explains why nc -zv keeps passing (it only tests the SYN) and why OrcaSlicer keeps working (it's holding an already-established session from before the hang). You can also see a bunch of old bambuddy source ports still getting stale ACKs from the printer long after bambuddy closed them, which looks like server-side sockets not being reaped. That's consistent with the camera daemon slowly running out of TLS session slots and then refusing new handshakes until the printer reboots — which matches your 35-minute / 10-hour failure windows and the "reboot the printer and it works again" remedy.
The relevant bit here is that you're running X1Plus (firmware 99.00.00.00 is the X1Plus marker). X1Plus is a third-party firmware that reimplements big parts of the X1C's Linux userspace, including the camera service, and bambuddy has no X1Plus-specific code paths on the camera side — it's talking to port 322 over TLS exactly the same way it does to stock firmware, and stock firmware doesn't exhibit this hang. So the bug is almost certainly in X1Plus's camera daemon, not in bambuddy.
What you can do:
I'm going to leave the bambuddy camera client alone for now since it's working correctly against stock firmware and the fix has to happen on the printer side. If X1Plus confirms this is a known issue or fixes it, please do link the upstream ticket here so anyone else on X1Plus who hits this can find it.
@mikefromdot commented on GitHub (Apr 14, 2026):
An attempt is being made to fix this and is currently being tested.
Issue stems from BBL's ipcam implementation in base firmware version locking up after a bit which is a known issue. An attempt is being made to remediate this by implementing a watchdog on the service and forcing a refresh which should fix this on the x1p side.