Dump 1090 stopped aufter 3.7.1 upgrade

FlightAware ADS-B Flight Tracking
1

Hi there
Today, I upgraded to flightaware 3.7.1 using the web interface. I also upgraded raspian with apt-get update/upgrade.

Now dump1090-fa does not work anymore. I get an empty map. Everything else still works. What could be the cause?

$ piaware-status
PiAware master process (piaware) is running with pid 17783.
PiAware ADS-B client (faup1090) is running with pid 17811.
PiAware ADS-B UAT client (faup978) is not running.
PiAware mlat client (fa-mlat-client) is running with pid 17820.

airspy_adsb (pid 291) is listening for connections on port 30005.
no program appears to be listening for connections on port 30978.
faup1090 is connected to the ADS-B receiver.
faup978 is NOT connected to the ADS-B UAT receiver.
piaware is connected to FlightAware.

got 'couldn't open socket: connection refused'
the ADS-B data program at localhost/30005 is producing data on localhost:30005.

$ uname -a
Linux piaware 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux

$ systemctl status piaware
â—Ź piaware.service - FlightAware ADS-B uploader
   Loaded: loaded (/lib/systemd/system/piaware.service; enabled; vendor preset: enabled)
   Active: active (running) […]
   CGroup: /system.slice/piaware.service
           ├─17783 /usr/bin/piaware -p /run/piaware/piaware.pid -plainlog -statusfile     /run/piaware/status.json
           ├─17811 /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --    stdout --lat 47.052 --lon 7.343
           └─17820 /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --input-type     auto --results beast,connect,localho

May 22 20:10:27 piaware piaware[17783]: mlat-client(17820): Beast-format results connection with ::1:30104: [Errno 111] Connection refused
May 22 20:10:49 piaware piaware[17783]: 77694 msgs recv'd from airspy_adsb (850 in last 5m); 77694 msgs sent to FlightAware
2

Did you use the airspy-conf script?

Maybe dump1090-fa is not starting because port 30005 is already used.
Best not to use 30005 and use some other port instead.

Then use piaware-config and set receiver-type to relay and point it at the airspy_adsb output.

3

No I did not use the config script. The system was perfectly working before and I wanted just an upgrade without configuration changes. What kind of configuration changes are necessary for 3.7.1?

I was using receiver-type other. Changing to relay does not make a difference.
When I use a different port such as 12345 I loose the radio connection, things get worse.

4

That setting was changed, it now deactivates dump1090-fa.
(don’t know why you’ll have to ask @obj)

You’ll have to reconfigure airspy_adsb to another listen port, for example 29999.
(also remove the connecting to 30004, relay will shove data into dump1090-fa by itself while also providing it to piaware)

Then change the piaware-config options to

receiver-type relay
receiver-port 29999
receiver-host localhost
5

@obj

I found the problematic commit:
Set ENABLED in /etc/defaults/dump{1090,978}-fa to control whether the… · flightaware/piaware-support@dc44a78 · GitHub

Not quite sure what the rationale was for deactivating dump1090-fa when “other” is set.
As it was running in net-only mode before i’m not sure what the benefit is?

6

“other” means “hey I am going to provide data in some way that is not managed by piaware / the sdcard image, and I don’t want the sdcard image to manage the local skyview either”. It is the most basic mode, where the only thing that happens is that the piaware feeder part gets data from where-ever you say and sends it to FA, but otherwise doesn’t do anything else.

vs “relay” which means “I am going to provide data in some other way, please arrange for it to be relayed to a local skyview & piaware”

1 Like
7

Thank you for the explanation. If I run the above commands I still do not see planes in dump1090-fa. Instead I get:

$ piaware-status
PiAware master process (piaware) is running with pid 23097.
PiAware ADS-B client (faup1090) is not running.
PiAware ADS-B UAT client (faup978) is not running.
PiAware mlat client (fa-mlat-client) is running with pid 23125.
Local ADS-B receiver (beast-splitter) is not running.

no program appears to be listening for connections on port 30005.
no program appears to be listening for connections on port 30978.
faup1090 is NOT connected to the ADS-B receiver.
faup978 is NOT connected to the ADS-B UAT receiver.
piaware is connected to FlightAware.

got 'couldn't open socket: connection refused'
Local ADS-B relay is NOT producing data on localhost:30005.
got 'couldn't open socket: connection refused'
the ADS-B data program at localhost/29999 is producing data on localhost:29999.

I do not run an UAT receiver but I am worried about the “couldn’t open socket” error.

My airspy_adsb options are -c localhost:30104:BEAST -l 29999:BEAST -g 17 -p -m 20 -v

Did maybe something change in the required permissions?

8

Did you restart everything?

Also as i said remove this -c localhost:30104:BEAST from your airspy options.
(Not the reason for the problem but it would lead to dump1090-fa getting all messages twice)

This looks like you didn’t restart.

9

Hooray! I removed the -c localhost:30104:BEAST command, rebooted and dump1090-fa is working again.
However, I still have got 'couldn't open socket: connection refused' in piaware-status:

$ piaware-status
PiAware master process (piaware) is running with pid 431.
PiAware ADS-B client (faup1090) is running with pid 521.
PiAware ADS-B UAT client (faup978) is not running.
PiAware mlat client (fa-mlat-client) is running with pid 684.
Local ADS-B receiver (beast-splitter) is running with pid 424.

beast-splitter (pid 424) is listening for connections on port 30005.
no program appears to be listening for connections on port 30978.
faup1090 is connected to the ADS-B receiver.
faup978 is NOT connected to the ADS-B UAT receiver.
piaware is connected to FlightAware.

got 'couldn't open socket: connection refused'
Local ADS-B relay is producing data on localhost:30005.
the ADS-B data program at localhost/29999 is producing data on localhost:29999.
1 Like
10

That is just a check if there is a program producing data on 30978.

@obj
Any chance to get rid of the 978 MHz checks in piaware-status if it’s not enabled?
They produce confusion obviously :slight_smile:

Or maybe just clearly mark it UAT/978 MHz.

1 Like