Re: Demoting IPv4 link-local services in service list sorting

Hi Grant,

thanks for sharing your insights!

On Mon, 8 Sept 2025 at 18:17, Grant Erickson <[email protected]> wro=
te:

> That said, there remains the question, =E2=80=9CThis could be done, but s=
hould it?=E2=80=9D.

This is a good question. We understand that service_compare() is already
complicated and can only factor in a limited number of criteria, so
added criteria really do need to provide value.

We initially aimed to do just what you hint at, patching up ConnMan's
sorting by applying application-level rules via D-Bus. But we then
started to wonder whether these should really be application-level
concerns.

> > As far as I can see, two changes would be required:
> > 1. Adding a condition to service_compare(), something like this:
>
> Seems reasonable. That would just need to be adjusted spatially in servic=
e_compare so it is appropriately prioritized relative to other =E2=80=9Crea=
dy=E2=80=9D state predicates.

Yes. I have placed it after the `state_a !=3D state_b` block, the
online-check-failure and preferred technologies criteria (among others)
would be applied earlier. The limitation to READY services could also be
made more explicit, in case code is moved around later.

> > 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 s=
tay in =E2=80=9Cready". When reachability is there, the other interface wil=
l 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.

According to my understanding one-shot mode does not handle this case
(though we initially thought it would). The check will fail for the LLA
service and it will stay in READY. But this does not cause the service
to be demoted in one-shot mode and so it may remain default service. The
other, good service never gets the chance to run an online check and
"prove" itself to be ONLINE. (As mentioned in original email, the
service remains in READY as it transitions bottom-up from AUTO to DHCP
mode, so there is no state change.)

We ran practical tests to confirm that in the described scenario the LLA
service remains default service even with one-shot online checking
enabled.

This means that in the current default configuration, ConnMan is less
robust in operating dual Ethernet than it could be, and may get stuck in
what is very obviously a dead-end. We observed that no default route is
even installed when ConnMan chooses an LLA service as default.

> > 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 do=
ing 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=9Cread=
y=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).

Yes, we have confirmed that the continuous online check successfully
recovers from accidental use of the LLA service as default service.

The issue for us is that ConnMan's online checks make specific, hard to
meet assumptions about the probe host. Our systems frequently run in
networks with firewall restrictions, and each additional host to
whitelist is a possible source of failure and friction. We could
configure ConnMan to use an HTTPS check URL on our application host, but
the online check does a case-sensitive string comparison when checking
for the marker header X-ConnMan-Status. (As far as we understand RFC
9112, it should be case insensitive.) This means we would need to
decorate an application server with a ConnMan specific response, and
also have to ensure that our servers preserve the capitalization of the
header field that ConnMan checks for.

Also, if we were to use the online check to demote LLA services, we
would need to balance quick detection of this scenario with low chance
of false positives on regular network services (tuning timing and
failure threshold parameters).

If we compare this with the heuristic to demote link-local services, it
seems generally applicable, leads to immediate resolution without risk
of false positives and does not require us to configure our server
infrastructure in specific ways.

So the heuristic seems to make dual Ethernet (and other) scenarios more
robust out of the box, while being compatible with all online check
modes (none/one-shot/continuous).

Thanks and best regards,
Johannes