September 2014 - OpenBSC - lists.osmocom.org

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 07 Jul '25

07 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 0/4] core/conv: Fast Viterbi decoding
by Thomas Tsou 26 Apr '16

26 Apr '16

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

5 13

Final review of L1SAP ported to current maste
by Harald Welte 25 Mar '15

25 Mar '15

Dear all, the valuable L1SAP abstraction has been sitting out of master for too long time. It is a pity that this has taken so long. I've finally been able to put some time into osmo-bts again and reviewed the following patch series. It consists of mostly Andreas' work, interspersed with smaller patches/fixups that I introduced after the respective original patch from Andreas. I have started a sysmobts between all of the major steps in this patch series and did a short manual tests involving registration (LU) of two MS, mobile-to-mobile call and vty-to-mobile SMS. So far I couldn't see any problems. What has not been tested yet is the PCU interface as well as encryption support. I plan to do this later this week. I intend to merge the code after this current review cycle. Please take your time to have a look and provide feedback (if any), so we can get this over and work on new features again, rather than infrastrutural changes. I didn't yet rebase the osmo-bts-trx interface on top of the L1SAP, as I don't have a hardware setup for it, and I will leave it to the owners of such hardware to publish/push the respective code after L1SAP is merged. 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)

3 43

[PATCH] Add subscriber delete command
by Ruben Pollan 25 Sep '14

25 Sep '14

