Fails at step: gp --acr-list-aram

[9600]

If I follow the steps outlined with a new sysmoUSIM-SJS1 everything proceeds fine up until the step 'gp --acr-list-aram', which results in:

Could not read A00000015141434C00

If I then execute gp -lvi this now fails with:

STRICT WARNING: Card cryptogram invalid! Card: CCC8261F92992718 Host: 344C0378D954D970 !!! DO NOT RE-TRY THE SAME COMMAND/KEYS OR YOU MAY BRICK YOUR CARD !!!

Repeating the same steps with a new card gives me the same result. 'gp -lvi' works fine prior to loading the applet and certificate, then fails with cryptogram invalid afterwards.

[herlesupreeth]

Have you unlocked the card as mentioned in the wiki? The reason for asking this is, you can only execute gp --acr-list-aram or gp -lvi without providing --key-enc --key-mac --key-dek if you have unlocked the card as mentioned in the wiki or else you need to execute those command as follows

$ gp --key-enc <KIC1> --key-mac <KID1> --key-dek <KIK1> --acr-list-aram
$ gp --key-enc <KIC1> --key-mac <KID1> --key-dek <KIK1> -lvi

[9600]

Yes, running -lvi completed without error the first time and I executed --unlock. Then installed the applet and pushed the certificate. The problem came with --acr-list-aram and the next time I then used -lvi. Tried these also by specifying the keys.

However, when I inserted the SIM into a Pixel 2 I the VoLTE option now appeared and the CoIMS app confirms correct configuration. So it seems like it worked, despite the above errors I now get using those commands.

The problem I have now is that I used pysim-prog to set the MCC/MNC to 001/01 and this is what my network is configured with, but the handset is showing a status of roaming and I suspect the SIM is still using the original 901/70 values configured by sysmocom.

Thanks for your help, it's appreciated!

[herlesupreeth]

Another thing, after you have unlocked the SIM using --unlock do not use the old keys as the --unlock command will write new keys

[9600]

You mean all three keys used in the unlock (-enc, -mac and -dek) are all changed as part of the unlock process? The response I got was:

Default type=DES3 bytes=404142434445464748494A4B4C4D4E4F kcv=8BAF47 set as master key for A000000003000000

Hence I'm not sure what this is telling me with respect to changed keys.

