I have a FlightAware FlightFeeder connected by Ethernet to my router. I also have a Raspberry Pi running FlightRadar24, which receives ADS-B data from the FlightFeeder using “beast-tcp” on port 30005.
The problem is that my ISP router does not support DHCP reservations, so the FlightFeeder’s local IP can potentially change and then I would have to update the FR24 configuration.
Currently, I’ve connected a small TP-Link router between the ISP router and the two devices, and I use its DHCP reservation feature to keep the FlightFeeder’s IP fixed.
I’d like to remove the extra TP-Link router if possible.
Is there any way to keep the FlightFeeder on a fixed/reserved IP while connecting it directly to the my ISP router? For example, can the FlightFeeder be configured with a static IP, or is there another recommended solution such as using its hostname/MAC address?
I’m looking for the most reliable solution for a 24/7 unattended setup.
You actually have a PiAware setup. Why not use Tailscale on both devices? It allows you to create a VPN and access them directly from anywhere in the world using a private IP range like 100.82.xxx.xxx. You would need to install it on both feeders as well as on the smartphone or PC you use for access, and run the application on all of them so they are on the same private network.
Thanks for the suggestion! Just to clarify my setup: I have a FlightFeeder that FlightAware provided to me for free, and I also have my own Raspberry Pi running the FR24 feeder. The FR24 Pi currently connects to the FlightFeeder using its local IP address and Beast TCP.
For Tailscale, would I need to install it on both devices? Is it possible to install Tailscale on the FlightAware-provided FlightFeeder?
Also, does the FlightFeeder allow me to change its network/software settings or install additional software, or is it restricted to the software provided by FlightAware?
If Tailscale can be installed on the FlightFeeder, then this sounds like a very interesting solution.
Why not just put a static IP on the FlightFeeder, somewhere outside of the range of IPs likely to be assigned by your router?
If your router is giving out 192.168.1.xxx addresses, give the FlightFeeder something like 192.168.1.235 (unless you have 200+ devices on your network, grabbing addresses from your router…)
In most cases a DHCP device will get its “preferred” IP back unless it falls off of the network and loses its lease long enough that the router puts that address back in the bucket. In general, assignments are distributed from the low end of the range, so I high static shouldn’t cause any problems in most cases. (and yes, you can use a static IP on the FlightFeeder - that’s how mine is set up)
Thanks! That’s helpful. Could you explain how you configured the static IP on your FlightFeeder? I have the non-touchscreen version of the FlightFeeder, so I don’t have the touchscreen interface to change the network settings.
Also, I only have around 10 devices at most connected to my router, so there is very little chance of the DHCP pool being heavily used. Would simply assigning the FlightFeeder a high static IP outside the usual range work in this case?
I’d appreciate it if you could explain the exact steps you used to configure the static IP on your FlightFeeder.
So, the best option would be an extra router to ensure everything works smoothly (since you can’t configure the ISP’s router or the FlightFeeder itself). After that, you could use another device that supports Tailscale to set up a “subnet router” (which exposes specific local IP ranges—like 192.168.1.0/24—to your tailnet; this allows you to reach devices on that local network that don’t have Tailscale installed, while keeping your general internet traffic local). It exposes your IP range to your tailnet, enabling you to directly access devices that don’t support Tailscale or where it can’t be installed, simply by typing their local IP address (192.168.xxx.xxx).
If you don’t actually want to use an extra router—but rather just a subnet router for remote access via the Tailnet—you need to check the local installation IP (usually 192.168.xxx.xxx) on your status page (https://www.flightaware.com/adsb/stats/user/xxxxxxxxxxxxxxxx) under the “Site Information” tab before attempting to access it via Tailnet.
I had no idea that there were FlightFeeders that didn’t have an interactive display. Mine does, so it was easy to configure. I am afraid I have no idea how you would do it if they have fully “black boxed” the device. (and I have to admit that doing so seems like a really dumb idea on FA’s part. That would create a device that would work great as long as the environment is exactly what they planned for).
Have you reached out to FlightAware Support? I would think they could help you out through their remote access.
@Raghubirbalhara as geckoVN mentioned, almost all ISP’s allow the use of a customer-supplied router {I’m fibre to premises and apart from the optical network transceiver (ONT)}, the entire system is owned and managed by me - granted, the ISP doesn’t get to manage that, which they don’t like, but that’s control for you.
Two options for you - get your own router and use that with the manufacturers firmware, or visit OpenWRT and source your own router that is supported by it and use that instead of the ISP’s router - don’t be tempted to double-NAT the routers - this is not good networking practice. Either way, you can then set the IP address(es) as reservations on the router, meaning they will always get the same local IP addresses. If you do decide to use the OpenWRT route, there is no shortage of help available on their forums.
A fixed DHCP reservation is the “best” way, if you can do that, since that keeps the configuration somewhere under your control and more accessible than putting the config on the flightfeeder itself.
If you really can’t do that, then you could provide a flightfeeder-config.txt on the boot partition of the FlightFeeder sdcard (with syntax like that of a PiAware sdcard’s piaware-config.txt) to configure a static IP, but maintaining that is not great since flightfeeders are not really set up for easy access to the sdcard and we don’t really test this path much at all.
