The idea of "subscriber_get_channel" was that different
requests would be coordinated. At the same time we have
seen that the "queue" can get stuck at both 31C3 and the
rhizomatica installations.
Voice calls and SMS do not need coordination. We should
be able to send SMS on a voice channel and switch the MS
from a SDCCH to a TCH in case we establish a voice call.
The SMS code itself needs to coordinate to obey the limit
of one SMS per direction but this should be enforced in
the sms layer and not on the subscriber.
Modify the code to have a simple paging coordination. The
subscriber code will schedule the paging and register who
would like to know about success/failure.
This allowed to greatly simplify the paging response
handling for the transaction code (and in fact we could
move the transaction list into the subscriber structure
now). The code gained to support to cancel the notification
of a request (but not the paging itself yet).
TODO: Cancel paging request in case no one cares about it
anymore.
The trans_alloc function still uses the subscr object to access the
network object.
This patch adds an explicit net parameter to this function and
removes the access to subscr to obtain it.
Sponsored-by: On-Waves ehf
Currently every subcriber object directly refers to the gsm_network
which contains a flag shared by every related subscriber
(keep_subscr). This adds a dependency on gsm_network even if only the
function defined in gsm_subscriber_base.c are used.
This patch adds a new struct gsm_subscriber_group which contains the
keep_subscr flag and a back reference to the network object. The
latter is not dereferenced in gsm_subscriber_base.c, so it can safely
be set to NULL when only that part of the gsm_subscriber API is being
used. It also changes that API to use gsm_subscriber_group instead of
gsm_network parameters.
Since there are some places where a pointer to the gsm_network is
needed but where only a gsm_subscriber is available, a 'net' back
pointer is added to the group struct, too. Nevertheless subscr group
and network could be separated completely, but this is not the topic
of this commit.
Sponsored-by: On-Waves ehf
This is an incompatible database schema change. Store the type of
the address in the database for both the sender and the receiver.
Currently it is possible to use SMPP to store a SMS and the NPI
and TON will be lost on the delivery of the SMS. The schema is
changed to make the delivery always use the right NPI/TON. This
patch is not ready for the master branch as there is no upgrade
path for the HLR yet.
It was possible that two SMS would be delivered at the same time
which violates GSM 04.11. We should solely rely on the sms queue
to schedule more SMS to the subscriber.
Each RP-DATA should have a unique msg reference. Currently 42 is
used for all of these. Remember the last reference we used and
increment it on the next SMS. Do not track if the reference is
still in use a clash is a lot less likely now. First unless SMPP
is used only one SMS is delivered at a time, second the transaction
space is a lot smaller than the one for the reference.
Sylvain pointed out that in the current crash log the transaction
we try to read the SMS from is actually a transaction for Call
Control. On AMD64 the struct layout is different and that leads to
a crash when the CC transaction is in front of the SMS transaction.
Look at the trans->protocol to fix the crash. The issue got
introduced in 6a3d765bf9 (2010)
when I added the SAPI N Reject handling.
#0 smpp_sms_cb (subsys=1, signal=4, handler_data=0xbb8270, signal_data=0x7fff33574ea0)
at smpp_openbsc.c:284
284 if (sms->source != SMS_SOURCE_SMPP)
(gdb) bt
#0 smpp_sms_cb (subsys=1, signal=4, handler_data=0xbb8270, signal_data=0x7fff33574ea0)
at smpp_openbsc.c:284
#1 0x00007f424e4a094c in osmo_signal_dispatch (subsys=1, signal=4,
signal_data=0x7fff33574ea0) at signal.c:105
#2 0x000000000042b070 in send_signal (sig_no=<optimized out>, trans=<optimized out>,
sms=<optimized out>, paging_result=<optimized out>) at gsm_04_11.c:125
#3 0x000000000042ccd2 in gsm411_sapi_n_reject (conn=0xec6790) at gsm_04_11.c:1000
#4 0x0000000000408983 in send_sapi_reject (link_id=<optimized out>, conn=<optimized out>)
at bsc_api.c:733
#5 rll_ind_cb (_data=<optimized out>, lchan=<optimized out>, link_id=<optimized out>,
rllr_ind=<optimized out>) at bsc_api.c:755
#6 rll_ind_cb (lchan=<optimized out>, link_id=<optimized out>, _data=<optimized out>,
rllr_ind=<optimized out>) at bsc_api.c:736
#7 0x000000000041f8d2 in complete_rllr (rllr=<optimized out>, type=<optimized out>)
at bsc_rll.c:55
#8 0x00007f424e4a03bc in osmo_timers_update () at timer.c:243
#9 0x00007f424e4a069b in osmo_select_main (polling=0) at select.c:133
#10 0x0000000000407394 in main (argc=<optimized out>, argv=0x7fff33575238) at bsc_hack.c:346
(gdb) frame 3
#3 0x000000000042ccd2 in gsm411_sapi_n_reject (conn=0xec6790) at gsm_04_11.c:1000
1000 send_signal(S_SMS_UNKNOWN_ERROR, trans, sms, 0);
(gdb) p trans
$1 = (struct gsm_trans *) 0xedba80
(gdb) p *trans
....
data = 0x1}}, sms = 0x3439323400000003}}}
(gdb) p trans->protocol
$4 = 3 '\003'
Let's revert it and see if we can find the real issue about the
sms being invalid. Sylvain has pointed out that we get invoked
from a timer and might not have stopped it properly.
This reverts commit 80ba9b5dd6.
I am not sure why it is crashing so this is a speculative fix based on
something we already did in 3e9b2ec257.
#0 sms_find_pending (smsq=0x2706300, sms=<optimized out>) at sms_queue.c:77
#1 sms_sms_cb (subsys=<optimized out>, signal=4, handler_data=0x26e2270,
signal_data=0x7fffdac256c0) at sms_queue.c:396
#2 0x00007fcdea94394c in osmo_signal_dispatch (subsys=1, signal=4,
signal_data=0x7fffdac256c0) at signal.c:105
#3 0x000000000042acc0 in send_signal (sig_no=<optimized out>, trans=<optimized out>,
sms=<optimized out>, paging_result=<optimized out>) at gsm_04_11.c:124
#4 0x000000000042c8e2 in gsm411_sapi_n_reject (conn=0x2722d30) at gsm_04_11.c:999
#5 0x00000000004085d3 in send_sapi_reject (link_id=<optimized out>, conn=<optimized out>)
at bsc_api.c:733
#6 rll_ind_cb (_data=<optimized out>, lchan=<optimized out>, link_id=<optimized out>,
rllr_ind=<optimized out>) at bsc_api.c:755
#7 rll_ind_cb (lchan=<optimized out>, link_id=<optimized out>, _data=<optimized out>,
rllr_ind=<optimized out>) at bsc_api.c:736
#8 0x000000000041f522 in complete_rllr (rllr=<optimized out>, type=<optimized out>)
at bsc_rll.c:55
#9 0x00007fcdea9433bc in osmo_timers_update () at timer.c:243
#10 0x00007fcdea94369b in osmo_select_main (polling=0) at select.c:133
#11 0x0000000000406fbc in main (argc=9, argv=<optimized out>) at bsc_hack.c:346
An ESME can now be configured in the VTY to enable osmocom-extensions,
which will add vendor-specific SMPP TLVs for RxLev/RxQual/ARFCN/IMEI and
transmit power to the SMPP DELIVER-SM message type.
The issue can be reproduced by typing the following 9 or more times.
OpenBSC> subscriber id 2 sms sender id 2 send bla
For some unknown reason the phone sends us a CP-ERROR for a transaction
identifier we have allocated and used but don't remember. Due the way
we use the SMC/SMR we 'establish' the machine and this results in a CP-ACK
being sent out. But the CP-ERROR is not having the content we want for
an establish so we send out a RP-ERROR. This will result in a CP-ERROR
because the phone does not know the transaction...
Avoid the issue by checking the direction of the transaction. If we do
not know the transaction and it is supposed to be allocated by us then
just ignore it and do not create a new transaction.
Rebased, tested and fixed by Holger Freyther. Release the transaction
only once the SMC is asking for the release and set the cb's to NULL
to catch a use after free early.
This has been rebased and fixed by Holger Freyther. The change of
the debug area was split out in a previous commit and the is_mt was
put back into the transaction code.
The transaction is now freed from the RELEASE_REQ sent by the SMC
layer and not inside the error path. When clearing the SMC instance
we also clear the callbacks.
This should and does happen as part of the trans_free/msc_release_connection
code. There is no easy way to determine that the lchan is now 'free' for other
things.. Let the transaction code sort this out. This code just needs to make
sure that transactions are always freed.
Use the code that is shipped inside the libosmogsm library. Right now
the signature (besides the static) and the implementation is the same.
This makes using the libosmogsm SMC code more easy in the near future.
For the gsm340_gen_oa we are now using a small wrapper to generate the
proper type and numbering plan.
libosmogsm is a new library that is distributed in the libosmocore.
Now, openbsc depends on it. This patch gets openbsc with this
change.
This patch also rewrites all include path to the new
osmocom/[gsm|core]
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
Holger Hans Peter Freyther
Harald Welte
Sylvain Munaut