Cellular connection drops out

Status changed to 'Confirmed' because the bug affects multiple users.

syslog with ofono -d

Just noticed that when it reconnected I am now seeing E not H

And now back to H after several minutes

I confirm this behaviour on arale. It started 2 weeks ago or so but thought it was my operator (Free Mobile France). Sometimes the phone displays "Searching" and never connects to the cellular network while another phone next to it, with the same operator, is connected.

@Pat, @jibel, could you please paste the result of executing /usr/share/ofono/scripts/list-modems while this is happening?

Taking a look at syslog from comment #3, I see that initial registration after boot takes around one minute, which is a bit long, but not unusual for arale. Four minutes after that I see that signal is lost for about 30 seconds, but then things seem to recover. It does not look very suspicious at first sight, but output of list-modems *while the indicator sees no coverage* may give a hint.

@Pat, thanks for the logs. I can see there are time periods where you lose registration for a while. Also, I see that initially two networks are found:

310/410 -> AT&T, GSM and UMTS bands compatible with MX4
310/120 -> Sprint, LTE bands non compatible with MX4

but after a while I see notifications showing only the Sprint network. Besides, Sprint should not appear here unless you can register there. Do you know if there is some agreement between Sprint and AT&T to share network in your area, maybe depending on the band?

Also, could you try going to SystemSettings->Cellular->Carrier&APN->Carrier and check which operators do you see there? Try to select AT&T as your only operator and see if that improves the situation.

