[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: persistent-net.rules for fixed ethX names and VLANs



Hi,

sorry, unfortunately I missed your mail, thank you for your
response and sorry for the delay.

On Tue, Nov 19, 2013 at 11:24 PM, Pascal Hambourg
<pascal@plouf.fr.eu.org> wrote:
> Hello,
>
> Steffen Dettmer a écrit :
>> On Thu, Nov 14, 2013 at 4:36 PM, Steffen Dettmer
>> <steffen.dettmer@gmail.com> wrote:
>>> I have persistent-net.rules in form:
>>>
>>>   SUBSYSTEM=="net", KERNEL=="eth*" ACTION=="add",
>>>     ATTR{address}=="40:d8:55:09:43:0f", NAME="eth3"
>>>
>>> How to use fixed ethX device names and VLAN devices at the same time?
>
> The behaviour you describe does not happen on a standard Debian system.
> I guess it is because the standard rules have the DRIVERS="?*"

Yes, the rules generated by the Debian net rule generator (which
are the "standard rules", right?) include DRIVERS="?*" (and are
only generated for devices that have a DRIVER=).

> condition. 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?

  (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.  Also, different virtual devices, like VLAN and
  [guessed] bridge interfaces would be indistinguishable. This
  seems not to be a "Debian thing" but possibly a general udev
  weakness?)

>>   # 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:)
You are absolutely right, but the standard naming convention
here already fails for the network card, because its driver does
not set the DRIVER name field to a non-empty value.

Regards,
Steffen


Reply to: