After a quick test, with the olpc 802 build and all the newer ones (including dextrose), I saw that only on the 802 build, Network Manager starts autoip after the dhcpclient has given up.
Researching on the web, I found this [1]. Basically autoip was causing confusion when making the users to believe that the ethernet connection was _always_ successful. So I asked Dan Williams and he told me they disabled it by default (since NM 0.7.0). Apparently the only (easy) way to make this work is to create a custom wired setting from _some_ UI... 1) http://www.mail-archive.com/networkmanager-list@gnome.org/msg04835.html Saludos, On Sun, Dec 26, 2010 at 11:48 PM, Mikus Grinbergs <mi...@bga.com> wrote: > Kevin, here is how my XOs communicate: > > 1) I haven't seen any reason to ever go to Gnome -- instead I've > written several scripts which I run from Terminal, and which set up > communication between XOs (when it hasn't been setup automatically). > > 2) Much of my inter-XO communication has been using (NON-adhoc) mesh. > [I've written scripts to turn (non-adhoc) mesh on/off, and scripts to > turn ad-hoc wireless on/off.] > > Until very recently, I have __NOT__ tried Associating to the same > Access Point in order to communicate between XOs. When my trial network > has included an XO-1.5 (which does not currently support plain mesh), > I've been able to use the ad-hoc (XO initiated) network instead of a > plain mash network in order to communicate between my test XOs. > > 3) So far, all of my internet connections have gone through a local > ethernet LAN. > > [Note: in the XO, which 'eth_' gets assigned to the ethernet seems > to be somewhat hit or miss. If, when installing a new build, the > "wrong" name gets assigned -- I edit > /etc/udev/rules.d/70-persistent-net.rules and correct the name to what I > want.] > > [Note: once in a while an XO would fail to communicate with the > ethernet. My bypass has always been to unplug the ethernet cable from > the XO, wait some seconds, then plug the cable back in. Usually, > Network Manager recognizes "communications interface became present" -- > and sets up the software for properly accessing that interface.] > > 3a) When I was using F7-based or F9-based XO builds, my local ethernet > LAN had a DHCP server on it -- that DHCP server dynamically assigned > IPv4 addresses to the XOs plugged in to that LAN. I __NEVER__ recall > having a problem communicating between XOs via the ethernet (though very > few Activities were able to collaborate). > > 3b) About the time I started using F11-based XO builds, the hardware > system housing my DHCP server gave out. I've been too lazy to set up a > new DHCP server -- so for the last year I've been running without one on > my ethernet LAN. I have defined static IPv4 addresses for the desktop > systems on the ethernet LAN. The XO (e.g., via the Sugar control panel) > does not support assigning an XO a static IPv4 address -- so I've > written a script with which I do that. [I have to run that script every > time I restart the session, or replug the ethernet cable.] > > [Note: Network Manager (or Avahi?) periodically overrides the > static IPv4 address I assign. This happens infrequently enough that I > simply re-run my script.] > > ---- > > > collaboration does not seem to work without the route commands > > I have not yet figured out when specifying a "default route" is > absolutely necessary. I've noticed that "multi-cast" seems used for > collaboration -- so I make sure to run yet another script which issues > (using a functioning interface) 'ip route add 224.0.0.0/4'. > > > mikus > > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel >
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel