7 Sep
2012
7 Sep
'12
6:02 p.m.
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(a)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