Frequent offline state in android subsystem, Xperia 10 III, 5.1.0.11

General
1

I’m using an Xperia 10 III running Sailfish 5.1.0.11. Since the update from the previous release, I have an extremely annoying issue with mobile connectivity in the Android support system.

I have searched the forum and not found any topic that was similar and not years old.

Device will have mobile data and the sailfish browser is able to resolve DNS and connect to servers. But every Android app will immediately claim to be offline. The only way to restore connectivity is to first restart mobile network through utilities. Then restart (regular?) network through utilities. After that, Android apps have data connectivity. This state lasts for minutes, sometimes 1, often 5-10 and sometimes up to an hour. But, inevitably, the Android layer goes offline again.

As the built-in browser is sadly out of date and also has no support for proper ad blocking, I almost exclusively use fennec for web. Also, the best apps for public transport are Android apps as well and obviously important when commuting for work. So the Android layer going offline every few minutes is a huge pain.

Two days ago I activated the “Treat mobile data as WLAN” option after having (to no obvious effect) tested deactivating it. Then, I had connectivity for more than a day and felt relief, but the next day the issue was present again.

It has gotten so bad that I’m using a secondary device for checking public transport and have the mobile hotspot enabled. This works flawlessly as native sailfish networking is fine. But it is a bit silly and cumbersome to dual-wield Xperia 10s (second device has HW damage and can’t connect beyond 2G any more).

I will set up a log collector for a few days and go over the system journal to try and determine what component is failing.

Is there anything obvious that I’m missing? Could I have changed some config file under /etc that might cause trouble? Can I supply some useful information for diagnostics?

2

I’m using exactly the same config as you, to the point where I’m also using Fennec… but I don’t experience anything like that on exactly the same setup and that’s weird.

First off, did you actually change anything in /etc or elsewhere in system files? Some nonstandard DNS? Changes to /etc/hosts maybe?

Then, how does your network setup look like under Android AppSupport? (go to SFOS settings - AppSupport - tap android version 5 times). You should have mobile data from your SIM card, and if you enabled the “treat mobile data as wifi” option, it should appear like mobile_data_0 or something like this, and it will say “unable to change” (true, because SFOS governs it).

Also yes, default browser is terribly outdated, even SFOS forum page says it’s not compatible anymore :smiley: But you can install updated version in parallel from Storeman (search for sailfish-browser-next). While AFAIK you can’t uninstall the outdated default one, you can link the updated one to serve as default (instructions are either on the forum or on the sailfish-browser-next’s page on OpenRepos; I haven’t tried them yet).

3

Thank you for reminding me to look at the android side of things. I see no wifi device. I see both of the SIM cards, though.

And there I discovered something strange:

  • SIM1, which is the only one used for data, shows up as disabled
    • enabling is not possible, toggle flicks to inactive right away
  • SIM2, which is only there for calls & SMS, is listed as “active”
    • data is not activated, it cannot be deactivated

When I do the song and dance to reset connectivity, SIM1 shows up under android as “Active / Default for mobile data, SMS”. Apps now have connectivity. I suspect that when android goes “offline” the next time, I will find the same broken SIM state again.

So what seems to happen is that some event brings the SIM into a state where the android layer (or some bridge service) will drop it and regard it as “inactive” and it will never recover from that state, unless ofono is restarted. The additional need to restart networking is just a secondary problem.

I will have to get around to looking at logs, maybe there are hints.

4

I did collect logs and, for a lark, had tasked an LLM with looking for clues and piecing things together. It did not take long and what it found makes sense to me, here is the generated summary:

When Android apps report “offline” while Sailfish OS mobile data keeps working, the cause is a crash (SIGABRT) of the Qualcomm vendor RIL daemon vendor.qcrild and the incomplete recovery in ofonod that follows it .

When qcrild dies, every binder interface it serves goes away. droid-hal-init restarts qcrild straight away. The running ofonod then reconnects only to android.hardware.radio@1.5::IRadio/slot1 . It does not reconnect to android.hardware.radio.config@1.1::IRadioConfig/default or to IRadio/slot2 , and only modem /ril_0 is re-registered.

Native Sailfish networking only needs the slot1 data context, which ofono re-activates within about 30 s. That is why native data and the mobile hotspot keep working. The Android layer depends on ofono’s full SIM/slot state, which is now incomplete, so Android loses the SIM and with it the default data connection.

The user’s workaround works because of how each step acts on this state:

  1. Restarting ofono: a fresh ofonod connects to IRadioConfig, slot1 and slot2 and registers both /ril_0 and /ril_1. Android sees the SIM again.
  2. Restarting connman: the cellular service is re-created and becomes the default route. Android shows SIM1 as the data connection again.

Every qcrild crash in the dataset is followed by this manual fix.

Why qcrild crashes (all 4 tombstones of the day): Scudo, the heap allocator, aborts with corrupted chunk header while the Qualcomm RIL frees memory in its cell-location code. The call path is qcril_qmi_nas_poll_cell_info_list → (in 3 of 4 crashes qcril_qmi_nas_cell_location_unsol_if_needed_cl) → qcril_free_adv , inside /odm/lib64/libril-qc-hal-qmi.so . This is heap corruption (a bad, stale or double free, or an overwrite) in the proprietary vendor RIL blob.

What sets it off: all four crashes happen 5–41 s after geoclue’s mobile-network positioning provider (org.freedesktop.Geoclue.Providers.Mlsdb) is activated or looks up cells. That provider asks for the cell-info list through ofono, which leads into exactly the qcrild code path that crashes. The lookups are started by geoclue-master on behalf of an Android app’s location request (via apkd-bridge-hw).

I have Location settings on “custom” and all I changed as a test was to disable “Online position lookup based on nearby cell towers and WLAN networks”.

I haven’t really been out and about for the past 7 days, but so far, I could not observe a loss of connectivity for the android layer. Yay!

I’m also not sure whether this qualifies as a solution. The device becomes a lot more usable but ultimately, the original defect persists.

EDIT: Nope, just after posting, I managed to provoke the same incident again, so apparently this setting alone is not enough as a workaround :confused:

I’m not sure what the proper channels for this bug report are, as the root cause must be fixed in the proprietary executable. But ofonod should at least be handling this crash more sensibly. I have the logs in question and the tombstones saved away in case any details would be needed for a fix.