The "make" build system was deprecated in v4.0 in favor of idf.py
(cmake). The remaining support is removed in v5.0.
* Original commit: espressif/esp-idf@9c1d4f5b54
The following changes have been made:
1. All FreeRTOS kernel source files are now placed in the
freertos/FreeRTOS-Kernel folder to match with the upstream folder structure.
2. All kernel include files are now placed in freertos/FreeRTOS-Kernel/include.
3. All port files are now placed in freertos/FreeRTOS-Kernel/portable.
4. All additions/customizations are placed in freertos/esp_additions.
5. All other miscellaneous files (README, License files etc.) are moved to
freertos/FreeRTOS-Kernel folder to match with the upstream.
6. Updated esp-cryptoauthlib to latest commit to resolve FreeRTOS
include dependencies.
Signed-off-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
* Original commit: espressif/esp-idf@4846222102
Fix for packets containing unexpected domains, such as openthread.thread.home.arpa.
If we find this packet we set the name entry as invalid, but continue with parsing as the packet might contain related queries for us.
Closes https://github.com/espressif/esp-idf/issues/7694
* Original commit: espressif/esp-idf@d16f9bade5
* 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
* Original commit: espressif/esp-idf@54e329444a
Regression from 2893d7e21b skipped reading the packet causing issues when locally reproducing crashed found by the fuzzer
* Original commit: espressif/esp-idf@dae803335e
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
Strict mode was hardcoded in private header file, but it's useful for
users to enable/disable it depending on the mdns library they are using.
e.g. Avahi might not resolve the non-strict answers.
* Original commit: espressif/esp-idf@0eee31546d
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
