[En-Nut-Discussion] Ethernut as TCP Client stops trying to connect after a while.

Erik Lindstein erik at ledutveckling.com
Mon Mar 10 09:38:11 CET 2008


Hi.
I use
Hw: Ethernut 2  ( 5 units with identical software excpent from MAC and
IP-adress settings. )
Sw: ethernut-4.4.0 / avr-gcc (GCC) 3.4.6

I have a tcp socket client thread running on my board and it connects
to a PC on a LAN and sends some xml-data to the PC then gets a text
string back with a command in it.
This thread normaly runns with a sleeptime of 300ms but when it can't
connect to the PC it sleeps 3000ms.

This workes fine when the PC is on ( The server software dossnt need
to be on, just that the PC is on and the network cable is connected to
the LAN )
If i start my server software the client starts exchanges data
correcty and it can run for weeks without any problems.

But if i close down the server software and power down the PC so that
there is nothing that responds to the Ethernut connection attempts the
TCP communications just stops working after a while.
I havent been able to replicate the problem by just having the PC of
for 1-2 hours but always when i leave it over night i will at least
get a couple of clients stop trying to connect to the PC when i start
it up again and starts the server software.

If i look at the ethernet interface with Wireshark i don´t se any
connection attempts at all from the clients that dropped off.
I can always still ping the units that dossnt make any connection
attepmts so the TCPsm are still alive in some way.

I write NutHeapAvailible() on the LCD and i have about 21023-bytes
memory left on the devices when this happens.
I also write out the number of sockets in *tcpSocketList and i can se
that there is 1 socket in there.
When the system is working and the PC is of i see that the socket
numbers are pending from 0 to 1.
But when the problem occurs its fixed to be 1 socket there.

Also the other threads i have in the software seems to work ok ( i
have an LCD with some info-text on and that workes fine )

This is a major problem for me because the customer is suposed to be
able to leave the units on and the PC of or not connected.

Anyone have any hits to what the problem can be?
If there was some arp problem on the client woudnt the unit start
again when i ping it from the PC server?

Below is my tcp-client thread code:

---------------------------------------------
#define TCP_TIMEOUT 300
#define TCP_CLIENT_CONNECTION_RATE 300
#define TCP_CLIENT_NO_CONNECTION_TIMEOUT 3000
#define TCP_SERVER_CLOSED_DOWN_SERVICE_TIMEOUT 10000
#define MAX_CONNECTION_RETRY 5

THREAD(InetdThread, arg)
{
	TCPSOCKET *socket;
	FILE *stream = 0;
	u_long rip = inet_addr(TCPSERVERADDR);
	u_long tmo = TCP_TIMEOUT;
	int socket_error = 0;
	uint16_t data_exchange_timeout = 0;
	uint8_t *start = 0, *stop = 0;
	uint8_t unit[20], cmd[40], value[40];
	uint8_t data_exchange_buffer[100] = "0";
	uint8_t no_connection_count = 0;

	for(;;)
	{
		data_exchange_timeout = TCP_CLIENT_NO_CONNECTION_TIMEOUT;
		if(internal_status & (1UL<<SB_REMOTE_ACTIVE))
		{
			if(internal_status & (1UL<<SB_TCPCLIENT_ENABLED))
			{
				data_exchange_timeout = TCP_CLIENT_NO_CONNECTION_TIMEOUT;
				if ((socket = NutTcpCreateSocket()) != 0)
				{
					NutTcpSetSockOpt(socket, SO_RCVTIMEO, &tmo, sizeof(tmo));
					NutTcpSetSockOpt(socket, SO_SNDTIMEO, &tmo, sizeof(tmo));
					if(NutTcpConnect(socket, rip, TCPSERVERPORT) == 0)
					{
						stream = _fdopen((int) ((uptr_t) socket), "r+b");
						if(stream != 0)
						{
                                                   // CODE TO SEND XML
AND RECIEVE STRING.
						}
						no_connection_count = 0;
					}
					else
					{
						if(no_connection_count++ > MAX_CONNECTION_RETRY)
						{
							data_exchange_timeout = TCP_CLIENT_NO_CONNECTION_TIMEOUT;
							no_connection_count = 0;
						}
						socket_error = NutTcpError(socket);
						sprintf(info_text ,"Conn error:%d\nCount:%d", socket_error,
no_connection_count);
					}
				}
				fclose(stream);
				NutTcpCloseSocket(socket);
			}
		}
		NutSleep(data_exchange_timeout);
	}
}

-----------



More information about the En-Nut-Discussion mailing list