Hi guys,
I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now.
Tickets:
Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either:
* not import tickets
* only import from one project
* deal with changing ticket numbers
In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number?
Wiki:
We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this?
kind regards
holger
Hi,
It might interest you that OpenBSC has entered Debian unstable today!
https://tracker.debian.org/news/755641
Please test the package and file bugs as you find them. I haven't added init/service files
yet to the package, since it needs some careful thought around what default is the best
for the general users.
Best regards,
Ruben
Dear List,
I am in the process of creating the Wiki page for Ettus B200/B210 with OpenBSC, GPRS and Asterisk.
I am quite close, both data and calls are working, but the voice calls are half sided. The downlink direction works, but the uplink does not.
I tried without Asterisk and LCR (between two phones) and still the calls are half sided.
In the mean time I got these messages in the Osmo-BTS log:
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284768 ts=2 tr x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284764 to transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284764 to transmit.
<0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=1284772 ts=1 trx= 0
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=1284772 ts=1 tr x=0
<0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x0a fn=1284772 ts=2 trx= 0
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284772 ts=2 tr x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284768 to transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284768 to transmit.
SMS and GPRS seems to be fine.
If someone have any idea, I would love to hear it. :-)
Thanks!
Csaba
Hi all,
This patch set adds to libosmocore an optimized Viterbi decodeer for
architecture specific (Intel SSE) and non-specific cases. The
implementation covers codes with constraint lengths of K=5 and K=7 and
rates 1/4 to 3/4, which make up the majority of GSM use cases. Speedup
from the current implementation is in the range of 5 to 20 depending on
the processor and code type. API is unchanged.
Tested on Haswell (i7-4770K) and Atom (D2550). Additional test codes
from osmo-bts are included. Further tests for AWGN bit-error-rate
and benchmarks can be found in the following repository.
https://github.com/ttsou/osmo-conv-test
Here are some examples.
Bit error test for GPRS CS2 with SNR of 5 dB and 100000 bursts.
$ ./conv_test -c 2 -e -r 5 -i 100000
=================================================
[+] Testing: GPRS CS2
[.] Specs: (N=2, K=5, non-recursive, flushed, not punctured)
[.] Input length : ret = 290 exp = 290 -> OK
[.] Output length : ret = 588 exp = 588 -> OK
[.] BER tests:
[..] Testing base:
[..] Input BER.......................... 0.042443
[..] Output BER......................... 0.000006
[..] Output FER......................... 0.001350 (135)
[..] Testing SIMD:
[..] Input BER.......................... 0.042460
[..] Output BER......................... 0.000005
[..] Output FER......................... 0.001240 (124)
Timed AFS benchmark with 8 threads and 100000 bursts per thread.
$ ./conv_test -b -c 10 -j 8 -i 100000
=================================================
[+] Testing: GSM TCH/AFS 6.7
[.] Specs: (N=4, K=5, recursive, flushed, punctured)
[.] Input length : ret = 140 exp = 140 -> OK
[.] Output length : ret = 448 exp = 448 -> OK
[.] Performance benchmark:
[..] Encoding / Decoding 800000 bursts on 8 thread(s):
[..] Testing base:
[..] Elapsed time....................... 4.320001 secs
[..] Rate............................... 25.925920 Mbps
[..] Testing SIMD:
[..] Elapsed time....................... 0.458272 secs
[..] Rate............................... 244.396341 Mbps
[..] Speedup............................ 9.426718
-TT
Hello everyone,
a student college and me are using the osmo-sim-auth tool for a student
project. We have valid data for our SIM card since it's a special
ordered test SIM card. In 2G mode we get the correct RES value, but in
3G mode we always get only an AUTS value. We calculated the SQN value
from the AUTS to verify that we have the correct SQN value, but still we
only get AUTS as return.
I would be grateful to hear if any of you have an idea why this is
happening.
Best regards
Marco
Hi,
we are now running our own copy of patchwork at https://patchwork.osmocom.org. In addition to single patches this version can track series and has a REST API and git-pw client support. The system is currently subscribed to the GPRS, OpenBSC and OsmocomBB mailinglist.
The installation is running offlineimap every couple of minutes to fetch new mail, this means it can take some minutes for your comment or patch to be visible.
kind regards
holger
Hi list,
osmo_prim_init() and msgb use firstly confuses me, and secondly is
apparently "inefficient" in sccp_helpers.c.
First, let's look at osmo_sccp_tx_unitdata() (libosmo-sccp branch
sysmocom/iu):
int osmo_sccp_tx_unitdata(struct osmo_sua_link *link,
const struct osmo_sccp_addr *calling_addr,
const struct osmo_sccp_addr *called_addr,
uint8_t *data, unsigned int len)
{
struct msgb *msg = msgb_alloc(1024, "sccp_tx_unitdata");
struct osmo_scu_prim *prim;
struct osmo_scu_unitdata_param *param;
prim = (struct osmo_scu_prim *) msgb_put(msg, sizeof(*prim));
param = &prim->u.unitdata;
memcpy(¶m->calling_addr, calling_addr, sizeof(*calling_addr));
memcpy(¶m->called_addr, called_addr, sizeof(*called_addr));
osmo_prim_init(&prim->oph, SCCP_SAP_USER, OSMO_SCU_PRIM_N_UNITDATA, PRIM_OP_REQUEST, msg);
msg->l2h = msgb_put(msg, len);
memcpy(msg->l2h, data, len);
return osmo_sua_user_link_down(link, &prim->oph);
}
First off, we allocate 1024 bytes of msgb. Into it goes an osmo_scu_prim
struct (here 'prim'). We set some parameters in prim, fair enough. But
now what, prim->oph, the prim header, has a msg pointer, which points back
at the msgb that contains the prim. really?? The msgb containing a struct
pointing back at the same msgb has my head spinning.
Finally we add the data, l2h pointing at the start of it. I'm confused ...
how large is the msgb supposed to be? Is it len + sizeof(*prim)?
Secondly, let's look at:
int osmo_sccp_tx_unitdata_msg(struct osmo_sua_link *link,
const struct osmo_sccp_addr *calling_addr,
const struct osmo_sccp_addr *called_addr,
struct msgb *msg)
{
int rc;
rc = osmo_sccp_tx_unitdata(link, calling_addr, called_addr,
msg->data, msgb_length(msg));
msgb_free(msg);
return rc;
}
So, something out there has a msgb containing data. For example, from
ranap_new_msg_paging_cmd(). That msgb has probably been allocated
specifically to compose a message to go over the sccp link.
We go on, though, to allocate *another* msgb (size 1024, remember), and
memcpy the first msgb into the second msgb, behind the osmo_scu_prim
struct.
I'll first use this as-is, talking about premature optimization. But I'd
prefer to have neither the wicked cunning nor the blunt dumbness in there;
the combination strikes me as jolly mad ;)
Are there good reasons for this?
I would have envisioned something like: tell ranap_new_msg_paging_cmd() to
allocate sizeof(*prim) of headroom; or first create a msgb of fixed
known-max size, and add first the prim header and then compose the data.
And, given the union prim->u has "unknown" size, why not point at the data
from prim->oph directly, instead of pointing back at the msgb? Or have
that union first? That would be easier to understand.
If some code needs to know the msgb that contains the prim->oph, I find it
weird to pass it the prim->oph with a backpointer, instead of just passing
the msgb right away.
~Neels
Hi,
this only happens when building a debian package, valgrind doesn't show anything crazy. It is a bit difficult to see which test it is. Any ideas?
holger
Output:
+++ /media/sf_source/gsm/libosmocore/tests/testsuite.dir/at-groups/7/stdout 2016-03-31 20:03:51.000000000 +0200
@@ -24,7 +24,7 @@
Src: [L1]> 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 [L2]> 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 [L3]> 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b [L4]> 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
Dst: [L1]> 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 [L2]> 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 [L3]> 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b [L4]> 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
msgb(%p): Sub area is not fully contained in the msg data
-msgb(%p): Sub area is not fully contained in the msg data
+msgb(%p): Negative sizes are not allowed
msgb(%p): Sub area is not fully contained in the msg data
msgb(%p): Negative sizes are not allowed
msgb(%p): Negative sizes are not allowed
7. testsuite.at:42: 7. msgb (testsuite.at:42): FAILED (testsuite.at:45)
Hi,
it is my pleasure to announce the osmo-sip-connector. It is a pure connector/translator/bridge from our NITB MNCC protocol to SIP (and vice versa). The sourcecode can be found here[1] and Debian 8.0 packages are available as part of the nightly packages[2] we are building. To run it a config file needs to be placed in /etc/osmocom/osmo-sip-connector.cfg. An example configuration can be found in doc/examples/ of the git repository.
The system is meant to contact (and be contacted) from a single SIP PBX, the system will not do RTP proxying and transcoding is left as exercise to the PBX. The system is using libosmocore/libosmovty and sofia-sip(-glib) for SIP. There is a custom evpoll.c that integrates Osmocore's event loop with glib.
As with every (new) software there is a long list of TODOs and we will address them:
* Review logging and make sure enough context about call handling is present
* Add VTY show commands (e.g. list calls and legs)
* Add Stats/Counters to measure events and timing
* Find a testing strategy
* Implement a codec selection scheme that is good
* IMSI based addressing
* Release cause mapping
* DTMF handling
* Create a manual for it.
In the long run we might want to consider mapping LUs to SIP REGISTER and SMPP to SIP as well. But that is quite far away and just a vague idea right now.
kind regards
holger
[1] http://git.osmocom.org/osmo-sip-connector/
[2] https://build.opensuse.org/package/show/network:osmocom:nightly/osmo-sip-co…
In the past normal migration was possible only if the actual
schema version differed from the version used in DB by 1. For
example, if DB uses an old version 3 and you need to use it
with the code written for version 5, the check_db_revision()
will convert it to 4 and DB will still use incompatible schema
version during Osmo-NITB running time. After next run it will
be converted to version 5.
This patch replaces a set of 'else-if' checks by a 'switch'
without 'break' statements between 'case' labels (waterfall).
It makes you able to migrate from current version to the
latest despite any difference between them.
Also fixed the sms_from_result_v3() to avoid large depth of
function calls, because they can be changed in the future
and lose compatibility with old table schemas.
Also fixed db_test and now it is successful.
Signed-off-by: Vadim Yanitskiy <axilirator(a)gmail.com>
---
openbsc/src/libmsc/db.c | 65 ++++++++++++++++++++++++++++----------------
openbsc/tests/db/db_test.c | 1 +
openbsc/tests/db/db_test.err | 3 ++
3 files changed, 45 insertions(+), 24 deletions(-)
diff --git a/openbsc/src/libmsc/db.c b/openbsc/src/libmsc/db.c
index 04aee79..ad5afca 100644
--- a/openbsc/src/libmsc/db.c
+++ b/openbsc/src/libmsc/db.c
@@ -225,23 +225,27 @@ static struct gsm_sms *sms_from_result_v3(dbi_result result)
{
struct gsm_sms *sms = sms_alloc();
long long unsigned int sender_id;
- struct gsm_subscriber *sender;
- const char *text, *daddr;
+ const char *text, *daddr, *extension;
const unsigned char *user_data;
- char buf[32];
+ dbi_result sender_result;
if (!sms)
return NULL;
- sms->id = dbi_result_get_ulonglong(result, "id");
-
sender_id = dbi_result_get_ulonglong(result, "sender_id");
- snprintf(buf, sizeof(buf), "%llu", sender_id);
- sender = db_get_subscriber(GSM_SUBSCRIBER_ID, buf);
- OSMO_ASSERT(sender);
- strncpy(sms->src.addr, sender->extension, sizeof(sms->src.addr)-1);
- subscr_direct_free(sender);
- sender = NULL;
+ sms->id = dbi_result_get_ulonglong(result, "id");
+
+ sender_result = dbi_conn_queryf(conn,
+ "SELECT * FROM Subscriber "
+ "WHERE id = %llu", sender_id);
+
+ if (sender_result) {
+ if (dbi_result_next_row(sender_result)) {
+ extension = dbi_result_get_string(sender_result, "extension");
+ strncpy(sms->src.addr, extension, sizeof(sms->src.addr) - 1);
+ }
+ dbi_result_free(sender_result);
+ }
sms->reply_path_req = dbi_result_get_ulonglong(result, "reply_path_req");
sms->status_rep_req = dbi_result_get_ulonglong(result, "status_rep_req");
@@ -477,16 +481,20 @@ static int check_db_revision(void)
{
dbi_result result;
const char *rev_s;
+ int db_rev = 0;
+ /* Make a query */
result = dbi_conn_query(conn,
- "SELECT value FROM Meta WHERE key='revision'");
+ "SELECT value FROM Meta "
+ "WHERE key = 'revision'");
if (!result)
return -EINVAL;
-
if (!dbi_result_next_row(result)) {
dbi_result_free(result);
return -EINVAL;
}
+
+ /* Fetch the DB schema revision */
rev_s = dbi_result_get_string(result, "value");
if (!rev_s) {
dbi_result_free(result);
@@ -494,28 +502,37 @@ static int check_db_revision(void)
}
if (!strcmp(rev_s, SCHEMA_REVISION)) {
- /* everything is fine */
- } else if (!strcmp(rev_s, "2")) {
+ /* Everything is fine */
+ dbi_result_free(result);
+ return 0;
+ }
+
+ db_rev = atoi(rev_s);
+ dbi_result_free(result);
+
+ /* Incremental migration waterfall */
+ switch (db_rev) {
+ case 2:
if (update_db_revision_2())
goto error;
- } else if (!strcmp(rev_s, "3")) {
+ case 3:
if (update_db_revision_3())
goto error;
- } else if (!strcmp(rev_s, "4")) {
+ case 4:
if (update_db_revision_4())
- goto error;
- } else {
- LOGP(DDB, LOGL_FATAL, "Invalid database schema revision '%s'.\n", rev_s);
- dbi_result_free(result);
+ goto error;
+
+ /* The end of waterfall */
+ break;
+ default:
+ LOGP(DDB, LOGL_FATAL, "Invalid database schema revision '%d'.\n", db_rev);
return -EINVAL;
}
- dbi_result_free(result);
return 0;
error:
- LOGP(DDB, LOGL_FATAL, "Failed to update database from schema revision '%s'.\n", rev_s);
- dbi_result_free(result);
+ LOGP(DDB, LOGL_FATAL, "Failed to update database from schema revision '%d'.\n", db_rev);
return -EINVAL;
}
diff --git a/openbsc/tests/db/db_test.c b/openbsc/tests/db/db_test.c
index a02d1f8..2fdd830 100644
--- a/openbsc/tests/db/db_test.c
+++ b/openbsc/tests/db/db_test.c
@@ -187,6 +187,7 @@ int main()
char *alice_imsi = "3243245432345";
alice = db_create_subscriber(alice_imsi);
+ db_subscriber_alloc_tmsi(alice);
db_sync_subscriber(alice);
alice_db = db_get_subscriber(GSM_SUBSCRIBER_IMSI, alice->imsi);
COMPARE(alice, alice_db);
diff --git a/openbsc/tests/db/db_test.err b/openbsc/tests/db/db_test.err
index fa9a54c..d8a3e7f 100644
--- a/openbsc/tests/db/db_test.err
+++ b/openbsc/tests/db/db_test.err
@@ -1,2 +1,5 @@
Going to migrate from revision 3
+[0;mMigration complete.
+[0;mGoing to migrate from revision 4
+[0;mMigration complete.
[0;m
\ No newline at end of file
--
2.8.0
v2 was an accidental re-post of the same patches, this time for real:
Changes to first version:
* Use struct value_string[] instead of switch{} for auth_action_str().
* Tweak first and last patch's log message.
Neels Hofmeyr (7):
Add MM Auth test; add auth_action_str() function
MM Auth test: add two tests for AUTH_THEN_CIPH
MM Auth test: add test to re-use existing auth
MM Auth: introduce AUTH_ERROR constant.
MM Auth: return AUTH_NOT_AVAIL instead of hardcoded zero
Fix MM Auth: disallow key_seq mismatch
Fix MM Auth: zero-initialize auth tuple before first use
openbsc/.gitignore | 1 +
openbsc/configure.ac | 1 +
openbsc/include/openbsc/auth.h | 9 +
openbsc/src/libmsc/auth.c | 33 +++-
openbsc/tests/Makefile.am | 2 +-
openbsc/tests/mm_auth/Makefile.am | 21 +++
openbsc/tests/mm_auth/mm_auth_test.c | 340 ++++++++++++++++++++++++++++++++++
openbsc/tests/mm_auth/mm_auth_test.ok | 40 ++++
openbsc/tests/testsuite.at | 7 +
9 files changed, 446 insertions(+), 8 deletions(-)
create mode 100644 openbsc/tests/mm_auth/Makefile.am
create mode 100644 openbsc/tests/mm_auth/mm_auth_test.c
create mode 100644 openbsc/tests/mm_auth/mm_auth_test.ok
--
2.1.4
I just fixed some things (gsm_subscriber.c, VTY tmsi parsing)
and did some tests. It works!
Location Update Request with TMSI from previous network:
<0002> gsm_04_08.c:1127 LOCATION UPDATING REQUEST: MI(TMSI)=0x68044a6c
type=NORMAL
<0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS.
<0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS.
Outgoing SMS from OpenBSC VTY:
OpenBSC> subscriber tmsi 0xb7f861b6 sms sender tmsi 0xb7f861b6 send TEST
<0002> gsm_subscriber.c:175 Subscriber <IMSI> not paged yet.
<0004> abis_rsl.c:1465 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(***) SS(0)
lctype SDCCH r=OTHER ra=0x1a ta=1
<0004> abis_rsl.c:1199 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK
<0000> abis_rsl.c:1653 (bts=0,trx=0,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION
<0000> gsm_04_08.c:3573 Dispatching 04.08 message, pdisc=6
<0003> gsm_04_08.c:1180 PAGING RESPONSE: MI(TMSI)=0xb7f861b6
<0003> gsm_04_08.c:1198 <- Channel was requested by <IMSI>
<0003> gsm_04_08.c:1259 TX APPLICATION INFO id=0x00, len=4
<0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 06) Sending 0x38 to MS.
<0001> transaction.c:71 subscr=0x2363f00, net=0x2333e90
USSD request also works:
<0002> gsm_04_08.c:956 <- CM SERVICE REQUEST serv_type=0x08
MI(TMSI)=0xb7f861b6
<0002> gsm_04_08_utils.c:692 -> CM SERVICE ACK
As you can see, now TMSI displays in hex.
I'll provide a new patch soon.
С наилучшими пожеланиями,
Яницкий Вадим.
2016-03-22 18:58 GMT+06:00 Вадим Яницкий <axilirator(a)gmail.com>:
> Hello, Harald! Good day, Holger!
>
> It looks like SQLite3 doesn't have support of unsigned 64-bit integers. :(
> Of course, we can write some custom functions, which can emulate it,
> but it isn't good solution, I think.
>
> My suggestion is to keep the TMSI column type in string format: 0xffffffff.
> I need to know your opinions before starting to write a new patch.
>
>
> С наилучшими пожеланиями,
> Яницкий Вадим.
>
> 2016-03-17 22:34 GMT+06:00 Holger Freyther <holger(a)freyther.de>:
>
>>
>> > On 17 Mar 2016, at 17:21, Вадим Яницкий <axilirator(a)gmail.com> wrote:
>> >
>> > Hi Guys!
>> >
>> > > If you have time, please check if there are other occurrences in
>> OpenBSC
>> > > or OsmocomBB where the TMSI is printed as integer. Thanks!
>> >
>> > No problem! :)
>> >
>> > > I think it was a bit too quick. I foresee one problem. Let's assume
>> someone
>> > > is using TMSIs and now upgrade the sourcecode. All CM Service Requests
>> > > will fail because the TMSI is not known. What is the
>> migration/mitigation plan?
>> >
>> > I absolutely agree with Holger. Maybe we can add some code that will
>> check
>> > if database still stores TMSIs in old representation style and convert
>> them to
>> > uint32_t? We can change the libmsc/db.c:db_prepare() for this purpose.
>>
>>
>> yes, we have a schema version and can just increase it. E.g. have a look
>> at how we migrate SMS.
>>
>>
>>
>> >
>> > > tmsi_from_string will not work for this anymore.
>> >
>> > Yes, I forgot to change the gsm_subscriber.c ... Sorry.
>>
>>
>> it happens. thanks for contributing
>>
>>
>>
>> >
>> > > there is no length check but that doesn't seem to be a big issue
>> right now.
>> >
>> > We can just write a function that will do this check instead of using
>> #define.
>>
>> I think you will not need to touch this define at all. We might want to
>> change the name to _from_mi_string.
>>
>>
>> >
>> > > * a DB schema upgrade and store the TMSI as uint32_t
>> > > * Use hex presentation in VTY
>> >
>> > +1
>>
>>
>> looking forward for the follow up.
>>
>>
>> holger
>
>
>
Though MM Auth might be tested implicitly, it is acutely lacking a dedicated
test suite. I found two problems in the MM Auth logic, and to have regression
tests for those, I need an actual test suite.
So, at first I add a bread-and-butter test suite for MM Auth. Then, I
cosmetically improve use of constants in return values. Finally, I fix the two
issues with reflection in the new tests.
Neels Hofmeyr (7):
Add MM Auth test; add auth_action_str() function
MM Auth test: add two tests for AUTH_THEN_CIPH
MM Auth test: add test to re-use existing auth
MM Auth: introduce AUTH_ERROR constant.
MM Auth: return AUTH_NOT_AVAIL instead of hardcoded zero
Fix MM Auth: disallow key_seq mismatch
Fix MM Auth: zero-initialize auth tuple before first use
openbsc/.gitignore | 1 +
openbsc/configure.ac | 1 +
openbsc/include/openbsc/auth.h | 18 ++
openbsc/src/libmsc/auth.c | 24 ++-
openbsc/tests/Makefile.am | 2 +-
openbsc/tests/mm_auth/Makefile.am | 21 +++
openbsc/tests/mm_auth/mm_auth_test.c | 340 ++++++++++++++++++++++++++++++++++
openbsc/tests/mm_auth/mm_auth_test.ok | 40 ++++
openbsc/tests/testsuite.at | 7 +
9 files changed, 446 insertions(+), 8 deletions(-)
create mode 100644 openbsc/tests/mm_auth/Makefile.am
create mode 100644 openbsc/tests/mm_auth/mm_auth_test.c
create mode 100644 openbsc/tests/mm_auth/mm_auth_test.ok
--
2.1.4
Dear 3G Folks,
after various problems with obtaining a stable Location Update of a 3G
subscriber on our hNodeB femto-cell, we've finally succeeded today!
Basically, after both MM Authentication and Integrity Protection were in
place today, the phone finally started to reply to the Location Updating
Accept with the expected TMSI Reallocation Complete message.
After that, the phone was still cycling new Location Update Requests every
half minute or so, because we were replying with the wrong LAC id = 0;
Osmo-CSCN (Circuit-Switched Core Network) needs to know which RNC (like a
BSC in 2G) has which Location Area Code. The RNC tells us its global RNC
ID when it first connects, and the CSCN needs to match the LAC properly
from prior knowledge (aka config).
Now that both Integrity Protection and the matching LAC are in place
during the Location Updating Accept message from the CSCN, the UE happily
stays subscribed to the CSCN! It's about time, too.
The reasons why it took this long to reach this admittedly meagre sounding
milestone were mostly:
- The fact that Osmocom did not feature a standalone MSC, which first had
to be surgically separated from the BSC part (used to be the NITB).
I introduced and then eradicated a few build problems in the process.
- Osmocom's libmsc previously was not able to do mere MM Authentication
without also enabling Ciphering, so to test MM Authentication on its own
I needed a new path in the auth and ciph code.
- Osmocom's libmsc so far expected to have precisely one BSC, as part of
the NITB, so it simply telepathically knew "the" LAC. Now, libmsc has to
figure out the LAC from a table instead. (VTY configuration to match
RNCs with LACs is in the making, as well as the RNC and BSC registry
itself.)
So, in fact, this milestone has much more under the hood than the layman
would expect.
Now that we have all of these fleas numbered and in the same matchbox, the
long overdue stable 3G Location Update on IuCS using the new osmo-cscn
finally arrived this afternoon.
As soon as this code is configurable and peer reviewed, I will move on to
implement 3G paging. I do hope to shift up a gear on that, with new
confidence and by now much firmer knowledge of 3G and the "Osmoverse".
Lively greetings from sysmocom's open 3G lab in Berlin!
Stay tuned for more Updates, soon at this Location.
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
> Begin forwarded message:
>
> From: scan-admin(a)coverity.com
> Subject: New Defects reported by Coverity Scan for Osmocom
> Date: 18 March 2016 at 18:01:06 GMT+1
> To: holger(a)freyther.de
>
>
> Hi,
>
> Please find the latest report on new defect(s) introduced to Osmocom found with Coverity Scan.
>
> 2 new defect(s) introduced to Osmocom found with Coverity Scan.
>
>
> New defect(s) Reported-by: Coverity Scan
> Showing 2 of 2 defect(s)
>
> ________________________________________________________________________________________________________
> *** CID 76332: API usage errors (PW.TOO_MANY_PRINTF_ARGS)
> /source-iuh/openbsc/openbsc/src/gprs/gprs_gmm.c: 120 in ()
> 114 case IU_EVENT_RAB_ASSIGN:
> 115 rc = sgsn_ranap_rab_ass_resp(mm, (RANAP_RAB_SetupOrModifiedItemIEs_t *)data);
> 116 break;
> 117 case IU_EVENT_IU_RELEASE:
> 118 mm->iu.integrity_active = 0;
> 119 /* Clean up ue_conn_ctx here */
>>>> CID 76332: API usage errors (PW.TOO_MANY_PRINTF_ARGS)
>>>> the format string ends before this argument
> 120 LOGMMCTXP(LOGL_INFO, mm, "IU release\n", type);
harmless, but easy to fix and the compiler already warns
>
> 46 llist_for_each_entry(conn, &network->subscr_conns, entry) {
>>>> CID 76331: API usage errors (PW.PRINTF_ARG_MISMATCH)
>>>> argument is incompatible with corresponding format string conversion
> 47 DEBUGP(DIUCS, "%3d: %s", i++, subscr_name(conn->subscr));
please avoid side-effects like this in DEBUGP. It might be completely off but with recent changes it might or might not be evaluated depending on your logging settings.
holger
Hello all!
I just quickly looked at the gsm48_mi_to_string() method in gsm48.c.
I found that it is used in several projects like OsmocomBB and OpenBSC,
but it seems a bit strange to me that the TMSI represented in decimal...
> ...
> uint32_t tmsi;
> ...
> return snprintf(string, str_len, "%u", tmsi);
> ...
Can we move to use a hex representation instead of decimal? And why if not?
> ...
> uint32_t tmsi;
> ...
> return snprintf(string, str_len, "%x", tmsi);
> ...
С наилучшими пожеланиями,
Яницкий Вадим.