From: John Wu <jw...@gm...> - 2011-03-17 07:03:34
|
On Thu, Mar 17, 2011 at 2:07 PM, David A. Burgess <dbu...@jc...> wrote: > John - > > Oh my! I don't mean to criticize you personally or particularly here, but > this is important information to repeat sometimes and I hope lots of people > read this. > > You are doing at least one Very Bad Thing here and, from your reported > results, probably two: > > 1. You were probably testing in a band that is used for public cellular > service in your area, like 900 or 1800 in ITU regions 1 or 3 or 850 or 1900 > in ITU region 2. That is Bad. > > 2. You were spoofing your local public network. That's Especially Very > Bad. > > There are numerous posts in this mailing list warning against these things. > There are also specific instructions in the public wiki warning against > these things (like this: > http://gnuradio.org/redmine/wiki/gnuradio/OpenBTSMS_Camping). The default > configuration is MCC=001 MNC=01, a test network. You should not have > changed them unless you were absolutely sure what you were doing. > > So now your phones' SIMs "remember" that they cannot get service in your > network. The problem is that your network is identical to your local public > carrier, so they don't bother looking for service there either. Oops. > > So, what now? The only solution I can recommend is to power down every > phone, remove and reinsert the SIM and battery, and power back up. (And > what about iPhones, where you can't remove the SIM and battery? I have no > idea. I'll wager that a misconfigured BTS, regardless of the type, might > well "brick" an iPhone.) Anyway, if you are lucky, this battery removal > procedure will fix everything. There is a chance, though, that some SIMs > will "remember" that the name of the network is now "OpenBTS" and they will > may continue to show that name even after service is restored. I don't have > a good solution for that, but if you search the mailing list archives for > the subject line "they want to kill me", you might find something useful. > It is not so critical. After I close Openbts all cellphone can register to real network at present. Thanks! > > -- David > > A postscript, and THIS IS IN CAPS BECAUSE IT IS IMPORTANT: THE CELLULAR > NETWORK IS MORE DELICATE THAN THE IP NETWORK. IT WAS NOT DESIGNED WITH THE > EXPECTATION THAT RANDOM CIVILIANS WOULD EVER HAVE ACCESS TO NETWORK > EQUIPMENT. THERE ARE FEW SAFEGUARDS AGAINST ROGUE ACTORS IN L3. DON"T SCREW > WITH YOUR PHONE COMPANY; IT IS ILLEGAL AND THE THREAT TO PUBLIC SAFETY. > (Maybe someone should put that in the masthead of the public release just > to be sure everyone who runs OpenBTS see it.) > > > > On Mar 16, 2011, at 8:29 PM, John Wu wrote: > > I set MCC and MNC the same with local GSM network, and LAC keep the default > value 1000. > I have tried the reject code with 0x11 0x0C 0x05 0x16 all with the same > result. > Once my cell phone is rejected from Openbts it will not find other BTS and > just keep trying > register to OpenBTS. And my neighbour's cell phone also have the same > result. > > On Thu, Mar 17, 2011 at 11:11 AM, David A. Burgess <dbu...@jc...>wrote: > >> >> What where your MCC/MNC/LAC and what reject code did you send? >> >> And have you tried power-cycling the phone? >> >> On Mar 16, 2011, at 7:58 PM, John Wu wrote: >> >> > I dont want my cellphone to register to openbts so I reject it in the >> location update. >> > but after that my cell phone do not register to real network. Is it >> something to do with >> > LAC NCC or NCC permited? >> > >> > Regards! >> > >> ------------------------------------------------------------------------------ >> > Colocation vs. Managed Hosting >> > A question and answer guide to determining the best fit >> > for your organization - today and in the future. >> > >> http://p.sf.net/sfu/internap-sfd2d_______________________________________________ >> > Openbts-discuss mailing list >> > Ope...@li... >> > https://lists.sourceforge.net/lists/listinfo/openbts-discuss >> >> > > |