Page 7 of 18 FirstFirst ... 5678917 ... LastLast
Results 61 to 70 of 176

Thread: Problems with feeder statistics and data sharing

  1. #61
    First officer
    Join Date
    Sep 2013
    Location
    Farnborough, UK
    Posts
    204
    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

  2. #62
    Passenger
    Join Date
    Dec 2017
    Posts
    5
    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.

  3. #63
    Passenger
    Join Date
    Dec 2016
    Location
    NW Poland
    Posts
    3
    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 at 18:58.

  4. #64
    Passenger
    Join Date
    Dec 2017
    Posts
    5
    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.

  5. #65
    Passenger papasven's Avatar
    Join Date
    Jan 2014
    Location
    near Berlin
    Posts
    14
    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 |

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

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

  8. #68
    Flight attendant
    Join Date
    Apr 2018
    Posts
    67
    Dropping IPv6 also stops your PiAware from working too!! Lucky i run two boxes.

  9. #69
    Captain abcd567's Avatar
    Join Date
    Sep 2013
    Location
    Toronto CYYZ
    Posts
    2,854
    Quote 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

  10. #70
    Flight attendant
    Join Date
    Apr 2018
    Posts
    67
    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 at 06:30.

Posting Permissions

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