XO-1.5 os852 USB ethernet RFC3927 IPv4 address not assigned

[Quozl]

After connecting a USB ethernet adapter, with a cable attached to another laptop, an IP address is not assigned.

Workaround:

avahi-autoipd eth1

Note: the interface may have a name other than eth1, if the laptop has seen other USB ethernet adapters since it was installed.

[mikus]

I believe this is the correct ("as designed") architectural behavior.

In three years of using physical ethernet connectivity for XOs, my experience has been that when an ethernet cable (with adapter) gets plugged in to the XO, the XO attempts to contact a DHCP server (presumed to exist somewhere at the other end of that cable). If this attempt is successful, it is that DHCP server which assigns an IP address to the "joining" XO. If this attempt to contact a DHCP server is unsuccessful, it is up to the "joining" XO to set its own IP address (e.g., by invoking zeroconf).

[Whether there has been a regression (between 10.1 and 8.2) regarding ethernet self-assignment of IP address I haven't noticed -- on my LAN I always explicitly set the ethernet IPv4 address if a system has failed to connect because it doesn't have the proper IP address.]

[Quozl]

|testcase|

• boot two OLPC XOs to Sugar in OLPC OS 10.1.2 and disconnect wireless,

• connect an ethernet cable between two USB ethernet adapters, (Some USB ethernet adapters may require a crossover cable. The indicators should indicate that, or test it yourself in some other way first).

• connect the USB ethernet adapters to the OLPC XOs,

• watch for any adapter indicators, (these are relevant if you know from experience what they mean, since they vary across adapter models),

• allow at least five to ten second to elapse,

• check Sugar frame for an IP address assignment, in the palette of the USB network device icon, and record the result,

• check Terminal using ifconfig for an IP address assignment, and note the bytes sent and received if there is no IP address (non zero values of received bytes indicate there is no need for a crossover cable, but zero value of received bytes does not prove there is a need for a crossover cable, since that might also happen if the other XO does not run avahi-autoipd).

• check Sugar neighbourhood view of each XO for the other XO icon,

• check collaboration through activity sharing is operational, and record the result,

• use the avahi-autoipd workaround if there was no IP address assignment,

• repeat the Sugar frame, Terminal ifconfig, Sugar neighbourhood view, and collaboration tests above.

Success: that an IP was automatically assigned and collaboration was possible.

[Quozl]

Testing by Kevin Gordon, following the above test case, shows:

Operating System	IPv4 address assigned	IPv6 address assigned
OLPC OS 8.2.1 os802	yes	yes
OLPC OS 10.1.2 os852	no	yes
OLPC OS 10.1.3 os359	no	yes
Ubuntu 10.04	no	yes
Fedora 11	no	yes
Microsoft Windows 7	yes	yes
Microsoft Windows XP	yes	yes

As a consequence of not assigning an RFC3927 IPv4 address, the laptops do not see each other in neighbourhood view.

This is a regression from 8.2.1.