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

On Sep 9, 2025, at 11:38=E2=80=AFAM, Johannes Emerich =
<[email protected]> wrote:
>>> 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.
>>=20
>> 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).
>=20
> Yes, we have confirmed that the continuous online check successfully
> recovers from accidental use of the LLA service as default service.

Excellent; that is great to hear that this works as-intended.

> The issue for us is that ConnMan's online checks make specific, hard =
to
> meet assumptions about the probe host.

I was able to stand up an nginx instance with very little configuration =
that easily and statically satisfies the connman online check header =
requirements. Let me know if you would like me to share that =
configuration.

> 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.)

Agreed that this case sensitivity should be relaxed in connman to comply =
with RFCs. Unfortunately, the change is somewhat involved since it =
involves customizing the g_hash functions used for handling web headers.

That said, I have a client that uses Envoy for the online check endpoint =
(rather than nguni) and there was a setting in Envoy they found they =
could flip that does the right case for that custom header:

% curl --verbose http://<host>/api/v2/status
*   Trying <address>:80...
* TCP_NODELAY set
* Connected to <host> (<address>) port 80 (#0)
> GET /api/v2/status HTTP/1.1
> Host: <host>
> User-Agent: curl/7.68.0
> Accept: */*
>=20
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< cache-control: max-age=3D0, private, must-revalidate
< content-length: 0
< date: Tue, 09 Sep 2025 18:48:10 GMT
< server: envoy
< x-request-id: 07307f81-5144-493d-9c8e-c8d23f1b3174
< x-envoy-upstream-service-time: 1
< X-ConnMan-Status: online
<=20
* Connection #0 to host <host> left intact

> 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.

Again, for both nginx and Envoy, this is a fairly trivial exercise to =
return the desired static content.

> 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).

Agreed. Between the two algorithms (geometric and fibonacci), the min =
and max intervals, and the success and failure thresholds, there are an =
abundance of =E2=80=9Cdials=E2=80=9D to get a behavior that should work =
well for your application.

> 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.

Seems reasonable.

> 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).

Seems like a win-win!

Best,

Grant

--=20
Principal
Nuovations

[email protected]
https://www.nuovations.com/