IP Location discovery

[ka7u]

This isn't a complaint, I'm just curious how this works. Please note the lines below from the user.log: Dec 27 02:32:20 kiwisdr kiwid: 3:59:32 0... 0 3937.00 kHz lsb z9 "ka7u" ::ffff:174.238.145.162 Phoenix, Arizona, USA (LEAVING after 0:08:33) Dec 27 02:33:58 kiwisdr kiwid: 4:01:10 01.. 1 580.00 kHz am z8 "ka7u" ::ffff:192.168.6.1 Phoenix, Arizona, USA (ARRIVED)

Both logins are reported from Phoenix, but the 2nd one shows a local IP address working through a VPN back to the local network. So it would seem the IP location is determined by the client web browser and not the KiwiSDR server, or so I speculate. Would you care to tell how this IP Location discovery is accomplished? Ron - KA7U

[jks-prv]

Hi Ron. Right now connecting IP addresses are geolocated using the service provided by ipinfo.io You can duplicate the lookup by typing this on the Beagle:

curl ipinfo.io/174.238.145.162

You should get:

{
  "ip": "174.238.145.162",
  "hostname": "162.sub-174-238-145.myvzw.com",
  "city": "Phoenix",
  "region": "Arizona",
  "country": "US",
  "loc": "33.4449,-112.0868",
  "org": "AS22394 Cellco Partnership DBA Verizon Wireless",
  "postal": "85007"
}

Now I know you're not in Arizona. But are you using a 3G/4G cell-based Internet service from Verizon? That might explain why the IP address geolocates to a funny place. If they're back-hauling over their cell network to Phoenix before it jumps onto the Internet.

You are correct about the second point: The lookup with ipinfo.io is performed in Javascript on the client's browser and the result passed back to the Kiwi server. It's done this way for a couple of reasons. First, if all the lookups were done on the Kiwi server then it's possible (but not likely) the hourly/daily/monthly maximum of these free lookup services might be reached. By doing it on the client-side the requests are distributed amongst all the client IP addresses. Second, at the time the geolocation lookup was added there wasn't good support for blocking actions on the Kiwi server. And doing a call to curl within the server can potentially block for a long time depending on how long the site takes to respond (or timeout). There is now better support available and it may make sense to move the geolocation to the server. Especially in light of the security implications.

I'm not sure why it still says Phoenix when you're using a VPN back to the same local network. Doing a geolocate of a non-pubic IP address usually gives an error. How is it you're doing a VPN back to the local network anyway? Why would you do that? Does it solve some sort of problem?

[ka7u]

OK John, and thank you for the informative explanation. I understand it now. I am in Phoenix for the Christmas Holidays and then on to work for January in San Diego. So will be on the road for a time. Living in the mobile home and the 4G network is usually my best ISP solution. There is no reason to use the VPN for the KiwiSDR access. I just happened to try it out as I was connected to it anyway, and I noticed that the location remained Phoenix while connected via the VPN. So it made me curious about how this worked. It makes sense that it would continue to report Phoenix as the IP address as I don't route Internet access through the VPN. I could but generally I don't as the VPN is used primarily for remote radio control and remote desktop back to the home QTH. So my client web browser would use the Verizon IP while the local IP 192.168.6.107 would route through the VPN. Thanks for the answer, Ron - KA7U

[jks-prv]

Okay, thanks. I think I understand now. I didn't realize you were on the road. We had a problem a week or so ago when ipinfo.io was reporting everyone was in Hong Kong for a few hours. Their database was messed up or something. So I thought this might have been a similar situation.