lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0903241150020.16753@asgard.lang.hm>
Date:	Tue, 24 Mar 2009 11:51:29 -0700 (PDT)
From:	david@...g.hm
To:	Dan Williams <dcbw@...hat.com>
cc:	Patrick McHardy <kaber@...sh.net>,
	Matt Domsch <Matt_Domsch@...l.com>, netdev@...r.kernel.org,
	linux-hotplug@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Network Device Naming mechanism and policy

On Tue, 24 Mar 2009, Dan Williams wrote:

> On Tue, 2009-03-24 at 17:21 +0100, Patrick McHardy wrote:
>> Matt Domsch wrote:
>>> 2) udev may have rules to change the device names.  This is most often
>>>    seen in the '70-persistent-net.rules' file.  Here we have
>>>    additional challenges:
>>>
>>> ...
>>>
>>>    c) udev may not always be able to change a device's name.  If udev
>>>       uses the kernel assignment namespace (ethN), then a rename of
>>>       eth0->eth1 may require renaming eth1->eth0 (or something else).
>>>       Udev operates on a single device instance at a time, it becomes
>>>       difficult to switch names around for multiple devices, within
>>>       the single namespace.
>>
>> I would classify this as a bug, especially the fact that udev doesn't
>> undo a failed rename, so you end up with ethX_rename. Virtual devices
>> using the same MAC address trigger this reliably unless you add
>> exceptions to the udev rules.
>
> Any particular reason the MAC addresses are the same?  This came up a
> while ago with the 'dnet' device in the thread "Dave DNET ethernet
> controller".
>
> If the MAC address isn't a UUID for the device, then *what* is?

I have seen systems (I think they were Sun boxes) where the _machine_ had 
a MAC address, and it used that same MAC on all interfaces.

this is convienient for some things, but not for others.

what's unique and reproducable is the discovery order

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