Announcement

Collapse
No announcement yet.

Problems with feeder statistics and data sharing

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

  • #76
    Looks like stats have been fixed - up time has started to climb again and Max and Average ranges now correct, seemingly for everyone.

    T-EGSY1

    Comment


    • #77
      Originally posted by Scroggie View Post
      Looks like stats have been fixed - up time has started to climb again and Max and Average ranges now correct, seemingly for everyone.

      T-EGSY1
      Lets just hope nobody lost their luggage!

      T-EGVF5

      Comment


      • #78
        Well, I don't think, that maxrange and especially average range are showing correct data at this point. As the 30 days is used in the equation to calculate the average value and we have had an outage of several weeks, it will take 30 days to get the facts showing "correct" values again. Well, unless you add a floating equation, that increases the divider by one each day starting with with the number of days with data available. I won't expect FR24 to put in that amount of effort. So along with the uptime especially the avarage range should start to increase too.

        T-EDDV13

        Comment


        • #79
          Agreed. When the max range changed for first time in weeks I looked at the distances of a number of feeders, it was their current day max distance. It now appears to be the max distance is for the best day for each individual. And it appears to be what they were doing long before the database crash where your max distance was simply your best max in the past 30 days, and after 30 days it would drop to your next best.

          Comment


          • #80
            Yes agreed. I didn't mean "correct" in the literal sense just that the database was at last updating properly.

            Comment


            • #81
              Any thoughts on what the average range is measuring? The 'help' icon says its the average range of the radar in the last 30 days. Clearly its not the 30 day average of the max range - so is it the average range of all reports ( huge calculation effort ) for the last 30 days ? or the average of the daily average for the last 30 days ?? or the average max range of each aircraft ??

              ylis

              Comment


              • #82
                From what I saw, long before the system crash, it appeared to me that it was the max distance a feeder had posted in the last 30 days, a single day number. Sometimes those numbers seemed even more than 30 days old. There was very little movement in the max distances. But your question is a good one. There are a lot of different things that description could mean but most logically it should be the 30 day moving average of each day's single longest distance recorded.

                Comment


                • #83
                  Hi,

                  I've been feeding traffic from a very remote site for some time now (T-YBBE1). Unfortunately I don't have unfettered network access at that remote site, so the only way to get the traffic into fr24 is by port forwarding the dump1090/beast port through an SSH tunnel to an AWS instance running fr24feed. This worked nicely until about 10 days ago when there was a power interruption to the site. I've just recovered that server, traffic is coming in as usual, but fr24feed keeps giving me this error:

                  2018-07-10 01:06:03 | [reader][i]Connecting to Beast receiver via (avr-tcp://127.0.0.1:30002)
                  2018-07-10 01:06:03 | [reader][i]Connected to the receiver, configuring
                  2018-07-10 01:06:03 | [reader][i]Configured, processing messages
                  2018-07-10 01:07:12 | [feed][i]Downloading configuration
                  2018-07-10 01:07:12 | [e]HTTP Response: [HTTP/1.1 403 Forbidden]
                  2018-07-10 01:07:12 | [feed][i]Failed on start, Sleeping 120 seconds
                  2018-07-10 01:09:12 | [feed][i]Downloading configuration
                  2018-07-10 01:09:12 | [e]HTTP Response: [HTTP/1.1 403 Forbidden]
                  2018-07-10 01:09:12 | [feed][i]Failed on start, Sleeping 120 seconds
                  2018-07-10 01:09:14 | [time][i]Synchronizing time via NTP
                  2018-07-10 01:09:17 | [time][i]Time synchronized correctly, offset +0.0024 seconds, drift 0.0013 seconds/minute
                  2018-07-10 01:11:12 | [feed][i]Downloading configuration
                  2018-07-10 01:11:12 | [e]HTTP Response: [HTTP/1.1 403 Forbidden]

                  and so forth...

                  Looks like fr24feed is trying to get some information from your servers but fails with a 403. Any idea how to fix this?

                  Thanks

                  - Balt

                  Comment


                  • #84
                    balt

                    Give this command in the AWS system running fr24feed

                    Code:
                    sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
                    Wait for 5 minutes, then check status
                    Code:
                    fr24feed-status
                    .

                    Comment


                    • #85
                      feed.flightradar24.com resolves as an IPv4 address, so I don't think that's the problem:

                      dig feed.flightradar24.com

                      ; <<>> DiG 9.10.3-P4-Ubuntu <<>> feed.flightradar24.com
                      ;; global options: +cmd
                      ;; Got answer:
                      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60219
                      ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

                      ;; OPT PSEUDOSECTION:
                      ; EDNS: version: 0, flags:; udp: 4096
                      ;; QUESTION SECTION:
                      ;feed.flightradar24.com. IN A

                      ;; ANSWER SECTION:
                      feed.flightradar24.com. 23 IN CNAME feed.flightradar24.com.cdn.cloudflare.net.
                      feed.flightradar24.com.cdn.cloudflare.net. 23 IN A 104.20.0.101
                      feed.flightradar24.com.cdn.cloudflare.net. 23 IN A 104.20.1.101

                      ;; Query time: 0 msec
                      ;; SERVER: 172.31.0.2#53(172.31.0.2)
                      ;; WHEN: Tue Jul 10 01:47:53 UTC 2018
                      ;; MSG SIZE rcvd: 138

                      Comment


                      • #86
                        I still tried your suggestion, same problem.

                        Comment


                        • #87
                          Originally posted by balt View Post
                          feed.flightradar24.com resolves as an IPv4 address, so I don't think that's the problem:

                          dig feed.flightradar24.com
                          That doesn't preclude them also resolving as ipv6 and the client taking the ipv6 choice. What does:

                          dig feed.flightradar24.com AAAA

                          show?

                          It's not very likely, but the ipv6 servers may be different from the ipv4 servers and as such may be having difficulties and thus returning 403 whereas the ipv4 servers don't.

                          Not saying this is the case, but worth eliminating. Particularly as we know that flightradar24 are actively trying to get their ipv6 system back up and running.

                          Comment


                          • #88
                            interesting times...

                            making sure ipv6 is off:

                            ubuntu@syd-rssh:~$ sysctl net.ipv6.conf.all.disable_ipv6
                            net.ipv6.conf.all.disable_ipv6 = 1

                            then resolving ipv6 name still works:

                            ubuntu@syd-rssh:~$ dig feed.flightradar24.com AAAA

                            ; <<>> DiG 9.10.3-P4-Ubuntu <<>> feed.flightradar24.com AAAA
                            ;; global options: +cmd
                            ;; Got answer:
                            ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40249
                            ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

                            ;; OPT PSEUDOSECTION:
                            ; EDNS: version: 0, flags:; udp: 4096
                            ;; QUESTION SECTION:
                            ;feed.flightradar24.com. IN AAAA

                            ;; ANSWER SECTION:
                            feed.flightradar24.com. 41 IN CNAME feed.flightradar24.com.cdn.cloudflare.net.
                            feed.flightradar24.com.cdn.cloudflare.net. 60 IN AAAA 2400:cb00:2048:1::6814:165
                            feed.flightradar24.com.cdn.cloudflare.net. 60 IN AAAA 2400:cb00:2048:1::6814:65

                            ;; Query time: 5 msec
                            ;; SERVER: 172.31.0.2#53(172.31.0.2)
                            ;; WHEN: Tue Jul 10 06:51:40 UTC 2018
                            ;; MSG SIZE rcvd: 162

                            Comment


                            • #89
                              Originally posted by balt View Post
                              interesting times...

                              making sure ipv6 is off:

                              ubuntu@syd-rssh:~$ sysctl net.ipv6.conf.all.disable_ipv6
                              net.ipv6.conf.all.disable_ipv6 = 1

                              then resolving ipv6 name still works:

                              ubuntu@syd-rssh:~$ dig feed.flightradar24.com AAAA

                              ; <<>> DiG 9.10.3-P4-Ubuntu <<>> feed.flightradar24.com AAAA
                              ;; global options: +cmd
                              ;; Got answer:
                              ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40249
                              ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

                              ;; OPT PSEUDOSECTION:
                              ; EDNS: version: 0, flags:; udp: 4096
                              ;; QUESTION SECTION:
                              ;feed.flightradar24.com. IN AAAA

                              ;; ANSWER SECTION:
                              feed.flightradar24.com. 41 IN CNAME feed.flightradar24.com.cdn.cloudflare.net.
                              feed.flightradar24.com.cdn.cloudflare.net. 60 IN AAAA 2400:cb00:2048:1::6814:165
                              feed.flightradar24.com.cdn.cloudflare.net. 60 IN AAAA 2400:cb00:2048:1::6814:65

                              ;; Query time: 5 msec
                              ;; SERVER: 172.31.0.2#53(172.31.0.2)
                              ;; WHEN: Tue Jul 10 06:51:40 UTC 2018
                              ;; MSG SIZE rcvd: 162
                              Yes, I believe that behavior is correct.
                              You are asking a DNS server to tell you the IPv6 address for feed.flightradar24.com but that request can still be made via an IPv4 connection.

                              You can try the command "ping6 feed.flightradar24.com" to ping FR24 via IPv6, or even "ping6 localhost"
                              If you get returns, then you know that you still have IPv6 enabled.
                              If it seems as if the command hangs and doesn't give any output, then use "CTRL-C" to stop it and it will tell you how many packets were sent and what the loss was.

                              Comment


                              • #90
                                Originally posted by balt View Post
                                interesting times...

                                making sure ipv6 is off:

                                ubuntu@syd-rssh:~$ sysctl net.ipv6.conf.all.disable_ipv6
                                net.ipv6.conf.all.disable_ipv6 = 1

                                then resolving ipv6 name still works:

                                ubuntu@syd-rssh:~$ dig feed.flightradar24.com AAAA

                                Yeah, that's expected. A lot of people confuse having an ipv6 network with being able to make DNS queries of certain types - such as AAAA. Your DNS query went over ipv4 asking the other end for any entries that match the "AAAA" type. Think of a DNS query as akin to a database query. The database really doesn't care what transport you used to get there.

                                The salient point is that the feeder program can't use an IPv6 address even if it bothers to query for one as you've disabled ipv6 at the kernel.

                                On that basis, if you're still getting the 403 errors, then there is likely some authentication issue (such as the config containing an old password) that is unrelated to the current flightradar24 stats issues.

                                Comment

                                Working...
                                X