30 sec delay when closing socket on W5100

TCP/IP Chip W5100
1

Hi! I’m having an issue interfacing to the W5100. I have had W5500 support working great for years, and I had assumed that W5100 would work just by compiling against the W5100 drivers.

The W5100 does seem to work, however when closing a socket the close command hangs for 30 seconds - everything else works.

Here’s the code I’m using:

  // try and close gracefully
  disconnect((uint8_t)sckt);
  uint8_t status;
  while ((status=getSn_SR((uint8_t)sckt)) != SOCK_CLOSED &&
         waiting_for_less_than_one_second) ;
  // if that didn't work, force it
  if (status != SOCK_CLOSED)
    closesocket((uint8_t)sckt);

So very similar to other WIZnet examples as far as I can tell, and it works fine on the W5500.

When working as a server, this code works great and handles sockets without delay. It’s only when acting as a client that there is the problem.

Is there a flag or something I’m not setting up properly? Full code is here:

initialisation: Espruino/jswrap_wiznet.c at master · espruino/Espruino · GitHub
socket: Espruino/network_wiznet.c at master · espruino/Espruino · GitHub

Thanks!

2

There must be delay anyway as code you have assumes exchange between two network devices. In case of W5500 it seems delay is subtle for you to notice.

Several things to mention -

  1. 30 seconds sounds like disconnect finishes with timeout. I recommend you resetting Sn_IR bits before performing disconnect and check them after disconnect to see if TIMEOUT bit got set. Further, you must check if you set timeout value properly. While default value for both W5500 and W5100 is the same, and I do not see you setting the value in the code, actual value is worth checking;
  2. Check the related RFC documents, I suspect they may say that client must respond to the server’s FIN packet with FIN packet, but server is not obliged to do it. Thus it may simply that server does not respond, and disconnect terminates with timeout. You can only know it looking into Wireshark logs. I think my code, for the client part, just performs DISCON if in connected state, and then immediately closes the socket. In any case if server will respond with FIN later, it will get RST packet from W5x00.
3

Thanks - yes, it does sound like a timeout. I’ll check those registers. If I set the timeout value to something lower than 30 seconds, I guess that will affect other aspects of the connection?

I’m still unsure why the W5500 and W5100 would behave so differently though?

4

No idea… the best is to compare network activity from and to each of the chips. May happen that W5500 sets PSH flag on the FIN packet.

Not sure if you need timeout at all if you communicate to non-embeded device (e.g. Windows or Linux) when socket hung for several tens of seconds is not an issue for remote network stack. Howeher if you work with another embedded devices it would be good to have FIN processed properly.

Are you able to test both chips and get the dump of the packet exchange?