Closed Bug 841360 Opened 11 years ago Closed 11 years ago

A-GPS does not work.

Categories

(Core :: DOM: Device Interfaces, defect)

Product:
Core
Component:
DOM: Device Interfaces
Platform:
All
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Project Flags:
blocking-b2g tef+

People

(Reporter: jaoo, Assigned: kanru)

References

Details

Attachments

(1 file)

|adb logcat| output with some traces showing the error.
5.30 KB, text/plain
Details 
A-GPS support does not work. The geolocation provider object is unable to setup data connection through the RIL. Once the AGps interface gets initialized a setup data call has to be performed by the RIL and that's not happening. It seems that the `SetupAGPS()` function doesn't get the SUPL server settings so the `SetupAGPS()` doesn't initialize the mRIL object and geolocation provider object is unable to reach the RIL for setting up the data call.
Blocks: 715788
blocking-b2g: --- → tef?
Blocks: b2g-v1-certification
No longer blocks: 715788
Necessary for certification, so blockin the meta Bug 819528
Has this been attempted with the commercial GPS provider?   SUPL has been validated already with that implementation.
I've tested with the reference implementation (even) adding the following settings to ${GAIA_HOME}/build/custom-pref.js:

pref("geo.gps.supl_server", "supl.google.com");
pref("geo.gps.supl_port", 7276);
Blocks: 715788
A-GPS has also been validated in production and testing configurations with the default implementation.  (The latter is bug 837839).  I would recommend testing with the settings enabled by DOGFOOD=1 in your build.

Distributing the test configuration to dogfooders is blocked on bug 837559.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #4)
> A-GPS has also been validated in production and testing configurations with
> the default implementation.  (The latter is bug 837839).  I would recommend
> testing with the settings enabled by DOGFOOD=1 in your build.
> 
> Distributing the test configuration to dogfooders is blocked on bug 837559.

Even adding test.supl.svc.ovi.com:7276 to ${GAIA_HOME}/build/custom-prefs.js (as  DOGFOOD=1 brakes Gaia) it doesn't work. The issue is in [1].

[1] http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/GonkGPSGeolocationProvider.cpp#555
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #6)
> Created attachment 714311 [details]
> |adb logcat| output with some traces showing the error.

Notice also this:

E/LocSvc_api_rpc_glue(  108): loc_ioctl failed select_id = 0, ioctl_type RPC_LOC_IOCTL_SET_SUPL_VERSION, returned RPC_LOC_API_RPC_FAILURE
Kan-Ru, please dupe this if required.
Assignee: nobody → kchen
blocking-b2g: tef? → tef+
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #6)
> Created attachment 714311 [details]
> |adb logcat| output with some traces showing the error.

