esp-idf: [TW#26643] mdns_query_a method is not working

Environment

Development Kit: [ESP32-DevKitC]
Kit version (for WroverKit/PicoKit/DevKitC): [v2]
Core (if using chip or module): [ESP-WROOM32]
IDF version (git rev-parse --short HEAD to get the commit id.): 11b444b
Development Env: [Make]
Operating System: [Ubuntu]
Power Supply: [USB]

Problem Description

mdns_query_a method returns ESP_ERR_NOT_FOUND when the host is present. ESP-IDF example for mdns also doesn’t print the IP corresponding to its own service. All other methods e.g mdns_query_ptr, mdns_query_txt, etc are working as expected. //Detailed problem description goes here.

Expected Behavior

mdns_query_a should resolve the address correctly.

Steps to repropduce

Run mdns esp-idf example. Make sure hostname specified in sdkconfig matches to that “mdns_query_host” function call in the example.
Run the example to see that it doesn’t print the IP.

I (520) phy: phy_version: 4000, b6198fa, Sep  3 2018, 15:11:06, 0, 2
I (540) wifi: mode : sta (24:0a:c4:11:b3:e8)
I (540) gpio: GPIO[0]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 
I (1270) wifi: n:6 1, o:1 0, ap:255 255, sta:6 1, prof:1
I (2250) wifi: state: init -> auth (b0)
I (2260) wifi: state: auth -> assoc (0)
I (2260) wifi: state: assoc -> run (10)
I (2460) wifi: connected with Router, channel 6
I (2460) wifi: pm start, type: 1

I (5770) event: sta ip: 192.168.2.42, mask: 255.255.255.0, gw: 192.168.2.1
I (67320) mdns-test: Query A: esp32.local
W (69360) mdns-test: ESP_ERR_NOT_FOUND: Host was not found!
I (69360) mdns-test: Query PTR: _arduino._tcp.local
W (72460) mdns-test: No results found!
I (72460) mdns-test: Query PTR: _http._tcp.local
W (75560) mdns-test: No results found!
I (75560) mdns-test: Query PTR: _printer._tcp.local
W (78660) mdns-test: No results found!
I (78660) mdns-test: Query PTR: _ipp._tcp.local
W (81760) mdns-test: No results found!
I (81760) mdns-test: Query PTR: _afpovertcp._tcp.local
W (84860) mdns-test: No results found!
I (84860) mdns-test: Query PTR: _smb._tcp.local
W (87960) mdns-test: No results found!
I (87960) mdns-test: Query PTR: _ftp._tcp.local
W (91060) mdns-test: No results found!
I (91060) mdns-test: Query PTR: _nfs._tcp.local

Zeroconf browser on different machine shows that an mdns service with esp.local hostname is already running in the network.

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 26 (4 by maintainers)

Commits related to this issue

mdns: sending search packets also in probing and announcing state mdns queries did not work properly when send imeadiately after set_hostname, which cuased reinit of pcb and therefore restarted probi... — committed to espressif/esp-idf by david-cermak 6 years ago
mdns: sending search packets also in probing and announcing state mdns queries did not work properly when send imeadiately after set_hostname, which cuased reinit of pcb and therefore restarted probi... — committed to espressif/esp-idf by david-cermak 6 years ago

Most upvoted comments

Thanks @AadiMehta for sharing the code. I was successfully able to recreate both issues. I am however convinced that none of the issue is on the esp-mdns library side.

Let me explain, you can test and investigate in your environment with any dns resolving tool and wireshark.

Not resolving mixed case name. When executed the zeroconf script you provided, the name Bar_service_name.local is not resolved, but you can see the querries being send to network.

When running

dns-sd -B _services._dns-sd._udp
dns-sd -B _samplefoobar._tcp
dns-sd -L Bar_service_name _samplefoobar._tcp

the name gets resolved and further pings to Bar_service_name.local work fine.

It works in a similar way when running avahi on linux (no name resolution, queries appear in local network, but no answers)

Of course when running the script with lower case server, resolution works without any browse protocol, list services, etc. querries and corresponding replies could be seen on network.

Having to run multiple API’s for zeroconf script vs mdns_query_ptr for googlezone: The answer field in a response packet from zeroconf server is only PTR type as you see it on the ESP32 log.

Compare this to a mdns advevertize server running using avahi-daemon /etc/avahi/services/foo.service:

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name>Foo_service</name>
  <service>
    <type>_samplefoobar._tcp</type>
    <port>80</port>
  </service>
</service-group>

avahi_answer

YOu can see that the reply packet contains much more answer fields, also the ESP32 log shows these details (PTR, SRV, A records):

I (5457227) mdns-test: Query PTR: _samplefoobar._tcp.local
1: Interface: STA, Type: V6
  PTR : Foo_service
  SRV : raspberrypi.local:80
  A   : 254.128.0.0
2: Interface: STA, Type: V4
  PTR : Foo_service
  SRV : raspberrypi.local:80
  A   : 192.168.0.141
  A   : 254.128.0.0

david-cermak on Oct 16, 2018

@david-cermak

If you require, here is a sample python-zeroconf mdns server.

sample_mdns_server.zip

For this zeroconf python library will be required.

AadiMehta on Oct 11, 2018