Using Soft AP example - can't connect to HTTP

There’s a few WiFi networks around and I’ve got a ZigBee mesh, but none of the other devices in the house have any issues. I have several photons that operate lighting in the house and work perfectly day in/day out.

The thing that’s baffled me so far is that the errors/issues haven’t been entirely random, although plentiful. e.g. I’ve had it so it works in chrome but not in FF on the same machine. The thing where it works when accessed directly but not via xmlhttp was consistent until just now.

I will however try all this again in a remote location with no other 2.4GHz interference just out of interest.

I’ve got some interesting results from Wireshark but unfortunately, my knowledge only extends to HTTP protocol I’m not as familiar with the underlying TCP layers. Can anyone else shed any light on this…

#Working

#Not Working

I suggest you try 0.7.0-rc.6, as there have been a number of bugfixes/enhancements introduced to SoftAP/HTTP server implementation in 0.7.x versions: https://github.com/particle-iot/firmware/pull/1362

Your wireshark logs look quiet similar to what I was seeing when the web browser was bombarding Photon with several concurrent HTTP requests and it couldn’t handle that properly.

1 Like

After speaking to another dev we came up with a possible cause, but not checked the docs to see if there’s anything about it. A possible security measure could be causing this behaviour.

How about if once a request has been made to /public-key all subsequent requests to the API (but no the user firmware generated pages) must have the same IP, MAC and User/Agent.

That would mean that once one device has started the connection/claiming process, no other device could take over/confuse the process.

It would also explain perfectly why it fails to work on different devices, but in isolation works perfectly on a given device. It would also explain the scenario where it works if you manually open /public-key but not via xmlhttp request in the same browser. I think the user/agent string would be different (from memory).

I’m going to put this to the test, but it’s gone midnight here, so it will have to wait until tomorrow.

Today’s update… not even sure if that’s the case or not as I now can’t connect to either photon full stop. AP works, ping works, but no HTTP.

Just to go back to basics, I’ve taken my laptop and a photon to my parent’s house with one existing WiFi AP and no neighbours, made no difference.

Updating the firmware to the latest RC next.

Hey there @Nemiah – I’d like to make sure you get support from our internal firmware team if you believe there may be a bug that exists within Particle’s system firmware.

Can you provide us with the most up-to-date instructions for replicating the issue and I will make sure we get a GitHub issue created in order to track the investigation and resolution of the problem?

2 Likes

Thanks @will TBH at this point I couldn’t even tell you how to consistently recreate the error as it keeps changing.

I’ve ordered 2 new Photons from a UK reseller, I will flash them with the latest firmware and the soft-ap demo. Take them to a location with few 2.4GHz networks and run some tests.

The only thing I can say for certain so far is that the 2 photons I have will not respond to HTTP requests intermittently around 50% of the time. There is no logic to when this happens so far. Tested with Chrome & FF on Win10 laptop and Chrome on Android 8 on a Pixel 2.

After more tests on the new Photons, I’ll post my results.

1 Like

@Nemiah, if you are running with SYSTEM_THREAD(ENABLED), do you consider the fact that the user thread will run while in listening mode (ie SoftAP is running)? As in WiFi/Cloud is not available to the user thread.

1 Like

I’m just using the example code from the git repo, SYSTEM_THREAD has not been set, so it will be in its default state (don’t know what that is from memory). loop() is just blinking an LED anyway in this example.

So the new photons have arrived today. As a control, I have taken it out of the packet, powered up using an OEM Sony USB charger and attempted to configure using the Particle Android app. It connects to the Photon’s AP, but cant’ configure the device.

I manually tried to get http://192.168.0.1/public-key and this also timed out.

I’ve tried several times, after resetting and it’s still the same. Thinking back to pairing other Photons and Cores in the past I’ve always found the process to be somewhat unreliable but I always put this down to the firmware etc not being 100% stable and things like when there were different apps for core/photon etc. I just assumed there were bugs.

I’m going to try the same test in a different location as the answer is either the environment is causing the issue or the device is buggy/faulty.

But either way, it still brings me back to the original issue, which is I wouldn’t expect a consumer to have to go to all this trouble. Let’s just say it is the environment, my question(and the consumer’s) would be why do all my other WiFi/ZigBee/Bluetooth devices work fine?

