1. fix(wifi): Rename old NAN configuration to NAN-Sync
- Rename CONFIG_ESP_WIFI_NAN_ENABLE to CONFIG_ESP_WIFI_NAN_SYNC_ENABLE to indicate
the support for Synchronized NAN (Wi-Fi Aware).
- Because the original flag really controls the synchronized feature set, rename it
to CONFIG_ESP_WIFI_NAN_SYNC_ENABLE so the NAN-Sync and NAN-USD paths can be
selected independently without confusion.
2. Document esp_wifi_start requirement and fix USD examples
3. Rename nan_callbacks to nan_sync_callbacks
4. Remove the discovery_flag, clarify docs for sync vs USD flows, and add USD start/stop APIs
5. Require esp_wifi_start() before USD start
6. docs(nan): add NAN-USD application examples
7. add migration guide and hints for NAN-USD proto field
8. Improve allow_broadcast documentation
9. Add attention to the API esp_wifi_remain_on_channel
10. fix(wifi): align NAN API renames and docs for v6.0
- keep shared APIs under esp_wifi_nan_* while reserving
sync/usd names for mode-specific entry points
- clarify synchronized-cluster scope in headers, docs, and migration notes (EN/zh-CN)
- update examples for renamed helpers and WIFI_NAN_SYNC_CONFIG_DEFAULT()
- rename `wifi_nan_config_t` to `wifi_nan_sync_config_t`
11. Mark NAN-USD as esp-idf experimental feature
Since it's the DHCP server that assigned and IP to a client,
(the DHPCS doesn't have to be an AP, and DHCPC doesn't have to
be a station or an Eth netif)
Closes https://github.com/espressif/esp-idf/issues/15663
Make it possible to set the DNS servers to provide to the peer. This is
useful when acting as a PPP server.
If any DNS server is set, don't request a DNS server from the peer.
Introducing config option `CONFIG_ESP_NETIF_SET_DNS_PER_DEFAULT_NETIF`
to overcome LWIP limitation of using global DNS server info.
This config option enables LWIP callbacks to collect per netif DNS
server info and then restores global DNS servers of whichever network
interface is selected as default.
LWIP submodule update: git log --oneline aa4f6e78..3a3d1fb3
- dns: Allow storing dnsserver per netif (espressif/esp-lwip@3a3d1fb3)
UDP application sends packet using esp_netif, underlying transport such
as Wi-Fi may drop the packet due to higher load. New error code
represent transient, non-fatal packet drop error. udp application may
use such errtype, for example to rate limit.
DHCP Option 114 provides a modern method of indicating a captive
portal redirect to DHCP client. This introduces Option 114 to
the DHCPS component as well as provides examples for usage.
This commit removes the lock from the list manipulation code in esp_netif_objects.c,
because we already have another lock/task context for lwip.
So the list manipulation is unsafe and safety must be assured by the stack layer
(in esp_netif_lwip).
Problems with current locking:
* implementation of locking was wrong -- lazy init style of creating the mutex is not
thread safe (and destroying it if we have no interface makes the problem exhibit very frequently)
* locking only the list won't solve issues when assessing interfaces atomically
* maintaining multiple locks is problematic, as we often switch between
lwip context and user context in internal implementation of esp_netif_lwip
Closes https://github.com/espressif/esp-idf/issues/12261
If LCP keepalive mechanism is enabled in menuconfig, it's statically
configured on creation of an interface and cannot be changed runtime. In
some cases it's useful to relax LCP criteria during runtime operation,
for example before initiating OTA. This config option allows for
disabling already enabled LCP echo (this setting becomes effective after
reconnecting, i.e. initializing a new session)
Closes https://github.com/espressif/esp-protocols/issues/287
