Use the following commands please
1. sudo systemctl restart fr24feed
Wait a little and then run the second command and take the screenshot
2. tail -f /var/log/fr24feed/fr24feed.log
Announcement
Collapse
No announcement yet.
Problems with feeder statistics and data sharing
Collapse
X
-
Originally posted by Khan View PostPlease post a screenshot of the errors you are getting.
Screenshot_20180619-210419.jpg
Leave a comment:
-
The fix didn't work for me, tried reinstalling and all that, still connection issues. Any ideas how long until issue is resolved?
Leave a comment:
-
Originally posted by serek View PostKhan,
It's 2018, European Internet registry (RIPE) is not freely issuing IPv4 addresses to service providers for almost 6 years!!! Can you please at least re-assure us that you are working on server-side fix here? I know it's hard to make backend systems work with IPv6, but gracefully falling back to IPv4 has been implemented by many.
I see that you've introduced Cloudflare proxying. Is there no way to reconfigure Cloudflare DNS, so it doesn't serve IPv6 records?
Also, should you need a group of feeders in the future to help you deploying/testing/troubleshooting IPv6, please count me in!
Regards,
Sergiusz
Leave a comment:
-
Originally posted by ylis View PostCan someone explain ..
On the ip of pi:8754 status screen, I see after Local IP(s) an IPv4 followed by an IPv6 address. I recognise the first as my local LAN - any idea what the second v6 address might be ? Is it the destination address or could it be the WAN address of my internet service ?
Due to the shortage of IPv4 addresses we have become accustom to our computers having an unroutable LAN address (192.168.*.* or 10.*.*.* etc) that is NATed via our router to some LAN address.
IPv6 is different in that each device gets a truly globally routable address that is not run thru a NAT. Thus the address you are seeing is both the LAN address of your pi and the WAN address of your pi.
Leave a comment:
-
Can someone explain ..
On the ip of pi:8754 status screen, I see after Local IP(s) an IPv4 followed by an IPv6 address. I recognise the first as my local LAN - any idea what the second v6 address might be ? Is it the destination address or could it be the WAN address of my internet service ?
Stats are back working since 1010UTC and as an interesting aside, the RPi 3B's with the light blue dongle were less impacted than the Radarcape or the FA Prostick !!
Leave a comment:
-
$ sudo apt-get install dnsutils
$ sudo nslookup feed.flightradar24.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
feed.flightradar24.com canonical name = feed.flightradar24.com.cdn.cloudflare.net.
Name: feed.flightradar24.com.cdn.cloudflare.net
Address: 104.20.0.101
Name: feed.flightradar24.com.cdn.cloudflare.net
Address: 104.20.1.101
Name: feed.flightradar24.com.cdn.cloudflare.net
Address: 2400:cb00:2048:1::6814:65
Name: feed.flightradar24.com.cdn.cloudflare.net
Address: 2400:cb00:2048:1::6814:165
Leave a comment:
-
Originally posted by Birdie View PostI thought my receiver have problems. I removed the receiver front panel, cleaned the MicroSD contacts and reinstalled.
tail -F /var/log/fr24feed/fr24feed.log
and watching the output for a while. If you see things like:
2018-06-19 10:59:40 | [mlat][i]Received ADS-B time references AC:
2018-06-19 10:59:40 | [mlat][i] 7C3635
2018-06-19 10:59:40 | [mlat][i] 7C4779
...
2018-06-19 10:59:40 | [mlat][i] C058C2
the ADS-B side of your system is functioning normal and there is nothing you can do on that front. Other messages can indicate whether the data is being successfully sent to the servers.
Leave a comment:
-
Originally posted by Malcolml View PostThanks for reply, I can put my hair back now. Sorry if I missed earlier reports.
I thought my receiver have problems. I removed the receiver front panel, cleaned the MicroSD contacts and reinstalled. I also climb outside my 25 floor apartment window, stood on top of my air con compressor to check the antenna connections. Still I saw intermittent data feeds.Last edited by Birdie; 2018-06-19, 00:26.
Leave a comment:
-
Actually the problem is most likely that the fr24feed program is only resolving the server address at startup. So once it has acquired an ipv6 address it'll hold onto that forever.
What the program should do is periodically re-resolve feed.flightradar24.com and re-connect if the address has changed (or been dropped). That way if they have another catastrophic routing issue they can drop the AAAA address out of the DNS and the clients will eventually all auto-switch over to ipv4.
A restart would have worked as well if flightradar had dropped the AAAA during the problem period, but that doesn't seem to have happened, which is a bit odd. That way at least all those folk attempting a restart would have started working without starting to mess with their systems in an attempt to get them going again.
Leave a comment:
-
Leave a comment:
-
What JohnnyBravo would tell is that in Germany/Europe most ISP switch to IPv6 with an IPv4 stack. That dont make it easy to "just switch" to IPv4 at any time.
For me it was a phonecall to my ISP to ask for an real IPv4 adress, 10 minutes later it runs without extra costīs.
Leave a comment:
-
Originally posted by JohnnyBravo View PostAgreed!! It's 2018 for Pete's sake!
I had fully transitioned to IPv6 at home and I'm now running IPv4 only to be able to feed data to FR24....
Leave a comment:
-
My unit isn't working by the look of things. I've sent you an email.
Leave a comment:
Leave a comment: