April 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

Why isn't ARFCN 0 supported?
by Mike McTernan (wavemobile) 08 Jun '15

08 Jun '15

Good afternoon! In libbsc/bsc_init.c we have the following case: case GSM_BAND_900: if (bts->c0->arfcn < 1 || (bts->c0->arfcn > 124 && bts->c0->arfcn < 955) || bts->c0->arfcn > 1023) { LOGP(DNM, LOGL_ERROR, "GSM900 channel must be between 1-124, 955-1023.\n"); return -EINVAL; } break; 3GPP 45.005, table 2-2 gives valid channel numbers as: P-GSM900 -> 1-124, E-GSM900 -> 0-124 and 975-1023 R-GSM900 -> 0-124 and 955-1023 ER-GSM900 -> 0-124 and 940-1023 The code looks to bounds check ARFCN closest to R-GSM900, but omits ARFCN 0. Is the check "bts->c0->arfcn < 1" erroneous, or am I missing some history? Also should it really check for the R-GSM 900 range, or should it be E-GSM (more common)? The other band checks look correct. Kind Regards, Mike PS: osmo-arfcn is okay with ARFCN 0: $ ./osmo-arfcn -a 0 ARFCN 0: Uplink 890.0 MHz / Downlink 935.0 MHz

2 1

[PATCH] Use generic auth API
by Max 01 Jun '15

01 Jun '15

Signed-off-by: Max <max.suraev(a)fairwaves.co> --- openbsc/src/libmsc/auth.c | 69 +++++++++++++++++++---------------------------- 1 file changed, 28 insertions(+), 41 deletions(-) diff --git a/openbsc/src/libmsc/auth.c b/openbsc/src/libmsc/auth.c index 10d8edf..d04b2fc 100644 --- a/openbsc/src/libmsc/auth.c +++ b/openbsc/src/libmsc/auth.c @@ -24,47 +24,11 @@ #include <openbsc/debug.h> #include <openbsc/auth.h> #include <openbsc/gsm_data.h> - -#include <osmocom/gsm/comp128.h> +#include <osmocom/crypt/auth.h> #include <stdlib.h> -static int -_use_xor(struct gsm_auth_info *ainfo, struct gsm_auth_tuple *atuple) -{ - int i, l = ainfo->a3a8_ki_len; - - if ((l > A38_XOR_MAX_KEY_LEN) || (l < A38_XOR_MIN_KEY_LEN)) { - LOGP(DMM, LOGL_ERROR, "Invalid XOR key (len=%d) %s\n", - ainfo->a3a8_ki_len, - osmo_hexdump(ainfo->a3a8_ki, ainfo->a3a8_ki_len)); - return -1; - } - - for (i=0; i<4; i++) - atuple->sres[i] = atuple->rand[i] ^ ainfo->a3a8_ki[i]; - for (i=4; i<12; i++) - atuple->kc[i-4] = atuple->rand[i] ^ ainfo->a3a8_ki[i]; - - return 0; -} - -static int -_use_comp128_v1(struct gsm_auth_info *ainfo, struct gsm_auth_tuple *atuple) -{ - if (ainfo->a3a8_ki_len != A38_COMP128_KEY_LEN) { - LOGP(DMM, LOGL_ERROR, "Invalid COMP128v1 key (len=%d) %s\n", - ainfo->a3a8_ki_len, - osmo_hexdump(ainfo->a3a8_ki, ainfo->a3a8_ki_len)); - return -1; - } - - comp128(ainfo->a3a8_ki, atuple->rand, atuple->sres, atuple->kc); - - return 0; -} - /* Return values * -1 -> Internal error * 0 -> Not available @@ -76,6 +40,11 @@ int auth_get_tuple_for_subscr(struct gsm_auth_tuple *atuple, { struct gsm_auth_info ainfo; int i, rc; + static struct osmo_sub_auth_data auth = { + .type = OSMO_AUTH_TYPE_GSM + }; + struct osmo_auth_vector _vec; + struct osmo_auth_vector *vec = &_vec; /* Get subscriber info (if any) */ rc = db_get_authinfo_for_subscr(&ainfo, subscr); @@ -109,13 +78,23 @@ int auth_get_tuple_for_subscr(struct gsm_auth_tuple *atuple, return 0; case AUTH_ALGO_XOR: - if (_use_xor(&ainfo, atuple)) - return 0; + auth.algo = OSMO_AUTH_ALG_XOR; + if ((ainfo.a3a8_ki_len > A38_XOR_MAX_KEY_LEN) || (ainfo.a3a8_ki_len < A38_XOR_MIN_KEY_LEN)) { + LOGP(DMM, LOGL_ERROR, "Invalid XOR key (len=%d) %s\n", + ainfo.a3a8_ki_len, + osmo_hexdump(ainfo.a3a8_ki, ainfo.a3a8_ki_len)); + return -1; + } break; case AUTH_ALGO_COMP128v1: - if (_use_comp128_v1(&ainfo, atuple)) - return 0; + auth.algo = OSMO_AUTH_ALG_COMP128v1; + if (ainfo.a3a8_ki_len != A38_COMP128_KEY_LEN) { + LOGP(DMM, LOGL_ERROR, "Invalid COMP128v1 key (len=%d) %s\n", + ainfo.a3a8_ki_len, + osmo_hexdump(ainfo.a3a8_ki, ainfo.a3a8_ki_len)); + return -1; + } break; default: @@ -124,6 +103,14 @@ int auth_get_tuple_for_subscr(struct gsm_auth_tuple *atuple, return 0; } + memcpy(auth.u.gsm.ki, ainfo.a3a8_ki, sizeof(auth.u.gsm.ki)); + + if (osmo_auth_gen_vec(vec, &auth, atuple->rand) < 0) + return -1; + + memcpy(atuple->sres, vec->sres, 4); + memcpy(atuple->kc, vec->kc, 8); + db_sync_lastauthtuple_for_subscr(atuple, subscr); DEBUGP(DMM, "Need to do authentication and ciphering\n"); -- 1.9.1

