Hello Szabi,
> because the clients don't have an address in the same range as the
other addresses
If it's IPv6 addresses, this should not matter: any valid addresses
assigned to the interface will be seen as "on link" in IPv6 terms. That
means the client can communicate with any valid "on link" IPv6 address
it has with the server. Even if the address is of another type, or from
another range (prefix).
If it's IPv4: do you mean a different IPv4 subnet? In such case I would
assume the server's mDNS multicasts would be ignored by the clients
because the IPv4 source address is from another subnet. Maybe I'm wrong
here.
Or is there another failure case possible here? I'm thinking maybe if
the service process, on the mDNS server host, only binds to one specific
IP address and not to "all IP addresses".
This is at least something that RFC 6762 did not really consider. It
requires/assumes that an advertised service is available on all the
valid addresses of the interface.
Yet another failure case is when an IPv6/IPv4 address is assigned to an
interface, possibly manually or by a script, where there's no proper
router configuration to support that address. So effectively it's
assigning an invalid address to an interface. RFC 6762 says "MUST NOT
include addresses that are not valid on that interface". But when an
invalid address is explicitly configured in the OS, Avahi doesn't really
know of course that it's invalid, so having a function to filter out /
block such invalid addresses would make sense and also complies to the
standard. But it's easier to just not configure such addresses!
For me not fully clear yet if any of these cases apply to the issue you
have.
> Setting aside the fact that the behaviour specified by the
> standard is asking for trouble, do you have an actual solution to this?
I think the standard was specified this way precisely to avoid the same
trouble. If only one address is included, it could be just the wrong one
that the client can't reach. If all addresses are included, the client
can either pick the matching one or try all the addresses until one works.
But I see the issue: if a client has the logic of "pick first one" it
just won't work. I was recently involved in work where
specification-wise the client would need to iterate all discovered host
addresses in preferred order (e.g. trying the 'most likely to remain
stable' addresses first) until one "worked".
However in the practical client implementation that was just skipped and
only the IPv6 link-local address was picked. It's some more work to get
the 'try all addresses' right. I could ask in the IETF dnssd WG for some
clarification.
best regards
Esko
On 6-10-2025 16:13, Szabolcs Szekelyi wrote:
Hi,
I have the same situation as described in this issue:
https://github.com/avahi/avahi/issues/269
Ie. my server have multiple addresses on a single interface, and avahi
publishes all of them. Only one of these addresses is the one where my host is
accessible to clients, because the clients don't have an address in the same
range as the other addresses. But if resolving my server's hostname yields the
wrong IP address on the client (by just pinging myserver.local for example),
it won't be able to communicate with the server and it ends up with an
advertised service that's actually inaccessible.
I understand that this behaviour is specified by RFC6762 as described in the
issue above. Setting aside the fact that the behaviour specified by the
standard is asking for trouble, do you have an actual solution to this?
Do you think a configuration option that allows avahi to ignore addresses in
specific ranges could be a viable solution?
Any other tips or tricks?
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339
