1010345 - Network location providers sends wrong radio field, cell based lookups broken

Status: RESOLVED WORKSFORME

(Core :: DOM: Geolocation, defect)

Description

[Hanno Schlichting]

While reviewing the network location provider code in http://mxr.mozilla.org/mozilla-central/source/dom/system/NetworkGeolocationProvider.js, I noticed that it sends a wrong radio field, but misses the mandatory radioType field. I think this currently means that no cell-based location look-ups work (including Tarako).

For Tarako I've opened an issue on the service side, to work around this and avoid having to do code updates on the 1.3T branch (https://github.com/mozilla/ichnaea/issues/201).

But for all newer branches we should fix the issue.

A valid API call for a GSM network should have the following structure:

{
  "radioType": "gsm",
  "cellTowers": [
    "cellId": 42,
    "locationAreaCode": 415,
    "mobileCountryCode": 310,
    "mobileNetworkCode": 410
  ]
}

What we currently send is:

{
  "cellTowers": [
    "radio": "gsm",
    "cellId": 42,
    "locationAreaCode": 415,
    "mobileCountryCode": 310,
    "mobileNetworkCode": 410
  ]
}

Note the misspelled and misplaced radio vs. radioType field.

This issue is orthogonal to the UMTS/CDMA support issues which require different values in the radioType field (https://bugzilla.mozilla.org/show_bug.cgi?id=1010278 and https://bugzilla.mozilla.org/show_bug.cgi?id=1010282).

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

FYI.

Comment 2

[:garvan]

Hanno added a server-side workaround for this bug, which is for all platforms.
We have a few cleanup items next time we touch this code, this is one of them.

Comment 3

[Joe Cheng [:jcheng] (please needinfo)]

since there is a server side workaround, let's not block tarako with this and add to backlog

Comment 4

[:gerard-majax]

(In reply to Joe Cheng [:jcheng] from comment #3)
> since there is a server side workaround, let's not block tarako with this
> and add to backlog

What workaround ? I cannot get any geolocation from MLS on my Flame. I'm getting constant 400 parseError from server.

Comment 5

[:gerard-majax]

(In reply to Alexandre LISSY :gerard-majax from comment #4)
> (In reply to Joe Cheng [:jcheng] from comment #3)
> > since there is a server side workaround, let's not block tarako with this
> > and add to backlog
> 
> What workaround ? I cannot get any geolocation from MLS on my Flame. I'm
> getting constant 400 parseError from server.

According to Hanno, in my case that's because my device has two SIM cards, one on WCDMA and one on GSM.

Comment 6

[Hanno Schlichting]

Bug #1035097 describes the "multiple network types" problem and tracks possible workarounds for it.

If we want to fix this bug (send one radioType per request), we'll need to come up with some way to decide which radio type to use.

Possible solutions:
1. Only scan the currently active radio interface
2. Scan all of them, but only use the "best" radio type, so LTE > CDMA > UMTS > GSM, based on the assumption that newer network standards generally have a smaller cell radius and so we'd get a more precise result
3. Send two network requests doing a lookup for each network type, use the one with a better accuracy
4. Deviate from the Google defined protocol and extend our workaround code to permanently allow multiple network types per request

Comment 7

[:garvan]

We need to follow up on this bug when a CDMA B2G device planned for support. Or if there is, need to find out what device it is.

Comment 8

[Hanno Schlichting]

This isn't an issue anymore. The wrong spelling of radio to radioType was fixed as part of bug #1035097.

The top-level vs. per-cell radioType distinction has made it permanently into the service spec and is now supported by our own location service and by combain.com. So we've gone with solution 4 out of the ones I stated in comment 6.