Intranet only - WiFi disconnects - how to stop?


#1

This note is related to: WiFi channel switching stops WiFi connectivity and is only recoverable by reboot (BUG), [SOLVED] TCPCLIENT intranet connection fails if no cloud connection and others tickets.

Situation is Photon connected on a WLAN which does NOT have connection to the cloud, ie Photon is flashing cyan.

The Photon is disconnecting from the WiFi at a regular intervals of say 15 seconds. Here is output from the trace log:

0004264763 [system] ERROR: Cloud: unable to resolve IP for device.spark.io
0004264763 [system] WARN: Cloud socket connection failed: -1
0004269767 [system] WARN: Internet Test Failed!
0004269767 [system] WARN: Resetting WLAN due to 2 failed connect attempts
0004269767 [system] WARN: Handling cloud error: 2
0004269869 [system] WARN: Resetting WLAN due to SPARK_WLAN_RESET
0004269869 [app] WARN: WiFi disconnected!
0004272639 [app] INFO: WiFi connected

Question is: is there a way to stop the WLAN reset from occurring?


#2

If you have no contact to the cloud you need to run a non-AUTOMATIC SYSTEM_MODE and not try to Particle.connect() but only WiFi.connect() - after switching the WiFi module on via WiFi.on().


#3

Yes! I want a solution for this as well. I use the photon with a local server. If there’s no Internet, it should still work with the local server and not keep resetting its WiFi.


#4

This is not really a solution. A cloud connection is nice to have for some purposes if available. Resetting WiFi continuously messes up the tcpserver.

This too simple fix breaks local network use cases.


#5

I’d dare to contradict. That’s a solution, you just have to lay out the rest of your project right.
My original statement states a prerequisite and is not a fix in its own righ and it doesnot break local network use cases by itself either.

You check for internet connection (or loss thereof) and act accordingly before the “safety net” hits.
When you look at the log timestamps you get a feeling about the time you’ve got to take matters in your own hand before the system jumps in.

BTW, the OP has stated his network has NO internet connection, so for his demand that also is the solution, I’d think.


#6

@ScruffR,

Am running in SEMI_AUTOMATIC_MODE, but I am calling Particle.connect() within setup() and in loop() as part of the @rickkas7 strategy described within my ticket:

I had added Particle.connect(); to this block (not realising the WiFi disconnect side effect until your comments above).

case WIFI_STATE_CONNECTED:
        // Do any one-time initialization here like calling udp.begin() or tcpServer.begin()
        Log.info("WiFi connected");

       // Also connect to the Particle cloud   
       Particle.connect();             // <=== I added this....

       wifiState = WIFI_STATE_RUNNING;
      break;

So, a solution is, as you said, don’t call Particle.connect() for this use case. Too easy!

That said, @Elco’s point regarding “great to have Particle cloud when it is there” is also a very good point, so it would be nice to solve that problem.

@Elco, wondering if this sorts out your request: pinging some external IP and only if you get a successful return, call Particle.connect()? Something like this:

if (!Particle.connected())
{
       int rc = WiFi.ping(IpAddress(8,8,8,8));
       if (rc > 0) 
               Particle.connect();
}

#7

@UMD, your ping approach would have been the way on my mind too.
You just also need to monitor the cloud connection and issue a Particle.disconnect() as soon you see a “persistent” loss of connection to prevent the system from trying to reestablish the desired (connected) state over and over eventually running into the failsafe which assumes the WiFi module must have some issue and resetting it to cure this “non-issue” (which the system doesn’t really know is not the cause).


Update:
I just read up on that “old” thread and as it turns out @rickkas7’s solution from back then silently accepts the fact that consistently failing cloud-connection attempts will eventually also reset the WiFi module. But since his client/server combo seems to not rely on persistent connections that’s fine for that use case.
But if you require a persistent connection or have any other reason to avoid a WiFi disconnect at all cost, extra work will be needed.

BTW, since actual WiFi outages have to be considered inevitable, explicit, graceful management of these situations may also need some thought. Just as with the cloud connection silently accepting the loss of WiFi connection is possible since the system does have some “brute force” failsafe in place, but then you may need to put up with the side effects of that too.


#8

@ScruffR,

Funny thing is that the reason for the ticket was because of UDP listener issues I was having (going away and not coming back). Research revealed another @rickkas7 gem:

The reason is that when WiFi disconnects, all of the listeners are removed

So, this underlying problem has been solved.

Am going to mark this ticket as solved because you have ably answered the “how to stop” question. Agree, further work could be done.

All good.


#9

Sorry, that could indeed be a solution for his issue.
My point should be that the solution Particle chose “reset the entire WiFi stack if there is no cloud connection” will make the device go haywire when the LAN loses Internet. What I’d like to have is a solution that connects to the Particle cloud if possible but doesn’t go haywire if it can’t.

Wow, this might explain my problems with the TCP server. My system can go into a state where the TCP server is not accepting new connections. I have set it up to listen for new connections and drop the existing connection on a new connect. But I see a problem with the connection being refused or time out after a while, even though the device still responds to ping. Perhaps the WiFi reset is related.


#10

Would it be possible to handle wifi disconnects with system event hooks?
Letting the particle system thread handle it in the background doesn’t seem to work.

With an event hook I could:

  • Completely destroy the TCP server and clients and recreate them when wifi comes back
  • Possibly prevent the system thread from blocking the whole system. (Why is this even the case, damn).

Some more info here: WiFi channel switching stops WiFi connectivity and is only recoverable by reboot (BUG)


#11

I have spent my entire weekend debugging Particle WiFi again. This shouldn’t be my job Particle, it should be yours. Please take over.

Here is a bug report that contains my test code, which prints out a lot of helpful system state to debug WiFi issues. It is also my best effort yet to maintain a TCP in bad conditions.

And here is a new issue for the topic of this thread:

I am trying to build a demo application that:

  • Communicates over TCP without the Particle cloud
  • Doesn’t crash when WiFi goes down temporarily
  • Reconnects when WiFi is back up
  • Doesn’t stop working when there is no cloud connection
  • Can use a cloud connection when it is available.
  • Doesn’t block the application loop under any circumstances

Direct link to the code:

If others want to join me in my battle, I can split off the code from the BrewPi repo into its own repository so it is easier to fork. The current version works fine on Intranet only, but as soon as a Particle.connect() call is added, the system will keep resetting WiFi until the cloud is back (issue #1491 above)


#12

@elco,

Have you tried firmware 0.8.0.rc.2 as yet?

The following improvements may be of assistance:

  • TCPClient: non-blocking, blocking, blocking with timeout writes support #14854
  • WiFi.dnsServerIP()/WiFi.dhcpServerIP() support #1386
  • Increase maximum supported number of simultaneously active TCP connections #13502

I would like to investigate your strategy and see what it brings, but can’t get to it for a few days unfortunately.

It is in everyone’s interest to get WiFi connectivity as reliable as it can be!!

Cheers - @UMD


#13

Yes, I have. It seems to have many of the same issues still and will disconnect from WiFi if it loses its cloud connection.