Hello!
I’m testing the GenieACS as an option for our production environment for different CPE vendors. While doing this I’ve noticed, that some times the genieacs-ui worker crashes when accessing an overview of a specific device (see the stack trace below):
genieacs-ui[27427]: 2021-07-02T13:28:06.746Z [ERROR] Uncaught exception; pid=24706 exceptionName="TypeError" exceptionMessage="Cannot read property 'name' of null" exceptionStack="TypeError: Cannot read property 'name' of null\n at callback (/usr/lib/node_modules/lib/ui/api.ts:662:27)\n at null.<anonymous> (/usr/lib/node_modules/lib/ping.ts:88:5)\n at ChildProcess.exithandler (child_process.js:310:7)\n at ChildProcess.emit (events.js:375:28)\n at maybeClose (internal/child_process.js:1055:16)\n at Process.ChildProcess._handle.onexit (internal/child_process.js:288:5)"
genieacs-ui[27427]: 2021-07-02T13:28:32.820Z [ERROR] Worker died; pid=24706 exitCode=1
After doing a little debugging and digging in the code I’m pretty sure this must be a bug at least within the lib/ping.ts module, or even the lib/ui/api.ts as well, since from my point of view the ui worker process shouldn’t crash when one of the sub modules is returning a null value.
What is causing the ping.ts to return a null value, is an incomplete RegEx (at least for the linux systems, I couldn’t test it with freebsd) that is parsing the reply of the system ping utility, in cases where the pinged host sends back duplicate replies.
switch (platform()) {
case "linux":
cmd = `ping -w 1 -i 0.2 -c 3 ${host}`;
parseRegExp1 = /(\d+) packets transmitted, (\d+) received, ([\d.]+)% packet loss[^]*([\d.]+)\/([\d.]+)\/([\d.]+)\/([\d.]+)/;
parseRegExp2 = /(\d+) packets transmitted, (\d+) received, ([\d.]+)% packet loss/;
break;
case "freebsd":
// Send a single packet because on FreeBSD only superuser can send
// packets that are only 200 ms apart.
cmd = `ping -t 1 -c 3 ${host}`;
parseRegExp1 = /(\d+) packets transmitted, (\d+) packets received, ([\d.]+)% packet loss\nround-trip min\/avg\/max\/stddev = ([\d.]+)\/([\d.]+)\/([\d.]+)\/([\d.]+) ms/;
parseRegExp2 = /(\d+) packets transmitted, (\d+) packets received, ([\d.]+)% packet loss/;
break;
default:
return callback(new Error("Platform not supported"));
}
In case of a duplicate ICMP reply packet, the summary line of the ping unility will have an additional statistics for duplicate replies and the regular expressions specified whithin the ping.ts module don’t match the summary line any more.
Here is an example of a duplicate ping reply:
vm:~$ ping -w 1 -i 0.2 -c 3 192.168.0.113
PING 192.168.0.113 (192.168.0.113) 56(84) bytes of data.
64 bytes from 192.168.0.113: icmp_seq=1 ttl=62 time=11.8 ms
64 bytes from 192.168.0.113: icmp_seq=1 ttl=62 time=12.1 ms (DUP!)
64 bytes from 192.168.0.113: icmp_seq=2 ttl=62 time=11.0 ms
64 bytes from 192.168.0.113: icmp_seq=2 ttl=62 time=11.3 ms (DUP!)
64 bytes from 192.168.0.113: icmp_seq=3 ttl=62 time=10.5 ms
--- 192.168.0.113 ping statistics ---
3 packets transmitted, 3 received, +2 duplicates, 0% packet loss, time 401ms
rtt min/avg/max/mdev = 10.557/11.404/12.179/0.573 ms
… here is an example of a normal ping reply without duplicates, which is working fine with the ping.ts module:
vm:~$ ping -w 1 -i 0.2 -c 3 192.168.0.243
PING 192.168.0.243 (192.168.0.243) 56(84) bytes of data.
64 bytes from 192.168.0.243: icmp_seq=1 ttl=62 time=8.26 ms
64 bytes from 192.168.0.243: icmp_seq=2 ttl=62 time=8.41 ms
64 bytes from 192.168.0.243: icmp_seq=3 ttl=62 time=8.34 ms
--- 192.168.0.243 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 401ms
rtt min/avg/max/mdev = 8.267/8.342/8.411/0.095 ms
I know this is an edge case, that is probably not often seen in the wild, since in my case it’s caused by an defectiv ONT/OLT bridge configuration and can’t be reproduced that easy. But still I think it should be fixed for the sake of the software stability of GenieACS.
It would be great if some one could take al look at it …