This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
David A. Burgess dburgess at jcis.netOn Jun 24, 2009, at 8:50 AM, Nordin wrote: > Thanks for your post David, > > Well that sounds strange, this means that if I turn off my pda > phone in Holland and turn it on in France, my pda phone won't > register because of non-standard TMSI issue? I doubt about that. No. It means the PDA might first try to register with that Dutch TMSI and then the network will need to explicitly request the IMSI. It's not supposed to use that Dutch TMSI in France, but it might try if there's a bug in its GSM stack. > The case is, I don't even see any transaction between OpenBSC and > the PDA phone from the debugging of bsc_hack. I have the feeling > that the PDA phone don't even do any request based on System > Informations provided by the BCCH of the bsc_hack. Ah. Sorry. You are probably correct then. There's something about the BCCH that the phone doesn't like. > As far as I know, we don't do TMSI resolution. We kind of like > saying "hey PDA, I don't want the TMSI, just give me your IMSI > instead" and so the PDA "should" drop the TMSI as it's TEMPRORAY > MSI anyway. If that's how it works. That's part of what I mean by TMSI resolution: if you can't recognize or support the TMSI, turn around and request the IMSI. The problem, sometimes, is that some phones don't drop the TMSI. They insist on using it, even when it should have been invalidated. The only way we could get the Treo 650 to stop sending us AT&T's old TMSI was to assign it one of our own. > > c u later... Not if I c u first... ;-) -- David >