NDK rec() problems

John Conover

Other Parts Discussed in Thread: AM3352

Hi,

We are running the latest NDK (2.24.0.11) with Code Composer 6.0.1.00040 on a AM3352 using the CPSW interface. We are running a static IP configuration that is pingable and all of the NDK calls prior to recv() come back without error ( socket, bind, listen and accept). We are trying to receive packets on a TCP socket (socket(AF_INET, SOCK_STREAM, IPPROTO_TCP))) where the initial packet is TCP with an 11 byte payload from a PC application.The call:

if ((g_nRXLength = recv(ClientSocket, g_cRXBuff, 1200, MSG_WAITALL)) > 0)

With the maximum packet size set to 1200 the recv() call will not return until the PC application is stopped and then the recv() call returns with a error 54 (connection reset by peer) and the console spits out a "recv() failed: Domain error".

If we set the max packet size to 1 the recv() call comes back with a receive size of 1, but since our packet processing is expecting a full packet this does not work. We have read the Developers Kit API and it seems we should be able to use the 1200 byte max packet size with recv flags of "MSG_WAITALL" to receive all the different size packets we expect to come across on this TCP socket. Is there some obvious reason why we are not able to receive the 11 byte payload packet (yes we see the packet come from the PC application on WireShark.)?

Thanks,

John C.

Code Composer    6.0.1.00040
Compiler                5.1.6
XDC Tools              3.30.3.47_core
SYS/BIOS              6.40.3.39
NDK                       2.24.0.11

over 11 years ago

0 John Conover over 11 years ago

Genius 4350 points

To add information I've shown a WireShark screen shot of the opening sequence. The embedded devices address is 10.1.9.200 with the PC application at 10.1.10.236. The embedded systems first response has a frame check sequence error and it's response to an 11 byte data request is an ack message as the recv() function call does not come back so the embedded system does not respond(just the NDK stack.) This sequence is when we use a maximum packet size of 128 in the recv call.

recv(ClientSocket, g_cRXBuff, 128, MSG_WAITALL)

If the recv() call uses a max packet size of 11 bytes, it will actually come back from the call.

Any ideas how to troubleshoot this?

Thanks,

John C.

0 John Conover over 11 years ago in reply to John Conover

Genius 4350 points

Are there some flags on setup that are making this socket act like a stream? Standard recv() calls are supposed to deliver full packets that are less than the maximum size, so why is this not working when the 11 byte packet comes in?

Thanks,

John C.

0 Steven Connell over 11 years ago in reply to John Conover

TI__Mastermind 45025 points

Hi John,

Have you tried without the MSG_WAITALL flag?

I think the issue you are seeing here is due to the MSG_WAITALL flag being set. The code that you have:

John Conover said:
recv(ClientSocket, g_cRXBuff, 128, MSG_WAITALL)

This essentially translates to "I want to receive 128 bytes, and I want you to block (MSG_WAITALL) until you accumulate all 128 bytes."

Please retry without throwing that flag and see if recv() returns with the 11 bytes.

Steve

0 John Conover over 11 years ago in reply to Steven Connell

Genius 4350 points

Hey Steve,

The good news is I tried using no flags and I do receive two packets:
g_nRXLength = recv(ClientSocket, g_cRXBuff, 1600, 0)

The bad news is that the other three tasks that process socket data never come off the recv() function call. They are all the same priority. The task receiving the two packets is getting them reliably so I'll close this thread out and see if I have any more issues on my side.

Thanks,

John C.

Processors

Processors forum

NDK rec() problems