Piaware wifi permission issue

FlightAware ADS-B Flight Tracking
1

I am teaching a high school aviation course and am having my students build 5 piaware boxes this year. I have a prototype PiAware (v 3.8) that runs perfectly on my home wifi – but when moved to the school wifi, it does not connect w/ piaware.flightaware.com for some reason. I know school IT has many restrictions on the network. I just need to let them know which one to loosen for PiAware to work. This is what I know:

  1. it was able obtain an IP according to box
  2. pinging from the said wifi network to FA works just fine
  3. pinging node-to-node on the said wifi is not allowed, so I can’t SSH into the box for more details
  4. If I hardwire to the school network, it works fine too. But I need it to be running wifi for deployment purposes.

What other network requirements does PiAware have? Any help is much appreciated!!

2

edit: misread sth. …

Does the WiFi have a captive portal?
As in how do you need to visit a page and type in a password?

piaware doesn’t support that as far as i know.

Connect a keyboard and screen?

You could also plug it into the Ethernet, ssh and check the logs.

Really it only needs to open a TCP connection to FA, the port is flexible i think.
But you can ask if there are restriction on outbound TCP connections …

3
  1. Dunno about captive portal. I’ll have to ask.
  2. I just realized that hardwire network working is irrelevant as it’s literally a different network with fewer restrictions.
  3. (after connecting kb/monitor) piaware-status says “PiAware ADS-B client (faup1090) is not running” and “faup1090 is NOT connected to the ADS-B receiver.” But the Pro Stick is connected.

Would a different wifi be reading a different config file or a different section of the config file somehow?

4

You can only configure one WiFi name/password.

Try a standard Raspbian Buster Lite image …
Using ssh would actually be some worthy endeavor :stuck_out_tongue_winking_eye:

5

Yeah, i guess the faup1090 not connecting is ultimately the problem.
Again, from the box I can ping piaware.flightaware.com fine. Something else is blocked…

I have 5 piaware units that are all dead in the water with the same problem.

6 
sudo journalctl --no-pager -u piaware

nc -v -v -v piaware.flightaware.com 1200

The nc command should say this:

