Announcement

Collapse
No announcement yet.

MLAT enabled but not running

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

  • #31
    Originally posted by spudd View Post
    Out of curiosity, what firewall are you running?

    If i look through localhost:8754/monitor.txt the MLAT error there is still stating mlat_problem="udp-firewall" so this maybe an independent issue from the coordinates problem
    Just a TalkTalk SuperRouter HG635 - no other software firewall between the Pi and the router though. I've tried it with the Router's Firewall disabled, with the Pi in the DMZ and with port forwarding; it doesn't make an iota of a difference.

    I suspect that udp-firewall error message is just a generic not-receiving-a-response-to-the-udp-packets error message? (You probably already know but unlike TCP, UDP is not stateful, there's no concept of a truly managed connection - so perhaps the software can't do anything but notice that it doesn't get a response and then just assume that it's a firewall problem, because there's no way to know further.)

    Comment


    • #32
      What the... lol. Thats taking the incorrectly named DVBT (in console) to another level. Have to verify mine when I get home now
      Posts not to be taken as official support representation - Just a helpful uploader who tinkers

      Comment


      • #33
        Originally posted by spudd View Post
        I remember reading in a thread that even a tiny time offset on the pi can cause the plane to be out by miles, surely a receiver being 350m off would also have this affect? I maybe wrong and it's late for working out the maths.

        I see in the monitor.txt file it states mlat-mode="UDP". Is there a TCP mode?
        Yeah, the 300m+ discrepancy thing seems unlikely under the circumstances - but it could be just that the receiving MLAT server is doing a sanity check on the reported location vs the location configured for one's radar site and spotting such a discrepancy and giving up. More likely is that it's just a rounding it before printing it out in the logs.

        Either way, we've both sent detailed reports at about the same time, after having the same problems, so perhaps it'll get them diagnosing.

        Comment


        • #34
          Originally posted by spudd View Post
          I've just checked the log and its full of

          2016-03-30 17:54:56 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
          2016-03-30 17:54:56 | [mlat][i]Registering MLAT station
          2016-03-30 17:54:56 | [mlat][i]Registering MLAT station: FAILURE


          I see when this was in beta lots of people had this issue but it was fixed with an update. I'm currently on the latest version as far as i know. Fresh install last week

          EDIT: I have not installed any driver for the RTL2838 DVB-T stick. I see back in past forum posts people have. Is this still needed or is it built in to the latest version of raspbian?
          Hmmmmm.... I've just noticed, we're having the same problem with EXACTLY the same server - udp://mlat-1.fr24.com:19788

          Comment


          • #35
            Originally posted by geekycow View Post
            Hmmmmm.... I've just noticed, we're having the same problem with EXACTLY the same server - udp://mlat-1.fr24.com:19788
            Install telnet, and go
            telnet mlat-1.fr24.com 19788

            If you get a blank screen and flashing cursor - its open.

            Just did from my region and alls good
            Posts not to be taken as official support representation - Just a helpful uploader who tinkers

            Comment


            • #36
              Originally posted by geekycow View Post
              Just a TalkTalk SuperRouter HG635 - no other software firewall between the Pi and the router though. I've tried it with the Router's Firewall disabled, with the Pi in the DMZ and with port forwarding; it doesn't make an iota of a difference.

              I suspect that udp-firewall error message is just a generic not-receiving-a-response-to-the-udp-packets error message? (You probably already know but unlike TCP, UDP is not stateful, there's no concept of a truly managed connection - so perhaps the software can't do anything but notice that it doesn't get a response and then just assume that it's a firewall problem, because there's no way to know further.)
              That rules that out then. I came across some forum posts that mentioned pfsense changing the UDP source port causing issues with some UDP streams and applications. I gave the fix ago but no luck (link for reference https://doc.pfsense.org/index.php/Static_Port)

              Comment


              • #37
                Originally posted by Oblivian View Post
                Install telnet, and go
                telnet mlat-1.fr24.com 19788

                If you get a blank screen and flashing cursor - its open.

                Just did from my region and alls good
                Good shout.

                Tested using the putty client and following settings but get an error

                puttysettings.jpg

                Get the network error caused abort error. Any luck for you geekycow?

                EDIT: works from the Pi though
                Last edited by spudd; 2016-03-30, 23:30.

                Comment


                • #38
                  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

                  Comment


                  • #39
                    With any luck Olov will check in a few hrs and be able to escalate. It wont be just you it effects (however odd that the port appears open just not doing what it should)
                    Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                    Comment


                    • #40
                      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
                      Now that is interesting! nice find

                      Comment


                      • #41
                        Originally posted by Oblivian View Post
                        Install telnet, and go
                        telnet mlat-1.fr24.com 19788

                        If you get a blank screen and flashing cursor - its open.

                        Just did from my region and alls good
                        Works fine here too, although of course telnet is TCP not UDP. Curious, why would that TCP port be open if MLAT works via UDP? If TCP works then UDP jolly well ought to, and it REALLY doesn't look like a local network problem.

                        Oblivian.... if you're also on a Pi and it works for you, could you just temporary try editing your /etc/hosts and see if you can force whatever MLAT UDP server you're using to instead use the IP for mlat-1.fr24.com ? e.g. If your logs say you're using usa-2.fr24.com then add "usa-2.fr24.com 83.140.21.66" to the bottom of /etc/hosts (please accept my apologies if I'm teaching granny to suck eggs!)

                        I *bet* it'll break as soon as you do that.

                        If so, we've got it!

                        Comment


                        • #42
                          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
                          Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                          Comment


                          • #43
                            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
                            Hehehehe. Yes, I honestly never thought to check the TCP ports, I just assumed they'd be locked down. Great call!

                            PS Thanks for all your help.
                            Last edited by geekycow; 2016-03-30, 23:57. Reason: ....errrr, the little blue men from alpha centauri made me do it?

                            Comment


                            • #44
                              Originally posted by Oblivian View Post
                              Thats it being dropped.. slightly diff issue (and don't beleive the 0/0 stats) that some of us are also seeing. At least yours reregisters.

                              And do you actually have a beast, seems strange to be running of 30005 which is the beast format output of dump1090 - AVRtcp to 30002 is confirmed, but not sure itll work from 30005 as modified data format.
                              Heard back from support. They say to ignore -- it's a server related issue that's being worked on.

                              Comment


                              • #45
                                Originally posted by KK6LDW View Post
                                Heard back from support. They say to ignore -- it's a server related issue that's being worked on.
                                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

                                Comment

                                Working...
                                X