Re: LEAP development

[Dan Williams <dcbw redhat com>]

On Wed, 2006-03-15 at 15:50 +0100, Anders �tling wrote:
> I have tried to dig through the nm sources to see how much LEAP
> support is hidden inside. From what I can understand (I am not a
> gnome/glade coder), there is a LEAP dialog prepared in the glade xml.
> Any chance that this dialog could be activated within a near future?
> I'd love to help, but as I said, I feel a bit overwhelmed with all
> "infrastructure" that surrounds the gnome applet. 
> 
> Is there any guidelines on how to start getting involved in nm
> development? I have coded C and C++ for 20 years so I guess there is
> something that is still useful ..

There are 3 actors here:

a) NetworkManager (attempts and manages connections)
b) the client (tells NM to connect to something)
c) the info-daemon (caches successful connection information, and what
access points are authorized or not)

In the NM Gnome applet, both (b) and (c) are the same
program, /usr/bin/nm-applet.  But they don't have to be.

Steps:

1) client serializes authentication info into a dbus message
2) Client calls NM's "setActiveDevice" method via dbus, passing it the
serialized authentication information
3) NetworkManager attempts a connection with the authentication info
4) If successful, NM tells the info-daemon to cache the successful
authentication information with a "updateNetworkInfo" dbus method call

Client (applet) code
----------------------

The client has a couple of bits to the auth mechanism.
 
a) Need to add a LEAP auth mode to include/NetworkManager.h
#define NM_AUTH_TYPE_LEAP			0x00000040

b) A helper function to serialize the LEAP auth info into a dbus
message.  This should go in libnm-util/dbus-helpers.c.  Something like
nmu_security_serialize_wep_with_cipher().  Your "we_cipher" will be
NM_AUTH_TYPE_LEAP from (a).  Further arguments will be the identity and
password.

dbus_bool_t
nmu_security_serialize_leap (DBusMessageIter *iter,
                             const char * leap_identity,
                             const char * leap_password)
{
  <stuff the two char* args into the message>
}

dbus_bool_t
nmu_security_serialize_leap_with_cipher (DBusMessageIter *iter,
                                         const char * leap_identity,
                                         const char * leap_password)
{
  <stuff NM_AUTH_TYPE_LEAP in as the first message argument>
  <call nmu_security_serialize_leap() to serialize the rest>
}

You also need a deserialization function to pull the relevant stuff out
of a dbus message and return it.

dbus_bool_t
nmu_security_deserialize_leap (DBusMessageIter *iter,
                               char **identity,
                               char **passwd)

c) The Wireless Security Object (wso): this object is a subclass of the
WirelessSecurityOption object, which is defined in
gnome/applet/wireless-security-option.h.  Subclasses of the wso manage
the UI associated with the auth options, in the case of LEAP this is the
identity/username and password.  See gnome/applet/wso-* files for
examples, most of the code from others can be carried over to LEAP.  You
don't need a cipher here since LEAP doesn't hash anything.  The
wso-wpa-eap.c doesn't use a cipher either so that's a good example.

There's a function in the wso called append_dbus_params_func() that
should then call your LEAP serialization function from above,
nmu_security_serialize_leap_with_cipher(), with the relevant identity
and password.

d) Make sure your LEAP UI bits are enabled.  Look at
wsm_set_capabilities() in wireless-security-manager.c.  You probably
just want to unconditionally append LEAP.  If all access points that
support LEAP also advertise WEP, then maybe we can gate it with that
too.  This function here instantiates your WSO object, which itself find
the necessary UI resources from the .glade file.

In NetworkManager:
--------------------

NM uses the deserialization function (from b above) to retrieve the
info.

a) Create an NMAPSecurity subclass for LEAP.  See any of the
nm-ap-security-* files.
  - Your function nm_ap_security_leap_new_deserialize() should call
nmu_security_deserialize_leap() from (b) above in the client section.
  - You also need to be able to serialize the LEAP info into a dbus
message here, which you created a function for in (b) from above.
  - The last bit here is to be able to write the config to
wpa_supplicant.  That's pretty straightforward.
  - Your real_get_default_capabilities() function should return default
requirements that an AP must meet to be able to use this
security/authentication information.  Probably just return
NM_802_11_CAP_KEY_MGMT_802_1X.  A bit tricky here since AP's don't
advertise the fact that they can do LEAP.

I think that's it for NM as long as you've got the correct
serialization/deserialization functions in libnm-util/dbus-helpers.c


Info-daemon
----------------

For the GNOME applet/info-daemon, we stick info into GConf.  That means
you need a translator to convert from the deserialized data form DBUS to
GConf.  We also store sensitive info in the gnome-keyring, which is
where the LEAP password would likely go.

a) You need to create a subclass of the NMGConfWSO object.  See all the
nm-gconf-wso-* files for examples.
  - For example, in your nm_gconf_wso_leap_new_deserialize_dbus()
function, you'll want to deserialize the info from the dbus message,
using the functions you created in the client section, letter (b), and
apply those attributes to the NMGConfWSOLEAP object's private data.
  - Next, your nm_gconf_wso_leap_new_deserialize_gconf() function should
be able to pull the LEAP info out of GConf.  Don't worry about the
password, since that's handled for you by your superclass.
  - real_serialize_dbus() and real_serialize_gconf() stuff the info back
into dbus or gconf, respectively.

b) Add your item to nm_gconf_wso_new_deserialize_gconf() in
nm-gconf-wso.c so you can actually get instantiated when a request comes
along.  There may be a few more places you need to stick
NM_AUTH_TYPE_LEAP to make sure stuff gets through (I'm thinking of
places like nm_gconf_wso_set_we_cipher() here).


There's probably a few rough edges here, probably around the
gnome-keyring stuff.  But this is essentially the work that's required.
If you have any questions, both Robert and I have done all of this more
than once for all the security options so we should be able to answer
your question.

Dan