Closed Bug 1156231 Opened 6 years ago Closed 6 years ago

Data registration lost issues

Categories

(Firefox OS Graveyard :: RIL, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(feature-b2g:2.5+, tracking-b2g:backlog, firefox42 fixed)

RESOLVED FIXED
FxOS-S4 (07Aug)
feature-b2g 2.5+
tracking-b2g backlog
Tracking Status
firefox42 --- fixed

People

(Reporter: jessica, Assigned: jessica)

References

Details

Attachments

(1 file, 2 obsolete files)

We have been receiving complains about data call drops or not able to recover after wifi. It is not reproducible everywhere, but from the logs, I can see that data registration becomes unregistered, so data call is not possible at this state. 

Currently, we are stuck, we really don't know what to do without partner's help. If you could please help us on thiese questions...

1. Is there some kind of power saving mode in the modem so that data registration gets unregistered automatically in some cases?

2. If we notice voice registration and data registration not consistent, e.g. voice registration _registered_ and data registration _unregistered_, how do recover from this state? is there a ril request we can use to force modem reattach data registration?

3. I know this is kind of vague, but could it be something we are not sending to modem or we are doing wrong, so that data registration gets unregistered automatically?
One thing to note, from bug 1137764 comment 38, it is reproducible with the whole base image with caf-ril. Bug 1138954 can reproduce the issue with Z3 compact with MozRil, but not in Android.
Anshul, could you please please shed some light here? Please refer to comment 0, thanks.
Flags: needinfo?(anshulj)
[Tracking Requested - why for this release]:
(In reply to Jessica Jong [:jjong] [:jessica] from comment #0)
> We have been receiving complains about data call drops or not able to
> recover after wifi. It is not reproducible everywhere, but from the logs, I
> can see that data registration becomes unregistered, so data call is not
> possible at this state. 
> 
> Currently, we are stuck, we really don't know what to do without partner's
> help. If you could please help us on thiese questions...
> 
> 1. Is there some kind of power saving mode in the modem so that data
> registration gets unregistered automatically in some cases?
None that I know of and I can't reproduce this issue locally.
> 2. If we notice voice registration and data registration not consistent,
> e.g. voice registration _registered_ and data registration _unregistered_,
> how do recover from this state? is there a ril request we can use to force
> modem reattach data registration?
No there isn't.
> 3. I know this is kind of vague, but could it be something we are not
> sending to modem or we are doing wrong, so that data registration gets
> unregistered automatically?
I am really not sure what's going on your network. I have tried this scenario specifically and I can't reproduce the issue.
Flags: needinfo?(anshulj)
It's clearly not reproducible everywhere.

For example for me it happens when I leave home (after a night being connected to WiFi) but not when I leave work (after a day being connected to WiFi).

I'd even say it happens to me every day (see bug 1137764).

Anshul, can you give us a way to diagnosticate a little more?
Flags: needinfo?(anshulj)
FTR from Bug 1137764, we think this happens both with QC RIL and MozRIL.
Since there is no specific ril request for re-attaching network, we use get/set preferred network type as a way to re-attach network.

---

Julien, this is an experimental patch for data registration recovery, I haven't tested on real network, so I am not sure if it works correctly. Could you help apply this patch on gecko and see if it can solve bug 1137764?

Please note that is a very draft patch, it may affect your voice call or sms, so don't use it for daily use. I just want to see if it can recover data registration properly, and please help collect ril logs to know whether it went right or wrong.

Thanks a lot!
Flags: needinfo?(felash)
Flags: needinfo?(anshulj)
I commented in bug 1137764; in short, it worked for my issue \o/.

To be sure I'll try once again tomorrow but I'm now hopeful !
Flags: needinfo?(felash)
Depends on: 1162426
For our workaround for re-registering data registration, we need to detach all registration first, including voice registration, so we need to make sure:
- there is no voice call going on, and we'll detach once voice call is ended
- for sms, we rely on the retry mechanism

Another question is, how much times are we going to try to re-register? I say, maybe try 3 times and give up if there is still no data registration when voice registration is registered.

Any suggestions are welcome!
Depends on: 1152730
What are the cases where trying to do it once is not enough?
(In reply to Julien Wajsberg [:julienw] from comment #10)
> What are the cases where trying to do it once is not enough?

Hmm, good question. I just though we could try a few times if we can't get data registration back, we could add some delay on each retry, so if the user moves from one area to another, there may be more chance to get the registration back.
When the user moves from one area to another, I think the usual way will work. When I don't have the specific issue it works usually fine.

Here it's really a workaround because we have an underlying issue.
(In reply to Julien Wajsberg [:julienw] from comment #12)
> When the user moves from one area to another, I think the usual way will
> work. When I don't have the specific issue it works usually fine.
> 
> Here it's really a workaround because we have an underlying issue.

When this issue happens, we can not predict whether the usual way will work or not.
Hmm, are you suggesting not to retry and rely on the usual way to work?
Yes :)

Tell me if this makes sense, maybe I'm wrong here !
This would be a nice improvement. Nominate as feature-b2g:2.5?
feature-b2g: --- → 2.5?
(In reply to Julien Wajsberg [:julienw] from comment #14)
> Yes :)
> 
> Tell me if this makes sense, maybe I'm wrong here !

Yeah, we expect it to act normal after the re-registration. We will try the 'no-retry' first and see how it goes. :)
Just a note that I don't have the issue on Aries.
(In reply to Julien Wajsberg [:julienw] from comment #17)
> Just a note that I don't have the issue on Aries.

And I do on the same device :)
Yep but we didn't have the same issue on Flame either.
It seems that users still a have chance to meet this condition, so we'll move forward with this and see if it enhances user experience. :)
Attached patch proposed patch. (obsolete) — Splinter Review
Hsinyi, may I have your feedback on this? Thanks.
Attachment #8597930 - Attachment is obsolete: true
Attachment #8639196 - Flags: feedback?(htsai)
Comment on attachment 8639196 [details] [diff] [review]
proposed patch.

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

Let's give it a try.

::: dom/mobileconnection/gonk/MobileConnectionService.js
@@ +791,5 @@
> +   * previous preferred network type. This is will cause deregistration and
> +   * registration on both voice and data networks.
> +   */
> +  _recoverDataRegistration: function() {
> +    this._debug("Trying to recover data registration...");

if (DEBUG) ...

@@ +796,5 @@
> +
> +    let currentPreferredNetworkType;
> +
> +    let resetPreferredNetworkType = () => {
> +      this.setPreferredNetworkType(currentPreferredNetworkType, {

To have a precise callback type defined in nsIMobileConnection, please add
QueryInterface: XPCOMUtils.generateQI([Ci.nsIMobileConnectionCallback])

@@ +804,5 @@
> +    };
> +
> +    let setTemporaryPreferredNetworkType = () => {
> +      this.setPreferredNetworkType(
> +        Ci.nsIMobileConnection.PREFERRED_NETWORK_TYPE_WCDMA_GSM_CDMA_EVDO, {

ditto.

@@ +810,5 @@
> +          notifyError: aErrorMsg => resetPreferredNetworkType()
> +      });
> +    };
> +
> +    this.getPreferredNetworkType({

ditto.
Attachment #8639196 - Flags: feedback?(htsai) → feedback+
Attached patch patch, v1.Splinter Review
Hsinyi, I've addressed your review comment 22. Mind reviewing again? Thanks.

I've tested on emulator to see if unregistering data will trigger recovery (get/set preferred network type) as expected. I've also tested on Flame to verify that this does not affect normal scenarios.
Attachment #8639196 - Attachment is obsolete: true
Attachment #8641517 - Flags: review?(htsai)
Comment on attachment 8641517 [details] [diff] [review]
patch, v1.

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

Ship it!
Attachment #8641517 - Flags: review?(htsai) → review+
feature-b2g:2.5+ as this is within a 2.5 user story "As a user, I want to have a robust control in data connection."
feature-b2g: 2.5? → 2.5+
Assignee: nobody → jjong
https://hg.mozilla.org/mozilla-central/rev/fdbf6184df4e
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → FxOS-S4 (07Aug)
Duplicate of this bug: 869631
You need to log in before you can comment on or make changes to this bug.