OpenBSC February 2016

openbsc@lists.osmocom.org

20 participants
84 discussions

by mosbah abdelkader

> 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 weeks

Moving from trac to a single redmine

by Holger Freyther

Hi guys, I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now. Tickets: Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either: * not import tickets * only import from one project * deal with changing ticket numbers In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number? Wiki: We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this? kind regards holger

8 years, 8 months

Half sided calls

by Sipos Csaba

Dear List, I am in the process of creating the Wiki page for Ettus B200/B210 with OpenBSC, GPRS and Asterisk. I am quite close, both data and calls are working, but the voice calls are half sided. The downlink direction works, but the uplink does not. I tried without Asterisk and LCR (between two phones) and still the calls are half sided. In the mean time I got these messages in the Osmo-BTS log: <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284768 ts=2 tr x=0 <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284764 to transmit. <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284764 to transmit. <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=1284772 ts=1 trx= 0 <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=1284772 ts=1 tr x=0 <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x0a fn=1284772 ts=2 trx= 0 <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284772 ts=2 tr x=0 <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284768 to transmit. <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284768 to transmit. SMS and GPRS seems to be fine. If someone have any idea, I would love to hear it. :-) Thanks! Csaba

9 years, 1 month

[PATCH 0/4] core/conv: Fast Viterbi decoding

by Thomas Tsou

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

9 years, 1 month

[PATCH 1/2] utils: 'meas_json' utility to convert measurement feed into a JSON feed.

by Alexander Chemeris

