Closed Bug 1061272 Opened 7 years ago Closed 3 years ago

(Nexus S) Voice registration state misses radioTech and type

Categories

(Firefox OS Graveyard :: RIL, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: gerard-majax, Unassigned)

References

Details

(Whiteboard: [systemsfe])

Attachments

(3 files, 1 obsolete file)

Attached 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.
With:
 - Gecko git c5b55f7c492664837cba920d256e8b54cc008de2
 - Gaia git 5bbb8889656c45aeb101c13ea0f23cb685ee7ed1
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.
Summary: Improper location returned → Cell scan problem on Nexus S
Garvan, that was exactly I did, and I see 'type' being |null|.
> 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.
Blocks: b2g-nexuss
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.
The patch LGTM, but is this masking an underlying bug in the RIL?
(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)
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)
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.
Flags: needinfo?(echen)
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.
Attachment #8483299 - Attachment is obsolete: true
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)
Summary: Cell scan problem on Nexus S → Voice registration state missed radioTech and typp
Summary: Voice registration state missed radioTech and typp → Voice registration state misses radioTech and type
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]
Unassigning as I'm stopping dogfooding Nexus S.
Assignee: lissyx+mozillians → nobody
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: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.