Issue #1131: Bizare SIM card - Replicant

Actions

Copy link

Issue #1131

closed

Bizare SIM card

Added by Richard "Cylus" Palmer almost 10 years ago. Updated about 5 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Paul Kocialkowski

Category:

Telephony and mobile data

Target version:

Replicant 4.2

Start date:

12/19/2014

Due date:

% Done:

Estimated time:

Resolution:

wontfix

Device:

Galaxy S 3 (I9300)

Grant:

Type of work:

Description

As requested by Paulk, here is a bug report on my bizarre SIM card, which may or may not be related to a bug in Replicant.

When using this SIM card, the device claims to have no service in any spot in the interface where the carrier would normally be listed, such as at the bottom of the notification drawer or on the quick settings menu's mobile data square.

Actual service does not seem to be effected by this, and the signal strength icon functions as normal, showing both the strength of the signal and which network (E, 3G, H, H+) the device is connected to.

I'm not sure if it is related or not, but the SIM also does not seem to have access point information, so this information has to be entered into Replicant manually. This information might legitimately be missing from the SIM card, but it might just be unreadable by Replicant due to the same potential bug that is making the device claim not to have service.

I'm not sure what I'm looking for in the radio buffer, or even what to try to trigger while capturing said buffer, but I've uploaded some output. If you have any requests of what to try to trigger, I'd be happy to upload something specific.

Files

Download all files

radiobuffer.txt (491 KB) radiobuffer.txt	radio buffer	Richard "Cylus" Palmer, 12/19/2014 04:15 AM
main.txt (342 KB) main.txt		Richard "Cylus" Palmer, 01/16/2015 02:27 AM
radio.txt (290 KB) radio.txt		Richard "Cylus" Palmer, 01/16/2015 02:27 AM

History
Notes
Property changes

Actions

Copy link

Updated by Paul Kocialkowski almost 10 years ago

Thanks for the report! Your log has many things of interest:

First, it seems that the RIL is somewhat crashing in the beginning. You can spot that because on the log, you get the following out of the blue (as opposed to in the beginning of the log). If you can get that to happen again, grabbing a log of the main buffer would help understand what is going on:
```
D/RIL     ( 2701): Created IPC FMT client
D/RIL     ( 2701): Created IPC RFS client
D/RIL     ( 2701): Created SRS client
D/RIL-IPC ( 2701): Starting i9300 modem boot
```

Then, your PLMN number is unknown to our database, which comes straight from wikipedia's http://en.wikipedia.org/wiki/Mobile_country_code so feel free to add it there so that it's included in the next batch of Replicant releases!

D/RIL-IPC ( 2701): xmm626_sec_modem_fmt_recv: Received FMT message
D/RIL-IPC ( 2701): xmm626_sec_modem_fmt_recv: Message: aseq=0x00, command=IPC_NET_SERVING_NETWORK, type=IPC_TYPE_NOTI, size=11
D/RIL-IPC ( 2701): ================================= IPC FMT data =================================
D/RIL-IPC ( 2701): [0000]   02 02 04 33 31 30 34 31  30 BF 84                  ...31041 0..
D/RIL-IPC ( 2701): ================================================================================
E/RIL     ( 2701): ipc2ril_net_operator: Finding operator with PLMN 31041 failed

Something interesting, there is a message we are ignoring that contains the string we're looking for, so we could add support for it as well:

D/RIL-IPC ( 2701): xmm626_sec_modem_fmt_recv: Message: aseq=0x00, command=IPC_NET_IDENTITY, type=IPC_TYPE_NOTI, size=110
D/RIL-IPC ( 2701): ================================= IPC FMT data =================================
D/RIL-IPC ( 2701): [0000]   00 FF 00 20 03 00 41 00  54 00 26 00 54 00 00 00   ... ..A. T.&.T...
D/RIL-IPC ( 2701): [0010]   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
D/RIL-IPC ( 2701): [0020]   00 00 00 00 00 00 40 03  00 41 00 54 00 26 00 54   ......@. .A.T.&.T
D/RIL-IPC ( 2701): [0030]   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
D/RIL-IPC ( 2701): [0040]   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
D/RIL-IPC ( 2701): [0050]   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
D/RIL-IPC ( 2701): [0060]   00 00 00 00 00 00 00 00  33 31 30 34 31 30         ........ 310410
D/RIL-IPC ( 2701): ================================================================================
D/RIL-IPC ( 2701): Unhandled IPC FMT message: IPC_NET_IDENTITY

