Cell-id info no longer returned via dbus calls in SFOS 4.2

Bug Reports
,
1

REPRODUCIBILITY (% or how often): 90-100%
BUILD ID = OS VERSION (Settings > About product): 4.2.0.21 (Verla)
HARDWARE (XA2, X10, X10 II, …): XA2 Plus Dual SIM
UI LANGUAGE: English
REGRESSION: (compared to previous public release: Yes, No, ?): Yes

DESCRIPTION:

I have a background program active which act based on cellid’s. I noticed this was no longer working and that it stopped working exactly after the upgrade to 4.2. It uses dbus commands.

Some dbus commands that return no data anymore:
dbus-send --system --print-reply --dest=org.ofono /ril_0 org.nemomobile.ofono.CellInfo.GetCells
dbus-send --print-reply --system --dest=org.ofono /ril_0 org.ofono.NetworkMonitor.GetServingCellInformation

It returns an empty array (same goes for my second SIM, ril_1). The first command does return some result maybe 1 out of 20 times, the second one always returns an empty array.

PRECONDITIONS:

Upgraded to SFOS 4.2

STEPS TO REPRODUCE:

  1. Issue the dbus commands.
  2. Maybe someone who has not upgraded to 4.2 can confirm it still works on their device? Or does it work for others on 4.2?

EXPECTED RESULT:

Array with cell info

ACTUAL RESULT:

Empty array

ADDITIONAL INFORMATION:

1 Like
2

Seems to work fine for me on 4.2.

3

Thanks for testing. It was tested of an XA2 or an other model?
I was actually able to get a result from the second command a few minutes ago for the first time, but now it is returning an empty array once again. Can’t imagine it is hardware related, as it worked fine before the 4.2 upgrade. It could be related to some corrupted software component then, no idea really.

4

Xperia 10 II here. 

5

Still broken in 4.3.0.12.

Saw some warnings passing during the upgrade, no idea if it is related:

[78 %] [Install] ofono 1.23+git35-1.10.1.jolla: [22 %]qt.qpa.bearer.connman: QConnmanEngine: Deferring a cellular service configuration because ofonoNetwork is unavailable
[78 %] [Install] ofono 1.23+git35-1.10.1.jolla: [100 %]qt.qpa.bearer.connman: QConnmanEngine: Unable to translate the bearer type of the unknown network technology: ""
[81 %] [Install] ofono-alien-binder-plugin 0.1.5-1.2.1.jolla: [0 %]qt.qpa.bearer.connman: QConnmanEngine: Unable to translate the bearer type of the unknown network technology: ""
[82 %] [Install] ofono-ril-binder-plugin 1.2.5-1.3.1.jolla: [0 %]qt.qpa.bearer.connman: QConnmanEngine: Unable to translate the bearer type of the unknown network technology: ""
6

@adekker:
I tried with 4.3.0.12/X10ii and both dbus commands worked fine.
I also tried with 4.2.0.21/XA2 (h4113, one SIM) and the commands worked in this case, too. However, the first try of the first command did not give a proper output but after that, it worked fine.

7

First try was empty too, XA2, 4.2.

8

X with 4.3 works fine.
Also on first try.

9

Your finding and the response of @amaretzek confirms for me that it does not work as pre SFOS 4.2. Before 4.2 I would always get a response, now it has become russian roulette.

And the least chance of getting a response seems to be when the device is in sleep mode. I am running a background process that performs actions based on cellid using this commands, and I immediately noticed it stopped working after my upgrade to 4.2

10

Have the same problem for a while now. Maybe even earlier than 4.2.
Xperia 10, 4.3.

11

And… not fixed in 4.4.0.58 :frowning_face:

12

And… not fixed in 4.4.0.64 :frowning_face:

13

Do you have a XA2 or a XA2 Dual SIM?

14

I checked again (now both 10 and 10III) and 2nd command seems to work now.
But first one (GetCells) returns an empty array on 10III.

15

As this topic got some attention recently I decided to do some more test rounds to see if anything has changed recently.
At first it seems I got proper replies, only to find out it does not update when for example cell-id’s change. It gives the strong impression I am getting only cached results. After restarting ofono all I get is empty results once again.

16

Is this commit related?

It seems some changes were made for 4.2 that didn’t always update that data unless someone was subscribed to it.

1 Like
17

Looks like a change that could be related.
Is there any way I can verify this by way of a change in some settings to change the behavior, or even some experimental ofono package? Or do I indeed need to subscribe to some service/channel now and if so, how?

18

From the looks of that commit, subscribing to that dbus property might be enough to start it populating. If I start a map app, and I have the mlsdb active, that call works.

1 Like
19

I think calling GetCells cold should still return valid data, and is possibly a case that these changes have missed so I’ve filed a bug internally. You might be able to get something working from that commit in the meantime though. I think the mls geoclue plugin is using some QOfonoExtCellWatcher:

https://github.com/mer-hybris/geoclue-providers-mlsdb/blob/75322021af14e70077b0d9c7704827b521584220/plugin/mlsdbprovider.cpp#L370

20

For a program running in the background that on-demand behavior shouldn’t a problem because the first org.nemomobile.ofono.CellInfo.GetCells call enables cell info tracking and then updates start coming. Or at least that’s how it’s supposed to work.

org.ofono.NetworkMonitor.GetServingCellInformation temporarily enables cell info update notifications and waits up to 10 sec for an update to arrive. From dbus-send (a short-lived client) that should actually produce non-empty result more often than org.nemomobile.ofono.CellInfo.GetCells, I’m surprised to hear the opposite. That also depends on whether the modem is currently registered or not.

In any case, the result of the initial query shouldn’t be assumed accurate. Keeping cell info notification enabled generates D-Bus traffic and extra wakeups from the modem, which was the reason for enabling those on demand.

3 Likes