See my last post. === I need to figure out a better solution. Right now, if the custom port server has more than one person feeding to single port, or the server goes down then it will redirect your feed and/or anyone double feeding to 30005. Previously, we would lose the data from anyone double feeding. However, due to VRS coding the port doesn't close so I can't make it always put the feed back to the custom port. I'll look at it when I have time. I've reported the VRS not closing ports in a timely manager to the VRS dev. The developers stance is since ADSBx is using VRS beyond what he intends it to be used and it needs to be VRS behind a proxy server, he feels that it's not a vanilla install and therefor not a VRS problem to fix.
Mlat-client seems to work - no disconnection reported. Other entries are typical for startup. Check if netcat script looks as it should: Code: #! /bin/sh while true do sleep 30 /usr/bin/socat -u TCP:localhost:30005 TCP:feed.adsbexchange.com:51081 done When your data are not visible on custom feed VRS run netstat on Pi and check if it is connected to ADSBx server on custom port.
MDA, It stopped feeding data so I ran netcat and the result is: Code: Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 adsbx-custom.mid:http Dell-laptop.mi:60618 TIME_WAIT tcp 0 0 adsbx-custom.mid:http Dell-laptop.mi:60636 TIME_WAIT tcp 0 0 adsbx-custom.mid:http Dell-laptop.mi:60665 TIME_WAIT tcp 0 0 localhost:30104 localhost:39740 ESTABLISHED tcp 0 0 localhost:49610 localhost:30005 ESTABLISHED tcp 0 0 localhost:39740 localhost:30104 ESTABLISHED tcp 0 0 localhost:9105 localhost:51878 TIME_WAIT tcp 0 0 adsbx-custom.mid:41746 feed.adsbexchange:51081 ESTABLISHED tcp 0 240 adsbx-custom.mid:3226 Dell-laptop.mi:60427 ESTABLISHED tcp 0 0 adsbx-custom.mid:http Dell-laptop.mi:60679 ESTABLISHED tcp 0 0 adsbx-custom.mid:http Dell-laptop.mi:60625 TIME_WAIT tcp 0 0 localhost:30005 localhost:49610 ESTABLISHED tcp6 0 0 localhost:http localhost:54020 TIME_WAIT tcp6 0 0 localhost:http localhost:54014 TIME_WAIT tcp6 0 0 localhost:9100 localhost:49638 TIME_WAIT tcp6 0 0 localhost:http localhost:54006 TIME_WAIT I also checked out the adsbexchange-netcat_maint.sh file and it has basically what you showed above: Code: while true do /usr/bin/socat -u TCP:localhost:30005 TCP:${ADSBXCUSTOMURL}:${CPORT} sleep 30 done and adsb-config.txt has the following: Code: ADSBXCUSTOMPORT 51081 Appreciate the troubleshooting help. endo
So it's not that you are stopping feeding data. You are still feeding. Sometimes it will get routed to 30005, I can't fix it until the VRS dev fixes/changes how VRS handles TCP port opening and closing. And I don't think that will happen any time soon. So occasionally your custom port might go to the anonymous port. It will correct, it just happens when the custom server has an issue HAProxy routes it to the 30005 cluster so no data is lost. Assuming your IP is: 173.73.x.x an_exp=<NEVER> rex=4m36s wex=<NEVER> buf=0x6bb8c0 data=0x6bb8d4 o=0 p=0 rsp.next=0 i=0 size=0 0x46b8f90: [22/Feb/2019:00:08:53.906034] id=805907 proto=tcpv4 source=173.73.x.x:33733 flags=0xce, conn_retries=3, srv_conn=0x14bd1e0, pend_pos=(nil) frontend=CustomFeeds_150 backend=custom_51081
James, Yup, that's my IP address. You may have explained in a previous post about it switching to the generic 30005 port but I didn't quite understand at the time. Got it now. Not the end of the world if I'm not on the custom port, I just wanted to make sure I was still feeding. Regards
Just keep feeding to 51081 ... I'm trying to see if I can implement sticky sessions based on the source IP so if VRS is holding the port open, and a feed disconnects and reconnects ... maybe just maybe it will put the feed back on the custom port ....
Just installed the image to a rpi-zero I can access the dashboard at ip-address, but from there only dump1090 and the shell loads. I can't get the 'real' dashboard to load.
You need to use Grafana for Pi Zero ARMv6 https://www.adsbexchange.com/forum/...age-on-pi-zero-with-grafana-dashboard.621433/
Thanks for the help, I got Grafana working now. I still don't see any planes. I'm getting this on the map: "Problem fetching data from dump1090. AJAX call failed (error: Not Found). Maybe dump1090 is no longer running? The displayed map data will be out of date."
Hit F5 to group them arrow keys to move up and down kill the adsbexchange-dump1090_maint.sh script .. run it manually or try to run dump1090 with --net --interactive see what the error is
ah, "no supported RTLSDR devices found. " I'm using a nesdr smartee rtlsdr and a micro usb to usb A OTG cable
I've tested those here. I have 2 of those black smartee, so they are supported. They are RTL2832U. lsusb
If I had to guess it's not detecting the device. Unplug it and plug it back in. Maybe cable isn't the best, SDR use a lot of power and require good cables. I have a zero W running the FA SDR, and have test with RTL-SDR, smartee, and a few others.
I just tested the rtlsdr on my android phone to make sure it was working and it was. I'll try restarting and see if that helps. " [email protected]:~ $ sudo sh ./adsbexchange-dump1090_maint.sh t: /sys/class/net/eth0/address: No such file or directory -e Running dump1090 with --quiet --net --ppm 0 --fix --lat 39.095079 --lon -84.63202 --max-range 400 --net-ri-port 0 --net-ro-port 30002 --net-bi-port 30004,30104 --net-bo-port 30005 --net-sbs-port 30003 --net-heartbeat 30 --net-ro-size 5000 --net-ro-interval 1 --net-buffer 2 --write-json /run/dump1090-mutability --write-json-every 5 --json-location-accuracy 1 Thu Mar 7 07:05:32 2019 UTC dump1090-mutability v1.15~dev starting up. Using sample converter: UC8, integer/table path No supported RTLSDR devices found. "
bash script is executable already sudo ./adsbexchange-dump1090_maint.sh is sufficient .. lsusb that will show USB devices .. You should see a RTL2832U device ...
