Photon softAP usage?

Well, if it’s not working, try upgrading! Just flash an LED blink app to the Photon from the cloud IDE.

Okay I experimented with Wireshark packet captures today to try and get at the root of the
Safari/iOS issue.

Using:

  • This SoftAP connection page I put together. Which uses the raw XMLHttpRequest object to make XHR requests,
  • A Photon running stock v0.4.5 as flashed via the Particle CLI,
  • OSX 10.7.5,
  • Chrome Version 45.0.2454.101 (64-bit),
  • Safari Version 6.1.6 (7537.78.2),

I got the following TCP stream from Chrome. Which worked

POST /configure-ap HTTP/1.1
Host: 192.168.0.1
Connection: keep-alive
Content-Length: 318
Origin: http://app.neosmartblinds.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
Content-Type: multipart/form-data
Accept: */*
Referer: http://app.neosmartblinds.com/connect/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8

{"idx":0,"ssid":"VIDEOTRON9054","sec":4194308,"ch":6,"pwd":"2f788f8cf7554ef5cecf9ec7e7424d42ed794473f473d221cb30b401bfcae3f2f47b8087fde722b96ed89e2bc6f24de49eb64a4133285388ba33092b6f9a0fffdee30e93fe637df53c8621249934eee54238f1825b45a1439bdb5c7126281e042114b5235d1400083c7c95b8feba8c59ac78f310cb9e0509e10f6e0dc2c978da"}HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: Keep-Alive
Access-Control-Allow-Origin: *
Transfer-Encoding: chunked

1
{
1
"
1
r
1
"
1
:
1
0
1
}
0

And this from Safari, which didn’t get the device to connect…

POST /configure-ap HTTP/1.1
Host: 192.168.0.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/6.1.6 Safari/537.78.2
Content-Length: 318
Accept: */*
Referer: http://app.neosmartblinds.com/connect/
Origin: http://app.neosmartblinds.com
Content-Type: multipart/form-data
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: keep-alive

{"idx":0,"ssid":"VIDEOTRON9054","sec":4194308,"ch":6,"pwd":"4902d3e432f21dfc5f3defa6f2b08d68d47b1aba2649dfed7381f29b8446e836dc89258de60039a59b52e9b936d9132d868579eeafdb8abeb48d06141a7bed224e8ff9fd60c3b3cc14485ea66f9b10dd4d413fe677ddd0675456a765cd4cf024792a12ff7b8ece4e2a2e4a42cbcd7717e31b7b5f5250a6cf9342179a358bcca1"}HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: Keep-Alive
Access-Control-Allow-Origin: *
Transfer-Encoding: chunked

1
{
1
"
1
r
1
"
1
:
1
0
1
}
0

Can anyone spot a relevant difference in the TCP stream? @mdma ? This is basically as raw as it gets…

1 Like

@mebrunet While there’s a small difference in Accept-Language, I think at this point we may fairly retire the hypothesis that the HTTP server configuration is to blame.

I can confirm @indraastra 's errors. Further, I am seeing errors stemming from Uint8Array being thrown from inside the Browserify shim for XHR (where it handles responses) as well!

I think, at this point, we are seeing a pervasive JS problem centered on the way different browsers handle Buffer() and Uint8Array. That’s why we’re seeing problems in RSA land, as well as the slightly less abstruse XHR land.

@javier_pelaez you need to:

  1. open http://23.253.54.117/setup in your browser of choice (note, I’ve only tested chrome to work)
  2. put your photon in listening mode
  3. you photon will now be publishing an open wifi hotspot, connect to it
  4. return to your browser and press the “scan” button
  5. select the wifi access point your would like to connect to
  6. enter your password and your photon will connect to the specified wifi network
1 Like

I have to disagree. I think it’s precisely a bug with the Photon’s (or Broadcom’s) HTTP sever that is causing this problem.

If the raw TCP communication stream contains the same essential information, differing only in the order of the headers, some capitalization… etc. Then it’s likely some obscure bug related either to those differences, or some other lower-level differences in the way the HTTP protocol is being executed/interpreted (e.g. TCP/IP headers). Keep in mind those TCP streams were raw network traffic… by the time Wireshark picks them up the browser isn’t changing anything about them anymore.

Additionally, other HTTP servers seem to have no problem extracting JSON POST data from both Safari and Chrome. So it’s quite hard not to point the finger at the Photon. Whether the issue lies with Particle’s firmware or Broadcom’s underlying WICKED SDK remains TBD.

(Note: I made sure “pwd” field passed by Safari in the above capture was able to get the Photon working with Chrome - so you can rule out an RSA issue in this case.)

