Archived: Feed issues with 19-2

[abcd567]

Yes. This would be a good start. There is a reason that different software packages come in separate Debian packages. Mixing them up, and then using non-standard update mechanisms is a recipe for the very disaster that is taking place.

Actually all this interference by fr24feed to dump1090 is needed because of the setting "receiver=dvbt". If this setting is not there, most of the ownership and permissions isuues, and crisis caused by them will disappear.

[fr24-pad]

Actually all this interference by fr24feed to dump1090 is needed because of the setting "receiver=dvbt". If this setting is not there, most of the ownership and permissions isuues, and crisis caused by them will disappear.

Even with receiver=dvbt the packages could and should be separate. All the problems they're having are of their own creation, proper package management solved them long ago.

[abcd567]

Why receiver=dvbt?
Network mode (avr-tcp or beast-tcp) is much simpler.

[fr24-pad]

I agree. I use avr-tcp because I'm using dump1090-mutability 1.15-dev. I think the real problem is that the people building the packages are developers, not sysadmins.

[abcd567]

@fr24-pad

I have Pi24 image, and after auto-upgrade, it has dump1090-mutabilty ver 1.14. It works fine at "receiver=dvbt". Flightaware and Planefinder feeders also work fine in their default network mode.

When I change setting of fr24feed to "avr-tcp, 127.0.0.1:30002" or "beast-tcp, 127.0.0.1:30005", everything fails. The dump1090-mutability status shows running, but all feeders complaint of "no program available to listen at port 30005".

I edited file /etc/default/dump1090-mutability, and changed setting START_DUMP1090="no" to START_DUMP1090="yes".
This enabled start of dump1090-mutability at boot.
Rebooted.
Still same situation.

[abcd567]

This weekend, I will try a cleanup: remove all pieces of codes in various files through which fr24feed controls dump1090-mutability.

The first thing I will do is
sudo rm -rf /usr/lib/fr24/dump1090
Another thing is to edit file fr24feed.service and remove commands giving permissions/ownership of dump1090 to user fr24.
set dump1090-mutability to automatically start at boot

I expect this will result in failure of fr24feed on setting receiver=dvbt, but will work ok in network modes "avr-tcp, 127.0.0.1:30002", or "beast-tcp 127.0.0.1:30005".

[Nigelr]

I've read about the problems with dump1090 mutability but ca. 3 weeks ago my feed to FR24 using dump1090-fa stopped on one of my Pis and i've tried various things, without success, to get it feeding again. Dump1090-fa and the feed to fa and RB24 are working fine. All the feed to FR24 from my other Pi is fine and still working.

Any suggestions and advice would be gratefully received.

Thanks

[Oblivian]

I've read about the problems with dump1090 mutability but ca. 3 weeks ago my feed to FR24 using dump1090-fa stopped on one of my Pis and i've tried various things, without success, to get it feeding again. Dump1090-fa and the feed to fa and RB24 are working fine. All the feed to FR24 from my other Pi is fine and still working.

Any suggestions and advice would be gratefully received.

Thanks

Depending on confidence to fix if it breaks. Purge it and the config. Apt install only (!not script) and setup manually for avrtcp. But that may be broken going by last tests.

Sent from my XT1092 using Tapatalk

[abcd567]

NEW EXPERIMENT ON PI24 upgraded to v 1.0.19-13
Setting avr-tcp and beast-tcp were not working. Only dvbt was working.
Fixed by following method:

1. Permanently disabled fr24feed from starting/stopping/running dump1090-mutability
   

   sudo rm /usr/lib/fr24/dump1090

2. Permanently enabled automatic start of dump1090-mutability at boot
   

   sudo nano /etc/default/dump1090-mutability
   #changed "no" to "yes"
   START_DUMP1090="[COLOR="#FF0000"][B]yes[/B][/COLOR]"

3. Rebooted
   

   sudo reboot

4. Map at ip-0f-pi/dump1090/ is ok
   The FR24 status shows that at setting DVBT, it has failed.
   Changed setting to AVR(TCP), 127.0.0.1:30002.
   Now shows OK
   

   pi@raspberrypi:~ $ fr24feed-status
   [ ok ] FR24 Feeder/Decoder Process: running.
   [ ok ] FR24 Stats Timestamp: 2018-02-03 07:28:56.
   [ ok ] FR24 Link: connected [UDP].
   [ ok ] FR24 Radar: T-CYYZ9.
   [ ok ] FR24 Tracked AC: 4.
   [ ok ] Receiver: connected (2627 MSGS/0 SYNC).
   [ ok ] FR24 MLAT: ok [UDP].
   [ ok ] FR24 MLAT AC seen: 4.

   pi@raspberrypi:~ $ sudo systemctl status piaware -l
   ● piaware.service - FlightAware ADS-B uploader
      Loaded: loaded (/lib/systemd/system/piaware.service; enabled)
      Active: active (running) since Sat 2018-02-03 02:26:16 EST; 3min 45s ago
   ..........................
   ..........................
   Feb 03 02:26:53 raspberrypi piaware[531]: 20 msgs recv'd from dump1090-mutabi; 20 msgs sent to FlightAware

