[WORKING] New ADSBExchange base image v1.0

Just FYI - I'm not trying to get to a zero-write/read-only file system point... and I'm OK with the cards dying from time to time. I just want to prevent "stupid" writes - hitting the card every 5 minutes to log how many aircraft are currently being tracked is worthless information. There's no sense in chewing up the limited writes that these cards have on BS.

 

I concur! Read-only IoT appliance is tempting though....

 

Aggh... IoT... so much fail!

 

You don't want to be connected to everything all the time so the Chinese can steal your bank account numbers through your automated fish tank thermometer? Are you from the stone age?

 

Nope, not in the least. I'm a full-time cybersecurity guy who purposely dumps all that IoT shit (which can be handy... I like my Nest thermostats, etc.) in their very own isolated VLAN so they can't even make a run at my internal stuff. Nor do I do anything with Dropbox and the like!

 

Something else I've noticed... the 15m system load doesn't seem to have much of a basis in reality. Here's the uptime values:


BTW, in other news, I sent in a custom feed update request... hasn't happened yet. Did I foul something up? I'm on 51295.

 

No keep feeding 51295 ... I'm just swamp and it takes about 4 hours to update those damn custom ports.

I have no idea .. I'm just pulling from what the Pi is telling me using ....

https://github.com/prometheus/node_exporter

 

Wiped and started fresh - some findings based on the most recent build (1.27)

- After configuring your adsb config on the SD card before inserting it into the Pi and starting up - the "feeder name" - should not just be "feeder name" -- is there a place to determine the correct name to use here? Is it user defined (use whatever you want), or something else?

- Watching the console of the TTY, I am getting "No binary formatter available, falling back to text format" every so often from rc.local. Also, it spews some stats every now and then (receiver status: connected, server status: ready, Receiver: 141 msg/s received...." that sort of thing.

- Noting my dump1090 web page, I am seeing a lot of 0 heading (track: n/a) on MLAT... am I doing something wrong, or are there just not enough MLAT enabled feeders nearby me to calculate heading properly?

- I like the custom maps, but I wanted to add a few feeders on, because some of those other feeds offer free access to their pay-level sites (flightradar24, flightaware), but in the interest of sharing, plane finder and radar box... where I went wrong with this before I wiped was that both the adsbx custom build and flightaware (.deb install) both want to use port 80 on the http server. It's probably just a matter of editing adsbx to something else before the FlightAware client, finding their config, and changing it back afterwards.

I guess for now, I'm mostly interested in how to debug the Track: N/A issue on my mlat. If I ps -ef |grep mlat, I see the mlat command line running:

It has /mlat-client --privacy --input-type dump1090 --input-connect localhost:30005 --lat (my lat) --lon (my long) --alt (my alt) --user adsb-jamcc_f01272_1.26vlan --server feed.adsbexchange.com:31090 --no-udp --results beast,connect,127.0.0.1:30104

Thanks...

 

- not sure what you mean by feeder name ... but config file has a parameter for MLAT feeder name and is user defined ... please no spaces .. MLAT client seems to hate that and I don't have it corrected in 1.27 yet "custom_name" is fine; "dingle flop" is not. I think.

- "No binary formatter available, falling back to text format" - that's fine

- I'm not sure of that honestly. Dump1090 should take care of it and there has been some discussion. It used to work then suddenly stopped.

- meh, not interested in $40/mo fleet tracking crap that is of no real use but I guess it makes people feel better. Yes, FA and FR24 install and try to take over the pi control; which is why I don't feed them and didn't add them to the image. There is a tutorial on how to feed FA from this image; apparently it now breaks it because of whatever it tries to do. I honestly have more important things to do that try to fix FA crap until the next update when they break it again. I'll look at it when I have time again for the next revision.

 

You might try disabling the fa-dump1090 webserver? ADSBx image uses lighttpd as webserver ...

 

Thanks. I’ll tinker tomorrow some more. Appreciate your response.

 

No problem.

 

I had no issues adding all the other feeders... they all detected an existing dump1090 running, used the standard port, and didn't try to install anything. As far as the "pi control", I strip out all the zerotier and FA control stuff anyway... my network is my own.

 

You can't really strip out the FA control stuff if you are feeding FA, as far as I know, the fa-client itself uses TCL/TCK tunneling for bidirectional communication with FA.

If you want to remove ZeroTier

sudo apt-get remove zerotier-one

 

I've been doing a little tweaking to minimize SD card writes, figured I'd share it here if it's useful:

Disable swapping entirely, just in case (obviously, if you do something that exhausts RAM, this will be a problem... but nothing we're running is RAM hungry anyway - Grafana/Prometheus are actually the worst offenders)
sudo dphys-swapfile swapoff
sudo dphys-swapfile uninstall
sudo update-rc.d dphys-swapfile remove

PlaneFinder isn't well behaved on log files - it wants to write to /var/log/pfclient and can't be changed. So, dump it into RAM by adding this into fstab, then mounting:
tmpfs /var/log/pfclient tmpfs defaults,noatimes,size=64m 0 0

I also used the above to create another RAM drive at /var/log/tmp, where I'm dumping all the other logs.

Fix PiAware - edit /etc/rsyslog.d/piaware.conf and change the destination to /var/log/tmp/piaware.log
Fix RadarBox - create /etc/rsyslog.d/rbfeeder.conf by copying piaware.conf, change the programname to 'rbfeeder', change the destination to '/var/log/tmp/rbfeeder.log'
Fix OpenSky - create /etc/rsyslog.d/openskyd.conf by copying piaware.conf, change the programname to 'openskyd-dump1090', change the destination to '/var/log/tmp/openskyd.log'

The last issue is the grafana DB and session file... I'll experiment with that later.

BTW, this command, run as root, lets you see whatever has been modified in the last 60 minutes (and avoid stuff you don't care about) which can be handy for this process:
sudo find / -path /sys -prune -o -path /proc -prune -o -path /run -prune -o -mmin -60 -type f | more

 

Everything that James said is true. The ONLY reason I contribute data to FR24 is for the Account they give to feeders. The business account lets you search up to 1 year of history (maybe more). Now all be it that history is limited based on what they choose to provide, but for lots of just general research it is usable. Also with that level of account, you get all of the alerting and such that is available on the FR24 app. FR24Premium app (abandoned but still works). Just something to think about.

 

I think we could build an Alert type system eventually.

I'm not sure about the FR24 database - but we do offer a complete flight history search going back to when we started saving it (July 2016).

https://flight-data.adsbexchange.com/

With our API - in theory you could build your own alerting system and much more.

https://www.adsbexchange.com/data/

There have been more pressing things I needed to fix and build, but if anyone wants to start coding - ADSBx will host it!

 

If you delete the ZT ID, just like SSH .. on boot it will regenerate the unique ZT ID. At least it should. Unless I messed up the latest image in a rush. <derp>

There is a script called resetpi.sh ... something like that - it should take care of it.

 

resethispi.sh

Code:

#! /bin/bash


if [ $(id -u) -ne 0 ]; then
  echo -e "This script must be run as root. \n"
  exit 1
fi

echo -e "\n\n RESET ZT"
rm /var/lib/zerotier-one/identity.*
echo -e "\n SSH ZT"
rm /etc/ssh/ssh_host_*
echo -e "\n RESET WPA_SUPPLICANT CONF"
rm /etc/wpa_supplicant/wpa_supplicant.conf
echo -e "\n REMOVE BASH HISTORY"
rm .bash_history
echo -e "\n COPY DEFAULT CONFIG adsb-config.txt.bak to /boot"
cp adsb-config.txt.bak /boot/adsb-config.txt