ON am ADSB Stats page the Local IP address is not correct at all. All of the octets are incorrect. I wonder why it is showing the bad addres. Where do I correct that?
Is it an IP that is use by the receiver, just not the one you thought you had configured? Or is it completely wrong and unrelated to your network? Did you used to use that address, or is there any reason you can think of why you would have the address listed? Do you have multiple feeder sites and you’re viewing a different one to the one you thought?
Completely wrong. I have a 192.168 network and the “Site Local IP” is 172.18.0.7.
Single feeder site. I seem to recall that popped up after PiAware 8.x
I have no idea where the 172 address is coming from. I am on PiAware 9.0.1
FYI. The IP address of the Pi is a static address
Your IP address starting with 172 is a class B private network
Just a silly thought, is your 192.168 class C network connected to a bigger network prior to going on the internet?
That would explain why you see a class C private network and you end up at Flightaware with a class B IP address.
What is your gateway IP address ?
Thanks, my newwork (all Ubiquiti gear) is a single typical home single layer 192.168.1 with a gateway of 192.168.1.1. I do have 4 VLAN’s and all of my radio PC’ and home PC’s are on the 192.168.1 subnet. I have been dusting off my network brain cells (in my pre retired life I was a network engineer -about 25 years ago) trying to figure out where the 172 is coming from.
Okay let’s look a little layer deeper then.
Login to your Pi and list all the network interfaces and their IP’s
issue the following command:
/sbin/ifconfig -a
Check if you have multiple IP’s, underneath one of my systems output
Normally you would have an eth0 and a lo interface (ethernet and loop-back adapter).
Additionally there could be a wlan0 interface depending if you have Wi-Fi enabled.
None of those should have the 172. address but an 192.168.1.x address for the eth0 and wlan0 interface. the lo interface will be 127.0.0.1 ( local loop-back IP address).
Then do a traceroute on your Pi to see if there are strange IP hops going on.
trace route isn’t installed by default so you have to install it first
sudo apt-get update
sudo apt-get install traceroute
then execute the command
traceroute flightaware.com
It will show you the number of hops and the route it takes towards the FA server.
Here’s an example from one of my systems.
Hop 1 is my local router
Hop 2 is the exit of the serviceprovider
Hop 3 and 4 are masked
Hop 5 is the receiving server from Flightaware (that handles the traceroute request, not the server the feeder is talking to).
Hop 6 is the answering server.
They both have 172.x.x.x addresses but those are public IP ranges., 172.16.0.0 – 172.31.255.255 are reserved for private Class B networks.
1 Like
Full disclosure I am running (and have been for a while) the “ultrafeeder” config. I had upgraded to a PI-4 a couple of year ago and did a fresh install of my various feeders. Then updated the config’s with my previous feeder id’s.
I do have two 172’s that popped up in my ifconfig. wlan0 is off via kill.
br-1b3865098cb9: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.18.0.1 netmask 255.255.0.0 broadcast 172.18.255.255
inet6 fe80::42:fdff:fe1d:c737 prefixlen 64 scopeid 0x20
ether 02:42:fd:1d:c7:37 txqueuelen 0 (Ethernet)
RX packets 100713341 bytes 41555326826 (38.7 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 95696236 bytes 6361555579 (5.9 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:66:17:20:76 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Here is my trace route.
traceroute to flightaware.com (104.18.39.201), 30 hops max, 60 byte packets
1 unifi (192.168.1.1) 0.149 ms 0.082 ms 0.084 ms
2 22.21.176.1 (22.21.176.1) 13.283 ms 13.350 ms 13.230 ms
3 int-0-4-0-7.dtr01owsomi.netops.charter.com (96.34.34.40) 13.308 ms 13.292 ms 13.280 ms
4 lag-247.crr01aldlmi.netops.charter.com (96.34.35.64) 16.400 ms 16.384 ms 16.378 ms
5 * lag-807.bbr01aldlmi.netops.charter.com (96.34.2.8) 15.662 ms *
6 lag-905.bbr01chcgil.netops.charter.com (96.34.0.193) 21.162 ms 17.488 ms 17.399 ms
7 lag-811.prr01chcgil.netops.charter.com (96.34.3.119) 35.294 ms 74.140 ms 74.126 ms
8 13335.chi.equinix.com (208.115.136.180) 20.968 ms 096-034-152-083.biz.spectrum.com (96.34.152.83) 15.412 ms 20.933 ms
9 172.69.5.3 (172.69.5.3) 20.940 ms 172.70.176.2 (172.70.176.2) 20.198 ms 172.69.56.3 (172.69.56.3) 19.936 ms
10 104.18.39.201 (104.18.39.201) 20.127 ms 18.280 ms 18.251 ms
**** seeing all that I wonder about disabling the bridge and docker0 interfaces??? Are they really needed?
I don’t use the setup you have but my guess would be that the docker environment has a virtual private network inside. This will probably communicate to the outside world via your Ubiquiti network gateway.
My assumption is that your Pi is reachable under the 192.168.1.x IP address but that the feeders itself are communicating via the class B network inside Docker.
So in your case the construction is : Class B IP address 172.18.0.1 (class B can be determined from the netmask IP address) via gateway 172.18.0.x towards your Ubiquity 192.168.1.1 gateway way and then over the internet towards Flightaware.
Since the feeder in docker has an 172.18.0.X address that will be shown in the statistics page in Flightaware.
If you would disable the bridge or the docker interface you end up with a system not able to communicate towards Flightaware.
These interfaces translate the Class B network traffic towards your Ubiquity router(Class C network) and onwards to Flightaware.
As long as you run in in a vrtual environment like docker you will have a virtual network inside that environment.
The IP address assigned inside that virtual environment will be sent as the local IP address towards Flightaware and not the Class C IP address of the Pi4 acting as a docker host inside your Ubiquity network.
So long story short, as long as you run a virtual environment you won’t see the local IP address of the PI4 
1 Like
My router assigns local IP’s like 10.0.0.xx and gateway is 10.0.0.1
This does not match with Class B and Class C network IP’s described by you. Which class network is mine?
Private IPv4 addresses[edit]
The Internet Engineering Task Force (IETF) has directed the Internet Assigned Numbers Authority (IANA) to reserve the following IPv4 address ranges for private networks:[1]: 4
| RFC 1918 name | IP address range | Number of addresses | Largest CIDR block (subnet mask) | Host ID size | Mask bits | *Classful*description[Note 1] |
|---|---|---|---|---|---|---|
| 24-bit block | 10.0.0.0 – 10.255.255.255 | 16777216 | 10.0.0.0/8 (255.0.0.0) | 24 bits | 8 bits | single class A network |
| 20-bit block | 172.16.0.0 – 172.31.255.255 | 1048576 | 172.16.0.0/12 (255.240.0.0) | 20 bits | 12 bits | 16 contiguous class B networks |
| 16-bit block | 192.168.0.0 – 192.168.255.255 | 65536 | 192.168.0.0/16 (255.255.0.0) | 16 bits | 16 bits | 256 contiguous class C networks |
In practice, it is common to subdivide these ranges into smaller subnets.
You have a Class A private network on your router
The net mask determines how many IP addresses you have available in your environment.
A netmask stating 255.255.255.0 leaves you with 256 ip addresses ( minus 1 broadcast and 1 gateway address) so you have 254 possible IP’s to connect inside that network. This is also called a /24 network
In a netmask of 255.255.0.0 you have 65356 available IP’s that is a /16 network
In the Class A network with netmask 255.0.0.0 , a /8 network you have 16777216 IP’s (would be a little overkill for a home network)
1 Like
I had not really looked into the networking structure of Docker before today. I was poking around that earlier today plus with your comments it does make sense where the 172. is coming from. It’s not that big of a deal as I tend to go to the local address anyways. On occasion I might click on the link from the stats page (brain cells are a little old).
Thanks again for the research effort.
Have a Happy New Year.
1 Like
Happy new year to you too, make it a good one.
As an IT and networking guy myself I like to get into the detail so happy to be of service
1 Like
Sure enough, in the bowels of the default_adsb network in Docker is the PiAware connection:
(To include virtual mac addresses)
"fdfb02c7903ef6e7e2ec14f681a257b769379f99bcaadfa2392491f5d3520eac": {
"Name": "piaware",
"EndpointID": "2edf95948c42df83b603a1af72f65309656540cd62ba9cbd0522aa5f2f8e9429",
"MacAddress": "02:42:ac:12:00:07",
"IPv4Address": "172.18.0.7/16",
"IPv6Address": ""
1 Like
Thank you for detailed info about local network.
1 Like
I never use docker.
When all feeders and decoders have debian packages available for direct installation on RPi, why should I complicate my system by unnecessarily creating containers?
Agreed, to each his/her own on building their systems. I choose to try the Docker world when I upgraded hardware mainly to learn/understand the system design and process. The next time a new concept comes out I’ll probably try that way also. 
5 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.