MissingKeyMapError On PfClient Port 30053


New Member
Greetings! I am new to this site. I have been running two ADS-B receivers on Raspberry Pi's since the summer of 2014. One is on the north shore of Long Island and the other is on the south shore. Besides feeding my own private Virtual Radar Server implementation, they also feed some other flight tracking services. I just installed pfclient on these two receivers and they are now feeding PlaneFinder.net.

I have noticed a problem with the receivers depending upon how I specify the URL and the device I am accessing it from. I am getting a MissingKeyMapError from Google Maps. After doing some research, I see the Google has implemented mandatory keys effective June 22, 2016. I was wondering if there is any workaround or planned upgrade to fix this problem. My home device is the most problematic as it is configured with a NAT address of If I access on the local network with that address it works fine. If I try to access it from the public address (port forwarding is enabled) I can get to the device but the maps throw the "Oops! Something went wrong" with MissingKeyMapError error. I can still access the logs, data, 3D view and settings.
Yes they suddenly made the a requirement at very short notice.

We are thinking about the best way forward for this!
Thanks for the info. I was not quite sure if it was my installation or this new Google mess. I'll take "Google Mess" for $500 Alex!
I have an idea that might work. I use Virtual Radar Server and I tried to move my site to my personal domain from a domain I was borrowing. Naturally, Google Maps scoffed at the idea without a map key (the current domain is grandfathered because it was active before June 22, 2016) so I registered for a free map key and was able to install the necessary JavaScript to allow my personal domain access to the Google Maps JavaScript API. Would it be possible to add an argument to pfclient, such as --map-key=xxxx, so that users can register for their own keys and supply them to pfclient? If present, the module would need to inject the the following code (from Google examples):

<script async defer src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&callback=initMap"

Replacing YOUR_API_KEY with the key supplied on the command line.
Yes we may do something like this although we would rather not have users jumping through these hoops so may switch to something else for mapping.
For most users I would not expect needing a key to be a problem. Apparently keys will not be required for people using private addresses in their URL such as those in the 192.168.x.x block (at least not for the foreseeable future). I have no problem using to access my device. When I switch to my public address either using the physical address (68.x.x.x block) or my personal domain it does not work and the key is required. The funny thing is if I use my employers domain to reference my device's 68.x.x.x address (employer's domain has been using the Google Maps API for sometime now and is grandfathered under Google's new policy) I am able to access the maps on my device from the Internet without a key using a host name on that domain I set up to point to my device. For the time being, it is a viable workaround.

If implemented, I would expect the map key feature to really be only for power users and not for casual home users who do not do port forwarding on their router and only access the system at home. Just my random thoughts... :)