[BUG] Can't connect to SSID starting with space

[Crocmagnon]

Bug description

Printer type - [MINI]

Printer firmware version - 4.4.0
Original or Custom firmware - Original

Optional upgrades - Filament Runout Sensor

USB drive or USB/Octoprint
N/A

Describe the bug
I can't connect the Prusa Mini to my wifi network. Its SSID starts with a space.

How to reproduce

• Create a wifi network with an SSID starting with a space
• Follow the guide to setup the wifi on the Prusa MINI
• Configure your wifi credentials in the prusa_printer_settings.ini file

I've tried the following config entries (with and without quotes):

[wifi]
ssid= REDACTED SSID
key_mgmt=WPA
psk=REDACTED_PSK

[wifi]
ssid=" REDACTED SSID"
key_mgmt=WPA
psk="REDACTED_PSK"

Expected behavior
The printer should connect to the wifi network.

I tried connecting it to another AP not starting with a space - tethering with my phone, and it works fine.

G-code
N/A

Crash dump file
dump.bin.zip

Additional analysis

According to the docs, the code parsing INI files strips whitespaces:

Prusa-Firmware-Buddy/lib/inih/ini.h

Lines 42 to 55 in 215bcf5

	/* Parse given INI-style file. May have [section]s, name=value pairs
	(whitespace stripped), and comments starting with ';' (semicolon). Section
	is "" if name=value pair parsed before any section heading. name:value
	pairs are also supported as a concession to Python's configparser.
	For each name=value pair parsed, call handler function with given user
	pointer as well as section, name, and value (data only valid for duration
	of handler call). Handler should return nonzero on success, zero on error.
	Returns 0 on success, line number of first error on parse error (doesn't
	stop on first error), -1 on file open error, or -2 on memory allocation
	error (only when INI_USE_STACK is zero).
	*/
	int ini_parse(const char* filename, ini_handler handler, void* user);

Parse given INI-style file. May have [section]s, name=value pairs (whitespace stripped)

The code that strips the whitespaces from the value is here:

Prusa-Firmware-Buddy/lib/inih/ini.c

Lines 195 to 196 in 215bcf5

	value = lskip(value);
	rstrip(value);

Also, from what I can see, there is no handling of quotes to delimit strings.

If I take my two config examples:

[wifi]
ssid= REDACTED SSID
key_mgmt=WPA
psk=REDACTED_PSK

This is parsed as:

{
    "ssid": "REDACTED SSID",
    "psk": "REDACTED_PSK",
    "key_mgmt": "WPA"
}

(missing leading whitespace)

[wifi]
ssid=" REDACTED SSID"
key_mgmt=WPA
psk="REDACTED_PSK"

While that should be parsed as:

{
    "ssid": "\" REDACTED SSID\"",
    "psk": "\"REDACTED_PSK\"",
    "key_mgmt": "WPA"
}

(with quotes not part of the SSID or PSK)

Spaces in SSID are valid, as you show in the guide, but they're also valid at the beginning and and of the string. I believe the same story is true for the PSK.

I understand the choice of stripping whitespaces because it would more likely be a config error, although I believe with sufficient documentation it could be allowed.
Or, we could have a config option in the printer menu "strip whitespaces while parsing INI". It would be enabled by default so the current behavior still remains the default one with the option to change it.

I'd love to try and remove the two incriminated lines and test on my MINI, but I don't have a broken tab to install custom firmware so I guess I'll wait 🙂

[chillygithub]

Using spaces in the ESSID or PSK is far from Best Practice. And should be avoided, as its is known to break many implementations of the wireless stack.

[Crocmagnon]

It may not be best practice but it’s definitely permitted by the standard 🙂
Since we’re in the process of building such an implementation, I propose supporting this behavior.

EDIT:
Quick note: I’ve previously successfully connected many ESP8266 to my wifi network so the hardware shouldn’t get in the way.

[laloch]

Hi @Crocmagnon, thanks for reporting. While technically you're right that SSID can be any binary string including non-printable characters as long as it fits 32 octets, practically there are probably no consumer devices allowing to do so. We will certainly discuss the issue and my vote will certainly be for sticking with Cisco SSID policy which explicitly disallows leading and trailing whitespace characters.

