Failed TCP connection to all provided addresses

[Christopher Robert]

Hi

I Installed and configurated my feeder following
https://forum.planefinder.net/threa...-raspbian-dump1090-data-feeder.241/#post-2451

But the feeder isnt working and in the logs I get all 5 seconds an error like
2019-01-28 16:40:01.466343 [-] Failed TCP connection to all provided addresses for: 127.0.0.1:30005
2019-01-28 16:40:01.466200 [V] Failed to resolve remote socket address 127.0.0.1 30005 : Servname not supported for ai_socktype (errno: -8)

Could that be a conflict with my pihole <https://pi-hole.net/>?
Other feeders are working well with the same hardware.

Best regards from Switzerland
Christopher

 

[Lee Armstrong]

Hello Christopher,

It sounds like whatever you are connecting to on port 30005 is not listening? Do you already have Dump1090 installed and listening on that port at all?

Lee

 

[Christopher Robert]

Hello

First I checked if there were different versions of dump1090 installed:

apt-cache policy dump1090-fa
apt-cache policy mr-dump1090
apt-cache policy dump1090
apt-cache policy dump1090-mutability

Only dump1090-mutability was installed.
So I made a clean uninstall:

sudo systemctl disable dump1090-mutability
sudo systemctl stop dump1090-mutability
sudo apt-get remove dump1090-mutability
sudo apt-get --purge remove dump1090-mutability

And re-istalled dump1090-mutability:

sudo dpkg -i dump1090-mutability_1.14_armhf.deb
sudo dpkg-reconfigure dump1090-mutability

But at the end there were the same errors.
Once again, clean uninstall of dump1090-mutability.
And I tried to install only dump1090:

cd ~
git clone git://github.com/MalcolmRobb/dump1090.git
cd dump1090
make
./dump1090 --interactive --net --net-http-port 8080

Here I saw that the usb-dongle is working and the dump1090 is feeding data.

I reconfigured the planefinder client with the sharecode - and had once again the boring errors.
I tried also other configurations (AVR-TCP, Kinetic, Radarscape) all made the same error like Beast.
I also checked if there was a space character before or after 127.0.0.1 and 30005 - none.

So the dump1090 and the hardware are working well, the problem must be the planefinder client.
So I made a clean unuistall of the pflient:

sudo systemctl disable pfclient
sudo systemctl stop pfclient
sudo apt-get remove pfclient
sudo apt-get --purge remove pfclient

And re-installed pfclient:
sudo dpkg -i pfclient_4.1.1_armhf.deb

After the configuration in the web-interface I had - a new error. ;-(
2019-01-29 10:25:30.330279 [-] Failed TCP connection to all provided addresses for: 127.0.0.1:30005
2019-01-29 10:25:30.330018 [V] Failed to open connection to socket: Connection refused (errno: 111)


Best regards
Christopher

 

[Christopher Robert]

Update:
After a restart of the raspi (sudo reboot) the pflient connects:

2019-01-29 11:18:17.102548 [-] TCP connection established: 127.0.0.1:30005
2019-01-29 11:18:17.101760 [-] Client restarted successfully
2019-01-29 11:18:17.101659 [-] Closed TCP connection: 127.0.0.1:30005
2019-01-29 11:18:17.101205 [V] Low-traffic detected, restarting client (this is standard behaviour and is safe to ignore)

The clean uninstall and new installation and configuration of the pfclient solved the problem, but the raspberry must be restarted to make it work correcly.

Is the dump1090-mutability better then the dump1090?
Could this solve the problem with the low traffic?
Should I change it?
Now I know how to proceed a clean uninstall. ;-)

Best regards
Christopher

 

[Christopher Robert]

Finally it works!

