I've been using UDP for some time now.

Attempting to use TCP with this stack.

In another post, I had an issue with FreeRTOSselect not working with a Listen socker because a FreeRTOSConfig setting was in conflict with the FreeRTOSselect's capability.

I'm wondering if the issue that follows is also associated with conflicting CONFIG settings.

My TCP usage is a small web server. Chrome is attempting to connect.

FreeRTOSIP identifies the incoming connection and my code issues FreeRTOS_accept.

Chrome does not like the connections and closes all of the connections without ever attempting to send data to the connection.

I have a WireShark listing showing MY side of the communication -- notice all of the re-tries.

Following the WireShark listing are the stack's debug messages that are generated during the process.

Chrome is 192.1689.1.37 FreeRTOSIP is 192.168.1.12

Stack Debug Listing: ~~~ Debugger Active IP 192.168.1.37 PixelBoard Debugger Active IP 192.168.1.12 D:7:28 AM:9901642 -> Gain: Socket 80 now has 1 / 3 child

D:7:28 AM:9901643 -> prvSocketSetMSS: 1460 bytes for c0a80125ip:51148

D:7:28 AM:9901643 -> Socket 80 -> c0a80125ip:51148 State eCLOSED->eSYN_FIRST

D:7:28 AM:9901644 -> Socket 80 -> c0a80125ip:51148 State eSYNFIRST->eSYNRECEIVED

D:7:28 AM:9901644 -> Gain: Socket 80 now has 2 / 3 children

D:7:28 AM:9901644 -> prvSocketSetMSS: 1460 bytes for c0a80125ip:51149

D:7:28 AM:9901644 -> Socket 80 -> c0a80125ip:51149 State eCLOSED->eSYN_FIRST

D:7:28 AM:9901644 -> Socket 80 -> c0a80125ip:51149 State eSYNFIRST->eSYNRECEIVED

D:7:28 AM:9901892 -> Gain: Socket 80 now has 3 / 3 children

D:7:28 AM:9901892 -> prvSocketSetMSS: 1460 bytes for c0a80125ip:51150

D:7:28 AM:9901893 -> Socket 80 -> c0a80125ip:51150 State eCLOSED->eSYN_FIRST

D:7:28 AM:9901893 -> Socket 80 -> c0a80125ip:51150 State eSYNFIRST->eSYNRECEIVED

D:7:28 AM:9901930 -> xTCPCheckNewClient[0]: client on port 80

D:7:28 AM:9901931 -> Connection Using 1

D:7:28 AM:9901931 -> xTCPCheckNewClient[0]: client on port 80

D:7:28 AM:9901931 -> Connection Using 2

D:7:28 AM:9901931 -> Connection Using 3

D:7:28 AM:9904642 -> eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK

D:7:28 AM:9904642 -> Socket 80 -> c0a80125ip:51148 State eSYNRECEIVED->eSYNFIRST

D:7:28 AM:9904643 -> Socket 80 -> c0a80125ip:51148 State eSYNFIRST->eSYNRECEIVED

D:7:28 AM:9904643 -> eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK

D:7:28 AM:9904643 -> Socket 80 -> c0a80125ip:51149 State eSYNRECEIVED->eSYNFIRST

D:7:28 AM:9904643 -> Socket 80 -> c0a80125ip:51149 State eSYNFIRST->eSYNRECEIVED

D:7:28 AM:9904892 -> eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK

D:7:28 AM:9904892 -> Socket 80 -> c0a80125ip:51150 State eSYNRECEIVED->eSYNFIRST

D:7:28 AM:9904892 -> Socket 80 -> c0a80125ip:51150 State eSYNFIRST->eSYNRECEIVED

D:7:28 AM:9910642 -> eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK

D:7:28 AM:9910642 -> Socket 80 -> c0a80125ip:51148 State eSYNRECEIVED->eSYNFIRST

D:7:28 AM:9910643 -> Socket 80 -> c0a80125ip:51148 State eSYNFIRST->eSYNRECEIVED

D:7:28 AM:9910643 -> eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK

D:7:28 AM:9910643 -> Socket 80 -> c0a80125ip:51149 State eSYNRECEIVED->eSYNFIRST

D:7:28 AM:9910643 -> Socket 80 -> c0a80125ip:51149 State eSYNFIRST->eSYNRECEIVED

D:7:28 AM:9910892 -> eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK

D:7:28 AM:9910893 -> Socket 80 -> c0a80125ip:51150 State eSYNRECEIVED->eSYNFIRST

D:7:28 AM:9910895 -> Socket 80 -> c0a80125ip:51150 State eSYNFIRST->eSYNRECEIVED

D:7:28 AM:9912929 -> Killing stuck session 0