Edit: We should, however, definitely add an option to connect using BSSID to allow for connecting to "hidden" networks and networks with unsupported SSIDs.

[Crocmagnon]

I guess using the BSSID would be fine! 👍🏻

practically there are probably no consumer devices allowing to do so

You’d probably be surprised to know that I never had any issue connecting devices such as laptops, phones (even slightly older models), e-readers, ESP, AC unit, robot vacuum, smart home bridges or other smart home gadgets.

This is the first time I’m getting blocked because of the space 😊 (and it’s not even because the hardware doesn’t support it, it’s only because the config file parser wants to strip spaces 😅).

In the past I also experimented with emojis, but it was widely unsupported.

I understand that leading/trailing spaces are a recipe for failure though, but I used to live in a wifi crowded place and this was an acceptable solution to “always” display my SSID first in alphabetical order (also, now I have a bunch of connected devices and no intention of repairing everything).

[Crocmagnon]

Hi @laloch ! Thanks to the team for the RC1 release 😀
I noticed that the release notes didn't mention the BSSID capability. Have you had time to discuss the feature?

Thanks 🙂

[laloch]

Hi @Crocmagnon, we have the BSSID capability in our backlog. It is, however, scheduled for 4.5.0 at the moment.

[Crocmagnon]

Thanks for the feedback! 👍🏻 Looking forward to testing this on my network.

[nmschulte]

My SSID has a trailing space and I ran into this issue as well. Has this made it into the current release, v4.7.1; this doesn't seem documented if so; can we use it now? Otherwise, what is the status of the BSSID spec issue?

Supporting BSSID would work, but also unsure why a leading or trailing space does not: it seems like the code would have to be trimming the field rather than taking it verbatim (up to the new-line), which is odd to me.

[Crocmagnon]

it seems like the code would have to be trimming the field

that’s what it does

[nmschulte]

unsure why a leading or trailing space does not: it seems like the code would have to be trimming the field rather than taking it verbatim (up to the new-line), which is odd to me.

that’s what it does

So I discovered; thanks. I understand why this is the case now as well: https://en.wikipedia.org/wiki/INI_file#Keys_(properties)

I created a PR (#3158) in attempt to supported quoted string values, but I suspect this may get rejected. Another idea is to support escape sequences, allowing to use a Unicode escape sequence for the leading/trailing spaces, but for similar reasons I feel this may be unwelcome.

[lovemetwotimes]

SSID with spaces inside string also doesnt work.

[nmschulte]

SSID with spaces inside string also doesnt work.

SSIDs with internal spaces works fine for me.

[douglsmith]

Thanks @nmschulte. I'm hoping your PR is implemented because I have a long-existing Wi-Fi network with a PSK that ends in a space. Changing the PSK is not really an option because it would require reconfiguring about 100 other devices and convincing others that the change is worth that pain. This would be just to accommodate one MK4 that can't deal with a character that is allowed in the Wi-Fi specifications. No other device on our network has ever had an issue with this in over a decade of use.

[nmschulte]

we have the BSSID capability in our backlog. It is, however, scheduled for 4.5.0 at the moment.

v4.5.0 has long since passed. #3158 has received no attention. @laloch, will this issue ever be resolved?

[github-actions]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[Crocmagnon]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

Oh please no not you Prusa 😔
I can come here every now and then to comment. I can even setup a script to automatically post a useless comment regularly to keep this alive. No comment doesn’t mean the issue doesn’t exist anymore or people aren’t interested anymore. It just means that everything has been said and we’re waiting for a real implementation.

Either leave this open if you actually plan on implementing it someday or close it if you don’t but please, no stalebot 😩

[danopernis]

@Crocmagnon that's OK, we only needed to know if this was still active. Now that we know, I am assigning this so the stalebot won't touch it anymore.

We are planning to fix this using #3158 but I can't give you ETA yet.

[Crocmagnon]

Sorry, I've been bit by organisations using stalebot to massively close issues in the past and I'm quite bitter about it.
I shouldn't have reacted like this.

Thank you for your answer ❤️