Losing network connection on QNX 3.15 pc

Hello, I have several QNX pc’s that run an app called AUTONET, that acquires data from test rigs. I transfer the data using an FTP utility that is part of the APP. I transfer across the corporate lan to a pc running Windows 2019 server, that is on the same virtual subnet. Lately they some of the pc’s have been losing their connection, and I have to reboot to get it back. Usually when I boot, I get a message, “gethostbyname - unknown host”. But this is ok because when I get this message, it works fine, and will transfer files. But sometimes when transferring, it will be going smoothly for around an hour, and stop because the connection was lost. I then will get a message “gethostbyname - host name lookup failure”. The Autonet program has setup files, Host, Hosts, Networks, Gateways, but I don’t add any entries to them because it always worked anyway. Any help appreciated.

When you do the FTP transfers are you doing them by name or by IP address? If you are doing them by IP Address then it shouldn’t matter if gethostbyname fails because you are not doing DNS lookups. On the other hand, if you are doing the FTP by name, then I’d check to make sure the name server machine is not dropping off the network.

Also, I’ve never heard of QNX 3.15. Do you mean QNX 4?

Tim

Thanks Tim. We use the IP, so I figured that’s what “Unknown host” was. But “host name lookup failure” is what I see when connection is lost. QNX 3.15 is 2.21 in protected mode. I’m starting to suspect my server. I’ve been looking through the IIS logs, and I do see some codes.

Just some information to suppliment Tim’s answer.

The 3 in 3.15 usually means that this is QNX 2 running in protected mode. The number appears in the command “tsk info” and is available to programs. Drivers for example needed to know whether running in protected mode or not. Yes the same driver could work in either real or protected mode for QNX 2. However 3.15 would usually mean QNX 2.15 in protected mode, not 2.21, the last distributed version. It still could be QNX 2.21 (or 3.21) and mismarked having originally run with 2.15. There were also cases of products distributed with QNX in which the distributor labed QNX versions in their own manner. As I recall 2.15G was probaby the last version until the Y2K fixes were put in. Hmmm, actually they weren’t Y2K, they were 1996 fixes. 1980 + 16 years.

But getting back to TCP/IP, there were at least three different implementations of TCP/IP that ran on QNX 2. Without intending criticism, they were all fragile. The first was implemented with a board that had an onboard processor. A subsequent version was somewhat available from QNX although it required a very specific, though generic NIC. The last I recall Uwe Wannags was selling a version from Europe that might have been a little more generous with NIC card support.

TCP/IP was always a somewhat awkward add on given that QNX 2 as not Posix compliant. To have any idea if something was going wrong on the QNX side, we would need to know which implementation. Beyond this, I don’t know much about it. Ethernet and TCP/IP became much easier to deal with in QNX 4 and going forward.

I think you are probably much better off investigating the server side initially as if the problem is there, it will be much easier to handle.

I use Linksys Ether16 cards with NE2000 compatible driver.

Did you figure out if it was your server (by which I assume this is what your QNX machines are FTPing files to)?

If your setup has been running a long time (many years) it’s possible that cables, a NIC card or the router has degraded over time. In our lab we have a 48 port Netgear switch that dates from 2006 and several of the ports are ‘bad’ in that you get intermittent dropped connections so we’ve taped over them and use different ports. We’ve also replaced quite a few cables in that time period as well.

Tim

I did fix the hostname lookup failure. I had a DNS server address that was no more.

One more idea occurred to me, only because I diagnosed a similar behavior once. The enviornment consisted of two duplicate system which each used duplicate private IP addresses on a LAN, separated from the WAN by a router.

One system consisting of a few devices would be started and run for a while before one device would lose track of another. The problem turned out to be a misconnected ethernet cable on the 2nd system that bridged the LAN to the WAN exposing the private IP’s to the WAN. ARP packets from this system would eventually make their way into the failing system which would get confused as to where an IP actually was. Merely disconnected the misconnected cable solved the problem.