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
esp_netif_set_dns_info() was available only for standard interfaces, not
for Point to point types (PPP, SLIP), but it should be normally
supported. Moreover DNS servers are global in lwip, so it doesn't really
depend on type of the interface.
Also added some minor fixes to the esp_netif_get_dns_info() to allow for
NULL parameters (as it's a public API) and hardcode the IPv4 type in
case of DHCP server capable interface.
Updated logs and added error checks to the original API, before we
launch the lwIP counterpart.
Closes https://github.com/espressif/esp-idf/issues/8648
IP update notification for "point to point" interfaces is performed
via the same callback function as for any other interfaces (dhcp_cb,
although it's not DHCP related). In P2P interfaces we have to assure
that we always get a notification, so we can set the interface up.
This was omitted when getting the same IP address for the second
time, causing the PPPoS interface (in esp-modem applications) failing
to reconnect if disconnected.
Closes https://github.com/espressif/esp-idf/issues/10308
Closes https://github.com/espressif/esp-protocols/issues/188
lwip/netif struct has two places to store user's data
* netif->state (1 void*) but that might be occupied in special cases
* netif->client_dtat (n void*s) but that must be enabled in opts.h
This commit stores esp_netif_t* primarily in state, but if any special
netif is enabled in menuconfig (bridgeif, pppos), it uses netif->client_data.
This commit also fixes incorrect esp_netif that is attached to
IP_EVENT_GOT_IP6 event posted by pppos interfaces in:
c585618b97/components/esp_netif/lwip/esp_netif_lwip_ppp.c (L114)
Closes https://github.com/espressif/esp-idf/issues/9345
Fix dependency tree so that lwip doesn't depend on any specific network
interface component.
Network interface drivers shall depend on esp_netif.
esp_netif shall depend on lwip (but not on any specific interface
driver) -- it optionally depends on vfs and esp_eth (need ethernet
header for L2/bridge mode)
ESP_RETURN_ON_FALSE(a, err_code, ...) macro
Will print and return err_code
if (unlikely(!(a)))
so "a" needs to state what we expect to be TRUE
which in this case means:
mld6_leavegroup_netif(...) == ERR_OK