[avahi] BUG/BYDESIGN avahi_entry_group_add_service

[Lennart Poettering]

On Tue, 13.05.08 17:13, Stefan de Konink (avahi at ml.kinkrsoftware.nl) wrote:

Hey!

There's something wrong with the quoting of your mail user agent.

>  >> It is strange:
>  >>
>  >> 1) Avahi doesn't allow an IP address as host
>  >
>  > It's not a limitation of Avahi. It is a limitation of DNS-SD. DNS-SD
>  > service definitions contain references to host names, not to IP
>  > addresses. Registration of IP adresses is done by Avahi itself and
>  > anyway, regardless if any services are registered or not, and
>  > regardless on which interfaces a service is registered.
> 
> Ok, strange situation. But let me elaborate.

It's not strange. Not at all ;-)

>  >> 2) Ignores the host completely, and if the host is correct it will 
> still export *all* (public/private) IPs. (like it was NULL)
>  >
>  > Avahi registers A/AAAA records for all relevant interfaces automatically.
> 
> But this is not what the user specified! The user specified the service 
> is active for a specific hostname. This hostname resolves to an IP 
> address. Why does avahi broadcast it to all interfaces pretending that 
> the service is connected to NULL/::/0.0.0.0?

Avahi registers the local host name on all local interfaces with the
appropriate IP adress. i.e. on a multi-homed hosts with 10.0.0.1
(eth0) and 192.168.1.1 (eth1) as addresses and name "foobar" it will
register one A record "foobar.local" referring to 10.0.0.1 on eth0,
and on eth1 it will register "foobar.local" as well, but this time
referring to 192.168.1.1.

If you pass AVAHI_IF_UNSPEC as interface when registering a service
the service is registered on each interface, always pointing to the
same host name, which in turn however (as described above) might point
to a different IP address on each interface.

If you want to register a service on a single interface only, then
just pass an explicit interface index when registering the service.

If you pass a host name in the 'host' parameter when registering a
service this has only influence about what host name is stored inside
the DNS-SD data where the service actually is. It has no influence
where the service data is published. This is, again, what the
interface index is for. 

> Shouldn't the hostname not be exported? Like you said in the reply on my 
> first question?

Host name registration is completely independant from service
registration. Hostnames will always be registered, to make things like
nss-mdns work. Host names are automatically registered when Avahi
starts up. 

> Anyway the it is not like a 'big' deal for me, because we can limit the 
> interfaces now. But I consider this behavior plain incorrect. If a 
> service doesn't run on 0.0.0.0 it should not be dumped on the network as 
> such.

The current behaviour makes complete sense. I think this is mostly a
misunderstanding: to limit a service to a specific interface use the
interface index argument (as mentioned), that's what it is intended
for. The host name string does not refer to the interface where to
register the service but only to the host name where *you* made the
service available on. Unless the service you are registering is not
local it makes no sense to pass anything but NULL here.

In its API Avahi identifies network interfaces only by their numeric
index. Using IP addresses or host names for identifying interfaces is
not useful, because you can assign a host name to multiple IP adresses
and an IP address to multiple local interfaces. And interface names
can change at any time and are not unique during system runtime. Only
iface indexes are both stable and unique during system runtime.

If you want to map an interface index to a name and vice versa use
BSD/POSIX if_indextoname() and if_nametoindex(). If you want to map an IP
address to an interface index you should use rtnetlink(7) or use
SIOCGIFCONF and parse /proc/net/if_inet6.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4