3 3

[PATCH] bssgp: Fix call to llist_entry in fc_queue_timer_cfg
by Jacob Erlbeck 05 May '15

05 May '15

Currently the DL sometimes hangs and sometimes a lot of messages (still not able to send PDU) are logged. This is caused by an invalid timer delay computation, setting msecs either to 0 or to some big value. This is due to an '&' operator at the wrong place, accessing some parts in fc instead of the first element of the list. This commit fixes that issue. Sponsored-by: On-Waves ehf --- src/gb/gprs_bssgp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gb/gprs_bssgp.c b/src/gb/gprs_bssgp.c index 4c93b69..fe4fcca 100644 --- a/src/gb/gprs_bssgp.c +++ b/src/gb/gprs_bssgp.c @@ -628,7 +628,7 @@ static int fc_queue_timer_cfg(struct bssgp_flow_control *fc) if (llist_empty(&fc->queue)) return 0; - fcqe = llist_entry(&fc->queue.next, struct bssgp_fc_queue_element, + fcqe = llist_entry(fc->queue.next, struct bssgp_fc_queue_element, list); if (fc->bucket_leak_rate != 0) { -- 1.9.1

3 10

[PATCH] opensgsn: Replace some TODOs with error paths and fix compiler warning
by Mike McTernan (wavemobile) 01 May '15

01 May '15

openggsn: Check return codes and take error paths on failure. Return early when socket() returns -1, and check return codes where indicated by some TODOs. This removes 2 TODOs and fixes a compiler warning about assignment to a variable which then isn't used. Signed-off-by: Michael McTernan <mike.mcternan(a)wavemobile.com> Index: osmobss/openggsn/lib/tun.c =================================================================== --- osmobss.orig/openggsn/lib/tun.c 2015-04-28 10:51:37.960449539 +0100 +++ osmobss/openggsn/lib/tun.c 2015-04-28 10:54:40.301130739 +0100 @@ -117,6 +117,7 @@ int tun_sifflags(struct tun_t *this, int ifr.ifr_name[IFNAMSIZ - 1] = 0; /* Make sure to terminate */ if ((fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { SYS_ERR(DTUN, LOGL_ERROR, errno, "socket() failed"); + return -1; } if (ioctl(fd, SIOCSIFFLAGS, &ifr)) { SYS_ERR(DTUN, LOGL_ERROR, errno, @@ -318,9 +319,19 @@ int tun_addaddr(struct tun_t *this, req.n.nlmsg_seq = 0; req.n.nlmsg_flags |= NLM_F_ACK; - status = sendmsg(fd, &msg, 0); /* TODO Error check */ + status = sendmsg(fd, &msg, 0); + if (status == -1) { + SYS_ERR(DTUN, LOGL_ERROR, errno, "sendmsg() failed"); + close(fd); + return -1; + } + + status = tun_sifflags(this, IFF_UP | IFF_RUNNING); + if (status == -1) { + close(fd); + return -1; + } - tun_sifflags(this, IFF_UP | IFF_RUNNING); /* TODO */ close(fd); this->addrs++; return 0;

2 4

[PATCH 1/2] bssgp: Fix output of the VTY 'show bssgp stats' command
by Jacob Erlbeck 29 Apr '15

29 Apr '15

The output is terminated by a '\n' instead of VTY_NEWLINE. This is fixed by the commit. Sponsored-by: On-Waves ehf --- src/gb/gprs_bssgp_vty.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/gb/gprs_bssgp_vty.c b/src/gb/gprs_bssgp_vty.c index 88ae49f..080867b 100644 --- a/src/gb/gprs_bssgp_vty.c +++ b/src/gb/gprs_bssgp_vty.c @@ -97,9 +97,10 @@ static void dump_bvc(struct vty *vty, struct bssgp_bvc_ctx *bvc, int stats) if (fc) vty_out(vty, "FC-BVC(bucket_max: %uoct, leak_rate: " "%uoct/s, cur_tokens: %uoct, max_q_d: %u, " - "cur_q_d: %u)\n", fc->bucket_size_max, + "cur_q_d: %u)%s", fc->bucket_size_max, fc->bucket_leak_rate, fc->bucket_counter, - fc->max_queue_depth, fc->queue_depth); + fc->max_queue_depth, fc->queue_depth, + VTY_NEWLINE); } } -- 1.9.1

