* Set all the ports in the services table we're not using to zero.
* Don't enable a table entry that's disabled but has a port defined. This allows us to use the table definition for the 30005 port for us to connect out to it.
Before this if dump1090 restarted for some reason then faup1090 will sit
there indefinitely "looking" stupid and passing no data to piaware,
even after dump1090 comes back up.
Much gratitude to Oliver Jowett (github user mutability) for the fix.
For faup1090 only the FlightAware service is enabled and we were shortening
the services table by using our own define of FAUP_NET_SERVICES_NUM and
having it set to 1.
Apps need to stick with the same number of services as defined by
MODES_NET_SERVICES_NUM in dump1090 because dump1090 support routine
modesAcceptClients loops on this constant to walk the services table.
Likewise we now define all the service ports dump1090 defines even though we
are not using them. We have configured them as disabled.
Version bump to 1.14.
faup1090 was using the wrong constant, MODES_NET_SERVICES_NUM, rather than
FAUP_NET_SERVICES_NUM, so it ran off the end of an array binding random
ports until failing when it tried to bind the FlightAware port a second time.
Thanks to Oliver Jowett (github user "mutability") for the fix.
* If faup1090 can't start because the 10001 port is already in use it will now
exit with an exit status of 98 (EADDRINUSE).
* Emit the faup1090 version number if faup1090 is run with the --help argument.
* Make wicked sure we don't come up on any other ports that we shouldn't be on.
* Add "install" argument to faup1090 makefile makefaup1090.
BUGZID:
* connects to dump1090 a la ppup1090
* extracts the data, filters, batches packets and compresses to use very littl bandwidth
* requires FA "ADS-B adept" software to actually move the data.
Oliver Jowett
Karl Lehenbauer
Karl Lehenbauer