D:7:28 AM:9912930 -> Lost: Socket 80 now has 2 / 3 children

D:7:28 AM:9912930 -> FreeRTOS_closesocket[80 to c0a80125ip:51148]: buffers 44 socks 3

D:7:28 AM:9912931 -> Closed Socket 1

D:7:28 AM:9912931 -> Killing stuck session 1

D:7:28 AM:9912931 -> Lost: Socket 80 now has 1 / 3 child

D:7:28 AM:9912932 -> FreeRTOS_closesocket[80 to c0a80125ip:51149]: buffers 44 socks 2

D:7:28 AM:9912932 -> Closed Socket 2

D:7:28 AM:9912932 -> Killing stuck session 2

D:7:28 AM:9912932 -> Lost: Socket 80 now has 0 / 3 children

D:7:28 AM:9912933 -> FreeRTOS_closesocket[80 to c0a80125ip:51150]: buffers 44 socks 1

D:7:28 AM:9912933 -> Closed Socket 3

~~~

Have you seen this issue before?

Are there any config settings that may be causing the issue.

Thanks in advance for any comments.

Joe

You're too quick.

I'm just ready testing your earlier source code and now you're posting +TCP logging.

Please find attached a simple TCP server that uses Select(). I tested it on real hardware.

What hardware platform are you using now, still a NXP K64?

About the logging: did you also have a PCAP file from Wireshark, not only a print-screen?

Chrome does not like the connections

It seems to me that Chrome doesn't receive any response at all, for some reason there is a one-way traffic. Strange though that Wireshark doesn see +TCP responses (SYN+ACK)

~~~~ /* Standard includes. */

/* FreeRTOS includes. */

/* FreeRTOS+TCP includes. */

static unsigned short ListenPort = 8008;

static Socket_t xListenSocket;

extern void clearWDT (void); /* Should be called by each process */

typedef struct xSesssion { Sockett S; } Sesssiont;

#define WF_DataWasSentLookForComplete 1

static TaskHandle_t pxHTTPTask;

static char pcBuffer[ 256 + 1 ];

static Sesssiont xSessions[ MAXSESSIONS ]; static SocketSet_t xSocketSet;

void AcceptConnection() { struct freertossockaddr xAddress; socklent xAddressLength = ( socklent ) sizeof( xAddress ); BaseTypet xSessionNr;

Socket_t xSocket = FreeRTOS_accept( xListenSocket, &xAddress, &xAddressLength  );

FreeRTOS_printf( ( "FreeRTOS_accept returns %p\n", xSocket ) );
if( xSocket != NULL )
{
UBaseType_t xReceiveTimeOut = 0ul;

	/* The call to FreeRTOS_recv() will be non-blocking. */
	FreeRTOS_setsockopt( xSocket, 0, FREERTOS_SO_RCVTIMEO, &xReceiveTimeOut, sizeof( xReceiveTimeOut ) );       
	for( xSessionNr = 0; xSessionNr < MAX_SESSIONS; xSessionNr++ )
	{
		if( xSessions[xSessionNr].S == FREERTOS_INVALID_SOCKET )
		{
			memset( xSessions + xSessionNr, 0, sizeof xSessions[ xSessionNr ] );
			xSessions[xSessionNr].S = xSocket;
			FreeRTOS_FD_SET( xSocket, xSocketSet, eSELECT_READ | eSELECT_EXCEPT );
			break;
		}
	}
}

}

