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@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