On Fri, 2012-12-07 at 15:27 +0000, Cunningham, Robert wrote: > > From: Dan Williams [mailto:dcbw@xxxxxxxxxx] > > Sent: Friday, December 07, 2012 7:17 AM > > Subject: Re: Random MAC address from smsc75xx: How to permanently set? > > > > 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. > > While I can use this information in a udev rule during device discovery to initially set a MAC address, it still gets overwritten by a fresh random MAC address when doing "ifconfig ethX up". How do I make my desired MAC address "stick" through multiple ifconfig up/down cycles? > > How can I consistently override MAC address (re-)randomization whenever it occurs after initial boot? I doubt udev rules will help, but I really don't know for sure. Yeah, that part I don't know. My initial reply was just about your use of kernel interface names as the key for locking the MAC, which is not guaranteed to be stable. Not enough people realize that. 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
