#Possible Airlift Breakout Bug

1 messages · Page 1 of 1 (latest)

icy wraith
#

I don't yet have 100% reliable reproduction, but this is what I have so far. I'm using a Pi Pico W, but due to major known connectivity issues with the Pi Pico W, I decided to fix them by using an Airlift Breakout.
As originally written, the sketch opens two listening TCP sockets and one UDP socket.
Initially everything appeared to be working fine, but after several hours I'd start getting bad connections.
Worse yet, using Wireshark, when these bad connections arrived in the sketch, there was no actual traffic going to the Airlift.
There were several manifestations that I saw:

  1. One TCP server is a web server on 80, the other TCP server is for a custom protocol. The custom protocol sends a two byte length followed by the payload. Debug output reported that the custom protocol had seen a length of 17735. Much larger than normal, but that's a highly interesting number in hex: 0x4547. Those two bytes are 'G' and 'E' (little endian). That means that a previous web request was being replayed over the custom path.
  2. On other occasions I'd see connections coming into the web server that than "received" data previously sent over the Serial USB link. No idea how that got there, but the data in the debug logs was instantly recognizable.
  3. Once this got started it carried on repeatedly for ever. I'd get WiFiClient instances returned from WiFiServer::available() that reported true from their operator bool(), but then immediately reports false from WiFiClient::connected()().
    I don't know what's going on inside the Airlift, I'd be interested in learning how to reprogram the firmware on it, but for now I can work around these issues by only using the web server, and just figuring how to survive without the custom protocol.
    The main issue with reproduction, and this bears repeating, it can take hours (several of them) before problems start showing up. So patience will be essential when trying to reproduce this.
icy wraith
#

All that said, I can try and create a small test sketch that reproduces the problem. That might prove very useful to you when trying to track this down.

drifting creek
#

Are you using the latest version of NINA-FW?
We are working on restarting our branch with the latest from upstream: https://github.com/adafruit/nina-fw/pull/62. It might be worth waiting to test with that. Unfortunateyl the artifacts have been deleted. I need to test that PR and will be reconstituting the artifacts.

icy wraith
#

The version I'm using is the one that downloads from the Airlift Learn page download link. The library.properties file states that it's version 1.6.0. The firmware on the airlift is whatever was on it when it arrived here a week or two ago. No idea of the version, nor how to find that out. If there's a code sample I can run in the sketch on the Pi Pico W I can easily add that and report back.
I'm functional for now with this combination, so it sounds like a really good idea for me to wait for the new version.
One thing that may be implied by your message is that I might have to update the firmware on the Airlift board. Since I'm using a PI Pico W, I should just follow the instructions at https://learn.adafruit.com/upgrading-esp32-firmware/upgrade-airlift-firmware-using-rp2040
That does however raise an interesting question. Is the source to the NINA firmware available? I am attracted to the idea of replacing it with custom ESP32 firmware that offloads the web and custom protocol servers to the Airlift, that would reduce the workload on the Pi Pico W.

drifting creek
icy wraith
#

I had to adapt a little. The sample on that page is CircuitPython, while the project I'm working on is C++ (PlatformIO). That said, a quick look in WiFi.h in the WiFiNINA library source shows a function WiFiClass::firmwareVersion() that reports version 1.2.2

drifting creek
# icy wraith I had to adapt a little. The sample on that page is CircuitPython, while the pr...

that is quite old. That version is missing a number of newer root certificates and some fixes. But it also may be more casual about certificates that don't work. You can try updating and see how it works out. The older version is here in case you need to revert: https://learn.adafruit.com/adding-a-wifi-co-processor-to-circuitpython-esp8266-esp32/firmware-files#esp32-only-spi-firmware-3020185. Having said that, the errors you are seeing don't sound cert-related at all.

We are working on a rework of NINA-FW, bringing it up to date with the arduino version. But that is not done yet: https://github.com/adafruit/nina-fw/pull/62

#

You could also do a hard reset on the AirLift or possibly the whole Pico and attached AirLift when you detect that you are in an unrecoverable state