Unsupported installation on HassOS due to Network Manager but no clue why

[heymoe]

HassOS release with the issue:

arch    x86_64
chassis vm
dev false
docker  true
docker_version  19.03.11
hassio  true
host_os HassOS 4.15
installation_type   Home Assistant OS
os_name Linux
os_version  5.4.72
python_version  3.8.5
supervisor  249
timezone    America/New_York
version 0.116.4
virtualenv  false

Supervisor logs:

20-10-26 18:57:02 ERROR (MainThread) [supervisor.core] NetworkManager is not correctly configured
20-10-26 18:57:02 WARNING (MainThread) [supervisor.core] System running in a unsupported environment!

Description of problem: I switched to running HA off of the official HassOS image (qcow2) in a KVM to make sure my environment was fully supported. I previously ran HA on a ArchLinux VM with HassIO installed with the official installer which was working fine but the supervisor -> system screen showed I had a few unsupported items thus the switch to HassOS.

I got everything up and running on HassOS using a backup but found that my supervisor -> system screen was still saying I'm running an unsupported environment due to "Network Manager".

From a shell, "systemctl status NetworkManger" show Network Manager is up and running and nmcli shows two interfaces are up and running:

# nmcli con show
NAME            UUID                                  TYPE      DEVICE
my-network      c02b4b68-6b94-4548-850c-04af9e972994  vlan      enp1s0.100
HassOS default  f62bf7c2-e565-49ff-bbfc-a4cf791e6add  ethernet  enp1s0

The my-network interface is the real / active network connection while the "HassOS default" interface is setup disable IPv4 and IPv6 to prevent Network Manager from trying to get an IP for the enp1s0 interface, otherwise booting will hang for a bit while it tries to get an IP for that interface but will eventually timeout and continue booting. The config files that setup these interfaces are in the /etc/NetworkManager/system-connections/ directory.

I have tried making my vlan config the "HassOS default" using the "f62bf7c2-e565-49ff-bbfc-a4cf791e6add" UUID in case the supervisor was expecting the real network to be defined as such with and without a second interface / config that would prevent Network Manager from trying to get an IP for enp1s0. Didn't seem to help any.

The logs don't really tell me anything as to why the supervisor thinks Network Manager is not configured correctly especially since Network Manager is up and running. I can only assume it has something to do with using vlan tagging on the main interface.

Let me know if you need some other information. Thanks!

[pvizeli]

Yeah. VLAN on the device instead of tagging it at the network port is currently not a supported setup. Feel free to join into development and help out or change it to tag it on the switch. Otherwise, your setup will still work at some point, but it can lose functionality. I.e. next samba add-on remove the network interface option and get it from Supervisor or just stop starting with an error that no network was found. Other add-ons can follow also plugins.

[ludeeus]

Can you post the full output of your "my-network" connection (nmcli con show "my-network")?

[heymoe]

@pvizeli : Bummer.. Happy to help where I can to get vlan tagging supported.

@ludeeus : Here is my output.

connection.id:                          my-network
connection.uuid:                        19d6bc29-aee8-4e4b-a230-9ef3b9042d05
connection.stable-id:                   --
connection.type:                        vlan
connection.interface-name:              --
connection.autoconnect:                 yes
connection.autoconnect-priority:        0
connection.autoconnect-retries:         -1 (default)
connection.multi-connect:               0 (default)
connection.auth-retries:                -1
connection.timestamp:                   1603750614
connection.read-only:                   no
connection.permissions:                 --
connection.zone:                        --
connection.master:                      --
connection.slave-type:                  --
connection.autoconnect-slaves:          -1 (default)
connection.secondaries:                 --
connection.gateway-ping-timeout:        0
connection.metered:                     unknown
connection.lldp:                        default
connection.mdns:                        -1 (default)
connection.llmnr:                       -1 (default)
connection.wait-device-timeout:         -1
802-3-ethernet.port:                    --
802-3-ethernet.speed:                   0
802-3-ethernet.duplex:                  --
802-3-ethernet.auto-negotiate:          no
802-3-ethernet.mac-address:             --
802-3-ethernet.cloned-mac-address:      --
802-3-ethernet.generate-mac-address-mask:--
802-3-ethernet.mac-address-blacklist:   --
802-3-ethernet.mtu:                     auto
802-3-ethernet.s390-subchannels:        --
802-3-ethernet.s390-nettype:            --
802-3-ethernet.s390-options:            --
802-3-ethernet.wake-on-lan:             default
802-3-ethernet.wake-on-lan-password:    --
ipv4.method:                            manual
ipv4.dns:                               ###.###.###.###
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.addresses:                         ###.##.###.###/24
ipv4.gateway:                           ###.###.###.###
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)
ipv4.routing-rules:                     --
ipv4.ignore-auto-routes:                no
ipv4.ignore-auto-dns:                   yes
ipv4.dhcp-client-id:                    --
ipv4.dhcp-timeout:                      0 (default)
ipv4.dhcp-send-hostname:                yes
ipv4.dhcp-hostname:                     --
ipv4.dhcp-fqdn:                         --
ipv4.never-default:                     no
ipv4.may-fail:                          yes
ipv4.dad-timeout:                       -1 (default)
ipv6.method:                            auto
ipv6.dns:                               --
ipv6.dns-search:                        --
ipv6.dns-options:                       --
ipv6.dns-priority:                      0
ipv6.addresses:                         --
ipv6.gateway:                           --
ipv6.routes:                            --
ipv6.route-metric:                      -1
ipv6.route-table:                       0 (unspec)
ipv6.routing-rules:                     --
ipv6.ignore-auto-routes:                no
ipv6.ignore-auto-dns:                   no
ipv6.never-default:                     no
ipv6.may-fail:                          yes
ipv6.ip6-privacy:                       -1 (unknown)
ipv6.addr-gen-mode:                     stable-privacy
ipv6.dhcp-duid:                         --
ipv6.dhcp-send-hostname:                yes
ipv6.dhcp-hostname:                     --
ipv6.token:                             --
vlan.parent:                            enp1s0
vlan.id:                                100
vlan.flags:                             1 (REORDER_HEADERS)
vlan.ingress-priority-map:              --
vlan.egress-priority-map:               --
proxy.method:                           none
proxy.browser-only:                     no
proxy.pac-url:                          --
proxy.pac-script:                       --
GENERAL.NAME:                           my-network
GENERAL.UUID:                           19d6bc29-aee8-4e4b-a230-9ef3b9042d05
GENERAL.DEVICES:                        enp1s0.100
GENERAL.STATE:                          activated
GENERAL.DEFAULT:                        yes
GENERAL.DEFAULT6:                       no
GENERAL.SPEC-OBJECT:                    --
GENERAL.VPN:                            no
GENERAL.DBUS-PATH:                      /org/freedesktop/NetworkManager/ActiveConnection/1
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/Settings/2
GENERAL.ZONE:                           --
GENERAL.MASTER-PATH:                    --
IP4.ADDRESS[1]:                         ###.###.###.###/24
IP4.GATEWAY:                            ###.###.###.###
IP4.ROUTE[1]:                           dst = ###.###.###.###/24, nh = 0.0.0.0, mt = 400
IP4.ROUTE[2]:                           dst = 0.0.0.0/0, nh = ###.###.###.###, mt = 400
IP4.DNS[1]:                             ###.###.###.###
IP6.ADDRESS[1]:                         xxxx::xxxx:xxxx:xxxx:xxxx/64
IP6.GATEWAY:                            --
IP6.ROUTE[1]:                           dst = fe80::/64, nh = ::, mt = 400
IP6.ROUTE[2]:                           dst = ff00::/8, nh = ::, mt = 256

