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
<pas...@plouf.fr.eu.org> wrote:
> Hello,
>
> Steffen Dettmer a écrit :
>> On Thu, Nov 14, 2013 at 4:36 PM, Steffen Dettmer
>> <steffen.dett...@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
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caobounojt1mqhhop5d613khuyf_o3phmquwcihrjubc5jut...@mail.gmail.com
