8 Commits

Author	SHA1	Message	Date
Daniël van de Giessen	1df5ee12e8	esp32/network_ppp: Stop polling if PPP was disconnected. ... When disconnecting from PPP the modem sends a confirmation. This message is received, like all messages, through the poll() method. lwIP may then immediately call our status callback with code PPPERR_USER to indicate the connection was closed. Our callback then immediately proceeds to free the PCB. Thus, during each new iteration of the loop in poll() we must check if we haven't disconnected in the meantime to prevent calling the pppos_input_tcpip with a PCB that is now NULL. Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>	2025-08-25 23:11:33 +10:00
Daniël van de Giessen	72147c02c7	esp32/network_ppp: Stop polling if stream becomes None. ... If while a polling operation is active the stream is removed we should stop polling data from that stream. This was already the intended behaviour, but implemented incorrectly. Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>	2025-08-25 23:11:33 +10:00
Daniël van de Giessen	8c47ff7153	esp32/network_ppp: Correctly clean up PPP PCB after close. ... If PPP is still connected, freeing the PCB will fail and thus instead we should trigger a disconnect and wait for the lwIP callback to actually free the PCB. When PPP is not connected we should check if the freeing failed, warn the user if so, and only mark the connection as inactive if not. When all this happens during garbage collection the best case is that the PPP connection is already dead, which means the callback will be called immediately and cleanup will happen correctly. The worst case is that the connection is still alive, thus we are unable to free the PCB (lwIP won't let us) and it remains referenced in the netif_list, meaning a use-after-free happens later when lwIP traverses that linked list. This change does not fully prevent that, but it *does* improve how the PPP.active(False) method on the ESP32 port behaves: It no longer immediately tries to free (and fails), but instead triggers a disconnect and lets the cleanup happen correctly through the status callback. Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>	2025-08-11 12:38:37 +10:00
Daniël van de Giessen	adcfdf625b	esp32/network_ppp: Use non-thread-safe API inside status callback. ... The status callback runs on the lwIP tcpip_thread, and thus must use the non-thread-safe API because the thread-safe API would cause a deadlock. Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>	2025-08-11 12:38:37 +10:00
Daniël van de Giessen	3b1e22c669	esp32/network_ppp: Restructure to match extmod/network_ppp_lwip. ... The ESP32 PPP implementation predates the generic implementation in extmod. The new extmod implementation has a few advantages such as a better deinitialisation procedure (the ESP32 implemementation would not clean up properly and cause crashes if recreated) and using the UART IRQ functionality instead of running a task to read data from the UART. This change restructures the ESP implementation to be much closer to the new extmod version, while also bringing a few tiny improvements from the ESP32 version to the extmod version. The diff between extmod/network_ppp_lwip.c and ports/esp32/network_ppp.c is now a small set of easy to review ESP32 port-specific changes. Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>	2025-05-15 11:56:14 +10:00
Daniël van de Giessen	77406b4240	extmod/network_ppp: Allow stream=None to suspend PPP. ... This allows the stream to be set to `None`, which essentially stops all PPP communication without disconnecting the session. This allows replacing the stream on-the-fly to suspend it, for example to send AT commands to a modem without completely disconnecting and re-establishing the PPP connection: uart = ppp.config('stream') ppp.config(stream=None) uart.write(b'+++') # do some AT commands uart.write(b'ATO\r\n') ppp.config(stream=uart) Any attempted communication by PPP while the stream is not connected will register as simple packet loss to the LwIP stack because we return 0 for any write calls, and protocols like TCP will then automatically handle retrying. Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>	2024-11-13 13:11:32 +11:00
Daniël van de Giessen	161e2bd37d	extmod/network_ppp: Add stream config parameter. ... This makes the stream that the PPP object wraps, which is normally only set once via the constructor, accessible and configurable via the `ppp.config()` method. Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>	2024-11-13 13:10:58 +11:00
Damien George	bc952d37fe	extmod/network_ppp_lwip: Add network.PPP via lwIP. ... This commit adds a new `network.PPP` interface which works on any port that has bare-metal lwIP, eg rp2, stm32, mimxrt. It has been tested on stm32. A board needs to enable `MICROPY_PY_NETWORK_PPP_LWIP` and then it can use it as follows: import network ppp = network.PPP(uart) ppp.connect() while not ppp.isconnected(): pass # use `socket` module as usual, etc ppp.disconnect() Usually the application must first configure the cellular/etc UART link to get it connected and in to PPP mode first (eg ATD*99#), before handing over control to `network.PPP`. The PPP interface automatically configures the UART IRQ callback to call PPP.poll() on incoming data. Signed-off-by: Damien George <damien@micropython.org>	2024-08-29 23:46:13 +10:00