- OpenBSC - lists.osmocom.org

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 02 Dec '16

02 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

Nokia crash during init is fixed
by Sipos Csaba 24 Nov '16

24 Nov '16

Dear Harald, Just wanted to confirm that a long outstanding crash is now fixed by your patch: http://cgit.osmocom.org/libosmocore/commit/?id=f92e44c5399d8914aad58bd2c740… After applying it, the nasty hack I used is not needed anymore, and the BTS-es are coming up just fine, all services are working correctly. Will update the Nokia Site specific part of the wiki with this new information. Thanks! Csaba

3 10

Osmo-trx Git Access and New Branch Request
by z.tamosevicius＠limemicro.com 24 Nov '16

24 Nov '16

Hello, My name is Zydrunas Tamosevicius. I work for Lime on Myriad-RF and would like to ask to have a new "myriadrf" branch set up and access in osmo-trx git repository. We want to be able to work on adding support for Myriad-RF hardware. The intention is to have these changes merged into master after we get it working on our branch. Is there any guidelines we have to follow? Thank you in advance! -- Best regards, Zydrunas Tamosevicius Senior IC Design Engineer (Digital) Lime Microsystems z.tamosevicius(a)limemicro.com

2 1

MGCP support
by Kristian Martens 23 Nov '16

23 Nov '16

All, Does there exist a document describing to which port the callagent (MSC) has to connect to, how and where the CIC to RTP IP/port mapping table is defined etc? Regards, Kristian -- *Kristian Martens* Software Engineer Mobile: +49 160 1024262 Office: +49 30 65218529 / ng4T GmbH Siemensdamm 50 13629 Berlin Germany www.ng4t.com <http://www.ng4t.com> / Berlin-Charlottenburg, HRB 123546 Geschäftsführer Dr. Andreas Kallmann

2 1