(this is a dev SIM so I'm not bothered about disclosing keys)

[laf0rge]

The problem I have now is that I used pysim-prog to set the MCC/MNC to 001/01 and this is what my network is configured with, but the handset is showing a status of roaming and I suspect the SIM is still using the original 901/70 values configured by sysmocom.

The mcc/mnc arguments only make sense in batch programming, where you want pySim to generate [random/seuqential] IMSIs within that MCC/MNC. If you want to change the HPLMN (home network) you have to change the IMSI to start with its MCC+MNC, e.g. 00101 instead of 90170.

[9600]

If I omit the MCC/MNC arguments and set the IMSI with a prefix of 00101, pysim-prog returns a line with "MCC/MNC : 901/55". Then if I execute pysim-read, for each of the three *LMNAcT lines I also get "MCC: 901 MNC: 055". The IMSI is now updated, but are these other results showing 901/55 correct?

[herlesupreeth]

You mean all three keys used in the unlock (-enc, -mac and -dek) are all changed as part of the unlock process? The response I got was:

Default type=DES3 bytes=404142434445464748494A4B4C4D4E4F kcv=8BAF47 set as master key for A000000003000000

Hence I'm not sure what this is telling me with respect to changed keys.

Yes, all the three keys (-enc, -mac and -dek) gets changed to 404142434445464748494A4B4C4D4E4F.

And since the gp tool uses 404142434445464748494A4B4C4D4E4F key as default one would not need to provide them after the SIM is unlocked

[9600]

@herlesupreeth Many thanks.

The SIM is programmed with an IMSI starting 00101 and I also set MCC+MNC. Connects fine to my network — without roaming — and now I just need to figure out how to configure the APNs. Android (10 on a Pixel 2) won't let me from the GUI. Built SetAPN and tried using this, but presumably it would need to be signed similar to CoIMS, else I'd need to push another cert to the SIM?

[herlesupreeth]

Built SetAPN and tried using this, but presumably it would need to be signed similar to CoIMS, else I'd need to push another cert to the SIM?

Well, i realized that setting APN in Android (I have yet to update that README) does not need Carrier Privileges so you can just run it and it will insert the APNs. In worst case if you want to have Carrier Privileges in SetAPN app just push the cert with which you sign that app onto the SIM.

[9600]

Appears as though it may, since if I run adb logcat and then start the app, I get:

04-11 10:51:51.681 2205 2226 E DatabaseUtils: java.lang.SecurityException: No permission to write APN settings 04-11 10:51:51.682 8711 8711 E AndroidRuntime: java.lang.RuntimeException: Unable to start activity ComponentInfo{com.example.setapn/com.example.setapn.MainActivity}: java.lang.SecurityException: No permission to write APN settings 04-11 10:51:51.682 8711 8711 E AndroidRuntime: Caused by: java.lang.SecurityException: No permission to write APN settings 04-11 10:51:51.682 8711 8711 E AndroidRuntime: at com.example.setapn.MainActivity.checkNewAPN(MainActivity.java:74)

Is there somewhere I can find details of how to get the cert and format for use with the gp command? And would this replace yours and stop CoIMS from working?

[herlesupreeth]

If you are running Android Studio, follow the second answer (with android studio screenshot) in this post to get the sha-1 certificate of the app

https://stackoverflow.com/questions/15727912/sha-1-fingerprint-of-keystore-certificate/35308827

In the wiki there is break down of apdu sent to sim by gp tool - all you need to do is replace your sha-1 cert in place of my cert.

And, dont worry about cert of CoIMS being replaced, the ARAM applet can successful hold upto 4 certificates i guess after which there is some length issue which is not handled by the applet.

[9600]

Many thanks, pushed the additional SHA1 and now I can run SetAPN and its GUI loads. Data works via the internet APN and now just need to work out why VoLTE isn't. When I look at the MME the handset is only getting an IP for the internet APN, but not ims, and I only see one attach in the logs. VoLTE toggle is enabled and config reported by CoIMS looks OK, so further investigation is required. Maybe there are extra steps on this Pixel 2 / Android 10.

[herlesupreeth]

Strange, i had this app working in pixel 3a Android 10.

Can you post here the screenshot of the app with all the config?

[9600]

There are quite a few screens, so I've attached the first 4x from CoIMS, plus the Testing mode > Phone info. Would be quite nice if there were an option to save all the debug info to a file.

[herlesupreeth]

One thing i noticed in the testing menu is that you haven't programmed the MSISDN on the SIM. It's a definite requirement to complete IMS registration. Also, i have observed check for msisdn flags in two or three UEs. It could be that without MSISDN IMS registration is not triggered.

The output of CoIMS looks all good

[9600]

I programmed an MSISDN and now see a Phone Number in CoIMS Phone info, but doesn't appear to have made a difference. Still not even getting a second IP for the ims APN. Also had other handsets register fine when using an Anritsu test SIM that has no MSISDN configured.

I'm not very familiar with Android internals. Is there some way I can debug what's happening on the handset? Ideally that's better than adb logcat + grep.

[herlesupreeth]

Thats unfortunate. In order to better debugging rather having to use adb is to use any Samsung phone having Android Pie. In Samsung phones/tab you can use the option menu in CoIMS app to enter Samsung IMS debugger and it collects all the things you need to debug. But since it's a phone issue and not a SIM issue i guess the above mentioned method is useless. Btw, you mentioned that APN setting menu is not accessible which bit strange as it was accessible in pixel 3a /Android 10

Oops i didnt read one of your previous reply properly, if there is no attempt by UE to get IP for ims apn then it means this method outlined by Google may not be enough to activate VoLTE and is totally unrelated to presence of MSISDN or not. However i will have a look into this since this method had almost 100% working rate on Qualcomm chipsets.

[9600]

Thanks. I just tested again with Lemfo LTE watch fitted with the Anritsu test SIM and this registered fine, so I know the IMS is set up OK. I have two Samsung J5 Core handsets, but sadly they run the Go version of Oreo.

The Pixel 2 will let me open the APN menu, but not add entries, which obviously I was able to do with SetAPN. Also found I could get access to add an entry by rooting the handsets and executing 'am start -a android.intent.action.INSERT content://telephony/carriers --ei simId -1'. It is strange that after loading the ARA-M applet and running CoIMS, I get the VoLTE toggle and I now also have the ims APN set up, but it makes no attempt (that I can tell) to get an IP from the APN.

[herlesupreeth]

Does the pixel 2 try to connect to ims if it is fitted with Anritsu sim or does it not even in that case as well?

[9600]

Pixel 2 with Anritsu test SIM fitted doesn't even show the toggle for VoLTE. It just gets an IP for internet APN and no registration on the IMS.

Tried also with the sysmoUSIM fitted in the Lemfo device (which works fine with the Anritsu SIM) and this gets an IP for the ims APN (it's the only one configured), but it does not register with the IMS. This is strange and I can't see anything in the UE DB to suggest why one SIM would register and another wouldn't.

[herlesupreeth]

Well, there could be a lot of reasons for that behavior in Lemfo devices

1. Maybe Anritsu SIM has an ISIM which has even finer granular control over IMS than USIM
2. Or Lemfo device has a configuration built into OS which allows IMS registration
3. Non configured IMSConfigData in the SIM Etc.

[herlesupreeth]

Can you send me a pcap at the core network while attaching pixel 2 with sysmocom usim?

[9600]

Sure, just sent a pcap file to your Gmail.

[herlesupreeth]

Thanks for the pcap. It looks like UE is at fault here for not choosing the right Voice Domain, please see the sceenshot of the pcap which you sent below

In this screenshot you can see that UE in its PDN Connectivity Request is sending the Voice Domain as Circuit Switched Voice only. That is kinda indicating that UE does not suport Voice over PS (IMS)

[9600]

Thanks, interesting. Could this be something in the SIM card configuration? Output from pySim-read.py below (note this from before the MSISDN was programmed). Screenshot of mobile network settings in Android attached also.

$ ./pySim-read.py -p 0 Using PC/SC reader (dev=0) interface Reading ... ICCID: 8988211000000352032 IMSI: 001010000035203 SMSP: ffffffffffffffffffffffffffffffffffffffffffffffffe1ffffffffffffffffffffffff0581005155f5ffffffffffff000000 SPN: Amarisoft Display HPLMN: True Display OPLMN: True PLMNsel: fff11fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PLMNwAcT: fff11fffff # MCC: 001 MNC: 001 AcT: UTRAN, E-UTRAN, GSM, GSM COMPACT, cdma2000 HRPD, cdma2000 1xRTT ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused

OPLMNwAcT: fff11fffff # MCC: 001 MNC: 001 AcT: UTRAN, E-UTRAN, GSM, GSM COMPACT, cdma2000 HRPD, cdma2000 1xRTT ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused

HPLMNAcT: fff11fffff # MCC: 001 MNC: 001 AcT: UTRAN, E-UTRAN, GSM, GSM COMPACT, cdma2000 HRPD, cdma2000 1xRTT ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused ffffff0000 # unused

ACC: 0008 MSISDN: Not available AD: 00000002 Done !

[herlesupreeth]

Could this be something in the SIM card configuration?

I am not 100% sure but it has more to do with device capabilities (or atleast what it advertises) or settings and not related to SIM

Btw, all the SIM details you pasted above looks good.

[9600]

Would be nice to figure it out, but also ordered a Galaxy A10, based on your recommendation of Samsung UEs. Will be interesting to see if that works without carrier privileges. I know colleagues have been using Samsung devices with VoLTE, but I suspect always with Anritsu test SIMs and I recall someone once suggesting that carrier privileges is not always required if MCC/MNC = 001/01.

[herlesupreeth]

I would be interested to solve the issue on pixel 2 as well.

Actually for the plmn 00101 it's the opposite of what your colleagues mentioned. So far from my experience what i found on many UEs were locked features for test plmn.

Btw, are you running vanilla android 10 on that pixel 2 or a custom rom? And by any chance its carrier locked?

[9600]

It's running vanilla Android, walleye-qq2a.200405.005-factory-1f086f95. It was bought used and I supposedly not locked. I read that only EE sold Pixel 2s locked and it works fine with a Vodafone SIM, but then it gets service and data works fine with the sysmoUSIM, and its just VoLTE that doesn't.

[9600]

Samsung Galaxy A10 arrived, but getting strange results so far.

When carrying out the initial setup I saw a message along the lines of MCC: 001 MNC:01 not allowed. At this point it had the sysmoUSIM fitted. Once booted there was no service and if I search networks, my local network is not listed, only the operator networks. I also didn't get the VoLTE toggle despite carrier_volte_provisioned = true in CoIMS home screen.

Fitting the Anritsu test SIM instead and I get the same behaviour as above, albeit this time I get the VoLTE toggle — so the opposite of what you would expect with regard this vs. other SIM ...

[herlesupreeth]

Activation of IMS on Samsung is not so straight forward as installing the CoIMS and running the app (Samsung doesnt follow much of Google guidelines with regards to IMS). For Samsung devices, you need to go to CoIMS --> options menu --> Samsung IMS settings and in that you need to enable IMS services you want to activate (MMTEL, RCS, MMTEL Video etc), then you will get VoLTE toggle in the menu.

For initial setup its always tricky even for me (I see this behaviour only with srslte enb and not with commercial eNB from Casa), so here is what i do all the time (its a hit or miss method). Goto CoIMS --> options menu --> Testing menu and in there set the network type as only LTE. Now go back and do a search of networks manually (still you will not see the 00101 network) and leave it in the very vicinity of eNB and at some point (at phone's will :P) it will connect and after initial attach phone will recognise the network for subsequent attaches.

[9600]

Thanks. I've set the preferred network in CoIMS to LTE only, but should I be concerned that in All Cell Measurement Info I don't see a signal for my network? I can only see an operator network in 1800MHz band, whereas my network is in 2600MHz.

I also saw on the packaging a sticker noting that this was being sold in the European market and a UK company has loaded English firmware on it, hence now I'm wondering whether the radio firmware is correct (according to published specs it should support Band 7).

[herlesupreeth]

I think most of the handsets support band 7 atleast (not the handsets before 2012 maybe). For "All Cell Measurement Info" you need to change the interval value in the dropdown as immediate, then you will see cells nearby

[9600]

With this set to immediate I now see a call in 800MHz also, but not my network. Strange. I've done a few more searches and will just leave the handset in close proximity and see if it eventually attaches.

[herlesupreeth]

Another thing you could give it a try is to put phone in Safe mode and try to see if phone attaches or not

[9600]

Left the handset on over night and it still didn't see network at all. Just restarted in safe mode and same result. The fact it cannot even see the network, e.g. in CoIMS phone info also for neighbouring cells, makes me think something is not right. Hadn't appreciated when buying this from Amazon that it was sold in one market and then the vendor loaded another firmware. Will try re-loading firmware.

[9600]

No change after re-flashing and it seems the build I loaded was the same it had on previously. Also tried changing the network MCC/MNC to those for valid networks and the handset still couldn't see the cell at all, either in Android Settings or CoIMS. Whereas the Samsung J5 Core handsets can at least attach and get data service, but obviously I can't run CoIMS due to them running Android Go.

Will see if I can load Lineage or some other firmware onto the A10 this weekend and test again.

Also noticed that carrier_list.textpb does not have any MCC = 999 entries and you should be able to use this with any MNC for private networks. Ofcom are stating that private networks should be using this when they grant you a Shared Access spectrum licence, so unless Android project include this, it looks as though enterprises are going to have great difficulty getting VoLTE to work.

[herlesupreeth]

Will see if I can load Lineage or some other firmware onto the A10 this weekend and test again.

pleas let me know how it goes.

Also noticed that carrier_list.textpb does not have any MCC = 999 entries and you should be able to use this with any MNC for private networks. Ofcom are stating that private networks should be using this when they grant you a Shared Access spectrum licence, so unless Android project include this, it looks as though enterprises are going to have great difficulty getting VoLTE to work.

That is true. carrier_list.textpb has only 00101. But it is possible to have 999 MCC on that as well by filling out some form (i havent done it myself so cant tell how easy or hard it is).

[herlesupreeth]

i would like to close this issue as the carrier privileges worked inspite of the error description in this issue. please feel free to re-open this if you face any further issues

[9600]

Sounds good, had wondered quite a bit off-topic! Thanks for all your help and will let you know how things go when I get chance to proceed further with testing.