Announcement

Collapse
No announcement yet.

MLAT enabled but not running

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

  • #46
    regarding the MLAT issue
    Spudd

    I used to get that error why my PI was running the Jessie Raspbian build. It worked fine when i reinstalled under Wheezy.

    try;

    cat /etc/os-release

    and see what it says. Mine reads;


    PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
    NAME="Raspbian GNU/Linux"
    VERSION_ID="7"
    VERSION="7 (wheezy)"
    ID=raspbian
    ID_LIKE=debian
    ANSI_COLOR="1;31"
    HOME_URL="http://www.raspbian.org/"
    SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
    BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
    I am certainly running Jessie build. What where you running geekycow?

    All about feeding data to Flightradar24 (The Flightradar24 receiver, Raspberry Pi and Windows feeding software). No discussions about Flightradar24 web or apps.
    Last edited by spudd; 2016-04-01, 01:59.

    Comment


    • #47
      Originally posted by mainie View Post
      Moin,
      the 0/0 stats might be a server issue. But I think the "[reader][i]Connecting to Beast receiver via (tcp://localhost:30005@Cg)" is a produced by 'fr24feed'. Do you have piaware installed and dump1090 allready fired up when you start fr24feed?

      Regrads
      Maik
      Actually not sure...as they all start on boot.

      The issue support said was attributed to their server was the recurring error:
      [mlat][w]Could not ping MLAT server, result=-1000, number of errors=1.
      Last edited by KK6LDW; 2016-04-01, 05:23.

      Comment


      • #48
        Originally posted by KK6LDW View Post
        Actually not sure...as they all start on boot.

        The issue support said was attributed to their server was the recurring error:
        [mlat][w]Could not ping MLAT server, result=-1000, number of errors=1.
        Ah, ok.. To prevent fr24feed using localhost:30005@Cg make sure fr24feed is started first. It points out that on startup the binary first checks for a running dump1090 instance. If this true it will check for the presence of /usr/bin/piaware. If both conditions are met fr24feed will always use this interesting beast-output-port settings. fr24feed also checks for a running fa-mlat-client process. But this condition doesn't have any effect on this parameter at all.

        Maik

        Comment


        • #49
          Originally posted by Oblivian View Post
          Due to timezone currently at work for another 7 or so hrs and I think we goto an australasian server. But shall do. And yeah, techo enough to know my way around hence the telnet suggestions etc
          Did you ever get a chance to try this oblivion?

          Originally posted by geekycow View Post
          A-HA!

          It *IS* the server, it's not us.

          Given KK6LDW was having success with the usa-2.fr24.com server, I did a temporary hack and changed the Pi's /etc/hosts file such that mlat-1.fr24.com would resolve to the same IP as usa-2.fr24.com maps to - if I do that, the log files suddenly change....

          2016-03-31 00:29:38 | [mlat][i]Registering MLAT station
          2016-03-31 00:29:39 | [mlat][i]Registering MLAT station: FAILURE
          2016-03-31 00:29:40 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
          2016-03-31 00:29:40 | [mlat][i]Registering MLAT station
          2016-03-31 00:29:42 | [mlat][i]Registering MLAT station: FAILURE
          2016-03-31 00:29:43 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
          2016-03-31 00:29:43 | [mlat][i]Registering MLAT station
          2016-03-31 00:29:44 | [mlat][i]Registering MLAT station: FAILURE
          2016-03-31 00:29:45 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
          2016-03-31 00:29:45 | [mlat][i]Registering MLAT station
          2016-03-31 00:29:46 | [mlat][i]Registering MLAT station: SUCCESS
          2016-03-31 00:29:47 | [feed][i]sent 1, filtered 0 AC in 1 packet
          2016-03-31 00:29:50 | [mlat][i]Pinging the server
          2016-03-31 00:29:51 | [mlat][i]Stats 0/0
          2016-03-31 00:29:55 | [feed][i]sent 1, filtered 0 AC in 1 packet
          2016-03-31 00:30:02 | [feed][i]sent 1, filtered 0 AC in 1 packet
          2016-03-31 00:30:07 | [feed][i]sent 1, filtered 0 AC in 1 packet
          2016-03-31 00:30:10 | [mlat][i]Pinging the server
          2016-03-31 00:30:11 | [mlat][i]Stats 0/0
          2016-03-31 00:30:13 | [feed][i]sent 1, filtered 0 AC in 1 packet
          2016-03-31 00:30:21 | [feed][i]sent 1, filtered 0 AC in 1 packet
          2016-03-31 00:30:23 | [feed][i]filtering out 1 overlapping AC (saving bandwidth)
          2016-03-31 00:30:27 | [feed][i]sent 0, filtered 1 AC in 0 packets
          2016-03-31 00:30:30 | [mlat][i]Pinging the server
          2016-03-31 00:30:31 | [mlat][i]Stats 0/0
          2016-03-31 00:30:33 | [feed][i]sent 0, filtered 1 AC in 0 packets
          2016-03-31 00:30:49 | [mlat][i]Pinging the server


          You can see the point where the /etc/hosts file was updated and it suddenly works.

          (Overriding the server in this way is not a proper solution and risks supplying poor/slow data - so I only did this temporarily to test the theory.)

          Warm Regards
          Julie
          x
          What did you change in /etc/hosts file to get it to point at the different MLAT server? I want to try this to confirm it is the server and not me.

          Comment


          • #50
            Originally posted by spudd View Post
            Did you ever get a chance to try this oblivion?



            What did you change in /etc/hosts file to get it to point at the different MLAT server? I want to try this to confirm it is the server and not me.
            I added-

            52.20.254.84 mlat-1.fr24.com

            -to the bottom of /etc/hosts

            52.20.254.84 is the IP address of usa-2.fr24.com, which appears to be working; however, there's probably a reason why it's using a different server and therefore best not keep doing that for too long, just enough to test the theory. You should notice the change in status almost immediately, without even restarting.

            Comment


            • #51
              Originally posted by spudd View Post
              regarding the MLAT issue


              I am certainly running Jessie build. What where you running geekycow?

              http://forum.flightradar24.com/threa...d?goto=newpost
              Jessie.

              Jessie uses systemd and handles service/daemon start-up slightly differently, amongst other things. But any new Pi config is probably going to be Jessie!

              Comment


              • #52
                Originally posted by Oblivian View Post
                Due to timezone currently at work for another 7 or so hrs and I think we goto an australasian server. But shall do. And yeah, techo enough to know my way around hence the telnet suggestions etc
                Originally posted by geekycow View Post
                A-HA!

                It *IS* the server, it's not us.

                Given KK6LDW was having success with the usa-2.fr24.com server, I did a temporary hack and changed the Pi's /etc/hosts file such that mlat-1.fr24.com would resolve to the same IP as usa-2.fr24.com maps to - if I do that, the log files suddenly change....

                2016-03-31 00:29:38 | [mlat][i]Registering MLAT station
                2016-03-31 00:29:39 | [mlat][i]Registering MLAT station: FAILURE
                2016-03-31 00:29:40 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
                2016-03-31 00:29:40 | [mlat][i]Registering MLAT station
                2016-03-31 00:29:42 | [mlat][i]Registering MLAT station: FAILURE
                2016-03-31 00:29:43 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
                2016-03-31 00:29:43 | [mlat][i]Registering MLAT station
                2016-03-31 00:29:44 | [mlat][i]Registering MLAT station: FAILURE
                2016-03-31 00:29:45 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
                2016-03-31 00:29:45 | [mlat][i]Registering MLAT station
                2016-03-31 00:29:46 | [mlat][i]Registering MLAT station: SUCCESS
                2016-03-31 00:29:47 | [feed][i]sent 1, filtered 0 AC in 1 packet
                2016-03-31 00:29:50 | [mlat][i]Pinging the server
                2016-03-31 00:29:51 | [mlat][i]Stats 0/0
                2016-03-31 00:29:55 | [feed][i]sent 1, filtered 0 AC in 1 packet
                2016-03-31 00:30:02 | [feed][i]sent 1, filtered 0 AC in 1 packet
                2016-03-31 00:30:07 | [feed][i]sent 1, filtered 0 AC in 1 packet
                2016-03-31 00:30:10 | [mlat][i]Pinging the server
                2016-03-31 00:30:11 | [mlat][i]Stats 0/0
                2016-03-31 00:30:13 | [feed][i]sent 1, filtered 0 AC in 1 packet
                2016-03-31 00:30:21 | [feed][i]sent 1, filtered 0 AC in 1 packet
                2016-03-31 00:30:23 | [feed][i]filtering out 1 overlapping AC (saving bandwidth)
                2016-03-31 00:30:27 | [feed][i]sent 0, filtered 1 AC in 0 packets
                2016-03-31 00:30:30 | [mlat][i]Pinging the server
                2016-03-31 00:30:31 | [mlat][i]Stats 0/0
                2016-03-31 00:30:33 | [feed][i]sent 0, filtered 1 AC in 0 packets
                2016-03-31 00:30:49 | [mlat][i]Pinging the server


                You can see the point where the /etc/hosts file was updated and it suddenly works.

                (Overriding the server in this way is not a proper solution and risks supplying poor/slow data - so I only did this temporarily to test the theory.)

                Warm Regards
                Julie
                x
                Originally posted by geekycow View Post
                I added-

                52.20.254.84 mlat-1.fr24.com

                -to the bottom of /etc/hosts

                52.20.254.84 is the IP address of usa-2.fr24.com, which appears to be working; however, there's probably a reason why it's using a different server and therefore best not keep doing that for too long, just enough to test the theory. You should notice the change in status almost immediately, without even restarting.
                Yep worked for me instantly.

                2016-04-01 21:45:02 | [mlat][i]Registering MLAT station
                2016-04-01 21:45:02 | [mlat][i]Registering MLAT station: FAILURE
                2016-04-01 21:45:03 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
                2016-04-01 21:45:03 | [mlat][i]Registering MLAT station
                2016-04-01 21:45:03 | [mlat][i]Registering MLAT station: FAILURE
                2016-04-01 21:45:04 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
                2016-04-01 21:45:04 | [mlat][i]Registering MLAT station
                2016-04-01 21:45:04 | [mlat][i]Registering MLAT station: SUCCESS
                2016-04-01 21:45:06 | [feed][i]sent 6, filtered 6 AC in 1 packet
                2016-04-01 21:45:06 | [mlat][i]Pinging the server
                2016-04-01 21:45:07 | [mlat][i]Stats 0/0
                2016-04-01 21:45:11 | [feed][i]sent 4, filtered 5 AC in 1 packet
                2016-04-01 21:45:14 | [feed][i]removed 1 of 21 AC
                2016-04-01 21:45:16 | [feed][i]sent 4, filtered 6 AC in 1 packet
                2016-04-01 21:45:21 | [feed][i]sent 2, filtered 6 AC in 1 packet

                Good to know its a server side issue by the looks of it. Hopefully someone gets to look in to it sometime soon
                Last edited by spudd; 2016-04-01, 20:50.

                Comment


                • #53
                  Looks like there are 5 MLAT servers


                  telnet mlat-1.fr24.com 19788
                  Trying 83.140.21.66...
                  Connected to wro.fr24.com.

                  telnet mlat-2.fr24.com 19788
                  Trying 52.20.254.84...
                  Connected to usa-1.fr24.com.

                  telnet mlat-3.fr24.com 19788
                  Trying 54.79.112.149...
                  Connected to australia.fr24.com.

                  telnet mlat-4.fr24.com 19788
                  Trying 52.20.254.84...
                  Connected to usa-1.fr24.com.

                  telnet mlat-5.fr24.com 19788
                  Trying 83.140.21.66...
                  Connected to wro.fr24.com.

                  telnet mlat-6.fr24.com 19788
                  Trying 83.140.21.99...
                  telnet: Unable to connect to remote host: Connection refused

                  Comment


                  • #54
                    Originally posted by spudd View Post
                    regarding the MLAT issue


                    I am certainly running Jessie build. What where you running geekycow?

                    http://forum.flightradar24.com/threa...d?goto=newpost
                    I've created a fix, see the thread you posted about previously.

                    After doing that fix you can run-

                    sudo service fr24feed diagnostics

                    -and get the same information on Jessie.

                    Comment


                    • #55
                      MLAT status and fixes so far

                      To consolidate the multiple threads in to one:

                      A fix to Debian Jessie (latest Raspbian is based off of Jessie too) to fix the issue with systemd

                      Originally posted by geekycow View Post
                      I've just had a look and a play and it seems it's a bug with fr24feed on Jessie.

                      Raspbian Wheezy uses an older method to start and stop services and daemons, and that lets the fr24feed scripts run those diagnostics when "sudo service fr24feed status" is run. However, Raspbian Jessie uses a new system called "systemd" to do it, which is faster and more efficient but it's different enough that it can sometimes tickle bugs.

                      SystemD intercepts the "status" request and instead reports detailed information on the status of the service (the program/daemon only) all by itself, unfortunately this means the fr24feed software doesn't get a chance to add its extra information.

                      The solution is for fr24feed to *not* use "status" as a hook for getting detailed information about the fr24feed service and instead use another term (e.g. "diagnostics".) Alternatively, in order to preserve backwards compatibility with any software and information out there for running on Wheezy, it could trigger on either "diagnostics"/"status" on Wheezy and or only "diagnostics" on Jessie by changing just two lines.

                      Here's a patch that'll do it (also in the file attached)-


                      --- /etc/init.d/fr24feed 2016-03-04 15:17:12.000000000 +0000
                      +++ /etc/init.d/fr24feed.new 2016-04-01 22:03:27.593210225 +0100
                      @@ -157,7 +157,7 @@
                      stop)
                      stop
                      ;;
                      - status)
                      + status|diagnostics)
                      status
                      ;;
                      restart)
                      @@ -170,7 +170,7 @@
                      status_of_proc $DAEMON "fr24feed server"
                      ;;
                      *)
                      - echo "Usage: $0 {start|stop|restart|status}"
                      + echo "Usage: $0 {start|stop|restart|status|diagnostics}"
                      exit 2
                      ;;
                      esac


                      I'll report this to the people behind fr24feed, but to make such a change now, download the attached textfile to your pi and run the following command on it-

                      sudo patch < fr24feed-patch-jessie.txt


                      After doing this, issue-

                      sudo systemctl daemon-reload


                      Then to display the diagnostics on Jessie you can use-

                      sudo service fr24feed diagnostics

                      Hope that helps?

                      Warm Regards
                      Julie
                      x

                      PS Presumably because I'm a newbie here, a message told me this attachment will disappear if not downloaded/viewed within an hour of posting?
                      geekycow's fix is reattached to this post or available in the original post here (http://forum.flightradar24.com/attac...4&d=1459545311)

                      Once applied you should see the following output when running sudo service fr24feed diagnostic

                      sudo service fr24feed diagnostics
                      [ ok ] FR24 Feeder/Decoder Process: running.
                      [ ok ] FR24 Stats Timestamp: 2016-04-02 13:10:33.
                      [ ok ] FR24 Link: connected [UDP].
                      [ ok ] FR24 Radar: T-E*****.
                      [ ok ] FR24 Tracked AC: 27.
                      [ ok ] Receiver: connected (2578 MSGS/0 SYNC).
                      [FAIL] FR24 MLAT: not running ... failed!

                      Or if MLAT is working:

                      [ ok ] FR24 Feeder/Decoder Process: running.
                      [ ok ] FR24 Stats Timestamp: 2016-04-04 18:54:35.
                      [ ok ] FR24 Link: connected [UDP].
                      [ ok ] FR24 Radar: T-E****.
                      [ ok ] FR24 Tracked AC: 22.
                      [ ok ] Receiver: connected (2147165 MSGS/0 SYNC).
                      [ ok ] FR24 MLAT: ok [UDP].
                      [ ok ] FR24 MLAT AC seen: 19.

                      __________________________________________________ ____________

                      Test to check if MLAT works with a different MLAT server to mlat-1.fr24.com initial issue in this thread - SOLVED

                      This was an issue with the mlat-1.fr24.com server as confimred by support. They have fixed the server and the issue is resolved.

                      If you see this in your log file (cat /var/log/fr24feed.log) try the following to test a different MLAT server.

                      [mlat][i]Registering MLAT station
                      [mlat][i]Registering MLAT station: FAILURE
                      [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
                      [mlat][i]Registering MLAT station
                      [mlat][i]Registering MLAT station: FAILURE
                      [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788

                      Originally posted by geekycow View Post
                      I added-

                      52.20.254.84 mlat-1.fr24.com

                      -to the bottom of /etc/hosts

                      52.20.254.84 is the IP address of usa-2.fr24.com, which appears to be working; however, there's probably a reason why it's using a different server and therefore best not keep doing that for too long, just enough to test the theory. You should notice the change in status almost immediately, without even restarting.
                      After adding the above check your log and you should see the following:

                      [feed][i]filtering out 1 overlapping AC (saving bandwidth)
                      [feed][i]sent 0, filtered 1 AC in 0 packets
                      [mlat][i]Pinging the server
                      [mlat][i]Stats 0/0
                      [feed][i]sent 0, filtered 1 AC in 0 packets
                      [mlat][i]Pinging the server

                      Alternatively to checking the log you can stop the fr24feed service and run it standalone to get the same output. This is done by running


                      sudo service fr24feed stop
                      sudo fr24feed start


                      Alternatively if you are running on a systemd install and have applied the fix above you can use

                      sudo service fr24feed diagnostics

                      As geekycow stated, there is probably a reason you are on the mlat-1.fr24.com server and not any of the others so don't do this permanently. Test to see if it fixes the issue and post here with your results



                      __________________________________________________ ____________
                      I will try and keep this post updated with the latest
                      Attached Files
                      Last edited by spudd; 2016-04-04, 19:02.

                      Comment


                      • #56
                        Originally posted by spudd View Post
                        [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
                        [mlat][i]Registering MLAT station
                        [mlat][i]Registering MLAT station: FAILURE
                        Same here. Just set up my receiver (T-EDDN68) and got MLAT errors. After setting the IP in /etc/hosts as described, the error is gone. What is going on with mlat-1.fr24.com?

                        Thx

                        Comment


                        • #57
                          Originally posted by nodomain View Post
                          Same here. Just set up my receiver (T-EDDN68) and got MLAT errors. After setting the IP in /etc/hosts as described, the error is gone. What is going on with mlat-1.fr24.com?

                          Thx
                          We're not quite sure as of yet.
                          It would be worth while also emailing support about this issue. Hopefully the more people that do, the sooner we will get an official response

                          Comment


                          • #58
                            Weirdly, after testing the 52.20.254.84 mlat-1.fr24.com change in the /etc/hosts file and switching back to the normal MLAT server i still get the message that MLAT is running


                            [ ok ] FR24 Feeder/Decoder Process: running.
                            [ ok ] FR24 Stats Timestamp: 2016-04-04 12:22:25.
                            [ ok ] FR24 Link: connected [UDP].
                            [ ok ] FR24 Radar: T-EXXXX.
                            [ ok ] FR24 Tracked AC: 42.
                            [ ok ] Receiver: connected (21681 MSGS/0 SYNC).
                            [ ok ] FR24 MLAT: ok [UDP].
                            [ ok ] FR24 MLAT AC seen: 41.

                            I have also rebooted the Pi to make sure and it still seems ok.
                            Maybe coincidence or not but this is the 7th day my receiver has been on

                            What about for you?

                            Comment


                            • #59
                              Originally posted by spudd View Post
                              Weirdly, after testing the 52.20.254.84 mlat-1.fr24.com change in the /etc/hosts file and switching back to the normal MLAT server i still get the message that MLAT is running


                              [ ok ] FR24 Feeder/Decoder Process: running.
                              [ ok ] FR24 Stats Timestamp: 2016-04-04 12:22:25.
                              [ ok ] FR24 Link: connected [UDP].
                              [ ok ] FR24 Radar: T-EXXXX.
                              [ ok ] FR24 Tracked AC: 42.
                              [ ok ] Receiver: connected (21681 MSGS/0 SYNC).
                              [ ok ] FR24 MLAT: ok [UDP].
                              [ ok ] FR24 MLAT AC seen: 41.

                              I have also rebooted the Pi to make sure and it still seems ok.
                              Maybe coincidence or not but this is the 7th day my receiver has been on

                              What about for you?
                              Mine now suddenly working too. Also got a reply from support regarding the Jessie/Wheezy differences patch. I imagine that they've fixed it.

                              Julie
                              x

                              Comment


                              • #60
                                Can confirm it was a server side issue that has now been resolved.

                                So sorry for the late reply. Your email had ended up in the wrong inbox.

                                That issues was because of our servers and has been fixed. Can you check now and confirm for me.

                                EDIT: may require the fr24feed service to be restarted?

                                Comment

                                Working...
                                X