Bambu Labs printer firmware has Wi-Fi key bug

[pfurrie]

I’m using a 63 character fully random Wi-Fi key. Every time I shut off my printer (or it loses power because of lightning storms in Central Florida), the printer can’t re-attach to the network. Oh, every other device (many) on the network re-connects fine except for the 3D printer. Checking the printer, the signal strength for the desired network is great. Soooo… I click “Forget” for that network, then re-setup that network. Painfully enter the 63-character key… again. Last night I had to do that three times… once for a stuck piece of filament from the AMS that required taking that apart to clear it, once again for the firmware update from Bambu Labs (which apparently reboots the thing as I would expect), and the other was when I typed the key in wrong, apparently. Which brings up another issue: If I type in the Wi-Fi key wrong, stop wiping out the entire field. This forces the user to have to start from scratch. EITHER keep the wrong password in the field, allowing the user to unhide the password and then edit the offending character(s), OR get a less painful way to connect the printer to the network. A LOT of other smart home devices have far better network connection processes… use one of those. Create a temp network from the printer that the user connects to with their phone, then the printer app asks for the key, at which point the user can copy/paste the key from a saved copy of that key. Easy peezy.

So, Bambu Labs, if you are listening (?), you have a flaw in your firmware. If you are limiting the size of the Wi-Fi key you save to the non-volatile memory, then fix it. Wi-Fi keys can be up to 63 characters long. You better have enough memory on that printer to handle that many characters. If not, shame on you. Your Wi-Fi circuitry and the code that uses the key seem to handle it just fine, it is just the part of the code that saves and/or retrieves the key.

Or give us a reasonably-priced hardware add-on to upgrade our printers to have wired networking. Blows my mind that this wasn’t included.

And please: no “password-shaming” for me having the fully allowable Wi-Fi key. If we aren’t part of the solution, we are part of the problem.

Oh, and yes, I did open a support ticket with Bambu, including detailed info and multiple screen pics from the printer to help illustrate the issue.

[Olias]

Look, you’ll find plenty of people who empathize with your plight, including me. However, posting an open letter to Bambu on this topic, or others for that matter, won’t make a difference. They have been stonewalling this community since day one regarding their lousy Wi-Fi and TCP/IP stack implementation and have chosen, through their actions, to ignore us here.

You mention that if Bambu left insufficient memory to accommodate the industry standard of 64 characters, they should be ashamed of themselves. Well, clearly, Bambu has no shame. They only care about the almighty dollar. They have yours, and that’s all that matters to them. Future customers don’t seem to be part of their growth strategy; otherwise, they would address the numerous bugs and shortcomings in their architecture. Perhaps you are not familiar with the Chinese business philosophy of Chabuduo.

If you search this forum, you will find many posts similar to yours. Bambu doesn’t care—that much is obvious.

But if really want to get through to Bambu, here’s the door of their complaint department.

Oh, and after you file the complaint via email—since they don’t have phones or customer service personnel in China—you will receive an automated message stating that they are experiencing higher-than-normal volume and asking you to be patient.

[RocketSled]

@pfurrie

Painfully enter the 63-character key

I fully understand the desire to be able to use a feature as-designed and without limitation. But… the security of your computer network only needs to be as good as the security of the building it’s in. If breaking in to your network is harder than breaking in to your house, additional levels of network security are arguably not providing any benefit.

A 63 byte WPA key has 95^63 possible permutations of characters. It would be a practical impossibility to brute force this key. But a 32 byte key has 95^32 which is still an astronomically high number of combinations not practically susceptible to brute force guessing.

I would argue no one actually needs a 63 byte key… even for WPA3.

If I was the software designer having to make a choice on this, I wouldn’t have any qualms about limiting keys to 32 bytes. The only thing I’d argue BBL did wrong was not including an errata to make it clear they made this design decision…

You can solve your problem if you abandon the idea that you actually need a 63 byte key.

[MZip]

I’ve got to go with @RocketSled on this one. Someone with intent would need to be close enough for a wifi signal to start attacking you (which isn’t terribly hard with yagi antennas), or they just burglar you and plug something in, tap into a network cable, or swap out a bit of hardware. Physical access is hard to beat if someone has intent.

For WiFi, though, simple and common passwords are beyond most regular Joes to crack just because few know how to sniff or target. Just having a password and encrypting traffic will keep most out. If I lived near the convention center where Black Hat was coming, I think I might just turn everything off for the duration, though.

This is also based on there not being weaknesses in the WiFi encryption itself. If there are, someone can easily monitor your wifi and decrypt it if they know how. There’s a number of encryption algorithms that should be avoided because they are known to be cracked. No idea if any are part of WiFi but some have been common with things like ssh where security can be negotiated from a whole list of encryption methods. If there’s a weakness, your password may not even matter.

