RE: Random MAC address from smsc75xx: How to permanently set?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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�����٥



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux