[avahi] PTR query responses

Markus Rathgeb maggu2810 at googlemail.com
Mon Mar 12 10:28:57 PDT 2012

2012/3/12 Markus Rathgeb <maggu2810 at googlemail.com>:
> 2012/3/12 Christiano F. Haesbaert <haesbaert at haesbaert.org>:
>> On 12 March 2012 13:08, Markus Rathgeb <maggu2810 at googlemail.com> wrote:
>>> Hello!
>>> I have here multiple machines with the same setup.
>>> Normally if a multicast question for a PTR "_srv._proto.local" is
>>> made, the machines reply with a multicast response containing four
>>> records, the types PTR, TXT, SRV, A.
>>> This morning I see (wireshark) a machine that reply contains only the
>>> PTR record -- missing the TXT, SRV and A type.
>>> If a multicast question for the A record of the machine's name is
>>> requested, the machine answered with a multicast respone given the A
>>> record.
>>> After a restart of the avahi daemon of this machine, the machine's
>>> reply to the PTR question contains all four records (PTR, TXT, SRV, A)
>>> again.
>>> What's going on?
>>> Could someone explain me, how I could run in that situation and
>>> whether it is correct or not (why)?
>>> Thanks in advance,
>>> Markus
>> There is a feature called something like "Known Answer Suppression",
>> the querierer includes the known answers in the query packet, under
>> the AN section, so the the one getting queried won't include the known
>> answers in the reply.
>> Not sure if I made myself clear, try using avahi-browse, if the
>> service ain't there, it's wrong.
>> _______________________________________________
>> avahi mailing list
>> avahi at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/avahi
> Thank you for the reply.
> avahi-browse shows the service.
> avahi-resolve-hostname could resolve the A record.
> The windows command line tool dns-sd seems also to be working (-B and
> -G v4 hostname).
> I got the error with some tools written by colleagues.
> So I do not say it is an error of avahi (it could be an error in the
> implementation of the tools).
> The mutlicast PTR question for the special service is done to get a
> list of all machines that are offering that service (no "known answer"
> included).
> So it is possible to request the A record for every machine that sends
> an answer and no A record in the answer was included.
> The question is: Why are always the four record types in the answer
> and now one machine replies with only one record type in the answer (I
> never seen this before and after restart of avahi I see four record
> types again for this machine)?
> The restart of avahi was done after about four hours.

I have had a look at the sending a response packet logic:

[reponse-sched.c] static void
send_response_packet(AvahiResponseScheduler *s, AvahiResponseJob *rj)
[reponse-sched.c] static int
packet_add_response_job(AvahiResponseScheduler *s, AvahiDnsPacket *p,
AvahiResponseJob *rj)

[reponse-sched.c] static int
packet_add_response_job(AvahiResponseScheduler *s, AvahiDnsPacket *p,
AvahiResponseJob *rj)
[server.c] void avahi_server_enumerate_aux_records(AvahiServer *s,
AvahiInterface *i, AvahiRecord *r, void (*callback)(AvahiServer *s,
AvahiRecord *r, int flush_cache, void* userdata), void* userdata) {

the "existing" AVAHI_DNS_TYPE_SRV and AVAHI_DNS_TYPE_SRV entries for
the name should be added.

the "existing" AVAHI_DNS_TYPE_A and AVAHI_DNS_TYPE_AAAA entries for
the name should be added


So, why could a PTR response packet be sent without the SRV, TXT and A
entries and after a retry the entries are added.
No service files or avahi configuration files are changed on the machine.

The function
[server.c] static void enum_aux_records(AvahiServer *s, AvahiInterface
*i, const char *name, uint16_t type, void (*callback)(AvahiServer *s,
AvahiRecord *r, int flush_cache, void* userdata), void* userdata)
iterate in the else branch over the entries in a hash map.
Could there be an error if that hash map is filled?

More information about the avahi mailing list