OpenBSC

openbsc@lists.osmocom.org

19 participants
4282 discussions

Re: Moving from trac to a single redmine
by Вадим Яницкий 22 Feb '16

22 Feb '16

Hi all! Moving all projects to a Redmine is a good way, I think. In connection with the event I would like to offer my help with post-processing some old pages (mostly OsmocomBB) and with improving the new wiki structure. So, my suggestions: - Create the main page that will describe all all of the child projects of Osmocom umbrella including recent news and plans. - Separate the libosmocore related pages from OsmocomBB into a new section named "Libraries", for example. - Separate both SIMTrace and softSIM into a new sections. It it would be nice to enable Strict-Transport-Security to avoid some traffic interception attempts. Also what about enabling SPF and DKIM for mailing lists? With best regards, Vadim Yanitskiy. 2016-02-19 4:46 GMT+06:00 <openbsc-request(a)lists.osmocom.org>: > Send OpenBSC mailing list submissions to > openbsc(a)lists.osmocom.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osmocom.org/mailman/listinfo/openbsc > or, via email, send a message with subject or body 'help' to > openbsc-request(a)lists.osmocom.org > > You can reach the person managing the list at > openbsc-owner(a)lists.osmocom.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OpenBSC digest..." > > > Today's Topics: > > 1. Re: autoreconf v2.69 with subdir-objects: ./configure creates > directory 'src/tests/\$(top_srcdir)' (Neels Hofmeyr) > 2. Re: hnb_cs_lu.msc (Neels Hofmeyr) > 3. Re: hnb_cs_lu.msc (Harald Welte) > 4. branches: daniel/gprs-iu + sysmocom/cscn = sysmocom/iu; > merging to master (Neels Hofmeyr) > 5. Re: Moving from trac to a single redmine (Harald Welte) > 6. Re: Moving from trac to a single redmine (Holger Freyther) > 7. Re: branches: daniel/gprs-iu + sysmocom/cscn = sysmocom/iu; > merging to master (Holger Freyther) > 8. sysmocom/iu: your commits from today (Neels Hofmeyr) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 17 Feb 2016 15:44:35 +0100 > From: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> > To: Eric Blake <eblake(a)redhat.com> > Cc: bug-autoconf(a)gnu.org, openbsc(a)lists.osmocom.org > Subject: Re: autoreconf v2.69 with subdir-objects: ./configure creates > directory 'src/tests/\$(top_srcdir)' > Message-ID: <20160217144435.GD2106@dub6> > Content-Type: text/plain; charset="us-ascii" > > Eric, > > you've clarified just about all of my questions. > Many thanks for your reply! > > ~Neels > > > https://lists.gnu.org/archive/html/automake/2015-12/msg00001.html >

3 3

warnings
by Neels Hofmeyr 21 Feb '16

21 Feb '16

