On 7/31/07, Kay Sievers <[EMAIL PROTECTED]> wrote:
> On 7/31/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
> > On 31.07.2007 00:17, Gabriel C wrote:
> > > Sasa Ostrouska wrote:
> > >
> > >> Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
> > >> to check that, thx for the tip.
> > >
> > > Yes udev does this based on the MAC address but AFAIK forcedeth is
> > > 'special' for some reason
> > > ( which I can really remember now and gets on each boot a new MAC address
> > > or alike )
> >
> > Ah yes, that's a workaround for certain buggy boards to make sure you're
> > not left without networking even if the MAC address stored on the board
> > is bogus.
> >
> > Basically, forcedeth checks if the MAC address supplied by your
> > mainboard is bogus and autogenerates a random MAC address from a private
> > range (prefix 00:00:6c) as workaround. However, it will complain loudly
> > if it has to do that.
> >
> > Quoting from forcedeth.c:
> > > if (!is_valid_ether_addr(dev->perm_addr)) {
> > > /*
> > > * Bad mac address. At least one bios sets the mac address
> > > * to 01:23:45:67:89:ab
> > > */
> > > printk(KERN_ERR "%s: Invalid Mac address detected:
> > > %02x:%02x:%02x:%02x:%02x:%02x\n",
> > > pci_name(pci_dev),
> > > dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2],
> > > dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]);
> > > printk(KERN_ERR "Please complain to your hardware vendor. Switching
> > > to a random MAC.\n");
> > > dev->dev_addr[0] = 0x00;
> > > dev->dev_addr[1] = 0x00;
> > > dev->dev_addr[2] = 0x6c;
> > > get_random_bytes(&dev->dev_addr[3], 3);
> > > }
> >
> > Sometimes it helps to update the BIOS and/or set the MAC address which
> > is printed on the board as MAC address in the BIOS.
>
> In any case, it would be nice if the network core could add something like:
> MAC_ORIGIN=device
> MAC_ORIGIN=user
> MAC_ORIGIN=random
> or whatever makes sense here, to the uevent environment. So userspace
> can handle according to that, like falling back using the
> bus-slot-number to lookup the persistent name, or whatever is
> appropriate.
Can't we use the "locally administered" bit in the MAC address? By
checking for ENV{address}=="?[2367abef]:*", we would skip the
persistent rule generation based on the MAC address?
Thanks,
Kay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
