From: David A. B. <dbu...@jc...> - 2009-01-09 20:09:39
|
Alex - [Sorry if you get two copies. I'm having mail problems today.] That means that OpenBTS is probably fully functional. Your problem is simply one of getting the handset provisioned in Asterisk. What you are getting here is a TMSI, not an IMSI. The phone SHOULD be sending an IMSI, since it should know that the old TMSI is meaningless in the new network. This is happening because the handset's GSM stack violates the location updating rules of GSM 04.08. This is a common enough handset bug that the OpenBTS location updating code should deal with it automatically, but since it doesn't do that yet, you'll need to get the handset to invalidate its own TMSI. The surest way to do that is to power off the handset, remove the battery and SIM, then reassemble it all and power it back on. Then hope that the handset sees your OpenBTS before it finds the real network and gets another TMSI. Once you get an IMSI, you can use the attached script to provision it in Asterisk. -- David  On Jan 9, 2009, at 4:50 AM, Alexsander Loula wrote: > Hi David, > > I got a Motorola A1200 that seems to work with OpenBTS. I'm seeing > these messages: > > 1231504673.423354 2980133776: DCCHDispatch.cpp:105 ControlLayer > DCCHDisptacher waiting for SDCCH ESTABLISH > 1231504919.403355 2987056016: RadioResource.cpp:134 ControlLayer > AccessGrantResponder RA=24 when=0:205381 > 1231504919.404181 2987056016: RadioResource.cpp:169 ControlLayer > AccessGrantResponder sending PageMode=(0) DedicatedModeOrTBF=(TMA=0 > Downlink=0 DMOrTBF=0) ChannelDescription=(typeAndOffset=SDCCH/4-3 > TN=0 TSC=0 ARFCN=10) RequestReference=(RA=24 T1'=26 T2=7 T3=4) > TimingAdvance=0 > 1231504919.872491 2980133776: ControlCommon.cpp:347 ControlLayer > getMessage got primitive=DATA raw= > (000001010000100000100000001001111111010001010000000000000110111100110 > 011000001011111010000110000000000111101001110100010) > 1231504919.872600 2980133776: DCCHDispatch.cpp:109 ControlLayer > DCCHDispatcher got MM Location Updating Request MobileIdentity= > (TMSI=0x3003d3a2) > 1231504919.872627 2980133776: MobilityManagement.cpp:109 > ControlLayer LocationUpdatingController MM Location Updating > Request MobileIdentity=(TMSI=0x3003d3a2) > 1231504919.872638 2980133776: MobilityManagement.cpp:140 > ControlLayer LocationUpdatingController : SIPRegistration -> FAILED > > Now I need to program the IMSI on extension.conf, right? > > Tks, > Alex David A. Burgess Kestrel Signal Processing, Inc. |
From: Alexsander L. <ale...@gm...> - 2009-01-09 20:35:52
|
Hi David, I got new phones and SIM Cards and I got then registering under OpenBTS. The phones are the iPhone (2G - unlocked) and Motorola A1200. I tried to make calls from A1200 to iPhone and vice-verse, but the OpenBTS900 stopped to work after phone started to ring. Did you see it before? This is because those phones are not fully supported by OpenBTS? Thanks again for your great support! Alex 2009/1/9 David A. Burgess <dbu...@jc...> > Alex - > > [Sorry if you get two copies. I'm having mail problems today.] > > That means that OpenBTS is probably fully functional. Your problem is > simply one of getting the handset provisioned in Asterisk. > > What you are getting here is a TMSI, not an IMSI. The phone SHOULD be > sending an IMSI, since it should know that the old TMSI is meaningless in > the new network. This is happening because the handset's GSM stack violates > the location updating rules of GSM 04.08. > > This is a common enough handset bug that the OpenBTS location updating code > should deal with it automatically, but since it doesn't do that yet, you'll > need to get the handset to invalidate its own TMSI. The surest way to do > that is to power off the handset, remove the battery and SIM, then > reassemble it all and power it back on. Then hope that the handset sees > your OpenBTS before it finds the real network and gets another TMSI. > > Once you get an IMSI, you can use the attached script to provision it in > Asterisk. > > -- David > > > > > > On Jan 9, 2009, at 4:50 AM, Alexsander Loula wrote: > > Hi David, > > I got a Motorola A1200 that seems to work with OpenBTS. I'm seeing these > messages: > > 1231504673.423354 2980133776: DCCHDispatch.cpp:105 ControlLayer > DCCHDisptacher waiting for SDCCH ESTABLISH > 1231504919.403355 2987056016: RadioResource.cpp:134 ControlLayer > AccessGrantResponder RA=24 when=0:205381 > 1231504919.404181 2987056016: RadioResource.cpp:169 ControlLayer > AccessGrantResponder sending PageMode=(0) DedicatedModeOrTBF=(TMA=0 > Downlink=0 DMOrTBF=0) ChannelDescription=(typeAndOffset=SDCCH/4-3 TN=0 TSC=0 > ARFCN=10) RequestReference=(RA=24 T1'=26 T2=7 T3=4) TimingAdvance=0 > 1231504919.872491 2980133776: ControlCommon.cpp:347 ControlLayer getMessage > got primitive=DATA > raw=(000001010000100000100000001001111111010001010000000000000110111100110011000001011111010000110000000000111101001110100010) > 1231504919.872600 2980133776: DCCHDispatch.cpp:109 ControlLayer > DCCHDispatcher got MM Location Updating Request > MobileIdentity=(TMSI=0x3003d3a2) > 1231504919.872627 2980133776: MobilityManagement.cpp:109 ControlLayer > LocationUpdatingController MM Location Updating Request > MobileIdentity=(TMSI=0x3003d3a2) > 1231504919.872638 2980133776: MobilityManagement.cpp:140 ControlLayer > LocationUpdatingController : SIPRegistration -> FAILED > > Now I need to program the IMSI on extension.conf, right? > > Tks, > Alex > > > > David A. Burgess > Kestrel Signal Processing, Inc. > > > > > > |
From: David A. B. <dbu...@jc...> - 2009-01-09 20:54:39
|
Alex - Here's what I'm going to request: (1) Try a call from the iPhone to a known-good termination, like Zoiper or a PAP2 phone. (2) Try a call from a known-good SIP client to the iPhone. In both cases, please collect the control layer logs (OpenBTS900 | grep Control) and please send them to me. Clearly, the iPhone exercises some bug. Hopefully we can find and fix it and get out another release. The new release can include a fix for the TMSI problem, too. -- David On Jan 9, 2009, at 12:35 PM, Alexsander Loula wrote: > Hi David, > > I got new phones and SIM Cards and I got then registering under > OpenBTS. The phones are the iPhone (2G - unlocked) and Motorola > A1200. I tried to make calls from A1200 to iPhone and vice-verse, > but the OpenBTS900 stopped to work after phone started to ring. > > Did you see it before? This is because those phones are not fully > supported by OpenBTS? > > Thanks again for your great support! > > Alex David A. Burgess Kestrel Signal Processing, Inc. |
From: Alexsander L. <ale...@gm...> - 2009-01-09 22:06:25
|
I'll do it Monday morning... 2009/1/9 David A. Burgess <dbu...@jc...> > Alex - > Here's what I'm going to request: > > (1) Try a call from the iPhone to a known-good termination, like Zoiper or > a PAP2 phone. > > (2) Try a call from a known-good SIP client to the iPhone. > > In both cases, please collect the control layer logs (OpenBTS900 | grep > Control) and please send them to me. Clearly, the iPhone exercises some > bug. Hopefully we can find and fix it and get out another release. The new > release can include a fix for the TMSI problem, too. > > -- David > > On Jan 9, 2009, at 12:35 PM, Alexsander Loula wrote: > > Hi David, > > I got new phones and SIM Cards and I got then registering under OpenBTS. > The phones are the iPhone (2G - unlocked) and Motorola A1200. I tried to > make calls from A1200 to iPhone and vice-verse, but the OpenBTS900 stopped > to work after phone started to ring. > > Did you see it before? This is because those phones are not fully supported > by OpenBTS? > > Thanks again for your great support! > > Alex > > > > David A. Burgess > Kestrel Signal Processing, Inc. > > > > > |
From: Alfonso De G. <ad...@cr...> - 2009-01-16 16:30:12
|
Hello David, David A. Burgess ha scritto: > The bottom line is that the stuff in CommonLibs/Threads needs to be > patched to work under most Linux variants. I particularly suspect the > pthread_cond_timedwait does not behave as documented. I have taken a look into the method implementing the timed condition wait. There we need to take into account the possibility (and this is what actually happens in most Linux variants) to observe spurious wakeups from the pthread_cond_timedwait() - the function occasionally returns even though the condition variable wasn't signaled or broadcast. According to the POSIX specs, in case of spurious wakeups pthread_cond_timedwait() and pthread_cond_wait() are required to return zero: http://opengroup.org/onlinepubs/007908799/xsh/pthread_cond_wait.html For this exact reason, the predicate associated to the condition wait needs to be re-evaluated upon such return and the function eventually invoked again. Why are we observing this behaviour in Linux? This seems to be related to the use of futex in the pthread_cond_timedwait() implementation on Linux http://en.wikipedia.org/wiki/Spurious_wakeup. As each blocking lnx syscall, futex returns abruptly when the process receives a signal. Here it is a patch proposal: /** Block for the signal up to the cancellation timeout. */ void Signal::wait(Mutex& wMutex, unsigned timeout) const { int rc = 0; Timeval then(timeout); struct timespec waitTime = then.timespec(); while (! then.passed() && rc == 0) rc = pthread_cond_timedwait(&mSignal,&wMutex.mMutex,&waitTime); } As far as I can tell, this does not explains the high CPU load. Cheers, -- Alfonso De Gregorio http://Crypto.lo.gy/ |
From: David A. B. <dbu...@jc...> - 2009-01-16 17:34:57
|
Alfonso - Thanks for the excellent research on that. I agree that your proposed changes should solve the spurious wake-up problem. I can easily imagine how spurious wake-ups could cause CPU consumption problems. There are several loops in the code that block on pthread condition variables with timeouts. If spurious wake-ups are too frequent, these loops could be spinning fast instead of blocking the way they were designed to do. Another possibility to explain the high CPU consumption is some unexpected behavior of usleep, like quantization of ulseep parameters causing usleep calls with wait times too short to return immediately, or (horrors!) usleep might be implemented as a spin-wait in Linux. -- David On Jan 16, 2009, at 8:29 AM, Alfonso De Gregorio wrote: > Hello David, > > David A. Burgess ha scritto: > >> The bottom line is that the stuff in CommonLibs/Threads needs to >> be patched to work under most Linux variants. I particularly >> suspect the pthread_cond_timedwait does not behave as documented. > > I have taken a look into the method implementing the timed > condition wait. > There we need to take into account the possibility (and this is > what actually happens in most Linux variants) to observe spurious > wakeups from the pthread_cond_timedwait() - the function > occasionally returns even though the condition variable wasn't > signaled or broadcast. > > According to the POSIX specs, in case of spurious wakeups > pthread_cond_timedwait() and pthread_cond_wait() are required to > return zero: http://opengroup.org/onlinepubs/007908799/xsh/ > pthread_cond_wait.html > For this exact reason, the predicate associated to the condition > wait needs to be re-evaluated upon such return and the function > eventually invoked again. > > Why are we observing this behaviour in Linux? This seems to be > related to the use of futex in the pthread_cond_timedwait() > implementation on Linux http://en.wikipedia.org/wiki/ > Spurious_wakeup. As each blocking lnx syscall, futex returns > abruptly when the process receives a signal. > > Here it is a patch proposal: > > /** Block for the signal up to the cancellation timeout. */ > void Signal::wait(Mutex& wMutex, unsigned timeout) const > { > int rc = 0; > Timeval then(timeout); > struct timespec waitTime = then.timespec(); > > while (! then.passed() && rc == 0) > rc = pthread_cond_timedwait > (&mSignal,&wMutex.mMutex,&waitTime); > } > > > As far as I can tell, this does not explains the high CPU load. > > Cheers, > > -- > Alfonso De Gregorio http://Crypto.lo.gy/ David A. Burgess Kestrel Signal Processing, Inc. |
From: Alexsander L. <ale...@gm...> - 2009-02-19 18:40:07
|
Hi Alfonso, I have applied the suggested patch and the CPU load is worst than before. Itś consuming 100% on a Core 2 Duo 2.6 GHz. Without the patch the load is around 60%, but sometimes the transceiver crash. Anyone facing the same issue? Tks, Alex 2009/1/16 Alfonso De Gregorio <ad...@cr...> > Hello David, > > David A. Burgess ha scritto: > > The bottom line is that the stuff in CommonLibs/Threads needs to be >> patched to work under most Linux variants. I particularly suspect the >> pthread_cond_timedwait does not behave as documented. >> > > I have taken a look into the method implementing the timed condition wait. > There we need to take into account the possibility (and this is what > actually happens in most Linux variants) to observe spurious wakeups from > the pthread_cond_timedwait() - the function occasionally returns even though > the condition variable wasn't signaled or broadcast. > > According to the POSIX specs, in case of spurious wakeups > pthread_cond_timedwait() and pthread_cond_wait() are required to return > zero: http://opengroup.org/onlinepubs/007908799/xsh/pthread_cond_wait.html > For this exact reason, the predicate associated to the condition wait needs > to be re-evaluated upon such return and the function eventually invoked > again. > > Why are we observing this behaviour in Linux? This seems to be related to > the use of futex in the pthread_cond_timedwait() implementation on Linux > http://en.wikipedia.org/wiki/Spurious_wakeup. As each blocking lnx > syscall, futex returns abruptly when the process receives a signal. > > Here it is a patch proposal: > > /** Block for the signal up to the cancellation timeout. */ > void Signal::wait(Mutex& wMutex, unsigned timeout) const > { > int rc = 0; > Timeval then(timeout); > struct timespec waitTime = then.timespec(); > > while (! then.passed() && rc == 0) > rc = pthread_cond_timedwait(&mSignal,&wMutex.mMutex,&waitTime); > } > > > As far as I can tell, this does not explains the high CPU load. > > Cheers, > > -- > Alfonso De Gregorio http://Crypto.lo.gy/ > > |