Connection to piaware.flightaware.com 1200 port [tcp/*] succeeded!

If it doesn’t connect, then you can’t establish the TCP connection to FA …

7

Thank you much, wiedehopf. just did the 2 commands. nc gave a succeded msg.

Any other suggestions?

8

Maybe I should ask a different question: is there a way from the server end (FA status page) that I can get info on what the error is? the device status page’s hourly receive report shows it’s not connect. Is there another way to confirm the “down” status?

9

…

You need to use both commands on the problematic WiFi …

10

yes, @wiedehopf, I did both successfully.

11

Are you able to determine the IP for one of the units (ref your point 1) and access that IP in a web browser from another computer on the same wifi network? If so then the unit has joined the wifi network with the credentials you have provided. In that case, what does that page look like in the browser? It should look like this, all green. If any sections are red you can hover your mouse over them and it will give a summary of the problem it’s having.

piaware

12

hi @chrislfa - this local status page does not work on this said wifi. Since PING is blocked, when I go to the local IP in a browser, it simply spins and times out. Again, this all works perfectly while it’s on my home wifi.

13

@wiedehopf - no, no captive portal.

14

With you saying it works fine at home, a captive portal of some kind does sound like the most likely culprit. What happens if you take a normal Windows computer and join the wifi network and try to visit somewhere like Google in a browser? Does it work immediately or does it direct you to a school page, such as wifi policy or a login page? That’s the captive portal @wiedehopf mentioned.

On a normal browser you’d simply agree to the policy or login or whatever and then it would work as normal. School assets I imagine would likely already be authenticated. But PiAware would have no easy way to manage that and would remain unable to reach the wider network. They typically work by either giving you an IP on a separate subnet until you agree/authenticate, or else they hijack DNS and redirect everything to the captive page, which would mean PiAware thinks it’s talking to FlightAware but it’s getting no response because it’s actually not.

Since it’s school activity I’d imagine if you present this to the school IT admins they’ll be able to diagnose the problem and sort it out for you.

Edit - just saw your reply saying no captive portal. I’ve leave the above there as it may be useful for future visitors with the same problem. I’d ask the school IT admins for help at this stage.

15

Thinking on, with you saying it gets an IP but you can’t reach it in a browser, perhaps the local network policy blackholes MAC addresses identifying RPi’s (starting B8-27-EB or the newer DC-A6-32) to prevent students from adding them to the network. In which case your feeders are falling foul of that policy.

16

@chrislfa - You are saying the network policy may be blocking RPi’s specifically? I’ll ask them to check but they would probably remember such a policy.

They want to help me but are just under-resourced to know what to do for me. They do use a tool to block specific hostnames (youtube, tinyurl, VPN’s, etc). But PA is fine based on ping, journalctl, and nc. That leads me to wonder whether piaware needs some additional unpublished connections.

17

The PiAware schematic may be useful for digging into that, it shows the ports and connections needed.

But regardless of its connection to FlightAware I would get things firmed up locally first. If you’ve installed PiAware and enabled ssh, and the device is getting an IP but you can’t reach it in a browser and you have no access to ssh to it, then this is where your admins need to step in.

They need to use their admin level access to:

  • Confirm that it has an IP on the wifi network and that they can see its allocation and lease
  • Confirm that they can see that IP via a browser
  • Confirm that they can ssh into it
  • Eliminate any anomalies like captive portals, web proxies, firewall rules or anything else that would prevent access locally.

Once the local situation is sorted out and you know where you stand, only then can you make sense of any symptoms you’re then seeing when attempting to feed FlightAware, off the local network.

If this all comes down to a rigid policy preventing it from working, perhaps they can configure a temporary dedicated wifi network for your project which is off the school network and lets the devices communciate externally, and which is locked down for just the exact MAC addresses of your Pis and a few dedicated computers for accessing them.

18

@syeh768 - can you post the output of this, in particular the messages around the time of connection.

You can also try:

openssl s_client -connect piaware.flightaware.com:1200

which should successfully handshake and report a CA chain like this:

Certificate chain
 0 s:C = US, ST = Texas, L = Houston, O = FlightAware LLC, OU = Operations, CN = *.flightaware.com
   i:C = US, ST = TX, O = FlightAware LLC, OU = Operations, CN = FlightAware Intermediate
 1 s:C = US, ST = TX, O = FlightAware LLC, OU = Operations, CN = FlightAware Intermediate
   i:C = US, ST = TX, L = Houston, O = FlightAware LLC, OU = Operations, CN = FlightAware Root
 2 s:C = US, ST = TX, L = Houston, O = FlightAware LLC, OU = Operations, CN = FlightAware Root
   i:C = US, ST = TX, L = Houston, O = FlightAware LLC, OU = Operations, CN = FlightAware Root

(it will complain about a self-signed certificate in the CA chain - that is normal)

19

@chrislfa - based on the schematics, do I need to verify ports 30105 and 30106 are in business? can I do a similar nc to verify that?

nc -v -v -v [hostname] 30105
nc -v -v -v [hostname] 30106

20

@obj - here is my output from sudo journalctl --no-pager -u FA

– Logs begin at Sat 2020-03-07 22:17:01 UTC, end at Sun 2020-03-08 18:33:16 UTC. –

Mar 07 22:17:15 piaware systemd[1]: Started FlightAware ADS-B uploader.

Mar 07 22:17:15 piaware piaware[483]: creating pidfile /run/piaware/piaware.pid

Mar 07 22:17:15 piaware piaware[483]: ****************************************************

Mar 07 22:17:15 piaware piaware[483]: piaware version 3.8.0 is running, process ID 483

Mar 07 22:17:15 piaware piaware[483]: your system info is: Linux piaware 4.19.75-v7+ #1270 SMP Tue Sep 24 18:45:11 BST 2019 armv7l GNU/Linux

Mar 07 22:17:17 piaware piaware[483]: Connecting to FlightAware adept server at piaware.flightaware.com/1200

Mar 07 22:17:17 piaware piaware[483]: Connection with adept server at piaware.flightaware.com/1200 established

Mar 07 22:17:17 piaware piaware[483]: TLS handshake with adept server at piaware.flightaware.com/1200 completed

Mar 07 22:17:17 piaware piaware[483]: FlightAware server certificate validated

Mar 07 22:17:17 piaware piaware[483]: encrypted session established with FlightAware

Mar 07 22:17:17 piaware sudo[538]: piaware : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=list /usr/bin/netstat --program --tcp --wide --all --numeric

Mar 07 22:17:17 piaware sudo[540]: piaware : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/netstat --program --tcp --wide --all --numeric

Mar 07 22:17:17 piaware sudo[540]: pam_unix(sudo:session): session opened for user root by (uid=0)

Mar 07 22:17:17 piaware sudo[540]: pam_unix(sudo:session): session closed for user root

Mar 07 22:17:18 piaware sudo[553]: piaware : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/netstat --program --tcp --wide --all --numeric

Mar 07 22:17:18 piaware sudo[553]: pam_unix(sudo:session): session opened for user root by (uid=0)

Mar 07 22:17:19 piaware sudo[553]: pam_unix(sudo:session): session closed for user root

Mar 07 22:17:19 piaware piaware[483]: ADS-B data program ‘dump1090-fa’ is listening on port 30005, so far so good

Mar 07 22:17:19 piaware piaware[483]: Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout --lat 33.918 --lon -118.384

Mar 07 22:17:19 piaware piaware[483]: Started faup1090 (pid 562) to connect to dump1090-fa

Mar 07 22:17:19 piaware piaware[483]: UAT support disabled by local configuration setting: uat-receiver-type

Mar 07 22:17:19 piaware piaware[483]: adept reported location: 33.91781, -118.38379, 138ft AMSL

Mar 07 22:17:19 piaware piaware[483]: logged in to FlightAware as user DVSAviation01

Mar 07 22:17:19 piaware piaware[483]: my feeder ID is bc63599b-cd28-4da7-8189-f286d80247ed

Mar 07 22:17:19 piaware piaware[483]: site statistics URL: https://flightaware.com/adsb/stats/user/DVSAviation01#stats-121431

Mar 07 22:17:19 piaware piaware[483]: Lost connection to adept server at piaware.flightaware.com/1200: server closed connection