1138954 - Data connection stops working after a couple of minutes/hours

Status: RESOLVED INVALID

(Firefox OS Graveyard :: RIL, defect)

Description

[:gerard-majax]

This is something new, it was not there a couple of days ago. I would say it may have started with a Gecko from sunday evening.

STR:
 0. Boot
 1. Enable data or keep it disabled

Expected:
 After some time, you should still have a valid data connection icon in the tray

Actual:
 After some time, the data connection icon in the tray gets replaces with the "<>" symbol, meaning "no data connection available"

I have no specific log. As far as I can say, data connection effectively drops. I'm trying to collect more logs on this issue.

Comment 1

[:gerard-majax]

Attachment: dev-log-main.log

This log was captured when the issue got reproduced.

Comment 2

[:gerard-majax]

Turning on/off airplane mode gets data to work again, until the next failure. Forcing network type from auto to something else do not helps.

Comment 3

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

Hello Jessica, could you please help this? If you need a shinano device, come by my desk :)

Comment 4

[Jessica Jong [:jessica] (inactive)]

From the logs, I see that data registration turned to 'searching':

> 03-03 16:38:53.563   293   293 I Gecko   : -*- RadioInterface[0]: Received message from worker: {"rilMessageType":"networkinfochanged","rilMessageClientId":0,"voiceRegistrationState":{"regState":1,"state":"registered","connected":true,"roaming":false,"emergencyCallsOnly":false,"cell":{"gsmLocationAreaCode":20101,"gsmCellId":33443879},"radioTech":3,"type":"umts","rilMessageType":"voiceregistrationstatechange"},"dataRegistrationState":{"regState":2,"state":"searching","connected":false,"roaming":false,"emergencyCallsOnly":true,"cell":{"gsmLocationAreaCode":-1,"gsmCellId":-1},"radioTech":0,"type":null,"rilMessageType":"dataregistrationstatechange"},"signal":{"voice":{"signalStrength":-87,"relSignalStrength":92},"data":{"signalStrength":-87,"relSignalStrength":92},"rilMessageType":"signalstrengthchange"}}

then data connection got disconnected unexpectedly:

> 03-03 16:38:53.643   293   293 I Gecko   : -*- RadioInterface[0]: Received message from worker: {"status":65535,"suggestedRetryTime":-1,"cid":"0","active":0,"type":"IP","ifname":"rmnet0","addresses":["100.119.127.66/30"],"dnses":["62.201.129.203","62.201.129.204"],"gateways":["100.119.127.65"],"state":3,"radioTech":14,"apn":"mmsbouygtel.com","chappap":3,"pdptype":"IP","rilMessageType":"datacallstatechange","rilMessageClientId":0}

I'll see it if I can reproduce it here.
Alexandre, do you find this very often?

Comment 5

[:gerard-majax]

Yes. Every 20-30min

Comment 6

[:gerard-majax]

And it's 100% sure this is a recent regression. I hope it's not related to my SIM card/account, though, but I only have one nano SIM :)

Comment 7

[:gerard-majax]

Ok, maybe it's my fault. I have put some more money on this account, and since then, it's still up.

Comment 8

[:gerard-majax]

I don't have anymore the issue now :(

Comment 9

[Jessica Jong [:jessica] (inactive)]

Thanks for the update. I left shinano overnight, and data was still there in the morning. :)

Comment 10

[:gerard-majax]

I'm re-opening because I saw it on other devices and with other SIM cards. We get reports from french community on recent nightlies (1-2 weeks old I'd say) too on Open C.

Comment 11

[:gerard-majax]

Reproduced twice on Shinano and Aries, with uptodate builds. Device left on my desk during the night. When looking at the data connection indicator in the notification tray, the next morning, it's "<>" instead of "3G/H/4G".

Comment 12

[:gerard-majax]

Orange F and Free Mobile SIM cards.

Comment 13

[:gerard-majax]

User reports for Open C https://bugzilla.frenchmozilla.org/show_bug.cgi?id=620
Builds are impacted since 2.0, but maybe just since a couple of weeks.

Comment 14

[Jessica Jong [:jessica] (inactive)]

If you see a "<>" in the notification tray, means that data registration is not registered, so data connection is not possible. I have seen other bugs with the same symptoms, data registration just gets disconnected after a while, but we haven't been able to reproduce it here in Taipei. I think we need modem/partner's help to check this. 

Wesley, do you know how can we ask for partner's help?