1 1

[PATCH] mgcp/test: Fix mgcp-transcoding assertion (Coverity)
by Jacob Erlbeck 27 Apr '15

27 Apr '15

In test_rtp_seq_state an assignment is accidently done within an assertion. This commit changes that into a comparison as it was intended. Fixes: Coverity CID 1295457, 1295458 Sponsored-by: On-Waves ehf --- openbsc/tests/mgcp/mgcp_transcoding_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openbsc/tests/mgcp/mgcp_transcoding_test.c b/openbsc/tests/mgcp/mgcp_transcoding_test.c index 1b8001e..c5c0a0b 100644 --- a/openbsc/tests/mgcp/mgcp_transcoding_test.c +++ b/openbsc/tests/mgcp/mgcp_transcoding_test.c @@ -295,7 +295,7 @@ static void test_rtp_seq_state(void) OSMO_ASSERT(cont >= 0); OSMO_ASSERT(state->is_running); OSMO_ASSERT(state->next_seq == 2); - OSMO_ASSERT(state->next_time = 240); + OSMO_ASSERT(state->next_time == 240); /* verify that the right timestamp was written */ OSMO_ASSERT(len == audio_packets_pcma[0].len); -- 1.9.1

1 0

test
by Holger Freyther 26 Apr '15

26 Apr '15

1 0

test
by Holger Freyther 26 Apr '15

26 Apr '15

1 0

[PATCH 1/9] gsup: Document passing MSISDN as part of the response
by Holger Freyther 23 Apr '15

23 Apr '15

