ESP8266mDNS: Replies are not reliably sent on the correct network interface

[ccooper21]

Basic Info

Hardware

Hardware: NodeMCU (ESP-12E)
Core Version: Latest (commit a01638f from Mar 13, 2017)

Description

I spent the day experimenting with the mDNS-SD_Extended example and the related ESP8266mDNS library. I did not have any success getting my ESP to respond to mDNS queries for most the day. In order to investigate, I used both WireShark on my laptop and tcpdump on my router to monitor the relevant network traffic. There just weren't any mDNS/UDP packets getting sent in response to queries from my other devices. Ultimately, I discovered that the responses were getting sent, but through the SOFTAP_IF interface instead of the STATION_IF interface that was connected to my local network. As a workaround, disabling the SOFTAP_IF interface was a step in the right direction, but it was not sufficient. I noticed that in the MDNSResponder::advertiseServices(...) method that all traffic gets sent to the SOFTAP_IF interface. It appears that this is just a simple coding mistake. These problems appear to have been caused as a result of commit a546d64. Aside from the simple coding mistake that I mentioned, unfortunately, I'm not familiar enough with all of the code involved or mDNS to understand exactly what needs to be fixed to get mDNS working reliably with both interfaces enabled as was the intent of the referenced commit.

Settings in IDE

Module: NodeMCU 1.0 (ESP-12E)
Flash Size: 4MB
CPU Frequency: 80Mhz
Flash Mode: Unknown
Flash Frequency: Unknown
Upload Using: Serial over USB
Reset Method: NodeMCU

Sketch

See mDNS-SD_Extended example

Debug Messages

Entering MDNSResponder::queryService(...)...
queryService esp tcp
Sending mDNS query...
Entering send(...)...
Calling udp_sendto(,, 224.0.0.251, 5353)...
Payload:
000000000001000000000000045f657370045f746370056c6f63616c00000c0001
 . . . . . . . . . . . . . _ e s p . _ t c p . l o c a l . . . . .
udp_send
udp_send: added header in given pbuf 0x3fff2994
udp_send: sending datagram of length 41
udp_send: UDP packet length 41
udp_send: UDP checksum 0x2cb0
udp_send: ip_output_if (,,,,IP_PROTO_UDP,)
ip_output_if: ew1
IP header:
+-------------------------------+
| 4 | 5 |  0x00 |        61     | (v, hl, tos, len)
+-------------------------------+
|        8      |000|       0   | (id, flags, offset)
+-------------------------------+
|    1  |   17  |    0x1404     | (ttl, proto, chksum)
+-------------------------------+
|  192  |  168  |    4  |    1  | (src)  <----- This network is not in use.  The correct network is 192.168.16.1/23.
+-------------------------------+
|  224  |    0  |    0  |  251  | (dest)
+-------------------------------+
netif->output()
udp_send: ip_output_if(...) rc = 0x0000
Leaving send(...)
Waiting for answers...

/cc @swarren

[swarren]

I do see the coding error; both line 878 and 883 of a546d64 get the IP from the same interface and hence presumably respond on the same interface. I definitely tested (and often actively use) this code with both interfaces active; I have no idea how that worked for me. Perhaps it's a difference between responding to queries (which is what I would have tested) and pro-actively advertizing services without a query (which I probably didn't test). I'll test out a patch ASAP, but it won't be until after the weekend since I'm booked up. LLMNR might have the same issue; I'll check that too.

[ccooper21]

@swarren Are you using the MDNSResponder::queryService(...) API? The implementation doesn't appear to have any awareness of network interfaces or IP addresses. Apparently it leaves it to the UdpContext object to decide what is best. As best I can tell it just sends a query to one interface. Anecdotally, its behavior seems deterministic, but in my case the wrong interface is always chosen. In any case, wouldn't a query need to get sent from all interfaces?

[swarren]

No, I'm not using queryService() at all. I only updated the "server" side of MDNS to handle multiple interfaces.
In theory, it's as simple as moving most of the body of queryService() into a utility function, and calling it twice just like advertiseServices() does. I'm not sure if I'm going to fix that though...

[swarren]

