Page 9 of 18 FirstFirst ... 7891011 ... LastLast
Results 81 to 90 of 176

Thread: Problems with feeder statistics and data sharing

  1. #81
    Purser
    Join Date
    Nov 2016
    Posts
    155
    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

  2. #82
    Passenger
    Join Date
    May 2017
    Posts
    6
    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.

  3. #83
    Passenger
    Join Date
    Jan 2015
    Posts
    13
    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

  4. #84
    Captain abcd567's Avatar
    Join Date
    Sep 2013
    Location
    Toronto CYYZ
    Posts
    2,826
    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
    .

  5. #85
    Passenger
    Join Date
    Jan 2015
    Posts
    13
    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

  6. #86
    Passenger
    Join Date
    Jan 2015
    Posts
    13
    I still tried your suggestion, same problem.

  7. #87
    Passenger
    Join Date
    Jun 2018
    Posts
    7
    Quote 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.

  8. #88
    Passenger
    Join Date
    Jan 2015
    Posts
    13
    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

  9. #89
    Flight attendant JohnnyBravo's Avatar
    Join Date
    Mar 2016
    Location
    T-EHGG148
    Posts
    53
    Quote 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.

  10. #90
    Passenger
    Join Date
    Jun 2018
    Posts
    7
    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •