ethernet device appears as usb0 and not eth0 on beagle XM boards

[Torez Smith]

network ethernet device on the beagle XM board is manifesting as device usb0 but should be eth0. This bug fixes the driver and names that device.

[Ricardo Salveti (rsalveti)]

This is actually the expected behavior for Beagle xM boards.

If you check the system reference manual (http://beagle.s3.amazonaws.com/design/xM-A/BB_xM_SRM_A2_01.pdf - Page 80), you'll see that at Beagle XM uses SMSC LAN9514 as the USB hub and Ethernet adapter.

You can also find more about the SMSC chip at http://www.smsc.com/media/Downloads_Public/Data_Sheets/9514.pdf.

So it's not just a normal ethernet device, it's together with the USB hub, and it uses it structure.

Now regarding the naming, you can check why by looking at the driver smsc95xx (drivers/net/usb/smsc95xx.c). It basically uses the usbnet kernel infrastructure, making 'usbnet' module as a dependency, and then as a consequence the ethernet adapter gets called as 'usb0' instead of 'eth0'.

If you still want to change it, maybe creating a udev rule or something like that, but I'd stuck with 'usb0' as it shows the user that his ethernet device is connected with the USB hub.

[Loïc Minier (lool)]

I certainly understand it's USB-based, but my regular beagleboard has an external USB Ethernet adapter based on ASIX and its interface is called eth0. asix also uses usbnet.

If you check drivers/net/usb/usbnet.c, you will see that it uses some heuristics to name devices usb%d or eth%d; for some reason, smc95xx doesn't match.

[Loïc Minier (lool)]

smc95xx does set FLAG_ETHER; Torez, what's the MAC address on your beagle XM?

Could you pass your dmesg on XM, I'd like to see whether the MAC address is randomized or not.

[Ricardo Salveti (rsalveti)]

Yep, you're right, it seems that this is more related on how the mac address was generated. In our case we're getting a random mac address at every boot, probably because the EEPROM content is still the default one (FFFFFFFFFFFFh).

[Loïc Minier (lool)]

Marcin had a similar issue in the past
http://www.spinics.net/lists/netdev/msg95158.html

As I read the comment, it seems to say that a link from host-to-host should be named usb0, and that locally generated MAC addresses are usually host-to-host.

I think our use cases shows that it's not always host-to-host though, since the XMs are just regular boards.

How can we fix this?
- well obvioiusly by seting a MAC address in all boards
- we could have another MAC address generation functions which doesn't use the "locally generated" space, but something else, perhaps some vendor space, or just plain random; it's kind of evil, but then the boards don't have a MAC
- we could rename the interface in userspace, as the comment suggests; it's a bit ugly to workaround in userspace though, I'd rather fix the kernel
- we could add a flag to net devices to indicate whether these are likely host-to-host or for use on a regular network, in which case usbnet would also use eth%d

[Ricardo Salveti (rsalveti)]

For me it's weird that we get a board with an internal ethernet chip without a valid mac address by default. Probably they are not worried about getting a mac and writing it at the eeprom.

You could add another flag to say the device is not host-to-host, but it'd be better to talk with the usbnet driver's maintainers first.

[Loïc Minier (lool)]

I remember someone mentions there isn't even an EEPROM wired to the ethernet chip

[Ricardo Salveti (rsalveti)]

You can check at the reference manual that the EEPROM wires are nc (page 80):
http://beagle.s3.amazonaws.com/design/xM-A/BB_xM_SRM_A2_01.pdf

[Ricardo Salveti (rsalveti)]

Same for Panda, by the way.

[Torez Smith (lnxtorez)]

point of reference, the IGEPV2 board has random MAC addresses but makes use of eth0. No eeprom to store the MAC address

[Torez Smith (lnxtorez)]

Few notes and/or observations.....

1) beagle XM board has device " SMSC LAN9514 Ethernet HUB " and uses kernel driver drivers/net/usb/smsc95xx.c

2) igep board has device " SMSC LAN9221i " and uses driver drivers/net/smsc911x.c (igep is not relevant to this bug but using it as an opma3 family point of reference )

3) neither board have EEPROM so MAC addresses are not stored on board

4) both drivers call random_ether_addr() to generate the initial ethernet address.

5) random_ether_addr() clears multicast bits and sets the local assignment bit ( addr [0] |= 0x02; )

