Unclear network behaviour

    • OMV 4.x
    • Unclear network behaviour

      Dear friends,

      I am using openmediavault on my NanoPI M4 board and it works like a charm. I recommend it. Besides, I do have some problem...

      The network setup has two static IP addresses where one belongs to VLAN interface. Everything works nice until power loss happens and returns again when I experience changes on the network interface which are not actually possible to find in settings (network config is as it should be). Settings are unchanged but it all acts like it was configured to accept DHCP and it obtains DHCP address until I reboot it and everything is back to normal with two addresses and VLAN settings. The same thing will happen if I disconnect the LAN cable from it and return again. The system immediately loses the configured addresses and obtains DHCP. Restarting network doesn't help. Only reboot of the system helps.

      Anyone knows what could possibly cause this behavior?

      Best Regards.
    • crashtest wrote:

      This sounds like Network Manager may be conflicting with ifupdown.

      Where did you configure your two static IP addresses?
      Hello friend. Thanks for reply!

      I have configured it via openmediavault web interface. You can check the photo.
      Any clues?

      Best Regards.
      Images
      • Unnamed QQ Screenshot20190911085013.jpg

        95.58 kB, 1,366×657, viewed 28 times
    • Unfortunately, I'm not at home right now so I don't have access to an SBC.

      I can't verify the exact location of the Network Managers conf file.
      It should be here:
      /etc/NetworkManager/NetworkManager.conf
      __________________________________

      In the conf file, changing the following highlighted setting to true:

      [main]
      plugins=ifupdown,keyfile
      [ifupdown]
      managed=true


      Reboot and test.
      _________________________________

      This setting may have significance in another application so please reply, one way or another.
      (If you're not sure how to get on the command line, please advise.)


    • crashtest wrote:

      This setting may have significance in another application so please reply, one way or another.
      I nearly replied to this originally then backed out, but looking at the image I'm trying to makes sense from it;

      eth0 has an ip beginning 172. this is usually the address range that docker uses in bridge mode

      eth0.100 this is the VLAN this has an ip beginning 10. the alternative to 192. for a private network.

      VLAN ip addressing is usually in the same range as the actual Interface.

      TBH looking at it the settings don't make sense
      Raid is not a backup! Would you go skydiving without a parachute?
    • geaves wrote:

      eth0 has an ip beginning 172. this is usually the address range that docker uses in bridge mode
      With his address and subnet mask setting 172.16.0.0/24 , he's well clear of the Docker bridged network 172.17.0.0/16. Even with classfull addressing, he'd be in another class B network. The entire 10.0.0.0/8 network is private as well and free for all to use, behind a router.

      I've never setup sub-interfaces in the GUI. (This is why I asked the user "where" it was configured. I thought this would be command line only.) So, I was somewhat surprised to see that in the GUI, but it makes sense that it's possible.

      geaves wrote:

      VLAN ip addressing is usually in the same range as the actual Interface.
      A VLAN is about layer 2, Ethernet/Datalink. A VLAN is about a logical grouping of physical interfaces. The IP address range attached to a VLAN is another matter altogether but, since it's a separate grouping of interfaces, setting the group up with a separate IP network address range is usually what is done.
    • geaves wrote:

      crashtest wrote:

      This setting may have significance in another application so please reply, one way or another.
      I nearly replied to this originally then backed out, but looking at the image I'm trying to makes sense from it;
      eth0 has an ip beginning 172. this is usually the address range that docker uses in bridge mode

      eth0.100 this is the VLAN this has an ip beginning 10. the alternative to 192. for a private network.

      VLAN ip addressing is usually in the same range as the actual Interface.

      TBH looking at it the settings don't make sense
      Guys, thanks for reply!
      Yes, ETH address is starting with 172 and it is also a private range address. It worked fine until VLAN was added. Why do You think it makes no sense and why there should be VLAN address in the same range? I'm not sure I understand. TBH, having addresses in same range on main and VLAN interface actually makes no sense.
      This is what I have in NetworkManager.conf
      [main]
      dns=default
      rc-manager=file
      plugins=ifupdown,keyfile
      [ifupdown]
      managed=true
      It was already configured to true.
    • crashtest wrote:

      geaves wrote:

      eth0 has an ip beginning 172. this is usually the address range that docker uses in bridge mode
      With his address and subnet mask setting 172.16.0.0/24 , he's well clear of the Docker bridged network 172.17.0.0/16. Even with classfull addressing, he'd be in another class B network. The entire 10.0.0.0/8 network is private as well and free for all to use, behind a router.
      I've never setup sub-interfaces in the GUI. (This is why I asked the user "where" it was configured. I thought this would be command line only.) So, I was somewhat surprised to see that in the GUI, but it makes sense that it's possible.

      geaves wrote:

      VLAN ip addressing is usually in the same range as the actual Interface.
      A VLAN is about layer 2, Ethernet/Datalink. A VLAN is about a logical grouping of physical interfaces. The IP address range attached to a VLAN is another matter altogether but, since it's a separate grouping of interfaces, setting the group up with a separate IP network address range is usually what is done.
      I tried to do as You suggested but the settings was already configured to true in networkmanager.conf

      By the way,

      this is what I can find in interfaces file

      # Include additional interface stanzas.
      source-directory interfaces.d

      # The loopback network interface
      auto lo
      iface lo inet loopback

      # eth0 network interface
      auto eth0
      allow-hotplug eth0
      iface eth0 inet static
      address 172.16.202.40
      gateway 172.16.202.1
      netmask 255.255.255.0
      dns-nameservers 172.16.202.1
      dns-search tntrace.com
      iface eth0 inet6 manual
      pre-down ip -6 addr flush dev $IFACE

      # eth0.100 network interface
      auto eth0.100
      iface eth0.100 inet static
      vlan-raw-device eth0
      address 10.201.100.10
      gateway 10.201.100.1
      netmask 255.255.255.0
      dns-nameservers 172.16.202.2
      dns-search mikrotik
      iface eth0.100 inet6 manual
      vlan-raw-device eth0
      pre-down ip -6 addr flush dev $IFACE
    • The only reason I can come up with, where you'd get a DHCP address when an interface flaps, is Network Manager attempting to keep the interface up regardless. This is what it does and why the Armbian Dev's like it. (It works well with wireless interfaces where interference may be a factor with the wireless int going up and down.)

      ipupdown is more geared toward wired interfaces, where interfaces are unlikely to flap. The "true" setting places ifupdown under NM control but, based on what you're describing, it still seems as if they're conflicting.
      __________________________________________________

      Do you have OS backup? (A cloned copy of your boot drive?) Since you're not using wireless, you could try purging NetworkManager but I don't know if that would break something.

      (OR)

      I have an ARM based board on the way. Can you give me a week or so? I can try removing Network Manager to see what happens.
    • spaxton wrote:

      Guys, thanks for reply!
      Sorry this was me having an MS moment re the Vlan

      @crashtest this came up once before with 'you know who' but from my understanding of that Network Manager does not look in /etc/network/interfaces but in /etc/network/interfaces.d that contains a folder in relation to each network interface, that's what Armbian does.
      Even though the setting managed is set to true in the network.conf, Network Manager is not actually taking control, that may explain why dhcp is being allocated with a power loss. Without directing you to the thread in question this was pointed to within the thread, following that based upon the OP's initial problem this may present a solution.
      Raid is not a backup! Would you go skydiving without a parachute?
    • crashtest wrote:



      __________________________________________________

      Do you have OS backup? (A cloned copy of your boot drive?) Since you're not using wireless, you could try purging NetworkManager but I don't know if that would break something.

      (OR)

      I have an ARM based board on the way. Can you give me a week or so? I can try removing Network Manager to see what happens.
      Many thanks for this!!! I am facing this problem for 3 months already so I am ok to wait. I do have some dd image backup but I don't know how to restore it.

      geaves wrote:


      @crashtest this came up once before with 'you know who' but from my understanding of that Network Manager does not look in /etc/network/interfaces but in /etc/network/interfaces.d that contains a folder in relation to each network interface, that's what Armbian does.
      Even though the setting managed is set to true in the network.conf, Network Manager is not actually taking control, that may explain why dhcp is being allocated with a power loss. Without directing you to the thread in question this was pointed to within the thread, following that based upon the OP's initial problem this may present a solution.
      Thanks for directions! DHCP will assign an IP even if I just disconnect the ethernet and connect again. Armbian reports only one address in this case and it is a DHCP one. When a power loss occur, the switch goes down as well and therefore there is no ethernet link while the armbian is booting. As soon as it gets the link, it will obtain DHCP address. If the link is active then shut down and power on won't trigger this situation to have DHCP address.
    • spaxton wrote:

      I do have some dd image backup but I don't know how to restore it.
      Backup is only good if you know how to restore it. Think about using the cloning process laid out in this -> guide, starting on page 75 - OS backup. It's an off-line process but it's dirt simple to backup and restore. A restoration is as easy as swapping the SD-card and booting up. All it takes is a 2nd SD-card. Really, IMHO, you should have at least two cards.
      __________________________________________________

      geaves wrote:

      @crashtest this came up once before with 'you know who' but from my understanding of that Network Manager does not look in /etc/network/interfaces but in /etc/network/interfaces.d that contains a folder in relation to each network interface, that's what Armbian does.
      Thanks for the -> re-link. :) (There are so many, I'm losing track.) I'll be able to run down a few more details on NetworkManager, first hand, when the Rock64 board arrives. For example, I'd like to see what happens after NetworkManager is purged.
      _________________________________________________

      @spaxton , you might give some thought to trying the process in @geaves 's -> link. That is, of course, after you've cloned your working SD-card. ;)

      The post was edited 1 time, last by crashtest ().

    • crashtest wrote:

      spaxton wrote:

      I do have some dd image backup but I don't know how to restore it.
      Backup is only good if you know how to restore it. Think about using the cloning process laid out in this -> guide, starting on page 75 - OS backup. It's an off-line process but it's dirt simple to backup and restore. A restoration is as easy as swapping the SD-card and booting up. All it takes is a 2nd SD-card. Really, IMHO, you should have at least two cards.__________________________________________________

      @spaxton , you might give some thought to trying the process in @geaves 's -> link. That is, of course, after you've cloned your working SD-card. ;)

      Hahah. Thanks for reply and directions! I have a plenty of SD cards. The link suggests disabling the NetworkManager. I will try this if my backup restoration was successful.

      Best Regards. ;)