next topic »

[Reply #15 on:]

I have applied the patches by etracer and used the example code by NJPaul, nothing has changed. I still get the same SYN, RST in wireshark session logs.

SYN and RST are not bad things.  The SYN is the initial state to start the TCP session. If the server is issuing you a RST then you're likely trying to connect to a non-existent service or you're firewalled, etc.

The patches have nothing to do with the ability to connect as that wasn't broken. It's the ability to open repeated connections that was the issue.

I think you have another configuration issue.

[Reply #16 on:]

When anyone is looking into this issue, have they gone back to the original datasheets to see what's "supposed" to happen according to WIZNet?

I seem to recall the datasheets had some state flow diagrams in them.

There's also this: http://www.wizwiki.net/tc/regina/entry/W5100-Hardware-Design-Guide-2-MCU-Porting

--Phil.

[Reply #17 on:]

Just a quick note that I think I've found the root cause of the incomplete disconnects that result in subsequent failed connects.

The client.stop() function is improperly terminating the connection. I'll post more here later after I finalize testing.

[Reply #18 on:]

I've posted a completely revised Client portion of the Ethernet library. It includes many fixes and seems to resolve any connection issues or situations where a connection fails to completely close.

See here: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1238640832/0#0

[Reply #19 on:]

Looks good. I will use it and let you know how it goes, and if I come up with any more fixes. I was thinking of putting in some functions to make it easy to do UDP as well.

[Reply #20 on:]

I'm using the shield to log remote temperatures, pressures and humidity, UDP would be marvelous for logging.

[Reply #21 on:]

etracer,

I'm using arduino 17
do you know if any of these fixes are included in ver17?

I'd hate replace it with an older fix
Thanks
Jeff

[Reply #22 on:]

Yes, all of the client fixes I submitted are included in Arduino 0017.

[Reply #23 on:]

Thanks
I've been doing so much reading about these problems it was starting to get hard to tell if it applied to 17 or not.

I am trying to send a very small amount of info to a php script on my webserver once every second and i am getting some intermittent failures

can you post a simple example that uses the libraries that are built into arduino 17 that will send an HTTP GET once per second?

I'm just trying to see what kinds of defensive coding you are using to deal with these problems

Thanks in advance
Jeff

[Reply #24 on:]

etracer,

Below is what i came up with for a simple example that displays the problem
when the connection is made the elapsed time is always roughly 120ms

when it fails it is always about 32180ms

so there is some sort of time out built into the connect function. i don't know enough about C to figure this all out. all i can do is give sample code to help point smarter guys in the right direction.

let me know your thoughts on this when you have a chance to look at it
Thanks
Jeff

Code:

#include <Ethernet.h>

byte mac[] = {
  0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = {
  192, 168, 0, 54 };
byte subnet[] = {
  255, 255, 255, 0 };
byte gateway[] = {
  192, 168, 0, 1 };
byte server[] = {
  74, 86, 153, 136 }; // btbsw

Client client(server, 80);

int failures = 0;
unsigned long time;

void setup()
{
  Ethernet.begin(mac, ip, gateway, subnet);
  Serial.begin(9600);
  Serial.println("Connecting...");
  delay(1000);
}

void loop()
{
  Serial.println("001-Connect");
  time = millis();
  if (client.connect()) {
    Serial.println("002-Waiting to be connected...");
    Serial.print("Elapsed time(ms) = ");
    Serial.println(millis()-time, DEC);
    while (!client.connected()) delay(50);    // wait for byte
    Serial.println("003-Connection established");
    Serial.println("004-Sending GET request");
    client.println("GET /~latenigh/test.php HTTP/1.0");
    client.println();
    Serial.println("005-Waiting for response...");
    while (client.available() == 0) delay(50);    // wait for byte
    Serial.println("006-Received something");
    Serial.println("<Begin Response>");
    while (client.available() != 0) Serial.print((char)client.read());
    Serial.println();
    Serial.println("<End Response>");
    Serial.println("007-Finished getting response");
    Serial.println("008-Issue client.stop");
    client.stop();
    Serial.println("009-Waiting for status = zero...");
    while(client.status() != 0) delay(50);
    Serial.println("010-Status went to zero");
    Serial.println();
    Serial.println();
  }
  else {
    Serial.println("Connection failed");
    Serial.print("Elapsed time(ms) = ");
    Serial.println(millis()-time, DEC);
    Serial.print(++failures, DEC);
    Serial.println(" failures to connect since start");
    Serial.println();
  }
  delay(1000);
}

[Reply #25 on:]

Sorry, but I haven't done any Arduino development for over 6 months now.  I don't even have any boards hooked up at the moment to test any code.

You might try the sample sketch I posted here:

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1238640832

It was designed to do quick connections to demonstrate the problems in the client code and subsequent fixes.

A quick glance at your code indicates nothing that terribly incorrect.  In a real-world application you need to be more careful how you read the response from the webserver.  It's unreasonable to expect an "immediate" response after your "GET" request.  Additionally the only correct way to determine the end of the response is to parse the HTTP and look for the "content-length" header to determine the expected data.  Simply looping until the buffer is empty is guaranteed to not be successful because it assumes the webserver always returns the data in one contiguous chunk with no delays (this doesn't happen except in controlled situations).

The roughly 30 second delay on the connect failures is being caused by the TCP/IP stack on the WizNet chip - not the Arudino library.  It's also absolutely normal.  This is the SYN timeout on the connection request.  So the problem is not your connection code, but why the server is refusing (or ignoring) your connection attempt.  Connection failures to webservers are a reality and you have to code around it.  Maybe the server is too busy.  Maybe it doesn't like how you might be prematurely closing the connection (by not processing all of the data in the response), etc.  So ultimately you need to examine why the connection failures are occurring and that's going to take examination of the webserver logs, possible TCP/IP packed analysis, etc.

Or you can just accept that it's unreasonable to expect 100% of your connections to succeed and write code that can tolerate the occasional failure.