May 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

OsmoSGSN [PATCH], Network Service
by Michal Grznár 05 Aug '14

05 Aug '14

Hi, I am using OsmoSGSN in topology with OpenGGSN and proprietary simulator of BSS. There was a problem with an implementation of Network service, cause Network Service implementation in the simulator of BSS is based on different release of 3GPP standard (3GPP TS 48. 016 v7. 4. 0 (2008-04)/Network service (Release 7))...and the problem is that in IP-subnetwork, which I am using there is no use for RESET or UNBLOCK procedure, so I had to do a PATCH in gprs_ns.c, which was needed to complete succesful connection between sim-bss and OsmoSGSN: switch (nsh->pdu_type) { case NS_PDUT_ALIVE: +++ LOGP(DNS, LOGL_INFO, "Rx NS ALIVE\n"); +++ /*mark NS-VC as alive*/ +++ (*nsvc)->state = NSE_S_ALIVE; +++ (*nsvc)->remote_state = NSE_S_ALIVE; +++ /*initiate TEST procedure: Send ALIVE_ACK and start timer*/ +++ rc = gprs_ns_tx_simple((*nsvc), NS_PDUT_ALIVE_ACK); +++ nsvc_start_timer((*nsvc), NSVC_TIMER_TNS_TEST); +++ break; . . . } another PATCH I needed to do was to change a little bit procedure for allocation of P-TMSI in procedure uint32_t sgsn_alloc_ptmsi(void) in gprs_sgsn.c uint32_t sgsn_alloc_ptmsi(void) { struct sgsn_mm_ctx *mm; uint32_t ptmsi; restart: +++ ptmsi = rand() | 0xc0000000; /*because of GPRS IMSI ATTACH*/ llist_for_each_entry(mm, &sgsn_mm_ctxts, list) { if (mm->p_tmsi == ptmsi) goto restart; } return ptmsi; } because in GPRS IMSI ATTACH in message ATTACH COMPLETE (3GPP 24.008, 23.003, 48.018) there is new TLLI==new allocated P-TMSI and I need local TLLI, so I had to do it this way regards Michal

3 6

trau_decode_fr memory corruption. Fix requested
by Holger Hans Peter Freyther 23 Jun '14

23 Jun '14

Dear Andreas, Harald, I don't really know much about the bit order of TRAU frames but the trau_test.c is causing an out of bounds access to the gsm_fr_map. Re-produce (GCC >= 3.8 or clang >= 3.2 required): $ make clean && make CFLAGS+="-ggdb3 -Og -fsanitize=address" $ cd tests/trau $ ./trau_test Issue: Breakpoint 1, 0xb69e7810 in __asan_report_error () from /usr/lib/i386-linux-gnu/libasan.so.0 (gdb) bt #0 0xb69e7810 in __asan_report_error () from /usr/lib/i386-linux-gnu/libasan.so.0 #1 0xb69e08cf in __asan_report_load1 () from /usr/lib/i386-linux-gnu/libasan.so.0 #2 0x0804c4e7 in trau_encode_fr (tf=tf@entry=0xbffff530, data=data@entry=0xbffff700 <incomplete sequence \320>) at trau_mux.c:441 #3 0x08048e06 in test_trau_fr_efr (data=<optimized out>, data@entry=0xbffff700 <incomplete sequence \320>) at trau_test.c:35 #4 0x080494bf in main () at trau_test.c:70 (gdb) frame2 Undefined command: "frame2". Try "help". (gdb) frame 2 #2 0x0804c4e7 in trau_encode_fr (tf=tf@entry=0xbffff530, data=data@entry=0xbffff700 <incomplete sequence \320>) at trau_mux.c:441 441 k = gsm_fr_map[++l]-1; (gdb) p l $1 = 76 (gdb) p l $2 = 76 (gdb) p sizeof(gsm_fr_map) $3 = 76 Please fix as soon as possible as I would like to enable ASAN checking on the jenkins as soon as possible. kind regards holger

2 2

[PATCH 1/2] write_queue: Avoid possible use-after-free if fd is read-/writable
by Daniel Willmann 12 Jun '14

12 Jun '14

If the FD is both readable and writable and the read callback closes the connection (and frees the surrounding structure) we shouldn't call the write callback (or check anything else in the read fd). With this patch callback functions can return -EBADFD if they don't want the FD to be handled any more. --- src/write_queue.c | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/src/write_queue.c b/src/write_queue.c index cef40f8..d17493d 100644 --- a/src/write_queue.c +++ b/src/write_queue.c @@ -21,8 +21,15 @@ * */ +#include <errno.h> #include <osmocom/core/write_queue.h> +#define HANDLE_BAD_FD(rc, label) \ + do { \ + if (rc == -EBADFD) \ + goto label; \ + } while (0); + /*! \addtogroup write_queue * @{ */ @@ -39,14 +46,19 @@ int osmo_wqueue_bfd_cb(struct osmo_fd *fd, unsigned int what) { struct osmo_wqueue *queue; + int rc; queue = container_of(fd, struct osmo_wqueue, bfd); - if (what & BSC_FD_READ) - queue->read_cb(fd); + if (what & BSC_FD_READ) { + rc = queue->read_cb(fd); + HANDLE_BAD_FD(rc, err_badfd); + } - if (what & BSC_FD_EXCEPT) - queue->except_cb(fd); + if (what & BSC_FD_EXCEPT) { + rc = queue->except_cb(fd); + HANDLE_BAD_FD(rc, err_badfd); + } if (what & BSC_FD_WRITE) { struct msgb *msg; @@ -58,16 +70,21 @@ int osmo_wqueue_bfd_cb(struct osmo_fd *fd, unsigned int what) --queue->current_length; msg = msgb_dequeue(&queue->msg_queue); - queue->write_cb(fd, msg); + rc = queue->write_cb(fd, msg); msgb_free(msg); + HANDLE_BAD_FD(rc, err_badfd); + if (!llist_empty(&queue->msg_queue)) fd->when |= BSC_FD_WRITE; } } return 0; +err_badfd: + return rc; } +#undef HANDLE_BAD_FD /*! \brief Initialize a \ref osmo_wqueue structure * \param[in] queue Write queue to operate on -- 1.8.4.2

