lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jasper Verschueren
Subject: [lwip-devel] [bug #58142] mDNS: RFC violation after recent changes - affecting probing
Date: Tue, 12 May 2020 06:25:40 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36

Follow-up Comment #3, bug #58142 (project lwip):

Hi David,

I think that this topic is a big discussion point between implementers.
I have checked a few different implementations and see that this is not
consistent.
Some include TXT record in the authority section and some don't.
This to me is a big issue since tie-breaking will not work between these
different implementations.
So there is some work to do before mDNS can be really stable.
Which contradicts the complete point of zero configuration. 

I must say that some parts of the RFC are sensitive to interpretation. 
This part is definitely one of them.

You suggest we fix this in another place but keep the txt record in the
probe.
This I think isn't a good idea since the tie-breaking is looking for *all*
answers which includes txt records.
If we do not take into account txt records for tie-breaking but include it in
the authority section we might confuse the other host.
This is also an implementation that is not described in the RFC.

So for me the question is simple: do we include TXT or not in the probe
authority section.
Or in other words is your patch good or not.

I have taken the devices I have at home and evaluated what they include in the
probe message:
* Google Chromecast Ultra - includes the TXT record in the authority section
* Apple TV 1e gen - does not include TXT record
* Apple TV 2e gen - does not include TXT record
* Brother printer - does not include TXT record
* Avahi-Deamon - includes TXT record
* Honeywell Lyric thermostat - does not include TXT record

Since Apple is probably the most trust worthy implementation, I agree we
should follow them.
Strange that a big company as Google does it differently.
They might still be annoyed they didn't develop it :).

So I think this bug report might be incorrect.
Please give me a little more time to discuss this with others before rejecting
this bug. 

Kind regards,
Jasper

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]