TCP Not Connecting. Using CAsyncSocket

This is an advanced question. We are not newbies. Our program has been in commercial use for several years.
Please help us if you can. We are stuck.


We have a new customer that has three of our programs. Each program connects to about 60 TCP ports. Our code uses an CAsyncSocket derived class that has worked in many customers. We are the TCP server (we do the "listen"). We instantiate one class for each port. Some ports successfully connects to the other device. But other ports do not connect. Its always the same port numbers that connect and dont connect.

1) WireShark shows the other device is send "SYN" commands to us every few seconds. Apparently our computer is ignoring the SYN commands and is not sending the SYN ACK.

2) The Microsoft utility TCPView.exe shows these ports in "LISTENING" mode. but they are NOT "ESTABLISHED"

3) Our code does have an "OnAccept" handler. We know that this handler works, because some TCP ports connect. The OnAccept does not give an error. The OnAccept is not called for these non-connecting ports.

4) Our code is well written. We check for error codes at all place. We also check for NULL pointers when we allocate memory. No errors are occurring at this customer.

5) The Windows firewall is turned OFF.

6) This is a Windows 10 computer.


We can not figure out what is causing the problem. This computer has 2 built in NICs and both are being used. One NIC is connected to the customer's office network. The other NIC is connected to a separate network that links the equipment we are using. When we WireShark to this "other" network we can see SYN commands comming to us from the IP we expect it to come from. But our computer does not respond and the connection is not established.

On the ports that work, the SYN command is ack'd, connection is made and data transfers occur. This is all good.

We are wondering:
1) Is it possible that the LISTEN is occurring on only one of the NICs and not the NIC that we need? How does that work?

2) We have looked at the "route" table using the "cmd" command "route print". We don't understand thsi data we don't know if this is related or helpful or what?

3) The end-customer chose the actual port numbers. They are 60000 through 60011 and also 61000 through 61045. Could these port numbers be related to the problem. Should we change port numbers?

4) Or is there some other problem.


Please help us if you can. We are stuck.

I'd begin with the port numbers: since the firewall is OFF, try to play with other numbers including the default ones that Windows Sockets selects for you.