I don’t in any way mean to say security isn’t important. It’s just that fairly simple methods keep out most who would attack over the wire or over WiFi where the attacker has also got to be close by. If you are being targeted by someone with skillz, you have bigger issues.

The easiest way to be compromised is by inviting the vampire in by clicking links, opening suspicious emails, and even just happening to visit “watering hole” compromised websites.

[Olias]

@RocketSled

the security of your computer network only needs to be as good as the security of the building it’s in.

I have to vehemently disagree on this point my friend. A cybercriminal—against whom we strive to protect our Wi-Fi—is nothing like a burglar or home invader. Cybercrime is driven by a mindset of clandestine intrusion, operating with stealth and precision. Cybercriminals have no interest in physical walls, just as a burglar has no interest in the data on your hard drive. The analogy simply doesn’t hold.

Cybersecurity best practices demand minimizing one’s digital footprint in cyberspace at all times. While a 64-character passcode might seem excessive, the vulnerabilities of other devices on the LAN cannot be ignored.

A Benchy may not be worth stealing, but sensitive information such as bank records or home office data on the same network absolutely requires a higher level of protection. No one should be forced to weaken their entire network security perimeter just to accommodate the botched design of Bambu’s TCP/IP implementation—and they know it. Why do you think they rushed out LAN mode last year? It wasn’t a solution; it was a stalling tactic to quiet criticism. Once they bought themselves time, they did nothing—neither tightening security nor improving Wi-Fi stability, as countless posts have pointed out.

Bambu Labs gets no free pass. Their apathetic approach to security, combined with their authoritarian stance on blocking user modifications, is both irresponsible and user-hostile. They have a choice: lead, follow, or get out of the way. Blocking users who seek alternative methods reeks of arrogance—hubris so extreme it’s like comparing Elon Musk to Gandhi.

[krellboy]

@Olias

No one should be forced to weaken their entire network security perimeter just to accommodate the botched design of Bambu’s TCP/IP implementation

The point other people are making is that the longer password doesn’t meaningfully increase the security, so he isn’t weakening his security in any practical sense by using a shorter key. A 16 character password would need 44012666865176569775543212890625 tries to crack it, and I’m guessing you might practically be able to do 1 attempt per millisecond.

[Olias]

@krellboy

The point other people are making is that the longer password doesn’t meaningfully increase the security

How does that make sense? If longer passwords weren’t more secure, every website or banking institution would allow passwords of any length. The NIST standard of 8–12 characters exists for a reason, as does the WPA spec allowing up to 63 characters.

The bottom line is this: why should users be forced to downgrade their WPA password strength for a single vendor’s device when the rest of the industry has adhered to these standards for the past 20 years? Simply put, why should Bambu get a pass for such egregiously lax implementation?

If your point was that a password alone cannot fully secure a network, that is true. However, cybersecurity is about layers, and no network can be secure without ensuring every point of ingress is locked down. That’s the gist of the OP’s desire to use long passwords. Bottom line: he shouldn’t be forced to compromise on this just because Bambu can’t get its act together.

[krellboy]

@Olias

How does that make sense? If longer passwords weren’t more secure, every website or banking institution would allow passwords of any length. The NIST standard of 8–12 characters exists for a reason, as does the WPA spec allowing up to 63 characters.

Longer passwords are more secure, they just aren’t MEANINGFULLY more secure. There isn’t any advantage to a password that takes 100 times longer than the life of the universe to crack vs one that takes 5 times the life of the universe.

The reason it supports 63 characters are because some people choose phrase passwords like “correcthorsebatterystaple”, but he is choosing passwords like “F^%B56okMEok.mI” which is a very different thing.

[pfurrie]

I did get a reply to my ticket, and this gets very interesting… stick with me…

They requested that I first try connecting the printer to my mobile phone hotspot. Then say I should try a shorter password. I grind my teeth but try some experiments… here is the reply I sent to them after doing the tests:

Problem is much worse now… read on.

As you requested, I tested the printer with my phone as a hotspot. Connected with a short password:
123456789a123456789b123456789c123456789d

That password was easy to type in an easy to keep track of the length. Restarting the printer also worked okay, though on a couple rounds of testing, the printer didn’t retain any memory of being connected to that network at all – when re-selecting the network, was not provided with the option to “forget”. This is another issue, but let’s move on with the bigger issue.

I increased the length of the password in steps, finally reaching 63 characters:
123456789a123456789b123456789c123456789d123456789e123456789f123

The printer connected, AND it retained the connection through a power cycle. Okay, we’ve shown that the length of the password is not the issue.

The original password contains a “pipe” character - | . That is not a lower-case L and not a one (1), but a vertical line symbol. It is more unusual, so thought I’d test just that:

123456789|

The printer connected just fine, and retained the password after a power-cycle.

Next, I created a new password based on only the special characters that exist in my original 63-character password. Here is that new password:

