DD-WRT direct Feeding

[wiedehopf]

The real check for it working is the Stats line being displayed occasionally.
(With increasing numbers)

The other stuff just mean it's trying to work

[federbear]

After reading through lots of posts regarding MLAT, there shouldn't be any problems turning on MLAT.

It is turned on and it looks like as it is working properly.

[mlat][i]Received ADS-B time references AC:
[mlat][i] 440CB1
[mlat][i] 4780C0
[mlat][i] 478353
[mlat][i] 47840C
[mlat][i] 47840D
[mlat][i] 478534
[mlat][i] 478535
[mlat][i] 478536
[mlat][i] 47873E
[mlat][i] 47A6CE
[mlat][i] 4AC954
[mlat][i] 4CA6B6
[mlat][i] 4CA7A4
[mlat][i] 4CA867
[mlat][i] 4CAA58
[mlat][i] 4D2130
[mlat][i] 896343
[mlat][i] AA463E
[feed][i]sent 13, filtered 7 AC in 1 packet

[abcd567]

The FR24 MLAT is NOT fed back to receiver, so no problem of dump1090 version.

If FlightAware or Adsbexchange is fed, then the dump1090 receives mlat feedback. This feedback is kept isolated from locally received messages by dump1090-mut ver 1.15 and dump1090-fa. The dump1090-mut ver 1.14 and Malcolm Robb do not have provision to keep them isolated.

[wiedehopf]

After reading through lots of posts regarding MLAT, there shouldn't be any problems turning on MLAT.

[federbear]

Which dump1090 version is it?

