BufferedTcpObject Connect never times out

[davecove]

I am doing this on a SBL2e:

Code: Select all

while ( 1 )
{
	DestIP = AsciiToIp( "192.168.42.87" );
	DestPort = TCP_PORT;  // #define TCP_PORT 23334 is above
	iprintf( "Attempting to send to port\r\n");
	if (tcp.Connect(DestIP, DestPort, 40))
	{
	  iprintf( "Connection Succeeded. \r\n");
	  if (tcp.Connected())
	  {
		  iprintf( "Sending data to socket\r\n");
		  tcp.Printf("This message is from the TCP Client<EOF>" );
	  }
	  else
		  iprintf( "Socket not open\r\n" );
	}
	else
	{
	  iprintf( "*** Connection Failed. \r\n");
	}

	if (tcp.Connected())
	{
	 tcp.Close();
	 iprintf( "Closing socket \r\n");

	}
	else
		iprintf( "Socket not connected\r\n" );

	OSTimeDly(20);
}

If I run it with a server process listening on a nearby networked PC I get this over and over in MTTTY (expected)

Code: Select all

Attempting to send to port
Connection Succeeded.
Sending data to socket
Closing socket

I also do see the message 'This message is from the TCP Client<EOF>' delivered on the server process output. (also expected)

If I run this without the server process running on a nearby networked PC I get one of these and nothing else (unexpected):

Code: Select all

Attempting to send to port

Where's my timeout? Why don't I ever see

Code: Select all

*** Connection Failed.

Thank you for your time,
Dave

[rnixon]

Just ran the SBL2e tcp client example on my system, took just a few minutes. When I specify an address without a server it does display the timeout message. Have you tried the example and does it behave the same way?

[davecove]

If I load and run the TcpClient example I get this:

Code: Select all

--- DEBUG MENU ---
C = Make a TCP connection
M = Send TCP message to Client
O = Display OS tasks
S = Display system information
T = Display TCP socket status
X = Close TCP connection
DHCP has assigned an IP address of: 192.168.42.91
Enter destination IP address: 192.168.42.87
Enter destination port number: 23334
Attempting TCP connection to 192.168.42.87 : 23334

Never times out...

[rnixon]

Strange, mine times out. What happens if you ping 192.168.42.87 from your pc?

[rnixon]

Also, what tools release are you using? I am using 2.7.1.

[davecove]

Code: Select all

Pinging 192.168.42.87 with 32 bytes of data:
Reply from 192.168.42.87: bytes=32 time<1ms TTL=128
Reply from 192.168.42.87: bytes=32 time<1ms TTL=128
Reply from 192.168.42.87: bytes=32 time<1ms TTL=128
Reply from 192.168.42.87: bytes=32 time<1ms TTL=128

How do tell what tools I have?

Dave

[davecove]

release_tag says 2.5.2

How do I get something more recent?

Dave

[rnixon]

My release notes say that is over 4 years old. I would definitely update. I do a lot of SBL2e stuff and the new features are definitely worth it. Log into your support account and use the Get Latest Tools link.

[davecove]

Ok, obtained the 2.7.1 release. No joy. (Hoping Tom Kenney sees this)

I uninstalled the old version, deleted c:/nburn and installed the new version. Then I created my own TcpClient project, imported the main.cpp and makefile from the SLB2E/TcpClient example folder, compiled it, and used MTTTY to load it on my SLB2e.

Same issue.

If I try to connect to an IP address that doesn't exist on my network, it does time out. If I point it at an address that is actually assigned to a running machine (Linux, Android or Windows, PC or Beaglebone, Virtual Machine or bare metal), and that does not have my requested port open (verified with a port scanner), it never times out. If the port is open, it does connect.

Here are a couple of WireShark traces between the SLB2E and the PC with the port open and closed. https://dl.dropboxusercontent.com/u/176 ... Traces.zip

Dave

[rnixon]

I ran that same test against my windows 7 machine and the SBL2e did work properly. However the trace is very different. I see the arp to get the pc's address, then the syn, then nothing. Windows doesn't arp and send a rst to the client on a port that it is not listening on.

It would be a really interesting data point if you could try that on a non-vmware machine and see if your results change. Maybe vmware listens on all ports at some level, then does a rst. I'm not saying that the SBL2e should not timeout in that case, but it may shed some light on the problem.