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>
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>
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>
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>
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>
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>
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>
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>
