Getting "connect ECONNREFUSED" on connection attempt

[j2inet]

I have some code that has been working for the past couple of years. Today, across several machines, it stopped working. The code hasn't changed, but there was an update to the Phidget driver.

In tracing the failure, it occurs in a block of code that looks like the following.

The exception that occurs is

Code: Select all

{
   "name":"PhidgetError",
   "errorCode":35,
   "message":"connect ECONNREFUSED ::1:5661",
   ...
}

Here is the code.

Code: Select all

var phidget22 = require('phidget22');
    connect() {
        var self = this;
        var conn = new phidget22.Connection(5661, 'localhost');
        conn.connect().then(()=>{
        ....
        }).catch(e=> {
               console.error(e);
               throw e;
        });
     }

Any idea what could cause this?


UPDATE 2023-08-17

This issue is currently resolved. While I don't 100% know what caused it, I will note that the JavaScript libraries appear to have a range of driver versions with which they are compatible. This solution is a couple of years old, and it is possible that one of those compatibility boundaries was crossed. In response to the updated driver, I ended up updated the node library version and making small updates to code because of the change in the name of a class from a previous JavaScript SDK version to the current version.

[mparadis]

This could be caused by a mismatch in library versions- are both the computer running the code and the computer with the Phidgets connected running the same version?

[j2inet]

Initially they were. I thought that they two might be misaligned through the automatic driver updates. Comparing the code that we have to the code that is provided for examples, I did see a difference. Modern code creates a new phidget22.NetworkConnection instead of a phidget22.Connection. I tried updating drivers on all machines and node libraries on all machines to the latest version. I adjusted the code to use the modern method of connecting. Aligning the driver, node library, and JavaScript code had no effect on the machines of interest (I was able to recreate the issue and resolve it on my home machine using the above approach). I should mention I'm on the East coast and the machines of interest are 2,000 miles away on the West coast, and some of the simple testing such as removing an RFID tag from a reader must be done through sending requests to people on site.

Using some network tools while the machine was in a state in which the ECONNREFUSED error was being produced, I did find that port 5661 was actually open and I was able to arbitrarily open a socket connection to it. I wasn't able to probe further since I know nothing of the protocol that the Phidgets Network Server uses.

I find it a bit perplexing that the machines with identical code are presenting different results.

[j2inet]

Issue Resolved

I've gotten things working again, though I don't know what the actual problem was. Now that things are working again, I'm disabling "Automatic Check for updates" and asking that no one else ever allow one of these machines to update the drivers outside of new code development (Somewhere, a security professional read that sentence and died a little inside). Since I am about to end my efforts to support this client and this custom app, I'm compelled to leave the system in the most stable state that I can.


I have however noted that a few oddities exists.

Sometimes when I try to open the Phidgets Control Panel, the window will appear and then immediate disappear. It isn't minimized, it isn't behind another window. The process just isn't there. I sometimes have to reboot to make the window appear.

When the Phidgets control panel does appear, the network pane often renders blank. This occurs irrespective of whether the Phidgets Network Service is running or not. Thankfully I don't need to change any settings in there other than ensure that the services are running, which I end up doing with the Windows Service applet.

The resulting run setting for the service is not predictable after a drive update. Sometimes it remains set to automatic, other times it gets reset to manual. I noted this because there are 4 machines in which I am performing the same tasks in parallel. During an upgrade I also notice that some machines would ask that the service be terminated, and other machines don't.

Weird. But weird with workarounds.

I'm just happy to get things responsive again. I'm updating the original post in the hopes of making it more helpful to others.

[Patrick]

Would it be possible to get a copy of the network server logs from the failure period? It may be overwritten by now, but this would help me track down the issue.

C:\ProgramData\Phidgets\logs\Phidget22NetworkServer_networkserver.log

Thanks,
-Patrick