Actions

Copy link

Updated by Richard "Cylus" Palmer over 9 years ago

I'm very sorry I didn't respond to this sooner. Somehow, I didn't even see the alert in my inbox, though it did come in correctly.

I will grab the data from the main buffer when I can, which will likely be after work tomorrow.

I can't edit Wikipedia though, it seems that Tor exit nodes are banned at Wikipedia. Reading is allowed, but page modification is not.

I don't know a lot about the topic, but it seems odd to me that the string is stored in a different place than other SIM cards. It seems like it should be in a standard place, but then again, I'm more in favor of standards than corporations are. Still, it makes me wonder what the goal was for the company to program the SIM card oddly. The crashing RIL seems to scream "nonstandard SIM" to me as well, but again, I don't know what I'm talking about.

I'll try to get my inbox cleaned out as well so important notifications such as this don't slip past me again.

Actions

Copy link

Updated by Paul Kocialkowski over 9 years ago

I will grab the data from the main buffer when I can, which will likely be after work tomorrow.

That's only relevant if the RIL crashes still happen (it could be a one-time thing). Since that happened at power-on, I suggest you turn the device off and on again, grab radio logs, check if the crash is there and if it is, grab and attach the main buffer logs here.

I don't know a lot about the topic, but it seems odd to me that the string is stored in a different place than other SIM cards.

There are 2 different things here, the PLMN and the "virtual" operator name. Usually, each operator sets a particular name on the SIM card's data, which is displayed by the system. However, not every operator does that. Then there is the PLMN number. That's the number identifying the operator of each cell tower (as you probably know, numerous operators don't actually have cell towers but rent them to bigger operators).

The operator name that matches the PLMN number is usually stored in a database, that's part of Samsung-RIL in our case. It simply turns out that your operator is not part of the database (which is directly imported from wikipedia). It also seems like the IPC_NET_IDENTITY message does provide that value, so we could also get it from there.

It seems like it should be in a standard place, but then again, I'm more in favor of standards than corporations are. Still, it makes me wonder what the goal was for the company to program the SIM card oddly. The crashing RIL seems to scream "nonstandard SIM" to me as well, but again, I don't know what I'm talking about.

The crashing RIL seems to scream "nonstandard SIM" to me as well, but again, I don't know what I'm talking about.

Nah, it's most certainly unrelated.

Actions

Copy link

Updated by Richard "Cylus" Palmer over 9 years ago

File main.txt main.txt added
File radio.txt radio.txt added

I rebooted, and the radio boot seems to happen thrice. I guess that means it crashed twice?

If I understand correctly what the PLMN is, it should be associated with the carrier AT&T. If it's relevant, the virtual operator is Cricket.

Logs for both the main and radio buffers are attached.

Actions

Copy link

Updated by Paul Kocialkowski over 9 years ago

For some reason, it seems that the whole system is crashing at boot, only once. That's odd, but is not directly related to the RIL, so that's fine.

I'll try to solve the operator issue next time I work on Samsung-RIL. As you said, service shouldn't be affected by this.

Actions

Copy link

Updated by Denis 'GNUtoo' Carikli almost 9 years ago

Device Galaxy S 3 (I9300) added

Actions

Copy link

Updated by Wolfgang Wiedmeyer almost 8 years ago

It looks like the operator issue occurs because Samsung-RIL expects that the MNC code, which is the second part of the PLMN number, has only two digits. I tried to fix this here: https://code.fossencdi.org/hardware_ril_samsung-ril.git/commit/?h=replicant-6.0&id=6fa066836fa6fd4164244337d1facee369a074fd

Your operator AT&T has the three-digit MNC code 410 as part of the PLMN 310410. Samsung-RIL couldn't detect it because it thought the PLMN is 31041. The zero at the end was missing. So no need to edit the Wikipedia page.

Actions

Copy link