August 2015 - 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

[PATCH] Add SMPP support in the debian build, include libsmpp34-dev as a dependency.
by Ciaby 14 Sep '15

14 Sep '15

This is the last out-of-tree patch that we're still using to package OpenBSC in Rhizomatica. Adding SMPP support in the Debian packages shouldn't be an issue, right? Cheers Ciaby

2 2

[PATCH] msc: Add channel information to the meas_feed, bump version to v1
by Alexander Chemeris 14 Sep '15

14 Sep '15

Hi all, Attached is a patch for the openbsc which extends meas_feed with channel information - type and id (bts/trx/ts/ss). This is used by the web incarnation of meas_vis utility we wrote [1]. Originally it was a pure copy of the original meas_vis, but when we deployed it at Rhizomatica, they suggested it would be more useful if the channel information is displayed. It would be great to see this patch merged to master. When/if this is merged, I'll submit a patch with meas_json utility which listens on the meas_feed socket and converts it to JSON format digestible by web tools. This JSON is what meas_web uses as a data feed. [1] https://github.com/fairwaves/meas_web PS Apologies for attaching the patch instead of inlining it. GMail would ruin it. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co

3 4

[PATCH] openbsc: unhardwire MGCP endpoint id
by Mike McTernan (wavemobile) 01 Sep '15

01 Sep '15

Hi Folks, At present endpoint IDs are assumed to end with @mgw when trying to find/match non-e1 endpoint ids. Unless the MGCP peer supports compatible configuration, DNS or a hosts file may need to be setup to meet the hardwired host name requirement in the openBsc MGCP, and then we can still only run one BSC. The attached patch makes a simple change to use either the configured local_ip or source_addr, matching logic used in SDP responses. It also improves the error message when an endpoint can't be found. Please consider for inclusion to mainline. Kind Regards, Mike

2 4

dvnixload error: Entry point not found
by Diego Fernandez Alonso 24 Aug '15

24 Aug '15

Hello. I have a problem with my sysmoBTS. When I start the bts I receive a BOOTME message. So after identify in the SysmoBTS Manual the problem like broken UBL, I tried to follow the manual using the dvnixload utility. I installed the binutils-multiarch package and others neccesary for the execution of the divnixload, but during the proccess I get an error: root@ubun-osmo:/home/osmo-user/Documentos# ./dvnixload -p /dev/ttyUSB0 ubl-sysmobts-v2.elf u-boot-sysmobts-v2.elf dvnixload info: Using cross compiler "" dvnixload info: Expecting messages: [BOOTME] [BOOTPSP] [I_ME] dvnixload info: [BOOTME] received dvnixload error: Entry point not found dvnixload error: Entry point not found Do someone know why I get an "Entry point not found" message and how I can fix it? Thank you so much!!

2 5

8-PSK modulation/demodulation
by Piotr Krysik 20 Aug '15

20 Aug '15

Hi all, I'm developing gr-gsm - the ancestor of Airprobe's gsm-receiver. I want to add support for 8-PSK reception. I'm going to implement a demodulator (preferably doing also channel equalization) and also modulator (currently mostly to generate test data). I don't want to duplicate work that was already done so I want to ask if you are aware of any publicly available 8-PSK implementations (or partial implementations) aimed at supporting EDGE reception? Also I will greatly appreciate pointing to any documents containing good information on this topic. -- Best Regards, Piotr Krysik

2 1

subdir-objects / autoconf
by Harald Welte 19 Aug '15

19 Aug '15

Hi Holger, I added libosmocore commit 7c942ba1475a366cc7c8a129fbdd335166ce21c6 during the camp as at the simtrace/osmocombb/openbsc workshop, several participants could not build the respective software packages. This behavior was observed by Kevin and me, and adding subdir-objects resolved the problem. Due to the hectic nature of a workshop where everyone is waiting for the build to succeed on the system of all participants we did not have time to record the specific distribution versions at that time. On Debian unstable with autoconf 2.50 / automake 1.15, the build generates the following warnings: =============== src/gsm/Makefile.am:15: warning: source file 'milenage/aes-encblock.c' is in a subdirectory, src/gsm/Makefile.am:15: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. =============== The project still builds afterwards on this Debian system, so indeed it is just a warning. However, the warning quite clearly indicates that the use of subdir-objects is not optional in the future! So I'm not sure your revert of the assciated commit is the right way to proceed. The point seems to be that 'make distclean' wants to remove the generated objects for the tests, but the latter only are compiled when 'make check' is used, but not in the default build. Any ideas? -- - 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 4