?/*-;"!>(^($=|.'~:%,#

Note: this leaves out all the letters and numbers from the original password, so I’m not worried that you have this.

Here where it gets interesting, and worse. At first, this connected to the hotspot network. Good, so far. Then I restarted the printer. Went back to the network screen. I’ve attached a picture of the screen…

So, at this point, NO networks are displayed. None. Previously, there had been 12 networks detected from our neighborhood.

Power-cycled again, including unplugging the power cord for ten seconds. Plug it back in and power it on. Same.

Next, I went to the phone and changed the hotspot password to:
123456789

Then on the printer, tried to manually connect to the hotspot:
SSID: Proxima
Password: 123456789

Won’t connect. Tried a second time. Refuses to connect… fails.

Changed the hotspot password to:
password

Again, on the printer, tried to manually connect to the hotspot:
SSID: Proxima
Password: password

Same failure.

Soooooo… it seems the Wi-Fi networking component of the printer has been bricked by entering a password of special characters… and it isn’t even a particularly long password.

I only have one printer. Can’t test this with another one. You, on the other hand, make the printers and have access to many. You can test this with one of your printers (if you dare).

Also… you asked for me to provide a log file. But I DID provide one in my original post for this ticket. Did you not look at the attachments?

At this point, I’m screwed (thank you very little). The printer is not just incredibly inconvenient (having to re-enter that original password), but won’t connect to network at all.

Your turn.

So yeah, now the printer can’t be used over the network. Pretty sure there is a factory reset procedure, but I first want to find out how they reply.

On other matters…

Look, when I ask for no password-shaming in the OP, why then do it? It isn’t productive. I’m playing by the rules of what the Wi-Fi password length is by the standards. And using characters that are allowed. The company should just make sure their software routine for handling this generic task plays well with others and move on to the interesting stuff.

As far as Bambu Labs not paying attention… that’s another matter.

[Olias]

@pfurrie

but I first want to find out how they reply.

Thanks for sharing these details.

Your story is a window into how the minds at Bambu Labs work; just hack it together until it’s “Chabuduo” (差不多).

Bambu should thank you not only for being patient in this test case but also for schooling them in basic Computer Science! What you’ve effectively done is demonstrate extreme test cases that “break” their algorithm. That is precisely what software testing is supposed to do. I once worked for a company that performed software maturity testing services to the RTCA DO-178B standard, which the commercial aerospace industry uses to certify that the underlying control code in cockpit avionics is “sound.” Why such detailed testing one might add and is it really necessary? Well… at 34,000 feet, there’s no CTRL-ALT-DEL – it has to work 100% of the time, with no glitches.

Now, I’m not saying their firmware needs to be as robust as, say, aircraft engine control software, but come on—passwords and Wi-Fi connectivity? It’s not like we’re curing cancer or landing a robotic rover on Europa. This is basic “network appliance 101” design and engineering, and you’re absolutely right to call Bambu out on their glaring lack of engineering professionalism. Frankly, they should be embarrassed, but we all know that as long as the cash keeps rolling in, nothing will improve. If they’re smart, they’ll take what you just gave them for free and incorporate it into their firmware validation test suite.

[pfurrie]

Yep, for sure. Too bad this had to go from bummer to brick (well, brick-like).

I get it that what we have here is an edge case, but it has gone from “hey dude, you’re using too long of a password!” to “oh damn, just 21 character password toasts the printer” problem. Geez, I thought I’d be able to manually connect, and then maybe back it out of its current snit.

Now… since all of those special characters are in the original Wi-Fi key, the presence of any of them apparently isn’t a deal-breaker. And it would be highly improbably that this particular string of characters is the only one that would brick the printer… who could get that unlucky on their first try?!

So, what aspect of the brick password is offensive? The question mark at the beginning? The percent sign? Dollar sign? Some escape code that was unwittingly entered?

I’m betting the period, comma, and hyphen are all OK… they are just too common. Basically, what would be the testing protocol going forward?

Here’s another thought: perhaps this had nothing to do with this password, but was something to do with some other glitch. Nah, I’m going with: there is an errant escape code in there that isn’t handled gracefully when it is re-read from memory when the printer is booting up. The boot code retrieves all of the configuration info from some file and parses it. Something with the parser chokes on some character combination, polluting the Wi-Fi routine.

[Olias]

@pfurrie

Here’s another thought: perhaps this had nothing to do with this password, but was something to do with some other glitch.

One possible alternative to a path to self-recovery of the brick… errr I meant Printer… is to consider doing an offline firmware update using the SD card that Bambu recently started to support. This method should allow one to restore the firmware back to its pristine factory state… or so one would hope. My confidence in Bambu is very shaky.

https://wiki.bambulab.com/en/general/update-firmware-from-sd-card

[MZip]

@pfurrie

Some escape code that was unwittingly entered?

That’s my guess. You have to trap those and make sure you code in ways they don’t matter. It’s easy to miss that.