4 6

osmo-pcu: Upgrade DL tbf to use multislot if possible
by Daniel Willmann 30 May '14

30 May '14

Hello, if the network iniates a data transfer it will page the MS to open a TBF and since this paging happens over the CCCH it can only ask the MS to use one PDCH initially. With this patch (and if there are more PDCH ts available) the PCU will remember that it can upgrade to use multiple timeslots and send a downlink assignment with the new timeslot allocation over the TBF. Regards, Daniel -- - Daniel Willmann <dwillmann(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

1 3

[PATCH 1/3] lchan: Speculative "fix" for error and late reply
by Holger Hans Peter Freyther 26 May '14

26 May '14

From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com> Looking at the code it seemed possible that a channel would transition from BROKEN to NONE. Or worse from NONE to BROKEN. Start the timer _after_ the channel has been released. --- openbsc/src/libbsc/abis_rsl.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/openbsc/src/libbsc/abis_rsl.c b/openbsc/src/libbsc/abis_rsl.c index 5d40794..984fa7e 100644 --- a/openbsc/src/libbsc/abis_rsl.c +++ b/openbsc/src/libbsc/abis_rsl.c @@ -52,6 +52,7 @@ enum sacch_deact { }; static int rsl_send_imm_assignment(struct gsm_lchan *lchan); +static void error_timeout_cb(void *data); static void send_lchan_signal(int sig_no, struct gsm_lchan *lchan, struct gsm_meas_rep *resp) @@ -64,9 +65,15 @@ static void send_lchan_signal(int sig_no, struct gsm_lchan *lchan, static void do_lchan_free(struct gsm_lchan *lchan) { - /* we have an error timer pending to release that */ - if (lchan->state != LCHAN_S_REL_ERR) + /* We start the error timer to make the channel available again */ + if (lchan->state == LCHAN_S_REL_ERR) { + lchan->error_timer.data = lchan; + lchan->error_timer.cb = error_timeout_cb; + osmo_timer_schedule(&lchan->error_timer, + lchan->ts->trx->bts->network->T3111 + 2, 0); + } else { rsl_lchan_set_state(lchan, LCHAN_S_NONE); + } lchan_free(lchan); } @@ -679,8 +686,6 @@ static int rsl_rf_chan_release(struct gsm_lchan *lchan, int error, DEBUGP(DRSL, "%s RF Channel Release CMD due error %d\n", gsm_lchan_name(lchan), error); if (error) { - struct e1inp_sign_link *sign_link = msg->dst; - /* * FIXME: GSM 04.08 gives us two options for the abnormal * chanel release. This can be either like in the non-existent @@ -708,10 +713,6 @@ static int rsl_rf_chan_release(struct gsm_lchan *lchan, int error, * TODO: start T3109 now. */ rsl_lchan_set_state(lchan, LCHAN_S_REL_ERR); - lchan->error_timer.data = lchan; - lchan->error_timer.cb = error_timeout_cb; - osmo_timer_schedule(&lchan->error_timer, - sign_link->trx->bts->network->T3111 + 2, 0); } /* Start another timer or assume the BTS sends a ACK/NACK? */ -- 1.9.1

1 2

GPRS broken in master
by Pierre Kim 25 May '14

25 May '14

Hello, I updated my OpenBSC repo today and found that the GPRS is not working properly with the newest osmo-nitb. I tried several different versions of osmo-nitb and osmo-sgsn to localize the problem and concluded that osmo-nitb is causing the issue. The phone can attach to GPRS and PDP context request is accepted, but the phone still cannot send or receive data. <000f> sgsn_libgtp.c:126 Create PDP Context <000f> sgsn_libgtp.c:379 libgtp cb_conf(type=16, cause=128, pdp=0xb733cea0, cbp=0x8839230) <000f> sgsn_libgtp.c:265 Received CREATE PDP CTX CONF, cause=128(Request accepted) <0013> gprs_sndcp.c:297 SNSM-ACTIVATE.ind (lle=0x8838568 TLLI=d527d1cf, SAPI=3, NSAPI=5) <0011> gprs_bssgp.c:503 BSSGP BVCI=0 TLLI=d527d1cf Rx LLC DISCARDED <0011> gprs_bssgp.c:376 BSSGP TLLI=0xd527d1cf Rx UPLINK-UNITDATA <0012> gprs_llc.c:551 LLC SAPI=1 C FCS=0xd9c320CMD=UI DATA <0011> gprs_bssgp.c:503 BSSGP BVCI=0 TLLI=d527d1cf Rx LLC DISCARDED <0011> gprs_bssgp.c:376 BSSGP TLLI=0xd527d1cf Rx UPLINK-UNITDATA <0012> gprs_llc.c:551 LLC SAPI=1 C FCS=0x26346bCMD=UI DATA <0011> gprs_bssgp.c:503 BSSGP BVCI=0 TLLI=d527d1cf Rx LLC DISCARDED <0011> gprs_bssgp.c:376 BSSGP TLLI=0xd527d1cf Rx UPLINK-UNITDATA <0012> gprs_llc.c:551 LLC SAPI=1 C FCS=0x4a642eCMD=UI DATA Please let me know if you need more logs or packet dump. I will be reverting to older revisions to find out when exactly it got broken Regards, Pierre

2 1