[ludeeus]

Currently been filter on device type, I have to look closer on that output, but it looks like it might have all we need, I assume you masked your internal IPs manually and it did not report with #?

[heymoe]

You're correct, I masked my IPs with ###.###.###.###

[ludeeus]

Looked it over, for our current implementation, it should just work if we add vlan to the filter. But since I'm not able to testing, I can't be sure and I can't write tests to ensure that it will continue to work in the future, so I'm not confident enough to make that change in the codebase.

But honestly, you should just have your hypervisor handle the networking, and pass an untagged interface to the VM. That way you don't need VLAN handing inside the VM itself.

Or if you know your way around python, feel free to jump in on the development of the Supervisor :tada:

[heymoe]

OK.. dug around the code in the supervisor container and made two changes based on how it's filtering for the ethernet and wireless interfaces.

Here are the changes I made:

/usr/src/supervisor/supervisor/dbus/const.py:

At the bottom of the file I added: VLAN = "vlan" to the class ConnectionType.

Before:

class ConnectionType(str, Enum):                          
    """Connection type."""                                                    

    ETHERNET = "802-3-ethernet"               
    WIRELESS = "802-11-wireless"

After:

class ConnectionType(str, Enum):                          
    """Connection type."""                                                    

    ETHERNET = "802-3-ethernet"               
    WIRELESS = "802-11-wireless"
    VLAN = "vlan"

/usr/src/supervisor/supervisor/dbus/network/__init__.py:

Toward the bottom of this file in the NetworkManager class there is an if statement (filter) that looking for the defined connectionTypes from the above file. I added VLAN to the list / filter.

Before:

            if interface.connection.type not in [
                ConnectionType.ETHERNET,
                ConnectionType.WIRELESS,
            ]:

After:

            if interface.connection.type not in [
                ConnectionType.ETHERNET,
                ConnectionType.WIRELESS,
                ConnectionType.VLAN,
            ]:

After that, I restarted the supervisor and once it reloaded I went to the Supervisor -> System screen in HA and it no longer says I'm running an unsupported installation AND in the "Host System" box it actually shows the correct IP and netmask of my box now where as before that wasn't being shown at all. There were no other errors / warnings in the supervisor logs also.

I understand what you're saying about having the host pass an untagged interface to the guest but there are use cases for having the guest do the tagging itself from a general virtual environment point of view. I'll look into getting an untagged interface configured up to pass to HassOS but if adding 2 lines of code can make the supervisor get the IPv4 info it needs from a vlan interface, then maybe this something that should be considered supporting too. Granted there might be more to this then just getting the IPv4 information from an interface that I'm not aware of that I understand needs to be taken into consideration too.

[ludeeus]

Yes, that's the filtering I was talking about, and it will work for now, but we can't really be sure what the future brings. Those 2 changes in themselves are not what worries me, it's what they make possible.

Now you have full access to that interface, with functions that have only been tested with the 2 connection types we have. VLAN interfaces might require/expect different types of data when operating them. For you, it might not be a problem, but it others now get access to these features that are not tested, it can be bad.

And any changes we might do in the future might make those possibilities even worse.

@pvizeli what do you think?

[ludeeus]

Support implemented in home-assistant/supervisor#2217