Problems with TCP/IP-Handshaking in NDK 2.20.3.24 with OMAP configured as client

Hi Andreas,

What socket options are using on both sides?

Todd

Hi Todd,

on OMAP-side we use the following code to create a connection to the PC (we use the documentation spru523_ug.pdf to implement the client-functionality on OMAP-side):

SOCKET socketToPC;
struct sockaddr_in sin;

// For correct stack operation, the task thread open a file descriptor session:
fdOpenSession((HANDLE)TaskSelf());

int addrIP = 0x031FA8C0; // 192.168.31.3
int port = 12002;
sin.sin_family      = AF_INET;
sin.sin_addr.s_addr = addrIP;
sin.sin_port        = htons(port);

socketToPC = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
connect(socketToPC, (PSA)&sin, sizeof(sin));



On PC-side:

For listening on connection on server side we use boost::asio library (v1.42.0) with
boost::asio::ip::tcp::socket for ipv4 connections.
Following additional types are involved:
- boost::asio::io_service
- boost::asio::ip::tcp::acceptor

Thanks for any help,

Andreas

Andreas,

Sounds like you need to use the SO_REUSEADDR option on the server side. If you don't have this option, and another request comes in while in a TIME_WAIT state, it is denied.

Todd

Todd,

thanks for your answer,

What exactly means SO_REUSEADDR? Can a socket on the PC with the option SO_REUSEADDR accept two connections from a client with two identical client-port-numbers? We find out, that the OMAP always connects to the server with the same local-port-number (57345).

As server we use a DSP and alternatively a PC:

We use the DSP with the lwIP - TCP/IP Stack (an open source IP-stack for processors with limited resources from the Swedish Institute of Computer Science). On this IP-stack it is not possible to set the option SO_REUSEADDR

On the PC we use a program which opens a server-socket, but we are uncertain, if the option SO_REUSEADDR is used.

Is there a way to connect with the OMAP to a server which has not the option SO_REUSEADDR?

Andreas

Andreas,

So you are not using the NDK, you are using lwip...correct? Are you using BIOS?

Regarding SO_REUSEADDR, it's probably best to just google it. There's lots of information out there regarding the topic. In summary, SO_REUSEADDR allows your server to bind to an address which is in a TIME_WAIT state.

Todd

Hi Todd,

sorry for the not clear description of my system.

We use a LogicPD evoBoard with a OMAP-L138. On this OMAP we use SysBios 6.30.3.46 and NDK 2.20.3.24. The OMAP is configured as client and connects to an other DSP (Analog-Devices BlackFin). On the BlackFin runs the lwip-stack which is configured as server. We cannot set the option SO_REUSEADDR in the lwip-stack on the Blackfin.

Alternatively we tried to connect from the OMAP to a PC. On the PC runs a program which opens a server-socket. This socket works with the set option SO_REUSEADDR, but the behavior is equal with the BlackFin-DSP: The OMAP cannot connect to the PC for two times.

Only if we restart the server (BlackFin / PC), the OMAP can build up a connection again.

Your description with the SO_REUSEADDR-option sounds plausible as reason for our problems, because if the OMAP restarts, the old connection on server-side is still alive and blocks a new connection-try from the OMAP. But on the PC the option SO_REUSEADDR is set and it is not working as it is described above.

Andreas

Andreas,

Thanks for describing the system.

If you wait for several minutes (e.g. 10 minutes) between stopping the omap-L138 and restarting it, does the problem still exist? If it works, the problem is mostly likely related to the SO_REUSEADDR option.

FYI: lwIP version 1.40 has support for SO_REUSEADDR.

The NDK does "randomize' the initial Send Sequence (ISS). It is initially 0x7f000000, but then is incremented based on timeouts within the stack. Can you attempt to delay the connection request in the second run of the connect? You can add a Task_sleep(50*globalFlag) before the connect() where globalFlag = 0 for the first run and globalFlag = 1 for the second run. This should cause you initial ISS to be different between the two runs. If the problem still exists, it is not related to the ISS. Note: I validated that it was not an issue when I ran a tcp echo server on my Windows PC and had the NDK send requests to it. The same ISS was used in multiple runs with no problem.

Todd

Hi Todd,

thanks for your answer.

I add "Task_sleep(50)" before connect() in the second connection try and it works.

Additional i tried to call connect() in a loop. For the first try the connection established at the first connection try. After a restart of the OMAP the first connestion in the loop faild as expected. After the second connect()-call in the loop the connection is successful. After a second restart of the OMAP the connection is successful after the third connect()-call in the loop. This would be a acceptable solution for my problem, but connect() tried up to 75 seconds to build up a connection until connect() returns with connection-timeout. Is it possible to shorten the timeout for a connection-try in connect()?

Andreas

Andreas,

Suprising we have not seen this before. I'm going to play around with it more. Are you using a static IP address?

You can reduce the connect timeout via the cfgAddEntry with the CFGITEM_IP_SOCKTIMECONNECT option.

Todd

Hi Todd,

on the OMAP (client) we are using a static IP address, configured as follows:

int addrIP = 0x031FA8C0; // 192.168.31.3
int port = 12002;
sin.sin_family      = AF_INET;
sin.sin_addr.s_addr = addrIP;
sin.sin_port        = htons(port);

socketToPC = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
connect(socketToPC, (PSA)&sin, sizeof(sin));

On the BlackFin (server) with the lwIP we use a static IP address, too.

Can you give me more information how to configure CFGITEM_IP_SOCKTIMECONNECT to reduce the connect timeout? In the document spru524_pg (NDK Programmer's Reference Guide) I found a small discription about CfgAddEntry() and the SockTimeConnect-option, but I don´t understand how and where I can implement this configuration in my SysBios-project for the OMAP.

Andreas

Hi Todd,

thanks for your help. I add

var Ip = xdc.useModule('ti.ndk.config.Ip');
Ip.socketConnectTimeout = 5;

to my *.cfg-file of my project and the connection-timeout is reduced to 5 seconds. This is a good solution for my problem.

Your question: After the second and third OMAP restart after a SYN-request from the OMAP the PC (and the lwIP-Stack on the BlackFin, too) sends a dublicated ACK as shown in the screenshot in the first post in line 5 and 7 (In line 1, 4 and 6 are the SYN-requests from the OMAP, only after the first SYN-request the connection is successful established).

Andreas