docker-fr24feed-piaware-dump1090
docker-fr24feed-piaware-dump1090 copied to clipboard
Thom-x
piaware MLAT Client with wrong configuration for Beast-format results connection and http feed tracker dosn´t show any airplanes
Specifications
- Image hash or version: 1dfcc89a983344c2aea001478dbbcd46403947867189f1ad3c71d4b2919ca2eb
- Platform: armv8
- Subsystem:
Expected Behavior
Beast-format results connection with dump1090:30104:
Actual Behavior
Beast-format results connection with 127.0.0.1:30104:
Steps to Reproduce the Problem
I run a rasp. v4 swarm cluster of 3 nodes. On the first node i have a running dump1090 container, which is not in the swam context because of missing device section in compose support :
/ # netstat -antp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.11:37461 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:30001 0.0.0.0:* LISTEN 1/dump1090
tcp 0 0 0.0.0.0:30002 0.0.0.0:* LISTEN 1/dump1090
tcp 0 0 0.0.0.0:30003 0.0.0.0:* LISTEN 1/dump1090
tcp 0 0 0.0.0.0:30004 0.0.0.0:* LISTEN 1/dump1090
tcp 0 0 0.0.0.0:30005 0.0.0.0:* LISTEN 1/dump1090
tcp 0 0 0.0.0.0:30104 0.0.0.0:* LISTEN 1/dump1090
tcp 0 0 10.0.23.83:30005 10.0.23.96:35814 ESTABLISHED 1/dump1090
tcp 0 0 10.0.23.83:30005 10.0.23.96:35824 ESTABLISHED 1/dump1090
tcp 0 0 :::30001 :::* LISTEN 1/dump1090
tcp 0 0 :::30002 :::* LISTEN 1/dump1090
tcp 0 0 :::30003 :::* LISTEN 1/dump1090
tcp 0 0 :::30004 :::* LISTEN 1/dump1090
tcp 0 0 :::30005 :::* LISTEN 1/dump1090
tcp 0 0 :::30104 :::* LISTEN 1/dump1090
/ #
/ #
My current stack configuration :
version: "3.7"
services:
feeder:
image: "thomx/fr24feed-piaware"
restart: unless-stopped
volumes:
- /etc/localtime:/etc/localtime:ro # needed to sync time for MLAT
environment:
#### System Service State
- "SERVICE_ENABLE_DUMP1090=false"
- "SERVICE_ENABLE_FR24FEED=false"
- "SERVICE_ENABLE_HTTP=true"
- "SERVICE_ENABLE_IMPORT_OVER_NETCAT=false"
- "SERVICE_ENABLE_ADSBEXCHANGE=false"
- "SERVICE_ENABLE_PLANEFINDER=false"
- "SERVICE_ENABLE_OPENSKY=false"
- "SERVICE_ENABLE_ADSBFI=false"
- "SERVICE_ENABLE_RADARBOX=false"
- "SERVICE_ENABLE_ADSBHUB=false"
##### PIAWARE
- "SERVICE_ENABLE_PIAWARE=true"
- "PIAWARE_FEEDER_DASH_ID=XXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX"
- "PIAWARE_RECEIVER_DASH_TYPE=other"
- "PIAWARE_RECEIVER_DASH_HOST=dump1090"
- "PIAWARE_RECEIVER_DASH_PORT=30005"
#### Default Values
- "HTML_DEFAULT_TRACKER=FlightAware"
#- "DUMP1090_REMOTE_HOST=dump190"
#- "DUMP1090_REMOTE_PORT=30005"
- "HTML_SITE_LAT=51.000000"
- "HTML_SITE_LON=12.000000"
- "HTML_SITE_ALT=124"
- "HTML_SITE_NAME=HOME"
- "MLAT_EXACT_LAT=51.000000"
- "MLAT_EXACT_LON=12.000000"
- "MLAT_ALTITUDE_MSL_METERS=124"
deploy:
resources:
limits:
memory: 200M
replicas: 1
labels:
- "traefik.enable=true"
- "traefik.swarm.network=proxy"
- "traefik.http.routers.sdr.rule=Host(`sdr.fritz.box`)"
- "traefik.http.routers.sdr.entrypoints=websecure"
- "traefik.http.routers.sdr.tls=true"
- "traefik.http.routers.sdr.tls.domains[0].main=sdr.fritz.box"
- "traefik.http.routers.sdr.tls.domains[0].sans=sdr.fritz.box"
- "traefik.http.routers.sdr.service=sdr"
- "traefik.http.services.sdr.loadbalancer.server.port=8080"
- "traefik.http.services.sdr.loadBalancer.sticky.cookie=true"
- "traefik.http.services.sdr.loadBalancer.sticky.cookie.name=sdr"
networks:
- proxy
logging:
options:
max-size: "30m"
tmpfs:
- /run:exec,size=32M
- /planefinder/log:exec,size=32M
- /usr/lib/fr24/public_html/data:size=32M
networks:
proxy:
external: true
At that point everything is working fine - my feeder is shown in piaware - with 3 green status bars. But in the stack container i got several messages :
2023-11-18T21:15:23.857177615Z [piaware] mlat-client(242): Receiver status: connected
2023-11-18T21:15:23.857554984Z [piaware] mlat-client(242): Server status: synchronized with 247 nearby receivers
2023-11-18T21:15:23.858251556Z [piaware] mlat-client(242): Receiver: 212.7 msg/s received 15.4 msg/s processed (7%)
2023-11-18T21:15:23.858786813Z [piaware] mlat-client(242): Server: 0.0 kB/s from server 0.0kB/s TCP to server 0.2kB/s UDP to server
2023-11-18T21:15:23.859244682Z [piaware] mlat-client(242): Results: 1.2 positions/minute
2023-11-18T21:15:23.859747032Z [piaware] mlat-client(242): Aircraft: 5 of 5 Mode S, 12 of 12 ADS-B used
2023-11-18T21:15:49.025521314Z [piaware] mlat-client(242): Beast-format results connection with 127.0.0.1:30104: [Errno 111] Connection refused
2023-11-18T21:15:54.019923550Z [piaware] 1294 msgs recv'd from the ADS-B data program at dump1090/30005 (295 in last 5m); 1294 msgs sent to FlightAware
2023-11-18T21:16:19.433077013Z [piaware] mlat-client(242): Beast-format results connection with ::1:30104: [Errno 99] EADDRNOTAVAIL
2023-11-18T21:16:49.929933600Z [piaware] mlat-client(242): Beast-format results connection with 127.0.0.1:30104: [Errno 111] Connection refused
2023-11-18T21:17:20.291891279Z [piaware] mlat-client(242): Beast-format results connection with ::1:30104: [Errno 99] EADDRNOTAVAIL
2023-11-18T21:17:50.813398209Z [piaware] mlat-client(242): Beast-format results connection with 127.0.0.1:30104: [Errno 111] Connection refused
2023-11-18T21:18:20.876294228Z [piaware] mlat-client(242): Beast-format results connection with ::1:30104: [Errno 99] EADDRNOTAVAIL
2023-11-18T21:18:51.326009504Z [piaware] mlat-client(242): Beast-format results connection with 127.0.0.1:30104: [Errno 111] Connection refused
2023-11-18T21:19:21.617961951Z [piaware] mlat-client(242): Beast-format results connection with ::1:30104: [Errno 99] EADDRNOTAVAIL
2023-11-18T21:19:51.945382619Z [piaware] mlat-client(242): Beast-format results connection with 127.0.0.1:30104: [Errno 111] Connection refused
2023-11-18T21:20:22.693274119Z [piaware] mlat-client(242): Beast-format results connection with ::1:30104: [Errno 99] EADDRNOTAVAIL
2023-11-18T21:20:52.726622939Z [piaware] mlat-client(242): Beast-format results connection with 127.0.0.1:30104: [Errno 111] Connection refused
2023-11-18T21:20:54.020374011Z [piaware] 1570 msgs recv'd from the ADS-B data program at dump1090/30005 (276 in last 5m); 1570 msgs sent to FlightAware
I expect that the mlat-client connect´s to my container dump1090:30104 and not to 127.0.0.1:30104 or missed i something ?
I you want to connect to a remote dump1090, you can do it like that:
- "DUMP1090_ADDITIONAL_ARGS=--json-location-accuracy 2 --net-bi-port 30004,30104 --net-only"
- "SERVICE_ENABLE_IMPORT_OVER_NETCAT=true"
- "DUMP1090_LOCAL_PORT=30004"
- "DUMP1090_REMOTE_HOST=dump1090"
- "DUMP1090_REMOTE_PORT=30005"
If you do it like this, you don't have to change anything else.
I you want to connect to a remote dump1090, you can do it like that:
- "DUMP1090_ADDITIONAL_ARGS=--json-location-accuracy 2 --net-bi-port 30004,30104 --net-only" - "SERVICE_ENABLE_IMPORT_OVER_NETCAT=true" - "DUMP1090_LOCAL_PORT=30004" - "DUMP1090_REMOTE_HOST=dump1090" - "DUMP1090_REMOTE_PORT=30005"If you do it like this, you don't have to change anything else.
Ok that is weird. In my opinion the mlat client of piaware should also use the environment var PIAWARE_RECEIVER_DASH_HOST and maybe a additional env variable like PIAWARE_RECEIVER_DASH_BEAST_PORT for the port definition - like in the other feeder parts.
I mean the same issue exist also in the ADS-B Exchange feeder. There both XXXX_RECEIVER_HOST and XXXX_RECEIVER_PORT variables are missing and the feeder also try´s 127.0.0.1
Everything is working fine if dump1090 is running in the same container, but if it runs outside - like on my side - some of the feeder will not work, which is a shame, because it is a relly nice deployment/package which you created.
But back to your answer, it means that your dump1090 starts and takes the input from my dump1090 outside and forwards it to the mlat client, right?
If so - not a nice setup . Is there not the possiblity to provide the external receiver var for host and port to all feeder´s and also to the "secondary" parts of the feeder - like the mlat client of piaware ?
Anyway, I will try - but in my opinion not the best solution
It might be possible to do it the way you want. But this image was made to put everything in the same place. Routing the traffic from remote dump1090 to the local one is the easiest way I found, it avoid complex configuration and works pretty good, it's just two dump1090 taking to reach other.
It might be possible to do it the way you want. But this image was made to put everything in the same place. Routing the traffic from remote dump1090 to the local one is the easiest way I found, it avoid complex configuration and works pretty good, it's just two dump1090 taking to reach other.
But why then the environment var exist for XXXX_RECEIVER_HOST and XXXX_RECEIVER_PORT on other feeder´s section´s ? I mean yea your image was build for single container which is mostly perfekt and when docker swarm compose will fully supported devices like USBs, then everything will be fine for me ;) - but at the moment they don´t support it.
I mean, is it really a high risk to replace every 127.0.0.1 defintion with a environment var for every feeder section ? It would be a complete implementation rather than just a partial one and it gives more flexibility.
Yea it is work i know but one point more for your image ;)
PR are welcome. 😄 I did not do it because not enough time and no need for it. Also it's a bit tedious to do it for all feeders.
So no chance that you will fix that point - that every 127.0.0.1 address for actually local dump1090 app / or feeder section, is more flexible to set via env var for a remote instance ?
No chance right now sorry. It would involve some rework and documentation, I'm pretty sure people won't use it properly in the end.
For me using local dump1090 connecting to a remote one it a solid workaround for now. It's how I've been using it for several years.