Replicant

I forgot to mention that under LineageOS everything works. And the Replicant image is from the build 18.2.17.

By the way the phone handles incoming calls and incoming SMS with no issue (despite the message No SIM card - Orange displayed on the main screen).
But outcoming calls are not possible (Cellular network not available).

Thanks.

On a (my first) fresh install of Replicant 6.0, I also have the issue where the SIM card is not recognized.
As F-Droid currently does not work with an external USB dongle nor usb networking (#1792), this makes it a particularly annoying issue where I can't install any app.
I can confirm the same SIM-card/phone works with Samsung's ROM. I can also provide my logs with Replicant and/or LineageOS if it is of any use.

Glad to see that the priority on this went from normal to urgent. Looking forward to get more help to help the helpers. I have no idea myself what to do to debug this. Still on a depressing emergency phone and I want my replicant back in order. Any new ideas?

Tomas, please check if the issue is still there with Replicant 6.0. If it is, then please open a new issue. It doesn't look like a SIM card problem in your case, because the radio interface fails to communicate with the modem pretty much right at the beginning. That's why the logs looked the same to you, with or without the SIM card. There are many of these errors in your log:

E/RILClient( 1900): Connect_RILD: Connecting failed. Connection refused(111)
D/RIL-IPC ( 1892): Reading RFS data failed
E/RIL-IPC ( 1892): Receiving from IPC RFS client failed
E/RIL     ( 1892): IPC RFS client loop failed

Laura Arjona Reina wrote:

Hi, my SIM card is recognized in my i9300 with Cyanogenmod 13, but not with Replicant 6. I'm attaching the logs.
That SIM was working with Replicant 4.2.2 in that phone until one day that suddenly stopped working. Reflashing 4.2 didn't help.
Sorry I cannot provide the replicant 4.2.2, I'm currently using CM13 and couldn't find the time to do more tests, for now...

Hi, it appears that you have attached the Replicant 6.0 log twice. The log is rather short. Could you capture another log after waiting at least one or two minutes after the phone is booted? It looks to me like the radio interface is never really able to access the SIM card at the SIM state never leaves the state "not ready". Not even the IMSI is successfully transferred.

Your issue is quite different compared to the regression between 4.2 and 6.0 that was originally reported. Could you open a new issue with the longer log? And could you also attach the log from CyanogenMod/LineageOS if you already have one? You could name the new issue "SIM card not recognized (SIM card never ready)" or something similar.

Raphaël Mélotte wrote:

On a (my first) fresh install of Replicant 6.0, I also have the issue where the SIM card is not recognized.
As F-Droid currently does not work with an external USB dongle nor usb networking (#1792), this makes it a particularly annoying issue where I can't install any app.
I can confirm the same SIM-card/phone works with Samsung's ROM. I can also provide my logs with Replicant and/or LineageOS if it is of any use.

In case you used Replicant 4.2 before: did it work with 4.2? At least a radio log with Replicant 6.0 is needed to decide what your issue is about. There can be several causes why the SIM card is not recognized.

Raphaël Mélotte wrote:

I'll try to attach a radio log captured at the very first boot (Replicant-4.2-radio_working) and another one after a reboot (Replicant-4.2-radio_not-working).

Thanks, these could provide some additional clues. Your logs look similar to the others in this issue. This line seems to be there in all of them:

06-01 10:53:51.085 2812 2812 D GSMPhone: [GSMPhone] updateCurrentCarrierInProvider: mSubId = -2 currentDds = -1 operatorNumeric = null

currentDds shouldn't be -1. This means that Android couldn't determine how many SIM card slots are available. The value should be retrieved from settings in the data partition. These are generated early at boot and I don't yet know why this happens because the RIL seems to work fine up to this point, at least from what I can see in the logs.

I asked Paul to look into this issue and he hopefully has some time in the near future.

Fil Bergamo wrote:

Thanks Wolfgang, for working also on this thing!

Yeah, it's probably the most frustrating Replicant bug I have looked into so far. AFAIR this is going on now since December of last year, when I received the first mails about this issue. The solution is probably a one-liner and pretty obvious, once you have figured it out ;)

I tried your RILs right away..
No luck though..

Both with and without PIN lock, no SIM gets recognized, neither on i9100 nor on i9300..
I attached some other logs, all taken with your updated RIL in place.

Thanks for the logs! Yes, they still show the same errors:

08-30 22:51:02.000  2896  2896 E SIMRecords: [SIMRecords] Exception in get GID1 com.android.internal.telephony.uicc.IccException: sw1:103 sw2:0

I expect that at least some of these SIMRecords exceptions are fatal for Android 6 which leads to the impression that the SIM card is not recognized. As an example, the request for the content of GID1 is this one:

08-30 22:51:01.670  2896  2896 D RILJ    : [3730]> iccIO: SIM_IO 0xb0 0x6f3e  path: 3F007FFF,0,0,26 aid: null [SUB0]

The path 3F007FFF is now the same as for the proprietary RIL which is good. As I previously already noticed in the other issue, the specified size (0x26 or 38) is wrong. It should be 8. That's currently my lead and what should be further investigated. With my SIM cards, it is also 8 with Replicant.

Same issue: The SIM card in my i9100 is still not recognized with the patched file. :'(
By the way, the battery consumption is very high with Replicant 6, so after ca. 15 hours the battery must be charged again - with Replicant 4.2 it was after 2 to 3 days without a lot of usage. Maybe this issue is affected by that.

I don't know if it can be of any help, but I just learned that my simcard that isn't recognized under R6.0 is a "USIM" type.
Could the sim type be relevant in this issue?
Could it be a lack of support of 3G-related protocols in 6.0 that were supported in 4.2?

Fil Bergamo wrote:

I don't know if it can be of any help, but I just learned that my simcard that isn't recognized under R6.0 is a "USIM" type.
Could the sim type be relevant in this issue?
Could it be a lack of support of 3G-related protocols in 6.0 that were supported in 4.2?

How can one check whether or not a SIM card is of the "USIM" type?

Hephaestus Aitnaios wrote:

How can one check whether or not a SIM card is of the "USIM" type?

Well, your telephony provider should tell you..
In my case, i found it written in the on the dashboard of my web account..

Niclas Hoyer wrote:

The SIM is still not recognized by Android, BUT I got an SMS from my provider that new settings are sent to my device. So GSM seems to be working (see third log). Then I did some more tests. Basically every incoming connection works, so I can receive SMS and even phone calls, but everything outgoing is blocked, because the SIM card is still "not recognized" and as such there is "no connection".

So maybe it works using patches RILs, but there is "just" some GUI bug?

Interesting suggestion here...
I don't think the bug would be in the GUI, but rather on underlying levels of the framework, if at all.
I can have a check on that, trying a little debugging..
Just give me some time and I'll get back here with a response..

Niclas Hoyer wrote:

The SIM is still not recognized by Android, BUT I got an SMS from my provider that new settings are sent to my device. So GSM seems to be working (see third log). Then I did some more tests. Basically every incoming connection works, so I can receive SMS and even phone calls, but everything outgoing is blocked, because the SIM card is still "not recognized" and as such there is "no connection".

I confirm that I can receive calls and SMS's even if the SIM card is still unrecognized by the device.
I'm now looking into Replicant's source code, and I want to do some debugging to understand exactly where the information about gsm connection state is returned to the phone app.
Maybe it will be useful to understand what causes the state of the GSM connection to be reported as "missing"..

It would be much appreciated if someone can tell me where exactly the phone service is located inside the source tree. It would speed up my research a lot, instead of following references around the tree, like I'm doing right now..

I just ordered a "multicard" SIM from my provider, that allows me to use my i9100 and my i9300 simultaneously with the same number. I thought that would be great for debugging this issue. Unfortunately the new SIMs just work on Replicant 6.0. I still have the old SIM, which is deactivated. I think it should still be useful for debugging. All of them are "USIM" type SIMs supporting GSM/UMTS/LTE, same provider and they look the same. I wonder what could be different, that the old one isn't recognized.

It would be much appreciated if someone can tell me where exactly the phone service is located inside the source tree. It would speed up my research a lot, instead of following references around the tree, like I'm doing right now..

I was just poking around the tree by myself. One possible starting point could be Samsung-RIL, the libre software replacement for the proprietary RIL, that talks to the Android framework: https://redmine.replicant.us/projects/replicant/wiki/Samsung-RIL

Hello,

Like several other users, I had this issue and went to my mobile service provider to get a new SIM card and it worked. Before that, I tried to follow what happens in the radio log in the case of the old SIM card and does not happen with the new SIM card. Four consecutive lines caught my attention with old SIM card, and indeed it does not appear with the new one :

10-23 12:23:47.972 3445 3445 D SubscriptionController: [getSubId]- sSlotIdxToSubId.size == 0, return DummySubIds slotIdx=0
10-23 12:23:47.974 3445 3445 D SubscriptionController: [getSlotId]- subId invalid
10-23 12:23:47.974 3445 3445 D SubscriptionController: getSimStateForSlotIdx: simState=READY ordinal=5
10-23 12:23:47.974 2324 2937 D SubscriptionManager: getSimStateForSubscriber: simState=5 slotIdx=0

I interpret the two first lines as the SubscriptionController being unable to get a slot because getSubId returns DummySubIds. It does that because sSlotIndexToSubId is empty in SubscriptionController.java and the DummySubIds are generated by the function getDummySubIds(slotIndex) which from my reading of the code could return null if it does not find an appropriate integer with the function getActiveSubInfoCountMax(). However the latter function calls TelephonyManager::getSimCount() and should return 1 in the case of the mono-SIM Galaxy S2.

When come the two last line of the sample hereabove, it says that SubscriptionController::getSimStateForSlotIdx et SubscriptionManager::getSimStateForSubscriber return 5 (READY), which is strange after having stated that no slot was available.

However with the new SIM card, none of that occurs, and this can be confirmed when looking at the logs of Issue #1868 where the author made the same test as me (old SIM not working, new SIM working). In his new SIM logs, no trace of getSubId returning DummySubIds nor getSlotId complaining about invalid subId.

I hope it makes sense and could originate some progress on this annoying issue, which I believe is very blocking for the widespread of Replicant 6. Many thanks to the contributors !

I followed Avgot Abike's suggestions and had a look around the code for

sSlotIdxToSubId

in

frameworks/opt/telephony/src/java/com/android/internal/telephony/SubscriptionController.java

There are a bunch of TODOs/FIXMEs that caught my attention, both above the variable's definition, and in various other places, that suggest something is wrong with the current implementation in SubscritionController.

line 137:

 // FIXME: Does not allow for multiple subs in a slot and change to SparseArray
    protected static Map<Integer, Integer> sSlotIdxToSubId =
            new ConcurrentHashMap<Integer, Integer>();

See also line 751:

// (...)
// If sSlotIdxToSubId already has a valid subId for a slotId/phoneId,
// do not add another subId for same slotId/phoneId.
Integer currentSubId = sSlotIdxToSubId.get(slotId);
if (currentSubId == null
        || !SubscriptionManager.isValidSubscriptionId(currentSubId)) {
    // TODO While two subs active, if user deactivats first
    // one, need to update the default subId with second one.

    // FIXME: Currently we assume phoneId == slotId which in the future
    // may not be true, for instance with multiple subs per slot.
    // But is true at the moment.
    sSlotIdxToSubId.put(slotId, subId);
// (...)

And most interesting, line 1258:

protected int[] getDummySubIds(int slotIdx) {
        // FIXME: Remove notion of Dummy SUBSCRIPTION_ID.
        // I tested this returning null as no one appears to care,
        // but no connection came up on sprout with two sims.
        // We need to figure out why and hopefully remove DummySubsIds!!!
        int numSubs = getActiveSubInfoCountMax()
        // (....)

And finally, line 1611:

    // FIXME: We need we should not be assuming phoneId == slotId as it will not be true
    // when there are multiple subscriptions per sim and probably for other reasons.
    public int getSubIdUsingPhoneId(int phoneId) {
        int[] subIds = getSubId(phoneId);
        if (subIds == null || subIds.length == 0) {
            return SubscriptionManager.INVALID_SUBSCRIPTION_ID;
        }
        return subIds[0];
    }

Unfortunately I have no clue at all about what those comments mean..
Someone who knows about telephony???

Could it be a meaningful hint or just a red herring???