Announcement

Collapse
No announcement yet.

FR24feed on Raspberry Pi - Frequent DNS requests for NTP

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

  • FR24feed on Raspberry Pi - Frequent DNS requests for NTP

    I'm running FR24feed on a Pi 2 Model B. I already configured NTP in Raspbian (before installing FR24feed) to use "0.north-america.pool.ntp.org" and "1.north-america.pool.ntp.org" for NTP synchronization.

    However from my DNS logs I can see FR24Feed making constant lookups of other NTP servers - (1.asia.pool.ntp.org, 1.south-america.pool.ntp.org, 1.africa.pool.ntp.org, 1.oceania.pool.ntp.org). And it hit's them constantly - hundreds of times per day.

    How does FR24feed implement NTP? Because it seems to ignore my Raspbian configuration set in the NTP conf file, and goes it itself with it's own, seperate version of NTP. Can I stop this and let it use the NTP servers I defined, the North America ones?

    9Za3cm7.png

  • #2
    Why is this question not being answered? I have a local GPS based time server that provides 1PPS output via serial / USB to the raspberry pi on which fr24feed is installed, so it seems not necessary to use external NTP servers or even try to sync the OS time using remote NTP servers, can this be turned off and for it to use the local or at any rate configured NTP server that runs locally?
    Last edited by hnapel; 2017-01-03, 17:00.

    Comment


    • #3
      Workaround may be to edit /etc/hosts and add those names to point to 127.0.0.1, e.g.

      127.0.0.1 localhost 1.asia.pool.ntp.org 1.south-america.pool.ntp.org 1.africa.pool.ntp.org 1.oceania.pool.ntp.org

      Comment


      • #4
        Also I can add the NTP pool project hates it when 'vendors' add hardcoded pool servers to their devices / software http://www.pool.ntp.org/vendors.html FR24 being a responsible party should look into this.

        Comment


        • #5
          I caught the whole process in the act using the logging of dnsmasq (which I admit I was not aware of using...) , the fr24feed caches the DNS lookups, so you will have to restart fr24feed to observe this:

          Jan 3 18:58:11 dnsmasq[24058]: query[A] dns-verify.fr24.com from 127.0.0.1
          Jan 3 18:58:11 dnsmasq[24058]: forwarded dns-verify.fr24.com to 192.168.178.1
          Jan 3 18:58:11 dnsmasq[24058]: forwarded dns-verify.fr24.com to fd00::ca0e:14ff:fee9:8a03
          Jan 3 18:58:11 dnsmasq[24058]: reply dns-verify.fr24.com is 8.8.8.8
          Jan 3 18:58:11 dnsmasq[24058]: query[A] dns-verify.fr24.com from 127.0.0.1
          Jan 3 18:58:11 dnsmasq[24058]: cached dns-verify.fr24.com is 8.8.8.8
          Jan 3 18:58:11 dnsmasq[24058]: query[PTR] 8.8.8.8.in-addr.arpa from 127.0.0.1
          Jan 3 18:58:11 dnsmasq[24058]: forwarded 8.8.8.8.in-addr.arpa to 192.168.178.1
          Jan 3 18:58:11 dnsmasq[24058]: reply 8.8.8.8 is google-public-dns-a.google.com
          Jan 3 18:58:12 dnsmasq[24058]: query[A] 1.europe.pool.ntp.org from 127.0.0.1
          Jan 3 18:58:12 dnsmasq[24058]: forwarded 1.europe.pool.ntp.org to 192.168.178.1
          Jan 3 18:58:12 dnsmasq[24058]: reply 1.europe.pool.ntp.org is 46.165.212.204
          Jan 3 18:58:12 dnsmasq[24058]: reply 1.europe.pool.ntp.org is 213.203.202.38
          Jan 3 18:58:12 dnsmasq[24058]: reply 1.europe.pool.ntp.org is 5.9.49.12
          Jan 3 18:58:12 dnsmasq[24058]: reply 1.europe.pool.ntp.org is 147.231.100.5
          Jan 3 18:58:12 dnsmasq[24058]: query[A] 1.north-america.pool.ntp.org from 127.0.0.1
          Jan 3 18:58:12 dnsmasq[24058]: forwarded 1.north-america.pool.ntp.org to 192.168.178.1
          Jan 3 18:58:12 dnsmasq[24058]: reply 1.north-america.pool.ntp.org is 209.242.224.117
          Jan 3 18:58:12 dnsmasq[24058]: reply 1.north-america.pool.ntp.org is 74.82.59.142
          Jan 3 18:58:12 dnsmasq[24058]: reply 1.north-america.pool.ntp.org is 198.204.225.190
          Jan 3 18:58:12 dnsmasq[24058]: reply 1.north-america.pool.ntp.org is 54.236.224.171
          Jan 3 18:58:12 dnsmasq[24058]: query[A] 1.asia.pool.ntp.org from 127.0.0.1
          Jan 3 18:58:12 dnsmasq[24058]: forwarded 1.asia.pool.ntp.org to 192.168.178.1
          Jan 3 18:58:12 dnsmasq[24058]: reply 1.asia.pool.ntp.org is 157.7.208.12
          Jan 3 18:58:12 dnsmasq[24058]: reply 1.asia.pool.ntp.org is 109.226.40.40
          Jan 3 18:58:12 dnsmasq[24058]: reply 1.asia.pool.ntp.org is 123.108.200.124
          Jan 3 18:58:12 dnsmasq[24058]: reply 1.asia.pool.ntp.org is 203.95.213.129
          Jan 3 18:58:12 dnsmasq[24058]: query[A] 1.oceania.pool.ntp.org from 127.0.0.1
          Jan 3 18:58:12 dnsmasq[24058]: forwarded 1.oceania.pool.ntp.org to 192.168.178.1
          Jan 3 18:58:13 dnsmasq[24058]: reply 1.oceania.pool.ntp.org is 54.252.165.245
          Jan 3 18:58:13 dnsmasq[24058]: reply 1.oceania.pool.ntp.org is 192.189.54.17
          Jan 3 18:58:13 dnsmasq[24058]: reply 1.oceania.pool.ntp.org is 13.55.50.68
          Jan 3 18:58:13 dnsmasq[24058]: reply 1.oceania.pool.ntp.org is 103.242.70.4
          Jan 3 18:58:13 dnsmasq[24058]: query[A] 1.south-america.pool.ntp.org from 127.0.0.1
          Jan 3 18:58:13 dnsmasq[24058]: forwarded 1.south-america.pool.ntp.org to 192.168.178.1
          Jan 3 18:58:13 dnsmasq[24058]: reply 1.south-america.pool.ntp.org is 190.15.128.196
          Jan 3 18:58:13 dnsmasq[24058]: reply 1.south-america.pool.ntp.org is 200.160.0.8
          Jan 3 18:58:13 dnsmasq[24058]: reply 1.south-america.pool.ntp.org is 170.155.148.1
          Jan 3 18:58:13 dnsmasq[24058]: reply 1.south-america.pool.ntp.org is 200.160.7.193
          Jan 3 18:58:13 dnsmasq[24058]: query[A] 1.africa.pool.ntp.org from 127.0.0.1
          Jan 3 18:58:13 dnsmasq[24058]: forwarded 1.africa.pool.ntp.org to 192.168.178.1
          Jan 3 18:58:13 dnsmasq[24058]: reply 1.africa.pool.ntp.org is 197.82.150.123
          Jan 3 18:58:13 dnsmasq[24058]: reply 1.africa.pool.ntp.org is 196.10.52.57
          Jan 3 18:58:13 dnsmasq[24058]: reply 1.africa.pool.ntp.org is 41.79.80.34
          Jan 3 18:58:13 dnsmasq[24058]: query[A] 1.europe.pool.ntp.org from 127.0.0.1
          Jan 3 18:58:13 dnsmasq[24058]: cached 1.europe.pool.ntp.org is 147.231.100.5
          Jan 3 18:58:13 dnsmasq[24058]: cached 1.europe.pool.ntp.org is 5.9.49.12
          Jan 3 18:58:13 dnsmasq[24058]: cached 1.europe.pool.ntp.org is 213.203.202.38
          Jan 3 18:58:13 dnsmasq[24058]: cached 1.europe.pool.ntp.org is 46.165.212.204
          Jan 3 18:58:13 dnsmasq[24058]: query[A] 1.north-america.pool.ntp.org from 127.0.0.1
          Jan 3 18:58:13 dnsmasq[24058]: cached 1.north-america.pool.ntp.org is 54.236.224.171
          Jan 3 18:58:13 dnsmasq[24058]: cached 1.north-america.pool.ntp.org is 198.204.225.190
          Jan 3 18:58:13 dnsmasq[24058]: cached 1.north-america.pool.ntp.org is 74.82.59.142
          Jan 3 18:58:13 dnsmasq[24058]: cached 1.north-america.pool.ntp.org is 209.242.224.117
          Jan 3 18:58:14 dnsmasq[24058]: query[A] 1.asia.pool.ntp.org from 127.0.0.1
          Jan 3 18:58:14 dnsmasq[24058]: cached 1.asia.pool.ntp.org is 203.95.213.129
          Jan 3 18:58:14 dnsmasq[24058]: cached 1.asia.pool.ntp.org is 123.108.200.124
          Jan 3 18:58:14 dnsmasq[24058]: cached 1.asia.pool.ntp.org is 109.226.40.40
          Jan 3 18:58:14 dnsmasq[24058]: cached 1.asia.pool.ntp.org is 157.7.208.12
          Jan 3 18:58:14 dnsmasq[24058]: query[A] 1.oceania.pool.ntp.org from 127.0.0.1
          Jan 3 18:58:14 dnsmasq[24058]: cached 1.oceania.pool.ntp.org is 103.242.70.4
          Jan 3 18:58:14 dnsmasq[24058]: cached 1.oceania.pool.ntp.org is 13.55.50.68
          Jan 3 18:58:14 dnsmasq[24058]: cached 1.oceania.pool.ntp.org is 192.189.54.17
          Jan 3 18:58:14 dnsmasq[24058]: cached 1.oceania.pool.ntp.org is 54.252.165.245
          Jan 3 18:58:14 dnsmasq[24058]: query[A] 1.south-america.pool.ntp.org from 127.0.0.1
          Jan 3 18:58:14 dnsmasq[24058]: cached 1.south-america.pool.ntp.org is 200.160.7.193
          Jan 3 18:58:14 dnsmasq[24058]: cached 1.south-america.pool.ntp.org is 170.155.148.1
          Jan 3 18:58:14 dnsmasq[24058]: cached 1.south-america.pool.ntp.org is 200.160.0.8
          Jan 3 18:58:14 dnsmasq[24058]: cached 1.south-america.pool.ntp.org is 190.15.128.196
          Jan 3 18:58:14 dnsmasq[24058]: query[A] 1.africa.pool.ntp.org from 127.0.0.1
          Jan 3 18:58:14 dnsmasq[24058]: cached 1.africa.pool.ntp.org is 41.79.80.34
          Jan 3 18:58:14 dnsmasq[24058]: cached 1.africa.pool.ntp.org is 196.10.52.57
          Jan 3 18:58:14 dnsmasq[24058]: cached 1.africa.pool.ntp.org is 197.82.150.123
          Jan 3 18:58:15 dnsmasq[24058]: query[A] feed.flightradar24.com from 127.0.0.1
          Jan 3 18:58:15 dnsmasq[24058]: forwarded feed.flightradar24.com to 192.168.178.1
          Jan 3 18:58:15 dnsmasq[24058]: reply feed.flightradar24.com is <CNAME>
          Jan 3 18:58:15 dnsmasq[24058]: reply got.fr24.com is 83.140.21.89
          Jan 3 18:58:16 dnsmasq[24058]: query[A] mlat-1.fr24.com from 127.0.0.1
          Jan 3 18:58:16 dnsmasq[24058]: forwarded mlat-1.fr24.com to 192.168.178.1
          Jan 3 18:58:16 dnsmasq[24058]: reply mlat-1.fr24.com is <CNAME>
          Jan 3 18:58:16 dnsmasq[24058]: reply wro.fr24.com is 83.140.21.66

          Comment


          • #6
            I solved it as follows, on a typical raspberry pi with raspbian I suppose dnsmasq is enabled by default, it is a small local DNS cache program, I added to the file /etc/init.d/dnsmasq the following:

            # custom logging
            DNSMASQ_OPTS="$DNSMASQ_OPTS --log-queries --log-facility=/var/log/dnsmasq.log"

            # Add local hosts file
            DNSMASQ_OPTS="$DNSMASQ_OPTS --addn-hosts=/home/pi/fake_ntp_hosts"

            In the file fake_ntp_hosts it has:

            root@raspberrypi:/var/log# cat /home/pi/fake_ntp_hosts
            # route these ntp pool requests to the local timeserver
            # workaround fr24feed ntp issue
            192.168.178.12 1.europe.pool.ntp.org
            192.168.178.12 1.north-america.pool.ntp.org
            192.168.178.12 1.asia.pool.ntp.org
            192.168.178.12 1.oceania.pool.ntp.org
            192.168.178.12 1.south-america.pool.ntp.org
            192.168.178.12 1.africa.pool.ntp.org

            On my LAN the 192.168.178.12 is a GPS based time server that beats any remote NTP server, if your local NTP server is configured well, you may want to replace this with 127.0.0.1 .

            Here's the result of restarting dnsmasq and fr24feed service from the log files:

            fr24feed.log :

            2017-01-03 20:52:44 | [time][i]Synchronizing time via NTP
            2017-01-03 20:52:44 | [time][i]Time synchronized correctly, offset +0.0000 seconds

            dnsmasq.log :

            Jan 3 20:52:44 dnsmasq[27150]: query[A] 1.europe.pool.ntp.org from 127.0.0.1
            Jan 3 20:52:44 dnsmasq[27150]: /home/pi/fake_ntp_hosts 1.europe.pool.ntp.org is 192.168.178.12
            Jan 3 20:52:44 dnsmasq[27150]: query[A] 1.north-america.pool.ntp.org from 127.0.0.1
            Jan 3 20:52:44 dnsmasq[27150]: /home/pi/fake_ntp_hosts 1.north-america.pool.ntp.org is 192.168.178.12
            Jan 3 20:52:44 dnsmasq[27150]: query[A] 1.asia.pool.ntp.org from 127.0.0.1
            Jan 3 20:52:44 dnsmasq[27150]: /home/pi/fake_ntp_hosts 1.asia.pool.ntp.org is 192.168.178.12
            Jan 3 20:52:44 dnsmasq[27150]: query[A] 1.oceania.pool.ntp.org from 127.0.0.1
            Jan 3 20:52:44 dnsmasq[27150]: /home/pi/fake_ntp_hosts 1.oceania.pool.ntp.org is 192.168.178.12
            Jan 3 20:52:44 dnsmasq[27150]: query[A] 1.south-america.pool.ntp.org from 127.0.0.1
            Jan 3 20:52:44 dnsmasq[27150]: /home/pi/fake_ntp_hosts 1.south-america.pool.ntp.org is 192.168.178.12
            Jan 3 20:52:44 dnsmasq[27150]: query[A] 1.africa.pool.ntp.org from 127.0.0.1
            Jan 3 20:52:44 dnsmasq[27150]: /home/pi/fake_ntp_hosts 1.africa.pool.ntp.org is 192.168.178.12
            Jan 3 20:52:44 dnsmasq[27150]: query[A] 1.europe.pool.ntp.org from 127.0.0.1
            Jan 3 20:52:44 dnsmasq[27150]: /home/pi/fake_ntp_hosts 1.europe.pool.ntp.org is 192.168.178.12
            Jan 3 20:52:44 dnsmasq[27150]: query[A] 1.north-america.pool.ntp.org from 127.0.0.1
            Jan 3 20:52:44 dnsmasq[27150]: /home/pi/fake_ntp_hosts 1.north-america.pool.ntp.org is 192.168.178.12
            Jan 3 20:52:44 dnsmasq[27150]: query[A] 1.asia.pool.ntp.org from 127.0.0.1
            Jan 3 20:52:44 dnsmasq[27150]: /home/pi/fake_ntp_hosts 1.asia.pool.ntp.org is 192.168.178.12
            Jan 3 20:52:44 dnsmasq[27150]: query[A] 1.oceania.pool.ntp.org from 127.0.0.1
            Jan 3 20:52:44 dnsmasq[27150]: /home/pi/fake_ntp_hosts 1.oceania.pool.ntp.org is 192.168.178.12
            Jan 3 20:52:44 dnsmasq[27150]: query[A] 1.south-america.pool.ntp.org from 127.0.0.1
            Jan 3 20:52:44 dnsmasq[27150]: /home/pi/fake_ntp_hosts 1.south-america.pool.ntp.org is 192.168.178.12
            Jan 3 20:52:44 dnsmasq[27150]: query[A] 1.africa.pool.ntp.org from 127.0.0.1
            Jan 3 20:52:44 dnsmasq[27150]: /home/pi/fake_ntp_hosts 1.africa.pool.ntp.org is 192.168.178.12
            Jan 3 20:52:45 dnsmasq[27150]: query[A] feed.flightradar24.com from 127.0.0.1
            Jan 3 20:52:45 dnsmasq[27150]: cached feed.flightradar24.com is <CNAME>
            Jan 3 20:52:45 dnsmasq[27150]: cached got.fr24.com is 83.140.21.89

            Comment


            • #7
              You can now be potentially sending bad info to the server to calculate MLAT positions. The reason they use NTP is to make a reference point that nearly all receivers in a given area can be synchronized with and tag their packets with the same upload time. If each has a different type of GPS receiver, the CPU load, connection, Pi type and method of connecting to the clock can differ. And with things that move fast, this means 4 packets stamped with different times within miliseconds could be as much as 3kms off course or have their data ignored/not able to assist in calculation due to age

              In that respect, they have pointed out adding a GPS is generally ignored or causes sync fight issus (the same with a different NTP specified in windows). This 'fix' above now bypasses that common filtering and may well be sending different data to the others still utilising NTP nullifying any results
              Posts not to be taken as official support representation - Just a helpful uploader who tinkers

              Comment


              • #8
                An yes, I realise you have input against the technological faults for/against in the past.

                But they made it the way it is for everyone to be on a level ground without much input. The odd client here and there changing that probably is going to do more harm than good.

                But without the actual devs visiting the forums these days, heading people off into an unknown territory possibly isnt a good idea
                Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                Comment


                • #9
                  The local GPS based timeserver is always more accurate than any remote one, for example I know my home router has an asynchronous latency that would already add milliseconds to the time offset that NTP cannot correct for, sorry but this answer does not convince me. It's not good for anyone at ground level, they should apply for a vendor zone and configure NTP servers based on closer geographical location, with all the knowledge about positions that should be possible. MLAT does not make use of NTP , it would be too crude anyway, MLAT works by using timestamps of other aircraft in the vicinity that send their position. If the developers don't read these posts then what's the point? Anyway I also made the NTP pool guys aware of this misconfiguration and they may have more convincing arguments.

                  Comment


                  • #10
                    I have no doubt your local time may now be more accurate than others. But as a result you are now causing them or your own data to not match what is expected while the others all use the same sources.

                    Mlat uses an airborne aircraft with time tag for reference yes, but as data is grouped every 4 seconds from clients before being sent off with an upload time the age of the contents matter...

                    Sent from my XT1092 using Tapatalk
                    Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                    Comment


                    • #11
                      Originally posted by Oblivian View Post
                      I have no doubt your local time may now be more accurate than others. But as a result you are now causing them or your own data to not match what is expected while the others all use the same sources.
                      Mlat uses an airborne aircraft with time tag for reference yes, but as data is grouped every 4 seconds from clients before being sent off with an upload time the age of the contents matter...
                      Sorry Oblivian, but You are talking nonsense.

                      First, NTP is far to crude to have any use for the MLAT timestamp. So it is not used for that.

                      Secondly, the difference between different NTP time servers is so small, that it can NOT affect the timing of when the feeders send data. The transmission delay, using various types of connections, 3G/4G etc, inserts a much bigger time difference than any NTP ambiguity.

                      And if there is any special reason to use the NTP servers so impolitely, the developers should come back here and explain it. After all, we host the receivers, provide the locations, electricity and bandwidth. They make money from the data. Not too much to ask, I think.

                      /M
                      F-ESDF1, F-ESGG1, F-ESGP1, F-ESNK1, F-ESNV2, F-ESNV3 F-ESSL4, F-ESNZ7, F-LFMN3
                      T-ESNL1, T-ESNL2, T-ESGR15
                      P-ESIA, P-ESIB, P-ESGF, P-ESSN, P-EFMA
                      mrmac (a) fastest.cc

                      Comment


                      • #12
                        *shrug*

                        Is what is implied so far. It's done differently to the likes of FA

                        All about feeding data to Flightradar24 (The Flightradar24 receiver, Raspberry Pi and Windows feeding software). No discussions about Flightradar24 web or apps.

                        All about feeding data to Flightradar24 (The Flightradar24 receiver, Raspberry Pi and Windows feeding software). No discussions about Flightradar24 web or apps.

                        All about feeding data to Flightradar24 (The Flightradar24 receiver, Raspberry Pi and Windows feeding software). No discussions about Flightradar24 web or apps.
                        Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                        Comment


                        • #13
                          Originally posted by Oblivian View Post
                          *shrug*
                          Is that another way of saying "I don't have a clue" ?

                          Everything you linked to supports what I wrote above. Nothing "implied" supports your theories.

                          /M
                          F-ESDF1, F-ESGG1, F-ESGP1, F-ESNK1, F-ESNV2, F-ESNV3 F-ESSL4, F-ESNZ7, F-LFMN3
                          T-ESNL1, T-ESNL2, T-ESGR15
                          P-ESIA, P-ESIB, P-ESGF, P-ESSN, P-EFMA
                          mrmac (a) fastest.cc

                          Comment


                          • #14
                            Yes. And I dont think I ever insinuated otherwise. A normal pleb like me normally doesnt need to when the app provider had an ideal in mind and implements it in their code.

                            All I understand is data is time stamped on reception where the source has no aeronautical gps time attached ala all mode s. Held for the 4 seconds bundled with more, processed and stamped again by the feeder portion as it fires it off. So if your clock is off by a time those tags are likely to be inaccurate and csuse the time errors we have people post about in console? It appears fr stop this by getting the client app to control system time via ntp. On everyones.

                            You would think that artificially changing the source it uses from our neighbors feeding down the road who are all using the local ntp will all of a sudden make the bundled time (or distance) differ for the same apparent time.

                            Not that pi mlat has been seen thus far. as the guys in aus have found the mlat fed back from fa is visible below 1500 while invisible on fr.

                            Sent from my GT-I9300 using Tapatalk
                            Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                            Comment


                            • #15
                              No it uses pool servers that reply with different actual servers, just try nslookup 1.europe.pool.ntp.org a few times in a row, also with the great spread in geographical locations of all the receivers this will result in an enormous spread in timing accuracy. If you want to stick with the defaults it's ok, ultimately it is for the fr24 developers to deal with this, otherwise if like NasEscobar you have carefully chosen which servers to use in the local NTP setup you may use this tweak to point all time requests to it and it will probably yield a greater accuracy, then if you have your own reliable local NTP server (typically GPS based, if you can afford an atomic clock you would not be using raspberry PI's ...) then you can use the same as I did.

                              Comment

                              Working...
                              X