On 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.