Piaware lost TCP connection


#1

Hi,

Piaware lost the TCP connection to my Radarcape during a Radarcape firmware update. It was not able to reestablish the connection itself. I had to reboot Piaware via the SSH console.

Can this be made easier? I.e. try to reconnect to Port 10003 several times before final timeout or have a reboot button on the Piaware main page?

Also I have lost track of the web page that explained the meaning of the aircraft.json output (this was not on github). Could a help button on the Piaware main page lead to that page?

Other than that, it works very well and MLAT tracks are of super quality. :laughing:

Thx, Andy


#2

It should try to reconnect to port 10003 automatically. The journal will have gone since you rebooted but if you look in /var/log/syslog for beast-splitter entries there might be something interesting. (when receiver-type is radarcape, it is beast-splitter that actually connects to the radarcape).

Possibly the problem is that the radarcape went away without shutting down the TCP connection properly and beast-splitter didn’t notice? (As it’s not sending data, if the remote host just abruptly reboots then the connection can hang forever)

(edit: I expect that, if left alone, piaware would have eventually noticed the lack of traffic and tried restarting beast-splitter. But that takes over an hour before it kicks in)
(edit2: you can remotely reboot a piaware device via the FA website stats page)

The json docs are here (they are somewhat out of date, I haven’t updated them in a while): github.com/flightaware/dump1090 … ME-json.md


#3

Hi,

thanks for the link! Indeed, it was github …

The radarcape abort was brutal, I think the watchdog did woof, so there was no chance to do a orderly shutdown.

Andy


#4

I’ll look at making beast-splitter detect this a bit better. In radarcape mode there should be a status message about once a second, so if it doesn’t see that for a while it can assume the connection is hosed and try to reconnect.


#5

As a workaround here is a small python script (as a systemd service) that tries to restart beast-splitter when a radio malfunction is detected. It seems it works though I am not sure about the permissions when issuing the os.system call.


import json, httplib, os, threading

def check_radio_status():
    conn = httplib.HTTPConnection("127.0.0.1")
    conn.request("GET", "/status.json")
    r1 = conn.getresponse()
    jdata = r1.read()

    data = json.loads(jdata)
    status = data"radio"]"status"]
    if status != "green":
        os.system("sudo systemctl restart beast-splitter.service")
        print "beast-splitter.service restart executed"
    else:
        print "radio connection ok"

    threading.Timer(60.0, check_radio_status ).start()

check_radio_status() 


#6

FWIW there is a fix here: github.com/flightaware/beast-sp … f033a04fd5
(which will be in the next piaware sdcard release)

Also the status json files are available under /run/piaware/ and /run/beast-splitter/ if you want to grab them directly rather than via http.