Opened 2 years ago

Closed 2 years ago

Last modified 12 months ago

#1016 closed defect (pending)

Location vs wifi

Reported by: robert@… Owned by: nkukich@…
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 2 years ago by llynch@…

Component: incomingnetwork
Owner: changed from llynch@… to nkukich@…
Status: newassigned
Type: requestdefect

Nick -

You might check with Jim on the recent updates here

comment:2 Changed 2 years ago by 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
>

comment:3 Changed 2 years ago 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

comment:4 Changed 2 years ago by 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
>

comment:5 Changed 2 years ago by jim@…

Resolution: pending
Status: assignedclosed

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

comment:6 Changed 12 months ago by Rick Alfvin

Milestone: ietf-96ietf-096

Milestone renamed

Note: See TracTickets for help on using tickets.