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

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

 



> -----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.)

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