tnw07b is responding to pings but ssh connections are reset. I think the problem is an IP conflict. nmap does not look like a DSM: Oops, I made a mistake, nmap does look like a DSM. (Port 22 is ssh, 8888 is tinyproxy, 30000 is dsm. Xinetd check-mk 6556 is not listed I suspect because nmap does not scan it by default.)
[daq@ustar raw_data]$ nmap tnw07b
Starting Nmap 7.40 ( https://nmap.org ) at 2017-03-10 17:40 WET
Nmap scan report for tnw07b (192.168.1.146)
Host is up (0.055s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
8888/tcp open sun-answerbook
30000/tcp open ndmps
But And data are coming in:
tnw07b:/dev/gps_pty0 7 2 32 2017 03 10 17:41:25.874 03 10 17:41:41.036 2.04 0.142 0.925 69 80
tnw07b:/dev/ttyUSB0 7 22 16 2017 03 10 17:41:25.828 03 10 17:41:40.958 0.99 1.008 1.009 39 39
tnw07b:/dev/ttyUSB4 7 102 16 2017 03 10 17:41:26.368 03 10 17:41:41.434 1.00 1.004 1.005 38 38
tnw07b:/dev/ttyUSB7 7 32768 4 2017 03 10 17:41:26.049 03 10 17:41:41.049 0.20 4.772 5.228 17 30
...
[root@ustar daq]# netstat -ap | grep tnw07b
tcp 0 0 ustar:51968 tnw07b:43666 ESTABLISHED 9440/dsm_server
So something must have the wrong IP address. According to nagios, tnw07b was responding to check-mk requests until 2017-03-09 10:52 UTC, so something was plugged in then which replaced tnw07b, but I haven't figured out what it could be yet. I'm running nmap to see what other kinds of devices have the same open port signature as nmap reports abovehappened then which now causes network connections to be reset. Probably this system needs to be rebooted.