A (very) brief tour of the OLPC 802.11s device class in NM r3246

Bill Mccormick billmcc at nortel.com
Tue Jun 17 10:06:47 EDT 2008

Hey Michael,

this may help a bit, it's a high level view of the nm concurrency model.
I found it pretty tough to understand what was going on until I had this

I know the code seems kind of hard to follow at first, but this is
mostly an artifact of using glib for thread communication, and gobject
for objects, etc.  Once you get used to glib things seem alot more clear

one of my big questions/comments is around the 802.11 mesh device.   It
more or less assumes control of network manager to decide what type of
connection the XO has.   I suspect it would be better to align the
802.11 mesh device with the other devices and put this control function
into NetworkManagerPolicy.c instead.   I think this is a good discussion
topic for moving forward.

my other trouble spot would be the error path handling.   Once in a
while we see odd nm behaviour & I suspect this is because of a lost
message from a driver or avahi or whatever.   we probably want to either
built in some global fallback which will always keep the network up, or
to go over the error paths in detail - or both.   This may have improved
a lot in the Fedora 9 nm, I haven't looked at that.   

I'll try and clean up the rest of my notes this week and forward them on
in case they can help.


-----Original Message-----
From: devel-bounces at lists.laptop.org
[mailto:devel-bounces at lists.laptop.org] On Behalf Of Michael Stone
Sent: Monday, June 16, 2008 11:11 PM
To: devel at lists.laptop.org
Subject: A (very) brief tour of the OLPC 802.11s device class in NM

Sjoerd and I started dissecting our NM-0.6 divergence so that we can
begin porting that necessary pieces of that divergence to NM-0.7.
Several highlights from our reading of two important files follow.
NM-specific terminology is /emphasized/.

nm-device-802-11-mesh-olpc.c [1] contains:

  * A nice description of the state machine currently used to decide
    change network associations. 

  * The flag-file MESH_STEP_FILE (/etc/NetworkManager/mesh-step)
    which can be used to alter the initial state of the aforementioned
    connectivity state machine.

  * The callbacks and setup/teardown logic on lines 536-661 which sync
    the 'scanning' flag between the /mesh device/ (a.k.a. the msh0
    network interface) and its /companion (wireless) device/.

  * Hoary netlink socket code (perhaps duplicating functionality of
    iwconfig?) in the second quarter of the file.

  * Hoary /mpp/ (mesh portal point) - http://tinyurl.com/4yxbyr
          /aipd/ (avahi-autoipd)    - http://tinyurl.com/43kygw   and
          device association logic  - http://tinyurl.com/4fstfh
    in the second half of the file.

  * The init method of the Mesh Device gobject class, showing off all
    the Device methods we have overriden.

nm-dbus-nm.c [2] contains:

  * The construction and implemenation of the D-Bus interface used by
    Sugar for /device activation/ (associating with networks) radio
       http://tinyurl.com/3fcabp, http://tinyurl.com/3ozy7n

More details to come,


Devel mailing list
Devel at lists.laptop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NetworkManagerConcurrency.pdf
Type: application/octet-stream
Size: 9968 bytes
Desc: NetworkManagerConcurrency.pdf
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080617/2ce30757/attachment.obj>

More information about the Devel mailing list