* Update submodule: git log --oneline 8290c3b8f2adaf82aa45ec992b87f16205f2689b..4f24c9baf9101634b7c690802f424b197b3bb685
Detailed description of the changes:
- lower the dhcp discover and request retry backoff time (esp-lwip@4f24c9ba)
- netdb:fixed bug for getaddrinfo returns null when IPV4 mapped address (esp-lwip@a4d70c7e)
Some of the esp_sntp_...() APIs that wrap lwip's SNTP
module use tcpip_callback() to execute the lwip functionality
in the correct state (either with locked TCP/IP core,
or within the TCP/IP thread).
tcpip_callback() however doesn't wait for completion of the callback,
which doesn't prevent from using the stack variables after destroy
if used as a parameter.
Introduced in a71fa82.
Fixed by using of tcpip_api_call() instead of the tcpip_callback().
Closes https://github.com/espressif/esp-idf/issues/10611
* Update submodule: git log --oneline a7abf28e02282b32479f4bbaf2d90f09d2a60f4c..6bb132e3797d5449a923804c75c57d458920f8ac
Detailed description of the changes:
- tcp_in/ooseq: Fix incorrect segment trim when FIN moved (esp-lwip@6bb132e3)
- api_msg: fix tcp_abort thread safety (esp-lwip@53a6e019)
* Cherry-pick important fixes to 2.1.2-esp
- CVE-2020-22283: Attacker could craft a packet that would disclose 8 bytes of some heap memory:
- icmp6: Don't copy too much data
- icmp6: Fix copying of chained pbuf in reply
- icmp6: keep to the RFC and send as much as possible with icmp6 error messages
- CVE-2020-22284: ZEP - ZigBee Encapsulation Protocol/6LoWPAN is not supported in IDF,
the netif module (zepif.c) is not included in the build, but users can still inject
the file into compilation process, implement IO interface and use this.
- zepif: Copy possibly chained output pbuf properly
- Add #define for minimum IPv6 MTU length
- pbuf: Add pbuf_copy_partial_pbuf library function
* PPPoS: Fix null-deref when processing double break packet
- pppos: fix in_tail null (espressif/esp-lwip@537c69d5)
- PPP: Add test exhibiting empty packet null-deref (espressif/esp-lwip@202a07da)
* NAPT: Fix PBUF_REF type to clone the pbuf before forwarding
- IP-FORWARD: If packet-type is PBUF_REF clone it before forwarding
- Add NAPT unit test to exercise NAT feature for both RAM and REF pbuf types
* version: Update version numbers to match 2.1.2-esp
* Update submodule: 2749568fe1...76303df238
- test/napt: Add unit test for IP forward with PBUF_REF (espressif/esp-lwip@76303df2)
- napt: Fix PBUF_REF type to clone the pbuf before forwarding (espressif/esp-lwip@39068263)
- version: Update version numbers to match 2.1.2-esp (espressif/esp-lwip@2b922919)
- pppos: fix in_tail null (espressif/esp-lwip@537c69d5)
- PPP: Add test exhibiting empty packet null-deref (espressif/esp-lwip@202a07da)
- pbuf: Add pbuf_copy_partial_pbuf library function (espressif/esp-lwip@1c9cd9c1)
- Add #define for minimum IPv6 MTU length (espressif/esp-lwip@d2dc577b)
- zepif: Copy possibly chained output pbuf properly (espressif/esp-lwip@64ab7f2a)
- icmp6: Don't copy too much data (espressif/esp-lwip@4a64731b)
- icmp6: Fix copying of chained pbuf in reply (espressif/esp-lwip@7c822ff4)
- icmp6: keep to the RFC and send as much as possible with icmp6 error messages (espressif/esp-lwip@29100ab6)
- dns: Add API to clear dns cache (espressif/esp-lwip@ee59f77d)
- CI: Fixed adding gitlab key (espressif/esp-lwip@5a2bdba7)
- test case: modify test case test_tcp_new_max_num_remove_FIN_WAIT_1 (espressif/esp-lwip@6b090f7d)
Closes https://github.com/espressif/esp-idf/issues/8300
Closes https://github.com/espressif/esp-idf/issues/8451
Moved FreeRTOSConfig.h from include/freertos to include/esp_additions/freertos.
Updated FreeRTOS.h file to include FreeRTOSConfig.h without the
freertos/ prefix to match with the upstream file.
Renamed architecture specific FreeRTOSConfig.h files to FreeRTOSConfig_arch.h
Signed-off-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
LWIP has two definess for setting max number of sntp servers:
- Total number of handled servers
- max number of sntp's picked via DHCP
by default both values are equal to 1, but could be set separately
Signed-off-by: Emil Muratov <gpm@hotplug.ru>
When client's request refused by sending NAK, its record still resided
in the linked list of pooled addresses. It is okay from the spec
perspective (RFC2131.p16: Server MAY mark the offered address
unavailable), but would consume some memory if the client didn't retry.
Closes https://github.com/espressif/esp-idf/issues/6410
David Cermak