Hi list, I tend to use vim's :make command so that it takes me to the positions of warnings and errors automatically. However, when hacking on osmo-iuh, I sometimes get dozens of these irritating warning chunks: [[[ ../../include/osmocom/hnbap/CriticalityDiagnostics-IE-List.h:35:10: warning: ‘struct Member’ declared inside parameter list struct IE_Extensions *iE_Extensions /* OPTIONAL */; ^ /usr/local/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^ ../../include/osmocom/hnbap/CriticalityDiagnostics-IE-List.h:31:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct Member { ^ ../../include/osmocom/hnbap/CriticalityDiagnostics-IE-List.h:35:10: warning: its scope is only this definition or declaration, which is probably not what you want struct IE_Extensions *iE_Extensions /* OPTIONAL */; ^ /usr/local/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^ ../../include/osmocom/hnbap/CriticalityDiagnostics-IE-List.h:31:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct Member { ^ ]]] The cause are numerous instances of code like: [[[ /* CriticalityDiagnostics-IE-List */ typedef struct CriticalityDiagnostics_IE_List { A_SEQUENCE_OF(struct Member { Criticality_t iECriticality; ProtocolIE_ID_t iE_ID; TypeOfError_t typeOfError; struct IE_Extensions *iE_Extensions /* OPTIONAL */; /* * This type is extensible, * possible extensions are below. */ /* Context for parsing across buffer boundaries */ asn_struct_ctx_t _asn_ctx; } ) list; /* Context for parsing across buffer boundaries */ asn_struct_ctx_t _asn_ctx; } CriticalityDiagnostics_IE_List_t; ]]] "...which is probably not what you want". Turns out it kinda is what I want, I just don't want these warnings :P Filtering proper error messages from this mess is hard. Any idea to get rid of these warnings would speed up my dev cycle dramatically... Short of refactoring the way these A_SEQUENCE_OF() get generated. I guess the struct should rather be first declared with a unique name and then only the type name should be used in A_SEQUENCE_OF(). i.e. not like osmo-iuh/include/osmocom/rua/RUA_CriticalityDiagnostics-IE-List.h: A_SEQUENCE_OF(struct Member {... but like: osmo-iuh/include/osmocom/rua/RUA_Disconnect.h: A_SEQUENCE_OF(RUA_IE_t) list; Doesn't seem to come from the asn1tostruct.py... Thanks!! ~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

2 2

Progress of trac->redmine migration
by Holger Freyther 21 Feb '16

21 Feb '16

Hi all, I think we are close to the point of no return. All tickets and wikis have been imported. Please have a quick look if there is something obviously broken and if not I will proceed with post-processing and renaming tonight. kind regards holger

3 3

License exception for OpenSSL
by Ruben Undheim 21 Feb '16

21 Feb '16

Hi, When running lintian on openbsc, I get the following error: E: osmocom-bsc-nat: possible-gpl-code-linked-with-openssl E: osmocom-nitb: possible-gpl-code-linked-with-openssl It seems like openbsc is being linked with libcrypto from OpenSSL, but I cannot find any statement of OpenSSL exception for the AGPL. Debian policy requires this. Can you look into this? You can have a look at wget if you need an example. Ruben

2 3

branches: daniel/gprs-iu + sysmocom/cscn = sysmocom/iu; merging to master
by Neels Hofmeyr 21 Feb '16

21 Feb '16

The openbsc branches to use for testing IuPS and IuCS have changed, because Daniel and I have merged the branches. They used to be daniel/gprs-iu (IIRC) and sysmocom/cscn. Both are now merged as: sysmocom/iu Holger, this is relevant to our coverity configuration. We are still using other branches that may or may not be merged to their respective masters. I'd like to publicly record here why or why not we should merge them now. Please add any reasons you know. We're using master for Iu[h|CS|PS] in: libasn1c: * master libosmo-abis: * master libosmocore: * master openggsn: * master osmo-python-tests: * master osmo-iuh: * master Reasons NOT to merge to master in: openbsc: * sysmocom/iu - hardcoded kc and sres for testing - NITB and most probably osmo-bsc are not operational - A-interface not implemented in CSCN asn1c: * aper-prefix - ? libosmo-netif: * sysmocom/sctp - ? libosmo-sccp: * laforge/wip - ? Thanks for any additions... ~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

3 3

Status of osmocom libraries in Debian
by Ruben Undheim 20 Feb '16

20 Feb '16

Hi, First of all I would like to thank you guys for working on an awesome project and contributing so much nice code! I've been working on getting the Osmocom libraries into Debian. libosmocore has been there for some time now, but I recently also got libosmo-sccp, libosmo-abis, libosmo-netif, libsmpp34 (not directly osmocom) and openggsn in. This means that all dependencies for building openbsc, osmo-bts and osmo-pcu should be available in Debian. I would also like to thank you for keeping a quite well-maintained debian directory in the tar-balls, even with good state of SONAME-ing etc. I've used this as the starting point where possible, but also modified them to meet "Debian standard". It would be great if you could test the packages and also verify that the copyright files contain all the copyright holders. Let me know on this list or on private email if there is something missing or wrong. Here are links to all copyright files: https://tracker.debian.org/media/packages/libo/libosmo-abis/copyright-0.3.2… https://tracker.debian.org/media/packages/libo/libosmo-netif/copyright-0.0.… https://tracker.debian.org/media/packages/libo/libosmo-sccp/copyright-0.7.0… https://tracker.debian.org/media/packages/libo/libosmocore/copyright-0.9.0-4 https://tracker.debian.org/media/packages/libs/libsmpp34/copyright-1.10-1 https://tracker.debian.org/media/packages/o/openggsn/copyright-0.92-1 You will have to run Debian sid (unstable) to directly install the packages using "apt install", but you could also download the .deb-files manually from: https://packages.debian.org/unstable/[packagename] or for Ubuntu here: https://launchpad.net/ubuntu/xenial/+source/[packagename] I'm also aware of that the code is moving ahead rapidly and what is in Debian unstable now may quickly get out-of-date. But I will try to keep them up-to- date as much as possible, and also provide backport packages. Getting the packages in the first time is usually much more cumbersome than keeping them up-to-date. For those interested in Ubuntu, the current versions will most likely get into the next long-term support release (16.04), since its freeze date for package imports from Debian is already Feb 18th. So let me know quickly if there is something wrong so that I possibly may be able to fix it before the freeze (when it's much more straight forward). Cheers, Keep up the good work. Ruben

3 3

[PATCH] Extend L1SAP PH-DATA with presence information
by msuraev＠sysmocom.de 20 Feb '16

20 Feb '16

From: Max <msuraev(a)sysmocom.de> Previously the presence of header and data blocks were communicated in-band which decreases code readability and makes it unnecessary hard to add support for new hardware. Note: both OsmoBTS and OsmoPCU have to be modified to take advantage of extended ph_data_param structure. --- include/osmocom/gsm/l1sap.h | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/include/osmocom/gsm/l1sap.h b/include/osmocom/gsm/l1sap.h index 9f3fe98..1af8ba8 100644 --- a/include/osmocom/gsm/l1sap.h +++ b/include/osmocom/gsm/l1sap.h @@ -25,6 +25,16 @@ enum osmo_mph_info_type { PRIM_INFO_DEACT_CIPH, /*!< \brief Deactivation of ciphering */ }; +/*! \brief PH-DATA presence information */ +enum osmo_ph_pres_info_type { + PRES_INFO_INVALID = 0, /*!< \brief Data is invalid */ + PRES_INFO_HEADER = 1, /*!< \brief Only header is present and valid */ + PRES_INFO_FIRST = 3, /*!< \brief First half of data + header are valid (2nd half may be present but invalid) */ + PRES_INFO_SECOND = 5, /*!< \brief Second half of data + header are valid (1st halfmay be present but invalid) */ + PRES_INFO_BOTH = 7, /*!< \brief Both parts + header are present and valid */ + PRES_INFO_UNKNOWN +}; + /*! \brief for PH-RANDOM_ACCESS.req */ struct ph_rach_req_param { uint8_t ra; /*!< \brief Random Access */ @@ -48,6 +58,7 @@ struct ph_data_param { uint8_t chan_nr; /*!< \brief Channel Number (Like RSL) */ uint32_t fn; /*!< \brief GSM Frame Number */ int8_t rssi; /*!< \brief RSSI of receivedindication */ + enum osmo_ph_pres_info_type pdch_presence_info; /*!< \brief Info regarding presence/validity of header and data parts */ }; /*! \brief for TCH.{req,ind} | TCH-RTS.ind */ -- 2.7.1

3 2

[PATCH 1/3] Ignore files generated by cscope tool
by msuraev＠sysmocom.de 20 Feb '16

20 Feb '16

From: Max <msuraev(a)sysmocom.de> Signed-off-by: Max <msuraev(a)sysmocom.de> --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 6cc9aa5..a22fd4f 100644 --- a/.gitignore +++ b/.gitignore @@ -5,6 +5,7 @@ Makefile.in Makefile .deps +src/cscope* aclocal.m4 autom4te.cache -- 2.7.1

2 3

[PATCH] Fix OsmoPCU integration
by msuraev＠sysmocom.de 20 Feb '16

20 Feb '16

From: Max <msuraev(a)sysmocom.de> Add support for explicitly passing PH-DATA presence info. Remove in-band passing of presence information and replace corresponding check. This also fixes integration between Octasic BTS hw and OsmoPCU: previously osmo-bts-octphy have not provided in-band presence information which cause off-by-one errors and misinterpretation of ph_data_ind by PCU. Note: this requires libosmocore version with osmo_ph_pres_info_type support integrated. --- include/osmo-bts/scheduler_backend.h | 2 +- src/common/l1sap.c | 5 +++-- src/common/scheduler.c | 3 ++- src/osmo-bts-octphy/l1_if.c | 1 + src/osmo-bts-trx/scheduler_trx.c | 16 +++++++--------- 5 files changed, 14 insertions(+), 13 deletions(-) diff --git a/include/osmo-bts/scheduler_backend.h b/include/osmo-bts/scheduler_backend.h index 9f663cd..1614250 100644 --- a/include/osmo-bts/scheduler_backend.h +++ b/include/osmo-bts/scheduler_backend.h @@ -42,7 +42,7 @@ struct msgb *_sched_dequeue_prim(struct l1sched_trx *l1t, int8_t tn, uint32_t fn enum trx_chan_type chan); int _sched_compose_ph_data_ind(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, - enum trx_chan_type chan, uint8_t *l2, uint8_t l2_len, float rssi); + enum trx_chan_type chan, uint8_t *l2, uint8_t l2_len, float rssi, enum osmo_ph_pres_info_type presence_info); int _sched_compose_tch_ind(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, enum trx_chan_type chan, uint8_t *tch, uint8_t tch_len); diff --git a/src/common/l1sap.c b/src/common/l1sap.c index 8056034..ac398d3 100644 --- a/src/common/l1sap.c +++ b/src/common/l1sap.c @@ -744,6 +744,7 @@ static int l1sap_ph_data_ind(struct gsm_bts_trx *trx, uint8_t tn; uint32_t fn; int8_t rssi; + enum osmo_ph_pres_info_type pr_info = data_ind->pdch_presence_info; rssi = data_ind->rssi; chan_nr = data_ind->chan_nr; @@ -767,11 +768,11 @@ static int l1sap_ph_data_ind(struct gsm_bts_trx *trx, return 0; } /* drop incomplete UL block */ - if (data[0] != 7) + if (pr_info != PRES_INFO_BOTH) return 0; /* PDTCH / PACCH frame handling */ pcu_tx_data_ind(&trx->ts[tn], 0, fn, 0 /* ARFCN */, - L1SAP_FN2MACBLOCK(fn), data + 1, len - 1, rssi); + L1SAP_FN2MACBLOCK(fn), data, len, rssi); return 0; } diff --git a/src/common/scheduler.c b/src/common/scheduler.c index e9d2423..07c2e12 100644 --- a/src/common/scheduler.c +++ b/src/common/scheduler.c @@ -268,7 +268,7 @@ found_msg: } int _sched_compose_ph_data_ind(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, - enum trx_chan_type chan, uint8_t *l2, uint8_t l2_len, float rssi) + enum trx_chan_type chan, uint8_t *l2, uint8_t l2_len, float rssi, enum osmo_ph_pres_info_type presence_info) { struct msgb *msg; struct osmo_phsap_prim *l1sap; @@ -284,6 +284,7 @@ int _sched_compose_ph_data_ind(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, l1sap->u.data.link_id = trx_chan_desc[chan].link_id; l1sap->u.data.fn = fn; l1sap->u.data.rssi = (int8_t) (rssi); + l1sap->u.data.pdch_presence_info = presence_info; msg->l2h = msgb_put(msg, l2_len); if (l2_len) memcpy(msg->l2h, l2, l2_len); diff --git a/src/osmo-bts-octphy/l1_if.c b/src/osmo-bts-octphy/l1_if.c index 3215aa1..781d589 100644 --- a/src/osmo-bts-octphy/l1_if.c +++ b/src/osmo-bts-octphy/l1_if.c @@ -1032,6 +1032,7 @@ static int handle_ph_data_ind(struct octphy_hdl *fl1, l1sap->u.data.chan_nr = chan_nr; l1sap->u.data.fn = fn; l1sap->u.data.rssi = rssi; + l1sap->u.data.pdch_presence_info = PRES_INFO_BOTH; /* FIXME: consider EDGE support */ l1sap_up(trx, l1sap); diff --git a/src/osmo-bts-trx/scheduler_trx.c b/src/osmo-bts-trx/scheduler_trx.c index 15c05e8..243539d 100644 --- a/src/osmo-bts-trx/scheduler_trx.c +++ b/src/osmo-bts-trx/scheduler_trx.c @@ -190,7 +190,7 @@ got_msg: l1if_process_meas_res(l1t->trx, tn, fn, trx_chan_desc[chan].chan_nr | tn, 456, 456, -110, 0); - _sched_compose_ph_data_ind(l1t, tn, 0, chan, NULL, 0, -110); + _sched_compose_ph_data_ind(l1t, tn, 0, chan, NULL, 0, -110, PRES_INFO_INVALID); } } @@ -841,7 +841,7 @@ int rx_data_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, l1if_process_meas_res(l1t->trx, tn, fn, trx_chan_desc[chan].chan_nr | tn, n_errors, n_bits_total, *rssi_sum / *rssi_num, *toa_sum / *toa_num); - return _sched_compose_ph_data_ind(l1t, tn, *first_fn, chan, l2, l2_len, *rssi_sum / *rssi_num); + return _sched_compose_ph_data_ind(l1t, tn, *first_fn, chan, l2, l2_len, *rssi_sum / *rssi_num, PRES_INFO_UNKNOWN); } int rx_pdtch_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, @@ -856,7 +856,7 @@ int rx_pdtch_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, uint8_t *rssi_num = &chan_state->rssi_num; float *toa_sum = &chan_state->toa_sum; uint8_t *toa_num = &chan_state->toa_num; - uint8_t l2[54+1]; + uint8_t l2[54]; int n_errors, n_bits_total; int rc; @@ -906,7 +906,7 @@ int rx_pdtch_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, *mask = 0x0; /* decode */ - rc = pdtch_decode(l2 + 1, *bursts_p, NULL, &n_errors, &n_bits_total); + rc = pdtch_decode(l2, *bursts_p, NULL, &n_errors, &n_bits_total); /* Send uplnk measurement information to L2 */ l1if_process_meas_res(l1t->trx, tn, fn, trx_chan_desc[chan].chan_nr | tn, @@ -919,10 +919,8 @@ int rx_pdtch_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, return 0; } - l2[0] = 7; /* valid frame */ - return _sched_compose_ph_data_ind(l1t, tn, (fn + GSM_HYPERFRAME - 3) % GSM_HYPERFRAME, chan, - l2, rc + 1, *rssi_sum / *rssi_num); + l2, rc + 1, *rssi_sum / *rssi_num, PRES_INFO_BOTH); } int rx_tchf_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, @@ -1038,7 +1036,7 @@ int rx_tchf_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, /* FACCH */ if (rc == GSM_MACBLOCK_LEN) { _sched_compose_ph_data_ind(l1t, tn, (fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME, chan, - tch_data + amr, GSM_MACBLOCK_LEN, rssi); + tch_data + amr, GSM_MACBLOCK_LEN, rssi, PRES_INFO_UNKNOWN); bfi: if (rsl_cmode == RSL_CMOD_SPD_SPEECH) { /* indicate bad frame */ @@ -1204,7 +1202,7 @@ int rx_tchh_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, chan_state->ul_ongoing_facch = 1; _sched_compose_ph_data_ind(l1t, tn, (fn + GSM_HYPERFRAME - 10 - ((fn % 26) >= 19)) % GSM_HYPERFRAME, chan, - tch_data + amr, GSM_MACBLOCK_LEN, rssi); + tch_data + amr, GSM_MACBLOCK_LEN, rssi, PRES_INFO_UNKNOWN); bfi: if (rsl_cmode == RSL_CMOD_SPD_SPEECH) { /* indicate bad frame */ -- 2.7.1

1 0

hnbgw should reconnect to CN
by Neels Hofmeyr 19 Feb '16

19 Feb '16

Hi list, during testing of OsmoCSCN, I find that osmo-hnbgw connects to the CN servers once, but when such a CN component restarts, no new connection is established. Sequence: - start hnbgw, which continuously tries to connect to CS and PS CN servers every five seconds (osmo-cscn and dummy-cn in my case). - start dummy-cn, hnbgw connects. - start osmo-cscn, hnbgw connects. - osmo-cscn segfaults ;) - hnbgw logs the disconnect - I restart osmo-cscn - but hnbgw never attempts to reconnect to osmo-cscn. - so I have to restart hnbgw, hnb-test and its VTY connection "all the time", which is cumbersome. I briefly tried to resolve the issue, but I'm losing patience. I tried to enable the DLINP debug logging but found that hnbgw's VTY doesn't allow me to manipulate logging levels, apparently. Next I'd have liked to set the hnbgw_log_info to indicate [DLINP] = { .loglevel = LOGL_DEBUG } but DLINP is negative. Does this really have to be as fiendish? I guess the INT2IDX() macro doesn't apply here, as it would cause index overlaps with the other D* constants. It can be really hard to find my way around the Osmo source code, with the little non-obvious things accumulating... I did find that much: the reconnect flag passed to osmo_stream_cli_open2() is effective only while state == STREAM_CLI_STATE_CONNECTING, i.e. until a first connection is established. Now, if upon disconnect, something were to set the state back to cli->state = STREAM_CLI_STATE_CONNECTING my guess is that the cli_timer_cb() would indeed attempt to reconnect as I intend. BTW, what does cli stand for? Not command-line interface, is it. If I stayed onto this I'd probably solve the issue. My focus should be on an IuCS Location Update though, so comments or help is appreciated :) So long I'll carry on with the workaround, restarting hnbgw "all the time". Thanks! ~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

3 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC