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. Dan > I've searched extensively for other solutions, but have found none that will survive "ifconfig ethX up". > > Is there a way to "permanently" tell the smsc75xx device driver to use my desired MAC addresses instead of generating random ones every time? And to have the MAC addresses remain unchanged when I bring the interfaces up and down? > > I suspect there's a big, obvious clue I'm missing. Would someone please beat me over the head with it? Using small words and simple examples? > > > TIA, > > -BobC > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
