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
On 18 Feb 2016, at 12:56, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
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.
and the build is broken.
/home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:126:1: warning: "ENHANCEDRELOCATIONCOMPLETEREQUESTIES_RANAP_EXTENDEDRNC_ID_PRESENT" redefined /home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:125:1: warning: this is the location of the previous definition /home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:436:1: warning: "RANAP_ENHANCEDRELOCATIONINFORMATIONREQUESTIES_RANAP_IUSIGNALLINGCONNECTIONIDENTIFIER_PRESENT" redefined /home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:434:1: warning: this is the location of the previous definition /home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:437:1: warning: "RANAP_ENHANCEDRELOCATIONINFORMATIONREQUESTIES_RANAP_GLOBALCN_ID_PRESENT" redefined /home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:435:1: warning: this is the location of the previous definition In file included from /home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_common.h:592, from /home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:7, from iu.c:26: /home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:856: error: redefinition of typedef 'RANAP_RAB_SetupOrModifiedItemIEs_t' ../../include/openbsc/iu.h:8: note: previous declaration of 'RANAP_RAB_SetupOrModifiedItemIEs_t' was here In file included from iu.c:31: /home/builder/coverity/install-iuh/include/asn1c/asn1helpers.h: In function 'OCTET_STRING_noalloc': /home/builder/coverity/install-iuh/include/asn1c/asn1helpers.h:26: warning: assignment discards qualifiers from pointer target type iu.c: In function 'ranap_handle_co_rab_ass_resp': iu.c:273: warning: implicit declaration of function 'ranap_free_rab_setupormodifieditemies' make[3]: *** [iu.o] Error 1 make[3]: Leaving directory `/home/builder/coverity/source-iuh/openbsc/openbsc/src/libiu' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/builder/coverity/source-iuh/openbsc/openbsc/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/builder/coverity/source-iuh/openbsc/openbsc' make: *** [all] Error 2
branches used:
asn1c * aper-prefix layer1-api * master libasn1c * master libosmo-abis * master libosmo-dsp * master libosmo-netif * sysmocom/sctp libosmo-sccp * laforge/wip libosmocore * master libsmpp34 * master openbsc * sysmocom/iu openggsn * master osmo-bts * master osmo-gmr * master osmo-iuh * master osmo-pcu * master
Hi Neels,
On Thu, Feb 18, 2016 at 12:56:20PM +0100, Neels Hofmeyr wrote:
Reasons NOT to merge to master in:
asn1c: * aper-prefix - ?
If you look at the aper code I took from OpenAirInterface and re-based, you will see that it does not look 100% complete and would probably not yet qualify for submitting it to the upstream asn1c project. The situation is not made better by my hackish way to implement the type prefixing on top of it by means of an environment variable.
Specifically, it * contains commented-out code which might just have been a work-around of some buggy code, rather than fit for removal in general * contains TODO comments like "/* TODO: act upon NOTE in #18.7 for canonical PER */" which hints that it is not properly implementing parts of the PER specification * contrary to the rest of asn1c, it does not come with a comprehensive test suiet for the APER encoding and decoding routines of all types
Any help in cleaning this code up (it could be done for the type prefixing independent of the APER support) would be much appreciated. The goal is to get this merged in asn1c, after all.
It might also be worth to contact the OpenAirInterface guys about their thoughts on moving this code forward. I fear there might be none, as they are using an ancient version of asn1c to begin with. But they are a much larger project and might be convinced to put some resources on doing this properly?
Unless we think something is ready for pushing to upstream asn1c, we should keep it out of our local master, too.
libosmo-netif: * sysmocom/sctp - ?
I pushed one of the two commits to master.
However, commit 89118114972d587f623305e410d45eb934900e81 basically just prints some messages to the log file in case there are association state changes like UP and LOST. This is clearly not the intended behavior.
The application should be notified accordintly in such events, particularly in 'connection lost' events that can be communicated in the same way as they can for e.g. TCP sockets.
Only after that is resolved, we can merge it to master.
libosmo-sccp: * laforge/wip - ?
My main problem with this patch set is naming. We are creating an 'SCCP User SAP' which should look the same no matter what the underlying transport protocol stacking is. Whether it's SUA/SCTP/IP or SCCP/M3UA/SCTP/IP or SCCP/MTP3/M2UA/SCTP/IP or SCCP/MTP3/MTP2/E1 or SCCP/MTP3/MTP2/M2PA/SCTP/IP should not matter to the application.
The sccp_sap.h data structures still follow that rule. However the sua.h code (creating a SUA client or server, 'struct osmo_sua_user / struct osmo_sua_link' directly reference SUA.
In terms of the function names I don't care really too much, as inevitably an application will somehow need to specify the protocol stacking it would like to use. Either explicitly or implicitly via system-level configuration of the signalling stack.
However, the application should not have to keep an 'osmo_sua_user' pointer or an 'osmo_sua_link' pointer in its own data structures. It should be an opaque osmo_sccp_user / osmo_sccp_link structure, so once we change from one underlying stacking to another, the data structures of the application do not have to change.
Thanks for the detailed reasoning!
~Neels
On Fri, Feb 19, 2016 at 09:35:19AM +0100, Harald Welte wrote: [...]
-
Harald Welte -
Holger Freyther -
Neels Hofmeyr