--- openbsc/src/utils/Makefile.am | 6 +- openbsc/src/utils/meas_json.c | 169 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 174 insertions(+), 1 deletion(-) create mode 100644 openbsc/src/utils/meas_json.c diff --git a/openbsc/src/utils/Makefile.am b/openbsc/src/utils/Makefile.am index f6255a0..89f2dfb 100644 --- a/openbsc/src/utils/Makefile.am +++ b/openbsc/src/utils/Makefile.am @@ -4,7 +4,7 @@ AM_LDFLAGS = $(COVERAGE_LDFLAGS) noinst_HEADERS = meas_db.h -bin_PROGRAMS = bs11_config isdnsync +bin_PROGRAMS = bs11_config isdnsync meas_json if HAVE_SQLITE3 bin_PROGRAMS += osmo-meas-pcap2db osmo-meas-udp2db endif @@ -32,6 +32,10 @@ meas_vis_SOURCES = meas_vis.c meas_vis_LDADD = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) -lcdk -lncurses meas_vis_CFLAGS = $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) +meas_json_SOURCES = meas_json.c +meas_json_LDADD = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) +meas_json_CFLAGS = $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) + osmo_meas_pcap2db_SOURCES = meas_pcap2db.c meas_db.c osmo_meas_pcap2db_LDADD = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) -lpcap $(SQLITE3_LIBS) osmo_meas_pcap2db_CFLAGS = $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) diff --git a/openbsc/src/utils/meas_json.c b/openbsc/src/utils/meas_json.c new file mode 100644 index 0000000..940e5e7 --- /dev/null +++ b/openbsc/src/utils/meas_json.c @@ -0,0 +1,169 @@ +/* Convert measurement report feed into JSON feed printed to stdout. + * Each measurement report is printed as a separae JSON root entry. + * All measurement reports are separated by a new line. + */ + +/* (C) 2015 by Alexander Chemeris <Alexander.Chemeris(a)fairwaves.co> + * With parts of code adopted from different places in OpenBSC. + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Affero General Public License as published by + * the Free Software Foundation; either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Affero General Public License for more details. + * + * You should have received a copy of the GNU Affero General Public License + * along with this program. If not, see <http://www.gnu.org/licenses/>. + * + */ +#include <string.h> +#include <errno.h> +#include <unistd.h> +#include <stdlib.h> +#include <stdio.h> + +#include <netinet/in.h> + +#include <osmocom/core/socket.h> +#include <osmocom/core/msgb.h> +#include <osmocom/core/select.h> + +#include <osmocom/gsm/gsm_utils.h> + +#include <openbsc/meas_feed.h> + +static void print_meas_rep_uni_json(struct gsm_meas_rep_unidir *mru) +{ + printf("\"RXL-FULL\":%d, \"RXL-SUB\":%d, ", + rxlev2dbm(mru->full.rx_lev), + rxlev2dbm(mru->sub.rx_lev)); + printf("\"RXQ-FULL\":%d, \"RXQ-SUB\":%d", + mru->full.rx_qual, mru->sub.rx_qual); +} + +static void print_meas_rep_json(struct gsm_meas_rep *mr) +{ + int i; + + printf("\"NR\":%d", mr->nr); + + if (mr->flags & MEAS_REP_F_DL_DTX) + printf(", \"DTXd\":true"); + + printf(", \"UL_MEAS\":{"); + print_meas_rep_uni_json(&mr->ul); + printf("}"); + printf(", \"BS_POWER\":%d", mr->bs_power); + if (mr->flags & MEAS_REP_F_MS_TO) + printf(", \"MS_TO\":%d", mr->ms_timing_offset); + + if (mr->flags & MEAS_REP_F_MS_L1) { + printf(", \"L1_MS_PWR\":%d", mr->ms_l1.pwr); + printf(", \"L1_FPC\":%s", + mr->flags & MEAS_REP_F_FPC ? "true" : "false"); + printf(", \"L1_TA\":%u", mr->ms_l1.ta); + } + + if (mr->flags & MEAS_REP_F_UL_DTX) + printf(", \"DTXu\":true"); + if (mr->flags & MEAS_REP_F_BA1) + printf(", \"BA1\":true"); + if (mr->flags & MEAS_REP_F_DL_VALID) { + printf(", \"DL_MEAS\":{"); + print_meas_rep_uni_json(&mr->dl); + printf("}"); + } + + if (mr->num_cell == 7) + return; + printf(", \"NUM_NEIGH\":%u, \"NEIGH\":[", mr->num_cell); + for (i = 0; i < mr->num_cell; i++) { + struct gsm_meas_rep_cell *mrc = &mr->cell[i]; + if (i!=0) printf(", "); + printf("\"IDX\":%u, \"ARFCN\":%u, \"BSIC\":%u, \"POWER\":%d", + mrc->neigh_idx, mrc->arfcn, mrc->bsic, rxlev2dbm(mrc->rxlev)); + } + printf("]"); +} + +static void print_meas_feed_json(struct meas_feed_meas *mfm) +{ + time_t now = time(NULL); + + printf("{"); + printf("\"time\":%ld, \"imsi\":\"%s\", \"name\":\"%s\", \"scenario\":\"%s\", ", + now, mfm->imsi, mfm->name, mfm->scenario); + + printf("\"meas_rep\":{"); + print_meas_rep_json(&mfm->mr); + printf("}"); + + printf("}\n"); + +} + +static int handle_meas(struct msgb *msg) +{ + struct meas_feed_meas *mfm = (struct meas_feed_meas *) msgb_data(msg); + + print_meas_feed_json(mfm); + + return 0; +} + +static int handle_msg(struct msgb *msg) +{ + struct meas_feed_hdr *mfh = (struct meas_feed_hdr *) msgb_data(msg); + + if (mfh->version != MEAS_FEED_VERSION) + return -EINVAL; + + switch (mfh->msg_type) { + case MEAS_FEED_MEAS: + handle_meas(msg); + break; + default: + break; + } +} + +static int udp_fd_cb(struct osmo_fd *ofd, unsigned int what) +{ + int rc; + + if (what & BSC_FD_READ) { + struct msgb *msg = msgb_alloc(1024, "UDP Rx"); + + rc = read(ofd->fd, msgb_data(msg), msgb_tailroom(msg)); + if (rc < 0) + return rc; + msgb_put(msg, rc); + handle_msg(msg); + msgb_free(msg); + } + + return 0; +} + +int main(int argc, char **argv) +{ + int rc; + struct osmo_fd udp_ofd; + + udp_ofd.cb = udp_fd_cb; + rc = osmo_sock_init_ofd(&udp_ofd, AF_INET, SOCK_DGRAM, IPPROTO_UDP, NULL, 8888, OSMO_SOCK_F_BIND); + if (rc < 0) + exit(1); + + while (1) { + osmo_select_main(0); + }; + + exit(0); +} -- 1.9.1

