The repeated query will be copied in the next event loop while the
memory is freed instantly. Delay the free to fix this issue.
* Original commit: espressif/esp-idf@5f244c86f2
The resolver was able to respond correctly, but would also resolve its
own queries and cause issues with BCT 1.5.2, specifically
* MULTIPLE QUESTIONS - DUPLICATE SUPPRESSION
* MULTIPLE QUESTIONS - DISTRIBUTED DUPLICATE SUPPRESSION
tests failed.
* Original commit: espressif/esp-idf@b649603a0d
the mDNS responder should not repeat questions when replying, however resolvers
must ignore these questions field if they are present. esp-idf mDNS
library does include questions in answering packets (thus not strictly
following the RFC6762) so the resolver did not correctly resolved
another instance host name.
Closes https://github.com/espressif/esp-idf/issues/6190
* Original commit: espressif/esp-idf@0693e172de
By default adds original queries to responses in order to be resolved by some resolvers, such as lwIP mdns library. This functionality however is discouraged by the RFC6762, so it could be disabled in menuconfig if MDNS_STRICT_MODE configured
Closes https://github.com/espressif/esp-idf/issues/5521
* Original commit: espressif/esp-idf@bcfa36db8f
mdns module store local copy of esp_netif for common interfaces,
but it was correctly initialized only when interface started.
If the event were missed (e.g. mdns_init after interface start)
the local copy wouldn't be initialized. Fixed by restoring the local
copy.
Closes WIFI-1538
* Original commit: espressif/esp-idf@09e36f9f33
mdns library deinitialization destroys internal structures including action queue. if an event (e.g. network update) received
after some essential stucture is destoyed, an unexpected behavour might be introduced (e.g. crash of adding the event notification
to the action queue which was already destroyed
Closes WIFI-1485
* Original commit: espressif/esp-idf@eaa2f12d67
tcpip_adapter_dhcpc_get_status() returns the actual internal value of dhcp client without any locking or TCP/IP stack context call, so when CONNECTED event fired with default settings it started DHCP client in TCP/IP stack context and at the same time mdns event handler checking actual DHCP state, which could still be INIT (not STARTED). Purpose of this check is to enable PCB if DHCP was stopped before setting network interface up (typically static IP settings), so the solutin is to check against TCPIP_ADAPTER_DHCP_STOPPED state
* Original commit: espressif/esp-idf@7f410a0bcb
In case of invalid name entry, only this entry is invalidated and parsing continues as other query entries could contain questions to be responded to
* Original commit: espressif/esp-idf@4bd4c7caf3
Issue: MDNS server initially sends probing packets to resolve naming confilicts with already registered service instances. In case of a conflict, instance name is altered and probing restarts. Original instance however wasnnot removed from the structure and upon service removal only one entry was removed and a dangling service might have been kept in the structure to bring about a crash.
Resolution: Keep only one instance of a service in the probing structure.
Closes IDF-498
* Original commit: espressif/esp-idf@265e983a45
possible race condition: user task runs mdns_init, which enables pcbs while mdns-task already created could execute enable/disable of the same pcbs if an appropriate system event received
* Original commit: espressif/esp-idf@c87f0cb6ca
