Socket programming using QNX 4.25

I have developed a TCP/IP client (QNX) program which requests communicates with ethernet TCP/IP enabled microcontroller based devices.

The devices at startup are configured with fixed (pre-decided) IP adrresses. The devices are programmed in listening mode and hence wait for connection request from client (QNX program). Once the connection is successfully established, client sends data packets. On receipt of valid data packet, device (non-qnx) returns a response packet to client program.

I have tested this TCP/IP communication on ethernet connectivity and everything is working fine. If the device or LAN switch is powered OFF, QNX client program tries to establish a new connection.

I then tried to conduct experiments on this connectivity by exception testing. I need help with the following :-

1.] What would happen if 2 of the devices on the ethernet network are started with same IP address? Will my QNX program communicate with one of the two devices or will it not communicate at all?

2.]If only one device is configured on network with IP address 192.168.0.3. My program communicates with it. Then I powered it OFF and observed that my program tried to establish a new connection. On power ON of the device, my program started communicating with the device. Then I again switched it OFF and observed that my program tried to establish a new connection. I powered on another device with same IP address and observed that my program failed to communicate with it. On running netstat -an, I noted that state of socket was FIN_WAIT_1 on QNX computer. On restart of the program, my program did not communicate with the device. Then I decided to restart Socket. On restart of Socket process, my program started communicating with the device. What does this FIN_WAIT_1 indicate and how to resolve this problem?

  1. if 2 devices have same IP, they won’t talk at all.
  2. FIN_WAIT_1 is a tcp status, it tells you in which stage is the connection. You problem (of restart the program but still no communication), probably have something to do with
    the SO_REUSEADDR socket option. You need to turn that on in your program. Check setsockopt() function call.

As per your suggestion, I tried to enable SO_REUSEADDR using setsockopt () function. But the observation is still the same.

Device 1 (IP 192.168.0.10) communicates normally when switched ON. On powering it OFF, state of socket is FIN_WAIT_1 and Send-Q shows 88. If the same device is switched on, it starts communicating and status of socket checges to ESTABLISHED. Instead of switching on Device1 another device configured with same IP is started, QNX program does not connect to it and status of socket remains as FIN_WAIT_1 and send-Q 88. The program starts communication with it only of Socket process is restarted.

Is there any way of monitoring status of socket from the program instead of netstat. Why is restart of Socket manager required? Will it be possible to initialise the settings from the QNX program?

I am totally stuck and feel that data communication using TCP/IP is not reliable (in case of abrupt termination of remote end)!!! Is it due to the our application program? Are there any more options which can be tried out?

To me, it sounds like you are not using TCP the way it was designed. Different machines (different mac addresses) with the same IP is certainly an error from TCP’s point of view. It will probably straighten itself out, but it will take a long time for all the appropriate timeouts to occur. I suspect one of your problems is the arp cache is wrong. Instead of restarting Socket, try flushing the arp cache (arp -f? maybe) and see if that helps.

You may want to read a good reference on how TCP works and what all the different states are. When a session is unexpectedly terminated, there are quite a few timeouts which have to occur before the “remains” of the session are cleared up.

You also never mentioned which version of TCP you are using in QNX4. There are two versions, the 4.25 version and a 5.x version (which I am not sure that was ever released - it might be in perpetual beta).

And yes, you should be able to get any book on socket programming and use the techniques listed to get info about various sockets - like all things unixy, Richard Stevens books are probably the best. You can also take a look at the source for most the BSD utilities dealing with TCP and see how they do it. QNX’s TCP is based on a BSD stack.

Rick…