FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [August 2016 Threads] +TCP - How force a close on a TCP connection on a Remote ServerPosted by joehinkle on August 20, 2016 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
+TCP - How force a close on a TCP connection on a Remote ServerPosted by rtel on August 20, 2016 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.
+TCP - How force a close on a TCP connection on a Remote ServerPosted by joehinkle on August 20, 2016 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.
+TCP - How force a close on a TCP connection on a Remote ServerPosted by heinbali01 on August 20, 2016
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.
+TCP - How force a close on a TCP connection on a Remote ServerPosted by rtel on August 21, 2016 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.
+TCP - How force a close on a TCP connection on a Remote ServerPosted by joehinkle on August 21, 2016 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
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|