(Nexus S) Voice registration state misses radioTech and type

RESOLVED WONTFIX

Status

defect
RESOLVED WONTFIX
5 years ago
Last year

People

(Reporter: gerard-majax, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [systemsfe])

Attachments

(3 attachments, 1 obsolete attachment)

Posted file 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.
Reporter

Comment 1

5 years ago
With:
 - Gecko git c5b55f7c492664837cba920d256e8b54cc008de2
 - Gaia git 5bbb8889656c45aeb101c13ea0f23cb685ee7ed1

Comment 2

5 years ago
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.

Updated

5 years ago
Summary: Improper location returned → Cell scan problem on Nexus S
Reporter

Comment 3

5 years ago
Garvan, that was exactly I did, and I see 'type' being |null|.
Reporter

Comment 4

5 years ago
> 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.
Reporter

Updated

5 years ago
Blocks: b2g-nexuss
Reporter

Comment 5

5 years ago
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

5 years ago
The patch LGTM, but is this masking an underlying bug in the RIL?
Reporter

Comment 7

5 years ago
(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 :)
Flags: needinfo?(htsai)
Edgar, please help me take a look at this, thank you very much.
Flags: needinfo?(htsai) → needinfo?(echen)
Reporter

Comment 9

5 years ago
Bug 843452 landed and touched this very zone of the code. My fix needs to be rebased (did it locally).
(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.
Flags: needinfo?(echen) → needinfo?(lissyx+mozillians)
Reporter

Comment 11

5 years ago
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.
Flags: needinfo?(lissyx+mozillians) → needinfo?(echen)
(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.

Updated

5 years ago
Flags: needinfo?(echen)
Reporter

Comment 13

5 years ago
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.
Reporter

Updated

5 years ago
Attachment #8483299 - Attachment is obsolete: true
Reporter

Comment 14

5 years ago
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).
Attachment #8487071 - Flags: review?(echen)
Reporter

Updated

5 years ago
Summary: Cell scan problem on Nexus S → Voice registration state missed radioTech and typp
Reporter

Updated

5 years ago
Summary: Voice registration state missed radioTech and typp → Voice registration state misses radioTech and type
Reporter

Updated

5 years ago
Assignee: nobody → lissyx+mozillians
Component: Geolocation → RIL
Product: Core → Firefox OS
Version: Trunk → unspecified
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. :(
Attachment #8487071 - Flags: review?(echen) → review-
Whiteboard: [systemsfe]
Reporter

Comment 16

4 years ago
Unassigning as I'm stopping dogfooding Nexus S.
Assignee: lissyx+mozillians → nobody
Reporter

Comment 17

4 years ago
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.
Change the bug title to better reflect the case.
Summary: Voice registration state misses radioTech and type → (Nexus S) Voice registration state misses radioTech and type
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.