OpenBSC January 2019

openbsc@lists.osmocom.org

25 participants
55 discussions

Enable / disable of a bts / trx
by Gullik Webjorn 26 Jan '19

26 Jan '19

Hi, What is the best practice to enable / disable a single bts / trx in a multi trx configuration? Just stopping it, phones settle after some time, but I get a lot of timeouts in syslog. So, for service / reconfig purposes, how do I disable a single (remote ) bts from the BSC side? ( without making a temporary config file and restarting ? ) Gullik

2 1

Osmo metrics and counters
by Omar Ramadan 26 Jan '19

26 Jan '19

I've been investigating the availability of KPIs on the control interfaces. Is there a way to enumerate which metrics and counters exist? What would be the best way to do so? Thinking it would be a useful to add a list function to add to the VTY and/or the CTRL interface itself.

3 3

TOA loop / reporting
by Sylvain Munaut 26 Jan '19

26 Jan '19

Hi, I've been digging into the TOA loop and reporting code and I'm a bit confused as to why some things are done the way they are now. So if anyone has insights or if I misread anything. AFAICT the toa values are accumulated at two places (at the L1 level) : - chan_state->meas.toa_* : This is used for the TA loop that sends the requested TA to the MS. This is called _only_ for SACCH bursts. - chan_state->toa_* : This is used to send the average TOA value to L2 in the Measurement Info ( call to l1if_process_meas_res ) * First confusing thing is the one in the 'meas' struct is actually _not_ the one used for measurements info. * Why are only SAACH TOA values used for the TA regulation loop ? Is there a spec somewhere that says to ignore the TOA of the other burst types ? * Why is there two way of keeping track of this in the first place ? tbh, I'm a bit confused as to why L2 needs that info at all. There is this "MS timing offset" but I don't exactly see why the MS needs this at all, it can't act on it anyway and should tend to zero. Then this is used to report in RSL which I guess is useful for debugging. If I'm reading https://projects.osmocom.org/projects/osmobts/wiki/Timing_Advance correctly, the way I see things : * We should keep track of the TOA of every bursts we receive (no matter where it comes from) * Then when we get a full SACCH set, we can : - know which TA the MS was using for all those bursts we accumulated. Knowing the TA it used, the TA we requested and the average TOA of all those bursts, we can update the requested TA. - At this point we can also clear all those counters and start the cycle again. Now, it appears that the upper layer wants to do more advanced stats, so basically every burst info would also generate a measurement info from L1 to L2 and L2 would do it's own summing / stats independently of L1. Although I guess at this point, this would be done at each L2 packet rather than each burst because some other info is included in those reports (like BER) which are only available by packet and not per bursts. Cheers, Sylvain

2 1

New osmocom CNI versions released
by Harald Welte 25 Jan '19

25 Jan '19

Hi! Just in case not every subscriber here is following the osmocom.org RSS feed: At http://osmocom.org/news/104 we have just announced a bunch of new tagged versions of the Osmocom CNI (cellular network infrastructure) software stack. See the link above for all related details, and links to changelogs. The "network:osmocom:latest" feed already contains builds for Debian 8 and 9, as well as Ubuntu 16.04, 16.10, 17.04, 17.10 and 18.04. Raspbian 9 + Ubuntu 18.10 are currently building, see https://build.opensuse.org/project/monitor/network:osmocom:latest I'd like to thank everyone who has contributed in some way to those new versions. That's primarily the great team of developers, but also everyone helping with testing, bug reports, bug squashing, documentation, etc. Happy hacking, Harald -- - Harald Welte <hwelte(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 * Geschaeftsfuehrer / Managing Director: Harald Welte

1 0

Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #366
by jenkins＠lists.osmocom.org 23 Jan '19

23 Jan '19

