[Solved] SoftAP /configure-ap requests thwarted by wiced HTTP server

TL;DR - The Wiced HTTP server deals with requests incorrectly, expecting the entire request to be contained within one TCP packet. This is not always the case, especially with HTTP POSTs with a body of data, which may be split off into a second packet. The issue is confirmed on the Broadcom lists here.

As I mentioned in another post, I’ve been working on a React Native configuration app for our product’s prototypes, which we’d like to deliver to potential customers with a user-friendly interface for setting up wifi.

After a few days’ work, I managed to get an Android device configuring a Photon and fully expected the same app to work on iOS, but to my dismay it did not. Since the configuration step is just an HTTP request being fired from a JS environment, I was wary of the CORS issues mentioned in the very active “Photon softAP usage?” thread, but that turned out to be a red herring.

My attempts to packet sniff the underlying difference between iOS and Android were thwarted because they looked identical in Wireshark…that is, until I finally noticed my iOS request was getting split between header and body into two packets. Going deeper into the rabbit hole revealed the failure to be in how internal WICED server handles HTTP requests.

Turns out: not very well. According to this line in the server code, requests are logically split on a packet-by-packet basis rather than as proper HTTP data streams. This explained why my iOS request was being returned a “successful” {r:0} response - the server was considering the posted data as a separate request! As a side note, this is exactly why I posted here about improving the configuration API to have better error handling, and possibly even provide a way to verify credentials before attempting connection.

The relevant confirmation of this issue can be found here: https://community.broadcom.com/message/14450#14450 . Unfortunately, there doesn’t seem to be a push to fix the behavior, but perhaps Particle can put some pressure on them?


Consider: http://serverfault.com/questions/337949/when-does-a-browser-send-http-payload-separately-from-the-http-request


@mdma https://github.com/spark/firmware/issues/680


I can confirm seeing the same POST-splitting behavior (i.e. request sent with 2 TCP packets) in Safari with an independent packet capture. Chrome only used 1.

Just ran into the same exact issue on our end. Any positive updates or breakthroughs in the past week?

We’re now reverting to the 90’s and creating a desktop app for our unfortunate iOS users…

You’re in luck, looks like @mdma is on it or will be on it shortly:

There’s a PR for testing for anyone that has a local build setup and can flash system-part2.

1 Like

Ok, time to look into local building.

Anything in the pipeline for non-local upgrades?

I can build system-part2.bin if needed - just tell me where’s a good place to store it.


I’m not actually our firmware engineer (rather, I’m the one with some time and some semblance of coding skills), so forgive my ignorance here: I can just flash the system-part2.bin to the photon then re-flash our firmware afterwards and that will be it? (Also, can I flash system-part2.bin via Dev or should I go through terminal or Build instead?)

Best place: somewhere on github I’m assuming - can you attach a file to the issue fix you posted previously?

I’ll add the file to the github issue (It does support attachments, but only a limited set of file extensions.)

For posterity, this issue was fixed as of firmware 0.4.7.