3 p.m.
Hello,
I ran into the following issue with connman recently. I would have prefered to open a Jira
ticket for that but I don't seem to be able to request access to
https://01.org/jira/projects/CM which is rather expected though. I hope this is the right
place to post this in this context, please someone tell me otherwise.
* Description of the issue:
connmanctl fails to connect to WiFi network having passwords ending with a backslash
character (i.e. '\').
See the following commands entered consecutively in bash on my machine (observe the
Passphrase value in both cat invocation on my network "settings" file):
LibreElec:~/.cache/connman/wifi_dca632348f72_50726574747920666c7920666f7220612057694669_managed_psk
# cat settings
[wifi_dca632348f72_50726574747920666c7920666f7220612057694669_managed_psk]
Name=My wifi network
SSID=50726574747920666c7920666f7220612057694669
Frequency=5180
Favorite=true
AutoConnect=true
Modified=2020-12-15T22:28:21Z
Passphrase="kjHTJ235nnM!0\
IPv4.method=dhcp
IPv4.DHCP.LastAddress=192.168.87.29
IPv6.method=off
IPv6.privacy=disabled
LibreElec:~/.cache/connman/wifi_dca632348f72_50726574747920666c7920666f7220612057694669_managed_psk
# connmanctl connect
wifi_dca632348f72_50726574747920666c7920666f7220612057694669_managed_psk
Error
/net/connman/service/wifi_dca632348f72_50726574747920666c7920666f7220612057694669_managed_psk:
Input/output error
LibreElec:~/.cache/connman/wifi_dca632348f72_50726574747920666c7920666f7220612057694669_managed_psk
# cat settings
[wifi_dca632348f72_50726574747920666c7920666f7220612057694669_managed_psk]
Name=My wifi network
SSID=50726574747920666c7920666f7220612057694669
Frequency=5180
Favorite=true
AutoConnect=true
Modified=2020-12-15T22:28:21Z
Passphrase="kjHTJ235nnM!0
IPv4.method=dhcp
IPv4.DHCP.LastAddress=192.168.87.29
IPv6.method=off
IPv6.privacy=disabled
The content of the setting file shown with cat differs between the 2 invocations as the
ending backslash char has been removed from the passphrase value in the second instance,
just after trying to connect the network with connman.
Please note that connman connects seamlessly on another network with a simpler password on
the very same WiFi router. Other Linux devices can connect to the network with a password
ending with a backslash as long as they don't rely on connman.
Also note that most modern WiFi tools (e.g. wpa_supplicant) offer the possibility to store
hashed passphrases rather than clear ones in their config files, for 2 good reasons:
1. It is safer and good practice to store a hashed password rather than a clear one;
2. a hash will never have any special character issue such as the one described in this
ticket.
For the story, the reason why I fiddled with connmanctl is that the LibreElec OS provides
a GUI for the WiFi settings (e.g. as a connectivity wizard on Kodi 1st start) which
initially failed on my network having a password ending with a backslash character,
whereas another network on the same router with a very simple password connected
successfuly.
As a side note, my WiFi password do start with a double quote character as well as ending
witht a backslash. I was not specifically looking for trouble but it seems I have been
very "unlucky" with the password generator I used at the time I setup the
network.
I have since plugged my rPi to my network via ethernet rather than WiFi for bandwidth
reasons so it is not a blocker to me anymore, but I believe I may not be the only one
hitting this wall so it may worth a look into.
* Additional info:
** package version(s)
1.38 (shipped on latest LibreElec distro for raspberry pi 4)
** Steps to reproduce:
Create a WiFi configuration for a network with a password ending with a backslash
character (i.e. Passphrase=<whatever_you_fancy>\) and try the commands listed
above.
Cheers
1:19 a.m.
New subject: connmanctl fails to connect to WiFi network having passwords
ending with a backslash character
Hi,
On Tue, Dec 22, 2020 at 12:00:03AM -0000, * * wrote:
I ran into the following issue with connman recently. I would have
prefered to open a Jira ticket for that but I don't seem to be able to
request access to https://01.org/jira/projects/CM which is rather
expected though. I hope this is the right place to post this in this
context, please someone tell me otherwise.
I've just cleanup all stale issues in the Jira. The idea was that we can
use it for new bugs reports. It's useless if we as community can't login
in. Furthermore, the configuration of this Jira is also targeted to
Intel's product development and has lot's of bells and whistles upstream
never will use.
Thus I was pondering to use something else. Obvious choice are a
gitlab/github but we don't need the rest they offer, especially the
workflow with PR, as the development happens here on the mailing list.
So I am not sure what to do here.
# cat settings
Passphrase="kjHTJ235nnM!0\
# connmanctl connect wifi_[...]
Error /net/connman/service/wifi_[...]: Input/output error
# cat settings
Passphrase="kjHTJ235nnM!0
We use GLib's key file API to read and write the settings file. The
problem might be we that we don't escape the special chars when writing
the passhphrase and later we retrieve it using a plain
g_key_file_get_string(). The documenation says
'... this function handles escape sequences like \s.'
So clearly we need to encode the string when saving it to settings.
Also note that most modern WiFi tools (e.g. wpa_supplicant) offer
the
possibility to store hashed passphrases rather than clear ones in
their config files, for 2 good reasons:
1. It is safer and good practice to store a hashed password rather than a clear one;
2. a hash will never have any special character issue such as the one
described in this ticket.
There was a lot discussion about this in the past. I can't remember why
we have decided to keep them in plain text though. Just note, to declare
'it's safer' without a context doesn't say anything. What's the
attack
vector, what is the asset, what does the attacker gain with it, ..w. are
the question to answer first.
As a side note, my WiFi password do start with a double quote
character as well as ending witht a backslash. I was not specifically
looking for trouble but it seems I have been very "unlucky" with the
password generator I used at the time I setup the network.
See it positive, you are good tester. You find the bugs!
I have since plugged my rPi to my network via ethernet rather than
WiFi for bandwidth reasons so it is not a blocker to me anymore, but I
believe I may not be the only one hitting this wall so it may worth a
look into.
Thanks for the report I'll think I know exactly where the problem is.
Daniel
6:12 a.m.
New subject: connmanctl fails to connect to WiFi network having passwords
ending with a backslash character
On Tue, Dec 22, 2020 at 11:19:05AM +0100, Daniel Wagner wrote:
> # cat settings
> Passphrase="kjHTJ235nnM!0
We use GLib's key file API to read and write the settings file. The
problem might be we that we don't escape the special chars when writing
the passhphrase and later we retrieve it using a plain
g_key_file_get_string(). The documenation says
'... this function handles escape sequences like \s.'
So clearly we need to encode the string when saving it to settings.
FYI, just sent out a patch which escapes the passphrase. Please give it
go and let me know if it works for you.
6:16 a.m.
New subject: connmanctl fails to connect to WiFi network having passwords
ending with a backslash character
Hi Daniel,
thanks a lot for the swift action on that, it is far beyond my expectations
as I did not even know about the community just a few days ago.
I'll test it and report back ASAP.
Cheers!
Boris
--
On Wed, 23 Dec 2020 at 15:12, Daniel Wagner <wagi(a)monom.org> wrote:
On Tue, Dec 22, 2020 at 11:19:05AM +0100, Daniel Wagner wrote:
> > # cat settings
> > Passphrase="kjHTJ235nnM!0
>
> We use GLib's key file API to read and write the settings file. The
> problem might be we that we don't escape the special chars when writing
> the passhphrase and later we retrieve it using a plain
> g_key_file_get_string(). The documenation says
>
> '... this function handles escape sequences like \s.'
>
> So clearly we need to encode the string when saving it to settings.
FYI, just sent out a patch which escapes the passphrase. Please give it
go and let me know if it works for you.
593
days inactive
594
days old
3 comments
3 participants
participants (3)
-
* * -
Boris *
-
Daniel Wagner