--- openbsc/include/openbsc/gsm_subscriber.h | 1 + openbsc/src/libbsc/gsm_subscriber_base.c | 2 +- openbsc/src/libmsc/vty_interface_layer3.c | 24 +++++++++++++++++++++++- 3 files changed, 25 insertions(+), 2 deletions(-) diff --git a/openbsc/include/openbsc/gsm_subscriber.h b/openbsc/include/openbsc/gsm_subscriber.h index 7aae4c3..120111b 100644 --- a/openbsc/include/openbsc/gsm_subscriber.h +++ b/openbsc/include/openbsc/gsm_subscriber.h @@ -101,6 +101,7 @@ int subscr_pending_kick(struct gsm_subscriber *subscr); char *subscr_name(struct gsm_subscriber *subscr); +void subscr_free(struct gsm_subscriber *subscr); int subscr_purge_inactive(struct gsm_network *net); void subscr_update_from_db(struct gsm_subscriber *subscr); void subscr_expire(struct gsm_network *net); diff --git a/openbsc/src/libbsc/gsm_subscriber_base.c b/openbsc/src/libbsc/gsm_subscriber_base.c index 5e00443..2b31e95 100644 --- a/openbsc/src/libbsc/gsm_subscriber_base.c +++ b/openbsc/src/libbsc/gsm_subscriber_base.c @@ -66,7 +66,7 @@ struct gsm_subscriber *subscr_alloc(void) return s; } -static void subscr_free(struct gsm_subscriber *subscr) +void subscr_free(struct gsm_subscriber *subscr) { llist_del(&subscr->entry); talloc_free(subscr); diff --git a/openbsc/src/libmsc/vty_interface_layer3.c b/openbsc/src/libmsc/vty_interface_layer3.c index 064eca9..6b53f65 100644 --- a/openbsc/src/libmsc/vty_interface_layer3.c +++ b/openbsc/src/libmsc/vty_interface_layer3.c @@ -465,7 +465,28 @@ DEFUN(subscriber_ussd_notify, return CMD_SUCCESS; } -DEFUN(ena_subscr_authorizde, +DEFUN(ena_subscr_delete, + ena_subscr_delete_cmd, + "subscriber " SUBSCR_TYPES " ID delete", + SUBSCR_HELP "Delete subscriber in HLR\n") +{ + struct gsm_network *gsmnet = gsmnet_from_vty(vty); + struct gsm_subscriber *subscr = + get_subscr_by_argv(gsmnet, argv[0], argv[1]); + + if (!subscr) { + vty_out(vty, "%% No subscriber found for %s %s%s", + argv[0], argv[1], VTY_NEWLINE); + return CMD_WARNING; + } + + db_subscriber_delete(subscr); + subscr_free(subscr); + + return CMD_SUCCESS; +} + +DEFUN(ena_subscr_authorized, ena_subscr_authorized_cmd, "subscriber " SUBSCR_TYPES " ID authorized (0|1)", SUBSCR_HELP "(De-)Authorize subscriber in HLR\n" @@ -982,6 +1003,7 @@ int bsc_vty_init_extra(void) install_element_ve(&show_stats_cmd); install_element_ve(&show_smsqueue_cmd); + install_element(ENABLE_NODE, &ena_subscr_delete_cmd); install_element(ENABLE_NODE, &ena_subscr_name_cmd); install_element(ENABLE_NODE, &ena_subscr_extension_cmd); install_element(ENABLE_NODE, &ena_subscr_authorized_cmd); -- 2.1.0

2 8

[PATCH 1/4] gprs: Fix and check BVCI in BSSGP STATUS messages
by Jacob Erlbeck 23 Sep '14

23 Sep '14

Currently the BVCI is not set in all invocations to bssgp_tx_status() when the cause is UNKNOWN_BVCI. This patch adds the argument where it is missing. It also adds a check for compliance (GSM 08.18, 10.4.14.1) to bssgp_tx_status() to emit errors when the following requirement is not fulfilled: The BVCI must be included if (and only if) the cause is either "BVCI blocked" or "BVCI unknown". Sponsored-by: On-Waves ehf --- src/gb/gprs_bssgp.c | 2 +- src/gb/gprs_bssgp_util.c | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/src/gb/gprs_bssgp.c b/src/gb/gprs_bssgp.c index 5ef1887..b8c6c74 100644 --- a/src/gb/gprs_bssgp.c +++ b/src/gb/gprs_bssgp.c @@ -998,7 +998,7 @@ int bssgp_rcvmsg(struct msgb *msg) LOGP(DBSSGP, LOGL_NOTICE, "NSEI=%u/BVCI=%u Rejecting PDU " "type %u for unknown BVCI\n", msgb_nsei(msg), ns_bvci, pdu_type); - return bssgp_tx_status(BSSGP_CAUSE_UNKNOWN_BVCI, NULL, msg); + return bssgp_tx_status(BSSGP_CAUSE_UNKNOWN_BVCI, &ns_bvci, msg); } if (bctx) { diff --git a/src/gb/gprs_bssgp_util.c b/src/gb/gprs_bssgp_util.c index ae4647e..261e0b0 100644 --- a/src/gb/gprs_bssgp_util.c +++ b/src/gb/gprs_bssgp_util.c @@ -99,6 +99,20 @@ int bssgp_tx_status(uint8_t cause, uint16_t *bvci, struct msgb *orig_msg) struct bssgp_normal_hdr *bgph = (struct bssgp_normal_hdr *) msgb_put(msg, sizeof(*bgph)); + /* GSM 08.18, 10.4.14.1: The BVCI must be included if (and only if) the + cause is either "BVCI blocked" or "BVCI unknown" */ + if (cause == BSSGP_CAUSE_UNKNOWN_BVCI || cause == BSSGP_CAUSE_BVCI_BLOCKED) { + if (bvci == NULL) + LOGP(DBSSGP, LOGL_ERROR, "BSSGP Tx STATUS, cause=%s: " + "missing conditional BVCI\n", + bssgp_cause_str(cause)); + } else { + if (bvci != NULL) + LOGP(DBSSGP, LOGL_ERROR, "BSSGP Tx STATUS, cause=%s: " + "unexpected conditional BVCI\n", + bssgp_cause_str(cause)); + } + LOGP(DBSSGP, LOGL_NOTICE, "BSSGP BVCI=%u Tx STATUS, cause=%s\n", bvci ? *bvci : 0, bssgp_cause_str(cause)); msgb_nsei(msg) = msgb_nsei(orig_msg); -- 1.9.1

2 5

Support for integrating RRLP with openbsc
by Kunal Dawn 22 Sep '14

22 Sep '14

Hello everyone I am new to openbsc, and trying to implement my own mobile network for my masters project. Till now everything has gone well and my network is working gud. But the issue is when I am trying to implement rrlp with openbsc. I have set the rrlp mode to ms-based, but there is no response from the phone on sending the request. I have checked that the request is going to the phone with the help of wireshark. So please anyone help me with this, that should i use E-OTD or ms-assisted method for getting the response from the phone. Thanking you in anticipation Kunal

1 0

OpenBSC running on an Odroid-XU
by John Baker 18 Sep '14

18 Sep '14

Hi, I have an Odroid-XU I have setup with Debian Wheezy and a USRP B200. After building the UHD drivers from source, I followed the "network from scratch" page. I also configured and built osmo-trx with the --with-neon-vfpv4 option. Things are running OK, a whole lot better than my attempt with OpenBTS actually. I"m able to connect to the network with my Samsung S4 phone, but after an hour or so of the BTS running, I get a UHD recieved time out error (see below). I wonder what could be causing this? I have the B200 plugged into the USB 3.0 port, along with external power. Thanks in advance for any help. root@odroid-wheezy:~# osmo-trx linux; GNU C++ version 4.6.3; Boost_104900; UHD_003.007.002-94-ge56809a0 Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 1 Samples-per-Symbol...... 1 External Reference...... Disabled C0 Filler Table......... Disabled Diversity............... Disabled Tuning offset........... 0 -- Loading firmware image: /usr/local/share/uhd/images/usrp_b200_fw.hex... done -- Loading FPGA image: /usr/local/share/uhd/images/usrp_b200_fpga.bin... done -- Operating over USB 3. -- Detecting internal GPSDO.... No GPSDO found -- not found -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 32.000000 MHz -- Actually got clock rate 32.000000 MHz -- Performing timer loopback test... pass -- Asking for clock rate 26.000000 MHz -- Actually got clock rate 26.000000 MHz -- Performing timer loopback test... pass -- Setting B200 1 SPS -- Transceiver active with 1 channel(s) ALERT 3030074464 23:06:10.4 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:10.5 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:10.6 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:10.7 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:10.8 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:10.9 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.0 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.1 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.2 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.3 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.4 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.5 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.6 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.7 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.9 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.0 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.1 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.2 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.3 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.4 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.5 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.6 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.7 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.8 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.9 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.0 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.1 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.2 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.3 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.4 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.5 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.6 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.7 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.8 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.9 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:14.0 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:14.1 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:14.2 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out terminate called after throwing an instance of 'uhd::assertion_error' what(): AssertionError: accum_timeout < _timeout in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool) at /root/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:232

2 1

TIP: Working with nanoBTS behind NAT
by admin＠manateeshome.com 15 Sep '14

15 Sep '14

I wrote a short post about using nanoBTS behind NAT and getting proper connection. http://manatails.net/blog/2014/09/setting-arbitary-destination-ip-for-rtp-p… As OpenBSC does not natively support NAT like Asterisk does, One needs to use a simple hack to manually tell the BSC about the connection information. Regards, Pierre

1 0