Hi Harald,<br><br>I don't know if you saw that first email when I posted it (see below for reference), but I still can't decide where to put the trans_free. From the code, it's obvious you thought about it but apparently didn't decide yet since all call to it are commented :)<br>
<br>In gsm411_rx_rp_ack(...) there is a comment saying "/* do not free the transaction here, this is done by sending CP-ACK */", however this is no longer true, the method sending the cp_ack is now called _before_ gsm411_rx_rp_ack and so doesn't free up the transaction anymore (the trans_free call in gsm411_tx_cp_ack is commented out).<br>
<br>To me gsm411_rx_rp_ack sounds like the right place to do it but if you wrote that comment in the first place I guess you had reason not to do it there. Could you elaborate on that ?<br><br>    Sylvain<br><br><br><div class="gmail_quote">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I've noticed a problem when delivering several SMS to a mobile back-to-back.<br>The first one is ok, the second one is received by the MS but OpenBSC fails with "RX RP-ACK but no sms in transaction?!?" when receiving the "RX SMS RP-ACK (MO)"<br>
(full log below)<br><br>From the symptoms and looking at the code, I would say that the transaction of the first SMS delivery was not freed, therefore, when we receive the RP-ACK of the second SMS, we do a trans_find_by_id in gsm0411_rcv_sms, and we actually find the transaction of the _first_ deliver (which has its .sms field cleared since it was released already).<br>
<br>I think you wouldn't notice if you waited between SMS because SMC Timer TC1* would expire, calling trans_free().<br><br>The problem is that I don't really know _where_ trans_free should be called. There are commented out call to it at several places ...<br>
I would think the RP-ACK(MO) reception looks like a good place. But OTOH, this whole process can queue data, giving away a reference to lchan (without get) and trans_free does a put on lchan (so I guess that could invalidate the lchan ref that was queued ? didn't check that in details)<br>
<br></blockquote><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">   Sylvain<br><br><br>--- SNIP ---<br><0100> gsm_04_11.c:920 send_sms_lchan()<br>
<0002> transaction.c:69 subscr=0x1fe52d0, subscr->net=0x1f8fc30<br><0002> gsm_subscriber_base.c:131 subscr 46332 usage increases usage to: 4<br><0002> gsm_04_11.c:937 lchan (bts=0,trx=0,ts=0,ch=0) increases usage to: 1<br>
<0100> gsm_04_11.c:972 TX: SMS DELIVER<br><0100> gsm_04_11.c:188 TX: CP-DATA trans=4<br><0100> gsm_04_11.c:149 GSM4.11 TX 49 01 1e 01 2a 07 91 44 77 58 10 06 50 00 12 00 05 b9 72 65 f7 00 00 90 80 72 12 03 41 00 02 44 3a<br>
<0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA INDICATION<br><0100> gsm_04_11.c:817 trans_id=c RX SMS CP-ACK<br><0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA INDICATION<br>
<0100> gsm_04_11.c:817 trans_id=c RX SMS CP-DATA<br><0100> gsm_04_11.c:191 TX: CP-ACK trans=4<br><0100> gsm_04_11.c:149 GSM4.11 TX 49 04<br><0100> gsm_04_11.c:750 RX SMS RP-ACK (MO)<br><0002> gsm_subscriber_base.c:139 subscr 27567 usage decreased usage to: 0<br>
<0002> gsm_subscriber_base.c:139 subscr 46332 usage decreased usage to: 3<br>DB: Found Subscriber: ID 2, IMSI 206205003327508, NAME '', TMSI 1666608304, EXTEN '27567', LAC 1, AUTH 1<br>DBI: -7: The requested variable type does not match what libdbi thinks it should be<br>
<0002> gsm_subscriber_base.c:131 subscr 46332 usage increases usage to: 4<br><0100> gsm_04_11.c:920 send_sms_lchan()<br><0002> transaction.c:69 subscr=0x1fe52d0, subscr->net=0x1f8fc30<br><0002> gsm_subscriber_base.c:131 subscr 46332 usage increases usage to: 5<br>
<0002> gsm_04_11.c:937 lchan (bts=0,trx=0,ts=0,ch=0) increases usage to: 2<br><0100> gsm_04_11.c:972 TX: SMS DELIVER<br><0100> gsm_04_11.c:188 TX: CP-DATA trans=4<br><0100> gsm_04_11.c:149 GSM4.11 TX 49 01 1f 01 2a 07 91 44 77 58 10 06 50 00 13 00 05 b9 72 65 f7 00 00 90 80 72 12 03 41 00 03 47 39 19<br>
<0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA INDICATION<br><0100> gsm_04_11.c:817 trans_id=c RX SMS CP-ACK<br><0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA INDICATION<br>
<0100> gsm_04_11.c:817 trans_id=c RX SMS CP-DATA<br><0100> gsm_04_11.c:191 TX: CP-ACK trans=4<br><0100> gsm_04_11.c:149 GSM4.11 TX 49 04<br><0100> gsm_04_11.c:750 RX SMS RP-ACK (MO)<br><0100> gsm_04_11.c:640 RX RP-ACK but no sms in transaction?!?<br>
<0100> gsm_04_11.c:561 TX: SMS RP ERROR, cause 111 (Protocol Error)<br><0100> gsm_04_11.c:188 TX: CP-DATA trans=4<br><0100> gsm_04_11.c:149 GSM4.11 TX 49 01 04 05 2a 01 6f<br><0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA INDICATION<br>
<0100> gsm_04_11.c:817 trans_id=c RX SMS CP-ACK<br><0100> gsm_04_11.c:159 SMC Timer TC1* is expired, calling trans_free()<br><0002> transaction.c:101 lchan (bts=0,trx=0,ts=0,ch=0) decreases usage to: 1<br>
<0002> gsm_subscriber_base.c:139 subscr 46332 usage decreased usage to: 4<br>--- /SNIP ---</blockquote></div><br>