sdr-enthusiasts / docker-flightradar24 Goto Github PK

Seems to be an issue in 1.0.46-2_linux_amd64_nohealthcheck, not present in 1.0.46-2_linux_amd64_nohealthcheck where /usr/local/bin/fr24feed cannot be executed.

This originally manifested as repeating error in stdout:

2024-02-22T21:15:40.173261318+00:00 stdout F [2024-02-22 21:15:40.173][fr24feed] qemu-arm-static: /usr/local/bin/fr24feed: Invalid ELF image for this architecture

On further investigation, this was nothing to do with arm or invalid ELF images, but because the s6 scripts/fr24feed naively assumes that if /usr/local/bin/fr24feed --version doesn't run, it should try again with qemu-arm-static. Since the binary cannot be exec'd, the --version test fails, and the script incorrectly tries to launch an amd64 ELF binary with qemu-arm-static wrapper.

The simplest reproduction case demonstrating the issue:

Broken in 1.0.46-2_linux_amd64_nohealthcheck

[root@crow ~]# podman run -ti --entrypoint /usr/local/bin/fr24feed ghcr.io/sdr-enthusiasts/docker-flightradar24:1.0.46-2_linux_amd64_nohealthcheck --version
{"msg":"exec container process `/usr/local/bin/fr24feed`: Operation not permitted","level":"error","time":"2024-02-22T21:40:01.397735Z"}

Working in 1.0.46-1_linux_amd64_nohealthcheck:

[root@crow ~]# podman run -ti --entrypoint /usr/local/bin/fr24feed ghcr.io/sdr-enthusiasts/docker
-flightradar24:1.0.46-1_linux_amd64_nohealthcheck --version
1.0.46-1

Injecting strace into the latest image doesn't yield any interesting reason as to why the binary cannot be execve'd:

root@cbdd708c9c0a:/# strace -f /usr/bin/fr24feed
execve("/usr/bin/fr24feed", ["/usr/bin/fr24feed"], 0x7ffe73606cd8 /* 41 vars */) = -1 EPERM (Operation not permitted)
strace: exec: Operation not permitted
+++ exited with 1 +++

This is running on a host with selinux disabled, so is not an avc denial.

Hello,

my Flightradar24 Container (mikenye/fr24feed) is not running properly.

mikenye/readsb-protobuf is running and receiving flight data. But in my Flightradar24-log following error is showing up every few seconds and no data is send to Flightradar24.com

2021-11-25 19:11:31 | errno: 104
2021-11-25 19:11:31 | [reader][e]Configuration failed, please make sure the specified device is a unknown receiver

Any idea what the problem could be?

Regards

Hi guys.

