From jenkins at lists.osmocom.org Tue Jan 1 02:23:28 2019 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Tue, 1 Jan 2019 02:23:28 +0000 (UTC) Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #345 Message-ID: <1586170007.365.1546309408672.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 682.86 KB...] ^~~~ ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct MemberA { ^~~~~~~~~~~~~ CC RANAP_ListOF-SNAs.lo CC RANAP_ListOfInterfacesToTrace.lo CC RANAP_InterfacesToTraceItem.lo CC RANAP_LoadValue.lo CC RANAP_LocationRelatedDataRequestType.lo CC RANAP_LocationRelatedDataRequestTypeSpecificToGERANIuMode.lo CC RANAP_LocationReportingTransferInformation.lo CC RANAP_ReportChangeOfSAI.lo CC RANAP_PeriodicReportingIndicator.lo CC RANAP_DirectReportingIndicator.lo CC RANAP_L3-Information.lo CC RANAP_M1Report.lo CC RANAP_M2Report.lo CC RANAP_M4Report.lo CC RANAP_M4-Collection-Parameters.lo CC RANAP_M4-Period.lo CC RANAP_M4-Threshold.lo CC RANAP_M5Report.lo CC RANAP_M5-Period.lo CC RANAP_M6Report.lo CC RANAP_M6-Period.lo CC RANAP_M7Report.lo CC RANAP_M7-Period.lo CC RANAP_Management-Based-MDT-Allowed.lo CC RANAP_MaxBitrate.lo CC RANAP_MaxSDU-Size.lo CC RANAP_MBMS-PTP-RAB-ID.lo CC RANAP_MBMSBearerServiceType.lo CC RANAP_MBMSCNDe-Registration.lo CC RANAP_MBMSCountingInformation.lo 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_MeasurementQuantity.lo CC RANAP_MeasurementsToActivate.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_PositioningMethodAndUsage.lo CC RANAP_PositioningDataSet.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_PositioningPriority.lo 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 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_RABased.lo 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 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_RAC.lo 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_ResponseTime.lo CC RANAP_ResidualBitErrorRatio.lo CC RANAP_RIMInformation.lo CC RANAP_RIM-Transfer.lo CC RANAP_RIMRoutingAddress.lo /bin/bash: line 1: 16651 Segmentation fault /bin/bash ../../libtool --silent --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.13-45696\" -DPACKAGE_STRING=\"osmo-iuh\ 0.3.0.13-45696\" -DPACKAGE_BUGREPORT=\"openbsc at 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.3.0.13-45696\" -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_ResponseTime.lo -MD -MP -MF .deps/RANAP_ResponseTime.Tpo -c -o RANAP_ResponseTime.lo RANAP_ResponseTime.c Makefile:2506: recipe for target 'RANAP_ResponseTime.lo' failed make[4]: *** [RANAP_ResponseTime.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 1261 C/C++ compilation units (100%) successfully 1261 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 From jenkins at lists.osmocom.org Wed Jan 2 02:30:04 2019 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Wed, 2 Jan 2019 02:30:04 +0000 (UTC) Subject: Jenkins build is back to normal : Coverity-Upload (jenkins-job-builder) #346 In-Reply-To: <1586170007.365.1546309408672.JavaMail.jenkins@jenkins.osmocom.org> References: <1586170007.365.1546309408672.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <1571604319.381.1546396204735.JavaMail.jenkins@jenkins.osmocom.org> See From keith at rhizomatica.org Wed Jan 2 12:11:14 2019 From: keith at rhizomatica.org (Keith) Date: Wed, 2 Jan 2019 13:11:14 +0100 Subject: 35c3 feedback Message-ID: <2b0d858f-4117-ac80-4e80-36fdfd6be101@rhizomatica.org> Hi all. 1) SIP Connector handling of TON GSM340_TYPE_INTERNATIONAL Apparently at least one person was frustrated at the congress by not being able to call out using the numbers stored in their GSM handset using the form +CountryCode. As we know this appears at Call Control with TON intl, which sip connector then prefixes with '+' before sending to SIP The reason for lack of service at ccc was that the Yate pbx does not support this number scheme and needed the 00 prefix. This would have been trivial to patch had we known, and it prompts me to think this should probably be implemented as a runtime config option in sip section 'tonintl prefix' or some such? It would seem correct for it to be restricted to the set of either '00' or '+', no other options really makes sense, not even "no prefix". right? 2) 3G data instabilities ( Just a quick observation note, no pcap! ) I happened to notice that pinging a 3G handset from the network side (default ping: 1 sec internal, 64 ICMP bytes) keeps the connection "alive" and using 3G data is then a pleasant experience, IM, email, browsing, SIP call all working nicely. peak max download speed of 16Mbps was reported at one time by m.speedof.me However, stopping the ping results in loss of data conex within a few seconds, and the behaviour from users point of view is then strikingly similar to what's observed on 2G; and I am more or less convinced has to do with the unknown Timing Advance issues in the PCU. So I thought I'd note it down here.? k/ From msuraev at sysmocom.de Wed Jan 2 12:46:31 2019 From: msuraev at sysmocom.de (Max) Date: Wed, 2 Jan 2019 13:46:31 +0100 Subject: 35c3 feedback In-Reply-To: <2b0d858f-4117-ac80-4e80-36fdfd6be101@rhizomatica.org> References: <2b0d858f-4117-ac80-4e80-36fdfd6be101@rhizomatica.org> Message-ID: Hi. Thanks for write-up. Comments are inline below, here's another (unrelated) issue observed during 35c3: https://osmocom.org/issues/3741 02.01.19 13:11, Keith ?????: > 1) SIP Connector handling of TON GSM340_TYPE_INTERNATIONAL > > Apparently at least one person was frustrated at the congress by not > being able to call out using the numbers stored in their GSM handset > using the form +CountryCode. > > As we know this appears at Call Control with TON intl, which sip > connector then prefixes with '+' before sending to SIP > > The reason for lack of service at ccc was that the Yate pbx does not > support this number scheme and needed the 00 prefix. The *+12345... format is defined in **ITU-T E.123 so the lack of support for this format looks like a bug in Yate.* *What about 00 prefix? Unless it's defined in some spec, I don't think it make sense to introduce options just to work around bug in particular PBX. * > 2) 3G data instabilities > > ( Just a quick observation note, no pcap! ) > > I happened to notice that pinging a 3G handset from the network side > (default ping: 1 sec internal, 64 ICMP bytes) keeps the connection > "alive" and using 3G data is then a pleasant experience, IM, email, > browsing, SIP call all working nicely. peak max download speed of 16Mbps > was reported at one time by m.speedof.me > > However, stopping the ping results in loss of data conex within a few > seconds, and the behaviour from users point of view is then strikingly > similar to what's observed on 2G; and I am more or less convinced has to > do with the unknown Timing Advance issues in the PCU. Is there bug for this already? If both 2G and 3G have similar issues in the absence of MT traffic than there might be something wrong in the core components (SGSN/GGSN?). -- - Max Suraev 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 Directors: Harald Welte From djks74 at gmail.com Wed Jan 2 13:13:17 2019 From: djks74 at gmail.com (Sandi Suhendro) Date: Wed, 2 Jan 2019 20:13:17 +0700 Subject: 35c3 feedback In-Reply-To: References: <2b0d858f-4117-ac80-4e80-36fdfd6be101@rhizomatica.org> Message-ID: + country code using osmo-sip-connector is fine with asterisk pbx for osmocom stacks for me. regards, Sandi / DUO On Wed, Jan 2, 2019, 19:47 Max Hi. > > Thanks for write-up. > > Comments are inline below, here's another (unrelated) issue observed > during 35c3: https://osmocom.org/issues/3741 > > 02.01.19 13:11, Keith ?????: > > 1) SIP Connector handling of TON GSM340_TYPE_INTERNATIONAL > > > > Apparently at least one person was frustrated at the congress by not > > being able to call out using the numbers stored in their GSM handset > > using the form +CountryCode. > > > > As we know this appears at Call Control with TON intl, which sip > > connector then prefixes with '+' before sending to SIP > > > > The reason for lack of service at ccc was that the Yate pbx does not > > support this number scheme and needed the 00 prefix. > > The *+12345... format is defined in **ITU-T E.123 so the lack of support > for this format looks like a bug in Yate.* > > *What about 00 prefix? Unless it's defined in some spec, I don't think > it make sense to introduce options just to work around bug in particular > PBX. > * > > > 2) 3G data instabilities > > > > ( Just a quick observation note, no pcap! ) > > > > I happened to notice that pinging a 3G handset from the network side > > (default ping: 1 sec internal, 64 ICMP bytes) keeps the connection > > "alive" and using 3G data is then a pleasant experience, IM, email, > > browsing, SIP call all working nicely. peak max download speed of 16Mbps > > was reported at one time by m.speedof.me > > > > However, stopping the ping results in loss of data conex within a few > > seconds, and the behaviour from users point of view is then strikingly > > similar to what's observed on 2G; and I am more or less convinced has to > > do with the unknown Timing Advance issues in the PCU. > > Is there bug for this already? If both 2G and 3G have similar issues in > the absence of MT traffic than there might be something wrong in the > core components (SGSN/GGSN?). > > -- > - Max Suraev 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 Directors: Harald Welte > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith at rhizomatica.org Wed Jan 2 13:54:55 2019 From: keith at rhizomatica.org (Keith) Date: Wed, 2 Jan 2019 14:54:55 +0100 Subject: 35c3 feedback In-Reply-To: References: <2b0d858f-4117-ac80-4e80-36fdfd6be101@rhizomatica.org> Message-ID: <3167850e-9c59-2b3d-fe39-22fcc738524e@rhizomatica.org> On 02/01/2019 13:46, Max wrote: > Hi. > > > 02.01.19 13:11, Keith ?????: > > The *+12345... format is defined in **ITU-T E.123 so the lack of > support for this format looks like a bug in Yate.* > > *What about 00 prefix? Unless it's defined in some spec, I don't think > it make sense to introduce options just to work around bug in > particular PBX. > * > It's probably not a BUG as such, but rather a (lack of) implementation in the configured dialplan. I'm not so familiar with YATE, but I would imagine it is probably something that would have also been fixed by a simple regex modification in some yate config file.? '^(+|00)' or something.. you make a good point though, and I glad I asked before submitting a patch. all the same, maybe it might be a nice thing for users to have, just as a convenience?? Without a config option, for a user faced with a non compliant upstream SIP UA over which they have no control, they would have no choice but to patch and recompile the sip connector. >> 2) 3G data instabilities >> >> >> >> I happened to notice that pinging a 3G handset from the network side >> (default ping: 1 sec internal, 64 ICMP bytes) keeps the connection >> "alive" > Is there bug for this already? If both 2G and 3G have similar issues > in the absence of MT traffic than there might be something wrong in > the core components (SGSN/GGSN?). I don't know if there's a specific issue for this as such, there are a number of issues that would seem related, but most of them filed under OsmoPCU.? I believe there is something(s) wrong in the core components, and that was indeed the local feedback I got in the GSM room.. :)) but I don't know what to file. I'd need to get 3G setup at home to contribute anything useful, hence the simple note. k/ From devifr at gmail.com Wed Jan 2 20:25:35 2019 From: devifr at gmail.com (devifr) Date: Wed, 2 Jan 2019 15:25:35 -0500 Subject: pysim-read errors Message-ID: All, I have the following error when I run pySim-read.py: Traceback (most recent call last): File "pySim-read.py", line 86, in sl = SerialSimLink(device=opts.device, baudrate=opts.baudrate) File "/home/macbook/Desktop/pyscard-1.9.7/pysim/pySim/transport/serial.py", line 45, in __init__ baudrate = baudrate, File "/home/macbook/.local/lib/python2.7/site-packages/serial/serialutil.py", line 240, in __init__ self.open() File "/home/macbook/.local/lib/python2.7/site-packages/serial/serialposix.py", line 268, in open raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg)) serial.serialutil.SerialException: [Errno 2] could not open port /dev/ttyUSB0: [Errno 2] No such file or directory: '/dev/ttyUSB0' Exception AttributeError: "'SerialSimLink' object has no attribute '_sl'" in > ignored I'm no Linux and/or Python guru but from what I can gather is that it's having issues with identifying the card reader on dev/ttyUSB0. To address that issue, I've confirmed my current card reader (identiv SCR3310) is working when I've ran the pcsc_scan script: PC/SC device scanner V 1.5.2 (c) 2001-2017, Ludovic Rousseau Using reader plug'n play mechanism Scanning present readers... 0: SCR3310 Smart Card Reader [CCID Interface] (53311828708432) 00 00 Wed Jan 2 12:02:36 2019 Reader 0: SCR3310 Smart Card Reader [CCID Interface] (53311828708432) 00 00 Card state: Card inserted, ATR: 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8 ATR: 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8 + TS = 3B --> Direct Convention + T0 = 9F, Y(1): 1001, K: 15 (historical bytes) TA(1) = 95 --> Fi=512, Di=16, 32 cycles/ETU 125000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 156250 bits/s TD(1) = 80 --> Y(i+1) = 1000, Protocol T = 0 ----- TD(2) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface bytes following ----- TA(3) = C3 --> Clock stop: no preference - Class accepted by the card: (3G) A 5V B 3V + Historical bytes: 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 Category indicator byte: 80 (compact TLV data object) Tag: 3, len: 1 (card service data byte) Card service data byte: E0 - Application selection: by full DF name - Application selection: by partial DF name - BER-TLV data objects available in EF.DIR - EF.DIR and EF.ATR access services: by GET RECORD(s) command - Card with MF Tag: 7, len: 3 (card capabilities) Selection methods: FE - DF selection by full DF name - DF selection by partial DF name - DF selection by path - DF selection by file identifier - Implicit DF selection - Short EF identifier supported - Record number supported Data coding byte: 21 - Behaviour of write functions: proprietary - Value 'FF' for the first byte of BER-TLV tag fields: invalid - Data unit in quartets: 2 Command chaining, length fields and logical channels: 13 - Logical channel number assignment: by the card - Maximum number of logical channels: 4 Tag: 5, len: 7 (card issuer's data) Card issuer data: 86 81 02 86 98 44 18 + TCK = A8 (correct checksum) Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8 GREEN CARD, Grcard (Hong Kong ) Co.,Limited, LTE Usim Card (Telecommunication) Celcom Postpaid 3G (Telecommunication) Additionally, I've ran the following command (dmesg | tail -6) to determine what path my card reader is mounted to: macbook at ubuntu:~/Desktop/pyscard-1.9.7/pysim$ dmesg | tail -n 6 [ 7079.120203] usb 3-3.1: new full-speed USB device number 6 using xhci_hcd [ 7079.223962] usb 3-3.1: New USB device found, idVendor=04e6, idProduct=5116 [ 7079.223965] usb 3-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [ 7079.223968] usb 3-3.1: Product: SCR33xx v2.0 USB SC Reader [ 7079.223969] usb 3-3.1: Manufacturer: Identive [ 7079.223971] usb 3-3.1: SerialNumber: 53311828708432 My questions are this, is there a known work around for this errors that I've posted above? Also, if my card is not mounting to dev/ttyUSB0, where do they mount to? I've looked in /mnt, /media as well as /dev....no joy. I've searched the Open BSC archives as well as scoured the web for an answer to this issue and I'm coming up blank. One last thing, I've ran this python script on an Ubuntu VM and Dual Boot. Same issue both machines. I've also tried this script with an Alcor card reader. Same output. Any help is greatly appreciated. Thanks, Derek From domi at tomcsanyi.net Wed Jan 2 22:37:17 2019 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Wed, 2 Jan 2019 23:37:17 +0100 (CET) Subject: pysim-read errors In-Reply-To: References: Message-ID: Hi Derek, Please see the help included in the program you mentioned, it answers your question. You need the -p option with the correct number (usually 0 if you only have one reader connected) to use PCSC. Cheers, Domi 2019. jan. 2. d?tummal, 21:26 id?pontban devifr ?rta: > All, > > I have the following error when I run pySim-read.py: > > Traceback (most recent call last): > > File "pySim-read.py", line 86, in > sl = SerialSimLink(device=opts.device, baudrate=opts.baudrate) > > File "/home/macbook/Desktop/pyscard-1.9.7/pysim/pySim/transport/serial.py", > line 45, in __init__ > > baudrate = baudrate, > > File "/home/macbook/.local/lib/python2.7/site-packages/serial/serialutil.py", > line 240, in __init__ > > self.open() > > File "/home/macbook/.local/lib/python2.7/site-packages/serial/serialposix.py", > line 268, in open > > raise SerialException(msg.errno, "could not open port {}: > {}".format(self._port, msg)) > > serial.serialutil.SerialException: [Errno 2] could not open port > /dev/ttyUSB0: [Errno 2] No such file or directory: '/dev/ttyUSB0' > > Exception AttributeError: "'SerialSimLink' object has no attribute > '_sl'" in > > ignored > > I'm no Linux and/or Python guru but from what I can gather is that > it's having issues with identifying the card reader on dev/ttyUSB0. > To address that issue, I've confirmed my current card reader (identiv > SCR3310) is working when I've ran the pcsc_scan script: > > PC/SC device scanner > > V 1.5.2 (c) 2001-2017, Ludovic Rousseau > > Using reader plug'n play mechanism > > Scanning present readers... > > 0: SCR3310 Smart Card Reader [CCID Interface] (53311828708432) 00 00 > > > > Wed Jan 2 12:02:36 2019 > > Reader 0: SCR3310 Smart Card Reader [CCID Interface] (53311828708432) 00 00 > > Card state: Card inserted, > > ATR: 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8 > > > ATR: 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8 > > + TS = 3B --> Direct Convention > > + T0 = 9F, Y(1): 1001, K: 15 (historical bytes) > > TA(1) = 95 --> Fi=512, Di=16, 32 cycles/ETU > > 125000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 156250 bits/s > > TD(1) = 80 --> Y(i+1) = 1000, Protocol T = 0 > > ----- > > TD(2) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface > bytes following > > ----- > > TA(3) = C3 --> Clock stop: no preference - Class accepted by the > card: (3G) A 5V B 3V > > + Historical bytes: 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 > > Category indicator byte: 80 (compact TLV data object) > > Tag: 3, len: 1 (card service data byte) > > Card service data byte: E0 > > - Application selection: by full DF name > > - Application selection: by partial DF name > > - BER-TLV data objects available in EF.DIR > > - EF.DIR and EF.ATR access services: by GET RECORD(s) command > > - Card with MF > > Tag: 7, len: 3 (card capabilities) > > Selection methods: FE > > - DF selection by full DF name > > - DF selection by partial DF name > > - DF selection by path > > - DF selection by file identifier > > - Implicit DF selection > > - Short EF identifier supported > > - Record number supported > > Data coding byte: 21 > > - Behaviour of write functions: proprietary > > - Value 'FF' for the first byte of BER-TLV tag fields: invalid > > - Data unit in quartets: 2 > > Command chaining, length fields and logical channels: 13 > > - Logical channel number assignment: by the card > > - Maximum number of logical channels: 4 > > Tag: 5, len: 7 (card issuer's data) > > Card issuer data: 86 81 02 86 98 44 18 > > + TCK = A8 (correct checksum) > > > Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): > > 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8 > > GREEN CARD, Grcard (Hong Kong ) Co.,Limited, LTE Usim Card (Telecommunication) > > Celcom Postpaid 3G (Telecommunication) > > Additionally, I've ran the following command (dmesg | tail -6) to > determine what path my card reader is mounted to: > > macbook at ubuntu:~/Desktop/pyscard-1.9.7/pysim$ dmesg | tail -n 6 > > [ 7079.120203] usb 3-3.1: new full-speed USB device number 6 using xhci_hcd > > [ 7079.223962] usb 3-3.1: New USB device found, idVendor=04e6, idProduct=5116 > > [ 7079.223965] usb 3-3.1: New USB device strings: Mfr=1, Product=2, > SerialNumber=5 > > [ 7079.223968] usb 3-3.1: Product: SCR33xx v2.0 USB SC Reader > > [ 7079.223969] usb 3-3.1: Manufacturer: Identive > > [ 7079.223971] usb 3-3.1: SerialNumber: 53311828708432 > > My questions are this, is there a known work around for this errors > that I've posted above? Also, if my card is not mounting to > dev/ttyUSB0, where do they mount to? I've looked in /mnt, /media as > well as /dev....no joy. I've searched the Open BSC archives as well > as scoured the web for an answer to this issue and I'm coming up > blank. One last thing, I've ran this python script on an Ubuntu VM > and Dual Boot. Same issue both machines. I've also tried this script > with an Alcor card reader. Same output. Any help is greatly > appreciated. > > Thanks, > Derek From nhofmeyr at sysmocom.de Thu Jan 3 00:30:52 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 3 Jan 2019 01:30:52 +0100 Subject: Please be aware: doxygen: confusion about \ref and \a Message-ID: <20190103003052.GB30946@my.box> Researching for a discussion at https://gerrit.osmocom.org/c/libosmocore/+/12384 made me realize that our use of doxygen keywords is currently confused. TLDR: - Links to structs, members and functions are implicit in doxygen. - Don't use '\ref', except to link to sections or files. - Don't use '\a', it is merely cosmetic and breaks reading flow for some. Details: (*) We are often using '\ref' wrongly, and also '\a' is merely cosmetic. Example: osmo_crc16(), see param 'len' intending to reference the 'buffer' param: /*! Compute 16bit CCITT polynome 0x8408 (x^0 + x^5 + x^12) over given buffer. * \param crc[in] previous CRC value * \param buffer[in] data pointer * \param len[in] number of bytes in input \ref buffer * \return updated CRC value */ uint16_t osmo_crc16(uint16_t crc, uint8_t const *buffer, size_t len) ... It looks perfectly sane, but this is wrong for more than one reason: - '\ref' is not actually about code elements. It is about referencing pages or code sections. See http://www.doxygen.nl/manual/commands.html#cmdref "Creates a reference to a named section, subsection, page or anchor." Doxygen complains with e.g.: "gsmtap_util.c:192: warning: unable to resolve reference to `data' for \ref command" Luckily '\ref' doesn't break implicit linking, which is probably why the misconception that we need to include them arose in the first place. - There *AREN'T* any references to function arguments at all!! It is not possible in doxygen to create a formal link to a function argument. You can reference struct members, functions, ... but not arguments. API code often uses '\a' (at least 320 times in libosmocore), but that does not add a formal link, either. '\a' is only and simply putting a term in italics. http://www.doxygen.nl/manual/commands.html#cmda There are currently at least 260 uses of '\ref' in libosmocore, of which only a few are correct. An example of correct use is gsmtap_source_init(): http://ftp.osmocom.org/api/latest/libosmocore/core/html/group__gsmtap.html#ga8f0bdeba378d233f34057e63e2d3a6d3 /*! [...] integrated with libosmocore \ref select */ which renders as integrated with libosmocore [Select loop abstraction] Ironically, the same gsmtap_source_init() also includes examples of incorrect use, ignore those for this argument, please. (*) Hyperlinks are fully automatic and implicit. Notice that formal links are detected automatically, without the need for an explicit doxygen marker. For example, look at the API doc for osmo_cgi_name2(): http://ftp.osmocom.org/api/latest/libosmocore/gsm/html/gsm23003_8c.html#af964fab51a2830226a42f10c1db06ba3 It has a link to osmo_cgi_name(), with a doxygen source of /*! Same as osmo_cgi_name(), but uses a different static buffer. [...] I will hence continue to omit '\a' and '\ref', and will actually ask patch submitters to omit them in code review. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Thu Jan 3 02:10:40 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 3 Jan 2019 03:10:40 +0100 Subject: 35c3: found induction charger in GSM room Message-ID: <20190103021040.GC30946@my.box> Is anyone missing a phone induction charger pad after congress? We found one left behind when clearing out the GSM room. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laforge at gnumonks.org Thu Jan 3 10:08:32 2019 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 3 Jan 2019 11:08:32 +0100 Subject: 35c3 feedback In-Reply-To: <3167850e-9c59-2b3d-fe39-22fcc738524e@rhizomatica.org> References: <2b0d858f-4117-ac80-4e80-36fdfd6be101@rhizomatica.org> <3167850e-9c59-2b3d-fe39-22fcc738524e@rhizomatica.org> Message-ID: <20190103100832.GA3054@nataraja> Hi Keith, On Wed, Jan 02, 2019 at 02:54:55PM +0100, Keith wrote: > It's probably not a BUG as such, but rather a (lack of) implementation > in the configured dialplan. I'm not so familiar with YATE, but I would > imagine it is probably something that would have also been fixed by a > simple regex modification in some yate config file.? '^(+|00)' or > something.. > > you make a good point though, and I glad I asked before submitting a patch. > > all the same, maybe it might be a nice thing for users to have, just as > a convenience?? I would argue we should first try to find out if there's a config/setting in yate that can make it support the '+' format. If there's an easy fix by just changing configs/dialplans, then we should document this in the Osmocom wiki and/or osmo-sip-connector manual. Implementing a workaround is an option, but I would only do it if we are sure there is no other way to fix it, short if patching the yate source code on the other side. > Without a config option, for a user faced with a non compliant upstream > SIP UA over which they have no control, they would have no choice but to > patch and recompile the sip connector. If the problem exists with more implementations than just yate, it would be a strong indication that we should implement some work-around on our side. But if it's only yate, see above comment. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Thu Jan 3 11:01:39 2019 From: holger at freyther.de (Holger Freyther) Date: Thu, 3 Jan 2019 11:01:39 +0000 Subject: Scaling up virtual bts tests for the BTS test - how I hold it wrong? In-Reply-To: <72c0e399-c4dd-a08f-b6f7-bd25fc6dd4af@sysmocom.de> References: <079E0BD2-5621-4092-BEAD-EFB6A8E9D812@freyther.de> <72c0e399-c4dd-a08f-b6f7-bd25fc6dd4af@sysmocom.de> Message-ID: > On 30. Dec 2018, at 23:21, Pau Espin Pedrol wrote: > > Hi Holger, Hey Pau, thank you for the instant response! > One can similarly do the same to request allocation of 100 sysmoBTS: > > bts: > - type: osmo-bts-sysmo > times: 100 ah great! That's a good interim solution. > I'd like to be able to specifcy pools of objects in resources.conf so we don't need to add 1 line per object there. In the case of IP addresses, specifying a subnet range and let osmo-gsm-tester to expand that into a set of objects at runtime. +1. Do you have a timeline or open issue for it? Besides the IP pool I have needs for a combined IMSI/MSISDN pool >> * 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. > > Yeah for now the way to do it is to ask for one until you get the specific exception thrown when there's no more objects of that type or matching the specifications. Fine for me to add more APIs to fetch this kind of information more easily. There are two parts to this. The first is convenience API but to me the more important is topology. I would like to build the network based on the suite.conf and in the python code. As a first proposal (but we require a lot more thinking) what about something like: hlr: <- define a HLR. Multiple might be possible -subs: times: 100000 pool: <- define IMSI/MSISDN pool -name: Foo imsi_start: XXXX msisdn_start: XXXX kind: draw_at_random times: 10k hlr: ... msc: <- MSCs connecting to it? High level or scope to HLR? type: nitb bsc: <- BSCs connecting to (void if NITB is used) times: 5 -bts: <- BTSs type: <- ... virtual_mobiles: <- borrowing from the HLRs? ... What we can't do with the above is simulate movements of subscribers (but we can't do that easily right now and can review it if that becomes a genuine requirement). We currently need to hardcode number of hlrs to one but that seems reasonable. One benefit is that the same test would work for both NITB and BSC/MSC. >> * 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. > > So you could specify manually a different ARFCN for each bts (number of elements in object modifiers must match number of elements in the resources in suite.conf). Let's say you want 3 BTS with 3 differnet arfcn, 2 of them in 1800 band and 1 in 900 band: I will give it a try. Please be aware that ARFCNs do not uniquely identify a band. >> * Configure these capacities from the outside. Changing from 1 to 256 BTS should be a single line (or even a parameter change). > > Unfortunately these kind of capacities are so far fixed by the suite.conf. If you want to do tests with different numbers, you can manually change the "times" attribute in there, or put a big number and only use a subset of them when running the test in the suite. I am thinking of a xpath like command line parameter --suite_override=hlr[0].bts[all].type=osmo-bts-virtual --suite_override=hlr[0].bts.times=100 what do you think? holger From pespin at sysmocom.de Thu Jan 3 15:13:04 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Thu, 3 Jan 2019 16:13:04 +0100 Subject: Scaling up virtual bts tests for the BTS test - how I hold it wrong? In-Reply-To: References: <079E0BD2-5621-4092-BEAD-EFB6A8E9D812@freyther.de> <72c0e399-c4dd-a08f-b6f7-bd25fc6dd4af@sysmocom.de> Message-ID: <42ff760e-a704-0847-3d7d-add77af0d047@sysmocom.de> Hi Holger, >> I'd like to be able to specifcy pools of objects in resources.conf so we don't need to add 1 line per object there. In the case of IP addresses, specifying a subnet range and let osmo-gsm-tester to expand that into a set of objects at runtime. > > +1. Do you have a timeline or open issue for it? Besides the IP pool I have needs for a combined IMSI/MSISDN pool No timeline since I could workaround that myself so far by adding new IP addresses manually. I tend to implement this kind of new features only once I find I am really blocked or constrained by previous system when trying to add new kind of tests (or more complex ones). > There are two parts to this. The first is convenience API but to me the more important is topology. I would like to build the network based on the suite.conf and in the python code. As a first proposal (but we require a lot more thinking) what about something like: > > hlr: <- define a HLR. Multiple might be possible > -subs: > times: 100000 > pool: <- define IMSI/MSISDN pool > -name: Foo > imsi_start: XXXX > msisdn_start: XXXX > kind: draw_at_random > times: 10k > hlr: > ... > > msc: <- MSCs connecting to it? High level or scope to HLR? > type: nitb > bsc: <- BSCs connecting to (void if NITB is used) > times: 5 > -bts: <- BTSs > type: <- ... > > virtual_mobiles: <- borrowing from the HLRs? > ... > > What we can't do with the above is simulate movements of subscribers (but we can't do that easily right now and can review it if that becomes a genuine requirement). We currently need to hardcode number of hlrs to one but that seems reasonable. > > One benefit is that the same test would work for both NITB and BSC/MSC. > TBH I don't like the idea of making the suite/scenario yml file structure a lot more complex, I think current status is quite complex and makes it already difficult to gasp how to put everything together. The kind of stuff that you intend to do here can already be done far more easily by using (or extending) the python test API. That's mostly what the test does anyway: Setting up a specific topology with a pre-allocated sub-set of objects, and then do some actions on that. If you require several similar tests but with different number of objects, you can abstract that by using the "lib" feature of a suite. See for instance osmo-gsm-tester.git/suites/gprs/lib/testlib.py and its users in osmo-gsm-tester.git/suites/gprs/lib/iperf3*.py > > I will give it a try. Please be aware that ARFCNs do not uniquely identify a band. Yes, that's why in osmo-gsm-tester initial work around this topic expects an arfcn to be actually a dictionary with ARFCN+BAND iirc. > > > >>> * Configure these capacities from the outside. Changing from 1 to 256 BTS should be a single line (or even a parameter change). >> >> Unfortunately these kind of capacities are so far fixed by the suite.conf. If you want to do tests with different numbers, you can manually change the "times" attribute in there, or put a big number and only use a subset of them when running the test in the suite. > > > I am thinking of a xpath like command line parameter > > --suite_override=hlr[0].bts[all].type=osmo-bts-virtual --suite_override=hlr[0].bts.times=100 > This kind of feature is similar to what scenarios provide already. The issue is still though that in order to sanely combine and override yml cfg files (lists, tuples, dictionaries, etc.) we require some restrictions in order to make it "sane" and usable for most cases. For instance right now we handle lists of "non-complex" attributes (integers, strings, etc.) as sets when combining them, but we expect lists of dictionaries to be the same size when merging them to have meaningful result (so order of items in list is important when combining or overwriting them). Lists of objects are expanded before merging suites and scenarios, so the "times" attribute is removed and item put in place in the list before combine() and override() operations are done. You may want to look at git history to understand reasons behind current system. Maybe one could use scenario modifiers to change the amount of objects from the suite.conf, that's something to explore, but I'd need to invest some time testing and reading the code too. IIRC summary is that regular suite.conf + scenarios are merged using combine(), while scenario modifiers are merged using override(). Something like [suite.conf] bts: - times: 1 [mod-num-bts.cfg] modifiers: bts: - times: 2 I think to that in order to override() you also need same list size, due to sanity checks. We could perhaps add a new "section" in scenarios which overpasses these checks, let's call it "appends" or whatever, which let's you add new requires resources to the suite. These are my 5cents, not an ultimate answer but just some advises and ideas. Regards, Pau -- - Pau Espin Pedrol 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 From holger at freyther.de Fri Jan 4 02:36:11 2019 From: holger at freyther.de (Holger Freyther) Date: Fri, 4 Jan 2019 02:36:11 +0000 Subject: Declaratively describing network topology (WAS Re: Scaling up virtual bts tests for the BTS test - how I hold it wrong?) In-Reply-To: <42ff760e-a704-0847-3d7d-add77af0d047@sysmocom.de> References: <079E0BD2-5621-4092-BEAD-EFB6A8E9D812@freyther.de> <72c0e399-c4dd-a08f-b6f7-bd25fc6dd4af@sysmocom.de> <42ff760e-a704-0847-3d7d-add77af0d047@sysmocom.de> Message-ID: > On 3. Jan 2019, at 15:13, Pau Espin Pedrol wrote: > Hi! let me spin this into a new thread. >> What we can't do with the above is simulate movements of subscribers (but we can't do that easily right now and can review it if that becomes a genuine requirement). We currently need to hardcode number of hlrs to one but that seems reasonable. >> One benefit is that the same test would work for both NITB and BSC/MSC. > > TBH I don't like the idea of making the suite/scenario yml file structure a lot more complex, I think current status is quite complex and makes it already difficult to gasp how to put everything together. > > The kind of stuff that you intend to do here can already be done far more easily by using (or extending) the python test API. That's mostly what the test does anyway: Setting up a specific topology with a pre-allocated sub-set of objects, and then do some actions on that. SCNR. This sounds too much like "just write more code". ;) > If you require several similar tests but with different number of objects, you can abstract that by using the "lib" feature of a suite. See for instance osmo-gsm-tester.git/suites/gprs/lib/testlib.py and its users in osmo-gsm-tester.git/suites/gprs/lib/iperf3*.py The number of "objects" is secondary. Let's say 40k subscribers, 256 BSCs, 512 BTS. The numbers are constant but there are many ways a network can be organized. And many present a nice problem/failure potential for our software stack. But what I want to stretch here. The topology does not matter to the success criteria (99% of subs manage to do X within Y units of time) or execution of the test (start mobiles and ask them to do stuff). If the topology does not matter, why would I want to change the test code? I want the suite to give me a configured network and then use the functional identities (e.g. connect to the SMPP interfaces, etc). If it is in a suite.conf, topology.conf or a RPC call is secondary to me. Does this change anything for you? holger From gullik.webjorn at corevalue.se Fri Jan 4 17:49:14 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Fri, 4 Jan 2019 18:49:14 +0100 Subject: Limesdr mini and nightly builds.... Message-ID: Hi, I have just received a limesdr mini, and I am trying to get that sdr to the same level as I had with uhd B100. I managed to get the whole config working properly, but stability was bad, as you have read. As I was recommended, I have been runnig "nightly" binaries, and see where I end up.... :-) limesdr installed in Orange Pi Zero, (armhf). Limesuite 18.10.0-1, LimeUtil seems happy, and I can see the SDR However, I cannot get stability enough to get a stable signal.... Gullik TRX LIME CONFIG log stderr ?logging filter all 1 ?logging color 1 ?logging print category 1 ?logging timestamp 1 ?logging print file basename ?logging level set-all info ! line vty ?no login ! trx ?bind-ip 127.0.0.1 ?remote-ip 127.0.0.1 ?base-port 5700 ?egprs disable ?tx-sps 4 ?rx-sps 4 ?rt-prio 18 ?chan 0 ? tx-path BAND1 ? rx-path LNAW bsc 1.3.0.287 or .284 will not run, fails with error in sysmalloc(), so I try running .283, from dec 19.... maybe this problem is armhf related...?? this is the bsc config...... osmobsc config file ! osmo-bsc default configuration ! (assumes STP to run on 127.0.0.1 and uses default point codes) ! e1_input ?e1_line 0 driver ipa network ?network country code 1 ?mobile network code 1 ?encryption a5 0 ?neci 1 ?paging any use tch 0 ?handover 0 ?handover algorithm 1 ?handover1 window rxlev averaging 10 ?handover1 window rxqual averaging 1 ?handover1 window rxlev neighbor averaging 10 ?handover1 power budget interval 6 ?handover1 power budget hysteresis 3 ?handover1 maximum distance 9999 ?dyn_ts_allow_tch_f 0 ?periodic location update 30 ?bts 0 ? type sysmobts ? band DCS1800 ? cell_identity 0 ? location_area_code 1 ? base_station_id_code 63 ? ms max power 15 ? cell reselection hysteresis 4 ? rxlev access min 0 ? radio-link-timeout 32 ? channel allocator ascending ? rach tx integer 9 ? rach max transmission 7 ? channel-descrption attach 1 ? channel-descrption bs-pa-mfrms 5 ? channel-descrption bs-ag-blks-res 1 ? early-classmark-sending forbidden ? ip.access unit_id 1801 0 ? oml ip.access stream_id 255 line 0 ? codec-support fr ? gprs mode none ? trx 0 ?? rf_locked 0 ?? arfcn 871 ?? nominal power 20 ?? ! to use full TRX power, set max_power_red 0 ?? max_power_red 3 ?? rsl e1 tei 0 ?? timeslot 0 ??? phys_chan_config CCCH+SDCCH4 ??? hopping enabled 0 ?? timeslot 1 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 2 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 3 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 4 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 5 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 6 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 7 ??? phys_chan_config TCH/F ??? hopping enabled 0 msc 0 ?no bsc-welcome-text ?no bsc-msc-lost-text ?no bsc-grace-text ?type normal ?allow-emergency allow ?amr-config 12_2k forbidden ?amr-config 10_2k forbidden ?amr-config 7_95k forbidden ?amr-config 7_40k forbidden ?amr-config 6_70k forbidden ?amr-config 5_90k allowed ?amr-config 5_15k forbidden ?amr-config 4_75k forbidden ?codec-list fr1 fr2 fr3 hr1 hr3 ?mgw remote-ip 127.0.0.1 ?mgw remote-port 2427 ?mgw local-port 2727 ?mgw endpoint-range 1 31 bsc ?mid-call-timeout 0 ?no missing-msc-text bsc does not seem to want to speak with trx-lms, I don't understand which config entry is wrong.... ?osmo_bsc_main.c:284 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 871 using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63 <0007> a_reset.c:106 A-RESET(msc-0)[0xdb2e98]{DISC}: (re)sending BSSMAP RESET message... <0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0007> osmo_bsc_bssap.c:58 RESET ACK from MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0007> a_reset.c:74 A-RESET(msc-0)[0xdb2e98]{DISC}: SIGTRAN connection succeded. <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-0-CCCH_SDCCH4)[0xddfcd8]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-1-TCH_F)[0xde0038]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-2-TCH_F)[0xde0398]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-3-TCH_F)[0xde06f8]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-4-TCH_F)[0xde0a58]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-5-TCH_F)[0xde0db8]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-6-TCH_F)[0xde1118]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-7-TCH_F)[0xde1478]{UNUSED}: Event TS_EV_OML_READY not permitted <0015> input/ipaccess.c:248 Sign link vanished, dead socket <0015> input/ipaccess.c:74 Forcing socket shutdown with no signal link set <0015> bts_ipaccess_nanobts.c:416 (bts=0) Dropping OML link. <0015> bts_ipaccess_nanobts.c:397 (bts=0,trx=0) Dropping RSL link. <0015> input/ipa.c:262 accept()ed new link from 127.0.0.1 to port 3002 <0004> abis_nm.c:538 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. <0004> abis_nm.c:538 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. So, has anyone config files for Limesdr mini -> trx-lms -> osmo-bts-trx_0.8.1.199 -> osmo-msc or can point me in the right direction.... Gullik From djks74 at gmail.com Fri Jan 4 18:01:30 2019 From: djks74 at gmail.com (Sandi Suhendro) Date: Sat, 5 Jan 2019 01:01:30 +0700 Subject: Limesdr mini and nightly builds.... In-Reply-To: References: Message-ID: Try this : https://osmocom.org/attachments/3389/config%20osmo-splits.tar.gz On Sat, Jan 5, 2019 at 12:56 AM Gullik Webjorn wrote: > Hi, > > I have just received a limesdr mini, and I am trying to get that sdr to > the same level as I had with > > uhd B100. I managed to get the whole config working properly, but > stability was bad, as you have read. > > As I was recommended, I have been runnig "nightly" binaries, and see > where I end up.... :-) > > limesdr installed in Orange Pi Zero, (armhf). Limesuite 18.10.0-1, > LimeUtil seems happy, and I can see the SDR > > However, I cannot get stability enough to get a stable signal.... > > Gullik > > > TRX LIME CONFIG > > log stderr > logging filter all 1 > logging color 1 > logging print category 1 > logging timestamp 1 > logging print file basename > logging level set-all info > ! > line vty > no login > ! > trx > bind-ip 127.0.0.1 > remote-ip 127.0.0.1 > base-port 5700 > egprs disable > tx-sps 4 > rx-sps 4 > rt-prio 18 > chan 0 > tx-path BAND1 > rx-path LNAW > > bsc 1.3.0.287 or .284 will not run, fails with error in sysmalloc(), so > I try running .283, from dec 19.... > > maybe this problem is armhf related...?? > > this is the bsc config...... > > osmobsc config file > > ! osmo-bsc default configuration > ! (assumes STP to run on 127.0.0.1 and uses default point codes) > ! > e1_input > e1_line 0 driver ipa > network > network country code 1 > mobile network code 1 > encryption a5 0 > neci 1 > paging any use tch 0 > handover 0 > handover algorithm 1 > handover1 window rxlev averaging 10 > handover1 window rxqual averaging 1 > handover1 window rxlev neighbor averaging 10 > handover1 power budget interval 6 > handover1 power budget hysteresis 3 > handover1 maximum distance 9999 > dyn_ts_allow_tch_f 0 > periodic location update 30 > bts 0 > type sysmobts > band DCS1800 > cell_identity 0 > location_area_code 1 > base_station_id_code 63 > ms max power 15 > cell reselection hysteresis 4 > rxlev access min 0 > radio-link-timeout 32 > channel allocator ascending > rach tx integer 9 > rach max transmission 7 > channel-descrption attach 1 > channel-descrption bs-pa-mfrms 5 > channel-descrption bs-ag-blks-res 1 > early-classmark-sending forbidden > ip.access unit_id 1801 0 > oml ip.access stream_id 255 line 0 > codec-support fr > gprs mode none > trx 0 > rf_locked 0 > arfcn 871 > nominal power 20 > ! to use full TRX power, set max_power_red 0 > max_power_red 3 > rsl e1 tei 0 > timeslot 0 > phys_chan_config CCCH+SDCCH4 > hopping enabled 0 > timeslot 1 > phys_chan_config TCH/F > hopping enabled 0 > timeslot 2 > phys_chan_config TCH/F > hopping enabled 0 > timeslot 3 > phys_chan_config TCH/F > hopping enabled 0 > timeslot 4 > phys_chan_config TCH/F > hopping enabled 0 > timeslot 5 > phys_chan_config TCH/F > hopping enabled 0 > timeslot 6 > phys_chan_config TCH/F > hopping enabled 0 > timeslot 7 > phys_chan_config TCH/F > hopping enabled 0 > msc 0 > no bsc-welcome-text > no bsc-msc-lost-text > no bsc-grace-text > type normal > allow-emergency allow > amr-config 12_2k forbidden > amr-config 10_2k forbidden > amr-config 7_95k forbidden > amr-config 7_40k forbidden > amr-config 6_70k forbidden > amr-config 5_90k allowed > amr-config 5_15k forbidden > amr-config 4_75k forbidden > codec-list fr1 fr2 fr3 hr1 hr3 > mgw remote-ip 127.0.0.1 > mgw remote-port 2427 > mgw local-port 2727 > mgw endpoint-range 1 31 > bsc > mid-call-timeout 0 > no missing-msc-text > > bsc does not seem to want to speak with trx-lms, I don't understand > which config entry is wrong.... > > osmo_bsc_main.c:284 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 871 > using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63 > <0007> a_reset.c:106 A-RESET(msc-0)[0xdb2e98]{DISC}: (re)sending BSSMAP > RESET message... > <0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC: > RI=SSN_PC,PC=0.23.1,SSN=BSSAP > <0007> osmo_bsc_bssap.c:58 RESET ACK from MSC: > RI=SSN_PC,PC=0.23.1,SSN=BSSAP > <0007> a_reset.c:74 A-RESET(msc-0)[0xdb2e98]{DISC}: SIGTRAN connection > succeded. > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-0-CCCH_SDCCH4)[0xddfcd8]{UNUSED}: Event TS_EV_OML_READY not > permitted > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-1-TCH_F)[0xde0038]{UNUSED}: Event TS_EV_OML_READY not > permitted > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-2-TCH_F)[0xde0398]{UNUSED}: Event TS_EV_OML_READY not > permitted > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-3-TCH_F)[0xde06f8]{UNUSED}: Event TS_EV_OML_READY not > permitted > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-4-TCH_F)[0xde0a58]{UNUSED}: Event TS_EV_OML_READY not > permitted > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-5-TCH_F)[0xde0db8]{UNUSED}: Event TS_EV_OML_READY not > permitted > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-6-TCH_F)[0xde1118]{UNUSED}: Event TS_EV_OML_READY not > permitted > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-7-TCH_F)[0xde1478]{UNUSED}: Event TS_EV_OML_READY not > permitted > <0015> input/ipaccess.c:248 Sign link vanished, dead socket > <0015> input/ipaccess.c:74 Forcing socket shutdown with no signal link set > <0015> bts_ipaccess_nanobts.c:416 (bts=0) Dropping OML link. > <0015> bts_ipaccess_nanobts.c:397 (bts=0,trx=0) Dropping RSL link. > <0015> input/ipa.c:262 accept()ed new link from 127.0.0.1 to port 3002 > <0004> abis_nm.c:538 BTS0 feature 'EGPRS' reported via OML does not > match statically set feature: 0 != 1. Please fix. > <0004> abis_nm.c:538 BTS0 feature 'OML Alerts' reported via OML does not > match statically set feature: 1 != 0. Please fix. > > So, has anyone config files for Limesdr mini -> trx-lms -> > osmo-bts-trx_0.8.1.199 -> osmo-msc or can point me in the > > right direction.... > > Gullik > > > > > -- Best Regards, Sandi -------------- next part -------------- An HTML attachment was scrubbed... URL: From gullik.webjorn at corevalue.se Fri Jan 4 19:59:34 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Fri, 4 Jan 2019 20:59:34 +0100 Subject: Limesdr mini and nightly builds.... In-Reply-To: References: Message-ID: <7a6fbc06-aedd-a3a8-6b96-a8d38d4963c6@corevalue.se> This is the sequence of events that preceedes a failure in osmo-trx-lime. Before this event everything looks normal, and sometimes I can see the messages relating to phones selecting this bts. But, then I get many hundreds of fail messages, overfilling the terminal buffer. I managed to catch ONE event, it follows....at 17:53:26...... Fri Jan? 4 17:53:22 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2012824 Fri Jan? 4 17:53:23 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2013041 Fri Jan? 4 17:53:24 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2013257 Fri Jan? 4 17:53:25 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2013474 Fri Jan? 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 331871c got 3318b18 (3318b18) diff=3fc Fri Jan? 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 33190e0 got 3320c64 (3320c64) diff=7b84 Fri Jan? 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 3319aa4 got 3321628 (3321628) diff=7b84 Fri Jan? 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 331a468 got 3321fec (3321fec) diff=7b84 Fri Jan? 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 331ae2c got 33229b0 (33229b0) di after this, possibly 30 seconds later ?? the BTS restarts ?? and the trx synchronizes up, config is done, and log starts logging IND CLOCK every second... then this same event happens.....and we have a loop..... This is on an orange PI Zero, arm, so maybe not visible on your platforms..... Gullik From djks74 at gmail.com Fri Jan 4 20:25:21 2019 From: djks74 at gmail.com (Sandi Suhendro) Date: Sat, 5 Jan 2019 03:25:21 +0700 Subject: Limesdr mini and nightly builds.... In-Reply-To: <7a6fbc06-aedd-a3a8-6b96-a8d38d4963c6@corevalue.se> References: <7a6fbc06-aedd-a3a8-6b96-a8d38d4963c6@corevalue.se> Message-ID: Hi Gullik, you might have same issued as here https://osmocom.org/issues/3339 On Sat, Jan 5, 2019 at 2:59 AM Gullik Webjorn wrote: > This is the sequence of events that preceedes a failure in > osmo-trx-lime. Before this event everything looks > > normal, and sometimes I can see the messages relating to phones > selecting this bts. But, then I get many hundreds > > of fail messages, overfilling the terminal buffer. > > I managed to catch ONE event, it follows....at 17:53:26...... > > Fri Jan 4 17:53:22 2019 DMAIN <0000> Transceiver.cpp:1039 > [tid=3043908688] ClockInterface: sending IND CLOCK 2012824 > Fri Jan 4 17:53:23 2019 DMAIN <0000> Transceiver.cpp:1039 > [tid=3043908688] ClockInterface: sending IND CLOCK 2013041 > Fri Jan 4 17:53:24 2019 DMAIN <0000> Transceiver.cpp:1039 > [tid=3043908688] ClockInterface: sending IND CLOCK 2013257 > Fri Jan 4 17:53:25 2019 DMAIN <0000> Transceiver.cpp:1039 > [tid=3043908688] ClockInterface: sending IND CLOCK 2013474 > Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] > chan 0 recv buffer of len 2500 expect 331871c got 3318b18 (3318b18) > diff=3fc > Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] > chan 0 recv buffer of len 2500 expect 33190e0 got 3320c64 (3320c64) > diff=7b84 > Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] > chan 0 recv buffer of len 2500 expect 3319aa4 got 3321628 (3321628) > diff=7b84 > Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] > chan 0 recv buffer of len 2500 expect 331a468 got 3321fec (3321fec) > diff=7b84 > Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] > chan 0 recv buffer of len 2500 expect 331ae2c got 33229b0 (33229b0) di > > after this, possibly 30 seconds later ?? the BTS restarts ?? and the trx > synchronizes up, config is done, and log starts logging IND CLOCK every > second... > > then this same event happens.....and we have a loop..... > > This is on an orange PI Zero, arm, so maybe not visible on your > platforms..... > > Gullik > > > -- Best Regards, Sandi -------------- next part -------------- An HTML attachment was scrubbed... URL: From gullik.webjorn at corevalue.se Fri Jan 4 20:29:59 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Fri, 4 Jan 2019 21:29:59 +0100 Subject: Limesdr mini and nightly builds.... In-Reply-To: References: <7a6fbc06-aedd-a3a8-6b96-a8d38d4963c6@corevalue.se> Message-ID: <292afe18-38a4-ffb2-d42a-7a3693c23ab2@corevalue.se> Yes, I just spotted that bug report #3339, and one thing that is similar to a completely other system is the USB2 vs USB3, which is the only type available on the Opi Z. Regards, Gullik From gullik.webjorn at corevalue.se Fri Jan 4 20:53:15 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Fri, 4 Jan 2019 21:53:15 +0100 Subject: Limesdr mini and nightly builds.... In-Reply-To: <292afe18-38a4-ffb2-d42a-7a3693c23ab2@corevalue.se> References: <7a6fbc06-aedd-a3a8-6b96-a8d38d4963c6@corevalue.se> <292afe18-38a4-ffb2-d42a-7a3693c23ab2@corevalue.se> Message-ID: <2a18e844-9697-1e9a-df76-25ceb22979c6@corevalue.se> Watching a phone, the phone associates with the BTS, after about 15-25 seconds the strength indicator shrinks, and after 30 seconds, the Operator Logo disappears , and the phone diplays "select operator". After 30-60 seconds, the signal indicator again shows full scale + operator, then slowly goes down to zero and repeat..... Could this indicate some dependency on the power regulation loop ? Gullik On 2019-01-04 21:29, Gullik Webjorn wrote: > Yes, I just spotted that bug report #3339, and one thing that is > similar to > > a completely other system is the USB2 vs USB3, which is the only type > available on the Opi Z. > > Regards, > > Gullik > > From gullik.webjorn at corevalue.se Fri Jan 4 22:54:15 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Fri, 4 Jan 2019 23:54:15 +0100 Subject: Limesdr mini and nightly builds.... In-Reply-To: <2a18e844-9697-1e9a-df76-25ceb22979c6@corevalue.se> References: <7a6fbc06-aedd-a3a8-6b96-a8d38d4963c6@corevalue.se> <292afe18-38a4-ffb2-d42a-7a3693c23ab2@corevalue.se> <2a18e844-9697-1e9a-df76-25ceb22979c6@corevalue.se> Message-ID: And after a fairly long time the trx exits. Restarting it, everything goes back to the OK, bug 3339 cycle once per minute approx. Any suggestions on how I could help identifying the problem? Gullik On 2019-01-04 21:53, Gullik Webjorn wrote: > Watching a phone, the phone associates with the BTS, after about 15-25 > seconds the strength indicator > > shrinks, and after 30 seconds, the Operator Logo disappears , and the > phone diplays "select operator". > > After 30-60 seconds, the signal indicator again shows full scale + > operator, then slowly goes down to zero and > > repeat..... > > Could this indicate some dependency on the power regulation loop ? > > Gullik > > On 2019-01-04 21:29, Gullik Webjorn wrote: >> Yes, I just spotted that bug report #3339, and one thing that is >> similar to >> >> a completely other system is the USB2 vs USB3, which is the only type >> available on the Opi Z. >> >> Regards, >> >> Gullik >> >> From gullik.webjorn at corevalue.se Sat Jan 5 10:56:48 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Sat, 5 Jan 2019 11:56:48 +0100 Subject: Limesdr mini and nightly builds.... In-Reply-To: References: Message-ID: bsc 1.3.0.287 or .284 will not run, fails with error in sysmalloc(), so I try running .283, from dec 19.... > maybe this problem is armhf related...?? > I can confirm that osmo-bsc_1.3.0.288.f3bd8_armhf.deb seems to run OK. Gullik From gullik.webjorn at corevalue.se Sat Jan 5 11:02:59 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Sat, 5 Jan 2019 12:02:59 +0100 Subject: Limesdr mini and nightly builds.... In-Reply-To: References: Message-ID: I have found an interesting log entry, I cannot see where it is called... Sat Jan? 5 11:58:42 2019 DDEV <0002> LMSDevice.cpp:386 [tid=3070102608] chan 0: Setting TX gain to 73 dB Sat Jan? 5 11:58:42 2019 DLMS <0003> LMSDevice.cpp:102 [tid=3021294672] L Sat Jan? 5 11:58:42 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3012840528] ClockInterface: sending IND CLOCK 920402 the message of a single L seems a little cryptic, and I have not found it's origin...... Gullik From gullik.webjorn at corevalue.se Sat Jan 5 20:54:31 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Sat, 5 Jan 2019 21:54:31 +0100 Subject: Limesdr mini and nightly builds.... In-Reply-To: References: Message-ID: Well, we just have to find out what is happening. I have currently built the trx-lms from source, so once I can figure out how to build with debug....without breaking everything.... In the mean time: <0015> input/ipa.c:262 accept()ed new link from 127.0.0.1 to port 3002 <0004> abis_nm.c:538 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. <0004> abis_nm.c:538 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'CBCH' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Halfrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech EFR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Halfrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is unreported Yes, it would be nice to fix, I imagine this is a configuration mismatch, where should these be set, and using what keywords? This also indicates a problem, but I am to much a beginner to realize its importance..... <0003> osmo_bsc_main.c:284 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 871 using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63 <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-0-CCCH_SDCCH4)[0xe641d0]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-1-TCH_F)[0xe64530]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-2-TCH_F)[0xe64890]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-3-TCH_F)[0xe64bf0]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-4-TCH_F)[0xe64f50]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-5-TCH_F)[0xe652b0]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-6-TCH_F)[0xe65610]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-7-TCH_F)[0xe65970]{UNUSED}: Event TS_EV_OML_READY not permitted <0015> input/ipaccess.c:248 Sign link vanished, dead socket Is it because BSC and BTS are out of sync over their A-if ? As a consequence of trx restart ?? Regards, Gullik On 2019-01-05 12:02, Gullik Webjorn wrote: > I have found an interesting log entry, I cannot see where it is called... > > Sat Jan? 5 11:58:42 2019 DDEV <0002> LMSDevice.cpp:386 > [tid=3070102608] chan 0: Setting TX gain to 73 dB > Sat Jan? 5 11:58:42 2019 DLMS <0003> LMSDevice.cpp:102 [tid=3021294672] L > Sat Jan? 5 11:58:42 2019 DMAIN <0000> Transceiver.cpp:1039 > [tid=3012840528] ClockInterface: sending IND CLOCK 920402 > > the message of a single L seems a little cryptic, and I have not found > it's origin...... > > Gullik > From gullik.webjorn at corevalue.se Sun Jan 6 15:30:19 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Sun, 6 Jan 2019 16:30:19 +0100 Subject: Limesdr mini and nightly builds.... In-Reply-To: References: Message-ID: <59955a05-bbe4-0517-92ed-86bd0347dde6@corevalue.se> Hello Gentlemen, ( and Ladies also of course ) Here is again a small Monologue from me, with an attempt to fix a bug.... My osmo-trx-lms is not stable, and I have reported it's strange behaviour. Some things made me think of memory corruption, and when I found that one thread was logging a single letter "L" suspicion increased.... I have rebuilt the debian package from source, and tried to have a look at the log message print, but failed to place a breakpoint in LMSDevice.cpp:102 with meaningful result, typically gdb could not retrieve general registers....again, memory corruption?? However, after numerous tries I managed to "continue" the correct number of times to hit exactly the right instance of the breakpoint, without trx-lms giving up due to timeouts, and here is a bt when this happens: (gdb) bt #0? lms_log_callback (lvl=, msg=0xb415353c "L") at LMSDevice.cpp:102 #1? 0xb6d0c6c8 in lime::log(lime::LogLevel, char const*, std::__va_list) () from /usr/lib/arm-linux-gnueabihf/libLimeSuite.so.18.10-1 #2? 0xb6d26b22 in ?? () from /usr/lib/arm-linux-gnueabihf/libLimeSuite.so.18.10-1 #3? 0xb6d299f6 in ?? () from /usr/lib/arm-linux-gnueabihf/libLimeSuite.so.18.10-1 #4? 0xb6c75a6a in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 #5? 0xb6fab5e8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0 #6? 0xb6aee4fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) Last line: corrupt stack ?? Since I have had very little reaction, I deduce that most of you developers do NOT use my particular make of CPU, so this might be related to the Armbian ( Debian 9 ) I am running on this particular hardware. I am using the armhf variety of the source. Next step for me is rebuilding LimeSuite from source to get debugging info, so that backtraces etc. become more meaningful. The thinking here is that the subtle error in logging has a more general cause, and that memory corruption surely prevents the program to operate stable and as intended.... Best Regards, Gullik On 2019-01-05 21:54, Gullik Webjorn wrote: > Well, we just have to find out what is happening. I have currently > built the trx-lms from source, so > > once I can figure out how to build with debug....without breaking > everything.... > > In the mean time: > > <0015> input/ipa.c:262 accept()ed new link from 127.0.0.1 to port 3002 > <0004> abis_nm.c:538 BTS0 feature 'EGPRS' reported via OML does not > match statically set feature: 0 != 1. Please fix. > <0004> abis_nm.c:538 BTS0 feature 'OML Alerts' reported via OML does > not match statically set feature: 1 != 0. Please fix. > <0004> abis_nm.c:538 BTS0 feature 'CBCH' reported via OML does not > match statically set feature: 1 != 0. Please fix. > <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech V1' reported via > OML does not match statically set feature: 1 != 0. Please fix. > <0004> abis_nm.c:538 BTS0 feature 'Halfrate speech V1' reported via > OML does not match statically set feature: 1 != 0. Please fix. > <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech EFR' reported via > OML does not match statically set feature: 1 != 0. Please fix. > <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech AMR' reported via > OML does not match statically set feature: 1 != 0. Please fix. > <0004> abis_nm.c:538 BTS0 feature 'Halfrate speech AMR' reported via > OML does not match statically set feature: 1 != 0. Please fix. > <0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is > unreported > > Yes, it would be nice to fix, I imagine this is a configuration > mismatch, where should these be set, and using what keywords? > > This also indicates a problem, but I am to much a beginner to realize > its importance..... > > <0003> osmo_bsc_main.c:284 bootstrapping RSL for BTS/TRX (0/0) on > ARFCN 871 using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63 > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-0-CCCH_SDCCH4)[0xe641d0]{UNUSED}: Event TS_EV_OML_READY > not permitted > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-1-TCH_F)[0xe64530]{UNUSED}: Event TS_EV_OML_READY not > permitted > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-2-TCH_F)[0xe64890]{UNUSED}: Event TS_EV_OML_READY not > permitted > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-3-TCH_F)[0xe64bf0]{UNUSED}: Event TS_EV_OML_READY not > permitted > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-4-TCH_F)[0xe64f50]{UNUSED}: Event TS_EV_OML_READY not > permitted > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-5-TCH_F)[0xe652b0]{UNUSED}: Event TS_EV_OML_READY not > permitted > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-6-TCH_F)[0xe65610]{UNUSED}: Event TS_EV_OML_READY not > permitted > <0011> bts_ipaccess_nanobts.c:315 > timeslot(0-0-7-TCH_F)[0xe65970]{UNUSED}: Event TS_EV_OML_READY not > permitted > <0015> input/ipaccess.c:248 Sign link vanished, dead socket > > Is it because BSC and BTS are out of sync over their A-if ? As a > consequence of trx restart ?? > > Regards, > > Gullik > > > > On 2019-01-05 12:02, Gullik Webjorn wrote: >> I have found an interesting log entry, I cannot see where it is >> called... >> >> Sat Jan? 5 11:58:42 2019 DDEV <0002> LMSDevice.cpp:386 >> [tid=3070102608] chan 0: Setting TX gain to 73 dB >> Sat Jan? 5 11:58:42 2019 DLMS <0003> LMSDevice.cpp:102 >> [tid=3021294672] L >> Sat Jan? 5 11:58:42 2019 DMAIN <0000> Transceiver.cpp:1039 >> [tid=3012840528] ClockInterface: sending IND CLOCK 920402 >> >> the message of a single L seems a little cryptic, and I have not >> found it's origin...... >> >> Gullik >> From nhofmeyr at sysmocom.de Sun Jan 6 21:39:05 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 6 Jan 2019 22:39:05 +0100 Subject: got traces for inter-MSC Handover? Message-ID: <20190106213905.GA8691@my.box> Hi all, my current task is implementing inter-MSC Handover for OsmoMSC. It would be immensely helpful to look at network traces of the messages carrying out an inter-MSC handover. Primarily for 2G (BSSAP), but 3G (RANAP) might also be interesting. The part on the A-interface (BSSAP) is interesting for both the outgoing (orig. MSC and BSS) as well as the incoming (remote MSC and BSS) sides. Most interesting would be some kind of trace of communication between the two MSCs, the E-interface (MAP) negotiating the HO as well as the call forwarding between the two MSCs, if at all available. We are exploring various avenues to obtain inter-MSC HO traces, so far to no avail. If anyone reading this is able to help out, that would be highly appreciated and super helpful to be interoperable. Thanks! ~N -- - Neels Hofmeyr 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From devifr at gmail.com Mon Jan 7 00:19:32 2019 From: devifr at gmail.com (devifr) Date: Sun, 6 Jan 2019 19:19:32 -0500 Subject: pysim-read errors In-Reply-To: References: Message-ID: Domi, Thanks for the reply. Yeah, I saw the options in the help; however, the help didn't have any values...specifically for the p option. Regardless, the -p option with 0 was the fix. Thank you much. Derek On Wed, Jan 2, 2019 at 5:37 PM Tomcs?nyi, Domonkos wrote: > > Hi Derek, > > Please see the help included in the program you mentioned, it answers your question. > You need the -p option with the correct number (usually 0 if you only have one reader connected) to use PCSC. > > Cheers, > Domi > > > 2019. jan. 2. d?tummal, 21:26 id?pontban devifr ?rta: > > > All, > > > > I have the following error when I run pySim-read.py: > > > > Traceback (most recent call last): > > > > File "pySim-read.py", line 86, in > > sl = SerialSimLink(device=opts.device, baudrate=opts.baudrate) > > > > File "/home/macbook/Desktop/pyscard-1.9.7/pysim/pySim/transport/serial.py", > > line 45, in __init__ > > > > baudrate = baudrate, > > > > File "/home/macbook/.local/lib/python2.7/site-packages/serial/serialutil.py", > > line 240, in __init__ > > > > self.open() > > > > File "/home/macbook/.local/lib/python2.7/site-packages/serial/serialposix.py", > > line 268, in open > > > > raise SerialException(msg.errno, "could not open port {}: > > {}".format(self._port, msg)) > > > > serial.serialutil.SerialException: [Errno 2] could not open port > > /dev/ttyUSB0: [Errno 2] No such file or directory: '/dev/ttyUSB0' > > > > Exception AttributeError: "'SerialSimLink' object has no attribute > > '_sl'" in > > > > ignored > > > > I'm no Linux and/or Python guru but from what I can gather is that > > it's having issues with identifying the card reader on dev/ttyUSB0. > > To address that issue, I've confirmed my current card reader (identiv > > SCR3310) is working when I've ran the pcsc_scan script: > > > > PC/SC device scanner > > > > V 1.5.2 (c) 2001-2017, Ludovic Rousseau > > > > Using reader plug'n play mechanism > > > > Scanning present readers... > > > > 0: SCR3310 Smart Card Reader [CCID Interface] (53311828708432) 00 00 > > > > > > > > Wed Jan 2 12:02:36 2019 > > > > Reader 0: SCR3310 Smart Card Reader [CCID Interface] (53311828708432) 00 00 > > > > Card state: Card inserted, > > > > ATR: 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8 > > > > > > ATR: 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8 > > > > + TS = 3B --> Direct Convention > > > > + T0 = 9F, Y(1): 1001, K: 15 (historical bytes) > > > > TA(1) = 95 --> Fi=512, Di=16, 32 cycles/ETU > > > > 125000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 156250 bits/s > > > > TD(1) = 80 --> Y(i+1) = 1000, Protocol T = 0 > > > > ----- > > > > TD(2) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface > > bytes following > > > > ----- > > > > TA(3) = C3 --> Clock stop: no preference - Class accepted by the > > card: (3G) A 5V B 3V > > > > + Historical bytes: 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 > > > > Category indicator byte: 80 (compact TLV data object) > > > > Tag: 3, len: 1 (card service data byte) > > > > Card service data byte: E0 > > > > - Application selection: by full DF name > > > > - Application selection: by partial DF name > > > > - BER-TLV data objects available in EF.DIR > > > > - EF.DIR and EF.ATR access services: by GET RECORD(s) command > > > > - Card with MF > > > > Tag: 7, len: 3 (card capabilities) > > > > Selection methods: FE > > > > - DF selection by full DF name > > > > - DF selection by partial DF name > > > > - DF selection by path > > > > - DF selection by file identifier > > > > - Implicit DF selection > > > > - Short EF identifier supported > > > > - Record number supported > > > > Data coding byte: 21 > > > > - Behaviour of write functions: proprietary > > > > - Value 'FF' for the first byte of BER-TLV tag fields: invalid > > > > - Data unit in quartets: 2 > > > > Command chaining, length fields and logical channels: 13 > > > > - Logical channel number assignment: by the card > > > > - Maximum number of logical channels: 4 > > > > Tag: 5, len: 7 (card issuer's data) > > > > Card issuer data: 86 81 02 86 98 44 18 > > > > + TCK = A8 (correct checksum) > > > > > > Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): > > > > 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8 > > > > GREEN CARD, Grcard (Hong Kong ) Co.,Limited, LTE Usim Card (Telecommunication) > > > > Celcom Postpaid 3G (Telecommunication) > > > > Additionally, I've ran the following command (dmesg | tail -6) to > > determine what path my card reader is mounted to: > > > > macbook at ubuntu:~/Desktop/pyscard-1.9.7/pysim$ dmesg | tail -n 6 > > > > [ 7079.120203] usb 3-3.1: new full-speed USB device number 6 using xhci_hcd > > > > [ 7079.223962] usb 3-3.1: New USB device found, idVendor=04e6, idProduct=5116 > > > > [ 7079.223965] usb 3-3.1: New USB device strings: Mfr=1, Product=2, > > SerialNumber=5 > > > > [ 7079.223968] usb 3-3.1: Product: SCR33xx v2.0 USB SC Reader > > > > [ 7079.223969] usb 3-3.1: Manufacturer: Identive > > > > [ 7079.223971] usb 3-3.1: SerialNumber: 53311828708432 > > > > My questions are this, is there a known work around for this errors > > that I've posted above? Also, if my card is not mounting to > > dev/ttyUSB0, where do they mount to? I've looked in /mnt, /media as > > well as /dev....no joy. I've searched the Open BSC archives as well > > as scoured the web for an answer to this issue and I'm coming up > > blank. One last thing, I've ran this python script on an Ubuntu VM > > and Dual Boot. Same issue both machines. I've also tried this script > > with an Alcor card reader. Same output. Any help is greatly > > appreciated. > > > > Thanks, > > Derek From snehasish.cse at live.com Mon Jan 7 06:38:29 2019 From: snehasish.cse at live.com (Snehasish Kar) Date: Mon, 7 Jan 2019 06:38:29 +0000 Subject: Adding priority for EMLPP service in paging type 1 In-Reply-To: References: <81DC58B6-C9B8-4B82-88C1-591F5EFF80EC@gnumonks.org> , <20181226205830.GB2559@nataraja>, Message-ID: Herald any update on this? BR ________________________________ From: Snehasish Kar Sent: Monday, December 31, 2018 7:04 PM To: Harald Welte Cc: openbsc at lists.osmocom.org Subject: Re: Adding priority for EMLPP service in paging type 1 Hello Harald I have been able to add priority to the paging and setup command, though it is hard-coded now, but still please check it and let me know if I am correct or wrong. diff --git a/openbsc/src/libbsc/abis_rsl.c b/openbsc/src/libbsc/abis_rsl.c index 5a508b207..5b45cd497 100644 --- a/openbsc/src/libbsc/abis_rsl.c +++ b/openbsc/src/libbsc/abis_rsl.c @@ -1034,6 +1034,8 @@ int rsl_paging_cmd(struct gsm_bts *bts, uint8_t paging_group, uint8_t len, if (bts->type == GSM_BTS_TYPE_RBS2000 && is_gprs) msgb_tv_put(msg, RSL_IE_ERIC_PACKET_PAG_IND, 0); + msgb_tv_put(msg, RSL_IE_EMLPP_PRIO, 0x7f); + msg->dst = bts->c0->rsl_link; diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c index 09e35cce2..a7ba85744 100644 --- a/openbsc/src/libmsc/gsm_04_08.c +++ b/openbsc/src/libmsc/gsm_04_08.c @@ -2376,7 +2376,7 @@ static int gsm48_cc_tx_setup(struct gsm_trans *trans, void *arg) /* signal */ if (setup->fields & MNCC_F_SIGNAL) gsm48_encode_signal(msg, setup->signal); - + msgb_v_put(msg,GSM48_IE_PRIORITY_LEV | 0xf); new_cc_state(trans, GSM_CSTATE_CALL_PRESENT); rate_ctr_inc(&trans->net->msc_ctrs->ctr[MSC_CTR_CALL_MT_SETUP]); diff --git a/src/common/paging.c b/src/common/paging.c index aa604e7..092da05 100644 --- a/src/common/paging.c +++ b/src/common/paging.c @@ -293,7 +293,7 @@ static int fill_paging_type_1(uint8_t *out_buf, const uint8_t *identity1_lv, cur = tlv_put(cur, GSM48_IE_MOBILE_ID, identity2_lv[0], identity2_lv+1); pt1->l2_plen = L2_PLEN(cur - out_buf); - + cur = v_put(cur,/*priority*/0x7f); return cur - out_buf; } I have attached the wireshark traces please check. Also there is a wireshark dump with airprobe to see whether the paging messages are correctly being transported or not. BR Snehasish ________________________________ From: Harald Welte Sent: Thursday, December 27, 2018 2:28 AM To: Snehasish Kar Cc: openbsc at lists.osmocom.org Subject: Re: Adding priority for EMLPP service in paging type 1 Hi Snehasish, On Wed, Dec 26, 2018 at 02:13:38PM +0000, Snehasish Kar wrote: > Please find the updated patches: Thanks, there were no requested related pcap traces, though. I think you are making the wrong assumption that you can simply add a byte to the RSL message which then magically appears on the Um interface. Instead, you need to study how eMLPP is actually implemented over Abis. There's an additional information element that needs to be added to the RSL PAGING COMMAND, see Section 8.5.5 of 3GPP TS 48.058. The IE is of type TV, so you need to msgb_put_tv(...) to add it. Furthermore, you will need to teach OsmoBTS (assuming you are using OsmoBTS) to interpret that additional IE and then construct the air interface paging rest octets from it. Please also notice that openbsc.git is no longer maintained anymore and it is strongly suggested you switch to the new "split NITB" architecture consisting of osmo-bsc.git + osmo-msc.git + osmo-hlr.git. We're very much looking forward to receiving your patches contributing eMLPP support to the Osmocom stack. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmith at sysmocom.de Mon Jan 7 09:27:50 2019 From: osmith at sysmocom.de (Oliver Smith) Date: Mon, 7 Jan 2019 10:27:50 +0100 Subject: Please be aware: doxygen: confusion about \ref and \a In-Reply-To: <20190103003052.GB30946@my.box> References: <20190103003052.GB30946@my.box> Message-ID: <45d75dfe-5238-12f3-f09e-3dbb1c43c11b@sysmocom.de> Thanks for the write-up, I've extended the guidelines with "Parameters can not be referenced with \ref, nor with \a" and linked to your post: https://osmocom.org/projects/cellular-infrastructure/wiki/Guidelines_for_API_documentation#Parameters Regards, Oliver On 1/3/19 1:30 AM, Neels Hofmeyr wrote: > Researching for a discussion at https://gerrit.osmocom.org/c/libosmocore/+/12384 > made me realize that our use of doxygen keywords is currently confused. > > TLDR: > > - Links to structs, members and functions are implicit in doxygen. > - Don't use '\ref', except to link to sections or files. > - Don't use '\a', it is merely cosmetic and breaks reading flow for some. > > > Details: > > > (*) We are often using '\ref' wrongly, and also '\a' is merely cosmetic. > > Example: > osmo_crc16(), see param 'len' intending to reference the 'buffer' param: > > > /*! Compute 16bit CCITT polynome 0x8408 (x^0 + x^5 + x^12) over given buffer. > * \param crc[in] previous CRC value > * \param buffer[in] data pointer > * \param len[in] number of bytes in input \ref buffer > * \return updated CRC value > */ > uint16_t osmo_crc16(uint16_t crc, uint8_t const *buffer, size_t len) > ... > > It looks perfectly sane, but this is wrong for more than one reason: > > - '\ref' is not actually about code elements. It is about referencing pages or > code sections. See http://www.doxygen.nl/manual/commands.html#cmdref > "Creates a reference to a named section, subsection, page or anchor." > Doxygen complains with e.g.: > "gsmtap_util.c:192: warning: unable to resolve reference to `data' for \ref command" > Luckily '\ref' doesn't break implicit linking, which is probably why the > misconception that we need to include them arose in the first place. > > - There *AREN'T* any references to function arguments at all!! > It is not possible in doxygen to create a formal link to a function argument. > You can reference struct members, functions, ... but not arguments. > > API code often uses '\a' (at least 320 times in libosmocore), but that does not > add a formal link, either. '\a' is only and simply putting a term in italics. > http://www.doxygen.nl/manual/commands.html#cmda > > > There are currently at least 260 uses of '\ref' in libosmocore, of which only a > few are correct. An example of correct use is gsmtap_source_init(): > http://ftp.osmocom.org/api/latest/libosmocore/core/html/group__gsmtap.html#ga8f0bdeba378d233f34057e63e2d3a6d3 > /*! [...] integrated with libosmocore \ref select */ > which renders as > integrated with libosmocore [Select loop abstraction] > > Ironically, the same gsmtap_source_init() also includes examples of incorrect > use, ignore those for this argument, please. > > > > (*) Hyperlinks are fully automatic and implicit. > > Notice that formal links are detected automatically, without the need for an > explicit doxygen marker. For example, look at the API doc for osmo_cgi_name2(): > http://ftp.osmocom.org/api/latest/libosmocore/gsm/html/gsm23003_8c.html#af964fab51a2830226a42f10c1db06ba3 > It has a link to osmo_cgi_name(), with a doxygen source of > /*! Same as osmo_cgi_name(), but uses a different static buffer. [...] > > > > I will hence continue to omit '\a' and '\ref', and will actually ask patch > submitters to omit them in code review. > > ~N > -- - Oliver Smith https://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 From gullik.webjorn at corevalue.se Mon Jan 7 19:17:20 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Mon, 7 Jan 2019 20:17:20 +0100 Subject: Limesdr mini and nightly builds.... In-Reply-To: <59955a05-bbe4-0517-92ed-86bd0347dde6@corevalue.se> References: <59955a05-bbe4-0517-92ed-86bd0347dde6@corevalue.se> Message-ID: A small update from Sweden, I have built LimeSuite and osmo-trx-lms from source, this time on a Intel Atom, i386 distribution. I have redirected the bts - trx ip addresses, and yes, I could briefly see the beacon, and i managed to get two phones on the network, though not stable. However, I can see the exact behaviour of the osmo-trx-lms as on the armhf kit, i.e. the logging of a single L like this... Sat Jan? 5 11:58:42 2019 DLMS <0003> LMSDevice.cpp:102 [tid=3021294672] L I have not verified that the reason is exactly the same yet, since I don't have debug environment on the 386 yet, but the symptom is exactly the same, with strange length packets and a lot of packet flushing, all probably related to recovering synch. This reduces the previously assumed probability that the problem lies in hardware or hardware related software (armbian Linux) , but actually is a memory problem within osmo-trx (lms) What is relatively easy is to move the B100 to the "new" platform, and try to isolate the problem with regards to uhd device vs. lms device, so I will do that test and report back. Regards, Gullik On 2019-01-06 16:30, Gullik Webjorn wrote: > Hello Gentlemen, ( and Ladies also of course ) > > Here is again a small Monologue from me, with an attempt to fix a bug.... > > My osmo-trx-lms is not stable, and I have reported it's strange > behaviour. > > Some things made me think of memory corruption, and when I found that > one thread > > was logging a single letter "L" suspicion increased.... > > I have rebuilt the debian package from source, and tried to have a > look at the log message print, > > but failed to place a breakpoint in LMSDevice.cpp:102 with meaningful > result, typically gdb > > could not retrieve general registers....again, memory corruption?? > > However, after numerous tries I managed to "continue" the correct > number of times to hit exactly > > the right instance of the breakpoint, without trx-lms giving up due to > timeouts, > > and here is a bt when this happens: > > (gdb) bt > #0? lms_log_callback (lvl=, msg=0xb415353c "L") at > LMSDevice.cpp:102 > #1? 0xb6d0c6c8 in lime::log(lime::LogLevel, char const*, > std::__va_list) () from > /usr/lib/arm-linux-gnueabihf/libLimeSuite.so.18.10-1 > #2? 0xb6d26b22 in ?? () from > /usr/lib/arm-linux-gnueabihf/libLimeSuite.so.18.10-1 > #3? 0xb6d299f6 in ?? () from > /usr/lib/arm-linux-gnueabihf/libLimeSuite.so.18.10-1 > #4? 0xb6c75a6a in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 > #5? 0xb6fab5e8 in start_thread () from > /lib/arm-linux-gnueabihf/libpthread.so.0 > #6? 0xb6aee4fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 > Backtrace stopped: previous frame identical to this frame (corrupt > stack?) > (gdb) > > Last line: corrupt stack ?? > > Since I have had very little reaction, I deduce that most of you > developers do NOT use my particular make of CPU, > > so this might be related to the Armbian ( Debian 9 ) I am running on > this particular hardware. I am using the armhf > > variety of the source. > > Next step for me is rebuilding LimeSuite from source to get debugging > info, so that backtraces etc. become more meaningful. > > The thinking here is that the subtle error in logging has a more > general cause, and that memory corruption surely prevents > > the program to operate stable and as intended.... > > Best Regards, > > Gullik > > > > > > On 2019-01-05 21:54, Gullik Webjorn wrote: >> Well, we just have to find out what is happening. I have currently >> built the trx-lms from source, so >> >> once I can figure out how to build with debug....without breaking >> everything.... >> >> In the mean time: >> >> <0015> input/ipa.c:262 accept()ed new link from 127.0.0.1 to port 3002 >> <0004> abis_nm.c:538 BTS0 feature 'EGPRS' reported via OML does not >> match statically set feature: 0 != 1. Please fix. >> <0004> abis_nm.c:538 BTS0 feature 'OML Alerts' reported via OML does >> not match statically set feature: 1 != 0. Please fix. >> <0004> abis_nm.c:538 BTS0 feature 'CBCH' reported via OML does not >> match statically set feature: 1 != 0. Please fix. >> <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech V1' reported via >> OML does not match statically set feature: 1 != 0. Please fix. >> <0004> abis_nm.c:538 BTS0 feature 'Halfrate speech V1' reported via >> OML does not match statically set feature: 1 != 0. Please fix. >> <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech EFR' reported via >> OML does not match statically set feature: 1 != 0. Please fix. >> <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech AMR' reported via >> OML does not match statically set feature: 1 != 0. Please fix. >> <0004> abis_nm.c:538 BTS0 feature 'Halfrate speech AMR' reported via >> OML does not match statically set feature: 1 != 0. Please fix. >> <0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is >> unreported >> >> Yes, it would be nice to fix, I imagine this is a configuration >> mismatch, where should these be set, and using what keywords? >> >> This also indicates a problem, but I am to much a beginner to realize >> its importance..... >> >> <0003> osmo_bsc_main.c:284 bootstrapping RSL for BTS/TRX (0/0) on >> ARFCN 871 using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63 >> <0011> bts_ipaccess_nanobts.c:315 >> timeslot(0-0-0-CCCH_SDCCH4)[0xe641d0]{UNUSED}: Event TS_EV_OML_READY >> not permitted >> <0011> bts_ipaccess_nanobts.c:315 >> timeslot(0-0-1-TCH_F)[0xe64530]{UNUSED}: Event TS_EV_OML_READY not >> permitted >> <0011> bts_ipaccess_nanobts.c:315 >> timeslot(0-0-2-TCH_F)[0xe64890]{UNUSED}: Event TS_EV_OML_READY not >> permitted >> <0011> bts_ipaccess_nanobts.c:315 >> timeslot(0-0-3-TCH_F)[0xe64bf0]{UNUSED}: Event TS_EV_OML_READY not >> permitted >> <0011> bts_ipaccess_nanobts.c:315 >> timeslot(0-0-4-TCH_F)[0xe64f50]{UNUSED}: Event TS_EV_OML_READY not >> permitted >> <0011> bts_ipaccess_nanobts.c:315 >> timeslot(0-0-5-TCH_F)[0xe652b0]{UNUSED}: Event TS_EV_OML_READY not >> permitted >> <0011> bts_ipaccess_nanobts.c:315 >> timeslot(0-0-6-TCH_F)[0xe65610]{UNUSED}: Event TS_EV_OML_READY not >> permitted >> <0011> bts_ipaccess_nanobts.c:315 >> timeslot(0-0-7-TCH_F)[0xe65970]{UNUSED}: Event TS_EV_OML_READY not >> permitted >> <0015> input/ipaccess.c:248 Sign link vanished, dead socket >> >> Is it because BSC and BTS are out of sync over their A-if ? As a >> consequence of trx restart ?? >> >> Regards, >> >> Gullik >> >> >> >> On 2019-01-05 12:02, Gullik Webjorn wrote: >>> I have found an interesting log entry, I cannot see where it is >>> called... >>> >>> Sat Jan? 5 11:58:42 2019 DDEV <0002> LMSDevice.cpp:386 >>> [tid=3070102608] chan 0: Setting TX gain to 73 dB >>> Sat Jan? 5 11:58:42 2019 DLMS <0003> LMSDevice.cpp:102 >>> [tid=3021294672] L >>> Sat Jan? 5 11:58:42 2019 DMAIN <0000> Transceiver.cpp:1039 >>> [tid=3012840528] ClockInterface: sending IND CLOCK 920402 >>> >>> the message of a single L seems a little cryptic, and I have not >>> found it's origin...... >>> >>> Gullik >>> From axilirator at gmail.com Mon Jan 7 19:36:25 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 7 Jan 2019 20:36:25 +0100 Subject: Limesdr mini and nightly builds.... In-Reply-To: References: <59955a05-bbe4-0517-92ed-86bd0347dde6@corevalue.se> Message-ID: Hello Gullik, > [...] managed to get two phones on the network, though not stable. It's known issue that LimeSDR is not stable as a PHY for OsmoTRX. I wouldn't expect any miracles, trying it on different hardware, until the problem is investigated and the fix is merged. > [...] the message of a single L seems a little cryptic [...] > DLMS <0003> LMSDevice.cpp:102 [tid=3021294672] L AFAIK, this message comes from the LMS driver, and it means that you're sending TX samples too [L]ate. Most likely, your CPU is too slow. However, you can play with the real-time priority. I've never seen such messages with LimeSDR though. With best regards, Vadim Yanitskiy. From gullik.webjorn at corevalue.se Mon Jan 7 19:59:16 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Mon, 7 Jan 2019 20:59:16 +0100 Subject: Limesdr mini and nightly builds.... In-Reply-To: References: <59955a05-bbe4-0517-92ed-86bd0347dde6@corevalue.se> Message-ID: <2cdfab8f-0212-6570-2bb1-ed5e9457e9b1@corevalue.se> Thanks Vadim, I just saw the code in Streamer.cpp, so my conclusions were wrong.... Interesting though is that a backtrace in the armhf version shows something the debugger thinks is a corrupted stack :-) OK, so this was a blind shot, I will try to concentrate on the "main" error, the inability to serve the device data at proper rate and the problems with reading.... Regards, Gullik On 2019-01-07 20:36, Vadim Yanitskiy wrote: > Hello Gullik, > >> [...] managed to get two phones on the network, though not stable. > It's known issue that LimeSDR is not stable as a PHY for OsmoTRX. > I wouldn't expect any miracles, trying it on different hardware, > until the problem is investigated and the fix is merged. > >> [...] the message of a single L seems a little cryptic [...] >> DLMS <0003> LMSDevice.cpp:102 [tid=3021294672] L > AFAIK, this message comes from the LMS driver, and it means that > you're sending TX samples too [L]ate. Most likely, your CPU is > too slow. However, you can play with the real-time priority. > > I've never seen such messages with LimeSDR though. > > With best regards, > Vadim Yanitskiy. From jenkins at lists.osmocom.org Tue Jan 8 02:30:37 2019 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Tue, 8 Jan 2019 02:30:37 +0000 (UTC) Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #352 Message-ID: <2064512963.468.1546914637072.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 1.15 MB...] CC libarch_sse_4_1_la-convert_sse_4_1.lo CCLD libarch_sse_4_1.la CCLD libarch_sse_3.la ar: `u' modifier ignored since `D' is the default (see `U') ar: `u' modifier ignored since `D' is the default (see `U') CCLD libarch.la ar: `u' modifier ignored since `D' is the default (see `U') make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/x86' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' make[4]: Nothing to be done for 'all-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' Making all in device make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' Making all in uhd make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device/uhd' CXX UHDDevice.lo CXXLD libdevice.la ar: `u' modifier ignored since `D' is the default (see `U') make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device/uhd' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[4]: Nothing to be done for 'all-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' CXX radioVector.lo CXX radioClock.lo CXX Transceiver.lo CXX signalVector.lo CXX ChannelizerBase.lo CXX radioBuffer.lo CXX sigProcLib.lo CXX radioInterface.lo CXX Channelizer.lo CXX Synthesis.lo CXX Resampler.lo CXX radioInterfaceResamp.lo CXX radioInterfaceMulti.lo CXX osmo_trx_uhd-osmo-trx.o CXXLD libtransceiver_common.la ar: `u' modifier ignored since `D' is the default (see `U') CXXLD osmo-trx-uhd make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' Making all in contrib make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' Making all in systemd make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib/systemd' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib/systemd' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' Making all in tests make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' Making all in CommonLibs make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs' CXX PRBSTest.o CXX BitVectorTest.o CXX SocketsTest.o CXX InterthreadTest.o CXX TimevalTest.o CXX LogTest.o CXX VectorTest.o CXXLD BitVectorTest CXXLD VectorTest CXXLD TimevalTest CXXLD SocketsTest CXXLD LogTest CXXLD PRBSTest CXXLD InterthreadTest make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs' Making all in Transceiver52M make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M' CC convolve_test-convolve_test.o CCLD convolve_test make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx' + make install Making install in doc make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc' Making install in examples make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples' make[3]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' /usr/bin/install -c -m 644 osmo-trx-uhd/osmo-trx-uhd.cfg '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' make install-data-hook make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples' for f in $(find . -type f -name '*.cfg*' | sed -e 's,^.,,'); do \ j="/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/doc/osmo-trx/examples/$f" && \ mkdir -p "$(dirname $j)" && \ /usr/bin/install -c -m 644 ./$f $j; \ done make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples' Making install in manuals make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/manuals' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/manuals' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/manuals' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/manuals' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc' Making install in CommonLibs make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs' make[2]: Nothing to be done for 'install-exec-am'. make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs' Making install in GSM make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM' make[2]: Nothing to be done for 'install-exec-am'. make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM' Making install in Transceiver52M make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' Making install in arch make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' Making install in common make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/common' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/common' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/common' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/common' Making install in x86 make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/x86' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/x86' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/x86' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/x86' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' Making install in device make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' Making install in uhd make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device/uhd' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device/uhd' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device/uhd' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device/uhd' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' /bin/bash ../libtool --mode=install /usr/bin/install -c osmo-trx-uhd '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' libtool: install: /usr/bin/install -c osmo-trx-uhd /home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin/osmo-trx-uhd /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev2' /usr/bin/install -c -m 644 std_inband.rbf '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev2' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev4' /usr/bin/install -c -m 644 std_inband.rbf '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev4' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' Making install in contrib make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' Making install in systemd make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib/systemd' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib/systemd' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib/systemd' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib/systemd' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' Making install in tests make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' Making install in CommonLibs make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs' Making install in Transceiver52M make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx' make[2]: Nothing to be done for 'install-exec-am'. make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx' + popd ~/osmo-ci/coverity/source-Osmocom Emitted 2332 C/C++ compilation units (100%) successfully 2332 C/C++ compilation units (100%) are ready for analysis The cov-build utility completed successfully. + cd /home/osmocom-build/osmo-ci/coverity/source-Osmocom + rm -f Osmocom.tgz + tar czf Osmocom.tgz cov-int + set +x curl \ --form token="$token" \ --form email=holger at freyther.de --form file=@Osmocom.tgz \ --form version=Version --form description=AutoUpload \ https://scan.coverity.com/builds?project=Osmocom % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (51) SSL: no alternative certificate subject name matches target host name 'scan.coverity.com' Build step 'Execute shell' marked build as failure From jenkins at lists.osmocom.org Wed Jan 9 02:29:53 2019 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Wed, 9 Jan 2019 02:29:53 +0000 (UTC) Subject: Jenkins build is back to normal : Coverity-Upload (jenkins-job-builder) #353 In-Reply-To: <2064512963.468.1546914637072.JavaMail.jenkins@jenkins.osmocom.org> References: <2064512963.468.1546914637072.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <16354831.484.1547000993356.JavaMail.jenkins@jenkins.osmocom.org> See From sergey.mayzus at uwcfx.com Thu Jan 10 03:54:05 2019 From: sergey.mayzus at uwcfx.com (=?UTF-8?B?U2VyZ2V5IE1heXp1cw==?=) Date: Thu, 10 Jan 2019 03:54:05 +0000 Subject: =?UTF-8?B?T3Ntb1RSWCAtIG9zbW8tdHJ4LXVzcnAtMSBBYm9ydGU=?= =?UTF-8?B?ZCA6OiBBc3NlcnRpb24gJ3B4ICE9IDAnIGZhaWxlZA==?= Message-ID: An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Jan 10 11:11:03 2019 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 10 Jan 2019 12:11:03 +0100 Subject: OsmoTRX - osmo-trx-usrp-1 Aborted :: Assertion 'px != 0' failed In-Reply-To: References: Message-ID: <20190110111103.GV606@nataraja> On Thu, Jan 10, 2019 at 03:54:05AM +0000, Sergey Mayzus wrote: > Hello, > > Trying to use OsmoTRX (osmo-trx-usrp1) with USRP1 SDR, this is great news, thanks for looking into this. I don't think anyone in Osmocom has been using a USRP1 for quite some time, so your mileage may vary. It would be great to iron out the problems you experience and ensure continued support of this old SRD platform. > Thu Jan 10 04:47:04 2019 DDEV <0002> USRPDevice.cpp:98 [tid=3066698432] opening > USRP device.. > Can't find firmware: std.ihx This is probably the key here. The firmware file for the USRP1 device was not found. You could strace osmo-trx-usrp1 to see where it expects that file, and then try to put it in the right location. It seems that our libusrp.git doesn't include that file, thought. UHD ships the file at /usr/share/uhd/images/usrp1_fw.ihx, but I'm not sure if it's compatible with old libusrp. I think the firmware used to be built together with libusrp, but I don't recall the details.. It's been so many years back. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From gullik.webjorn at corevalue.se Thu Jan 10 21:31:39 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Thu, 10 Jan 2019 22:31:39 +0100 Subject: Some progress and some questions.... Message-ID: <26ba2180-3a42-b70d-46ea-92a87348a27b@corevalue.se> I have now built osmo-trx-lms and osmo-bts-trx from source on an i386 platform. I have beacon, and two phones registered, the configuration from msc and up is the one I had three weeks ago, which more or less worked, but with large stability problems. I guess *this* report is the most interesting for you now.... I build from the "master", and target debian9 on i386. I have not been able to make a call yet, possibly because I might have messed up some library the MSC is dependent on, but I will work on that. What is interesting is that bts 0 trx 0 is running trx-uhd with a B100, and seems quite stable. Moreover, bts 1 trx 0 is running on the i386 and seems happy so far, after 30 minutes. This is Limesdr mini. I have just copied the bts0 to trx 0 section from my original config, duplicated it and changed bts0 to bts1, and the ipa unit-id 1805 0, and of course the ip addresses. I will comment the various lines in my configs, as I have understood them, and look forward to your comments, or maybe a keyword list explaining what each parameter is used for. ! osmo-bsc default configuration ! (assumes STP to run on 127.0.0.1 and uses default point codes) ! e1_input ?e1_line 0 driver ipa network ?network country code 1 ?mobile network code 1 ?encryption a5 0 ?neci 1 ?paging any use tch 0 ?handover 0 ?handover algorithm 1 ?handover1 window rxlev averaging 10 ?handover1 window rxqual averaging 1 ?handover1 window rxlev neighbor averaging 10 ?handover1 power budget interval 6 ?handover1 power budget hysteresis 3 ?handover1 maximum distance 9999 ?dyn_ts_allow_tch_f 0 ?periodic location update 30 ! here is the first bts - trx section. The ip.access id must match the one in the BTS, where it is called ipa. ?bts 0 ? type sysmobts ? band DCS1800 ? cell_identity 0 ? location_area_code 1 ? base_station_id_code 63 ? ms max power 15 ? cell reselection hysteresis 4 ? rxlev access min 0 ? radio-link-timeout 32 ? channel allocator ascending ? rach tx integer 9 ? rach max transmission 7 ? channel-descrption attach 1 ? channel-descrption bs-pa-mfrms 5 ? channel-descrption bs-ag-blks-res 1 ? early-classmark-sending forbidden ? ip.access unit_id 1801 0 ? oml ip.access stream_id 255 line 0 ? codec-support fr ? gprs mode none ? trx 0 ?? rf_locked 0 ?? arfcn 871 ?? nominal power 20 ?? ! to use full TRX power, set max_power_red 0 ?? max_power_red 3 ?? rsl e1 tei 0 ?? timeslot 0 ??? phys_chan_config CCCH+SDCCH4 ??? hopping enabled 0 ?? timeslot 1 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 2 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 3 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 4 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 5 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 6 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 7 ??? phys_chan_config TCH/F ??? hopping enabled 0 ! this is BTS1. The ! osmo-bsc default configuration ! (assumes STP to run on 127.0.0.1 and uses default point codes) ! e1_input ?e1_line 0 driver ipa network ?network country code 1 ?mobile network code 1 ?encryption a5 0 ?neci 1 ?paging any use tch 0 ?handover 0 ?handover algorithm 1 ?handover1 window rxlev averaging 10 ?handover1 window rxqual averaging 1 ?handover1 window rxlev neighbor averaging 10 ?handover1 power budget interval 6 ?handover1 power budget hysteresis 3 ?handover1 maximum distance 9999 ?dyn_ts_allow_tch_f 0 ?periodic location update 30 *bts 0** *** type sysmobts ? band DCS1800 ? cell_identity 0 ? location_area_code 1 ? base_station_id_code 63 ? ms max power 15 ? cell reselection hysteresis 4 ? rxlev access min 0 ? radio-link-timeout 32 ? channel allocator ascending ? rach tx integer 9 ? rach max transmission 7 ? channel-descrption attach 1 ? channel-descrption bs-pa-mfrms 5 ? channel-descrption bs-ag-blks-res 1 ? early-classmark-sending forbidden *? ip.access unit_id 1801 0** *? oml ip.access stream_id 255 line 0 ? codec-support fr ? gprs mode none ? trx 0 ?? rf_locked 0 *?? arfcn 871** *?? nominal power 20 ?? ! to use full TRX power, set max_power_red 0 ?? max_power_red 3 ?? rsl e1 tei 0 ?? timeslot 0 ??? phys_chan_config CCCH+SDCCH4 ??? hopping enabled 0 ?? timeslot 1 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 2 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 3 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 4 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 5 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 6 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 7 ??? phys_chan_config TCH/F ??? hopping enabled 0 *bts 1** *** type sysmobts ? band DCS1800 ? cell_identity 0 ? location_area_code 1 ? base_station_id_code 63 ? ms max power 15 ? cell reselection hysteresis 4 ? rxlev access min 0 ? radio-link-timeout 32 ? channel allocator ascending ? rach tx integer 9 ? rach max transmission 7 ? channel-descrption attach 1 ? channel-descrption bs-pa-mfrms 5 ? channel-descrption bs-ag-blks-res 1 ? early-classmark-sending forbidden *? ip.access unit_id 1805 0** *? oml ip.access stream_id 255 line 0 ? codec-support fr ? gprs mode none ? trx 0 ?? rf_locked 0 *?? arfcn 881** *?? nominal power 20 ?? ! to use full TRX power, set max_power_red 0 ?? max_power_red 3 ?? rsl e1 tei 0 ?? timeslot 0 ??? phys_chan_config CCCH+SDCCH4 ??? hopping enabled 0 ?? timeslot 1 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 2 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 3 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 4 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 5 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 6 ??? phys_chan_config TCH/F ??? hopping enabled 0 ?? timeslot 7 ??? phys_chan_config TCH/F ??? hopping enabled 0 msc 0 ?no bsc-welcome-text ?no bsc-msc-lost-text ?no bsc-grace-text ?type normal ?allow-emergency allow ?amr-config 12_2k forbidden ?amr-config 10_2k forbidden ?amr-config 7_95k forbidden ?amr-config 7_40k forbidden ?amr-config 6_70k forbidden ?amr-config 5_90k allowed ?amr-config 5_15k forbidden ?amr-config 4_75k forbidden ?codec-list fr1 fr2 fr3 hr1 hr3 ?mgw remote-ip 127.0.0.1 ?mgw remote-port 2427 ?mgw local-port 2727 ?mgw endpoint-range 1 31 bsc ?mid-call-timeout 0 ?no missing-msc-text Does this look OK to you?? Regards, Gullik -------------- next part -------------- An HTML attachment was scrubbed... URL: From gullik.webjorn at corevalue.se Thu Jan 10 21:37:09 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Thu, 10 Jan 2019 22:37:09 +0100 Subject: Some progress and some questions....corrected In-Reply-To: <26ba2180-3a42-b70d-46ea-92a87348a27b@corevalue.se> References: <26ba2180-3a42-b70d-46ea-92a87348a27b@corevalue.se> Message-ID: <5714557c-e2dc-732c-5557-040050cd9197@corevalue.se> Sorry to clutter the list......last was a cut'n'paste error.... Gullik On 2019-01-10 22:31, Gullik Webjorn wrote: > > I have now built osmo-trx-lms and osmo-bts-trx from source on an i386 > platform. > > I have beacon, and two phones registered, the configuration from msc > and up is the one > > I had three weeks ago, which more or less worked, but with large > stability problems. > > I guess *this* report is the most interesting for you now.... > > I build from the "master", and target debian9 on i386. > > > I have not been able to make a call yet, possibly because I might have > messed up some > > library the MSC is dependent on, but I will work on that. > > What is interesting is that bts 0 trx 0 is running trx-uhd with a > B100, and seems quite stable. > > Moreover, bts 1 trx 0 is running on the i386 and seems happy so far, > after 30 minutes. > > This is Limesdr mini. > > > I have just copied the bts0 to trx 0 section from my original config, > duplicated it and changed > > bts0 to bts1, and the ipa unit-id 1805 0, and of course the ip addresses. > > I will comment the various lines in my configs, as I have understood > them, and look forward to your > > comments, or maybe a keyword list explaining what each parameter is > used for. > > > ! osmo-bsc default configuration > ! (assumes STP to run on 127.0.0.1 and uses default point codes) > ! > e1_input > ?e1_line 0 driver ipa > network > ?network country code 1 > ?mobile network code 1 > ?encryption a5 0 > ?neci 1 > ?paging any use tch 0 > ?handover 0 > ?handover algorithm 1 > ?handover1 window rxlev averaging 10 > ?handover1 window rxqual averaging 1 > ?handover1 window rxlev neighbor averaging 10 > ?handover1 power budget interval 6 > ?handover1 power budget hysteresis 3 > ?handover1 maximum distance 9999 > ?dyn_ts_allow_tch_f 0 > ?periodic location update 30 > *bts 0** > *** type sysmobts > ? band DCS1800 > ? cell_identity 0 > ? location_area_code 1 > ? base_station_id_code 63 > ? ms max power 15 > ? cell reselection hysteresis 4 > ? rxlev access min 0 > ? radio-link-timeout 32 > ? channel allocator ascending > ? rach tx integer 9 > ? rach max transmission 7 > ? channel-descrption attach 1 > ? channel-descrption bs-pa-mfrms 5 > ? channel-descrption bs-ag-blks-res 1 > ? early-classmark-sending forbidden > *? ip.access unit_id 1801 0** > *? oml ip.access stream_id 255 line 0 > ? codec-support fr > ? gprs mode none > ? trx 0 > ?? rf_locked 0 > *?? arfcn 871** > *?? nominal power 20 > ?? ! to use full TRX power, set max_power_red 0 > ?? max_power_red 3 > ?? rsl e1 tei 0 > ?? timeslot 0 > ??? phys_chan_config CCCH+SDCCH4 > ??? hopping enabled 0 > ?? timeslot 1 > ??? phys_chan_config TCH/F > ??? hopping enabled 0 > ?? timeslot 2 > ??? phys_chan_config TCH/F > ??? hopping enabled 0 > ?? timeslot 3 > ??? phys_chan_config TCH/F > ??? hopping enabled 0 > ?? timeslot 4 > ??? phys_chan_config TCH/F > ??? hopping enabled 0 > ?? timeslot 5 > ??? phys_chan_config TCH/F > ??? hopping enabled 0 > ?? timeslot 6 > ??? phys_chan_config TCH/F > ??? hopping enabled 0 > ?? timeslot 7 > ??? phys_chan_config TCH/F > ??? hopping enabled 0 > *bts 1** > *** type sysmobts > ? band DCS1800 > ? cell_identity 0 > ? location_area_code 1 > ? base_station_id_code 63 > ? ms max power 15 > ? cell reselection hysteresis 4 > ? rxlev access min 0 > ? radio-link-timeout 32 > ? channel allocator ascending > ? rach tx integer 9 > ? rach max transmission 7 > ? channel-descrption attach 1 > ? channel-descrption bs-pa-mfrms 5 > ? channel-descrption bs-ag-blks-res 1 > ? early-classmark-sending forbidden > *? ip.access unit_id 1805 0** > *? oml ip.access stream_id 255 line 0 > ? codec-support fr > ? gprs mode none > ? trx 0 > ?? rf_locked 0 > *?? arfcn 881** > *?? nominal power 20 > ?? ! to use full TRX power, set max_power_red 0 > ?? max_power_red 3 > ?? rsl e1 tei 0 > ?? timeslot 0 > ??? phys_chan_config CCCH+SDCCH4 > ??? hopping enabled 0 > ?? timeslot 1 > ??? phys_chan_config TCH/F > ??? hopping enabled 0 > ?? timeslot 2 > ??? phys_chan_config TCH/F > ??? hopping enabled 0 > ?? timeslot 3 > ??? phys_chan_config TCH/F > ??? hopping enabled 0 > ?? timeslot 4 > ??? phys_chan_config TCH/F > ??? hopping enabled 0 > ?? timeslot 5 > ??? phys_chan_config TCH/F > ??? hopping enabled 0 > ?? timeslot 6 > ??? phys_chan_config TCH/F > ??? hopping enabled 0 > ?? timeslot 7 > ??? phys_chan_config TCH/F > ??? hopping enabled 0 > msc 0 > ?no bsc-welcome-text > ?no bsc-msc-lost-text > ?no bsc-grace-text > ?type normal > ?allow-emergency allow > ?amr-config 12_2k forbidden > ?amr-config 10_2k forbidden > ?amr-config 7_95k forbidden > ?amr-config 7_40k forbidden > ?amr-config 6_70k forbidden > ?amr-config 5_90k allowed > ?amr-config 5_15k forbidden > ?amr-config 4_75k forbidden > ?codec-list fr1 fr2 fr3 hr1 hr3 > ?mgw remote-ip 127.0.0.1 > ?mgw remote-port 2427 > ?mgw local-port 2727 > ?mgw endpoint-range 1 31 > bsc > ?mid-call-timeout 0 > ?no missing-msc-text > > Does this look OK to you?? > > Regards, > > Gullik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Jan 11 17:02:31 2019 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 11 Jan 2019 18:02:31 +0100 Subject: OsmoTRX - osmo-trx-usrp-1 Aborted :: Assertion 'px != 0' failed In-Reply-To: <20190110111103.GV606@nataraja> References: <20190110111103.GV606@nataraja> Message-ID: <20190111170231.GT606@nataraja> On Thu, Jan 10, 2019 at 12:11:03PM +0100, Harald Welte wrote: > > Can't find firmware: std.ihx > > This is probably the key here. The firmware file for the USRP1 device was not > found. You could strace osmo-trx-usrp1 to see where it expects that file, and > then try to put it in the right location. > > I think the firmware used to be built together with libusrp, but I don't recall > the details.. It's been so many years back. I've now been working on a series of patches to ensure we build + package the std.ihx firmware file as part of libusrp. See the 'laforge/firmware' branch of libusrp.git. I've also pushed the patches to gerrit for review. NOTE: I've not tested any of this with a USRP1 yet. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From gullik.webjorn at corevalue.se Fri Jan 11 19:35:17 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Fri, 11 Jan 2019 20:35:17 +0100 Subject: Status of 2-bts osmobts @ gullik Message-ID: Just a short update: Orange Pi Zero (armhf) + Ettus B100 ARFCN 871 osmo-trx-uhd_0.4.0.124 unstable after 5-120 minutes. Supermicro I386 + Limesdr mini ARFCN 881 osmo-trx-lms_0.4.0_i386 (built from latest source ) relatively stable. Incoming and outgoing calls OK. PSTN access OK. Sometimes fails with "communication error" as displayed on Nokia, main suspicion is failed trx-uhd ( without handover) will investigate further. Not sure which BTS it was on. As for LimeSDR mini support, best so far, has run overnight. Gullik From axilirator at gmail.com Fri Jan 11 19:58:36 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sat, 12 Jan 2019 02:58:36 +0700 Subject: Status of 2-bts osmobts @ gullik In-Reply-To: References: Message-ID: Hi, > Orange Pi Zero (armhf) + Ettus B100 ARFCN 871 > osmo-trx-uhd_0.4.0.124 unstable after 5-120 minutes. Have you tried to compile OsmoTRX with NEON SMID? See both --with-neon and --with-neon-vfpv4 configure options. Before doing that, make sure that your CPU does support them. This can be checked using 'cat /proc/cpuinfo'. Also, could you please clarify, what do you mean by 'unstable'? > Supermicro I386 + Limesdr mini ARFCN 881 osmo-trx-lms_0.4.0_i386 > (built from latest source ) relatively stable. Most likely, because the CPU does support SSE instructions. Please note that they aren't supported on ARM. > Incoming and outgoing calls OK. PSTN access OK. Sometimes fails > with "communication error" as displayed on Nokia, Please attach the logs and PCAP traces. With best regards, Vadim Yanitskiy. From gullik.webjorn at corevalue.se Fri Jan 11 21:18:05 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Fri, 11 Jan 2019 22:18:05 +0100 Subject: Status of 2-bts osmobts @ gullik In-Reply-To: References: Message-ID: <350467f1-eabe-863b-10e2-e61976f53bc3@corevalue.se> Cpuinfo: root at orangepizero:~# cat /proc/cpuinfo processor??? : 0 model name??? : ARMv7 Processor rev 5 (v7l) BogoMIPS??? : 120.00 Features??? : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer??? : 0x41 CPU architecture: 7 CPU variant??? : 0x0 CPU part??? : 0xc07 CPU revision??? : 5 there are 4 of these.....so multithreading makes sense.....load 85% / 400% htop looks nice.... On 2019-01-11 20:58, Vadim Yanitskiy wrote: > Hi, > >> Orange Pi Zero (armhf) + Ettus B100 ARFCN 871 >> osmo-trx-uhd_0.4.0.124 unstable after 5-120 minutes. > Have you tried to compile OsmoTRX with NEON SMID? > See both --with-neon and --with-neon-vfpv4 configure options. > Before doing that, make sure that your CPU does support them. > This can be checked using 'cat /proc/cpuinfo'. > > Also, could you please clarify, what do you mean by 'unstable'? After 5 to 120 minutes (random) the trx goes into this loop behaviour: Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:1005 [tid=3008443472] new latency: 7:69514 (underrun 0:2524734 vs 4:2524732) Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.01 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.04 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.04 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.04 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.07 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.07 sec. Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:1005 [tid=3008443472] new latency: 7:69515 (underrun 7:2524745 vs 0:2524744) Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.07 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.09 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.09 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.12 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.12 sec. Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:1005 [tid=3008443472] new latency: 7:69516 (underrun 4:2524757 vs 7:2524755) Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.15 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.15 sec. ^Csignal 2 received shutting down??? ---THIS is myself stopping the transceiver. Fri Jan 11 22:00:15 2019 DMAIN <0000> osmo-trx.cpp:435 [tid=3070163440] Shutting down transceiver... Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:307 [tid=3070163440] Stopping the transceiver Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:320 [tid=3070163440] Stopping the device Fri Jan 11 22:00:16 2019 DMAIN <0000> Transceiver.cpp:333 [tid=3070163440] Transceiver stopped Restarting it goes back to proper operation, for x minutes, then it hits this situation. I have seen it recover back to normal once or twice, but often it loops forever as above. Since stopping / starting it corrects the problem, it seems the internal fail-safe mechanizm does not work properly. Some times it exits, i.e. stops by itself. I will get a fingerprint of that... Note I am running the "same build" trx on both systems however I could swap the SDR's to find out if the problem stays with the platform or the sdr device and its particular driver code. > >> Supermicro I386 + Limesdr mini ARFCN 881 osmo-trx-lms_0.4.0_i386 >> (built from latest source ) relatively stable. > Most likely, because the CPU does support SSE instructions. > Please note that they aren't supported on ARM. Yes, this is clear to me, and I will verify compile switches for the Arm cpu. >> Incoming and outgoing calls OK. PSTN access OK. Sometimes fails >> with "communication error" as displayed on Nokia, > Please attach the logs and PCAP traces. I will try to catch relevant info, but it requires "babysitting", to catch, however I can run gdb of course... > > With best regards, > Vadim Yanitskiy. Thanks for your comments, Regards, Gullik From axilirator at gmail.com Fri Jan 11 21:37:44 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sat, 12 Jan 2019 04:37:44 +0700 Subject: Status of 2-bts osmobts @ gullik In-Reply-To: <350467f1-eabe-863b-10e2-e61976f53bc3@corevalue.se> References: <350467f1-eabe-863b-10e2-e61976f53bc3@corevalue.se> Message-ID: Hmm, > Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva > idivt vfpd32 lpae evtstrm feel free to (re)configure: ./configure --with-sse=no --with-neon=yes --with-neon-vfpv4=yes and recompile. Also, I recommend to play with 'rt-prio' VTY option. > Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:1005 > [tid=3008443472] new latency: 7:69514 (underrun 0:2524734 vs 4:2524732) > Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] > Packet loss between host and device at 6618.01 sec. > Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] > Packet loss between host and device at 6618.04 sec. Hmm, I've never seen anything like that. With best regards, Vadim Yanitskiy. From jenkins at lists.osmocom.org Sat Jan 12 02:24:08 2019 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Sat, 12 Jan 2019 02:24:08 +0000 (UTC) Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #356 Message-ID: <87693852.523.1547259848558.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 723.64 KB...] CC RANAP_GeographicalArea.lo CC RANAP_GeographicalCoordinates.lo CC RANAP_GA-EllipsoidArc.lo CC RANAP_GA-AltitudeAndDirection.lo CC RANAP_GA-Point.lo CC RANAP_GA-PointWithAltitude.lo CC RANAP_GA-PointWithAltitudeAndUncertaintyEllipsoid.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_IE-Extensions.h:15, from ../../include/osmocom/ranap/RANAP_GeographicalCoordinates.h:16, from ../../include/osmocom/ranap/RANAP_GA-Point.h:14, from ../../include/osmocom/ranap/RANAP_GeographicalArea.h:14, from RANAP_GeographicalArea.c:7: ../../include/osmocom/ranap/RANAP_GA-Polygon.h:26:23: warning: ?struct Member? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct Member { ^ /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_GA-Polygon.h:26:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct Member { ^~~~~~~~~~~~~ CC RANAP_GA-PointWithUnCertainty.lo CC RANAP_GA-PointWithUnCertaintyEllipse.lo CC RANAP_GA-Polygon.lo CC RANAP_GA-UncertaintyEllipse.lo CC RANAP_GERAN-BSC-Container.lo CC RANAP_GERAN-Cell-ID.lo CC RANAP_GERAN-Classmark.lo CC RANAP_GlobalCN-ID.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_GA-Polygon.h:14, from RANAP_GA-Polygon.c:7: ../../include/osmocom/ranap/RANAP_GA-Polygon.h:26:23: warning: ?struct Member? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct Member { ^ /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_GA-Polygon.h:26:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct Member { ^~~~~~~~~~~~~ CC RANAP_GlobalRNC-ID.lo CC RANAP_GTP-TEI.lo CC RANAP_GuaranteedBitrate.lo CC RANAP_HigherBitratesThan16MbpsFlag.lo CC RANAP_HS-DSCH-MAC-d-Flow-ID.lo CC RANAP_IMEI.lo CC RANAP_IMEIGroup.lo CC RANAP_IMEIList.lo CC RANAP_IMEISV.lo CC RANAP_IMEISVGroup.lo CC RANAP_IMEISVList.lo CC RANAP_ImmediateMDT.lo CC RANAP_IMSI.lo CC RANAP_IncludeVelocity.lo CC RANAP_InformationExchangeID.lo CC RANAP_InformationExchangeType.lo CC RANAP_InformationRequested.lo CC RANAP_InformationRequestType.lo CC RANAP_InformationTransferID.lo CC RANAP_InformationTransferType.lo CC RANAP_IntegrityProtectionAlgorithm.lo CC RANAP_IntegrityProtectionInformation.lo CC RANAP_IntegrityProtectionKey.lo CC RANAP_InterSystemInformationTransferType.lo CC RANAP_InterSystemInformation-TransparentContainer.lo CC RANAP_IPMulticastAddress.lo CC RANAP_IuSignallingConnectionIdentifier.lo CC RANAP_KeyStatus.lo CC RANAP_IuTransportAssociation.lo CC RANAP_LA-LIST.lo CC RANAP_LAC.lo CC RANAP_LAI.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_LA-LIST.h:14, from RANAP_LA-LIST.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 { ^~~~~~~~~~~~~ CC RANAP_LastKnownServiceArea.lo CC RANAP_LastVisitedUTRANCell-Item.lo CC RANAP_LHN-ID.lo CC RANAP_Links-to-log.lo CC RANAP_ListOF-SNAs.lo CC RANAP_ListOfInterfacesToTrace.lo CC RANAP_InterfacesToTraceItem.lo CC RANAP_LoadValue.lo CC RANAP_LocationRelatedDataRequestType.lo CC RANAP_LocationRelatedDataRequestTypeSpecificToGERANIuMode.lo CC RANAP_LocationReportingTransferInformation.lo CC RANAP_ReportChangeOfSAI.lo CC RANAP_PeriodicReportingIndicator.lo CC RANAP_DirectReportingIndicator.lo CC RANAP_L3-Information.lo CC RANAP_M1Report.lo CC RANAP_M2Report.lo CC RANAP_M4Report.lo CC RANAP_M4-Collection-Parameters.lo CC RANAP_M4-Period.lo CC RANAP_M4-Threshold.lo CC RANAP_M5Report.lo CC RANAP_M5-Period.lo CC RANAP_M6Report.lo CC RANAP_M6-Period.lo CC RANAP_M7Report.lo CC RANAP_M7-Period.lo CC RANAP_Management-Based-MDT-Allowed.lo CC RANAP_MaxBitrate.lo CC RANAP_MaxSDU-Size.lo CC RANAP_MBMS-PTP-RAB-ID.lo CC RANAP_MBMSBearerServiceType.lo CC RANAP_MBMSCNDe-Registration.lo CC RANAP_MBMSCountingInformation.lo 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_MeasurementQuantity.lo CC RANAP_MeasurementsToActivate.lo CC RANAP_MSISDN.lo CC RANAP_NAS-SequenceNumber.lo CC RANAP_NAS-PDU.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 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_PositioningPriority.lo 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 /bin/bash: line 1: 2491 Illegal instruction /bin/bash ../../libtool --silent --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.13-45696\" -DPACKAGE_STRING=\"osmo-iuh\ 0.3.0.13-45696\" -DPACKAGE_BUGREPORT=\"openbsc at 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.3.0.13-45696\" -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_PriorityLevel.lo -MD -MP -MF .deps/RANAP_PriorityLevel.Tpo -c -o RANAP_PriorityLevel.lo RANAP_PriorityLevel.c Makefile:2506: recipe for target 'RANAP_PriorityLevel.lo' failed make[4]: *** [RANAP_PriorityLevel.lo] Error 132 make[4]: *** Waiting for unfinished jobs.... 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 { ^~~~~~~~~~~~~ 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 1161 C/C++ compilation units (100%) successfully 1161 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 From gullik.webjorn at corevalue.se Sat Jan 12 12:48:24 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Sat, 12 Jan 2019 13:48:24 +0100 Subject: A ramble about MSC, sip-connector and asterisk. Message-ID: <98b5c383-64f6-aae8-cee0-7982896c1232@corevalue.se> Hi, Some weeks ago I managed to integrate osmobts with my asterisk server. In the beginning, I did not get any call progress, ( as opposed to running WITHOUT asterisk ). I realized that defining the msc to sipconnector socket effectively disabled all the logic related to this. To remedy the situation, I set an asterisk "progress statement" whenever the extensions.conf indicated a number belonging to my GSM network. This works OK, but now, I don't get call progress on calls toward PSTN. These extensions do not have "progress" statements, since all SIP phones interpret the call progress sip messages such as RINGING. I am interested in your comments whether msc + sipconnector should emulate mobiles as "sip phones", it does seem to just silently drop call progress messages, and is this the way it should work? The functionality IS there, since when osmobts was bridging the calls, call progress WAS there. Well, I kludged up a solution for the GSM-only situation, and this seems suboptimal. I guess some clever asterisk hacking would solve that, possibly having a redundant progress statement on ALL extensions would do it, but would I not lose "actual" call progress signals from the PSTN, since asterisk would emulate them? Another way would be a small "local" asterisk.....before the *real* one. Boldly moving on to MultiBTS and handover.... Gullik From djks74 at gmail.com Sat Jan 12 13:00:32 2019 From: djks74 at gmail.com (Sandi Suhendro) Date: Sat, 12 Jan 2019 20:00:32 +0700 Subject: A ramble about MSC, sip-connector and asterisk. In-Reply-To: <98b5c383-64f6-aae8-cee0-7982896c1232@corevalue.se> References: <98b5c383-64f6-aae8-cee0-7982896c1232@corevalue.se> Message-ID: Osmocom stacks doesnt have any problem with some pbx especially asterisk. If you facing cannot get call progress via pstn, please give us details log. One i can remain you, nat also need to be configure to yes for many case. regards, Sandi / DUO On Sat, Jan 12, 2019, 19:48 Gullik Webjorn Hi, > > Some weeks ago I managed to integrate osmobts with my asterisk server. > In the beginning, I did > > not get any call progress, ( as opposed to running WITHOUT asterisk ). I > realized that defining > > the msc to sipconnector socket effectively disabled all the logic > related to this. > > To remedy the situation, I set an asterisk "progress statement" whenever > the extensions.conf > > indicated a number belonging to my GSM network. This works OK, but now, > I don't get call progress > > on calls toward PSTN. These extensions do not have "progress" > statements, since all SIP phones > > interpret the call progress sip messages such as RINGING. > > > I am interested in your comments whether msc + sipconnector should > emulate mobiles as "sip phones", > > it does seem to just silently drop call progress messages, and is this > the way it should work? > > The functionality IS there, since when osmobts was bridging the calls, > call progress WAS there. > > Well, I kludged up a solution for the GSM-only situation, and this seems > suboptimal. > > I guess some clever asterisk hacking would solve that, possibly having a > redundant progress statement > > on ALL extensions would do it, but would I not lose "actual" call > progress signals from the PSTN, > > since asterisk would emulate them? Another way would be a small "local" > asterisk.....before the *real* one. > > Boldly moving on to MultiBTS and handover.... > > Gullik > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gullik.webjorn at corevalue.se Sat Jan 12 19:22:05 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Sat, 12 Jan 2019 20:22:05 +0100 Subject: Balancing BTS'es for handover Message-ID: Below is a measurement on my "most distant" BTS, BTS 1. From what I see, downlink is 35 dB below uplink, which of course is natural when the MS can produce 30 dBm, and the BTS which in this case uses a bareback Limesdr min, can only produce 10 dBm. the bsc parameter ms max power is set to 15 for both bts 0 and bts 1. However, it seems MS output power is *much* stronger. Further, my understanding is that it is the BTS level measurements that decides when to handover, i.e. measurements in the upstream, and not the MS receive levels... Since there is such a mismatch between the micro BTS and the MS, maybe the RX should be attenuated, to bring upsteram levels more equal to downstream. OsmoBSC# show conns Active subscriber connections: conn ID=6, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1 at mgw BTS 0, TRX 0, Timeslot 1, Lchan 0: Type TCH_F ? Connection: 1, State: ESTABLISHED ? BS Power: 20 dBm, MS Power: 16 dBm ? Channel Mode / Codec: SPEECH_V1 ? No Subscriber ? Bound IP: 127.0.0.1 Port 16390 RTP_TYPE2=0 CONN_ID=0 ? Conn. IP: 192.168.1.70 Port 4186 RTP_TYPE=3 SPEECH_MODE=0x00 ? Measurement Report: ??? Flags: ??? MS Timing Offset: 0 ??? L1 MS Power: 16 dBm, Timing Advance: 0 ??? RXL-FULL-dl: -110 dBm, RXL-SUB-dl: -110 dBm RXQ-FULL-dl: 5, RXQ-SUB-dl: 5 ??? RXL-FULL-ul:? -74 dBm, RXL-SUB-ul:? -73 dBm RXQ-FULL-ul: 3, RXQ-SUB-ul: 1 What are *your* experiences with "power control" and with "handover". Best Regards, Gullik From jenkins at lists.osmocom.org Sun Jan 13 02:30:47 2019 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Sun, 13 Jan 2019 02:30:47 +0000 (UTC) Subject: Jenkins build is back to normal : Coverity-Upload (jenkins-job-builder) #357 In-Reply-To: <87693852.523.1547259848558.JavaMail.jenkins@jenkins.osmocom.org> References: <87693852.523.1547259848558.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <529240095.544.1547346647570.JavaMail.jenkins@jenkins.osmocom.org> See From laforge at gnumonks.org Sun Jan 13 09:24:23 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 13 Jan 2019 10:24:23 +0100 Subject: uncalibrated general-purpose SDRs (was Re: Balancing BTS'es for handover) In-Reply-To: References: Message-ID: <20190113092423.GJ606@nataraja> Hi Gullik, On Sat, Jan 12, 2019 at 08:22:05PM +0100, Gullik Webjorn wrote: > Below is a measurement on my "most distant" BTS, BTS 1. From what I see, > downlink is 35 dB What do you mean by "downlink is 35dB"? > below uplink, which of course is natural when the MS can produce 30 dBm, and > the BTS which > > in this case uses a bareback Limesdr min, can only produce 10 dBm. If you are using a general-purpose SDR hardware you cannot expect that any of the signal levels written anywhere actually meany anything at all. There is no absolute levels reported by SDR hardware anywhere, and there is no calibration of either transmit nor receiver. This means: * there's no general calibration curve for the chip/board * there's no per-unit individual calibration curve for the unit you have This is *very* different from a real GSM base station. Without designing a calibration procedure for the above, as well as some mechanism to apply it in production, I don't think one can expect any of the readings to state anything realistic, nor expect any power control loops to operate. Please don't get me wrong, general-purpose SDRs such as USRPs or LimeSDR are great tools for experiments in the lab. But that's what they are - at least for the time being. There is a *big* difference between a real-world base station and a GP-SDR board. > the bsc parameter ms max power is set to 15 for both bts 0 and bts 1. > However, it seems MS output power is *much* stronger. The 16dBm is probably the closest one can get to the 15 dBm you requested: > ??? L1 MS Power: 16 dBm, Timing Advance: 0 How do you establish this fact? Did you attach a RF power meter to the MS output and masure the output power? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From domi at tomcsanyi.net Sun Jan 13 10:17:33 2019 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Sun, 13 Jan 2019 11:17:33 +0100 (CET) Subject: uncalibrated general-purpose SDRs (was Re: Balancing BTS'es for handover) In-Reply-To: <20190113092423.GJ606@nataraja> References: <20190113092423.GJ606@nataraja> Message-ID: <57FBE5D1-338D-490A-AFBD-E99AD4DD9CBB@tomcsanyi.net> Hi Harald, Just a fun fact: afaik current commercial multi-purpose (2G/3G/4G) base stations use generic SDRs to accomplish support for all technologies in a compact package. Of course those SDRs are in a completely different league in terms of accuracy, calibration and price :). Cheers, Domi 2019. jan. 13. d?tummal, 10:30 id?pontban Harald Welte ?rta: > Hi Gullik, > >> On Sat, Jan 12, 2019 at 08:22:05PM +0100, Gullik Webjorn wrote: >> Below is a measurement on my "most distant" BTS, BTS 1. From what I see, >> downlink is 35 dB > > What do you mean by "downlink is 35dB"? > >> below uplink, which of course is natural when the MS can produce 30 dBm, and >> the BTS which >> >> in this case uses a bareback Limesdr min, can only produce 10 dBm. > > If you are using a general-purpose SDR hardware you cannot expect that > any of the signal levels written anywhere actually meany anything at > all. There is no absolute levels reported by SDR hardware anywhere, and > there is no calibration of either transmit nor receiver. This means: > * there's no general calibration curve for the chip/board > * there's no per-unit individual calibration curve for the unit you have > > This is *very* different from a real GSM base station. Without > designing a calibration procedure for the above, as well as some > mechanism to apply it in production, I don't think one can expect any of > the readings to state anything realistic, nor expect any power control loops > to operate. > > Please don't get me wrong, general-purpose SDRs such as USRPs or LimeSDR > are great tools for experiments in the lab. But that's what they are - > at least for the time being. There is a *big* difference between a > real-world base station and a GP-SDR board. > >> the bsc parameter ms max power is set to 15 for both bts 0 and bts 1. >> However, it seems MS output power is *much* stronger. > > The 16dBm is probably the closest one can get to the 15 dBm you > requested: >> L1 MS Power: 16 dBm, Timing Advance: 0 > > How do you establish this fact? Did you attach a RF power meter to the > MS output and masure the output power? > > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) From gullik.webjorn at corevalue.se Sun Jan 13 12:32:25 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Sun, 13 Jan 2019 13:32:25 +0100 Subject: uncalibrated general-purpose SDRs (was Re: Balancing BTS'es for handover) In-Reply-To: <20190113092423.GJ606@nataraja> References: <20190113092423.GJ606@nataraja> Message-ID: <69b53427-871f-ee47-f2c9-df77c6253c4a@corevalue.se> Thanks Harald, On 2019-01-13 10:24, Harald Welte wrote: > Hi Gullik, > > On Sat, Jan 12, 2019 at 08:22:05PM +0100, Gullik Webjorn wrote: >> Below is a measurement on my "most distant" BTS, BTS 1. From what I see, >> downlink is 35 dB > What do you mean by "downlink is 35dB"? This is what osmocom thinks, if I understand correctly. 110 -74 = 36 (ok, i was careless in subtracting) i.e. osmocom thinks that the level it sees is -74, and the mobile reports a signal of -110 , Right?? ??? RXL-FULL-dl: -110 dBm, RXL-SUB-dl: -110 dBm RXQ-FULL-dl: 5, RXQ-SUB-dl: 5 ??? RXL-FULL-ul:? -74 dBm, RXL-SUB-ul:? -73 dBm RXQ-FULL-ul: 3, RXQ-SUB-ul: 1 > >> below uplink, which of course is natural when the MS can produce 30 dBm, and >> the BTS which >> >> in this case uses a bareback Limesdr min, can only produce 10 dBm. Given that the mobile *can* produce up to 30 dBm, and the limesdr *can* produce 10 dBm, the asymmetry makes sense. But 36 dB = 4000 !! > If you are using a general-purpose SDR hardware you cannot expect that > any of the signal levels written anywhere actually meany anything at > all. There is no absolute levels reported by SDR hardware anywhere, and > there is no calibration of either transmit nor receiver. This means: > * there's no general calibration curve for the chip/board > * there's no per-unit individual calibration curve for the unit you have > > This is *very* different from a real GSM base station. Without > designing a calibration procedure for the above, as well as some > mechanism to apply it in production, I don't think one can expect any of > the readings to state anything realistic, nor expect any power control loops > to operate. > > Please don't get me wrong, general-purpose SDRs such as USRPs or LimeSDR > are great tools for experiments in the lab. But that's what they are - > at least for the time being. There is a *big* difference between a > real-world base station and a GP-SDR board. Yes, I do understand this, but thought that there *was* at least a power loop, where osmobsc tells the mobile to increase or decrease power based on rx level. For a particular SDR, it should be possible to have a rough calibration based on the similarity of devices. Also, manual attenuation to bring levels within reasonable range can be done with sdr gain adjust or attenuation pads. Some years ago when I was playing with OpenBTS, i spent a lot of time trying to get the correct TX level and RX gain, so that up and downlink were within some reasonable levels, and the BER was OK. Being a novice with osmobts, I am aiming for the same thing, eliminating small issues one at the time. >> the bsc parameter ms max power is set to 15 for both bts 0 and bts 1. >> However, it seems MS output power is *much* stronger. > The 16dBm is probably the closest one can get to the 15 dBm you > requested: This is fine by me, and should I interpret this as the power loop in osmocom *works*, and that it has actually downregulater mobile power output to a "correct" value? Or, has the BSC just set the power to 15 db ( as in the config file) without regard of the uplink level measured ( -74 dBm? with uncertain accuracy )? >> ??? L1 MS Power: 16 dBm, Timing Advance: 0 The 16 dBm, is what the mobile reports, right? > How do you establish this fact? Did you attach a RF power meter to the > MS output and masure the output power? > I have not got to this point yet, but I have a suitable power meter, and a spectrum analyzer, so there are tests to be done once I have the setup stable. I am trying to get this to work the way you intended, so that enabling handover has a chance of succeeding. Some figures *you* have been aiming for would be nice.... Again, thanks for your reply, this is really fun.....and educational... Best Regards, Gullik From laforge at gnumonks.org Sun Jan 13 16:11:10 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 13 Jan 2019 17:11:10 +0100 Subject: uncalibrated general-purpose SDRs (was Re: Balancing BTS'es for handover) In-Reply-To: <57FBE5D1-338D-490A-AFBD-E99AD4DD9CBB@tomcsanyi.net> References: <20190113092423.GJ606@nataraja> <57FBE5D1-338D-490A-AFBD-E99AD4DD9CBB@tomcsanyi.net> Message-ID: <20190113161110.GN606@nataraja> Hi Domi, On Sun, Jan 13, 2019 at 11:17:33AM +0100, Tomcs?nyi, Domonkos wrote: > Just a fun fact: afaik current commercial multi-purpose (2G/3G/4G) base stations use generic SDRs to accomplish support for all technologies in a compact package. Sure. I think it's not so much the size of the package, but mostly the software reconfiguration part for so-called "spectrum re-farming". This allows you to scale down the number of GSM carriers and scale up the number/width of LTE carriers without any on-site visits. > Of course those SDRs are in a completely different league in terms of > accuracy, calibration and price :). When I said "general-pursose SDR" I was referring to a USRP-style or LimeSDR-style device. This means, basically 1) wide-band radio front-ends without band filters 2) IF or baseband filters that are muhc wider than GSM channels 3) all processing on general-purpose CPUs (as opposed to ASICs, DSPs or FPGAs) 4) no calibration of the RF output power over frequency and temperauture 5) no calibration of the Rx signal level over frequency and temperature 6) no clock that conforms even remotely to 3GPP accuracy requirements Of course not all of those topics are realted to the original discussion, and of course you can still use a general-purpose SDR as one element of a real-world base station. But then you have to add at least some of the missing elements I described above. For the calibration part: This could all be done in [open source software], if you have a signal generator with known/defined signal level. It would be a great project to define a calibration setup to determine calibration tables for Rx and Tx levels over (at least) frequency. OsmoBTS already has support for applying calibration tables on the transmit side, which were originally intended in case you add an external, non-linear-gain PA to a previously calibrated BTS. That could possibly be extended? For the receive side, no support exist. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sun Jan 13 16:31:30 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 13 Jan 2019 17:31:30 +0100 Subject: uncalibrated general-purpose SDRs (was Re: Balancing BTS'es for handover) In-Reply-To: <69b53427-871f-ee47-f2c9-df77c6253c4a@corevalue.se> References: <20190113092423.GJ606@nataraja> <69b53427-871f-ee47-f2c9-df77c6253c4a@corevalue.se> Message-ID: <20190113163130.GP606@nataraja> Hi Gullik, On Sun, Jan 13, 2019 at 01:32:25PM +0100, Gullik Webjorn wrote: > > On Sat, Jan 12, 2019 at 08:22:05PM +0100, Gullik Webjorn wrote: > > > Below is a measurement on my "most distant" BTS, BTS 1. From what I see, > > > downlink is 35 dB > > What do you mean by "downlink is 35dB"? > > This is what osmocom thinks, if I understand correctly. > > 110 -74 = 36 (ok, i was careless in subtracting) > > i.e. osmocom thinks that the level it sees is -74, and the mobile reports a > signal of -110 , Right?? Yes. However, the big difference is that the mobile has been calibrated to (if I remember) 2dB accuracy, while the GP-SDR based BTS has not been at all. > Given that the mobile *can* produce up to 30 dBm, and the limesdr *can* > produce 10 dBm, FYI: I've never seen a LimeSDR generate anywhre near 10dBm of a GSM carrier. > the asymmetry makes sense. But 36 dB = 4000 !! Yes, if such readings were correct, you'd have an unbalanced link. I'm still not really clear what you're trying to say here. I somehow have the feeling that between the lines you're saying the weak downlink should have an influence on the uplink? That's now how GSM power control is specified. > Yes, I do understand this, but thought that there *was* at least a power > loop, where osmobsc tells the mobile to increase or decrease power based on rx level. yes, there is. There's an uplink target receive level to which the power control loop will try to adjust. This is -75 dBm by default, and can be configured using 'uplink-power-target' at the BTS node of the configuration. > For a particular SDR, it should be possible to have a rough calibration > based on the similarity of devices. yes, it should be possible. Yet, nobody of the many users or proponents of related devices have been working on anything like that, to the best of my knowledge. I would love to see work in that area, and I'm honestly surprised that nobody with an interest in this has been doing so during the past almost 10 years of OpenBTS and OsmoBTS being out there. At least not in the public. > This is fine by me, and should I interpret this as the power loop in > osmocom *works*, and that it has actually downregulater mobile power > output to a "correct" value? If the "L1 MS Power" as seen in "show lchan" changes depending on your path loss, then the power control loop is working. You can also enable "logging level loop debug" to see it in action. > Or, has the BSC just set the power to 15 db ( as in the config file) without > regard of the uplink level measured ( -74 dBm? with uncertain accuracy )? Simply adjust your path loss by increasing attenuation between BTS and MS and see if the L1 MS Power increments. Please note that "-74 dBm" are by no means -74dBm at all due to the lack of any calibration. However, as long as OsmoBTS thinks it's -74 dBm, it thinks it's almost exactly at the target receive level of the uplink power control loop. > > > ??? L1 MS Power: 16 dBm, Timing Advance: 0 > The 16 dBm, is what the mobile reports, right? > > How do you establish this fact? Did you attach a RF power meter to the > > MS output and masure the output power? > > > I have not got to this point yet, but I have a suitable power meter, and a > spectrum analyzer, > > so there are tests to be done once I have the setup stable. > > I am trying to get this to work the way you intended, so that enabling > handover has a chance > of succeeding. Some figures *you* have been aiming for would be nice.... Seriously: We are aiming for "figures" that reflect absolute power levels, everything else feels like stumbling in the dark. I think that the best way to go ahead is to ensure that OsmoBTS is able to deal with loosely calibated (let's say compensated? absolute?) values. All the algoriths deal with that as input data, and trying to get them working without getting that first stepping stone right feels like trying to build the first floor without the foundation first. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From allexander.alex at gmail.com Sun Jan 13 22:14:18 2019 From: allexander.alex at gmail.com (Alex) Date: Sun, 13 Jan 2019 23:14:18 +0100 Subject: OsmoTRX + LimeSDR + Pine64 Message-ID: Hi everyone, I'm facing a little strange problem with latest version of OsmoTRX and LimeSDR on a Pine64 board. I've built everything from source (latest git commit) Here is the console output of osmo-trx-lms root at pine64:~/osmo-trx# osmo-trx-lms -C /opt/osmocom/etc/osmo-trx-limesdr.cfg Sun Jan 13 22:11:40 2019 DLGLOBAL <0004> telnet_interface.c:104 Available via telnet 127.0.0.1 4237 Sun Jan 13 22:11:40 2019 DLCTRL <000b> control_if.c:911 CTRL at 127.0.0.1 4236 Sun Jan 13 22:11:40 2019 DMAIN <0000> osmo-trx.cpp:430 [tid=281473725702144] Config Settings Log Level............... 0 Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 GSM BTS Address......... 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ 0 Reference............... 0 C0 Filler Table......... 1 Multi-Carrier........... 0 Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 Tx Antennas............. 'BAND1' Rx Antennas............. 'LNAW' Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:68 [tid=281473725702144] creating LMS device... Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:156 [tid=281473725702144] Opening LMS device.. Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:162 [tid=281473725702144] Devices found: 1 Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:172 [tid=281473725702144] Device [0]: LimeSDR Mini, media=USB 2.0, module=FT601, addr=24607:1027, serial=1D4259C8DFD3CD Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:181 [tid=281473725702144] Using device[0] Sun Jan 13 22:11:40 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] Reference clock 40.00 MHz Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:191 [tid=281473725702144] Init LMS device Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:113 [tid=281473725702144] Sample Rate: Min=100000 Max=3.072e+07 Step=0 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:201 [tid=281473725702144] Setting sample rate to 1.08333e+06 4 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:207 [tid=281473725702144] Sample Rate: Host=1.08333e+06 RF=3.46667e+07 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:214 [tid=281473725702144] Setting Internal clock reference Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:218 [tid=281473725702144] Setting VCTCXO to 180 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:113 [tid=281473725702144] LPFBWRange Rx: Min=1.4001e+06 Max=1.3e+08 Step=0 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:113 [tid=281473725702144] LPFBWRange Tx: Min=1.4001e+06 Max=1.3e+08 Step=0 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:242 [tid=281473725702144] LPFBW: Rx=1.4001e+06 Tx=5.2e+06 Sun Jan 13 22:11:41 2019 DMAIN <0000> LMSDevice.cpp:203 [tid=281473725702144] Antennas configured successfully Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:251 [tid=281473725702144] Setting LPFBW chan 0 Sun Jan 13 22:11:44 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] RX LPF configured Sun Jan 13 22:11:44 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] Filter calibrated. Filter order-4th, filter bandwidth set to 5.2 MHz.Real pole 1st order filter set to 2.5 MHz. Preemphasis filter not active Sun Jan 13 22:11:44 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] TX LPF configured Sun Jan 13 22:11:44 2019 DDEV <0002> LMSDevice.cpp:256 [tid=281473725702144] Calibrating chan 0 Sun Jan 13 22:11:44 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] Rx calibration finished Sun Jan 13 22:11:44 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] Tx calibration finished osmo-trx-lms: Threads.cpp:133: void Thread::start(void* (*)(void*), void*): Assertion `!res' failed. signal 6 received talloc report on 'OsmoTRX' (total 3427 bytes in 17 blocks) telnet_connection contains 1 bytes in 1 blocks (ref 0) 0xf748b60 logging contains 3043 bytes in 9 blocks (ref 0) 0xf6c44f0 struct trx_ctx contains 383 bytes in 5 blocks (ref 0) 0xf6c4220 msgb contains 0 bytes in 1 blocks (ref 0) 0xf6c41b0 full talloc report on 'OsmoTRX' (total 3427 bytes in 17 blocks) telnet_connection contains 1 bytes in 1 blocks (ref 0) 0xf748b60 logging contains 3043 bytes in 9 blocks (ref 0) 0xf6c44f0 Configure logging Set the log level for a specified category Main generic category TRX CTRL interface Device/Driver specific code Logging from within LimeSuite itself Library-internal global log family LAPD in libosmogsm A-bis Intput Subsystem A-bis B-Subchannel TRAU Frame Multiplex A-bis Input Driver for Signalling A-bis Input Driver for B-Channels (voice) Layer3 Short Message Service (SMS) Control Interface GPRS GTP library Statistics messages and logging Generic Subscriber Update Protocol Osmocom Authentication Protocol libosmo-sigtran Signalling System 7 libosmo-sigtran SCCP Implementation libosmo-sigtran SCCP User Adaptation libosmo-sigtran MTP3 User Adaptation libosmo-mgcp Media Gateway Control Protocol libosmo-netif Jitter Buffer Deprecated alias for 'no logging level force-all' contains 798 bytes in 1 blocks (ref 0) 0xf7019a0 logging level (main|trxctrl|dev|lms|lglobal|llapd|linp|lmux|lmi|lmib|lsms|lctrl|lgtp|lstats|lgsup|loap|lss7|lsccp|lsua|lm3ua|lmgcp|ljibuf) everything contains 150 bytes in 1 blocks (ref 0) 0xf7017f0 Configure logging Set the log level for a specified category Main generic category TRX CTRL interface Device/Driver specific code Logging from within LimeSuite itself Library-internal global log family LAPD in libosmogsm A-bis Intput Subsystem A-bis B-Subchannel TRAU Frame Multiplex A-bis Input Driver for Signalling A-bis Input Driver for B-Channels (voice) Layer3 Short Message Service (SMS) Control Interface GPRS GTP library Statistics messages and logging Generic Subscriber Update Protocol Osmocom Authentication Protocol libosmo-sigtran Signalling System 7 libosmo-sigtran SCCP Implementation libosmo-sigtran SCCP User Adaptation libosmo-sigtran MTP3 User Adaptation libosmo-mgcp Media Gateway Control Protocol libosmo-netif Jitter Buffer Log debug messages and higher levels Log informational messages and higher levels Log noticeable messages and higher levels Log error messages and higher levels Log only fatal messages contains 933 bytes in 1 blocks (ref 0) 0xf7013e0 logging level (main|trxctrl|dev|lms|lglobal|llapd|linp|lmux|lmi|lmib|lsms|lctrl|lgtp|lstats|lgsup|loap|lss7|lsccp|lsua|lm3ua|lmgcp|ljibuf) (debug|info|notice|error|fatal) contains 171 bytes in 1 blocks (ref 0) 0xf701230 struct log_target contains 214 bytes in 2 blocks (ref 0) 0xf6c4940 struct log_category contains 46 bytes in 1 blocks (ref 0) 0xf6c4a50 struct log_info contains 776 bytes in 2 blocks (ref 0) 0xf6c4560 struct log_info_cat contains 736 bytes in 1 blocks (ref 0) 0xf6c45f0 struct trx_ctx contains 383 bytes in 5 blocks (ref 0) 0xf6c4220 LNAW contains 5 bytes in 1 blocks (ref 0) 0xf748fd0 BAND1 contains 6 bytes in 1 blocks (ref 0) 0xf748ec0 127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0xf6c4470 127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0xf6c43f0 msgb contains 0 bytes in 1 blocks (ref 0) 0xf6c41b0 Aborted Can someone provide me a little light on this? I've some doubts about the usb power output, but I'm facing this also with a powered usb hub. Thank you and best regards Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Sun Jan 13 22:35:06 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 14 Jan 2019 05:35:06 +0700 Subject: OsmoTRX + LimeSDR + Pine64 In-Reply-To: References: Message-ID: Hello, > osmo-trx-lms: Threads.cpp:133: > void Thread::start(void* (*)(void*), void*): Assertion `!res' failed. > [...] > Can someone provide me a little light on this? As far as I can see, pthread_attr_setstacksize() fails to set required stack size for a thread. Probably, the amount of RAM is not enough. But in general, this part of code looks dirty: > /** A C++ wrapper for pthread threads. */ > class Thread { > /* ... */ > // FIXME -- Can this be reduced now? > size_t mStackSize; > > /* ... */ > /** Create a thread in a non-running state. */ > Thread(size_t wStackSize = (65536*4)):mThread((pthread_t)0) { > pthread_attr_init(&mAttrib); // (pat) moved this here. > mStackSize=wStackSize; > } > /* ... */ I am now wondering, where does this magic 65536*4 comes from, and how can we estimate and adjust this properly? With best regards, Vadim Yanitskiy. From allexander.alex at gmail.com Sun Jan 13 22:38:34 2019 From: allexander.alex at gmail.com (Alex) Date: Sun, 13 Jan 2019 23:38:34 +0100 Subject: OsmoTRX + LimeSDR + Pine64 In-Reply-To: References: Message-ID: Hi Vadim, A ram issue seems strange to me... The board has 2 gb of ram and I also successfully run the same config on a 1 gb virtual machine. Maybe a kernel limitation? Thank you and best regards Alex On Sun, 13 Jan 2019, 23:35 Vadim Yanitskiy Hello, > > > osmo-trx-lms: Threads.cpp:133: > > void Thread::start(void* (*)(void*), void*): Assertion `!res' failed. > > [...] > > Can someone provide me a little light on this? > > As far as I can see, pthread_attr_setstacksize() fails to set > required stack size for a thread. Probably, the amount of RAM > is not enough. But in general, this part of code looks dirty: > > > /** A C++ wrapper for pthread threads. */ > > class Thread { > > /* ... */ > > // FIXME -- Can this be reduced now? > > size_t mStackSize; > > > > /* ... */ > > /** Create a thread in a non-running state. */ > > Thread(size_t wStackSize = (65536*4)):mThread((pthread_t)0) { > > pthread_attr_init(&mAttrib); // (pat) moved this here. > > mStackSize=wStackSize; > > } > > /* ... */ > > I am now wondering, where does this magic 65536*4 comes from, > and how can we estimate and adjust this properly? > > With best regards, > Vadim Yanitskiy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mychaela.falconia at gmail.com Sun Jan 13 22:46:39 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Sun, 13 Jan 2019 14:46:39 -0800 Subject: GSM MS Tx power levels (was Re: uncalibrated general-purpose SDRs (was Re: Balancing BTS'es for handover)) Message-ID: Harald Welte wrote: > [...] the big difference is that the mobile has been calibrated to > (if I remember) 2dB accuracy, The GSM 05.05 spec indeed sets a tolerance of 2 dB under normal conditions or 2.5 dB under extreme conditions on the mobile station's maximum power output level for each band. These tolerances get looser for the lower power control level, up to 5 dB under normal conditions or 6 dB under extreme conditions for the lowest PCL. However, as someone who is intimately familiar with the actual calibration procedures performed by MS manufacturers (just did it myself less than 48 hours ago for a new batch of boards), I can tell you how it is actually done. There is a table of target power levels in dBm, and the calibration station goes through the full set of allowed PCLs (5-19 for EGSM and GSM850, or 0-15 for DCS and PCS) and steers the Tx power output (as measured by the test instrument, usually R&S CMU200) for each PCL to the dBm number in the table. But there is a hack in this setup which most MS manufacturers fail to disclose: with all GSM MS RF designs I have laid my hands on so far, including the one I've inherited from Openmoko (OK, I admit that all of my experience is with old stuff, not any of the recent stuff from MTK or Spreadtrum, but don't blame me, blame MTK and Spreadtrum for not publicly releasing their full chip docs and reference firmware source code), the MS hardware is oftentimes not actually capable of putting out the maximum power output prescribed by the spec (33 dBm for low bands or 30 dBm for high bands) while staying in the linear range of the PA (the range in which the relation between the APC control voltage and RF Vout is mostly linear), and thus the calibration procedure has to be fudged. In the case of Openmoko, they set the calibration targets for the highest power levels to 31.8 dBm and 28.8 dBm instead of 33/30 (for low and high bands, respectively), the next PCL down is set to 30.5/27.5 instead of 31/28, and then the proper official numbers from the spec further down. I have to do the same on my current GSM MS boards: when I tried putting out the full 33/30 dBm at the maximum PCL as the spec calls for, I can usually hit it if I crank the PA really high, but then it goes out of its linear range, and lacking better RF kung-fu, I have to assume that it's bad.. The maximum Tx power level fudging done by manufacturers in my or Openmoko's position is 1.2 dB, which is less than the spec tolerance of 2 dB, thus manufacturers like OM who did this fudging had no problems passing type approval tests, but I really wish I could find someone with more professional GSM MS design and manufacturing experience who could explain what actually happens, why we are not able hit the highest power levels while staying in the PA's linear range (the PA datasheet says it can put out 34.2 dBm in the low bands and 32.0 dBm in the high bands), and how the RF hw design might be improved so we can put out the highest power levels without fudging. Aside from the just-described fudging, the actual calibration tolerance (the maximum error between what the calibration procedure aims for and what actually comes out as measured by the CMU200) is less than 0.7 dB - and those ~0.5-0.6 dB errors happen mostly toward the lower power levels where the spec tolerances are the loosest; the maximum power level is calibrated to the shifted target number to better than 0.1 dB. M~ From nhofmeyr at sysmocom.de Mon Jan 14 02:03:56 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 14 Jan 2019 03:03:56 +0100 Subject: GSUP: E-interface messages for inter-MSC HO Message-ID: <20190114020356.GA12467@my.box> Hi Oliver, I've already spent some time on a first draft for the new messages we will need to implement the E-interface via GSUP for inter-MSC handover. It would be excellent if you could take over from what I have so far. I placed the draft in osmo-msc/doc/interMSC_HO_GSUP_msgs.txt on my branch neels/ho: http://git.osmocom.org/osmo-msc/tree/doc/interMSC_HO_GSUP_msgs.txt?h=neels/ho Anyone else is also more than welcome to take a look and remark on anything that might seem a bad idea, etc. This is the result of me reading a MAP trace of two MSCs negotiating inter-MSC handovers, and of reading the 29.002, 29.010,... specs. I'm not permitted to freely share the trace, let me know if you need details. The most interesting bits in the draft are - the new message types - the newly added IEs (see "Of which are newly added...") The tasks for you would be: - Spell out the protocol messages in common/chapters/gsup.adoc - Implement the definitions in gsup.h - Implement encoding and decoding, and tests It is not so trivial to understand what goes with which message; maybe you don't even need to know in detail? But if any info is still missing for you to grok what's going on, don't hesitate to ask, as always. Also interesting to figure out: Implement the IPA routing for which I added the source_name and destination_name IEs: N osmo-mscs connected to one osmo-hlr forward messages to each other via GSUP. - Connect two GSUP clients (test programs?) to a running osmo-hlr instance, and to extend the gsup_server so that we can use the source_name/destination_name IEs to forward GSUP messages between the two clients. (I added these because I'm fairly certain there is no existing in-band IPA protocol bits that would allow such routing; but I only briefly skimmed it, wouldn't hurt if you could verify that again.) The aim is to have plain gsup_client API to allow me to "just send messages back and fort". - The session_id/session_state: we still need to figure out how to avoid collisions in session_id numbers, as any peer may at any point re-use the same session_id. Vadim suggested using a TI flag that gets flipped between sender and receiver, but since there are more than two peers, I guess we should treat each session_id as subordinate to a Request's source_name. IOW, any peer owns the entire session_id number space itself for sending out Request message types, and a Response or Error message type echos this session_id back with the source_name then having become the destination_name; it is perfectly legal for two peers to use the same session_id and collisions are avoided by Request vs. Response/Error. Something like... MSC-A MSC-B MSC-B' -------> FOO_REQUEST(source=alice, destination=bob, id=3, state=BEGIN) <------- FOO_RESPONSE(source=bob, destination=alice, id=3, state=CONTINUE) -------> BAR_REQUEST(source=alice, destination=bob, id=3, state=CONTINUE) <------- BAR_RESPONSE(source=alice, destination=bob, id=3, state=CONTINUE) ---------------> FOO_REQUEST(source=alice, destination=fred, id=4, state=BEGIN) <--------------- FOO_ERROR(source=fred, destination=alice, id=4, state=CONTINUE) ---------------> END_REQUEST(source=alice, destination=fred, id=4, state=END) -------> END_REQUEST(source=alice, destination=bob, id=3, state=END) (We could possibly omit the source_name in Response/Error message types, because the Requestor already knows the peer from sending out the Request; but for sanity, maybe rather always keep both names.) Does this make sense / am I missing something? - And we need to make sure that we can freely re-use the session_id IE on the E-interface without conflicting with the Supplementary Services session_id / without confusing the gsup_client API. Please create issues on osmocom.org for these tasks as you see fit. There is no pressing need yet to get this done *right now*, I have yet to complete the inter-BSC HO in osmo-msc before I can start using GSUP. But it would be great to just build on working API once I need it. I would be super grateful if you could relieve me of the burden of spelling out these details. From the meetings I assume that sysmocom agrees; please manage that, too, and let me know if any other tasks are more important... Thanks!! ~N -- - Neels Hofmeyr 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From axilirator at gmail.com Mon Jan 14 03:42:05 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 14 Jan 2019 10:42:05 +0700 Subject: Google Summer of Code 2019 Message-ID: Dear Osmocom community, starting from 16th of January (until 7th of February) we can apply Google Summer of Code as an Open source mentor organization. Many well-known projects, such as Debian, FFmpeg, Apache, Git, GCC, GNURadio and others, have been participating last year. Personally, I think it's a great opportunity to move some of our projects forward. I would like to know your opinions about this idea, should we participate? I would be happy to be a mentor. With best regards, Vadim Yanitskiy. From allexander.alex at gmail.com Mon Jan 14 07:48:54 2019 From: allexander.alex at gmail.com (Alex) Date: Mon, 14 Jan 2019 08:48:54 +0100 Subject: OsmoTRX + LimeSDR + Pine64 In-Reply-To: References: Message-ID: Hi, I made a simple workaround: I yust commented out the two ?assume? directives in start function of Thread.cpp After recompiling everything seems to work properly, so it's OK, but I don't know exactly what checks I'm currently removing and their implications. Anyway, on a pure user experience basis, I can say it works. Best regards Alex On Sun, 13 Jan 2019, 23:38 Alex Hi Vadim, > A ram issue seems strange to me... The board has 2 gb of ram and I also > successfully run the same config on a 1 gb virtual machine. > > Maybe a kernel limitation? > > > Thank you and best regards > Alex > > On Sun, 13 Jan 2019, 23:35 Vadim Yanitskiy >> Hello, >> >> > osmo-trx-lms: Threads.cpp:133: >> > void Thread::start(void* (*)(void*), void*): Assertion `!res' failed. >> > [...] >> > Can someone provide me a little light on this? >> >> As far as I can see, pthread_attr_setstacksize() fails to set >> required stack size for a thread. Probably, the amount of RAM >> is not enough. But in general, this part of code looks dirty: >> >> > /** A C++ wrapper for pthread threads. */ >> > class Thread { >> > /* ... */ >> > // FIXME -- Can this be reduced now? >> > size_t mStackSize; >> > >> > /* ... */ >> > /** Create a thread in a non-running state. */ >> > Thread(size_t wStackSize = (65536*4)):mThread((pthread_t)0) { >> > pthread_attr_init(&mAttrib); // (pat) moved this here. >> > mStackSize=wStackSize; >> > } >> > /* ... */ >> >> I am now wondering, where does this magic 65536*4 comes from, >> and how can we estimate and adjust this properly? >> >> With best regards, >> Vadim Yanitskiy. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmith at sysmocom.de Mon Jan 14 09:38:04 2019 From: osmith at sysmocom.de (Oliver Smith) Date: Mon, 14 Jan 2019 10:38:04 +0100 Subject: GSUP: E-interface messages for inter-MSC HO In-Reply-To: <20190114020356.GA12467@my.box> References: <20190114020356.GA12467@my.box> Message-ID: <1ad07939-3524-b6f5-66a9-a66f66a78545@sysmocom.de> On 1/14/19 3:03 AM, Neels Hofmeyr wrote: > There is no pressing need yet to get this done *right now*, I have yet to > complete the inter-BSC HO in osmo-msc before I can start using GSUP. But it > would be great to just build on working API once I need it. Thanks for the detailed write-up! I'll get started with this once the save-IMEI-in-HLR related stuff I'm working on right now is in place (OS#2541). Regards, Oliver -- - Oliver Smith https://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 From ron.menez at entropysolution.com Mon Jan 14 11:55:14 2019 From: ron.menez at entropysolution.com (Ron) Date: Mon, 14 Jan 2019 11:55:14 +0000 Subject: SMS Sender Name Using Alphanumeric Characters Message-ID: Hi Community, Is it possible to send SMS using alphanumeric characters as a sender address? We tried it using an Open-Source SMS GW and it can send alphanumeric information in the sender address. Unfortunately, the SMS sent through API was not received to the test phone and the logs below are seen in OSMO-MSC. <000c> smpp_smsc.c:729 [entropy] Rx SUBMIT-SM (09170000023/1/1) <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. We also tried sending SMS with only Numeric information in the sender address and the SMS was received successfully by the test phone. We can share the traces taken and the configurations used if needed. TIA. Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mykola at pentonet.com Mon Jan 14 13:35:41 2019 From: mykola at pentonet.com (Mykola Shchetinin) Date: Mon, 14 Jan 2019 15:35:41 +0200 Subject: SMS Sender Name Using Alphanumeric Characters In-Reply-To: References: Message-ID: Hello Ron, We tried it using an Open-Source SMS GW and it can send alphanumeric > information in the sender address. > What is the name of that SMS GW software? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Mon Jan 14 13:38:55 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 14 Jan 2019 14:38:55 +0100 Subject: Google Summer of Code 2019 In-Reply-To: References: Message-ID: <20190114133855.GA19041@my.box> On Mon, Jan 14, 2019 at 10:42:05AM +0700, Vadim Yanitskiy wrote: > starting from 16th of January (until 7th of February) we can apply > Google Summer of Code as an Open source mentor organization. Many I think we had a GSoC trainee once. What does it take to participate? Maybe you can simply organise this? > Personally, I think it's a great opportunity to move some of our > projects forward. I'm not so sure about quality forward pushing coming from GSoC. But why not. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From keith at rhizomatica.org Mon Jan 14 13:44:33 2019 From: keith at rhizomatica.org (Keith) Date: Mon, 14 Jan 2019 14:44:33 +0100 Subject: Google Summer of Code 2019 In-Reply-To: References: Message-ID: <35a3565b-0801-6fde-5171-590372b29572@rhizomatica.org> Hi Vadim. I feel somewhat reluctant to be the first to respond and so negatively, but I for one have serious problems with any further collaboration with google (et al.) I'm even somewhat unhappy that many people on this mailing list force me to have my writing archived forever and completely outside of my control by using gmail email address. but.. hey.. what can one do? It's "free" right? And we are so poor opensource devs, we can't afford to run a mail server, or buy an account on non surveillance based service... The words "open source" and "google" in the same sentence should not "compile" but unfortunately, given the sad state of FOSS, they do. I don't have a good analysis of what google gets out of the summer of code, nor do I have the time or inclination to go reasearch it right now, but knowing their general modus operandi I'm pretty sure they get more out of it that anybody else, as is the case in fact, lamentably with most FOSS. I know that my contribution is not huge to Osmocom, but I can say is response to your proposal, I'd like to see osmocom be a little more on the ball, and work towards sustainable FOSS, and I firmly believe that means saying NO to corporate surveillance. Otherwise, what's the point? As some say in Kreuzberg, Google is kein guter Nachbar! and they are not your friends either. In the long terms, nothing good will come from collaboration with them. It's time to take a stand on ethical investment in FOSS. "just my 2c" :-P k/ From nhofmeyr at sysmocom.de Mon Jan 14 14:04:35 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 14 Jan 2019 15:04:35 +0100 Subject: A ramble about MSC, sip-connector and asterisk. In-Reply-To: <98b5c383-64f6-aae8-cee0-7982896c1232@corevalue.se> References: <98b5c383-64f6-aae8-cee0-7982896c1232@corevalue.se> Message-ID: <20190114140435.GC19041@my.box> Hi Gullik, what is up with your email client? It seems to insert two line feeds every 100 characters or so. I've never seen such weird flow as in your mails. Harder to follow your sentences when they break in the middle. Using external PBX is not trivial, and as soon as you do, all local call switching in osmo-msc is switched off. In general, using osmo-sip-connector works; what is not satisfactory yet is the codec negotiation. Sadly, so far the easiest solution is to hardcode a payload type number into osmo-sip-connector and clamp everything to one specific codec. For example, look at the neels/fr branch in osmo-sip-connector.git. But yours sounds more like a SIP negotiation issue?? I haven't used asterisk yet, but AFAIK at least yate, freeswitch and kamailio work without "clever hacking". > when osmobts was bridging the calls Nah. osmo-bts *never* bridges nor ever bridged calls. Old openbsc's osmo-nitb? openbts?? > Boldly moving on to MultiBTS and handover.... Since you mentioned lime before, let me say that even using timing-accurate sysmoBTS, I had 90% handover failure until I properly calibrated the internal clock. With a lime and no external clock source, you're hopelessly doomed. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From msuraev at sysmocom.de Mon Jan 14 15:01:25 2019 From: msuraev at sysmocom.de (Max) Date: Mon, 14 Jan 2019 16:01:25 +0100 Subject: Google Summer of Code 2019 In-Reply-To: <35a3565b-0801-6fde-5171-590372b29572@rhizomatica.org> References: <35a3565b-0801-6fde-5171-590372b29572@rhizomatica.org> Message-ID: <57c7bdd4-e22e-dd81-b1f2-2af52dff0dc7@sysmocom.de> Hi! 14.01.19 14:44, Keith ?????: > but I for one have serious problems with any further collaboration with > google (et al.) You don't have to: nobody forces you to be neither mentor nor student - GSoC participation is completely voluntarily. Moreover, I'm not really sure whether receiving payment could be considered as "collaboration" in the context of Free Software: usually collaboration means code contributions, tickets, documentation, testing etc. > I'm even somewhat unhappy that many people on this > mailing list force me to have my writing archived I'm not quite sure what you're referring to. We both write emails from non-gmail accounts for example. > I don't have a good analysis of what google gets out of the summer of > code, nor do I have the time or inclination to go reasearch it I'd really recommend doing some research on the subject matter before voicing a strong opinion about it. > and work towards sustainable FOSS Getting extra money and manpower is exactly that, isn't it? > means saying NO to corporate surveillance. What this have to do with GSoC? > and they are not your friends either. Again, how is this related to GSoC? In general, I'm only happy if developer A receive funding for his Osmocom work from entity B regardless of my personal opinion of either. -- - Max Suraev 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 Directors: Harald Welte From ron.menez at entropysolution.com Mon Jan 14 07:40:29 2019 From: ron.menez at entropysolution.com (Ron) Date: Mon, 14 Jan 2019 07:40:29 +0000 Subject: SMS Sender Name using Alphanumeric Message-ID: Hi Community, Is it possible to send SMS using alphanumeric information as a sender address? We tried it using an Open-Source SMS GW and it can send alphanumeric information in the sender address. Unfortunately, the SMS sent through API was not received to the test phone and the logs below are seen in OSMO-MSC. <000c> smpp_smsc.c:729 [entropy] Rx SUBMIT-SM (09170000023/1/1) <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. We also tried sending SMS with only Numeric information in the sender address and the SMS was received successfully by the test phone. Also attached in this email are the traces and configuration files used and taken during the testing. Kindly advice if we missed something in our configuration. TIA. Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Successful SMS_Numeric_Sender.pcap Type: application/octet-stream Size: 9625 bytes Desc: Successful SMS_Numeric_Sender.pcap URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Failed SMS_Alphanumeric_Sender.pcap Type: application/octet-stream Size: 9731 bytes Desc: Failed SMS_Alphanumeric_Sender.pcap URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-bsc.cfg Type: application/octet-stream Size: 4708 bytes Desc: osmo-bsc.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-bts.cfg Type: application/octet-stream Size: 2222 bytes Desc: osmo-bts.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-hlr.cfg Type: application/octet-stream Size: 344 bytes Desc: osmo-hlr.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-mgw.cfg Type: application/octet-stream Size: 356 bytes Desc: osmo-mgw.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-msc.cfg Type: application/octet-stream Size: 1946 bytes Desc: osmo-msc.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-stp.cfg Type: application/octet-stream Size: 438 bytes Desc: osmo-stp.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-trx.cfg Type: application/octet-stream Size: 944 bytes Desc: osmo-trx.cfg URL: From keith at rhizomatica.org Mon Jan 14 15:30:41 2019 From: keith at rhizomatica.org (Keith) Date: Mon, 14 Jan 2019 16:30:41 +0100 Subject: ringback in gsm. (was Re: A ramble about MSC, sip-connector and asterisk.) In-Reply-To: <98b5c383-64f6-aae8-cee0-7982896c1232@corevalue.se> References: <98b5c383-64f6-aae8-cee0-7982896c1232@corevalue.se> Message-ID: <2e16fb74-fbad-4b8c-e04c-353c3425474b@rhizomatica.org> On 12/01/2019 13:48, Gullik Webjorn wrote: > Hi, Hi Gullik, please find a couple of comments inline that I hope are helpful. First, I recommend to run sngrep and watch the SIP transactions between the osmo-sip-connector and asterisk. This should make it very clear, visually, what's happening (or not). > > ?These extensions do not have "progress" statements, since all SIP phones > > interpret the call progress sip messages such as RINGING. What do you mean by interpret?? Do you mean that a SIP device will generate internal audible ringback on receiving 180 Ringing? Osmo SIP-connector is incomplete, but will react to (interpret?) a 180 Ringing, of course it does. It will also react to a 183. On receipt of a 180 or 183 it will send MNCC_ALERT_REQ. and .. actually looking at that, there's a flag we set: progress.desc: GSM48_PROGR_IN_BAND_AVAIL. We appear to be sending that on a 180, and that might not be correct. So when you said "I don't get call progress on calls toward PSTN", I wonder are you talking about early media (ringback)? In GSM, the called party should generate ringback, the GSM phone is not required to generate audible ringing notification. see? GSM 02.40 - Procedure for call progress indications, specifically 2.1: "Except? for? ring? tone,? all? tones? indicating? call? progress? to? a? Mobile? Station? user? shall? be? generated? in? the MS, on the basis of signals from the network where available, and are according to the standard defined in this specification." "For mobile terminated calls, the ring tone will be generated in the called MSC" and Section 2.2: "The? ring? tone? will? be? sent? over? the? traffic? channel,? since? this? channel? must? be? available? for? traffic immediately it is answered (exception: Off Air Call Set Up). The Ring Tone is therefore generated by the PLMN or PSTN supporting the called phone" But whether your asterisk is generating ringback or not is kind of OT for this mailing list. Anyway, I'm not sure that is your issue. As Neels mentioned, (obviously) your codec setup needs to be correct as well, in order for your PBX to send correctly encoded early media ringback. > > > I am interested in your comments whether msc + sipconnector should > emulate mobiles as "sip phones", Personally. I think, no it should not. I wonder is this terminology/idea arising from OpenBTS? There was (is?) talk about MS just being "SIP endpoints" with openbts, I know it was something some devs on openBTS view(ed) as a plus point, and thought this was a much better idea than supported the (much more complex) traditional GSM core network spec. (which is what osmocom is doing). NOTE, I believe I have at some point in the past, noticed some phone on a commercial network generating what I could swear sounded like locally generated ringback. It was just TOO clean. Maybe one could look at the spec again and see if it's actually possible. Osmo sip connector could then set whatever is required to indeed make the MS generate a local audible ringback, although I'm not sure this would be supported all the way back through MSC/BSC to the MS, as I don't think we support this so-called "off the air" SETUP. From keith at rhizomatica.org Mon Jan 14 15:55:20 2019 From: keith at rhizomatica.org (Keith) Date: Mon, 14 Jan 2019 16:55:20 +0100 Subject: Google Summer of Code 2019 In-Reply-To: <57c7bdd4-e22e-dd81-b1f2-2af52dff0dc7@sysmocom.de> References: <35a3565b-0801-6fde-5171-590372b29572@rhizomatica.org> <57c7bdd4-e22e-dd81-b1f2-2af52dff0dc7@sysmocom.de> Message-ID: On 14/01/2019 16:01, Max wrote: > > > I'm not quite sure what you're referring to. We both write emails from > non-gmail accounts for example. > > Which are then distributed to a mailing list where there are many gmail addresses. Under the terms of service agreed to by these subscribers, the content of THIS message is now google's to scan, analyze, store forever, input into behavioural study databases, and basically do what they will with. Yes, it's publicly archived too, but there is at least no implicit agreement that it's OK to scrape the openBSC archive and use it to train your AI, although I imagine google are doing that anyway. > > I'd really recommend doing some research on the subject matter before > voicing a strong opinion about it. > > I've done quite a lot of research on silicon valley and corporate surveillance companies, and Google specifically. Results of that research suggest that drilling into the nitty gritty of the terms of the GSoC will turn up more of the same. - Maximum benefit for silicon valley, minimal benefits to society in general and zero attention to the crisis we are living right now. So I defend my strong opinion. > > Again, how is this related to GSoC? On this and the other questions, I don't think I can go on here, because the massive question and potential discussion on how is Google bad for pretty much everything gets off topic for OpenBSC very quickly. > I'm only happy if developer A receive funding for his Osmocom work > from entity B regardless of my personal opinion of either. If developer X is working on FOSS just to get paid, and does not care about the ethics, they are possibly in the wrong job, but we all do need to get paid. Silicon Valley is driving software development it it's preferred direction in subtle ways. Money is power unfortunately. "software freedom" IS being eroded, well even the orginal concept was flawed.. but... OT OT I'm happy to discuss and preferably work on ways to continue developing truly free software. I know it's hard. I know a lot of people in Osmocom and elsewhere work very hard on it. I would not stand in the way of anybody who wants to go to google, but google by its very existence prevents other alternatives from even being considered because they now have everything wrapped up. Vadim asked for opinions and I gave mine. I'll say it once more; google is not your friend. From keith at rhizomatica.org Mon Jan 14 16:01:04 2019 From: keith at rhizomatica.org (Keith) Date: Mon, 14 Jan 2019 17:01:04 +0100 Subject: SMS Sender Name Using Alphanumeric Characters In-Reply-To: References: Message-ID: <5b5581a6-e4cb-6fce-347d-2d81ecf2c662@rhizomatica.org> On 14/01/2019 12:55, Ron wrote: > Hi Community, > > Is it possible to send SMS using alphanumeric characters as a sender > address? Yes it is, I do it all the time. > > > We can share the traces taken and the configurations used if needed. > > Yes, it looks like that is required for further analysis. Maybe you could also send the msc's sms database, (which is the hlr database in the case of nitb) please make sure not to send sensitive info in there. k/ From keith at rhizomatica.org Mon Jan 14 16:02:49 2019 From: keith at rhizomatica.org (Keith) Date: Mon, 14 Jan 2019 17:02:49 +0100 Subject: SMS Sender Name Using Alphanumeric Characters In-Reply-To: References: Message-ID: <20a5bacc-6162-7076-156b-64dd5587dd09@rhizomatica.org> On 14/01/2019 12:55, Ron wrote: > > > We can share the traces taken and the configurations used if needed. > > Oh wait.. you already did that before.. I'll take a look. k/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Mon Jan 14 16:12:58 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 14 Jan 2019 17:12:58 +0100 Subject: osmo-hlr db upgrade behavior poll Message-ID: <20190114161258.GA21676@my.box> Hi all, when reviewing osmo-hlr db schema upgrades, I came up with the idea that we shouldn't upgrade automatically. That's why, for schema updates, osmo-hlr now refuses to start and requires one start with the --db-upgrade option. Our systemd service file does not include that option. The result is that after an upgraded osmo-hlr binary, admins may have to take extra action to upgrade the DB. The rationale is that if someone by accident launches a newer osmo-hlr only once, with automatic upgrade the user is then stuck with the newer version DB, since we don't make a backup and we don't provide a downgrade path. I'm now wondering whether that is really necessary. In the daily churn, it creates noise. How to make this less noisy? - Users could add the --db-upgrade option to the service file to always upgrade. (But it is cumbersome to have a .service file that differs from the installed version) - We could also add a cfg file option to allow-db-upgrades. - We could drop the behavior and always upgrade. In the lack of strong opinions, this will probably stay as it is. I'd just like to hear what you guys think about it. Is it annoying or a good idea? Thanks! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From keith at rhizomatica.org Mon Jan 14 16:36:25 2019 From: keith at rhizomatica.org (Keith) Date: Mon, 14 Jan 2019 17:36:25 +0100 Subject: osmo-hlr db upgrade behavior poll In-Reply-To: <20190114161258.GA21676@my.box> References: <20190114161258.GA21676@my.box> Message-ID: On 14/01/2019 17:12, Neels Hofmeyr wrote: > Hi all, > > > The rationale is that if someone by accident launches a newer osmo-hlr only > once, with automatic upgrade the user is then stuck with the newer version DB, > since we don't make a backup and we don't provide a downgrade path. We possibly could provide a downgrade path in the form of an external script that would recreate the previous version and export what is possible. Of course, you lose what you lose, but presumably an admin doing this knows that. Is it worth it though? Who ever downgrades? What would it take to copy the database to a backup before upgrading, (from within osmo-hlr)? Not much, right? just copy it to hlr.db.version.timestamp or some such. > I'm now wondering whether that is really necessary. In the daily churn, it > creates noise. How to make this less noisy? Could it be that when the package is upgraded, the installer stops and asks for intervention like some debian packages, you know especially when they go "oops, you edited a file..." k/ From keith at rhizomatica.org Mon Jan 14 17:37:41 2019 From: keith at rhizomatica.org (Keith) Date: Mon, 14 Jan 2019 18:37:41 +0100 Subject: SMS Sender Name Using Alphanumeric Characters In-Reply-To: References: Message-ID: Ron, In your trace "Failed SMS_Alphanumeric_Sender.pcap" you have: a) the originator TON set to National (0x02). I use Alphanumeric (0x05) b) the originator NPI set to ISDN (0x01). I use Unknown (0x00) It obviously won't work with the first error, and IIRC the second was also needed, maybe not for all phones. Keith. From gullik.webjorn at corevalue.se Mon Jan 14 22:34:19 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Mon, 14 Jan 2019 23:34:19 +0100 Subject: A ramble about MSC, sip-connector and asterisk. In-Reply-To: <20190114140435.GC19041@my.box> References: <98b5c383-64f6-aae8-cee0-7982896c1232@corevalue.se> <20190114140435.GC19041@my.box> Message-ID: Hi Neels, On 2019-01-14 15:04, Neels Hofmeyr wrote: > Hi Gullik, > > what is up with your email client? It seems to insert two line feeds every 100 > characters or so. I've never seen such weird flow as in your mails. Harder to > follow your sentences when they break in the middle. This is Thunderbird on Ubuntu, my "office" laptop. I will see if I can fix it. > Using external PBX is not trivial, and as soon as you do, all local call > switching in osmo-msc is switched off. > > In general, using osmo-sip-connector works; what is not satisfactory yet is the > codec negotiation. Sadly, so far the easiest solution is to hardcode a payload > type number into osmo-sip-connector and clamp everything to one specific codec. > For example, look at the neels/fr branch in osmo-sip-connector.git. But yours > sounds more like a SIP negotiation issue?? > > I haven't used asterisk yet, but AFAIK at least yate, freeswitch and kamailio > work without "clever hacking". > >> when osmobts was bridging the calls Hmm, I clearly remember I could make calls BEFORE using the -M /tmp/msc_mncc command, which I believe then became a config file option. However, I was not very interested in a "stand-alone" system, so I soon emerged on the path to integrate with asterisk. But if you say so.....not only computer memory fail ...maybe I did not have audio, but call progress, i.e. "ringing" ?? And that is really what is missing here, I believe, ?? sip-sofia ?? responds "183 ringing", but no call progress in the phone. I fixed it by forcing asterisk to generate progress. >> Nah. osmo-bts *never* bridges nor ever bridged calls. >> Old openbsc's osmo-nitb? openbts?? >> >> Boldly moving on to MultiBTS and handover.... > Since you mentioned lime before, let me say that even using timing-accurate > sysmoBTS, I had 90% handover failure until I properly calibrated the internal > clock. With a lime and no external clock source, you're hopelessly doomed. I *do* have clock sources, however not integrated tonight :-) Limesdr mini feels "being worked at", for me it means multiple affordable BTS pocket size , and I will gladly help in making it more usable. Tomorrow I will attempt calibrating output, and possibly input, comparing spec analyzer traces with reported signal levels. And Harald pointed me in the right direction, the lack of output on the LimeSDR, so I will remedy that as well, adding a booster, to bring level up to +15 dBm, more useful but still within allowed +20 dBm for indoor use. > ~N Always an optimist, Gullik From msuraev at sysmocom.de Tue Jan 15 10:57:32 2019 From: msuraev at sysmocom.de (Max) Date: Tue, 15 Jan 2019 11:57:32 +0100 Subject: Google Summer of Code 2019 In-Reply-To: References: <35a3565b-0801-6fde-5171-590372b29572@rhizomatica.org> <57c7bdd4-e22e-dd81-b1f2-2af52dff0dc7@sysmocom.de> Message-ID: <94ae769a-1951-aafa-fd79-95064a99c83c@sysmocom.de> Hi. 14.01.19 16:55, Keith ?????: > Yes, it's publicly archived too, but there is at least no implicit > agreement that it's OK to scrape the openBSC archive and use it to train > your AI, although I imagine google are doing that anyway. Actually, there is: by the very definition of "public" - BND, Google (or me :) are complete free to scrape, train AI on or print the messages and make origami out of them. Using gmail adds absolutely nothing new to the picture. > I've done quite a lot of research on silicon valley and corporate > surveillance companies, and Google specifically. So does FSF I believe. Yet, GNU Hurd, GCC and numerous other projects have participated in GSoC for many years without any issues. They even came up with guidelines about it: https://www.gnu.org/software/soc-projects/guidelines.html Don't take it personally, but I'd rather side with gnu.org on this one :) > If developer X is working on FOSS just to get paid, and does not care > about the ethics, they are possibly in the wrong job I don't think we're in position to judge if FOSS developers are "in the wrong job" based on ethics disagreements. > I'll say it once more; google > is not your friend. Nobody claimed otherwise. You're preaching to the choir :) -- - Max Suraev 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 Directors: Harald Welte From jacob01 at gmx.net Tue Jan 15 12:28:42 2019 From: jacob01 at gmx.net (Jacob) Date: Tue, 15 Jan 2019 13:28:42 +0100 Subject: GSUP: E-interface messages for inter-MSC HO In-Reply-To: <20190114020356.GA12467@my.box> References: <20190114020356.GA12467@my.box> Message-ID: <670b347b-b6fb-36eb-9849-74e6eede31a5@gmx.net> Hi Neels, > Anyone else is also more than welcome to take a look and remark on anything > that might seem a bad idea, etc. I had a brief look on your draft and have some remarks and thoughts about it (see below). > This is the result of me reading a MAP trace of two MSCs negotiating inter-MSC > handovers, and of reading the 29.002, 29.010,... specs. I'm not permitted to > freely share the trace, let me know if you need details. > > The most interesting bits in the draft are > > - the new message types I briefly checked the operations in 29.002 (mainly whether they provide a result or not) and they seem to match your message types. > - the newly added IEs (see "Of which are newly added...") > [...] > > Also interesting to figure out: Implement the IPA routing for which I added the > source_name and destination_name IEs: N osmo-mscs connected to one osmo-hlr > forward messages to each other via GSUP. > > - Connect two GSUP clients (test programs?) to a running osmo-hlr instance, and > to extend the gsup_server so that we can use the source_name/destination_name > IEs to forward GSUP messages between the two clients. (I added these because > I'm fairly certain there is no existing in-band IPA protocol bits that would > allow such routing; but I only briefly skimmed it, wouldn't hurt if you could > verify that again.) The aim is to have plain gsup_client API to allow me to > "just send messages back and fort". The following questions come to my mind while reading this: * Why should this message router/server be part of the HLR? IMO these are completely separate things. So I'd rather put this functionality into a separate program/process. * What about adding a separate IPA protocol id for routing (proxying might came closer for the case given), that itself just carries other IPA messages of a different type along with source/destination_name and possibly other IEs that just relate to proxying (and possibly the session stuff, unless that went to another layer)? This could then be used with every IPA protocol and won't mess with the application layer. * What about security? Proxying will prevent conventional network monitoring tools and firewalls from working properly. Will it be possible to limit proxying to certain peers e.g. via configuration? BTW, the source and destination name IEs correspond to the global titles in the SCCP layer of SS7. There also exist means to address a destination logically (e.g. send this to the HLR that is responsible for that IMSI, see the E.214 numbering plan). > > - The session_id/session_state: we still need to figure out how to avoid > collisions in session_id numbers, as any peer may at any point re-use the > same session_id. Vadim suggested using a TI flag that gets flipped between > sender and receiver, but since there are more than two peers, I guess we > should treat each session_id as subordinate to a Request's source_name. IOW, > any peer owns the entire session_id number space itself for sending out > Request message types, and a Response or Error message type echos this > session_id back with the source_name then having become the destination_name; > it is perfectly legal for two peers to use the same session_id and collisions > are avoided by Request vs. Response/Error. Something like... To me this really sounds like re-implementing (parts of) TCAP (ITU T Q.770-779) . TCAP use transaction ids, one for every end of the 'connection' (origin and destination) where each tuple (origin, OTID) or (dest, DTID) identifies the transaction (note that in certain cases a peer can reply with a different origin, e.g. by replacing a E.214 by a E.164 GT). But TCAP is properly separated from the application layer stuff (MAP in that case). [...] While I like the idea to extend GSUP/IPA, I'm wondering whether at some point in the future it was better to just use the standard protocols (e.g. MAP/TCAP/SCCP, possibly on top of IPA, perhaps just MAP on IPA possibly combined with some restrictions concerning segmentation etc) instead of partly reimplementing all of them. At least I'd rather properly separate the session/proxying stuff from GSUP (still being a simplified MAP replacement). Jacob From ron.menez at entropysolution.com Tue Jan 15 02:58:10 2019 From: ron.menez at entropysolution.com (Ron) Date: Tue, 15 Jan 2019 02:58:10 +0000 Subject: SMS Sender Name Using Alphanumeric Characters In-Reply-To: References: Message-ID: <683D9450-B01E-43DB-89AF-943E4476D268@entropysolution.com> Thanks Keith for the information. It helps us very well. We were able to send Alphanumeric Characters in the Sender Address. Thank you again! Best Regard, Ron Menez ron.menez at entropysolution.com On Jan 15, 2019, at 1:37 AM, Keith > wrote: Ron, In your trace "Failed SMS_Alphanumeric_Sender.pcap" you have: a) the originator TON set to National (0x02). I use Alphanumeric (0x05) b) the originator NPI set to ISDN (0x01). I use Unknown (0x00) It obviously won't work with the first error, and IIRC the second was also needed, maybe not for all phones. Keith. -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith at rhizomatica.org Tue Jan 15 13:30:29 2019 From: keith at rhizomatica.org (Keith) Date: Tue, 15 Jan 2019 14:30:29 +0100 Subject: Google Summer of Code 2019 In-Reply-To: <94ae769a-1951-aafa-fd79-95064a99c83c@sysmocom.de> References: <35a3565b-0801-6fde-5171-590372b29572@rhizomatica.org> <57c7bdd4-e22e-dd81-b1f2-2af52dff0dc7@sysmocom.de> <94ae769a-1951-aafa-fd79-95064a99c83c@sysmocom.de> Message-ID: <3656dcc2-41c4-41ff-783a-b78e94521929@rhizomatica.org> On 15/01/2019 11:57, Max wrote: > - BND, Google (or me :) are complete free to scrape, train AI on or > print... Yep.. and there we see the entrance to one of many rabbit holes here and something that I consider one of the failures of FOSS and the "open" movement... > > > So does FSF I believe.... > Hmm. So, I think this (long standing) attitude of the infallible (FSF|GNU|EFF|etc) is getting very dangerous. History will absolve me :)) > > I don't think we're in position to judge if FOSS developers are "in > the wrong job" based on ethics disagreements. > I was more meaning to say that surely if one's goal is purely to make money, spending the majority of your programming skills/time on FOSS projects is probably not the best choice. Not that I don't think this debate should be had, nor do I want to avoid public discussion at all, but we should probably take this elsewhere.. So.. I still hang out at that place on tuesdays.. BTW.. at least until it's getting too smoky. From nhofmeyr at sysmocom.de Tue Jan 15 13:44:04 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 15 Jan 2019 14:44:04 +0100 Subject: GSUP: E-interface messages for inter-MSC HO In-Reply-To: <670b347b-b6fb-36eb-9849-74e6eede31a5@gmx.net> References: <20190114020356.GA12467@my.box> <670b347b-b6fb-36eb-9849-74e6eede31a5@gmx.net> Message-ID: <20190115134404.GB21676@my.box> Many thanks for your input! I don't really have strong opinions about any of these design questions. When extending the GSUP protocol I am mainly carrying out other people's ideas... On Tue, Jan 15, 2019 at 01:28:42PM +0100, Jacob wrote: > * Why should this message router/server be part of the HLR? IMO these > are completely separate things. So I'd rather put this functionality > into a separate program/process. So far osmo-hlr is the GSUP server. We've already introduced the concept of osmo-hlr as a router-thing concerning USSD services, towards external USSD providers. Adding a router in-between would change the topology, sort of like we added the osmo-stp for the A and Iu interfaces. osmo-hlr would then also be a GSUP client to the router instance, and osmo-msc and osmo-sgsn would have to add routing information to reach the HLR... That's (probably) backwards incompatible, not sure if we want to open that box now. > * What about adding a separate IPA protocol id for routing (proxying > might came closer for the case given), that itself just carries other > IPA messages of a different type along with source/destination_name and > This could then be > used with every IPA protocol and won't mess with the application layer. Ok, that sounds like a sane idea. I wonder whether such a concept is already in use somewhere on the IPA protocol? A drawback I see is that we currently have numerous IPA implementations flying around, IIRC in libosmocore, libosmo-netif, libosmo-sccp; and at least two in python... extending the libosmocore one would probably be enough. > possibly other IEs that just relate to proxying (and possibly the > session stuff, unless that went to another layer)? > > * What about security? Proxying will prevent conventional network > monitoring tools and firewalls from working properly. Will it be > possible to limit proxying to certain peers e.g. via configuration? I don't fully get the proxying idea. What's the purpose, to bridge messages for specific recipients through a NAT sort of thing? > BTW, the source and destination name IEs correspond to the global titles > in the SCCP layer of SS7. There also exist means to address a > destination logically (e.g. send this to the HLR that is responsible for > that IMSI, see the E.214 numbering plan). This is the first time I'm thinking about more than one HLR in Osmocom. I'm out of my depth here... > > - The session_id/session_state: we still need to figure out how to avoid > > collisions in session_id numbers, as any peer may at any point re-use the > > same session_id. Vadim suggested using a TI flag that gets flipped between > > sender and receiver, but since there are more than two peers, I guess we > > should treat each session_id as subordinate to a Request's source_name. IOW, > > any peer owns the entire session_id number space itself for sending out > > Request message types, and a Response or Error message type echos this > > session_id back with the source_name then having become the destination_name; > > it is perfectly legal for two peers to use the same session_id and collisions > > are avoided by Request vs. Response/Error. Something like... > > To me this really sounds like re-implementing (parts of) TCAP (ITU T > Q.770-779) . TCAP use transaction ids, one for every end of the > 'connection' (origin and destination) where each tuple (origin, OTID) or > (dest, DTID) identifies the transaction (note that in certain cases a Except that in TCAP, both sides invent an own ID for a dialogue. I'm planning to have just one ID sent back and forth, which the first Request specifies, and then remains the same from both sides. > peer can reply with a different origin, e.g. by replacing a E.214 by a > E.164 GT). But TCAP is properly separated from the application layer > stuff (MAP in that case). > While I like the idea to extend GSUP/IPA, I'm wondering whether at some > point in the future it was better to just use the standard protocols > (e.g. MAP/TCAP/SCCP, possibly on top of IPA, perhaps just MAP on IPA > possibly combined with some restrictions concerning segmentation etc) > instead of partly reimplementing all of them. IIUC the standard stack has quite a lot of duplicated information and is a lot more complex than GSUP/IPA, and that is precisely the idea: implement a simpler protocol with sufficient information to still allow translating into the more complex standard stack, but saving us all the gory details that we would need for the full stack. I did not make this decision, which is probably also made on the grounds of getting something done in a reasonable time frame (this is work for a sysmocom customer). Well, personally, I would enjoy myself more when staying with GSUP for now and keeping things as simple as possible :) (because I would rather concentrate on osmo-msc's handover code) > At least I'd rather > properly separate the session/proxying stuff from GSUP (still being a > simplified MAP replacement). The session_id IE was already added for USSD. Proxying doesn't seem to be a goal at this point. Routing messages between GSUP clients could be changed into routing messages between IPA clients. That would match well in the sense that we already send the MSC's name via IPA during the initial IPA ID exchange. However, keeping routing within GSUP would make operations a bit simpler now, since all our patches modify just one protocol layer, and we have only one GSUP server implementation vs. the various IPA ones. My first and final word on this is that I don't worry/care much about which way we do these things, because I personally don't have a larger scheming plan for IPA and GSUP, so I would like to hear other opinions. Thanks again for your very interesting input! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Tue Jan 15 14:03:48 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 15 Jan 2019 15:03:48 +0100 Subject: contribution In-Reply-To: <35a3565b-0801-6fde-5171-590372b29572@rhizomatica.org> References: <35a3565b-0801-6fde-5171-590372b29572@rhizomatica.org> Message-ID: <20190115140348.GC21676@my.box> On Mon, Jan 14, 2019 at 02:44:33PM +0100, Keith wrote: > I know that my contribution is not huge to Osmocom The way I feel is that you and Rhizomatica are actually (one of?) the most important drivers for Osmocom, if not by offloading huge sums of money, then at least by providing a perspective and meaning. When people ask me what I do they first go "yes? what? I don't...?" (sadly oblivious of the importance for openness of critical infra), but when I pull the Rhizomatica card they go "ah, wow!" -- and you are the most available, most present Rhizomatica person in the community. For me personally, the most interesting perspective for Osmocom is exactly the Rhizomatica use case of becoming a distributed GSM network that is resilient against network fragmentation between villages, i.e. enabling reliable operations for people that are not able to make infrastructure problems go away by dumping millions of bucks on them. When we're talking about profits and market and all that, granted, but on a level of meaning and perspective, as well as running real network operations, in my POV your contribution is actually paramount, is the main reason even. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Tue Jan 15 14:17:36 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 15 Jan 2019 15:17:36 +0100 Subject: Google Summer of Code 2019 In-Reply-To: <57c7bdd4-e22e-dd81-b1f2-2af52dff0dc7@sysmocom.de> References: <35a3565b-0801-6fde-5171-590372b29572@rhizomatica.org> <57c7bdd4-e22e-dd81-b1f2-2af52dff0dc7@sysmocom.de> Message-ID: <20190115141736.GD21676@my.box> On Mon, Jan 14, 2019 at 04:01:25PM +0100, Max wrote: > I'm not really sure whether receiving payment could be considered as > "collaboration" in the context of Free Software: usually collaboration means > code contributions, tickets, documentation, testing etc. Receiving money is a key part of corruption, for example. For important public/social positions, there are strict laws about where you're allowed to get money from for very concrete reasons. GSoC isn't openly imposing anything as return favor, the same way it isn't openly imposing a return favor for your search results. But all of it serves their corporate purpose nevertheless. I find it hard to put in few crisp words, but in general I agree with the general distrust of companies too huge to be good for anyone. If nothing else, Google uses GSoC to identify individuals that have time on their hands, are interested in software and need money, and they affiliate that new young generation with themselves, imprinting a positive image. (That's all I'm going to say on it... OT) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From stsp at stsp.name Tue Jan 15 14:22:36 2019 From: stsp at stsp.name (Stefan Sperling) Date: Tue, 15 Jan 2019 15:22:36 +0100 Subject: Google Summer of Code 2019 In-Reply-To: <20190115141736.GD21676@my.box> References: <35a3565b-0801-6fde-5171-590372b29572@rhizomatica.org> <57c7bdd4-e22e-dd81-b1f2-2af52dff0dc7@sysmocom.de> <20190115141736.GD21676@my.box> Message-ID: <20190115142236.GC78849@ted.stsp.name> On Tue, Jan 15, 2019 at 03:17:36PM +0100, Neels Hofmeyr wrote: > If nothing else, Google uses GSoC to identify individuals that have time on > their hands, are interested in software and need money, and they affiliate that It's more than that. They actively try to hire GsoC students and mentors. I was a mentor a few times in a row and their recruitment spam never stopped. From nhofmeyr at sysmocom.de Tue Jan 15 14:24:26 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 15 Jan 2019 15:24:26 +0100 Subject: osmo-hlr db upgrade behavior poll In-Reply-To: References: <20190114161258.GA21676@my.box> Message-ID: <20190115142426.GE21676@my.box> On Mon, Jan 14, 2019 at 05:36:25PM +0100, Keith wrote: > What would it take to copy the database to a backup before upgrading, > (from within osmo-hlr)? Not much, right? > > just copy it to hlr.db.version.timestamp or some such. And then two years later admin goes: what, where are all these huge backup files coming from, cluttering my operations file system? I was supposed to delete all contact information after six months according to terms of service! :P > Could it be that when the package is upgraded, the installer stops and > asks for intervention like some debian packages, you know especially > when they go "oops, you edited a file..." Yes, that would probably be a good idea. People building from source are anyway assumed to know what they're doing... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gullik.webjorn at corevalue.se Tue Jan 15 15:13:29 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Tue, 15 Jan 2019 16:13:29 +0100 Subject: Checking out LimeSDR Mini with osmocom. It seems good!! Message-ID: <020944ae-4b75-3e34-70c5-0eb18cd499b1@corevalue.se> Tue 15-jan-2019 LimeSDR transmit check. Fired up old HP 8614A signal generator at 1880 Mhz, and let it stabilize for 1 hour. Level measurement after adjusting ALC, 0dBm = -0.4 dBm as checked with spectrum analyzer Checked level with HP L423A probe. Check of LimeSDR mini output. Output as seen on spectrum analyzer -1.0 dBm. This correlates with LMS7002 datasheet with a possible 1 dB loss between chip and analyzer, including SMA-BNC coax adapter, 2 m foam insulated RG58 size cable, BNC - N connector. So, for practical purposes the LimeSDR mini provides 0 dBm ( +/- 1.4 dBm ) LimeSDR receive check. Receive antenna rigged with a 1/10 dB splitter, -10 dB port connected to spectrum analyzer, -1 dB port to LimeSDR. Connect single Nokia Handset, and make a call from osmobsc to fixed phone, so that only one mobile is using TCH. Move phone to get different uplink levels and correlate these to spectrum analyzer. Since carrier is TDMA, use peak hold on analyzer. Active subscriber connections: conn ID=31, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1 at mgw BTS 1, TRX 0, Timeslot 1, Lchan 0: Type TCH_F ? Connection: 1, State: ESTABLISHED ? BS Power: 10 dBm, MS Power: 10 dBm ? Channel Mode / Codec: SPEECH_V1 ? No Subscriber ? Bound IP: 192.168.1.75 Port 16384 RTP_TYPE2=0 CONN_ID=0 ? Conn. IP: 192.168.1.70 Port 4110 RTP_TYPE=3 SPEECH_MODE=0x00 ? Measurement Report: ??? Flags: ??? MS Timing Offset: 0 ??? L1 MS Power: 10 dBm, Timing Advance: 4 ??? RXL-FULL-dl:? -51 dBm, RXL-SUB-dl:? -51 dBm RXQ-FULL-dl: 0, RXQ-SUB-dl: 0 ??? RXL-FULL-ul:? -54 dBm, RXL-SUB-ul:? -54 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 Level on uplink -54 dBm, indicated on spectrum analyzer -53 (-63) dBm. OsmoBSC# show conn Active subscriber connections: conn ID=31, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1 at mgw BTS 1, TRX 0, Timeslot 1, Lchan 0: Type TCH_F ? Connection: 1, State: ESTABLISHED ? BS Power: 10 dBm, MS Power: 10 dBm ? Channel Mode / Codec: SPEECH_V1 ? No Subscriber ? Bound IP: 192.168.1.75 Port 16384 RTP_TYPE2=0 CONN_ID=0 ? Conn. IP: 192.168.1.70 Port 4110 RTP_TYPE=3 SPEECH_MODE=0x00 ? Measurement Report: ??? Flags: ??? MS Timing Offset: 0 ??? L1 MS Power: 10 dBm, Timing Advance: 4 ??? RXL-FULL-dl:? -69 dBm, RXL-SUB-dl:? -69 dBm RXQ-FULL-dl: 0, RXQ-SUB-dl: 0 ??? RXL-FULL-ul:? -59 dBm, RXL-SUB-ul:? -59 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 Mobile moved to another location within the lab. Level on uplink -59 dBm, indicated on spectrum analyzer -60 (-70) dBm. Conclusion: For such a simple low cost SDR, the accuracy seems within a couple of dB. Instruments used were are not "professional grade", at least not w.r. 2019, but I estimate I can measure within +/- 2 dB or so with this crude config. Power output is 10 times lower than I expected, I was probably mislead by some review on the web, and had to go down to the actual scematic and datasheet to understand that the expected level should be around 0 dBm. (thanks for pointing this out, Harald) For practical use outside a lab output is far too low. My plan is to add a small simple booster to bring level up to +15 which would allow me to cover my 2 acre lot without breaking any rules. Else, I am impressed, good value for a low price tag. I had expected far worse than indicated accuracy. Best Regards, Gullik From laforge at gnumonks.org Tue Jan 15 16:13:49 2019 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 15 Jan 2019 17:13:49 +0100 Subject: Google Summer of Code 2019 In-Reply-To: References: Message-ID: <20190115161349.GP11166@nataraja> Hi Vadim, On Mon, Jan 14, 2019 at 10:42:05AM +0700, Vadim Yanitskiy wrote: > starting from 16th of January (until 7th of February) we can apply > Google Summer of Code as an Open source mentor organization. Thanks. It's something that I've been pondering several times in the past, too. I know Holger did it once for Osmocom in the past, AFAIR, and in netfilter (where I was involved before) we also participated in GSoC. The results were - as any results from new developers - mixed. But I think it's a good opportunity to get new people involved in the project. > Personally, I think it's a great opportunity to move some of our > projects forward. I would like to know your opinions about this > idea, should we participate? I would be happy to be a mentor. I think it's a good idea and I'd support it. I just know that given the many projects I'm already way too late with and overloaded, I will not be able to personally mentor a GSoC student. So I'm happy to help with formailtiies, etc. - but that's about it, sorry. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue Jan 15 16:10:22 2019 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 15 Jan 2019 17:10:22 +0100 Subject: osmo-hlr db upgrade behavior poll In-Reply-To: <20190114161258.GA21676@my.box> References: <20190114161258.GA21676@my.box> Message-ID: <20190115161022.GO11166@nataraja> Hi Neels, On Mon, Jan 14, 2019 at 05:12:58PM +0100, Neels Hofmeyr wrote: > when reviewing osmo-hlr db schema upgrades, I came up with the idea that we > shouldn't upgrade automatically. That's why, for schema updates, osmo-hlr now > refuses to start and requires one start with the --db-upgrade option. > > Our systemd service file does not include that option. > > The result is that after an upgraded osmo-hlr binary, admins may have to take > extra action to upgrade the DB. > > The rationale is that if someone by accident launches a newer osmo-hlr only > once, with automatic upgrade the user is then stuck with the newer version DB, > since we don't make a backup and we don't provide a downgrade path. I think this is in-line with how other applications handle database schema upgrades. I frequently have the same steps whenever I am updating software we run on osmocom.org, such as e.g. our redmne instances. > In the lack of strong opinions, this will probably stay as it is. I'd just like > to hear what you guys think about it. Is it annoying or a good idea? I think the current beavior is fine. I just don't recall having seen any related information in the manual, please verify. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From keith at rhizomatica.org Wed Jan 16 16:27:02 2019 From: keith at rhizomatica.org (Keith) Date: Wed, 16 Jan 2019 17:27:02 +0100 Subject: default TA vty config for OSMO-PCU? Message-ID: <64b02560-3475-6463-882d-1d20ae52c4bb@rhizomatica.org> Hey list.. so i want to do some experiments setting the default TA in the PCU to the distance from the tower to the main population centre, rather than have it set to 220 (invalid) So, this email is not about the details of that issue, rather just a quick question. In the interim while this gets finally done right, would we accept adding a default-timing-advance param to the vty config? Otherwise I can patch and compile version for each BTS, but the vty config would be WAY more handy! thnx k/ From laforge at gnumonks.org Wed Jan 16 17:55:02 2019 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 16 Jan 2019 18:55:02 +0100 Subject: default TA vty config for OSMO-PCU? In-Reply-To: <64b02560-3475-6463-882d-1d20ae52c4bb@rhizomatica.org> References: <64b02560-3475-6463-882d-1d20ae52c4bb@rhizomatica.org> Message-ID: <20190116175502.GK27138@nataraja> hi Keith, it is my understanding that the TA value of osmo-pcu is working as expected, as the timing offset is established durign TBF establishment. What osmo-pcu is missing is the PTCCH signalling to continuously adjust the timing advance as the timing offset evolves during an onging TBF. So for a subscriber at a [relatively] fixed distance from the BTS (like the population centre you're describing), it *should* be working. Please note that Sylvain has just very recently designed an open source "timing advance generator" under sysmocom contract, ant using that device (based on the PLUTO-SDR) plus some coaxial wiring/attenuators, it should be rather easy to simulate both static as well as changing timing advance. The project is called 'osmo-rfds' (for RF Delay Simulator), see http://git.osmocom.org/osmo-rfds/ If OsmoPCU was just always operating at a static timing advance, I would agree that a VTY command would be a possible interim hack. But AFAIK, the PCU is not actually that limited ;) Please help to clarify, thanks. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From keith at rhizomatica.org Wed Jan 16 19:36:46 2019 From: keith at rhizomatica.org (Keith) Date: Wed, 16 Jan 2019 20:36:46 +0100 Subject: default TA vty config for OSMO-PCU? In-Reply-To: <20190116175502.GK27138@nataraja> References: <64b02560-3475-6463-882d-1d20ae52c4bb@rhizomatica.org> <20190116175502.GK27138@nataraja> Message-ID: <8373498d-d5bd-85a3-48bc-f542bfc5a5dc@rhizomatica.org> On 16/01/2019 18:55, Harald Welte wrote: > hi Keith, > > it is my understanding that the TA value of osmo-pcu is working as expected, > as the timing offset is established durign TBF establishment. What osmo-pcu > is missing is the PTCCH signalling to continuously adjust the timing advance > as the timing offset evolves during an onging TBF. Right. I'm aware of the missing part. What I noticed last summer with a phone on my desk a few metres from the BTS, that is to say, in Timing Advance "zone" 0, is this: If I change this line: http://git.osmocom.org/osmo-pcu/tree/src/tbf_dl.cpp#n130 replacing GSM48_TA_INVALID (defined as 220 in libosmocore) with 0 then I get much better performance, as in "it works", and with GSM48_TA_INVALID of 220 "it doesn't work" :) What seems to be not working as expected is the logic of the invalid TA, some phones just don't seem to like this, either that, OR the phones respond correctly to the invalid TA, and we are not dealing right with the response. Sorry.. I actually haven't looked at all the traces and work I did last summer, and memory is vague on the specifics. I actually want to do the experiments again, but with a variable INVALID_TA > > So for a subscriber at a [relatively] fixed distance from the BTS (like the population > centre you're describing), it *should* be working. > It isn't working. confirmed multiple times. It varies phone by phone, but basically, it goes like this: start: establish pdp context, send data. recv data.. all good until we have no data for a few seconds... TBF times out. Next, phone or network has data. network pages, phone does not respond. or phone sends RACH bursts, network does not respond. wait.... Eventually, this times out, pdp context is torn down. wait.... goto start. Which all makes for a "working" but rather frustrating instant messaging experience. > Please note that Sylvain has just very recently designed an open source > "timing advance generator" under sysmocom contract, ant using that device > (based on the PLUTO-SDR) plus some coaxial wiring/attenuators, it should be > rather easy to simulate both static as well as changing timing advance. Yep, and this is great! I think it's going to help a lot to debug and get this sorted out. > > The project is called 'osmo-rfds' (for RF Delay Simulator), see http://git.osmocom.org/osmo-rfds/ > > If OsmoPCU was just always operating at a static timing advance, I would > agree that a VTY command would be a possible interim hack. But AFAIK, the > PCU is not actually that limited ;) OK, so i didn't mean to implement a static timing advance, just to try a different "Invalid" TA to start with instead of 220. > Please help to clarify, thanks. hope that helps. Anyway, for sure, I can just implement the vty command for my tests, (and push to a private branch). Not something we really need in master. But if it were there.. people might be more inclined to test it out.. and that might help at least to debug/clarify this issue? (which I think is very much confused by the "works for me" element, like for example if you happen to use say, an iPhone 5c, which is one I have seen to work fine. :) k/ From osmith at sysmocom.de Thu Jan 17 10:21:15 2019 From: osmith at sysmocom.de (Oliver Smith) Date: Thu, 17 Jan 2019 11:21:15 +0100 Subject: osmo-hlr db upgrade behavior poll In-Reply-To: <20190115161022.GO11166@nataraja> References: <20190114161258.GA21676@my.box> <20190115161022.GO11166@nataraja> Message-ID: <98679950-b8e6-7a9d-f995-dd6fe127b11d@sysmocom.de> On 1/15/19 5:10 PM, Harald Welte wrote: > I think the current beavior is fine. I just don't recall having seen any > related information in the manual, please verify. It was not documented yet. Here's a patch that adds it: https://gerrit.osmocom.org/#/q/topic:hlr-docs-db-upgrade+(status:open+OR+status:merged) -- - Oliver Smith https://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 From sergey.mayzus at uwcfx.com Thu Jan 17 12:31:32 2019 From: sergey.mayzus at uwcfx.com (=?UTF-8?B?U2VyZ2V5IE1heXp1cw==?=) Date: Thu, 17 Jan 2019 12:31:32 +0000 Subject: =?UTF-8?B?UmU6IFJlOiBSZTogT3Ntb1RSWCAtIG9zbW8tdHJ4LXU=?= =?UTF-8?B?c3JwLTEgQWJvcnRlZCA6OiBBc3NlcnRpb24gJ3B4ICE9IDAnIGZhaWw=?= =?UTF-8?B?ZWQ=?= In-Reply-To: <20190111215003.GW606@nataraja> References: <20190110111103.GV606@nataraja> <20190111215003.GW606@nataraja> Message-ID: An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Thu Jan 17 15:19:04 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 17 Jan 2019 16:19:04 +0100 Subject: SMS sm_rp_mr set only when conn already established Message-ID: <20190117151904.GA6243@ass40.box> Hi folks, just now while resolving some unrelated merge conflict, I notice this bit of code we have in osmo-msc master. (It has recently been tweaked, but the code in question has been like this for a long time.) https://git.osmocom.org/osmo-msc/tree/src/libmsc/gsm_04_11.c#n1057 static struct gsm_trans *gsm411_alloc_mt_trans(struct gsm_network *net, struct vlr_subscr *vsub) { struct ran_conn *conn; struct gsm_trans *trans; int tid; LOGP(DLSMS, LOGL_INFO, "Going to send a MT SMS\n"); /* Generate a new transaction ID */ tid = trans_assign_trans_id(net, vsub, GSM48_PDISC_SMS, 0); if (tid == -1) { LOGP(DLSMS, LOGL_ERROR, "No available transaction IDs\n"); return NULL; } /* Attempt to find an existing connection */ conn = connection_for_subscr(vsub); /* Allocate a new transaction */ trans = gsm411_trans_init(net, vsub, conn, tid); if (!trans) return NULL; if (conn) { <===== if no active communication, this is NULL /* Generate unique RP Message Reference */ trans->sms.sm_rp_mr = conn->next_rp_ref++; <===== here } /* Use SAPI 3 (see GSM 04.11, section 2.3) */ trans->dlci = UM_SAPI_SMS; return trans; } We often create an MT SMS transaction when no connection to the subscriber is currently available, which is the case if we create the SMS transaction and only page later. (To prove that, the call flow is gsm411_send_sms(vsub) trans = gsm411_alloc_mt_trans(vsub) gsm411_rp_sendmsg(trans) gsm411_smr_send() srdownstatelist[0] = gsm411_rl_data_req() gsm411_mn_send() gsm411_mm_send() gsm411_mmsms_est_req() trans->paging_request = subscr_request_conn(...) ) But we only assign an sm_rp_mr reference number when the conn is already present. That means when we send an SMS, the sm_rp_mr reference is unset when we still need to page first?? Does anyone know this code well? I'm almost certain we should always set an RP reference? (i.e. drop the 'if (conn)' condition) What errors could arise from this? It seems that we would always send an RP reference of zero for all SMS that require paging. Could that be a reason Rhizomatica sometimes saw SMS delivered to the wrong recipient? So, does anyone already know that I'm on the wrong track here -- otherwise I'll create an issue for this, probably also needing tests. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From axilirator at gmail.com Thu Jan 17 16:14:04 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Thu, 17 Jan 2019 23:14:04 +0700 Subject: SMS sm_rp_mr set only when conn already established In-Reply-To: <20190117151904.GA6243@ass40.box> References: <20190117151904.GA6243@ass40.box> Message-ID: Hi Neels, > Does anyone know this code well? I'm almost certain we should > always set an RP reference? (i.e. drop the 'if (conn)' condition) I am the author of this code. Thanks a lot for looking into this! Actually, it was assumed that if there is no active RAN connection, we can just start counting from 0x00, as there are no other SMS related transactions, and transaction itself is allocated using talloc_zero(). Until now it was looking good, but... I just realized that as soon as we establish RAN connection with subscriber, we already have a transaction with sm_rp_mr == 0x00, but conn->next_rp_ref also remains == 0x00, it isn't increased! This means that we can face a SM-RP-MR conflict (or collision) if another MT SMS would arrive to the MSC (from SMSC over GSUP) when this transaction is still active, i.e. the first SMS is still being sent, because conn->next_rp_ref++ would return 0x00 too :/ I will write a TTCN test case, and fix this issue. Thanks! > Could that be a reason Rhizomatica sometimes saw SMS > delivered to the wrong recipient? I don't think they are using "SMS over GSUP", so most likely no. The 'trans->sms.sm_rp_mr' is only used by "SMS over GSUP" code. With best regards, Vadim Yanitskiy. From nhofmeyr at sysmocom.de Thu Jan 17 16:50:05 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 17 Jan 2019 17:50:05 +0100 Subject: two general code review questions Message-ID: <20190117165005.GB6243@ass40.box> Should we now put copyright comments in header files as well? re https://gerrit.osmocom.org/c/osmo-msc/+/11642/3/include/osmocom/msc/sgs_iface.h#2 When I see structs containing talloc'd char*, should I generally give code review to use fixed char arrays instead? I think it ends up being simpler semantically as well as better in terms of mem allocation. Right? e.g. https://gerrit.osmocom.org/c/osmo-msc/+/11642/30/include/osmocom/msc/sgs_server.h#18 and #21 Thanks for your opinions... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Thu Jan 17 16:58:35 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 17 Jan 2019 17:58:35 +0100 Subject: two general code review questions In-Reply-To: <20190117165005.GB6243@ass40.box> References: <20190117165005.GB6243@ass40.box> Message-ID: <20190117165835.GC6243@ass40.box> On Thu, Jan 17, 2019 at 05:50:05PM +0100, Neels Hofmeyr wrote: > Should we now put copyright comments in header files as well? > re https://gerrit.osmocom.org/c/osmo-msc/+/11642/3/include/osmocom/msc/sgs_iface.h#2 > > When I see structs containing talloc'd char*, should I generally give code > review to use fixed char arrays instead? I think it ends up being simpler > semantically as well as better in terms of mem allocation. Right? e.g. > https://gerrit.osmocom.org/c/osmo-msc/+/11642/30/include/osmocom/msc/sgs_server.h#18 > and #21 From IRC: neels: it depends. if the size is bounded, and we always need that string as part of the enclosing struct: array. neels: if the size is very dynamic/unknown/unbounded, and the char string is rather optional and not present in most cases: dynamic allocation ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laforge at gnumonks.org Thu Jan 17 22:18:21 2019 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 17 Jan 2019 23:18:21 +0100 Subject: Checking out LimeSDR Mini with osmocom. It seems good!! In-Reply-To: <020944ae-4b75-3e34-70c5-0eb18cd499b1@corevalue.se> References: <020944ae-4b75-3e34-70c5-0eb18cd499b1@corevalue.se> Message-ID: <20190117221821.GK27138@nataraja> Hi Gullik, thanks a lot for your extensive measurement and testing, as well as the report here to this list. On Tue, Jan 15, 2019 at 04:13:29PM +0100, Gullik Webjorn wrote: > So, for practical purposes the LimeSDR mini provides 0 dBm ( +/- 1.4 dBm ) Yes, that's more in-line with what I remember. Depending on unit and frequency, I think the expected level is roughly between 0 and 4 dBm. > Level on uplink -54 dBm, indicated on spectrum analyzer -53 (-63) dBm. So you're saying that the level displayed in the 'show lchan' actually was almost exactly the measrued level (-53 dBm)? That's a very big surprise to me. As far as I understand, the LimeSuite API never reports any absolute values, but rather only in dBFS (dB to full scale). So it's a bit of a mystery how you can get such an accurate reading? > For practical use outside a lab output is far too low. My plan is to add a > small simple booster > to bring level up to +15 which would allow me to cover my 2 acre lot without > breaking any rules. We made some osmo-bts-amp / osmo-bts-pa designs and devices some time ago, but they only have 10dB gain. They were made to go from +23 to +33 dBm, and not for such low input signals, where higher gain stages are required. Make surey you carefully look at your spectrum and use transmit filters to suppress the harmonics that your PA will be generating. > Else, I am impressed, good value for a low price tag. I had expected far > worse than indicated accuracy. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From gullik.webjorn at corevalue.se Thu Jan 17 23:39:04 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Fri, 18 Jan 2019 00:39:04 +0100 Subject: Checking out LimeSDR Mini with osmocom. It seems good!! In-Reply-To: <20190117221821.GK27138@nataraja> References: <020944ae-4b75-3e34-70c5-0eb18cd499b1@corevalue.se> <20190117221821.GK27138@nataraja> Message-ID: Hello Harald et.al. On 2019-01-17 23:18, Harald Welte wrote: > Hi Gullik, > > thanks a lot for your extensive measurement and testing, as well as the > report here to this list. > > On Tue, Jan 15, 2019 at 04:13:29PM +0100, Gullik Webjorn wrote: >> So, for practical purposes the LimeSDR mini provides 0 dBm ( +/- 1.4 dBm ) > Yes, that's more in-line with what I remember. Depending on unit and frequency, > I think the expected level is roughly between 0 and 4 dBm. > >> Level on uplink -54 dBm, indicated on spectrum analyzer -53 (-63) dBm. > So you're saying that the level displayed in the 'show lchan' actually was > almost exactly the measrued level (-53 dBm)? That's a very big surprise > to me. As far as I understand, the LimeSuite API never reports any absolute values, > but rather only in dBFS (dB to full scale). So it's a bit of a mystery > how you can get such an accurate reading? Yes, I am surprised myself, but I documented what I saw. Note also I checked at two different levels. I will probably redo these tests as I get a more output and a "better test range". >> For practical use outside a lab output is far too low. My plan is to add a >> small simple booster >> to bring level up to +15 which would allow me to cover my 2 acre lot without >> breaking any rules. > We made some osmo-bts-amp / osmo-bts-pa designs and devices some time ago, > but they only have 10dB gain. They were made to go from +23 to +33 dBm, > and not for such low input signals, where higher gain stages are required. > > Make surey you carefully look at your spectrum and use transmit filters to > suppress the harmonics that your PA will be generating. Yes, currently I use a linear amp designed as a preamp, but output level is a bit below 1 dB compression point, so we are operating linear, current output is 8-9 dBm, which enables extending the test range. I am limited to 100 mW indoor, +20 dBm. >> Else, I am impressed, good value for a low price tag. I had expected far >> worse than indicated accuracy. > Regards, > Harald > From axilirator at gmail.com Fri Jan 18 09:12:31 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Fri, 18 Jan 2019 16:12:31 +0700 Subject: SMS sm_rp_mr set only when conn already established In-Reply-To: References: <20190117151904.GA6243@ass40.box> Message-ID: Hi again, > I will write a TTCN test case, and fix this issue. Thanks! Please see: (TTCN-3 TC) https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/12627/ (OsmoMSC) https://gerrit.osmocom.org/#/c/osmo-msc/+/12628/ With best regards, Vadim Yanitskiy. From laforge at gnumonks.org Fri Jan 18 09:58:06 2019 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 18 Jan 2019 10:58:06 +0100 Subject: two general code review questions In-Reply-To: <20190117165005.GB6243@ass40.box> References: <20190117165005.GB6243@ass40.box> Message-ID: <20190118095806.GP27138@nataraja> Hi Neels, On Thu, Jan 17, 2019 at 05:50:05PM +0100, Neels Hofmeyr wrote: > Should we now put copyright comments in header files as well? > re https://gerrit.osmocom.org/c/osmo-msc/+/11642/3/include/osmocom/msc/sgs_iface.h#2 yes, it is general practise. > When I see structs containing talloc'd char*, should I generally give code > review to use fixed char arrays instead? I think it ends up being simpler > semantically as well as better in terms of mem allocation. Right? e.g. > https://gerrit.osmocom.org/c/osmo-msc/+/11642/30/include/osmocom/msc/sgs_server.h#18 > and #21 My general rule of thumb is: * if the string length is [relatively] bounded and the most common case is that the enclosing structure will have such a string present -> static array * if the string length is rather unbounded and/or there are many use cases where the string is not used at all -> pointer + talloc There may be other factors to take into consideration. For strings that can change at the lietime of the structure, such as 'name' or 'description' bits that are accessible from the VTY, we've traditionally used osmo_talloc_replace_string() as a hepler and then there's some tendency to do that. But then, if it were a static array, we'd simply use OSMO_STRLCPY_ARRAY() which is equally easy to use. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Jan 18 23:24:32 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 19 Jan 2019 00:24:32 +0100 Subject: tagging new versions / problems Message-ID: <20190118232432.GD1689@nataraja> 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.1/current/2acae/abi_compat_report.html 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.1/current/4981a/abi_compat_report.html 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/current/8784f/abi_compat_report.html 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.10.0/current/1268e/abi_compat_report.html#Added Feel free to comment. The most important part is to get the libosmocore/LCLS questions resolved. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From msuraev at sysmocom.de Sat Jan 19 15:56:43 2019 From: msuraev at sysmocom.de (Max) Date: Sat, 19 Jan 2019 16:56:43 +0100 Subject: tagging new versions / problems In-Reply-To: <20190118232432.GD1689@nataraja> References: <20190118232432.GD1689@nataraja> Message-ID: <5b8c4a0a-052b-4af7-e2a2-638e201694b6@sysmocom.de> Hi. 19.01.19 00:24, Harald Welte ?????: > 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. Maybe we could integrate it into 'make release' helper of libosmocore? > 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. In general, is there particular reason why we wouldn't want to bump soversion when making new release? Unless it's a minor bugfix release of course but so far we haven't bothered with those AFAIK. I've tried to add some general notes to https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release but there's still plenty of room for improvement. In general I thought that releasing new library version is the perfect opportunity to update soversion as well. > > gsm0808_create_lcls_conn_ctrl() has changed its argument type. Are we > sure there were no users of the function? The only user I know of is OsmoBSC v1.3.0 which is part of several repositories according to https://repology.org/metapackage/osmo-bsc/versions - shall we change the function name or bumping soversion will take care of ABI incompatibility? From reading old paper by Ulrich Drepper [1] the latter seems to be the case. If I'm missing something than we should document it by expanding our release wiki [2]. > In libosmocore we have some problem related to 'struct log_target': > http://people.osmocom.org/laforge/abi-report/compat_report/libosmocore/0.12.1/current/4981a/abi_compat_report.html > I suppose this is "only" ABI breakage but not API breakage and hence a > new libversion can rescue us? I'm confused by this: I thought that API breakage is taken care by new release version while ABI breakage is handle with new libversion? > Feel free to comment. The most important part is to get the > libosmocore/LCLS questions resolved. Let me know if I should make a patch which will covert ABI breakage into new API by adding gsm0808_create_lcls_conn_ctrl2() for example. [1] https://www.akkadia.org/drepper/dsohowto.pdf [2] https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release -- - Max Suraev 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 Directors: Harald Welte From laforge at gnumonks.org Sat Jan 19 20:35:33 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 19 Jan 2019 21:35:33 +0100 Subject: tagging new versions / problems In-Reply-To: <5b8c4a0a-052b-4af7-e2a2-638e201694b6@sysmocom.de> References: <20190118232432.GD1689@nataraja> <5b8c4a0a-052b-4af7-e2a2-638e201694b6@sysmocom.de> Message-ID: <20190119203533.GL1689@nataraja> Hi Max, On Sat, Jan 19, 2019 at 04:56:43PM +0100, Max wrote: > 19.01.19 00:24, Harald Welte ?????: > > 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. > > Maybe we could integrate it into 'make release' helper of libosmocore? I don't see how that would work. You have to analyze *befoer* you do 'make release'. Instead, the plan is to simply run the job to generate the reports by a cronjob every night, so that we have daily up-to-date reports of how 'current' differs from the last tagged version of each library. > > 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. > > In general, is there particular reason why we wouldn't want to bump > soversion when making new release? Unless it's a minor bugfix release of > course but so far we haven't bothered with those AFAIK. Compatibility. We don't want to force people to rebuild all their binaries just because somebody thought an enum was better than an uint8_t as a function argument. Sure, if there are important reasons to break ABI, do it. But don't do it without a good reason. > > gsm0808_create_lcls_conn_ctrl() has changed its argument type. Are we > > sure there were no users of the function? > > The only user I know of is OsmoBSC v1.3.0 which is part of several > repositories according to https://repology.org/metapackage/osmo-bsc/versions > - shall we change the function name or bumping soversion will take care of > ABI incompatibility? The problem here is not ABI compatibility, but API compatibility. Sure, we can (and have to) bump the LIBVERSION/soversion. But then if you want to build the old application (OsmoBSC v1.3.0 in your example) against a new libosmocore it will fail. This is absolutely unacceptable. However, I cannot find any reference to gsm0808_create_lcls_conn_ctrl() in osmo-bsc, neither in 1.3.0 nor in master - nor in the entire commit log. I guess we were really lucky this time. But still, I don't get all this "changing function signatures for no real gain" game. The old signature accepted pointers to the structure, and you had to change it so the structures are passed on the stack. Where's the gain in that? You camn do it one way or another. Why even only risk breaking some unknown 3rd party program out there for no apparent benefit at all? > I'm confused by this: I thought that API breakage is taken care by new > release version while ABI breakage is handle with new libversion? API breakage is never "taken care of". We cannot break APIs, as a general rule. Old applications should always work if recompiled against new libraries. There are exceptions in situations where e.g. a symbol was accidentially exported which was only meant to be used inside the library. Then it's fine to remove it. But changing the signature of a function *after* it has been part of a tagged version is *not* acceptable. > Let me know if I should make a patch which will covert ABI breakage into new > API by adding gsm0808_create_lcls_conn_ctrl2() for example. If at all, I would simply revert the change. But it seems we can do without. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From gullik.webjorn at corevalue.se Mon Jan 21 12:05:09 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Mon, 21 Jan 2019 13:05:09 +0100 Subject: Enable / disable of a bts / trx Message-ID: <8655bc3f-81d5-642f-e8da-8a0d4b6dc322@corevalue.se> 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 From nhofmeyr at sysmocom.de Mon Jan 21 13:15:15 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 21 Jan 2019 14:15:15 +0100 Subject: tagging new versions / problems In-Reply-To: <20190118232432.GD1689@nataraja> References: <20190118232432.GD1689@nataraja> Message-ID: <20190121131515.GB26847@my.box> On Sat, Jan 19, 2019 at 12:24:32AM +0100, Harald Welte wrote: > In libosmocore we have some problem related to 'struct log_target': > http://people.osmocom.org/laforge/abi-report/compat_report/libosmocore/0.12.1/current/4981a/abi_compat_report.html > I suppose this is "only" ABI breakage but not API breakage and hence a > new libversion can rescue us? A new member added to the end of the struct. Since all log targets should be allocated by log_target_create(), in practice it isn't even an ABI breakage? We just pass log_target* on the ABI, right? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Jan 21 13:18:56 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 21 Jan 2019 14:18:56 +0100 Subject: tagging new versions / problems In-Reply-To: <20190119203533.GL1689@nataraja> References: <20190118232432.GD1689@nataraja> <5b8c4a0a-052b-4af7-e2a2-638e201694b6@sysmocom.de> <20190119203533.GL1689@nataraja> Message-ID: <20190121131856.GC26847@my.box> > > > 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. > > > > In general, is there particular reason why we wouldn't want to bump > > soversion when making new release? Unless it's a minor bugfix release of > > course but so far we haven't bothered with those AFAIK. > > Compatibility. We don't want to force people to rebuild all their > binaries just because somebody thought an enum was better than an > uint8_t as a function argument. > > Sure, if there are important reasons to break ABI, do it. But don't do > it without a good reason. I wish C had enum types with explicit size :/ IMO let's revert back to uint8_t and put the enum type in the API doc. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Tue Jan 22 02:00:31 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 22 Jan 2019 03:00:31 +0100 Subject: msgb_wrap_with_TL(): the hallmark of wrong choices made Message-ID: <20190122020031.GD26847@my.box> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Tue Jan 22 02:04:57 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 22 Jan 2019 03:04:57 +0100 Subject: msgb_wrap_with_TL(): the hallmark of wrong choices made In-Reply-To: <20190122020031.GD26847@my.box> References: <20190122020031.GD26847@my.box> Message-ID: <20190122020457.GA25451@my.box> It looks like we need a 1.3.1 tag in osmo-msc, osmo-msc 1.3.0 won't build with libosmocore 1.0.1 :/ ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jenkins at lists.osmocom.org Tue Jan 22 02:23:30 2019 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Tue, 22 Jan 2019 02:23:30 +0000 (UTC) Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #366 Message-ID: <480362691.751.1548123810077.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...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 at 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 From holger at freyther.de Tue Jan 22 15:16:18 2019 From: holger at freyther.de (Holger Freyther) Date: Tue, 22 Jan 2019 15:16:18 +0000 Subject: Declaratively describing network topology (WAS Re: Scaling up virtual bts tests for the BTS test - how I hold it wrong?) In-Reply-To: References: <079E0BD2-5621-4092-BEAD-EFB6A8E9D812@freyther.de> <72c0e399-c4dd-a08f-b6f7-bd25fc6dd4af@sysmocom.de> <42ff760e-a704-0847-3d7d-add77af0d047@sysmocom.de> Message-ID: <0FC29A3C-238E-4759-8E42-2C2677958BC0@freyther.de> > On 4. Jan 2019, at 02:36, Holger Freyther wrote: > Hey Pau! Please take your time to respond to this. I understand that this will stall for some time now. > > Does this change anything for you? When looking at the p4[1][2] examples I noticed they are in a similar situation. E.g. when building a network of 100 switches, it doesn't say how they are connected (I would make it one big loop). I think we are in a similar situation and have a need to define topology (without having to rewrite the test). In the interim I will make sure we can execute our single test properly. holger [1] A language to program network flow/switches. [2] https://github.com/p4lang/tutorials/blob/dc08948a344c6ff26af47d2a2447800cab94ab49/exercises/load_balance/topology.json From andreapellegrin at hotmail.it Sun Jan 20 14:17:32 2019 From: andreapellegrin at hotmail.it (Andrea Pellegrin) Date: Sun, 20 Jan 2019 14:17:32 +0000 Subject: Problems installing libosmocore / gr-gsm on my Mac Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Jan 22 15:36:19 2019 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 22 Jan 2019 16:36:19 +0100 Subject: msgb_wrap_with_TL(): the hallmark of wrong choices made In-Reply-To: <20190122020031.GD26847@my.box> References: <20190122020031.GD26847@my.box> Message-ID: <20190122153619.GF30886@nataraja> Hi Neels, On Tue, Jan 22, 2019 at 03:00:31AM +0100, Neels Hofmeyr wrote: > 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. I had the same feeling yesterday. To clarify "rewrite libosmocore git history" is probably what you hinted here :) > 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. This is generally what we do. And "generally", we prefix them with osmo_ in the libraries, and don't permit the osmo_ prefix for symbols in applications. However, the msgb_ code pre-dates the osmo_ prefix - it even predates the name Osmocom as the project name. So we have some legacy prefixes that are "reserved" for use in libosmo*. Those are bitvec_ gsmtap_ log_ msgb_ rate_ctr_ abis_nm_ gprs_cipher_ gsm0341_ gsm0480_ gsm0502_ gsm0503_ gsm0808_ gsm29118_ gsm0858_ gsm340_ gsm411_ gsm414_ gsm48_ gsm610_ gsm620_ gsm690_ gsm_7bit_ lapd_ lapdm_ milenage_ rsl_ rxlev_ tlv_ ipa_ccm bssgp_ gprs_ns_ gprs_nsvc_ btsctx_ osim_ vty_ vector_ telnet_ config_ cmd_ buffer_ Unfortunately a lot of them are rather generic, so it's hard to avoid, at least in absence of any automatic tests for it. It's a separate discussion whether we should e.g. stop to export los of libosmovty internals (buffer, vector, cmd) - and if we should prefix all symbols in libosmo* with osmo_* providing the older names only as backwards compatibility layer with possibly weak symbols to be able to migrate to a cleaner namespace at least at some point in the future. Furthermore, there is one factors that made this particular instance even more problematic: The respective functions were inline functions. Otherwise we could have simply turned the library symbol into a weak symbol, making any application implementation supersede the library one. > * Such API changes in libosmocore should be tested with "all" depending programs. ACK. So what's needed is some kind of build job that continuously builds old applications against modern libosmo*. This could be run at least once per day/night, so we get notified if we introduce any such breakage and can fix libosmo* shortly to keep the incompatiblity something that appeared for a few days in the history, at maximum. > * 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. That goes without saying. It just wasn't possible in this case. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From pespin at sysmocom.de Tue Jan 22 16:04:51 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 22 Jan 2019 17:04:51 +0100 Subject: Problems installing libosmocore / gr-gsm on my Mac In-Reply-To: References: Message-ID: <024861c6-40c5-39e8-faa5-0ce5ca153980@sysmocom.de> Hi, Developers of osmo* usually don't build stuff under MacOS, so it's not officially supported. You are hitting a MacOS specific issue most probably related to https://osmocom.org/issues/3722 Can you make sure you are building master libosmocore? (share the commit hash you are building). It should contain 2ca8cebac67cfa179af77aa8d507fd4b96b2b230 and 2bf01d439cbbf346c333043ec0c82e6d5ef62ee2. Please share some information about your system, like MacOS version. I guess you are using MacOS 10.14. Can you also share with us this file from your system? /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/time.h Please provide the information in the redmine ticket I shared above. -- - Pau Espin Pedrol 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 From oramadan at fb.com Tue Jan 22 16:19:50 2019 From: oramadan at fb.com (Omar Ramadan) Date: Tue, 22 Jan 2019 16:19:50 +0000 Subject: Osmo metrics and counters Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Jan 22 19:10:20 2019 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 22 Jan 2019 20:10:20 +0100 Subject: Problems installing libosmocore / gr-gsm on my Mac In-Reply-To: References: Message-ID: <20190122191020.GM30886@nataraja> Hi Andrea, On Sun, Jan 20, 2019 at 02:17:32PM +0000, Andrea Pellegrin wrote: > > Air-di-Andrea:libosmocore andreapellegrin$ make > /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive You appear to be building this on an unsupported platform. Please build on a Linux based system. We would love to have support for more/other platforms, but this support would have to come from developers who are actually working on those platforms, and who can commit to maintaining libosmocore and other bits there. If anyone wants to get patches merged to support OS X or other systems, feel free to submit them to gerrit.osmocom.org. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue Jan 22 21:12:36 2019 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 22 Jan 2019 22:12:36 +0100 Subject: OS#3764: backward compatibility: It's not just API Message-ID: <20190122211236.GN30886@nataraja> 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/osmo-sgsn/Debian_9.0/x86_64 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 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 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From gullik.webjorn at corevalue.se Tue Jan 22 23:21:49 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Wed, 23 Jan 2019 00:21:49 +0100 Subject: Limesdr mini on Orange Pi Zero Message-ID: I have now moved the Limesdr mini back and forth between the Orange Pi Zero and a Supermicro (i386). On the Pi Zero I get the following on the console: Tue Jan 22 20:36:43 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043130448] ClockInterface: sending IND CLOCK 321960 Tue Jan 22 20:36:44 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043130448] ClockInterface: sending IND CLOCK 322176 Tue Jan 22 20:36:45 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043130448] chan 0 recv buffer of len 2500 expect 894a7c got 895e68 (895e68) diff=13ec Tue Jan 22 20:36:45 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043130448] chan 0 recv buffer of len 2500 expect 895440 got 897024 (897024) diff=1be4 Tue Jan 22 20:36:45 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043130448] chan 0 recv buffer of len 2500 expect 895e04 got 897de4 (897de4) diff=1fe0 The DDEV message can continue for a long time, and typically then ends with the transceiver exiting. It can however sometimes recover, and the first message of recovery is a IND Clock message, after that the transceiver restarts, and all is again well for some undefined time. I have followed your suggestions, and rebuilt --with-neon-vfpv4 , and I have enabled debugging. If I understand correctly, the function is readSamples, and is the actual input from the Lime rx. The length seems always correct, since I do not get that log entry, but rather that the time has "slipped", i.e. the LMS api has not delivered anything for "diff" time, or the timestamp received has "jumped" in the Lime. This indicates to me that this specific arm cpu in combination with limesdr mini and the software "drops data". I will gladly try to debug or narrow this down, but ask for some suggestions on how to proceed. One thought is to save a timestamp each time through readSamples and compare to some constant to determine that the problem is NOT that we are unable to read as fast as required. reading 2500 samples would take 2.3 mS if I understand this, so we need to cal readsamples at about this rate.... Possible causes could be something *else* locking out the program. From nhofmeyr at sysmocom.de Wed Jan 23 01:25:06 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 23 Jan 2019 02:25:06 +0100 Subject: msgb_wrap_with_TL(): the hallmark of wrong choices made In-Reply-To: <20190122153619.GF30886@nataraja> References: <20190122020031.GD26847@my.box> <20190122153619.GF30886@nataraja> Message-ID: <20190123012506.GA6612@my.box> On Tue, Jan 22, 2019 at 04:36:19PM +0100, Harald Welte wrote: > So we have some legacy prefixes that are "reserved" for use in libosmo*. Those are > > bitvec_ > gsmtap_ > log_ > msgb_ > rate_ctr_ > abis_nm_ > gprs_cipher_ > gsm0341_ > gsm0480_ > gsm0502_ > gsm0503_ > gsm0808_ > gsm29118_ > gsm0858_ > gsm340_ > gsm411_ > gsm414_ > gsm48_ > gsm610_ > gsm620_ > gsm690_ > gsm_7bit_ > lapd_ > lapdm_ > milenage_ > rsl_ > rxlev_ > tlv_ > ipa_ccm > bssgp_ > gprs_ns_ > gprs_nsvc_ > btsctx_ > osim_ > vty_ > vector_ > telnet_ > config_ > cmd_ > buffer_ yikes, quite a few more than I would have thought! BTW, in osmo-msc we still have a number of gsm48_ and other "reserved" prefixes as well, for example gsm48_rx_mm_serv_req(). As I'm refactoring for the inter-MSC split I should be able to get rid of them. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Wed Jan 23 01:49:08 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 23 Jan 2019 02:49:08 +0100 Subject: Osmo metrics and counters In-Reply-To: References: Message-ID: <20190123014908.GB6612@my.box> On Tue, Jan 22, 2019 at 04:19:50PM +0000, Omar Ramadan wrote: > 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. Hi Omar, though I have no answer ready, I briefly skimmed the code, and it looks to me like we have CTRL interface commands ready to query rate counters etc, but I couldn't find commands to actually list the available ones. Also the VTY contains tailored counter listing commands in various programs but lacks a generic list of available names, AFAICT. I'm not 100% sure, maybe I missed it. What comes to mind though is that at the CCC congress in december, we used the stats export which feeds all those counters to an external statistics interface, and there we could browse the available KPIs with a web interface, being able to compose dashboards in a javascript clickety way, combining KPIs with formulas and getting all sorts of graphs, fancy stuff like that. I forget the name, was it a graphite server? I'm not familiar with the details, but that could be interesting to explore. In almost all the core network .cfg you can place a config like stats reporter statsd disable remote-ip ${STATSD_IP} remote-port 9125 level global no prefix enable stats interval 5 and IIUC run a statsd instance to forward to a graphite ... ... stopping here because I didn't set it up and don't know the details, I hope someone else can take over here and provide pointers. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jenkins at lists.osmocom.org Wed Jan 23 02:30:09 2019 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Wed, 23 Jan 2019 02:30:09 +0000 (UTC) Subject: Jenkins build is back to normal : Coverity-Upload (jenkins-job-builder) #367 In-Reply-To: <480362691.751.1548123810077.JavaMail.jenkins@jenkins.osmocom.org> References: <480362691.751.1548123810077.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <591110811.770.1548210609400.JavaMail.jenkins@jenkins.osmocom.org> See From laforge at gnumonks.org Wed Jan 23 10:39:14 2019 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 23 Jan 2019 11:39:14 +0100 Subject: Limesdr mini on Orange Pi Zero In-Reply-To: References: Message-ID: <20190123103914.GP30886@nataraja> Hi Gullik, On Wed, Jan 23, 2019 at 12:21:49AM +0100, Gullik Webjorn wrote: > I have followed your suggestions, and rebuilt --with-neon-vfpv4 , and I have > enabled debugging. Are you running the osmo-trx process with real-time priority (SCHED_RR)? What is the CPU load? Please note on a multi-core system the interesting bit is not the average load over all CPU cores, but the maximum load of any one of the cores. > The length seems always correct, since I do not get that log entry, > but rather that the time has "slipped", i.e. the LMS api has not > delivered anything for "diff" time, or the timestamp received has > "jumped" in the Lime. > [...] > This indicates to me that this specific arm cpu in combination with limesdr > mini and the software "drops data". I will gladly try to debug or narrow > this down, but ask for some suggestions on how to proceed. Correct. This is a problem we've been observing on a variety of platforms for quite some time. Some samples are lost. * maybe the polling interval (bInterval) in the endpoint descriptors is set too low? * maybe the number / size of bulk-in USB transfers (URBs) is insufficient and/or thery are not re-submitted fast enough. * maybe there's some other process using too much cpu / pre-empting osmo-trx? * maybe there's some [buggy?] driver used on this system that disables/masks interrupts or otherwise causes high scheduler latencies, by disabling pre-emption or the like? * maybe there's some bios/firmware/management-mode code that can interrupt normal OS processing without the OS even knowing about it. * maybe there's some power management (cpu speed throttling, thermal throttling, ...) interfering? I'm not familiar with the inner workings of LimeSuite, but any program that would expect to achieve high performance on libusb should (IMHO) be using the asynchronous API of libusb, and it should make sure there are always multiple URBs submitted at any given point in time, so that the kernel can handle data from the USB device without interruption. IF I read LimeSuite correctly, they are submitting 16 URBs for read (USB_MAX_CONTEXTS returned by GetBuffersCount() used by ReceivePacketsLoop() which in turn calls the somewhat interestingly named method dataPort->BeginDataReading() for each of the buffers. https://elinux.org/images/c/c8/Debugging_Methodologies_for_Realtime_Issues_in_Linux_Systems.pdf is a good introduction, it may be a bit dated. > One thought is to save a timestamp each time through readSamples and > compare to some constant to determine that the problem is NOT that we > are unable to read as fast as required. reading 2500 samples would > take 2.3 mS if I understand this, so we need to cal readsamples at about this rate.... The data can be lost (at least) * between the USB device and the USB host, if the bus is overloaded or somehow the kernel / hardware cannot handle/schedule transfers fast enough, or * between kernel and userspace Your test seem to be looking at the second part. You can use a CLOCK_MONOTONIC time source to take timestamps, as you indicated. > Possible causes could be something *else* locking out the program. yes. That's why in the normal mode of operation you usuall start with running osmo-trx with SCHED_RR / realtime prirority. This way normal tasks that run with regular priority are not going to interfere anymore. But then, that leaves tons of kernel/driver code, and hardware/bios/firmware... It would be great to sched more light on this, but it likely needs very thorough analysis across all layers of a system. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From gullik.webjorn at corevalue.se Wed Jan 23 12:05:58 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Wed, 23 Jan 2019 13:05:58 +0100 Subject: Limesdr mini on Orange Pi Zero In-Reply-To: <20190123103914.GP30886@nataraja> References: <20190123103914.GP30886@nataraja> Message-ID: <3fe3f42b-6b82-25cd-388a-c732b60fea42@corevalue.se> Ok, some more experiments. I have made a small table that logs Linux time diffs in nanoseconds each time LMSDevice is called. From my first test this indicates that on this particular platform, within the last 8 calls time can be as low as 170 uS, i.e. a value of roughly 170000. But I also get times up to 44625499, i.e. 4.46 mS, and the values in the table can either look like: $2 = {32345376, 28481917, 16771791, 15794875, 16805792, 17252958, 44625499, 33037584} indicating several calls after one another had long times $4 = {198750, 179625, 33702624, 16127416, 27990666, 16007875, 13552168, 16100124} or the latest and 2'nd latest are low, but follow a sequence of long times. Thus, we are not dealing with a single interruption of short latency, but an extended period of long latency / interference. Once the condition occurs, I get 100's of logs of time mismatch, so, it does not recover. Right now I am wondering about fault recovery, i.e. what should the trx do once it has detected missing data? Whatever happens has a low chance of fixing the situation, once triggered, the condition persists. This is also indicated by the fact that the logged "diff" value is the *same* value in subsequent loggings, i.e. the trx does not recover / rewind / adjust timing to get back to normal. ?Are you running the osmo-trx process with real-time priority (SCHED_RR)? I tried that with no obvious effect..... > What is the CPU load? Please note on a multi-core system the > interesting bit is not the average load over all CPU cores, but the > maximum load of any one of the cores. "Normal" load is trx process taking 80 - 100 % out of 4 cpus, i.e. htop shows 4 cpus each with 20-25% load. trx seems to spread its threads over all cpus. > Correct. This is a problem we've been observing on a variety of > platforms for quite some time. Some samples are lost. > > * maybe the polling interval (bInterval) in the endpoint descriptors is > set too low? Hmm, my crude measurements indicate trx retrieving is cause, not lack of data. > * maybe the number / size of bulk-in USB transfers (URBs) is > insufficient and/or thery are not re-submitted fast enough. > * maybe there's some other process using too much cpu / pre-empting > osmo-trx? Yes it looks like that > Your test seem to be looking at the second part. You can use a > CLOCK_MONOTONIC time source to take timestamps, as you indicated. I used > clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &start_time); Maybe I should refine my test.... Thanx for your comments, Gullik From gullik.webjorn at corevalue.se Wed Jan 23 12:44:09 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Wed, 23 Jan 2019 13:44:09 +0100 Subject: Limesdr mini on Orange Pi Zero In-Reply-To: <3fe3f42b-6b82-25cd-388a-c732b60fea42@corevalue.se> References: <20190123103914.GP30886@nataraja> <3fe3f42b-6b82-25cd-388a-c732b60fea42@corevalue.se> Message-ID: <3e8a27ec-d9fa-886f-b201-b0edf18d8e09@corevalue.se> Just to make sure: We are reading 270 kbit/sec from the radio. Each sample is I + Q, 16 bits, 4 bytes With the Lime, samples per symbol is 4, so we are getting 4 bytes 4 * 270 k. So, we need to read 4.333 Mbytes / second. We read these 2500 bytes at the time, i.e. 1733 "packets" per second, each packet at 576 uS interval (average). Is this what to expect? Gullik From laforge at gnumonks.org Wed Jan 23 13:47:25 2019 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 23 Jan 2019 14:47:25 +0100 Subject: Limesdr mini on Orange Pi Zero In-Reply-To: <3fe3f42b-6b82-25cd-388a-c732b60fea42@corevalue.se> References: <20190123103914.GP30886@nataraja> <3fe3f42b-6b82-25cd-388a-c732b60fea42@corevalue.se> Message-ID: <20190123134725.GT30886@nataraja> On Wed, Jan 23, 2019 at 01:05:58PM +0100, Gullik Webjorn wrote: > platform, within the last 8 calls time can be as low as 170 uS, i.e. a value > of roughly 170000. But I also get times up to 44625499, i.e. 4.46 mS, the question is what is the target/expected value here, i.e. how many samples at which sample rate do we expect to read in every call, and what's the resulting interval? > Right now I am wondering about fault recovery, i.e. what should the > trx do once it has detected missing data? Whatever happens has a low > chance of fixing the situation, once triggered, the condition > persists. This is also indicated by the fact that the logged "diff" > value is the *same* value in subsequent loggings, i.e. the > trx does not recover / rewind / adjust timing to get back to normal. This is a very "dangerous" area. In a system like GSM, where there are performance figures specified as part of the spec conformance, we should be very careful about plastering over bugs like this. Any system (hardware + software) must be able to handle processing of all samples at any given point in time. If it can't handle this, it introduces bit errors which, if they happen frequently/reproducibly, will for sure degrade performance of the base station. So the "right" solution is to find the issue and solve it, not to "recover" by simply continuing with increased BER and degraded performance. If the system just magically recovers, I'm afraid people will put this into production operation without understanding the gravity of the problem, or that there is one at all. > ?Are you running the osmo-trx process with real-time priority (SCHED_RR)? > I tried that with no obvious effect..... I think ftrace with irqsoff, preemptoff, wakeup_rt tracers could be one option to debug this further. If there's a correlation between time with irqs/preemption disabled around the time of your "high latency bursts", that would be a very clear message. > > * maybe the polling interval (bInterval) in the endpoint descriptors is > > set too low? > Hmm, my crude measurements indicate trx retrieving is cause, not lack of > data. I'm not sure I understand yet how you reach that conclusion? It would be interesting to get some kind of watermarks of the amount of "used" libusb USB transfers inside LimeSuite. Maybe it's also worth increasing them or their size? > > * maybe there's some other process using too much cpu / pre-empting > > osmo-trx? > Yes it looks like that What about modifying osmo-trx to simply read and discard the samples, rather than processing them. Do you still get the overruns then? > > Your test seem to be looking at the second part. You can use a > > CLOCK_MONOTONIC time source to take timestamps, as you indicated. > I used > > clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &start_time); > Maybe I should refine my test.... This tells you how much CPU time a given process has consumed. It is not an absolut/reference clock. At least my understanding was that you wanted to take "absolute" timestamps. CLOCK_MONOTONIC_RAW is probably the best candidate for that. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Wed Jan 23 15:43:09 2019 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 23 Jan 2019 16:43:09 +0100 Subject: TOA loop / reporting Message-ID: 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 From gullik.webjorn at corevalue.se Wed Jan 23 20:39:50 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Wed, 23 Jan 2019 21:39:50 +0100 Subject: Limesdr mini on Orange Pi Zero In-Reply-To: <20190123134725.GT30886@nataraja> References: <20190123103914.GP30886@nataraja> <3fe3f42b-6b82-25cd-388a-c732b60fea42@corevalue.se> <20190123134725.GT30886@nataraja> Message-ID: <6807bbcc-8c2a-31c2-91f6-739e98d6f651@corevalue.se> >> Right now I am wondering about fault recovery, i.e. what should the >> trx do once it has detected missing data? Whatever happens has a low >> chance of fixing the situation, once triggered, the condition >> persists. This is also indicated by the fact that the logged "diff" >> value is the *same* value in subsequent loggings, i.e. the >> trx does not recover / rewind / adjust timing to get back to normal. > This is a very "dangerous" area. In a system like GSM, where there are > performance figures specified as part of the spec conformance, we should > be very careful about plastering over bugs like this. > > Any system (hardware + software) must be able to handle processing of > all samples at any given point in time. If it can't handle this, it > introduces bit errors which, if they happen frequently/reproducibly, > will for sure degrade performance of the base station. > > So the "right" solution is to find the issue and solve it, not to > "recover" by simply continuing with increased BER and degraded > performance. > > If the system just magically recovers, I'm afraid people will put this > into production operation without understanding the gravity of the > problem, or that there is one at all. > I am in violent agreement, but the process did NOT exit, and sometimes it DID recover, and except for the log messages I would not have seen the problem but for sporadic outage and other problems. I was just wondering what the thinking had been on handling this particular condition, apart from logging a LOG message... i.e. what is the best thing to do, when the error is detected? Mind you, I am just starting to learn how the trx is doing it's job, and thinking of what should happen next when this condition has occured. Is this something that *could* happen ( without broken hw ) and is it meaningful to continue to repeat the error?? Perhaps, the "jump" in timestamp has that effect on the "rest" of trx. What if the timestamp is screwed up on its way from Lime to trx?? > > I think ftrace with irqsoff, preemptoff, wakeup_rt tracers could be one > option to debug this further. If there's a correlation between time > with irqs/preemption disabled around the time of your "high latency > bursts", that would be a very clear message. Debugging, and my confusion will rise to a higher level... >>> * maybe the polling interval (bInterval) in the endpoint descriptors is >>> set too low? >> Hmm, my crude measurements indicate trx retrieving is cause, not lack of >> data. > I'm not sure I understand yet how you reach that conclusion? It would > be interesting to get some kind of watermarks of the amount of "used" > libusb USB transfers inside LimeSuite. Maybe it's also worth increasing > them or their size? Well, possible explanations.. 1. The limesdr sometimes fail to deliver a significant amount of packets, since the time "jumps" a large amount. 2. The trx / hw / linux fails to read packets, causing the lime to be unable to deliver the data, until trx / hw / linux becomes responsive again. 3. ??? It look like my crude tests shows that the trx can loop and get data at 170 uSec, but sometimes does not come back within 100 times that, why? To me 2. seems most probable....but I will see if I can check in LimeSuite. Also, tests with Limesdr and *other* applications can give clues.... >>> * maybe there's some other process using too much cpu / pre-empting >>> osmo-trx? >> Yes it looks like that > What about modifying osmo-trx to simply read and discard the samples, > rather than processing them. Do you still get the overruns then? I'll check.... >>> Your test seem to be looking at the second part. You can use a >>> CLOCK_MONOTONIC time source to take timestamps, as you indicated. I modified for MONOTONIC, no obvious change.... >> is tells you how much CPU time a given process has consumed. It is > not an absolut/reference clock. At least my understanding was that you > wanted to take "absolute" timestamps. CLOCK_MONOTONIC_RAW is probably > the best candidate for that. The fight goes on.... > Regards, > Harald Regards, Gullik From hwelte at sysmocom.de Fri Jan 25 12:27:08 2019 From: hwelte at sysmocom.de (Harald Welte) Date: Fri, 25 Jan 2019 13:27:08 +0100 Subject: New osmocom CNI versions released Message-ID: <20190125122708.GS30886@nataraja> 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 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 From laforge at gnumonks.org Sat Jan 26 10:37:05 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 26 Jan 2019 11:37:05 +0100 Subject: TOA loop / reporting In-Reply-To: References: Message-ID: <20190126103705.GD3930@nataraja> Hi Sylvain, On Wed, Jan 23, 2019 at 04:43:09PM +0100, Sylvain Munaut wrote: > 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. I don't recall any of this off my head, but I'm re-reading the code now to folow-up to your mail. > 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. The bit that this is only called for SACCH blocks in uplink was not known to me. I converted that code from float to integer math, and increased the resolution to 1/256 of bit period, but that SACCH-only logic seems to be there since the start. One note-worthy bit is that this algorithm will only modify the TA if the number of samples (in this case SACCH periods) has reached 16. This means the lchan->rqd_ta is only updated every ~ 7.6 seconds?! Please note that this code is in the osmo-bts-trx specific part. The "chan_state" you're referring to is the l1sched_chan_state which only exists on this particular PHY. > - chan_state->toa_* : This is used to send the average TOA value to L2 > in the Measurement Info ( call to l1if_process_meas_res ) This is correct, and is in the "common" part, i.e. it will be executed for any of sysmo,oc2g,octphy,trx. > * First confusing thing is the one in the 'meas' struct is actually > _not_ the one used for measurements info. I would look at it the other way around: The values computed for measurement reporting in the "common" part should be used also for the TA loop. Then, some PHYs like osmo-bts-trx don't have an internal TA loop and *must* always rely on the "common" TA loop code. Other PHYs that can do it in the DSP have the option of either a) computing it themselves (like now), or b) using the same "common" TA loop code This should then be a vty config option, and the default should be to use the "common" loop to ensure consistency across all hardware/PHYs we support. > * 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 ? Not that I'm aware of. I think this code goes back to what Jolly wrote in the early days of osmo-bts. I think it may be an oversight, and it's actually counterproductive. > * Why is there two way of keeping track of this in the first place ? * measurement processing is required for any PHY * TA computation is (by default) handled inside the DSP PHY of osmo-bts-{lc15,sysmo,oc2g} and hence the TA control is in the osmo-bts-trx specific part > tbh, I'm a bit confused as to why L2 needs that info at all. You need it e.g. in case of assigning a different channel (e.g. you're on a SDCCH, have established a certain TA and then assign a TCH/F). In this case, the TA value needs to be "inherited" from the old channel, and the BSC does so by copying the related values in its "lchan", which in turn will make sure the right IEs in the RSL CHAN ACT of the new channel are set. For more advanced BSCs than osmo-bsc, it's also feasible that the BSC would have a geographic/geometric map of the BTSs and establish the location of a MS, so that during hand-over to another cell you can do synchronous hand-over, where there's no RACH procedure on the new BTS/channel as you already have a very good estimate of what the TA on that new cell will be due to the geolocation knowledge. > 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. See above. > 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) ACK. And we should remove the l1sched_chan_state bits and rather rely on using the same values we're computing already on the "common" part for purpose of measurement reporting. > * 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. correct. And I think that "clearing of counters" etc. is all done (and tested!) for the measurement reporting, which is also happening at SACCH multiframe period. > 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. The interface between lower and upper side (provider and consumer) of L1SAP is on a per-block granularity. So the 4-8 bursts ToA values already get averaged into one report, and that report happens for each (23 byte) block. In other words: The INFO_IND period on L1SAP matches the DATA_IND period. In fact, dexter has an open ticket to merge those two so we have only one primitive for each block on the L1SAP interface, carrying both the mac block data as well as the associated measurments. This should simplify the code and make it easier to reads (and also slightly faster). > 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. ACK. Hope this clarifies :) Happy Hackimg, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat Jan 26 10:58:40 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 26 Jan 2019 11:58:40 +0100 Subject: Osmo metrics and counters In-Reply-To: References: Message-ID: <20190126105840.GE3930@nataraja> Dear Omar, On Tue, Jan 22, 2019 at 04:19:50PM +0000, Omar Ramadan wrote: > 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. I'm sorry that nobody has so far responded to this question. I thought this had long been taken care of :/ The list of counters of every program can be displayed/exported if you enter "show asciidoc counters", which is what we use to generate the tables you find in the manuals of the respective program. To get some more background about the individual counter types: * osmo_stat_item http://ftp.osmocom.org/api/latest/libosmocore/core/html/group__osmo__stat__item.html#details * rate_counter http://ftp.osmocom.org/api/latest/libosmocore/core/html/group__rate__ctr.html#details * osmo_counter (old, more or less deprecated) http://ftp.osmocom.org/api/latest/libosmocore/core/html/structosmo__counter.html * osmo_stats_reporter http://ftp.osmocom.org/api/latest/libosmocore/core/html/group__stats.html#details We have two of those in libosmcoore: One that reports to the logging sub-system, and another one that reports to statsd / behaves like a statsd exporter For rate counters, there's an example script on how to export them at http://git.osmocom.org/python/osmo-python-tests/tree/scripts/osmo_rate_ctr2csv.py If you have any more specific questions, please follow-up here. Thanks! Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat Jan 26 11:14:46 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 26 Jan 2019 12:14:46 +0100 Subject: Limesdr mini on Orange Pi Zero In-Reply-To: <3e8a27ec-d9fa-886f-b201-b0edf18d8e09@corevalue.se> References: <20190123103914.GP30886@nataraja> <3fe3f42b-6b82-25cd-388a-c732b60fea42@corevalue.se> <3e8a27ec-d9fa-886f-b201-b0edf18d8e09@corevalue.se> Message-ID: <20190126111446.GG3930@nataraja> Hi Gullik, I'm not the expert on osmo-trx, but as nobody else has followed-up so far: On Wed, Jan 23, 2019 at 01:44:09PM +0100, Gullik Webjorn wrote: > We are reading 270 kbit/sec from the radio. Each sample is I + Q, 16 bits, 4 > bytes To be more precise: 270 ksymbols/sec. Every sample is 16bit I+Q and hence four bytes in total. > With the Lime, samples per symbol is 4, so we are getting 4 bytes 4 * 270 k. indeed. > So, we need to read 4.333 Mbytes / second. also seems correct as per my understanding. > We read these 2500 bytes at the time, > i.e. 1733 "packets" per second, each packet at 576 uS interval (average). I cannot comment on that, but if those are the figures you found in the code, then that's it. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat Jan 26 11:12:18 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 26 Jan 2019 12:12:18 +0100 Subject: Osmo metrics and counters In-Reply-To: <20190123014908.GB6612@my.box> References: <20190123014908.GB6612@my.box> Message-ID: <20190126111218.GF3930@nataraja> Hi Neels, [this message is not adressed specifically to you, but to the wider community] On Wed, Jan 23, 2019 at 02:49:08AM +0100, Neels Hofmeyr wrote: > though I have no answer ready, I briefly skimmed the code, and it looks to me > like we have CTRL interface commands ready to query rate counters etc, but I > couldn't find commands to actually list the available ones. See my other response. > In almost all the core network .cfg you can place a config like > > stats reporter statsd > disable > remote-ip ${STATSD_IP} > remote-port 9125 > level global > no prefix > enable > stats interval 5 The problem is that this appears to have zero documentation beyond the API reference of libosmocore, which I pointed out in my other response on this thread. What we need is a section in the "common" part of the manuals explainig this mechanism in detail. I created https://osmocom.org/issues/3768 for this. This also brings me to http://osmocom.org/issues/3670 "TTCN-3 test for statsd exporter" which are missing so far. Finally, https://media.ccc.de/v/SE8HRK is a talk by daniel on the related features which may help as background information. Any volunteers? Seems like a very important topic operationally, but nothing anyone has been contributing any effort towards so far :/ Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat Jan 26 11:29:17 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 26 Jan 2019 12:29:17 +0100 Subject: Enable / disable of a bts / trx In-Reply-To: <8655bc3f-81d5-642f-e8da-8a0d4b6dc322@corevalue.se> References: <8655bc3f-81d5-642f-e8da-8a0d4b6dc322@corevalue.se> Message-ID: <20190126112917.GH3930@nataraja> Hi Gullik, On Mon, Jan 21, 2019 at 01:05:09PM +0100, Gullik Webjorn wrote: > What is the best practice to enable / disable a single bts / trx in a multi > trx configuration? Just stop/disconnect it? > Just stopping it, phones settle after some time, but I get a lot of timeouts in syslog. what kind 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 ? ) you can make any change to the configuration at runtime and you don't need to restart the BSC. Option 1: ---- enable configure terminal network bts 0 ip.access unit_id 55555 end drop bts connection 0 oml ---- assuming that "55555" is not a valid unit-id, the BTS will be disconnected and not permitted to reconnect due to unknown unit-id this is a bit of a hack. The better solution is: ---- enable configure terminal network bts 0 trx 0 rf_locked 1 end drop bts connection 0 oml ---- And then if you want to re-enable it, do the same with 'rf_locked 0'. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat Jan 26 12:25:42 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 26 Jan 2019 13:25:42 +0100 Subject: GSUP: E-interface messages for inter-MSC HO In-Reply-To: <670b347b-b6fb-36eb-9849-74e6eede31a5@gmx.net> References: <20190114020356.GA12467@my.box> <670b347b-b6fb-36eb-9849-74e6eede31a5@gmx.net> Message-ID: <20190126122542.GI3930@nataraja> Hi Jacob, great to read something from you here again. Thanks for your input! On Tue, Jan 15, 2019 at 01:28:42PM +0100, Jacob wrote: > The following questions come to my mind while reading this: > > * Why should this message router/server be part of the HLR? IMO these > are completely separate things. So I'd rather put this functionality > into a separate program/process. The HLR already contains a GSUP message router these days, which is used to route messages e.g. to "EUSE" (External USSD entities). The same is happening also for External SMS entities, as Vadim has enabled GSUP based SMS transport in OsmoMSC recently. So yes, one can argue that the functionality is reasonably distinct and should be yet another program to run. However, as GSUP messages so far don't contain an explicit sender or recipient, OsmoHLR can perform message routing based on the IPA identities of the connected programs. So if a LU comes from one given MSC, the IPA identity of that MSC is stored in the HLR as sort-of replacement of the global title of the MSC. If a MO-USSD arrives at the MSC, we take a routing decision based on the USSD code and route it to an EUSE. The EUSE itself is again identified by its IPA identity as communicated over the related GSUP connection. Once the EUSE responds, we use the IMSI as lookup into the HLR database, and get the IPA identity of the MSC, to which we then route the response. So unless we want to have an explicit "routing header" on the GSUP side, the GSUP router must be inside the HLR. What was clear to me from the beginning is that we don't want OsmoMSC to have multiple GSUP connections and do the routing itself. The latter was proposed by Vadim, IIRC. However, this would make it only more difficult to introduce a central GSUP-to-MAP or GSUP-to-DIAMETER gateway. > * What about adding a separate IPA protocol id for routing (proxying > might came closer for the case given), that itself just carries other > IPA messages of a different type along with source/destination_name and > possibly other IEs that just relate to proxying (and possibly the > session stuff, unless that went to another layer)? This could then be > used with every IPA protocol and won't mess with the application layer. It's an option, yes. However, we already introduced USSD and SMS over GSUP which add the SESSION_STATE and SESSION_ID, see http://git.osmocom.org/libosmocore/tree/include/osmocom/gsm/gsup.h#n182 So rather than changing everything again in an incompatible way, I think the safe approach is to add whatever needed to GSUP itself. > * What about security? Proxying will prevent conventional network > monitoring tools and firewalls from working properly. Will it be > possible to limit proxying to certain peers e.g. via configuration? I'm not sure I'm following you here. > BTW, the source and destination name IEs correspond to the global titles > in the SCCP layer of SS7. There also exist means to address a > destination logically (e.g. send this to the HLR that is responsible for > that IMSI, see the E.214 numbering plan). YYs. We basically thought that we'd treat the IPA ID as a binary blob, so that the HLR could potentially also simply store a SCCP-encoded GT later on, if ever required. Let's think for example some external SMSC registering itself in the waiting list to be informed once the subscriber is back online, ... > > - The session_id/session_state: we still need to figure out how to avoid > > collisions in session_id numbers, as any peer may at any point re-use the > > same session_id. Vadim suggested using a TI flag that gets flipped between > > sender and receiver, but since there are more than two peers, I guess we > > should treat each session_id as subordinate to a Request's source_name. IOW, > > any peer owns the entire session_id number space itself for sending out > > Request message types, and a Response or Error message type echos this > > session_id back with the source_name then having become the destination_name; > > it is perfectly legal for two peers to use the same session_id and collisions > > are avoided by Request vs. Response/Error. Something like... > > To me this really sounds like re-implementing (parts of) TCAP (ITU T > Q.770-779) . Ideally this is not the case. We just need the bare minimum that provides us with a separation of the indivivudal concurrent dialogues. I personally find the OTID/DTID approach of TCAP very difficult to follow, as there's normally only one of the two visible in each packet. Makes debugging hard, makes filtering in wireshark hard, ... > While I like the idea to extend GSUP/IPA, I'm wondering whether at some > point in the future it was better to just use the standard protocols > (e.g. MAP/TCAP/SCCP, possibly on top of IPA, perhaps just MAP on IPA > possibly combined with some restrictions concerning segmentation etc) > instead of partly reimplementing all of them. At least I'd rather > properly separate the session/proxying stuff from GSUP (still being a > simplified MAP replacement). By now we're using (connection oriented) SCCP aleready on the AoIP interface between OsmoBSC and OsmoMSC (via OsmoSTP in between). So speaking connectionless SCCP is certainly not a problem in terms of available osmocom infrastructure. TCAP, well, I once started a libosmo-tcap C implementation, which is still far from being complete. So lots of work would be required there. Using "just" the MAP encoding/decoding for the messages is an option, but we'd have to standardize on one specific MAP version for each application context, and we'd have to exclude segmentation as you suggest. Also, technically there's no problem with this as MAP is using ASN.1 BER, which we can speak without any problems from Lev Walkins' asn1c. The problem is that MAP doesn't contain the addresses (GTs) of the SCCP level, nor does it contain the session/dialogue notion of TCAP. So even if we used MAP as the inner messages, we'd still need the "routing" bits that were' talking about above. So switching to restricted-MAP-over-GSUP doesn't reduce the problem domain of SCCP+TCAP, responsible for routing and session/dialogue. The fundamental struggle that we have is the compromise between 1) staying if possible as close as possible to the 3GPP architecture, and 2) avoiding most of the complexities that go along with this. GSM is complex enough to set up, even without having to worry about SCCP etc. - Most of our users are not a public operator, and they have no SS7, no global titles, no point codes, etc. We tried hard with the AoIP interface, where we introduced lots of "magic" such as dynamic routing key registratio in OsmoSTP, etc. to ensure people can run OsmoBSC and OsmoMSC without having to know and configure all those bits - while at the same time allowing those with the skills (and requirements to talk to other MSCs) to do so. I don't think we did a perfect job on the A interface side, and I worry about introducing yet another of those interfaces. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat Jan 26 12:38:12 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 26 Jan 2019 13:38:12 +0100 Subject: GSUP: E-interface messages for inter-MSC HO In-Reply-To: <20190114020356.GA12467@my.box> References: <20190114020356.GA12467@my.box> Message-ID: <20190126123812.GK3930@nataraja> Hi Neels, I finally got a chance to catch up with various pending e-mails and hence this thread. On Mon, Jan 14, 2019 at 03:03:56AM +0100, Neels Hofmeyr wrote: > I placed the draft in osmo-msc/doc/interMSC_HO_GSUP_msgs.txt on my branch neels/ho: > http://git.osmocom.org/osmo-msc/tree/doc/interMSC_HO_GSUP_msgs.txt?h=neels/ho > > Anyone else is also more than welcome to take a look and remark on anything > that might seem a bad idea, etc. I'm not the expert on Inter-MSC HO, but it looks fine to me, from what I know. > Also interesting to figure out: Implement the IPA routing for which I added the > source_name and destination_name IEs: N osmo-mscs connected to one osmo-hlr > forward messages to each other via GSUP. > > - Connect two GSUP clients (test programs?) to a running osmo-hlr instance, and > to extend the gsup_server so that we can use the source_name/destination_name > IEs to forward GSUP messages between the two clients. (I added these because > I'm fairly certain there is no existing in-band IPA protocol bits that would > allow such routing; but I only briefly skimmed it, wouldn't hurt if you could > verify that again.) The aim is to have plain gsup_client API to allow me to > "just send messages back and fort". the existing gsup router inside OsmoHLR already does half of the job: It checks the list of GSUP connections and can route a message by the IPA identity of the peer. This is what's used for routing between OsmoMSC[s]s and EUSE[s]. The only difference AFAICT in this inter-msc HO scenario is that the destination identity would be read from a GSUP IE. But the actual route lookup would be just like the existing code, using gsup_route_find(), or even better: the osmo_gsup_addr_send() high level function to which you simply pass the IP identity to which you want to transmit to. > - The session_id/session_state: we still need to figure out how to avoid > collisions in session_id numbers, as any peer may at any point re-use the > same session_id. Vadim suggested using a TI flag that gets flipped between > sender and receiver, but since there are more than two peers, I guess we > should treat each session_id as subordinate to a Request's source_name. IOW, > any peer owns the entire session_id number space itself for sending out > Request message types, and a Response or Error message type echos this > session_id back with the source_name then having become the destination_name; > it is perfectly legal for two peers to use the same session_id and collisions > are avoided by Request vs. Response/Error. Something like... If that works: Great, problem solved! > (We could possibly omit the source_name in Response/Error message types, > because the Requestor already knows the peer from sending out the Request; > but for sanity, maybe rather always keep both names.) It makes filtering in wireshark so much easier to have the context in every message, so please keep it. > - And we need to make sure that we can freely re-use the session_id IE on the > E-interface without conflicting with the Supplementary Services session_id / > without confusing the gsup_client API. Using one common/shared allocator function inside OsmoMSC shouldn't be a problem. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat Jan 26 12:31:21 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 26 Jan 2019 13:31:21 +0100 Subject: GSUP: E-interface messages for inter-MSC HO In-Reply-To: <20190115134404.GB21676@my.box> References: <20190114020356.GA12467@my.box> <670b347b-b6fb-36eb-9849-74e6eede31a5@gmx.net> <20190115134404.GB21676@my.box> Message-ID: <20190126123121.GJ3930@nataraja> Hi! On Tue, Jan 15, 2019 at 02:44:04PM +0100, Neels Hofmeyr wrote: > > BTW, the source and destination name IEs correspond to the global titles > > in the SCCP layer of SS7. There also exist means to address a > > destination logically (e.g. send this to the HLR that is responsible for > > that IMSI, see the E.214 numbering plan). > > This is the first time I'm thinking about more than one HLR in Osmocom. I'm > out of my depth here... The general policy is that OsmoSGSN and OsmoMSC always only talk to one GSUP server, which is [so far] OsmoHLR with its internal GSUP router. If you want MAP connectivity, the strategy is to replace that OsmoHLR with its built-in GSUP router and swap in a GSUP-to-MAP gateway. This gateway then can do the normal E.214 translations etc. But in a pure Osmo* setup (still the majority of our users) we want to avoid all the related complexity. If one wanted multiple HLRs in a pure Osmo* network (like in the proposed Rhizomatica "distributed GSM"), then the GSUP router inside OsmoHLR (or some new proxy?) would have to do ISMI prefix matching and then forward the IP address of the HLR responsible for that IMSI-prefix. > Except that in TCAP, both sides invent an own ID for a dialogue. I'm planning > to have just one ID sent back and forth, which the first Request specifies, and > then remains the same from both sides. I really like that. As an alternative, one could still have two identifiers but make sure they are present in all messages - like source and destination port numbers. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jenkins at lists.osmocom.org Mon Jan 28 02:23:58 2019 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Mon, 28 Jan 2019 02:23:58 +0000 (UTC) Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #372 Message-ID: <793253029.85.1548642238141.JavaMail.jenkins@jenkins.osmocom.org> See Changes: [laforge] latest-packages: Add libosmo-dsp [laforge] osmocom-*-packages: clone via https:// not via unencrypted git:// ------------------------------------------ [...truncated 738.40 KB...] CC RANAP_RAB-SubflowCombinationBitRate.lo CC RANAP_RAB-TrCH-Mapping.lo CC RANAP_RAB-TrCH-MappingItem.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_RAC.lo 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 CC RANAP_SAC.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 { ^~~~~~~~~~~~~ CC RANAP_SAI.lo CC RANAP_SAPI.lo CC RANAP_SessionUpdateID.lo CC RANAP_Shared-Network-Information.lo CC RANAP_Session-Re-establishment-Indicator.lo CC RANAP_SignallingIndication.lo CC RANAP_SDU-ErrorRatio.lo CC RANAP_SDU-FormatInformationParameters.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 RANAP_Shared-Network-Information.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_SDU-FormatInformationParameterItem.lo CC RANAP_SDU-Parameters.lo CC RANAP_SDU-ParameterItem.lo CC RANAP_SNA-Access-Information.lo CC RANAP_SNAC.lo CC RANAP_Service-Handover.lo CC RANAP_Source-ToTarget-TransparentContainer.lo CC RANAP_SourceeNodeB-ToTargeteNodeB-TransparentContainer.lo CC RANAP_SourceCellID.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_AuthorisedPLMNs.h:14, from ../../include/osmocom/ranap/RANAP_SNA-Access-Information.h:14, from RANAP_SNA-Access-Information.c:7: ../../include/osmocom/ranap/RANAP_AuthorisedPLMNs.h:27:23: warning: ?struct MemberC? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberC { ^ /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_AuthorisedPLMNs.h:27:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct MemberC { ^~~~~~~~~~~~~ CC RANAP_SourceBSS-ToTargetBSS-TransparentContainer.lo CC RANAP_SourceID.lo CC RANAP_SourceRNC-ID.lo CC RANAP_SourceRNC-ToTargetRNC-TransparentContainer.lo CC RANAP_IRAT-Measurement-Configuration.lo CC RANAP_IRATmeasurementParameters.lo CC RANAP_RSRQ-Type.lo CC RANAP_RSRQ-Extension.lo CC RANAP_EUTRANFrequencies.lo CC RANAP_MeasBand.lo CC RANAP_SubscriberProfileIDforRFP.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_EUTRANFrequencies.h:14, from ../../include/osmocom/ranap/RANAP_IRATmeasurementParameters.h:15, from ../../include/osmocom/ranap/RANAP_IRAT-Measurement-Configuration.h:15, from RANAP_IRAT-Measurement-Configuration.c:7: ../../include/osmocom/ranap/RANAP_EUTRANFrequencies.h:27:23: warning: ?struct MemberJ? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberJ { ^ /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_EUTRANFrequencies.h:27:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct MemberJ { ^~~~~~~~~~~~~ CC RANAP_SourceStatisticsDescriptor.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_EUTRANFrequencies.h:14, from ../../include/osmocom/ranap/RANAP_IRATmeasurementParameters.h:15, from RANAP_IRATmeasurementParameters.c:7: ../../include/osmocom/ranap/RANAP_EUTRANFrequencies.h:27:23: warning: ?struct MemberJ? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberJ { ^ /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_EUTRANFrequencies.h:27:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct MemberJ { ^~~~~~~~~~~~~ CC RANAP_SupportedRAB-ParameterBitrateList.lo CC RANAP_SupportedBitrate.lo CC RANAP_SourceUTRANCellID.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_EUTRANFrequencies.h:14, from RANAP_EUTRANFrequencies.c:7: ../../include/osmocom/ranap/RANAP_EUTRANFrequencies.h:27:23: warning: ?struct MemberJ? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberJ { ^ /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_EUTRANFrequencies.h:27:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct MemberJ { ^~~~~~~~~~~~~ CC RANAP_SRB-ID.lo CC RANAP_SRB-TrCH-Mapping.lo CC RANAP_SRB-TrCH-MappingItem.lo CC RANAP_SRVCC-HO-Indication.lo CC RANAP_SRVCC-Information.lo CC RANAP_SRVCC-Operation-Possible.lo CC RANAP_SubflowSDU-Size.lo CC RANAP_TAC.lo CC RANAP_TAI.lo CC RANAP_Target-ToSource-TransparentContainer.lo CC RANAP_TargeteNodeB-ToSourceeNodeB-TransparentContainer.lo CC RANAP_TargetBSS-ToSourceBSS-TransparentContainer.lo CC RANAP_TargetCellId.lo CC RANAP_TargetENB-ID.lo CC RANAP_TargetRNC-ID.lo CC RANAP_TargetID.lo CC RANAP_TargetRNC-ToSourceRNC-TransparentContainer.lo CC RANAP_TBCD-STRING.lo CC RANAP_TemporaryUE-ID.lo CC RANAP_Time-UE-StayedInCell.lo CC RANAP_Time-UE-StayedInCell-EnhancedGranularity.lo CC RANAP_TimeToMBMSDataTransfer.lo CC RANAP_TimingDifferenceULDL.lo /bin/bash: line 1: 9944 Segmentation fault /bin/bash ../../libtool --silent --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.4.0.1-04b5\" -DPACKAGE_STRING=\"osmo-iuh\ 0.4.0.1-04b5\" -DPACKAGE_BUGREPORT=\"openbsc at 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.1-04b5\" -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_TimeToMBMSDataTransfer.lo -MD -MP -MF .deps/RANAP_TimeToMBMSDataTransfer.Tpo -c -o RANAP_TimeToMBMSDataTransfer.lo RANAP_TimeToMBMSDataTransfer.c Makefile:2506: recipe for target 'RANAP_TimeToMBMSDataTransfer.lo' failed make[4]: *** [RANAP_TimeToMBMSDataTransfer.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 1390 C/C++ compilation units (100%) successfully 1390 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 From holger at freyther.de Mon Jan 28 08:08:36 2019 From: holger at freyther.de (Holger Freyther) Date: Mon, 28 Jan 2019 08:08:36 +0000 Subject: Reset GSM tester state? Message-ID: <5A7FC84F-2B1B-4B10-A4F5-F2C8A86F7CD2@freyther.de> A wild guess but can any of you check if the GSM tester state is corrupt again? My test with virtual equipment failed the last two times I tried with no IP addresses available and the production run seems broken as well. thank you! holger From nhofmeyr at sysmocom.de Mon Jan 28 12:52:09 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 28 Jan 2019 13:52:09 +0100 Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #372 In-Reply-To: <793253029.85.1548642238141.JavaMail.jenkins@jenkins.osmocom.org> References: <793253029.85.1548642238141.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <20190128125209.GC1720@my.box> On Mon, Jan 28, 2019 at 02:23:58AM +0000, jenkins at lists.osmocom.org wrote: > See > > CC RANAP_Time-UE-StayedInCell.lo > CC RANAP_Time-UE-StayedInCell-EnhancedGranularity.lo > CC RANAP_TimeToMBMSDataTransfer.lo > CC RANAP_TimingDifferenceULDL.lo > /bin/bash: line 1: 9944 Segmentation fault [...] > Makefile:2506: recipe for target 'RANAP_TimeToMBMSDataTransfer.lo' failed > make[4]: *** [RANAP_TimeToMBMSDataTransfer.lo] Error 139 > make[4]: *** Waiting for unfinished jobs.... I think this is exactly what I saw when I tried to build osmo-iuh on debian-stable for congress! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Jan 28 13:10:58 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 28 Jan 2019 14:10:58 +0100 Subject: Reset GSM tester state? In-Reply-To: <5A7FC84F-2B1B-4B10-A4F5-F2C8A86F7CD2@freyther.de> References: <5A7FC84F-2B1B-4B10-A4F5-F2C8A86F7CD2@freyther.de> Message-ID: <20190128131058.GE1720@my.box> On Mon, Jan 28, 2019 at 08:08:36AM +0000, Holger Freyther wrote: > A wild guess but can any of you check if the GSM tester state is corrupt again? My test with virtual equipment failed the last two times I tried with no IP addresses available and the production run seems broken as well. > > thank you! I notice the osmo-gsmtester-prod moved to IP address .107 since I was last on it. But I can log in. The /var/tmp/osmo-gsm-tester/state has reserved resources since 2019-01-23 22:21:01. The 'ps' output looks troubling, a large number of tcpdumps running: 843!! wtf See http://people.osmocom.org/neels/eengeeK2/gsm_tester_ps.txt No 'osmo-gsm-tester.py' in ps, so nothing is running. I erased the reserved_resources and rebooted. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From pespin at sysmocom.de Mon Jan 28 20:30:36 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 28 Jan 2019 21:30:36 +0100 Subject: Reset GSM tester state? In-Reply-To: <20190128131058.GE1720@my.box> References: <5A7FC84F-2B1B-4B10-A4F5-F2C8A86F7CD2@freyther.de> <20190128131058.GE1720@my.box> Message-ID: Hi, that happens from time to time because while running a job in there, the jenkins connection between jenkins master and slave fails. As a result, jenkins decides it's a good idea to kill -9 osmo-gsm-tester process, leaving as a result its child processes alive without anybody controlling them. I usually take care myself of removing those processes (ps -ef | grep osmo, kill) and cleaning state (rm /var/tmp/osmo-gsm-tester/state/*) when I see lots of tests failing with UNKNOWN during the more-or-less daily jenkins job. Unfortunately, due to being on sick leave these days it may take longer than usual to have this work done after a conn failure, my apologies. Thanks Neels for taking care of the issue. Kind regards, Pau -- - Pau Espin Pedrol 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 From laforge at gnumonks.org Tue Jan 29 00:33:11 2019 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 29 Jan 2019 01:33:11 +0100 Subject: Jeknins leaking processes (was Re: Reset GSM tester state?) In-Reply-To: References: <5A7FC84F-2B1B-4B10-A4F5-F2C8A86F7CD2@freyther.de> <20190128131058.GE1720@my.box> Message-ID: <20190129003311.GM19437@nataraja> Hi Pau, On Mon, Jan 28, 2019 at 09:30:36PM +0100, Pau Espin Pedrol wrote: > that happens from time to time because while running a job in there, the > jenkins connection between jenkins master and slave fails. As a result, > jenkins decides it's a good idea to kill -9 osmo-gsm-tester process, > leaving as a result its child processes alive without anybody controlling > them. FYI, this leaking ofprocesses is a known bug in Jenkins since 2013 (!) which many people raised at https://issues.jenkins-ci.org/browse/JENKINS-17116 It's a real pity that such an importan bug doesn't seem to get fixed by Jenkins upstream. If there are any Java developers with some spare cycles reading here, it would really be great if you could contribue a related fix upstream. Thanks! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jenkins at lists.osmocom.org Tue Jan 29 02:30:07 2019 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Tue, 29 Jan 2019 02:30:07 +0000 (UTC) Subject: Jenkins build is back to normal : Coverity-Upload (jenkins-job-builder) #373 In-Reply-To: <793253029.85.1548642238141.JavaMail.jenkins@jenkins.osmocom.org> References: <793253029.85.1548642238141.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <202689420.104.1548729007031.JavaMail.jenkins@jenkins.osmocom.org> See From gullik.webjorn at corevalue.se Tue Jan 29 11:20:20 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Tue, 29 Jan 2019 12:20:20 +0100 Subject: Limesdr mini on Orange Pi Zero In-Reply-To: <20190126111446.GG3930@nataraja> References: <20190123103914.GP30886@nataraja> <3fe3f42b-6b82-25cd-388a-c732b60fea42@corevalue.se> <3e8a27ec-d9fa-886f-b201-b0edf18d8e09@corevalue.se> <20190126111446.GG3930@nataraja> Message-ID: I have tried to investigate *where* the type #3339 bug occurs. I was thinking in terms either Lime hw / fw / driver drops packets, or something screws up the timestamp leading to the perception of lost data. I have added some debug printouts, where LMS_GetStreamStatus is called, and as the error occurs, I also get dropped packets. The explanation from the API is that droppedPackets = "Number of dropped packets by HW." To me this indicates that the program / usb driver / usb is not emptying the on board fifo frequently enough, and that this is the cause of the problem ( as Harald indicated he suspected ) At least I have convinced myself that: 1??? Packets are lost within the Lime board ( since it reports them) and not in the higher levels of code. 2??? That it is indeed "lowlevel" i.e. Lime driver or usb driver bug, or just the fact we do not get time to process quick enough, ????? which I feel we should have plenty of cpu to compensate for. Gullik And yes, we should not confuse bits and symbols :-) From holger at freyther.de Tue Jan 29 16:25:08 2019 From: holger at freyther.de (Holger Freyther) Date: Tue, 29 Jan 2019 16:25:08 +0000 Subject: Reset GSM tester state? In-Reply-To: References: <5A7FC84F-2B1B-4B10-A4F5-F2C8A86F7CD2@freyther.de> <20190128131058.GE1720@my.box> Message-ID: > On 28. Jan 2019, at 20:30, Pau Espin Pedrol wrote: > > Hi, Hi! I don't know how the state works but have you considered: * Adding stale detection, either in code or jenkins? * far fetched.. look if subreaper can be of any help? cheers holger > > that happens from time to time because while running a job in there, the jenkins connection between jenkins master and slave fails. As a result, jenkins decides it's a good idea to kill -9 osmo-gsm-tester process, > leaving as a result its child processes alive without anybody controlling them. > > I usually take care myself of removing those processes (ps -ef | grep osmo, kill) and cleaning state (rm /var/tmp/osmo-gsm-tester/state/*) when I see lots of tests failing with UNKNOWN during the more-or-less daily jenkins job. Unfortunately, due to being on sick leave these days it may take longer than usual to have this work done after a conn failure, my apologies. > > Thanks Neels for taking care of the issue. > > Kind regards, > Pau > > -- > - Pau Espin Pedrol 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 From nhofmeyr at sysmocom.de Wed Jan 30 12:47:39 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 30 Jan 2019 13:47:39 +0100 Subject: Reset GSM tester state? In-Reply-To: References: <5A7FC84F-2B1B-4B10-A4F5-F2C8A86F7CD2@freyther.de> <20190128131058.GE1720@my.box> Message-ID: <20190130124739.GA3079@my.box> On Tue, Jan 29, 2019 at 04:25:08PM +0000, Holger Freyther wrote: > > > > On 28. Jan 2019, at 20:30, Pau Espin Pedrol wrote: > > > > Hi, > > > Hi! > > I don't know how the state works but have you considered: > > * Adding stale detection, either in code or jenkins? > * far fetched.. look if subreaper can be of any help? The state works pretty nicely if you don't kill -9 the process :P The thought to build another safeguard around it has come up a few times before. yet we probably wouldn't be talking about it if jenkins didn't maintain that habit of just kicking open the airlock to void space on the osmo-gsm-tester. (OTOH of course it would be even nicer if we could deal with kill -9 safely as well, but where do you draw the line; there's always *some* place where a kill -9 breaks the plan.) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Wed Jan 30 13:43:56 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 30 Jan 2019 14:43:56 +0100 Subject: channel statistics Message-ID: <20190130134356.GC3079@my.box> After 35c3 and talking about statistics, it has become apparent to me that we lack a good way of monitoring channel usage / availability; TL;DR: I think we need min/max aggregators that sync with the stats push/poll time period. This is just an idea I'm getting, not planning on implementing anything now, nor have I really done my homework and tried to achieve useful stats. Has anyone discussed this before / created an issue / solved it in a different way? Here goes... IIUC we have counters that we can poll/push in a given time period, so that the data we get out makes sense and has no "holes" or "overlaps" in it. However, we also have highly volatile numbers that are extremely interesting for an operator to see: how many channels of which kind are currently still available? I asked around and one solution I heard is to poll the CTRL interface once per second and aggregate min/max values before sending on to statistics once per minute. That could be considered close enough, but we can do better. Polling momentary values has holes in it, and doesn't scale well. If, e.g., one new channel request comes in while at the same time another channel is released, we might for a short time hit a situation of no more channels being available, and the polling might just miss that and would show more available channels than we factually had. If hypothetically scaling up such a situation: we might actually have turned down 5 channel requests while the polled number still shows available lchans at all times. So, we should allow: - seeing peak usage - in a pushing-stats fashion - that is still useful when sampled only, say, once per minute. One idea would be to push out a new number as soon as channel availability changes, but that again doesn't scale well (might generate too many events when monitoring a large number of cells). So I'm thinking that we should aggregate the minimum-available lchan counts within osmo-bsc per stats timeframe. There should be separate minimum-available numbers for each lchan kind. I guess minimum-available is more useful than maximum-used lchans, but we could also provide both. Also, if I want to find out how many lchans I need to add to provide adequate service, it would be good to somehow determine the maximum number of "concurrent" turned down channel requests. We probably already have that in a per-second moving average? But here again, if I sample a per-second moving average only once per minute, I will miss the maximum value that this per-second value has reached in that minute. This probably also needs a think-over from a practical "I want useful stats" POV. Or am I missing something? Thanks, ~N -- - Neels Hofmeyr 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From keith at rhizomatica.org Wed Jan 30 19:23:59 2019 From: keith at rhizomatica.org (Keith) Date: Wed, 30 Jan 2019 20:23:59 +0100 Subject: channel statistics In-Reply-To: <20190130134356.GC3079@my.box> References: <20190130134356.GC3079@my.box> Message-ID: <4da1eaf8-a619-7de4-d302-3a30c9023796@rhizomatica.org> On 30/01/2019 14:43, Neels Hofmeyr wrote: > I asked around and one solution I heard is to poll the CTRL interface once per > second and aggregate min/max values before sending on to statistics once per > minute. That could be considered close enough, but we can do better. So I do that, except actually poll the vty, (yes, I know...) and much less often.. I actually only poll channels in use every 60 seconds. which gives a kind of idea of general usage patterns during the day, but is rather useless for detecting how often we experience saturation. > > Polling momentary values has holes in it, and doesn't scale well. If, e.g., one > new channel request comes in while at the same time another channel is > released, we might for a short time hit a situation of no more channels being > available, and the polling might just miss that and would show more available > channels than we factually had. If hypothetically scaling up such a situation: > we might actually have turned down 5 channel requests while the polled number > still shows available lchans at all times. So, we should allow: So, in order to compensate somewhat for what I just described, I poll the "no channel" counter and that gives me an idea of how many chan requests were rejected in the period. I only do this every 5 mins though. OpenBSC# show statistics Channel Requests??????? : 1 total, 0 no channel ????????????????????????????????????????????????????? ^^^^^^^^^^^ this one. > > One idea would be to push out a new number as soon as channel availability > changes, but that again doesn't scale well (might generate too many events when > monitoring a large number of cells). Yes, I think so. > > So I'm thinking that we should aggregate the minimum-available lchan counts > within osmo-bsc per stats timeframe. > > There should be separate minimum-available numbers for each lchan kind. yep. that would be great. In general I have a very basic to zero knowledge of the "science" of stats collection, KPI etc. But I imagine the industry has a standard? Maybe we can follow it? I will take a look at the KPI talk from OsmoDevCon again https://media.ccc.de/v/SE8HRK > I guess minimum-available is more useful than maximum-used lchans, but we could > also provide both. I do think there's something to be said for counters that count "error" situations, like no chan available, then you know that this happened, without trying to constantly count channels in use and then having to be concerned about that micro-second between chan release and chan request that may or may not overlap.? -? actually I do not know how big that window is, maybe more than a uSecond :) > Also, if I want to find out how many lchans I need to add to provide adequate > service, it would be good to somehow determine the maximum number of > "concurrent" turned down channel requests. Maybe "what was the duration of complete saturation" might be a good question. I'll try to come up with a list of "questions" like that. >