* Reduced number of include paths
* Abstract the internals of mdns packet (specifics defined in
mdns_networking.c)
* Use ESP_IP addresses instead of lwip addresses
mdns resolver didn't correctly resolved queries when host name wasn't
assigned. Fixed by allowing processing also if some answer present
(non-strict mode)
Closes https://github.com/espressif/esp-idf/issues/6598
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.
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
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
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
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
esp32s2beta: Merge support to master
Closes IDF-513, IDF-756, IDF-758, IDF-999, IDF-753, IDF-749, IDF-754, IDF-840, and IDF-755
See merge request espressif/esp-idf!6100
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