SBL2e TCP connect and TCP write problems

[MrSteel]

Hi,

I have problems with my SBL2e module.
- When I am trying to connect to server I have to connect multiple times for connection to success.
- The bigger problem is that when the connection is up sbl2e module transmuting tcp bursts from different source ports not the same all the time.

My program example:

Code: Select all

InitializeStack();																				// Initialize stack
OSChangePrio(MAIN_PRIO);																		// Initialize OS Prio
EnableAutoUpdate();																				// Enable auto update
InitIRQUart( UART1, UART1_BAUD, 1, 8, eParityNone );
InitIRQUart( UART2, UART2_BAUD, 1, 8, eParityNone );
assign_stdio(UART1);																			// Assigne printf to port UART2
OSTimeDly(1);

unsigned int retry = 0;

if( tcp.Connected() )
{
	tcp.Close();
}
while( retry < 3 )
{
	if( tcp.Connect( IP, PORT, 40 ))
	{
		iprintf("Connected!");
		break;
	}
	else																	// Retry connection
	{
		retry++;
		iprintf("Error!");
	}
}

while( true )
{
	tcp.write("Code testing!", 13, 20 );
	OSTimeDly(20);
}

My question. How can I force SBL2e to always use the same TCP source port?
Other question. Is possible for rutine tcp.connect to return wrong response ? I did see in my logs that sbl2e did try to connect and did but sbl2e tcp.connect returned no connection made!

Best regards,

[rnixon]

You need to run wire shark to see what is going on for the first attempt.

Specifying the same source port should be avoided. It messes with the way TCP is designed to work.

There are 4 things that define a tcp connection: source ip, dest ip, source port, dest port. Standard tcp/ip stack operation on any computer device is to pick a random source port for a connect call. This is done to prevent connection problems in the event a connection is not terminated properly on either end (half-open sockets).

If you have a tcp connection, say host 'A' connects to hose 'B', and host A "goes away" without closing the connection (eg. crash, cable disconnected, power-off, etc), host B still thinks there is a connection for that combination of ip and port numbers. So it will not allow a new connection to occur for that same set of parameters until that socket is closed on host B.

What is the reason for having to specify the source port number?


If you do NOT specify the source port number, some ways to handle the situation of host B listening on a specific port number are:

1. A timer that after a certain period allows a new connection to bump the existing one. For example, if host B is listens 10.1.1.1 :3000 and has an active connection. Any new connection attempt to port 3000 will cause host B to close() the existing one and accept the new one. But the new one should not have the same source port number.

2. A timer on host B that closes the socket if there is no activity over a certain period.

Implementing both of these isn't a bad idea. The "bump" timer can be shorter than the timeout.