[BUG] Lines that include # are treated as comments even when using quoted INI strings

[Swizzler121]

Printer model

MK3.5

Firmware version

6.1.2

Upgrades and modifications

None

Printing from...

N/A

Describe the bug

When filling out the prusa_printer_settings.ini if you are using a password (or any other key I assume) that begins or includes a # symbol, it's treated as a comment, even when in a quoted string (Feature added in latest update #3158).

Example config:

[wifi]
ssid = example ssid
psk = "#examplepsk"

I first noticed the issue in a previous firmware but had an alternative network at the time with a different psk that avoided the issue. When I saw the above mentioned feature I decided to try again, just to find this is still an issue.

This firmware update does include a way to manually enter the password using the screen, and using that you are then able to join networks that include a # in the login details, but compatibility with the prusa_printer_settings.ini file would be preferable.

How to reproduce

Join a network with a PSK that includes a # sign by loading the prusa_printer_settings.ini file

Expected behavior

It successfully loads the correct settings from the prusa_printer_settings.ini file and joins the wifi network successfully.

Files

No response

[danopernis]

Yeah, I agree with you, this is a bug.

The thing is, the INI parser is based on https://github.com/benhoyt/inih and that is quite difficult to modify. Proper solution to solving this bug would most likely involve complete rewrite of the INI parser and that will take a lot of time, which would be better spent on solving other bugs and creating new features. Therefore, I don't think we will get to work on this anytime soon. If anybody wants to contribute proper parser based on proper tokenization and formal grammar, I would be happy to discuss details.

In the meantime, as a workaround, please use other means of entering the password, like the Prusa App or on-screen keyboard.

[bkerler]

@danopernis This doesn't seem to be caused by the ini parser. The handler does interpret the value correctly as "#examplepsk" and does run espif_join_ap(ap.ssid, passwd) with passwd being set to "#examplepsk".

[bkerler]

@Swizzler121 it does seem that this is no bug. In fact, the quotation marks are treated as password letters. So if you define the password without quotation marks :

[wifi]
ssid = example ssid
psk = #examplepsk

it should work as expected.

[Swizzler121]

It did not work without quotes either, like I said i initially ran into the bug trying to use it as shown above without quotes, but when that failed I did some searching and saw the bug about allowing quoted lines, so I waited for that to be merged to try again.

I've also tried on two pieces of networking hardware with two different passwords that started with a # sign, one on a meraki network and another on a unifi access point.

Like I also said it did work when manually entering the password using the screen interface, so the AP connection SHOULD work but isn't when using the .ini parser for some reason.

[bkerler]

@Swizzler121 I tried using your example ssid and psk and it works as it should with fw 6.1.2, it isn't treated as comment. Instead it treats quotation marks as password chars. Update: It turned out to be a problem, depending on the content of the ini file.

[Swizzler121]

Is the a way to pull an error off the printer so I could see why it's failing in my case then? could be another unknown bug? I assumed it was the # as it was leading the password field and was the only special character, and occurred across two passwords that shared that trait even though they were being broadcast by different hardware.

(also want to re-iterate that it connects fine to the network when using the on-device network join function, so isn't some incompatibility with the network configuration.)

[bkerler]

I'm now having similar issues if the ini is just containing those values without the network fields ... need to dig deeper into this.

[bkerler]

Ok, I was now able to fully identify the issue and wrote a PR #4175 for it.
It seems that even if the same values are accepted with ini files with network field, in some variants the value fields are indeed misinterpreted as inline comments, leading to a nulltermination if the value starts with "#". This shouldn't be the case.

[bkerler]

Sorry for causing so much trouble in the beginning, glad I finally was able to hunt down the issue properly :)