void httpserver( void *pvParameters ) { UBaseTypet xReceiveTimeOut = pdMSTOTICKS( 5000ul ); BaseTypet xResult, xSessionNr; struct freertossockaddr serveraddr; UBaseTypet TimeoutActive = pdFALSE;

/* loop through list of open sessions looking for work */
for(xSessionNr = 0; xSessionNr < MAX_SESSIONS; xSessionNr++)
{
	xSessions[xSessionNr].S = FREERTOS_INVALID_SOCKET;
}

while(1)
{

        /* Create a TCP socket. */
    xListenSocket = FreeRTOS_socket( FREERTOS_AF_INET, FREERTOS_SOCK_STREAM, FREERTOS_IPPROTO_TCP );
    if( xListenSocket != FREERTOS_INVALID_SOCKET )
	{
        break;
	}

TryAgain:
vTaskDelay( pdMSTOTICKS( 100 ) ); }

/* Set a time out so accept() will just wait for a connection. */ FreeRTOSsetsockopt( xListenSocket, 0, FREERTOSSO_RCVTIMEO, &xReceiveTimeOut, sizeof( xReceiveTimeOut ) );

memset(&server_addr, '\0', sizeof(server_addr));      
server_addr.sin_port = FreeRTOS_htons( ListenPort );
server_addr.sin_addr = FreeRTOS_GetIPAddress(); // Single NIC, currently not used

// Bind the address to the socket. 
if( FreeRTOS_bind( xListenSocket, &server_addr, sizeof( server_addr ) ) == -1 )
{
    FreeRTOS_closesocket( xListenSocket );
    xListenSocket = FREERTOS_INVALID_SOCKET;
    goto TryAgain;
}

FreeRTOS_printf( ("Socket created and Bind.\n" ) );

while(1)
{
    xSocketSet = FreeRTOS_CreateSocketSet();
    if( xSocketSet )
	{
        break;
	}

    vTaskDelay( pdMS_TO_TICKS( 100 ) );
}

//Listen to incoming connections
xResult = FreeRTOS_listen( xListenSocket , MAX_SESSIONS );

// add listen to socket set 
FreeRTOS_FD_SET( xListenSocket, xSocketSet, eSELECT_READ );

//Accept and incoming connection
FreeRTOS_printf( ("Waiting for incoming connections... (xResult = %ld)\n", xResult ) );

while(1)
{
	clearWDT ();

    /* See if any of the sockets have input or ready to send */
	/* Wait at most 10 seconds. */
    xResult = FreeRTOS_select( xSocketSet, ( pdMS_TO_TICKS( 10000 ) ) );    // Blocks until activity

    if(xResult < 0)
	{
	static BaseType_t xLastError;

		if( xLastError != xResult )
		{
			xLastError = xResult;
			FreeRTOS_printf( ("Select returns %ld\n", xResult ) );
		}
	}
    else if( xResult > 0 )
    {
		FreeRTOS_printf( ("Select returns %ld\n", xResult ) );
        // check if new read on listen
        if( ( FreeRTOS_FD_ISSET( xListenSocket, xSocketSet ) & eSELECT_READ ) != 0 )  // read on listen means new connection waiting
		{
            AcceptConnection();
		}
    }

	/* Work on the socket list. */
	for( xSessionNr = 0; xSessionNr < MAX_SESSIONS; xSessionNr++ )
	{
	Socket_t xSocket = xSessions[ xSessionNr ].S;

		if( xSocket != FREERTOS_INVALID_SOCKET )
		{
		BaseType_t xLength;

			xLength = FreeRTOS_recv( xSocket, pcBuffer, sizeof( pcBuffer ) - 1, 0L );

			if( xLength < 0 )
			{
				if( xLength != -pdFREERTOS_ERRNO_EAGAIN )
				{
					FreeRTOS_printf( ("Connection lost, socket will be closed.\n" ) );
					FreeRTOS_FD_CLR( xSocket, xSocketSet, eSELECT_ALL );
					FreeRTOS_closesocket( xSocket );
					/* Mark as free. */
					xSessions[ xSessionNr ].S = FREERTOS_INVALID_SOCKET;
				}
			}
			else if( xLength > 0 )
			{
				FreeRTOS_send( xSocket, pcBuffer, xLength, 0 );
			}
			break;
		}
	}
}

}

void httpserverinstall() { if( pxHTTPTask == NULL ) { /* Call this function once to start the test with FreeRTOSaccept(). */ xTaskCreate( httpserver, "httpserver", STACKSIZEHTTPTASK, NULL, PRIORITYHTTPTASK, &pxHTTPTask ); }

}

~~~~

Yes I have a pcap file.

I resolved the other issue We spoke about -- see that post.

In your example server above -- what does function clearWDT (); do?

It is missing from the code?

Joe

I've implemented you server above.

Same connection issue.

I have include pcap files for execution on Chrome and IE.

Any IP config setting that could be related?

I wrote the EMAC - driver. Any potential issue I caused there? The driver was running in another port -- no issue.

Here is a debug dump from YOUR web server. If you look at the pcap file, I still see a lot of re-transmissions.

Do you see any behavior difference in my server and yours?

The two Test_WS files are YOUR web server.

Web Browser is 192.168.1.37 FreeRTOSIP is 192.168.1.12

Thanks.

Joe

Debug dump YOUR Server ~~~ D:9:47 AM:18280267 -> Gain: Socket 8008 now has 1 / 4 child

D:9:47 AM:18280267 -> prvSocketSetMSS: 1460 bytes for c0a80125ip:52610

D:9:47 AM:18280268 -> Socket 8008 -> c0a80125ip:52610 State eCLOSED->eSYN_FIRST

D:9:47 AM:18280268 -> Socket 8008 -> c0a80125ip:52610 State eSYNFIRST->eSYNRECEIVED

D:9:47 AM:18283269 -> eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK

D:9:47 AM:18283270 -> Socket 8008 -> c0a80125ip:52610 State eSYNRECEIVED->eSYNFIRST