From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com> --- openbsc/doc/sgsn-remote-protocol.txt | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/openbsc/doc/sgsn-remote-protocol.txt b/openbsc/doc/sgsn-remote-protocol.txt index 3369d19..88a384e 100644 --- a/openbsc/doc/sgsn-remote-protocol.txt +++ b/openbsc/doc/sgsn-remote-protocol.txt @@ -121,6 +121,7 @@ Network peer -> SGSN 01 IMSI 4.2.9 M TLV 2-10 04 PDP info complete 4.2.8 O TLV 2 05 PDP info 4.2.3 1-10 TLV + 13 MSISDN 4.2.10 O TLV 0-9 If the PDP info complete IE is present, the old PDP info list shall be cleared. @@ -357,6 +358,7 @@ IEI that shall be used for the encoding. | 0x10 PDP context id big endian int | | 0x11 PDP type 4.2.4 | | 0x12 APN 04.08, 10.5.6.1 | + | 0x13 MSISDN ISDN-AddressString/octet | | 0x20 RAND octet string | | 0x21 SRES octet string | | 0x22 Kc octet string | @@ -397,3 +399,24 @@ The IMSI is encoded like in octet 4-N of the Called Party BCD Number defined in Note 1) Either '1 1 1 1 | Number digit N' (N odd) or 'Number digit N | Number digit N-1' (N even), where N is the number of digits. + +4.2.10. ISDN-AddressString / MSISDN /Called Party BCD Number + + +MSISDN. ISDN-AddressString in GSM 09.02 and Called Party +BCD Number in GSM 04.08. + + 8 7 6 5 4 3 2 1 + +-----------------------------------------------------+ + | | IEI | octet 1 + +-----------------------------------------------------+ + | Length of IE contents | octet 2 + +-----------------------------------------------------+ + | ext | Type of num | Numbering plan | octet 2 + +-----------------------------------------------------+ + | Number digit 2 | Number digit 1 | octet 3 + +-----------------------------------------------------+ + | Number digit 4 | Number digit 3 | octet 4 + +-----------------------------------------------------+ + : : : + +-----------------------------------------------------+ -- 2.3.5

1 8

OsmoBTS - OsmocomBB emulation project
by Dominiq T 11 Apr '15

11 Apr '15

Dear Osmcom, I am working on a project, where I am connecting OsmoBTS with OsmocomBB without hardware. I am trying to remove l1 on both sides and connect OsmoBTS with BB application via simple unix sockets. Based on the further recommendations, I am using osmobts-trx branch. Currently I am able to handle messages between BTS and TRX driver on clock and control ports, and on BB side I am in state that phone wants to connect into a cell (so its waiting for BCCH) . I am now trying to find a possible way how to handle messages on data port , between BTS – TRX ( TRX is removed, there is my application instead), and forward these messages to my customized BB l1 interface . The thing is that I need to send to BB phone (layer23) messages in structures from gsm_04_08.h (i.e. gsm48_system_information_type_3). I am not sure if I will be able to get needed from the messages coming on the data port 5702. I found, that PCU creates unix socket on “/tmp/pcu_bts” , but only in case sysmoBTS is in use (please correct me if I am wrong), so this will be not possible due compilation errors without HW. Here I found the gsm48_system_information_type_3 messages. So basically I need somehow to get this message structures on my custom l1 BB interface. Do you have any idea how to do this ? Any advice will be highly appreciated. Many thanks you for your attention :) Best regards, Dominik Tamaskovic.

2 2

libosmo-abis/RSL queue and OS interaction
by Holger Hans Peter Freyther 11 Apr '15

11 Apr '15

Dear Pablo, Ciaby, from what I see we have the following OpenBSC/OS integration. * OpenBSC wants to send some RSL data and calls abis_rsl_sendmsg ** abis_rsl_sendmsg entails the msgb into a queue and informs the lower layer driver (ipa in our case) ** ipa sets the when to ~= BSC_FD_WRITE * code returns * OpenBSC runs select for all fds/timers.. * libosmocore dispatches fd's ** libosmo-abis/ipaccess.c will try to write a single message ** libosmo-abis/ipaccess.c will set the BSC_FD_WRITE again if the queue is not empty * Linux/TCP will run nagle to combine these messages * OpenBSC runs select for all fds/timers... .... The integration does work but appears to be a bit painful for busy and high latency links. E.g. OpenBSC starts timers when abis_rsl_sendmsg is invoked which might just be a little bit later. I wonder if there is a better way? For reading we could read until -EWOULDBLOCK but then this might not be too fair for the other parts of the software. For writing we might end up in the situation where a write only partially succeeds and we need to remember how much of the msgb to write next... So we would need to do ioctl's to check how much space is left in the send buffer Do you have ideas? comments? is it a non issue? is it something we can do better? Is there a TCP mode where a "write" either fully succeeds or fails with -ENOSPC or such? holger

