FreeRTOS_send gets stuck replying 0

dibosco wrote on Tuesday, August 30, 2016:

Folks,

I have a situation where, ocassionally, FreeRTOS_send() returns 0.

I followed the premise on this page:

http://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/TCP_Networking_Tutorial_Sending_TCP_Data.html

However, very ocassionally, I find that in this part:

if( FreeRTOS_connect( xSocket, &xRemoteAddress, sizeof( xRemoteAddress ) ) == 0 )
{
/* Keep sending until the entire buffer has been sent. /
while( xAlreadyTransmitted < xTotalLengthToSend )
{
/
How many bytes are left to send? /
xLenToSend = xTotalLengthToSend - xAlreadyTransmitted;
xBytesSent = FreeRTOS_send( /
The socket being sent to. /
xSocket,
/
The data being sent. /
&( pcBufferToTransmit[ xAlreadyTransmitted ] ),
/
The remaining length of data to send. /
xLenToSend,
/
ulFlags. */
0 );

    if( xBytesSent >= 0 )
    {
        /* Data was sent successfully. */
        xAlreadyTransmitted += xBytesSent;
    }
    else
    {
        /* Error - break out of the loop for graceful socket close. */
        break;
    }
}

}

The xBytesSent is always zero and therefore the thread gets stuck infinitely in that bit of the code and the whole web server just stops responding,

I changed the line from:

if( xBytesSent >= 0 )

to

if( xBytesSent > 0 )

And that seems to stop the thread from locking up, but I very ocassionally get my auto-refresh page not responding and have to manually refresh the page, then all is well again.

I’m using a version of the TCP/IP stack that is around a year old. Is it worth updating it? Or do these symptoms point to something more sinister?

If it’s of any help I did step into the code and found that the zero return value was here:

else if( pxSocket->u.xTcp.bits.bFinSent )
{
    /* This TCP connection is closing already, the FIN flag has been sent.
    Maybe it is still delivering or receiving data.
    Return OK in order not to get closed/deleted too quickly */
    xResult = 0;
}

Which is in prvTCPSendCheck() which is called by FreeRTOS_send().

Many thanks!

Rob

heinbali01 wrote on Tuesday, August 30, 2016:

Hi Rob,

There is a newer release available of the +TCP library than the one that you are using:

http://www.freertos.org/FreeRTOS-Labs/RTOS_labs_download.html

Just thinking out loud: if the FIN has been sent (bFinSent), then the connection is in a closing state.
Apparently, the peer has not yet acknowledged the FIN, because ucTCPState != eCLOSED yet, the connection isn’t closed.

It would be interesting to see a PCAP dump of that conversation in which send() hangs. Can you create that?

On itself, your code seems correct: eventually FreeRTOS_send() will either send all data, or the connection gets closed and FreeRTOS_send() will return a negative errno code.

If FreeRTOS_send() returns 0, it means that the buffers are full. Does the call still block when nothing can be sent? Isn’t it just spinning around on a too high priority?

Do you have these enabled?

    #define ipconfigTCP_HANG_PROTECTION         1
    #define ipconfigTCP_KEEP_ALIVE              1

Not sure if it would help you with this problem though :slight_smile:

What does your code do after sending the file? After the last successful call to FreeRTOS_send()? Do you wait for the data to be properly delivered?
Do you use the same socket for more transactions?

Regards.

dibosco wrote on Thursday, September 01, 2016:

Hi Hein,

I have attached an instance where the auto page request is sent out and
nothing is returned to the browser.

Eventually, I hit the little x on the right of the URL bar in Firefox,
re-request the page by hitting the curved arrow and it works fine.

In twenty minutes of the auto request page being active, it fails to
reply once or twice.

I would say, this isn’t sending a file, this is updating the web browser
where the system is up to, when setting up the addresses on a pair of
DALI buses. A process that takes around twenty minutes.

Both of those #defines are enabled, yes.

I’ll try the latest version of the stack.

Thanks!

Rob

On 30/08/16 16:43, Hein Tibosch wrote:

Hi Rob,

There is a newer release available of the +TCP library than the one that
you are using:

FreeRTOS+TCP Downloads

Just thinking out loud: if the FIN has been sent (|bFinSent|), then the
connection is in a closing state.
Apparently, the peer has not yet acknowledged the FIN, because
|ucTCPState != eCLOSED| yet, the connection isn’t closed.

It would be interesting to see a PCAP dump of that conversation in which
send() hangs. Can you create that?

On itself, your code seems correct: eventually |FreeRTOS_send()| will
either send all data, or the connection gets closed and
|FreeRTOS_send()| will return a negative errno code.

If |FreeRTOS_send()| returns 0, it means that the buffers are full. Does
the call still block when nothing can be sent? Isn’t it just spinning
around on a too high priority?

Do you have these enabled?

#define ipconfigTCP_HANG_PROTECTION         1
#define ipconfigTCP_KEEP_ALIVE              1

Not sure if it would help you with this problem though :slight_smile:

What does your code do after sending the file? After the last successful
call to |FreeRTOS_send()|? Do you wait for the data to be properly
delivered?
Do you use the same socket for more transactions?

Regards.


FreeRTOS_send gets stuck replying 0
https://sourceforge.net/p/freertos/discussion/382005/thread/07900148/?limit=25#ab7d


Sent from sourceforge.net because you indicated interest in
SourceForge.net: Log In to SourceForge.net

To unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net

heinbali01 wrote on Thursday, September 01, 2016:

Hi Rob,

The PCAP shows a GET request that isn’t responded to. The browser waits for 30 seconds and disconnects.

Things are still not clear to me :frowning:

I’ll try the latest version of the stack.

Good idea. Make sure you get the latest, which is “160831_FreeRTOS_Labs.zip”.

Regards.

dibosco wrote on Friday, September 02, 2016:

Hi Hein,

I did update the stack and kernel from the link you sent and ran the
cycle several times with no issues, so hopefully the new stack has done
the trick!

Thanks!

Rob

On 02/09/16 00:34, Hein Tibosch wrote:

Hi Rob,

The PCAP shows a GET request that isn’t responded to. The browser
waits for 30 seconds and disconnects.

Things are still not clear to me :frowning:

I'll try the latest version of the stack.

Good idea. Make sure you get the latest, which is
“160831_FreeRTOS_Labs.zip”.

Regards.


FreeRTOS_send gets stuck replying 0
https://sourceforge.net/p/freertos/discussion/382005/thread/07900148/?limit=25#956f


Sent from sourceforge.net because you indicated interest in
SourceForge.net: Log In to SourceForge.net

To unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net