I noticed that the CI build for "esp8266" uses a strange (out-of-tree) path for choosing its lwip which looks quite outdated. Can this be updated or do we need to adjust for that older lwip version by using more preprocessing macros?

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (866fc34) 98.36% compared to head (223e0d9) 98.36%.

@@           Coverage Diff           @@
##           master    #9108   +/-   ##
=======================================
  Coverage   98.36%   98.36%           
=======================================
  Files         159      159           
  Lines       21069    21069           
=======================================
  Hits        20724    20724           
  Misses        345      345           

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

I've rebased the changes to depend on the recently included changes from the cyw43-driver. Regarding the lwip < v2.0 for esp8266: As I haven't heard anything back for #9108 (comment) I don't assume upgrading lwip for esp8266 is an option. So I've did some preprocessor definitions to make the code use the different, incompatible types for lwip < 2.0, in order to make it work on both versions now.

@dpgeorge could you take a look at the changes, give some feedback and hopefully merge them?

Situation with lwip on esp8266 is a PITA. Some closed parts of SDK depend on lwip 1.x. There exists esp82xx-nonos-linklayer project (used in Arduino) that acts as a bridge between those closed parts and lwip 2.x, but micropython is not currently using it.

Actually, the whole esp8266 toolchain that micropython currently uses is very old and abandoned. Ideally, it should be replaced with https://github.com/earlephilhower/esp-quick-toolchain that is maintained and used by Arduino.

UPD: Possibly the easier route is to use https://github.com/someburner/esp-open-sdk that is very much similar to current sdk that is used for esp8266, but bundles esp82xx-nonos-linklayer

Hi @jimmo would you mind giving this a quick look? The changes are pretty simple. I (and from the reactions 3 others), would like to see this merged, with or without enabling it per default for the picoW board.

I, too, would love to see this merged. Would be great to at least have an easy, straightforward way to enable IPv6 for custom builds.

I've rebased the changes @dpgeorge, would you mind commenting, reviewing and/or merging this?

@dpgeorge what's needed to get this over the line? I appreciate that some ISPs are laggards in terms of adopting IPv6 -- if you're struggling to test this with your ISP then please shout as I'm sure we can find a solution.

This looks good!

But I think IPv6 should be disabled by default on rp2 because:

• Pico W's may start behaving strangely on certain networks if they try to use IPv6 routing instead of IPv4, and that network doesn't fully support IPv6
• we should enable it equally and at the same time on all ports that use lwIP
• I think we need at least some of the API functions discussed in IPv6 APIs #12600 so IPv6 can be configured

That said, I'm happy to merge the changes here, as long as it's not enabled by default on rp2.

Thank you for your feedback.

Pico W's may start behaving strangely on certain networks if they try to use IPv6 routing instead of IPv4, and that network doesn't fully support IPv6

I believe as-is this change can not make Pico Ws behave strangely in any broken network, because dns will use the ipv4 address instead. So the behavior is:

• "connect to ipv4 raw address" -> works unchanged
• "connect to ipv6 raw address" -> might work now (if the ipv6 in the network works), and had no chance to work before
• "connect to a dns name with only ipv4" -> works unchanged
• "connect to a dns name with both ipv4 and ipv6" -> works unchanged, as dns prefers ipv4
• "connect to a dns name with only ipv6" -> might work now (if the ipv6 in the network works), and had no chance to work before

Changing the dns default however will change the 4th case. So leaving this as-is for default will not make the device behave different.

we should enable it equally and at the same time on all ports that use lwIP

Good point, feel free to drop 507128e while merging this and we can enable ipv6 a bit later.

I think we need at least some of the API functions discussed in #12600 so IPv6 can be configured

I already have some code for that locally. I will polish that and submit it as PR in the next days.

OK, I've merged this PR without the commit that enables IPv6 on rp2. That can come later.

I already have some code for that locally. I will polish that and submit it as PR in the next days.

Sounds good, thanks!

OK, I've merged this PR without the commit that enables IPv6 on rp2. That can come later.

Are there any news about the commit that enables IPv6? I have the latest release of the firmware and get only ipv4 address

There was a PR that added ipconfig as a more flexible way to configure networking (incl. ipv6), #13689, a PR to extend documentation to cover ipconfig (#14140) , and a PR to implement ipconfig also on other ports, to get a uniform interface: #14199

I think, when #14140 is merged, we could enable IPv6 by default. To use IPv6 right now, you need to enable LWIP_IPV6 and LWIP_IPV4 manually and compile the firmware yourself.