Hello,
I want to understand the behavior of WiFi in the following scenario.
I have configured P1 with two valid WiFi network configurations stored, say network1 and network2. At the time of storing WiFi configurations, network1 and network2 are good i.e. P1 can connect to internet on either network.
After a while the network behaviour changed as follows,
On network1, P1 can connect to WiFi but can't connect to internet.
On network2, P1 can connect to WiFi and internet.
Whenever a device can't connect to internet, I see the following log messages on the particle console
unable to resolve IP for device.spark.io
Cloud socket connection failed: -1
Internet Test Failed!
Resetting WLAN due to 2 failed connect attempts
Handling cloud error: 2
Resetting WLAN due to SPARK_WLAN_RESET
I believe this calls WiFi.off() and WiFi.on(). The P1 can store 5 WiFi configurations. Since I have 2 WiFi configurations, the P1 will attempts to connect Network1 and then if it fails it should try Network2.
Is this retrying mechanism true if P1 is able to connect to WiFi on Network1 but not to the internet? When WLAN is reset due to failed internet test, does Particle again try network1 or does it try connecting to the next saved network credentials?
Based on observations on some particle devices, they end up in a state where they are connected to WiFi but not to the particle cloud(flashing cyan)
Running from source (advanced)
To grab the CLI source and play with it locally
git clone git@github.com:spark/particle-cli.git
cd particle-cli
npm install
node bin/particle help
Hi @bko,
I don't believe that it's a key corruption issue because restarting the device fixes the problem. Yes, this has been provisioned to the cloud long back. This behaviour can be easily reproducible. My test behaviour is as follows:
Launch a hotspot on my phone and connect particle P1 to it
After the particle is connected to mobile phone hotspot, turn data off. This will keep the WiFi on and internet off. After about after 20 seconds particle starts to blink cyan. At this point of time if I enable and disable data before WLAN gets reset, I end up in one of the following states I mentioned.
Either particle keeps retrying to connect forever in blinking cyan or particle stops retrying with the message
0000405279 [system] INFO: Cloud socket connected
Could you also clarify about the WiFi retrying mechanism?
I doubt that the device will switch WiFi network once it has found the WiFi access is possible - irrespective of internet availability
But this would be a good use-case for this issue
But for the reason why your connection fails check your firewall settings. (I don’t think it’s a keys issue when it can connect via alternative networks)
This part of the most recent log, which is repeated many times, shows that:
You can resolve the DNS name of cloud and get an address. Good, the internet is connected.
You can open a socket to the cloud. Good, you can reach the cloud.
You can announce your presence and receive the 40-bit nonce from the cloud. Still good.
You somehow cannot encrypt the nonce+deviceID with the cloud's public key and return it.
According to this log, you are connecting over TCP here, you just cannot get the cloud connection all the way up.
As to why you cannot encrypt the nonce+deviceID, there could be many reasons. The cloud public key could be wrong on the device, the deviceID could be wrong on the device, the encrypted message (which should 256 bytes) is the wrong length from the device, the decrypted message on the cloud server has the wrong deviceID or nonce, the cloud does not have a public key for your device, etc. That is why I asked about provisioning and keys.
Yes the network definitely has internet problems I agree. Working on it to get the connection fixed. I was able to emulate this by connecting P1 to mobile hotspot and turning data on and off. Also, I am not able to disconnect/reconnect WiFi or turn off WiFi module when P1 is stuck in blinking green state. So the only way to get out of this situation looks like particle reboot.
How to make sure that my provisioning keys aren’t corrupted? Also this happens at random times after restart. I was able to reproduce this by disabling/enabling internet to the AP.
So, it sounds like you’re inducing a scenario where the network is valid, but the internet connection is lost, but you’ve found that resetting the device fixes the issue. If you’re managing your device in another system_mode other than AUTOMATIC, you might need to recreate some of the automatic recovery modes into your firmware.
In particular I recommend measuring the time your device has spent offline, and if it exceeds some value (lets say, 5 minutes, or 15 minutes), it performs a full restart of the device. This can help you recover from any kind of stuck issue that your firmware has landed in while running in something other than automatic mode, etc.
Also, if your device has an additional bluetooth radio, it’s possible your firmware is generating harmful bluetooth interference during the wifi reconnection, if say, your firmware transmits over bluetooth while the WiFi module is attempting to connect, etc.