While mobile devices (especially those with a GPS) have made people more aware of geolocation/geotagging, you don’t need a GPS in a device to make it location-aware, nor do you need to resort to IP-based reverse lookups. Location information can be made available on any network that has a DHCP server using the Location Configuration Information DHCP Option defined in RFC 3825 and RFC 6225. It makes sense: for most wired or wireless networks, the engineer responsible for setting up the DHCP server will know at the least where the server or AP is located, and maybe even static information about the locations of each terminal of a wired port.
The Option has a somewhat unorthodox binary format with non-power-of-2-width fixed point reals. To make generating the DHCP configuration statements easier, I developed a web-based RFC 6225 location configuration generation tool. It’s all client-side and even has a Google Maps preview of the location!
Copy the configuration to your local DHCP server, grab an appropriate geolocation library, and you’re ready to go! The tool generates a DHCP LCI Option for both dnsmasq and ISC’s dhcpd.
The lack of fixed point integers in Javascript made the implementation a little trickier than it would have been in, say, C.
Other lessons: Google Maps is not highly accurate.
Update 2019-06-01: updated the tool from RFC 3825 to support RFC 6225 and the GeoLoc option.
Update 2023-04-24: fixed a bug with the dhcpd/dnsmasq config lines missing the leading payload bytes (that existed since 2019 :( )
Nifty; I’ve set this on the UCC’s DHCP server.
One possible upgrade for your tool is DMS mode – our survey-grade data is in degrees/minutes/seconds/fractions of a second, rather than in decimal degrees, and I couldn’t find an online tool that actually worked to generate the conversion.
Good to hear :)
I’ve updated the tool to parse DMS notation like: 115 48′ 58.02″ (and some intuitive variants)… Now to start hacking CoreLocation to use the DHCP info instead of relying on Skyhook.
thanks for this!
it looks like the configuration lines in the output might be missing the first two bytes of the option data. for rfc-6225, the option data for option 123 is 16 bytes, but only 14 bytes are given for the configuration lines. for the default parameters, the site produces “dhcp-option=123,cb:…”, but the hex output shown above this option suggests the first byte after the option value and length to be 0x4c. i think this is probably an error with this line: const geoConfData = geoConfBuffer.toHex(2, true).substr(6), which should either skip the first two bytes in the toHex, or the first 6 bytes in the colon separated ascii encoded hex output, but not both. thanks for making this.
Thanks, eric. Fixed!