[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [bug #58142] mDNS: RFC violation after recent changes - aff
[lwip-devel] [bug #58142] mDNS: RFC violation after recent changes - affecting probing
Wed, 8 Apr 2020 06:54:13 -0400 (EDT)
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36
Summary: mDNS: RFC violation after recent changes - affecting
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: jasperv
Submitted on: Wed 08 Apr 2020 12:54:11 PM CEST
Severity: 3 - Normal
Item Group: Faulty Behaviour
Assigned to: None
Discussion Lock: Any
Planned Release: None
lwIP version: git head
Commit introducing wrong behavior:
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.
- 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
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 -
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
Answer RRs: 0
Authority RRs: 2
Additional RRs: 0
device1._http._tcp.local: type ANY, class IN, "QM" question
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
Answer RRs: 2
Authority RRs: 0
Additional RRs: 1
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
device1.local: type A, class IN, cache flush, addr 192.168.0.121
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
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
Maybe something else is wrong?
How are the Bonjour Conformance Tests executed?
Reply to this item at:
Message sent via Savannah
- [lwip-devel] [bug #58142] mDNS: RFC violation after recent changes - affecting probing,
Jasper Verschueren <=