I’ll report back when I have more information.

I’ve just done a quick video on the off chance I’m missing something really obvious here. I know the video only shows one attempt, with one device but I didn’t want to bore everyone to death!

So far I have tried both Photons, with a Pixel 2 and a Windows Laptop and tried various different methods of configuring WiFi (without connecting via serial). None have worked. I’ve tied powering via a good quality USB power supply and via USB port.

PS: I do have an ESD protected workbench but I had to film this at my PC’s desk

1 Like

This video is quite good to rule out other things but unfortunately this leaves us (at least me) at the stage where we start stabbing in the dark :blush:

Could it be that your phone is running some app in the background that prevents switching WiFi networks?

I know what you mean, but I just wanted to make sure that I’m not missing something really basic. All previous tests and info above still apply. Assuming there aren’t multiple bugs you can rule out the app not working because I get the same results if I manually connect a laptop or phone to the Photon’s AP and then try and request the public key.

We can rule out the Photon being at fault as I now have 4 that behave in the same way, 2 being brand new.

We can rule out the environment as I get the same results in places that have much less 2.4GHz traffic.

My plan is to put together a spreadsheet of tests and see if any patterns emerge when changing Photon/Firmware/Device used to configure/Location/Power supply.

I’m also thinking of taking them down to my local hackspace and letting different people have a go at setting them up with the default tinker app and flashing an LED, just to see if they fare any better. (I’ll do this one at a time of course!)

1 Like

Here’s the testing that I’ll be doing, I’ll update as I go. If anyone can think of anything else to add, let me know!

@Nemiah, have you tested with the web setup?

I hadn’t seen this before. Funnily enough, it’s exactly how I was going to write my own setup script once I got it working.

It’s still based on the same principle as the other setup methods though, it just polls http://192.168.0.1/device-id via JS xmlhttp but I will add it for the sake of completeness.

@Nemiah, let us know how your tests go with the web setup. Yes it does poll the same way but the application doing so is different. :wink:

This rang a bell with me when I first read it as something I should go and check as I'm sure I had read it was safe. @jvanier & @mdma have previously stated that System.set will check the existing value first and then only change it if it is different, of course things might have changed since 2015...

@Nemiah, am wondering if you were able to sort out this problem?

I too am suffering with similar issues with SoftAP (using P1, DeviceOS 1.4.0).

With the device in listening mode

  • My laptop is reliably provided with an IP address (192.168.0.2) by the device (good)
  • Am able to ping the device (192.168.0.1) (good)
  • Browsing the device responds with “Connection Refused” (bad)
  • curl also return “Connection Refused” (bad)
  • debug reveals that “myPage()” is not called
  • softap_set_application_page_handler(myPage, nullptr) is called within STARTUP()
  • myPage is correctly forward declared
  • I note for the record that ping sometimes does not work… seems random…

I have had SoftAP working sometime in the past, but have had to define it out of recent times because of the 20K+ text overhead.

Am resurrecting its inclusion by setting refactoring myPage() to retrieve the static text from file instead. Am pretty sure that this code change is not the issue because of the debug - ** myPage() is simply not being called ** (as port 80 is not open).

Any thoughts? I note that there has been a lot of noise on the topic of SoftAP…

UPDATE: I was able to get reliable ping AND connection to the HTTP service on port 80 with the device.

How?

I put the device into SAFE MODE then into LISTEN MODE… I believe this to be the default SoftAP mode of operation and not my code, because there was no head or body content, just the the HTML tags.

Happy to report that I was able to sort this issue.

  • Extensive testing revealed that SoftAP requires circa 10K of free memory
  • I optimised memory usage, but still did not have enough for SoftAP usage
  • Resolved by workaround - some classes required large amounts of memory which was allocated to the BSS segment. Changed some of these classes to use heap memory for the large structures ( ie used malloc() ).
  • The trick was to not call the class .begin() method when in Listening Mode, hence memory would not be allocated to the class

Downsides are:

  • one needs to enter Listening Mode soon after reset, before loop() kicks off
  • you need to reset after using SofftAP to configure your WiFi

Case closed.

1 Like