1061272 - (Nexus S) Voice registration state misses radioTech and type

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: RIL, defect)

Description

[:gerard-majax]

Attachment: logcat

While playing with FMD on my Nexus S running a master built yesterday, I got my device located near Paris while I was at home. Attached is a part of logcat I could collect at the time.

One can notice that my device was only seeing one AP, mine. I did survey over there a lot using both FxStumbler and MozStumbler. My device has working SIM attached to Free Mobile network (20815) roaming on Orange F network (20801).

The returned location matches GeoIP and makes sense regarding this sole criterion ; given that I only have one AP in sight right now, hannosch said on #geo it's normal we only use GeoIP.

What I'm wondering is why it seems the GSM network info were not used to provide a better location: I was located near Paris while I'm living near Tours, that's a 250km delta.

Comment 1

[:gerard-majax]

With:
 - Gecko git c5b55f7c492664837cba920d256e8b54cc008de2
 - Gaia git 5bbb8889656c45aeb101c13ea0f23cb685ee7ed1

Comment 2

[:garvan]

Alexandre, would it be possible to add a log line here
http://lxr.mozilla.org/mozilla-central/source/dom/system/NetworkGeolocationProvider.js#421

LOG(var) for those 3 variables, and see which is blank. Ultimately this seems like a bug in the RIL for the Nexus S and the bug should go to that team to look at. On the Flame with m-c, cell info is showing up ok in the geolocation scanning.

As we mentioned on IRC, it would be handy if there was a way to debug the cell layer in isolation.

Comment 3

[:gerard-majax]

Garvan, that was exactly I did, and I see 'type' being |null|.

Comment 4

[:gerard-majax]

> 09-03 08:19:00.242  3020  3020 I Gecko   : -*- RILContentHelper: Received message 'RIL:VoiceInfoChanged': {"clientId":0,"data":{"connected":true,"emergencyCallsOnly":false,"roaming":false,"network":{"longName":"Free","shortName":"Free","mcc":"208","mnc":"15","rilMessageClientId":0},"cell":{"gsmLocationAreaCode":3370,"gsmCellId":116654103},"type":null,"signalStrength":-85,"relSignalStrength":100,"state":"registered"}}
> 09-03 08:19:00.277  3020  3020 I Gecko   : -*- RILContentHelper: Received message 'RIL:DataInfoChanged': {"clientId":0,"data":{"connected":false,"emergencyCallsOnly":false,"roaming":false,"network":{"longName":"Free","shortName":"Free","mcc":"208","mnc":"15","rilMessageClientId":0},"cell":{"gsmLocationAreaCode":3370,"gsmCellId":116654103},"type":"hsdpa","signalStrength":-85,"relSignalStrength":100,"state":"registered"}}

I remember that in the past, the voice.type was equal to data.type.

Comment 5

[:gerard-majax]

Attachment: Use both voice or data information to find cells

In some contexts, the voice.type value may be null: this happens on the
Nexus S device for instance. Not having this value will make cell
scanning not possible, so we also make use of the data connection
information to query the cell and network type.

Comment 6

[:garvan]

The patch LGTM, but is this masking an underlying bug in the RIL?

Comment 7

[:gerard-majax]

(In reply to Garvan Keeley [:garvank] from comment #6)
> The patch LGTM, but is this masking an underlying bug in the RIL?

I had a look at the very old debug log I could find from my Nexus S, and it looks like the type has always been null for the voice. So either it's a bug that comes back from the very early days, or it's a condition we can legitimately have.

Hsi-Yi, can you assert this? Confere comment 4 and comment 5 :)

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Edgar, please help me take a look at this, thank you very much.

Comment 9

[:gerard-majax]

Bug 843452 landed and touched this very zone of the code. My fix needs to be rebased (did it locally).

Comment 10

[Edgar Chen [:edgar]]

(In reply to Alexandre LISSY :gerard-majax from comment #7)
> (In reply to Garvan Keeley [:garvank] from comment #6)
> > The patch LGTM, but is this masking an underlying bug in the RIL?
> 
> I had a look at the very old debug log I could find from my Nexus S, and it
> looks like the type has always been null for the voice. So either it's a bug
> that comes back from the very early days, or it's a condition we can
> legitimately have.
> 
> Hsi-Yi, can you assert this? Confere comment 4 and comment 5 :)

Hi Alexandre, data.type and voice.type come from different RIL parcel, they could possible have different value.
But it should not be 'null' if device is connected to a network, could you share RIL log to me? I can take a look why voice.type gets 'null' value.

Thank you.

Comment 11

[:gerard-majax]

Edgar, this is the first thing I checked on RIL side:
 - voice registration state returns a string list with only 3 components
 - data registration state returns a string list with 4 elements

So in case of the voice registration state, we don't have any indication on the radio tech. According to all the logs I have, that dates back to 2012, it has always been like this. Given we do a readStringList(), and I did not saw any error in logcat, I get this is the expected behavior for this device.

Comment 12

[Edgar Chen [:edgar]]

(In reply to Alexandre LISSY :gerard-majax from comment #11)
> Edgar, this is the first thing I checked on RIL side:
>  - voice registration state returns a string list with only 3 components
>  - data registration state returns a string list with 4 elements
> 
> So in case of the voice registration state, we don't have any indication on
> the radio tech. According to all the logs I have, that dates back to 2012,
> it has always been like this. Given we do a readStringList(), and I did not
> saw any error in logcat, I get this is the expected behavior for this device.

Thanks for these information.
If rild doesn't carry the information of radio tech in voice registration state, null is an expected value.
Then it looks like a device specific behavior.

Comment 13

[:gerard-majax]

Attachment: Copy voice registration state network type from data registration state

In some contexts, the voice.type value may be null: this happens on the
Nexus S device for instance, where the VOICE_REGISTRATION_STATE reply
from the RIL does not include any network type.

Comment 14

[:gerard-majax]

Comment on attachment 8487071 [details] [diff] [review]
Copy voice registration state network type from data registration state

Edgar, since you seems to imply that this looks like a valid edge case, I'm attaching a new fix that does the work at RIL level. It fixes the issue for MLS case, and I think it also fixed other RIL issues on Nexus S (Calls settings displays completely for example).

Comment 15

[Edgar Chen [:edgar]]

Comment on attachment 8487071 [details] [diff] [review]
Copy voice registration state network type from data registration state

Review of attachment 8487071 [details] [diff] [review]:
-----------------------------------------------------------------

The radio tech of CS (voice) and PS (data) are coming from different parcel. And some techs are only for PS, for example: gprs, hsdpa ... etc.
Copying radio tech of data to voice isn't a good idea.
IMO, if underlying layer doesn't provide enough information, we should just leave it null as we have now.
And this seems to only happen in Nexus S, probably because the ril version is too old, or the manufacturer doesn't implement it correctly. :(

Comment 16

[:gerard-majax]

Unassigning as I'm stopping dogfooding Nexus S.

Comment 17

[:gerard-majax]

Attachment: Copy voice registration state network type from data registration state

In some contexts, the voice.type value may be null: this happens on the
Nexus S device for instance, where the VOICE_REGISTRATION_STATE reply
from the RIL does not include any network type.

Comment 18

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Change the bug title to better reflect the case.

Comment 19

[BMO Automation]

Firefox OS is not being worked on