mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 05:35:30 +02:00
[GH-ISSUE #58] [Bug]: printing to virtual A printer failes #24
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#24
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 @VID-PRO on GitHub (Jan 5, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/58
Originally assigned to: @maziggy on GitHub.
Bug Description
FTP error when printing to virtual A1 printer
Expected Behavior
all files will be transfered
Steps to Reproduce
print to a virtual A1 printer
Printer Model
A1
Bambuddy Version
0.1.6b6
Printer Firmware Version
virtual
Installation Method
Docker
Operating System
Linux (Ubuntu/Debian)
Relevant Logs
Screenshots
Additional Context
No response
Checklist
@maziggy commented on GitHub (Jan 6, 2026):
Virtual printer only supports sending files to Bambuddy. You need to hit the Send button in Slicer instead of Print.
@VID-PRO commented on GitHub (Jan 6, 2026):
tried it with send but i got this error:
@maziggy commented on GitHub (Jan 6, 2026):
Please use branch 0.1.6b7 and use the new "export debug logs" function.
https://wiki.bambuddy.cool/features/system-info/#support-bundle
@VID-PRO commented on GitHub (Jan 6, 2026):
@VID-PRO commented on GitHub (Jan 6, 2026):
under settings -> virtual printer i can see that there is 1 pending file
@Percy2Live commented on GitHub (Feb 5, 2026):
I'm facing the same issue on my P1S. The odd thing is it works totally fine for certain plates. For others I always receive this error:
When I try it over and over again I am lucky at a certain point and it sends it successfully
bambuddy-support-20260205-221740.zip
@maziggy commented on GitHub (Feb 6, 2026):
Please use branch 0.1.8b and try again. Yesterday evening we fixed a FTP related bug for the P1S.
@Percy2Live commented on GitHub (Feb 6, 2026):
Thanks for pointing this out. Is there an easy way to use 0.1.8b with Docker? It's not a tagged release, is it?
@maziggy commented on GitHub (Feb 6, 2026):
cd to your bambuddy folder and do a
git pull && git checkout 0.1.8b && git pull && docker compose down && docker compose build --no-cache && docker compose up -d
@Percy2Live commented on GitHub (Feb 6, 2026):
I tested it with 0.1.8 and there the issue still persists. Sending a sliced file from bambu studio to bambuddy takes multiple attempts, printing via bambuddy doesn't work at all. Is 0.1.8b going to adress further measures to tackle this?
@maziggy commented on GitHub (Feb 6, 2026):
Send me a support package from your 0.1.8 version. Please don't forget to force the problem so that it gets logged.
@Percy2Live commented on GitHub (Feb 6, 2026):
attached you can find the support package.
I first uploaded a small model via bambu studio (first try aborted, second try went through).
Then I tried to print another model which was manually queued (without success)
It seems to be an ftp related issue. Surprisingly browsing the SD-card via the "file-system" tab works fine.
bambuddy-support-20260206-174405.zip
Thanks for looking into this!
EDIT: Maybe some more side-information: Running in docker on a Synology NAS in host mode, IP-table rules applied. Firewall currently disabled to exclude interferences. I usually run my docker containers with macvlan, but as port 9990 is hard coded in bambuddy I had to switch to host mode (macvlan is able to publish port 990 without issues, but remapping internal port 9990 to 990 is not possible in macvlan for my understanding if it's not configurable)
@maziggy commented on GitHub (Feb 6, 2026):
Also please show me a screenshots of your virtual printer settings when connected with Bambu Studio.
@Percy2Live commented on GitHub (Feb 6, 2026):
@Percy2Live commented on GitHub (Feb 6, 2026):
I'm currently looking into this with wireshark. I was surprised that there's almost no traffic between my PC and bambuddy even while sending something via bambu studio. Especially not at the ports I would expect. Is bambu studio directly sending to port 990?
@Percy2Live commented on GitHub (Feb 7, 2026):
Update: Small improvement with 0.1.8.1:
I was able to start a print via bambuddy. However, sending a file from bambu studio still takes multiple attempts and most of the time I'm receiving errors:
EDIT:
Bambuddy now also seems to notice the sending attempt:
@maziggy commented on GitHub (Feb 7, 2026):
I'm working on improvements right now.
@Percy2Live commented on GitHub (Feb 7, 2026):
No pressure, just wanted to keep you updated. Let me know if I can test anything. Great work, I already really like it
@maziggy commented on GitHub (Feb 7, 2026):
Here we go..... Virtual printer now has major changes that should improve it.
Please use branch 0.1.9b and rebuild container.
Please note the new network requirements for virtual printer function!!!! -> https://wiki.bambuddy.cool/features/virtual-printer/
@Percy2Live commented on GitHub (Feb 7, 2026):
Great, I would love to test this. Can you make this a tagged beta release? I couldn't get it working by building it myself
@maziggy commented on GitHub (Feb 7, 2026):
No, sorry.
cd to your bambuddy folder and do a
git pull && git checkout 0.1.9b && git pull && docker compose build --no-cache && docker compose down && docker compose up -d
@Percy2Live commented on GitHub (Feb 7, 2026):
Unfortunately this isn't working on synology. I've got another server which I can try later to perform build it from the branch
@Percy2Live commented on GitHub (Feb 7, 2026):
ok, I forked it and built a released version 0.1.9b
I looked through the changes in the wiki, ports 50000-50100 are no issue on my setup as I'm running it in host mode directly on one of my Synologys.
What I can tell is that with v0.1.9b the sending from the slicer to bambuddy fails completely. I'm now getting the error everytime, independently on how many times I retry. With 0.1.8.1 it still took a couple of attempts but worked in the end.
I'm still a bit puzzled by the wireshark recordings, I'm not able to identify the traffic that belongs to the slicer connecting to bambuddy (no traffic on port 990 and 50000-50100). Let me know if you are interested in some recordings
@maziggy commented on GitHub (Feb 7, 2026):
Now I'm confused. What virtual printer mode do you want to use now? The issue was opened for Queue mode and now you are talking about Proxy mode.
@Percy2Live commented on GitHub (Feb 7, 2026):
Sorry for the confusion. I'm also using queued mode.
With v0.1.9b I'm unable to send prints from bambu studio to the queue of bambuddy
@Percy2Live commented on GitHub (Feb 7, 2026):
Ok, I just noticed ports 50000-50100 are only required for proxy mode. There must be other changes as well, though: With v0.1.9b I'm completely unable to queue prints. I just verified: going back to v0.1.8.1 allows me to queue prints after some attempts
@notti commented on GitHub (Feb 7, 2026):
I have the same issue. Packet dump seems to show that bambustudio sends RST after ~80kb
@maziggy commented on GitHub (Feb 8, 2026):
Guys, need more details. Please send a support package.
@Percy2Live commented on GitHub (Feb 8, 2026):
Sure, I can create one. With 0.1.8.1 (multiple attempts required for sending a print from bambu studio to bambuddy) or with 0.1.9b (sending doesn't work at all)?
@Percy2Live commented on GitHub (Feb 8, 2026):
Here is one with 0.1.8.1 as I'm running on this right now. Took 18 attempts to send a print to bambuddy from bambu studio:
bambuddy-support-20260208-130609.zip
@maziggy commented on GitHub (Feb 8, 2026):
0.1.9b woud be better ;)
@Percy2Live commented on GitHub (Feb 8, 2026):
Alright, this one is with 0.1.9b. I must correct my previous statement: With 0.1.9b it seems to be similar to 0.1.8.1.
This time I was able to send the print at the 6th attempt - Yesterday I wasn't that lucky, after 40-50 attempts I assumed it's not working at all.
bambuddy-support-20260208-131549.zip
@maziggy commented on GitHub (Feb 8, 2026):
And please show me your docker-compose.yml and iptables rules.
@Percy2Live commented on GitHub (Feb 8, 2026):
I'm using a pre built image which I created on my own by forking your release:
iptables:
@maziggy commented on GitHub (Feb 8, 2026):
Good news: Your setup looks correct — network_mode: host is right, and your iptables rules are not blocking anything (INPUT policy is ACCEPT, no rules filtering the passive port range 50000-50100).
What the logs tell us: The error [Errno 104] Connection reset by peer means Bambu Studio is actively aborting the data transfer (sending a TCP RST). The small verify_job file (16 bytes) always succeeds, but the larger 3MF file fails intermittently mid-transfer.
A few questions/comments:
And most importantly: you are not using an original Bambuddy image! We don't provide support for third party images.
@Percy2Live commented on GitHub (Feb 8, 2026):
I'm using a DS918+ with an Intel J3455 and 16GB of RAM - while this isn't the most powerful CPU, it should have plenty of resources to perform this job. I checked on this particular system and it's around 20% load currently:
I am aware that this isn't the original image, but due to the lack of a released beta version I saw no other chance than to fork it. There are no other changes beside the docker_compose.yml. Please consider releasing beta versions as well, I'm unable to built those manually on Synology - releasing beta versions is common procedure and enables non devs like me to support with testing the latest builds.
@maziggy commented on GitHub (Feb 8, 2026):
Improved file transfer in branch 0.1.9b. Please try again.
If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!
@Percy2Live commented on GitHub (Feb 8, 2026):
Either rebuilding the 0.1.9b release in my fork (after syncing with your branch) was not really successfull or the issue still persists. I will have to wait for a release in your repo for testing
@notti commented on GitHub (Feb 8, 2026):
Hi, sorry for not sending more details earlier, tried to look into the issue and well - it was very puzzling.
From what I could observer it didn't really look like there was/is an issue in bambuddy - more like in BambuStudio -> Looking at traffic dumps with wireshark, it was always BambuStudio sending RST on the data connection out of nowhere - everything else looked ok. So I set out to debug a bit more - and try to figure out what is going on - including dumping the sslkeylog in bambuddy and have a look at the decrypted connections - also there it looked strange -> data was sent - and out of nowhere bambustudio just sends an RST. Also the small verify_job upload worked always - but also here things looked not like I would expect them (FIN from bambustudio and right away RST again... in the decrypted data I could at least see that the TLS connection was torn down correctly).
Another thing I could see there, that was a bit suspicous is that the TLS-"New Session Ticket" looked very weird (sometimes two right away - also somehow the whole thing looked not like it should from BambuStudio).
Unfortunately I could not really look into what is going on in BambuStudio (could not get tracing to work in a usable way)
So I suspected that maybe something is wrong on this end and patched ftp_server.py to not keep any ssl sessions around - unfortunately that did not work :/
So next try: I had a look at my X1C with nmap what ciphers and TLS version it supports -> X1C seems to only support 1.2 (i only looked at the ftp part [1]) - while connections BambuStudio <-> bambuddy were always TLS1.3 [2]
Well I thought I can give it one last try - maybe TLS 1.3 is the issue... and limited the maximum TLS version in ftp_server.py to 1.2 -> voila - uploads work:
I tried a couple of times and it work every time - so maybe TLS 1.3 is broken in the bambustudio network plugin in linux?
[1]:
[2]:
(
session_reused=Falsewith my try to deactivate session sharing - original code would haveTruehere)PS: for completenes my setup:
BambuStudio: Running on linux via flatpack
bambuddy: Via docker (compose) - network setup as macvlan, the required firewallrules for 9990 -> 990 added directly in the network namespace of the container via nsenter (I already have too much stuff on my host), running on a self-built nas with debian zfs on a ryzen 5600 with 32G ram)
@notti commented on GitHub (Feb 8, 2026):
Would be good if someone else also can test this and confirm (see related pull request)
@notti commented on GitHub (Feb 13, 2026):
@Percy2Live does the new release also work for you?
@Percy2Live commented on GitHub (Feb 15, 2026):
I can confirm that the sending error in Bambu Studio is gone with v0.1.9.
Tried multiple objects multiple times - each one went through without issues. Seems to be fixed
@maziggy commented on GitHub (Feb 15, 2026):
If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!