[avahi] PTR query responses

[Markus Rathgeb]

2012/3/12 Christiano F. Haesbaert <haesbaert at haesbaert.org>:
> On 12 March 2012 14:28, Markus Rathgeb <maggu2810 at googlemail.com> wrote:
>> 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)
>> calls
>> [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)
>> calls
>> [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) {
>>
>> For class AVAHI_DNS_CLASS_IN and type AVAHI_DNS_TYPE_PTR
>> the "existing" AVAHI_DNS_TYPE_SRV and AVAHI_DNS_TYPE_SRV entries for
>> the name should be added.
>>
>> For class AVAHI_DNS_CLASS_IN and type AVAHI_DNS_TYPE_SRV
>> 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.
>>
>
> Because the PTR response is what takes part in the enumeration phase,
> when you get the SRV/TXT/A records, you actually resolving the
> services.
>
> In a normal cenario, you don't want every SRV/TXT/A (you don't want to
> resolve them all), you want to enumerate all possible services, and
> you (the user) picks one, you resolve it (ask for the SRV/TXT/A).
>
> It's been over a year since I implemented mdns/dns-sd and my mind is a bit fusy.
>
>> 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?

I understand the point of view, first get the PTR response, and then
resolve what you want to use.
But it does not explain, why the same avahi versions and the same
configurations does act differently (and normally more than a PTR
record is send).