> From: Dan Williams [mailto:d...@redhat.com]
> 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: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.)
>
> 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�����r��y����b�X��ǧv�^�){.n�+����{������^n�r���z���h�����&�� �G���h�(�階�ݢj"���m������z�ޖ���f���h���~�m�
