[lwip-devel] [bug #58142] mDNS: RFC violation after recent changes - affecting probing

[Jasper Verschueren]

URL:
  <https://savannah.nongnu.org/bugs/?58142>

                 Summary: mDNS: RFC violation after recent changes - affecting
probing
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: jasperv
            Submitted on: Wed 08 Apr 2020 12:54:11 PM CEST
                Category: apps
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: git head

    _______________________________________________________

Details:

Commit introducing wrong behavior:

e85e4738
mdns: remove service TXT record from probe packets
   TXT records isn't required to be unique in network, so it shouldn't be
included in probe packets.
   Additionnaly, when TXT record is present, the Bonjour Conformance Test from
Apple Inc. always fail because generated probe nevert have TXT record.

change done:

-      outmsg->serv_replies[i] = REPLY_SERVICE_SRV | REPLY_SERVICE_TXT;
+      outmsg->serv_replies[i] = REPLY_SERVICE_SRV;


This breaks the Simultaneous Probe Tiebreaking feature in mDNS.
RFC6762 section 8.2 states:
   When a host is probing for a group of related records with the same
   name (e.g., the SRV and TXT record describing a DNS-SD service), only
   a single question need be placed in the Question Section, since query
   type "ANY" (255) is used, which will elicit answers for all records
   with that name.  However, for tiebreaking to work correctly in all
   cases, the Authority Section must contain *all* the records and
   proposed rdata being probed for uniqueness.

If we receive an ANY question for a service we reply with the SRV and TXT
record in the answer section.
We add the A record in the additional section. This also after the above
change.
If we do it at that point, we should also do it in the probe.

I compared this to the behavior of a "well-known" implementation -
avahi-daemon.
On my network I have a device called 'device1' that has an http service using
a version of lwIP prior to the above commit.
If I use avahi-daemon to also host that same service I can see the probes and
the response of my unit.

$ avahi-publish-service device1 _http._tcp 80 []

Avahi sends out this query:
  Multicast Domain Name System (query)
    Transaction ID: 0x0000
    Flags: 0x0000 Standard query
    Questions: 1
    Answer RRs: 0
    Authority RRs: 2
    Additional RRs: 0
    Queries
        device1._http._tcp.local: type ANY, class IN, "QM" question
    Authoritative nameservers
        device1._http._tcp.local: type SRV, class IN, priority 0, weight 0,
port 80, target jasper.local
        device1._http._tcp.local: type TXT, class IN
    [Response In: 19]

Including TXT and SRV.

The response of my device:
  Multicast Domain Name System (response)
    Transaction ID: 0x0000
    Flags: 0x8400 Standard query response, No error
    Questions: 0
    Answer RRs: 2
    Authority RRs: 0
    Additional RRs: 1
    Answers
        device1._http._tcp.local: type SRV, class IN, cache flush, priority 0,
weight 0, port 80, target device1.local
        device1._http._tcp.local: type TXT, class IN, cache flush
    Additional records
        device1.local: type A, class IN, cache flush, addr 192.168.0.121
    [Unsolicited: True]

You can see above the my PC doesn't have the correct hostname compared to the
service name (jasper != device1).
This isn't possible as it would introduce hostname conflicts and be resolved
there already.
But that doesn't matter to prove my point.

So I request to revert this commit.
We should however check why Bonjour Conformance Test by Apple have an issue
with this.
Maybe something else is wrong?
How are the Bonjour Conformance Tests executed? 




    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?58142>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/