Package: connman
Version: 1.41-3
* My use case:
I run a virtual machine with virt-manager (KVM/QEMU). Each time the
virtual machine is switched on, virt-manager creates a virtual ethernet
interface vnetN with a different number and MAC address on the host and
attaches it to the bridge virbr0. As a bridge member, vnetN is not
supposed to receive any IP configuration.
Connman was installed on the host with LXDE and manages the physical
ethernet and wireless interfaces with IPv4 and IPv6 automatic configuration.
* Problem description:
By default, connman manages vnetN with automatic methods and, after
failing to use DHCP, assigns it a link-local IPv4 address (APIPA
169.254.0.0/16) and a direct default IPv4 route with default metric (the
highest priority). This default route conflicts with the existing IPv4
default route associated with the physical network interface and breaks
the host IPv4 connectivity outside the LAN.
syslog:
2024-02-27T14:40:24.211054+01:00 chantecler connmand[14215]: vnet0 {add}
address 169.254.248.201/16 label vnet0 family 2
2024-02-27T14:40:24.211505+01:00 chantecler connmand[14215]: vnet0 {add} route
169.254.0.0 gw 0.0.0.0 scope 253 <LINK>
2024-02-27T14:40:24.211727+01:00 chantecler connmand[14215]: vnet0 {add} route
0.0.0.0 gw 0.0.0.0 scope 253 <LINK>
2024-02-27T14:40:24.211943+01:00 chantecler connmand[14215]: vnet0 {add} route
0.0.0.0 gw 0.0.0.0 scope 253 <LINK>
ip addr:
2: enp0s25: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP group default qlen 1000
inet 192.168.0.252/24 brd 192.168.0.255 scope global enp0s25
4: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
group default qlen 1000
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
8: vnet0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc noqueue
master virbr0 state UNKNOWN group default qlen 1000
inet 169.254.248.201/16 brd 169.254.255.255 scope global vnet0
ip route:
0.0.0.0 dev vnet0 scope link
default dev vnet0 scope link
default via 192.168.0.1 dev enp0s25
169.254.0.0/16 dev vnet0 proto kernel scope link src 169.254.248.201
192.168.0.0/24 dev enp0s25 proto kernel scope link src 192.168.0.252
192.168.0.1 dev enp0s25 scope link
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
* Workaround:
Add "vnet" to NetworkInterfaceBlacklist in /etc/connman/main.conf.
* Comments/questions:
1) Isn't it desirable to ignore "vnet" interfaces in the default
configuration ? Or is there a use case where connman should manage vnet
interfaces ?
2) What is the use case for creating a direct default IPv4 route when
DHCP failed and an APIPA address was assigned, specially when another
default route already exists ? Communicating with other hosts in the
APIPA subnet on the same LAN does not require it. It may allow to send
packets to other hosts in non-APIPA subnets on the same LAN, but usually
they do not have a direct route to the APIPA subnet and are unable to reply.
3) If such use case exists, shouldn't this default route have a low
priority (high metric) so that other default routes take precedence ?
