@felixdoerre Thank you for your work. I had started yesterday as well with changes. See https://github.com/robert-hh/micropython/tree/ports_ipconfig
There, only STM32 and MIMXRT are included, but the changes are the same as your's. I've tested these and they work fine. I will test the ESP32 implementation. The one I'm currently working on is NINAW10. Since you did not touch that yet, I can continue. I scratched my head a little bit to understand your code's logic.
About the NINAW10: As far as I can tell, the NINAW10 support cannot change the DHCP mode. DHCP is always enabled. I'll finish the NINAW10 version today.
b.t.w.: your comment (setting the IP in CIDR notation requires more work) applies at all ports.

Tested your changes for MIMXRT (MIMXRT1020_EVK) and STM32 (LAN: PYBD_SF6 with DP83848, WiFi: Built-in CYW43) and they work, as expected. I did not test other boards because the changes do not touch board-specific features.

Tested a little bit more.
ESP32:
The ESP32 port builds and I can query parameters.

• Setting e.g. addr4 failed.

>>> lan.ipconfig(addr4="10.0.0.144/16")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't specify pos and kw args

and

>>> lan.ipconfig(addr4=("10.0.0.144", "255.255.255.0"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't specify pos and kw args

• network.ipconfig() is missing.

MIMXRT & STM32:

• Setting addr4 using CIDR notation failed:

>>> lan.ipconfig(addr4="10.0.0.216/24")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid arguments

I have updated my branch with the implementation for NINAW10. It includes code for network.ipconfig(), even if the effect with NINAW10 is unclear, which may allow to set the DNS, but it cannot be read back from the module.

The following change fixes the bug in using the CIDR notation for lwip based stacks:

--- a/extmod/network_lwip.c
+++ b/extmod/network_lwip.c
@@ -303,6 +303,7 @@ mp_obj_t mod_network_nic_ipconfig(struct netif *netif, size_t n_args, const mp_o
                                     to_copy = split - addr_str;
                                 }
                                 memcpy(plain_ip, addr_str, to_copy);
+                                plain_ip[to_copy] = '\0';
                                 mp_obj_t prefix_obj = mp_parse_num_integer(split + 1, strlen(split + 1), 10, NULL);
                                 prefix_bits = mp_obj_get_int(prefix_obj);
                             }
@@ -310,7 +311,7 @@ mp_obj_t mod_network_nic_ipconfig(struct netif *netif, size_t n_args, const mp_o
                                 uint32_t mask = -(1u << (32 - prefix_bits));
                                 ip_addr_set_ip4_u32_val(netmask, ((mask & 0xFF) << 24) | ((mask & 0xFF00) << 8) | ((mask >> 8) & 0xFF00) | ((mask >> 24) & 0xFF));
                             }
-                            if (!ipaddr_aton(addr_str, &ip_addr)) {
+                            if (!ipaddr_aton(plain_ip, &ip_addr)) {
                                 mp_raise_ValueError(MP_ERROR_TEXT("invalid arguments"));
                             }
                             if ((mp_obj_str_get_qstr(args[0]) == MP_QSTR_addr6) != IP_IS_V6(&ip_addr)

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.39%. Comparing base (0e19286) to head (e138baf).

@@           Coverage Diff           @@
##           master   #14199   +/-   ##
=======================================
  Coverage   98.39%   98.39%           
=======================================
  Files         161      161           
  Lines       21204    21204           
=======================================
  Hits        20864    20864           
  Misses        340      340           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:   +20 +0.005% PYBV10
     mimxrt:   +24 +0.007% TEENSY40
        rp2:   +40 +0.005% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS

I updated the NINAW10 commit a few minutes ago. So you might not have taken the right version. Better wait a while, usually until the next day.
Edit: Sorry, you seem to have the last version.

OK. What's next. I could either continue with ESP8266 or CC3200.

I've incorporated the suggestions that were in the comments, so the esp32 code could work now. You can re-test that one. And/or start working on esp8266. I am not sure if esp8266 needs different code, or if that can re-use code from esp32, and if we can re-use code, should we try to extract the common logic somewhere?

OK. I'll re-test the ESP32. If you want to work at the ESP8266 code, I can go for the CC3200.
Or do you want to go for the esp32_ppp first?

The ESP32 code works fine. One little hiccup.
After setting DHCP first True, then False, the dns was still set, which seems wrong. Then, after setting addr4 and gw, dns was shown as 0.0.0.0. Nothing that needs a fix.

OK. I'll re-test the ESP32. If you want to work at the ESP8266 code, I can go for the CC3200.
Or do you want to go for the esp32_ppp first?

I can go for esp32_ppp first, but that one also seems wired to me. It can only be used to set dns and not ip addresses, and retreive the whole 4-tuple. Also it does not set dns with something interface-specific, but with the lwip-global dns_setserver. Do you know if that would work as well instead of esp_netif_set_dns_info? And if so, maybe the best way is:

• make dns network-global, and only use dns_setserver().
• for ppp implement a method to get addr+gw
• remove the dns set/get logic from network_common.

If that sounds sane to you, I'd continue with those changes, and you can pick esp8266 or cc3200 whatever you prefer.

I added a commit to my branch for NINAW10 dealing with dhcp4. For better visibility, I kept that separate. You can pick that commit and squash it to the existing NINAW10 commit.

I have no knowledge and no position about esp32_ppp. About dns setting per interface or global: that has to be tested. I can do that, if you have the code. dns setting was otherwise a network option. Although having a rather large function and some tweaky code in modnetwork.c seems not appropriate.

A few build errors with the last commit for ESP32_PPP. The last one is just a typo.

/home/robert/Downloads/MicroPython/micropython/ports/esp32/network_common.c: In function 'esp_network_ipconfig':
/home/robert/Downloads/MicroPython/micropython/ports/esp32/network_common.c:168:31: error: implicit declaration of function 'dns_getserver' [-Werror=implicit-function-declaration]
  168 |                 ipaddr_ntoa_r(dns_getserver(0), addr_str, sizeof(addr_str));
      |                               ^~~~~~~~~~~~~
/home/robert/Downloads/MicroPython/micropython/ports/esp32/network_common.c:168:31: warning: passing argument 1 of 'ipaddr_ntoa_r' makes pointer from integer without a cast [-Wint-conversion]
  168 |                 ipaddr_ntoa_r(dns_getserver(0), addr_str, sizeof(addr_str));
      |                               ^~~~~~~~~~~~~~~~
      |                               |
      |                               int
In file included from /home/robert/Downloads/esp-idf/components/lwip/lwip/src/include/lwip/sockets.h:46,
                 from /home/robert/Downloads/esp-idf/components/lwip/include/lwip/sockets.h:8,
                 from /home/robert/Downloads/MicroPython/micropython/ports/esp32/network_common.c:45:
/home/robert/Downloads/esp-idf/components/lwip/lwip/src/include/lwip/ip_addr.h:245:38: note: expected 'const ip_addr_t *' {aka 'const struct ip_addr *'} but argument is of type 'int'
  245 | char *ipaddr_ntoa_r(const ip_addr_t *addr, char *buf, int buflen);
      |                     ~~~~~~~~~~~~~~~~~^~~~
/home/robert/Downloads/MicroPython/micropython/ports/esp32/network_common.c:193:25: error: implicit declaration of function 'dns_setserver' [-Werror=implicit-function-declaration]
  193 |                         dns_setserver(0, &dns);
      |                         ^~~~~~~~~~~~~
In file included from /home/robert/Downloads/MicroPython/micropython/py/mpstate.h:35,
                 from /home/robert/Downloads/MicroPython/micropython/py/runtime.h:29,
                 from /home/robert/Downloads/MicroPython/micropython/ports/esp32/network_common.c:36:
/home/robert/Downloads/MicroPython/micropython/ports/esp32/network_common.c: At top level:
/home/robert/Downloads/MicroPython/micropython/ports/esp32/network_common.c:206:57: error: 'network_ipconfig' undeclared here (not in a function); did you mean 'esp_network_ipconfig'?
  206 | MP_DEFINE_CONST_FUN_OBJ_KW(esp_network_ipconfig_obj, 1, network_ipconfig);
      |                                                         ^~~~~~~~~~~~~~~~
/home/robert/Downloads/MicroPython/micropython/py/obj.h:391:104: note: in definition of macro 'MP_DEFINE_CONST_FUN_OBJ_KW'
  391 |     {{&mp_type_fun_builtin_var}, MP_OBJ_FUN_MAKE_SIG(n_args_min, MP_OBJ_FUN_ARGS_MAX, true), .fun.kw = fun_name}
      |                                                                                                        ^~~~~~~~
/home/robert/Downloads/MicroPython/micropython/ports/esp32/network_common.c:158:17: warning: 'esp_network_ipconfig' defined but not used [-Wunused-function]
  158 | static mp_obj_t esp_network_ipconfig(size_t n_args, const mp_obj_t *args, mp_map_t *kwargs) {
      |                 ^~~~~~~~~~~~~~~~~~~~

Just needed to uncomment #include "lwip/dns.h" and adding an esp_ at the method declaration. Now it builds. More later.

Hmm, when you now set the address without netmask, it assumes /32. Is that reasonable? Maybe we should assume /24 as a sane default.

Right & thanks. The intention was to not touch the netmask at all, like the ESPxx, NINAW10 and CC3200 does at the moment.

Updated. I was caught by the deferred setting of ip_addr and netmask. Please cross-check.

@felixdoerre While adding ipconfig() to another port which I support I noticed, that the code setting addr4 can be simplified. addr_str and to_copy are in most ports not needed. I pushed already the changes for C3200 and NINAW10 to the usual place. ESP32 and ESP8266 can be simplified similarly and had the behavior, that when skipping the /nnn in CIDR notation the netmask was 255.255.255.255. Updated files to ESP32 and ESP8266:
network_common.zip for the ESP32 port
network_wlan.zip for the ESP8266 port.

Thx for cleaning up. Yes. This looks reasonable. I've incorporated all those changes.

Thanks. One thing that I not really comfortable with is the dns setting in network.ipconfig(). Even if I understand the reason, it's kind of bumpy, because one cannot set all parameters with one call. It requires network.ipconfig() for dns and nic.ipconfig() for the other parameters.
Is there a common practice of reference for ipconfig() and it's parameters?

We discussed options in #12600. I am not aware of any other ipconfig method (like e.g. from cpython) that we modeled this after. Maybe the thing that fits the closest is the low-level interface to configure networking on linux. Do you know how the esp interfaces behave, if you have multiple and set/receive via dhcp different DNS servers on both? From what I have seen in the lwip library, the two dns servers should override each other, which can be a bit irritating, when you configure two different nics.

When you have a more complete complex linux system with resolved, that service manages the per-link dns servers and tries to intelligently switch between them, but given we don't have such a component, I'd feel that per-link dns servers are irritating.

Initially, I also envisioned to set the default gw globally, so one can actively choose where packages are routed per default, but it seems we left that out.

(and additionally, prefer is also global and only makes sense globally. That would be even more irritating if set per link, so if we have ipv6 we need that global method anyways).

Interestingly the last comment of Damien in #12600 uses a DNS setting in the nic.ipconfig() method.

Yes, and when I implemented the first round for lwip, I had dns in the nic method, but Damien hinted to keep the split between global and nic-config: #13689 (comment)

Maybe that can be re-considered. I most cases just one NIC is used. And most ports allow just one NIC well at a time. The ESP32 port for instance allows to use both WiFi and Ethernet at the same time in a good fashion, but for other ports this either does not work or is somewhat unresponsive. At least it's that what I have seen.

A similar thing, is that activating dhcp is now non-blocking, meaning that if you want to make sure, you have an IP before you continue, requires additional calls. Maybe the easiest way for "common usage" would be to have one "network-config" method, that can accept one dict, and then also deal with wifi-phy setup and similar? Because the goal, to configure networking in one call, is already not possible in most cases.

These code changes LGTM, although I think at some point (not this PR) we should look at refactoring out some of the common parts - for example splitting an IPV4/NETMASK string is implemented at least four times and they're not all the same.

There might even be a way to do this like the recent extmod/machine changes where the port supplies some static functions for each action, and there's one common argument parsing and verification routine.

But not for this PR, this LGTM.

Maybe the easiest way for "common usage" would be to have one "network-config" method, that can accept one dict, and then also deal with wifi-phy setup and similar? Because the goal, to configure networking in one call, is already not possible in most cases.

How difficult do you think this would be to implement on top of what's here? Agree it'd be a nice helper method for the common use case, although I worry a bit about the complexity of all the smaller details.

How difficult do you think this would be to implement on top of what's here? Agree it'd be a nice helper method for the common use case, although I worry a bit about the complexity of all the smaller details.

I am not sure how difficult this will turn out. Some challenge might be, that the order of applying config options matters sometimes. I'd imagine something like this:

{
 "wlan": {
  "module": "WLAN",
  "params": [network.STA_IF],
  "connect": ["ssid", "password"],
  "config": {"txpower": 7},
  "ipconfig": {"addr4":"10.0.4.2/24", "gw4": "10.0.4.1", "autoconf6": True}
  },
   "wlanAP": {
  "module": "WLAN",
  "params": [network.AP_IF],
  "connect": ["ssid", "password"],
  "config": {"security": 1},
  "ipconfig": {"addr4":"10.0.5.1/24", "addr6": "...."}
  },
  "ipconfig": {"dns": "10.0.4.1", "prefer": 4)
}

Applying this, should be possible in a few simple calls. I am not sure how one would convey, that you want to block until dhcp/autoconf is ready.

But I guess testing all the "rough corners" and making sure, every thinkable network configuration works, will be the tougher challenge. Also making sure that the semantics of this dict is the same across all boards. I am pretty sure, the format and semantics would need quite a few more discussions.

Thanks @felixdoerre and @robert-hh for all your work on this PR. I haven't forgotten about it! But it's too big of a change for the imminent v1.23.0 release, so will go in after that release is cut.

Now merged!

Regarding "easy network configuration": this is probably a good idea to have, to help users navigate the new complexity in address configuration. At the very least we need good docs (there's #14140 for that). Then eventually we can work towards some helper functions (written in Python) to make network configuration simpler.

I've tested those changes on my Portenta H7 (STM32) and my problem with setting a static IP address still happens in v1.24.0-preview.315.g8feb714b4

Maybe you guys could have a look? #15877

Thank you!