piaware 10.1 wireless will fail if the password has an apostrophe in it

[bp0]

Updated to 10.1 SD card image and copied my working config over, but it would not reconnect.
Assumed it has something to do with the change from ifupdown to NetworkManager in bookworm.
It seems the piaware scripts truncate at the ' if it exists in the password, certainly a bug.
Fixed it in the NetworkManager connection settings, but after reboot, piaware changed it back to the broken version and it would still not connect.

[sjemmett]

10.1 also fails when password is a passphrase that has multiple spaces and the entire passphrase is enclosed in either ' or ".

[bp0]

Looking into it a little bit, I set the password in /boot/firmware/piaware-config.txt:

...
wireless-ssid "elsewhere"
wireless-password "A password I've set with spaces and an apostrophe."
...

piaware-config -showall shows the full password, quoted:

...
wireless-password              "A password I've set with spaces and an apostrophe." # value set at /boot/firmware/piaware-config.txt:49
wireless-ssid                  elsewhere                      # value set at /boot/firmware/piaware-config.txt:48
...

So it seems that the config file parser is reading it correctly.

But the file created by generate_network_config_bookworm.py, /etc/NetworkManager/system-connections/wireless.nmconnection, shows the truncated password:

[connection]
id=wireless
uuid=acc6cf97-9575-4f41-ad85-65af044288df
type=wifi
autoconnect=true
[wifi]
mode=infrastructure
ssid=elsewhere
[wifi-security]
key-mgmt=wpa-psk
psk=A password I
[ipv4]
method=auto
[ipv6]
addr-gen-mode=default
method=auto
[proxy]

After I use nmtui to set the password, wireless.nmconnection shows it properly:

psk=A password I've set with spaces and an apostrophe.

And it works, but the file will be clobbered on reboot by piaware's generate_network_config_bookworm.py script.

[bp0]

I should mention the workaround is to create a second connection, using something like nmtui, perhaps called wireless-fallback.nmconnection, that has the proper ssid/psk set and then let the connection created by piaware fail and fallback to the new one.

[resuna]

I suspect the problem is somewhere in this function:

https://github.com/flightaware/piaware-support/blob/master/flightaware_piaware_config/src/flightaware_piaware_config/piaware_config.py#L270

Which looks like it's doing some rather dodgy ad-hoc parsing.

[resuna]

This line in particular looks smoke-emitting:

https://github.com/flightaware/piaware-support/blob/master/flightaware_piaware_config/src/flightaware_piaware_config/piaware_config.py#L290

[mutability]

Dodgy ad-hoc parsing is unfortunately the name of the game here.

The canonical parser is this tcl code:

piaware/package/fa_piaware_config.tcl

Lines 582 to 629 in 0cea9bb

	proc unquote_value {text} {
	set text [string trimleft $text]
	if {[string length $text] == 0} {
	# empty string
	return ""
	}
	set quote [string index $text 0]
	if {$quote ne "\"" && $quote ne "'"} {
	# simple case, unquoted value
	# take everything up to an (optional) comment char
	# trim whitespace
	set commentChar [string first "#" $text]
	if {$commentChar >= 0} {
	set text [string range $text 0 $commentChar-1]
	}
	return [string trimright $text]
	}
	# complex case, quoted value with backslash-escapes
	# this is very relaxed: we just entirely ignore everything (comments etc) after the close-quote
	# and we also don't care if the value doesn't have a close-quote
	set out ""
	set escape 0
	for {set i 1} {$i < [string length $text]} {incr i} {
	set ch [string index $text $i]
	if {$escape} {
	append out $ch
	set escape 0
	continue
	}
	if {$ch eq $quote} {
	break
	}
	if {$ch eq "\\"} {
	set escape 1
	continue
	}
	append out $ch
	}
	return $out
	}

which (to simplify) handles two cases:

• An option where the option value string starts with ' or ". In this case, the option value is everything up to the next instance of the same quote character, except you can backslash-escape any character. Everything after the closing quote is entirely ignored.
• An option where the option value string doesn't start with a quote. In this case, the option value ends at end-of-line or a # comment character, and no backslash-escaping is done, and the option value has surrounding whitespace trimmed.

i.e.

wireless-password "abcd e f ''' \" some more "

should produce an option value of abcd e f ''' " some more (with a trailing space)

wireless-password abcdef' ghi   # this is my password!

should produce an option value of abcdef' ghi (with no trailing whitespace)

From a quick look the python implementation is missing the subtlety that a matching quote is needed to terminate the quoted case, not either type of quote

[mutability]

A possible workaround (that should continue to work after this bug is fixed) is to backslash-escape all quotes of either type within a quoted string in your piaware configuration.

i.e.

wireless-password              "A password I\'ve set with spaces and an apostrophe."

(you will need to manually edit that in the config file, piaware-config won't generate a line like that)

[bp0]

It's strange then that piaware-config -showall shows the password correctly, and that it worked in the previous version of piaware that used ifupdown instead of NetworkManager.

Escaping the apostrophe with \ did get the value written to wireless.nmconnection correctly.

[mutability]

The difference is because there are two implementations of the config-reading code (the original tcl implementation, and a newer Python implementation that appeared in 10.x). piaware-config and most of the existing system continues to use the original tcl implementation, only new code like the bookworm networkmanager-config-generating scripts are using the python implementation

[TechnicalLee]

Also had this problem, but with a backslash in the password instead of an apostrophe. Backslashes must also escaped in the piaware-config file, even if not using quotes.

pass\word has to be changed to pass\\word

[nikeflight]

Hi all,

We've pushed a new image 10.2 that should fix these wifi issues.

Side note:
NetworkManager expects any \ to be escaped; so we added logic to escape them automatically.
It seems like that's the only special character that needs any special treatment.

[bp0]

The full value for wireless-password in my old (pre-10.1) config file was copied correctly into /etc/NetworkManager/system-connections/wireless.nmconnection after reboot into 10.2.
So it seems the reported bug is fixed, for me at least.
Thanks.