prioritize udev-rules before the driver/kernel occupy the name of the network interfaces
I have an ubuntu server 14.04 virtual machine with 2 network interfaces
eth0
- for web management, SSH
eth1
- for incoming span network analysis
I've configured the machine with udev rules (to ensure consistency and proper binding of mac-addresses to logical network interfaces names.
- I'm doing it only once when installing the server
writing these rules in
/etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:f5:aa:02", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:f5:aa:f8", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="eth0"
This setup works as expected until new network interfaces are added to the machine.
It's important to remind that the new interfaces are not added to the udev rules. (because I'm only doing it's once in the setup process)
I'm expecting the new network interfaces names to be any generic name (such as eth3
/p2p1
/em1
/...) as long as the name is not occupied by a udev rule.
This is what I experience after adding the interfaces and booting up the machine:
- my udev rule was ignored/conflicted and named
rename3
eth0
got hijacked. one of the new interfaces is noweth0
. this is super-problematic security-wise (can lead to data-leakage)
This is the related flow I've found in /var/log/dmesg
systemd-udevd[126]: starting version 204
...
vmxnet3 0000:04:00.0 eth0: NIC Link is Up 10000 Mbps
vmxnet3 0000:0b:00.0 eth1: NIC Link is Up 10000 Mbps
vmxnet3 0000:13:00.0 eth2: NIC Link is Up 10000 Mbps
vmxnet3 0000:1b:00.0 eth3: NIC Link is Up 10000 Mbps
...
vmxnet3 0000:0b:00.0 rename3: renamed from eth1
vmxnet3 0000:13:00.0 eth1: renamed from eth2
systemd-udevd[396]: renamed network interface eth1 to rename3
systemd-udevd[405]: renamed network interface eth2 to eth1
- IMO It's a race-condition. The driver/kernel occupy the names. later when my udev rules execute, the occupied names fallback to
rename*
Question,
Is there a way to change the order and prioritize udev-rules before the driver/kernel occupy the name of the interface?
NOTE - these workarounds (POC-level) worked for me:
- using a different naming convention in udev rules ( e.g.
management0
andspan0
) - worked without problems since it's not colliding with default.
- script to run @ boot - will redefine the udev rules on hardware changes - worked, but requires an additional reboot (naive approach) -
worked without problems
14.04 networking server
add a comment |
I have an ubuntu server 14.04 virtual machine with 2 network interfaces
eth0
- for web management, SSH
eth1
- for incoming span network analysis
I've configured the machine with udev rules (to ensure consistency and proper binding of mac-addresses to logical network interfaces names.
- I'm doing it only once when installing the server
writing these rules in
/etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:f5:aa:02", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:f5:aa:f8", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="eth0"
This setup works as expected until new network interfaces are added to the machine.
It's important to remind that the new interfaces are not added to the udev rules. (because I'm only doing it's once in the setup process)
I'm expecting the new network interfaces names to be any generic name (such as eth3
/p2p1
/em1
/...) as long as the name is not occupied by a udev rule.
This is what I experience after adding the interfaces and booting up the machine:
- my udev rule was ignored/conflicted and named
rename3
eth0
got hijacked. one of the new interfaces is noweth0
. this is super-problematic security-wise (can lead to data-leakage)
This is the related flow I've found in /var/log/dmesg
systemd-udevd[126]: starting version 204
...
vmxnet3 0000:04:00.0 eth0: NIC Link is Up 10000 Mbps
vmxnet3 0000:0b:00.0 eth1: NIC Link is Up 10000 Mbps
vmxnet3 0000:13:00.0 eth2: NIC Link is Up 10000 Mbps
vmxnet3 0000:1b:00.0 eth3: NIC Link is Up 10000 Mbps
...
vmxnet3 0000:0b:00.0 rename3: renamed from eth1
vmxnet3 0000:13:00.0 eth1: renamed from eth2
systemd-udevd[396]: renamed network interface eth1 to rename3
systemd-udevd[405]: renamed network interface eth2 to eth1
- IMO It's a race-condition. The driver/kernel occupy the names. later when my udev rules execute, the occupied names fallback to
rename*
Question,
Is there a way to change the order and prioritize udev-rules before the driver/kernel occupy the name of the interface?
NOTE - these workarounds (POC-level) worked for me:
- using a different naming convention in udev rules ( e.g.
management0
andspan0
) - worked without problems since it's not colliding with default.
- script to run @ boot - will redefine the udev rules on hardware changes - worked, but requires an additional reboot (naive approach) -
worked without problems
14.04 networking server
add a comment |
I have an ubuntu server 14.04 virtual machine with 2 network interfaces
eth0
- for web management, SSH
eth1
- for incoming span network analysis
I've configured the machine with udev rules (to ensure consistency and proper binding of mac-addresses to logical network interfaces names.
- I'm doing it only once when installing the server
writing these rules in
/etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:f5:aa:02", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:f5:aa:f8", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="eth0"
This setup works as expected until new network interfaces are added to the machine.
It's important to remind that the new interfaces are not added to the udev rules. (because I'm only doing it's once in the setup process)
I'm expecting the new network interfaces names to be any generic name (such as eth3
/p2p1
/em1
/...) as long as the name is not occupied by a udev rule.
This is what I experience after adding the interfaces and booting up the machine:
- my udev rule was ignored/conflicted and named
rename3
eth0
got hijacked. one of the new interfaces is noweth0
. this is super-problematic security-wise (can lead to data-leakage)
This is the related flow I've found in /var/log/dmesg
systemd-udevd[126]: starting version 204
...
vmxnet3 0000:04:00.0 eth0: NIC Link is Up 10000 Mbps
vmxnet3 0000:0b:00.0 eth1: NIC Link is Up 10000 Mbps
vmxnet3 0000:13:00.0 eth2: NIC Link is Up 10000 Mbps
vmxnet3 0000:1b:00.0 eth3: NIC Link is Up 10000 Mbps
...
vmxnet3 0000:0b:00.0 rename3: renamed from eth1
vmxnet3 0000:13:00.0 eth1: renamed from eth2
systemd-udevd[396]: renamed network interface eth1 to rename3
systemd-udevd[405]: renamed network interface eth2 to eth1
- IMO It's a race-condition. The driver/kernel occupy the names. later when my udev rules execute, the occupied names fallback to
rename*
Question,
Is there a way to change the order and prioritize udev-rules before the driver/kernel occupy the name of the interface?
NOTE - these workarounds (POC-level) worked for me:
- using a different naming convention in udev rules ( e.g.
management0
andspan0
) - worked without problems since it's not colliding with default.
- script to run @ boot - will redefine the udev rules on hardware changes - worked, but requires an additional reboot (naive approach) -
worked without problems
14.04 networking server
I have an ubuntu server 14.04 virtual machine with 2 network interfaces
eth0
- for web management, SSH
eth1
- for incoming span network analysis
I've configured the machine with udev rules (to ensure consistency and proper binding of mac-addresses to logical network interfaces names.
- I'm doing it only once when installing the server
writing these rules in
/etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:f5:aa:02", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:f5:aa:f8", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="eth0"
This setup works as expected until new network interfaces are added to the machine.
It's important to remind that the new interfaces are not added to the udev rules. (because I'm only doing it's once in the setup process)
I'm expecting the new network interfaces names to be any generic name (such as eth3
/p2p1
/em1
/...) as long as the name is not occupied by a udev rule.
This is what I experience after adding the interfaces and booting up the machine:
- my udev rule was ignored/conflicted and named
rename3
eth0
got hijacked. one of the new interfaces is noweth0
. this is super-problematic security-wise (can lead to data-leakage)
This is the related flow I've found in /var/log/dmesg
systemd-udevd[126]: starting version 204
...
vmxnet3 0000:04:00.0 eth0: NIC Link is Up 10000 Mbps
vmxnet3 0000:0b:00.0 eth1: NIC Link is Up 10000 Mbps
vmxnet3 0000:13:00.0 eth2: NIC Link is Up 10000 Mbps
vmxnet3 0000:1b:00.0 eth3: NIC Link is Up 10000 Mbps
...
vmxnet3 0000:0b:00.0 rename3: renamed from eth1
vmxnet3 0000:13:00.0 eth1: renamed from eth2
systemd-udevd[396]: renamed network interface eth1 to rename3
systemd-udevd[405]: renamed network interface eth2 to eth1
- IMO It's a race-condition. The driver/kernel occupy the names. later when my udev rules execute, the occupied names fallback to
rename*
Question,
Is there a way to change the order and prioritize udev-rules before the driver/kernel occupy the name of the interface?
NOTE - these workarounds (POC-level) worked for me:
- using a different naming convention in udev rules ( e.g.
management0
andspan0
) - worked without problems since it's not colliding with default.
- script to run @ boot - will redefine the udev rules on hardware changes - worked, but requires an additional reboot (naive approach) -
worked without problems
14.04 networking server
14.04 networking server
edited Dec 12 at 10:05
asked Dec 12 at 9:54
Jossef Harush
2,5671914
2,5671914
add a comment |
add a comment |
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1100267%2fprioritize-udev-rules-before-the-driver-kernel-occupy-the-name-of-the-network-in%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1100267%2fprioritize-udev-rules-before-the-driver-kernel-occupy-the-name-of-the-network-in%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown