[Server-devel] Hidden SSID and Proxy settings

[Jerry Vonau]

On Fri, 2011-03-04 at 15:34 +1100, James Cameron wrote:
> On Thu, Mar 03, 2011 at 09:55:26PM -0600, Jerry Vonau wrote:
> > On Thu, 2011-03-03 at 14:47 +1100, James Cameron wrote:
> > > On Wed, Mar 02, 2011 at 10:38:07PM -0500, Dr. Gerald Ardito wrote:
> > > > Both methods work within a session.
> > > > In GNOME, I can connect to the hidden network. And, if I change back
> > > > to Sugar, the connection is intact.
> > > 
> > > Yes.  NetworkManager still has knowledge of the hidden network
> > > connection request in memory, having been told about it by the GNOME
> > > nm-applet.
> > > 
> > > (Restarting NetworkManager at this point causes the connection to drop
> > > and not be re-established.)
> > > 
> > 
> > Well sort of, if you restart MN in a terminal in GNOME, ...
> 
> I was specifically talking about when the user has switched back to
> Sugar.  That was the context.
> 
> > the connection is re-established, switch over to sugar the AP icon has
> > the ESSID populated. This works if "Available to all users" was ticked
> > as NM sees this as a system connection under root's control. Now open
> > terminal in SUGAR and restart NM, now the ESSID is set to "None".
> > While un-ticked you will be prompted for the info, which is saved in
> > connections.cfg.  The difference might be that in GNOME you have
> > gnome-keyring running while in SUGAR it's not. There is the question
> > of who owns the connection while setup as an ifcfg file, root or olpc? 
> 
> I don't see where you are going with this, and I don't see how it is
> relevant to Gerald.  So I'll try explaining things in the hope that our
> mutual cognitive disconnect will eventually show up.
> 
> Some D-Bus service must provide the NetworkManagerSettings interface
> from which NetworkManager obtains the list of connections or a new
> connection.  The interface specification shows this:
> 
> http://projects.gnome.org/NetworkManager/developers/spec.html#org.freedesktop.NetworkManagerSettings
> 
> When GNOME is active, this is done by the panel applet.
> 
> When Sugar is active, this is done by the Sugar shell, in the source
> file jarabe/model/network.py
> 
> Upon restart, without a settings service, NetworkManager will not know
> about the user request to join the hidden network.  This also happens on
> boot.
> 
> Once Sugar is started, NetworkManager is informed (through the settings
> service in Sugar), of the user's request to connect.
> 
> > > > When I reboot, however, while the Wireless Connections UI (iin either
> > > > GNOME or Sugar using nm) shows the connection properly, it does not
> > > > actually connect to the hidden ssid.
> > > 
> > > Yes, I agree.  After reboot, NetworkManager is restarted, and therefore
> > > no longer knows about the hidden network connection request.
> > > 
> > 
> > Agreed, I'll look for how "Connect to Hidden Wireless network" runs its
> > re-scan for the hidden network in the code. 
> 
> It doesn't do a wireless scan for hidden networks.  It only offers a
> hidden network in the "Connect to Hidden Wireless network" if one was
> created by the user.  If that network is deleted from the settings
> service using "Edit Connections...", then "Connect to Hidden Wireless
> network" does not offer it.  Tested.
> 
> > > The ONBOOT setting doesn't appear to work either.
> > > 
> > 
> > On an un-hidden network it does, or at least loaded as the UI becomes
> > usable.
> 
> Why should it wait for the UI to become usable?  That sounds like it is
> waiting for the settings service to register with D-Bus.  Therefore it
> is not using ifcfg as such.


That is part of the problem, ifcfg-rh plugin, nm-applet knows how to use
the info while sugar does not. What is needed it to use NM keyfile
plugin so there is a common method of storing system level info between
sugar and gnome. Here is what I did, get into gnome, stop the NM
service, edit /etc/NetworkManager/nm-system-settings.conf using keyfile
in place of ifcfg-rh, restart NM. Now go configure your hidden network
ticking both of the boxes. That will create system level config file
in /etc/NetworkManager/system-connections/<name> that will be used by NM
upon boot. Reboot back into gnome, the settings should stick bringing
the network up and not ask for a password. Switch over sugar, the icon
for the AP should be connected. Reboot, while in sugar, when sugar
returns you should be auto connected to your hidden network.     
  

> > Gerald, does your AP have any security or is it just hidden?   
> 
> For what it is worth, my test AP on which ONBOOT did not work, has no
> security, it is just hidden.
> 
> I agree with Gerald, the issue is now one of persistence.
> 

Think we should ditch the ifcfg-rh plug-in in favor of using NM native
system support. This would mean tweeking network.py to write out the
needed NM config file. 

Jerry