mirror
/
esp-idf
kopia lustrzana https://github.com/espressif/esp-idf
1
0
Forkuj 0
Kod Zgłoszenia Projekty Wydania Wiki Aktywność
esp-idf/components/esp_netif/lwip/esp_netif_lwip_ppp.h

84 wiersze
2.4 KiB
C
Czysty Zwykły widok Historia

esp_netif/lwip: Implement basic support for vanilla-lwip (2.1.3-REL) * Reference lwip-2.1.3-REL vanilla lwip version * Use inherent NETIF callbacks instead of dhcp/ipv6/autoip
2022-02-14 12:46:21 +00:00
/*
fix(esp_netif): Lock netif list with TCPIP context 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
2023-09-22 17:10:36 +00:00
* SPDX-FileCopyrightText: 2019-2023 Espressif Systems (Shanghai) CO LTD
esp_netif/lwip: Implement basic support for vanilla-lwip (2.1.3-REL) * Reference lwip-2.1.3-REL vanilla lwip version * Use inherent NETIF callbacks instead of dhcp/ipv6/autoip
2022-02-14 12:46:21 +00:00
*
* SPDX-License-Identifier: Apache-2.0
*/
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
#ifndef _ESP_NETIF_LWIP_PPP_H_
#define _ESP_NETIF_LWIP_PPP_H_
/**
* @brief Creates new PPP related structure
fix(esp_netif): Lock netif list with TCPIP context 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
2023-09-22 17:10:36 +00:00
* This needs to be called withing lwIP context
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
*
* @param[in] esp_netif pointer esp-netif instance
* @param[in] stack_config TCP/IP stack configuration structure
*
* @return
* - pointer to ppp-netif object on success
* - NULL otherwise
*/
esp-netif: SLIP interface refactor to isolate interface from drivers
2020-06-12 14:43:34 +00:00
netif_related_data_t * esp_netif_new_ppp(esp_netif_t *esp_netif, const esp_netif_netstack_config_t *esp_netif_stack_config);
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
/**
* @brief Creates new PPP related structure
fix(esp_netif): Lock netif list with TCPIP context 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
2023-09-22 17:10:36 +00:00
* This needs to be called withing lwIP context
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
*
esp_netif: Extend PPP netif API to control connection failure
2020-11-25 15:37:36 +00:00
* @param[in] esp_netif pointer esp-netif instance
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
*
* @return
* - ESP_OK on success
*/
esp_netif: Extend PPP netif API to control connection failure
2020-11-25 15:37:36 +00:00
esp_err_t esp_netif_start_ppp(esp_netif_t *esp_netif);
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
/**
* @brief Data path API to input incoming packets to PPP
*
* @param[in] ppp pointer to internal ppp context instance
* @param[in] buffer pointer to the incoming data
* @param[in] len length of the data
* @param[in] eb external buffer ptr not used here (to be inline with input function prototypes)
*
* @return
* - ESP_OK on success
*/
esp_netif: Make esp_netif_receive() return value configurable
2023-03-27 10:54:25 +00:00
esp_netif_recv_ret_t esp_netif_lwip_ppp_input(void *ppp, void *buffer, size_t len, void *eb);
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
/**
* @brief Destroys the ppp netif object
fix(esp_netif): Lock netif list with TCPIP context 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
2023-09-22 17:10:36 +00:00
* This needs to be called withing lwIP context
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
*
esp-netif: SLIP interface refactor to isolate interface from drivers
2020-06-12 14:43:34 +00:00
* @param[in] netif_related pointer to internal ppp context instance
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
*/
esp-netif: SLIP interface refactor to isolate interface from drivers
2020-06-12 14:43:34 +00:00
void esp_netif_destroy_ppp(netif_related_data_t *netif_related);
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
/**
* @brief Stops the PPP interface
fix(esp_netif): Lock netif list with TCPIP context 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
2023-09-22 17:10:36 +00:00
* This needs to be called withing lwIP context
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
*
esp-netif: SLIP interface refactor to isolate interface from drivers
2020-06-12 14:43:34 +00:00
* @param[in] netif_related pointer to internal ppp context instance
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
*
* @return
* - ESP_OK on success
*/
esp-netif: SLIP interface refactor to isolate interface from drivers
2020-06-12 14:43:34 +00:00
esp_err_t esp_netif_stop_ppp(netif_related_data_t *netif_related);
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
/**
* @brief Sets default netif for routing priority config
fix(esp_netif): Lock netif list with TCPIP context 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
2023-09-22 17:10:36 +00:00
* This needs to be called withing lwIP context
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
*
esp-netif: set default interface for ppp netif must be called from lwip context On update of any interface (set up/down) a routing preference is updated calling esp_netif_update_default_netif() that is called from lwip context. But if the related netif was ppp type, the set_default api used user-mode, thus causing a dead lock. Closes https://github.com/espressif/esp-idf/issues/4746
2020-02-11 09:27:46 +00:00
* @note: This function must be called from lwip thread
*
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
*/
esp-netif: SLIP interface refactor to isolate interface from drivers
2020-06-12 14:43:34 +00:00
void esp_netif_ppp_set_default_netif(netif_related_data_t *netif_related);
pppos_client: udated example code to use esp-netif in PPP configuration
2019-11-11 15:38:43 +00:00
fix(esp_netif): Lock netif list with TCPIP context 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
2023-09-22 17:10:36 +00:00
/**
* @brief Set PPP auth internal version (TCPIP context must be locked)
* This needs to be called withing lwIP context
*
* For params/return value description, please @refitem esp_netif_ppp_set_auth()
*/
esp_err_t esp_netif_ppp_set_auth_internal(esp_netif_t *netif, esp_netif_auth_type_t authtype, const char *user, const char *passwd);
esp_netif: Enable use of the ESP-IDF with a non-LWIP (and non-BSD-style) IP stack. Note: besides the esp-netif component, this commit also disables net_sockets.c from mbedtls, which is one of the base components and uses BSD API (not specifically lwIP). This might be refactored to use CONFIG_SUPPORT_BSD_API instead of CONFIG_ESP_NETIF_TCPIP_LWIP in the future. It also disables smartconfig_ack.c and wifi_init.c from esp_wifi component for referencing some lwIP config options (smartconfig_ack.c changes might be also updated to check CONFIG_SUPPORT_BSD_API) Merges https://github.com/espressif/esp-idf/pull/5856
2020-09-11 22:37:28 +00:00
#endif // _ESP_NETIF_LWIP_PPP_H_