> -----Original Message----- > From: Jassi Brar [mailto:jassisinghb...@gmail.com] > 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 <d...@redhat.com> 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.)
