OpenBSC

openbsc@lists.osmocom.org

4315 discussions

osmo-trx binary can't be moved between "same" CPUs
by Neels Hofmeyr 05 Dec '16

05 Dec '16

Hi osmo-trx folks, I'd like to draw your attention to https://osmocom.org/issues/1869 -- "osmo-trx binary cannot be moved to similar CPU" Has anyone seen this before and/or is up to the task of fixing it? Thanks! ~N -- - 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: Harald Welte

2 2

Dynamic TCH/F_PDCH does not work as TCH/F for CS voice call
by Mrinal Mishra 05 Dec '16

05 Dec '16

Hello All, As reported earlier "CS call is not working using TCH/F_PDCH dynamic channel configuration" in URRP B210 board(osmo-trx) . We further checked the commit version using git bisect to find out the exact version from where this functionality is broken . Below is the commit version of BSC : c3f72f63afde926dfc46827d6880055597515fb6 dyn TS: fix: ts_subslots() for TCH/F_PDCH in PDCH mode Thanks and Regards, Mrinal

3 2

libosmocore support for GSMTAP based logging
by Harald Welte 02 Dec '16

02 Dec '16

Dear all, when debugging Osmocom programs, one usually looks at either the pcap trace of one of the many interfaces (Um interface via GSMTAP or OsmocomBB, Abis, Gb, Gp or A interface via ethernet, ...) or at the log files of the various osmocom programs. Sometimes it can be hard to match the two different domains, and it is useful to see in sequence when a certain message was received and what kind of actions this triggered inside e.g. OsmoPCU or OSmoSGSN. One could have used the libosmocore 'syslog' log target for this and then configure the local syslog daemon to log to a remote syslog server via the network. However, as there is another local process and context switches involved, the messages were re-ordered. Also, syslog only receives the fully-formatted log string, and not the meta-data like the log level or sub-system. Hence, the idae of having a GSMTAP based log target was floating around the project for many years. I finally implemented this today. The advantage is that in our single-threaded osmocom programs the GSMTAP messages will leave in-sequence with the protocol messages received or transmitted, and there is only the limited chance of re-ordering by the local network stack and/or intermediate routers. Both shouldn't be much of a concern during local debugging. What do you need to use this? 1) The follwoing three libosmcoore commits from gerrit: https://gerrit.osmocom.org/#/c/1355 https://gerrit.osmocom.org/#/c/1356 https://gerrit.osmocom.org/#/c/1357 2) a "log gsmtap" configuration in your config file (or via vty), similar to how syslog logging is configured: === SNIP === log gsmtap localhost logging filter all 1 logging color 1 logging print category 0 logging timestamp 0 logging level all everything logging level rll notice [...] === SNIP === 3) a wireshark with my Change-ID I0de723445e5b5ce0199a4081808111240a9ed047 (can also be found in the laforge/gsmtap-log branch of git://git.osmocom.org/wireshark or http://git.osmocom.org/wireshark/commit/?h=laforge/gsmtap-log&id=3a207894a4… I will leave this in review for a few days and then plan to merge it into libosmocore. The wireshark patch will also be submitted at that time. A screenshot is attached for your reference. There is of course no coloring of the lines in wirshark, but you can set various wireshark filters (e.g. on log level, sub-system) and also use colorization rules to e.g. map sub-systems again to colors. 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)

1 0

broken build, reverting CHREQ_T_PDCH_ONE_PHASE and CHREQ_T_PDCH_TWO_PHASE
by Neels Hofmeyr 02 Dec '16

02 Dec '16

Heads up, the current openbsc build is broken, as verified by https://jenkins.osmocom.org/jenkins/job/OpenBSC/ This is due to below libosmocore commit, which adds two items to enum chreq_type, thereby implicitly enlarging the ctype_by_chreq struct and breaking the static assert for gsm_network->ctype_by_chreq's size: ../../../src/libbsc/gsm_04_08_utils.c:138:1: error: size of array ‘dummyassert_size’ is negative osmo_static_assert(sizeof(ctype_by_chreq) == ^ What this patch lacks is * adjustment of ctype_by_chreq[] according to the new additions in libbsc/gsm_04_08_utils.c * same for reason_by_chreq[], also in libbsc/gsm_04_08_utils.c * enlarge ctype_by_chreq[] in gsm_network to 18, in openbsc/gsm_data.h. I could try to guess what the ctype_by_chreq[] and reason_by_chreq[] items should be, but to not get distracted from my current task, and since the values don't seem to be used by the current master branches yet, I decided to simply revert the libosmocore commit and leave it up to the original authors to follow up. (No need to mention that those should be merged to libosmocore and openbsc "at the same time" to avoid builds failing.) Thanks and apologies for any inconvenience... ~Neels commit c3c28528de78fd5d50c3a141c2176c0da5dd7075 Refs: 0.9.0-299-gc3c2852 Author: Alexander Couzens <lynxis(a)fe80.eu> AuthorDate: Tue Nov 29 12:42:05 2016 +0100 Commit: Harald Welte <laforge(a)gnumonks.org> CommitDate: Thu Dec 1 15:26:29 2016 +0000 gsm0408: add chreq_type for CHREQ_T_PDCH_ONE_PHASE and CHREQ_T_PDCH_TWO_PHASE For BSC-located pcu the BSC must understand the PDCH chan request. Change-Id: Ice44dcaaf798f93af3652a96c567f8e16a6cf784 --- include/osmocom/gsm/protocol/gsm_04_08.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/osmocom/gsm/protocol/gsm_04_08.h b/include/osmocom/gsm/protocol/gsm_04_08.h index 767aa3d..c05b62e 100644 --- a/include/osmocom/gsm/protocol/gsm_04_08.h +++ b/include/osmocom/gsm/protocol/gsm_04_08.h @@ -1456,6 +1456,8 @@ enum chreq_type { CHREQ_T_PAG_R_TCH_F, CHREQ_T_PAG_R_TCH_FH, CHREQ_T_LMU, + CHREQ_T_PDCH_ONE_PHASE, + CHREQ_T_PDCH_TWO_PHASE, CHREQ_T_RESERVED_SDCCH, CHREQ_T_RESERVED_IGNORE, }; -- - 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: Harald Welte

