Re: Random MAC address from smsc75xx: How to permanently set?
On Fri, 2012-12-07 at 15:27 +, Cunningham, Robert wrote: > > 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 +, 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 > > wrote: > > > > > On Thu, 2012-12-06 at 12:44 -0600, Dan Williams wrote: > > > > >> On Thu, 2012-12-06 at 18:35 +, 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 h
RE: Random MAC address from smsc75xx: How to permanently set?
> 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 +, 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 > wrote: > > > > On Thu, 2012-12-06 at 12:44 -0600, Dan Williams wrote: > > > >> On Thu, 2012-12-06 at 18:35 +, 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: Random MAC address from smsc75xx: How to permanently set?
On Fri, 2012-12-07 at 14:13 +, 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 wrote: > > > On Thu, 2012-12-06 at 12:44 -0600, Dan Williams wrote: > > >> On Thu, 2012-12-06 at 18:35 +, 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
RE: Random MAC address from smsc75xx: How to permanently set?
> -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 wrote: > > On Thu, 2012-12-06 at 12:44 -0600, Dan Williams wrote: > >> On Thu, 2012-12-06 at 18:35 +, 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.)
Re: Random MAC address from smsc75xx: How to permanently set?
On Fri, Dec 7, 2012 at 12:21 AM, Dan Williams wrote: > On Thu, 2012-12-06 at 12:44 -0600, Dan Williams wrote: >> On Thu, 2012-12-06 at 18:35 +, 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
Re: Random MAC address from smsc75xx: How to permanently set?
Dan Williams writes:
> On Thu, 2012-12-06 at 18:35 +, 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.
Creating a rule matching on the USB device should do, provided the
driver is fixed to prevent changing the address on every open.
>> 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?
Well, that is clearly a driver bug. It should reuse the same address.
What do you think about something like the completely untested attached
patch, Steve?
You may want to go over the other parts of .reset as well. It does a
lot, and I suspect most of it should be a onetime initialization thing
and not done on every device open.
Bjørn
>From a51089b8ad13957ba72be2f411c06684225ab3e5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?=
Date: Thu, 6 Dec 2012 20:33:25 +0100
Subject: [PATCH] smsc75xx: dont reset macaddress in open
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
usbnet_open calls the minidriver .reset function. Moving the
macadress initialization to .bind to prevent the macaddress
from changing every time the device is brought up in case a
persistent macaddress is missing.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/smsc75xx.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 1cbd936..971c679 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -1054,17 +1054,6 @@ static int smsc75xx_reset(struct usbnet *dev)
netif_dbg(dev, ifup, dev->net, "PHY reset complete\n");
- smsc75xx_init_mac_address(dev);
-
- ret = smsc75xx_set_mac_address(dev);
- if (ret < 0) {
- netdev_warn(dev->net, "Failed to set mac address\n");
- return ret;
- }
-
- netif_dbg(dev, ifup, dev->net, "MAC Address: %pM\n",
- dev->net->dev_addr);
-
ret = smsc75xx_read_reg(dev, HW_CFG, &buf);
if (ret < 0) {
netdev_warn(dev->net, "Failed to read HW_CFG: %d\n", ret);
@@ -1428,6 +1417,14 @@ static int smsc75xx_bind(struct usbnet *dev, struct usb_interface *intf)
netdev_warn(dev->net, "smsc75xx_reset error %d\n", ret);
return ret;
}
+ smsc75xx_init_mac_address(dev);
+ ret = smsc75xx_set_mac_address(dev);
+ if (ret < 0) {
+ netdev_warn(dev->net, "Failed to set mac address\n");
+ return ret;
+ }
+ netif_dbg(dev, ifup, dev->net, "MAC Address: %pM\n",
+ dev->net->dev_addr);
dev->net->netdev_ops = &smsc75xx_netdev_ops;
dev->net->ethtool_ops = &smsc75xx_ethtool_ops;
--
1.7.10.4
Re: Random MAC address from smsc75xx: How to permanently set?
On Thu, 2012-12-06 at 12:44 -0600, Dan Williams wrote: > On Thu, 2012-12-06 at 18:35 +, 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. Dan > 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 majord...@vger.kernel.org > > 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 majord...@vger.kernel.org > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random MAC address from smsc75xx: How to permanently set?
On Thu, 2012-12-06 at 18:35 +, 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 majord...@vger.kernel.org > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
