NetworkManager-0.6 broken in olpc3

[dsd]

It doesn't want to connect to anything. iwevent shows it associating successfully but then disassociating. I don't think it is running dhclient. I'll investigate further.

[dsd]

I set up two systems (one F7, one F9) to boot into text-only mode, without X/Sugar, and without NetworkManager. I then ran iwevent (logging the output) and then started NetworkManager. Both are running version 0.6.5-0.8.svn3246

The F7 system quickly settled on a mesh network (with school server) and obtained an address over DHCP. dhclient remained running as expected. eth0 came up with an IPv6 address, msh0 came up with a 172.18.x.x address. /etc/resolv.conf was populated with search domain and nameserver.

The F9 system jumped around networks for a few minutes, settled on the same mesh channel, but did not run dhclient. eth0 is down and has no addresses. msh0 is up but has IP address 169.254.x.x. /etc/resolv.conf is empty except for the "generated by networkmanager" comment.

If I manually run dhclient on msh0 on the OLPC-3 system once it has settled on a network, connectivity is established.

So the currently unexplained differences seem to be:

• eth0 not coming up
• network selection taking ages
• dhclient not running on msh0

[dsd]

iwevent log from working f7 setup

[dsd]

iwevent log from broken f9 setup

[dsd]

network manager log from working f7

[dsd]

network manager log from broken f9

[dsd]

There's a bug in NetworkManager-0.6.5-3206-edit.patch

it removes a call to new_nl_handle() :

@@ -560,7 +577,7 @@
 
 	g_return_val_if_fail (iface != NULL, FALSE);
 
-	if (!(nlh = new_nl_handle ()))
+	if (!nlh)
 		return FALSE;
 
 	if (!(request = rtnl_link_alloc ()))

The resultant logic is then as follows:

	struct nl_handle *	nlh = NULL;
	if (!nlh)
 		return FALSE;

so the nm_system_device_set_up_down_with_iface() function never does anything

There are still problems even with that fixed, so I'll keep hunting...

[dsd]

Next problem: src/dhcp-manager/nm-dhcp-manager.c dhclient_run() passes the -x option to dhclient

OLPC-2 has dhclient-3.0.5 and OLPC-3 has dhclient-4.0.0

Fedora had a patch in dhclient-3.0.5 which added a -x option:

+The -x argument enables extended option information to be created in the
+-s dhclient-script environment, which would allow applications running
+in that environment to handle options they do not know about in advance -
+this is a Red Hat extension to support dhcdbd and NetworkManager.

However dhclient-4.0.0 *upstream* added a -x option with totally different meaning:

- Added -x option to dhclient, which triggers dhclient processes
  to exit gracefully without releasing leases first

Fedora seem to have silently dropped their version of the -x patch with the 4.0.0 release, so running "dhclient -x" is now just a way of telling other dhclient's to go away.

NetworkManager upstream removed the -x option: http://svn.gnome.org/viewvc/NetworkManager/trunk/src/dhcp-manager/nm-dhcp-manager.c?r1=2674&r2=2681

So we now need to do the same, to make dhclient actually run when NM launches it.

The #if'd out part was then removed with another change: http://svn.gnome.org/viewvc/NetworkManager/trunk/src/dhcp-manager/nm-dhcp-manager.c?r1=3215&r2=3401 (perhaps we need to backport that patch?)

[dsd]

patch to kill -x option

[dsd]

NetworkManager-0.6 is now working on OLPC-3! To summarise, 2 fixes are needed:

1. NetworkManager-0.6.5-3206-edit.patch needs to be fixed as described above 2. nm-no-x.patch attached above

[dcbw]

You shouldn't need the entire 3215->3401 diff, just kill the bits making NM pass -x to dhclient. Turns out -x wasn't needed at all and the information I was given at the time indicating that I should use it was faulty. Thanks for tracking these down; dgilmore should be able to update the NM build.

[dsd]

agreed, the nm-no-x.patch attachment is all that is needed

[dsd]

fixed version of NetworkManager/OLPC-3/NetworkManager-0.6.5-3206-edit.patch

[dsd]

fixed in build 20, thanks

[gregorio]

Milestone Never Assigned deleted