CDC/RNDIS Ethernet over USB driver provides random Ethernet address after each reboot which makes MacOS X config problematic

[hns@…]

When plugging the OpenMoko? device through USB to a Mac with at least MacOS X 10.4.10, a CDC
Ethernet driver is started automatically on the Mac. The only additional step for a user is to go to the
Network Settings and configure a manual IP address (192.168.0.200) for the Mac.

This all works well, until the user decides to reboot the OpenMoko? device. After doing this, he has to
reconfigure MacOS X again and the Network Settings shows a second (third, etc.) entry for the
OpenMoko? because the old entries can't be deleted automatically.

One part of the reason is the way how MacOS X stores and associates network configuration data when
hot-plugging an Ethernet interface: they are hashed/indexed by the Ethernet MAC address. So, each
Ethernet interface has its own set of IP default configurations (ifconfig).

Now, the CDC-Ethernet driver appears to receive a "virtual" the Ethernet MAC address for both
endpoints of the USB connection, i.e. one for the Macintosh and one for the OM. These addresses
appear to be provided by the OM kernel (or the CDC Ethernet driver on the OM) through the USB profile
data. And, the Linux kernel appears to seed a randomized value for each reboot which results in this
bug.

My analysis has shown that the Sharp Zaurus (with Sharp ROM and kernel 2.4) is doing it slightly
different: the MAC addresses provided by USB are constant. So, the Zaurus does not have this problem
when being connected to the Mac. Unfortunately this MAC address is the same for all Zaurus devices so
that you get problems when plugging in two Zaurus devices.

So, I propose a patch for the USB/CDC-Ethernet module of the OM kernel that provides a MAC address
that somehow depends on a Neo serial number. Or is otherwise constant between kernel reflashes and
reboots but still unique between different OM devices (so that you can charge and connect two of them
on the same Macintosh without confusing the IP configuration).

It could e.g. be a random number derived when flashing uBoot and stored somewhere in the bootloader
flash.

Please note that this problem can't be solved on the Mac since all these mechanisms are system and
kernel modules provided by Apple. The only current workaround is the AJZaurusUSB driver which
ignores the MAC address - but also replaces the Apple CDC Ethernet driver (which appears to be more
stable that AJZaurusUSB).

[laforge@…]

I totally agree with the analysis and with the fact that OpenMoko? should have
fixed usb-ethernet MAC addresses.

I don't think we need any kernel patches for this. The kernel very well supports
fixed MAC addresses that are provided to it at kernel boot time parameter.

However, deriving a MAC address from the serial number / IMEI is not an option,
since we cannot guarantee that we wouldn't use an already-allocated MAC address
of a completely different vendor.

What we need is two officially allocated MAC addresses out of a to-be-bought OUI
range. Those two MAC addresses need to be stored in the environment partition
of the device during production.

The bootloader then passes these MAC addresses to the kernel at boot time, and
everything else should happen automatically.

So we need three things
1) the OID range that OpenMoko? wanted to buy anyway
2) a possibility to allocate two MAC addresses to each device during production
3) the ability to write those two MAC addresses into the bootargs_base
environment in the kernel-required syntax for usb ethernet.

[werner@…]

Agreed on getting an OUI and giving our machines proper MAC addresses.
It's ugly that EoUSB needs two globally unique IDs per device, but it
seems that this is unavoidable (?), and the MacOS approach of handling
configurations actually seems to make sense to me.

[hns@…]

Just an idea:
if you want to save MAC addresses it could be possible to re-use the Bluetooth MAC address on the Neo
side and some derived MAC (by using some hash algorithm) on the MAC side. Or derive two hash values.
Or simply XOR with two different patterns. It would also be unique.

The only requirement is that it is possible to read out the Bluetooth MAC before/during boot.

[wolfgang@…]

kernel

[stefan@…]

As it was already stated, this is more about to get OID range for the needed MAC
addresses then a kernel issue.

OpenMoko? Inc. needs to buy a OID range where the MAC address can be taken from.
Once this range is available system engineers should have a look how to assign
this addresses unique per device.

[werner@…]

To work around the MacOS situation, a pair of locally-chosen MAC
addresses for host and device could be stored in the environment,
and then passed to the kernel with the following u-boot commands:

setenv bootcmd setenv bootargs \${bootargs_base} \${bootargs_usb}
\${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000

setenv bootargs_usb g_ether.dev_addr=00:01:02:03:04:05
g_ether.host_addr=06:07:08:09:0a:0b

saveenv

Note that the first byte of each address must be an even number, or this
would be a multicast address, and the kernel would ignore it.

[werner@…]

Using properly assigned MAC addresses is part of a more involved
process, which will take a while.

[werner@…]

* Bug 783 has been marked as a duplicate of this bug. *

[cesarb@…]

(in reply to comment #6)

Not only should the number be even, the next bit (global/local bit) should be 1
(locally allocated address).

This means a better set of addresses would be:

setenv bootargs_usb g_ether.dev_addr=02:01:02:03:04:05
g_ether.host_addr=06:07:08:09:0a:0b