Fix Static addresses not working after change to ESP_NETIF and network not running with VS debugger #3133
Conversation
nfbot
changed the title
WalkthroughThis update integrates new ESP32 network configuration functionality. A new source file is added to the ESP32 networking build list and implements functions to retrieve network configuration blocks, configure network settings, and apply settings by index. The Ethernet event handler now applies static IP configuration upon connection. The wireless initialization applies static IP configuration for the Wi-Fi station interface. The Ethernet code replaces error aborts with non-aborting checks. The LWIP sockets driver is extended with an ESP32-specific network configuration update method. Corresponding header declarations are added. Changes
Assessment against linked issues
Suggested labels
Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
targets/ESP32/_Network/NF_ESP32_Ethernet.cpp (1)
222-223: Implementation looks good for configuring static addressesThe new code addresses the PR objective by calling
NF_ESP32_ConfigureNetworkByIndexto configure static IP addresses before starting the Ethernet driver, which should prevent them from being overwritten by DHCP.Consider adding error logging here similar to what's in the Wireless implementation for consistency:
- ESP_ERROR_CHECK(NF_ESP32_ConfigureNetworkByIndex(IDF_ETH_DEF, eth_netif)); + esp_err_t ec = NF_ESP32_ConfigureNetworkByIndex(IDF_ETH_DEF, eth_netif); + if (ec != ESP_OK) + { + ESP_LOGE(TAG, "Unable to configure Ethernet - result %d", ec); + }targets/ESP32/_Network/NF_ESP32_Network.cpp (1)
38-42: Improve error handling in default caseThe comment "can't reach here" is misleading since the default case can be reached with an invalid network interface number. Consider logging the invalid number and returning an error code.
default: - // can't reach here - HAL_AssertEx(); + // Invalid network interface number + DEBUG_PRINT("Invalid network interface number: %d\n", num); + return -1; break;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
targets/ESP32/_Network/CMakeLists.txt(1 hunks)targets/ESP32/_Network/NF_ESP32_Ethernet.cpp(1 hunks)targets/ESP32/_Network/NF_ESP32_Network.cpp(1 hunks)targets/ESP32/_Network/NF_ESP32_Wireless.cpp(2 hunks)targets/ESP32/_include/NF_ESP32_Network.h(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: nf-interpreter (Check_Code_Style)
- GitHub Check: nf-interpreter (Check_Build_Options)
- GitHub Check: nf-interpreter (Nightly build) (Check_Build_Options)
🔇 Additional comments (6)
targets/ESP32/_Network/CMakeLists.txt (1)
14-14: Correctly adds the new network file to the buildThis change properly adds the new
NF_ESP32_Network.cppfile to the build, aligning with the PR objective of moving common code into a dedicated file.targets/ESP32/_include/NF_ESP32_Network.h (1)
63-65: New function declarations look goodThese new function declarations support the PR objective by providing proper interfaces for retrieving network configuration blocks and applying network settings to prevent static addresses from being overwritten.
targets/ESP32/_Network/NF_ESP32_Wireless.cpp (2)
115-118: Helper function implementation looks goodThis new function provides a clean, dedicated way to configure the Wi-Fi station with the correct network index.
163-169: Error handling for network configuration looks goodThis implementation properly checks for errors when configuring the Wi-Fi station and logs them appropriately, helping with debugging if there are issues with static IP configuration.
targets/ESP32/_Network/NF_ESP32_Network.cpp (2)
55-69: Memory allocation handling is well implementedThe function properly checks for memory allocation failures and configuration retrieval errors, returning NULL in both cases. This allows the caller to handle errors appropriately.
103-118: Proper memory management in NF_ESP32_ConfigureNetworkByIndexThe function correctly frees the allocated memory for the network configuration block after use, which prevents memory leaks.
|
@alberk8 Are you able to test this is working OK. |
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
targets/ESP32/_Network/NF_ESP32_Network.cpp (2)
11-53: 🛠️ Refactor suggestionAdd a timeout for the infinite loop in
NF_ESP32_Wait_NetNumber.
At present, if the requested interface is never created, the loop can block indefinitely. Consider implementing a max retry count or timeout to prevent the application from hanging.int NF_ESP32_Wait_NetNumber(int num) { esp_netif_t *espNetif = nullptr; + const int maxRetries = 1500; // e.g. 1500 * 20ms = 30 seconds + int retryCount = 0; while (true) { // ... if (espNetif != NULL) { break; } vTaskDelay(20 / portTICK_PERIOD_MS); + if (++retryCount >= maxRetries) + { + return -1; // Indicate failure + } } return espNetif->lwip_netif->num; }
74-101: 🛠️ Refactor suggestionUse official DHCP APIs rather than manipulating
netIf->flags.
Disabling DHCP by modifyingnetIf->flagsdirectly can be fragile. The ESP-IDF recommends usingesp_netif_dhcpc_stop()oresp_netif_dhcpc_start()for robust DHCP control. Additionally, ifenableDHCPistrue, you may want to explicitly enable the DHCP client.bool enableDHCP = (config->StartupAddressMode == AddressMode_DHCP); // If DHCP is enabled, start the DHCP client +if (enableDHCP) { + ec = esp_netif_dhcpc_start(netIf); + if (ec != ESP_OK && ec != ESP_ERR_ESP_NETIF_DHCP_ALREADY_STARTED) { + return ec; + } +} else { // Set static addresses if (config->IPv4Address != 0) { ip_info.ip.addr = config->IPv4Address; ip_info.netmask.addr = config->IPv4NetMask; ip_info.gw.addr = config->IPv4GatewayAddress; ec = esp_netif_set_ip_info(netIf, &ip_info); - netIf->flags = (esp_netif_flags_t)(netIf->flags & ~ESP_NETIF_DHCP_CLIENT); + // Stop DHCP client if configured for static IP + esp_err_t dhcpStop = esp_netif_dhcpc_stop(netIf); + if (dhcpStop != ESP_OK && dhcpStop != ESP_ERR_ESP_NETIF_DHCP_ALREADY_STOPPED) + { + return dhcpStop; + } } }
🧹 Nitpick comments (2)
targets/ESP32/_Network/NF_ESP32_Wireless.cpp (1)
163-169: Revisit the 'ignore any errors' comment.
Although the inline comment states to ignore errors, the code does log errors whenec != ESP_OK. If these unexpected failures need follow-up actions (e.g. disabling further Wi-Fi initialization steps or reverting to DHCP), you might consider more robust handling instead of continuing with partial configuration.targets/ESP32/_Network/NF_ESP32_Network.cpp (1)
103-118: Validate the final result after configuration.
This function retrieves a network configuration block, applies it, and frees the block. Consider logging or confirming that the new IP configuration is successfully set. Adding a short verification step (like anotheresp_netif_get_ip_info()call) could help catch subtle runtime issues.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
targets/ESP32/_Network/NF_ESP32_Network.cpp(1 hunks)targets/ESP32/_Network/NF_ESP32_Wireless.cpp(2 hunks)targets/ESP32/_include/NF_ESP32_Network.h(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- targets/ESP32/_include/NF_ESP32_Network.h
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: nf-interpreter (Check_Code_Style)
- GitHub Check: nf-interpreter (Nightly build) (Check_Build_Options)
- GitHub Check: nf-interpreter (Check_Build_Options)
🔇 Additional comments (1)
targets/ESP32/_Network/NF_ESP32_Wireless.cpp (1)
115-118:❓ Verification inconclusive
Consider explicit handling of station mode checks.
While this function successfully delegates configuration toNF_ESP32_ConfigureNetworkByIndex, ensure that the caller only invokes it if the device is indeed in station mode. If future code calls this outside station mode contexts, it might lead to unexpected results or error logs.Would you like to verify that this function is only called for station interfaces by searching the codebase for its invocations and ensuring the associated logic?
🏁 Script executed:
#!/bin/bash rg -A 4 "NF_ESP32_ConfigureNetworkStation"Length of output: 828
Action: Confirm Explicit Station Mode Validation for NF_ESP32_ConfigureNetworkStation
We verified that the only identifiable invocation of this function is made with a variable named
wifiStaNetifintargets/ESP32/_Network/NF_ESP32_Wireless.cpp, suggesting that it is intended for station mode configurations. However, there is no explicit check within the function (or immediately before its invocation) that confirms the provided interface indeed belongs to station mode. To guard against potential misuse from future changes, please consider adding an explicit validation step—either here or at the caller—to ensure that the function is only used with station interfaces.
- File under review:
targets/ESP32/_Network/NF_ESP32_Wireless.cpp- Identified call site: Invocation using
wifiStaNetifwithout an accompanying station mode check
|
There are some useful suggestions coming out of coderabbitai for existing code but I don't have time at the moment to follow them up. I can do that once I am back from holiday. |
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
targets/ESP32/_Network/NF_ESP32_Network.cpp (2)
95-96:⚠️ Potential issueHandle DHCP enablement as previously recommended.
This logic assigns
enableDHCPbut never starts the DHCP client. A past comment already addressed this omission. WhenenableDHCPistrue, ensure you invokeesp_netif_dhcpc_start()to enable the DHCP client.Consider applying the following diff:
bool enableDHCP = (config->StartupAddressMode == AddressMode_DHCP); + if (enableDHCP) + { + ec = esp_netif_dhcpc_start(netIf); + if (ec != ESP_OK && ec != ESP_ERR_ESP_NETIF_DHCP_ALREADY_STARTED) + { + return ec; + } + }
107-107:⚠️ Potential issueAvoid direct flag manipulation to stop DHCP, as previously advised.
This line is still directly modifying
netIf->flagsto disable the DHCP client. Per the ESP-IDF guidelines, useesp_netif_dhcpc_stop(netIf)instead to improve reliability and forward compatibility.Example fix:
- netIf->flags = (esp_netif_flags_t)(netIf->flags & ~ESP_NETIF_DHCP_CLIENT); + ec = esp_netif_dhcpc_stop(netIf); + // It's okay if DHCP was already stopped + if (ec != ESP_OK && ec != ESP_ERR_ESP_NETIF_DHCP_ALREADY_STOPPED) + { + return ec; + }
🧹 Nitpick comments (1)
targets/ESP32/_Network/NF_ESP32_Network.cpp (1)
98-106: Validate static address settings to avoid invalid configurations.If a static IP is required (
enableDHCP == false) yetconfig->IPv4Addressis0, no valid IP info gets applied. Consider warning or handling this edge case to prevent silently misconfigured interfaces.Example approach:
bool enableDHCP = (config->StartupAddressMode == AddressMode_DHCP); // Set static addresses if (config->IPv4Address != 0) { + // Optionally validate these addresses before applying ip_info.ip.addr = config->IPv4Address; ip_info.netmask.addr = config->IPv4NetMask; ip_info.gw.addr = config->IPv4GatewayAddress; } +else if (!enableDHCP) +{ + // Log warning or handle the scenario where the user specified static mode + // but didn't provide valid static IP data + // e.g. ESP_LOGW("NF_ESP32_Network", "No static IP configured in static mode"); +}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
targets/ESP32/_Network/NF_ESP32_Network.cpp(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: nf-interpreter (Check_Code_Style)
- GitHub Check: nf-interpreter (Nightly build) (Check_Build_Options)
- GitHub Check: nf-interpreter (Check_Build_Options)
|
@AdrianSoundy , I have tested on ESP32 with WIFI and it still using Router DHCP IP. The output shows the static IP that is set but checking with the router interface it shows that the actual IP is 192.168.1.97, it does not seems to respond to ping. Output |
It is possible that the router is caching the IP for the default 24 hour period, and it is not forcing it?! |
|
No, I reboot everything and the ESP32 in question was not not connected to the router for more than 3 days. |
Thanks for testing. I can't look at this until I am back in NZ around 30th March. Currently in Australia. |
josesimoes
left a comment
josesimoes
left a comment
There was a problem hiding this comment.
Let's wait for Adrian to get a chance to test this again.
Automated fixes for code style.
Co-authored-by: Laurent Ellerbach <[email protected]>
Automated fixes for code style.
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
src/PAL/Lwip/lwIP_Sockets.cpp(3 hunks)targets/ESP32/_Network/NF_ESP32_Ethernet.cpp(2 hunks)targets/ESP32/_Network/NF_ESP32_Network.cpp(1 hunks)targets/ESP32/_Network/NF_ESP32_Wireless.cpp(1 hunks)targets/ESP32/_common/targetHAL_Network.cpp(1 hunks)targets/ESP32/_include/NF_ESP32_Network.h(1 hunks)
🧬 Code Graph Analysis (1)
targets/ESP32/_common/targetHAL_Network.cpp (1)
targets/ESP32/_Network/NF_ESP32_Network.cpp (2)
NF_ESP32_ConfigureNetworkByConfigIndex(97-113)NF_ESP32_ConfigureNetworkByConfigIndex(97-97)
🚧 Files skipped from review as they are similar to previous changes (4)
- targets/ESP32/_Network/NF_ESP32_Ethernet.cpp
- targets/ESP32/_Network/NF_ESP32_Wireless.cpp
- targets/ESP32/_Network/NF_ESP32_Network.cpp
- targets/ESP32/_include/NF_ESP32_Network.h
🧰 Additional context used
🧬 Code Graph Analysis (1)
targets/ESP32/_common/targetHAL_Network.cpp (1)
targets/ESP32/_Network/NF_ESP32_Network.cpp (2)
NF_ESP32_ConfigureNetworkByConfigIndex(97-113)NF_ESP32_ConfigureNetworkByConfigIndex(97-97)
🔇 Additional comments (2)
src/PAL/Lwip/lwIP_Sockets.cpp (2)
1453-1454: Verify ESP-IDF API for DHCP flag managementI didn’t find any
esp_netif_set_*or DHCP-related helper in the local codebase to safely enable the DHCP client flag. Directly writing toespNetif->flags(lines 1453–1454 and 1487) bypasses ESP-IDF’s abstraction and may break on upstream changes. Please:
- Check the ESP-IDF documentation (for the version the project depends on) to see if there’s an official API for managing DHCP client flags.
- If no public API exists, add a comment here explaining why direct struct access is necessary and note the ESP-IDF version dependency.
- Apply the same change (comment or API call) at line 1487.
1413-1417: No additional edge-case handling required for NF_ESP32_GetEspNetifThe helper in
targets/ESP32/_Network/NF_ESP32_Network.cppsimply returns the storedesp_netif_t*from eithernetif_get_client_data(netif)(whenLWIP_ESP_NETIF_DATAis set) ornetif->stateotherwise. In ESP-IDF each network interface type—STA, AP, Ethernet, Thread—attaches its ownesp_netifpointer via one of these two mechanisms. Therefore, this function inherently supports all current interface types without further branching.
…e5d-8895-4b9b-bff9-54ae667a4da0 Code style fixes for nanoframework/nf-interpreter PR#3133
AdrianSoundy
changed the title
|
@alberk8 |
AdrianSoundy
added
Platform: ESP32
6 participants
Description
This has been an issue since the IDF changed from TCPIP adapters to the ESP_NETIF interface.
The problem is the ESP_NETIF starts the DHCP when the WIFI connects overriding the static IP settings.
This change updates IP addresses in ESP_NETIF by call esp_netif_set_ip_info() for Ethernet & Wireless networks.
Also tidies up code by moving common code to new file NF_ESP32_Network.cpp
Also fixes issue where network stops working on starting a VS debug session.
Motivation and Context
How Has This Been Tested?
Further testing should be done to confirm chnage is working correctly.Types of changes
Checklist
Summary by CodeRabbit
New Features
Refactor
Documentation