On Wed, Jan 16, 2008 at 12:44:01PM +0100, Ard van Breemen wrote:
> On Mon, Jan 14, 2008 at 10:21:15AM +0100, Lo??c Minier wrote:
>> from your data above, it seems like it is either an udev or a
>> kernel bug. I'm tentatively reassigning this to udev
> But from the config from lionel I guess people are making the
> mistake into thinking that mac-addressess are unique, but they are
> not.
"People" here refers to the default
/etc/udev/rules.d/z45_persistent-net-generator.rules shipped in Debian
by the "udev" package.
Further testing shows that the problem indeed is that the
z25_persistent-net.rules match the vlan interfaces and try to rename
them to the same name as their base (real) interface. Why it works
with some kernel/udev combinations is unknown to me, but let's focus
on recent kernels and udev here, where the problem does appear.
I see several possible solutions; if the vlan and udev maintainers
could come to an agreement on this?
- the udev package could ship a different
z45_persistent-net-generator.rules, that does not assume uniqueness
of MAC addresses (as suggested by Ard) _and_ leaves vlan interfaces
alone. (If they are renamed at all, the ifupdown plugin in the vlan
package gets confused in all cases.)
The question is what to use instead of MAC addresses to recognise
interfaces.
Ard suggests PCI bus IDs. A disadvantage is that if one moves cards
from one PCI slot to another one, they change names, which is not
good for some scenario. An advantage, is that if a NIC is broken
and replaced by another one in the same slot, it silently takes the
same name, which is good for some (other) scenario. Also it means
that in a "complete cold spare machine" scenario, if one moves one
machine's hard disks into another (identical) machine, again the
same interface (the same RJ45 hole in the chassis) will have the
same interface name in Debian GNU/Linux. That's also an attractive
feature.
Any other idea? udev willing to do that, maybe after a wider
discussion on debian-devel or something like that?
- the udev package ships a different
z45_persistent-net-generator.rules, that does not assume uniqueness
of MAC addresses, but does not treat vlan interfaces interfaces
specially either.
The vlan package is changed to not be confused by udev renaming the
interface; this would mean that the ifupdown plugin is not anymore
activated on the _name_ of the interface, and not take any
information from the name of the interface, but always through
explicit configuration options such as "vlan-raw-device" and
"vlan-id". And take this opportunity to make it so that having both
an inet and inet6 stanza for a vlan interface works :)
- the vlan package could ship a z19_vlan that would preempt
z20_persistent-net.rules by specifying that vlan interfaces should
keep their kernel name.
For the first and last scenario, the question is how to recognise vlan
interfaces... I wanted to match by DRIVER=="8021q", but this does not
work. Then I thought maybe interfaces attached to no bus, by BUS==""
but this matches PCI interfaces, too. The best I could find is:
ACTION=="add", SUBSYSTEM=="net", KERNEL=="vlan*", NAME="%k"
ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*.*", NAME="%k"
or
ACTION=="add", SUBSYSTEM=="net", KERNEL=="vlan*", NAME="%k"
ACTION=="add", SUBSYSTEM=="net", KERNEL=="*.*", NAME="%k"
and then I realised that "true" interfaces have PHYSDEVPATH,
PHYSDEVBUS and PHYSDEVDRIVER in their environment. So we can use:
ACTION=="add", SUBSYSTEM=="net", ENV{PHYSDEVDRIVER}=="", NAME="%k"
Will this catch only "virtual" interfaces and no physical interface,
even in corner cases such as sparc, old machines, etc? If an expert
could take a look at this...
In all cases, it would be good if vlan mentioned this situation in its
README.Debian.
> The only correct method which will probably support *all* variants
> of pci cards that have the same mac-address (like the sparc),
Isn't it a break of some IEEE standard to sell two NICs with the same
MAC address? Aren't they supposed to be unique for physical
interfaces?
(This does not change the fact that MAC addresses are not unique as
far as Linux is concerned, because of multiple virtual interfaces on
the same physical interface, and that thus the assumption udev is
doing now is wrong.)
> or none at all (there are a lot of cards that came without a valid
> mac-address, or where it simply isn't possible to look it up, like
> the lp486e):
That's strange, I expected that the kernel needed to know the MAC
address of the interface, to generate the right ARP messages and all
that? And if the card does not _have_ a valid MAC address, how does
the kernel come up with one that is unique on the network? That is
necessary, isn't it?
--
Lionel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
