client.connect() causing watchdog to timeout once every 80 times

I am using the Ethernet library and posting to web every 10 seconds. The unit works fine, but every 11 or 12 minutes, it will reset.

I have a watchdog set at 8 seconds. It is timing out at the client.connect(server,80); call.

The strange thing is that is only does this after so many calls. Roughly 80 calls. I have freeMem running, and it is consistenly ~583 free. There doesn't seem to be a leak.

If I reduce the number of calls, the number of resets reduces with it. The number of posts is not exactly the same, but it is pretty close.

What can I do here?

Is it a server under your control? If it is, check the server logs. If not, it may be limiting the number of times you can connect during a specific time period.

edit: Is the server variable an IP address or a domain name?

The server is under a domain name. It is through DigitalOcean, so as far as I know there is no limit.

Once the unit resets, it works again within seconds of the reset.

You should post your code.

If you are not evaluating the return value of client.connect(), that could cause a problem. The correct evaluation is:

if(client.connect(server,80) == 1) {
   // send your request here

Thanks! I'll give that a shot.

If that doesn’t help, you should post your code. There may be something else there causing the hang.

It is still resetting.

Here is the code that I am using to post the data:

void postData(String inputData, String filename) {
  Serial.println("Posting Data.");
  if (client.connect(server, 80) == 1) {
        // Make a HTTP request:
        client.println("POST /telemetry/dev8/" + filename + ".php HTTP/1.1");
        client.println("Content-Type: application/x-www-form-urlencoded");
        client.print("Content-Length: "); 
        Serial.print("Data Length: ");
        client.println("Connection: close");
        Serial.print("Post DATA mem:"); // debug
      unsigned long startMillis = millis();
      unsigned long endMillis = startMillis + timeout;
      while(client.connected() && (millis() < endMillis)) {
        while(client.available()) {
          char ch =;
      // if the server's disconnected, stop the client:
   } // close if client
   else {
        // if you didn't get a connection to the server:
        Serial.println("connection failed");
        String resetString = "unit=" + unitName + "&process=reset";
        postData(resetString, "startreport");
   int memory = freeMemory();
   if (memory < 175) {

The serial will print “Posting Data” and then post “Started” which happens when the program restarts (first command in setup).

It appears the client.connect() function is failing. I do not like the String data type. It has caused me grief in the past, so I use character arrays. That could be part of the problem.

Ok. I'll give that a shot.

I have client code in the playground. You might give it a try if you are still having problems. I have tested it thoroughly for days and it doesn't lock up.

edit: It has never needed the wdt. Tested it by breaking the connection, causing the server to stall, returning corrupt and incomplete responses, etc.

edit2: I have server code in the playground also, and it has never needed the wdt. I'm running it on the internet right now, and somebody is trying to crash it by sending incomplete requests, bad page requests, connecting and not sending anything, sending bad/illegal characters in the request, and more, but it is still running without losing a single socket.

If you would like to try to crash it, here is the link to it. I run it daytime only (US central time). My Arduino server

I'll try to change the String first, then I'll work through the playground.

The reason I'm using the wdt is because it is a remote project and it is outside. Hopefully it will work for years.

Wdt shouldn't cause a problem for Ethernet, should it?

The wdt shouldn't cause a problem, but the way your code handles a server stall or broken connection may cause the client code you are using to lock up. That would be enough to cause the wdt software to time out and reboot the Arduino. My client code has all the error checking and fault tolerance I could think of to prevent a lockup. You can set the wdt for a longer period of time to catch any fails that happen, like longer than 30 seconds for my code.