-
Notifications
You must be signed in to change notification settings - Fork 13.3k
mDNS library fails to find non-ESP DNS-SD services on the network #2151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
/сс @larsenglund |
Followup: this library can find the above mentioned services on my network (using the ESP), although it is pretty raw: https://github.com/mrdunk/esp8266_mdns |
The library does indeed only support "ideal" responses with one of each of the four response types in the packet. That was all I needed at the moment so I didn't implement handling of more complex or segmented answers. |
Sift through the two RFCs linked in the code to get a better understanding of the packets that get sent around when making requests. Also sniffing a request and answer with something like Wireshark is usefull if one would like to add support for parsing more types of responses. |
What I found was that 4 responses were needed ( PTR,TXT,SRV,A ) before an answer was created. If can craft your replies to have this then it works, if not you need to modify the code. ESP8266mDNS.cpp //around 480
if (numAnswers < 3 || numAnswers > 4 ) {
//around line 509
int answerCount = numAnswers;
//around line 621
if ( (
(partsCollected == 0x0F && answerCount == 4) ||
(partsCollected == 0x0D && answerCount == 3)
)
&& serviceMatch) {
Hope that helps |
Can you guys test this PR?
|
@lorneb how is your TXT optional? Your device should return TXT even if empty |
@me-no-dev I was mucking around with MDNS, when testing I was not sending a TXT record. I should have read the RFC first as you are correct a TXT record is NOT optional. I'm sending TXT records now :-) |
Hi, what's the status of this? Is the issue resolved? was a PR made and/or merged? |
@brendanmatkin is this issue still valid with latest git? |
The referenced PR was merged. |
Basic Infos
Mac OS 10.11.5
Hardware
Hardware: ESP-12E
Core Version: 2.2.0
Description
mDNS library fails to find DNS-SD services on the network, other than those which it creates. If I load this sketch onto several ESP modules, they all find each other's advertised service. I've picked through the library and am not quite sure what's going on - it seems to me like the library might be creating & looking for non-standard DNS-SD service records, but I have been unable to find out how.
I uncommented the debugs in the mDNS library for the debug output below, as well as enabling Debug level "ALL" in the Arduino IDE. The sketch I'm loading is just the example sketch with MDNS.queryService() looking for various services. The one included below (ipp) is a printer sharing advertisement.
Bonjour Browser shows 4 different services (all of which show "can't resolve link-local name", but do show titles, ip+port v4 & v6, and text records):
Although finding a printer or whatever is trivial, I would love to use this to find a computer on the network (with a dynamic IP) running an OTA server. The library is obviously finding SOMETHING, I think it's either just throwing errors when it shouldn't, or looking for the wrong service record structure or something...
Settings in IDE
Module: Generic ESP8266 Module
Flash Size: 4MB
CPU Frequency: 160Mhz & 80Mhz (same behavior with both)
Flash Mode: qio
Flash Frequency: 40Mhz & 80Mhz
Upload Using: SERIAL
Reset Method: ck
Sketch
Debug Messages
I've seen a few different patterns (I think the first one is more accurate, the second or something similar seems to happen if I switch networks after the sketch has started). Also not sure why it keeps showing airport, the router used for the below output is an older D-Link (although I've had the same result with at least 3 different routers).
These tests are all done with a single active ESP8266 module.
Second Style:
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: