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.

    • Offizieller Beitrag

    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.)

    • Offizieller Beitrag

    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

    • Offizieller Beitrag

    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.

    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.

  • 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.

  • 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.

    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

    • Offizieller Beitrag

    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.

    • Offizieller Beitrag

    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.

  • 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.


    @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.

    • Offizieller Beitrag

    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.
    __________________________________________________

    @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. ;)

  • 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. ;)

  • Let us know how it went with NetworkManager and info in the link, one way or the other. It's a configuration issue that must be looked at, so your results will be of interest.

    Yes, sure. I will post the results here as soon as I apply the test. Thanks for support.

    • Offizieller Beitrag

    OK, I have the rock64 board and have OMV5 installed. I've had some strange name resolution that seem to be intermittent. Interestingly, with a static address assigned in the GUI, the name resolution issues disappear. So, with a static address and DNS server defined in the GUI, I disabled Networkmanager.


    systemctl stop NetworkManager.service
    systemctl disable NetworkManager.service


    We'll see how this goes for awhile.

  • OK, I have the rock64 board and have OMV5 installed. I've had some strange name resolution that seem to be intermittent. Interestingly, with a static address assigned in the GUI, the name resolution issues disappear. So, with a static address and DNS server defined in the GUI, I disabled Networkmanager.


    systemctl stop NetworkManager.service
    systemctl disable NetworkManager.service


    We'll see how this goes for awhile.

    Thanks for sharing. I still didn't test mine. To be honest, I couldn't catch some time to clone the card and test this. During the day the device is used so I cannot power off. I will do it soon and let You know what I achieved.


    Best Regards.

  • Hello friends,


    I have finally managed to clone the card and test this. Disabling network manager solved the problem but I don't know if I lost anything else by doing that. Time will tell..
    Many thanks for help!


    Best Regards.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!