OpenBSC January 2014

openbsc@lists.osmocom.org

33 participants
53 discussions

GPRS - local and foreign TLLIs
by Luca Melette 04 Feb '26

04 Feb '26

Hello everybody, after setting up a nanoBTS with OpenBSC/SGSN/GGSN, I had some troubles trying to connect my smartphone to the GPRS cell. Investigating the BTS-to-SGSN traffic, I saw that the frames sent by the SGSN were all marked with the same N(U) value (at LLC layer), the value was 0. With some debug, I found that the there was a mismatch in the TLLI storage, used to keep the status of attached terminals. The mentioned code is contained in gprs_llc.c, involving LL Entity functions and gprs_llc_tx_ui(). /* look-up or create the LL Entity for this (TLLI, SAPI) tuple */ lle = lle_by_tlli_sapi(msgb_tlli(msg), sapi); if (!lle) { struct gprs_llc_llme *llme; LOGP(DLLC, LOGL_ERROR, "LLC TX: unknown TLLI 0x%08x, " "creating LLME on the fly\n", msgb_tlli(msg)); llme = llme_alloc(msgb_tlli(msg)); lle = &llme->lle[sapi]; } The TX function uses the previously received TLLI to lookup for the LLE. The lle_by_tlli_sapi() performs the search, but preliminary it applies a foreign2local TLLI conversion to ensure to have a local one. Since no valid entry for the searched TLLI is found, a new one is created. And the problem is here. The new entry has the foreign TLLI. Next time the lookup fails again, and a new entry is created. This way, the counter N(U) is always reset, and the mobile do not recognize the message sequence and no attach is possible. My question is about foreign and local TLLIs. I patched the lookup, avoiding the conversion, so that the LLE is found and everything works fine... but... What is the sense of the conversion? Should the TLLI be always stored as a local one? Can this problem be solved with another foreign2local while allocating new entries? Actually, my problem has been solved with that workaround. But I'm curious to know what is the right way. Hope somebody can answer :) Thanks. Cheers, LM

5 6

Pysim error: SW match failed
by Martin Nagy 16 Aug '25

16 Aug '25

Hi all, After buying a super Sim Kit (16 in 1) from China, I tried the reader (green PCB inside a blue transparent plastic case with a blue LED) and SIM (identified as a fakesupersim) with pysim tool. However i am getting the following error: /pySim-prog.py -n 26C3 -c 49 -x 262 -y 42 -z 1234 -j 1 -t auto Insert card now (or CTRL-C to cancel) Autodetected card type fakemagicsim Generated card parameters : > Name : 26C3 > SMSP : e1ffffffffffffffffffffffff058100945555ffffffffffff000000 > ICCID : 8949262427518313026 > MCC/MNC : 262/42 > IMSI : 262422461512085 > Ki : 7b74741a1ee14337ec23f9ab92a13648 > OPC : ccd867d60797d8d45354a51b3ef568ff Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 530, in <module> card.program(cp) File "/home/nadicek/pysim/pysim/pySim/cards.py", line 231, in program self._scc.update_binary('6f30', hplmn + 'ff' * (tl-3)) File "/home/nadicek/pysim/pysim/pySim/commands.py", line 53, in update_binary return self._tp.send_apdu_checksw(pdu) File "/home/nadicek/pysim/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed ! Expected 9000 and got 9804. I checked mailing lists and haven’t found anybody who had similar problem with pysim. Also I have tried forcing different models of SIM, but nothing is working. Obviously I can remove this check from the script file (__init__.py in /pySim/transport), however somebody had a reason to put such condition there. I would like to ask if it is safe to remove that line of code and the purpose of that line of code. Thanks a lot and best regards Martin

3 3

Re: Help with sccp library
by mosbah abdelkader 08 Jul '25

08 Jul '25

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

4 3

[PATCH] sms_queue, smpp: Refactor MO SUBMIT code to make further changes easier.
by Alexander Chemeris 09 Mar '14

09 Mar '14