apt-cache policy dump1090
didnt show me the installation but it was installed (by make and not by apt, so it will not be shown by apt).
I could not unistall dump1090 correcly, and had problems with the concurrent installation of dump1090 and dump1090-mutability .
So I tried a workaround and updatet dump1090 to dump1090-fa.
But dump1090-fa gets conflicts with my pi-hole (both want to display messages on the same web-interface).
The installed dump1090-fa I could clean uninstall (like shown in Post #3).
And the I could Install and configure dump1090-mutability .

I works now, finally...

Best regards
Christopher

 

[Christopher Robert]

After finally having resolved the signature-problems with radarbox24 and updated the rbclient, I had some new errors with the pflient:
2019-02-01 14:18:54.647061 [-] Failed TCP connection to all provided addresses for: 127.0.0.1:30005
2019-02-01 14:18:54.646854 [V] Failed to open connection to socket: Connection refused (errno: 111).

It remembered me to the film "dinner for one": "Same procedure as ...".
Like in post #3 I unistalled and re-installed the dump1090-mutability and the pfclent, and it worked again.
Probably the re-installation of the pfclient should be enough, but I wanted to be shure.


Best regards
Christopher

 

[wiedehopf]

That sounds eerily like the fr24feed client wreaking havoc.

Use this as /etc/fr24feed.ini and insert your fr24 key and you should be good (i presume there is dvbt as receiver in the current one, because that means it will install dump1090 and not output on 30005)

receiver="beast-tcp"
fr24key="xxxxxxxxxx"
host="127.0.0.1:30005"
bs="no"
raw="no"
logmode="1"
logpath="/var/feed"
mlat="yes"
mlat-without-gps="yes"
use-http=yes
http-timeout=20

 

[Christopher Robert]

That sounds eerily like the fr24feed client wreaking havoc.

Use this as /etc/fr24feed.ini and insert your fr24 key and you should be good (i presume there is dvbt as receiver in the current one, because that means it will install dump1090 and not output on 30005)

receiver="beast-tcp"
...

Thanks, that looks good.
In my fr24feed.ini the receiver was "avr-tcp".
This seems to conflict witth the planefinder configuration as beast.

 

[wiedehopf]

In my fr24feed.ini the receiver was "avr-tcp".

avr-tcp is actually not a problem and should have worked. not sure what is going on with your pi just installing dump1090.

 

[Christopher Robert]

avr-tcp is actually not a problem and should have worked. not sure what is going on with your pi just installing dump1090.

For the moment everything is working good.
Only one thing looks a bit strange: Every day at 22:00 all ads-b-feeds begin to feed only empty data; after a reboot its okay.
I havent found why, but I havent searched deeply.
My workaround is a cronjob that reboots daily the raspi at 22:01. ;-)
That works fine, I will search later.

 

[wiedehopf]

Only one thing looks a bit strange: Every day at 22:00 all ads-b-feeds begin to feed only empty data; after a reboot its okay.

What image did you base that installation on?
Seems like it went horridly wrong at some point.

Oh nevermind it's that pihole thing. Maybe you've set some child internet filter that deactivates at 22:00 an screws everything up

Even if fr24 is blameless, it still looks like some other feeder might be installing dump1090.
Is is may be installed with some feeder as a dependency when you reinstall it trying to make it work?

Maybe just use a fresh sd-card image of pihole and start with that and only install the known good feeders first or only one feeder a week so you each time know you have a stable system and can maybe see what screws it up.
(pfclient and flightaware make top notch feeder programs that don't screw anything up. fr24 you just have to configure correctly. never had any problems with opensky personally. Don't think i fed any other service)

As you see i'm getting desperate because your problem sounds really strange.
One more thing:

If you do:
sudo apt-get update
sudo apt-get upgrade

Does it try to install dump1090? If yes it should say what requires it.

 

[Christopher Robert]

What image did you base that installation on?
Seems like it went horridly wrong at some point.

Raspbian Stretch Lite with XFCE-Desktop.

Oh nevermind it's that pihole thing. Maybe you've set some child internet filter that deactivates at 22:00 an screws everything up

I'm single, and single user.
The rest of the internet-connections are still working, only the ADS-B-feeders (based on dump1090) are sending feeds without data.
For example radarscape marks in the statistics the status online, transmitted data zero.
The planefinder client is for that very helpful, because it shows on the map no more planes, but in the log view a data transmission.
So it looks like the feeder is okay, but his source (dump1090) is down.

Today, with the cronjob reboot, I had only a short interrupt of the transmission.

Even if fr24 is blameless, it still looks like some other feeder might be installing dump1090.
Is is may be installed with some feeder as a dependency when you reinstall it trying to make it work?

Yes, it looks like that. My problem with the fr24 is his configuration. The auto-configuration configures a avr-tcp on 30002, and the manual configuration is a bit complicated, I dont know what they mean with some expressions. My dongle is the https://shop.jetvision.de/epages/64807909.sf/en_GB/?ObjectPath=/Shops/64807909/Products/67126 . But the setting you have posted in #7 are helpfull.

Maybe just use a fresh sd-card image of pihole and start with that and only install the known good feeders first or only one feeder a week so you each time know you have a stable system and can maybe see what screws it up.

Thats what I will do. I have read in the Internet that data sharing is quite easy, bought a dongle with antenna, began to install - and remarked a BIG difference between theorie and practice. That's okay, that's learning by doing.

(pfclient and flightaware make top notch feeder programs that don't screw anything up. fr24 you just have to configure correctly. never had any problems with opensky personally. Don't think i fed any other service)

I feed https://adsbexchange.com, http://www.adsbhub.org, https://flightaware.com, https://www.flightradar24.com, https://planefinder.net, https://opensky-network.org, https://www.radarbox24.com and I am surprised how little problems I have.

As you see i'm getting desperate because your problem sounds really strange.

I am engaged since 1986 with computers, so these problems dont worry me at all. But I am appreciative for your help.

One more thing:
If you do:
sudo apt-get update
sudo apt-get upgrade
Does it try to install dump1090? If yes it should say what requires it.

I t checks
OK:1 http://raspbian.raspberrypi.org/raspbian stretch InRelease
OK:2 http://apt.mopidy.com stretch Release
OK:3 http://repo.feed.flightradar24.com flightradar24 InRelease
OK:4 http://flightaware.com/adsb/piaware/files/packages stretch InRelease
OK:5 https://opensky-network.org/repos/debian opensky InRelease
OK:6 http://archive.raspberrypi.org/debian stretch InRelease
OK:7 https://apt.rb24.com rpi-stable InRelease

