TCP send failure after reopening a socket

[arielablumer]

Hi,

I am working on a product with a WiFi connectivity and a K66 based processor. MQX version is 4.0.2.

I am running a  test which sends packets from a TCP client to a TCP server running on a PC. It happens that tarnsmission fails due to TCP connection closure. When this happens I'm shutting down the socket and creating a new one. Ocassionally, sending TCP packets fails although the new connection was created successfully. I'm getting errno 0x1635 which implies the socket is closed. Any idea what may be the reson for this behavior?

BTW, I've seen a thread regarding an issue with multiple sockets, I'm using a single socket in my test.

Thanks,

Ariela

[arielablumer]

Hi Issac,

Haven't got any answer yet regarding the bug in connect()  return code. Was it supposed to be fixed in 4.2.2? it seems it's still there.

Thanks,

Ariela

[isaacavila]

Hello Ariela,

Sorry for late response, It should be already fixed in this release but need to corroborate about it! I will thank your patience and let you know if something is found!

Regards,

Isaac

[arielablumer]

Hi Isaac,

It looks like the problem wasn't solved. I measure the time it takes to connect and even when it equals connection timeout the return code indicates operation has succeed.

My workaround is to check both return code & connect() duration and if needed change the result.

Regards,

Ariela

[arielablumer]

Hi Isaac,

I've noticed the connect() still returns OK when the operation actually fails.

Do you know if a fix is expected for this issue?

Thanks,

Ariela

[arielablumer]

One more thing: I now realize that the cpnnect command always succeeds regardsless of actual state.

Is there a way to double check the connection state?

Thanks,

Ariela

[isaacavila]

Hello Ariela,

Could you please send me your project in order to test it on our side?

The error you are facing is obtained to abort connection by software (RTCSERR_TCP_CONN_ABORTED) but I need to corroborate what is the function/situation is causing this error.

regards,

Isaac

[arielablumer]

Hi Isaac,

I use GS2000 WiFi device for L2 so I doubt you can reproduce the problem on your side.

Looking into Wirehsark capture I noticed that the connection is lost after TCP packet loss.

The peer hasn't received a certain packet and although it keeps sending ACK asking for the missed packet my target keeps sending higher SEQ and finally restarts the socket.

When the target restarts the connection it returns connection was successfully started although it happens that the SYN,ACK packet wasn't received and I know for sure connection failed.

Any way to get a correct indication?

Thanks,

Ariela

[isaacavila]

Hello Ariela,

It seems to me that you are facing same issue that is expressed here: connect() error in user guide if so, you should move to MQX 4.2.0.2 which has fixed this issue (MQX-5682​).

You can try to use this latest release and check if the error you were facing is still presented!

Hope this helps!

Best Regards,

Isaac Avila

[arielablumer]

Hi Isaac,

Is the patch already available? Where can I find it?

I've been inspecting Wireshark capture looking for disconnection reason and I noticed my platform keep sending packets with incremented SEQ although peer insists to ask for retransmission of a packet it misses (ACK isn't incremented).

This ends up with closing the socket on my platform.

Is there a known issue regrading SEQ/ACK management?

Thanks,

Ariela

[isaacavila]

Hello Ariela,

You can download the latest MQX version on download tab from MQX Classic site: MQX™ Classic Software Solutions|NXP

About SEQ/ACK issues I need to look for something related, if something is found i will let you know!

Regards,

Isaac

[arielablumer]

Hi Isaac,

The upgrade indeed solved some of the issues I had.

There's one more problem I see.

The test I run sends a buffer of fixed size from the platform. A Python script receives the packets and returns them to the sender.

Once in a while I notice the platform receives partial buffers (i.e. number of received bytes < test buffer size).

The next time recv() is called the test receives the next packet instead of the partial one. (I attach a sequence number to each buffer). So practically I lose some data when this happens.

I wasn't expecting to receive partial packets; is this the expected behavior?

Thanks,

Ariela