3 2

[PATCH 1/4] mncc: Select the codec similar to the modify handling
by Holger Freyther 10 Apr '15

10 Apr '15

From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com> In case the default TCH/F codec is "EFR" and we do an early assignment from SDCCH to a TCH we would assign the TCH/H codec. This is because the lchan_type will be neither a TCH/H nor a TCH/F. At the same time the _gsm48_lchan_modify code to check for half vs. full-rate is the other way around. Align both. It is full-rate if it is not a TCH_H. This will have some other complications down the way (early assignment on cells with only TCH/H). So the mode should not depend on the _current_ channel but the kind of channel we want. --- openbsc/src/libmsc/mncc_builtin.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openbsc/src/libmsc/mncc_builtin.c b/openbsc/src/libmsc/mncc_builtin.c index a5a463b..5c3461b 100644 --- a/openbsc/src/libmsc/mncc_builtin.c +++ b/openbsc/src/libmsc/mncc_builtin.c @@ -69,7 +69,7 @@ static uint8_t determine_lchan_mode(struct gsm_mncc *setup) { /* FIXME: check codec capabilities of the phone */ - if (setup->lchan_type == GSM_LCHAN_TCH_F) + if (setup->lchan_type != GSM_LCHAN_TCH_H) return mncc_int.def_codec[0]; else return mncc_int.def_codec[1]; -- 2.1.4

1 3

[PATCH 1/4] nat: Fix timeslot range in 'show bsc mgcp' VTY command
by Jacob Erlbeck 09 Apr '15

09 Apr '15

Currently the inner loop in show_bsc_mgcp iterates of the timeslot interval [0, 31]. Timeslot 0 is not valid, which causes mgcp_timeslot_to_endpoint to generate a corresponding warning and to return an invalid endp value. That value causes an out-of-bound read access, possibly hitting unallocated memory. This patch fixes the loop range by starting with timeslot 1. Note that this does not prevent mgcp_timeslot_to_endpoint from returning an invalid endpoint index when called with arguments not within its domain. Addresses: <000b> ../../include/openbsc/mgcp.h:250 Timeslot should not be 0 [...] vty=0xb4203db0, argc=1, argv=0xbfffebb0) at bsc_nat_vty.c:256 max = 1 con = 0xb4a004f0 i = 0 j = 0 [...] ==15700== ERROR: AddressSanitizer: heap-use-after-free on address 0xb520be4f at pc 0x8062a42 bp 0xbfffeb18 sp 0xbfffeb0c Sponsored-by: On-Waves ehf --- openbsc/src/osmo-bsc_nat/bsc_nat_vty.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c b/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c index 5f4ad28..2b7db2e 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c +++ b/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c @@ -250,7 +250,7 @@ DEFUN(show_bsc_mgcp, show_bsc_mgcp_cmd, "show bsc mgcp NR", vty_out(vty, "MGCP Status for %d%s", con->cfg->nr, VTY_NEWLINE); max = bsc_mgcp_nr_multiplexes(con->max_endpoints); for (i = 0; i < max; ++i) { - for (j = 0; j < 32; ++j) { + for (j = 1; j < 32; ++j) { endp = mgcp_timeslot_to_endpoint(i, j); vty_out(vty, " Endpoint 0x%x %s%s", endp, con->_endpoint_status[endp] == 0 -- 1.9.1

2 5

[PATCH 1/2] msgb: Check the return value of msgb_alloc (Coverity)
by Jacob Erlbeck 09 Apr '15

09 Apr '15

In some places, the return value of msgb_alloc/msgb_alloc_headroom is not checked before it is dereferenced. This commit adds NULL checks to return with -ENOMEM from the calling functions if the alloc function has failed. Fixes: Coverity CID 1249692, 1293376 Sponsored-by: On-Waves ehf --- src/gsm/lapdm.c | 3 +++ src/sim/reader.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/src/gsm/lapdm.c b/src/gsm/lapdm.c index 698f850..54d3a0b 100644 --- a/src/gsm/lapdm.c +++ b/src/gsm/lapdm.c @@ -675,6 +675,9 @@ static int l2_ph_rach_ind(struct lapdm_entity *le, uint8_t ra, uint32_t fn, uint struct gsm_time gt; struct msgb *msg = msgb_alloc_headroom(512, 64, "RSL CHAN RQD"); + if (!msg) + return -ENOMEM; + msg->l2h = msgb_push(msg, sizeof(*ch)); ch = (struct abis_rsl_cchan_hdr *)msg->l2h; rsl_init_cchan_hdr(ch, RSL_MT_CHAN_RQD); diff --git a/src/sim/reader.c b/src/sim/reader.c index 160f175..e7169b5 100644 --- a/src/sim/reader.c +++ b/src/sim/reader.c @@ -58,6 +58,9 @@ static int transceive_apdu_t0(struct osim_card_hdl *st, struct msgb *amsg) uint16_t sw; int rc, num_resp = 0; + if (!tmsg) + return -ENOMEM; + /* create TPDU header from APDU header */ tpduh = (struct osim_apdu_cmd_hdr *) msgb_put(tmsg, sizeof(*tpduh)); memcpy(tpduh, msgb_apdu_h(amsg), sizeof(*tpduh)); -- 1.9.1

1 1

[PATCH 1/3] bssgp: Always expect dup != NULL in bssgp_tx_dl_ud (Coverity)
by Jacob Erlbeck 07 Apr '15

07 Apr '15

Currently the implementation of bssgp_tx_dl_ud conditionally adds some optional IE if dup != NULL. Later on is dereferences dup to access qos_profile and fc, but this without checking dup in advance. This may lead to an segmentation violation fault. This commit changes the value range of the function to only accept dup != NULL. An assertion will fail otherwise. All other explicit checks for non-NULL are removed. Fixes: Coverity CID 1040673 Sponsored-by: On-Waves ehf --- src/gb/gprs_bssgp.c | 49 ++++++++++++++++++++++++------------------------- 1 file changed, 24 insertions(+), 25 deletions(-) diff --git a/src/gb/gprs_bssgp.c b/src/gb/gprs_bssgp.c index 2f23290..a3fd6aa 100644 --- a/src/gb/gprs_bssgp.c +++ b/src/gb/gprs_bssgp.c @@ -1092,6 +1092,8 @@ int bssgp_tx_dl_ud(struct msgb *msg, uint16_t pdu_lifetime, uint16_t _pdu_lifetime = htons(pdu_lifetime); /* centi-seconds */ uint16_t drx_params; + OSMO_ASSERT(dup != NULL); + /* Identifiers from UP: TLLI, BVCI, NSEI (all in msgb->cb) */ if (bvci <= BVCI_PTM ) { LOGP(DBSSGP, LOGL_ERROR, "Cannot send DL-UD to BVCI %u\n", @@ -1124,35 +1126,32 @@ int bssgp_tx_dl_ud(struct msgb *msg, uint16_t pdu_lifetime, /* FIXME: optional elements: Alignment, UTRAN CCO, LSA, PFI */ - if (dup) { - /* Old TLLI to help BSS map from old->new */ - if (dup->tlli) { - uint32_t tlli = htonl(*dup->tlli); - msgb_tvlv_push(msg, BSSGP_IE_TLLI, 4, (uint8_t *) &tlli); - } - - /* IMSI */ - if (dup->imsi && strlen(dup->imsi)) { - uint8_t mi[10]; - int imsi_len = gsm48_generate_mid_from_imsi(mi, dup->imsi); - if (imsi_len > 2) - msgb_tvlv_push(msg, BSSGP_IE_IMSI, - imsi_len-2, mi+2); - } + /* Old TLLI to help BSS map from old->new */ + if (dup->tlli) { + uint32_t tlli = htonl(*dup->tlli); + msgb_tvlv_push(msg, BSSGP_IE_TLLI, 4, (uint8_t *) &tlli); + } - /* DRX parameters */ - drx_params = htons(dup->drx_parms); - msgb_tvlv_push(msg, BSSGP_IE_DRX_PARAMS, 2, - (uint8_t *) &drx_params); + /* IMSI */ + if (dup->imsi && strlen(dup->imsi)) { + uint8_t mi[10]; + int imsi_len = gsm48_generate_mid_from_imsi(mi, dup->imsi); + if (imsi_len > 2) + msgb_tvlv_push(msg, BSSGP_IE_IMSI, + imsi_len-2, mi+2); + } - /* FIXME: Priority */ + /* DRX parameters */ + drx_params = htons(dup->drx_parms); + msgb_tvlv_push(msg, BSSGP_IE_DRX_PARAMS, 2, + (uint8_t *) &drx_params); - /* MS Radio Access Capability */ - if (dup->ms_ra_cap.len) - msgb_tvlv_push(msg, BSSGP_IE_MS_RADIO_ACCESS_CAP, - dup->ms_ra_cap.len, dup->ms_ra_cap.v); + /* FIXME: Priority */ - } + /* MS Radio Access Capability */ + if (dup->ms_ra_cap.len) + msgb_tvlv_push(msg, BSSGP_IE_MS_RADIO_ACCESS_CAP, + dup->ms_ra_cap.len, dup->ms_ra_cap.v); /* prepend the pdu lifetime */ msgb_tvlv_push(msg, BSSGP_IE_PDU_LIFETIME, 2, (uint8_t *)&_pdu_lifetime); -- 1.9.1

1 2

recurring issue with OpenBSC
by Ciaby 06 Apr '15

06 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi! First a small update: we finally decided to _not_ use token mode, as it confuses a lot of phones, after receiving the token message the SIM goes into an error state and the only way to recover is to reboot the phone. Now we just read the IMSI straight from the SIM (using the card python library, just like osmo-sim-auth does) and register them. Now, the issue we see is that 1-2 users every day reach a point where they can make phone calls and send messages, but they can't receive neither of them. Sometimes the problem can be fixed by running: > subscriber extension <EXT> clear-requests but this only work when there are pending requests. In other cases, the phone has to be rebooted. Did anyone encounter the same issue? Cheers Ciaby -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUef1WAAoJEPU83OtbD4fQ69kQAI7peg30lHwbDPMXnTX80gUu 0dGsiK2iB5oWZ6Ohbs3W+/+xVoMseuG1di6Rk0XT9buN2IOR5fMfAs3INQ2EuAlV qz1RRn5Ux8uV0RJWyAJoSt7eFh3gbnDgsJ+x8SXEHQRw4rYHG2P+HXyEtncW6A6y L8/oPeIxH/LlP/55MP3KUY5BnQmN658LnJU9AFSwPkpjn2f/dj4o6mUdWo8haTTQ UWPWEdhQoeXPBqHsn2cKamT13SmiepMYAGuDEJci9LCS+J8vd70ukAP/oa1L6u1w +3+RbcNvC9fwAKDLU01b/cu630v6/mhk0lxWNlIz/kNL1aHPZe8QhP5sM4SuLtzj UaeHLxp4u2Pb7N31b3qtRA4jgl+5YFla5376F3d00jPSfZpmFggFgdRB2qWhF1m8 WucfzLc41dV1AVTdL90ISSRt1LZ/fLHBea8kgUxK+KrhBO7U7AV3PXk9of4EAf7y VKMX3KZWwtEKhpi0v3PihgW8bS/RaG3zEmsr30QXzXVaZknCfjGi8OOOB0JaHY48 o3g40YpzeyEq1gOyKKfBmtf1qk4GgLyPKfMUoTvXE2oNHmrg3ZlJldABKNzR9qz3 5hsHJ6/QGsBST1E3dphI0Zb6ubLnFwqBl02GyeJELLbtPCLPQMDicx03cqT4BjO3 vzDcPdIWg1sfSomYKMK9 =Zw4T -----END PGP SIGNATURE-----

2 7

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC April 2015