OpenBSC

openbsc@lists.osmocom.org

4315 discussions

sysmocom/iu: your commits from today
by Neels Hofmeyr 22 Feb '16

22 Feb '16

Moin Daniel :) (1) About ebd4d820b3b0d7ba5db3b25a14f407d0c7276044 "libiu: Use custom setupormodifieditemies function" It seems you forgot to commit the actual function definition of ranap_decode_rab_setupormodifieditemies_fromlist() I got the caller of it only and thus can't compile as-is. (2) About 38e2f1bca4e43414ed39a938d7c5d8bafe5e8533 " Revert "iu.c: avoid warning by declaring ranap_free_rab_setupormodifieditemies()" There should be no need to silence this warning, the ranap_free_* functions are declared in libranap headers. In any case this will only obscure any real issue. Maybe osmo-iuh was not rebuilt completely (including generation of the c files from the python script). This reverts commit 05ae5b1245f95bf765b42e49af7b2596e013f0a0. " I declared ranap_free_rab_setupormodifieditemies() like that because it is indeed not declared in a header that is installed. Also a grep tells me that no ranap_free_* is found in any osmo-iuh header file at all. I also did a 'make regen' in osmo-iuh/src/ to no avail. By 'libranap headers' I assume you mean libosmo-ranap, or is there a libranap I'm not aware of yet? If the ranap_free_* aren't in headers yet, I agree that they should be. I wanted to silence the warning without being sucked down the rabbit hole of autogenerated asn1 stuff. Any suggestions: more than welcome. (3) In general, I would welcome to see more of your WIP work in publicly visible private branches, maturing as you go and merged to sysmocom/iu once ready. For one, having a backup of your work-in-progress in the git repos makes it harder to lose it due to hardware failure. More important for me though is that I can see what you're up to, e.g. I could possibly find the ranap_..._fromlist() function defintion now. It's of course opening up your "most private" code developments to the outside world, possibly some stupid commits will be seen by one or two hacker peers, but I think it's a healthy premise that we all commit mostly bollocks and all needs refinement anyway... once again: push it! :) Ah, push it Push it good Ah, push it Pu-Push it real good -- Salt N Pepa (1987) As always I'm open to opinions and suggestions... ~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 13

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

22 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

1 2

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

22 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: OsmoBTS have to be modified to take advantage of extended ph_data_param structure. --- TODO-RELEASE | 1 + include/osmocom/gsm/l1sap.h | 11 +++++++++++ 2 files changed, 12 insertions(+) diff --git a/TODO-RELEASE b/TODO-RELEASE index edf1099..0939336 100644 --- a/TODO-RELEASE +++ b/TODO-RELEASE @@ -1,2 +1,3 @@ #library what description / commit summary line libosmocore change major external talloc dependency / internal talloc removal +libosmocore change major size of ph_data_param struct changed / Extend L1SAP PH-DATA with presence information \ No newline at end of file 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

1 0

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

21 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 20 Feb '16

20 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 20 Feb '16

20 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 20 Feb '16

20 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 19 Feb '16

19 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 19 Feb '16

19 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC