Unprivileged Incus adds its own interface default route on void-linux?

[namgo]

Required information

• Distribution: Void Linux
• Distribution version: latest
• The output of "incus info" or if that fails:

config: {}
api_extensions:
(removed to keep it shorter, should I re-add?)
api_status: stable
api_version: "1.0"
auth: trusted
public: false
auth_methods:
- tls
auth_user_name: 4efdd5bbef40a2bc2475f4acb4d874a365d2340d461b1d781d2ae6a88744e059
auth_user_method: tls
environment:
  addresses: []
  architectures:
  - x86_64
  - i686
  driver: lxc
  driver_version: 5.0.1
  firewall: xtables
  kernel: Linux
  kernel_architecture: x86_64
  kernel_features:
    idmapped_mounts: "true"
    netnsid_getifaddrs: "true"
    seccomp_listener: "true"
    seccomp_listener_continue: "true"
    uevent_injection: "true"
    unpriv_binfmt: "false"
    unpriv_fscaps: "true"
  kernel_version: 6.6.35_1
  lxc_features:
    cgroup2: "true"
    core_scheduling: "true"
    devpts_fd: "true"
    idmapped_mounts_v2: "true"
    mount_injection_file: "true"
    network_gateway_device_route: "true"
    network_ipvlan: "true"
    network_l2proxy: "true"
    network_phys_macvlan_mtu: "true"
    network_veth_router: "true"
    pidfd: "true"
    seccomp_allow_deny_syntax: "true"
    seccomp_notify: "true"
    seccomp_proxy_send_notify_fd: "true"
  os_name: Void
  os_version: ""
  project: user-1000
  server: incus
  server_clustered: false
  server_event_mode: full-mesh
  server_name: laptop
  server_pid: 10069
  server_version: "6.2"
  storage: btrfs
  storage_version: 6.5.1
  storage_supported_drivers:
  - name: lvm
    version: 2.03.23(2) (2023-11-21) / 1.02.197 (2023-11-21) / 4.48.0
    remote: false
  - name: lvmcluster
    version: 2.03.23(2) (2023-11-21) / 1.02.197 (2023-11-21) / 4.48.0
    remote: true
  - name: btrfs
    version: 6.5.1
    remote: false
  - name: dir
    version: "1"
    remote: false

Issue description

On a fresh void-linux system I've installed incus with incus-user enabled (adding my user to _incus).

Incus (or dnsmasq?) adds the unprivileged user's interface as a default route upon service start.

Steps to reproduce

(having created one container under my unprivileged user, which is an _incus group member)

1. sudo sv restart incus incus-client
2. ip route

default via 10.171.84.1 dev veth65a9dc71 proto dhcp src 10.171.84.154 metric 1006 
default via 10.171.84.1 dev vethd5388c52 proto dhcp src 10.171.84.154 metric 1008 
default via 192.168.1.1 dev wlp3s0 proto dhcp src 192.168.1.248 metric 3003 

where 10.171.84.1 belongs to incusbr-1000 interface.

Information to attach

• Any relevant kernel output (dmesg)
• Container log (incus info NAME --show-log)
• Container configuration (incus config show NAME --expanded)
• Main daemon log (at /var/log/incus/incusd.log)
• Output of the client with --debug
• Output of the daemon with --debug (alternatively output of incus monitor --pretty while reproducing the issue)

I looked through the above and couldn't see anything clearly relevant to adding routes, but please let me know if there's anything I can add!

[namgo]

I may have submitted this issue too early. I rebooted once more and now everything works as expected, I'm unable to reproduce.

Is this a known problem? I'm happy to close the issue if there's nothing I can do to debug it.

[stgraber]

Are you using connman? We've had a user report that connman was basically pointing a default route at any new interface.

[stgraber]

Normally network management tools should be smart enough to detect that an interface is part of a bridge (has the master field set) and not try to treat it as a physical network interface.

[namgo]

I'm not using any network management tools besides wpa_supplicant and dhcpcd as dhcp client. I'll close this as it's not reproducible again. Sorry for any confusion.