This command returns the current state of the connection to the USSD
side channel provider. It shows whether a provider has been connected
and authorized or not.
Fixes: OW#953
These commits have been deployed by sysmocom and it should qualify
as some form of smoke testing. Let's see how things go from here.
The by IMSI alertion has not been used, the rest should have been
executed by the system.
There's a VTY option by which for every ESME the user can specify if the
E.212 or E.164 number should be used in DELIVER-SM. The ALERT
notifications generate by subscriber LU have so far always contained the
E.212 (IMSI) rather than E.164 (MSISDN) which is a bit inconsistent.
Rather than copying code, we create a new function that implements
ALERTing all ESMEs.
If the MS memory for SMS is exceeded and we get an RP-layer error, we
need to report that back to the (transaction-mode) ESME. Otherwise the
ESME will wait forever after sending a SUBMIT-SM without ever receiving
a response to it.
Thanks to Holger for catching this.
* The post-routing is applied after the first re-writing. To do this
the new number is copied back into the called data structure.
* Add a testcase that goes from 0172 to 0049 and then back to 0049
using the post rule with a table lookup.
* Increase the rewritten rule to five digits (this is the easiest
for the unit test). This will add another 40kb to the runtime size.
* Create a unit test that tests adding and removing the prefix rules.
* Use the regexp match to replace from one package
* It is a trie. The max depth of the trie is the length of the
longest prefix. The lookup is O(lookuped_prefix), but as the prefix
length is limited, the lookup time is constant.
* Each node can hold the entire prefix, has place for the rewrite
rule with up to three digits.
* A trie with 20k entries will take about 3MB ram.
* Filling the trie 100 times takes ~800ms on my i7 laptop
* 10.000.000 lookups take 315ms.. (for the same prefix).
* 93/99 lines are tested, 6/6 functions are tested, 49 of 54 branches
are tested. Only memory allocation failures are not covered
* A late addition is to handle the '+' sign and to increase the number
of chars in the rewrite prefix. The timing/line coverage has not
been updated after this change.
In case we have access to the context verify that the selected
msgb_tlli is either the old_tlli or the tlli in either local or
foreign format. It is wrong to use any other TLLI.
Attempt to solve what f0901f0067e363c0ced6254db1b45a9771640412 tried to
solve without breaking the case of someone with a foreign TLLI from a
different network.
Lookup with the foreign TLLI converted to a local one in case we did
not find the TLLI and only then create a LLE/LLME on the fly for the
RX path.
During the GPRS Attach procedure we might have a foreign tlli and
in the RX create a LLME on the fly for this tlli. The GMM GPRS
Attach handling code will then assign a new TLLI and keep the
foreign tlli as the llme->old_tlli.
When the GMM is sending the identity request the msgb_tlli will
point to the foreign tlli. The GPRS LLC code will then try to find
that foreign tlli but due the conversion this will not be found.
Instead a new ad-hoc LLE/LLME will be created on the fly for
each message (this means there are duplicate LLE/LLMEs in the
list).
Make the code more strict and remove the tlli_foreign2local change
from the look-up routine. This will make the GPRS LLC code find
the right LLE/LLME and the N(U) will be handled correctly.
This partially reverts:
f0901f0067e363c0ced6254db1b45a9771640412
Addresses:
<0012> gprs_llc.c:773 LLC RX: unknown TLLI 0xadf11820, creating LLME on the fly
...
<0012> gprs_llc.c:357 LLC TX: unknown TLLI 0xedf11820, creating LLME on the fly
Reproducable:
Use pcu_emu (gprs attach) and observe with wireshark.
In case of a failure this method didn't set the pctx->lib back to
NULL. In case of a timeout the callback will be made with pdp=NULL
and this would lead to leaking the PDP context. Check for the case
of having a pctx->lib != pdp and free it.
This resolves:
<000f> gprs_sgsn.c:259 freeing PDP context that still has a libgtp handle attached to it, this shouldn't happen!
The jenkins build node has Python 2.5.X installed and the
assertGreater method is not available. Use assert_ until
we can use newer versions of Python.
Disable the periodic LU using "no periodic location update" VTY
command. In that case set the expire_lu to 0 which will then be
translated to a NULL in the database layer. This leads to a bit of
copy and paste in the db_sync_subscriber method but I don't see
how we could easily use 'datetime(%i, 'unixepoch')' and 'NULL'
at the same time.
Change the query to find expired queries to check for NOT NULL
and the time being in the past. This means if there are still
old subscribers in the database they might not be expired. One
would need to execute a query like "UPATE Subscriber SET expire_lu
= 0 WHERE expire_lu is null". The same applies when disabling the
periodic LU. One would need to update the database by hand.
Manual tests executed/passed:
1.) periodic LU enabled:
* use gst LUTest.st to do a LU
* UPDATE Subscriber SET expire_lu=datetime('now');
* observe the subscriber being expired (it was)
2.) periodic LU disabled:
* use gst LUTest.st to do a LU
* verify that the expire_lu is NULL in the database
We were expiring subscribers during active calls. This is because
the T3212 is stopped under certain conditions but we didn't stop
that timer at all.
Remember if T3212 timer was stopped due something done by NITB and
update the expiration time at the end of the radio connection, as
the phone should restart it when returning to MM Idle.
It is a bit difficult to decide when we should set the flag. E.g.
in a CM Service Request we don't know if we accept the service and
during a LU we already send MM messages before we accept or reject
the subscriber.
The easiest is to set the flag when receiving a paging response
on known subscribers and at the end of the authentication process.
Do not expire a subscriber that has an active connection that is
marked with the flag, e.g. we would still expire a subscriber that
is being paged.
Manual tests executed/passed:
* gst LUTest.st verified that a expiration date was set
* gst SMSTest.st (doing another LU but forcing a timeout on the
SMS sending). Verified that the expire_lu was updated.
Make sure to not ever have issues with this code again, move the
utility code to a new file and create a basic testcase. The method
currently has 100% line and branch coverage. My initial patched
missed the smpp_utils.c file and I re-did the copying (and verifying
the branch coverage)
bsc_api.c:417:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 7 has type ‘unsigned int’ [-Wformat]
bsc_api.c: In function ‘handle_ass_fail’:
bsc_api.c:458:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 7 has type ‘unsigned int’ [-Wformat]
db.c: In function ‘db_sync_subscriber’:
db.c:785:3: warning: format ‘%i’ expects argument of type ‘int’, but argument 8 has type ‘time_t’ [-Wformat]
osmo_msc.c: In function ‘msc_release_connection’:
osmo_msc.c:145:20: warning: unused variable ‘trans’ [-Wunused-variable]
smpp_smsc.c: In function ‘link_accept_cb’:
smpp_smsc.c:891:24: warning: assignment from incompatible pointer type [enabled by default]
smpp_smsc.c:271:1: warning: ‘esme_by_system_id’ defined but not used [-Wunused-function]
smpp_openbsc.c: In function ‘smpp_openbsc_init’:
smpp_openbsc.c:545:2: warning: implicit declaration of function ‘smpp_vty_init’ [-Wimplicit-function-declaration]
osmo_bsc_ctrl.c: In function ‘verify_bts_loc’:
osmo_bsc_ctrl.c:340:19: warning: variable ‘height’ set but not used [-Wunused-but-set-variable
smpp_mirror.c: In function ‘main’:
smpp_mirror.c:297:2: warning: implicit declaration of function ‘osmo_init_logging’ [-Wimplicit-function-declaration]
This adds a minimalistic ACL by which certain, individual roaming IMSIs
can be authorized to use the SGSN. So you can selectively bypass the
'MCC+MNC == first 5 digits of IMSI' checking for a couple of IMSIs
It appears to me that for NM_OC_BS11 mo was either NULL or the
one mo value from NM_OC_BS11_RACK. The break inside the nested
switch case didn't break from the outer one.
Fixes Coverity: CID 1040728
The esme->acl is treated like it can be NULL in other places
of the code. Assume it can be NULL during this check as well.
Dereference after null check (FORWARD_NULL)
9. var_deref_op: Dereferencing null pointer "esme->acl".
Fixes: Coverity CID 1042374
As Holger pointed out, they contained a GPLv2+ disclaimer rather than
the AGPLv3+ which we use for OpenBSC. This is not an incompaibility,
but was done unintentionally. The code was always mean to be under
AGPLv3+.
Nevertheless, anyone using those two files in a version up to this
commit have the right to use it under GPLv2+ as well. This is not
applicable for any versions after this commit.
A CM service request must be acknowledged also, when encryption is already
enabled.
Without encryption enabled, the security status is GSM_SECURITY_NOTAVAIL,
which causes a CM service acknowledge. On initial CM service request, the
security status is GSM_SECURITY_SUCCEED, if encryption is enabled. This
will not lead to an acknowledge, because the cyphering command implies an
acknowlege. An additional CM service request requires an acknowledge, so
I added a new security status: GSM_SECURITY_ALREADY
Coverity pointed out that we use trans->subscr after a NULL check,
it is our believe that every transaction will have a subscriber.
Remove the check and add an assert before we are dispatching things.
Fixes: Coverity CID 1040740, CID 1040739
Coverity pointed out that this code is logically dead. Quickly
judging the code we will forward the RSLD message anyway. Remove
the code for now and next time I work on the NAT/USSD bridge I
will have a look at the flow of the RLSD messages.
Fixes: Coverity CID 1042327
The number = int_number assignment will make the number point to
the stack and as the int_number goes out of scope at the end of
the if statement other code could re-use this stack for other memory.
Fixes: Coverity CID 1042325
