[v0.4.8-rc1 / v0.4.9] WiFi Reconnection Issue

Firmware
42

Not that I know of, I’ve just noticed it a few times recently.

43

@mdma: I picked through my code and removed chunks of functionality to see if I could pinpoint when my issue went away and I think I have found the piece of code that causes it, but I am not sure how to work around it.

So, in my application, I send about 6 UDP packets to a multicast address every second - I’ll not go into the finer details - but when sending the actual packet, I use this piece of code:

if(WiFi.ready()) {
  _udp.beginPacket(ip, port);
  size_t length = _udp.write(buffer, packetSize);
  if (length < 0) {
    errorCodeCount++;
  } else {
    correctPacketCount++;
  }
  _udp.endPacket();
}

If I remove this piece of code, I never see the issue I have described above.

I am going to try and write a simple replication now for you now.

1 Like
44

@mdma Ok - think I have both got a work around for this and replicated it within a single .cpp file.

In my code, I noticed that my UDP socket would return -26 (INVALID_SOCKET) after a reconnection. So I had been recycling the socket every time I reconnected.

I noticed if I started a 5 second timer after WiFi.ready() returns true, and use its completion to recycle my socket, I would not see the problem I have been seeing above and everything reconnects fine.

I have replicated this in a single application.cpp here:

It seems to take up to 10 reconnection attempts to cause it sometimes but I have seen it with as few as 3 or 4.

1 Like
45

How’s this working for you?

I’ve been running into the same issue with my UDP/CoAP client library getting INVALID_SOCKET errors often. After 10-48h it will start give errors at a higher rate, giving errors almost as soon as I re-open the socket.
Just finished rebuilding the entire thing to monitor errors more vigilantly and re-open the socket on errors similar to your above code. Fingers crossed it’s more stable.

46

The above code I have posted is replication of my error - I never reconnect after a few disconnects - if I was you I would put a delay in to rebuild your socket a few seconds after you detect a reconnection.

I’ve had that in for a few days now and its working well for me it seems.

47

@mdma Like a lot of other people I am trying to understand how to write an application that reliably works with Particle Cloud and can recover when wifi or internet connections are lost. The application I am building assumes that a Particle Cloud connection will be maintained (I also have a local operation mode that turns off wifi - because the wifi/cloud connection process was blocking) as there are facilities to monitor and control the device through a web application. I thought that when SYSTEM_THREAD(ENABLED) was implemented from firmware 0.4.6 this would stop the problems I was seeing of blocking of the application in loop due to connection issues.

If I understand your comment To have code run completely independently from the system, don't call any system APIs. I would like to be clear about the scope of what you have called system APIs. Reference Documentation Firmware - is this including all Cloud Functions, WiFi and System Calls?

Lastly, I am running my application with SYSTEM_MODE(SEMI_AUTOMATIC); I have done it this way because I sometimes might turn off wifi and run ‘disconnected/local’. I am correct in understanding that one Particle.connect() call and only one is required in setup() until and unless I have made a Particle.disconnect() call? If cloud or wifi connection is lost then the system will handle reconnection?