Quick reminder that despite being so overconfident, half of your messages only show a complete lack of technical understanding and have been disproved
And that your latest comment is a strawman:
Irrelevant shift: The topic was whether Orca needed the network code source — not whether MQTT could be reverse-engineered.
False implication: Denidil seems to suggest that because others reverse-engineered the protocol (e.g., for Panda Touch), this somehow justifies closing the network code — but:
Orca didn’t reverse engineer MQTT.
Orca used an official (though closed-source) plugin via a defined API boundary.
The reverse engineering happened in separate community projects, and is unrelated to Orca’s plugin use case.
It would be a very, very bad idea… Good thing that wasn’t the case then. Before Bambu Connect in order to pull the scenario you present you would need to gain access to the LAN the printer is on and get the auth code (physically from the printer or sniffed from an already authorized Bambu or Orca slicer). After the introduction of this ‘security update’ you still have to do the same, but while grabbing the auth code you also need to exfoliate the cert/priv key from Bambu Connect (or just use the one hardcoded in it, freely available on the interwebs)… Some added security, much wow…
And? Has it become somehow any less secure by people knowing the topics and message structure used in it? Are you saying that BL was relying on security-thtough-obscurity? They still use the same protocol, btw. they are just adding a self-rolled mTLS to it with atrociously amateurish way to handle client certs.
I wouldn’t dare to assume about everyone else, but based on your writing here I’d be very confident in saying that you know very little on the subject, putting it generously.
Why are so many people incapable of understanding that someone can think that Bambu had a point, solved the point in the wrong fashion, but also think Orca is acting poorly too?
Is it really that unfathomable to you people that someone can’t look at a situation and just go “you’re all wrong”
I dont have all the answers, But why do you think Bambu has your best interests at heart? No one is hacking printers dude. IMO more likely this “security feature” is more likely a back door for people who choose LAN mode, so they can download your personal designs off the SD card. Is that a reach? yea… but prove its not.
I would love to come back to this in 2-3 years where you cant use anything but bambu filament on bambu machines, and listen to how you say “they kind of have a point”
I would love to be proved wrong. I wont deny anything. I also dont think the market is too big.
They have no reason to force security between me and my own printer, in my own network. But they do it. They have no reason to send every print you make to their servers before sending it to the printer, but they do it. They have no reason to lock down their consumable products… yet to be seen.
Also i’m not really that heated about anything. I guess i misunderstood and am now trying to see your actual point. If you dont think they have your best intrests at heart, why are you so worried about people wanting open source networking software, if we’re not using bambu servers?
dude go look at market reports, they’re not even the single largest vendor (Creality is)
you being unaware of settings that change that is not their fault
their failing to offer that initially and having to be forced into it is their fault
this is one of many reasons why I say “you’re all wrong” You’re talking out of paranoia and ignorance and it’s just extremely grating.
BECAUSE THAT ISN’T WHAT I’M WORRIED ABOUT
Why are you people so freaking incapable of actually asking me what i mean when you fail to understand instead of making extremely obnoxious assumptions based on your own paranoia?
it’s freaking super maddening to put up with kind of nonsense.
Lets break this down
3D Printer security issues are real issues, as shown by other brands having been broken into
The MQTT interface on Bambu was undocumented and they warned that it would not remain available forever when people reverse engineered it
No interface to send remote commands should be unsecured (this is where “bambu has a legitimate point”)
No “it requires being on the same IP scope” is not security
Bambu’s solution (Bambu connect, etc) is a very poor solution (if a solution at all), as i have REPEATEDLY STATED OVER AND OVER THEY COULD HAVE DONE BETTER WITH A PURE OPEN SOURCE SOLUTION
Bambu’s whining about “3rd party slicers compromising their cloud stability” is a Bambu issue. It’s a code/design issue in their cloud platform
Orca blanket refusing to work with Bambu Connect based on pure ideological/paranoia grounds is also not a helpful move. It’s in fact a pretty poor move
Bambu making “Developer mode” was a good move
Bambu not making “developer mode” in the first place was a bad move
Bambu letting arbitrary valid gcode be sent via bambu connect is a good move
Bambu connect being a pile of trash Electron app is a bad move
“it requires being on the same IP scope" AND “it requires authentication before you’re even able to send commands” (which several users told you).
Why do you keep insisting this is insecure?
The printer always exposes it’s MQTT server, regardless of whether you use cloud mode, LAN mode, or developer mode.
So the only difference with developer mode is which type of client it allows, the network security is not affected at all.
I don’t even care if only the cloud was locked down for cost-saving reasons or whatever.
Previously both of these were possible at the same time, but since the authorization update and developer mode you can only choose one:
Connect anything via LAN
Use Bambu Handy
Can you explain how this is still a “good move”?
They can maybe solve the cloud reliability issue and somewhat reduce cost with rate-limiting.
But Bambu Connect etc was made because of business decisions. There’s no technical solution for these problems, also not with open-source:
hide how the network protocols work
reliably detect the type of client you’re connecting with
One of OrcaSlicer devs noticed that new version of network plugin adds anti-debugging, meaning that one cannot use debugger while working on either developing Orca or “open-source” Bambu Studio, meaning not only hindering 3rd party slicers but also making it hard for people wishing to contribute to Bambu Studio to do meaningful debugging: Please remove anti-debugging code in BBL network plugin · Issue #6726 · bambulab/BambuStudio · GitHub
You guys here are spending so much time to prove Denidil that he doesn’t understand what he’s talking about… I wish you would spend all that energy in pressing Bambu to find a proper middle ground in that.
I didn’t real the entire back and forth here but @Denidil said you can run Orca Slicer direct in Dev mode but it doesn’t sound like he tried that yet. My understanding is that no matter what mode you’re in after the firmware update, you can’t use Orca slicer as it will require bambu connect. Can anyone else confirm, has anyone actually tried it? I’m not "upgrading my offline x1c but that may make me consider the H2D once they get the print quality issues and bed heat distribution issues addressed.
I didn’t understand you wrong, what you’re saying goes against some older information I read so I’m looking for confirmation from someone actually doing it.
