Announcement

Collapse
No announcement yet.

Problems with feeder statistics and data sharing

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Khan
    replied
    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

    Leave a comment:


  • tzq33tdq
    replied
    Originally posted by Khan View Post
    Please post a screenshot of the errors you are getting.
    Here you go.
    Screenshot_20180619-210419.jpg

    Leave a comment:


  • Khan
    replied
    Please post a screenshot of the errors you are getting.

    Leave a comment:


  • tzq33tdq
    replied
    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:


  • Khan
    replied
    Originally posted by serek View Post
    Khan,

    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
    It is just a temporary work around. Our backend team is working on a proper solution but till then this work around can be used. Apologies for this but rest assured we are trying hard to have a proper solution as soon as possible.

    Leave a comment:


  • MarkDingo
    replied
    Originally posted by ylis View Post
    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 ?
    It will an IPv6 LAN and WAN address of your pi.

    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:


  • ylis
    replied
    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:


  • abcd567
    replied
    $ 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:


  • MarkDingo
    replied
    Originally posted by Birdie View Post
    I thought my receiver have problems. I removed the receiver front panel, cleaned the MicroSD contacts and reinstalled.
    There are a couple of ways of seeing if your receiver is the problem or not. The best and easiest is to have a look at the feed log on your receiving computer. At least for Raspberry PIs and other Linuxen, it's as simple as running the shell command:

    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:


  • Birdie
    replied
    Originally posted by Malcolml View Post
    Thanks for reply, I can put my hair back now. Sorry if I missed earlier reports.
    How ? Use Superglue ? LOL

    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:


  • MarkDingo
    replied
    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:


  • T-EICD2
    replied
    as of 21:30, 18-06-2018 there are still problems. Flight Radar Availability.jpg
    regards,
    F-EICD1

    Leave a comment:


  • tsunami
    replied
    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:


  • serek
    replied
    Originally posted by JohnnyBravo View Post
    Agreed!! 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....
    Are you trying to say that you ditched IPv4 completely and went IPv6 only!? That would be really JohnnyBravo style! You must not need Internet beyond Google, Facebook and very few others!

    Leave a comment:


  • CA Aurora
    replied
    My unit isn't working by the look of things. I've sent you an email.

    Leave a comment:

Working...
X