topic MQX 4.1 RTCS strange behaviour in MQX Software Solutions

MQX 4.1 RTCS strange behaviour

igor-imx — Thu, 06 Mar 2014 22:40:47 GMT

Hi Everyone

I just finished porting my project from MQX 4.0 to MQX 4.1. We are using a custom platform that is very close to TWRK60M512 tower board with some minor pinout differences.

I have a TCP client application (Modbus protocol client) which is working perfectly on the MQX4.0.

The client app is quite simple:

1. Connect to 6 servers using 6 sockets

2. Read the data (modbus tcp data) from those sockets

When i tired to run the same app after porting it (replacing the old MQX datatypes with the C99 style ones) and running it i get a really strange behaviour.

I attach a wireshark PCAP file which can explain it way better then with words. Basically after i Open 6 sockets and start reading the data, RTCS sends TCP RESET to the server.

So i made a test. I have called connect() 6 times with 6 different sockets and paused the debugger right after that. All 6 sockets are opened, see attached picture.

After that, i have performed one Modbus TCP request to only the 1st socket. But the other 4 sockets were issued a TCP RESET command from RTCS and it is visible on the captured as well.

Can anyone shed any light on what might be going on there? I know for sure there are no stack smashed (i increased the stacks and it checked with TAD plugin, all at around 40%-65%).

Any help would be greatly appreciated.

Also, here are the socket options that i set to all of those 6 sockets:

VOID MBPTCPSetSockOptions(SOCKET iSocket)

{

UINT option = 0;

option = 5000;

ULONG retval = RTCS_OK;

retval |= setsockopt(iSocket, SOL_TCP, OPT_CONNECT_TIMEOUT, &option, sizeof(option));

option = 400; //380

retval |= setsockopt(iSocket, SOL_TCP, OPT_RBSIZE, &option, sizeof(option));

option = 400; //380

retval |= setsockopt(iSocket, SOL_TCP, OPT_TBSIZE, &option, sizeof(option));

option = 1;

retval |= setsockopt(iSocket, SOL_TCP, OPT_NO_NAGLE_ALGORITHM, &option, sizeof(option));

option = 0;

retval |= setsockopt(iSocket, SOL_TCP, OPT_RECEIVE_NOWAIT, &option, sizeof(option));

option = 1;

retval |= setsockopt(iSocket, SOL_TCP, OPT_RECEIVE_PUSH, &option, sizeof(option));

option = 0;

retval |= setsockopt(iSocket, SOL_TCP, OPT_SEND_NOWAIT, &option, sizeof(option));

option = 1;

retval |= setsockopt(iSocket, SOL_TCP, OPT_SEND_PUSH, &option, sizeof(option));

option = 0;

//retval |= setsockopt(iSocket, SOL_TCP, OPT_TIMEWAIT_TIMEOUT, &option, sizeof(option));

option = 100;

retval |= setsockopt(iSocket, SOL_TCP, OPT_RECEIVE_TIMEOUT, &option, sizeof(option));

option = 30; //30 seconds keep alive

retval |= setsockopt(iSocket, SOL_TCP, OPT_KEEPALIVE, &option, sizeof(option));

if(RTCS_OK != retval)

{

TASK_BLOCK();

}

Thanks in advance

Re: MQX 4.1 RTCS strange behaviour

igor-imx — Thu, 06 Mar 2014 22:42:59 GMT

Sorry, forgot the attachments

Re: MQX 4.1 RTCS strange behaviour

igor-imx — Fri, 07 Mar 2014 19:00:18 GMT

I found the problem and as always it was in our code

However there is one interesting observation:

Here is the code i use:

SOCKET iClientSocket[1] = SocketDescriptor i got from socket() function call

at this point connect() was called as well

recieving function:

SOCKET iResultSocket ;

while(!)

{

iResultSocket = RTCS_selectset( iClientSocket , 1, 10);

if (RTCS_SOCKET_ERROR == iResultSocket)

{

//hadle error close the socket

}

else

{

if(SELECT_TIMED_OUT == iResultSocket)

{

//sleep 1 MS and continue to the top of the loop

}

else

{

READ FROM THE SOCKET HERE.

And this was the problem, since RTCS_selectset was returning a different socket value then the value of iClientSocket[0].

When i put the check here to see that iResultSocket == iClientSocket[0] and then do a read, problem disappeared

}

Can anyone on the MQX team please confirm that there is an issue with RTCS_selectset?

Thank you

Re: MQX 4.1 RTCS strange behaviour

Martin_ — Mon, 10 Mar 2014 07:42:41 GMT

Hi,

I wonder if you enable RTCSCFG_SOCKET_OWNERSHIP ? The described issue might happen if RTCSCFG_SOCKET_OWNERSHIP is TRUE and the task is the owner of more sockets. A task is an owner of a socket if it creates it (a call to socket()).

Just a side note, current implementation of RTCS_selectset() function cannot distinguish between readability/writeability, so a socket can unblock RTCS_selectset() when an ACK has been received and the send buffer is empty (= it is writeable). So, perhaps you may need to put also a timeout for recv() and send() calls (a received ACK might unblock RTCS_select, and if your code calls recv() then, socket might not have any data for reading and recv() might block).

We re-designed select functionality for next version of MQX, so that MQX RTCS will support standard BSD-like select() on sockets. It is able to choose between read/write-abiltiy. For backward compatibility, RTCS_selectset() function will still be supported, but inside the stack, it will be implemented using the new select() function.

-Martin

Re: MQX 4.1 RTCS strange behaviour

igor-imx — Thu, 13 Mar 2014 16:44:08 GMT

Hi Martin

Thank you for your reply

I have checked and the RTCSCFG_SOCKET_OWNERSHIP is disabled.

Unblocking of RTCS_select because of a write is probably what is happening since i have recv and send in different tasks.