No catch of TCP timeout

I am testing a disconnection of a tcp in node. I have an external computer connected to my node-red running on a pi. I set the the keep alive parameter on the pi set as

net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 2

I pull the ethernet cable out of the external computer after it has started reporting after a couple of minutes I got the following message on the console that I started node-red on.

9 Nov 16:10:12 - [info] Started flows
29 Nov 16:10:12 - [info] [tcp in:743745e5.05653c] listening on port 12000
29 Nov 16:10:12 - [info] [mqtt-broker:Data Server broker] Connected to broker: mqtt://localhost:1883

29 Nov 16:13:03 - [info] [tcp in:743745e5.05653c] Error: read ETIMEDOUT

So node-red detected the error.

I have a catch node set up to catch errors on the [tcp in:743745e5.05653c] using the selected node option. From the catch node I have a debug node but the msg never showed up anything.

Interestingly if I put the status node looking at the same "tcp in" when the connection is made I get 1 connection showing and once the error occurs I get 0 connections.

Anyone got an idea why I would not have seen the the error in the debug node? Should it not catch this condition?

And can someone tell me where/how to look for known defects so I can check that list out.

Are you looking at the complete msg with the debug node ?

Looking at node-red source, server errors are sent without a 2nd parameter in the node.send() call so are not caught by the catch node.

This is just the way it is.

(IMHO) I wouldn't like to say if this is something that would or should change (at least not until a major version update) unless it is considered a bug.

NOTE. the 2nd parameter of node.send is normally the msg and since TCP IN doesn't have a msg, this might well be by design.

yes I a looking at complete msg.

I did look at the link to the source however I am not a good enough JS programmer to follow the code.
IMHO ...
Generally when I think of a catch then all errors should caught it should not be dependant on if something exists or not. I have in the past done a similar action using python, wait on tcp messages. The try catch there would trap this error. I obviously think it is a defect.

Anyways what I think I will do is setup a watchdog message that if it does not show up then I know the link is down and can handle the exception. Once I get the watchdog again then I can clean things up. Not ideal but good enough for this application.

BTW you guys are incredible on the support.


This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.