Problems with feeder statistics and data sharing

[fungsaihou]

Another easy way to give IPv4 preference over IPv6. I am using it successfully on my 3 Pis

I agreed with abcd567. This is the easiest way to solve the IPv6 issue on FR24.

[abcd567]

Another easy way to give IPv4 preference over IPv6. I am using it successfully on my 3 Pis

Another good workaround for IPv6 problems is to:

In the file /etc/gai.conf find the following line:

#precedence ::ffff:0:0/96 100

Uncomment this line so it looks like:

precedence ::ffff:0:0/96 100

Your Pi will now prefer IPv4 over IPv6 without disabling IPv6.
I've done this and the feeder now happily connects over IPv4, system updates run smoother as well, and I still have IPv6 available.

If you have previously disabled IPv6 then you need to re-enable it for this solution to work properly.

[SentaSama]

Hello Khan,

whilst I understand that the feeder has issues with IPv6, I do not see the need to completely render IPv6 useless on the PI.

To get both you simply need to ensure that the IPv4 address comes first when resolving the feed-server.
Which can be done by a simple line into

/etc/hosts

like this:

104.20.0.101 feed.flightradar24.com feed.flightradar24.com.cdn.cloudflare.net

The "script" to do this could look like this:

sudo -s
grep -q -F '104.20.0.101 feed.flightradar24.com feed.flightradar24.com.cdn.cloudflare.net' /etc/hosts || echo '104.20.0.101 feed.flightradar24.com feed.flightradar24.com.cdn.cloudflare.net' >> /etc/hosts
exit

Have Fun

[bib]

Any news on when the issues will be fixed with fr24feeder? I've tried all the methods here and reinstalled the feeder a few times, no luck. I'm getting uptime, just no aircraft. Local page still says "Disconnected ()"

Fixed??? There is no chance. The developers do not have a clue despite being told what they are, both at the server and client ends.

At the client end, the problem with IPv6, can be fixed by wrapping the connection attempt in a loop which goes through all returned DNS replies. That way, they try both IPv6 & IPv4 addresses.

At the server end, a simple fix would be to disable IPv6 in the DNS. A proper fix would be to code IPv6 handlers.

3 possible fixes, and nothing happens.

[tzq33tdq]

Any news on when the issues will be fixed with fr24feeder? I've tried all the methods here and reinstalled the feeder a few times, no luck. I'm getting uptime, just no aircraft. Local page still says "Disconnected ()"

[John_R]

Thanks abcd567! I'll be giving that a look. The automated full install acted a little glitchy when I played with it on back up pi. Time to start reading!

[mem0tap]

mem0tap
Go to the ADS-B Receiver Project at www(dot)adsbreceiver(dot)net (I'm one post shy of being able to post links here ) They have exactly what you're looking for. It's still a work in progress but it's going to be great. I'm still having a little trouble getting it to work with my FR24 but it is also a stand alone dump1090 receiver that I've set up on another Pi for antenna testing and tweeking. The graphs and history it maintains are as near to perfect as you'll find.

Thanks, I'll have a look but would prefer FR24 to implement it. Also thanks to @abcd567 - will also investigate.

[abcd567]

mem0tap:

The proposal of John_R is good one, but requires to replace your current install by a new image from www.adsbreceiver.net .

If you want to retain your current install, and ADD to it stats functionality, try the method given in thread below. It will offer you options to install dump1090-mutability/dump1090-fa, data feeders etc. Say No to all options presented till you the option to install "Web Portal" is presented. Accept it. Say NO to "Advanced Options". This will install performance graphs you need.


Automated Installation of Dump1090-Mutability, Data Feeders, and Performance Graphs

[John_R]

mem0tap
Go to the ADS-B Receiver Project at www(dot)adsbreceiver(dot)net (I'm one post shy of being able to post links here ) They have exactly what you're looking for. It's still a work in progress but it's going to be great. I'm still having a little trouble getting it to work with my FR24 but it is also a stand alone dump1090 receiver that I've set up on another Pi for antenna testing and tweeking. The graphs and history it maintains are as near to perfect as you'll find.

[mem0tap]

Personally I'd prefer it if I could download a detailed report of my stats each month, this would enable me long term to asses the efficiency of the system, and know whether it is suffering any deterioration (as the antenna is outside) - If I could dump or add it to an office spreadsheet that would be perfect. I need to know whether adjustments I make and Antennas I design are an improvement. - Anybody listening?

[John_R]

So in a way it becomes a meaningless statistic since the range in most of a feeder's sectors may be terrain or obstruction limited, consequently accounting for a very small percentage of a feeders total tracks, while another direction or two could account for the vast majority of their tracks with exceptional results. Remember, for every town that name ends with the word "Hills" you have to have gullies. Otherwise how would you notice the hills?

[Oblivian]

I asked this a few weeks ago:

FR24 Support advised me that Average range = max for each direction / 8, we have north, north west, west etc..(8 directions)

Spose that could work. Would give a circular range plot from your location somewhere in the middle of all if location was perfect and 360deg view. But may hurt a bit for those on the side of a thin island with single direction view like here?...

[ylis]

I asked this a few weeks ago:

Any thoughts on what the average range is measuring?

FR24 Support advised me that Average range = max for each direction / 8, we have north, north west, west etc..(8 directions)

[Wilmer]

I wonder what happened here though and why FR24 can't just pull the AAAA records from DNS so feeders will stop trying to connect to what they don't yet support? Or is this entirely outside their control and only with CloudFlare? Surely you could ask CloudFlare to disable IPv6/AAAA records for your hostnames? :-/

Some stracing showed me that fr24feed does DNS in interesting ways:

2351  <... read resumed> "PING feed.flightradar24.com(2400:cb00:2048:1::6814:65 (2400:cb00:2048:1::6814:65)) 56 data bytes\n", 511) = 97'
...
2351  connect(9, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("255.255.255.255")}, 16) = -1 ENETUNREACH (Network is unreachable)

It runs ping $HOSTNAME, tries to find an IPv4 address in the output, which isn't there anymore and it fails? :-(

Nice workaround idea though: The ping command only recently started supporting IPv6, in the past you'd have to use ping6. You can get this old behaviour back though:

sudo apt-get install inetutils-ping

That'll get you an IPv4-only ping so stuff will work again, without disabling IPv6 for other things. Also, I strongly prefer this over adding entries to /etc/hosts that are bound to get stale at some point and cause different issues..

I also noticed a "DNS mode:" bit in my logs (and apparently a "dns-mode" fr24feed.ini directive) which could be used to switch to libc DNS mode, but I couldn't figure out how to actually enable that. Would've been helpful..

[abcd567]

Another good workaround for IPv6 problems is to:

In the file /etc/gai.conf find the following line:

#precedence ::ffff:0:0/96 100

Uncomment this line so it looks like:

precedence ::ffff:0:0/96 100

Your Pi will now prefer IPv4 over IPv6 without disabling IPv6.
I've done this and the feeder now happily connects over IPv4, system updates run smoother as well, and I still have IPv6 available.

thumb-single.jpg thumb-single.jpg thumb-single.jpg

If you have previously disabled IPv6 then you need to re-enable it for this solution to work properly.

If you have disable IPv6 by following command, rebooting Pi will enable IPv6
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1

If you have disable IPv6 by editing some file, undo the edits, and reboot Pi.