9 years, 2 months

Redmine theme

by Вадим Яницкий

Dear all, I suggest to change a stock Redmine theme to something more beautiful, for example gitmike: https://github.com/makotokw/redmine-theme-gitmike which used by srlabs.de and looks like pretty. Furthermore, the Osmocom logo will look better on light background. Opinions? С наилучшими пожеланиями, Яницкий Вадим.

9 years, 3 months

command for location update

by robert

Hi, Is it possible to have the virtual BTS start a location update at a specific time. In other words, can I add a command that asks all phones to request a location update at any desired time ? Best regards, Robert,

9 years, 3 months

Fwd: New Defects reported by Coverity Scan for Osmocom

by Holger Freyther

Hi guys, FYI after adding the do{} while and the log_check_level call coverity has found some dead code. The found_partial is a funny case of dead code. :) holger > Begin forwarded message: > > From: scan-admin(a)coverity.com > Subject: New Defects reported by Coverity Scan for Osmocom > Date: 29 February 2016 at 17:47:54 GMT+1 > To: holger(a)freyther.de > > > Hi, > > Please find the latest report on new defect(s) introduced to Osmocom found with Coverity Scan. > > 3 new defect(s) introduced to Osmocom found with Coverity Scan. > 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. > > New defect(s) Reported-by: Coverity Scan > Showing 3 of 3 defect(s) > > > ** CID 70677: Control flow issues (DEADCODE) > /source-iuh/osmo-pcu/src/gprs_rlcmac_ts_alloc.cpp: 907 in alloc_algorithm_b() > > > ________________________________________________________________________________________________________ > *** CID 70677: Control flow issues (DEADCODE) > /source-iuh/osmo-pcu/src/gprs_rlcmac_ts_alloc.cpp: 907 in alloc_algorithm_b() > 901 dl_slots, 'D'), > 902 single ? ", single" : ""); > 903 > 904 /* assign downlink */ > 905 if (dl_slots == 0) { > 906 LOGP(DRLCMAC, LOGL_NOTICE, "No downlink slots " >>>> CID 70677: Control flow issues (DEADCODE) >>>> Execution cannot reach this statement "do { > if (log_check_level...". > 907 "available\n"); > 908 return -EINVAL; > 909 } > 910 slotcount = pcu_bitcount(dl_slots); > 911 first_ts = ffs(dl_slots) - 1; > 912 avail_count = pcu_bitcount(reserved_dl_slots); > > ** CID 70676: Control flow issues (DEADCODE) > /source-iuh/libosmo-netif/src/rtp.c: 124 in osmo_rtp_get_payload() > > > ________________________________________________________________________________________________________ > *** CID 70676: Control flow issues (DEADCODE) > /source-iuh/libosmo-netif/src/rtp.c: 124 in osmo_rtp_get_payload() > 118 return NULL; > 119 } > 120 } > 121 if (rtph->padding) { > 122 if (payload_len < 0) { > 123 DEBUGPC(DLMUX, "received RTP frame too short for " >>>> CID 70676: Control flow issues (DEADCODE) >>>> Execution cannot reach this statement "do { > if (log_check_level...". > 124 "padding length\n"); > 125 return NULL; > 126 } > 127 payload_len -= payload[payload_len - 1]; > 128 if (payload_len < 0) { > 129 DEBUGPC(DLMUX, "received RTP frame with padding " > > ** CID 70675: Control flow issues (DEADCODE) > /source-iuh/libosmo-netif/src/channel.c: 57 in osmo_chan_create() > > > ________________________________________________________________________________________________________ > *** CID 70675: Control flow issues (DEADCODE) > /source-iuh/libosmo-netif/src/channel.c: 57 in osmo_chan_create() > 51 LOGP(DLINP, LOGL_ERROR, "unsupported channel type `%s'\n", > 52 cur->name); > 53 return NULL; > 54 } > 55 if (found_partial) { > 56 LOGP(DLINP, LOGL_ERROR, "Sorry, channel type `%s' does not " >>>> CID 70675: Control flow issues (DEADCODE) >>>> Execution cannot reach this statement "do { > if (log_check_level...". > 57 "support subtype `%u'\n", cur->name, subtype_id); > 58 return NULL; > 59 } > 60 > 61 c = talloc_zero_size(osmo_chan_ctx, > 62 sizeof(struct osmo_chan) + cur->datasiz); > > > ________________________________________________________________________________________________________ > To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/osmocom?tab=overview > > To manage Coverity Scan email notifications for "holger(a)freyther.de", click https://scan.coverity.com/subscriptions/edit?email=holger%40freyther.de&tok… >

9 years, 3 months

milestone: 3G CS Location Update Accept

by Neels Hofmeyr

Hi list, I've just seen my first Location Update Accept from our UMTS UE+femtoCell using osmo-cscn as IuCS network core :D The Identity Request (IMSI) that the UE used to not answer is now being answered, and I am getting a successful Location Update Accept from osmo-cscn after that. The reason why it didn't work last time isn't entirely clear. All I changed since is the *test* program that simulates the UE+hNodeB, and I merely verified that osmo-cscn works (as far as LU is concerned). A hint is, Daniel told me that the IuPS setup had one day stopped to reply with a message that used to work before, and has since again started working. So it might've been a timing issue in the reply towards UE. Next steps: Next I will briefly try to run Daniel's 3G SGSN together with CSCN to see whether the premature Iu Release (?) he sees still happens when CS is connected successfully. There is also still a segfault in osmo-hnbgw, triggered by reconnecting a second time with our hnb-test that simulates an hNodeB. That's next on the hacking todo list. According to the specs, proper Authentication is mandatory for UMTS, which osmo-cscn should initiate. That's not happening yet. It seems our testing UE is fine with that, so I'll see when I'll get to that. ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte

9 years, 3 months

gsm 7bit decode: *8/7

by Neels Hofmeyr

Hi list, I just thought I had fixed gsm_7bit_decode_n(), since its API doc says * \param length The length of the input sequence (in octets). int gsm_7bit_decode_n([...], uint8_t length); but the implementation is int gsm_7bit_decode_n([...], uint8_t septet_l) and indeed the length parameter is handled as septet length. So, logically, I came up with this patch: diff --git a/src/gsm/gsm_utils.c b/src/gsm/gsm_utils.c index e8e452f..a9afc1a 100644 --- a/src/gsm/gsm_utils.c +++ b/src/gsm/gsm_utils.c @@ -184,8 +184,9 @@ return text - text_buf_begin; } -int gsm_7bit_decode_n(char *text, size_t n, const uint8_t *user_data, uint8_t septet_l) +int gsm_7bit_decode_n(char *text, size_t n, const uint8_t *user_data, uint8_t octet_l) { + uint8_t septet_l = ((uint16_t)octet_l * 8) / 7; return gsm_7bit_decode_n_hdr(text, n, user_data, septet_l, 0); } (the cast to uint16_t makes 100% sure the calculation isn't truncated to uint8_t after the *8 multiplication -- I picked this up while hacking on 8bit microcontrollers. That truncation doesn't really happen on our 32bit/64bit machines, but if it did, the length would effectively be limited to 255/8 == 31 characters.) Then I noticed that callers actually do *8/7 before calling the function: parse_process_uss_req(): num_chars = (uss_req_data[6] * 8) / 7; /* Prevent a mobile-originated buffer-overrun! */ if (num_chars > MAX_LEN_USSD_STRING) num_chars = MAX_LEN_USSD_STRING; gsm_7bit_decode_n_ussd((char *)req->ussd_text, sizeof(req->ussd_text), &(uss_req_data[7]), num_chars); (This is gsm_7bit_decode_n_ussd(), its API doc says "see gsm_7bit_decode_n()") So we have the API talking about length "in octets" while the implementation clearly employs septet length. Fixing the implementation to match the API doc would break binary compatibility. I should probably fix the API doc to match that weird implementation, but it nags and hurts a little. Any opinions? ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte

9 years, 3 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC February 2016