I have a window's based TCP server that communicates with my +TCP embedded application.

My app comes out of reset and attampts to make a connection with the Window's based server.

Upon connection, data is passed back and forth.

ISSUE: If the connection is made and then the app does a reset -- the app attempts to make a connection with the server again. +TCP gives the same port to the app as in the first connection. The server still has an open connection based on that port number but my app is trying to start a new one.

The RED wireshark line below shows the connection mismatch. This issue of not connecting will continue forever.

I suspect it is the use of the same port number that +TCP assigns to the connection that causes the server to think it was the original connection and not a new one being started.

Looking at the Wireshark data, +TCP replies with a RST, ACK to the server's ACK.

+TCP is not using the same SEQ that the server provided in the ACK for the RST reply. Is that why the server is ignoring the RST and keeps the connection open?

pcap file attached

Thanks for any insight.

Joe

Hi Joe,

If you look in FreeRTOS_Sockets.c, you will find the implementation of prvGetPrivatePortNumber(), and there is a comment in the function "This needs to be randomised" [at least, you will see the comment if you are using the head revision code rather than the last release code].

The function provides port numbers between socketAUTOPORTALLOCATIONSTARTNUMBER and socketAUTOPORTALLOCATIONMAXNUMBER, with the first call always returning port number socketAUTOPORTALLOCATIONSTARTNUMBER.

You can update this function, and we can do here as well, so that on the first call it instead chooses a random number between socketAUTOPORTALLOCATIONSTARTNUMBER and socketAUTOPORTALLOCATIONSTARTNUMBER.

Thanks, I'll do that.

TCP question.

If +TCP had replied with the Server's SEQ instead of it's connection SEQ -- would THAT have terminated the connection?

If +TCP receives an out of sequence ACK -- why not reply to the same SEQ?

The port number change will fix my issue with not connecting, but the server will still have a connection that has to time out. I just wondering if the RST ACK reply was returned with the server's SEQ if that would fix everything?

Just asking -- Hoping I don't have to dig into the RFC to see.

Thanks.

If +TCP had replied with the Server's SEQ instead of it's connection SEQ -- would THAT have terminated the connection?

Tomorrow when I'm not tired I will look at your questions again.

But when a RST is sent, the actual ACK and SEQ numbers do no matter.

A TCP connection is identified by 4 "numbers" : source IP address + port number, and the target IP address and port number. If a sending host receives a RST matching with these 4 numbers, the socket owner must see an error like ECONNRESET

Applications like browsers on any OS will surely behave correctly in this respect.

The correct way to actively shutdown a +TCP connection is as follows:

~~~~ FreeRTOSshutdown( xSocket ); for( ;; ) { xResult = FreeRTOSrecv( xSocket, ucBuffer, sizeof( ucBuffer ), 0 ); if( ( xResult < 0 ) && ( xResult != -pdFREERTOSERRNOEWOULDBLOCK ) ) { FreeRTOS_closesocket( xSocket ); xSocket = NULL; break; } } ~~~~

Regards.

Correction! My post here https://sourceforge.net/p/freertos/discussion/382005/thread/794f3d82/#3cf0/39ac was not accurate. The first port number used is already a randomly selected port number between socketAUTOPORTALLOCATIONSTARTNUMBER and socketAUTOPORTALLOCATIONENDNUMBER. This is because FreeRTOS_IPInit() calls vNetworkSocketsInit(), and vNetworkSocketsInit() uses ipconfigRAND32() to randomise the first private port number used. This does however rely on ipconfigRAND32() operating correctly. If you do not define ipconfigRAND32() in FreeRTOSIPConfig.h it will get defaulted to just calling the rand() function provided by your C run time library - but you need to call srand() with appropriate entropy to seed the random number.

I implemented rand() for ipconfigRAND32() but had not set srand().

I've used an "un-used" ADC channel to acquire a seed for srand() prior to starting the IP thread.

Thanks for your reply