If a WPA password containing a hashmark (#) is entered into either the NetworkManager applet or the System -> Preferences -> Network Connections UI, the password is accepted and the wireless link is successfully authenticated and brought up, but upon reboot the password is truncated at the hashmark and the wireless connection does not successfully authenticate until the full password is manually re-entered. There are no keyfiles under /etc/NetworkManager/system-connections, but I just barely "chmod 600"'d .keep_net-misc_networkmanager-0 and don't know if that will change this behavior. Reproducible: Always Steps to Reproduce: 1. set wireless password to a string containing a hashmark (e.g. "G#NTOO L!NUX") using Network Connections UI 2. reboot 3. view password in Network Connections UI Actual Results: password is "G" Expected Results: password is "G#NTOO L!NUX"
Confirmed, this is a bug in networkmanager's wpa_supplicant.conf file parser. As a workaround, for now, you can edit /etc/NetworkManager/nm-system-settings.conf and change "plugins=ifnet,keyfile" to "plugins=keyfile". This will force networkmanager to use its own keyfiles instead of attempting to read and write openrc and wpa_supplicant configs.
Yes this is a bug caused by wpa_parser.c. Our parser is not smart enough right now to perfectly work with quotes. It simply treats all # as the start of comments. There is no simple solution to this so I have to suggest you follow Alexandre's advice. I'll leave this bug open to see if there is any better idea.
(In reply to comment #2) Actually, I already wrote a patch for this: https://bugzilla.gnome.org/show_bug.cgi?id=670381 I am going to add it to the next networkmanager-0.9.2.0 revbump, which will be coming as soon as I have something resembling a solution for bug #402085.
Well I think that works for most cases. I might be a bit excessive but what if the password contains double quote ("Ge\"#too" for example)? And I'm not sure if we should also deal with single quote. Single quote and double quote might be mixed. Things always get tricky when bash quotation is involved :P.
(In reply to comment #4) wpa_supplicant.conf is not a bash script; it has its own syntax. My patch treats the '#' character in wpa_supplicant.conf strings the same way that wpa_supplicant's parser does it. See wpa_config_get_line() in wpa_supplicant/config_file.c in wpa_supplicant-0.7.3.
Thanks for reporting the issue, it should be fixed in networkmanager-0.9.2.0-r4. >*networkmanager-0.9.2.0-r4 (20 Feb 2012) > > 20 Feb 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > +files/10-openrc-status-r1, +networkmanager-0.9.2.0-r4.ebuild, > +files/networkmanager-0.9.2.0-ifnet-password-truncated.patch, > +files/networkmanager-0.9.2.0-init-provide-net-r1.patch, > +files/networkmanager-0.9.2.0-pre-sleep.patch: > Fix openrc service going inactive while active connections are present (bug > #402613, thanks to Thomas Witt). Try to be more user-friendly by waiting a > few seconds before marking the service as inactive. Dispatch a pre-sleep > event to unmount network filesystems before suspending (bug #402085, thanks > to Marien Zwart). Do not truncate WPA passwords at '#' character (bug > #402133, thanks to John Hardin).
(In reply to comment #6) > Thanks for reporting the issue, it should be fixed in > networkmanager-0.9.2.0-r4. > > >*networkmanager-0.9.2.0-r4 (20 Feb 2012) > > > > 20 Feb 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > > +files/10-openrc-status-r1, +networkmanager-0.9.2.0-r4.ebuild, > > +files/networkmanager-0.9.2.0-ifnet-password-truncated.patch, > > +files/networkmanager-0.9.2.0-init-provide-net-r1.patch, > > +files/networkmanager-0.9.2.0-pre-sleep.patch: > > Fix openrc service going inactive while active connections are present (bug > > #402613, thanks to Thomas Witt). Try to be more user-friendly by waiting a > > few seconds before marking the service as inactive. Dispatch a pre-sleep > > event to unmount network filesystems before suspending (bug #402085, thanks > > to Marien Zwart). Do not truncate WPA passwords at '#' character (bug > > #402133, thanks to John Hardin). Any possibility of also getting the patch applied to 0.8.4? The 0.9 series _is_ masked at the moment...