2 3

RBS 2308 Protocol Error
by Caleb Pal 01 Dec '16

01 Dec '16

Good Evening, With the recent commits for the OM2000 protocol, I figured it was time to dust off the RBS2308 and see what would happen. I am using the latest version of DAHDI, with a TE122P T1 card. All osmocom software was pulled yesterday and installed successfully on a machine running Debian Stable. When OpenBSC starts, all appears normal with regards to bringing the BTS up until the timeslots for the first TRX are being configured. When the timeslots are configured, a protocol error is given for each. If I change trx0/ts0 from the default of CCCH+SDCCH4 to CCCH, that timeslot is successfully brought up, and the BTS transmits. Other configurations (TCH/F, TCH/F, PDCH, SDCCH8, TCH/F_TCH/H_PDCH) on timeslots 1-7 give the same protocol error. I have attached my openbsc.cfg, the output from the OpenBSC console, a pcap of the failed startup, and my DAHDI configuration. If they do not come through the list server, they are also available at: http://cleb.org/RBS/ Thanks, Caleb

3 4

confused by libosmo-netif
by Neels Hofmeyr 28 Nov '16

28 Nov '16

By random, I looked at an fd leak complained about by coverity in osmo_stream_srv_fd_cb() and came up with https://gerrit.osmocom.org/1320 Now I wanted to at least run it once to make sure I didn't break anything, but I'm unsure in figuring out how it is used. There are two Iu related callers: osmo-iuh's hnbgw.c and libosmo-sccp's sua.c. And I find libosmo-netif/src/channel/abis/ipa_stream_server.c, called in libosmo-netif/src/channel.c by osmo_chan_init() and osmo_chan_create(). But it seems no-one is ever calling these, except for examples in libosmo-netif. Am I right to conclude that there's some 2G / Abis / ip.access related code in libosmo-netif but we're not actually using it in openbsc, and that the only "real" osmo_stream_srv_* callers are 3G/Iu related? ~N -- - 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: Harald Welte

2 1

Re: Re: Any one who can help me ,can't find a branch or tag which may compile success.!! thank u.
by Harald Welte 28 Nov '16

28 Nov '16

