DD-WRT direct Feeding

[federbear]

I seems you don't have a log file configured but logmode is still 1.

Maybe just try this config (adapting the key and IP)
This config also uses use-http which can sometimes fix connection errors.

receiver="beast-tcp"
fr24key="xxxxxxxxxxxxxxxx"
host="127.0.0.1:30005"
bs="no"
raw="no"
logmode="0"
logpath="/var/log/fr24feed"
mlat="no"
mlat-without-gps="no"
use-http=yes
http-timeout=20

2019-05-09 23:59:13 | [main][i]FR24 Feeder/Decoder
2019-05-09 23:59:13 | [main][i]Version: 1.0.18-5/generic
2019-05-09 23:59:13 | [main][i]Built on Mar 4 2016 16:26:55 (devel-d11ca48.git/Linux/x86_64)
2019-05-09 23:59:13 | [main][i]Copyright 2012-2016 Flightradar24 AB
2019-05-09 23:59:13 | [main][i]http://flightradar24.com
2019-05-09 23:59:13 | [main][i]DNS mode: LIBC
2019-05-09 23:59:13 | [main][i]Automatic updates are DISABLED
2019-05-09 23:59:13 | [httpd][i]Server started, listening on 0.0.0.0:8754
2019-05-09 23:59:13 | [main][i]Reader thread started
2019-05-09 23:59:13 | [time][i]Synchronizing time via NTP
2019-05-09 23:59:13 | [master][i]Starting processing thread
2019-05-09 23:59:13 | [reader][i]Initializing reader
2019-05-09 23:59:13 | [reader][i]Connecting to Beast receiver via (tcp://federbear.noip.me:30005)
2019-05-09 23:59:14 | [reader][i]Connected to the receiver, configuring
2019-05-09 23:59:14 | [reader][i]Configured, processing messages
2019-05-09 23:59:16 | [time][i]Time synchronized correctly, offset +0.0003 seconds
2019-05-09 23:59:16 | [main][i]Feed Network client started
2019-05-09 23:59:16 | [feed][i]Downloading configuration
2019-05-09 23:59:16 | [feed][i]Failed on start, Sleeping 120 seconds
2019-05-09 23:59:17 | [reader][w]Setting new UTC offset: 0!

Just a question. Where it should save information that I wrote during the --signup process?...If it saves something at all. I do not think of the ini file now. It asked me about my email.

[wiedehopf]

I seems you don't have a log file configured but logmode is still 1.

Maybe just try this config (adapting the key and IP)
This config also uses use-http which can sometimes fix connection errors.

receiver="beast-tcp"
fr24key="xxxxxxxxxxxxxxxx"
host="127.0.0.1:30005"
bs="no"
raw="no"
logmode="0"
logpath="/var/log/fr24feed"
mlat="no"
mlat-without-gps="no"
use-http=yes
http-timeout=20

[federbear]

Yeah as i wrote above, maybe dump1090 is not even starting for some reason, like the config file being meant for a much earlier version?

Dump is running. I see the map. It shows the planes and if I start in the console, and it is not running as service, I see it writes a lot of messages about planes. I think It is a problem somewhere in the fr24feed that can not connect to the fr24 server. Perhaps it can not log in or something else. since it writes [reader][i]Configured, processing messages

[wiedehopf]

Edit:

Nevermind the connection to dump1090 is working fine, it just doesn't want to connect to fr24.

Maybe they killed off all the old versions.

Can you recheck your feed key here:

https://www.flightradar24.com/account/data-sharing

[federbear]

Did you update dump1090 as well?
Maybe it doesn't like the old configuration file.

As far as i see, it should work using port 30005 and beast-tcp

Your fr24feed.ini should look like this:

receiver="beast-tcp"
fr24key="xxxxxxxxxxxxxxxx"
host="127.0.0.1:30005"

If you are really on a remote IP you should change the 127.0.0.1 of course.
Don't forget to restart fr24feed after making changes.

Check if those settings work and if they don't continue with deleting the dump1090 configuration.
Then you can use
sudo dpkg-reconfigure dump1090
to create a new config file. (you can probably leave pretty much everything default)

I am not on the same machine where the dump runs, and it still fails.
Here is the current log:
2019-05-09 23:47:45 | [main][i]FR24 Feeder/Decoder
2019-05-09 23:47:45 | [main][i]Version: 1.0.18-5/generic
2019-05-09 23:47:45 | [main][i]Built on Mar 4 2016 16:26:55 (devel-d11ca48.git/Linux/x86_64)
2019-05-09 23:47:45 | [main][i]Copyright 2012-2016 Flightradar24 AB
2019-05-09 23:47:45 | [main][i]http://flightradar24.com
2019-05-09 23:47:45 | [main][i]DNS mode: LIBC
2019-05-09 23:47:45 | [main][i]Automatic updates are DISABLED
2019-05-09 23:47:45 | [httpd][i]Server started, listening on 0.0.0.0:8754
2019-05-09 23:47:45 | [main][i]Reader thread started
2019-05-09 23:47:45 | [time][i]Synchronizing time via NTP
2019-05-09 23:47:45 | [master][i]Starting processing thread
2019-05-09 23:47:45 | [reader][i]Initializing reader
2019-05-09 23:47:45 | [reader][i]Connecting to Beast receiver via (tcp://<router ip>:30005)
2019-05-09 23:47:45 | [reader][i]Connected to the receiver, configuring
2019-05-09 23:47:45 | [reader][i]Configured, processing messages
2019-05-09 23:47:46 | [reader][w]Setting new UTC offset: 0!
2019-05-09 23:47:47 | [time][i]Time synchronized correctly, offset +0.0001 seconds
2019-05-09 23:47:47 | [main][i]Feed Network client started
2019-05-09 23:47:47 | [feed][i]Downloading configuration
2019-05-09 23:47:47 | [feed][i]Failed on start, Sleeping 120 seconds

more /etc/fr24feed.ini
receiver="beast-tcp"
fr24key="<key>"
host="federbear.noip.me:30005"
bs="no"
raw="no"
logmode="1"
mlat="no"
mlat-without-gps="no"

[wiedehopf]

Did you update dump1090 as well?
Maybe it doesn't like the old configuration file.

As far as i see, it should work using port 30005 and beast-tcp

Your fr24feed.ini should look like this:

receiver="beast-tcp"
fr24key="xxxxxxxxxxxxxxxx"
host="127.0.0.1:30005"

If you are really on a remote IP you should change the 127.0.0.1 of course.
Don't forget to restart fr24feed after making changes.

Check if those settings work and if they don't continue with deleting the dump1090 configuration.
Then you can use
sudo dpkg-reconfigure dump1090
to create a new config file. (you can probably leave pretty much everything default)

[Oblivian]

He wrote something aboute remote-ip.

So i'm assuming dump1090 is running remotely and fr24feed is on another linux machine.
Before the change he was using the sbs protocol, but that doesn't seem to work anymore.

"2019-05-09 18:26:23 | [main][i]Version: 1.0.18-5/generic"

So thats the latest generic Debian version. So goodness knows how its reporting windows feeder not valid error 0.o Unless they have decided to kill that version too thanks to our recent discoveries.

I don't see any remote change that would effect this version and the way it was going. Especially Dump1090 if remote as fr servers can't touch it.

[federbear]

Did you read my whole post?
I asked for the output of the following command on the router:

dump1090 --help

Sorry, It took time to find this thread.

root@OpenWrt:~# dump1090 --help
-----------------------------------------------------------------------------
| dump1090 ModeS Receiver dump1090-mutability |
-----------------------------------------------------------------------------
--device-index <index> Select RTL device (default: 0)
--gain <db> Set gain (default: max gain. Use -10 for auto-gain)
--enable-agc Enable the Automatic Gain Control (default: off)
--freq <hz> Set frequency (default: 1090 Mhz)
--ifile <filename> Read data from file (use '-' for stdin)
--iformat <format> Sample format for --ifile: UC8 (default), SC16, or SC16Q11
--throttle When reading from a file, play back in realtime, not at max speed
--interactive Interactive mode refreshing data on screen. Implies --throttle
--interactive-rows <num> Max number of rows in interactive mode (default: 22)
--interactive-ttl <sec> Remove from list if idle for <sec> (default: 60)
--interactive-rtl1090 Display flight table in RTL1090 format
--raw Show only messages hex values
--net Enable networking
--modeac Enable decoding of SSR Modes 3/A & 3/C
--net-only Enable just networking, no RTL device or file used
--net-bind-address <ip> IP address to bind to (default: Any; Use 127.0.0.1 for private)
--net-ri-port <ports> TCP raw input listen ports (default: 30001)
--net-ro-port <ports> TCP raw output listen ports (default: 30002)
--net-sbs-port <ports> TCP BaseStation output listen ports (default: 30003)
--net-bi-port <ports> TCP Beast input listen ports (default: 30004,30104)
--net-bo-port <ports> TCP Beast output listen ports (default: 30005)
--net-ro-size <size> TCP output minimum size (default: 0)
--net-ro-interval <rate> TCP output memory flush rate in seconds (default: 0)
--net-heartbeat <rate> TCP heartbeat rate in seconds (default: 60 sec; 0 to disable)
--net-buffer <n> TCP buffer size 64Kb * (2^n) (default: n=0, 64Kb)
--net-verbatim Do not apply CRC corrections to messages we forward; send unchanged
--forward-mlat Allow forwarding of received mlat results to output ports
--lat <latitude> Reference/receiver latitude for surface posn (opt)
--lon <longitude> Reference/receiver longitude for surface posn (opt)
--max-range <distance> Absolute maximum range for position decoding (in nm, default: 300)
--fix Enable single-bits error correction using CRC
--no-fix Disable single-bits error correction using CRC
--no-crc-check Disable messages with broken CRC (discouraged)
--mlat display raw messages in Beast ascii mode
--stats Print stats at exit
--stats-range Collect/show range histogram
--stats-every <seconds> Show and reset stats every <seconds> seconds
--onlyaddr Show only ICAO addresses (testing purposes)
--metric Use metric units (meters, km/h, ...)
--gnss Show altitudes as HAE/GNSS (with H suffix) when available
--snip <level> Strip IQ file removing samples < level
--debug <flags> Debug mode (verbose), see README for details
--quiet Disable output to stdout. Use for daemon applications
--show-only <addr> Show only messages from the given ICAO on stdout
--ppm <error> Set receiver error in parts per million (default 0)
--html-dir <dir> Use <dir> as base directory for the internal HTTP server. Defaults to ./public_html
--write-json <dir> Periodically write json output to <dir> (for serving by a separate webserver)
--write-json-every <t> Write json output every t seconds (default 1)
--json-location-accuracy <n> Accuracy of receiver location in json metadata: 0=no location, 1=approximate, 2=exact
--dcfilter Apply a 1Hz DC filter to input data (requires lots more CPU)
--help Show this help

Debug mode flags: d = Log frames decoded with errors
D = Log frames decoded with zero errors
c = Log frames with bad CRC
C = Log frames with good CRC
p = Log frames with bad preamble
n = Log network debugging info
j = Log frames to frames.js, loadable by debug.html

[wiedehopf]

He wrote something aboute remote-ip.

So i'm assuming dump1090 is running remotely and fr24feed is on another linux machine.
Before the change he was using the sbs protocol, but that doesn't seem to work anymore.

[Oblivian]

If the only issue, is the core app. Update using the standard methods. Assuming a router is even capable of doing so

GPG and other errors - Update fr24feed
sudo apt-get update - refresh available app update list
sudo apt-get install fr24feed - manually check for update
- Will search for a new version and advise if 0 bytes were to be installed (no change) or if a new update was to be.

[wiedehopf]

Trying to upgrade a hacked router with dump 1090

Funny looking request for help moving from depreciated windows setups the thread is for....

Sent from my EML-L09 using Tapatalk

It seems people don't like opening their own threads.

Should i rather ask them to open their own thread?
Might stop some people from asking questions because they don't find the button though...

[wiedehopf]

Ok, I turned off, but on the client side it does not affect anything. The feeder still writes it:
2019-05-09 22:14:22 | [main][i]Feed Network client started
2019-05-09 22:14:22 | [feed][i]Downloading configuration
2019-05-09 22:14:22 | [feed][i]Failed on start, Sleeping 120 seconds

Did you read my whole post?
I asked for the output of the following command on the router:

dump1090 --help

[federbear]

Trying to upgrade a hacked router with dump 1090

Funny looking request for help moving from depreciated windows setups the thread is for....

Sent from my EML-L09 using Tapatalk

Because I got the same message on my linux that windows is not supported longer. It is really funny. So not the router is the problem but the old linux feeder app.

[failure]: Windows feeding software is now disabled!
But my linux never seen windows.....

[federbear]

Turn off the raw option that will produce messages on the local command line, not on a network port.
So the raw option could lead to it not running properly because the messages on the command line "have nowhere to go"

If you could provide the help output, that would explain the options:

dump1090 --help

Ok, I turned off, but on the client side it does not affect anything. The feeder still writes it:
2019-05-09 22:14:22 | [main][i]Feed Network client started
2019-05-09 22:14:22 | [feed][i]Downloading configuration
2019-05-09 22:14:22 | [feed][i]Failed on start, Sleeping 120 seconds

[Oblivian]

Trying to upgrade a hacked router with dump 1090

Funny looking request for help moving from depreciated windows setups the thread is for....

Sent from my EML-L09 using Tapatalk