dump1090-fa still working locally - but not connecting to FA

FlightAware ADS-B Flight Tracking
1

I’ve seen somewhat similar issues others have had here in the forums, but I didn’t find a real explanation as to what happened.

I had two PiAware 3.5.0 setups running from my house. One was ADSB+MLAT, other was ADSB-only (to avoid port-forwarding conflicts). The second Pi is destined to go to a location quite remote to me. (I have 4 other remote sites established now). Last night (July 17, 2017-03:00 UTC to 04:00 UTC) there appears to possibly have been either a local internet outage, or possibly an issue with FA servers…I’m not sure which, but a void in the daily stats only showed up for the two devices physically located here at my place (so I suspect local ISP).

I noticed midway through the day today that one device had come back up, but the other had not. I have MAC/DHCP reservations set up so they will reconnect wirelessly when powered cycled. I tried a physical disconnect of power several times on the second Pi (ADSB only) , but the Pi never establishes a connection with the FA servers. It does, however, work every time on my local network via PiAware SkyView. ADSB working fine…multiple aircraft seen, so the FA Blue dongle appears fine. {The first Pi which has ADSB & MLAT running has been working fine}

This one has me a bit baffled. I haven’t physically grabbed the SD card yet to check any logs on there (lazy), and I could simply re-image the card and I feel pretty confident that would clear up the issue. However, if this occurs again at the site which is several hours from me and essentially unattended, it might take some time for me to get there to get it back online. That would be both a time and gasoline waster.

No commands can be sent from the FA servers via the "Site Information Page’, nor can I remotely view the logs as there seems to be no connection being made of any sort between the Pi and FA servers.

Anyone have any thoughts as to what might have happened/changed? …and what is preventing a reconnect upon power-cycle?

thanks

2

The 3am-4am outage was a problem on the FA side

You have a bunch of sites - which are the ones affected?

The local logs are the place to look, if it’s not connecting to FA then there’s not much I’ll be able to tell you.
I would strongly suggest you sort out a remote admin mechanism (be it ssh + dynamic DNS or whatever) before putting a Pi anywhere you can’t easily get at it.

3

Most likely, due to recent changes/outage at Flightaware, a new feeder “Unique identifier” has been assigned to your Pi, and this new feeder I’d is not linked to any of your existing sites. To overcome this problem, follow the procedure below.:

First chose one station. Find and note down this station’s “Unique Identifier” from your stats page:

flightaware.com/adsb/stats/user/blacktop

The “Unique identifier” is in the format “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”.

Now check what is the “Unique identifier” in your selected station’s Pi’s cache:



cat /var/cache/piaware/feeder_id

Compare the two “Unique identifiers”. If they are different, follow the steps given below:



#delete the wrong "Unique Identifier" in Pi's cache. 
sudo rm /var/cache/piaware/feeder_id

#assign "Unique Identifier" by piaware-config command below
# replace “12345678-1234-1234-1234-123456789abc” by Unique Identifier of your existing station

piaware-config feeder-id 12345678-1234-1234-1234-123456789abc 

#restart piaware 
sudo systemctl restart piaware

After waiting few minutes, reload/refresh your Flight aware stats page

“Unique Identifier” is the one circled in red in the screenshot below.
https://s20.postimg.org/uf02u0ipp/2017-07-17_20.53.07.jpg

4

A friend noted the FA MLAT problem today and got hold of me, so we rebooted as many sites as we could and they all came back up okay (except the one running ADSB only). My FF 32576 site I assume will be managed by staff and rebooted if I don’t get to it right away(?)

The two I had running at the house here were 33858 (ADSB & MLAT enabled) and 39197 (ADSB, MLAT disabled). The 33858 Pi came up okay, but the other is refusing to connect. I’ll grab the logs soon and post them here for your perusal. I’m still just scratching the surface of Linux commands…but i see the value of having a good remote administration mechanism…especially now that the sites are being established further afield.

You might see that site 32756 is down, and has been for a couple of days. That is a totally unrelated ISP change. I’m having a DNS issue of some type with the new provider, but will have that sorted out soon.

I’ll grab the logs and post here shortly…
thank you

5

Thanks abcd567…this is making sense now. I`m off for some shuteye for an early morning, but I will try your solution tomorrow and let you know how I make out.
cheers!

6

I looked at 39197 and as abcd says it is a case where you had two Pis configured with the same feeder ID, currently both will be trying to feed to the same site.

I’d be interested to know how that happened - I’m guessing you cloned a sdcard at some point?

7

Actually, I don’t think I did anything at all. When the first instance of MLAT recently stopping had occurred, I was alerted by a friend who was the first to notice. I had done a reboot of 38358 an 42301 remotely. I didn’t even look at 39197 as I have MLAT disabled on that feed (I had been using that site mobile, trying to find more locations that I can grab signals from runway-level…I have it just reporting ADSB…mostly to keep it alive until the next foray).

When I got home from work I checked the stats and noticed that 38358 was not connected and tried to reboot a number of times via power cycling, but it never would. I did not write any sd cards or tried anything other than simple reboots. I wonder if the fact that both Pi`s are on the same public-facing IP, that it caused an issue somehow…

I`ll try to grab the logs for you…

8

Hi abcd567 and obj,
abcd567, I tried your solution of clearing the cache and writing the proper unique ID back to the device. It worked fine and immediately started communicating with the FA servers.

Actually, obj, I think you might be correct about writing the SD card for this particular Pi from an image I made of another Pi. It took four months for the problem to show up, but now that I know the issue, I’ll watch for that in the future.

thanks,
blacktop