pleaes always make sure you send your responses to the mailing list, never by private mail to individual developer s only On Mon, Nov 28, 2016 at 07:52:39AM +0800, 韩明君 wrote: > when i use the newest version of git tag 3G_2016_09 for compile I got lots of > make error(；′⌒`) so switch to the old version if you want anyone to help you, you need to include the exact error messages (copy+paste) in your message to the mailing list. > Anad another question is where may I found the nightly package,and download the *.deb file It is really very simple. Go to osmocom.org and search for 'nigthly'. Then you will find the link to http://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds -- - 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)

1 0

Any one who can help me ,can't find a branch or tag which may compile success.!! thank u.
by 韩明君 27 Nov '16

27 Nov '16

hello everyone ,first thanks for yours look at this email ... i work under ubuntu 14.04 and with the doc of http://osmocom.org/projects/openbsc/wiki/Building_OpenBSC now i only can do make install and success with git version of on-waves/0.3 （openbsc） and success found the executable file drwxr-xr-x 2 root root 4096 11月 27 15:42 ./ drwxr-xr-x 11 root root 4096 11月 13 21:46 ../ -rwxr-xr-x 1 root root 551571 11月 27 15:42 bs11_config* -rwxr-xr-x 1 root root 1877782 11月 27 15:42 bsc_hack* -rwxr-xr-x 1 root root 528464 11月 27 15:42 bsc_mgcp* -rwxr-xr-x 1 root root 1547559 11月 27 15:42 bsc_msc_ip* -rwxr-xr-x 1 root root 967960 11月 27 15:42 bsc_nat* -rwxr-xr-x 1 root root 1359089 11月 27 15:42 ipaccess-config* -rwxr-xr-x 1 root root 37451 11月 27 15:42 ipaccess-find* -rwxr-xr-x 1 root root 25066 11月 27 15:42 isdnsync* but as the README under openbsc this version don't work well with ip based BTS

2 1

question on USSD messages
by Neels Hofmeyr 26 Nov '16

26 Nov '16

Hi all, I'm looking at USSD message generation in openbsc, and would like to move a bit of msg generation to libosmocore. However, in libosmocore's gsm0480.c I already find an implementation that seems to do the same, yet with some differences I'm not sure how to deal with. The function originally in openbsc: gsm0480_send_releaseComplete() On the iu branch, I've moved the msg generation to gsm0480_gen_releaseComplete() This should rather go to libosmocore. There I already find gsm0480_create_ussd_resp() The openbsc variants are rather shorter. Is it incomplete/incorrect?? Is the libosmocore gsm0480_create_ussd_resp() just bloat for this case?? For convenience, let me paste the code: openbsc's Release Complete, very lean: struct msgb *gsm0480_gen_releaseComplete(void) { struct msgb *msg; msg = gsm48_msgb_alloc_name("GSM 04.08 USSD REL COMPL"); if (!msg) return NULL; gsm0480_l3hdr_push(msg, GSM48_PDISC_NC_SS, GSM0480_MTYPE_RELEASE_COMPLETE); return msg; } Note that the above does not set a direction flag nor trans_id in the proto_discr, like libosmocore's gsm0480_create_ussd_resp() does; neither do I understand the purpose of all the constant "code/id" TLs and wrapping: struct msgb *gsm0480_create_ussd_resp(uint8_t invoke_id, uint8_t trans_id, const char *text) { struct msgb *msg; uint8_t *ptr8; int response_len; msg = msgb_alloc_headroom(1024, 128, "GSM 04.80"); if (!msg) return NULL; /* First put the payload text into the message */ ptr8 = msgb_put(msg, 0); gsm_7bit_encode_n_ussd(ptr8, msgb_tailroom(msg), text, &response_len); msgb_put(msg, response_len); /* Then wrap it as an Octet String */ msgb_wrap_with_TL(msg, ASN1_OCTET_STRING_TAG); /* Pre-pend the DCS octet string */ msgb_push_TLV1(msg, ASN1_OCTET_STRING_TAG, 0x0F); /* Then wrap these as a Sequence */ msgb_wrap_with_TL(msg, GSM_0480_SEQUENCE_TAG); /* Pre-pend the operation code */ msgb_push_TLV1(msg, GSM0480_OPERATION_CODE, GSM0480_OP_CODE_PROCESS_USS_REQ); /* Wrap the operation code and IA5 string as a sequence */ msgb_wrap_with_TL(msg, GSM_0480_SEQUENCE_TAG); /* Pre-pend the invoke ID */ msgb_push_TLV1(msg, GSM0480_COMPIDTAG_INVOKE_ID, invoke_id); /* Wrap this up as a Return Result component */ msgb_wrap_with_TL(msg, GSM0480_CTYPE_RETURN_RESULT); /* Wrap the component in a Facility message */ msgb_wrap_with_TL(msg, GSM0480_IE_FACILITY); /* And finally pre-pend the L3 header */ gsm0480_l3hdr_push(msg, GSM48_PDISC_NC_SS | trans_id | (1<<7) /* TI direction = 1 */, GSM0480_MTYPE_RELEASE_COMPLETE); return msg; } Thanks for any insights! ~N -- - 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: Harald Welte

1 0

Re: New Defects reported by Coverity Scan for Osmocom
by Neels Hofmeyr 25 Nov '16

25 Nov '16

On Thu, Nov 24, 2016 at 12:01:08PM -0800, scan-admin(a)coverity.com wrote: > ________________________________________________________________________________________________________ > *** CID 149097: Null pointer dereferences (FORWARD_NULL) > /source-Osmocom/openbsc/openbsc/src/gprs/gprs_sndcp_comp.c: 67 in gprs_sndcp_comp_create() > 61 comp_field->rfc2507_params->nsapi, > 62 sizeof(comp_entity->nsapi)); > 63 } else if (comp_field->rohc_params) { > 64 comp_entity->nsapi_len = comp_field->rohc_params->nsapi_len; > 65 memcpy(comp_entity->nsapi, comp_field->rohc_params->nsapi, > 66 sizeof(comp_entity->nsapi)); > >>> CID 149097: Null pointer dereferences (FORWARD_NULL) > >>> Comparing "comp_field->v42bis_params" to null implies that "comp_field->v42bis_params" might be null. The point of this complaint: - gprs_sndcp_comp.c:67 implies that v42bis_params might be NULL - on line 104 we call gprs_sndcp_dcomp_init() - then this function (gprs_sndcp_dcomp.c near 88) dereferences comp_field->v42bis_params without checking for NULL (instead relies on comp_entity->algo == V42BIS) I think I'd add an OSMO_ASSERT(comp_field->v42bis_params) in gprs_sndcp_dcomp_init(). pmaier? ~N

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC