OpenBSC

openbsc@lists.osmocom.org

11 participants
4278 discussions

OpenBSC + LCR
by Gus Bourg 06 Aug '11

06 Aug '11

Hello all, I'm attempting to make my OpenBSC setup work with LCR and Asterisk. I'm not sure if the problem that I'm running into is specific to the nature of my setup (running a Nokia BTS) or is a misconfiguration issue with LCR. When I run without LCR and Asterisk I can call between phones, SMS etc. With LCR I have no such luck. I can place a call into the mobile from Asterisk, and the mobile rings, but when I answer the call hangs up. A pastebin of the LCR log can be found here: http://pastebin.com/DbM3TfFp Any insight into the cause would be much appreciated. :) Thanks, Gus

1 0

[PATCH] GPRS: Fix the parsing/interpretation of the PDP CTX status IE
by Harald Welte 06 Aug '11

06 Aug '11

The byte ordering is a bit odd: The least significant byte is ahead of the most significant byte, different from everything else in GSM that seems to be big-endian. Thanks to Seungju Kim <admin(a)manateeshome.com> for repoerting the bug. --- openbsc/src/gprs/gprs_gmm.c | 24 ++++++++++++++++-------- 1 files changed, 19 insertions(+), 11 deletions(-) diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index 098e4c2..c9fe517 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -867,7 +867,7 @@ static int gsm48_tx_gmm_ra_upd_rej(struct msgb *old_msg, uint8_t cause) } static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx, - uint16_t pdp_status) + uint8_t *pdp_status) { struct sgsn_pdp_ctx *pdp, *pdp2; /* 24.008 4.7.5.1.3: If the PDP context status information element is @@ -878,11 +878,20 @@ static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx, * being in state PDP-INACTIVE. */ llist_for_each_entry_safe(pdp, pdp2, &mmctx->pdp_list, list) { - if (!(pdp_status & (1 << pdp->nsapi))) { - LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " - "due to PDP CTX STATUS IE= 0x%04x\n", - pdp->nsapi, pdp_status); - sgsn_delete_pdp_ctx(pdp); + if (pdp->nsapi < 8) { + if (!(pdp_status[0] & (1 << pdp->nsapi))) { + LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " + "due to PDP CTX STATUS IE= 0x%02x%02x\n", + pdp->nsapi, pdp_status[1], pdp_status[0]); + sgsn_delete_pdp_ctx(pdp); + } + } else { + if (!(pdp_status[1] & (1 << (pdp->nsapi - 8)))) { + LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " + "due to PDP CTX STATUS IE= 0x%02x%02x\n", + pdp->nsapi, pdp_status[1], pdp_status[0]); + sgsn_delete_pdp_ctx(pdp); + } } } } @@ -975,8 +984,7 @@ static int gsm48_rx_gmm_ra_upd_req(struct sgsn_mm_ctx *mmctx, struct msgb *msg, /* Look at PDP Context Status IE and see if MS's view of * activated/deactivated NSAPIs agrees with our view */ if (TLVP_PRESENT(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)) { - uint16_t pdp_status = ntohs(*(uint16_t *) - TLVP_VAL(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)); + uint8_t *pdp_status = TLVP_VAL(&tp, GSM48_IE_GMM_PDP_CTX_STATUS); process_ms_ctx_status(mmctx, pdp_status); } -- 1.7.5.4 --CE+1k2dSO48ffgeK--

1 0

[PATCH] GPRS: Fix the byte ordering of the PDP context status IE
by Harald Welte 04 Aug '11

04 Aug '11

It seems that 24.008 Section 10.5.7.1 specifies the IE to be encoded in little endian... --- openbsc/src/gprs/gprs_gmm.c | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index 098e4c2..f83219f 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -870,6 +870,7 @@ static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx, uint16_t pdp_status) { struct sgsn_pdp_ctx *pdp, *pdp2; + uint16_t pdp_status_reordered; /* 24.008 4.7.5.1.3: If the PDP context status information element is * included in ROUTING AREA UPDATE REQUEST message, then the network * shall deactivate all those PDP contexts locally (without peer to @@ -877,8 +878,13 @@ static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx, * state PDP-INACTIVE on network side but are indicated by the MS as * being in state PDP-INACTIVE. */ + /* 24.008 10.5.7.1 indicates that the byte ordering is in fact + * little endian, i.e. the first octet contains NSAPI0..7 and + * the second payload octet NSAPI8..15 */ + pdp_status_reordered = (pdp_status & 0xff << 8) || (pdp_status >> 8); + llist_for_each_entry_safe(pdp, pdp2, &mmctx->pdp_list, list) { - if (!(pdp_status & (1 << pdp->nsapi))) { + if (!(pdp_status_reordered & (1 << pdp->nsapi))) { LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " "due to PDP CTX STATUS IE= 0x%04x\n", pdp->nsapi, pdp_status); @@ -977,6 +983,10 @@ static int gsm48_rx_gmm_ra_upd_req(struct sgsn_mm_ctx *mmctx, struct msgb *msg, if (TLVP_PRESENT(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)) { uint16_t pdp_status = ntohs(*(uint16_t *) TLVP_VAL(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)); + /* pdp_status is now in big endian, which is the wrong + * order. the wire encoding is little endian! We cannot + * simply drop the ntohs() above, as we migh be running + * on a big endian machine. */ process_ms_ctx_status(mmctx, pdp_status); } -- 1.7.5.4 --iq/fWD14IMVFWBCD--

1 0

Packages in pkgsrc-wip (for NetBSD and more)
by Pierre Pronchery 04 Aug '11

04 Aug '11

Hi openbsc@, for the record I have just packaged libosmocore 0.1.30 and OpenBSC 0.9.13 in pkgsrc-wip, as released by Harald about 5 months ago, see: http://openbsc.osmocom.org/trac/wiki/Tarballs and http://cvsweb.netbsd.se/cgi-bin/bsdweb.cgi/wip/libosmocore/ http://cvsweb.netbsd.se/cgi-bin/bsdweb.cgi/wip/openbsc/ I had to apply a few changes, patches are found in the two links above (not all of them good enough to be pushed though). Unfortunately OpenBSC is probably not useful on NetBSD at the moment, except with the isdn4bsd patches maybe (which I don't think are maintained anymore). pkgsrc can be useful on Linux distributions though. HTH anyway, -- khorben

2 2

GSM @ Camp 2011 preparations
by Harald Welte 02 Aug '11

02 Aug '11

Hi Peter and others, it seems like the situation regarding the GSM network at the Camp is starting to become clearer every day. I am still arguing that two relatively large BTS with circular antennas are a good idea. Therefore, I have now applied for a test license with the regulatory authority with the following parameters: * six GSM 1800 ARFCN * two antennas, circular, 18 meters above ground * 5W output power on each ARFCN. I know one of my customers in Germany has once managed to get a license for 5W, so I thought it is a good bet we should get the same. It should be more than sufficient to cover the camp. * from August 2nd through August 15th, i.e. we have time for build-up and can also run it one more day during shutdown of the camp I should be receiving "Motorola Horizon Macro" BTSs with 3 to 6 TRX each soon. They are able to drive something like >= 20W output power, way more than we need. The only problem with those BTS is: We will need to add the Motorola A-bis dialect to OpenBSC before the Camp, which could be a tough task depending on how far they are off the standard A-bis as specified in 08.58 and 12.21. If we cannot make those BTS work, our options are somewhat limited. 1) nanoBTS based The nanoBTS are 200mW only, so we would need a booster. Those cost about 1000 EUR for 6W downlink power + 18dB uplink LNA. Who is going to fund that? Also, we would need a combiner/splitter to run something like a 3-TRX setup. 2) Ericsson RBS I should have two RBS 2308 (4TRX each) soon, but both of them are GSM 1900. It is unlikely that we ge a license, and a lot of phones probably don't support it. So unless they can somehow be converted to 1800 MHz units, they are not a good fit either :/ 3) Siemens BS-11 All of them are GSM 900. No way to get a license in Germany, sorry. So we basically _have to_ make the Motorola Horizon work... 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)

4 12

AW: Current OpenBSC + LCR using MNCC socket
by Andreas.Eversberg 01 Aug '11

01 Aug '11

> I've committed some changes a couple of minutes ago (to libosmocore + > openbsc) that make lcr compile again. > The problem is: The query is always false, so no messages are sent to OpenBSC. > If I comment out the if-query, everything works as expected: Calls can be made mobile originated and mobile terminated. > However, I don't think the if-query is there without a reason. Since there is only one (gsm-)network instance, the "gsm->network" pointer must be set to something != NULL. Then it should work Thanx, applied both fixes. (blindly) Please try if it works.

5 11

Camp preparation and pySim
by Holger Hans Peter Freyther 30 Jul '11

30 Jul '11

Hi Sylvain, do we need such a hack on top of the 27c3 branch for the upcoming camp? I will try to create a proper patch before the start of the camp. holger

1 0

nanoBTS + external Antennas + Repeater
by Lennart Müller 27 Jul '11

27 Jul '11

Good morning, I would like to use two directional antennas with a nanoBTS DCS1800. As far as I know, first I need a duplexer to use one antenna both for RX and TX - does anybody know a cheap model? I found only one for 500 Euros. Second, to connect two antennas to the duplexer, I need a power splitter. Can somebody suggest one for duplex usage? Third, to improve indoor signal level, there are plenty offers of duplex repeaters, but the legal situation is unclear because one might produce distortion on ARFCNs different from his own. Again, anyone with experience? Maybe a suggestion for a model with a fixed ARFCN setting? Thanks, Lennart

2 1

sms bugfix
by Dennis Wehrle 26 Jul '11

26 Jul '11

Hello Our goal was to send status sms via the vty interface. But all of our sms were cropped. In contrast sms from one MS to another MS are displayed correctly (despite the fact, that the text at the database contains several '@' at the end / the user_data contains several zero-octets). Therefore i have inspect the code and found several bugs. The main problem is that the "user_data_len" is not correctly used. As per GSM 03.40, 9.2.3.16 TP‑User‑Data‑Length (TP‑UDL): "If the TP‑User‑Data is coded using the GSM 7 bit default alphabet, the TP‑User‑Data‑Length field gives an integer representation of the number of septets within the TP‑User‑Data field to follow." Currently the "user_data_len" contains the number of octets (returned from gsm_7bit_encode(...) at gsm_utils.c (libosmocore)). The big problem here is that this information is not unique, e.g.: 1.) 46 non-extension characters + 1 extension character => (46 * 7 bit + (1 * (2 * 7 bit))) / 8 bit = 42 octets 2.) 47 non-extension characters => (47 * 7 bit) / 8 bit = 41,125 = 42 octets 3.) 48 non-extension characters => (48 * 7 bit) / 8 bit = 42 octects But the MS has to know the correct "user_data_len" to decode the correct number of characters. For this reason i updated the gsm_7bit_encode() function to return the correct number of septets. However sometimes it is needed to know the correct number of octets (e.g. at gsm_04_11.c: gsm340_gen_tpdu(...)) => i added a function to gsm_utils.c named: uint8_t get_octet_len(const uint8_t sept_len) I have also fixed the problem, that the sms are wrongly stored / displayed on the database. But the solution on the function *sms_from_result(...) (at db.c) is not really "beautiful". This is because there exists no "user_data_len" field at the database. To store the right value for "user_data_len" (which is further needed) i have to get the length from the "text" field. Unfortunately this is not enough. If the text contains extension characters like {[]} etc. then the "user_data_len" has to be bigger because these characters needs two septets. Therefore i use a switch statement so search for these characters. A better solution for that is to store the right "user_data_len" to the database (on the encoding / decoding procedure). But i don't know if this is a suitable solution for all of you (because you have to change your database structure etc.). Best Regards Dennis Wehrle