6) driver smsc95xx sets FLAG_ETHER flag to help denote the network address is an ethernet address (as oppose to a wlan address, etc.)

7) while following the initialization logic, stack traces, etc., usbnet_probe() is called to probe device and further set it up.

8) in this routine, the logic to determine if we use interface eth% versus usb% is based on FLAG_ETHER being set and the content of addr [0]. If FLAG_ETHER is set "and" bit 1 of addr [0] is "not" set, use eth% otherwise use usb%. In the case of the beagle XM board, FLAG_ETHER is set "and" so is bit 1 of addr [0] which means we end up using usb%.

Sent email to driver writer for further analysis.

[Jamie Bennett (jamiebennett)]

Still present on 2011-02-01 images.

[Nicolas Pitre (npitre)]

IMHO this bug is invalid for Linaro Linux. The ethernet device is
behind a USB bridge which explains the usb0 device name. If user space
wants a different name, it has to be renamed from user space (udev can
do that).

[Loïc Minier (lool)]

This USB bridge is soldered on the board though; one could expect the board specific code to override the default device name in this case

[warmcat (andy-warmcat)]

Here's a summary of a discussion of this bug status between Loic, Nicolas and myself last night.

Board-specific code can't "override the default device name" in any nice way because on Panda, the ethernet PHY is not a platform_device that we can control by sending it flags in its platform_data set in the board specific file.

Instead, it's a USB device connected to a USB host port that is discovered and enumerated independent of any board-specific code. Further, because it's a USB network device its driver support for deciding this name is in the shared usbnet.c file used by all the USB network devices like this. There's a comment in usbnet.c on this code explicitly saying that if the user wants to force the name he can do it from userspace.

The reason usbnet.c forces usb%d in this case is because we do not set any fixed MAC address for the PHY, and the EEPROM the vendor could have connected to the PHY to set the MAC is absent too. The vendor never allocated any IEEE802 MAC Namespace address for the board then. Therefore there is no choice but to use a "local namespace" MAC address which has b1 set on the first octet; all randomized MACs have this bit set so they won't conflict with any MAC address from the official namespace which has b1 clear. When usbnet.c sees b1 set it goes down the usb%d path. Because no official MAC address has been paid for with these boards, in fact there is no solution involving being able to clear b1 in the MAC address and work with the existing logic.

Currently, the new random MAC on each boot really sucks because it means a new dhcp lease every boot and then a different IP.

It would be possible to solve this entirely in userspace because udev can rename the interface and Nicolas proposed using the SD card unique ID, available at "cat /sys/bus/mmc/devices/mmc0*/serial" as the LSBs of a randomized MAC so it is consistent on each boot, something that is best done in a udev or initscript. If the udev magic can be sent to udev upstream so all distros can do it, that would be pretty OK since it can provide a good spread of MAC addresses that don't change per boot.

The two ways to approach this in kernel I can think of are 1) propose a new generic scheme for providing platform_data for independently probed / enumerated USB stuff along the lines of SPI / I2C; or 2) add support for kernel commandline tokens in usbnet.c allowing override of naming for devices found on specific bus paths, eg, usbnet.forceifname=usb,1-1.1:1.0,eth but it seems to me this may be less welcome for the USB people to hear upstream than the udev people in the userspace case.

[Michael Pujos (pujos)]

Could anyone make a working udev rule that renames usb0 to eth0 ?

Theorically this simple rule should work:

KERNEL=="usb0", NAME="eth0"

but it doesn't: eth0 does not exist and udev gives weird errors on boot:

Starting udev
udevd[69]: specified group 'video' unknown
udevd[69]: specified group 'floppy' unknown
udevd[69]: specified group 'cdrom' unknown
udevd[69]: specified group 'tape' unknown

[ 3433.191833] udev[70]: starting version 165
udevd-work[181]: open /dev/null failed: No such file or directory
udevd-work[182]: open /dev/null failed: No such file or directory
udevd-work[183]: open /dev/null failed: No such file or directory
udevd[70]: failed to create queue file: No space left on device

Is that even possible to rename usb0 in eth0 ?

[Tom Gall (tom-gall)]

I believe this is fixed. Running the linaro-developer image from a snapshot dated April 22nd, it's eth0 on my Xm.

[warmcat (andy-warmcat)]

Right after a big battle a patch from Arnd Bergmann was accepted that turns all USB ethernets to eth%d and it's in mainline.