@ccooper21 try the code in https://github.com/swarren/esp8266-arduino/tree/mdns-query-multi-itf. It compiles, but I haven't flashed it or tested it at all; I don't have any test app/setup for this API...

[ccooper21]

@swarren Thanks for your work on this! I'm sure you made much faster progress than I would have given my lack of familiarity with the protocol and code base. Sorry for the delay in getting back to you. Irrespective of the problems that you fixed, I'm still experiencing some odd things that are getting in the way. For example, if I use Bonjour Browser on Windows or avahi-browse on Linux, I can't see the ESP device on the network unless the Arduino IDE is also running. It seems that the ESP is not sending a PTR record that the browser programs are expecting, but once the Arduino IDE finds the ESP it generates the missing PTR record from its cached MDNS/DNS-SD data. Also, if I use the ZeroConf Browser on Android I can see the ESP, but not the data from its associated TXT and SRV records. I'm not sure at this point if the specification for MDNS/DNS-SD is just too vague resulting in these inconsistencies, or whether the ESP implementation is just incomplete

[ccooper21]

It looks like the ESP8266 MDNS implementation does not properly follow sections 9 and 12 of RFC6763. I have an experimental revision that addresses section 9. It appears to resolve the previously described problems when using Bonjour Browser for Windows and avahi-browse on Linux. I'm going to take a look at what can be done about section 12 now with hopes that it will resolve the remaining problems that I have seen (e.g. with the ZeroConf Browser on Android).

[ccooper21]

@swarren It appears that the ESP8266 MDNS library is properly handling any combination of network interfaces supported by the ESP given your proposed changes. I was able to discover the endpoint for my ESP hosted service from clients attached via either the station or access point interface. Inversely, from the ESP I was able to discover other services on the network via either the station or access point interface. Please proceed with submitting a pull request for your proposed changes, as I have additional fixes that I'd like to submit based on them. Thanks!

[ccooper21]

For the benefit of anyone who reviews this issue later, there are a few loose ends that I encountered outside the scope of this issue, but relevant to testing the solution and getting satisfactory results with the ESP8266 MDNS library. These are:

• When receiving a service type enumeration request, the ESP does not respond in compliance with RFC6763 Section 9. The response should be a DNS PTR record associating the service type enumeration request domain with a service type (e.g. _services._dns-sd._udp.local PTR _arduino._tcp.local). Presently, the ESP responds as if a service instance enumeration request has been received (e.g. _arduino._tcp.local PTR MyService._arduino._tcp.local). I will raise a separate issue for this. (See issue ESP8266mDNS: Improve compliance with DNS-SD RFC6763 #3145)

• When responding to a DNS query (i.e. questions), the response records should be separated into the answers to the questions and additional records not explicitly requested. For more information, see RFC6763 Section 12 and RFC1035 Section 4.1. Presently, the ESP treats all response records as answers. I will raise a separate issue for this. (See issue ESP8266mDNS: Improve compliance with DNS-SD RFC6763 #3145)

• When the ESP8266 is heavily burdened with network traffic, other devices may not be able to find the MDNS services being advertised by the ESP. This is especially noticable when attaching to the ESP's access point interface using a device with a full operating system like Windows or Linux. Such devices throw off a lot of DNS queries and similar, and continue to do so since the queries are not answered by the ESP given that it is not a router and does not provide a path to the Internet. Such network traffic keeps the ESP's network stack tied up and unavailable to handle serviceable MDNS requests.

• When the ESP8266 is heavily burdened with network traffic, the ESP may not be able to find other MDNS services on the network. This is related to the previous point, except that in this case the problems results from the MDNS::queryService(...) method's use of a delay(...) call to wait for query responses. It appears that the delay(...) function can prematurely return as a result of incoming network traffic. In other words, the delay(...) call basically acts as a timeout mechanism. As a result, the execution of the MDNS::queryService(...) method may continue before the responses are received to the query that it sent.

• Wireshark reports that the Ethernet packets sent via the ESP's access point interface are malformed as indicated by an Ethernet frame check sequence error. I have observed this both for packets originating from the ESP and for packets traversing the ESP (e.g. multicast packets from a third device). Issue UDP multicast : ethernet frame check sequence incorrect #1441 appears to cover this problem.