Comment 15

[:gerard-majax]

Happened again during the night on my Free Mobile SIM card with my Z3 Compact.

Comment 16

[:gerard-majax]

Happened again a couple of times.

Comment 17

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Per comment 14 and below two relevant bugs, the data registration disconnects at some points unexpectedly.

https://bugzilla.mozilla.org/show_bug.cgi?id=1131896#c5
https://bugzilla.mozilla.org/show_bug.cgi?id=1137764#c26

NI to Anshul maybe he has some inputs.

Comment 18

[Anshul]

Wesley, let me try this on our end and let you know the result.

Comment 19

[:gerard-majax]

I'm not sure if there's a link, but it would look like in the previous days:
 - data connection stopped dropping
 - at the same time, it looks like LTE is working again

Comment 20

[Anshul]

I don't see the issue on my end. Data call stayed up all night.

Comment 21

[Jessica Jong [:jessica] (inactive)]

(In reply to Alexandre LISSY :gerard-majax from comment #19)
> I'm not sure if there's a link, but it would look like in the previous days:
>  - data connection stopped dropping
>  - at the same time, it looks like LTE is working again

I don't see how it is related, but if it's like this, then it may be a network issue.

Comment 22

[:gerard-majax]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #21)
> (In reply to Alexandre LISSY :gerard-majax from comment #19)
> > I'm not sure if there's a link, but it would look like in the previous days:
> >  - data connection stopped dropping
> >  - at the same time, it looks like LTE is working again
> 
> I don't see how it is related, but if it's like this, then it may be a
> network issue.

Yeah, a network issue with different carriers and devices ?

Comment 23

[GuidoZ]

Hi,
I had the same problem. After a couple of minutes or hours, my phone (geeksphone revolution & B2G 2.0.0.0) turned into airplane mode without a corresponding selection in the settings menu. After select and deselect the airplane mode (then the message "no SIM card" in notification tray are showed) the telephone, SMS and data connections working well.

Then I deselect in the settings menue -> "Cellular & Data" -> "Network operator" the "Automatic selection". Now after 24 hours my phone working stable. (But after rebooting the phone, the "automatic selection" is selected again).

I suppose, this problem caused by the behaviour, to automatic select a best network quality. So if your network quality went bad or you change the cell, the phone trying to connect another network. If you have not permissions, the network operator kicking you out of the net. The phone "thinks" you are in  airplane mode.

Comment 24

[:gerard-majax]

I have spotted this yesterday on a Flame running v2.1 uptodate.

Comment 25

[Jessica Jong [:jessica] (inactive)]

I am not sure if what GuidoZ saw is the same issue, as he mentioned he noticed "airplane mode" turning on. But in our case, it is only data connection that does not work.

As I said, from gecko ril's point of view, we just notice data registration getting lost, for us, it is a network issue, and data connection is not possible in this state. Unfortunately, there is not much we can do without modem/partner's help.

One more thing to confirm, Lissy, have you ever changed the network selection mode manually? It might affect your data registration state...

Comment 26

[:gerard-majax]

(In reply to Jessica Jong [:jjong] [:jessica] (OOO 4/3~4/10) from comment #25)
> I am not sure if what GuidoZ saw is the same issue, as he mentioned he
> noticed "airplane mode" turning on. But in our case, it is only data
> connection that does not work.
> 
> As I said, from gecko ril's point of view, we just notice data registration
> getting lost, for us, it is a network issue, and data connection is not
> possible in this state. Unfortunately, there is not much we can do without
> modem/partner's help.

Please, we have reports on several devices, multiple branches and different networks.
I don't remember seeing this before 2.1. 

> 
> One more thing to confirm, Lissy, have you ever changed the network
> selection mode manually? It might affect your data registration state...

As far as I can tell, all the devices I reproduced on were in Automatic mode, and I may have flipped sometimes but I always switch it back to automatic.

At least, this is what is reflected in the Settings app UI ...

Comment 27

[:gerard-majax]

It's setup on « Automatic (LTE/WCDMA/GSM) », and I've reproduced the issue once again (uptodate Gecko/Gaia, Z3 Compact).

An Airplane mode on/off later, it's back and data works again. I've also noticed that registering on the roaming network (Free Mobile is - national - roaming against Orange F where I am) takes much time than compared to Android, with the same carrier and the same device. Not sure if it's part of the issue ...

Comment 28

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

Thanks Jessica and Alexandre for all the debugging and reporting. Let me summarize what's going on so far and the ideas on mind.

According to the log, it's believed that the data connection stops due to the data registration lost, which is notified by rild/modem. And I won't be surprised at this outcome, I mean if there's no data registration, there's no data connection. However, we have no idea about the reason of data registration lost; the question will not be answered without vendor support to check the modem part.

Even though, I think we could try to figure out (and Jessica has already being doing) any potential way to recovering data registration in this case, since Alenxandre mentioned that the data connection stop isn't seen on z3 android, which uses the same vendor ril blobs with z3 fxos.

Jessica and I reviewed the AOSP code and mozril code again to understand how we could improve the recovery mechanism when data registration become disconnected. So far, we have not seen obvious differences in two implementations; also, in the original AOSP ril.h, we couldn't see an explicit ril request that is aiming for asking modem to re-trigger data registration. We are trying to reach partners to get some help there, and to see if customized request is needed (though I believe it's highly likely). Another step we are going to take is to study shinano android code; hopefully we could find some clues. Jessica filed bug 1156321 specifically for the data registration recovery. Let's move 'data registration loss' solution discussion there.

Please provide us more logs if another symptom, rather than registration problem, is seen along with data connection stopping. Thank you all.

Comment 29

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

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #28)
> Thanks Jessica and Alexandre for all the debugging and reporting. Let me
> summarize what's going on so far and the ideas on mind.
> 
> According to the log, it's believed that the data connection stops due to
> the data registration lost, which is notified by rild/modem. And I won't be
> surprised at this outcome, I mean if there's no data registration, there's
> no data connection. However, we have no idea about the reason of data
> registration lost; the question will not be answered without vendor support
> to check the modem part.
> 
> Even though, I think we could try to figure out (and Jessica has already
> being doing) any potential way to recovering data registration in this case,
> since Alenxandre mentioned that the data connection stop isn't seen on z3
> android, which uses the same vendor ril blobs with z3 fxos.
> 
> Jessica and I reviewed the AOSP code and mozril code again to understand how
> we could improve the recovery mechanism when data registration become
> disconnected. So far, we have not seen obvious differences in two
> implementations; also, in the original AOSP ril.h, we couldn't see an
> explicit ril request that is aiming for asking modem to re-trigger data
> registration. We are trying to reach partners to get some help there, and to
> see if customized request is needed (though I believe it's highly likely).
> Another step we are going to take is to study shinano android code;
> hopefully we could find some clues.

Correct the bug number:

Jessica filed bug 1156231 specifically for the data registration recovery. Let's move 'data registration loss' solution discussion there.

b.t.w. this issue doesn't look a regression to me based on all the comments. I am going to clear the keyword. If you don't agree, it's much help to provide a regression window, in case we move toward a wrong direction. Thanks.

Comment 30

[:gerard-majax]

I'm starting to wonder if there is not a link between all those issues. Just a few notes from an observation today that matches what I have been seeing for months, on several devices:
 - I'm browsing the Web on my B2G device, over Wi-Fi
 - Following a link, I suddenly get a "no network" error
 - Wi-Fi connection just dropped

Now, I noticed something which I did not paid attention to before
 - Data registration was also dropped right at the same moment
 - I was not connected to data, only wifi, but the icon in the status tray changed to "<>" from "H"
 - I was not moving when both those events happened
 - A few seconds/minutes ago, without any more either, data was showing "H"

Comment 31

[Jessica Jong [:jessica] (inactive)]

(In reply to Alexandre LISSY :gerard-majax from comment #30)
> I'm starting to wonder if there is not a link between all those issues. Just
> a few notes from an observation today that matches what I have been seeing
> for months, on several devices:
>  - I'm browsing the Web on my B2G device, over Wi-Fi
>  - Following a link, I suddenly get a "no network" error
>  - Wi-Fi connection just dropped
> 
> Now, I noticed something which I did not paid attention to before
>  - Data registration was also dropped right at the same moment
>  - I was not connected to data, only wifi, but the icon in the status tray
> changed to "<>" from "H"
>  - I was not moving when both those events happened
>  - A few seconds/minutes ago, without any more either, data was showing "H"

So, your concern is that when wifi is dropped, data registration is detached at the same moment, and you'd like to know if they are related? Well, we need logs with wifi and ril log enabled to know whether they are related.
But it seems to me that this is not really related to this bug... This bug is about data connection not working after some period of time, but in comment 30, your data connection was not enabled at all, is that correct?

Comment 32

[:gerard-majax]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #31)
> (In reply to Alexandre LISSY :gerard-majax from comment #30)
> > I'm starting to wonder if there is not a link between all those issues. Just
> > a few notes from an observation today that matches what I have been seeing
> > for months, on several devices:
> >  - I'm browsing the Web on my B2G device, over Wi-Fi
> >  - Following a link, I suddenly get a "no network" error
> >  - Wi-Fi connection just dropped
> > 
> > Now, I noticed something which I did not paid attention to before
> >  - Data registration was also dropped right at the same moment
> >  - I was not connected to data, only wifi, but the icon in the status tray
> > changed to "<>" from "H"
> >  - I was not moving when both those events happened
> >  - A few seconds/minutes ago, without any more either, data was showing "H"
> 
> So, your concern is that when wifi is dropped, data registration is detached
> at the same moment, and you'd like to know if they are related? Well, we
> need logs with wifi and ril log enabled to know whether they are related.
> But it seems to me that this is not really related to this bug... This bug
> is about data connection not working after some period of time, but in
> comment 30, your data connection was not enabled at all, is that correct?

No no and no. Since the beginning of this bug I have been stating that the symptom of "data connection drop" is inferred from the data connection status visible in the utility tray.

And my comment was about the inverse effect: data connection drop would, for some unexplained reason, make wifi enabled setting to turn off. And no, I don't have logs: the issue is rare for now, so it means I would have to live for days with this.

And again, I am not saying this *is* related. I just noticed that there is a correlation of those events and I'm wondering *if* it would be related. Given I'm not the only one seeing this spurious behavior, I thought it would be worthwhile to share and also to keep you informed.

Comment 33

[Jessica Jong [:jessica] (inactive)]

(In reply to Alexandre LISSY :gerard-majax from comment #32)
> (In reply to Jessica Jong [:jjong] [:jessica] from comment #31)
> > (In reply to Alexandre LISSY :gerard-majax from comment #30)
> > > I'm starting to wonder if there is not a link between all those issues. Just
> > > a few notes from an observation today that matches what I have been seeing
> > > for months, on several devices:
> > >  - I'm browsing the Web on my B2G device, over Wi-Fi
> > >  - Following a link, I suddenly get a "no network" error
> > >  - Wi-Fi connection just dropped
> > > 
> > > Now, I noticed something which I did not paid attention to before
> > >  - Data registration was also dropped right at the same moment
> > >  - I was not connected to data, only wifi, but the icon in the status tray
> > > changed to "<>" from "H"
> > >  - I was not moving when both those events happened
> > >  - A few seconds/minutes ago, without any more either, data was showing "H"
> > 
> > So, your concern is that when wifi is dropped, data registration is detached
> > at the same moment, and you'd like to know if they are related? Well, we
> > need logs with wifi and ril log enabled to know whether they are related.
> > But it seems to me that this is not really related to this bug... This bug
> > is about data connection not working after some period of time, but in
> > comment 30, your data connection was not enabled at all, is that correct?
> 
> No no and no. Since the beginning of this bug I have been stating that the
> symptom of "data connection drop" is inferred from the data connection
> status visible in the utility tray.
> 
> And my comment was about the inverse effect: data connection drop would, for
> some unexplained reason, make wifi enabled setting to turn off. And no, I
> don't have logs: the issue is rare for now, so it means I would have to live
> for days with this.
> 
> And again, I am not saying this *is* related. I just noticed that there is a
> correlation of those events and I'm wondering *if* it would be related.
> Given I'm not the only one seeing this spurious behavior, I thought it would
> be worthwhile to share and also to keep you informed.

I see, thanks for your feedback, we'll keep this in mind while debugging this kind of issues.

Comment 34

[:gerard-majax]

And new data: yesterday, I saw WiFi dropping while data was ok. So that was just a coincidence after all.

Comment 35

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

Thanks for the information. As it's not really something I can help for now, I am clearing the flag but I will still watch this bug to not miss updates.

Comment 36

[:gerard-majax]

I am still hitting thing on an irregular basis. I made sure each time I waited long enough after waking up my device so that it can have time to scan frequencies and re-detect towers. Everytime, after 2-3 minutes, still no data tech present. Airplane mode on/off gives it back instantly: area is correctly covered.

Comment 37

[Jessica Jong [:jessica] (inactive)]

(In reply to Alexandre LISSY :gerard-majax from comment #36)
> I am still hitting thing on an irregular basis. I made sure each time I
> waited long enough after waking up my device so that it can have time to
> scan frequencies and re-detect towers. Everytime, after 2-3 minutes, still
> no data tech present. Airplane mode on/off gives it back instantly: area is
> correctly covered.

Looks like we should keep moving forward with bug 1156231.

It'd be great if you could attach logs (with ril log enabled) when you meet this issue, to identify if it's the same cause for each of the cases. Thanks.

Comment 38

[:gerard-majax]

Yeah, it would be great ... if only it was happening when I can grab logs ?

Comment 39

[Jessica Jong [:jessica] (inactive)]

If you can't collect logs, it's fine, we can only wait and see if bug 1156231 solves your case. Being sarcastic (as always) doesn't help...

Comment 40

[:gerard-majax]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #39)
> If you can't collect logs, it's fine, we can only wait and see if bug
> 1156231 solves your case. Being sarcastic (as always) doesn't help...

This is still happening. Bug 1156231 fixed nothing.

Comment 41

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

(In reply to Alexandre LISSY :gerard-majax from comment #40)
> (In reply to Jessica Jong [:jjong] [:jessica] from comment #39)
> > If you can't collect logs, it's fine, we can only wait and see if bug
> > 1156231 solves your case. Being sarcastic (as always) doesn't help...
> 
> This is still happening. Bug 1156231 fixed nothing.

Jessica is taking paternity leave.

I admit that the solution in bug 1156231 has limitations that it won't keep recovering endlessly due to power concerns. Also, the recovery mechanism is designed based on a certain triggering point (what we identified from previous logs) that may not perfectly resolve data dropping if it is triggered by different reasons. However, please don't jump to conclusions so fast, especially it had been reported that the data lost has been nearly not seen anymore after bug 1156231 was landed for a while. 

Please please please help us by providing logs for further investigation. Thanks!

Comment 42

[:gerard-majax]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #41)
> (In reply to Alexandre LISSY :gerard-majax from comment #40)
> > (In reply to Jessica Jong [:jjong] [:jessica] from comment #39)
> > > If you can't collect logs, it's fine, we can only wait and see if bug
> > > 1156231 solves your case. Being sarcastic (as always) doesn't help...
> > 
> > This is still happening. Bug 1156231 fixed nothing.
> 
> Jessica is taking paternity leave.
> 
> I admit that the solution in bug 1156231 has limitations that it won't keep
> recovering endlessly due to power concerns. Also, the recovery mechanism is
> designed based on a certain triggering point (what we identified from
> previous logs) that may not perfectly resolve data dropping if it is
> triggered by different reasons. However, please don't jump to conclusions so
> fast, especially it had been reported that the data lost has been nearly not
> seen anymore after bug 1156231 was landed for a while.

You are jumping to conclusions. I have never seen the issue disappearing.
 
> 
> Please please please help us by providing logs for further investigation.
> Thanks!

How? I need to have my device and laptop constantly connecting collecting logs?

Comment 43

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

(In reply to Alexandre LISSY :gerard-majax from comment #42)
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #41)
> > (In reply to Alexandre LISSY :gerard-majax from comment #40)
> > > (In reply to Jessica Jong [:jjong] [:jessica] from comment #39)
> > > > If you can't collect logs, it's fine, we can only wait and see if bug
> > > > 1156231 solves your case. Being sarcastic (as always) doesn't help...
> > > 
> > > This is still happening. Bug 1156231 fixed nothing.
> > 
> > Jessica is taking paternity leave.
> > 
> > I admit that the solution in bug 1156231 has limitations that it won't keep
> > recovering endlessly due to power concerns. Also, the recovery mechanism is
> > designed based on a certain triggering point (what we identified from
> > previous logs) that may not perfectly resolve data dropping if it is
> > triggered by different reasons. However, please don't jump to conclusions so
> > fast, especially it had been reported that the data lost has been nearly not
> > seen anymore after bug 1156231 was landed for a while.
> 
> You are jumping to conclusions. I have never seen the issue disappearing.
>  

Actually, IIRC that's what you shared to me in an email...

> > 
> > Please please please help us by providing logs for further investigation.
> > Thanks!
> 
> How? I need to have my device and laptop constantly connecting collecting
> logs?

I think so? Sorry no better ideas.

I also set qawanted to see if we are able to get helps from QA.

Comment 44

[:gerard-majax]

Fine.