As this looks like it's becoming a Frequently Asked Question, I'll send
this note to a wider audience. Please forgive me if this is obvious to
most of the folks on this list.
After flashing or upgrading distros or bootloaders, some folks have been
noticing that their "usb0" network interface on the *host* side fails to
appear when the Freerunner is plugged into the USB port.
Alert users have noticed that it didn't really fail to appear, rather it
changed name from "usb0" to "eth1" (or "eth2", etc).
What's happening here is that certain bootloaders and certain distros
have begun to use the official USB mac address assigned by Openmoko to
the Freerunner, instead of letting the kernel generate a random address
in the locally-assigned range. Many hosts will respond differently when
they observe the official (static) mac address; instead of creating the
"usb0" interface, they will create and permanently assign an "eth<n>"
interface name to that mac address.
Clearly the latter is the correct way for things to work -- not only
does it make certain network managers on the hosts happier, it also
permits one to keep one's sanity when plugging multiple devices into a host.
The combination of the Qi bootloader and any kernel with g_ether
built-in will use the official mac address. If g_ether is a module,
then the decision to use the official mac address is up to the distro
As of the writing of this email, the Android b6 distro is known to use
the official mac address. The SHR "testing" distro will use the
official mac address when booted with Qi, but not when booted with
u-boot. The SHE "unstable" builds fix this inconsistency and will use
the official mac address with either bootloader.
One final note - a big thank you to Sebastian Wiedenroth for assistance
with this for SHR, and especially for finding a current issue with the
way Qi handles the official mac addresses (specifically, Qi assigns the
same mac address to both the device and host sides, which fails to work
with OS X, as well as resulting in duplicate IPV6 addresses -- SHR has
implemented a work-around to avoid this problem).
PS: a first cut at updating the wiki has been made, I urge folks to
correct and expand as they feel necessary: