Bug 707406

Summary: does not reconnect to the network (GnomeShell fallback mode; hidden ESSID; WPA2 Personal)
Product: [Fedora] Fedora Reporter: Roman Polach <r0polach>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 15CC: collura, dcbw, huffman, jklimes, joshuacov, mikethepsych, nsoranzo, ogre, RedHat-User, roryrogerson
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: NetworkManager-0.8.9997-4.git20110620.fc15 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-05 14:46:37 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
fix auto-connect feature for hidden SSIS
none
fix auto-connect feature for hidden SSIDs none

Description Roman Polach 2011-05-24 19:20:31 EDT
System does not automatically reconnect to the network (wireless; with hidden ESSID) after login.
One must click the applet and select "Connect to Hidden Wireless Network".
Then last used ESSID *is* in the list and when user select it, it also shows that it remember password (WPA2 personal) and then it finally connects.


Version-Release number of selected component (if applicable):
Fresh F15 installation. Default network "applet".


How reproducible:
Yes.


Steps to Reproduce:
1. Connect to hidden wireless network, set WPA2 personal password...
1. Log out and Log in again into system.
2. Wait if it connects to the network.
  
Actual results:
It does not connect automatically.

Expected results:
It should connect automatically.

Additional info:
Gnome is used in fallback mode (not sure if this is relevant)
Comment 1 Jirka Klimes 2011-05-27 11:46:51 EDT
Created attachment 501331 [details]
fix auto-connect feature for hidden SSIS
Comment 2 Jirka Klimes 2011-05-27 11:58:29 EDT
In F14 (NM 0.8) most WiFi connections were kept as user connections. The user setting service took care of updating networks' BSSIDs, which are needed for auto-connecting to hidden networks.

NM 0.9 removed the user setting service and the setting service inside NM don't update the BSSIDs.

The patch in comment #1 handles that.
It keeps the BSSIDs separate from the connection (similar to timestamps), because
updating it in the connection would force touching files in /etc (even if not as often as for timestamps).
Maybe we should merge "seen-bssids" file with "timestamps" into a single database file.
Comment 3 Dan Williams 2011-06-02 15:23:30 EDT
One suggestion I have would be to use ',' as a separator instead of ';' since using ';' makes it hard to visually distinguish the items in the list especially if they are MAC addresses.  The of course we'd set the separator char using g_key_file_set_list_separator() when reading it in.

Second, I don't know if we should bother sending the seen-bssids back out in the GetSettings() reply since the key was only ever intended to be used by user settings services to send the info to NM; now that it's stored in NM maybe we can just deprecate that setting value entirely?  I can't really think of a good reason to expose the bssid cache to normal apps; you can't use it for location services since the BSSIDs are not guaranteed to be in the same physical location, and perhaps we shouldn't expose the list anyway, see the recent new about Apple iOS and Android location caching and privacy.  Thoughts?

If we're not sending the BSSIDs back out in GetSettings(), then we could also make the code a bit more efficient by doing the conversion from struct ether_addr -> char* only when reading/writing the database, instead of doing it every time manager_hidden_ap_found is called, which will likely be more often than we update the DB.  However, we may be writing the DB more often too when roaming, so I don't know if my suggestion ends up being more efficient or not...

Next, if we want to keep this stuff more encapsulated and not use NM_IS_DEVICE_WIFI() we could put this code into activation_success_handler() in nm-device-wifi.c.  We also probably want to update the BSSID cache from set_current_ap() or periodic_update() so that we catch the BSSID when the wifi card roams.

Other than that, patch looks good and the architecture seems fine to me as well.
Comment 4 RedHat-User 2011-06-05 14:54:35 EDT
I have a very similar problem with my Fedora 15 x86_64 install on a Lenovo Thinkpad X120e.  My difference is that I cannot even initially connect to a hidden WPA2-Personal-secured wireless network without using root powers.

STEPS TO REPRODUCE:

1.  Boot up laptop without the wired connection.  Login as normal user.

2.  Left-click the NetworkManager icon.  (Currently a red "no" sign because of no wired network.)  Note that the "Enable networking" and "Enable wireless" boxes are checked.  Left-click the "Manage Connections..." button.

3.  In the window that appears, left-click the "Add..." button under the Wireless tab.

4.  In the window that appears, enter the hidden network's name in the "Connection name" and SSID fields under the Wireless tab.  Under the "Wireless Security" tab, change the security field to "WPA/WPA2 Personal".  Enter the WPA2-Personal password into the password field.  Left-click the OK button.

5.  The hidden network is now listed under the Wireless tab.  Left-click the OK button to close the Manage Connections window.

