[C2] No cellular network - ofonod crashes

REPRODUCIBILITY: Hard to reproduce, seems it is working again
OS VERSION: 5.0.0.29
HARDWARE: Jolla C2
UI LANGUAGE: French
REGRESSION: Yes

DESCRIPTION:

Network refuses to show up. Sim configuration does not show any. After investigation, ofonod died. Restarting it has no effect.

PRECONDITIONS:

Not sure of anything relevant.

STEPS TO REPRODUCE:

  1. Boot the phone
  2. Unlock the sim (if sim is locked, no issue)
  3. ofono restart several times, then no longer starts.

EXPECTED RESULT:

Mobile connectivity ok

ACTUAL RESULT:

No mobile connectivity

MODIFICATIONS:

Nothing relevant.

ADDITIONAL INFORMATION:

Backtrace of ofono -n :slight_smile:

ofonod[27230]: oFono version 1.29
ofonod[27230]: Initializing AML plugin.
ofonod[27230]: Reading of /etc/ofono/phonesim.conf failed: No such file or directory
ofonod[27230]: [gbinder-radio] Connected to android.hardware.radio.config.IRadioConfig/default
ofonod[27230]: [gbinder-radio] Connected to android.hardware.radio.modem.IRadioModem/slot2
ofonod[27230]: [gbinder-radio] Connected to android.hardware.radio.data.IRadioData/slot2
ofonod[27230]: [gbinder-radio] Connected to android.hardware.radio.messaging.IRadioMessaging/slot2
ofonod[27230]: [gbinder-radio] Connected to android.hardware.radio.network.IRadioNetwork/slot2
ofonod[27230]: [gbinder-radio] Connected to android.hardware.radio.sim.IRadioSim/slot2
ofonod[27230]: [gbinder-radio] Connected to android.hardware.radio.voice.IRadioVoice/slot2
ofonod[27230]: [gbinder-radio] Connected to android.hardware.radio.modem.IRadioModem/slot1
ofonod[27230]: [gbinder-radio] Connected to android.hardware.radio.data.IRadioData/slot1
ofonod[27230]: [gbinder-radio] Connected to android.hardware.radio.messaging.IRadioMessaging/slot1
ofonod[27230]: [gbinder-radio] Connected to android.hardware.radio.network.IRadioNetwork/slot1
ofonod[27230]: [gbinder-radio] Connected to android.hardware.radio.sim.IRadioSim/slot1
ofonod[27230]: [gbinder-radio] Connected to android.hardware.radio.voice.IRadioVoice/slot1
ofonod[27230]: getPreferredNetworkTypeBitmap error 1
ofonod[27230]: getPreferredNetworkTypeBitmap error 1
ofonod[27230]: SIM card OK
ofonod[27230]: Requested file structure differs from SIM: 6fb7
ofonod[27230]: SMS History Probe for modem: 0x27993bc0
ofonod[27230]: Registered interface org.ofono.NetworkTime, path /ril_0
ofonod[27230]: nw selection is already auto
ofonod[27230]: smsc query error GENERIC_FAILURE
ofonod[27230]: Requested file structure differs from SIM: 6fb7
ofonod[27230]: data reg changed 2 → 0 (unregistered), attached 0
ofonod[27230]: export_entries_one_storage_cb with ME failed
ofonod[27230]: data reg changed 0 → 2 (searching), attached 0
free(): invalid next size (fast)
ofonod[27230]: Aborting (signal 6) [ofonod]
ofonod[27230]: ++++++++ backtrace ++++++++
ofonod[27230]: +++++++++++++++++++++++++++

Running it once, as root, with debug enabled, and it is now working again… Hard to tell what changed.

1 Like

Did you check if this workaround helps?

Indeed it helped a lot, although it was not sufficient. The problem can occur if the folder is empty, but the following steps :

  • remove everything in that folder
  • clean up in the messages app any message that is marked for retry
  • restart ofono service
  • restart phone

did actually put the phone in a usable again state.

My guess is that there is a race condition in ofono (which explains why running it with debug logs could help). Questions for the dev : if it happens again, what kind of trace would be interesting ? Or a core dump ?

1 Like

In what way insufficient?

It would be nice if you would report more info in the original bug report since this is a duplicate. And close this one.

I had this problem twice since the upgrade on SFOS 5.0.0.29 with a german SIM and german UX and no workaround helped … Even the pulling out the sim and push it back brought no success and after hours and switching the fly mode ob and off it appeared suddenly back …

Insufficient because that was part of the solution (not doing it would not solve anything), but i had to also delete any message marked pending in messages app, restart ofono, and finally reboot the whole phone, to get it into usable state again.

So you didn’t restart ofono as written there? It should be enough!

Did you had ofono in failed state? Otherwise it was not the same bug.

1 Like

Not sure if i make myself clear, sorry :slight_smile:

I did a lot of trial, and is not sure about what finally get it to go back to the working state.

But the final sequence was:

  • boot the phone → ofono crashes
  • clean up the /var/lib/ofono/xxx/tx_queue folder
  • clean up any pending sms in the messages app
  • start ofono service
  • reboot the phone

The third step was very important in my case, i’ve tried without doing it and it failed.

1 Like

Yes it was in status failed … I attach a screenshot from the last time I had it

Interesting. So you had a failed SMS before? And after?

Yes.

Actually, i had a phone in a very pretty bad condition, where even devel-su would raise a Bus error. My wild guess is that dbus server has been oom-killed for some reason, or crashed, but i could not investigate more as nothing was responding correctly. It indeed all started with me trying to send an sms, which did not get delivered.

I had to hard reboot the phone, and that’s when the ofono problems came into play.

I need to raise a bug report for the former crash, but since this is my daily driver, bringing it back to an usable state was of higher priority on my list. And i honestly have no idea on how to reproduce the dbus crash. OTOH, the ofono crash seems pretty reproducible.

Auch, that sucks. I hope it’ll not repeat. Or a proper bugfix is found quick if it will.

Yeah, it’s seems so for many of us.

I deleted the SMS queue and how I mentioned in the former post, I tried to reboot 2 times and than plugging and unplugging the sim card, fly mode on / off and the issue remained and suddenly after a time after fly mode on / off the sim card was active again and since than it works …

1 Like

Just a small comment about the steps provided: you should first stop ofono service, only then clear the tx_queue folder contents, then start ofono again.

Reboot should not be necessary, but doesn’t hurt either.

2 Likes

I will give it a try in this way next time it happens. Honestly I did not stop the daemon, just deleted the queue and made a systemctl restart ofono … But I hope that workaround will be not the only solution in the future :wink:

1 Like

Thanks for warning! Instructions for workaround updated.

2 Likes