[SoftAP] HTTP-based public-key command times out

Hello,

We’re debugging some issues we’ve come across with SoftAP. It used to work, but somehow something broke…

We have an Ionic app that used the http-based softap library via browserify. That implementation would send the device-info, public-key, scan-ap, and configure-ap commands without issues. We built on top of that a custom UI similar to what is done with the Particle branded app.

I’m not sure at what point things stopped working because we didn’t test this for a while, but now when I go back to test it, the public-key command is timing out.

I’m able to reproduce this when I connect to the device using a Macbook Pro and send the command via postman. I can get good responses from device-info and version, but public-key times out.

The device is a P1 running system firmware 0.6.2.

In looking at the release notes for the 0.7.0 release candidates, I notice there’s a lot of activity regarding SoftAP. Is it possible this is an issue with 0.6.2? I will probably try running 0.7.0-rc.2 and see if this resolves it.

I know there has been a lot of issues with the HTTP-based implementation of SoftAP as well. In fact I’m able to run the public-key command just fine using TCP and my macbook. Unfortunately the TCP workflow still fails in the configure-ap step, I created another topic for that issue. Since we’re running Ionic (Cordova) we could migrate to use TCP in the app instead of HTTP, but would require a custom implementation of the softap-setup-js library which I was hoping to avoid. So anyway, is there any hope for HTTP or should I just focus on the TCP solution?

Currently 0.7.0-rc.2 is not an option since SoftAP is broken there. A fix has been found but not been released yet.
https://github.com/spark/firmware/issues/1360

1 Like

Thanks for the heads up @ScruffR. I did some more testing this morning and I can confirm that I’m able to successfully pull the public key using HTTP if I disable the system thread. We were previously running with SYSTEM_THREAD(ENABLED) but I commented that out and the public-key command works fine.

I’ll continue testing the rest of the HTTP-based SoftAP flow with the system thread off and report back here. I think we might be ok without the system thread enabled for our application.

The fix for this issue is now released in 0.7.0-rc.3

2 Likes

After implementing a new feature in our firmware, it looks like this issue is back. We’re still on system firmware 0.6.2, and are using it with system thread not enabled and SYSTEM_MODE(SEMI_AUTOMATIC);

The issue is the same as I previously reported - device-info and version commands return good responses, but public-key times out.

As we have a lot of custom functionality in our firmware, it’s tough to say which change specifically caused this to stop working even with the system thread disabled. I’m a bit mystified as to why features in our firmware would cause it to fail, as it’s my understanding that the application loop() is not called during wifi setup. I also have a check in our 1hz timer callback that checks for WiFi setup and doesn’t call any of our timer trigger functions if WiFi setup is enabled. So it must have something to do with the amount of memory we’re allocating or something?

I’m hoping we can just move to system firmware 0.7.x once it’s released since that fixes some known bugs in this area, does anyone know if there is a release date set yet for that?

Thanks!

Well I think we got to the bottom of this one, I think the root cause was basically too much memory usage in our application firmware.

I tried updating to 0.7.0-rc3 but that did not change the behavior. After a while of mucking around I decided to inspect the System.freeMemory() in a 1 hz timer while I went through the WiFi setup. I noticed that when we had all our code linked in the free memory during WiFi setup would drop to around 3.5 KB. This is apparently not enough to run the public key command?

We were able to reduce the size of a statically allocated buffer to free up some space and now the WiFi setup is working as normal. I was even able to turn the system thread back on and it still works - using the system thread must have added just enough additional memory pressure that put us over the threshold for the wifi setup stuff to stop working.

2 Likes