FR24 dump1090 deleted - dvbt failed.png FR24 dump1090 deleted - avr-tcp ok.png FR24 dump1090 deleted - Map ok.png

[AndreasWarby]

I had been using avr-tcp / 127.0.0.1:30002 for years and, in my case, the auto-update from 1.0.19-11 to 1.0.19-12 gave me this problem:

pi@piaware:~ $ /usr/bin/fr24feed-status
[ ok ] FR24 Feeder/Decoder Process: running.
[ ok ] FR24 Stats Timestamp: 2018-01-30 11:06:37.
[ ok ] FR24 Link: connected [UDP].
[ ok ] FR24 Radar: T-CYCV22.
[ ok ] FR24 Tracked AC:.
[FAIL] Receiver: down ... failed!
[FAIL] FR24 MLAT: not running ... failed!

I "fixed" this problem under 1.0.19-12 by instead configuring the receiver / host to
beast-tcp / 127.0.0.1:30005

With beast-tcp / 127.0.0.1:30005 in place, the auto-update from 1.0.19-12 to 1.0.12-13
went smoothly, with everything apparently working now and no interventions needed.

For reference here are the contents of my setup params:

pi@piaware:~ $ cat /etc/fr24feed.ini
receiver="beast-tcp"
fr24key="xxx"
host="127.0.0.1:30005"
bs="no"
raw="no"
logmode="2"
windowmode="0"
mpx="no"
mlat="yes"
mlat-without-gps="yes"

[abcd567]

Trying to install fr24feed on STRETCH, gpg key server failure

pi@raspberrypi:~ $ sudo -i
root@raspberrypi:~# gpg --keyserver eu.pool.sks-keyservers.net --recv-keys 40C430F5
gpg: keyserver receive failed: [COLOR="#FF0000"]No keyserver available[/COLOR]

[abcd567]

I now discovered that if eu. is removed from eu.pool.sks-keyservers.net in above post, the gpg key gets installed

pi@raspberrypi:~ $ sudo -i
root@raspberrypi:~# gpg --keyserver pool.sks-keyservers.net --recv-keys 40C430F5
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key C969F07840C430F5: public key "Flightradar24 <support@fr24.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1


root@raspberrypi:~# gpg --armor --export 40C430F5 | apt-key add -
OK
root@raspberrypi:~# mv /etc/apt/sources.list /etc/apt/sources.list.bak
root@raspberrypi:~# grep -v flightradar24 /etc/apt/sources.list.bak > /etc/apt/sources.list || echo OK
root@raspberrypi:~# echo 'deb http://repo.feed.flightradar24.com flightradar24 raspberrypi-stable' >> /etc/apt/sources.list

root@raspberrypi:~# apt-get update

[abcd567]

Raspbian STRETCH + dump1090-fa OR dump1090-mutability v1.15~dev + fr24feed ver 1.0.19-13

• Setting-1: OK
  receiver="beast-tcp"
  host="127.0.0.1:30005"
  
  
• Setting-2: FAILS
  receiver="avr-tcp"
  host="127.0.0.1:30002"
  
  
• Setting-3: FAILS
  receiver="beast-tcp"
  host="localhost:30005"
  
  
• Setting-4: Creates a mess.
  If by mistake setting is changed to receiver="dvbt", and fr24feed restarted or Pi rebooted, it creates a mess.
  - If you have dump1090-mutability v 1.15~dev, it gets replaced by ver 1.14
  - If you have dump1090-fa, it stays, but dump1090-mutability ver 1.14 also gets installed.
  
  After cleaning this mess, I safeguarded against future disasters by re-naming following 2 files:
  
  

  cd /usr/lib/fr24/
  
  sudo mv install_dump1090.sh  install_dump1090.sh.getlost
  sudo mv dump1090  dump1090.getlost

[MrMac]

SUGGESTION TO DEVELOPMENT TEAM

I feel it will simplify things if fr24feed:

• Does NOT install dump1090
• Does NOT control or take ownership of dump1090
• Does NOT control and change settings of dump1090
• Does NOT have option "DVBT"

Couldn't agree more. The de-facto standard today is for feeders and other clients to look for data at localhost:30005. I never let fr24feed control the decoder, normally avoiding a lot of this mess.

Another problem is that when fr24feed controls the execution of dump1090, the settings in /etc/default/dump1090-mutability are not used, causing a lot of ambiguity.

I also run all our Rpis in write-protected mode, preventing fr24feed from auto-updating. This saved more than 20 installations from being f***ed up by the latest buggy versions, so I can just wait for something that looks like a stable release.

Remove the "dvbt" option!

/M

[Oblivian]

Yeap. Still comes back to the original dilemma I suspected. Awful hard to keep dump1090 direct USB configs going when asked to completely pull/replace its existence when other stuff not using it in direct mode may rely on dropped files too from under our noses without manual intervention (hindsight would have been a lot easier to force it dead and give users a single working instruction or self install option to get going again..)

Certainly a case of too much automation with disregard :/

How's it go, KISS. Keep it stupidly simple.

Sent from my XT1092 using Tapatalk