#1016 closed defect (pending)
Location vs wifi
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | tbd | Milestone: | ietf-096 |
Component: | network | Keywords: | |
Cc: | My Current Location: | ||
My MAC Address: | My OS: |
Description
Hi, Can you tell me why at each IETF wifi locations indicates previous IETF place ? In Argentina it was showing Hawaii ... here in Berlin it is showing Argentina .... On PC/MAC this is none issue but with android this is a pain as even google defaults now to Google.ar Best, R.
Change history (6)
comment:1 Changed 5 years ago by
Component: | incoming → network |
---|---|
Owner: | changed from llynch@… to nkukich@… |
Status: | new → assigned |
Type: | request → defect |
comment:2 Changed 5 years ago by
Btw. .. now in Potsdam II the wifi shows Dallas TX ... great ! On Jul 20, 2016 4:43 PM, "IETF Tickets/NOC" <tickets@meeting.ietf.org> wrote: > #1016: Location vs wifi > ---------------------------+--------------------------------- > Reporter: robert@… | Owner: nkukich@… > Type: defect | Status: assigned > Priority: tbd | Milestone: ietf-96 > Component: network | Resolution: > Keywords: | My Current Location: > My MAC Address: | My OS: > ---------------------------+--------------------------------- > Changes (by llynch@…): > > * owner: llynch@… => nkukich@… > * status: new => assigned > * component: incoming => network > * type: request => defect > > > Comment: > > Nick - > > You might check with Jim on the recent updates here > > -- > Ticket URL: <https://tickets.meeting.ietf.org/ticket/1016#comment:1> > IETF Tickets/NOC <https://tickets.meeting.ietf.org> > IETF Meeting Tickets - NOC pages >
comment:3 Changed 5 years ago by
Robert,
The short version: Geolocation of IP addresses doesn't really take networks like IETF that move around into account.
The longer story is that just for Google, there are (at least) three unrelated mechanisms they use for geolocation:
The first one is the one that sets your location for normal web properties, things like google maps, the language for google search, and (I think) rights management for Youtube. This is actually the one thing that can be controlled. Using the mechanism that Eric Kline wrote in https://tools.ietf.org/html/draft-google-self-published-geofeeds-02, we publish the IETF location using the file at http://noc.ietf.org/geo/google.csv
The second one is the mapping of which google datacenter serves a given network. When we arrived here in Berlin, we had german maps, thanks to the first mechanism, but it was all being served out of a datacenter in South America. Not optimal. It turns out that there is an "auto-rehoming" mechanism that is data driven as people use the services, but that works on the order of weeks, and would shift us long after the meeting. Luckily, we have a good relationship with Google engineers, and they worked internally to get us moved to europe.
The final one is the one you're mentioning. It maps the BSSID back to a geographic location for android. Unfortunately, we've not cracked this one yet. It's likely that you're getting different results in different rooms because the AP used in that room was last used in Dallas, while most of the other ones were used in Buenos Aires. We're working with google now to see if we can improve this, but for now it's still a problem.
I realize this doesn't help your problem, but hopefully it at least explains what's happening.
- Jim
comment:4 Changed 5 years ago by
Thank you ! On Jul 20, 2016 5:15 PM, "IETF Tickets/NOC" <tickets@meeting.ietf.org> wrote: > #1016: Location vs wifi > ---------------------------+--------------------------------- > Reporter: robert@… | Owner: nkukich@… > Type: defect | Status: assigned > Priority: tbd | Milestone: ietf-96 > Component: network | Resolution: > Keywords: | My Current Location: > My MAC Address: | My OS: > ---------------------------+--------------------------------- > > Comment (by jim@…): > > Robert, > The short version: Geolocation of IP addresses doesn't really take > networks like IETF that move around into account. > > The longer story is that just for Google, there are (at least) three > unrelated mechanisms they use for geolocation: > > The first one is the one that sets your location for normal web > properties, things like google maps, the language for google search, and > (I think) rights management for Youtube. This is actually the one thing > that can be controlled. Using the mechanism that Eric Kline wrote in > https://tools.ietf.org/html/draft-google-self-published-geofeeds-02, we > publish the IETF location using the file at > http://noc.ietf.org/geo/google.csv > > The second one is the mapping of which google datacenter serves a > given network. When we arrived here in Berlin, we had german maps, thanks > to the first mechanism, but it was all being served out of a datacenter in > South America. Not optimal. It turns out that there is an "auto-rehoming" > mechanism that is data driven as people use the services, but that works > on the order of weeks, and would shift us long after the meeting. Luckily, > we have a good relationship with Google engineers, and they worked > internally to get us moved to europe. > > The final one is the one you're mentioning. It maps the BSSID back to > a geographic location for android. Unfortunately, we've not cracked this > one yet. It's likely that you're getting different results in different > rooms because the AP used in that room was last used in Dallas, while most > of the other ones were used in Buenos Aires. We're working with google > now to see if we can improve this, but for now it's still a problem. > > I realize this doesn't help your problem, but hopefully it at least > explains what's happening. > > - Jim > > -- > Ticket URL: <https://tickets.meeting.ietf.org/ticket/1016#comment:3> > IETF Tickets/NOC <https://tickets.meeting.ietf.org> > IETF Meeting Tickets - NOC pages >
comment:5 Changed 5 years ago by
Resolution: | → pending |
---|---|
Status: | assigned → closed |
Robert,
Again, sorry about this. We're working to get it resolved. I'll resolve this ticket for now, and hopefully we can resolve the issue before the next meeting.
- Jim
Nick -
You might check with Jim on the recent updates here