prioritize udev-rules before the driver/kernel occupy the name of the network interfaces












0














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"



enter image description here





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:



enter image description here




  1. my udev rule was ignored/conflicted and named rename3


  2. eth0 got hijacked. one of the new interfaces is now eth0. 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 and span0) - 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











share|improve this question





























    0














    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"



    enter image description here





    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:



    enter image description here




    1. my udev rule was ignored/conflicted and named rename3


    2. eth0 got hijacked. one of the new interfaces is now eth0. 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 and span0) - 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











    share|improve this question



























      0












      0








      0







      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"



      enter image description here





      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:



      enter image description here




      1. my udev rule was ignored/conflicted and named rename3


      2. eth0 got hijacked. one of the new interfaces is now eth0. 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 and span0) - 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











      share|improve this question















      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"



      enter image description here





      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:



      enter image description here




      1. my udev rule was ignored/conflicted and named rename3


      2. eth0 got hijacked. one of the new interfaces is now eth0. 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 and span0) - 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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Dec 12 at 10:05

























      asked Dec 12 at 9:54









      Jossef Harush

      2,5671914




      2,5671914



























          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
          });


          }
          });














          draft saved

          draft discarded


















          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
















          draft saved

          draft discarded




















































          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.




          draft saved


          draft discarded














          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





















































          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







          Popular posts from this blog

          flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

          Mangá

           ⁒  ․,‪⁊‑⁙ ⁖, ⁇‒※‌, †,⁖‗‌⁝    ‾‸⁘,‖⁔⁣,⁂‾
”‑,‥–,‬ ,⁀‹⁋‴⁑ ‒ ,‴⁋”‼ ⁨,‷⁔„ ‰′,‐‚ ‥‡‎“‷⁃⁨⁅⁣,⁔
⁇‘⁔⁡⁏⁌⁡‿‶‏⁨ ⁣⁕⁖⁨⁩⁥‽⁀  ‴‬⁜‟ ⁃‣‧⁕‮ …‍⁨‴ ⁩,⁚⁖‫ ,‵ ⁀,‮⁝‣‣ ⁑  ⁂– ․, ‾‽ ‏⁁“⁗‸ ‾… ‹‡⁌⁎‸‘ ‡⁏⁌‪ ‵⁛ ‎⁨ ―⁦⁤⁄⁕