As horiz0n on IRC points out: 00:16 <horiz0n> hehe, calling the c123 from my 9500 communicator crashes openbsc 00:17 <horiz0n> here is the log http://notepad.cc/share/LQ3awCtXz9 00:21 <horiz0n> and here the debug log http://notepad.cc/share/tPJYXo3SJG
<0000> abis_rsl.c:1388 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION <0003> gsm_04_08.c:1109 CIPHERING MODE COMPLETE <0003> gsm_04_08_utils.c:197 Sending Channel Release: Chan: Number: 0 Type: 2 <0004> abis_rsl.c:586 (bts=0,trx=0,ts=1,ss=0) DEACTivate SACCH CMD <0000> chan_alloc.c:363 (bts=0,trx=0,ts=1,ss=0) Recycling Channel <0000> abis_rsl.c:1388 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION ./runbsc.sh: line 6: 1179 Segmentation fault sudo ./bsc_hack -e 1 -d DINP:DNM:DRSL:DRR:DMM:DCC:DRLL:DMNCC:DSMS:DPAG,0:0:0
So what happens: We get a CM Service request, then go through authentication and ciphering. At that point, the network decides to release the channel and the channel is not completely closed yet (only SACCH deactivated) when we get an incoming SETUP message.
This message is treated as a new message (msc_compl_l3, but it has no conn->subscr and the code segfaults in trans_find_by_id(subscr=NULL, ...)
So I think there are actually multiple bugs. 1) the channel should not be released at that time 2) we have some kind of a race condition at channel release, where incoming messages should either be discarded _or_ should still be processed with all the data structures intact.
Cheers, Harald
On 07/04/2010 02:25 PM, Harald Welte wrote:
So I think there are actually multiple bugs.
- the channel should not be released at that time
Yeah, the MSC code should look at the request type of the CM Service Request and create a transaction (e.g. for SMS, CC) and start a timeout to terminate the transaction when nothing has happened.
- we have some kind of a race condition at channel release, where incoming messages should either be discarded _or_ should still be processed with all the data structures intact.
Well, it is a bug on a higher level. The MSC code decides to release the lchan because there is no transaction and operation left to execute, it calls the gsm0808_clear method which will free the subscriber_connection_data and will call lchan_release on all open lchan's.
Now if more data is coming, the bsc_api code sees there is no connection inside the lchan and will create one and call the complete layer3 callback... and somehow the MSC code assumes that there is a subscriber set inside the subscriber_connection_data, which is not the case.
Long story short, abis_rsl.c should probably not forward data when being in state REL_REQUEST and we should create a transaction for CC/SMS/USSD.
On 07/04/2010 03:23 PM, Holger Hans Peter Freyther wrote:
Long story short, abis_rsl.c should probably not forward data when being in state REL_REQUEST and we should create a transaction for CC/SMS/USSD.
Hi, I have done the following:
1.) In bsc_api.c only forward when the lchan->state is ACTIVE 2.) Create a dummy operation to keep the channel active in the beginning so we have five seconds for a transaction to handle it, I am releasing the "anchor" on the first CC/USSD/SMS/LU to free the channel fast.
What should be done:
We should create a transaction instead but I am not sure if we can derive the transaction id from the CM Service Request. Can we?
-
Harald Welte -
Holger Hans Peter Freyther