Hi,
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 ---
Hello Sylvain,
On Thu, 24 Sep 2009 02:13:45 +0200, "Sylvain Munaut" <246tnt(a)gmail.com> wrote:
>
> This evening I spent a few hours hacking a small test to activate
> ciphering and I tought people might be interested with tinkering with
> it. If you want to try for yourself, start off from the encryption
> branch of Harald, then apply the 4 patches I just posted to this list
> then apply the quick hack attached to this message.
Great that you provide the patches, I did a proof a concept implementation a
while ago (http://lists.gnumonks.org/pipermail/openbsc/2009-July/000584.html).
However I never found the time to actually complete it, so now I don't have
to care any more :-)
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi!
I'm surprised that this list is so quiet... no mails for more than a week
already.
Is anybody still playing with, developing or using OpenBSC? I would really
appreciate more community participation, such as
* more documentation in the wiki
* talk about what you're doing with OpenBSC (esp. the universities!)
* discussion / sharing of your experience
* bug reports (should probably go in trac)
* patches!
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
commit 7aa86ed1e8669bcd06970ba23a1ff5abd5da81e6
Author: Sylvain Munaut <tnt(a)246tNt.com>
Date: Thu Sep 24 01:44:24 2009 +0200
[gsm_04_08] Fix gsm48_send_rr_ciph_mode algorithm ID
The algorithm ID used in the GSM 04.08 RR message is
(x-1) for A5/x. In RSL it's (x+1) for A5/x so there is
a difference of 2.
Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com>
openbsc/src/gsm_04_08.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Hi all!
I have recently been informed there is a job opening related to OpenBSC
in Dresden / Germany. So if you're interested in working full time on
issues such as
* integrating OpenBSC into actual applications / products
* testing OpenBSC with various handsets in various scenarios
* sending bug reports and interacting with actual developers
The job is not really about development of the OpenBSC stack itself, but
related to system integration. So don't worry if you are neither a full-blown
programmer, nor know the GSM protocol specs up to the last bit ..
Please drop me a note, in case you're interested.
Regards,
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
hi joerg,
i am not into debian. can you explain:
- what files in your directory http://www.dorchain.net/~joerg/code/debian/
should be added to the git repository?
- where should they be located? (inside lcr directory)
- what files of original lcr or mISDN git are changed?
thanx in advance,
andreas
Hello all,
Just thought I would give everyone an update on my progress with the
Ericsson RBS. I got a T1 card, a Digium TE122P
(http://www.digium.com/en/products/digital/te122.php). This card support
E1/T1/J1. The 2401 I have only supports T1, otherwise I would have gotten a
HFC based chipset that OpenBSC supports.
The TE122P uses the DAHDI drivers, which used to be Zaptel. In reading
through the list archives, I found a couple tidbits about Zaptel.
The first was back in February from Harald:
http://lists.gnumonks.org/pipermail/openbsc/2009-February/000023.html. I
didn't see any updates after that. Were there updates made to make the
integration with other drivers easier?
The next I found was in March from Klaus-Peter Junghann:
http://lists.gnumonks.org/pipermail/openbsc/2009-March/000064.html. It looks
like he actually got the Zaptel driver to work. I'm not sure how much of
Zaptel has changed when the driver set was renamed to DAHDI. I did not see a
post from Mr. Junghann with the zaptel input module he spoke of.
I'm not sure what the interest level is with getting OpenBSC to integrate
with Ericsson RBS's? Like I previously mentioned, I am not much of a coder,
so I can't help much in that department. That being said, I am willing to
provide remote access to all the resources I have here (Debian Linux 5.0
Server, RBS 2401, Windows LMT). I can also provide access to a spec an
(which would be accessed via software on the Windows LMT) if needed down the
road. I am going to look into a STA to test on a couple ARFCN's in the
GSM1900 band, and I am more than willing to help with handset debugging at
that stage. I have quite a few different handsets lying around!
Thanks much,
Caleb
Hello,
While experimenting with a Motorola V3 GSM branded for AT&T, I enabled the
Engineering Menu with a SEEM edit. Not a terribly hard procedure once you
know where to look. After performing this hack, I looked in the Engineering
Menu, and there is an option to force the ARFCN the phone camps on. I think
this would be a useful tool if you want to force a handset to camp on your
Base Station. I'm not if it will help with the clock issues, but it might
alleviate some frustration. The Original V3's (no 3G) can be found on ebay
for a decent price. I'm not sure if any other phones include this
functionality (I haven't come across any), so I thought I would share it
with you all. If you need help performing the SEEM edit, let me know.
Caleb
