For reference here's an example of how the lwIP callbacks arise during a normal IPv4 WiFi connection and automatic re-connection:at this point I rebooted the WiFi access point
Notice how netif_status_callback() doesn't appear to be called when the link comes back up, so that's probably not a good trigger to reconnect the application. Checking for reason & LWIP_NSC_IPV4_ADDR_VALID in netif_ext_callback() looks like a better bet.
Code:
---- Opened the serial port /dev/tty.usbmodem212402 ----Version: 7.95.49 (2271bb6 CY) CRC: b7a28ef3 Date: Mon 2021-11-29 22:50:27 PST Ucode Ver: 1043.2162 FWID 01-c51d9400cyw43 loaded ok, mac (hw addr)API: 12.2Data: RaspberryPi.PicoWCompiler: 1.29.4ClmImport: 1.47.1Customization: v5 22/06/24Creation: 2022-06-24 06:55:08connecting to (network name)connect status: joiningconnect status: link failconnect status: joining netif_link_callback() netif_ext_callback(LWIP_NSC_LINK_CHANGED )connect status: no ip netif_status_callback() netif_ext_callback(LWIP_NSC_IPV4_ADDRESS_CHANGED | LWIP_NSC_IPV4_GATEWAY_CHANGED | LWIP_NSC_IPV4_SETTINGS_CHANGED | LWIP_NSC_IPV4_ADDR_VALID)connect status: link upWiFi connectedconnecting to MQTT serverconnectedapplication running (core 0)Code:
netif_link_callback() netif_ext_callback(LWIP_NSC_LINK_CHANGED )MQTT connect timeout netif_link_callback() netif_ext_callback(LWIP_NSC_LINK_CHANGED ) netif_ext_callback(LWIP_NSC_IPV4_ADDR_VALID)Statistics: Posted by mjcross — Thu Nov 20, 2025 8:41 am