SMS delivery (Mobile Terminated): First ok, second fails

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Sylvain Munaut 246tnt at gmail.com
Tue Sep 22 22:16:38 UTC 2009


Hi Harald,

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 :)

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).

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 ?

    Sylvain


I've noticed a problem when delivering several SMS to a mobile back-to-back.
> 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)"
> (full log below)
>
> 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).
>
> I think you wouldn't notice if you waited between SMS because SMC Timer
> TC1* would expire, calling trans_free().
>
> 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 ...
> 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)
>
>

> Sylvain
>
>
> --- SNIP ---
> <0100> gsm_04_11.c:920 send_sms_lchan()
> <0002> transaction.c:69 subscr=0x1fe52d0, subscr->net=0x1f8fc30
> <0002> gsm_subscriber_base.c:131 subscr 46332 usage increases usage to: 4
> <0002> gsm_04_11.c:937 lchan (bts=0,trx=0,ts=0,ch=0) increases usage to: 1
> <0100> gsm_04_11.c:972 TX: SMS DELIVER
> <0100> gsm_04_11.c:188 TX: CP-DATA trans=4
> <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
> <0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA
> INDICATION
> <0100> gsm_04_11.c:817 trans_id=c RX SMS CP-ACK
> <0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA
> INDICATION
> <0100> gsm_04_11.c:817 trans_id=c RX SMS CP-DATA
> <0100> gsm_04_11.c:191 TX: CP-ACK trans=4
> <0100> gsm_04_11.c:149 GSM4.11 TX 49 04
> <0100> gsm_04_11.c:750 RX SMS RP-ACK (MO)
> <0002> gsm_subscriber_base.c:139 subscr 27567 usage decreased usage to: 0
> <0002> gsm_subscriber_base.c:139 subscr 46332 usage decreased usage to: 3
> DB: Found Subscriber: ID 2, IMSI 206205003327508, NAME '', TMSI 1666608304,
> EXTEN '27567', LAC 1, AUTH 1
> DBI: -7: The requested variable type does not match what libdbi thinks it
> should be
> <0002> gsm_subscriber_base.c:131 subscr 46332 usage increases usage to: 4
> <0100> gsm_04_11.c:920 send_sms_lchan()
> <0002> transaction.c:69 subscr=0x1fe52d0, subscr->net=0x1f8fc30
> <0002> gsm_subscriber_base.c:131 subscr 46332 usage increases usage to: 5
> <0002> gsm_04_11.c:937 lchan (bts=0,trx=0,ts=0,ch=0) increases usage to: 2
> <0100> gsm_04_11.c:972 TX: SMS DELIVER
> <0100> gsm_04_11.c:188 TX: CP-DATA trans=4
> <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
> <0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA
> INDICATION
> <0100> gsm_04_11.c:817 trans_id=c RX SMS CP-ACK
> <0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA
> INDICATION
> <0100> gsm_04_11.c:817 trans_id=c RX SMS CP-DATA
> <0100> gsm_04_11.c:191 TX: CP-ACK trans=4
> <0100> gsm_04_11.c:149 GSM4.11 TX 49 04
> <0100> gsm_04_11.c:750 RX SMS RP-ACK (MO)
> <0100> gsm_04_11.c:640 RX RP-ACK but no sms in transaction?!?
> <0100> gsm_04_11.c:561 TX: SMS RP ERROR, cause 111 (Protocol Error)
> <0100> gsm_04_11.c:188 TX: CP-DATA trans=4
> <0100> gsm_04_11.c:149 GSM4.11 TX 49 01 04 05 2a 01 6f
> <0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA
> INDICATION
> <0100> gsm_04_11.c:817 trans_id=c RX SMS CP-ACK
> <0100> gsm_04_11.c:159 SMC Timer TC1* is expired, calling trans_free()
> <0002> transaction.c:101 lchan (bts=0,trx=0,ts=0,ch=0) decreases usage to:
> 1
> <0002> gsm_subscriber_base.c:139 subscr 46332 usage decreased usage to: 4
> --- /SNIP ---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090923/fce22c71/attachment.htm>


More information about the OpenBSC mailing list