On Fri, 2012-12-07 at 14:13 +0000, Cunningham, Robert wrote: > > -----Original Message----- > > From: Jassi Brar [mailto:jassisinghbrar@xxxxxxxxx] > > Sent: Thursday, December 06, 2012 10:21 PM > > Subject: Re: Random MAC address from smsc75xx: How to permanently set? > > > > On Fri, Dec 7, 2012 at 12:21 AM, Dan Williams <dcbw@xxxxxxxxxx> wrote: > > > On Thu, 2012-12-06 at 12:44 -0600, Dan Williams wrote: > > >> On Thu, 2012-12-06 at 18:35 +0000, Cunningham, Robert wrote: > > >> > I'm trying to bring up an OMAP4 system based on Variscite's OM44 > > module running Linaro's Ubuntu Precise in a headless configuration. The > > system contains two SMSC LAN7500 USB-GigE chips (not dongles), both of > > which are fully functional. > > >> > > > >> > The GigE chips don't have EEPROMS, so no permanent MAC addresses > > >> > can be assigned in hardware. As expected, the smsc75xx driver > > >> > assigns a random MAC address when the interface is discovered and > > >> > initialized. However, we need to provide consistent MAC addresses > > >> > on these interfaces. (Yes, we could respin the board to add > > >> > EEPROMS, but that's a last, and expensive, resort.) > > >> > > > >> > After the system boots, I'd like to change the MAC addresses to specific > > values. While there are multiple ways to do this (using commands such as > > ifconfig, ip, macchanger, and others), it seems the updated MAC address is > > always overridden when I do "ifconfig ethX up", which causes yet another > > different random MAC address to be created and assigned. Simply repeating > > ifconfig up/down causes an endless list of random MAC addresses to be > > generated. > > >> > > > >> > I created a udev rule that I hoped would handle the situation, but it is > > also overridden: > > >> > /etc/udev/rules.d/99-mac-address.rules: > > >> > SUBSYSTEM=="net", KERNEL=="eth0", RUN+="/sbin/ip link set dev > > %k address XX:XX:XX:XX:XX:00" > > >> > SUBSYSTEM=="net", KERNEL=="eth1", RUN+="/sbin/ip link set dev > > %k address XX:XX:XX:XX:XX:01" > > >> > > > >> > For a single interface, I can use u-boot variables or kernel boot > > arguments, but they seem to work only for the first interface, and I have > > two. > > >> > > >> Just matching on interface name won't guarantee that you get the same > > >> MAC assigned to the same physical interface each time you boot. You > > >> can't rely on bus probing order. What you really want to do is > > >> enhance the udev rule to match the network interfaces based on stuff > > >> like PCI bus address, SDIO details, or whatever bus type the > > >> interfaces are hanging off. If the device is a virtual one because > > >> it's on-chip or something like that, then you're at the mercy of the > > >> driver's probing code because it probably doesn't expose any unique > > >> details of the device. This all doesn't have anything to do with the > > >> MAC potentially being overwritten by something later, but just beware > > >> that device probing order is *not* generally reliable, which means > > >> that interface names can and do get reordered. > > > > > > Just noticed this was sent only to linux-usb, so I'll assume we're > > > talking about USB here. Unfortunately, USB probing order is even > > > *less* reliable than PCI and other types. So the only thing you can > > > do here is hope that the manufacturer set a unique serial number on > > > the network device (use lsusb -v to find it) and then you can use that > > > to lock the udev rules to that specific device. If not, you're hosed > > > and you'll never get completely reliable mapping between the network > > > interface and the MAC address you're trying to set. > > > > > Or the usb device path of lan7500 chips onboard, which would remain same > > across reboots ? > > In my specific case, the 7500s are hard-wired to separate hard-wired hubs, so I would expect consistent enumeration. The first 7500 on the first hub should always enumerate before the one on the second hub. I haven't seen any variation in the enumeration across many boots. > > If this turns out to be true, how can I use it to get control over my MAC addresses? I'm guessing a udev rule, but I'm no expert in that area (actually, I'm closer to a clueless newbie). > > There's still the general problem of uncontrolled re-randomization of the MAC address by the smsc75xx driver. To me, this looks like a real in-your-face bug. And since code is often shared between device drivers, I can't help but believe this behavior is not unique to the smsc75xx driver. Where would I check to see if this bug has already been reported for this and other drivers? Where would I check to see if a fix has already been created, but hasn't yet hit my kernel? (ARM kernels lag 2-3 releases behind x86 kernels, so this may already be old news to x86 folks.) KERNELS=="xxxxx" where xxxxx is something like 1-2:1 or whereever your devices are. Grab that from the /sys/class/net/usb0/device link which will be something like "../../../1-2:1.6" where of course the ".6" is the USB interface number which you probably don't need. Dan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
