# Genieacs-ui worker dies on malicios or unexpected ping reply **URL:** \ **Category:** Uncategorized\ **Created:** [July 2, 2021, 2:29pm UTC](https://forum.genieacs.com/t/genieacs-ui-worker-dies-on-malicios-or-unexpected-ping-reply/1825 "2021-07-02T14:29:23Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![d2u](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.genieacs.com/d2u/32/608_2.png) [@d2u](https://forum.genieacs.com/u/d2u)\ **Post date:** [July 2, 2021, 2:29pm UTC](https://forum.genieacs.com/t/genieacs-ui-worker-dies-on-malicios-or-unexpected-ping-reply/1825/1 "2021-07-02T14:29:23Z")
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): ```auto 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. (/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. ```auto 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: ```auto 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: ```auto 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 …