Ping node not propagating msg.payload if failed to ping

[tdlo]

Hi,

I’m using the latest released Node-Red for HA add-on (v7.0.0). It works great for pretty much all of my flows but one so far.

For some reason, the Ping node will propagate the payload fine when it can ping the address, but it fails to propagate anything when it can’t. I’m using the ping to check my Internet connection. After failing several times, the flow is supposed to reboot my modem.

I know the rest of the flow works fine, as I can inject both positive and negative (false) messages to the rest of the flow and everything works.

What I find interesting is in the Node-Red log, I’m getting the following log when the ping fails:
[info] [ping:Test Internet access] ping - Host '1.1.1.1' process timeout - sending SIGINT

I don’t know if that log entry is normal, but seeing as how it is not sending any values to the debug node when it can’t ping leads me to believe something else is wrong.

The properties of my Ping node are:

Target: 1.1.1.1
Mode: Timed
Ping (S): 20 (I've tried large and small values here)

Like I said, the rest of my flow works fine (including positive pings), but I’m providing a screenshot of the beginning part of my flow anyway just in case.

Also, if it helps, I’m running: HassOS 4.11 on a VM with Home Assistant 0.113.3

Any suggestions are appreciated. I couldn’t find this particular issue in my searches.

[krviii]

I believe that when the ping succeeds it will return a payload of type number with a value like 23.5. when it does not succeed it will return a type boolean with a value of false does your switch take this into account? it would be helpful to see your inside your nodes, could you share an export of your flow?

also, you may want to ping a few different reliable servers to be sure they all fail before rebooting your router. I know 1.1.1.1 is really reliable, but even cloudfare’s dns server might be unreachable at times, that is why you always define a backup.

[tdlo]

Thanks for the really quick reply. I definitely should have at least included the code in the switch. I’ve exported the whole thing (less the notify nodes). I’m aware of the way the ping output varies depending on success or fail, and think I have that right, but you may see something I didn’t.

[{"id":"3cddf8bf.263148","type":"tab","label":"Flow 1","disabled":false,"info":""},{"id":"a0d84cce.73759","type":"ping","z":"3cddf8bf.263148","mode":"timed","name":"Test Internet access","host":"1.1.1.1","timer":"20","inputs":0,"x":170,"y":240,"wires":[["b623cd47.4bc5a","f0187957.afb998"]]},{"id":"f0187957.afb998","type":"switch","z":"3cddf8bf.263148","name":"Unreachable?","property":"payload","propertyType":"msg","rules":[{"t":"false"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":400,"y":240,"wires":[["69ee2c72.f27534"],["2e05b581.ccdcca"]]},{"id":"69ee2c72.f27534","type":"counter","z":"3cddf8bf.263148","name":"Retry counter","init":"5","step":"1","lower":"0","upper":"","mode":"decrement","outputs":"1","x":690,"y":240,"wires":[["f5b557d3.0bcb98","e01664c1.117718"]]},{"id":"75dbb5d8.e57c7c","type":"delay","z":"3cddf8bf.263148","name":"Rate limit cycling","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"15","rateUnits":"minute","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":true,"x":1130,"y":240,"wires":[["1d27d6b1.999099"]]},{"id":"f5b557d3.0bcb98","type":"switch","z":"3cddf8bf.263148","name":"Exhausted retries?","property":"count","propertyType":"msg","rules":[{"t":"eq","v":"0","vt":"num"}],"checkall":"true","repair":false,"outputs":1,"x":900,"y":240,"wires":[["75dbb5d8.e57c7c","f35f654a.e27088","2e05b581.ccdcca"]],"info":"If the count hits zero, then continue to cycle the modem and reset the counter."},{"id":"e01664c1.117718","type":"debug","z":"3cddf8bf.263148","name":"Counter value","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"count","targetType":"msg","x":700,"y":560,"wires":[]},{"id":"b623cd47.4bc5a","type":"debug","z":"3cddf8bf.263148","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":390,"y":120,"wires":[]},{"id":"f35f654a.e27088","type":"debug","z":"3cddf8bf.263148","name":"Retries exhausted","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":970,"y":560,"wires":[]},{"id":"1d27d6b1.999099","type":"api-call-service","z":"3cddf8bf.263148","name":"Turn off modem","server":"8eacddf5.e8655","version":1,"debugenabled":false,"service_domain":"switch","service":"turn_off","entityId":"switch.internet_modem_switch","data":"","dataType":"json","mergecontext":"","output_location":"","output_location_type":"none","mustacheAltTags":false,"x":1380,"y":240,"wires":[["6fbfe15d.bdfc4"]]},{"id":"2e05b581.ccdcca","type":"change","z":"3cddf8bf.263148","name":"Reset counter","rules":[{"t":"set","p":"reset","pt":"msg","to":"true","tot":"bool"}],"action":"","property":"","from":"","to":"","reg":false,"x":620,"y":320,"wires":[["69ee2c72.f27534"]]},{"id":"df788bd8.d66a58","type":"inject","z":"3cddf8bf.263148","name":"Test unreachable","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"false","payloadType":"bool","x":180,"y":420,"wires":[["f0187957.afb998"]]},{"id":"1bdda3d6.25ec5c","type":"inject","z":"3cddf8bf.263148","name":"Test reachable","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"true","payloadType":"bool","x":180,"y":560,"wires":[["f0187957.afb998"]]},{"id":"6fbfe15d.bdfc4","type":"delay","z":"3cddf8bf.263148","name":"Wait before turning on","pauseType":"delay","timeout":"30","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":1740,"y":240,"wires":[["8ed46477.af72e8"]]},{"id":"8ed46477.af72e8","type":"api-call-service","z":"3cddf8bf.263148","name":"Turn on modem","server":"8eacddf5.e8655","version":1,"debugenabled":false,"service_domain":"switch","service":"turn_on","entityId":"switch.internet_modem_switch","data":"","dataType":"json","mergecontext":"","output_location":"","output_location_type":"none","mustacheAltTags":false,"x":1980,"y":240,"wires":[[]]},{"id":"8eacddf5.e8655","type":"server","z":"","name":"Home Assistant","legacy":false,"addon":true,"rejectUnauthorizedCerts":true,"ha_boolean":"y|yes|true|on|home|open","connectionDelay":true,"cacheJson":true}]

Good point about multiple servers to ping. I should at least add Google’s 8.8.8.8 DNS as well, and only reboot if all of them fail.

[tdlo]

Just did more debugging. The rest of the nodes are irrelevant. If I remove them all (except a debug node for the payload) and change the ping to something that won’t return, like “1.2.3.4”, the debug node is getting nothing and I’m getting that log entry mentioned above. Seems like something more fundamental is broken.

[krviii]

ok, i think i figured it out. It doesn’t seem to work the way we are expecting if the ping node is configured as timed. If you change to trigged and then set up a inject node set to repeat interval of say 20 seconds it should work correctly.

[tdlo]

Oh man, I thought you were on to something with that work-around. Unfortunately it still fails being triggered. My guess is the actual ping execution (whether it’s shelling out to do the ping or whatever) is terminating in an unexpected way. I shouldn’t be too surprised with a 7.0.0 release of a product. I’m just not sure if I should open an issue for this, and if it’s native Node-Red or something to do with how it’s configured as an HA add-on.

[krviii]

I have an example running on my nodered install. Try it out:

[{"id":"45c9340f.f0430c","type":"ping","z":"13e8c46a.72c67c","mode":"triggered","name":"Test Internet access","host":"1.1.1.1, 1.2.3.4","timer":"20","inputs":1,"x":1325.0001068115234,"y":655.0000591278076,"wires":[["4fbb45d7.b36bbc"]]},{"id":"4fbb45d7.b36bbc","type":"debug","z":"13e8c46a.72c67c","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1523.500144958496,"y":655.0000324249268,"wires":[]},{"id":"a14ff556.d9b348","type":"inject","z":"13e8c46a.72c67c","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"10","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":1127.5000915527344,"y":655.0000591278076,"wires":[["45c9340f.f0430c"]]}]

let it run for 30 seconds or so watching the debug window. it ping 1.1.1.1 and 1.2.3.4, you should see the first one return a ping time and the second one return false. If that doesn’t work, let’s compare install version on the ping module etc.

[tdlo]

I solved the problem. Took some digging in the source code and docker container.

First, source code: https://github.com/node-red/node-red-nodes/blob/81039eacbca8cbccb9034d25a3e0251cb11df525/io/ping/88-ping.js#L29

From there I can see the command it runs is: ping -n -w 5 -c 1 host/ip

From the git history, it looks like it’s been that way for a while.

When I exec’d into my Node-Red docker container and tried to run that with an IP I know would timeout (like 1.2.3.4), it always took 10 seconds to return, even with -w 5. The source code then dumps a warning just as I saw in my logs, and in essence doesn’t count it towards failure or success. I have a feeling the original authors meant to use ‘-W’ instead of ‘-w’, as that seems to guarantee termination in 5 seconds no matter what.

Anyway, by using your suggestion of a trigger, I can fashion a payload that gives me control of the timeout. For example:

[
    {
        "host": "1.1.1.1",
        "timeout": 11000
    },
    {
        "host": "8.8.8.8",
        "timeout": 11000
    }
]

By setting the timeout to 11 seconds (just to give a bit of wiggle room in my case), failures and successes work just fine!

This leaves me with two questions/concerns:

• Should the argument have been -W all along?
• Perhaps more importantly, why is my docker container taking longer to return from the ping command? My setup is pretty vanilla, but maybe my home networking is causing a complication.

Thanks krviii for all your help and support, it lead me down the right path to working-around the issue!!!

[BertrumUK (Neil B)]

Getting the same issue - would you care to share your config ?

[tdlo]

I’ve posted the sample config above. Here are the two nodes at the beginning of the flow that deal with the slow ping fail time and testing Internet connection:

[{"id":"1e97e127.3d4b9f","type":"ping","z":"18e1c60f.609a4a","mode":"triggered","name":"Test DNS","host":"","timer":"20","inputs":1,"x":360,"y":160,"wires":[["62f9ec3d.a88874","7967f23a.63ce3c"]]},{"id":"53050d.b43eeaf4","type":"inject","z":"18e1c60f.609a4a","name":"Ping trigger","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"60","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"[{\"host\":\"1.1.1.1\",\"timeout\":11000},{\"host\":\"8.8.8.8\",\"timeout\":11000}]","payloadType":"json","x":130,"y":160,"wires":[["1e97e127.3d4b9f"]]}]

Make sure that the inject node interval (time between tests) is a decent size larger than the timeout you set for the ping(s) in the payload.

[BertrumUK (Neil B)]

Thanks for that - using it to monitor a friends BB and if there is an ICMP block applied on their router it was not detecting it, using your setup I now get “false” returned so the email alerts can be sent whenever it fails.

Cheers