Location vs wifi

[robert@…]

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.

[llynch@…]

Nick -

You might check with Jim on the recent updates here

[robert@…]

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
>

[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

[robert@…]

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
>

[jim@…]

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

[Rick Alfvin]

Milestone renamed