@mebrunet: Aha, this is exactly why I asked the question. I should have nipped it in the bud yesterday to save you the probably migraine-inducing debug session of diffing these two TCP streams. If you still have the streams or can recreate them, look at the individual TCP packets and see if Safari sends two packets: one with the HTTP header only, and one with the request body. This is the issue I ran into with my react-native app and posted about here:

Basically, the requests are reconstructed by every debugging tool to be nearly identical apart from a few inconsequential headers because they ARE valid. The problem is that the HTTP server doesn't treat them the same at the packet level. Hopefully, that's what you're running into as well.

1 Like

It is good to know that the same PWD data worked in Chrome.

Consider the following discussion: https://github.com/spark/firmware/issues/635

At the end of the day, @mdma was not able to let us actually look at the server source due to licensing restrictions.

Which sort of throws a spanner in the works as far as debugging and ultimately solving the problem, if it is the server.

Edit: Nice find, @indraastra !!! Yes!

Caveat: it may not be exactly the same server source Particle is using but here is what it likely is:

https://github.com/asmcos/wiced-emw3165/blob/master/libraries/daemons/HTTP_server/http_server.c#L826

4 Likes

Bingo! Safari is posting the data with 2 TCP segments, Chrome is doing it with only one. Very good catch @indraastra!

I’m happy to email the raw packet capture files to anyone who wants to look them over further, just send me your email in a PM.

Note @msolters you can get a copy of the full WICKED SDK just by signing up as a developer with Broadcom.

The question becomes what do we do now? I’m not excited about the idea of waiting on Broadcom… @mdma Can we just reconfig the sever endpoints to be able to receive credentials via query parameters in a GET?

3 Likes

Sorry for duplicating this link but I have at least posted this as an issue in the firmware repository.

@mebrunet thanks for the info!

At the end of the day though, we need to see the WICED codebase being implemented in the firmware to be patched. We need to update the packet logic to accumulate data until it hits a CRLF line, and then to process that accumulated data.

2 Likes

Nice work people.

Thanks for this, your hard work tracking this down is so much appreciated. :+1: It really narrows down the search.

I’ve been unwell this week but as soon as I’m back I’ll look at fixing this. We are still waiting for a permissive license for WICED SDK 3.3.1 that might have already resolved this issue.

1 Like

I just checked the HTTP server daemon in WICED SDK 3.3.1 and it seems to suffer from the same problem of not really handling HTTP as a stream. Despite it being a blocker for us, I’m not sure it’d be a worthy investment on your part to fix their broken HTTP server. In the interim, supporting a GET version of the configure-ap and connect-ap HTTP calls like @mebrunet suggests is a really great idea.

1 Like

I have (started) an android app to control the color of a connected lamp for my family and i just wanted to tell you that the js-solution is also working great inside of a webview control inside the android app - with the HTML and .js files packed locally in the apps assets. that way you don’t even have to have internet access prior to connect to the photons AP.

i might change that approach to a native one later on - but i am new to android development and also i dont really know java - the app is created with xamarin in C#.

Anyways, this is really is an awesome community!

1 Like

Thanks for your answer. The photon works well, I have claimed it with my particle account and connected to a WiFi network with the Particle Android App, but not with the meteor page.
I have clear all the stored wifi credentials, put the device on listening mode, connected my laptop to the photon wireless network and to Internet by the Ethernet connection but the page does not find it.

The first time I connected it has automaticaly update the firmware (magenta light during some minutes).

It is neccesary to be claimed before trying?

Sorry, but I do not know what I am doing wrong and it seems it is a foolishness.

Thanks for your support

Thanks anthonywebb. In the step 4 it appears a pop up windows saying “There was a problem fetching important information from your device. Please verify your connection, then reload the page”

You will want to make sure that the photon is running the latest firmware. Install the particle CLI and run “particle update” from the command line, this will get you all up to date then the browser based config should work, we have been using it a lot (in chrome)

1 Like

I have put the device in dfu mode. Connected by USB cable and particle update says “update succesffully completed” but the light is still in yellow (no magenta) so I suppose the device is up to date.

After that it still happens the same. With the particle android app I do not have any problem.

When you are saying the latest firmware you are referring to the original firmware (Tinker), aren’t you?

Thanks

anthonywebb I have tried with another Photon (which has the same firmware version of the first one I tried) and it works perfectly.

Both have the 0.4.6

The main difference between the two Photon is the first one I tried was a virgin one it was claimed but it has Tinker software and the second one (the one which works) has my software running on it.

I have tried to install my software on the one which doesn’t work and now it also works.

So, may be this could be useful for others, it is neccesary to install a different software from the default one to use your web.

Congratulations for your contribution. Thank you very much,

May be you are having my same problem.