Announcement

Collapse
No announcement yet.

Problems with feeder statistics and data sharing

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

  • #61
    Any one else notice that the stats are still broken, everyone is still losing up time.

    I guess we now know what the hackers took when broke into fr24.
    T-EGLF8

    Comment


    • #62
      Yes... broken again.

      There is no excuse for the following...
      1. Not disabling IPv6 in DNS
      2. Not having the software try all addresses returned in the DNS query rather than just the first.

      I know I can disable IPv6 locally, but I will be buggered if I will break my system because someone will not fix their side of things.

      Comment


      • #63
        In fact, global stats are still broken. Local stats like range and amount of messages are OK. Do you really miss this "dick length competition" (which station is is the best source of data?).
        Sorry, we are delivering precious data which can be sold but we didn't get anything instead (except of access to nice mobile app).
        Website Admins, think about what will happen when disappointend people will stop to feed your website?
        Last edited by MDA; 2018-07-01, 18:58.

        Comment


        • #64
          There are 2 problems, one server side, the other client. Both related to IPv6.

          The server side has no idea about IPv6. Or perhaps it does, but their code may be junk with regards to it.

          The client side when making the DNS request, only attempt a connection on the first returned result, and since there are 4, of which the first 2 are IPv6, it never bothers to iterate through them to the IPv4 results, and so make a successful connection.

          I have no idea on the specifics of the server side of things, but the client problems are wholly inexcusable.

          Comment


          • #65
            Disabling IPV6 is not a good solution for me.
            I have now solved the connection problem for me by adding a line to the /etc/hosts file.

            mfg
            Code:
            104.20.1.101	feed.flightradar24.com
            | T-EDDB8 |T-EDDB28 | Virtual Radar | Dump1090 | ModesMixer2 |

            Comment


            • #66
              I guess we now know what the hackers took when broke into fr24.
              Can you expand on this ? Clearly, some of us aren't hacker-savvy and don't know ...

              ylis

              Comment


              • #67
                Originally posted by papasven View Post
                Disabling IPV6 is not a good solution for me.
                I have now solved the connection problem for me by adding a line to the /etc/hosts file.

                mfg
                Code:
                104.20.1.101	feed.flightradar24.com
                This is a risky and short-term fix.

                Flightrader uses the Cloudflare CDN and for many reasons CDNs may move a service from one IP to another. Say if they are doing maintenance in one of their data centers. Cloudflare reasonably expects that they can make such changes by updating their DNS. In fact CDNs live and die by their ability to modify DNS answers in response to traffic loads and proximity data and whatnot.

                Not saying that your fix isn't useful, but it's something that needs to be periodically checked and removed as soon as practical.

                Comment


                • #68
                  Dropping IPv6 also stops your PiAware from working too!! Lucky i run two boxes.

                  Comment


                  • #69
                    Originally posted by Coxy View Post
                    Dropping IPv6 also stops your PiAware from working too!! Lucky i run two boxes.
                    I have blocked IPv6 by adding "sysctl -w net.ipv6.conf.all.disable_ipv6=1" (without quotes) in file /etc/rc.local as shown below:

                    Code:
                    #!/bin/sh -e
                    #
                    # rc.local
                    #
                    # This script is executed at the end of each multiuser runlevel.
                    # Make sure that the script will "exit 0" on success or any other
                    # value on error.
                    #
                    # In order to enable or disable this script just change the execution
                    # bits.
                    #
                    # By default this script does nothing.
                    
                    # Print the IP address
                    _IP=$(hostname -I) || true
                    if [ "$_IP" ]; then
                      printf "My IP address is %s\n" "$_IP"
                    fi
                    
                    sysctl -w net.ipv6.conf.all.disable_ipv6=1
                    
                    exit 0

                    My PiAware works OK even after blocking IPv6
                    Code:
                    Jul 03 01:42:50 raspberrypi piaware[429]: 103 msgs recv'd from dump1090-fa (92 in last 5m); 103 msgs sent to FlightAware
                    Jul 03 01:47:50 raspberrypi piaware[429]: 195 msgs recv'd from dump1090-fa (92 in last 5m); 195 msgs sent to FlightAware
                    Jul 03 01:52:30 raspberrypi piaware[429]: mlat-client(632): Receiver status: connected
                    Jul 03 01:52:30 raspberrypi piaware[429]: mlat-client(632): Server status:   synchronized with 59 nearby receivers
                    Jul 03 01:52:30 raspberrypi piaware[429]: mlat-client(632): Receiver:   12.9 msg/s received        5.9 msg/s processed (46%)
                    Jul 03 01:52:30 raspberrypi piaware[429]: mlat-client(632): Server:      0.0 kB/s from server    0.0kB/s TCP to server     0.1kB/s UDP to se
                    Jul 03 01:52:31 raspberrypi piaware[429]: mlat-client(632): Results:  15.9 positions/minute
                    Jul 03 01:52:31 raspberrypi piaware[429]: mlat-client(632): Aircraft: 1 of 2 Mode S, 3 of 3 ADS-B used
                    Jul 03 01:52:50 raspberrypi piaware[429]: 272 msgs recv'd from dump1090-fa (77 in last 5m); 272 msgs sent to FlightAware
                    Jul 03 01:57:50 raspberrypi piaware[429]: 378 msgs recv'd from dump1090-fa (106 in last 5m); 378 msgs sent to FlightAware

                    Comment


                    • #70
                      Mmmm ok, as soon as i reboot - which enable IPv6 my Pi Aware starts feeding but when i run the sysctl -w net.ipv6.conf.all.disable_ipv6=1 it stops.

                      I even have trouble getting FR24 started properly after rebooting and need to do it in this order.

                      reboot
                      Stop dump
                      stop frfeed
                      stop pi

                      run IPv6 disable

                      restart dump
                      restart frfeed
                      retart pi

                      Ill try adding it to the rc.local

                      Might just be myset up. I have read a few of your other threads and wonder if my issue is due to using DVBT on the FR setup after the Dump1090 setup rather than running Beast????
                      Last edited by Coxy; 2018-07-03, 06:30.

                      Comment


                      • #71
                        Originally posted by Coxy View Post
                        Might just be myset up.......wonder if my issue is due to using DVBT on the FR setup after the Dump1090 setup rather than running Beast????
                        Most likely yes. If you already have dump1090-fa or dump1090-mutabity ver 1.15, and choose Receiver=DVBT, them fr24feed will install dump10o0-mutability v1.14, causing conflict between two versions of dump1090, and result in malfuntion.

                        Comment


                        • #72
                          Originally posted by MarkDingo View Post
                          This is a risky and short-term fix.

                          Flightrader uses the Cloudflare CDN and for many reasons CDNs may move a service from one IP to another. Say if they are doing maintenance in one of their data centers. Cloudflare reasonably expects that they can make such changes by updating their DNS. In fact CDNs live and die by their ability to modify DNS answers in response to traffic loads and proximity data and whatnot.

                          Not saying that your fix isn't useful, but it's something that needs to be periodically checked and removed as soon as practical.
                          Perhaps a better solution to those who still want to run both IPv4 and IPv6 on their Pi's:

                          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.
                          Both FR24 feeder and FlightAware feeder should now be happy and you don't have to worry about any DNS changes/updates.

                          Hope this helps!

                          Edit: If you have previously disabled IPv6 then you need to re-enable it for this to work properly!
                          Last edited by JohnnyBravo; 2018-07-03, 10:00.

                          Comment


                          • #73
                            Originally posted by ylis View Post
                            Can you expand on this ? Clearly, some of us aren't hacker-savvy and don't know ...
                            it wasn't about anything specific, just being sarcastic.
                            T-EGLF8

                            Comment


                            • #74
                              Some significant changes to the data overnight in the Shared Stats ....

                              ylis

                              Comment


                              • #75
                                Curiously monitoring dump1090 shows all my long range hits from North west, yet the polar plot indicates the only long range comes from the south east (where there is a ruddy great hill in the way? Also the 'range' indicates hits at 200nm+ yet the Maximum Distance seems less than half of that. (running a dedicated PI with an antenna above all local rooftops. Is it all still t1ts up?
                                Last edited by mem0tap; 2018-07-06, 08:29.

                                Comment

                                Working...
                                X