Legacy unicast responses can't span multiple packets

[rlbartle]

At the moment legacy unicast responses do not get split over several smaller ones when the response is going to be larger than 512 bytes, resulting in many of the services being omitted from unicast responses.

Here is one of the many entries in the syslog when avahi is responding to a service query and there are several matches to the query:

Oct 16 12:47:22 axpi avahi-daemon[405]: Record [Local\0321._XYZ-SERVICE._tcp.local#011IN#011SRV 0 0 7400 axpi.local ; ttl=120] not fitting in legacy unicast packet, dropping.

These log messages are added for each service matching the query which cannot fit in the 512 byte packet.

The relevant code is at avahi-core/server.c -> avahi_server_generate_response

if (legacy_unicast) {
    AvahiDnsPacket *reply;
    AvahiRecord *r;

    if (!(reply = avahi_dns_packet_new_reply(p, 512 + AVAHI_DNS_PACKET_EXTRA_SIZE /* unicast DNS maximum packet size is 512 */ , 1, 1)))
        return; /* OOM */

    while ((r = avahi_record_list_next(s->record_list, NULL, NULL, NULL))) {

        append_aux_records_to_list(s, i, r, 0);

        if (avahi_dns_packet_append_record(reply, r, 0, 10))
            avahi_dns_packet_inc_field(reply, AVAHI_DNS_FIELD_ANCOUNT);
        else {
            char *t = avahi_record_to_string(r);
            avahi_log_warn("Record [%s] not fitting in legacy unicast packet, dropping.", t);
            avahi_free(t);
        }

        avahi_record_unref(r);
    }

    if (avahi_dns_packet_get_field(reply, AVAHI_DNS_FIELD_ANCOUNT) != 0)
        avahi_interface_send_packet_unicast(i, reply, a, port);

    avahi_dns_packet_free(reply);

}

*edited since researching the topic some more

I'm not sure what consequences something like this would cause : rlbartle@f4b7859

[rtollert]

This message is the vast majority of syslog traffic on at least some embedded systems running avahi; is there anything that can be done to help move a fix along?

[fuzzy01]

Any update on this?

[terrafying]

I tried different configs till it stopped erroring - this seems to be what did it -

publish-addresses=yes
publish-hinfo=no
publish-workstation=no
publish-domain=no
publish-resolv-conf-dns-servers=no
publish-aaaa-on-ipv4=no
publish-a-on-ipv6=no

[pemensik]

As I understand the RFC at https://www.rfc-editor.org/rfc/rfc6762#section-6.7, I would say EDNS0 should be used for receiving larger response for legacy queries. If even that cannot work, TC bit should be set and retried over TCP.

And here we have a problem, because avahi-daemon does not even listen on TCP. But that is how unicast DNS response should be handled. So it seems to me it should.

[evverx]

TCP is mentioned in https://www.rfc-editor.org/rfc/rfc6762#section-18.5

In legacy unicast response messages, the TC bit has the same meaning
as in conventional Unicast DNS: it means that the response was too
large to fit in a single packet, so the querier SHOULD reissue its
query using TCP in order to receive the larger response.