On Wed, Jun 03, 2009 at 09:59:11AM +0200, Andreas.Eversberg wrote: are you familiar enough with the protocol to make this kind of statement? I wouldn't be sure. But if you say that switching LAC with IMSI Attach/Detach enabled works this way, ok. The reason I'm asking is that the phone would have to first go to a different ARFCN, sync to it and send some message, and then go back to the old one. This sounds really strange to me. What if you're in a fast moving vehicle and can no longer go back to the old cell/LAC? I would assume that an attach in a new LAC would implicitly be treated as a detach in the old cell, without any explicit IMSI DETACH message. Wikipedia is certainly not the definitive anwer, but as you can see at http://en.wikipedia.org/wiki/IMSI_attach it claims that ATTACH is only performed at the initial switch-on. Later on, it does a regular Location Update. The 04.08 chyapter 4.4.3 says: ===== The IMSI attach procedure is invoked if the detach/attach procedures are required by the network and an IMSI is activated in a mobile station (i.e. activation of a mobile station with plug-in SIM, insertion of a card in a card-operated mobile station etc.) within coverage area from the network or a mobile station with an IMSI activated outside the coverage area enters the coverage area. The IMSI attach procedure is used only if the update status is UPDATED and if the stored Location Area Identification is the same as the one which is actually broadcasted on the BCCH of the current serving cell. Otherwise a normal location updating procedure (see sub-clause 4.4.1) is invoked independently of the ATT flag indication. ===== So we will certainly get a Loaction Update both on initial phone power-up, as well as when we switch from one LAC to another. We don't really care if it's a IMSI ATTACH type or other type Location Update. The IMSI DETACH (section 4.3.4) doesn't say anything about changing location area. it is only sent once the SIM is deactivated/removed or the phone switched off. I don't think we need this, see above. But what I'm thinking right now is whether we have a DoS here, if somebody spoofs tons of IMSI DETACH messages. But well, not our primary concern right now. As soon as authentication and ciphering is used, it's not that much of an issue anymore anyway. Yes. The 'current_bts' pointer goes back to a time where at least I (and presumably Holger, too) did not yet fully understand the option of a LAC consisting of multiple BTS. So yes, I think it should be removed. What we'd rather need is a pointer to the current RR (or MM?) connection, if any. So if we have some MT call or other service request, we look up the subscriber and can either use an existing RR/MM connection, or if that one doesn't exist, we fall back to paging of all BTS in the LAC. The RR/MM connection is represented by what we call "lchan" right now. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)