PNLM list overwritten

[Brandon Creighton]

I've seen similar behavior before -- particularly trying to write
EF.PLMNSEL, EF.FPLMN, and EF.{O,H,}PLMNwACT on some US-carrier SIMs.

This seems to be worse in the ones from AT&T MVNOs (I've tried ones
from Red Pocket and H2O).  Generally, the write just fails; but I
believe I've observed some EFs get reset after a successful
write/read.  Are you getting a valid response from the UPDATE BINARY
command?

Unfortunately, I haven't found a reasonable workaround for this.  One
ugly hack that seemed to work with some SIMs on an HTC One V (a recent
Android phone ), is "priming" the SIM by first registering to the
network using a old Nokia 3310 or similar; the connected data is
stored on the SIM (EF.LOCI, I imagine?  I actually never figured out
why this worked.) and is good for a one-time use in the smartphone.

Writable or custom SIMs are reasonably inexpensive, so for anything
over a handful of devices in a test network (with manual network
selection), that's probably the way to go..

Are you operating as MCC=001 MNC=01 (test network)?

(Apologies to the list if this is the wrong venue for this.)


On Fri, Sep 7, 2012 at 8:15 AM, Dario Lombardo
<dario.lombardo.ml at gmail.com> wrote:
> Hil list
> Today I've observed a strange behaviour when modifying the PNLM of
> some real networks expired sims (to be used with osmocom and openbts).
> I've put 001 01 on the top of the list. I've ejected and reinsterted
> the sim in the reader many times, and I'm sure that the value has been
> wrtitten.
> When trying to connect to my test operator I get the message "your sim
> card doesn't allow the connection to this network operator" from my
> android phone.
> Reading again the pnlm I see that the original list has been restored.
> This astonishes me... Is is possible that the SIM overwrites the list
> by itselt? Or is it the phone that does it? The android has an
> original, not branded, operating system.
> Thanks everybody for your help.
> Dario
>