= bug description = When I go to geoip.fedoraproject.org/city most all values returned are wrong or null. Anaconda isn't able to set timezone correctly.
= bug analysis = Laptop on cable: {"country_code3": "USA", "country_code": "US", "postal_code": null, "dma_code": 0, "country_name": "United States", "metro_code": 0, "city": null, "region_name": null, "region": null, "ip": "50.183.15.223", "longitude": -97.0, "latitude": 38.0, "area_code": 0, "time_zone": null}
Cell phone on cell network returns the same information except for a different ip.
= fix recommendation = no idea
So, I pulled the newest GeoIPCityLite db and tested:
{{{ /usr/bin/geoiplookup 50.183.15.100 -f /usr/share/GeoIP/GeoLiteCity.dat GeoIP City Edition, Rev 1: US, N/A, N/A, N/A, 38.000000, -97.000000, 0, 0 }}}
So, it definitely looks like the data contains that bogus info. ;(
I submitted a correction request to maxmind. They update databases only on tuesdays, so the quickest we could expect something is next tuesday. :( Will leave this open to track progress.
My IP changed again, by provider, to 50.183.15.223 which also returns the bogus info.
Cell phone IP is 172.56.9.233, and it too returns this bogus info. So the problem may be somewhat broad.
When I go to http://www.maxmind.com/en/locate_my_ip and plug in my current ip 50.183.15.223, I get sane data: location Denver, postal code is two zip codes away, lat/long is 15 min drive away, ISP is correct, metro code is 751 (?). But still geoip.fedoraproject.org/city returns incorrect results.
Yeah, it's a different db...
"Note: These results are generated using our GeoIP2 Precision Web Services and may differ slightly from the results provided by our GeoIP Legacy databases and web services"
The 50.183.15.223 appears fixed now.
The other one doesn't seem to be yet, but we just need to wait for them to update their db. ;(
Login to comment on this ticket.