6 24

[PATCH] sms: Kill the text field, fix the size and truncation
by Holger Hans Peter Freyther 25 Jul '11

25 Jul '11

Patches from Dennis Wehrle, fix the truncation of SMS from the VTY --- openbsc/src/libmsc/db.c | 34 +++++++++++++++------------------- openbsc/src/libmsc/gsm_04_11.c | 2 +- openbsc/src/libmsc/gsm_04_80.c | 4 +++- 3 files changed, 19 insertions(+), 21 deletions(-) diff --git a/openbsc/src/libmsc/db.c b/openbsc/src/libmsc/db.c index 53675f7..d1dd749 100644 --- a/openbsc/src/libmsc/db.c +++ b/openbsc/src/libmsc/db.c @@ -51,7 +51,7 @@ static char *create_stmts[] = { "INSERT OR IGNORE INTO Meta " "(key, value) " "VALUES " - "('revision', '2')", + "('revision', '3')", "CREATE TABLE IF NOT EXISTS Subscriber (" "id INTEGER PRIMARY KEY AUTOINCREMENT, " "created TIMESTAMP NOT NULL, " @@ -108,9 +108,7 @@ static char *create_stmts[] = { "ud_hdr_ind INTEGER NOT NULL, " "dest_addr TEXT, " "user_data BLOB, " /* TP-UD */ - /* additional data, interpreted from SMS */ - "header BLOB, " /* UD Header */ - "text TEXT " /* decoded UD after UDH */ + "ud_length INTEGER NOT NULL " ")", "CREATE TABLE IF NOT EXISTS VLR (" "id INTEGER PRIMARY KEY AUTOINCREMENT, " @@ -177,7 +175,7 @@ static int check_db_revision(void) return -EINVAL; } rev = dbi_result_get_string(result, "value"); - if (!rev || atoi(rev) != 2) { + if (!rev || atoi(rev) != 3) { dbi_result_free(result); return -EINVAL; } @@ -990,15 +988,16 @@ int db_subscriber_assoc_imei(struct gsm_subscriber *subscriber, char imei[GSM_IM int db_sms_store(struct gsm_sms *sms) { dbi_result result; - char *q_text, *q_daddr; + char *q_daddr; unsigned char *q_udata; char *validity_timestamp = "2222-2-2"; + uint8_t octet_len = 0; /* FIXME: generate validity timestamp based on validity_minutes */ - dbi_conn_quote_string_copy(conn, (char *)sms->text, &q_text); dbi_conn_quote_string_copy(conn, (char *)sms->dest_addr, &q_daddr); - dbi_conn_quote_binary_copy(conn, sms->user_data, sms->user_data_len, + octet_len = gsm_get_octet_len(sms->user_data_len); + dbi_conn_quote_binary_copy(conn, sms->user_data, octet_len, &q_udata); /* FIXME: correct validity period */ result = dbi_conn_queryf(conn, @@ -1006,15 +1005,14 @@ int db_sms_store(struct gsm_sms *sms) "(created, sender_id, receiver_id, valid_until, " "reply_path_req, status_rep_req, protocol_id, " "data_coding_scheme, ud_hdr_ind, dest_addr, " - "user_data, text) VALUES " + "user_data, ud_length) VALUES " "(datetime('now'), %llu, %llu, %u, " - "%u, %u, %u, %u, %u, %s, %s, %s)", + "%u, %u, %u, %u, %u, %s, %s, %u)", sms->sender->id, sms->receiver ? sms->receiver->id : 0, validity_timestamp, sms->reply_path_req, sms->status_rep_req, sms->protocol_id, sms->data_coding_scheme, sms->ud_hdr_ind, - q_daddr, q_udata, q_text); - free(q_text); + q_daddr, q_udata, sms->user_data_len); free(q_daddr); free(q_udata); @@ -1029,8 +1027,9 @@ static struct gsm_sms *sms_from_result(struct gsm_network *net, dbi_result resul { struct gsm_sms *sms = sms_alloc(); long long unsigned int sender_id, receiver_id; - const char *text, *daddr; + const char *daddr; const unsigned char *user_data; + int octet_len; if (!sms) return NULL; @@ -1059,17 +1058,14 @@ static struct gsm_sms *sms_from_result(struct gsm_network *net, dbi_result resul sms->dest_addr[sizeof(sms->dest_addr)-1] = '\0'; } - sms->user_data_len = dbi_result_get_field_length(result, "user_data"); + sms->user_data_len = dbi_result_get_uint(result, "ud_length"); user_data = dbi_result_get_binary(result, "user_data"); + if (sms->user_data_len > sizeof(sms->user_data)) sms->user_data_len = (uint8_t) sizeof(sms->user_data); + octet_len = gsm_get_octet_len(sms->user_data_len); memcpy(sms->user_data, user_data, sms->user_data_len); - text = dbi_result_get_string(result, "text"); - if (text) { - strncpy(sms->text, text, sizeof(sms->text)); - sms->text[sizeof(sms->text)-1] = '\0'; - } return sms; } diff --git a/openbsc/src/libmsc/gsm_04_11.c b/openbsc/src/libmsc/gsm_04_11.c index ee7f577..ad3b300 100644 --- a/openbsc/src/libmsc/gsm_04_11.c +++ b/openbsc/src/libmsc/gsm_04_11.c @@ -628,7 +628,7 @@ static int gsm340_rx_tpdu(struct gsm_subscriber_connection *conn, struct msgb *m switch (sms_alphabet) { case DCS_7BIT_DEFAULT: - gsm_7bit_decode(gsms->text, smsp, gsms->user_data_len); + gsm_7bit_decode_hdr(gsms->text, smsp, gsms->user_data_len, gsms->ud_hdr_ind); break; case DCS_8BIT_DATA: case DCS_UCS2: diff --git a/openbsc/src/libmsc/gsm_04_80.c b/openbsc/src/libmsc/gsm_04_80.c index 39738a5..c7dad43 100644 --- a/openbsc/src/libmsc/gsm_04_80.c +++ b/openbsc/src/libmsc/gsm_04_80.c @@ -68,12 +68,14 @@ int gsm0480_send_ussd_response(struct gsm_subscriber_connection *conn, struct msgb *msg = gsm48_msgb_alloc(); struct gsm48_hdr *gh; uint8_t *ptr8; + uint8_t octet_len; int response_len; /* First put the payload text into the message */ ptr8 = msgb_put(msg, 0); response_len = gsm_7bit_encode(ptr8, response_text); - msgb_put(msg, response_len); + octet_len = gsm_get_octet_len(response_len); + msgb_put(msg, octet_len); /* Then wrap it as an Octet String */ msgb_wrap_with_TL(msg, ASN1_OCTET_STRING_TAG); -- 1.7.4.1 --------------090106040904000308080203--

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC