PiAware 1.20-1 released

We’ve released PiAware 1.20 with the following improvements:

  • Greatly improved range and message rate by configuring dump1090 to use auto-gain rather than max gain (–gain -10
    added to dump1090 arguments). Sites allowing remote upgrade will be upgraded automatically. People running their own copies of dump1090 are advised to add –gain -10 to their dump1090 command line arguments to obtain these same improvements.

  • Allow piaware to upgrade a package (piaware or dump1090) even if the current version can’t be determined, like when it isn’t installed. Since previous versions of the piaware bootable image shipped with dump1090 but dump1090 wasn’t installed as a dpkg, piaware versions prior to 1.20 can’t upgrade dump1090 through the manual or automatic installer. (piaware 1.20 can.)

  • Make piaware exit if it asks for a restart of itself but didn’t die. This keeps us from having two copies of piaware running at the same time after an update if there is a problem terminating the prior version of piaware.

  • piaware’s process ID number is now logged in piaware shutdown messages so the log isn’t confusing if the old version is still exiting while the new one is already running. (People upgrading from 1.19-3 will still see the potentially confusing messages; future upgrades from 1.20-1 forward will have clearer log messages.)

  • When piaware is looking for a dump1090 control script in /etc/init.d, make sure it prefers like fadump1090.sh to fadump1090.sh.dpkg-old.

  • Bug fix to make renaming /tmp/piaware.out to /tmp/piaware.out.yesterday to be more likely to occur on the UTC day boundary.

  • This is a backend improvement but two bugs were fixed in the signaling service which makes both manual and automatic updates much more likely to actually happen when requested.

People installing from the Debian package can follow the instructions at flightaware.com/adsb/piaware/upgrade

We have generated an SD card image for 1.20-1 as well. To download and install the SD card image, follow section 2 of the instructions at flightaware.com/adsb/piaware/build

SD card users running 1.17 or above who have not disabled automatic upgrades and are online are being automatically upgraded to 1.20-1 and to dump1090 1.1-1. This process has already begun and should be completed by tomorrow. Also anyone who installed from the Debian package who has enabled automatic upgrades and has not already upgraded will be automatically upgraded as well.

NOTE - The PiAware SD card image no longer has the default password of “raspberry” for the pi user. The new default password is “flightaware”. This is intended to help thwart automated attacks against Raspberry Pis running Raspbian.

From a quick look none of the changes really affect piaware-mutability as they’re mostly around upgrade management / restarts / logging which piaware-mutability does quite differently. I’ll take a closer look over the weekend and put out a new version if only to suppress the warning in the control panel.

I am running dump1090-mutab and have my piaware allowing auto-updates. My software updated to 1.20 and i have no warning in my control panel. All is running smooth thus far.

Thanks for your continued efforts.

THANK YOU for changing the default password on the SD card image! The SSH honeypot I run on another Pi tracks 8 to 10 attempts per day to log in using pi/raspberry.

I’m also running dump1090-mutability; both those systems automagically updated to PiAware 1.20 without issues.

bob k6rtm

.

About that update to 1.20–

I have a development PiAware box, and a production PiAware box.

The development box is set to update automatically.

The production box, being a production box, I don’t want it to update until I decide to do it.

The interesting part – both boxes did the auto update, even though the production box is marked “Prevent auto-updating” on the flightaware stats page…

cheers–

bob k6rtm

Thanks for the report, and props for running a honeypot, Bob. Also thanks for the hard numbers on the attempts.

While most RPi’s are behind NAT or a firewall they are still of course vulnerable to an attack from the LAN and no doubt there are some places where someone might have a public IP and not even know it.

Mine was set to ‘prevent auto-update’ but apparently it updated itself to 1.20 anyway. No big deal for me but I guess not quite what was intended…

Mi Pi was set to auto-update.
The update worked, but then the Pi stopped feeding data.

It was still live and checked frequently but the data feed stopped.
Used the web-site remote reboot and that seems to have worked.

You probably want to set piaware-config -autoUpdate 0 and piaware-config -manualUpdate 0; this will prevent piaware acting on upgrade commands even if they do mistakenly arrive.

Hi, thanks for the report. As I said in another thread… “that should be impossible” :blush: If you could paste the contents of the files /etc/piaware and /root/.piaware, that’ll help. (We certainly don’t want to update peoples’ machines against their wishes.) -karl

While we are still looking to get to the bottom of anyone’s machine being upgraded when they had automatic updating disabled, our automated tool is now checking your box’s last piaware login message’s report of the auto-update flag and will not attempt the update if the box reported auto update disabled. (piaware itself should be disallowing the update, anyway, even if it was requested, if updating is disabled, and we are still looking to understand what happened, but this should prevent our side from attempting the update going forward.)

I suspect the confusion is that people are setting “Prevent auto-updating” in the My ADS-B control panel, but not in the local piaware settings.
If there’s a bug on the FlightAware side that sends upgrade requests contrary to the control panel setting, boom, upgrade.

I too, got upgraded when my ADS-B page is configured not to update. In the case of my primary feeder, I think something got messed up in the process. I started the morning to find that it hadn’t fed FlightAware since midnight. It was online, Piaware was running, dump1090-mut was running, but was not feeding Piaware. I turned off mut and resumed using Piaware 1090 and still it wouldn’t feed. I think the problem might have been caused by a failed upgrade. Everything was working fine until midnight. I was asleep, so it wasn’t me. :smiley: I ended up creating a new Piaware disk from the latest image. Then it worked. I’m not complaining, just reporting. I’m retired, so I don’t mind having a fire to put out now and again. Keeps me on my toes. :laughing:

I think you are correct there. I only changed the setting in the My ADS-B control panel and not on the Pi itself.

And for the record:



pi@piaware ~ $ cat /etc/piaware
set imageType piaware
set autoUpdate 1
set manualUpdate 1

pi@piaware ~ $ sudo cat /root/.piaware
cat: /root/.piaware: No such file or directory

Thanks for the great work.

Auto update worked.

Running OK with the new version.

Cheers Steen

how do i check the current version in ssh ?
i have auto update enabled, but my adsb says Anomaly report for piaware feeder with a mac address of b8:27:eb:86:d4:82:
This system is running piaware version 1.19. Piaware version 1.20 is current. Please upgrade to the latest version by visiting flightaware.com/adsb/piaware/upgrade.

well, did the command job, running latest now to.

Did any updates get pushed out today 02/11/15 around 3:30pm Eastern? My aircraft colors were back to the default and my
range rings were gone.

I have auto update off on my ADSB page. I have not been able to turn it off in the /etc/piaware file.

I am trying to use PuTTY and WinSCP.

Yes we were pushing out full updates yesterday to mitigate the GHOST exploit, and for older versions of Raspbian heartbleed and perhaps other stuff.

Your report has caused considerable consternation here and I offer my apology. Thank you for the thoroughness of your report including about /etc/piaware. There are actually two things that must have gone wrong for this to happen. The thing where you have it disabled through the website and that wasn’t honored I have a bead on and we can fix that immediately. A more subtle problem is why the client side accepted the request when it was configured not to, but we will investigate that to its conclusion as well. We won’t push any more updates until we’ve solved this.