Been using this container image for a while now, but recently noticed that the qemu-arm-static fr24feed and pfclient process is using a lot of CPU. Far more than any other feeder/readsb.
This is on an intel nuc so is amd64 architecture (and it's running the amd64 container arch), but it seems the fr24 binary is being run in an emulated arm mode.

Is it expected that the fr24feed & pfclient binaries are run using arm emulation?

Many thanks!

what value I should use in beasthost? I am trying to install it under docker while running Home assistant on a Rpi 4.

Since this morning MLAT Timestamp errors are back. The fr24 container remains in status 'starting'. Could you please look into it?

On a Raspberry Pi Zero W running Raspbian Buster the container fails to start (see: mikenyefr24feedlatest.log) and also the Build on the Pi Zero fails to complete (see build.log).

The build fails because the script can't detect the architecture:
+ echo 'ERROR: Unable to determine architecture or unsupported architecture!'
+ exit 1
ERROR: Unable to determine architecture or unsupported architecture!

If I comment line 40&47 of the script "deploy_fr24feed.sh" out and force it to use the armhf architecture the build runs through
and the container itself runs perfectly fine.

Therefore I suggest to edit the if-function in line 47 of deploy_fr24feed.sh to properly detect the Raspberry Pi Zero W.

Content of the variable FILEOUTPUT is:
FILEOUTPUT='/usr/bin/file: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=f57b617d0d6cd9d483dcf847b03614809e5cd8a9, stripped'

Similar to the stats page on port 8754, the UAT feeder exposes 8755, but the BIND_INTERFACE is apparently not writing to the UAT feed config as shown by the following error when I add port 8755 to the ports in docker-compose.yml

the stats page on 8754:

here's my docker-compose for fr24

  fr24:
    # fr24 feeds ADS-B and UAT data (from ultrafeeder) to FlightRadar24. It also includes a status website. Please be careful
    # not to expose the status website to the internet as users may be able to start/stop/change the service from there.
    # Also note that FR24 has requested NOT to enable MLAT for those station that feed to multiple services; as such, it's commented out.
    image: ghcr.io/sdr-enthusiasts/docker-flightradar24
    #    profiles:
    #      - donotstart
    tty: true
    container_name: fr24
    hostname: fr24
    restart: always
    labels:
      - "autoheal=true"
    ports:
      - 8754:8754
      - 8755:8755
    environment:
      - BEASTHOST=ultrafeeder
      - TZ=${FEEDER_TZ}
      - FR24KEY=${FR24_SHARING_KEY}
      - FR24KEY_UAT=${FR24_UAT_SHARING_KEY}
      - BIND_INTERFACE=0.0.0.0
      - UATHOST=dump978
      - UATPORT=30978
    tmpfs:
      - /var/log

I currently have this container running on my local network. However, I've been unable to get flightradar24 to detect the device in https://www.flightradar24.com/activate-raspberry-pi. Looking at the logs, it's connecting to flightradar24 fine:

$ docker logs -f fr24feed
[...]
2020-11-17 22:10:40 | info | [httpd]Server started, listening on 0.0.0.0:8754
2020-11-17 22:10:40 | [i]PacketSenderConfiguration::fetch_config(): Yoda configuration for this receiver is disabled
2020-11-17 22:10:40 | [d]TLSConnection::ctor(): Enable verify_peer in production code!
2020-11-17 22:10:40 | [feed][d]fetching configuration
2020-11-17 22:10:41 | [feed][c]Max range AIR: 350.0nm
2020-11-17 22:10:41 | [feed][c]Max range GND: 100.0nm
2020-11-17 22:10:41 | [feed][c]Timestamps: optional
2020-11-17 22:10:41 | info | [stats]Stats thread started
2020-11-17 22:10:41 | info | Stopping ReceiverACSender threads for feed 
2020-11-17 22:10:41 | info | Configured ReceiverACSender: 185.218.24.22:8099,185.218.24.23:8099,185.218.24.24:8099, feed: XXXXXXX, send_interval: 5s, max age: 15s, send metadata: true, mode: 1, filtering: true
2020-11-17 22:10:41 | info | Network thread connecting to 185.218.24.22:8099 for feed XXXXXXX

I've tripled check the docker-compose.yml file and the FR24KEY env var, and they all look fine. What could be the cause of this, and am I missing anything?

docker-compose.yml:

version: '2.0'

volumes:
  readsbpb_rrd:
  readsbpb_autogain:

services:
  readsb:
    image: mikenye/readsb-protobuf
    tty: true
    container_name: readsb
    hostname: readsb
    restart: always
    devices:
      - /dev/bus/usb/001/005:/dev/bus/usb/001/005
    ports:
      - 8080:8080
      - 30005:30005
      - 30003:30003
    environment:
      - TZ=Europe/London
      - READSB_DCFILTER=true
      - READSB_DEVICE_TYPE=rtlsdr
      - READSB_FIX=true
      - READSB_GAIN=autogain
      - READSB_LAT=XX.XXXX
      - READSB_LON=XX.XXXX
      - READSB_MODEAC=true
      - READSB_RX_LOCATION_ACCURACY=2
      - READSB_STATS_RANGE=true
      - READSB_NET_ENABLE=true
    volumes:
      - readsbpb_rrd:/run/collectd
      - readsbpb_autogain:/run/autogain

  piaware:
    image: mikenye/piaware:latest
    tty: true
    container_name: piaware
    restart: always
    ports:
      - 8081:80
    environment:
      - TZ=Europe/London
      - LAT=XX.XXXX
      - LONG=XX.XXXX
      - BEASTHOST=readsb
      - FEEDER_ID=XXXXXXXXXX

  fr24feed:
    image: mikenye/fr24feed:1.0.25-3_armhf_arm64
    tty: true
    container_name: fr24feed
    restart: always
    ports:
      - 8754:8754
    environment:
      - TZ=Europe/London
      - BEASTHOST=readsb
      - FR24KEY=XXXXXXXXXXX

Hello 😀
Is it possible to get an own environment variable for local ntp server? So if the ISP is down the drift won't be too high.
Thanks and bist regards,
Christian

Request (TL;DR)

Allow setting bind-interface in the config file via an environment variable, e.g. something like this:

  # Set up fr24feed
  {
    echo receiver="beast-tcp"
    echo fr24key="${FR24KEY}"
    echo host="${BEASTHOST}:${BEASTPORT}"
    echo bs="no"
    echo raw="no"
    echo logmode="1"
    echo logpath="/var/log"
    echo mlat="${MLAT}"
    echo mlat-without-gps="${MLAT}"
+   if [ -z "${BIND_INTERFACE}" ]; then
+     echo bind-interface="${BIND_INTERFACE}"
+   fi
  } > /etc/fr24feed.ini

Why?

By default, the fr24feed program only allows access to its web interface from IP addresses in a private range. If you try to access the web interface from an IP address outside one of these ranges, the following message is displayed:

For security reasons the web interface is only availble from private class networks or after you have manually specified the bind-interface setting in /etc/fr24feed.ini
Please set it to bind-interface="0.0.0.0" to accept traffic from all interfaces or to the IP address of your preferred network interface!
For further assistance please contact [email protected]

So why doesn't this affect all users of this container? By default, docker runs with a "userland proxy". This means any incoming connections to a container appear to come from the proxy's address, typically 172.16.0.x (which is in the private range). So when running this container, most users' connections to the web-ui appears to come from an IP in the private range.

However, I run docker without the userland proxy, so that my containers can see the real client IPs. I also access my container via the Tailscale VPN, which uses IP addresses outside the private range ref. So for my particular use case, I need to set the bind-interface variable in the config.

Thanks!

I noticed that for a while the CPU usage of the fr24 docker has gone up to 100% of one core. I remember that it was around 20% before.

Here is some info, if you guys need more please let me know.

Process: "qemu-arm-static /usr/local/bin.fr24feed" uses 99% CPU

The docker image runs on a x86 system.

Log:

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 00-libsecomp2: executing...
[cont-init.d] 00-libsecomp2: exited 0.
[cont-init.d] 01-fr24feed: executing...
WARNING: Setting timezone via TZ is not supported in this container. fr24feed requires the container has a timezone of GMT (+0).
fr24feed version: 1.0.34-0
[cont-init.d] 01-fr24feed: exited 0.
[cont-init.d] 02-show-architecture.sh: executing...

Hardware information:
Machine: x86_64
Processor: unknown
Platform: unknown

[cont-init.d] 02-show-architecture.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
2023-02-22 09:55:51 | ______ _ _ _ _ _ _____ ___
2023-02-22 09:55:51 | | || |() | | | | | | / __ \ / |
2023-02-22 09:55:51 | | | | | _ __ _ | |_ | |_ _ __ __ _ | | __ _ _ ' / /' / /| | 2023-02-22 09:55:51 | | _| | || | / _ || ' \ | || '|/ _ | / _ | / _` || '| / / / /| |
2023-02-22 09:55:51 | | | | || || (| || | | || |_ | | | (| || (| || (| || | ./ /__ |
2023-02-22 09:55:51 | _| |||| _, ||| || _||| _,| _,| _,||| ___/ |/
2023-02-22 09:55:51 | / |
2023-02-22 09:55:51 | |/
2023-02-22 09:55:51 | 23-02-22 09:55:51.684 [I][http-server.cpp:270] [httpd]Server started, listening on :::8754
2023-02-22 09:55:52 | [i]PacketSenderConfiguration::fetch_config(): Yoda configuration for this receiver is disabled
2023-02-22 09:55:52 | [d]TLSConnection::ctor(): Enable verify_peer in production code!
2023-02-22 09:55:57 | [feed][d]fetching configuration
2023-02-22 09:55:57 | [feed][c]Max range AIR: 350.0nm
2023-02-22 09:55:57 | [feed][c]Max range GND: 100.0nm
2023-02-22 09:55:57 | 23-02-22 09:55:57.798 [I][crxstats.cpp:588] [stats]Stats thread started
2023-02-22 09:55:57 | [feed][c]Timestamps: optional
2023-02-22 09:55:57 | 23-02-22 09:55:57.801 [I][receiver_ac_sender.cpp:137] Stopping ReceiverACSender threads for feed
2023-02-22 09:55:57 | 23-02-22 09:55:57.804 [D][receiver_ac_sender.cpp:141] Stop called on non-running network thread for feed
2023-02-22 09:55:57 | 23-02-22 09:55:57.804 [I][receiver_ac_sender.cpp:96] Configured ReceiverACSender: 185.218.24.22:8099,185.218.24.23:8099,185.218.24.24:8099, feed: EHAM351, send_interval: 5s/1s, max age: 15s, send metadata: true, mode: 1, filtering: true
2023-02-22 09:55:57 | 23-02-22 09:55:57.814 [I][receiver_ac_sender.cpp:36] Network thread connecting to 185.218.24.22:8099 for feed EHAM351

I received an email from FR24 after setting up my raspberry pi 4 adsb setup using https://mikenye.gitbook.io/ads-b/ as a guide. I have no problems with any of the other accounts I am feeding but FR24 said that my feed was sending a lot of invalid data and turned off my feed. They said I needed to update to the latest before they would let me try contributing again. Is there any information I could provide to help me work through this issue. Even though they turned my feed off I can still see from the mypi address and port that my fr24feed is seeing aircraft. So I'm not sure what they mean by my feed is sending a lot of invalid data. Any help would be appreciated. My initial email from FR24 staff was back in June when they shut off my feed.

Hi, I have received an email out of the blue today from flightradar24 asking me to turn off mlat...

Important information
If you intend to share data to networks alongside Flightradar24, in your Flightradar24 receiver please disable MLAT to the following settings: MLAT=“no”and MLAT-without-gps=“no”. This is to ensure the quality of the data we receive and use and to reduce incompatibility with other services.

I do feed into piaware and flightradar using sdr-enthusiasts containers so I suppose this is what they are referring to.

I don't know if this is just directed at me or if it's going out to a wider audience but in any case I am comfortable I can satisfy their first ask using the documented environment variable:

MLAT=“no”

but I don't see an environment variable for the second

MLAT-without-gps=“no”

Can an environment variable be added for this and are there any wider consequences from this email that should be added to the container documentation?

What happened since the last update, fr24feed is not feeding anymore and CPU is skyhigh?

Since 2 weeks I now have this error every 20 minutes in the FR24FEED container logs.
This does not prevent FR24 to work, my data is uploaded correctly.
However it shows the container as Unhealthy (due to the healthcheck I guess).

I checked my host configuration for time sync and it seems ok:
timedatectl
Local time: Fri 2022-12-30 13:33:15 CET
Universal time: Fri 2022-12-30 12:33:15 UTC
RTC time: n/a
Time zone: Europe/Paris (CET, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

The host is a Raspberry 4 running Ubuntu 22.04 ARM8.

Is this an issue with my setup?
Should the healthcheck be modified?

At least on my system, the logs in fr24 container are in UTC time and the healthcheck script always gives:

($TIMESTAMP_NOW - $LOG_LAST_ENTRY_TIMESTAMP) around 7200 (my TZ is UTC+2), so it's always
No data sent data to fr24feed in past 5 mins. UNHEALTHY, even though the feeder is working fine.

I'm not sure how other systems are configured, but probably some -u should be used when interpreting the date taken from log? Now it is assuming the parsed date is in the local TZ, but it's not, at least in my case.

I have setup up the docker container as per the instructions and it is tracking planes just fine from readsb, it claims data is being uploaded but nothing is arriving at Flightradar24

Sharing key is set fine and I get offline notifications from fr24 when I stop the container, but no aircraft tracking data is uploaded

I'm having issues running the container on a Alpine docker host:

• Linux 5.4.111-0-lts x86_64
• Docker version 19.03.5, build 633a0ea838f10e000b7c6d6eed1623e6e988b5bb

When I start the container I get the following error:

fr24feed  | root@11e9fc708df3:/# [2024-02-17 20:13:02.453][fr24feed] terminate called after throwing an instance of 'std::system_error'
fr24feed  | [2024-02-17 20:13:02.453][fr24feed]   what():  Operation not permitted
fr24feed  | [2024-02-17 20:13:02.478][fr24feed] [s6wrap] !!! CAUTION !!! Wrapped program terminated by signal: 6 (Aborted)
fr24feed  | [2024-02-17 20:13:02.478][fr24feed] [s6wrap] Command line for terminated program was: /usr/local/bin/fr24feed

fr24feed runs fine on directly on the Alpine host.

It seems that the valid values for step 4.1 may have changed:

Step 4.1 - Receiver selection (in order to run MLAT please use DVB-T stick with dump1090 utility bundled with fr24feed):

 1 - DVBT Stick (USB)
 -----------------------------------------------------
 2 - SBS1/SBS1er (USB/Network)
 3 - SBS3 (USB/Network)
 4 - ModeS Beast (USB/Network)
 5 - AVR Compatible (DVBT over network, etc)
 6 - microADSB (USB/Network)

Enter your receiver type (1-7)$:7
Value 7 is incorrect, please choose correct receiver type!

Hi Mike,

I am creating my stack with following config:

version: '2.0'
  
  services:
  
    piaware:
      image: mikenye/piaware:latest
      tty: true
      container_name: piaware
      mac_address: de:ad:be:ef:13:37
      restart: always
      devices:
        - /dev/bus/usb/001/004:/dev/bus/usb/001/004
      ports:
        - 8080:8080
        - 30005:30005
      environment:
        - TZ="Germany/something"
        - LAT=something
        - LONG=something
      volumes:
        - /var/cache/piaware:/var/cache/piaware
  
  
    fr24feed:
      image: mikenye/fr24feed:latest
      tty: true
      container_name: fr24feed
      restart: always
      ports:
        - 8754:8754
      environment:
        - BEASTHOST=piaware
        - FR24KEY=something
        - MLAT=yes
  
    adsbexchange:
     image: mikenye/adsbexchange
     tty: true
     container_name: adsbx
     restart: always
     environment:
       - BEASTHOST=piaware
       - TZ=Germany/something
       - LAT=something
       - LONG=something
       - ALT=50m
       - SITENAME=something
       - UUID=something
     tmpfs:
       - /run:rw,nosuid,nodev,exec,relatime,size=64M,uid=1000,gid=1000

This config was running smoothly and perfect for >1year.

Today I did a docker-compose down + docker-compose pull + docker-compose up to update and since them the two containers adsb and fr24feed can not connect to the piaware anymore with following errors.

fr24feed:

2023-02-17 09:57:30 | BeastBase::connectTcp(): Unable go connect, error: Connection refused[reader][e]Could not connect to tcp://piaware:30005
2023-02-17 09:57:35 | BeastBase::connectTcp(): Unable go connect, error: Connection refused[reader][e]Could not connect to tcp://piaware:30005
2023-02-17 09:57:40 | BeastBase::connectTcp(): Unable go connect, error: Connection refused[reader][e]Could not connect to tcp://piaware:30005
2023-02-17 09:57:45 | BeastBase::connectTcp(): Unable go connect, error: Connection refused[reader][e]Could not connect to tcp://piaware:30005
2023-02-17 09:57:50 | BeastBase::connectTcp(): Unable go connect, error: Connection refused[reader][e]Could not connect to tcp://piaware:30005

adsbexchange:

[mlat-client] Connection to piaware:30005 lost: [Errno 111] Connection refused
[mlat-client] Reconnecting in 10.7 seconds
[adsbexchange-feed] Beast TCP input: Connection to piaware (172.26.0.3) port 30005 failed: 111 (Connection refused)
[mlat-client] Connection to piaware:30005 lost: [Errno 111] Connection refused
[mlat-client] Reconnecting in 10.9 seconds
[mlat-client] Connection to piaware:30005 lost: [Errno 111] Connection refused

Output of docker network inspect:

[
    {
        "Name": "fr24_default",
        "Id": "86ddfba4a073d88fd30456322fa7a32cf125bab49e060cc3f77bd996ba0d9607",
        "Created": "2023-02-17T09:44:47.822618498Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.26.0.0/16",
                    "Gateway": "172.26.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "4559c33fdf15c4c68c9e51b86419f04979356a3937f1f8e0a4527762fd92671a": {
                "Name": "adsbx",
                "EndpointID": "2e0486c84dd4cc9516ba68a6cf688ee44159532a90a4b8033cdbd6f0e7190cdd",
                "MacAddress": "02:42:ac:1a:00:02",
                "IPv4Address": "172.26.0.2/16",
                "IPv6Address": ""
            },
            "5086a7941ab0becfba06f30aac84387c238c93a900a875a1c03e3fbde5fe7753": {
                "Name": "fr24feed",
                "EndpointID": "bc18b59013a95704acb5788dbd2dadc68bc56435c004af6c7776dcdd5f834475",
                "MacAddress": "02:42:ac:1a:00:04",
                "IPv4Address": "172.26.0.4/16",
                "IPv6Address": ""
            },
            "9782522b6d6f9ccc7f0843602fc7daf787a49bc8880969c8dbbaa35ef8055d56": {
                "Name": "piaware",
                "EndpointID": "dfb3a405b88357a9dcebf32a85fa3d0cb5ffc4cdd969f9dd8eafefdbbbe8ee38",
                "MacAddress": "de:ad:be:ef:13:37",
                "IPv4Address": "172.26.0.3/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {
            "com.docker.compose.network": "default",
            "com.docker.compose.project": "fr24",
            "com.docker.compose.version": "2.0.0"
        }
    }
]

Would be great if you could guide me in the right direction. Thanks.

Hi,

First off, thanks for building this (and piaware), they are setup exactly as I imagined they should be and make transitioning from a manual setup to a docker based one incredibly easy!

Not sure how difficult it is, but would it be possible to have a fr24feed docker image compatible with raspberry pi 4?

Unable to find image 'mikenye/fr24feed:latest' locally
latest: Pulling from mikenye/fr24feed
docker: no matching manifest for linux/arm64/v8 in the manifest list entries.

when I run the script in the instruction I get the following error:

s6-envdir: fatal: unable to envdir /run/s6/container_environment: No such file or directory