Network manager 0.7: Difference between revisions

From OLPC
Jump to navigation Jump to search
mNo edit summary
 
(13 intermediate revisions by 4 users not shown)
Line 1: Line 1:
We currently use a pretty hacked version of network manager 0.6
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 modified network manager to work with the mesh in 0.7 (forward ported the changes).


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.
It would be nice if we had network manager 0.7 in joyride.


=== NetworkManager-0.8 ===
* Nicer API
* Nobody is developing 0.6 anymore
* 0.7 has new functionality and may have support for more networks


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 would likely require working with
* Sugar presence service
* Neighborhood view
* Frame for the mesh device representation


This work has been done. NetworkManager-0.8 supports OLPC mesh.
= Progress =
* Michael Stone told bjordan this would be nice
* Sent out email to devel --[[User:Bjordan|Bjordan]] 22:35, 16 July 2008 (UTC)
* Initial NM 0.7 with mesh support ready -- sjoerd, 17 July 2008


= Testing NM 0.7 =
=== NetworkManager-0.7 ===


We now need to backport the changes to NetworkManager-0.7 as this is what is being shipped in Fedora 11.
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.

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://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=ff88cf12c2de43081f1a7c93a2565658119b7894

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/20090716/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 Sugar Labs 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

[http://dev.laptop.org/git/users/dsd/NetworkManager/commit/?h=olpc-v2&id=27fab4abc8f17dd5cebb6d7159289f71483c3367 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!
Note that using this version will break network configuration in sugar!


Line 37: Line 73:
* connectmsh.py to connect to the mesh in various ways
* connectmsh.py to connect to the mesh in various ways


[[Category:Network]]
= TODO =
* Mesh Portal (MPP) support in NM 0.7
* NM 0.7 support in sugar:
What we need now is for someone to port the sugar components to use the new NetworkManager D-Bus API. NM 0.7 introduces a new D-Bus API and no longer supports the old one, which is what we use in sugar. --[[User:DanielDrake]], via [http://lists.laptop.org/pipermail/devel/2008-July/thread.html#16756 devel@]


Bug [http://dev.laptop.org/ticket/6248 #6248] - Presence service broken with NetworkManager-0.7 (NM D-Bus API change)

= Interested in helping =
--[[User:Bjordan|Bjordan]] - The more helpful information on the Wiki, the better my capacity to contribute (haven't done much dealing with network manager)

--[[User:MartinDengler|mtd]] - I've done some work on {{Trac|6995|Frame/mesh icons}}, so I could help with "Frame for the mesh device representation"

Latest revision as of 19:59, 25 September 2010

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. NetworkManager-0.8 supports OLPC mesh.

NetworkManager-0.7

We now need to 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:

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/20090716/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 Sugar Labs 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