Network manager 0.7

OLPC OS v8.2.x uses a hacked version of NetworkManager-0.6.

NetworkManager-0.7 is now supported by Sugar, but does not support the mesh device found in the OLPC XO-1.

Sjoerd Simons and Daniel Drake have worked to add mesh support upstream in NetworkManager so that (hopefully) we do not end up in the same situation again. Mesh support also needs to be readded to the sugar UI.

NetworkManager-0.8

The first step is to add the device support to NetworkManager's development branch so that it hangs around in future. This is currently NetworkManager-0.8.

This work has been done. 5 of the 6 patches have been accepted upstream. The remaining one is http://thread.gmane.org/gmane.linux.network.networkmanager.devel/13710

NetworkManager-0.7

After NetworkManager-0.8 includes mesh device support, we should backport the changes to NetworkManager-0.7 as this is what is being shipped in Fedora 11.

The patches that go into the 0.8 branch should be directly backported. You will have to make a few changes though, because some internals have changed around, particularly for the 6th patch (the one which adds the mesh driver). Nothing too difficult, but if you want to refer to a mostly-similar NetworkManager-0.7 implementation, then see http://dev.laptop.org/git/users/dsd/NetworkManager/log/?h=olpc-v2 (this was from a slightly earlier stage in development)

In the mesh device implementation patch, it is essential to make sure that the value of NM_DEVICE_TYPE_OLPC_MESH matches what went into the 0.8 branch.

Here are the 6 patches to backport:

• http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=14bc75edaad5fbe5615977b3c52c29e0bbb9d713
• http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=0f56957b77b0d86cf4cae3141e70f777cfc8847f
• http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=3fe8d0eed4c1e2b4c4c2d4454e5ec68d2272d2c3
• http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=38afee1e9fb7858a713b55017c6e9edc588cea13
• http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=8f0652a9f0f3b2b2525f48fbb46ebc2525924de7
• http://thread.gmane.org/gmane.linux.network.networkmanager.devel/13710

NM-0.7 needs HAL to identify the mesh device, through this FDI file: http://dev.laptop.org/~sjoerd/NM0.7/olpc-mesh.fdi

We will have to decide whether to ship that file in NetworkManager, hal-info, or olpc-utils.

sugar-0.86

Once NetworkManager supports the device, mesh device support needs to be re-added to Sugar. Again, the development branch should be targetted first, currently v0.86.

Here is a patch against sugar-0.84.5: http://dev.laptop.org/~dsd/20090715/olpcmesh.patch

This patch will have some small conflicts against sugar-0.86, but nothing big at this point. It reimplements mesh support in the neighborhood view and the frame. One big difference from previous implementations is that the logic of network selection is now handled in sugar (not NetworkManager) -- it is sugar that decides whether to mesh or not, and also it is sugar that first prompts NM to look for a school-server mesh before falling back on simple mesh. I tried to keep this logic in it's own file as much as possible.

In this patch, it is important to match DEVICE_TYPE_802_11_OLPC_MESH against the value that ends up being final upstream.

sugar-0.84

After getting mesh support back into upstream sugar, we should backport it to the version being shipped in Fedora 11 - sugar-0.84. It looks like sugarlabs are not accepting any feature patches, so this patch would instead be added to OLPC's fork of the sugar package.

The supplicant state tracking bug

There is only 1 bug that I know about. You can reproduce it by clicking on an open AP on the neighborhood view, waiting about half a second (don't wait for it to connect), then clicking on a mesh channel. The mesh connection will never complete. You might have to do this a few times before you catch it. The issue is that the state machine gets confused as to the state of wpa_supplicant and thinks it is scanning indefinitely (the mesh device waits for the scan to end before attempting to establish a connection).

Discussion: http://thread.gmane.org/gmane.linux.network.networkmanager.devel/13607

This patch implements Dan's suggestion, but does not fully solve the issue as occasionally con_state remains as SCANNING. This remains to be diagnosed.

Old stuff

Sjoerd's old testing instructions

A version of NM 0.7 with support for the OLPC mesh device is available at http://dev.laptop.org/~sjoerd/NM0.7/, this contains rpms, some needed config files and a few demo python programs. A git tree is available at http://dev.laptop.org/git?p=users/sjoerd/NetworkManager.git;a=summary. Note that using this version will break network configuration in sugar!

To test do the following steps:

• Ensure you have a recent joyride (Tested with build 2173)
• Install ppp using yum
• Install the NetworkManager-0.7.0 and NetworkManager-glib-0.7.0 rpms
• copy olpc-mesh.fdi to /etc/hal/fdi/information
• copy nm-user-settings.conf to /etc/dbus-1/system.d/
• reboot! (or restart hal and NM)

Now one can use:

• list_aps.py to list access points in range
• connect.py to connect to normal access points
• connectmsh.py to connect to the mesh in various ways