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/