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 25, 2009, at 12:46 AM, Nordin wrote: > >> 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. > > Well I'm sorry, but I'm still not convinced about that. Cause that > would be a major bug, which won't be accepted by the biggest user > group for PDA phones (like business men, or presidents like Obama). I agree that it is a major bug and a security risk for high-profile users, but it is real. The users might reject it if they knew, but most have no way of knowing, unless, of course, someone publishes a report on it and to my knowledge nobody has. (OK, except for Obama. You can bet someone competent has done an analysis of his PDA.) > >> Ah. Sorry. You are probably correct then. There's something >> about the BCCH that the phone doesn't like. > > That's I think is most likely the case. It would be great if someone with an OpenBTS system could turn on debugging messages and capture the raw bits from our system information messages 1-4 and send them to you for you to try in your OpenBSC build. I'd do it myself but I am traveling a lot lately and don't have the equipment with me. I looked at the BCCH messages in OpenBSC yesterday, but could not identify the problem. I don't know how OpenBSC handles the "rest octets" at the ends of these messages, but it is important that these be properly padded with the GSM filler pattern if you are not coding anything there. This is especially important for high-feature phones that might actually be looking for GPRS parameters. It is also important to present the BCCH messages in the correct sequence and with the timing given in GSM 05.02 6.3.1.3, but I suspect your BTS takes care of that for you. > >> 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. > > Yeah, that is what OpenBSC does, I think. But Harald, Holger, > Dieter and others know more about it. > >> The problem, sometimes, is that some phones don't drop the >> TMSI. They insist on using it, even when it should have been >> invalidated. > > In that case, I would see some negotiations from the debug > bsc_hack, which there is not. So my assumption is still some > missing information in the BCCH channel. Cause once again, trying > to register to my BTS manually failed and I don't see any attempt > to do just a simple Radio Resource request. The latter one I can't > confirm that for 100 %, because it's possible the debug doesn't > show all of that. I agree with your analysis. If the handset actually sees the network, then you do not have a frequency offset problem. Therefore, if you do not see channel requests coming from the phone via the BTS the most likely explanation is that the phone has found some inconsistency in the BCCH. > >> 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. > > Well, at least the Treo talked to you. > >>> >>> c u later... >> >> Not if I c u first... ;-) > uhhhh....c u soon? :) Sorry. It's joking response: If I see you coming, I will hide. Just a joke, though. > -- David David A. Burgess Kestrel Signal Processing, Inc.