SIM card related Projects » pySim

As far as I can see right now multiple things seem to be broken.

What I need would be the following:

• A commandline (I assume the above are exactly what you have tried)
• A CSV file sample (I think 3 records are enough) to test it. You do not have to do any modifications, I will then just copy+paste the data from my test card)

(In general log output from your system would be very helpful but since you showed my what goes wrong on your machine I know what output I should expect.)

thanks for fixing this.

i got a little odd warning from python on debian11:

/home/osmocom/test/pysim/./pySim-prog.py:602: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if opts.mnclen is "2":
/home/osmocom/test/pysim/./pySim-prog.py:604: SyntaxWarning: "is" with a literal. Did you mean "=="?
  elif opts.mnclen is "3":

not sure if this is the correct fix, but it seems to work:

diff --git a/pySim-prog.py b/pySim-prog.py
index b3919ee..448f2a0 100755
--- a/pySim-prog.py
+++ b/pySim-prog.py
@@ -599,9 +599,9 @@ def read_params_csv(opts, imsi=None, iccid=None):
         # commandline options we can use that info, otherwise we guess that
         # the length is 2, which is also the most common case.
         if opts.mnclen != "auto":
-            if opts.mnclen is "2":
+            if opts.mnclen == "2":
                 row['mnc'] = row.get('mnc', mnc_from_imsi(row.get('imsi'), False))
-            elif opts.mnclen is "3":
+            elif opts.mnclen == "3":
                 row['mnc'] = row.get('mnc', mnc_from_imsi(row.get('imsi'), True))
             else:
                 raise ValueError("invalid parameter --mnclen, must be 2 or 3 or auto")

provisioning seems to work fine.

I have checked this back with current master and --mnclen 3 and --mnclen 3, with pySim-shell I can confirm that EF.AD changes accordingly. We should try to reproduce the problem on the card programming setup.

I think I found the reason why it still works on my machine. The cards I am using are programmed with a different profile. Apparently the EF.AD in ADF.USIM is now an individual file and not a link to the EF.AD in DF.GSM. I am actually surprised that this is the case. A solution could be to select both files and program them both with the same content.

I have now fixed the problem. EF.AD is now also programmed under ADF.USIM:
https://gerrit.osmocom.org/c/pysim/+/31004 cards: also program EF.AD under ADF.USIM [NEW]

I still wonder why EF.AD is no longer linked to a single file. pySim-prog.py relies on the assumption that when the files in DF.GSM are written that then the corresponding files in ADF.USIM are updated as well. There are a few other files where it works the same way. I wonder if those need attention now. I could check it with an experiment, but then I need one of those new cards I can freely experiment with.

Here is a list of the potentially affected files:
EF.IMSI (seems to be ok)
EF.PLMNsel
EF.PLMNwAcT
EF.OPLMNwAcT
EF.HPLMNwAcT
EF.SMSP

seems to work, the phone is happy now.

roh thanks for trying it out.

sysmo-isim-tool_sja2 had the same problem. I have fixed that now as well. I am a bit unsure if we should program all linked files in all locations. Is there any opinion about that? Are we expecting spec changes that require us to unlink files all too soon?

On Thu, Jan 19, 2023 at 11:33:30AM +0000, dexter wrote:

sysmo-isim-tool_sja2 had the same problem. I have fixed that now as well. I am a bit unsure if we should program all linked files in all locations. Is there any opinion about that? Are we expecting spec changes that require us to unlink files all too soon?

you could always check the FCP if they are linked or not. That's probably the best approach as it will always work, no matter of the detailed card profile.

I wasn't aware that the link state is in the FCP. That allows us to detect if we should write the second location or leave it as it is. This might be helpful in more complex situations where we have to add an IE to a file that isn't present in the other for example. For the EF.AD, things should be fine now. We just read a the file and only modify the MNCLEN field and then we write it back. So we won't mix up things even when we write the second (linked) location.

My question is more about, do we want to keep everything as it is or do we want to write all files in all locations now in case we have to change the profile again?

I think introducing and using some generic function that checks if the file exists a second time and is not linked would be useful. The beat approach is probably to store the (path of) the sister file in the CardEF class. So this way some generic code can

• determine if the spec allows for a "sister" file somewhere else (and where!)
• determine if the current card has that sister file
• determine if the current card links the two files or not

But let's please hold back on this until the unit test patches are merged to avoid any conflicts

laforge wrote in #note-16:

But let's please hold back on this until the unit test patches are merged to avoid any conflicts

This has been done quite some time ago, yet this ticket is "urgent" and "in progress" without any updates?