(MLAT forwarding being off is the correct setting by the way, don't change that)

I suppose they not so much want to disable the Windows feeders but more generally feeds which rely on the non-raw data Basestation format.
Or it was just because your feeder version was so old and they want to disable the feed for that reason. And the reason given was Windows because well why give an accurate reason...
They could have just written which formats are acceptable and which are not or what the exact policies are.
But the information towards feeders is always lacking. No idea why they can't communicate with their feeders, it's puzzling.


You should be able to specify your position on the stats page and enable MLAT in the fr24feed.ini

It will not show you results on your local map though.
Only some MLAT networks like flightaware and ADSBexchange do that.

And for that to work without problems you need dump1090 mutability 1.15 which needs to be compiled from source.
You can also use a current version of dump1090-fa

If you have dump1090 mutability version 1.14 then MLAT data will be given to the feeders and it will produce bad data.

Anyway seems the reason for them stopping your feed was most likely just the very old feed software version

I think it is pretty sure, that they disabled the old feeder, and it caused this situation. I have two configs with different versions of dump, I am upgrading the older router right now, and both feeder got the same error. With the new key it worked immediately.

I agree that they did not do fair enough their communication. They have all accounts' email. It is pretty easy to send an email to us what the expected is about upgrading or old feeder software's outfasing.

Currently I do not turn on the MLAT, because I can not control my dump1090's version. It is downloaded from the openwrt repo and I can not compile special version.

This is the version that I use:

https://openwrt.org/packages/pkgdata/dump1090

[wiedehopf]

Which dump1090 version is it?

(MLAT forwarding being off is the correct setting by the way, don't change that)

I suppose they not so much want to disable the Windows feeders but more generally feeds which rely on the non-raw data Basestation format.
Or it was just because your feeder version was so old and they want to disable the feed for that reason. And the reason given was Windows because well why give an accurate reason...
They could have just written which formats are acceptable and which are not or what the exact policies are.
But the information towards feeders is always lacking. No idea why they can't communicate with their feeders, it's puzzling.


You should be able to specify your position on the stats page and enable MLAT in the fr24feed.ini

It will not show you results on your local map though.
Only some MLAT networks like flightaware and ADSBexchange do that.

And for that to work without problems you need dump1090 mutability 1.15 which needs to be compiled from source.
You can also use a current version of dump1090-fa

If you have dump1090 mutability version 1.14 then MLAT data will be given to the feeders and it will produce bad data.

Anyway seems the reason for them stopping your feed was most likely just the very old feed software version

[federbear]

Do you by chance use some MLAT network results like FA or ADSBexchange?

That old version of dump1090 can't handle MLAT results and will pass them on to fr24feed resulting in bad data.

Maybe the feed data was just blocked because he was feeding with SBS before and that can produce bad data as well i believe.
(Didn't you say you were feeding SBS format before?)

I do not see Mlat config in previous or current setup.

Currently it is not configured in the dump config:
option forward_mlat '0'
option lat ''
option lon ''
option max_range ''
option mlat '0'

I experienced that my old linux feeder wrote that windows is not supported longer. Funny.....
After that I could not connect to the FR24 feed server. I tried to configure my new setup and it wrote the errors that you saw. So I do not know the reason or the point in time when they could block my key, if they did it.

Regarding Mlat if it is possible I would like to take a part in it.

[wiedehopf]

Do you by chance use some MLAT network results like FA or ADSBexchange?

That old version of dump1090 can't handle MLAT results and will pass them on to fr24feed resulting in bad data.

Maybe the feed data was just blocked because he was feeding with SBS before and that can produce bad data as well i believe.
(Didn't you say you were feeding SBS format before?)

[Oblivian]

The old key either expired or being blocked.

Should really raise it with support to see if they did it for a reason

Sent from my EML-L09 using Tapatalk

[federbear]

With new key, but finally I am online! Thx to all!

[federbear]

Just run the signup again and don't put in a key.

They will assign you a new one.

Very annoying though that it said: Validated!

Many thanks!

[wiedehopf]

Just run the signup again and don't put in a key.

They will assign you a new one.

Very annoying though that it said: Validated!


The UDP traceroute looks just fine. The first few hops prove that UDP is not somehow filtered or something.
This IP 185.218.24.1 is actually the flightradar24 router IP for their feed servers
At least that's what i have deduced

[federbear]

I will do it today afternoon. I work today, and from here I can not test it, because I am behind proxy and firewall that I can not control. I open my router as well and with it you are able to use my router's data with your feeder setup. Lets hope that one of these test clarify where the problem is. Many thanks so far for all of you! I appreciate it!

traceroute -U -p 8099 -m 50 185.218.24.22
traceroute to 185.218.24.22 (185.218.24.22), 50 hops max, 60 byte packets
1 OpenWrt.lan (192.168.2.1) 13.130 ms 13.113 ms 13.108 ms
2 192.168.1.1 (192.168.1.1) 14.631 ms 13.083 ms 13.078 ms
3 100.127.254.245 (100.127.254.245) 18.524 ms 18.533 ms 18.528 ms
4 173.164.eidsiva.net (77.106.164.173) 18.533 ms 18.528 ms 18.523 ms
5 eb-e-gw-2.bkkb.no (193.28.236.30) 21.475 ms 21.485 ms 21.480 ms
6 ba-u-gw-2.bkkb.no (193.28.236.29) 21.476 ms 11.763 ms 11.739 ms
7 ba-u-gw.bkkb.no (193.28.236.234) 11.689 ms 11.716 ms 11.693 ms
8 ba-e-gw.bkkb.no (193.28.236.205) 11.328 ms 11.415 ms 13.030 ms
9 * * *
10 213.80.87.151 (213.80.87.151) 18.477 ms 18.434 ms 18.407 ms
11 185.218.24.1 (185.218.24.1) 18.404 ms 18.403 ms 18.496 ms
12 * * *
And after that there are only stars...

With your key:
2019-05-10 19:14:48 | [main][i]Feed Network client started
2019-05-10 19:14:48 | [feed][i]Downloading configuration
2019-05-10 19:14:48 | [feed][c]Interval: 5s
2019-05-10 19:14:48 | [feed][c]Latitude: 45.9293
2019-05-10 19:14:48 | [feed][c]Longitude: 24.3538
2019-05-10 19:14:48 | [feed][c]GND: YES
2019-05-10 19:14:48 | [feed][c]NonADSB: YES
2019-05-10 19:14:48 | [feed][c]Timestamps: optional
2019-05-10 19:14:48 | [feed][c]Max range AIR: 350.0nm
2019-05-10 19:14:48 | [feed][c]Max range GND: 100.0nm
2019-05-10 19:14:48 | [feed][i]defined 4 servers
2019-05-10 19:14:48 | [stats][i]Stats thread started
2019-05-10 19:14:48 | [feed][n]EDQG86@185.218.24.23:8099/UDP
2019-05-10 19:14:48 | [feed][n]connecting
2019-05-10 19:14:48 | [feed][n]connected via UDP (fd 8)
2019-05-10 19:14:48 | [feed][n]working

This is what I almost said: #%"%¤#/%(%#&"# ......

So it is not the dump, it is not my config, but my key.....

[federbear]

Let's check the output of this command, it uses UDP packets on the same destination port as fr24feed


traceroute -U -p 8099 185.218.24.22

(It will only go a couple of hops but it should do that)
If it shows something like this as one of the hops it's working:
6 FLIGHTRADAR.bar1.Stockholm1.Level3.net (213.242.110.94) 48.439 ms 42.349 ms 42.869 ms


You can also try my second feed key i only use it for testing anyway:

receiver="beast-tcp"
fr24key="dc398c0be744b547"
host="federbear.noip.me:30005"
bs="no"
raw="no"
logmode="0"
logpath="/tmp"
mlat="no"
mlat-without-gps="no"
use-http=yes
http-timeout=20

This config worked for me just 5 minutes ago.

I will do it today afternoon. I work today, and from here I can not test it, because I am behind proxy and firewall that I can not control. I open my router as well and with it you are able to use my router's data with your feeder setup. Lets hope that one of these test clarify where the problem is. Many thanks so far for all of you! I appreciate it!

[wiedehopf]

Let's check the output of this command, it uses UDP packets on the same destination port as fr24feed


traceroute -U -p 8099 185.218.24.22

(It will only go a couple of hops but it should do that)
If it shows something like this as one of the hops it's working:
6 FLIGHTRADAR.bar1.Stockholm1.Level3.net (213.242.110.94) 48.439 ms 42.349 ms 42.869 ms




This config worked for me just 5 minutes ago.