Two ethernet interfaces

[ra.ka]

Hi,

I have two ethernet interfaces (virtualized in Proxmox). How do I tell Matter server, which interface should it use?

I selected ens19 as primary in HA, Matter Server reports “ens19” as primary network interface, but later it prints “Found the primary network interface: ens18”

[22:27:24] INFO: Starting Matter Server...
s6-rc: info: service legacy-services successfully started
[22:27:25] INFO: Using 'ens19' as primary network interface.
[22:27:25] INFO: Successfully send discovery information to Home Assistant.
2024-05-01 22:27:26.283 (MainThread) INFO [matter_server.server.stack] Initializing CHIP/Matter Logging...
2024-05-01 22:27:26.284 (MainThread) INFO [matter_server.server.stack] Initializing CHIP/Matter Controller Stack...
[1714595246.309646][126:126] CHIP:CTL: Setting attestation nonce to random value
[1714595246.309895][126:126] CHIP:CTL: Setting CSR nonce to random value
[1714595246.310993][126:126] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_kvs
[1714595246.311142][126:126] CHIP:DL: writing settings to file (/tmp/chip_kvs-LgBylJ)
[1714595246.311227][126:126] CHIP:DL: renamed tmp file to file (/tmp/chip_kvs)
[1714595246.311515][126:126] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /data/chip_factory.ini
[1714595246.311592][126:126] CHIP:DL: writing settings to file (/data/chip_factory.ini-ilBLSH)
[1714595246.311640][126:126] CHIP:DL: renamed tmp file to file (/data/chip_factory.ini)
[1714595246.311672][126:126] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /data/chip_config.ini
[1714595246.311706][126:126] CHIP:DL: writing settings to file (/data/chip_config.ini-0ODN4G)
[1714595246.311772][126:126] CHIP:DL: renamed tmp file to file (/data/chip_config.ini)
[1714595246.311807][126:126] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /data/chip_counters.ini
[1714595246.311859][126:126] CHIP:DL: writing settings to file (/data/chip_counters.ini-PObZSK)
[1714595246.311904][126:126] CHIP:DL: renamed tmp file to file (/data/chip_counters.ini)
[1714595246.312216][126:126] CHIP:DL: writing settings to file (/data/chip_factory.ini-4UEVEJ)
[1714595246.312405][126:126] CHIP:DL: renamed tmp file to file (/data/chip_factory.ini)
[1714595246.312421][126:126] CHIP:DL: NVS set: chip-factory/unique-id = "1DF4307CBD679BA5"
[1714595246.312564][126:126] CHIP:DL: writing settings to file (/data/chip_factory.ini-R2Rz2G)
[1714595246.312854][126:126] CHIP:DL: renamed tmp file to file (/data/chip_factory.ini)
[1714595246.312878][126:126] CHIP:DL: NVS set: chip-factory/vendor-id = 65521 (0xFFF1)
[1714595246.312958][126:126] CHIP:DL: writing settings to file (/data/chip_factory.ini-x1dFKJ)
[1714595246.313098][126:126] CHIP:DL: renamed tmp file to file (/data/chip_factory.ini)
[1714595246.313122][126:126] CHIP:DL: NVS set: chip-factory/product-id = 32769 (0x8001)
[1714595246.313185][126:126] CHIP:DL: writing settings to file (/data/chip_counters.ini-4IxOLJ)
[1714595246.313319][126:126] CHIP:DL: renamed tmp file to file (/data/chip_counters.ini)
[1714595246.313333][126:126] CHIP:DL: NVS set: chip-counters/reboot-count = 1 (0x1)
[1714595246.313394][126:126] CHIP:DL: writing settings to file (/data/chip_counters.ini-WPeMdJ)
[1714595246.313594][126:126] CHIP:DL: renamed tmp file to file (/data/chip_counters.ini)
[1714595246.313617][126:126] CHIP:DL: NVS set: chip-counters/total-operational-hours = 0 (0x0)
[1714595246.313735][126:126] CHIP:DL: writing settings to file (/data/chip_counters.ini-8nyF7H)
[1714595246.313872][126:126] CHIP:DL: renamed tmp file to file (/data/chip_counters.ini)
[1714595246.313888][126:126] CHIP:DL: NVS set: chip-counters/boot-reason = 0 (0x0)
[1714595246.313990][126:126] CHIP:DL: writing settings to file (/data/chip_config.ini-8urAOK)
[1714595246.314099][126:126] CHIP:DL: renamed tmp file to file (/data/chip_config.ini)
[1714595246.314112][126:126] CHIP:DL: NVS set: chip-config/regulatory-location = 0 (0x0)
[1714595246.314196][126:126] CHIP:DL: writing settings to file (/data/chip_config.ini-5AdmnK)
[1714595246.314314][126:126] CHIP:DL: renamed tmp file to file (/data/chip_config.ini)
[1714595246.314333][126:126] CHIP:DL: NVS set: chip-config/location-capability = 2 (0x2)
[1714595246.314671][126:126] CHIP:DL: Got Ethernet interface: ens18
[1714595246.366019][126:126] CHIP:DL: Found the primary Ethernet interface:ens18
[1714595246.367042][126:126] CHIP:DL: Failed to get WiFi interface
[1714595246.367067][126:126] CHIP:DL: Failed to reset WiFi statistic counts