6.  Back at the desktop, again left-click the NetworkManager icon (still a red "no" sign).  The hidden network is not shown.  Left-click the "Show More..." button.  The hidden network is not shown.

Note:  I also tried the above with the hidden network's profile's "Connect automatically" box checked, but it still did not work.

7.  Open a terminal window and execute "sudo su -" to become root.  As root, execute the "iwlist wlan0 scan essid spynet" (where "spynet" is the name of the hidden network) command.

8.  Back on the normal user's desktop, left-click the NetworkManager icon; the connections area now shows the hidden network.  Left-clicking on it now connects to it.

Rebooting the computer and logging back in as the normal user, one does not see the hidden network in NetworkManager's connection area.  One does see an area to type in a hidden network name.  Typing in the name and pressing return results in nothing happening.  (The cursor stays in the text field.)

Surprisingly, root executing "iwlist wlan0 scan essid spynet" doesn't work like it did before.  But restarting the NetworkManger daemon ("service NetworkManager restart") and then running the iwlist command does.
Comment 5 Jirka Klimes 2011-06-06 13:09:32 EDT
(In reply to comment #3)
> One suggestion I have would be to use ',' as a separator instead of ';' since
> using ';' makes it hard to visually distinguish the items in the list
> especially if they are MAC addresses.  The of course we'd set the separator
> char using g_key_file_set_list_separator() when reading it in.
> 
Done.

> Second, I don't know if we should bother sending the seen-bssids back out in
> the GetSettings() reply since the key was only ever intended to be used by user
> settings services to send the info to NM; now that it's stored in NM maybe we
> can just deprecate that setting value entirely?  I can't really think of a good
> reason to expose the bssid cache to normal apps; you can't use it for location
> services since the BSSIDs are not guaranteed to be in the same physical
> location, and perhaps we shouldn't expose the list anyway, see the recent new
> about Apple iOS and Android location caching and privacy.  Thoughts?
> 
Done.
Yeah, we probably don't have any use for the list of BSSIDs.

> If we're not sending the BSSIDs back out in GetSettings(), then we could also
> make the code a bit more efficient by doing the conversion from struct
> ether_addr -> char* only when reading/writing the database, instead of doing it
> every time manager_hidden_ap_found is called, which will likely be more often
> than we update the DB.  However, we may be writing the DB more often too when
> roaming, so I don't know if my suggestion ends up being more efficient or
> not...
> 
It's not evident what attitude is better from performance point of view. So letting it as it is for now. It can be adjusted later.

> Next, if we want to keep this stuff more encapsulated and not use
> NM_IS_DEVICE_WIFI() we could put this code into activation_success_handler() in
> nm-device-wifi.c.  We also probably want to update the BSSID cache from
> set_current_ap() or periodic_update() so that we catch the BSSID when the wifi
> card roams.
> 
Done.
But, I'm not completely sure where to get the right BSSID from. I use current_ap, which should contain active AP on active device. Is it the right value or shall we rather use nm_device_wifi_get_bssid()?

Dan, feel free to update the patch as you see fit.
Comment 6 Jirka Klimes 2011-06-06 13:10:46 EDT
Created attachment 503293 [details]
fix auto-connect feature for hidden SSIDs
Comment 7 Jirka Klimes 2011-06-09 02:31:50 EDT
Upstream fix is 9549c70d943e3709694c4b0eb2595af11962c0eb
Comment 8 Nicola Soranzo 2011-06-09 13:14:55 EDT
Is this the same bug as #691139 ?
Comment 9 Jirka Klimes 2011-06-13 04:55:36 EDT
(In reply to comment #8)
> Is this the same bug as #691139 ?

Hmm, not exactly. I think the main problem of 691139 is an usability issue -
there's no means to connect to a hidden network via gnome-shell applet. One has
to go to control-center and activate it there (after the connection is created
in nm-connection-editor).
Comment 10 Joshua Covington 2011-06-23 05:16:35 EDT
I'm experiencing the same issue after upgrading to the latest 0.8.9997-4.git20110620. The previous version 0.8.9997-3.git20110613 did fix this but after the update I see the "hidden" ssid as a normal ssid and nm doesn't connect automatically. The connection should be initiallized manually by myself.

Maybe this is connected to https://bugzilla.redhat.com/show_bug.cgi?id=710502 
I changed NetworkManager-wait-online.service to --timeout=7  but this doesn't fix the automatic connection issue.
Comment 11 Jirka Klimes 2011-06-28 04:20:06 EDT
*** Bug 703471 has been marked as a duplicate of this bug. ***