Re: persistent-net.rules for fixed ethX names and VLANs
Steffen Dettmer a écrit :
>
> On Tue, Nov 19, 2013 at 11:24 PM, Pascal Hambourg
> <pascal@plouf.fr.eu.org> wrote:
>
>> A "real" network interface has the (non-null) driver name in
>> its parent device and thus matches the rule, whereas a "virtual" VLAN
>> interface does not.
>
> Thank you for your explanation. I think I understood well, but
> there seems to be a missing detail in my case: although for
> almost any device this might be true, but as the "udevadm info" from
> my original posting shows, there are drivers that do not do so.
> (For such devices, the Debian udev scripts do not even generate
> persistent net rules, because DRIVER must match non-empty in
> the generator script).
>
> The driver used here is "ksz884x".
>
> If it is required that a driver for a physical network card sets
> DRIVER and no other driver is allowed to do so (which IMHO would
> be a precondition to safely bind udev rules on that), I think
> this would indicate an issue with the driver "ksz884x".
>
> What do you think, is this right?
AFAICS the network interface device itself always has an empty DRIVER,
however (at least one of) the *parent* devices should have a non-empty
DRIVER, this is why the rules have DRIVERS and not just DRIVER. You did
not show the parent devices for the eth interface.
> (By the way, from a technical viewpoint I dislike the idea to
> distinguish ethernet/parent/physical devices from virtual
> devices like VLAN devices by determining the presence of a
> DRIVER name.
I tend to agree with you, this sounds a bit like a hack.
> Also, different virtual devices, like VLAN and
> [guessed] bridge interfaces would be indistinguishable.
Indistinguishable from what ?
>>> # Avoid renaming of VLAN interfaces:
>>> SUBSYSTEM=="net", KERNEL=="eth*.*" ACTION=="add", NAME="$kernel"
>>>
>>> Of course this only works as long as following the naming
>>> convention to call the VLAN interface "eth<X>.<V>" with <V> being
>>> the number of the VLAN tag, for example "eth3.77".
>>
>> It does not matter : the other naming convention vlan<V> won't match the
>> rule and thus won't be renamed, which is the desired behaviour IIUC.
>
> (assuming with "other naming convention" you mean the "standard
> rules" as generated by Debian net rule generator:)
No, I mean the other naming convention that can be used for VLAN
interfaces. See man vconfig. You can select between ethX.V, ethX.VVVV,
vlanV, vlanVVVV.
Reply to: