Project

General

Profile

Actions

Issue #1131

closed

Bizare SIM card

Added by Richard "Cylus" Palmer about 9 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Category:
Telephony and mobile data
Target version:
Start date:
12/19/2014
Due date:
% Done:

0%

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

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
Actions #1

Updated by Paul Kocialkowski about 9 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 #2

Updated by Richard "Cylus" Palmer about 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 #3

Updated by Paul Kocialkowski about 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 #4

Updated by Richard "Cylus" Palmer about 9 years ago

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 #5

Updated by Paul Kocialkowski about 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 #6

Updated by Denis 'GNUtoo' Carikli over 8 years ago

  • Device Galaxy S 3 (I9300) added
Actions #7

Updated by Wolfgang Wiedmeyer about 7 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 #8

Updated by Denis 'GNUtoo' Carikli over 5 years ago

  • Category changed from Telephony and mobile data to SIM card not recognized
Actions #9

Updated by Denis 'GNUtoo' Carikli over 5 years ago

  • Category changed from SIM card not recognized to Telephony and mobile data
Actions #10

Updated by Kurtis Hanna over 4 years ago

  • Resolution set to wontfix

This issue has been closed because Replicant 4.2 is no longer supported or maintained.

Actions #11

Updated by Kurtis Hanna over 4 years ago

  • Status changed from New to Closed
Actions

Also available in: Atom PDF