dump1090 collecting messages; flightradar24.com reporting Online - No data

[bimmerdriver]

I've had this problem a few times before, but I haven't been able to find out what's causing it.

It was the same with dump1090-mutability and dump1090-fa, so I think it must be something else.

Messages are being collected and I can see the aircraft being plotted by Skyaware. It's also reporting the message rate, as if everything is working properly.

The main page for http://localhost:8754/ also appears fine:



[PART 1 OF 3]

[bimmerdriver]

Here is the log from restarting fr24feeder. There are a few entries that look like errors:

flightradar24 2.png
flightradar24 3.png
[PART 2 OF 3]

[bimmerdriver]

Finally, I tried to rerun the account setup and it failed.

Here is the log:

$ sudo fr24feed --signup
/dev/shm/decoder.txt: Permission denied
[main][e]Could not create monitor file!
______  _  _         _      _                    _              _____    ___
|  ___|| |(_)       | |    | |                  | |            / __  \  /   |
| |_   | | _   __ _ | |__  | |_  _ __  __ _   __| |  __ _  _ __`' / /' / /| |
|  _|  | || | / _` || '_ \ | __|| '__|/ _` | / _` | / _` || '__| / /  / /_| |
| |    | || || (_| || | | || |_ | |  | (_| || (_| || (_| || |  ./ /___\___  |
\_|    |_||_| \__, ||_| |_| \__||_|   \__,_| \__,_| \__,_||_|  \_____/    |_/
               __/ |
              |___/
[main][i]FR24 Feeder/Decoder
[main][i]Version: 1.0.46-1/generic
[main][i]Built on Jan 18 2024 09:38:04 (T202401180935/Linux/static_amd64)
[main][i]Running on: ubuntu="22.04"
[main][i]Local IP(s): 172.22.194.208,fe80::215:5dff:fe59:8a57
[main][i]Copyright 2012-2024 Flightradar24 AB
[main][i]https://www.flightradar24.com
[main][i]DNS mode: PING

Welcome to the FR24 Decoder/Feeder sign up wizard!

Before you continue please make sure that:

 1 - Your ADS-B receiver is connected to this computer or is accessible over network
 2 - You know your antenna's latitude/longitude up to 4 decimal points and the altitude in feet
 3 - You have a working email address that will be used to contact you
 4 - fr24feed service is stopped. If not, please run: sudo systemctl stop fr24feed

To terminate - press Ctrl+C at any point


Step 1.1 - Enter your email address (username@domain.tld)
$:REDACTED

Step 1.2 - If you used to feed FR24 with ADS-B data before, enter your sharing key.
If you don't remember your sharing key, you can find it in your account on the website under "My data sharing".
https://www.flightradar24.com/account/data-sharing

Enter your sharing key or press ENTER/RETURN to continue.
$:REDACTED

Verifying sharing key...[W] Fall back to HTTP for error: SSL connect error
Got no response or empty response from the server :(​

[PART 3 OF 3]

[abcd567]

You have to set dump1090-mutability to start automatically at boot.

OPTION-1:
Issue following command

sudo nano /etc/default/dump1090-mutability

In file opened, scroll down to following line
START_DUMP1090="no"

Change "no" to "yes"
START_DUMP1090="yes"

Save file and REBOOT Pi

The dump1090-mutability will start on boot.


OPTION-2:
Issue following command

sudo dpkg-reconfigure dump1090-mutability

Following dialog will open. It will ask "start dump1090-mutability", and "NO" will be highlighted red. Use tab or arrow keys to make "YES" highlighted red and press Enter Key. Keep on pressing Enter key till dialog completes and closes.


dump1090-mutability.png

[bimmerdriver]

Thank you for your reply.

I installed dump1090-fa and fr24feed yesterday on a clean distro. I checked to see if somehow dump1090-mutability inadvertently got installed, but I don't think so. I used ps aux and systemctrl --type=service. There are no processes or services corresponding to dump1090-mutability. The only thing I noticed was the directory /run/dump-mutability was created this morning. It was empty.

I was away from the system for a few hours. When I returned, it was working. There is nothing obvious in the fr24feeder log that indicates why it spontaneously started working.

Here is part of the log from before and after it started working:

Feb 18 14:47:34 kaveri fr24feed[722]: [feed][n]syncing stream: timeout
Feb 18 14:47:35 kaveri fr24feed[722]: [feed][n]disconnected
Feb 18 14:47:35 kaveri fr24feed[722]: [I] [feed][n]waiting 17 seconds
Feb 18 14:47:52 kaveri fr24feed[722]: [feed][n]*****@185.218.24.22:8099/UDP
Feb 18 14:47:52 kaveri fr24feed[722]: [I] Network thread connecting to 185.218.24.22:8099 for feed CYNJ45
Feb 18 14:47:52 kaveri fr24feed[722]: [feed][n]connecting
Feb 18 14:47:52 kaveri fr24feed[722]: [feed][n]connected via UDP (fd 20)
Feb 18 14:47:52 kaveri fr24feed[722]: [feed][n]working
Feb 18 14:49:26 kaveri fr24feed[722]: [feed][n]syncing stream async: 1
Feb 18 14:49:27 kaveri fr24feed[722]: [feed][n]syncing stream result: 1
...
Feb 18 14:54:04 kaveri fr24feed[722]: [feed][n]syncing stream async: 1
Feb 18 14:54:50 kaveri fr24feed[722]: [feed][n]syncing stream: timeout
Feb 18 14:56:21 kaveri fr24feed[722]: [feed][n]syncing stream async: 1
Feb 18 14:56:54 kaveri fr24feed[722]: [i]PacketSenderConfiguration::on_periodic_refresh: refreshing configuration
Feb 18 14:56:54 kaveri fr24feed[722]: [i]PacketSenderConfiguration::fetch_config(): Yoda configuration for this receiver is disabled
Feb 18 14:57:00 kaveri fr24feed[722]: [I] [stats]sent 16 bytes
Feb 18 14:57:06 kaveri fr24feed[722]: [feed][n]syncing stream: timeout
Feb 18 14:58:28 kaveri fr24feed[722]: [time][i]Synchronizing time via NTP
Feb 18 14:58:29 kaveri fr24feed[722]: [time][e]Failed to synchronize time
Feb 18 14:58:29 kaveri fr24feed[722]: [reader][i]Timestamp source changed from SYSTEM-UNCERTAIN to SYSTEM-VALIDATED
Feb 18 14:58:35 kaveri fr24feed[722]: [time][i]Synchronizing time via NTP
Feb 18 14:58:36 kaveri fr24feed[722]: [time][e]Failed to synchronize time
Feb 18 14:58:37 kaveri fr24feed[722]: [feed][n]syncing stream async: 1
Feb 18 14:58:46 kaveri fr24feed[722]: [time][i]Synchronizing time via NTP
Feb 18 14:58:46 kaveri fr24feed[722]: [time][e]Time synchronized, offset -0.645 seconds, drift +0.201 seconds/minute
Feb 18 14:58:46 kaveri fr24feed[722]: [reader][i]Timestamp source changed from SYSTEM-VALIDATED to SYSTEM-UNCERTAIN
Feb 18 14:58:48 kaveri fr24feed[722]: [feed][i]sent 10,0 AC
Feb 18 14:58:54 kaveri fr24feed[722]: [feed][i]sent 11,0 AC
...
Feb 18 14:59:16 kaveri fr24feed[722]: [feed][i]sent 12,0 AC
Feb 18 14:59:21 kaveri fr24feed[722]: [feed][i]sent 9,0 AC
Feb 18 14:59:23 kaveri fr24feed[722]: [feed][n]syncing stream: timeout
Feb 18 14:59:24 kaveri fr24feed[722]: [feed][n]disconnected
Feb 18 14:59:24 kaveri fr24feed[722]: [I] [feed][n]waiting 23 seconds
Feb 18 14:59:47 kaveri fr24feed[722]: [feed][n]*****@185.218.24.23:8099/UDP
Feb 18 14:59:47 kaveri fr24feed[722]: [feed][n]connecting
Feb 18 14:59:47 kaveri fr24feed[722]: [I] Network thread connecting to 185.218.24.23:8099 for feed *****
Feb 18 14:59:47 kaveri fr24feed[722]: [feed][n]connected via UDP (fd 20)
Feb 18 14:59:47 kaveri fr24feed[722]: [feed][n]working
Feb 18 14:59:47 kaveri fr24feed[722]: [feed][i]sent 1,0 AC
Feb 18 14:59:53 kaveri fr24feed[722]: [feed][i]sent 10,0 AC
...
Feb 18 15:00:20 kaveri fr24feed[722]: [feed][i]sent 10,0 AC
Feb 18 15:00:25 kaveri fr24feed[722]: [feed][i]sent 10,0 AC​

In retrospect, what happened today is exactly what happened yesterday. I can only speculate that something is wrong in my installation, but I installed it EXACTLY according to your instructions. It's not like it's difficult. This is really strange.

[bimmerdriver]

Last night, it was working. Now I'm back to where I was yesterday morning. dump1090-fa is merrily tracking aircraft, but fr24feed is not receiving them. It's endlessly outputting the messages below, then it eventually gives and tries to reconnect.

Feb 19 09:05:45 kaveri fr24feed[7832]: [feed][n]connecting
Feb 19 09:05:45 kaveri fr24feed[7832]: [feed][n]connected via UDP (fd 20)
Feb 19 09:05:45 kaveri fr24feed[7832]: [feed][n]working
Feb 19 09:07:18 kaveri fr24feed[7832]: [feed][n]syncing stream async: 1
Feb 19 09:07:19 kaveri fr24feed[7832]: [feed][n]syncing stream result: 1
Feb 19 09:09:20 kaveri fr24feed[7832]: [feed][n]syncing stream async: 1
Feb 19 09:09:21 kaveri fr24feed[7832]: [feed][n]syncing stream result: 1​

I tried uninstalling and reinstalling fr24feed, then I ran sudo fr24feed --signup, which worked with no errors.

When I restart fr24feed, there are some log messages that don't seem right.

Feb 19 09:11:18 kaveri systemd[1]: Starting Flightradar24 Decoder & Feeder...
Feb 19 09:11:18 kaveri unregister_kernel_modules.sh[7886]: rmmod: ERROR: Module dvb_usb_rtl28xxu is not currently loaded
Feb 19 09:11:18 kaveri unregister_kernel_modules.sh[7887]: rmmod: ERROR: Module rtl2832 is not currently loaded
Feb 19 09:11:18 kaveri unregister_kernel_modules.sh[7888]: rmmod: ERROR: Module e4000 is not currently loaded
Feb 19 09:11:18 kaveri create_missing_directories.sh[7891]: chown: cannot access '#var#log#fr24feed': No such file or directory
Feb 19 09:11:18 kaveri systemd[1]: Started Flightradar24 Decoder & Feeder.

I replaced / with # to get by the f**king spam filter.

Given that dump1090-fa is working, how is it possible the kernel modules aren't installed?

Here are the contents of fr24feed.ini:

receiver="avr-tcp"
fr24key="REDACTED"
host="127.0.0.1:30002"
bs="no"
raw="no"
mlat="no"
mlat-without-gps="no"​

It's exactly what I've been using.

Here is the current log:

Feb 19 09:14:54 kaveri fr24feed[7893]: [feed][n]syncing stream result: 1
Feb 19 09:17:26 kaveri fr24feed[7893]: [feed][n]syncing stream async: 1
Feb 19 09:18:12 kaveri fr24feed[7893]: [feed][n]syncing stream: timeout
Feb 19 09:19:43 kaveri fr24feed[7893]: [feed][n]syncing stream async: 1
Feb 19 09:20:29 kaveri fr24feed[7893]: [feed][n]syncing stream: timeout
Feb 19 09:21:19 kaveri fr24feed[7893]: [I] [stats]sent 16 bytes
Feb 19 09:21:59 kaveri fr24feed[7893]: [feed][n]syncing stream async: 1
Feb 19 09:22:45 kaveri fr24feed[7893]: [feed][n]syncing stream: timeout
Feb 19 09:22:46 kaveri fr24feed[7893]: [feed][n]disconnected
Feb 19 09:22:46 kaveri fr24feed[7893]: [I] [feed][n]waiting 6 seconds
Feb 19 09:22:52 kaveri fr24feed[7893]: [feed][n]******@185.218.24.23:8099/UDP
Feb 19 09:22:52 kaveri fr24feed[7893]: [feed][n]connecting
Feb 19 09:22:52 kaveri fr24feed[7893]: [I] Network thread connecting to 185.218.24.23:8099 for feed ******
Feb 19 09:22:52 kaveri fr24feed[7893]: [feed][n]connected via UDP (fd 20)
Feb 19 09:22:52 kaveri fr24feed[7893]: [feed][n]working
Feb 19 09:24:25 kaveri fr24feed[7893]: [feed][n]syncing stream async: 1
Feb 19 09:24:26 kaveri fr24feed[7893]: [feed][n]syncing stream result: 1​

One possible cause of problems is related to WSL. It's not possible to connect the USB receiver until after it boots. However, it automatically starts dump1090-fa, lighttpd and fr24feed upon booting, so initially, there is a failure because the receiver is not connected.I think there's a way to create a service that runs before dump1090-fa, but I haven't got this sorted out. Perhaps this is why fr24feed tries to start dump1090-mutability, even though it's not installed.

[Oblivian]

Module thing is normal

You don't want them running else it goes into tv mode so they force stop/unload to make sure regardless. It reports errors but should say 'that's good'

Stream sync is possibly UDP connect failures. It expects constant network, and id say there is too many losses happening. Udp has no ack packets like tcp. It just pushes. So queuing is bad. So if they go out of whack....

[abcd567]

Module thing is normal

You don't want them running else it goes into tv mode so they force stop/unload to make sure regardless. It reports errors but should say 'that's good'

Stream sync is possibly UDP connect failures. It expects constant network, and id say there is too many losses happening. Udp has no ack packets like tcp. It just pushes. So queuing is bad. So if they go out of whack....

Well explained Oblivian
Screenshot_20240213_021059_WhatsApp.jpgScreenshot_20240213_021059_WhatsApp.jpgScreenshot_20240213_021059_WhatsApp.jpg

[bimmerdriver]

Module thing is normal

You don't want them running else it goes into tv mode so they force stop/unload to make sure regardless. It reports errors but should say 'that's good'

Stream sync is possibly UDP connect failures. It expects constant network, and id say there is too many losses happening. Udp has no ack packets like tcp. It just pushes. So queuing is bad. So if they go out of whack....

Thank you for the reply.

Glad that the errors are not a problem.

What about this error:

Feb 19 09:11:18 kaveri create_missing_directories.sh[7891]: chown: cannot access '#var#log#fr24feed': No such file or directory

I have noticed in some example fr24feed.ini files a statement about logging. Do I have to enable logging? If so, maybe I should to see if anything strange happens when it stops working, assuming it eventually starts working again.

I just checked the connection to feed.flightradar24.com and it looks fine:

ping feed.flightradar24.com
nslookup feed.flightradar24.com
traceroute feed.flightradar24.com​

The average ping response time was under 3 ms and there were no packets out of 100.

$ ping -c 100 feed.flightradar24.com
...
--- feed.flightradar24.com ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 100368ms
rtt min/avg/max/mdev = 1.711/2.785/12.050/1.319 ms​

Traceroute noted 6 hops and they were also in the millisecond range.

$ traceroute feed.flightradar24.com
traceroute to feed.flightradar24.com (104.16.58.181), 30 hops max, 60 byte packets
 1  kaveri.mshome.net (172.22.192.1)  0.339 ms  0.287 ms  0.296 ms
 2  pfSense.localdomain (10.28.92.1)  1.662 ms  1.649 ms  1.641 ms
 3  100.122.29.1 (100.122.29.1)  2.437 ms  2.427 ms  2.419 ms
 4  QUBCPQBIDR03.bb.telus.com (154.11.15.105)  2.447 ms  2.440 ms 154.11.15.107 (154.11.15.107)  2.431 ms
 5  QUBCPQAJDR02.bb.telus.com (154.11.15.73)  3.092 ms  3.080 ms  3.070 ms
 6  104.16.58.181 (104.16.58.181)  2.180 ms  1.879 ms  1.850 ms​

I have gigabit fibre internet up and down and it's normally reliable. This doesn't make any sense.

[bimmerdriver]

Here is an excerpt from /etc/default/dump1090-fa:

# Network ports to listen on for connections
NET_RAW_INPUT_PORTS=
NET_RAW_OUTPUT_PORTS=30002
NET_SBS_OUTPUT_PORTS=30003
NET_BEAST_INPUT_PORTS=30004,30104
NET_BEAST_OUTPUT_PORTS=30005​

Here is /etc/fr24feed.ini:

receiver="avr-tcp"
fr24key="REDACTED"
host="127.0.0.1:30002"
bs="no"
raw="no"
mlat="no"
mlat-without-gps="no"​

fr24feed.png

Why does dump1090-fa refer to port 30002 as RAW, but fr24feed refer to it as AVR? Should I try using NET_BEAST_OUTPUT_PORTS=30005?

[bimmerdriver]

Looking at this further, I think the problem is between fr24feeder and feed.flightradar24.com. At least I think this because according to the status at http://localhost:8754/, aircraft are being tracked and uploaded.

fr24feed 2.png

Aircraft are also appearing in the tracked aircraft list. The numbers are fairly consistent with http://localhost/skyaware/. However, this isn't consistent with the lack of messages in the log reflecting the uploaded aircraft. It seems like the aircraft are being bitbucketed by fr24feeder.

[abcd567]

Here is /etc/fr24feed.ini:

receiver="avr-tcp"
fr24key="REDACTED"
host="127.0.0.1:30002"
bs="no"
raw="no"
mlat="no"
mlat-without-gps="no"​

Why does dump1090-fa refer to port 30002 as RAW, but fr24feed refer to it as AVR?

Should I try using NET_BEAST_OUTPUT_PORTS=30005?

In file /etc/fr24feed.ini, FR24 default setting are as follows:

receiver="avr-tcp"
host="127.0.0.1:30002"


However using following is also OK:

receiver="beast-tcp"
host="127.0.0.1:30005"

[Oblivian]

Ping/icmp and tracing isn't the same as a udp stream.

And what can interrupt it is you're not talking directly to the hardware. Its through a software layer. Same thing happens with containers.

The slightest IO delay and you risk interruption of the process bombing out and just wedging for the heck of it.

The stata server is a secondary connection. Dont even go there... The number of times it independently goes offline and makes everyone think their feeder has stopped...

They changed the log location in new versions and didn't recode error correction for it. Search fr24feed.log and you'll see a few mentions.

If that was on it fills up fast. But you really need to capture what hapoens before/as it seemingly dies. Or run it interactivity and monitor the console out.

If you see lots of ping1.. ping2... Ping3
It isn't getting anything from you and needs to send a keep alive to see what happened.
The stream sync appears to be both the stats server and sending data once open.

In either case, if its uploading.. you'll see lines of how many ac sent each packet
If its not, you ain't sending from that instance of fr24reed.

and yes, the log will also show ignoring x aircraft if the server told your feeder to not bother because others are.

[bimmerdriver]

Ping/icmp and tracing isn't the same as a udp stream.

And what can interrupt it is you're not talking directly to the hardware. Its through a software layer. Same thing happens with containers.

The slightest IO delay and you risk interruption of the process bombing out and just wedging for the heck of it.

The stata server is a secondary connection. Dont even go there... The number of times it independently goes offline and makes everyone think their feeder has stopped...

They changed the log location in new versions and didn't recode error correction for it. Search fr24feed.log and you'll see a few mentions.

If that was on it fills up fast. But you really need to capture what hapoens before/as it seemingly dies. Or run it interactivity and monitor the console out.

If you see lots of ping1.. ping2... Ping3
It isn't getting anything from you and needs to send a keep alive to see what happened.
The stream sync appears to be both the stats server and sending data once open.

In either case, if its uploading.. you'll see lines of how many ac sent each packet
If its not, you ain't sending from that instance of fr24reed.

and yes, the log will also show ignoring x aircraft if the server told your feeder to not bother because others are.

Understood ping is not the same as the UDP packets. However, if ping was not working, it would point to a problem.

Coincidently, earlier today, I sent an email to support. I included screen captures of skyaware, http://localhost:8754/, http://localhost:8754/settings.html, http://localhost:8754/tracked.html and http://localhost:8754/logs.html. A few minutes after I sent the email I checked again and it was working. Unfortunately, the point in time when it started working was already past, so I couldn't see if anything interesting happened. Very strange.

The log looks like this:

Feb 19 19:47:42 kaveri fr24feed[8407]: [feed][i]sent 3,0 AC
Feb 19 19:47:48 kaveri fr24feed[8407]: [feed][i]sent 4,0 AC
Feb 19 19:47:48 kaveri fr24feed[8407]: [feed][n]syncing stream async: 1
Feb 19 19:47:49 kaveri fr24feed[8407]: [feed][n]syncing stream result: 1
Feb 19 19:47:54 kaveri fr24feed[8407]: [feed][i]sent 5,0 AC
...
Feb 19 19:48:39 kaveri fr24feed[8407]: [feed][i]sent 4,0 AC
Feb 19 19:48:44 kaveri fr24feed[8407]: [I] [stats]sent 541 bytes
Feb 19 19:48:45 kaveri fr24feed[8407]: [feed][i]sent 3,0 AC
...
Feb 19 19:53:18 kaveri fr24feed[8407]: [feed][i]sent 4,0 AC
Feb 19 19:53:23 kaveri fr24feed[8407]: [time][i]Synchronizing time via NTP
Feb 19 19:53:23 kaveri fr24feed[8407]: [time][i]Time synchronized correctly, offset -9.347 seconds, drift -0.001 seconds/minute
Feb 19 19:53:23 kaveri fr24feed[8407]: [feed][i]sent 4,0 AC​​

I've never seen a message indicating that an aircraft was ignored.

The syncing messages occur every 5 minutes.

The other messages have a longer interval between them.

[Oblivian]

Well thats different to

https://forum.flightradar24.com/forum/radar-forums/flightradar24-feeding-data-to-flightradar24/223825-dump1090-collecting-messages-flightradar24-com-reporting-online-no-data?p=223843#post223843

Where there is clearly something not producing data..as its nothing but data sync and fail attempts.

Which is where I suggest there is some form of UDP failure happening. Or the sticks just dropping the data between dump and feeder.

You should always get a ping, or aircraft upload message.

Are you sure it's even a good stick and not a fitpower tuner? 4-5 every few mins is poor compared to earlier 18. and I would not expect that to trigger ignores. Unless your data is just way worse than other feeders near.

It should be updating that every 2-3 seconds non stop.

Note the portal screenshots. Numbers tracked vs number uploaded. 3 short that its likely been told to ignore.

You may just need to face you're not running a PI, but rather a virtual environment and it's not likely to be bulletproof