Hi community, trying to get a newly built raspberry pi running and having an issue where the claim process is not finding the device.
From the device I can successfully ping piaware.flightaware.com and any other internet sites of interest. Browsing to multiple sites from the PI itself with local screen, keyboard etc works fine.
When I go to the claim page on Flightaware.com the device is not found. I’ve restarted several times, ran updates again and no improvement.
The device is connecting to our guest wifi here at work on the most remote mine site in Australia so I am mindful that there may be some firewall interference but that is not yet known.
Running in debug shows the TLS handshake failure.:
glenn@ADSB-TANAMI:~ $ sudo piaware -debug
2023-12-16 00:35:41Z ****************************************************
2023-12-16 00:35:41Z piaware version 9.0.1 is running, process ID 2424
2023-12-16 00:35:41Z your system info is: Linux ADSB-TANAMI 6.1.21-v7+ #1642 SMP Mon Apr 3 17:20:52 BST 2023 armv7l GNU/Linux
2023-12-16 00:35:41Z GPS: ::gpsdClient0: connect_completed
2023-12-16 00:35:41Z GPS: ::gpsdClient0: connection to gpsd at localhost/2947 failed: connection refused
2023-12-16 00:35:41Z GPS: ::gpsdClient0: closing gpsd socket, scheduling reconnect
2023-12-16 00:35:43Z Connecting to FlightAware adept server at piaware.flightaware.com/1200
2023-12-16 00:35:43Z Connection with adept server at piaware.flightaware.com/1200 established
2023-12-16 00:35:44Z TLS handshake with adept server at piaware.flightaware.com/1200 failed: handshake failed: software caused connection abort
2023-12-16 00:35:44Z reconnecting in 5 seconds…
2023-12-16 00:35:45Z ADS-B data program ‘dump1090-fa’ is listening on port 30005, so far so good
2023-12-16 00:35:45Z Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout
2023-12-16 00:35:45Z Started faup1090 (pid 2428) to connect to dump1090-fa
2023-12-16 00:35:45Z UAT support disabled by local configuration setting: uat-receiver-type
2023-12-16 00:35:47Z piaware received a message from dump1090-fa!
2023-12-16 00:35:49Z Connecting to FlightAware adept server at piaware.flightaware.com/1200
2023-12-16 00:35:49Z Connection with adept server at piaware.flightaware.com/1200 established
2023-12-16 00:35:49Z TLS handshake with adept server at piaware.flightaware.com/1200 failed: handshake failed: software caused connection abort
2023-12-16 00:35:49Z reconnecting in 4 seconds…
2023-12-16 00:35:53Z Connecting to FlightAware adept server at 206.253.80.199/1200
2023-12-16 00:35:53Z Connection with adept server at 206.253.80.199/1200 established
2023-12-16 00:35:54Z TLS handshake with adept server at 206.253.80.199/1200 failed: handshake failed: software caused connection abort
2023-12-16 00:35:54Z reconnecting in 6 seconds…
^C2023-12-16 00:35:54Z piaware (process 2424) is shutting down because it received a shutdown signal (SIGINT) from the system…
2023-12-16 00:35:54Z faup1090 exited with SIG SIGINT
2023-12-16 00:35:54Z piaware (process 2424) is exiting…
glenn@ADSB-TANAMI:~ $
On the local web page on the device I see aircraft being tracked successfully.
Any clues on how to best troubleshoot this " handshake failed: software caused connection abort" issue? I had searched this forum extensively but could only find related threads that always seemed to point to much earlier outages on the FA server side, which I don’t think is the case this time.
Look up the IP address in your router admin and go to the assigned IP address in a browser on the same network. If the device hasn’t been claimed a link to claim the PiAware device will display.
Yep. piaware can’t successfully establish a connection to the FlightAware servers; you’ll need to fix that before there’s anything on our side to claim.
Thaks for the replay SweetPea11. I had the same suggestion provided by the official support email I received overnight but either I am not understanding the guidance, or I’m blind, or my setup is different somehow.
To be more specific about my setup - it was a standard raspbian O/S build that I then layered the FA and dump1090 software onto.
I have connected my laptop to the same /24 subnet as the pi and when I open xxx.xxx.xxx.xxx:80 I get an error but when I open xxx.xxx.xxx.xxx:8080 I see the FA web page with expected aircraft details etc. but I cannot see any link that indicates I can click to claim.
I see exactly the same page when I use the browser on the PI and open 127.0.0.1:8080
Am I missing something?
OBJ - thank you also, are you confident that the TLS error I note in the logs is a firewall getting in the mix? I ask because if it is, I’d expect other sites to have some issues too but everything else is working so far. I’m considering capturing packets to see if more might be revealed during the failing exchange.
That is probably because you need to load piawareweb if you are NOT using the Flightaware image. Browsing to IPofPi/Skyaware should land you on the same page as :8080
in order to install piaware web use the following command on the raspberry pi
sudo apt install piaware-web
When it is running it will detect it isn’t being claimed as a feeder and then you will get a link to register.
it will run on port 80 so go to ipadres of pi:80 and it will be displayed.
Thanks to all for your comments. I’ve now installed the pi-awareweb and see the page on port 80. There is no link to claim and the Flightaware block is red indicating not connected to FA.
I can browse many https: sites from Chromium browser on the pi, including flightaware with no issues. I am typing this response on the PI now
I have tried many times to use the claim link on the FA site with no new device found.
An unknown is how much the firewall blocks any traffic on this guest network at the mine site, which is intended to allow fairly free reign for workers while blocking the obvious porn, gambling etc. sites. If the FW was tight, I’d expect to hit some snags while browsing etc. but have seen zero so far.
OBJ - do you know exactly what protofols etc are used in the initial connections to FA for device recognition? If not, I’ll see if I can make time available here in my limited evening break (12 hour shifts here, plus travel to camp, meal etc. leaves little spare time for non-work things ) to run wirehshark or tcpdump to figure it out myself and then speak with the global FW team in case they have some blocks in that are hampering the recognition process.
I really appreciate the quick feedback from you all.
piaware needs outbound connections to flightaware on TCP 1200 and UDP 4999…9999 (I think the UDP range might have changed as my connection is on 17094).
PiAware makes a TCP connection to piaware.flightaware.com port 1200, then does a TLS handshake, then starts talking an application-specific protocol on top of the TLS layer. notably, it is not http/https.
The TLS handshake is getting interrupted, which usually means something like a firewall is interfering and tearing down the connection.
Sounds definitely a problem with the Guest Network, NOT allowing the ports used by FlightAware to transfer out onto the net. It could be the ISP blocking the ports, though that is much less likely. Ports range from 0 to 65535. Leaving all the ports open is a huge security risk for home and commercial organizations.
For example, here or some of the ports usually left open:
*Web Service: Ports 80 (HTTP), 443 (HTTPs)
*Windows Remote Desktop Service: Port 3389
*Secure Shell (SSH): Port 22
*File Transfer Protocol (FTP): Ports 20,21
*Telnet: Port 23
*Simple Mail Transfer Protocol (SMTP): Port 25
*Post Office Protocol (POP3): Port 110
My guess, your Guest Network is doing the blocking. If you have a cooperative network manager, and a good argument, you may be able to open up specific ports like 1200 and whatever else is used by PiAware. Good luck.
I could do that but then the device would only be running when I am on site. My roster is 8 days on 6 days off so I’m trying to have 100% coverage here.
Given that this is apparent from the logs I shared initially, I suspect you are right on the money OBJ. Will get some hard port/protocol data then speak with the global firewall team. Might be able to convince them to put in an exception rule. Fortunately I have some sway with them due to my role here.
Yes, you are likely correct, just like OBJ stated. I’ll see if I can convince the global firewall team and if no luck there I may need to get more creative
Thanks for all the feedback. I’ll update the thread as things progress here.
Thanks - I’ve followed your good suggestion and as I expected, all is good with the receiver and feed once I bypassed the company firewall and used my hotspot to claim. I’ll run this way while I figure out the firewall fix or a different alternative for network access.
Once it was verified as working I put it back onto guest Wi-Fi here and immediately saw the TLS handshake issue again so the cause is clear.
For interest I’ve attached an image of the location - as I said, I work in the middle of nowhere - The Australian Outback The terrain is extremely flat out here so I am already seeing good range with the test antenna propped up on my office window ledge just one meter above the ground. The new, external high antenna I plan to install will see forever out here.
I have one remote site running on a Telstra Gen2 Arcadyan LH1000 modem with a Belong SIM. I don’t run MLAT and it consumes less tha a GB of data per month. I’m guessing there is not a lot of MLAT aircraft out there.
Could be useful if you can’t fix the firewall.
Just a little to the West of Tennant Creek so not really that remote. We only took five weeks to drive to Tennant Creek from Melbourne.
) to run wirehshark or tcpdump to figure it out myself and then speak with the global FW team in case they have some blocks in that are hampering the recognition process.
We only took five weeks to drive to Tennant Creek from Melbourne.