From: David A. B. <dbu...@jc...> - 2009-06-24 15:28:29
|
Holger - [OpenBTS - I'm cross posting this from OpenBSC.] A problem we had with a lot of PDA phones in OpenBTS was that they would attempt to register or access CM services by TMSI, even when our system had a different MCC/MNC/LAC and even when we had not yet assigned a TMSI. I first saw this with a Palm Treo 650 but have seen it with other PDA phones since then. I suspect a lot of them are using the same broken GSM chipset that does not follow the standard's TMSI invalidation rules. I don't know what you do for TMSI resolution in OpenBSC, but if you don't handle this case correctly you will have problems with these handsets. -- David On Jun 24, 2009, at 7:33 AM, Holger Freyther wrote: > > >> But Holger, do you also have registering issues with pda-phones, like >> the HTC or maybe even the iPhone? > > I remember we had some problems with the PDA phones at the 25C3, I > currently > have no physical access to any BTS and can't do tests. > > z. David A. Burgess Kestrel Signal Processing, Inc. |
From: Nordin <bou...@gm...> - 2009-06-24 15:50:53
|
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. 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. 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. c u later... David A. Burgess schreef: > Holger - > > [OpenBTS - I'm cross posting this from OpenBSC.] > > A problem we had with a lot of PDA phones in OpenBTS was that they > would attempt to register or access CM services by TMSI, even when our > system had a different MCC/MNC/LAC and even when we had not yet > assigned a TMSI. I first saw this with a Palm Treo 650 but have seen > it with other PDA phones since then. I suspect a lot of them are > using the same broken GSM chipset that does not follow the standard's > TMSI invalidation rules. I don't know what you do for TMSI resolution > in OpenBSC, but if you don't handle this case correctly you will have > problems with these handsets. > > -- David > > > On Jun 24, 2009, at 7:33 AM, Holger Freyther wrote: > >> >> >>> But Holger, do you also have registering issues with pda-phones, like >>> the HTC or maybe even the iPhone? >> >> I remember we had some problems with the PDA phones at the 25C3, I >> currently >> have no physical access to any BTS and can't do tests. >> >> z. > > > David A. Burgess > Kestrel Signal Processing, Inc. > > > > > > |
From: David A. B. <dbu...@jc...> - 2009-06-24 16:23:48
|
On 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 > |
From: Nordin <bou...@gm...> - 2009-06-25 07:46:34
|
> 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). > 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. > 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. > 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? :) |
From: David A. B. <dbu...@jc...> - 2009-06-25 15:59:01
|
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. |
From: Nordin <bou...@gm...> - 2009-06-26 09:15:13
|
> 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. Well, I already did that by using some traces I found in http://wiki.thc.org/. There I copied some values for GPRS support and changed that in OpenBSC source. Also added the missing SI 13 to the source, which contains some more info about the GPRS, but without success. > 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. In OpenBSC (I have older version, didn't do any updates yet) There are SI 1 to 4 that are filled and the Rest Octets (in SI 3 and SI 4) are filled with 0x2B, which the MS should ignore and thus it also indicates no GPRS support. > 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. Exactly, that's my assumption too. But as my collegue once said "Assumption is the mother of all f@ck" from a movie scene of Steven Seagal's film Under Siege 2. The fact is, it should/must work with BTSs without GPRS, so I think some important basic information on the BCCH is not complete and thus maybe corrupt in a certain way. Cause the same problem also occurs with the BS11 BTS according to other guys in the list. So I'll concentrate more on the BCCH and try to understand it carefully. > Sorry. It's joking response: If I see you coming, I will hide. Just > a joke, though. No need for appolagize, I like jokes too :p It's funny we laugh about jokes. Actually, we should always laugh and laugh harder when we hear a joke. The world would be so beautiful than. Greetings, Laughing Nordin. |
From: Nordin <bou...@gm...> - 2009-07-03 09:23:10
|
Hello guys, As I am not an experienced GSM engineer I can't fully understand the GSM specs. But I found this in paragraph 4.1.1.2.1 of GSM 04.08: "NOTE: Whenever GMM performs a combined GMM procedure, a GPRS MS enters the MM state MM LOCATION UPDATING PENDING in order to prevent the MM to perform a location update procedure." Since we haven't done anything for GPRS support, this might be the reason why a location update is not performed with bsc_hack. Once again, I'm a beginner on this field and still need some more readings and learning of GSM and OpenBSC sources. But I hope I found the part that might lead you to solve the GPRS supported mobiles registering issue. P.S.: Is everybody on holiday...:) |
From: Harald W. <la...@gn...> - 2009-07-04 08:51:42
|
On Fri, Jul 03, 2009 at 11:21:59AM +0200, Nordin wrote: > As I am not an experienced GSM engineer I can't fully understand the GSM > specs. > But I found this in paragraph 4.1.1.2.1 of GSM 04.08: > "NOTE: > Whenever GMM performs a combined GMM procedure, a GPRS MS enters the MM > state > MM LOCATION UPDATING PENDING in order to prevent the MM to perform a > location update procedure." I think the way OpenBSC is working (or at leats supposed to work), we don't permit for any combined GMM procedures but rather tread GSM and GPRS entirely separate. I don't remember the terminology, but there are three entirely different methods on how MM and GMM interact. They probably reflect the evolvement of GSM equipment. The simplest case to move forward for us is to keep GSM and GPRS entirely separate, i.e. not risking any regressions due to the inclusion of GPRS support (if at all, at some point). I strongly believe the problem is related to our SYSTEM INFROMATION headers, but I currently don't have the time to debug/verify the implementation that I did for it in some git branch... > P.S.: Is everybody on holiday...:) no, working full-time on GSM security right now. -- - Harald Welte <la...@gn...> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) |