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 ?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