With the last one, we had till yesterday problems with the signature, now they are solved.

So it looks like only the Raspbian dump1090 is updated, and the the other feeders.

 

[wiedehopf]

I am engaged since 1986 with computers, so these problems dont worry me at all. But I am appreciative for your help.

Well i was very little back then

Yes, it looks like that. My problem with the fr24 is his configuration. The auto-configuration configures a avr-tcp on 30002, and the manual configuration is a bit complicated, I dont know what they mean with some expressions.

The feeder configurations are unrelated to the dongle.

Only dump1090-mutability should interact with the dongle. (If you set dvbt as receiver in fr24 it starts its internal dump1090 which is not good)

I am surprised how little problems I have.

I really don't know about all those feeders, but yeah i suspect at 22:00 one of them somehow installs its own dump1090 or something.

So it looks like only the Raspbian dump1090 is updated, and the the other feeders.

So maybe just disable and stop or uninstall the adsbhub and radarbox feeders and check if the problems stop?

How do you start your dump1090 right now? dump1090-mutability via the supplied service?

Maybe disable the cronjob for reboot and check at 22:05
sudo journalctl -e
There could be something that tells you what happened there.

 

[Christopher Robert]

The feeder configurations are unrelated to the dongle.

Yes, but the decoder (dump1090) must correspond to the dongle.
And when the feeder expects data on port 30005 (like planefinder) and the decoder delivers them on 30002, the feeder cant feed usable data.
Something like that will be the cause when my feeders feed after 22:00 empty feeds.

Only dump1090-mutability should interact with the dongle. (If you set dvbt as receiver in fr24 it starts its internal dump1090 which is not good)

I thougt that piware could be the problem, because piaware is based on the fa-dump1090. But it works properly, started at 22:01 after the reboot.
The other feeders i will check tomorrow, now its sleeping-time for me.

I really don't know about all those feeders, but yeah i suspect at 22:00 one of them somehow installs its own dump1090 or something.

Perhaps one of the feeder has a routine that resets the port-settings from the dump1090 afer a update?
Tomorrow I will check the pi-hole logs (DNS-requests) from 22:00.

So maybe just disable and stop or uninstall the adsbhub and radarbox feeders and check if the problems stop?

I will have a look.
Its like with some old V8-engines, when you remove one ignition cable after another to look which cylinder doesn't work properly. ;-)

How do you start your dump1090 right now? dump1090-mutability via the supplied service?

sudo systemctl restart dump1090-mutability

Maybe disable the cronjob for reboot and check at 22:05
sudo journalctl -e
There could be something that tells you what happened there.

That's a very good idea, thank you.

 

[wiedehopf]

And when the feeder expects data on port 30005 (like planefinder) and the decoder delivers them on 30002, the feeder cant feed usable data.

Just to make sure post the output of this command:
cat /etc/fr24feed.ini
(you can redact the key)

Also i just checked on the radarbox feeder, also show it's config:
cat /etc/rbfeeder.ini

You want these setting:

[client]
network_mode=true

[network]
mode=raw
external_host=127.0.0.1
external_port=30005

(if network_mode is set to false it will screw everything up just like fr24 with dvbt set.)

 

[Christopher Robert]

Just to make sure post the output of this command:
cat /etc/fr24feed.ini
(you can redact the key))

cat /etc/fr24feed.ini
receiver="beast-tcp"
fr24key="*************"
host="127.0.0.1:30005"
bs="no"
raw="no"
logmode="1"
logpath="/var/log/fr24feed"
mlat="yes"
mlat-without-gps="yes"
http-timeout=20

Also i just checked on the radarbox feeder, also show it's config
cat /etc/rbfeeder

cat /etc/rbfeeder.ini
[client]
network_mode=true
log_file=/var/log/rbfeeder.log

key=***************************

sn=EXTRPI000******

[network]
mode=beast
external_port=30005
external_host=127.0.0.1

[mlat]

Both seem to be be similar.

You want these setting:

[client]
network_mode=true

[network]
mode=raw
external_host=127.0.0.1
external_port=30005

(if network_mode is set to false it will screw everything up just like fr24 with dvbt set.)

The mode is beast like fr24.

I think I have to wait till tomorrow 22:10.
Perhaps everithing is okay with the changes I made today.
If not, some problems will be logged at 22:05 like you proposed.

Thanks and good n8

 

[Christopher Robert]

There were no more activities necessessary, the ADS-B programs are now running stable.
But I need a hardware-upgrade.
My raspberry-activities have grown with the time, one small job after another came (DNS-Filter, firewall, printserver, NAS for backups, now ADS-B).
Its time that the busy but slow Homer (Raspberry Pi 2B+) gets a faster and flexible Marge (BananaPi Pro) on his side.
When some jobs have moved the system will be more stable and it will be easier to locate the problems.