IP and Ports for Flight Aware


#1

My Motorola requests the specific IP of piaware.flightaware.com, I did a network tools check and it didnt show the actual IP. Ive opened UDP 4999-9999. I see my MLAT is kinda low and I have a warning that 93% is blocked … Its a new modem as ive changed providers from FIOS to Comcast.

Port Forwarding is for inbound. What setting would be for out bound ?


#2

My router has UPnP enabled and it shows an open port UDP 63145, but your situation might be different.


#3

Thanks, but that page does not show anything about what ports should be opened on a cable modem for outbound traffic?


#4

Ive heard good and bad about UPnP. I will turn it on and see if it makes a difference.


#5

Mmh, most modem/routers allow outbound traffic, only incoming traffic is blocked by a firewall.

Maybe there is a general setting, or you have to add the ip of the pi that is sending data?

Also, I guess if it blocks traffic, then you should have zero mlat signals being send out.

What is the name/product number of the modem?


#6

Opening UPnP stopped the errors. now I need to see what UPnP does.

Motorola MG7315


#7

Well Crap. Saw this morning its saying 100% of MLAT not reaching.

WTH ?

Can someone with Knowledge of Outbound help me out here. I can do Port Forwarding well (Inbound) but dont understand this Outbound stuff.


#8

Try setting the firewall settings to low, in Advanced - Protection & … - Firewall Protection.


#9

You could also check you have upstream channels working and whether wlan problems lead to data not being send, in case you connect via wlan.


#10

Direct to modem via 4 port switch. No wireless :). So thats one less problem

Firewall already at low


#11

:slightly_frowning_face:

Found this in old thread, written obj. Some of it you already tried.

piaware itself listens on no ports. It connects to piaware.flightaware.com:1200 for feeding data, localhost:30005 for receiving data, and by default it connects to localhost:30104 for returning mlat results. Also, outbound UDP to a port in the range 4999…9999 on whichever FlightAware host it connects to.


#12

The one thing that is odd, some messages are send out, others are not. If it is a configuration issue, shouldn‘t it either be working or not working at all? If you block a port, it is blocked, if you open it, all traffic goes through. Maybe there is a problem somewhere else, on the flightaware side or with the upstream service of your provider?


#13

https://portforward.com/ is a very good site with detailed info regarding port forwarding and settings for a number of routers. maybe yours is also there…
HTH
evangel


#14

I am not sure if this relates to Flightaware servers also, but the Flightradar24 servers refused connection to feeders if the feeder used IPv6. The FR24 admin suggested to give following command to overcome this issue:

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1

Above solved the problem, but if Pi is rebooted, the command has to be issued again.
I have solved this by adding “sysctl -w net.ipv6.conf.all.disable_ipv6=1” (without quotes) in file /etc/rc.local, above exit 0, as shown below:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi

sysctl -w net.ipv6.conf.all.disable_ipv6=1

exit 0

#15

there should be no need for port forwarding.

this router interface looks like utter crap. if there would be a lower level than low i would probably set it.

maybe check the firewall Event log that is shown in the screenshot by biekerc?

disabling ipv6 is always worth a try but flightaware seems to have tons more of network knowledge compared to the competitors cough so i doubt it’s a problem upstream.

A strange problem i had was with a channel bundeling service allowing simultaneous use of wired broadband and mobile broadband.
My suspicion is that if the UDP packets arrive at the flightaware server out of order they are discarded.

Wouldn’t make much sense but hey.
Maybe someone from the flightaware team can elaborate on the out of order issue even if its’ only a guess.
This out of order problem could also occur when there is congestion at your provider as UDP packets are not ordered by design.

I guess on my setup the udp packets look like this:
UDP (582 bytes) from pi:53309 to gales.hou.flightaware.com:7773 on wlan0

So the local port is 53309 and the remote port 7773.
That’s information you could check with you Firewall event log.

Apart from that it’s not much use because those packets are outbound and should not be filtered by your router.

It’s really tricky to track down intermittent UDP problems i switched off this channel bundeling i had going on but that was just a lucky guess. The reason why it didn’t work with this bundeling enabled i never figured out. (apart from my guess it was an out of order problem)


#16

Did a factory reset. Not sure what command I cleared after I reloaded my Wifi and admin passwords. But, its working now and Im seeing lots of MLAT planes again on Modesmixer.


#17

Port Forwarding is from your Router to the FIXED IP address of your device, on a given PORT. If an exchange begins from the Internet, then P.F. will be a necessity.

Outbound traffic, like our browsers, do not need P.F. and unless you’ve been tweeking your firewall, the F.W. needs no adjustment either - - all outbound traffic is allowed.

UPnP is normally unnecessary but is always a security risk. It allows a program on your system to open and configure ports willy-nilly. Try hard to avoid this if possible.