Re: Demoting IPv4 link-local services in service list sorting
Grant Erickson <[email protected]> Mon, 8 Sep 2025 09:16:48 -0700
| Newsgroups | dev.linux.lists.connman |
|---|---|
| Message-ID | <[email protected]> |
On Sep 3, 2025, at 5:50=E2=80=AFAM, Johannes Emerich = <[email protected]> wrote: >=20 >=20 > I am trying to teach ConnMan to give IPv4 link-local services lower > priority than READY/ONLINE services using another ipconfig method = (e.g. > DHCP). This seems like a useful heuristic, given that link-local > services are not suitable for configuring the default route. At the look, this seems reasonable. Certainly in my =E2=80=9Cclient=E2=80=9D= code above my D-Bus ConnMan client, I have sorting functions that = sub-sort services in the =E2=80=9Cready=E2=80=9D state by other = criteria, including whether or not they are in error (such as = =E2=80=9Conline-check-failure=E2=80=9D). Within connman itself, in service_compare, the online check failures = threshold is used as a comparison predicate. That said, there remains the question, =E2=80=9CThis could be done, but = should it?=E2=80=9D. More on that below. > As far as I can see, two changes would be required: >=20 > 1. Adding a condition to service_compare(), something like this: >=20 > /* Prefer configured IPv4 address over auto/link-local IP. > * > * This just checks for CONNMAN_IPCONFIG_METHOD_AUTO, but other > * checks could be done. > */ > bool a_is_link_local =3D is_ipv4ll(service_a); > bool b_is_link_local =3D is_ipv4ll(service_b); > if (a_connected && !a_is_link_local && b_is_link_local) > return -1; > if (a_is_link_local && b_connected && !b_is_link_local) > return 1; Seems reasonable. That would just need to be adjusted spatially in = service_compare so it is appropriately prioritized relative to other = =E2=80=9Cready=E2=80=9D state predicates. That said, there remains the question, =E2=80=9CThis could be done, but = should it?=E2=80=9D. More on that below. > 2. Triggering re-sorting when IP/ipconfig method of a service changes >=20 > Currently formerly link-local services are not actually promoted when > DHCP becomes active. This is likely because a service that transitions > from IPv4LL to DHCP just remains in READY state, and no re-sorting > occurs. >=20 > To address this, ConnMan would need to trigger re-sorting of the = service > list when a service's ipconfig method or IP address changes. I am > currently looking into triggering sorting from service_ip_bound() or > address_updated() and this works in a basic test by just adding: >=20 > SERVICE_LIST_SORT(); > __connman_gateway_update(); >=20 >=20 > I would be grateful for any feedback on the below: >=20 > - Is there any reason not to demote link-local services in the way I > described? That said, there remains the question, =E2=80=9CThis could be done, but = should it?=E2=80=9D. More on that below. > Context for this change >=20 > Our kiosk system built with ConnMan typically uses two simultaneous > Ethernet connections, one to an input device using a link-local = address, > one to some network providing Internet access. In most cases ConnMan > reliably uses the Internet-bound network as the default service, but = if > the network is slow to respond to DHCP requests for some reason, both > Ethernet services end up with link-local addresses initially. In this > case, ConnMan may choose the local-only connection as default service > and stick with that choice even when the other service receives a good > IP and gateway via DHCP later. The either one-shot or continuous online reachability check should = handle this case. The check will always fail for your LLA interface and = it will stay in =E2=80=9Cready". When reachability is there, the other = interface will transition from =E2=80=9Cready=E2=80=9D to =E2=80=9Conline=E2= =80=9D when the reachability check succeeds and the priority issue = should be resolved. > Continuous online checks are not currently a good fit for us and = should not be required as it is known a > priori that link-local services are not useful as default services. Why is this the case? The mechanism is doing exactly what it should be = doing which is to answer the question, dynamically, =E2=80=9CCan this = network interface and the network service associated with it reach the = Internet?=E2=80=9D. If the answer is =E2=80=9Cno=E2=80=9D, it stays in = =E2=80=9Cready=E2=80=9D. If the answer is =E2=80=9Cyes=E2=80=9D, it gets = promoted to =E2=80=9Conline=E2=80=9D (subject to other configuration and = conditions). Best, Grant --=20 Principal Nuovations [email protected] https://www.nuovations.com/