[SM-Discuss] netconf MAC setting change
seth at swoolley.homeip.net
seth at swoolley.homeip.net
Thu Jun 22 02:01:40 EDT 2006
Yeah, I'm on probably ten hours of sleep this whole week, but I thought
I'd chip in anyways...
You don't need to keep track of renamings. You really only need two
types of MACs and a way to keep volatile persistence in-line when you
You just need to make a distinction between NATIVE_MAC and SPOOF_MAC.
If SPOOF_MAC is defined, then when you see NATIVE_MAC, persist
NATIVE_MAC and SPOOF_MAC into a volatile area of memory. The volatile
area of memory I propose is /var/run. If the uptime is newer than the
file creation date, you invalidate that entry. (Normally /var/run is
cleared for reboots, but just in case it isn't you have that check.) To
bring up and down a card that has already been brought up, you just use
its SPOOF_MAC. To bring up a card that has not been brought up yet,
it's still in its NATIVE_MAC state. If a user messes with a MAC outside
of this framework, they are on their own, of course.
This of course assumes that the driver is loaded and not reloaded (which
would bring it back to its NATIVE_MAC state. If the SPOOF_MAC cannot be
found, identify the card by its NATIVE_MAC. You can't always use that
technique though in the case where you may have a SPOOF_MAC that matches
another card's NATIVE_MAC (swapping two interfaces and their MAC
addresses), so you must remember to only check the NATIVE_MAC if the
SPOOF_MAC is not also found, otherwise it is invalidated. If SPOOF_MAC
would duplicate a NATIVE_MAC, the other NATIVE_MAC should be changed to
its SPOOF_MAC (with a recursive check if needed) as well.
To handle renaming properly, you simply check for cards with the native
name already and rename them to something else, to prevent colliding.
You have the MAC to identify them with so when they are brought up, you
can always find it again.
That covers almost any situation and still allows it to be a flexible
field. It doesn't allow duplicate names, nor duplicate MACs, but that's
the flaw when you want both to be unique.
(Gee, I hope that all makes sense from my stream-of-consciousness.)
On Wed, Jun 21, 2006 at 05:47:43PM +0200, Pieter Lenaerts wrote:
> On Wed, Jun 21, 2006 at 04:50:28PM +0200, Thomas Orgis wrote:
> > I agree that, though possible, remembering the MAC history may be tedious and unnecessary complex. Jut wondering now how far your "_never_ change" goes when one does changes to the hardware (moving cards in slots) that are not expected / should not break the network config.
> you're now holding on to bus address, which is indeed volatile as well,
> not that much on pci for me personally, but espescially on usb
> this line works:
> BUS=="pci", DRIVER=="3c59x", NAME="fooh"
> we can't count on different drivers for different cards though.
> > I'm just clinging to the MAC because it was created for the purpose of identifying NICs.
> this is only for identifying nics on the ethernet, has nothing to do
> with identifying them in a box iianm.
> > I won't oppose netconf using a more safe may to identify cards internally, as long as it doesn't sacrifice flexibility that one has now.
> > Even when it is as simple as not _forcing_ network card identification so that the common setup of just one NIC just works and continues to work with unchanged config when nic is exchanged.
> of course it should support simple cases as well :)
> > And of course my favourite example of broken config because of changed pci slot positions - I hate it when windows finds a _new_ device just because I had to reorder the cards.
> although this is a cornercase of a cornercase it should definetely be
> the goal to beat this.
> on the other hand, we could require to rerun netconf should we use the
> bus address anyway (which I think we shouldn't atm)
> maybe someone knows a solution for the two identical nics issue
> anyway, we're not in a hurry and I oppose to any implementation before
> this is thought through and approved by the community.
> Pieter Lenaerts
> Source Mage GNU/Linux
> http://www.sourcemage.org - "Linux so advanced it may well be magic"
> SM-Discuss mailing list
> SM-Discuss at lists.ibiblio.org
More information about the SM-Discuss