[WallyR (Wally)]

You can’t.
HA does not have the options needed to do this.

[wmaker (Tommy Long)]

@ra.ka

I selected ens19 as primary in HA

Hi, may I ask how one selects a primary network interface in HA?
Are you referring to UI->Settings->Systems->Network->Network Adapter?
Best Regards

[ra.ka]

Yes, correct.

I run HA Supervised in Ubuntu, which is virtualized in Proxmox, so it is easy to map the VLANs to the ethernet interfaces and swap MAC addresses. Whatever mapping of VLAN to ETH ports and MAC addresses the Matter always selected the subnet that I didn’t want. I have not changed IP address on the subnet, so maybe it selects the interface based on the IP address?

[wmaker (Tommy Long)]

After doing a little research …

HA’s Supervisor picks the primary interface (it is believed to be based on the interface with the default gateway route), and other AddONs such as Matter call a Supervisor API to get this primary interface.

When one has multiple interfaces, the Forum user below provides some insight and seems to have a workaround. This user has three Ethernet interfaces, each with their own subnet. Each subnet is also configured with their own default gateway (this isn’t best practice IMHO, but may be the only way using nm-cli). Given multiple default gateways, Routing should pick a default gateway/route with the lowest metric. HA’s Supervisor is apparently picking this same interface by querying the kernel for chosen default route.

So the user’s workaround is to configure the desired interface’s default gateway with the lowest metric (they actually did it a bit differently but same effect).

Selector under Settings>System>Network that sets default adapter

Yes, still an issue with the latest version. This is super annoying. It is good security practice to separate the IoT nodes to separate network(s) from the main home network. Giving possibility to mark the default network shouldn’t be even too hard to implement. Now this feels just silly.

[WallyR (Wally)]

Matter use IPv6 and that is vastly different from IPv4.
Matter will connect to your FE80 network, but all your interfaces will have this network and there is no way of giving Matter an interface ID.

[wmaker (Tommy Long)]

Yeah Matter is going to use all its IPv6 interfaces for most of its operations.
Matter Server does use a “primary interface”. As I understand it, in practice this primary interface should be set to the interface/network that your HA Companion App will be on when commissioning a device.

Here is where the Matter Server AddOn calls the Supervisor API to get the primary interface, and if the Supervisor doesn’t have one, the Matter server falls back to selecting as the primary interface, the interface used by the default IPv4 route.

The Supervisor from what I can tell determines the “primary interface” by calling Dbus (and Dbus is just another interface into Network Manager) to get what Dbus calls the “PrimaryConnection” and from what I can tell this is based on the interface with the default route. There should indeed be a distinction between a default IPv4 route versus a default IPv6 route, but I can’t find anywhere in the path that a “primary interface” is selected based on IPv6 … it seems to be based only on IPv4 default route.

[WallyR (Wally)]

You are still trying to apply IPv4 logic to an IPv6 network.
Default route does not really make sense in IPv6 and especially not in a FE80 network.

[Videonissen]

Why not just inactivate IPv6 on the secondary interface?

[WallyR (Wally)]

It does often not work, because it is only done on the HA container and not on the Matter one, which is the one that matter.

[wmaker (Tommy Long)]

@WallyR

You are still trying to apply IPv4 logic to an IPv6 network.

I’m not saying that it should work that way, but it appears to be that that is the way that primary interface selection was actually implemented.

[WallyR (Wally)]

Yeah for IPv4.
For IPv6 it makes no sense to talk like that.
Some network addresses will exist on multiple interfaces, but they are not the same.
Most interfaces will have several IPv6 addresses and the other devices on the that interface might not have all the same IPv6 addresses, so it is like having multiple network on the an interface.
The selection of which interface to use is automagical chosen from transmission to transmission.