Apple Geolocation contact?
Hi All, I have a laboratory in my department which thinks it's in central Russia when using Apple Maps on macOS and iOS devices. (I've also seen it in Google Maps on macOS, which I assume is GMaps getting its location from the OS). The lab has also reported Bhutan, Malta, and the equally exotic Ohio. This room is a shielded from GPS and cellular signals, but may pick up neighboring Access Points. Step outside of that specific room and you're back in Colorado. Phones and laptops keep setting their timezone wildly wrong and we're having graduate students and faculty missing classes/meetings. I've tried swapping out the Access Point in the lab. I've tried dropping a pin in Apple Maps and reporting the location as incorrect, repeatedly and with separate devices. I started looking at geolocatemuch, but I'm not sure that's the problem in this instance. The NAT IP we come from shows proper location in infosniper. I'd love to chat with an Apple person about how to solve it. Wish I could get frequent flyer miles for this... Thanks, J.R. Raith _________________________________________________ Network Administration & Desktop Support JILA Computing - University of Colorado, Boulder
On 8/28/24 19:40, J.R. Raith wrote:
Phones and laptops keep setting their timezone wildly wrong and we're having graduate students and faculty missing classes/meetings.
Not that I'd trust MacOS or especially iOS to honor it in all circumstances, but I assume you're sending the timezone option via your DHCP servers? -- Brandon Martin
Thanks for mentioning that -- we weren't, but are now. My test Mac still thinks we're in a different timezone though. The journey continues... Thanks again! J.R. ________________________________________________ Network Administration & Desktop Support JILA Computing - University of Colorado, Boulder On 2024-08-29 13:12, Brandon Martin wrote:
On 8/28/24 19:40, J.R. Raith wrote:
Phones and laptops keep setting their timezone wildly wrong and we're having graduate students and faculty missing classes/meetings.
Not that I'd trust MacOS or especially iOS to honor it in all circumstances, but I assume you're sending the timezone option via your DHCP servers?
-- Brandon Martin
Greetings from up the mountain (Lee Hill), I've been fighting a similar issue. I'd like to throw in, a lot of mobile devices are geolocation dependent for time, and may completely disregard DHCP timezone and instead rely entirely on GeoLocation *even if it is woefully inaccurate, or unobtainable*. The room being shielded from cellular and GPS, I would imagine removes the primary mechanism most devices use to locate themselves. In those cases, most devices won't fail back to normal timesetting standard practices, but instead just 'send it' and set the time to some obscure default based on zeroed location or hardcoded internals. Our issue at our house has been a total lack of cellular coverage and odd dynamics of GPS in a forest/valley leading to our mobiles falling back to obscure manufacturer default timezones when they reboot up here. If my cell phone goes dead, it will ignore the internal RTC on power up, and briefly show 00:00 before syncing with a timeserver and settings it's timezone to EST, regardless of what it was set to before or what DHCP says is correct. It's a real shame given our proximity to the NIST office. There are some really bright time folks over there, it might be worth your time to reach out to someone there. Surely someone at CU will know the right person :) Thanks, Riley C. O'Connor ColoradoColo - AS17139 307.438.9253 - m32@cubit.sh On Wednesday, August 28th, 2024 at 5:40 PM, J.R. Raith <raithjr@jila.colorado.edu> wrote:
Hi All,
I have a laboratory in my department which thinks it's in central Russia when using Apple Maps on macOS and iOS devices. (I've also seen it in Google Maps on macOS, which I assume is GMaps getting its location from the OS). The lab has also reported Bhutan, Malta, and the equally exotic Ohio. This room is a shielded from GPS and cellular signals, but may pick up neighboring Access Points. Step outside of that specific room and you're back in Colorado.
Phones and laptops keep setting their timezone wildly wrong and we're having graduate students and faculty missing classes/meetings.
I've tried swapping out the Access Point in the lab. I've tried dropping a pin in Apple Maps and reporting the location as incorrect, repeatedly and with separate devices.
I started looking at geolocatemuch, but I'm not sure that's the problem in this instance. The NAT IP we come from shows proper location in infosniper.
I'd love to chat with an Apple person about how to solve it.
Wish I could get frequent flyer miles for this...
Thanks, J.R. Raith _________________________________________________ Network Administration & Desktop Support JILA Computing - University of Colorado, Boulder
On 8/29/24 19:31, Riley O via NANOG wrote:
I've been fighting a similar issue. I'd like to throw in, a lot of mobile devices are geolocation dependent for time, and may completely disregard DHCP timezone and instead rely entirely on GeoLocation*even if it is woefully inaccurate, or unobtainable*.
Do we (operators of all sorts) know why they (big-buy mobile device manufacturers) do this? We know how unreliable network-based geolocation can be especially when there's a lack of network access. Presumably they are aware of this issue, too, and it seems glaringly obvious in the case where there's lack of the major network-based indicators they prefer to use (GPS, cellular, etc.). Worse, they seem to have made it difficult or impossible for us to do anything about it when it breaks despite effectively relying on our industry to make it work in the first place. Defaulting to nonsensical timezones (UTC, whatever country in Asia did the firmware, etc.) seems like the worst possible outcome in most cases. Just keeping the old timezone and using the (however inaccurate) onboard RTC seems like a far better situation in absence of all usable data. I'd also be inclined to trust the DHCP-provided timezone if I had no way to other way verify it it, and if you have enough network access to get that, you probably have access to NTP to get good universal civil time as well. I'm sure the high-level application has no notion of "my time is probably bogus" given that even most mainstream OSes don't handle it well at that level of the software stack, but they seem to have chosen the worst possible way to handle that at the lower levels. FWIW, my desk IP phone (which is like 15-20 years old) picks up the timezone from DHCP and time from (S)NTP exactly how you'd want it to. I think it was even the default setting, but it has readily-accessible knobs to configure that behavior if it's doing the wrong thing. -- Brandon Martin
I've been fighting a similar issue. I'd like to throw in, a lot of mobile devices are geolocation dependent for time, and may completely disregard DHCP timezone and instead rely entirely on GeoLocation *even if it is woefully inaccurate, or unobtainable*.
1. RFC4833 *presumes* that the DHCP server KNOWS where the client IS to begin with. 2. RFC4833 provides no mechanisms for the client to validate that the time information sent to it is valid for its current location, or hasn't been tampered with. This is a pretty simple chicken / egg problem. If you need to know where the client is to give it the right time zone, by definition something has to know where the client is, so why not just use THAT for your location? It's also massively insecure , especially these days, to just trust that whatever TZ you got sent in DHCP is correct and wasn't manipulated or spoofed. Using that as an indicator for *location* is ..... yeah.... On Thu, Aug 29, 2024 at 7:32 PM Riley O via NANOG <nanog@nanog.org> wrote:
Greetings from up the mountain (Lee Hill),
I've been fighting a similar issue. I'd like to throw in, a lot of mobile devices are geolocation dependent for time, and may completely disregard DHCP timezone and instead rely entirely on GeoLocation *even if it is woefully inaccurate, or unobtainable*.
The room being shielded from cellular and GPS, I would imagine removes the primary mechanism most devices use to locate themselves. In those cases, most devices won't fail back to normal timesetting standard practices, but instead just 'send it' and set the time to some obscure default based on zeroed location or hardcoded internals.
Our issue at our house has been a total lack of cellular coverage and odd dynamics of GPS in a forest/valley leading to our mobiles falling back to obscure manufacturer default timezones when they reboot up here. If my cell phone goes dead, it will ignore the internal RTC on power up, and briefly show 00:00 before syncing with a timeserver and settings it's timezone to EST, regardless of what it was set to before or what DHCP says is correct.
It's a real shame given our proximity to the NIST office. There are some really bright time folks over there, it might be worth your time to reach out to someone there. Surely someone at CU will know the right person :)
Thanks, Riley C. O'Connor ColoradoColo - AS17139 307.438.9253 - m32@cubit.sh
On Wednesday, August 28th, 2024 at 5:40 PM, J.R. Raith < raithjr@jila.colorado.edu> wrote:
Hi All,
I have a laboratory in my department which thinks it's in central Russia when using Apple Maps on macOS and iOS devices. (I've also seen it in Google Maps on macOS, which I assume is GMaps getting its location from the OS). The lab has also reported Bhutan, Malta, and the equally exotic Ohio. This room is a shielded from GPS and cellular signals, but may pick up neighboring Access Points. Step outside of that specific room and you're back in Colorado.
Phones and laptops keep setting their timezone wildly wrong and we're having graduate students and faculty missing classes/meetings.
I've tried swapping out the Access Point in the lab. I've tried dropping a pin in Apple Maps and reporting the location as incorrect, repeatedly and with separate devices.
I started looking at geolocatemuch, but I'm not sure that's the problem in this instance. The NAT IP we come from shows proper location in infosniper.
I'd love to chat with an Apple person about how to solve it.
Wish I could get frequent flyer miles for this...
Thanks, J.R. Raith _________________________________________________ Network Administration & Desktop Support JILA Computing - University of Colorado, Boulder
participants (4)
-
Brandon Martin -
J.R. Raith -
Riley O -
Tom Beecher