This is required to implement normal prefix/regexp routing in addition to the current "if unroutable" model. --- openbsc/src/libmsc/gsm_04_11.c | 63 +++++++++++++++++++++++----------------- 1 file changed, 37 insertions(+), 26 deletions(-) diff --git a/openbsc/src/libmsc/gsm_04_11.c b/openbsc/src/libmsc/gsm_04_11.c index e554b74..7e8ede8 100644 --- a/openbsc/src/libmsc/gsm_04_11.c +++ b/openbsc/src/libmsc/gsm_04_11.c @@ -279,6 +279,39 @@ static int gsm340_gen_tpdu(struct msgb *msg, struct gsm_sms *sms) return msg->len - old_msg_len; } +static int sms_queue_try_deliver(struct gsm_subscriber_connection *conn, + struct msgb *msg, struct gsm_sms *gsms) +{ + /* determine gsms->receiver based on dialled number */ + gsms->receiver = subscr_get_by_extension(conn->bts->network, gsms->dst.addr); + if (!gsms->receiver) { + rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED; + goto out; + } + + switch (sms_mti) { + case GSM340_SMS_SUBMIT_MS2SC: + /* MS is submitting a SMS */ + rc = gsm340_rx_sms_submit(msg, gsms); + break; + case GSM340_SMS_COMMAND_MS2SC: + case GSM340_SMS_DELIVER_REP_MS2SC: + LOGP(DLSMS, LOGL_NOTICE, "Unimplemented MTI 0x%02x\n", sms_mti); + rc = GSM411_RP_CAUSE_IE_NOTEXIST; + break; + default: + LOGP(DLSMS, LOGL_NOTICE, "Undefined MTI 0x%02x\n", sms_mti); + rc = GSM411_RP_CAUSE_IE_NOTEXIST; + break; + } + + if (!rc && !gsms->receiver) + rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED; + +out: + return rc; +} + /* process an incoming TPDU (called from RP-DATA) * return value > 0: RP CAUSE for ERROR; < 0: silent error; 0 = success */ static int gsm340_rx_tpdu(struct gsm_subscriber_connection *conn, struct msgb *msg) @@ -393,44 +426,22 @@ static int gsm340_rx_tpdu(struct gsm_subscriber_connection *conn, struct msgb *m /* FIXME: This looks very wrong */ send_signal(0, NULL, gsms, 0); - /* determine gsms->receiver based on dialled number */ - gsms->receiver = subscr_get_by_extension(conn->bts->network, gsms->dst.addr); - if (!gsms->receiver) { + rc = sms_queue_try_deliver(conn, msg, gsms); + if (rc == GSM411_RP_CAUSE_MO_NUM_UNASSIGNED) { #ifdef BUILD_SMPP rc = smpp_try_deliver(gsms, conn); - if (rc == 1) { - rc = 1; /* cause 1: unknown subscriber */ + if (rc == GSM411_RP_CAUSE_MO_NUM_UNASSIGNED) { osmo_counter_inc(conn->bts->network->stats.sms.no_receiver); } else if (rc < 0) { - rc = 21; /* cause 21: short message transfer rejected */ + rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED; /* FIXME: handle the error somehow? */ } #else - rc = 1; /* cause 1: unknown subscriber */ osmo_counter_inc(conn->bts->network->stats.sms.no_receiver); #endif goto out; } - switch (sms_mti) { - case GSM340_SMS_SUBMIT_MS2SC: - /* MS is submitting a SMS */ - rc = gsm340_rx_sms_submit(msg, gsms); - break; - case GSM340_SMS_COMMAND_MS2SC: - case GSM340_SMS_DELIVER_REP_MS2SC: - LOGP(DLSMS, LOGL_NOTICE, "Unimplemented MTI 0x%02x\n", sms_mti); - rc = GSM411_RP_CAUSE_IE_NOTEXIST; - break; - default: - LOGP(DLSMS, LOGL_NOTICE, "Undefined MTI 0x%02x\n", sms_mti); - rc = GSM411_RP_CAUSE_IE_NOTEXIST; - break; - } - - if (!rc && !gsms->receiver) - rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED; - out: sms_free(gsms); -- 1.7.9.5

1 1

[PATCH] Use generic osmocom auth api
by ☎ 08 Mar '14

08 Mar '14

Hi. Attached is a small patch which replaces direct call to comp128 from libosmocore to auth api call. This will help to remove comp128 from libosmocore public api and to use other auth functions in openbsc in future. -- best regards, Max, http://fairwaves.ru

4 7

LAPDm code issues (ladpm.c)
by Jacob Erlbeck 21 Feb '14

21 Feb '14

Hi LAPDm guys, while I was digging into the LAPDm code to find out, why a broken SABM message is sent on a SAPI3 establish SACCH request during an active call (leading to a delay of 3s between RSL EST request and response), I stumbled over the following: The initial SABM message (not the retransmitted one after T200) has a non-zero length and ends with 3 bytes that have been taken from the end of the RSL EST REQ message. The MS does not answer to this. Interestingly the second SABM message that gets sent after T200 (2s) has a length field of 0 and no trailing garbage. The difference lies in the way the msgb is handled. In rslms_rx_rll_est_req() the msg buffer passed from RSL is being used. In the case of IPA, the l2h is prepended by the 3 byte IPA header. Since all code in lapdm.c that handles RSL message seem to assume, that msg->data == msg->l2h, length computation is done based on that assumption in some places. In addition, msgb_pull() is used in a way that would also lead to undefined results in this case, e.g. in msgb_pull_l2h() just the difference between l2h and l3h is pulled from the beginning (msg->data). The main difficulty to find this, was that much msgb handling is done by manual access to the msgb fields. I'd really favor the use of the predefined macros/inlines instead of meddling around with the fields. I've added a function msgb_pull_to_l3() to msgb.h which just skips over everything in front of l3 (and therefore invalidates l2h and l1h) and replaced all calls to msgb_pull_l2h() by calls to msgb_pull_to_l3(). In addition, I replaced manual l3 length adjustment by calls to msgb_trim(). That alone fixed the SABM issue described above. See the jerlbeck/fixes/lapd-sms branch for details. But AFAICS there is still something to do: - The remaining msgb_pull() need to be checked (at least the one in l2_ph_data_ind() looks suspicious to me. - L3 length computation should be done with the macros, how it is done in lapdm_send_ph_data_req() is broken. - Why does lapd_msg_ctx have a length field that is not used? - ladp_test.c should be extended to check other execution paths, too. I've tried it for dummy packets and I didn't get it working without failing assertions (see below) - How l2/data/.. in a msg are expected to be used/set should be documented somewhere. - It should be clarified, whether all abis driver should reset the msg to start with l2. Cheers Jacob ====== The following patch still breaks the assertions, at least changing the l3len computation in lapdm_send_ph_data_req() influences but doesn't fix it. --- a/tests/lapd/lapd_test.c +++ b/tests/lapd/lapd_test.c @@ -123,8 +123,10 @@ static struct msgb *create_empty_msg(void) static struct msgb *create_dummy_data_req(void) { struct msgb *msg; + const int dummy_l1len = 3; msg = msgb_from_array(dummy1, sizeof(dummy1)); + msgb_push(msg, dummy_l1len); rsl_rll_push_l3(msg, RSL_MT_DATA_REQ, 0, 0, 1); return msg; }

3 5

Unbounded AGCH queue in OsmoBTS
by Alexander Chemeris 14 Feb '14

14 Feb '14

Hi all, We're moving this discussion to the mailing list, as it seems it is more generic and complex than we've thought initially. The issue arose when I started doing load testing of the OsmoTRX transceiver and disabled all gating in it. As a result, all incoming noise was processed as valid Normal Bursts and Access Bursts and sent up to OsmoBTS. This leads to a situation, similar to a RACH flood, when there are more RACH requests coming, than a BTS could reasonably process. And this leads to an unbounded increase of the AGCH queue in the BTS - it consumes a few Mb per minute. I think that this is the root cause of the issue we've seen at a Netherlands festival installation, when 20K phones suddenly started connecting to our station after official networks went down. When the amount of RACH requests exceeded available CCCH capacity (took <5 seconds), mobile phones stopped answering out IMM.ASS messages. Hypothesis is that the AGCH queue became so long, requests were sent too late for a phone to receive it. And thus no phones answered to our IMM.ASS messages. Unfortunately, I wasn't able to collect enough data to check this hypothesis during that time and we don't have another big festival on hands atm. An attached is a quick fix for the unbounded queue growth. It uses a hardcoded value for the maximum queue length, which is fine for our load testing, but not flexible enough for the real life usage. We should make the AGCH queue long enough to keep high performance. At the same time, it must not exceed MS timeout or _all_ IMM.ASS messages will miss their target MS's. We could make this parameter user-configurable on a BTS side, but it seems more reasonable to automatically calculate it, depending on the channel combination and timeout values. But this should be done on the BSC side. So the questions are: 1) what is a good way to calculate it? 2) should we configure this queue length over OML, or move the queue from BTS to BSC? -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

5 23

osmoSGSN
by Michal Grznár 12 Feb '14

12 Feb '14

Hi, I am trying to use osmoSGSN in topology with openGGSN and sim-bss, which is simulator of BSS made by company Alcatel-Lucent. I have a problem that my osmoSGSN can not communicate with sim-BSS and it can not connect correctly. It is caused by non function bssgp. I would like to ask you, how can I configure bssgp on osmoSGSN? I can configure ns states also from vty on osmoSGSN but I can not bssgp states such as bvci etc...Please could you help me? I hope you will reply me soon. Thank you very much Best regards, Michal Grznár

2 3

[PATCH 1/5] mgcp/test: Only include conn_mode into test output
by Jacob Erlbeck 31 Jan '14

31 Jan '14

Currently the conn_mode and the output_enabled flags are printed to stdout. This patch modifies this to print the output_enabled flags to stderr instead. The bits in conn_mode are shown as RECV, SEND, and LOOP. This does not reduce the significance of the test, since there is an assertion already that verifies the values of the output_enabled flags with respect to the conn_mode. Sponsored-by: On-Waves ehf --- openbsc/tests/mgcp/mgcp_test.c | 21 +++++++++++++++------ openbsc/tests/mgcp/mgcp_test.ok | 18 +++++++++--------- 2 files changed, 24 insertions(+), 15 deletions(-) diff --git a/openbsc/tests/mgcp/mgcp_test.c b/openbsc/tests/mgcp/mgcp_test.c index fa68867..5f69072 100644 --- a/openbsc/tests/mgcp/mgcp_test.c +++ b/openbsc/tests/mgcp/mgcp_test.c @@ -399,13 +399,22 @@ static void test_messages(void) else printf("Requested packetization period not set\n"); - if ((endp->conn_mode & CONN_UNMODIFIED) == 0) - printf("Connection mode: %d, " - "BTS output %sabled, NET output %sabled\n", + if ((endp->conn_mode & CONN_UNMODIFIED) == 0) { + printf("Connection mode: %d:%s%s%s%s\n", endp->conn_mode, - endp->bts_end.output_enabled ? "en" : "dis", - endp->net_end.output_enabled ? "en" : "dis"); - else + !endp->conn_mode ? " NONE" : "", + endp->conn_mode & MGCP_CONN_SEND_ONLY ? + " SEND" : "", + endp->conn_mode & MGCP_CONN_RECV_ONLY ? + " RECV" : "", + endp->conn_mode & MGCP_CONN_LOOPBACK & + ~MGCP_CONN_RECV_SEND ? + " LOOP" : ""); + fprintf(stderr, + "BTS output %sabled, NET output %sabled\n", + endp->bts_end.output_enabled ? "en" : "dis", + endp->net_end.output_enabled ? "en" : "dis"); + } else printf("Connection mode not set\n"); OSMO_ASSERT(endp->net_end.output_enabled == diff --git a/openbsc/tests/mgcp/mgcp_test.ok b/openbsc/tests/mgcp/mgcp_test.ok index fbe2566..76806f9 100644 --- a/openbsc/tests/mgcp/mgcp_test.ok +++ b/openbsc/tests/mgcp/mgcp_test.ok @@ -19,7 +19,7 @@ Testing CRCX Dummy packets: 1 Detected packet duration: 40 Requested packetetization period: 20-20 -Connection mode: 1, BTS output enabled, NET output disabled +Connection mode: 1: RECV Testing MDCX3 Dummy packets: 1 Packet duration not set @@ -29,35 +29,35 @@ Testing MDCX4 Dummy packets: 1 Detected packet duration: 40 Requested packetetization period: 20-20 -Connection mode: 3, BTS output enabled, NET output enabled +Connection mode: 3: SEND RECV Testing MDCX4_PT1 Dummy packets: 1 Detected packet duration: 40 Requested packetetization period: 20-40 -Connection mode: 3, BTS output enabled, NET output enabled +Connection mode: 3: SEND RECV Testing MDCX4_PT2 Dummy packets: 1 Detected packet duration: 40 Requested packetetization period: 20-20 -Connection mode: 3, BTS output enabled, NET output enabled +Connection mode: 3: SEND RECV Testing MDCX4_PT3 Dummy packets: 1 Detected packet duration: 40 Requested packetization period not set -Connection mode: 3, BTS output enabled, NET output enabled +Connection mode: 3: SEND RECV Testing MDCX4_SO Detected packet duration: 40 Requested packetetization period: 20-20 -Connection mode: 2, BTS output disabled, NET output enabled +Connection mode: 2: SEND Testing DLCX Detected packet duration: 20 Requested packetization period not set -Connection mode: 0, BTS output disabled, NET output disabled +Connection mode: 0: NONE Testing CRCX_ZYN Dummy packets: 1 Packet duration not set Requested packetization period not set -Connection mode: 1, BTS output enabled, NET output disabled +Connection mode: 1: RECV Testing EMPTY Testing SHORT1 Testing SHORT2 @@ -68,7 +68,7 @@ Testing RQNT2 Testing DLCX Detected packet duration: 20 Requested packetization period not set -Connection mode: 0, BTS output disabled, NET output disabled +Connection mode: 0: NONE Testing CRCX Re-transmitting CRCX Testing RQNT1 -- 1.7.9.5

2 9

[PATCH 1/9] Complete definitions for all speech traffic frames at MNCC interface
by Andreas Eversberg 31 Jan '14

31 Jan '14

The new definitions are: half rate and AMR Change of definition name for bad frame, because it applies to all types of traffic, not only TCH/F. Increase MNCC interface version to 4. --- openbsc/include/openbsc/mncc.h | 6 ++++-- openbsc/src/libmsc/mncc.c | 6 +++++- openbsc/src/libtrau/trau_mux.c | 2 +- openbsc/tests/trau/trau_test.c | 2 +- 4 files changed, 11 insertions(+), 5 deletions(-) diff --git a/openbsc/include/openbsc/mncc.h b/openbsc/include/openbsc/mncc.h index ffc247b..c61f6b8 100644 --- a/openbsc/include/openbsc/mncc.h +++ b/openbsc/include/openbsc/mncc.h @@ -95,7 +95,9 @@ struct gsm_call { #define GSM_TCHF_FRAME 0x0300 #define GSM_TCHF_FRAME_EFR 0x0301 -#define GSM_TCHF_BAD_FRAME 0x03ff +#define GSM_TCHH_FRAME 0x0302 +#define GSM_TCH_FRAME_AMR 0x0303 +#define GSM_BAD_FRAME 0x03ff #define MNCC_SOCKET_HELLO 0x0400 @@ -161,7 +163,7 @@ struct gsm_data_frame { unsigned char data[0]; }; -#define MNCC_SOCK_VERSION 2 +#define MNCC_SOCK_VERSION 4 struct gsm_mncc_hello { uint32_t msg_type; uint32_t version; diff --git a/openbsc/src/libmsc/mncc.c b/openbsc/src/libmsc/mncc.c index b484772..73db5f0 100644 --- a/openbsc/src/libmsc/mncc.c +++ b/openbsc/src/libmsc/mncc.c @@ -84,7 +84,11 @@ static struct mncc_names { {"MNCC_FRAME_DROP", 0x0202}, {"MNCC_LCHAN_MODIFY", 0x0203}, - {"GSM_TCH_FRAME", 0x0300}, + {"GSM_TCHF_FRAME", 0x0300}, + {"GSM_TCHF_FRAME_EFR", 0x0301}, + {"GSM_TCHH_FRAME", 0x0302}, + {"GSM_TCH_FRAME_AMR", 0x0303}, + {"GSM_BAD_FRAME", 0x03ff}, {NULL, 0} }; diff --git a/openbsc/src/libtrau/trau_mux.c b/openbsc/src/libtrau/trau_mux.c index 7b9bac0..fd1895f 100644 --- a/openbsc/src/libtrau/trau_mux.c +++ b/openbsc/src/libtrau/trau_mux.c @@ -314,7 +314,7 @@ struct msgb *trau_decode_efr(uint32_t callref, return msg; bad_frame: - frame->msg_type = GSM_TCHF_BAD_FRAME; + frame->msg_type = GSM_BAD_FRAME; return msg; } diff --git a/openbsc/tests/trau/trau_test.c b/openbsc/tests/trau/trau_test.c index f8a48db..b95f1e8 100644 --- a/openbsc/tests/trau/trau_test.c +++ b/openbsc/tests/trau/trau_test.c @@ -57,7 +57,7 @@ void test_trau_fr_efr(unsigned char *data) msg = trau_decode_efr(1, &tf); OSMO_ASSERT(msg != NULL); frame = (struct gsm_data_frame *)msg->data; - OSMO_ASSERT(frame->msg_type == GSM_TCHF_BAD_FRAME); + OSMO_ASSERT(frame->msg_type == GSM_BAD_FRAME); msgb_free(msg); } -- 1.8.1.5 --------------060708050209070502020504 Content-Type: text/x-diff; name="0002-Use-helper-function-to-check-if-an-MNCC-frame-is-dat.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0002-Use-helper-function-to-check-if-an-MNCC-frame-is-dat.pa"; filename*1="tch"

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2014