> 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. ��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
