Ethernet fails connecting after a while: client.connect() problem [imported]

[agdl]

From @cmaglie on November 15, 2012 19:3

This is Issue 1068 moved from a Google Code project. Added by 2012-10-09T22:18:15.000Z by [email protected]. Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

What steps will reproduce the problem?

1. Opening frequently a Ethernet connection (Once a minute)
2. After a while, the wiznet is no longer able to open connection.

What is the expected output? What do you see instead? Running forever.

What version of the Arduino software are you using? On what operating system? Which Arduino board are you using? Arduino Mega2560, Ethernet shield. (Official Arduino), Arduino 1.0.1, Win7

Please provide any additional information below. It is hard to reproduce. Sometimes the cliet.connect() keeps returning a false after a few hours, Sometimes after a few days. I think (but i not sure) the problem occures more often if the WizNet is exposed to externel attempts to make a connection after opening ports on my router.

The problem and (possible) solution is discribes here:

http://forum.freetronics.com/viewtopic.php?t=176

I not sure if there is a relation to issue 1049.

Copied from original issue: arduino/Arduino#1068

[agdl]

From @CzechM8 on December 20, 2012 18:2

Shouldn't this be closed? It was fixed 9 months ago.

[agdl]

From @CzechM8 on January 4, 2013 17:48

Never mind, this is different issue - a race condition, state model, or maybe a firmware bug. However, the fix in the link given above has been incorporated in a previous Arduino release.

[agdl]

From @stevstrong on March 18, 2015 17:24

HI, I know, it is an old topic, but I have a very similar issue. I have a W5500 module connected to a custom ATmega128A board. I am using Arduino IDE version 1.6.1, the Ethernet lib adapted to W5500 (by merging the Wiznet lib to the native Arduino Ethernet lib). The merging only refers to the chip selection define and the addition of the new cpp and header files necessary for w5500.h. In my software I run a local web server (always accessible) and a client, which client is connecting each second minute to a web server (NIST time TCP server on the internet), get the data from it and then disconnecting from it. The problem is the client connection to this web server by calling "client.connect(...)". After a time, which randomly varies between couple of minutes and hours (although it occurs several times per day - up to 15 times), the client cannot connect anymore to the mentioned web server. In these cases the "client.connect(...)" function returns consequently always "0". This means that once the connection failed, it will continuously fail, cannot recover anymore. In my software I check if the connection fails for 20 consecutive times, and then a Watchdog reset is activated. In addition, the Ethernet SW initialization routine sets an IO pin to HW reset the W5500 chip as well before "Ethernet.begin(...)" and "client.connect(...)", so that the W5500 chip is HW reset for sure before the software starts initializing it. After reboot, the client connection works again. It works also then, when 10 seconds before was not yet working, so I can exclude NIST web server availability problem.

I checked the Ethernet sources, specially EthernetClient.cpp, and saw that a return value of "0" is given when no sockets are available. But how can this happen? In the SW I always stop the client after finishing data reception and I therefore expect that the socket will be also closed.

Any hints how can I locate the root cause?

[agdl]

From @ferobred on April 20, 2015 10:49

Hi, I have the same problem as @stevstrong In every connection with the server I close the connection with "client.stop()", But only works when I Restart the ethernet shield, not the next times. It works with Ethernet.begin(mac,ip....) before client.connect(server,port) every connection. I think it works because the begin function restarts all sockets, but i don´t know why the client.stop() don´t close that sockets.

cc @jecrespo

[agdl]

From @stevstrong on July 9, 2015 14:33

It seems that I could solve the problem with the following approach:

ctime = millis() + TIMEOUT_REPLY;  // time within to get reply
while ( client.connected() )
{
    if ( millis()>ctime )   // if no answer received within the prescribed time
        break;
    while ( client.available() )
        Time_ParseTCPData( client.read() );
}
client.stop();

I think that the constructs while ( client.connected() ) and while( client.availble() ) did the trick. Hope that it helps others as well.