D:9:47 AM:18283270 -> Socket 8008 -> c0a80125ip:52610 State eSYNFIRST->eSYNRECEIVED

S:9:48 AM:18285955 -> Select returns 1

S:9:48 AM:18285955 -> FreeRTOS_accept returns 2000fda8

D:9:48 AM:18289264 -> eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK

D:9:48 AM:18289264 -> Socket 8008 -> c0a80125ip:52610 State eSYNRECEIVED->eSYNFIRST

D:9:48 AM:18289264 -> Socket 8008 -> c0a80125ip:52610 State eSYNFIRST->eSYNRECEIVED

D:9:48 AM:18301266 -> Gain: Socket 8008 now has 2 / 4 children

D:9:48 AM:18301267 -> prvSocketSetMSS: 1460 bytes for c0a80125ip:52612

D:9:48 AM:18301267 -> Socket 8008 -> c0a80125ip:52612 State eCLOSED->eSYN_FIRST

D:9:48 AM:18301267 -> Socket 8008 -> c0a80125ip:52612 State eSYNFIRST->eSYNRECEIVED

D:9:48 AM:18304266 -> eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK

D:9:48 AM:18304266 -> Socket 8008 -> c0a80125ip:52612 State eSYNRECEIVED->eSYNFIRST

D:9:48 AM:18304266 -> Socket 8008 -> c0a80125ip:52612 State eSYNFIRST->eSYNRECEIVED

S:9:48 AM:18305955 -> Select returns 1

S:9:48 AM:18305955 -> FreeRTOS_accept returns 20010f68

D:9:48 AM:18310266 -> eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK

D:9:48 AM:18310267 -> Socket 8008 -> c0a80125ip:52612 State eSYNRECEIVED->eSYNFIRST

D:9:48 AM:18310267 -> Socket 8008 -> c0a80125ip:52612 State eSYNFIRST->eSYNRECEIVED

~~~

Missed your question.

Yes -- still same NXP Kinetis K64 (Use to be FreeScale)

Joe

Hein:

It just occurred to me, you might think this is about the Listening / Select issue I post about over the weekend.

It's NOT. I resolved that issue -- I believe you folks have a CONFIG option issue that needs looking into.

This is a Connection issue AFTER the listening has accepted the connection.

Joe

Hi Joe,

clearWDT ()

Sorry I left that in, it's my Watch Dog Timer, every task must call it regularly.

Your last logging shows the same: the client doesn't seem to receive any TCP packets.

Yes I have a pcap file.

I still don't the PCAP file attached?

Normally when users are developing a EMAC / +TCP driver, they get in touch with us directly. This shortens the development time and it decreases frustrations. I already invited you to contact us :-) You can reach me as h point tibosch at freertos point org.

There is already a port for K63F, but I'm not sure if that would help you?

I've just posted a working example of the use of FreeRTOS_select() in this thread. I tested it with :

#define ipconfigTCP_HANG_PROTECTION        1

Have you tried it already?

There is no known issue (yet) with the hang protection. It is normally used along with ipconfigTCP_KEEP_ALIVE, which causes ALIVE messages to be exchanged.

Have you already tried the example HTTP server?

~~~~ FreeRTOS-Plus-TCPprotocolsHTTPFreeRTOSHTTPserver.c ~~~~

it also uses FreeRTOS_select() and I it is often used along with ipconfigTCP_HANG_PROTECTION.

Regards, Hein

Our posts keep on crossing each other...

I'll attach a PCAP of the communication that I just saw. It is sending three times "Hello world" to the server and disconnect.

The logging shows this:

~~~~ 70.379 [10]: Select returns 1 70.380 [10]: FreeRTOS_accept returns d0233ec8 71.854 [10]: Select returns 1 72.894 [10]: Select returns 1 73.917 [10]: Select returns 1 75.015 [10]: Select returns 4 75.015 [10]: Connection lost, socket will be closed. ~~~~

Regards.

Update:

Issue is resolved.

Stack GREAT!!. User had issue.

I was too knowledable about stack and driver design that I read more into the porting requirements than what +TCP wanted.

I am using bufferallocation1 which uses statically defined network buffers.

When I designed the driver's transmit function I assumed the return indicated if the networkbuffer was actually transmitted.

If I did not have an empty xmit buffer slot, I returned FALSE back to the stack and DID NOT release the buffer. The stack thought the buffer was released and reused it, which happened to be a TCP reply to a client with the wrong port number. My client did NOT receive a proper connection SYN+ACK to the required port .. so it bailed.

Hein was extreemly helpful in resolving the issue which was with my transmit driver. I now spin until the message can be transmitted and always release EVERY buffer ... transmitted or not.

Great help from Hein at FreeRTOS.

Joe