It didn't happen for the last couple of days but in my case there is an agreement between Free Mobile and Orange France to use Orange network when Free has no coverage.
In settings/Cellular/Carrier the 2 operators are listed, Free is selected (which is fine, it's my operator) and I cannot change it.

@jibel - have you been able to capture this behaviour in logs?

On 2 August 2016 at 09:21, Alfonso Sanchez-Beato <
<email address hidden>> wrote:

> @Pat, thanks for the logs. I can see there are time periods where you
> lose registration for a while. Also, I see that initially two networks
> are found:
>
> 310/410 -> AT&T, GSM and UMTS bands compatible with MX4
> 310/120 -> Sprint, LTE bands non compatible with MX4
>
> but after a while I see notifications showing only the Sprint network.
> Besides, Sprint should not appear here unless you can register there. Do
> you know if there is some agreement between Sprint and AT&T to share
> network in your area, maybe depending on the band?
>
> Also, could you try going to
> SystemSettings->Cellular->Carrier&APN->Carrier and check which operators
> do you see there? Try to select AT&T as your only operator and see if
> that improves the situation.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1607823
>
> Title:
> Cellular connection drops out
>
> Status in Canonical System Image:
> Confirmed
> Status in ofono package in Ubuntu:
> Confirmed
>
> Bug description:
> MX4 running 379 from 7/15
>
> I recently noticed the phone was Searching for a signal for some time,
> even though I know it was connected just prior.
> Wifi is disabled.
>
> The attached syslog shows the modem disconnecting and reconnecting
> several times throughout the morning.
>
> Interesting ofono commit on the 12th related to managing power states
>
> http://people.canonical.com/~lzemczak/landing-team/ubuntu-touch/rc-proposed/meizu.en/arale/375.commitlog
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1607823/+subscriptions
>

Le 02/08/2016 à 10:58, John McAleely a écrit :
> @jibel - have you been able to capture this behaviour in logs?
Not yet because the problem didn't occur recently.

>
> On 2 August 2016 at 09:21, Alfonso Sanchez-Beato <
> <email address hidden>> wrote:
>
>> @Pat, thanks for the logs. I can see there are time periods where you
>> lose registration for a while. Also, I see that initially two networks
>> are found:
>>
>> 310/410 -> AT&T, GSM and UMTS bands compatible with MX4
>> 310/120 -> Sprint, LTE bands non compatible with MX4
>>
>> but after a while I see notifications showing only the Sprint network.
>> Besides, Sprint should not appear here unless you can register there. Do
>> you know if there is some agreement between Sprint and AT&T to share
>> network in your area, maybe depending on the band?
>>
>> Also, could you try going to
>> SystemSettings->Cellular->Carrier&APN->Carrier and check which operators
>> do you see there? Try to select AT&T as your only operator and see if
>> that improves the situation.
>>
>> --
>> You received this bug notification because you are a bug assignee.
>> https://bugs.launchpad.net/bugs/1607823
>>
>> Title:
>> Cellular connection drops out
>>
>> Status in Canonical System Image:
>> Confirmed
>> Status in ofono package in Ubuntu:
>> Confirmed
>>
>> Bug description:
>> MX4 running 379 from 7/15
>>
>> I recently noticed the phone was Searching for a signal for some time,
>> even though I know it was connected just prior.
>> Wifi is disabled.
>>
>> The attached syslog shows the modem disconnecting and reconnecting
>> several times throughout the morning.
>>
>> Interesting ofono commit on the 12th related to managing power states
>>
>> http://people.canonical.com/~lzemczak/landing-team/ubuntu-touch/rc-proposed/meizu.en/arale/375.commitlog
>>
>> To manage notifications about this bug go to:
>>
>> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1607823/+subscriptions
>>
>

--
Jean-Baptiste Lallement
irc: jibel

@jibel, that behaviour might be considered a bug, I have opened bug #1608885 for system-settings to address that.

If you see the bug again you can try to execute /usr/share/ofono/scripts/scan-for-operators and you will see a list like:

<<
Scanning operators on modem /ril_0...
[ /ril_0/operator/21403 ]
    Status = current
    MobileCountryCode = 214
    MobileNetworkCode = 03
    Name = Orange
    Technologies = gsm umts

[ /ril_0/operator/21401 ]
    Status = available
    MobileCountryCode = 214
    MobileNetworkCode = 01
    Name = vodafone ES
    Technologies = gsm umts

[ /ril_0/operator/21404 ]
    Status = available
    MobileCountryCode = 214
    MobileNetworkCode = 04
    Name = Yoigo
    Technologies = gsm umts

[ /ril_0/operator/21407 ]
    Status = available
    MobileCountryCode = 214
    MobileNetworkCode = 07
    Name = movistar
    Technologies = gsm umts
>>

You can force one or another operator by doing:

phablet@ubuntu-phablet:/usr/share/ofono/scripts/test-network-registration <path>

being path something like /ril_0/operator/XXXXX, as in scan-for-operators output. Check if forcing your operator to Free changes something.

@alfonso
Not aware of any agreement other than maybe under roaming
My APN shows only AT&T options and the correct one is selected
btw running scan-for-operators gets access denied on dbus

I flashed stable on one MX4, and there had been no disconnects from the network in 22 hrs
While plugged in retrieving the syslog it lost connection :(
So not a regression in proposed it would seem.

syslog and output of sudo /system/bin/logcat -b radio > /tmp/radio.txt when it's happening

@jibel, thanks for the logs. The sequence of registration events that I see is:

D/AT ( 2080): AT< +CREG: 1,"0C94","07EEF3DF",2,0,0
D/AT ( 2080): AT< +CREG: 3,"0D16","0540FD26",2,0,0
D/AT ( 2080): AT< +CREG: 1,"0D16","0540FD27",2,0,0

Apparently the phone tries to register to cell 0540FD26 and it gets registration denied (state=3). It recovers then registration (state=1) after moving to cell 0540FD27.

What is weird is that the LAC is the same for both cells (0D16). This implies that both cells belong to the same network, and therefore if the device can register to one of them it should be able to do the same with the other one. As that does not happen, this points to a modem FW error or maybe that some tuning on modem parameters is needed on our side.

I made a longer recording during 30min and I get the following:
D/AT ( 2124): AT< +CREG: 2
D/AT ( 2124): AT< +CREG: 1,2
D/AT ( 2124): AT< +CREG: 2,"FFFF","0FFFFFFF",0,0,0
D/AT ( 2124): AT< +CREG: 3,2,"FFFF","0FFFFFFF",0,0,0
D/AT ( 2124): AT< +CREG: 3
D/AT ( 2124): AT< +CREG: 1,3
D/AT ( 2124): AT< +CREG: 1
D/AT ( 2124): AT< +CREG: 1,1
D/AT ( 2124): AT< +CREG: 1,1
D/AT ( 2124): AT< +CREG: 1,"0D16","0540FD27",2,0,0
D/AT ( 2124): AT< +CREG: 3,1,"0D16","0540FD27",2,0,0
D/AT ( 2124): AT< +CREG: 1,"0D16","05400015",2,0,0
D/AT ( 2124): AT< +CREG: 3,1,"0D16","05400015",2,0,0
D/AT ( 2124): AT< +CREG: 1,"0D16","0540FD27",2,0,0
D/AT ( 2124): AT< +CREG: 3,1,"0D16","0540FD27",2,0,0
D/AT ( 2124): AT< +CREG: 1,"0D16","0540FD27",2,0,0
D/AT ( 2124): AT< +CREG: 3,1,"0D16","0540FD27",2,0,0
D/AT ( 2124): AT< +CREG: 1,"0D16","05400015",2,0,0
D/AT ( 2124): AT< +CREG: 3,1,"0D16","05400015",2,0,0
D/AT ( 2124): AT< +CREG: 1,"0D16","0540FD27",2,0,0
D/AT ( 2124): AT< +CREG: 3,1,"0D16","0540FD27",2,0,0
D/AT ( 2124): AT< +CREG: 1,"0C94","07EE0015",2,0,0
D/AT ( 2124): AT< +CREG: 3,1,"0C94","07EE0015",2,0,0

If I understood correctly your previous comment, from the records above, the device keeps registering, then being denied on the same cell, then switching to another cell of the same LAC. It keeps switching between the same cells of the same LAC several times, before switching to another LAC and being denied again.

@jibel, no, that is not happening, you are registered all the time. Some of the lines you see there are not events, but answers to AT+CREG commands.

Event:
< +CREG: 1,"0C94","07EE0015",2,0,0

Command and response:
> AT+CREG
< +CREG: 3,1,"0C94","07EE0015",2,0,0

As you see, it is pretty confusing, as the registration status is in one case the first integer, and in the other case the second one. You can ignore the responses to AT+CREG (remove the lines with the extra integer) and just take the events to follow state. In your case:

D/AT ( 2124): AT< +CREG: 2
D/AT ( 2124): AT< +CREG: 2,"FFFF","0FFFFFFF",0,0,0
D/AT ( 2124): AT< +CREG: 3
D/AT ( 2124): AT< +CREG: 1
D/AT ( 2124): AT< +CREG: 1,"0D16","0540FD27",2,0,0
D/AT ( 2124): AT< +CREG: 1,"0D16","05400015",2,0,0
D/AT ( 2124): AT< +CREG: 1,"0D16","0540FD27",2,0,0
D/AT ( 2124): AT< +CREG: 1,"0D16","0540FD27",2,0,0
D/AT ( 2124): AT< +CREG: 1,"0D16","05400015",2,0,0
D/AT ( 2124): AT< +CREG: 1,"0D16","0540FD27",2,0,0
D/AT ( 2124): AT< +CREG: 1,"0C94","07EE0015",2,0,0

so you start searching (2), for a moment you get access denied (3, maybe while authenticating?), then you are registered (1) without further changes.

Btw, you can add "-v threadtime" the the logcat command to get timing information.

I can reliably get the signal to drop on my main phone by plugging into the usb port on my laptop.
it immediately gets no signal then unregistered and eventually searching. It seems to search until I unplug it, at which point it connects within 3 secs, usually at E not H. Rebooting the phone gets it back to H if it doesn't get there quickly enough on its own.

I noticed this frequently when it was plugged into a wall charger as well, there was no signal.

@Pat, which phone are you using?

Also, please try to reproduce the bug while this command is running:

sudo /system/bin/logcat -b radio -v threadtime > /tmp/radio.txt

Then upload syslog and radio.txt to the bug.

MX4
Logs attached

@Pat, thanks for the logs. I see something similar as in jibel's: registration is suddenly dropped and then re-established after a few seconds. Sequence is (1: registered, 0: non-registered, 2: searching):

08-25 21:31:13.108 2160 2169 D AT : AT< +CREG: 1,"1B48","07EF7DA3",6,0,0
08-25 21:34:34.482 2160 2169 D AT : AT< +CREG: 0,"FFFF","0FFFFFFF",0,0,0
08-25 21:34:34.489 2160 2169 D AT : AT< +CREG: 2,"FFFF","0FFFFFFF",0,0,0
08-25 21:34:53.145 2160 2169 D AT : AT< +CREG: 1,"1779","00007DA3",3,0,0
08-25 21:35:06.616 2160 2169 D AT : AT< +CREG: 1,"1B48","07EF7DA3",6,0,0

I checked that there are no suspicious AT commands triggered from our side, so this looks like a modem firmware bug. There is a small chance that we need to set some configuration to avoid this though.

I experience signal dropping out also on Meizu Pro 5 OTA-12.

With the new MX4 firmware I am not noticing the connection dropping during normal use. The comments in #22 are still the case though, connecting USB can trigger a drop which is a behavior I had not noticed over the past year or so..

Pro 5, OTA-23, stable, meizu-pd.en ,
The connection drops out all the time. Sometimes there is no Data connection shown and the phone has an active data connection a sometimes there is the Data indicator present and the phone has no Data connection at all. The phone reconnects back to the network most of the times, but other times I have to trigger the flight mode ir change to 2G and back to 2G/3G/4G

This is quite an annoying bug when browsing the net.

I'm having this issue on Meizu Pro 5 with OTA-13 (stable). People sometimes cannot reach me and calls often drop even when they do reach me.

Still no progress with this annoying bug? It's really one of the worst bugs. Signal drops draining the battery, makes phones overheats. Sometimes I only find a notification of a missed call, but the phone never rang. The caller says the call has gone straight to voicemail. Browsing the net is a choir as the page loading freezes, stops and resumes all the time. Any news would be welcome. Thanks.