See <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/366/display/redire…> ------------------------------------------ [...truncated 686.45 KB...] CC RANAP_MBMSHCIndicator.lo CC RANAP_MBMSIPMulticastAddressandAPNRequest.lo CC RANAP_MBMSLinkingInformation.lo CC RANAP_MBMSRegistrationRequestType.lo CC RANAP_MBMSServiceArea.lo CC RANAP_MBMSSessionDuration.lo CC RANAP_MBMSSessionIdentity.lo CC RANAP_MBMSSessionRepetitionNumber.lo CC RANAP_MDT-Activation.lo CC RANAP_MDTAreaScope.lo CC RANAP_MDT-Configuration.lo CC RANAP_MDTMode.lo CC RANAP_MDT-PLMN-List.lo CC RANAP_MDT-Report-Parameters.lo CC RANAP_MeasurementsToActivate.lo CC RANAP_MeasurementQuantity.lo CC RANAP_MSISDN.lo CC RANAP_NAS-PDU.lo CC RANAP_NAS-SequenceNumber.lo CC RANAP_NAS-SynchronisationIndicator.lo CC RANAP_NewBSS-To-OldBSS-Information.lo CC RANAP_NonSearchingIndication.lo CC RANAP_NRTLoadInformationValue.lo CC RANAP_NumberOfIuInstances.lo CC RANAP_NumberOfSteps.lo CC RANAP_Offload-RAB-Parameters.lo CC RANAP_Offload-RAB-Parameters-APN.lo CC RANAP_Offload-RAB-Parameters-ChargingCharacteristics.lo CC RANAP_OldBSS-ToNewBSS-Information.lo CC RANAP_OMC-ID.lo CC RANAP_Out-Of-UTRAN.lo CC RANAP_PagingAreaID.lo CC RANAP_PagingCause.lo CC RANAP_PDP-TypeInformation.lo CC RANAP_PDP-Type.lo CC RANAP_PDP-TypeInformation-extension.lo CC RANAP_PDP-Type-extension.lo CC RANAP_PDUType14FrameSequenceNumber.lo CC RANAP_PeriodicLocationInfo.lo CC RANAP_PermanentNAS-UE-ID.lo CC RANAP_PermittedEncryptionAlgorithms.lo CC RANAP_PermittedIntegrityProtectionAlgorithms.lo CC RANAP_LABased.lo CC RANAP_LAI-List.lo CC RANAP_LoggedMDT.lo CC RANAP_LoggingInterval.lo CC RANAP_LoggingDuration.lo CC RANAP_PLMNidentity.lo CC RANAP_PLMNs-in-shared-network.lo CC RANAP_Port-Number.lo CC RANAP_PositioningDataDiscriminator.lo CC RANAP_PositioningDataSet.lo CC RANAP_PositioningMethodAndUsage.lo CC RANAP_PositioningPriority.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:14, from RANAP_PLMNs-in-shared-network.c:7: ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:23: warning: ‘struct MemberA’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberA { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberA { ^~~~~~~~~~~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:23: warning: ‘struct MemberM’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberM { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberM { ^~~~~~~~~~~~~ CC RANAP_PositionData.lo CC RANAP_PositionDataSpecificToGERANIuMode.lo CC RANAP_Pre-emptionCapability.lo CC RANAP_Pre-emptionVulnerability.lo CC RANAP_PriorityLevel.lo CC RANAP_Priority-Class-Indicator.lo CC RANAP_ProvidedData.lo CC RANAP_P-TMSI.lo CC RANAP_QueuingAllowed.lo CC RANAP_RAB-AsymmetryIndicator.lo CC RANAP_RABased.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:14, from ../../include/osmocom/ranap/RANAP_Shared-Network-Information.h:14, from ../../include/osmocom/ranap/RANAP_ProvidedData.h:14, from RANAP_ProvidedData.c:7: ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:23: warning: ‘struct MemberA’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberA { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberA { ^~~~~~~~~~~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:23: warning: ‘struct MemberM’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberM { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberM { ^~~~~~~~~~~~~ CC RANAP_RAI-List.lo CC RANAP_RABDataVolumeReport.lo CC RANAP_RAB-ID.lo CC RANAP_RAB-Parameter-ExtendedGuaranteedBitrateList.lo CC RANAP_RAB-Parameter-ExtendedMaxBitrateList.lo CC RANAP_RAB-Parameter-GuaranteedBitrateList.lo CC RANAP_RAB-Parameter-MaxBitrateList.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:14, from RANAP_RABDataVolumeReport.c:7: ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:23: warning: ‘struct MemberN’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberN { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberN { ^~~~~~~~~~~~~ CC RANAP_RAB-Parameters.lo CC RANAP_RABParametersList.lo CC RANAP_RAB-SubflowCombinationBitRate.lo CC RANAP_RAB-TrCH-Mapping.lo CC RANAP_RAB-TrCH-MappingItem.lo CC RANAP_RAC.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_RABParametersList.h:14, from RANAP_RABParametersList.c:7: ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:23: warning: ‘struct MemberN’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberN { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberN { ^~~~~~~~~~~~~ In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_RABParametersList.h:14, from RANAP_RABParametersList.c:7: ../../include/osmocom/ranap/RANAP_RABParametersList.h:29:23: warning: ‘struct MemberB’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberB { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_RABParametersList.h:29:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberB { ^~~~~~~~~~~~~ CC RANAP_RAI.lo CC RANAP_RAListofIdleModeUEs.lo CC RANAP_NotEmptyRAListofIdleModeUEs.lo CC RANAP_RAofIdleModeUEs.lo CC RANAP_LAListofIdleModeUEs.lo CC RANAP_RAT-Type.lo CC RANAP_RateControlAllowed.lo CC RANAP_RedirectAttemptFlag.lo CC RANAP_RedirectionCompleted.lo CC RANAP_RejectCauseValue.lo CC RANAP_RelocationRequirement.lo CC RANAP_RelocationType.lo CC RANAP_RepetitionNumber0.lo CC RANAP_RepetitionNumber1.lo CC RANAP_ReportArea.lo CC RANAP_ReportInterval.lo CC RANAP_ReportAmount.lo CC RANAP_RequestedGPSAssistanceData.lo CC RANAP_RequestedGANSSAssistanceData.lo CC RANAP_RequestedLocationRelatedDataType.lo CC RANAP_RequestedMBMSIPMulticastAddressandAPNRequest.lo CC RANAP_MBMSIPMulticastAddressandAPNlist.lo CC RANAP_RequestedMulticastServiceList.lo CC RANAP_Requested-RAB-Parameter-Values.lo CC RANAP_Requested-RAB-Parameter-ExtendedMaxBitrateList.lo CC RANAP_Requested-RAB-Parameter-ExtendedGuaranteedBitrateList.lo CC RANAP_Requested-RAB-Parameter-MaxBitrateList.lo CC RANAP_Requested-RAB-Parameter-GuaranteedBitrateList.lo CC RANAP_RequestType.lo CC RANAP_ResidualBitErrorRatio.lo CC RANAP_ResponseTime.lo CC RANAP_RIMInformation.lo CC RANAP_RIM-Transfer.lo CC RANAP_RIMRoutingAddress.lo CC RANAP_RNC-ID.lo CC RANAP_RNCTraceInformation.lo CC RANAP_RNSAPRelocationParameters.lo CC RANAP_RRC-Container.lo CC RANAP_RTLoadValue.lo CC RANAP_RSRVCC-HO-Indication.lo CC RANAP_RSRVCC-Information.lo CC RANAP_RSRVCC-Operation-Possible.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_RABParametersList.h:14, from ../../include/osmocom/ranap/RANAP_RNSAPRelocationParameters.h:14, from RANAP_RNSAPRelocationParameters.c:7: ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:23: warning: ‘struct MemberN’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberN { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberN { ^~~~~~~~~~~~~ In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_RABParametersList.h:14, from ../../include/osmocom/ranap/RANAP_RNSAPRelocationParameters.h:14, from RANAP_RNSAPRelocationParameters.c:7: ../../include/osmocom/ranap/RANAP_RABParametersList.h:29:23: warning: ‘struct MemberB’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberB { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_RABParametersList.h:29:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberB { ^~~~~~~~~~~~~ /bin/bash: line 1: 21336 Segmentation fault /bin/bash ../../libtool --silent --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.4.0\" -DPACKAGE_STRING=\"osmo-iuh\ 0.4.0\" -DPACKAGE_BUGREPORT=\"openbsc(a)lists.osmocom.org\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"osmo-iuh\" -DVERSION=\"0.4.0\" -DSTDC_HEADERS=1 -I. -Wall -I../../include -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -g -O2 -Wall -MT RANAP_RSRVCC-Operation-Possible.lo -MD -MP -MF .deps/RANAP_RSRVCC-Operation-Possible.Tpo -c -o RANAP_RSRVCC-Operation-Possible.lo RANAP_RSRVCC-Operation-Possible.c Makefile:2506: recipe for target 'RANAP_RSRVCC-Operation-Possible.lo' failed make[4]: *** [RANAP_RSRVCC-Operation-Possible.lo] Error 139 make[4]: *** Waiting for unfinished jobs.... make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src/ranap' Makefile:642: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src' Makefile:454: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src' Makefile:458: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh' Makefile:382: recipe for target 'all' failed make: *** [all] Error 2 [WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully. Emitted 1278 C/C++ compilation units (100%) successfully 1278 C/C++ compilation units (100%) are ready for analysis For more details, please look at: /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt Build step 'Execute shell' marked build as failure

1 1

msgb_wrap_with_TL(): the hallmark of wrong choices made
by Neels Hofmeyr 23 Jan '19

23 Jan '19

I think we all agree that what happened with the msgb_wrap_with_TL() is a prime example about how absolutely *not* to do things. This makes me want to rewrite libosmocore history. After all the naming / API duplication mistakes around msgb_wrap_with_TL(), the final state I am trying to finish my day to is that the osmo-msc and openbsc master builds remain broken, while patches to fix that are idling on gerrit with a commit log summary that mentions neither that they fix the build nor that they are related to msgb_wrap_with_TL(). All this happens with a new release tag on libosmocore, which was tagged to include a commit that is supposed to fix things instead of break them... Let's try to avoid this kind of series of events in the future. * Separate function definitions must not have identical names. * This applies both to the master HEADs as well as throughout entire API history. * Especially functions moved to another source tree *must* change their name. * Such API changes in libosmocore should be tested with "all" depending programs. * API fixes in libosmocore should ideally build with both past and future versions of depending source trees, i.e. should not need a matching patch in the other source trees. * When a commit breaks the master build in depending programs, * clearly mark that so in the commit log and/or gerrit comments, so it is not merged on its own by accident. * the author should not go away until either none or both of them are merged. * Similarly obvious, avoid pouring water on burning oil. Sure, we all make mistakes every now and then. In this case we made a few more :P I spent time now to merge fixes to the master builds instead of going to sleep... (I hope I'm not adding mistakes to the minefield, though.) Not sure what to do about osmocom-bb. It has lots of implicit function definition warnings, only one of them is: gsm480_ss.c:441:3: warning: implicit declaration of function ‘msgb_wrap_with_TL’ ~N

2 3

OS#3764: backward compatibility: It's not just API
by Harald Welte 22 Jan '19

22 Jan '19

I've been investigating today what is the cause of build failures like this: https://build.opensuse.org/package/live_build_log/network:osmocom:latest/os… where "make check" suddenly fails with things like [ 80s] -==> got signal NS_UNBLOCK, NS-VC 0x2001/1.2.3.4:1111 [ 80s] - [ 80s] MESSAGE to BSS at 0x01020304:1111, msg length 1 [ 80s] 07 [ 80s] [ 80s] +==> got signal NS_UNBLOCK, NS-VC 0x2001/1.2.3.4:1111 [ 80s] + [ 80s] result (UNBLOCK) = 1 as the diff. So clearly some re-ordering happening here. This appears when building the "latest" osmo-sgsn version (1.3.0) against a current libosmocore. As libosmocore remains API compatible, this is building fine, as expected. However, ther is commit commit 797558ea1768e464f9559c5f7a4f3f4285c5de25 Author: Stefan Sperling <ssperling(a)sysmocom.de> Date: Mon Nov 19 17:18:41 2018 +0100 send NS_POUT_UNBLOCK_ACK before signalling S_NS_UNBLOCK In gprs_ns_process_msg(), we were dispatching the S_NS_UNBLOCK signal before sending out the NS_POUT_UNBLOCK_ACK message. Signal handlers might send messages to the other side, assuming that NS is now unblocked. However, since such messages will arrive before the UNBLOCK_ACK message the receiver might discard them. This problem has been observed with our TTCN3 BSSGP_Emulation as a peer to osmo-pcu. This patch makes TTCN3 PCU TC_paging() test pass regardless of whether the test or osmo-pcu is started first. Before this patch, this test would only pass if the test was started before osmo-pcu. A remaining problem is that the test does not yet keep passing reliably unless osmo-pcu is restarted between test runs. Change-Id: I3af54a14bb6bcfa167c9a9d9f67835e7f5b9f1bb Related: OS#2890 Related: OS#2388 which is a fix, and is appreciated. However, it causes breakage, at least in unit tests that rely on testing the old behavior, such as the gbproxy test. This immediately showed up, and one day later we have the following commit commit eefb70df2c6aa7b1362d5e8decf52af3ff95ecb9 Author: Stefan Sperling <ssperling(a)sysmocom.de> Date: Tue Nov 20 11:33:17 2018 +0100 update gbproxy test expected output libosmocore commit 797558ea1768e464f9559c5f7a4f3f4285c5de25 changed the order of NS_UNBLOCK_ACK transmission dispatching of the NS_UNBLOCK signal. Update expected output of gbproxy tests accordingly to make these tests pass again. Change-Id: Ia3df811755b1c88cf7a27a466677b24a6c32fd8e Related: OS#2388 which is making sure the test passes from now onwards, but which of course doesn't do anything about older, already-released versions of osmo-sgsn, which will all fail to pass "make check" - forever. There may be people who want to rely on older versions of osmo-sgsn in the future, and they will think they have non-working software if "make check" doesn't pass :/ So what do we take from this? Be careful with changing existing library code semantics. Even if the function signature is not modified, there are existing applications and/or test cases that make assumptions. And we should not break those assumptions. If something like this shows up ever again, I think the correct approach is to 1) keep the old semantics as it is, making sure that old applications/tests will continue to work/pass, even on modern library versions or master of the day 2) introduce a new function/symbol implementing the new semantics. Or, in this case (as it's some library-internal function dispatching events/signals), probably some kind of flag is needed. New code, depending on new library versions, may then set that flag and elicit the new behavior, while old code gets the old behavior. Please let's make sure we don't fall into the same trap in the future again. The process of avoiding this can be helped by having automatic build testing of old/previous applications against "master of the day" of the libraries. Let's track the latter in #3765. Happy hacking, 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

Problems installing libosmocore / gr-gsm on my Mac
by Andrea Pellegrin 22 Jan '19

22 Jan '19

Hi, I really hope you can help me, I’m trying this for 10h. I’m following your instruction: https://osmocom.org/projects/gr-gsm/wiki/Installation https://osmocom.org/projects/libosmocore/wiki/Libosmocore Installing gr-gsm I stay still at cmake .., for libosmocore (No package 'libosmocoding' found) So I try to install libosmocore, everything work up to make command. Infact give a lot of error, here: Air-di-Andrea:libosmocore andreapellegrin$ make /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive Making all in include /Applications/Xcode.app/Contents/Developer/usr/bin/make all-am make[3]: Nothing to be done for `all-am'. Making all in src /Applications/Xcode.app/Contents/Developer/usr/bin/make all-am CC timer_clockgettime.lo timer_clockgettime.c:78:7: error: use of undeclared identifier 'CLOCK_REALTIME_COARSE' case CLOCK_REALTIME_COARSE: ^ timer_clockgettime.c:82:7: error: use of undeclared identifier 'CLOCK_MONOTONIC_COARSE'; did you mean '_CLOCK_MONOTONIC_RAW'? case CLOCK_MONOTONIC_COARSE: ^~~~~~~~~~~~~~~~~~~~~~ _CLOCK_MONOTONIC_RAW /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/time.h:158:1: note: '_CLOCK_MONOTONIC_RAW' declared here _CLOCK_MONOTONIC_RAW __CLOCK_AVAILABILITY = 4, ^ timer_clockgettime.c:86:7: error: use of undeclared identifier 'CLOCK_BOOTTIME'; did you mean '_CLOCK_REALTIME'? case CLOCK_BOOTTIME: ^~~~~~~~~~~~~~ _CLOCK_REALTIME /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/time.h:153:1: note: '_CLOCK_REALTIME' declared here _CLOCK_REALTIME __CLOCK_AVAILABILITY = 0, ^ timer_clockgettime.c:86:7: error: duplicate case value '_CLOCK_REALTIME' case CLOCK_BOOTTIME: ^ timer_clockgettime.c:76:7: note: previous case defined here case CLOCK_REALTIME: ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/time.h:154:24: note: expanded from macro 'CLOCK_REALTIME' #define CLOCK_REALTIME _CLOCK_REALTIME ^ timer_clockgettime.c:84:7: error: duplicate case value '_CLOCK_MONOTONIC_RAW' case CLOCK_MONOTONIC_RAW: ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/time.h:159:29: note: expanded from macro 'CLOCK_MONOTONIC_RAW' #define CLOCK_MONOTONIC_RAW _CLOCK_MONOTONIC_RAW ^ timer_clockgettime.c:82:7: note: previous case defined here case CLOCK_MONOTONIC_COARSE: ^ 5 errors generated. make[3]: *** [timer_clockgettime.lo] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Air-di-Andrea:libosmocore andreapellegrin$ I’m really desperate, hoping you can help me! Really thanks. Andrew

3 2

Scaling up virtual bts tests for the BTS test - how I hold it wrong?
by Holger Freyther 22 Jan '19

22 Jan '19

After a lot of work[1] the gsm tester can finally: * Start a virtual bts * Mobile/virtphy processes * Complete LUs for 10 MS. The next step (besides having a proper test verdict) is scaling this beyond what a simple physical set-up can provide. Let's go to 100+ BTS and 10k subscribers but somehow I am still holding it wrongly and would like to have feedback to see how to evolve the gsm tester. What do I need to change to scale this up and how to externally parameterize it? * suite.conf: Add one line per virtual bts to reserve (I would prefer to specify type+num) * resources.prod.conf: Add more Virtual BTS. I started to pick IPs from 127.0.1.0/24 as it avoids having to configure special IPs. * register_default_mass.py: I need to somehow know how many BTS (and NITBs) were reserved. Or in the long run the topology of how to connect M BTS to N BSCs? Currently I can run until I get an exception but that is not desirable. What's missing: * High-level API of the SuiteRun to get me the toplogy of the network. It seems undesirable in the specific suite to discover how many BTSs were reserved in suite.conf or what the topology is. * ARFCN usage. Besides the redundancy all my BTS currently have the same ARFCN. There should be an easy way to configure an band+arfcn pool. * IMSI/MSISDN pooling. I would like to specify pools of IMSI/MSISDN pairs (and size) and then draw from it. I needs these to program into the mobile, NITB/HLR/AuC and for client to client SMS transfers. * Configure these capacities from the outside. Changing from 1 to 256 BTS should be a single line (or even a parameter change). Any idea or comment on how to achieve this? cheers holger [1] Hindsight is 20/20 and the difficulty was not adding scripting to mobile but getting the GSM tester to spawn the network and we are unfortunately not done yet.

2 5

tagging new versions / problems
by Harald Welte 21 Jan '19

21 Jan '19

Hi! I've been looking at tagging new versions of our libraries. I know Pau in the past already used the abi-{dumper,tracer,...} toolkit, but I couldn't find any instructions about it, nor has it been automatized it seems. I've now started with this and have a setup that we can run nightly to generate ABI/API compatibility reports. There are unfortunately some issues in libosmogsm: http://people.osmocom.org/laforge/abi-report/compat_report/libosmocore/0.12… related to LCLS changes that (I believe) were mostly introduced by Max. gsm0808_cause_name() changes the size of the argumetn from uint8_t to an 'int' that may be 32/64bit in size :( That breaks ABI, so we need to bump soversion, or revert that change. As the gsup changes require a version bump anyway, we should be fine. gsm0808_create_lcls_conn_ctrl() has changed its argument type. Are we sure there were no users of the function? The old signature was part of the previous release! In libosmocore we have some problem related to 'struct log_target': http://people.osmocom.org/laforge/abi-report/compat_report/libosmocore/0.12… I suppose this is "only" ABI breakage but not API breakage and hence a new libversion can rescue us? In libgtp we also have changes requiring a libveersion change: http://people.osmocom.org/laforge/abi-report/compat_report/osmo-ggsn/1.2.2/… Apart from that, it looks quite fine. libosmo-sigtran has two new symbols, but remains fully backwwards compatible: http://people.osmocom.org/laforge/abi-report/compat_report/libosmo-sccp/0.1… Feel free to comment. The most important part is to get the libosmocore/LCLS questions resolved. 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)

3 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2019