Re: supplicant-manager

[Dan Williams <dcbw redhat com>]

On Wed, 2006-11-29 at 13:06 +0200, Tambet Ingo wrote: 
> Hey,
> 
> I committed some changes to make NetworkManager HEAD compilable. It
> included Timo's dbus-1.0 fix and new glib marshallers for
> supplicant-manager (it tried to use the ones from the main src dir, but
> these aren't built until all managers are built).
> 
> Where do I get the dbus-able wpa_supplicant?

0.5.5 and later have the necessary dbus bits.  You'll have to get
nightly snapshots since anoncvs is still down.  Run it with:

wpa_supplicant -u    (plus any debug options like -ddd you want)

The '-u' is the magic "be a dbus service" flag.  You'll need to copy the
"dbus-wpa_supplicant.conf" file
to /etc/dbus-1/system.d/wpa_supplicant.conf and send DBus a SIGHUP.

Note that as of now, with CVS, you can't actually _connect_ to anything
with the supplicant-manager yet, I haven't hooked up the
NMSupplicantConnection objects, and I'm still thinking that object
through (including a rename).  I'd suggest putting a "return NULL;" at
the bottom of NetworkManagerPolicy.c's auto_get_best_device() function
so that you can investigate the supplicant functionality without having
NM spawn a copy of wpa_supplicant while trying to connect.

Here's some thoughts on how the connection process should go...

- if the NMDevice doesn't have a valid NMSupplicantInterface (ie, the
supplicant interface object is in the READY state), you can't connect at
all, and the connection request should immediately fail.  We need to
report this somehow, but I'm not sure yet.  We'll need to rework some
bits of activation in the near future to return more error information
that the applets can use.  Right now, for example, NM has problems if
dhcdbd is not running.  Eventually we'll use dbus activation for dhcdbd,
wpa_supplicant, and the VPN service daemons starting with DBus 1.1 and
later, but we don't have that yet.  For now we assume that the
wpa_supplicant dbus service _must_ be started and exist on the bus.

- The NMDevice (wireless first, we'll do the bits for 802.1x over wired
when new config framework stuff based on PolicyKit comes along) builds
up an NMSupplicantConnection object by creating it, then passing it to
all the NMAPSecurity subclasses, which add their own options to the
NMAPSecurity objects just like they do now in the
real_write_supplicant_config() function.

- The NMDevice sets the NMSupplicantConnection on the
NMSupplicantInterface, then schedules a timeout waiting for the
supplicant interface to connect

- The SupplicantInterface creates a new network (using the supplicant's
"addNetwork" dbus method), and stores the returned DBus object path of
that network.  We assume that for now, the SupplicantInterface can only
handle _one_ configured wireless network at a time, although
wpa_supplicant can have more than one.  We're not using wpa_supplicant
for network selection yet, if ever.

- The SupplicantInterface sets the network config on this new network by
building up a DBus dictionary of the options in a DBusMessage and
pushing those to the supplicant using the new network's "set" dbus
method

- The SupplicantInterface sets the "ap_scan" config value (using the
supplicant interface's "setAPScan" DBus method) for the interface based
on what the config is.  This might require more interaction from the
NMDevice, and perhaps the NMSupplicantConnection object should have a
completely separate config option for "ap_scan" that's not stored in the
hash table.

- The SupplicantInterface enables the network by calling the "enable"
method of the network (I'm not sure if this step is required, i.e. if
new networks are enabled by default).

- The SupplicantInterface calls the "selectNetwork" method of the
wpa_supplicant interface object, which causes wpa_supplicant to attempt
association with that network's config

- The SupplicantInterface object listens for the "StateChange" signal of
the interface, waiting for the state to change.  When the state changes,
it should store that new connection state, and emit a new
"iface-state-change" (or something) signal

- The NMDevice listens for the 'iface-state-change' signal from the
NMSupplicantInterface GObject, and if the device is undergoing
activation, and the state changes to CONNECTED, then the NMDevice
proceeds to the IP config stage of activation.

All of the DBus interfaction should be done with PendingCalls so that we
don't block anywhere.  That means a bit more choreography, but it's the
best way to do it, and the timeout on the NMDevice's supplicant
activation should take care of that.

I'm not entirely sure how activation cancellation should work, but I
think it would mean removing the network from the supplicant
("removeNetwork" on the supplicant interface dbus object) and maybe
disabling the network (the "disable" method on the supplicant network
object).  We may need to add some other DBus commands to wpa_supplicant
to support cancelling an in-progress association request.  I think they
are there already in the socket-based control interface, but not the
DBus control interface.

I think, based on this mail, that we should rename the
NMSupplicantConnection to something like NMSupplicantConifg.  I'd
originally thought that the Connection object would be the object that
tracked the connection from start->finish, but that's a bit complicated
for now, and the state tracking is already done in NMDevice.  So to keep
things simple, we'll just have the NMSupplicantConfig (formerly
NMSupplicantConnection) object limited to storing and validating
supplicant configuration tags.  It's really just hash table with
paranoid key/value pair validation.

The NMDevice's link state should be derived from the
NMSupplicantInterface state too.  The NMDevice's link is valid
if-and-only-if the device owns a valid NMSupplicantInterface object in
state READY _and_ if-and-only-if that NMSupplicantInterface object says
the wpa_supplicant thinks it's connected (by calling some new
nm_supplicant_interface_get_iface_state() function that tracks what the
supplicant's StateChange DBus signal sends out).

Once this bit is done, we can rip out 1000 lines of code for the
wpa_supplicant spawning, lifecycle handling, and log redirection.  That
will feel _very_ good.

I'm going to look into this possibly later this week, maybe on the
weekend.  But if anyone else wants to start on it, be my guest :)

Cheers,
Dan

> Tambet
> 
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list