That looks like we are unable to get the RIL object. What environment was this test performed? Does it has a working RIL implementation?
(In reply to Kan-Ru Chen [:kanru] from comment #9)
> That looks like we are unable to get the RIL object.

Yes, you're right.

> What environment was this test performed? 

Couple of them:

  - BRANCH=master VARIANT=eng
  - BRANCH=v1-train VARIANT=user

  A-GPS setting (Both environments):

    ${GAIA_HOME}/build/custom-pref.js:
      pref("geo.gps.supl_server", "test.supl.svc.ovi.com");
      pref("geo.gps.supl_port", 7276);

> Does it has a working RIL implementation?

Yes, it does.
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #10)
> (In reply to Kan-Ru Chen [:kanru] from comment #9)
> > That looks like we are unable to get the RIL object.
> 
> Yes, you're right.

Without the RIL object the A-GPS settings are irrelevant. I think this is the main issue here..
I can't reproduce the !mRIL case :/
(In reply to Kan-Ru Chen [:kanru] from comment #12)
> I can't reproduce the !mRIL case :/

That's very good somehow but not what I saw in my last test. In which test environment are you seeing that? Could you share the repos and cset/hash of gecko and gaia please?
I'm building from the b2g18 branch. https://hg.mozilla.org/releases/mozilla-b2g18/rev/e808d17a5371

gaia is 772ecdb9c5c71a1721896545a3312dff867626dc
I tested it on Unagi.
(In reply to Kan-Ru Chen [:kanru] from comment #14)
> I'm building from the b2g18 branch.
> https://hg.mozilla.org/releases/mozilla-b2g18/rev/e808d17a5371
> 
> gaia is 772ecdb9c5c71a1721896545a3312dff867626dc

Good news. I'm unable to reproduce the !mRIL issue neither with the environment detailed above. I vaguely remember seeing an issue around `GetInterfaceRequestor()` function last week. On the other hand after setting up the data connection over the A-GPS interface object (`mAGpsInterface->data_conn_open()` function) the geolocation provider receives a A-GPS callback (`AGPSStatusCallback()`) asking for releasing the A-GPS data connection. Do you why that is happening?
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #16)
> (In reply to Kan-Ru Chen [:kanru] from comment #14)
> > I'm building from the b2g18 branch.
> > https://hg.mozilla.org/releases/mozilla-b2g18/rev/e808d17a5371
> > 
> > gaia is 772ecdb9c5c71a1721896545a3312dff867626dc
> 
> Good news. I'm unable to reproduce the !mRIL issue neither with the
> environment detailed above. I vaguely remember seeing an issue around
> `GetInterfaceRequestor()` function last week. On the other hand after
> setting up the data connection over the A-GPS interface object
> (`mAGpsInterface->data_conn_open()` function) the geolocation provider
> receives a A-GPS callback (`AGPSStatusCallback()`) asking for releasing the
> A-GPS data connection. Do you why that is happening?

It will release the data connection once the required data is retrieved. That usually takes very short time.
(In reply to Kan-Ru Chen [:kanru] from comment #17)
> It will release the data connection once the required data is retrieved.
> That usually takes very short time.

Well It seems the flow I'm seeing in my test is the right one but I'm still not able to retrieve my location (for example using the `geoloc` test app). AFAIK I should be able to do it even in indoors environments but that's not happening. Could you tell us the steps to validate A-GPS please since I'm not able to figure out how the flow continues?
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #18)
> (In reply to Kan-Ru Chen [:kanru] from comment #17)
> > It will release the data connection once the required data is retrieved.
> > That usually takes very short time.
> 
> Well It seems the flow I'm seeing in my test is the right one but I'm still
> not able to retrieve my location (for example using the `geoloc` test app).
> AFAIK I should be able to do it even in indoors environments but that's not

Unfortunately it can't do it in indoors. We do not have cell id locating yet. 

> happening. Could you tell us the steps to validate A-GPS please since I'm
> not able to figure out how the flow continues?

When in outdoors, it should be able to retrieve the location in less then 1 minute, often in a few dozen seconds.

If you really want to verify the engine is connecting to the SUPL server, you could setup a proxy server (like netcat) and monitor the network traffic.
(In reply to Kan-Ru Chen [:kanru] from comment #19)
> When in outdoors, it should be able to retrieve the location in less then 1
> minute, often in a few dozen seconds.

The time-to-first-fix (TTFF) range from 2 to 4 minutes. Without A-GPS support the TTFF reaches more than 15 minutes. So it works more o less with test.supl.svc.ovi.com:7276 A-GPS settings. On the down side with agps.movistar.es:7276 A-GPS settings the TTFF is never less than than 15 minutes so I assume A-GPS doesn't work properly with those settings. The A-GPS server settings from Telefonica Spain have some details about security (TLS 1.0), certs (Verisign Class 3) and so on. Are those kind of settings supported?, I mean, the security ones.

> 
> If you really want to verify the engine is connecting to the SUPL server,
> you could setup a proxy server (like netcat) and monitor the network traffic.

Well, I assume you're testing A-GPS through WiFi. Right?
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #20)
> On the down side with
> agps.movistar.es:7276 A-GPS settings the TTFF is never less than than 15
> minutes so I assume A-GPS doesn't work properly with those settings. The
> A-GPS server settings from Telefonica Spain have some details about security
> (TLS 1.0), certs (Verisign Class 3) and so on. Are those kind of settings
> supported?, I mean, the security ones.

False alarm, sorry sorry sorry. The correct settings are agps.movistar.es:7275. With those ones the behavior is more o less the same (4min TTFF) and It seems to work. Kanru, could you double-check and validate those settings on your side please? So, since the !mRIL case is not longer happening and it seems to work should we resolve this bug?
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Opps, Don't want to resolve this bug yet. Sorry.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #21)
> (In reply to José Antonio Olivera Ortega [:jaoo] from comment #20)
> > On the down side with
> > agps.movistar.es:7276 A-GPS settings the TTFF is never less than than 15
> > minutes so I assume A-GPS doesn't work properly with those settings. The
> > A-GPS server settings from Telefonica Spain have some details about security
> > (TLS 1.0), certs (Verisign Class 3) and so on. Are those kind of settings
> > supported?, I mean, the security ones.
> 
> False alarm, sorry sorry sorry. The correct settings are
> agps.movistar.es:7275. With those ones the behavior is more o less the same
> (4min TTFF) and It seems to work. Kanru, could you double-check and validate
> those settings on your side please? So, since the !mRIL case is not longer
> happening and it seems to work should we resolve this bug?

We need an update from OEM in order to support the secure connection. Default build does not include the needed bits. So it's still false alarm I guess..
(In reply to Kan-Ru Chen [:kanru] from comment #23)
> We need an update from OEM in order to support the secure connection.
> Default build does not include the needed bits. So it's still false alarm I
> guess..

The correct setting were agps.movistar.es:7275, security (TLS 1.0) and certs (Verisign Class 3) so if secure connection is not supported yet my tests are invalid right?
If we wind up resolving this without changing any code, please use WONTFIX or WORKSFORME, not FIXED, as the status.
What's the next action here?
Flags: needinfo?(kchen)
I suggest we resolve this bug with WORKSFORME.
Flags: needinfo?(kchen)
(In reply to Kan-Ru Chen [:kanru] from comment #27)
> I suggest we resolve this bug with WORKSFORME.

I agree but we should file a follow-up bug for tracking the work to be done in order to support secure connection.
after discussing with jaoo, it sounds like there is no bug here at all.  He has verified both nokia and tef agps servers and all works.  Marking WFM
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: