USB Ethernet test

Martin Abente martin.abente.lahaye at
Tue Jan 11 12:40:23 EST 2011

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...



On Sun, Dec 26, 2010 at 11:48 PM, Mikus Grinbergs <mikus at> 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'.
> mikus
> _______________________________________________
> Devel mailing list
> Devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Devel mailing list