From jenkins at lists.osmocom.org Mon Dec 3 02:23:33 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Mon, 3 Dec 2018 02:23:33 +0000 (UTC) Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #315 Message-ID: <482032320.967.1543803813164.JavaMail.jenkins@jenkins.osmocom.org> See Changes: [Oliver Smith] cosmetic: gerrit-verifications: format docker cmd ------------------------------------------ [...truncated 670.25 KB...] from ../../include/osmocom/ranap/RANAP_CriticalityDiagnostics-IE-List.h:14, from RANAP_CriticalityDiagnostics-IE-List.c:7: ../../include/osmocom/ranap/RANAP_CriticalityDiagnostics-IE-List.h:28:23: warning: ?struct MemberG? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberG { ^ /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_CriticalityDiagnostics-IE-List.h:28:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct MemberG { ^~~~~~~~~~~~~ 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_MessageStructure.h:14, from RANAP_MessageStructure.c:7: ../../include/osmocom/ranap/RANAP_MessageStructure.h:27:23: warning: ?struct MemberL? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberL { ^ /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_MessageStructure.h:27:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct MemberL { ^~~~~~~~~~~~~ CC RANAP_ClassmarkInformation3.lo CC RANAP_CN-ID.lo CC RANAP_CN-DomainIndicator.lo CC RANAP_Correlation-ID.lo CC RANAP_CSFB-Information.lo CC RANAP_CSG-Id.lo CC RANAP_CSG-Id-List.lo CC RANAP_CSG-Membership-Status.lo CC RANAP_DataPDUType.lo CC RANAP_DataVolumeReference.lo CC RANAP_DataVolumeReportingIndication.lo CC RANAP_DCH-ID.lo CC RANAP_DeliveryOfErroneousSDU.lo CC RANAP_DeliveryOrder.lo CC RANAP_DeltaRAListofIdleModeUEs.lo CC RANAP_NewRAListofIdleModeUEs.lo CC RANAP_RAListwithNoIdleModeUEsAnyMore.lo CC RANAP_ForwardingIndication.lo CC RANAP_DL-GTP-PDU-SequenceNumber.lo CC RANAP_DL-N-PDU-SequenceNumber.lo CC RANAP_D-RNTI.lo CC RANAP_DRX-CycleLengthCoefficient.lo CC RANAP_DSCH-ID.lo CC RANAP_EARFCN-Extended.lo CC RANAP_E-DCH-MAC-d-Flow-ID.lo CC RANAP_ENB-ID.lo CC RANAP_EncryptionAlgorithm.lo CC RANAP_EncryptionInformation.lo CC RANAP_EncryptionKey.lo CC RANAP_End-Of-CSFB.lo CC RANAP_EquipmentsToBeTraced.lo CC RANAP_E-UTRAN-Service-Handover.lo CC RANAP_Event.lo CC RANAP_Event1F-Parameters.lo CC RANAP_Event1I-Parameters.lo CC RANAP_ExtendedGuaranteedBitrate.lo CC RANAP_ExtendedMaxBitrate.lo CC RANAP_ExtendedRNC-ID.lo CC RANAP_FrameSequenceNumber.lo CC RANAP_FrequenceLayerConvergenceFlag.lo CC RANAP_GANSS-PositioningDataSet.lo CC RANAP_GANSS-PositioningMethodAndUsage.lo CC RANAP_GeographicalArea.lo CC RANAP_GeographicalCoordinates.lo CC RANAP_GA-AltitudeAndDirection.lo CC RANAP_GA-EllipsoidArc.lo CC RANAP_GA-Point.lo CC RANAP_GA-PointWithAltitude.lo CC RANAP_GA-PointWithAltitudeAndUncertaintyEllipsoid.lo CC RANAP_GA-PointWithUnCertainty.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-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 CC RANAP_GlobalRNC-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_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_IuTransportAssociation.lo CC RANAP_KeyStatus.lo CC RANAP_LA-LIST.lo CC RANAP_LAC.lo CC RANAP_LAI.lo CC RANAP_LastKnownServiceArea.lo CC RANAP_LastVisitedUTRANCell-Item.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_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 ../../libtool: line 1748: 1801 Aborted gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.11-319c\" "-DPACKAGE_STRING=\"osmo-iuh 0.3.0.11-319c\"" -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.11-319c\" -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_MBMSLinkingInformation.lo -MD -MP -MF .deps/RANAP_MBMSLinkingInformation.Tpo -c RANAP_MBMSLinkingInformation.c -o RANAP_MBMSLinkingInformation.o > /dev/null 2>&1 ../../libtool: line 1748: 1802 Aborted gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.11-319c\" "-DPACKAGE_STRING=\"osmo-iuh 0.3.0.11-319c\"" -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.11-319c\" -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_MBMSSessionDuration.lo -MD -MP -MF .deps/RANAP_MBMSSessionDuration.Tpo -c RANAP_MBMSSessionDuration.c -o RANAP_MBMSSessionDuration.o > /dev/null 2>&1 ../../libtool: line 1748: 1800 Aborted gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.11-319c\" "-DPACKAGE_STRING=\"osmo-iuh 0.3.0.11-319c\"" -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.11-319c\" -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_MBMSRegistrationRequestType.lo -MD -MP -MF .deps/RANAP_MBMSRegistrationRequestType.Tpo -c RANAP_MBMSRegistrationRequestType.c -o RANAP_MBMSRegistrationRequestType.o > /dev/null 2>&1 [ERROR] capture: cannot update build log: No space left on device [ERROR] capture: cannot update build log: No space left on device [ERROR] capture: cannot update build log: ../../libtool: line 1751: 1808 Aborted $RM $removelist No space left on device ../../libtool: line 1751: 1809 Aborted $RM $removelist ../../libtool: line 1751: 1807 Aborted $RM $removelist Makefile:2506: recipe for target 'RANAP_MBMSLinkingInformation.lo' failed make[4]: *** [RANAP_MBMSLinkingInformation.lo] Error 1 make[4]: *** Waiting for unfinished jobs.... Makefile:2506: recipe for target 'RANAP_MBMSRegistrationRequestType.lo' failed make[4]: *** [RANAP_MBMSRegistrationRequestType.lo] Error 1 [ERROR] capture: cannot update build log: No space left on device Makefile:2506: recipe for target 'RANAP_MBMSSessionDuration.lo' failed make[4]: *** [RANAP_MBMSSessionDuration.lo] Error 1 gcc: internal compiler error: Aborted (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. [ERROR] capture: cannot update build log: Makefile:2506: recipe for target 'RANAP_MBMSSessionIdentity.lo' failed make[4]: *** [RANAP_MBMSSessionIdentity.lo] Error 1 No space left on device ../../libtool: line 1751: 1814 Aborted $RM $removelist Makefile:2506: recipe for target 'RANAP_MBMSIPMulticastAddressandAPNRequest.lo' failed make[4]: *** [RANAP_MBMSIPMulticastAddressandAPNRequest.lo] Error 1 RANAP_MBMSServiceArea.c:142:1: fatal error: closing dependency file .deps/RANAP_MBMSServiceArea.Tpo: No space left on device }; ^ compilation terminated. Makefile:2506: recipe for target 'RANAP_MBMSServiceArea.lo' failed make[4]: *** [RANAP_MBMSServiceArea.lo] Error 1 [ERROR] capture: cannot update build log: No space left on device ../../libtool: line 1748: 1790 Aborted gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.11-319c\" "-DPACKAGE_STRING=\"osmo-iuh 0.3.0.11-319c\"" -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.11-319c\" -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_MDT-Activation.lo -MD -MP -MF .deps/RANAP_MDT-Activation.Tpo -c RANAP_MDT-Activation.c -fPIC -DPIC -o .libs/RANAP_MDT-Activation.o Makefile:2506: recipe for target 'RANAP_MDT-Activation.lo' failed make[4]: *** [RANAP_MDT-Activation.lo] Error 1 [ERROR] capture: cannot update build log: No space left on device ../../libtool: line 1748: 1796 Aborted gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.11-319c\" "-DPACKAGE_STRING=\"osmo-iuh 0.3.0.11-319c\"" -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.11-319c\" -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_MBMSSessionRepetitionNumber.lo -MD -MP -MF .deps/RANAP_MBMSSessionRepetitionNumber.Tpo -c RANAP_MBMSSessionRepetitionNumber.c -fPIC -DPIC -o .libs/RANAP_MBMSSessionRepetitionNumber.o Makefile:2506: recipe for target 'RANAP_MBMSSessionRepetitionNumber.lo' failed make[4]: *** [RANAP_MBMSSessionRepetitionNumber.lo] Error 1 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 /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/emit/build2-deb9build-ansible/emit-db: UPDATE CovBuildInvocation SET refct = $COV_BINDING1 WHERE (CovBuildInvocation.rowid = $COV_BINDING2) ;: disk I/O error [write] Build step 'Execute shell' marked build as failure From jenkins at lists.osmocom.org Mon Dec 3 09:34:33 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Mon, 3 Dec 2018 09:34:33 +0000 (UTC) Subject: Jenkins build is back to normal : Coverity-Upload (jenkins-job-builder) #316 In-Reply-To: <482032320.967.1543803813164.JavaMail.jenkins@jenkins.osmocom.org> References: <482032320.967.1543803813164.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <869831707.982.1543829673639.JavaMail.jenkins@jenkins.osmocom.org> See From laszlo.sitzer at sumup.com Tue Dec 4 08:47:05 2018 From: laszlo.sitzer at sumup.com (Daniel Laszlo Sitzer) Date: Tue, 4 Dec 2018 09:47:05 +0100 Subject: pySim patch - decode EF_[O|H]PLMNwAcT Message-ID: Hello everyone, I implemented decoding of the [O|H]PLMNwAcT elementary file in pySim. Here https://github.com/lazlo/pysim-dec-plmn you will also find unit tests for the code I wrote. Let me know if I should further refactor the code (maybe to use more of the existing conversions functions in pySim/util.py). I'm aware it is not the most elegant code but it does its job. Best, Lazlo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-WIP-Decode-xPLMNwAcT.patch Type: text/x-patch Size: 4356 bytes Desc: not available URL: From laszlo.sitzer at sumup.com Tue Dec 4 08:55:49 2018 From: laszlo.sitzer at sumup.com (Daniel Laszlo Sitzer) Date: Tue, 4 Dec 2018 09:55:49 +0100 Subject: pySim patch - decode EF_[O|H]PLMNwAcT In-Reply-To: References: Message-ID: Sorry! The patch had one error (name of argument mismatch with use in function body). Fixed it. On Tue, Dec 4, 2018 at 9:47 AM Daniel Laszlo Sitzer wrote: > Hello everyone, > > I implemented decoding of the [O|H]PLMNwAcT elementary file in pySim. > Here https://github.com/lazlo/pysim-dec-plmn you will also find unit > tests for the code I wrote. > > Let me know if I should further refactor the code (maybe to use more of > the existing conversions functions in pySim/util.py). I'm aware it is not > the most elegant code but it does its job. > > Best, > > Lazlo > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-WIP-Decode-xPLMNwAcT.patch Type: text/x-patch Size: 4348 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Tue Dec 4 13:46:39 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 4 Dec 2018 14:46:39 +0100 Subject: pySim patch - decode EF_[O|H]PLMNwAcT In-Reply-To: References: Message-ID: <20181204134639.GA1788@my.box> Laszlo! Great to hear from you!! Also thanks for the patch. In the meantime we have moved to using gerrit for code review in osmocom, and pysim is also there now. It can be a bit cumbersome to register and login and all that, but if you don't mind it would be great if you could submit the patch on gerrit. This wiki page should guide you through the process: https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit Feel free to ping here or on freenode #osmocom if you need anything! ~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 Dec 4 15:57:27 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 4 Dec 2018 16:57:27 +0100 Subject: survey: doxygen Message-ID: <20181204155727.GB1788@my.box> Hi all, we have doxygen API doc in libosmocore. The doxygen format, even though well defined, is often a distraction from code review because we often fail to get it right and need another review cycle. I'm looking for ways how I don't need to write review on doxygen comments. Ideas: - We introduce hard doxygen validation in the gerrit jobs. Difficulties: - we'd probably first need to fix *all* current doxygen errors. - we'd need to add doxygen to all projects, because some of us add doxygen comments even there, and it is odd to use the format but fail to do it right. - there is no way to make sure the initial summary is ended in '.', because the script cannot understand human semantics. - I don't think anyone uses it. So we could just drop doxygen. (I find it much more useful to just browse the code with ctags.) If we drop doxygen, we can just use the comments whichever way we like, omit '.' whereever and I don't need to nitpick on it. And we can drop all those \param and \a and \ref bits that break the flow of reading a C comment. libosmocore is the only git tree actually building doxygen docs. OTOH, when removing doxygen, would we also drop all those \file and other section markers? - Or, I stop giving a damn about doxygen and let everyone commit all sorts of doxygen formatting errors, because no-one is reading the HTML version anyway. thoughts welcome... ~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 Tue Dec 4 16:10:13 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 4 Dec 2018 17:10:13 +0100 Subject: survey: doxygen In-Reply-To: <20181204155727.GB1788@my.box> References: <20181204155727.GB1788@my.box> Message-ID: <6690d87e-1466-440c-6d37-959022542aa5@sysmocom.de> Hi, On 12/4/18 4:57 PM, Neels Hofmeyr wrote: > Hi all, > > we have doxygen API doc in libosmocore. The doxygen format, even though well > defined, is often a distraction from code review because we often fail to get > it right and need another review cycle. > > I'm looking for ways how I don't need to write review on doxygen comments. > Ideas: > > - We introduce hard doxygen validation in the gerrit jobs. > Difficulties: > - we'd probably first need to fix *all* current doxygen errors. > - we'd need to add doxygen to all projects, because some of us add doxygen > comments even there, and it is odd to use the format but fail to do it > right. > - there is no way to make sure the initial summary is ended in '.', > because the script cannot understand human semantics. > I think it makes sense to enable doxygen validation during jenkins.sh, but on the long run, no rush (like I did with --enable-werror some time ago). > > - I don't think anyone uses it. So we could just drop doxygen. > (I find it much more useful to just browse the code with ctags.) I have used it a few times. You may not use it because you are used to the libosmo* implementation, but users of these libraries don't need to care about implementation details, and in this case it's useful having the doxygen API. I used doxygen API several times when building apps that use C library APIs (ffmpeg and alike I can think of now). So think about use case: somebody not really interested in developing libosmocore but willing to use some of its features in his own project (msgb, timers, main loop, fsm, etc.). > libosmocore is the only git tree actually building doxygen docs. IIRC libosmo-abis or/and libosmo-netif do too. In general, my opinion regarding this topic is: even if w dont' currently build doxygen, allow people to use doxygen formatting to ease enabling it later. Don't be too picky about formatting, small bits can always be improved later if needed. I'm personally happy to receive comments on some doxygen formatting I do wrong. Some related topic: I sometimes have the feeling the doxygen html documentation we generate is not really visible and most people may not even know where it is. I'd need to check where it is located right now. Not sure how to give it more visibility though. 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 jenkins at lists.osmocom.org Wed Dec 5 02:17:00 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Wed, 5 Dec 2018 02:17:00 +0000 (UTC) Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #318 Message-ID: <242670449.1024.1543976220905.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ Started by timer Building remotely on build2-deb9build-ansible (ttcn3 osmo-gsm-tester-build osmocom-gerrit-debian9 osmocom-master-debian9 coverity) in workspace Wiping out workspace first. Cloning the remote Git repository Cloning repository git://git.osmocom.org/osmo-ci > git init # timeout=10 ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not init at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:772) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:564) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to build2-deb9build-ansible at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) at hudson.remoting.Channel.call(Channel.java:955) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146) at sun.reflect.GeneratedMethodAccessor1028.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132) at com.sun.proxy.$Proxy79.execute(Unknown Source) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1146) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186) at hudson.scm.SCM.checkout(SCM.java:504) at hudson.model.AbstractProject.checkout(AbstractProject.java:1208) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1815) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Caused by: hudson.plugins.git.GitException: Command "git init returned status code 1: stdout: stderr: : No space left on device at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1996) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1964) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1960) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1597) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:770) ... 11 more ERROR: Error cloning remote repo 'origin' From laforge at gnumonks.org Wed Dec 5 07:59:29 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 5 Dec 2018 08:59:29 +0100 Subject: survey: doxygen In-Reply-To: <20181204155727.GB1788@my.box> References: <20181204155727.GB1788@my.box> Message-ID: <20181205075929.GQ6114@nataraja> Hi Neels, On Tue, Dec 04, 2018 at 04:57:27PM +0100, Neels Hofmeyr wrote: > we have doxygen API doc in libosmocore. [not only there, but also in other parts of the project] > The doxygen format, even though well defined, is often a distraction > from code review because we often fail to get it right and need > another review cycle. that's more a question of tooling, discipline and policy. Example: I don't think I have ever rejected a patch based on doxygen related errors. > I'm looking for ways how I don't need to write review on doxygen comments. > Ideas: > > - We introduce hard doxygen validation in the gerrit jobs. very good idea. > Difficulties: > - we'd probably first need to fix *all* current doxygen errors. Sounds like a really good idea. I'm not sure, but I would hope one could selectively enable/disable doxygen warning generation similar to the way one can enable/disable classes of gcc warnings? This way one could standardize on a set of critical vs. non-critical warnings/errors. > - we'd need to add doxygen to all projects, because some of us add doxygen > comments even there, and it is odd to use the format but fail to do it > right. I think whenever I write API documentation, I put it in doxygen format from the beginning. That's probably because I still remember the suffering of converting all the various non- structured comments before we introduced doxygen to some libosmo* projects, and I didn't want to go through that again if we later expand to other projects. I think it makes limited sense to document various static functions inside a project using Doxygen or any other API documentation tool. However, if there's a clear provider/consumer API split between two given parts of a program, and there are (or are expected to be) more than one caller/user, then those are indications for having API documentation even within one non-library program/project, such as osmo-{bts,bsc,msc,...}. > - there is no way to make sure the initial summary is ended in '.', > because the script cannot understand human semantics. that's the problem with "autobrief", right? I never had any isuses with the explicit \brief, but everybody wanted to have autobrief in place some time ago... > - I don't think anyone uses it. So we could just drop doxygen. > (I find it much more useful to just browse the code with ctags.) Definitely not. It was a lot of work and (I think) a great achievement to finally have some amount of API documentation when it was introduced. To the contrary, we should have more of it, and aim to achieve 100% coverage on all of our libraries. Irrespective of the given format/system like doxygen, the content of course should document the *interesting* bits. Example: Of course 'msgb' is a message buffer. But does the function make assumptions about the msgb you pass to it? Does it require any of the 'l*h' pointers to be set? does it use the msgb->cb? ... > If we drop doxygen, we can just use the comments whichever way we like, omit > '.' whereever and I don't need to nitpick on it. And we can drop all those > \param and \a and \ref bits that break the flow of reading a C comment. doesn't your brain automatically remove those by now when reading? I don't think I consciously notice them... > libosmocore is the only git tree actually building doxygen docs. That's not entirely true: http://ftp.osmocom.org/api/latest/ lists also libosmo-netif, libosmo-sccp, libosmo-dsp and even osmo-gmr (Sylvain!) > - Or, I stop giving a damn about doxygen and let everyone commit all sorts of > doxygen formatting errors, because no-one is reading the HTML version anyway. I used to look at it every so often, particularly when adding new sections / code modules to it. Not so much recently, admittedly. To me, the HTML generation is more of a (very nice) by-product. The importance is to have documentation in place. Mandating a structured format makes it easier to have it in one format, similar to having a coding style to ensure not every developer writes his code completely differently and hence putting the burden on the reader of the code. 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 nhofmeyr at sysmocom.de Wed Dec 5 11:07:25 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 5 Dec 2018 12:07:25 +0100 Subject: survey: doxygen In-Reply-To: <6690d87e-1466-440c-6d37-959022542aa5@sysmocom.de> References: <20181204155727.GB1788@my.box> <6690d87e-1466-440c-6d37-959022542aa5@sysmocom.de> Message-ID: <20181205110725.GA5760@my.box> > only for libosmocore actually I see now there are: libosmocore libosmodsp libosmonetif libosmosccp osmo-gmr libosmosdp? also interesting: on my disk it's called 'libosmo-netif' and 'libosmo-sccp' with dashes. On Tue, Dec 04, 2018 at 05:10:13PM +0100, Pau Espin Pedrol wrote: > know where it is. I'd need to check where it is located right now. Not sure > how to give it more visibility though. Doing the typical redmine search dance: type "Documentation", check [x] Search titles only, click "_Wiki_pages_" https://osmocom.org/projects/cellular-infrastructure/wiki/Guidelines_for_API_documentation Just added a link from the Osmocom Manuals wiki page. (btw, osmith, that wiki page still explains stuff how it was before the move of manuals) ~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 Dec 5 11:21:14 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 5 Dec 2018 12:21:14 +0100 Subject: survey: doxygen In-Reply-To: <20181205075929.GQ6114@nataraja> References: <20181204155727.GB1788@my.box> <20181205075929.GQ6114@nataraja> Message-ID: <20181205112114.GB5760@my.box> On Wed, Dec 05, 2018 at 08:59:29AM +0100, Harald Welte wrote: > > - there is no way to make sure the initial summary is ended in '.', > > because the script cannot understand human semantics. > > that's the problem with "autobrief", right? Even for explicit \brief, you should still end the sentence in a dot. One of the two: either the same (next line bleeds into \brief) or we had a problem if the first summary spans more than one line and was cut off by \brief? In any case, the logic was so that I came to the conclusion that without having to write '\brief', things were more or less similar. But I really don't understand why anyone would write an API comment and choose to not end a sentence in a full-stop, and why many of you particularly do that for the first sentence only. That's a very weird social phenomenon :P My particular taste problem with '\brief' was that I dislike any and all of the doxygen formatting breaking the flow of reading API and writing doc in C comment. Worst of all is '\a', it reads like the english 'a', and totally messes up reading. Shouldn't be that hard for doxygen to just automatically find all the defined names and highlight them. > doesn't your brain automatically remove those by now when reading? They reliably throw me off every time. Maybe because my personal nature tends towards "too obsessed with details". > > libosmocore is the only git tree actually building doxygen docs. > > That's not entirely true: > http://ftp.osmocom.org/api/latest/ lists also libosmo-netif, libosmo-sccp, libosmo-dsp > and even osmo-gmr (Sylvain!) yep, also just noticed, thx ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From osmith at sysmocom.de Wed Dec 5 15:08:28 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Wed, 5 Dec 2018 16:08:28 +0100 Subject: survey: doxygen In-Reply-To: <20181205110725.GA5760@my.box> References: <20181204155727.GB1788@my.box> <6690d87e-1466-440c-6d37-959022542aa5@sysmocom.de> <20181205110725.GA5760@my.box> Message-ID: <595b6088-1a06-9c10-8845-03af37b4b8b6@sysmocom.de> On 12/5/18 12:07 PM, Neels Hofmeyr wrote: > (btw, osmith, that wiki page still explains stuff how it was before the move of manuals) Updated, thanks for the pointer. -- - 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 nhofmeyr at sysmocom.de Wed Dec 5 15:22:07 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 5 Dec 2018 16:22:07 +0100 Subject: jenkins build slaves: disks full Message-ID: <20181205152207.GA8543@my.box> We recently hit a bunch of jenkins failures, due to a full disk. Just now I removed 172G worth of docker images from build2-deb9build-ansible; I thought we had the docker cleanup automated by now? Even after that, build-2 still uses 244G of its root file system, which doesn't seem right. most of it is also in the deb9build-ansible lxc: root at build-2 /var/lib/lxc/deb9build-ansible/rootfs # du -hs * | sort -h [...] 2.2G opt 5.8G usr 8.1G tmp (what! 33G home 153G var The tmp/ has many folders like 196M tmp.u3y02wgBNI which are all from March to May this year. I will delete them now. home: root at build-2 /var/lib/lxc/deb9build-ansible/rootfs/home/osmocom-build # du -hs * 0 bin 19G jenkins 14G jenkins_build_artifact_store 1.2G osmo-ci Interesting, I wasn't aware of us using the artifact store. Seems to come from some manual builds between April-October. Removing. jenkins workspaces of 19G seems ok. But osmo-ci of 1.2G!? That seems to be a manual build of the coverity job -- though the date is pretty recent, so is our coverity job actually building in ~osmocom-build/osmo-ci instead of in a workspace? Even after the docker cleanup commands I used from the osmocom.org servers wiki page: docker rm $(docker ps -a -q) docker rmi $(docker images -q -f dangling=true) There are still 321 docker images around, most of which are months old. Not sure why above cleanups don't catch those. I'm just going to indiscriminately blow all of them away now. Maybe a good cleanup strategy would be to every week or so automatically wipe out the entire build slave lxc and re-create it from scratch? After this, we have on build-2: Filesystem Size Used Avail Use% Mounted on /dev/md2 438G 83G 333G 20% / ------ host-2 Similar story on host-2 deb9build-ansible lxc: tons of docker images, just removed all of them. But after that we still have root at host2 ~ # df -h Filesystem Size Used Avail Use% Mounted on /dev/md2 438G 311G 105G 75% / On host-2 though there are a lot of services running. root at host2 / # du -hs * | sort -h [...] 1.2G usr 59G var 75G home 176G external [...] 2.7G gerrit 3.1G redmine-20170530-before-upgrade-to-3.4.tar 4.3G mailman 5.7G openmoko-wiki 7.8G gitolite 9.9G openmoko-people 29G redmine 112G jenkins root at host2 /external/jenkins/home/jobs # du -hs * | sort -h 171M nplab-m3ua-test 198M master-osmo-pcu 241M ttcn3-sip-test 251M osmo-gsm-tester_build-osmo-bsc 262M ttcn3-ggsn-test 287M gerrit-osmo-ttcn3-hacks 297M master-osmo-bsc 322M master-libosmo-sccp 328M osmo-gsm-tester_build-osmo-sgsn 355M master-osmo-mgw 359M master-libosmo-netif 365M osmo-gsm-tester_build-osmo-iuh 390M gerrit-asn1c 392M gerrit-osmo-bsc 419M ttcn3-nitb-sysinfo 445M osmo-gsm-tester_build-osmo-msc 456M osmo-gsm-tester_manual-build-all 461M master-libosmocore 461M TEST_osmocomBB_with_libosmocore_dep 482M master-osmo-iuh 611M master-osmo-sgsn 704M gerrit-osmo-bts 748M master-osmo-msc 756M gerrit-osmo-msc 929M master-openbsc 1.1G master-osmo-bts 1.1G ttcn3-hlr-test 1.2G gerrit-libosmocore 1.2G ttcn3-mgw-test 1.9G osmo-gsm-tester-rnd_run 2.0G ttcn3-sgsn-test 3.0G ttcn3-msc-test 3.2G osmo-gsm-tester_run 3.5G master-asn1c 4.2G ttcn3-bsc-test-sccplite 4.7G osmo-gsm-tester_run-rnd 6.2G osmo-gsm-tester_gerrit 6.3G osmo-gsm-tester_run-prod 7.5G osmo-gsm-tester_ttcn3 8.5G ttcn3-bsc-test 43G ttcn3-bts-test It seems we are caching 211 ttcn3-bts-test builds. That seems a tad much. Indeed https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/configure has "[ ] Discard old builds" (unchecked). Looking in osmo-ci, the jobs/ttcn3-testsuites.yml has no 'build-discarder' set. I guess we should add one? Any discard option preferences? A month? A year? (compare master-builds.yml) ----- admin-2 It seems I can not login there, or at least I don't know the IP address... ssh: Could not resolve hostname admin2.osmocom.org: Name or service not known So I guess I can't check there. ~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 Dec 5 15:31:25 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 5 Dec 2018 16:31:25 +0100 Subject: jenkins build slaves: disks full In-Reply-To: <20181205152207.GA8543@my.box> References: <20181205152207.GA8543@my.box> Message-ID: <20181205153125.GB8543@my.box> On Wed, Dec 05, 2018 at 04:22:07PM +0100, Neels Hofmeyr wrote: > ----- admin-2 > > It seems I can not login there, or at least I don't know the IP address... > ssh: Could not resolve hostname admin2.osmocom.org: Name or service not known > So I guess I can't check there. The mad jenkins web ui script console gives me Filesystem Size Used Avail Use% Mounted on /dev/md2 438G 143G 273G 35% / So it's not near critical yet, but also might have a bit of build-up? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From osmith at sysmocom.de Wed Dec 5 15:57:04 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Wed, 5 Dec 2018 16:57:04 +0100 Subject: jenkins build slaves: disks full In-Reply-To: <20181205152207.GA8543@my.box> References: <20181205152207.GA8543@my.box> Message-ID: <26394490-de67-258d-4101-401e856914ad@sysmocom.de> On 12/5/18 4:22 PM, Neels Hofmeyr wrote: > It seems we are caching 211 ttcn3-bts-test builds. That seems a tad much. > Indeed https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/configure > has "[ ] Discard old builds" (unchecked). > Looking in osmo-ci, the jobs/ttcn3-testsuites.yml has no 'build-discarder' set. > I guess we should add one? Any discard option preferences? A month? A year? > (compare master-builds.yml) The values that master-builds.yml has sound sane to me, so I created a patch that applies them to ttcn3-testsuites.yml: https://gerrit.osmocom.org/#/c/osmo-ci/+/12141/ 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 nhofmeyr at sysmocom.de Thu Dec 6 01:28:51 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 6 Dec 2018 02:28:51 +0100 Subject: libosmocore builds non-concurrent Message-ID: <20181206012850.GA27230@my.box> I'm noticing that the libosmocore gerrit builds actually wait for each single one to finish. I guess we can turn on concurrent builds there? ... osmith? :) ~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 Thu Dec 6 02:31:42 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Thu, 6 Dec 2018 02:31:42 +0000 (UTC) Subject: Jenkins build is back to normal : Coverity-Upload (jenkins-job-builder) #319 In-Reply-To: <242670449.1024.1543976220905.JavaMail.jenkins@jenkins.osmocom.org> References: <242670449.1024.1543976220905.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <561963152.1103.1544063502438.JavaMail.jenkins@jenkins.osmocom.org> See From laforge at gnumonks.org Thu Dec 6 06:29:37 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 6 Dec 2018 07:29:37 +0100 Subject: looking for more uild hosts / Re: jenkins build slaves: disks full In-Reply-To: <20181205152207.GA8543@my.box> References: <20181205152207.GA8543@my.box> Message-ID: <20181206062937.GA28806@nataraja> On Wed, Dec 05, 2018 at 04:22:07PM +0100, Neels Hofmeyr wrote: > We recently hit a bunch of jenkins failures, due to a full disk. thanks for investigating. > Just now I removed 172G worth of docker images from build2-deb9build-ansible; > I thought we had the docker cleanup automated by now? I was also under that impression. > The tmp/ has many folders like > 196M tmp.u3y02wgBNI > which are all from March to May this year. I will delete them now. I think that's the ttcn3 test runs, which (from our shell script?) generate such a tmp directory for pcap and log files? > Even after the docker cleanup commands I used from the osmocom.org servers wiki page: > docker rm $(docker ps -a -q) > docker rmi $(docker images -q -f dangling=true) > There are still 321 docker images around, most of which are months old. > Not sure why above cleanups don't catch those. because something still references them. > I'm just going to indiscriminately blow all of them away now. would have been interesting to investigate where those references come from. Maybe something is starting containers that keep persistent state ('docker run' without '--rm'), which will introduce reference counts to the underlying images? > Maybe a good cleanup strategy would be to every week or so automatically wipe > out the entire build slave lxc and re-create it from scratch? an option, but not sure what kind of fall-out that might create due to build slave inavailability during re-creation time, ...? > On host-2 though there are a lot of services running. sure, it's our main *.osmocom.org server. NEver intended as a build host, just created build slaves there as long as we still have capacity. > ----- admin-2 > > It seems I can not login there, or at least I don't know the IP address... Not even an osmocom.org machine. Again just using some spare capacity there. General note: "large" root severs are unfortunately rather expensive to rent (even at Hetzner), so I've been hesitant to spend even more than the several hundred EUR that we spend for hosting per month already. If somebody has spare capacity (mainly CPU + RAM) and would want to make that available to Osmocom, it would be much appreciated. Another strategy might be to simply buy machines and run them e.g. from the sysmocom office. The bandwidth requirements are low, so running behind a cable modem is feasible. 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 Thu Dec 6 10:28:53 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 6 Dec 2018 11:28:53 +0100 Subject: Rationale for having master builds in docker containers? Message-ID: <20181206102853.GJ28806@nataraja> Hi! I'm currently wondering why on earth we'd be running our master builds inside docker containers on the build slaves. According to https://git.osmocom.org/osmo-ci/tree/jobs/master-builds.yml we're currently building the following projects inside a container: * openbsc.git * osmo-bsc.git * osmo-mgw.git * osmo-msc.git * osmo-sgsn.git but none of the others. AFAIR, Holger originally introduced the dockerized builds for speeding up the build tests? I'm not sure how that In terms of the history that we have on the jenkins job builder files in osmo-ci.git, the dockerized builds in master-builds.yml were copied from the gerrit-verifications.yml. But the git history of course doesn't go back to why the [manual jenkins jobs] used the docker container in the first place. My line of thought would be to have [at least] all master builds run natively on the build slave. They are all generated by ansible these days, and should contain a well-defined environment. Any comments? Regards, Harald p.s.: The underlying topic is that SSH agent forwarding doesn't exceed into the docker container, and hence it is not possible to use jenkins credentials for uploading resulting build artefacts such as the manuals... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Thu Dec 6 11:02:24 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 6 Dec 2018 12:02:24 +0100 Subject: looking for more uild hosts / Re: jenkins build slaves: disks full In-Reply-To: <20181206062937.GA28806@nataraja> References: <20181205152207.GA8543@my.box> <20181206062937.GA28806@nataraja> Message-ID: <20181206110224.GB1700@my.box> On Thu, Dec 06, 2018 at 07:29:37AM +0100, Harald Welte wrote: > > On host-2 though there are a lot of services running. > > sure, it's our main *.osmocom.org server. NEver intended as a build host, just created > build slaves there as long as we still have capacity. > > ----- admin-2 > > > > It seems I can not login there, or at least I don't know the IP address... > > Not even an osmocom.org machine. Again just using some spare capacity there. Would be good then to take a look and make sure that the spare capacity isn't hogging the disk space away from the real services. I used to be able to login via admin2.osmocom.org. jenkins reaches the build slave via an Ipv6 address, haven't figured out yet what the admin2 root server login would be. ~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 Dec 6 11:37:46 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 6 Dec 2018 12:37:46 +0100 Subject: Rationale for having master builds in docker containers? In-Reply-To: <20181206102853.GJ28806@nataraja> References: <20181206102853.GJ28806@nataraja> Message-ID: <20181206113746.GD1700@my.box> On Thu, Dec 06, 2018 at 11:28:53AM +0100, Harald Welte wrote: > Hi! > > I'm currently wondering why on earth we'd be running our master builds > inside docker containers on the build slaves. > > According to https://git.osmocom.org/osmo-ci/tree/jobs/master-builds.yml > we're currently building the following projects inside a container: > * openbsc.git > * osmo-bsc.git > * osmo-mgw.git > * osmo-msc.git > * osmo-sgsn.git > > but none of the others. Those are the projects that run the python-based external tests, which involve opening up VTY and CTRL ports among others, because we start up the program and interact with it on VTY and CTRL. That means each of those projects is not able to run tests more than once per slave, or we get sporadic conflicts of not being able to start the main program. That was really annoying. Another complex way would be to round robin through a range of ports or localhost addresses or something, and tweak the .cfg for each test run so that the ports never conflict :/ Or some sort of network segmenting? > p.s.: The underlying topic is that SSH agent forwarding doesn't exceed > into the docker container, and hence it is not possible to use jenkins > credentials for uploading resulting build artefacts such as the > manuals... ah yes. I think the only really good reason to build the manuals in a jenkins build that also runs 'make check' is that we want to catch asciidoc bugs in the patches submitted for the manuals. But to publish, it could make more sense to have a separate job for the manuals, i.e. build and publish the manuals from a jenkins job that does not use docker to de-collide the ports. That also doesn't need several build axes, just the one build config that enables the most software components. Why? well, that is the other complication, because we (want to) auto-generate VTY reference data from the main program. That then would also require starting the program and firing up VTY ports and avoiding conflicts. But I'm also having an idea here, that we introduce a cmdline option that directly dumps the VTY reference to stdout instead of having to connect via VTY and without opening any ports. Another idea would be to somehow run contrib/jenkins.sh in the docker, but in the jenkins job extract the generated manuals from that docker to publish 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 domi at tomcsanyi.net Thu Dec 6 12:12:18 2018 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Thu, 6 Dec 2018 13:12:18 +0100 (CET) Subject: Rationale for having master builds in docker containers? In-Reply-To: <20181206113746.GD1700@my.box> References: <20181206102853.GJ28806@nataraja> <20181206113746.GD1700@my.box> Message-ID: <5FC8ADC3-CF3B-4DA7-A526-84569FC05E15@tomcsanyi.net> Hi Neels, 2018. dec. 6. d?tummal, 13:38 id?pontban Neels Hofmeyr ?rta: > > Those are the projects that run the python-based external tests, which involve > opening up VTY and CTRL ports among others, because we start up the program and > interact with it on VTY and CTRL. That means each of those projects is not able > to run tests more than once per slave, or we get sporadic conflicts of not > being able to start the main program. That was really annoying. > > Another complex way would be to round robin through a range of ports or > localhost addresses or something, and tweak the .cfg for each test run so that > the ports never conflict :/ > > Or some sort of network segmenting? I think Linux network namespaces would be a possible solution for this issue, if I understood correctly, but setting that up feels to me more complicated then using Docker. Just my 2cents. Cheers, Domi From holger at freyther.de Thu Dec 6 16:26:47 2018 From: holger at freyther.de (Holger Freyther) Date: Thu, 6 Dec 2018 16:26:47 +0000 Subject: Rationale for having master builds in docker containers? In-Reply-To: <5FC8ADC3-CF3B-4DA7-A526-84569FC05E15@tomcsanyi.net> References: <20181206102853.GJ28806@nataraja> <20181206113746.GD1700@my.box> <5FC8ADC3-CF3B-4DA7-A526-84569FC05E15@tomcsanyi.net> Message-ID: > On 6. Dec 2018, at 12:12, Tomcs?nyi, Domonkos wrote: > > Hi Neels, > > 2018. dec. 6. d?tummal, 13:38 id?pontban Neels Hofmeyr ?rta: > >> >> Those are the projects that run the python-based external tests, which involve >> opening up VTY and CTRL ports among others, because we start up the program and >> interact with it on VTY and CTRL. That means each of those projects is not able >> to run tests more than once per slave, or we get sporadic conflicts of not >> being able to start the main program. That was really annoying. >> >> Another complex way would be to round robin through a range of ports or >> localhost addresses or something, and tweak the .cfg for each test run so that >> the ports never conflict :/ >> >> Or some sort of network segmenting? > > I think Linux network namespaces would be a possible solution for this issue, if I understood correctly, but setting that up feels to me more complicated then using Docker. > Just my 2cents. I just skimmed through this thread but it seems to have the right answers. The primary reason was being able to run multiple instances of the VTY tests without having to make the (test)software more complex (e.g. bind to vty port 0 and then parse it) (and the db paths and af_unix paths) Secondary reasons are making the build environment volatile and managing the dependencies differently. For the primary one I looked at "ip netns exec" first but IIRC couldn't find tools to automatically clean things up. I briefly considered writing something that does clone+unshare(2) but the toolchain of docker was further and provided immediate results. holger From laforge at gnumonks.org Fri Dec 7 06:46:04 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 7 Dec 2018 07:46:04 +0100 Subject: Rationale for having master builds in docker containers? In-Reply-To: References: <20181206102853.GJ28806@nataraja> <20181206113746.GD1700@my.box> <5FC8ADC3-CF3B-4DA7-A526-84569FC05E15@tomcsanyi.net> Message-ID: <20181207064604.GY28806@nataraja> Hi Holger and List, On Thu, Dec 06, 2018 at 04:26:47PM +0000, Holger Freyther wrote: > I just skimmed through this thread but it seems to have the right answers. > > The primary reason was being able to run multiple instances of the VTY tests > without having to make the (test)software more complex (e.g. bind to vty > port 0 and then parse it) (and the db paths and af_unix paths) ok. That's very valid for gerrit builds, where it's important to be able to build test multiple patches in parallel. For master builds, I would argue that this is not a real concern, as it's fine to have only one master build per repository (e.g. osmo-bsc.git) at any given time [on any given build slave]. > Secondary reasons are making the build environment volatile That's of course still a valid reason, for any build, including master builds - so we'll have to keep the dockerized builds. However, I would argue that we should 1) build all projects, or at least all projects that have dependencies on other [osmocom] projecst inside docker, not some on the build slave and some in a container 2) have a process by which the container images are re-built. Right now those appear to be still jessie-based, for example. It's good to test both jessie and stretch, of course, but doing some project builds on either of the two doesn't really ensure compatibility for both versions. We should either build everything on both stretch and jessie, or one defined version. 3) ensure that gerrit and master builds run in identical environments. This reduces the risk of patches passing gerrit but failing in master. > and managing the dependencies differently. Can you please elaborate on that? Regarding the "deployment" of artifacts like pdf manuals or binary firmware builds, I would say it's best to move that into a separate post-build action inside jenkins, one that happens outside e.g. the docker image. This would mean we mount some "output" directory from the build slave into the container where the artifacts are stored to persist beyond the "--rm" docker container. >From there, we should be able to scp/rsync/... the artefact to the [ftp] server, using e.g. SSH agent forrwarding with credetials provided by the server. -- - 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 Dec 7 07:00:03 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 7 Dec 2018 08:00:03 +0100 Subject: TTCN-3 failures of osmo-bsc-tests[-sccplite] Message-ID: <20181207070003.GZ28806@nataraja> Hi all, after osmo-bsc doesn't crash running the TTCN3 tests anymore, we have integration result tests again. Thanks to Daniel for looking into this. Please let's all work together to ensure a situation like this doesn't persist for week[s] ever again in the future. Looking at the results, I see the following deterioration of test results: 1) TC_chan_exhaustion consistently fails since build 421. This is a clear regression. If I would have to take a guess, I would suspect some dynamic PDCH related changes could have had an impact on this. I've created https://osmocom.org/issues/3721 to track this one. If anyone feels like he has some knowledge on what caused the regression on Nov 22nd/23rd, please take this issue. 2) TC_paging_resp_unsol was newly introduced and failed from day one. It was introduced by Pau related to OS#3680 (making T3113 dynamic). Hoewver, even though we have merged the patch to make it dynamic, the test still fails. @pau: Please investigate. Maybe we simply need to update the config file? 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 osmith at sysmocom.de Fri Dec 7 10:58:22 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Fri, 7 Dec 2018 11:58:22 +0100 Subject: Rationale for having master builds in docker containers? In-Reply-To: <20181207064604.GY28806@nataraja> References: <20181206102853.GJ28806@nataraja> <20181206113746.GD1700@my.box> <5FC8ADC3-CF3B-4DA7-A526-84569FC05E15@tomcsanyi.net> <20181207064604.GY28806@nataraja> Message-ID: Hi, > 1) build all projects, or at least all projects that have dependencies on other > [osmocom] projecst inside docker, not some on the build slave and some in a container +1 > > 2) have a process by which the container images are re-built. Right now those appear > to be still jessie-based, for example. It's good to test both jessie and stretch, > of course, but doing some project builds on either of the two doesn't really ensure > compatibility for both versions. We should either build everything on both stretch > and jessie, or one defined version. I thought there is a defined process already. All Jenkins jobs generated by gerrit-verifications.yml and master-builds.yml use the "osmocom:amd64" image, which is defined here: osmo-ci.git/docker/Dockerfile_osmocom_jenkins.amd64 It gets rebuilt automatically for all buildbots, whenever changes to osmo-ci.git are made: https://jenkins.osmocom.org/jenkins/job/update-osmo-ci-on-slaves/ With a few more details, I had documented the process as I understood it here: https://osmocom.org/projects/osmocom-servers/wiki/Jenkins_build_verification_jobs > 3) ensure that gerrit and master builds run in identical environments. This reduces > the risk of patches passing gerrit but failing in master. Assuming we use Docker for all builds, then this should be solved (as we are using the same image already). > Regarding the "deployment" of artifacts like pdf manuals or binary firmware > builds, I would say it's best to move that into a separate post-build action > inside jenkins, one that happens outside e.g. the docker image. This would > mean we mount some "output" directory from the build slave into the container > where the artifacts are stored to persist beyond the "--rm" docker container. > > From there, we should be able to scp/rsync/... the artefact to the [ftp] server, > using e.g. SSH agent forrwarding with credetials provided by the server. Sounds good. (Implementation details: the entire build folder is actually mounted inside Docker, so it is writing all build results to the host system. But we clean it up with "osmo-clean-workspace.sh" from osmo-ci.git/scripts before and after each build, hence the built pdfs do not remain. But I'm sure we can find a way to keep the artifacts, no need to discuss that here in detail.) 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 pespin at sysmocom.de Fri Dec 7 11:22:02 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Fri, 7 Dec 2018 12:22:02 +0100 Subject: TTCN-3 failures of osmo-bsc-tests[-sccplite] In-Reply-To: <20181207070003.GZ28806@nataraja> References: <20181207070003.GZ28806@nataraja> Message-ID: <8c0c1d22-6ade-1feb-2d9a-9736b68346fb@sysmocom.de> Hi, TC_paging_resp_unsol works for me after applying following patch I just submitted to gerrit: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/12196/ It seems to be an issue with concurrent patches being merged changing stuff in related places in TTCN3 code. 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 osmith at sysmocom.de Fri Dec 7 12:10:08 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Fri, 7 Dec 2018 13:10:08 +0100 Subject: libosmocore builds non-concurrent In-Reply-To: <20181206012850.GA27230@my.box> References: <20181206012850.GA27230@my.box> Message-ID: <354d0356-df3f-0a64-9222-b04cd4959240@sysmocom.de> Hi Neels, On 12/6/18 2:28 AM, Neels Hofmeyr wrote: > I'm noticing that the libosmocore gerrit builds actually wait for each single one to finish. > I guess we can turn on concurrent builds there? ... osmith? :) > > ~N libosmocore is built with external tests, which should not run in parallel: "don't run vty and ctrl tests concurrently so that the ports don't conflict". https://git.osmocom.org/libosmocore/tree/contrib/jenkins_amd64.sh#n19 https://git.osmocom.org/libosmocore/tree/tests/Makefile.am#n310 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 pespin at sysmocom.de Fri Dec 7 12:35:48 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Fri, 7 Dec 2018 13:35:48 +0100 Subject: TTCN-3 failures of osmo-bsc-tests[-sccplite] In-Reply-To: <20181207070003.GZ28806@nataraja> References: <20181207070003.GZ28806@nataraja> Message-ID: <62667375-5d9b-e7d1-7be3-8bebd2a94701@sysmocom.de> 3) I expect BTS_Tests.TC_dyn_ipa_pdch_tchf_act_pdch_act_nack to be fixed by following commit: https://gerrit.osmocom.org/#/c/osmo-bts/+/12180/ -- - 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 osmith at sysmocom.de Fri Dec 7 13:16:34 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Fri, 7 Dec 2018 14:16:34 +0100 Subject: building and publishing manuals for osmo-gsm-tester.git Message-ID: <7b7a0688-1621-c13c-d21f-f76ec7de2733@sysmocom.de> Hi everyone, the manuals have been moved to the project specific repositories. I'm wondering what's the best way implement gerrit build verification and publishing the manuals for osmo-gsm-tester.git. With typical Osmocom projects, we have gerrit-verifications.yml and master-builds.yml, which build the projects when patches land in gerrit and when commits are merged to master. The latter is also able to publish the generated PDFs. No osmo-gsm-tester related jobs are created in both configs so far. Instead, there is a section in osmo-gsm-tester_runner.yml, which generates the osmo-gsm-tester_gerrit job. This osmo-gsm-tester_gerrit job works differently than the gerrit-verifications and master-builds jobs; they do not seem to have the osmo-ci scripts available (which are used to build and install dependencies and to clean up the workspace). The way I've implemented building and publishing manuals in the other projects makes use of both scripts (the dependency that gets installed is osmo-gsm-manuals, which has the shared manuals content). So far, the osmo-gsm-tester_gerrit job runs a few smoke test to make sure that the osmo-gsm-tester is not completely broken. It does not do a full run, as this would take 15 hours. I see the following solutions now: a) remove osmo-gsm-tester_gerrit and add an entry in gerrit-verifications and master-builds instead. Then implement manuals building and publishing just like in the other projects. b) extend osmo-gsm-tester_gerrit to build manuals, without the osmo-ci scripts (so it's maybe 10 more lines of shell code), and create an entry in master-builds for publishing the manuals (together with a new jenkins script, e.g. contrib/jenkins-publish-manuals.sh) c) do not do build the manuals in osmo-gsm-tester_gerrit, but keep that job and add an *additional* job in gerrit-verifications just for building the manuals (also add the same job in master-builds to build and publish the manuals). Regarding c), I am not sure how this would look like in gerrit. Two jobs would get triggered for each new patch, but jenkins should only give the verification +1 if both jobs ran through - can it do that? 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 osmith at sysmocom.de Fri Dec 7 15:36:27 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Fri, 7 Dec 2018 16:36:27 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181127230431.GC21949@my.box> References: <20181113154350.GA11128@fintan.stsp.name> <20181127230431.GC21949@my.box> Message-ID: <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> On 11/28/18 12:04 AM, Neels Hofmeyr wrote: > Looking at the dudle, I now see that clearly this is your favorite: > > "merge at three votes, by enforcing from gerrit: we install a plugin to add up > voting, +3 allows to merge, at first no-one has +3 permissions" > > So, we need a volunteer to try out that prolog snippet Max pointed out: > https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html#_example_13_1_1_2_code_review I took a shot at this. Reading up on the docs, I was surprised that the prolog code does not go into the gerrit installation. But instead into the git repository along with the code. From the top of that docs site: $ git fetch origin refs/meta/config:config $ git checkout config ... edit or create the rules.pl file $ git add rules.pl $ git commit -m "My submit rules" $ git push origin HEAD:refs/meta/config Obviously not everybody is allowed to do this. I get (after making sure that the remote url points to gerrit, not git.osmocom.org): fatal: Couldn't find remote ref refs/meta/config So my suggestion is, that somebody who has the permissions, tries to push the rules.pl file to one not-so-important Osomocom repository for test purposes. And then we simply try it out. Regarding the contents of the rules.pl file, it seems we only need to change "2" to "3" in the following line of the given example. Counting to three is supposed to be easy after all. add_category_min_score(NoCR,'Code-Review', 2, Labels), The docs also say (on top) that these rules may be disabled with "rules.enable=false" in the gerrit config. It does not sound like that is the default, but in case it is, we would need to provide a '$site_path'/etc/gerrit.config file that overrides this. My understanding is, that gerrit.osmocom.org runs the docker container from docker-playground.git/gerrit. I've patched it to build again, and I can add the config file there if necessary. https://gerrit.osmocom.org/#/q/topic:docker-gerrit-fixes 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 osmith at sysmocom.de Fri Dec 7 15:59:36 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Fri, 7 Dec 2018 16:59:36 +0100 Subject: Rationale for having master builds in docker containers? In-Reply-To: References: <20181206102853.GJ28806@nataraja> <20181206113746.GD1700@my.box> <5FC8ADC3-CF3B-4DA7-A526-84569FC05E15@tomcsanyi.net> <20181207064604.GY28806@nataraja> Message-ID: On 12/7/18 11:58 AM, Oliver Smith wrote: >> 1) build all projects, or at least all projects that have dependencies on other >> [osmocom] projecst inside docker, not some on the build slave and some in a container > > +1 One edge case: libosmocore gets compiled on FreeBSD_amd64. How would we handle that if we want to build everything with Docker? -- - 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 stsp at stsp.name Fri Dec 7 16:18:22 2018 From: stsp at stsp.name (Stefan Sperling) Date: Fri, 7 Dec 2018 17:18:22 +0100 Subject: Rationale for having master builds in docker containers? In-Reply-To: References: <20181206102853.GJ28806@nataraja> <20181206113746.GD1700@my.box> <5FC8ADC3-CF3B-4DA7-A526-84569FC05E15@tomcsanyi.net> <20181207064604.GY28806@nataraja> Message-ID: <20181207161822.GR44110@ted.stsp.name> On Fri, Dec 07, 2018 at 04:59:36PM +0100, Oliver Smith wrote: > One edge case: libosmocore gets compiled on FreeBSD_amd64. How would we > handle that if we want to build everything with Docker? I wouldn't have much hope for any Osmocom code to keep working on non-Linux platforms in the long term. It is simply not a priority for the project. There's no attention being paid to portability concerns at the level required for portability to non-Linux platforms. As an OpenBSD user/dev, I believe this problem is much too pervasive in the free software community as a whole. But in Osmocom's case I really don't mind the lack of BSD support. The effort required for portability is non-trivial and I don't see any advantages in using FreeBSD instead of Linux as a base for Osmocom deployments. OpenBSD is out anyway since it doesn't have an SCTP stack. AFAIK none of the BTS hardware supported by Osmocom is supported by any BSD. And most of the active Osmocom developers don't have direct experience with BSD anyway. Their time is better spent making sure that Osmocom runs very very well on Linux. From pespin at sysmocom.de Fri Dec 7 17:37:03 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Fri, 7 Dec 2018 18:37:03 +0100 Subject: building and publishing manuals for osmo-gsm-tester.git In-Reply-To: <7b7a0688-1621-c13c-d21f-f76ec7de2733@sysmocom.de> References: <7b7a0688-1621-c13c-d21f-f76ec7de2733@sysmocom.de> Message-ID: <55c0a6ea-05c7-00c6-2c2d-7c1cf7fdc98a@sysmocom.de> Hi, osmo-gsm-tester jobs are set up different because the nodes expected to run them are quite specialized: they need a different set of dependencies and HW attached to it than a regular "osmocom builder". In osmo-gsm-tester, we build sysroots of different osmocom projects which will later be packaged into a "trial" used by osmo-gsm-tester main unit to run the tests. This part of building the osmocom project sysroots (osmo-gsm-tester-builder.yml) can be done by a normal osmocom jenkins build node, and it is actually done by them. The osmo-gsm-tester_runner.yml require to be run in a "osmo-gsm-tester main unit" node, with different dependencies and HW attached as explained above. What I would do: * Add a new "master-osmo-gsm-tester" job together either together with other "master-" jobs or inside osmo-gsm-tester-builder.yml, because those nodes should more or less have the same dependencies. This "master-osmo-gsm-tester" needs to only build + publish the pdf to the FTP server. A new script can be created for that in osmo-gsm-tester.git/contrib/. Feel free to depend on osmo-ci or copy whatever is needed as you see makes sense. * Extend osmo-gsm-tester_gerrit job (which calls osmo-ci.git/contrib/jobs/osmo-gsm-tester_run-gerrit.sh) to also build the manuals in osmo-gsm-tester.git but no publish them. Since this job is run in an "osmo-gsm-tester main unit" node, that means you mayu need to update the ansible files in osmo-ci.git to install required dependencies onto those nodes. See osmo-ci.git/ansible/roles/gsm-tester/. As a reminder, this is the job actually running the full set of tests in osmo-gsm-tester main unit (Prod setup): https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run-prod/ -- - 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 jenkins at lists.osmocom.org Sat Dec 8 02:29:53 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Sat, 8 Dec 2018 02:29:53 +0000 (UTC) Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #321 Message-ID: <196359925.1156.1544236193544.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 1.18 MB...] checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking dependency style of gcc... gcc3 checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking whether gcc understands -c and -o together... (cached) yes checking dependency style of gcc... (cached) gcc3 checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking whether g++ supports C++11 features by default... yes checking whether ln -s works... yes checking whether make sets $(MAKE)... (cached) yes checking for rm... /bin/rm checking for pkg-config... /usr/bin/pkg-config checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.20... yes checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking the maximum length of command line arguments... 1572864 checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... dlltool checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for a working dd... /bin/dd checking how to truncate binary pipes... /bin/dd bs=4096 count=1 checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking how to run the C++ preprocessor... g++ -E checking for ld used by g++... /usr/bin/ld -m elf_x86_64 checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC -DPIC checking if g++ PIC flag -fPIC -DPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking if g++ supports -c -o file.o... (cached) yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... (cached) GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for ANSI C header files... (cached) yes checking byteswap.h usability... yes checking byteswap.h presence... yes checking for byteswap.h... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for size_t... yes checking whether time.h and sys/time.h may both be included... yes checking whether byte ordering is bigendian... no checking for LIBOSMOCORE... yes checking for LIBOSMOVTY... yes checking for LIBOSMOCTRL... yes checking for UHD... no checking for UHD... yes checking whether C++ compiler accepts -msse3... yes checking whether C++ compiler accepts -msse4.1... yes checking whether gcc has __builtin_cpu_supports built-in... yes checking for LIBUSB... yes checking for FFTWF... yes checking boost/config.hpp usability... yes checking boost/config.hpp presence... yes checking for boost/config.hpp... yes CPPFLAGS="" CFLAGS="-g -O2" CXXFLAGS="-g -O2" LDFLAGS="" checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating CommonLibs/Makefile config.status: creating GSM/Makefile config.status: creating Transceiver52M/Makefile config.status: creating Transceiver52M/arch/Makefile config.status: creating Transceiver52M/arch/common/Makefile config.status: creating Transceiver52M/arch/arm/Makefile config.status: creating Transceiver52M/arch/x86/Makefile config.status: creating Transceiver52M/device/Makefile config.status: creating Transceiver52M/device/uhd/Makefile config.status: creating Transceiver52M/device/usrp1/Makefile config.status: creating Transceiver52M/device/lms/Makefile config.status: creating tests/Makefile config.status: creating tests/CommonLibs/Makefile config.status: creating tests/Transceiver52M/Makefile config.status: creating doc/Makefile config.status: creating doc/examples/Makefile config.status: creating contrib/Makefile config.status: creating contrib/systemd/Makefile config.status: creating doc/manuals/Makefile config.status: creating config.h config.status: executing tests/atconfig commands config.status: executing depfiles commands config.status: executing libtool commands + make -j 8 make all-recursive make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx' Making all in doc make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc' Making all in examples make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples' Making all in manuals make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/manuals' make[3]: Nothing to be done for 'all'. make[3]: Leaving 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' make[3]: Nothing to be done for 'all-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' Making all in CommonLibs make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs' CXX BitVector.lo CXX LinkedLists.lo CXX Sockets.lo CXX Threads.lo CXX Timeval.lo CC trx_vty.lo CXX Logger.lo CC debug.lo CXXLD libcommon.la ar: `u' modifier ignored since `D' is the default (see `U') make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs' Making all in GSM make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM' CXX GSMCommon.lo CXXLD libGSM.la ar: `u' modifier ignored since `D' is the default (see `U') make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM' Making all in Transceiver52M make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' Making all in arch make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' Making all in common make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/common' CC convolve_base.lo CC convert_base.lo CC fft.lo CCLD libarch_common.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/common' Making all in x86 make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/x86' CC convolve.lo CC convert.lo CC libarch_sse_3_la-convolve_sse_3.lo CC libarch_sse_3_la-convert_sse_3.lo 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 radioInterface.lo CXX radioVector.lo CXX radioClock.lo CXX radioBuffer.lo CXX sigProcLib.lo CXX signalVector.lo CXX Transceiver.lo CXX ChannelizerBase.lo /bin/bash: line 2: 11309 Illegal instruction /bin/bash ../libtool --silent --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -Wall -I../CommonLibs -I../GSM -I./arch/common -I./device -lpthread -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -g -O2 -MT signalVector.lo -MD -MP -MF $depbase.Tpo -c -o signalVector.lo signalVector.cpp Makefile:729: recipe for target 'signalVector.lo' failed make[3]: *** [signalVector.lo] Error 132 make[3]: *** Waiting for unfinished jobs.... make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' Makefile:833: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' Makefile:516: 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-trx' Makefile:447: 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 2313 C/C++ compilation units (100%) successfully 2313 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 laforge at gnumonks.org Sat Dec 8 07:57:40 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 8 Dec 2018 08:57:40 +0100 Subject: FreeBSD portability / Re: Rationale for having master builds in docker containers? In-Reply-To: <20181207161822.GR44110@ted.stsp.name> References: <20181206102853.GJ28806@nataraja> <20181206113746.GD1700@my.box> <5FC8ADC3-CF3B-4DA7-A526-84569FC05E15@tomcsanyi.net> <20181207064604.GY28806@nataraja> <20181207161822.GR44110@ted.stsp.name> Message-ID: <20181208075740.GC1173@nataraja> Hi Stephan, On Fri, Dec 07, 2018 at 05:18:22PM +0100, Stefan Sperling wrote: > I wouldn't have much hope for any Osmocom code to keep working on non-Linux > platforms in the long term. It is simply not a priority for the project. > There's no attention being paid to portability concerns at the level > required for portability to non-Linux platforms. Indeed, this is true. We once had build testing for more projects on FreeBSD, but the amount of time fixing those issues was considerable, while at the time we did a quick poll and not a single FreeBSD user identified themselves at this mailing list. So the decision was clear, and we concluded, as you write: > Their time is better spent making sure that Osmocom runs very > very well on Linux. However, let me re-state that we are happy to merge any compatibility/portability related patches, should there be any developers/users on other platforms that contribute such changes. I just want to make clear that we're not ignorant of or somehow opposing other platforms. It's just that we focus our existing resources where we feel they are spent most effectively. 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 nhofmeyr at sysmocom.de Sat Dec 8 14:31:23 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 8 Dec 2018 15:31:23 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> References: <20181113154350.GA11128@fintan.stsp.name> <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> Message-ID: <20181208143123.GA6923@my.box> On Fri, Dec 07, 2018 at 04:36:27PM +0100, Oliver Smith wrote: > So my suggestion is, that somebody who has the permissions, tries to > push the rules.pl file to one not-so-important Osomocom repository for > test purposes. And then we simply try it out. the sandbox repos on gerrit ssh://you at gerrit.osmocom.org:29418/sandbox I gave you all sorts of permissions on the sandbox repos, but then figured, if I forgot something, I might as well give you admin access on the gerrit ui as well. > My understanding is, that gerrit.osmocom.org runs the docker container > from docker-playground.git/gerrit. I've patched it to build again, and I > can add the config file there if necessary. hmm, no idea. ~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 Sat Dec 8 14:35:40 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 8 Dec 2018 15:35:40 +0100 Subject: libosmocore builds non-concurrent In-Reply-To: <354d0356-df3f-0a64-9222-b04cd4959240@sysmocom.de> References: <20181206012850.GA27230@my.box> <354d0356-df3f-0a64-9222-b04cd4959240@sysmocom.de> Message-ID: <20181208143540.GB6923@my.box> On Fri, Dec 07, 2018 at 01:10:08PM +0100, Oliver Smith wrote: > libosmocore is built with external tests, which should not run in > parallel: "don't run vty and ctrl tests concurrently so that the ports > don't conflict". Oh, does libosmocore contain vty tests? Ah yes, I even added some not so long ago. To avoid vty port conflicts, we build the projects that do vty tests inside yet another docker. Then the jobs can run concurrently. See osmo-msc and osmo-bsc jenkins jobs... ~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 Sat Dec 8 14:47:57 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 8 Dec 2018 15:47:57 +0100 Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #321 In-Reply-To: <196359925.1156.1544236193544.JavaMail.jenkins@jenkins.osmocom.org> References: <196359925.1156.1544236193544.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <20181208144757.GC6923@my.box> On Sat, Dec 08, 2018 at 02:29:53AM +0000, jenkins at lists.osmocom.org wrote: > make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' > CXX radioInterface.lo > CXX radioVector.lo > CXX radioClock.lo > CXX radioBuffer.lo > CXX sigProcLib.lo > CXX signalVector.lo > CXX Transceiver.lo > CXX ChannelizerBase.lo > /bin/bash: line 2: 11309 Illegal instruction /bin/bash ../libtool --silent --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -Wall -I../CommonLibs -I../GSM -I./arch/common -I./device -lpthread -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -g -O2 -MT signalVector.lo -MD -MP -MF $depbase.Tpo -c -o signalVector.lo signalVector.cpp Illegal instruction again :P Where was that last time, libosmocore? Leaving to osmo-trx experts to fix... ~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 Sat Dec 8 23:01:48 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Sun, 9 Dec 2018 00:01:48 +0100 Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #321 In-Reply-To: <20181208144757.GC6923@my.box> References: <196359925.1156.1544236193544.JavaMail.jenkins@jenkins.osmocom.org> <20181208144757.GC6923@my.box> Message-ID: <6aa4031d-ffed-af34-9215-ec23aba1cd0f@sysmocom.de> Hi, That looks like an illegal instruction in bash or libtool, not in osmo-trx, so probably some issue related to OBS. -- - 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 jenkins at lists.osmocom.org Sun Dec 9 02:30:59 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Sun, 9 Dec 2018 02:30:59 +0000 (UTC) Subject: Jenkins build is back to normal : Coverity-Upload (jenkins-job-builder) #322 In-Reply-To: <196359925.1156.1544236193544.JavaMail.jenkins@jenkins.osmocom.org> References: <196359925.1156.1544236193544.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <1771887583.1172.1544322659282.JavaMail.jenkins@jenkins.osmocom.org> See From osmith at sysmocom.de Mon Dec 10 12:30:14 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Mon, 10 Dec 2018 13:30:14 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181208143123.GA6923@my.box> References: <20181113154350.GA11128@fintan.stsp.name> <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> <20181208143123.GA6923@my.box> Message-ID: <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> On 12/8/18 3:31 PM, Neels Hofmeyr wrote: > On Fri, Dec 07, 2018 at 04:36:27PM +0100, Oliver Smith wrote: >> So my suggestion is, that somebody who has the permissions, tries to >> push the rules.pl file to one not-so-important Osomocom repository for >> test purposes. And then we simply try it out. > the sandbox repos on gerrit > ssh://you at gerrit.osmocom.org:29418/sandbox > > I gave you all sorts of permissions on the sandbox repos, but then figured, if > I forgot something, I might as well give you admin access on the gerrit ui as > well. > Thank you! It worked as expected. Here's a patch, that has been merged with 3x +1 votes. It would also have been possible to submit with 1x +1 and 1x +2 (as tnt clicked first), but not without reaching 3 in total. https://gerrit.osmocom.org/#/c/sandbox/+/12216/ For the record, here are the steps again (now needs to be applied to every Osmocom project repo): $ git fetch origin refs/meta/config:config $ git checkout config ... add rules.pl from the example, replace 2 with 3 $ git add rules.pl $ git commit -m "My submit rules" $ git push origin HEAD:refs/meta/config It seems that I have permissions now to do this to all projects. Should I go ahead? 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 msuraev at sysmocom.de Mon Dec 10 12:39:22 2018 From: msuraev at sysmocom.de (Max) Date: Mon, 10 Dec 2018 13:39:22 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> References: <20181113154350.GA11128@fintan.stsp.name> <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> <20181208143123.GA6923@my.box> <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> Message-ID: Hi. I think there's one more thing we should test first - see below. 10.12.18 13:30, Oliver Smith ?????: > > It seems that I have permissions now to do this to all projects. Should > I go ahead? What about -1 vote counting? Say User1 put -1 on the patch, User2 put +1 and User3 put +2. Can the patch be merged in this case? Essentially, does substraction works as well as deletion? -- - 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 osmith at sysmocom.de Mon Dec 10 13:25:32 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Mon, 10 Dec 2018 14:25:32 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: References: <20181113154350.GA11128@fintan.stsp.name> <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> <20181208143123.GA6923@my.box> <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> Message-ID: <57d4bf33-eb33-682b-47a6-ddde56c72d30@sysmocom.de> Hi Max and ML, On 12/10/18 1:39 PM, Max wrote: > What about -1 vote counting? > > Say User1 put -1 on the patch, User2 put +1 and User3 put +2. Can the > patch be merged in this case? We played with this idea here: https://gerrit.osmocom.org/#/c/sandbox/+/12218/ Results: * -1, +1, +2 -> can not be merged * -1, +1, +2, +1 -> can be merged So yes, negative votes do get substracted from the total of 3 that is required for a merge. However, Neels discovered something else we should think about collectively: the overview in the UI is confusing with the new +3 configuration applied (which we currently have in the sandbox repo only). https://gerrit.osmocom.org/#/q/%22What+about+-1+vote+counting%22 As time of writing, this shows only the patch mention above. It can *not* be merged, as it has -1+1+2=2. However, the search results show a green checkmark in the code review (CR) column. Probably, because there is a +2 in the reviews. So this is misleading, as one might think that the patch is ready, although it isn't. The "New UI" is only slightly better. It is also showing the checkmark, but it is colored red instead of green. So... is this what we want, or should we rather give everyone +2 and set up a social convention (see earlier discussions in this thread)? 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 msuraev at sysmocom.de Mon Dec 10 13:41:49 2018 From: msuraev at sysmocom.de (Max) Date: Mon, 10 Dec 2018 14:41:49 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <57d4bf33-eb33-682b-47a6-ddde56c72d30@sysmocom.de> References: <20181113154350.GA11128@fintan.stsp.name> <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> <20181208143123.GA6923@my.box> <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> <57d4bf33-eb33-682b-47a6-ddde56c72d30@sysmocom.de> Message-ID: Thanks for taking care of this. 10.12.18 14:25, Oliver Smith ?????: > > The "New UI" is only slightly better. It is also showing the checkmark, > but it is colored red instead of green. What is "New UI"? > So... is this what we want, or should we rather give everyone +2 and set > up a social convention (see earlier discussions in this thread)? I'm pretty sure that it's possible to fix the display to match the expectations, however it's only cosmetic issue (as long as "submit" button does not appear) so I don't think it should be a showstopper. -- - 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 osmith at sysmocom.de Mon Dec 10 13:51:08 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Mon, 10 Dec 2018 14:51:08 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: References: <20181113154350.GA11128@fintan.stsp.name> <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> <20181208143123.GA6923@my.box> <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> <57d4bf33-eb33-682b-47a6-ddde56c72d30@sysmocom.de> Message-ID: <7b81aa15-2e93-ebe7-8b21-9ec6a40a7cb3@sysmocom.de> On 12/10/18 2:41 PM, Max wrote: > What is "New UI"? There's a link at the bottom of the site, "Switch to New UI": https://gerrit.osmocom.org/?polygerrit=1 -- - 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 msuraev at sysmocom.de Mon Dec 10 14:11:17 2018 From: msuraev at sysmocom.de (Max) Date: Mon, 10 Dec 2018 15:11:17 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <7b81aa15-2e93-ebe7-8b21-9ec6a40a7cb3@sysmocom.de> References: <20181113154350.GA11128@fintan.stsp.name> <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> <20181208143123.GA6923@my.box> <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> <57d4bf33-eb33-682b-47a6-ddde56c72d30@sysmocom.de> <7b81aa15-2e93-ebe7-8b21-9ec6a40a7cb3@sysmocom.de> Message-ID: <702c46e9-a172-2d53-ed91-13a720c65d0c@sysmocom.de> Looks neat, thanks. I've also noticed that we're not using the latest gerrit release where this UI is default. Could it be that displaying checkbox symbol is fixed in there? 10.12.18 14:51, Oliver Smith ?????: > On 12/10/18 2:41 PM, Max wrote: >> What is "New UI"? > There's a link at the bottom of the site, "Switch to New UI": > https://gerrit.osmocom.org/?polygerrit=1 > > -- - 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 osmith at sysmocom.de Mon Dec 10 14:48:27 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Mon, 10 Dec 2018 15:48:27 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <702c46e9-a172-2d53-ed91-13a720c65d0c@sysmocom.de> References: <20181113154350.GA11128@fintan.stsp.name> <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> <20181208143123.GA6923@my.box> <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> <57d4bf33-eb33-682b-47a6-ddde56c72d30@sysmocom.de> <7b81aa15-2e93-ebe7-8b21-9ec6a40a7cb3@sysmocom.de> <702c46e9-a172-2d53-ed91-13a720c65d0c@sysmocom.de> Message-ID: <59a0264e-31bc-7e5d-583a-ded05d76ac1d@sysmocom.de> On 12/10/18 3:11 PM, Max wrote: > I've also noticed that we're not using the latest gerrit release where > this UI is default. Good catch, it seems they are planning to deprecate the old UI soon. > Could it be that displaying checkbox symbol is fixed > in there? Maybe, but I don't spot anything related in their release notes: https://www.gerritcodereview.com/2.16.html I am not even sure if they would consider it a bug. The color changes between green and red in the new UI after all, seems like it is intentional. Personally, I would like to have the +3 thing implemented in every repository, like it is done now in the sandbox repo, even if the old UI displays it a bit weird. Any more opinions on this? 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 pespin at sysmocom.de Mon Dec 10 14:58:26 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 10 Dec 2018 15:58:26 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <59a0264e-31bc-7e5d-583a-ded05d76ac1d@sysmocom.de> References: <20181113154350.GA11128@fintan.stsp.name> <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> <20181208143123.GA6923@my.box> <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> <57d4bf33-eb33-682b-47a6-ddde56c72d30@sysmocom.de> <7b81aa15-2e93-ebe7-8b21-9ec6a40a7cb3@sysmocom.de> <702c46e9-a172-2d53-ed91-13a720c65d0c@sysmocom.de> <59a0264e-31bc-7e5d-583a-ded05d76ac1d@sysmocom.de> Message-ID: <418028ae-4877-bc2c-ada7-72ad4ecf6e04@sysmocom.de> Let's move forward, +1 (we have +3 already, can we merge? :-P) -- - 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 Mon Dec 10 23:13:36 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 11 Dec 2018 00:13:36 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <7b81aa15-2e93-ebe7-8b21-9ec6a40a7cb3@sysmocom.de> References: <20181113154350.GA11128@fintan.stsp.name> <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> <20181208143123.GA6923@my.box> <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> <57d4bf33-eb33-682b-47a6-ddde56c72d30@sysmocom.de> <7b81aa15-2e93-ebe7-8b21-9ec6a40a7cb3@sysmocom.de> Message-ID: <20181210231336.GC6861@my.box> On Mon, Dec 10, 2018 at 02:51:08PM +0100, Oliver Smith wrote: > On 12/10/18 2:41 PM, Max wrote: > > What is "New UI"? > > There's a link at the bottom of the site, "Switch to New UI": > https://gerrit.osmocom.org/?polygerrit=1 The single worst issue in the "new UI" for me is that when a patch is in "WIP" mode, it is impossible "Reply" and send the draft comments. For that I need to go back to the old UI. I also think some design choices are too thin/flimsy and "hard to see", the old ui has more contrast and substance. I tried to send feedback on it, but doing so requires a google login or something equally useless, and they don't just provide an email address. So there I wasn't willing to drill further... Otherwise the new UI is a huge improvement in that each patch shows the related patches *in the right sequence*, and on the summary page there is a row highlight on mouse hover, so it's 1000x easier to click the right row. Also the new UI remembers the patch reply text even if you click on an in-file draft comment and come back later, where the old UI obliterates your text. Remembering the UI choice seems to be a cookie, so if you remove cookies on browser closing, you will always be thrown back to the old ui. ...so much for that :) ~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 Dec 10 23:44:34 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 11 Dec 2018 00:44:34 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <57d4bf33-eb33-682b-47a6-ddde56c72d30@sysmocom.de> References: <20181113154350.GA11128@fintan.stsp.name> <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> <20181208143123.GA6923@my.box> <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> <57d4bf33-eb33-682b-47a6-ddde56c72d30@sysmocom.de> Message-ID: <20181210234434.GD6861@my.box> I think we can give it a try and see whether the annoyance of the below is annoying enough to bother: On Mon, Dec 10, 2018 at 02:25:32PM +0100, Oliver Smith wrote: > However, Neels discovered something else we should think about in summary, even with the +3 voting config applied: A patch with CR votes | shows on the patch summary page as | old UI | new UI ------------------------------------------------------------------ +1 | +1 | +1 +1 +1 | +1 | +1 +1 +1 +1 | +1 | +1 (!) +2 | green tick | green tick (!) +2 +1 | green tick | green tick +2 -1 | green tick | red tick (I hope that's accurate) Also I found that the "label status" shown in the new UI when viewing the patch isn't accurate, only the presence of the "Submit" button is. I do think it sucks that it doesn't show the status properly; you always need to click around and manually sum up CR votes to see where you're at. It's quite a half-arsed implementation, little more than a quick example. Maybe that prolog code can be fixed to reflect a more accurate or custom label status? (Or a social convention would solve that in a breeze.) Also I expect patches to sit around a lot longer, because getting three code reviews so far was quite rare. And I guess it's not ok to add an own +1 vote? :) Maybe we'll need to reduce +3 to +2. Well, let's see. But ok to give it a try as-is. Oh, BTW, do some people still get the right to +2, so that actually only two reviews are needed if one of them voted +2? Or does everyone only +1 now? (easy to configure and enforce) ~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 Dec 11 07:58:53 2018 From: stsp at stsp.name (Stefan Sperling) Date: Tue, 11 Dec 2018 08:58:53 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181210234434.GD6861@my.box> References: <20181113154350.GA11128@fintan.stsp.name> <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> <20181208143123.GA6923@my.box> <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> <57d4bf33-eb33-682b-47a6-ddde56c72d30@sysmocom.de> <20181210234434.GD6861@my.box> Message-ID: <20181211075853.GW44110@ted.stsp.name> On Tue, Dec 11, 2018 at 12:44:34AM +0100, Neels Hofmeyr wrote: > I do think it sucks that it doesn't show the status properly; you always need > to click around and manually sum up CR votes to see where you're at. It's > quite a half-arsed implementation, little more than a quick example. Well... We are doing code review via a *web interface* So what else would you expect? > Oh, BTW, do some people still get the right to +2, so that actually only two > reviews are needed if one of them voted +2? Or does everyone only +1 now? > (easy to configure and enforce) Current +2 / +1 vote token assignments shouldn't change. This was never explicitly discussed, but it was implied. From nhofmeyr at sysmocom.de Tue Dec 11 11:10:24 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 11 Dec 2018 12:10:24 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181211075853.GW44110@ted.stsp.name> References: <20181113154350.GA11128@fintan.stsp.name> <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> <20181208143123.GA6923@my.box> <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> <57d4bf33-eb33-682b-47a6-ddde56c72d30@sysmocom.de> <20181210234434.GD6861@my.box> <20181211075853.GW44110@ted.stsp.name> Message-ID: <20181211111024.GI6861@my.box> On Tue, Dec 11, 2018 at 08:58:53AM +0100, Stefan Sperling wrote: > So what else would you expect? I expect this huge stack of server and client both running on sheer godlike products of science and maths to be able to count to three! :) All this logic is expertly stacked and designed to produce ... garble. But right, that's pretty much the definition of web apps. /me reminisces the days of websites and when simple weblinks and scroll bars worked without javacript ... back when gmx.net was cool :) > > Oh, BTW, do some people still get the right to +2, so that actually only two > > reviews are needed if one of them voted +2? Or does everyone only +1 now? > > (easy to configure and enforce) > > Current +2 / +1 vote token assignments shouldn't change. > This was never explicitly discussed, but it was implied. Ok, then it might turn out to be not such dramatic delay in patches... ~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 Tue Dec 11 11:43:31 2018 From: msuraev at sysmocom.de (Max) Date: Tue, 11 Dec 2018 12:43:31 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181211111024.GI6861@my.box> References: <20181113154350.GA11128@fintan.stsp.name> <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> <20181208143123.GA6923@my.box> <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> <57d4bf33-eb33-682b-47a6-ddde56c72d30@sysmocom.de> <20181210234434.GD6861@my.box> <20181211075853.GW44110@ted.stsp.name> <20181211111024.GI6861@my.box> Message-ID: <466024f3-93a6-8345-c5e5-288552ca57cc@sysmocom.de> If you dislike web interfaces so much than why do you keep using it instead of something like https://github.com/openstack/gertty ? 11.12.18 12:10, Neels Hofmeyr ?????: > > But right, that's pretty much the definition of web apps. > -- - 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 nhofmeyr at sysmocom.de Tue Dec 11 12:33:10 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 11 Dec 2018 13:33:10 +0100 Subject: OT: owning a sysmoBTS we could use for 35c3? Message-ID: <20181211123310.GJ6861@my.box> Hi, if anyone owns a sysmoBTS and either comes to 35c3 or can easily pass it on: can we use your sysmoBTS for the GSM installation, please? They will get insured by the event, we just need the serial number(s). I might also ask you personally later this week / at sysmocom office. 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 laforge at gnumonks.org Wed Dec 12 07:57:22 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 12 Dec 2018 08:57:22 +0100 Subject: OT: owning a sysmoBTS we could use for 35c3? In-Reply-To: <20181211123310.GJ6861@my.box> References: <20181211123310.GJ6861@my.box> Message-ID: <20181212075722.GE16403@nataraja> Hi Neels, On Tue, Dec 11, 2018 at 01:33:10PM +0100, Neels Hofmeyr wrote: > if anyone owns a sysmoBTS and either comes to 35c3 or can easily pass it on: > can we use your sysmoBTS for the GSM installation, please? I suppose this applies to owners of quad-band sysmoBTS only, as the license for the CCC congress is in the 850 band? > I might also ask you personally later this week / at sysmocom office. It would be important to indicate the duration during which the devices are required, i.e. when do you need them (latest) and when will you be able to return them. 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 nhofmeyr at sysmocom.de Wed Dec 12 10:50:12 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 12 Dec 2018 11:50:12 +0100 Subject: OT: owning a sysmoBTS we could use for 35c3? In-Reply-To: <20181212075722.GE16403@nataraja> References: <20181211123310.GJ6861@my.box> <20181212075722.GE16403@nataraja> Message-ID: <20181212105012.GB1926@my.box> Yes, quad band, and latest during congress time, or if you're not coming on/before 22nd of December in Berlin, or pass it on with someone. Until end of congress, or 1st of January. This is not super duper urgent, so no need to go for huge efforts to get the BTS to Leipzig, but it would be nice to have some more to spread around. ~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 Dec 12 10:54:48 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 12 Dec 2018 11:54:48 +0100 Subject: build slave segfaults In-Reply-To: <2010217903.1228.1544575979322.JavaMail.jenkins@jenkins.osmocom.org> References: <2010217903.1228.1544575979322.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <20181212105448.GC1926@my.box> I see sporadic segfaults during jenkins builds every now and then... Let's keep an eye on it. This one built on build2-deb9build-ansible ~N On Wed, Dec 12, 2018 at 12:52:59AM +0000, jenkins at lists.osmocom.org wrote: > See > ... > CC auth_milenage.lo > /bin/bash: line 2: 6091 Segmentation fault (core dumped) /bin/bash ../../libtool --silent --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../include -I/usr/include/p11-kit-1 -DBUILDING_LIBOSMOCORE -Wall -Wall -g -O2 -DBUILDING_LIBOSMOCORE -Wall -MT auth_milenage.lo -MD -MP -MF $depbase.Tpo -c -o auth_milenage.lo auth_milenage.c > make[3]: *** [auth_milenage.lo] Error 139 > Makefile:582: recipe for target 'auth_milenage.lo' failed > make[3]: *** Waiting for unfinished jobs.... > make[3]: Leaving directory '/build/deps/libosmocore/src/gsm' -------------- 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 Dec 12 11:11:21 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 12 Dec 2018 12:11:21 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <466024f3-93a6-8345-c5e5-288552ca57cc@sysmocom.de> References: <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> <20181208143123.GA6923@my.box> <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> <57d4bf33-eb33-682b-47a6-ddde56c72d30@sysmocom.de> <20181210234434.GD6861@my.box> <20181211075853.GW44110@ted.stsp.name> <20181211111024.GI6861@my.box> <466024f3-93a6-8345-c5e5-288552ca57cc@sysmocom.de> Message-ID: <20181212111121.GD1926@my.box> On Tue, Dec 11, 2018 at 12:43:31PM +0100, Max wrote: > If you dislike web interfaces so much than why do you keep using it instead > of something like https://github.com/openstack/gertty ? interesting, I think I knew this once but forgot about it. I wonder, how does gertty interact with the +3 scheme... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From osmith at sysmocom.de Wed Dec 12 11:19:24 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Wed, 12 Dec 2018 12:19:24 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <20181113154350.GA11128@fintan.stsp.name> References: <20181113154350.GA11128@fintan.stsp.name> Message-ID: <039465ef-7ac6-4142-b44f-ee19918186fb@sysmocom.de> So, everbody who replied lately was in favor of rolling out this rule, as we had tested it in the sandbox. I'm rolling it out now. -- - 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 nhofmeyr at sysmocom.de Wed Dec 12 11:21:57 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 12 Dec 2018 12:21:57 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <466024f3-93a6-8345-c5e5-288552ca57cc@sysmocom.de> References: <20181127230431.GC21949@my.box> <34132dbe-f65f-4a00-bf7d-ac91aaaec598@sysmocom.de> <20181208143123.GA6923@my.box> <1ad74927-a80c-41fc-2027-321a92a98ec1@sysmocom.de> <57d4bf33-eb33-682b-47a6-ddde56c72d30@sysmocom.de> <20181210234434.GD6861@my.box> <20181211075853.GW44110@ted.stsp.name> <20181211111024.GI6861@my.box> <466024f3-93a6-8345-c5e5-288552ca57cc@sysmocom.de> Message-ID: <20181212112157.GE1926@my.box> On Tue, Dec 11, 2018 at 12:43:31PM +0100, Max wrote: > of something like https://github.com/openstack/gertty ? All that gertty is giving me is "Error" in the top right corner without the slightest hint at what error it might be. Ah, there's a ~/.gertty.log. Hm, just python tracebacks: AttributeError: 'NoneType' object has no attribute 'keys' Well, not willing to fix their code as well, web interface it is then. ~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 Wed Dec 12 11:23:14 2018 From: keith at rhizomatica.org (Keith) Date: Wed, 12 Dec 2018 12:23:14 +0100 Subject: OT: owning a sysmoBTS we could use for 35c3? In-Reply-To: <20181212105012.GB1926@my.box> References: <20181211123310.GJ6861@my.box> <20181212075722.GE16403@nataraja> <20181212105012.GB1926@my.box> Message-ID: On 12/12/2018 11:50, Neels Hofmeyr wrote: > Yes, quad band, and latest during congress time, I'm wondering what the max possible ERP from the superfemto boards inside the 2050 is, as I understand the freq restriction is with the power stage? One could (as I've done) disconnect the DC from the PA and connect a TX antenna (actually two, in fact) > or if you're not coming on/before 22nd of December in Berlin, > or pass it on with someone. Hmm. I can bring the 1002 on the 26th. > > Until end of congress, or 1st of January. and take it back on the 30th > > This is not super duper urgent, so no need to go for huge efforts to get the > BTS to Leipzig, but it would be nice to have some more to spread around. > > ~N From osmith at sysmocom.de Wed Dec 12 11:41:12 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Wed, 12 Dec 2018 12:41:12 +0100 Subject: voting in gerrit: merge at +3? (+2+1 / +1+1+1) In-Reply-To: <039465ef-7ac6-4142-b44f-ee19918186fb@sysmocom.de> References: <20181113154350.GA11128@fintan.stsp.name> <039465ef-7ac6-4142-b44f-ee19918186fb@sysmocom.de> Message-ID: <8f7c0423-db33-1540-de1c-591701e02e88@sysmocom.de> On 12/12/18 12:19 PM, Oliver Smith wrote:> So, everbody who replied lately was in favor of rolling out this rule, > as we had tested it in the sandbox. I'm rolling it out now. > Done. I've updated the "Adding a new repository" section in the Gerrit wiki page with instructions on adding the rules.pl file: https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit -- - 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 pespin at sysmocom.de Wed Dec 12 12:26:45 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 12 Dec 2018 13:26:45 +0100 Subject: build slave segfaults In-Reply-To: <20181212105448.GC1926@my.box> References: <2010217903.1228.1544575979322.JavaMail.jenkins@jenkins.osmocom.org> <20181212105448.GC1926@my.box> Message-ID: <8d590832-e52d-cedf-c1fe-2c08f691a26f@sysmocom.de> There's no much we can do about that other than opening an OBS bug report. It's a segfault in either bash or libtool, so not related to us. It could be a bug in bash/libtool or even on the virtualization layer being used by OBS to run containers. 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 Dec 12 14:08:15 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 12 Dec 2018 15:08:15 +0100 Subject: OT: owning a sysmoBTS we could use for 35c3? In-Reply-To: <20181211123310.GJ6861@my.box> References: <20181211123310.GJ6861@my.box> Message-ID: <20181212140815.GF1926@my.box> Update: a friendly operator named after a chemical formula has given us 4x 1800 MHz band ARFCNs! Thanks, O2! Thanks to lynxis for managing this! So we no longer are limited to quad band sysmoBTS. We have plenty nano3Gs, BTW, but if you'd like to participate, feel free to bring yours along, too. ~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 Wed Dec 12 14:29:43 2018 From: msuraev at sysmocom.de (Max) Date: Wed, 12 Dec 2018 15:29:43 +0100 Subject: build slave segfaults In-Reply-To: <20181212105448.GC1926@my.box> References: <2010217903.1228.1544575979322.JavaMail.jenkins@jenkins.osmocom.org> <20181212105448.GC1926@my.box> Message-ID: <0b582234-fef1-344b-842b-25c6ed80b13d@sysmocom.de> Hit this recently as well with https://jenkins.osmocom.org/jenkins/job/gerrit-libosmocore/1319/a2=default,a3=default,a4=default,arch=amd64,label=osmocom-gerrit-debian9/ Is there way to retrieve core dump to see what exactly went wrong? What're the settings for |systemd-coredump on buildhost? | 12.12.18 11:54, Neels Hofmeyr ?????: > I see sporadic segfaults during jenkins builds every now and then... > Let's keep an eye on it. > > This one built on build2-deb9build-ansible > > ~N -- - 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 nhofmeyr at sysmocom.de Wed Dec 12 15:46:50 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 12 Dec 2018 16:46:50 +0100 Subject: vty expect script Message-ID: <20181212154650.GG1926@my.box> Hi Keith, I'm now using your vty expect script from https://gerrit.osmocom.org/#/c/osmo-dev/+/11811/ in our congress gsmcore setup, and I absolutely love it! I tweaked the logging, and next to it I also put vty_sticky, which re-opens the vty when the program gets restarted. Attached my current versions. Such a simple and nice way to customize logging, easily attach and detach, quickly change some log levels... much simpler than navigating journalctl. Thanks for that! ~N -------------- next part -------------- #!/usr/bin/expect -f set vty [lindex $argv 0] set host localhost switch $vty { hlr { set port 4258 } bsc { set port 4242 } mgw { set port 4243 } mgw2 { set host 127.0.0.2 set port 4243 } sg { set port 4245 } msc { set port 4254 } sip { set port 4256 } gg { set port 4260 } osmo-hlr { set port 4258 } osmo-bsc { set port 4242 } osmo-mgw { set port 4243 } osmo-mgw-for-bsc { set port 4243 } osmo-mgw-for-msc { set host 127.0.0.2 set port 4243 } osmo-sgsn { set port 4245 } osmo-msc { set port 4254 } osmo-sip-connector { set port 4256 } osmo-ggsn { set port 4260 } default { set port 4242 } } spawn telnet localhost $port expect ">" send "enable\r" expect "#" send "logging enable\r" expect "#" send "logging print category 1\r" expect "#" send "logging print category-hex 0\r" expect "#" send "logging print level 1\r" expect "#" send "logging print file basename last\r" expect "#" send "logging print extended-timestamp 1\r" expect "#" send "logging level set-all notice\r" expect "#" switch $vty { msc { send "logging level mm info\r" expect "#" send "logging level cc info\r" expect "#" } } send "logging filter all 1\r" expect "#" interact -------------- next part -------------- #!/bin/sh while true; do vty $@ sleep 3 done -------------- 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 Dec 12 16:10:17 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 12 Dec 2018 17:10:17 +0100 Subject: build slave segfaults In-Reply-To: <8d590832-e52d-cedf-c1fe-2c08f691a26f@sysmocom.de> References: <2010217903.1228.1544575979322.JavaMail.jenkins@jenkins.osmocom.org> <20181212105448.GC1926@my.box> <8d590832-e52d-cedf-c1fe-2c08f691a26f@sysmocom.de> Message-ID: <20181212161017.GJ1926@my.box> On Wed, Dec 12, 2018 at 01:26:45PM +0100, Pau Espin Pedrol wrote: > on the virtualization layer being used by OBS to run containers. This is our own jenkins build slave, not an OBS package builder. In our build slaves, sporadic failures usually didn't happen. Might hint at faulty RAM or somesuch. Or just a flapping bug, of course. ~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 Dec 12 16:12:18 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 12 Dec 2018 17:12:18 +0100 Subject: Build failed in =?iso-8859-1?Q?Jenkins?= =?iso-8859-1?Q?=3A_master-osmo-pcu_=BB_origin=2Fnrw=2Flitecell15=2C0=2Cos?= =?iso-8859-1?Q?mocom-master-debian9=2Clc15=2CTrue?= #1068 In-Reply-To: <1399662695.1247.1544620929114.JavaMail.jenkins@jenkins.osmocom.org> References: <1399662695.1247.1544620929114.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <20181212161218.GK1926@my.box> whoops, another one On Wed, Dec 12, 2018 at 01:22:09PM +0000, jenkins at lists.osmocom.org wrote: > make[1]: Entering directory ' > CXX gprs_debug.lo > CXX csn1.lo > CXX gsm_rlcmac.lo > CXX gprs_bssgp_pcu.lo > CXX gprs_rlcmac.lo > CXX gprs_rlcmac_sched.lo > CXX gprs_rlcmac_meas.lo > CXX gprs_rlcmac_ts_alloc.lo > gprs_bssgp_pcu.cpp:982:2: warning: #warning "This causes ASAN to complain. It is not critical for normal operation but should be fixed nevertheless" [-Wcpp] > #warning "This causes ASAN to complain. It is not critical for normal operation but should be fixed nevertheless" > ^~~~~~~ > CXX gprs_ms.lo > CXX gprs_ms_storage.lo > CXX gsm_timer.lo > CXX pcu_l1_if.lo > CC pcu_vty.lo > CXX pcu_vty_functions.lo > CC mslot_class.lo > CXX tbf.lo > CXX tbf_ul.lo > CXX tbf_dl.lo > /bin/bash: line 2: 9155 Segmentation fault /bin/bash ../libtool --silent --tag=CXX --mode=compile g++ -DPACKAGE_NAME=\"osmo-pcu\" -DPACKAGE_TARNAME=\"osmo-pcu\" -DPACKAGE_VERSION=\"0.5.1.38-5b52\" -DPACKAGE_STRING=\"osmo-pcu\ 0.5.1.38-5b52\" -DPACKAGE_BUGREPORT=\"osmocom-net-gprs at lists.osmocom.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"osmo-pcu\" -DVERSION=\"0.5.1.38-5b52\" -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/\" -DSTDC_HEADERS=1 -I. -I../include -Wall -I -I -fno-strict-aliasing -I -DENABLE_DIRECT_PHY -I -I./osmo-bts-litecell15 -Wall -ldl -pthread -g -O2 -MT tbf_ul.lo -MD -MP -MF $depbase.Tpo -c -o tbf_ul.lo tbf_ul.cpp > Makefile:779: recipe for target 'tbf_ul.lo' failed > make[1]: *** [tbf_ul.lo] Error 139 > make[1]: *** Waiting for unfinished jobs.... > make[1]: Leaving directory ' > Makefile:466: recipe for target 'all-recursive' failed > make: *** [all-recursive] Error 1 > Build step 'Execute shell' marked build as failure > [WARNINGS]Skipping publisher since build result is FAILURE -- - 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 nhofmeyr at sysmocom.de Wed Dec 12 16:31:55 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 12 Dec 2018 17:31:55 +0100 Subject: switched to gerrit +3, some ideas Message-ID: <20181212163155.GA32159@my.box> There are obvious problems with the current +3 enforcing scheme on gerrit. a) if a patch has +2, the summary shows a tick mark, you don't see that another +1 is needed. b) if a patch has three +1s, the summary shows +1, you don't see that it can be merged. c) voting +1 for an own patch has an effect on the mergability. Ideas to improve: a) +2 hides missing +1 On IRC, we agreed that it is a good idea to require two reviews (by two people) -- three is too much. Currently that would be one +2 vote plus one +1 vote. (alternatively 3x +1, too). Idea: if we remove the "+2" ability, we avoid the problem that a +2 hides the missing +1. Everyone has only +1 votes, and we add up using that plugin. To require only two reviews, we merge once a sum of +2 is reached. b) 3x +1 == "+1" There's no solution short of fixing what gerrit shows in the summary. Everyone will still click on the patch and then see that it already has three votes. c) +1 to self The solution is that you don't vote for your own patches, unless it is really super trivial and not worth wasting others' review time on. Let's see for a few days how we fare with these quirks. ~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 Wed Dec 12 21:13:43 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 12 Dec 2018 22:13:43 +0100 Subject: build slave segfaults In-Reply-To: <20181212161017.GJ1926@my.box> References: <2010217903.1228.1544575979322.JavaMail.jenkins@jenkins.osmocom.org> <20181212105448.GC1926@my.box> <8d590832-e52d-cedf-c1fe-2c08f691a26f@sysmocom.de> <20181212161017.GJ1926@my.box> Message-ID: <20181212211343.GR16403@nataraja> On Wed, Dec 12, 2018 at 05:10:17PM +0100, Neels Hofmeyr wrote: > On Wed, Dec 12, 2018 at 01:26:45PM +0100, Pau Espin Pedrol wrote: > > on the virtualization layer being used by OBS to run containers. > > This is our own jenkins build slave, not an OBS package builder. might be useful to look at whether it happens on one particular build slave only, or on multiple/all. If it's only one particular machine, then very clearly that machine is likely broken. -- - 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 Wed Dec 12 21:17:51 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 12 Dec 2018 22:17:51 +0100 Subject: switched to gerrit +3, some ideas In-Reply-To: <20181212163155.GA32159@my.box> References: <20181212163155.GA32159@my.box> Message-ID: <20181212211751.GS16403@nataraja> Hi Neels and Oliver, thanks for your work and investigation. To me, it seems, after all, gerrit is not suited for what we try to achieve. Confusing messages in the UI are dangerous, particularly if there's no clear solution in sight. I would hence rather go back to Neels' proposal to simply give all [known] developers +2 capacity with a social contract. Please let's avoid re-starting the discussion from scratch. > Let's see for a few days how we fare with these quirks. Ok if you'd like we can do that, but to me a broken UI/representation with no fix expected to show up makes it quite clear that this is not a situation which we want to persist. To me, the behaviour you describe as the current status quo is a no-go, sorry. 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 Wed Dec 12 21:53:50 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 12 Dec 2018 22:53:50 +0100 Subject: switched to gerrit +3, some ideas In-Reply-To: <20181212211751.GS16403@nataraja> References: <20181212163155.GA32159@my.box> <20181212211751.GS16403@nataraja> Message-ID: <50cb92c2-607e-400a-7c06-8909bf523fd7@sysmocom.de> Hi, given that the UI has so many issues with the plugin, let's move to the other approach then (everybody can +2, that's it, right?). -- - 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 Thu Dec 13 02:06:25 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 13 Dec 2018 03:06:25 +0100 Subject: switched to gerrit +3, some ideas In-Reply-To: <20181212211751.GS16403@nataraja> References: <20181212163155.GA32159@my.box> <20181212211751.GS16403@nataraja> Message-ID: <20181213020625.GB12706@my.box> On Wed, Dec 12, 2018 at 10:17:51PM +0100, Harald Welte wrote: > I would hence rather go back to Neels' proposal to simply give all [known] > developers +2 capacity with a social contract. Ok, I like that, but wanted to give the other way a chance / didn't want to be the one to press for it. osmith, can you remove the special repository config again plz, and then I'll take care of reconfiguring gerrit tomorrow. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From osmith at sysmocom.de Thu Dec 13 09:55:06 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Thu, 13 Dec 2018 10:55:06 +0100 Subject: switched to gerrit +3, some ideas In-Reply-To: <20181213020625.GB12706@my.box> References: <20181212163155.GA32159@my.box> <20181212211751.GS16403@nataraja> <20181213020625.GB12706@my.box> Message-ID: On 12/13/18 3:06 AM, Neels Hofmeyr wrote: > On Wed, Dec 12, 2018 at 10:17:51PM +0100, Harald Welte wrote: >> I would hence rather go back to Neels' proposal to simply give all [known] >> developers +2 capacity with a social contract. > > Ok, I like that, but wanted to give the other way a chance / didn't want to be > the one to press for it. > > osmith, can you remove the special repository config again plz, Done. -- - 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 mykola at kingmuffin.com Fri Dec 14 09:51:18 2018 From: mykola at kingmuffin.com (Mykola Shchetinin) Date: Fri, 14 Dec 2018 11:51:18 +0200 Subject: nano3g ip.access femtocells and transcoding Message-ID: Dear Osmocom community, Did somebody try to use nano3g ip.access femtocells and Osmocom system with external call handling? What I am trying to do is to make calls work between VoIP phones connected to PBX and UEs connected to Osmocom system. I've tried two PBXs: Kamailio with rtpengine and Asterisk. Signalling worked good between VoIP phone and UE with both PBXs; calls between two UEs registered on Osmocom system worked good also... But I fail to do transcoding (calls between VoIP phone and UE). The problem is that it is unknown which codec is used by nano3g ip.access femtocell. So, the question is: Do you know what codecs were used for speech in your setup with nano3g ip.access femtocells? Or do you know how to find out that information? (It was stated by ip.access that they use AMR but I failed to match AMR specs with RTP payload that was sent by femtocell...). I would be very grateful for any ideas. Kind regards, Mykola From djks74 at gmail.com Fri Dec 14 10:05:04 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Fri, 14 Dec 2018 17:05:04 +0700 Subject: nano3g ip.access femtocells and transcoding In-Reply-To: References: Message-ID: Dear Mykola, PBX (like asterisk) not support amr, try using TCHF/TCHH (not AMR). see this : https://community.asterisk.org/t/support-for-amr-codec/73659 hope this help! On Fri, Dec 14, 2018 at 4:51 PM Mykola Shchetinin wrote: > Dear Osmocom community, > > Did somebody try to use nano3g ip.access femtocells and Osmocom system with > external call handling? What I am trying to do is to make calls work > between > VoIP phones connected to PBX and UEs connected to Osmocom system. I've > tried two > PBXs: Kamailio with rtpengine and Asterisk. Signalling worked good between > VoIP > phone and UE with both PBXs; calls between two UEs registered on Osmocom > system > worked good also... But I fail to do transcoding (calls between VoIP phone > and > UE). The problem is that it is unknown which codec is used by nano3g > ip.access > femtocell. > > So, the question is: Do you know what codecs were used for speech in your > setup > with nano3g ip.access femtocells? Or do you know how to find out that > information? (It was stated by ip.access that they use AMR but I failed to > match > AMR specs with RTP payload that was sent by femtocell...). > > I would be very grateful for any ideas. > > Kind regards, Mykola > -- Best Regards, Sandi -------------- next part -------------- An HTML attachment was scrubbed... URL: From mykola at kingmuffin.com Fri Dec 14 10:07:29 2018 From: mykola at kingmuffin.com (Mykola Shchetinin) Date: Fri, 14 Dec 2018 12:07:29 +0200 Subject: nano3g ip.access femtocells and transcoding In-Reply-To: References: Message-ID: > try using TCHF/TCHH (not AMR) and how do one tell the femtocell to use that? -------------- next part -------------- An HTML attachment was scrubbed... URL: From djks74 at gmail.com Fri Dec 14 10:12:43 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Fri, 14 Dec 2018 17:12:43 +0700 Subject: nano3g ip.access femtocells and transcoding In-Reply-To: References: Message-ID: Change on your config on osmo-bsc, osmo-msc to change the codec. example : (osmo-bsc) msc 0 ip.access rtp-base 25000 no bsc-welcome-text no bsc-msc-lost-text no bsc-grace-text type normal allow-emergency allow codec-list fr1 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 forbidden amr-config 5_15k forbidden amr-config 4_75k forbidden mgw remote-ip 127.0.0.1 mgw remote-port 2427 mgw endpoint-range 1 31 mgw local-ip 127.0.0.1 (osmo-msc) mncc-int default-codec tch-f fr default-codec tch-h hr On Fri, Dec 14, 2018 at 5:07 PM Mykola Shchetinin wrote: > > try using TCHF/TCHH (not AMR) > and how do one tell the femtocell to use that? > -- Best Regards, Sandi -------------- next part -------------- An HTML attachment was scrubbed... URL: From mykola at kingmuffin.com Fri Dec 14 10:16:28 2018 From: mykola at kingmuffin.com (Mykola Shchetinin) Date: Fri, 14 Dec 2018 12:16:28 +0200 Subject: nano3g ip.access femtocells and transcoding In-Reply-To: References: Message-ID: Thank you for the help. Though we don't have osmo-bsc as we have 3g only network (osmo-hnbgw) and the parameters you've written for osmo-msc seem to work for internal call handling only (as far as I know) whilst I use osmo-sip-connector to connect to PBX... -------------- next part -------------- An HTML attachment was scrubbed... URL: From djks74 at gmail.com Fri Dec 14 10:20:15 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Fri, 14 Dec 2018 17:20:15 +0700 Subject: nano3g ip.access femtocells and transcoding In-Reply-To: References: Message-ID: it should be the same for osmo-msc, it connect to osmo-sip-connector too via /tmp/bsc_mncc om msc site. did you add these parameter to connect mncc to osmo-sip? On Fri, Dec 14, 2018 at 5:16 PM Mykola Shchetinin wrote: > Thank you for the help. > Though we don't have osmo-bsc as we have 3g only network (osmo-hnbgw) and > the parameters you've written for osmo-msc seem to work for internal call > handling only (as far as I know) whilst I use osmo-sip-connector to connect > to PBX... > -- Best Regards, Sandi -------------- next part -------------- An HTML attachment was scrubbed... URL: From mykola at kingmuffin.com Fri Dec 14 10:24:36 2018 From: mykola at kingmuffin.com (Mykola Shchetinin) Date: Fri, 14 Dec 2018 12:24:36 +0200 Subject: nano3g ip.access femtocells and transcoding In-Reply-To: References: Message-ID: I will try that and report -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Fri Dec 14 15:28:23 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 14 Dec 2018 16:28:23 +0100 Subject: nano3g ip.access femtocells and transcoding In-Reply-To: References: Message-ID: <20181214152823.GA2611@my.box> Hi Mykola, that talk about AMR in this thread is completely moot when we're talking IuCS and nano3G. The point is that IuCS doesn't talk plain RTP, it talks IuUP inside the RTP payload (!). That is another header, and the AMR bits inside that are mangled and shifted around, even though the underlying codec is still AMR. We are also talking about that as we are gearing up for congress. Not so long ago on this mailing list we have talked about IuUP, and the two branches that are half finished work towards de-/encapsulating IuUP when talking to 3G. So far 3G <-> 3G voice calls work only because we directly pass through the IuUP (with a pretty mad header hack) and then both ends understand to extract the voice from it. As soon as you want to go 3G <-> 2G or 3G <-> PBX, it's a lost cause without IuUP decoding, e.g. in OsmoMGW. ~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 Fri Dec 14 15:35:56 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 14 Dec 2018 16:35:56 +0100 Subject: nano3g ip.access femtocells and transcoding In-Reply-To: <20181214152823.GA2611@my.box> References: <20181214152823.GA2611@my.box> Message-ID: <20181214153556.GA6975@my.box> Copying another mail I wrote on another list: " I've been asked about IuUP specs. So far I know of 3GPP TS 25.414, 5.1.3.3.2 RTP Payload: "A single Iu UP PDU, as described in TS 25.415 [24], shall be transported as RTP payload." And 25.415 contains the juicy bits. We have osmo-mgw branch neels/iuup refactoring some RTP packet handling to be able to easily strip/insert an IuUP header with correct checksums etc., and we have libosmocore branch laforge/iu_up implementing a state machine about unshuffling the payload bits. I guess to get a working solution we would need to marry those two branches and fix whatever is still broken/not implemented in there. They are still potentially wildly incompatible. " ~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 Fri Dec 14 15:50:44 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 14 Dec 2018 16:50:44 +0100 Subject: switched to gerrit +3, some ideas In-Reply-To: References: <20181212163155.GA32159@my.box> <20181212211751.GS16403@nataraja> <20181213020625.GB12706@my.box> Message-ID: <20181214155044.GB7033@my.box> > > osmith, can you remove the special repository config again plz, > > Done. I have already enabled +2 permissions for known users, but we have a bit of a vacuum now because there is no official etiquette on voting written on the wiki yet. Coming soon. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mykola at kingmuffin.com Fri Dec 14 16:30:50 2018 From: mykola at kingmuffin.com (Mykola Shchetinin) Date: Fri, 14 Dec 2018 18:30:50 +0200 Subject: nano3g ip.access femtocells and transcoding In-Reply-To: <20181214153556.GA6975@my.box> References: <20181214152823.GA2611@my.box> <20181214153556.GA6975@my.box> Message-ID: Hello Neels, Thank you very much. It explains a lot! > We have osmo-mgw branch neels/iuup refactoring some RTP packet handling to be > able to easily strip/insert an IuUP header with correct checksums etc., and we > have libosmocore branch laforge/iu_up implementing a state machine about > unshuffling the payload bits. I guess to get a working solution we would need > to marry those two branches and fix whatever is still broken/not implemented in > there. They are still potentially wildly incompatible. And can I ask what the status/priority of this work is? When do you want/expect to get this working? Is there any way we could support that? Kind regards, Mykola From nhofmeyr at sysmocom.de Fri Dec 14 17:08:34 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 14 Dec 2018 18:08:34 +0100 Subject: switched to gerrit +3, some ideas In-Reply-To: <20181213020625.GB12706@my.box> References: <20181212163155.GA32159@my.box> <20181212211751.GS16403@nataraja> <20181213020625.GB12706@my.box> Message-ID: <20181214170834.GA9068@my.box> See voting rules draft at https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit Give feedback, otherwise these are now in force. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From lynxis at fe80.eu Sat Dec 15 21:22:15 2018 From: lynxis at fe80.eu (Alexander Couzens) Date: Sat, 15 Dec 2018 22:22:15 +0100 Subject: OT: owning a sysmoBTS we could use for 35c3? In-Reply-To: References: <20181211123310.GJ6861@my.box> <20181212075722.GE16403@nataraja> <20181212105012.GB1926@my.box> Message-ID: <20181215203047.1076b0c8@lazus.yip> Hi Keith, thanks for your offer! The 2050 seems is tooo big (and powerful). It would be nice if you could bring a sysmo1002. Best, lynxis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nhofmeyr at sysmocom.de Sun Dec 16 16:06:55 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 16 Dec 2018 17:06:55 +0100 Subject: Build failed in =?iso-8859-1?Q?Jenkins?= =?iso-8859-1?Q?=3A_master-osmo-sgsn_=BB_--disable-iu=2C1=2Ca3=3Ddefault?= =?iso-8859-1?Q?=2Ca4=3Ddefault=2Cosmocom-master-debian9?= #7511 In-Reply-To: <205580966.26.1544945909352.JavaMail.jenkins@jenkins.osmocom.org> References: <205580966.26.1544945909352.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <20181216160655.GD6112@my.box> Created issue OS#3736 for this. Let's collect failing build details there. ~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 Sun Dec 16 16:42:09 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 16 Dec 2018 17:42:09 +0100 Subject: nano3g ip.access femtocells and transcoding In-Reply-To: References: <20181214152823.GA2611@my.box> <20181214153556.GA6975@my.box> Message-ID: <20181216164209.GB12816@my.box> On Fri, Dec 14, 2018 at 06:30:50PM +0200, Mykola Shchetinin wrote: > And can I ask what the status/priority of this work is? When do you want/expect > to get this working? The prio is hobby / contribution. There is no funding for that presently. But being able to decode it is very desirable from the community POV. It would allow 2G/PBX+PSTN interop, early media: important for a non-lab installation. We might try to get it working for the 35c3 congress, but we might just disable 3G (as opt-in) if 3G voice cannot work, to improve the user experience. > Is there any way we could support that? As always, you can contribute code, or you can fund development. Fund either own developer(s) and contribute to gerrit, or book e.g. from sysmocom. I think we should be able to take that on in early 2019, but rather ask sales at . ~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 gullik.webjorn at corevalue.se Mon Dec 17 08:46:58 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Mon, 17 Dec 2018 09:46:58 +0100 Subject: First post Message-ID: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> Hello, I have recently started to deploy OpenBSC . Initially I hope to contribute to manuals and howtos and with bug reports and testing. I have followed the suggested line, and installed everything from binarys, which puts for instance osmo-msc at 1.2.0. The platform is Orange Pi Zero, and UHD / B100, but will evolve to OPI Z + limesdr-mini. I have encountered the "swapped address" bug reported some 3-4 months ago, but is there in osmo-msc 1.2.0, i.e. resulting in one way audio, since the sdp is addressed to a byte reversed address. Apart from that problem I have some minor stability issues (more later ). so, my entry #1 Latest .deb packages have an issue with requesting the RTP stream for audio TO Mobile with a bogus IP address: 16:20:17.739790 IP (tos 0x0, ttl 64, id 50362, offset 0, flags [none], proto UDP (17), length 698) ??? orangepizero.lan.5065 > slottet.lan.sip: [udp sum ok] SIP, length: 670 ??????? INVITE sip:1000 at 192.168.1.80:5060 SIP/2.0 ??????? Via: SIP/2.0/UDP 192.168.1.170:5065;rport;branch=z9hG4bKcgB6KF1r9Z8Zj ??????? Max-Forwards: 70 ??????? From: ;tag=9U40t8B3a8p5r ??????? To: ??????? Call-ID: 590931be-7be8-1237-51bb-0242ed556d0c ??????? CSeq: 938485738 INVITE ??????? Contact: ??????? User-Agent: sofia-sip/1.12.11devel ??????? Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE ??????? Supported: timer, 100rel ??????? Content-Type: application/sdp ??????? Content-Length: 129 ??????? v=0 ??????? o=Osmocom 0 0 IN IP4 170.1.168.192 ??????? s=GSM Call ??????? c=IN IP4 170.1.168.192 ??????? t=0 0 ??????? m=audio 4036 RTP/AVP 0 ??????? a=rtpmap:0 GSM/8000 Asterisk on 192.168.1.80, osmo stack on 192.168.1.170, Best Regards, Gullik From gullik.webjorn at corevalue.se Mon Dec 17 09:00:30 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Mon, 17 Dec 2018 10:00:30 +0100 Subject: First post In-Reply-To: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> References: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> Message-ID: <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> It looks like this is addressed in change 11139, however this was 3 months ago, and build date of osmo-msc_1.2.0_armhf.deb seems to be nov-10, but it seems not in there. Would the fix be in osmo-msc_1.2.0.140.1051c_armhf.deb ? Gullik On 2018-12-17 09:46, Gullik Webjorn wrote: > Hello, > > I have recently started to deploy OpenBSC . Initially I hope to > contribute to manuals and howtos > > and with bug reports and testing. I have followed the suggested line, > and installed everything from > > binarys, which puts for instance osmo-msc at 1.2.0. The platform is > Orange Pi Zero, and UHD / B100, > > but will evolve to OPI Z + limesdr-mini. > > I have encountered the "swapped address" bug reported some 3-4 months > ago, but is there in > > osmo-msc 1.2.0, i.e. resulting in one way audio, since the sdp is > addressed to a byte reversed > > address. Apart from that problem I have some minor stability issues > (more later ). > > so, my entry #1 > > Latest .deb packages have an issue with requesting the RTP stream for > audio TO Mobile > > with a bogus IP address: > > 16:20:17.739790 IP (tos 0x0, ttl 64, id 50362, offset 0, flags [none], > proto UDP (17), length 698) > ??? orangepizero.lan.5065 > slottet.lan.sip: [udp sum ok] SIP, length: > 670 > ??????? INVITE sip:1000 at 192.168.1.80:5060 SIP/2.0 > ??????? Via: SIP/2.0/UDP > 192.168.1.170:5065;rport;branch=z9hG4bKcgB6KF1r9Z8Zj > ??????? Max-Forwards: 70 > ??????? From: ;tag=9U40t8B3a8p5r > ??????? To: > ??????? Call-ID: 590931be-7be8-1237-51bb-0242ed556d0c > ??????? CSeq: 938485738 INVITE > ??????? Contact: > ??????? User-Agent: sofia-sip/1.12.11devel > ??????? Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, > SUBSCRIBE, NOTIFY, REFER, UPDATE > ??????? Supported: timer, 100rel > ??????? Content-Type: application/sdp > ??????? Content-Length: 129 > > ??????? v=0 > ??????? o=Osmocom 0 0 IN IP4 170.1.168.192 > ??????? s=GSM Call > ??????? c=IN IP4 170.1.168.192 > ??????? t=0 0 > ??????? m=audio 4036 RTP/AVP 0 > ??????? a=rtpmap:0 GSM/8000 > > Asterisk on 192.168.1.80, osmo stack on 192.168.1.170, > > Best Regards, > > Gullik > From pespin at sysmocom.de Mon Dec 17 09:39:38 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 17 Dec 2018 10:39:38 +0100 Subject: First post In-Reply-To: <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> References: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> Message-ID: Hi Gullik, first of all, thanks for testing and reporting the issues you see. Where are you installing your packages from? Osmocom repositories? latest [1] or nightly [2]? Packages from "latest" start to be a bit old nowadays, and have some known bugs. So in general if you are planning to contribute and you are getting used to the system, I'd recommend using nightly to follow development more tightly, at least until we have a new release. If you find an issue, please give it a try on nightly and see if the bug is still there, then submit a ticket in redmine. Patches welcome too of course. Fyi, I plan to do a new release of all components soon in mid January when I'm back from Holidays. [1] https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds [2] https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds On 12/17/18 10:00 AM, Gullik Webjorn wrote: > It looks like this is addressed in change 11139, however this was 3 > months ago, and build date > > of osmo-msc_1.2.0_armhf.deb seems to be nov-10, but it seems not in there. > > Would the fix be in osmo-msc_1.2.0.140.1051c_armhf.deb ? > > Gullik > > > On 2018-12-17 09:46, Gullik Webjorn wrote: >> Hello, >> >> I have recently started to deploy OpenBSC . Initially I hope to >> contribute to manuals and howtos >> >> and with bug reports and testing. I have followed the suggested line, >> and installed everything from >> >> binarys, which puts for instance osmo-msc at 1.2.0. The platform is >> Orange Pi Zero, and UHD / B100, >> >> but will evolve to OPI Z + limesdr-mini. >> >> I have encountered the "swapped address" bug reported some 3-4 months >> ago, but is there in >> >> osmo-msc 1.2.0, i.e. resulting in one way audio, since the sdp is >> addressed to a byte reversed >> >> address. Apart from that problem I have some minor stability issues >> (more later ). >> >> so, my entry #1 >> >> Latest .deb packages have an issue with requesting the RTP stream for >> audio TO Mobile >> >> with a bogus IP address: >> >> 16:20:17.739790 IP (tos 0x0, ttl 64, id 50362, offset 0, flags [none], >> proto UDP (17), length 698) >> ??? orangepizero.lan.5065 > slottet.lan.sip: [udp sum ok] SIP, length: >> 670 >> ??????? INVITE sip:1000 at 192.168.1.80:5060 SIP/2.0 >> ??????? Via: SIP/2.0/UDP >> 192.168.1.170:5065;rport;branch=z9hG4bKcgB6KF1r9Z8Zj >> ??????? Max-Forwards: 70 >> ??????? From: ;tag=9U40t8B3a8p5r >> ??????? To: >> ??????? Call-ID: 590931be-7be8-1237-51bb-0242ed556d0c >> ??????? CSeq: 938485738 INVITE >> ??????? Contact: >> ??????? User-Agent: sofia-sip/1.12.11devel >> ??????? Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, >> SUBSCRIBE, NOTIFY, REFER, UPDATE >> ??????? Supported: timer, 100rel >> ??????? Content-Type: application/sdp >> ??????? Content-Length: 129 >> >> ??????? v=0 >> ??????? o=Osmocom 0 0 IN IP4 170.1.168.192 >> ??????? s=GSM Call >> ??????? c=IN IP4 170.1.168.192 >> ??????? t=0 0 >> ??????? m=audio 4036 RTP/AVP 0 >> ??????? a=rtpmap:0 GSM/8000 >> >> Asterisk on 192.168.1.80, osmo stack on 192.168.1.170, >> >> Best Regards, >> >> Gullik >> -- - 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 stsp at stsp.name Mon Dec 17 15:02:39 2018 From: stsp at stsp.name (Stefan Sperling) Date: Mon, 17 Dec 2018 16:02:39 +0100 Subject: switched to gerrit +3, some ideas In-Reply-To: <20181214170834.GA9068@my.box> References: <20181212163155.GA32159@my.box> <20181212211751.GS16403@nataraja> <20181213020625.GB12706@my.box> <20181214170834.GA9068@my.box> Message-ID: <20181217150239.GQ22366@ted.stsp.name> On Fri, Dec 14, 2018 at 06:08:34PM +0100, Neels Hofmeyr wrote: > See voting rules draft at https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit > > Give feedback, otherwise these are now in force. The new section about voting rules looks good to me. There's some historical baggage throughout this document which should be cleaned up, though. For instance, further down the page in the section https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit#Rationale under "The advantages of Gerrit" it still says: * developers + maintainers can formally vote on a patch (developer: -1/0/+1, maintainer: -2/0/+2) * once a patch has +2 score, it can be (automatically) merged into master I suppose we could just remove those lines? They simply describe the default configuration of gerrit. Similarly, the section https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit#Merge-patch-to-master begins with "A patch can be merged when it has CR+2 and V+1 votes, ..." and duplicates information which is already covered at the top of the page. Apart from that, there is some obsolete information such as a description of a gerrit bug which has been fixed upstream -- do we really need to keep such information around? https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit#Rebase-if-necessary I am wondering if there isn't a better way to integrate the new voting rules in the existing text, rather than putting them right at the top of the page? The page is about general gerrit usage in Osmocom. It doesn't really make much sense to explain voting etiquette before explaining basic details such as how to access gerrit in the first place. Any volunteers for cleaning this page up? Did I just volunteer involuntarily? :) From nhofmeyr at sysmocom.de Mon Dec 17 16:19:03 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 17 Dec 2018 17:19:03 +0100 Subject: switched to gerrit +3, some ideas In-Reply-To: <20181217150239.GQ22366@ted.stsp.name> References: <20181212163155.GA32159@my.box> <20181212211751.GS16403@nataraja> <20181213020625.GB12706@my.box> <20181214170834.GA9068@my.box> <20181217150239.GQ22366@ted.stsp.name> Message-ID: <20181217161903.GA18760@my.box> On Mon, Dec 17, 2018 at 04:02:39PM +0100, Stefan Sperling wrote: > I suppose we could just remove those lines? Sure, go ahead! > Any volunteers for cleaning this page up? > Did I just volunteer involuntarily? :) Usually this stuff sticks to my shoes after I step into it, would very much welcome spreeeeading that around a bit. Well but I often am quite nitpicky on prose, so could be my fault, too, scaring off others too much. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mykola at pentonet.com Mon Dec 17 16:41:31 2018 From: mykola at pentonet.com (Mykola Shchetinin) Date: Mon, 17 Dec 2018 18:41:31 +0200 Subject: nano3g ip.access femtocells and transcoding In-Reply-To: <20181216164209.GB12816@my.box> References: <20181214152823.GA2611@my.box> <20181214153556.GA6975@my.box> <20181216164209.GB12816@my.box> Message-ID: Hello Neels, > As always, you can contribute code, or you can fund development. Fund either > own developer(s) and contribute to gerrit, or book e.g. from sysmocom. Understood. I will try to make it work. Though I don't promise anything as I see this code the first time unlike you and Harald :) Regards, Mykola From nhofmeyr at sysmocom.de Tue Dec 18 12:38:41 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 18 Dec 2018 13:38:41 +0100 Subject: nano3g ip.access femtocells and transcoding In-Reply-To: References: <20181214152823.GA2611@my.box> <20181214153556.GA6975@my.box> <20181216164209.GB12816@my.box> Message-ID: <20181218123841.GA1950@my.box> On Mon, Dec 17, 2018 at 06:41:31PM +0200, Mykola Shchetinin wrote: > Hello Neels, > > > As always, you can contribute code, or you can fund development. Fund either > > own developer(s) and contribute to gerrit, or book e.g. from sysmocom. > > Understood. I will try to make it work. Though I don't promise anything as I see > this code the first time unlike you and Harald :) Feel free to ping on IRC: FreeNode #osmocom any time. In case we try anything for congress it would be good to keep in touch. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ron.menez at entropysolution.com Tue Dec 18 02:17:31 2018 From: ron.menez at entropysolution.com (Ron) Date: Tue, 18 Dec 2018 02:17:31 +0000 Subject: 3G Working Setup Message-ID: <405FF598-A525-43D5-835A-1BC94EC61CD1@entropysolution.com> Hi Community, Does anyone successfully run a 3G network using OSMOCOM elements? Currently we are trying to run the following OSMO elements using this URL "https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box#OsmoHNBGW?. Instead of using a 3G femto cell as HnodeB, does anyone tried to use UMTRX, B210, and LimeSDR? Is there other software that will act as HnodeB between the SDR and OSMOHNBGW? TIA. Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From domi at tomcsanyi.net Wed Dec 19 07:22:53 2018 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Wed, 19 Dec 2018 08:22:53 +0100 (CET) Subject: 3G Working Setup In-Reply-To: <405FF598-A525-43D5-835A-1BC94EC61CD1@entropysolution.com> References: <405FF598-A525-43D5-835A-1BC94EC61CD1@entropysolution.com> Message-ID: <07F01EB9-0F0B-443C-BDDC-8FC4B5B11A7B@tomcsanyi.net> Hello Ron, As far as I know the only project that aims to do a NodeB using SDR is this: http://openbts.org/w/index.php?title=OpenBTS-UMTS Many people also try to use commercial femtocells - so far without any luck if I am correct. Sysmocom IIRC was/is in negotiation of cresting a working femtocell with some vendors, but my memory might be wrong on that. And of course there is the nano3G too. Cheers, Domi 2018. dec. 19. d?tummal, 2:46 id?pontban Ron ?rta: > Hi Community, > > Does anyone successfully run a 3G network using OSMOCOM elements? > > Currently we are trying to run the following OSMO elements using this URL "https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box#OsmoHNBGW?. > > Instead of using a 3G femto cell as HnodeB, does anyone tried to use UMTRX, B210, and LimeSDR? > > Is there other software that will act as HnodeB between the SDR and OSMOHNBGW? > > TIA. > > Best Regard, > > Ron Menez > ron.menez at entropysolution.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Wed Dec 19 12:29:13 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 19 Dec 2018 13:29:13 +0100 Subject: 3G Working Setup In-Reply-To: <405FF598-A525-43D5-835A-1BC94EC61CD1@entropysolution.com> References: <405FF598-A525-43D5-835A-1BC94EC61CD1@entropysolution.com> Message-ID: <20181219122913.GA1905@my.box> On Tue, Dec 18, 2018 at 02:17:31AM +0000, Ron wrote: > Hi Community, > > Does anyone successfully run a 3G network using OSMOCOM elements? The main obstacle is 3G voice, as has been discussed numerous times lately. Only 3G<->3G voice works, because we cannot unmangle the IuUP of 3G voice yet. Will not work: transcode to a PBX or interop with 2G. Mykola recently expressed interest in implementing that, but it remains an open issue, desirable to be solved, but yet unfunded. > Currently we are trying to run the following OSMO elements using this URL "https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box#OsmoHNBGW?. > > Instead of using a 3G femto cell as HnodeB We have the nano3G and the SysmoCell5000 series sold by sysmocom. > Is there other software that will act as HnodeB between the SDR and OSMOHNBGW? The point is that an hNodeB contains an RNC that we happily use. There is no free/open source RNC available apparently, so that is considerable development effort. Expressed in 2G terms, it is as if the osmo-bsc were missing. > does anyone tried to use UMTRX, B210, and LimeSDR? It's not a question of "try", the point is that there is no 3G capable phy to drive the SDR with. In 2G terms, it is as if osmo-bts-trx were missing. Anyone willing to invest time there is more than welcome. It is a considerable effort though. ~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 Wed Dec 19 12:36:01 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 19 Dec 2018 13:36:01 +0100 Subject: 3G Working Setup In-Reply-To: <07F01EB9-0F0B-443C-BDDC-8FC4B5B11A7B@tomcsanyi.net> References: <405FF598-A525-43D5-835A-1BC94EC61CD1@entropysolution.com> <07F01EB9-0F0B-443C-BDDC-8FC4B5B11A7B@tomcsanyi.net> Message-ID: <20181219123601.GS11991@nataraja> Hi Ron and Domi, On Wed, Dec 19, 2018 at 08:22:53AM +0100, Tomcs?nyi, Domonkos wrote: > As far as I know the only project that aims to do a NodeB using SDR is this: > > http://openbts.org/w/index.php?title=OpenBTS-UMTS As usual for OpenBTS architecture, it is missing all the normal 3GPP system architecture, interfaces and protocols. In order to get this working within Osmocom, one would have to remove all core network components from OpenBTS-UMTS (no GGSN, SGSN) and keep only the NodeB + RNC related parts. If one then adds an IuPS interface, one could hook it up with OsmoSGSN and use it together with the remaining osmocom stack. It sounds like a fun project, and I'd love to work on that if I had time and if there weren't plenty of higher priority tasks at this point. So until somebody takes the approach above, one can only use femtocells with Iuh interface in the Osmocom universe. Please note that you also must "own" the cell on a technical level, i.e. it must not be locked down to a given operator. 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 mykola at kingmuffin.com Wed Dec 19 18:49:41 2018 From: mykola at kingmuffin.com (Mykola Shchetinin) Date: Wed, 19 Dec 2018 20:49:41 +0200 Subject: Note about IuUP Message-ID: Hello, It is about how I got a voice working between UE connected to Osmocom 3G (external call handling - Kamailio PBX) and VoIP softphone connected to the PBX. The part about is IuUP only. (Transcoding comes later) I have a traces of a call where a commercial NITB was used and I compared them to traces which I got from a call where Osmocom system was used. (Osmocom Core consisted of libosmocore of branch laforge/iu_up, osmo-mgw of branch neels/iuup and other stuff from Nightly Builds) My femtocell (nano3g ip.access) uses AMR 12.2k as a codec. The difference in IuUP <-> AMR conversion between two. When converting from IuUP to AMR: - Osmo-mgw only strips IuUP header from RTP payload; - Commercial NITB strips IuUP header and prepends AMR header to RTP payload; When converting from AMR to IuUP: - Osmo-mgw only prepends IuUP header to RTP payload; - Commercial NITB strips AMR header and prepends IuUP header to RTP payload; So that means basically that my femtocell sends AMR payload as IuUP payload without AMR header. And expects AMR payload inside IuUP message without AMR header. IuUP header is 4 bytes. AMR header for octet-aligned mode is 2 bytes. To test this I've modified the code of iuup_cn_node.c so that it does: - when converting from IuUP data (rx_data): after stripping IuUP header it prepends 0xf03c as a header (it is for AMR 12.2k). - when converting to IuUP data (osmo_iuup_cn_tx_payload): before prepending IuUP header it strips AMR header. The call performed had voice on both sides. It was performed between a regular phone connected to a femtocell and a VoIP softphone connected to Kamailio PBX. Kind regards, Mykola From mykola at pentonet.com Wed Dec 19 18:56:38 2018 From: mykola at pentonet.com (Mykola Shchetinin) Date: Wed, 19 Dec 2018 20:56:38 +0200 Subject: Note about IuUP In-Reply-To: References: Message-ID: So, the AMR header is hardcoded (0xf03c) and this hack won't to work with AMR of a different bitrate or a different codec. And the problem that arise is how to form a header... From laforge at gnumonks.org Wed Dec 19 20:44:24 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 19 Dec 2018 21:44:24 +0100 Subject: Note about IuUP In-Reply-To: References: Message-ID: <20181219204424.GA7569@nataraja> On Wed, Dec 19, 2018 at 08:56:38PM +0200, Mykola Shchetinin wrote: > So, the AMR header is hardcoded (0xf03c) and this hack won't to work with AMR of > a different bitrate or a different codec. And the problem that arise is how to > form a header... Please refer to http://osmocom.org/issues/1936 for more background and http://git.osmocom.org/libosmocore/log/?h=laforge/iu_up for [untested] code to parse and encode IuUP headers with CRC, etc. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ron.menez at entropysolution.com Wed Dec 19 07:24:27 2018 From: ron.menez at entropysolution.com (Ron) Date: Wed, 19 Dec 2018 07:24:27 +0000 Subject: 3G Working Setup In-Reply-To: <07F01EB9-0F0B-443C-BDDC-8FC4B5B11A7B@tomcsanyi.net> References: <405FF598-A525-43D5-835A-1BC94EC61CD1@entropysolution.com> <07F01EB9-0F0B-443C-BDDC-8FC4B5B11A7B@tomcsanyi.net> Message-ID: Thanks Domonkos for the input. Best Regard, Ron Menez ron.menez at entropysolution.com On Dec 19, 2018, at 3:22 PM, Tomcs?nyi, Domonkos > wrote: Hello Ron, As far as I know the only project that aims to do a NodeB using SDR is this: http://openbts.org/w/index.php?title=OpenBTS-UMTS Many people also try to use commercial femtocells - so far without any luck if I am correct. Sysmocom IIRC was/is in negotiation of cresting a working femtocell with some vendors, but my memory might be wrong on that. And of course there is the nano3G too. Cheers, Domi 2018. dec. 19. d?tummal, 2:46 id?pontban Ron > ?rta: Hi Community, Does anyone successfully run a 3G network using OSMOCOM elements? Currently we are trying to run the following OSMO elements using this URL "https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box#OsmoHNBGW?. Instead of using a 3G femto cell as HnodeB, does anyone tried to use UMTRX, B210, and LimeSDR? Is there other software that will act as HnodeB between the SDR and OSMOHNBGW? TIA. Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Dec 19 21:39:44 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 19 Dec 2018 22:39:44 +0100 Subject: Note about IuUP In-Reply-To: References: Message-ID: <350D9988-57FB-4831-9E0B-CBA34F5291BB@gnumonks.org> Can you post your changes somewhere? Even more so, can you post pcap trsaces of a working setup (whether or not osmocom)? Thanks! -- Sent from a mobile device. Please excuse my brevity. From nhofmeyr at sysmocom.de Wed Dec 19 22:41:55 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 19 Dec 2018 23:41:55 +0100 Subject: LAI_AND_LAC, curious Message-ID: <20181219224155.GA13771@my.box> Re commit 6cb833608fa39943c1ce9fe046992922e09f4266 rename CELL_IDENT_LAI_AND_LAC to CELL_IDENT_LAI The name "LAI AND LAC" makes no sense because a LAC is part of a LAI. Keep the old name available for API backwards compatibility. Change-Id: I2749cf75b7b45de0cd43cf4c696a6b6984f5a065 Related: OS#3124 I remember giving similar code review during the gsm0808_cell_ident patches, and I think the conclusion was that even the specs speak of LAI_AND_LAC. Well, anyway, I'm glad that sanity made it to the CELL_IDENT API finally :) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mykola at pentonet.com Thu Dec 20 07:46:01 2018 From: mykola at pentonet.com (Mykola Shchetinin) Date: Thu, 20 Dec 2018 09:46:01 +0200 Subject: Note about IuUP In-Reply-To: <350D9988-57FB-4831-9E0B-CBA34F5291BB@gnumonks.org> References: <350D9988-57FB-4831-9E0B-CBA34F5291BB@gnumonks.org> Message-ID: > Can you post your changes somewhere? Yes, I've uploaded them to gerrit: https://gerrit.osmocom.org/#/c/osmo-mgw/+/12390/ Jenkins build failed as it needs to be compiled against libosmocore of branch laforge/iu_up. I've just uploaded it to make it easier to share the changes. > Even more so, can you post pcap trsaces of a working setup (whether or not > osmocom)? I cannot post the pcap trace of a call where commercial NITB was used. Though I attach a trace of a call of Osmocom system with the patch referenced above. Description: 10.0.3.20: nano3g ip.access S8 10.0.3.19: Osmocom System (where the trace was captured) 172.48.1.3: Kamailio PBX and rtpengine -------------- next part -------------- A non-text attachment was scrubbed... Name: trace-osmo.pcap Type: application/octet-stream Size: 257173 bytes Desc: not available URL: From stsp at stsp.name Thu Dec 20 08:53:06 2018 From: stsp at stsp.name (Stefan Sperling) Date: Thu, 20 Dec 2018 09:53:06 +0100 Subject: LAI_AND_LAC, curious In-Reply-To: <20181219224155.GA13771@my.box> References: <20181219224155.GA13771@my.box> Message-ID: <20181220085306.GI22366@ted.stsp.name> On Wed, Dec 19, 2018 at 11:41:55PM +0100, Neels Hofmeyr wrote: > Re > commit 6cb833608fa39943c1ce9fe046992922e09f4266 > > rename CELL_IDENT_LAI_AND_LAC to CELL_IDENT_LAI > > The name "LAI AND LAC" makes no sense because a LAC > is part of a LAI. Keep the old name available for > API backwards compatibility. > > Change-Id: I2749cf75b7b45de0cd43cf4c696a6b6984f5a065 > Related: OS#3124 > > I remember giving similar code review during the gsm0808_cell_ident patches, Neels, if you look up issue 3124, you'll see that it was filed by yourself and assigned to me back when you reviewed the cell_ident patches :) > and I think the conclusion was that even the specs speak of LAI_AND_LAC. > Well, anyway, I'm glad that sanity made it to the CELL_IDENT API finally :) > > ~N From mykola at pentonet.com Thu Dec 20 12:46:20 2018 From: mykola at pentonet.com (Mykola Shchetinin) Date: Thu, 20 Dec 2018 14:46:20 +0200 Subject: nano3g ip.access provisioning/configuration Message-ID: Dear Osmocom community, Who deals with configuration of nano3g ip.access here? How do you configure it? We use the latest ip.access firmware that has a bunch of bugfixes and it doesn't support "older" telnet configuration methodology: https://osmocom.org/projects/cellular-infrastructure/wiki/Configuring_the_ipaccess_nano3G So, do you just use other/older firmware or do you have TR069 ACS set up? Kind regards, Mykola From gullik.webjorn at corevalue.se Thu Dec 20 15:24:54 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Thu, 20 Dec 2018 16:24:54 +0100 Subject: First post In-Reply-To: <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> References: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> Message-ID: I have just tried to install from nightly, as opposed to latest. osmo-trx-uhd??? OK osmo-bts-trx?? OK osmo-bsc OK however running osmo-bsc : root at orangepizero:~# osmo-bsc -D osmo-bsc: relocation error: /usr/lib/arm-linux-gnueabihf/libosmoabis.so.6: symbol ipa_ccm_id_resp_parse, version LIBOSMOGSM_1.0 not defined in file libosmogsm.so.10 with link time reference the libosmoabis6 installed is from "nightly" , and is libosmoabis.so.6.0.1 Regards, Gullik >> From gullik.webjorn at corevalue.se Thu Dec 20 15:31:40 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Thu, 20 Dec 2018 16:31:40 +0100 Subject: First post In-Reply-To: References: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> Message-ID: <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> reinstalling libosmogsm causes osmo-bsc to exit with: root at orangepizero:~# osmo-bsc osmo-bsc: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libosmogsm.so.10: undefined symbol: osmo_bcd2str this also from nightly Gullik On 2018-12-20 16:24, Gullik Webjorn wrote: > I have just tried to install from nightly, as opposed to latest. > > osmo-trx-uhd??? OK > > osmo-bts-trx?? OK > > osmo-bsc OK > > however running osmo-bsc : > > root at orangepizero:~# osmo-bsc -D > osmo-bsc: relocation error: > /usr/lib/arm-linux-gnueabihf/libosmoabis.so.6: symbol > ipa_ccm_id_resp_parse, version LIBOSMOGSM_1.0 not defined in file > libosmogsm.so.10 with link time reference > > the libosmoabis6 installed is from "nightly" , and is > libosmoabis.so.6.0.1 > > Regards, > > Gullik > >>> From pespin at sysmocom.de Thu Dec 20 15:35:47 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Thu, 20 Dec 2018 16:35:47 +0100 Subject: First post In-Reply-To: References: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> Message-ID: <48b3b11b-1e16-2282-1818-d006e1291890@sysmocom.de> Hi, looks like you are not using libosmogsm from nightly, probably still using the one from testing. if I get libosmogsm from https://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_9.0/amd64/libosmogsm10_0.12.0.162.b2600_amd64.deb $ objdump -T libosmogsm.so.10.0.0 | grep ipa_ccm_id_resp_parse 000000000002f260 g DF .text 000000000000017e LIBOSMOGSM_1.0 ipa_ccm_id_resp_parse so the symbol is there. That symbol was added in libosmocore 7869baf843fd10d0fd28f79395f3e7a01eebb8b7, that is after last release (and thus not available in package version from "latest"). Easiest would be that you for reinstall for all libosmo* and osmo* packages. 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 pespin at sysmocom.de Thu Dec 20 15:37:55 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Thu, 20 Dec 2018 16:37:55 +0100 Subject: First post In-Reply-To: <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> References: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> Message-ID: <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> That was a On 12/20/18 4:31 PM, Gullik Webjorn wrote: > reinstalling libosmogsm causes osmo-bsc to exit with: > > root at orangepizero:~# osmo-bsc > osmo-bsc: symbol lookup error: > /usr/lib/arm-linux-gnueabihf/libosmogsm.so.10: undefined symbol: > osmo_bcd2str > > this also from nightly > that function was added in libosmocore 7079e698481705c82c7aff58ea9c63469626af80, you need to install new package "libosmocore" from nightly, don't use the one from latest. Please, update all packages and libs as mentioned in my previous post. (force apt re-install for libosmo* and osmo*). -- - 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 gullik.webjorn at corevalue.se Fri Dec 21 08:48:47 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Fri, 21 Dec 2018 09:48:47 +0100 Subject: Call progress on nightly build In-Reply-To: <86598f32-b8fe-9e9d-22a9-5ec7348dd359@corevalue.se> References: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> <86598f32-b8fe-9e9d-22a9-5ec7348dd359@corevalue.se> Message-ID: I have trx, bts, bsc, msc, stp, hlr, and sip installed... asterisk runs on a separate machine, i.e. my ordinary pbx, with just the recomended changes to sip and extensions. When dialling an external number I do not get any call progress (ringing) in the MS. Phone is quiet as I dial the number, when the call is answered voice is "suddenly" there, this is a difference from "latest" where call progress was audiable but had only oneway audio. I run HLR with the -U switch, there seems to be a difference between "latest" and "nightly", what does the -U switch do, modify the database, or just run HLR in backward compatibility mode? Should I delete / reregister phones? Regards, Gullik From gullik.webjorn at corevalue.se Fri Dec 21 09:38:46 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Fri, 21 Dec 2018 10:38:46 +0100 Subject: Call progress on nightly build In-Reply-To: References: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> <86598f32-b8fe-9e9d-22a9-5ec7348dd359@corevalue.se> Message-ID: <575d4103-bfb6-c269-9b03-55727e523afa@corevalue.se> I have trx, bts, bsc, msc, stp, hlr, and sip installed...on a Orange PI Zero. asterisk runs on a separate machine.. SDR is Ettus B100 for now.... CPU is 4 core arm H2+, idle with stack running 75% idle, increasing to 90% with one call active, i.e. lots of CPU left. Memory consumption 250 out of 512 M, so plenty memory left. In all -- impressive!! A pocket-size GSM base station. Gullik From gullik.webjorn at corevalue.se Fri Dec 21 11:26:45 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Fri, 21 Dec 2018 12:26:45 +0100 Subject: osmo-uhd-trx In-Reply-To: <575d4103-bfb6-c269-9b03-55727e523afa@corevalue.se> References: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> <86598f32-b8fe-9e9d-22a9-5ec7348dd359@corevalue.se> <575d4103-bfb6-c269-9b03-55727e523afa@corevalue.se> Message-ID: I have also seen Bug #3067 Where the uhd-trx continously logs packet loss. Killing the trx, and restarting it, it recovers, and operation is resumed. It seems to get into some unrecoverable loop. This happens rarely, I have seen it twice the last 24 hours. Will try to get a better footprint. Gullik -------------- next part -------------- An HTML attachment was scrubbed... URL: From gullik.webjorn at corevalue.se Fri Dec 21 12:21:57 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Fri, 21 Dec 2018 13:21:57 +0100 Subject: osmo-uhd-trx In-Reply-To: References: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> <86598f32-b8fe-9e9d-22a9-5ec7348dd359@corevalue.se> <575d4103-bfb6-c269-9b03-55727e523afa@corevalue.se> Message-ID: <4c1991aa-3e36-a9ed-c004-c4181aed9690@corevalue.se> Hmm, is the event code actually generated by the uhd driver? It looks like the definition of EVENT_CODE_SEQ_ERROR that generates this log item comes from include/uhd/types/metadata.hpp Gullik | bool uhd_device::recv_async_msg() { uhd::async_metadata_t md; thread_enable_cancel(false); bool rc = usrp_dev->get_device()->recv_async_msg(md); thread_enable_cancel(true); if (!rc) return false; // Assume that any error requires resynchronization if (md.event_code != uhd::async_metadata_t::EVENT_CODE_BURST_ACK) { aligned = false; if ((md.event_code != uhd::async_metadata_t::EVENT_CODE_UNDERFLOW) && (md.event_code != uhd::async_metadata_t::EVENT_CODE_TIME_ERROR)) { LOGC(DDEV, ERR) << str_code(md); } } return true; }| -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Fri Dec 21 22:47:42 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 21 Dec 2018 23:47:42 +0100 Subject: First post In-Reply-To: <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> References: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> Message-ID: <20181221224742.GA6639@my.box> > Please, update all packages and libs as mentioned in my previous post. > (force apt re-install for libosmo* and osmo*). It is important to understand that you cannot sanely mix 'latest' and 'nightly' packages. In 'latest', we have sensible version information and the LIBVERSION is settled. Package dependencies make sense. It is a sane debian package. In 'nightly', we are tracking current master, so even though essential changes have taken place, you may stay on the very same version number. That's why we have disabled version numbers in nightly (don't recall how exactly). If you're using 'nightly', drop all other osmo* packages and only use nightly. Don't expect debian dependencies to pick the correct osmo* packages. ~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 Sat Dec 22 08:41:09 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Sat, 22 Dec 2018 09:41:09 +0100 Subject: First post In-Reply-To: <20181221224742.GA6639@my.box> References: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> <20181221224742.GA6639@my.box> Message-ID: Thanx Neels, Yes, I was under the impression I had already purged "latest", but to make sure, I will scratch the system completely, and reinstall from "nightly" including all required packages and dependencies. Does "nightly" require anything special regarding UHD, or could that be retrieved with apt-get, i.e. std Ettus UHD? I am using a B100. Gullik On 2018-12-21 23:47, Neels Hofmeyr wrote: >> Please, update all packages and libs as mentioned in my previous post. >> (force apt re-install for libosmo* and osmo*). > It is important to understand that you cannot sanely mix 'latest' and 'nightly' packages. > > In 'latest', we have sensible version information and the LIBVERSION is > settled. Package dependencies make sense. It is a sane debian package. > > In 'nightly', we are tracking current master, so even though essential changes > have taken place, you may stay on the very same version number. That's why we > have disabled version numbers in nightly (don't recall how exactly). > > If you're using 'nightly', drop all other osmo* packages and only use nightly. > Don't expect debian dependencies to pick the correct osmo* packages. > > ~N From gullik.webjorn at corevalue.se Sat Dec 22 09:00:50 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Sat, 22 Dec 2018 10:00:50 +0100 Subject: osmo-uhd-trx In-Reply-To: <4c1991aa-3e36-a9ed-c004-c4181aed9690@corevalue.se> References: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> <86598f32-b8fe-9e9d-22a9-5ec7348dd359@corevalue.se> <575d4103-bfb6-c269-9b03-55727e523afa@corevalue.se> <4c1991aa-3e36-a9ed-c004-c4181aed9690@corevalue.se> Message-ID: <2af53f98-3303-ccb5-50f4-4f27a53866a4@corevalue.se> At 3 am the trx stopped again. This time it exited (itself) after logging large amounts of packet loss, within 1 second or so....(as far back as the terminal history displays). Restarting it signal came back within a few seconds. UHD used: UHD_003.009.005-0-unknown installed with apt. trx: osmo-trx-uhd_0.4.0.124.42c1_armhf.deb It seems the interaction beween UHD and TRX is the problem, ( or the TRX itself ) since just rerunning trx fixes everything, and the rest of the BTS components seem functionally intact. Gullik On 2018-12-21 13:21, Gullik Webjorn wrote: > > Hmm, is the event code actually generated by the uhd driver? It looks like > > the definition of EVENT_CODE_SEQ_ERROR that generates this log item comes > > from include/uhd/types/metadata.hpp > > > Gullik > > > | > bool uhd_device::recv_async_msg() > { > uhd::async_metadata_t md; > > thread_enable_cancel(false); > bool rc = usrp_dev->get_device()->recv_async_msg(md); > thread_enable_cancel(true); > if (!rc) > return false; > > // Assume that any error requires resynchronization > if (md.event_code != uhd::async_metadata_t::EVENT_CODE_BURST_ACK) { > aligned = false; > > if ((md.event_code != uhd::async_metadata_t::EVENT_CODE_UNDERFLOW) && > (md.event_code != uhd::async_metadata_t::EVENT_CODE_TIME_ERROR)) { > LOGC(DDEV, ERR) << str_code(md); > } > } > > return true; > }| > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sat Dec 22 09:42:09 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 22 Dec 2018 10:42:09 +0100 Subject: osmo-uhd-trx In-Reply-To: <2af53f98-3303-ccb5-50f4-4f27a53866a4@corevalue.se> References: <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> <86598f32-b8fe-9e9d-22a9-5ec7348dd359@corevalue.se> <575d4103-bfb6-c269-9b03-55727e523afa@corevalue.se> <4c1991aa-3e36-a9ed-c004-c4181aed9690@corevalue.se> <2af53f98-3303-ccb5-50f4-4f27a53866a4@corevalue.se> Message-ID: <20181222094209.GR2961@nataraja> On Sat, Dec 22, 2018 at 10:00:50AM +0100, Gullik Webjorn wrote: > At 3 am the trx stopped again. This time it exited (itself) after logging > large amounts of packet loss, The interesting question is: Was there some kind of cron job or other activity running at 3am on that system, which could cause a system load high enough to make the flow between B100, kernel USB stack, libusb, UHD and osmo-trx-uhd interrupt? Something like this is likely the root cause of the problem. Sure, osmo-trx could "plaster around" it by having a more elegant recovery mechanism, but failing fast due to exit and letting osmo-trx-uhd respawn (normally executed via systemd) isn't actually all too bad. What's definitely a real problem that needs immediate fixing is if we somehow get stack with osmo-trx continuing to run, but failing to transmit a valid signal wihout exit + respawn. 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 Sat Dec 22 11:25:00 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Sat, 22 Dec 2018 12:25:00 +0100 Subject: osmo-uhd-trx In-Reply-To: <20181222094209.GR2961@nataraja> References: <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> <86598f32-b8fe-9e9d-22a9-5ec7348dd359@corevalue.se> <575d4103-bfb6-c269-9b03-55727e523afa@corevalue.se> <4c1991aa-3e36-a9ed-c004-c4181aed9690@corevalue.se> <2af53f98-3303-ccb5-50f4-4f27a53866a4@corevalue.se> <20181222094209.GR2961@nataraja> Message-ID: <27605323-c38f-3271-ae20-51ec92d1be5a@corevalue.se> Hello Harald, long time..... This is syslog for the time... Dec 22 03:15:01 localhost CRON[25895]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Dec 22 03:16:22 localhost osmo-bts-trx[18200]: #033[0;m<0007> l1sap.c:510 1338262/1009/16/22/46 Invalid condition detected: Frame difference is 1338262-1338205=57 > 1! Dec 22 03:17:01 localhost CRON[25911]: (root) CMD (?? cd / && run-parts --report /etc/cron.hourly) here trx uhd has logged lots of lost packets 03:36:19, so 2 seconds before next syslog entry, all within the same second, filling the terminal buffer, so I cannot see loggings immediately before Dec 22 03:19:38 localhost osmo-bts-trx[18200]: #033[0;m#033[1;36m<0001> bts.c:250 Shutting down BTS 0, Reason No clock from osmo-trx Dec 22 03:19:41 localhost osmo-bts-trx[18200]: #033[0;mShutdown timer expired Dec 22 03:19:41 localhost osmo-bts-trx[18200]: ((*)) Dec 22 03:19:41 localhost osmo-bts-trx[18200]:?? | Dec 22 03:19:41 localhost osmo-bts-trx[18200]:? / \ OsmoBTS Dec 22 03:19:41 localhost systemd[1]: osmo-bts-trx.service: Main process exited, code=exited, status=42/n/a Dec 22 03:19:41 localhost systemd[1]: osmo-bts-trx.service: Unit entered failed state. Dec 22 03:19:41 localhost systemd[1]: osmo-bts-trx.service: Failed with result 'exit-code'. Dec 22 03:19:43 localhost systemd[1]: osmo-bts-trx.service: Service hold-off time over, scheduling restart. Dec 22 03:19:43 localhost systemd[1]: Stopped Osmocom osmo-bts for osmo-trx. Dec 22 03:19:43 localhost systemd[1]: Started Osmocom osmo-bts for osmo-trx. Dec 22 03:19:43 localhost osmo-bts-trx[25938]: <0017> control_if.c:911 CTRL at 127.0.0.1 4238 Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m<0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241 Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m<0012> input/ipaccess.c:882 enabling ipaccess BTS mode, OML connecting to 127.0.0.1:3002 Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;33m<000b> trx_if.c:754 Open transceiver for phy0.0 Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m<0012> input/ipa.c:128 127.0.0.1:3002 connection done Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m<0012> input/ipaccess.c:705 received ID get from 1801/0/0 Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:229 O&M Get Attributes [0], Manufacturer Dependent State is unsupported by TRX. Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:1055 ADM state already was Unlocked Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m<0012> input/ipa.c:128 127.0.0.1:3003 connection done Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m<0012> input/ipaccess.c:705 received ID get from 1801/0/0 Dec 22 03:19:45 localhost osmo-bts-trx[25938]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 03:19:47 localhost osmo-bts-trx[25938]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 03:19:49 localhost osmo-bts-trx[25938]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) I just had the same stopping again, here is a snippet from that trx terminal......... Sat Dec 22 10:21:16 2018 DMAIN <0000> Transceiver.cpp:1016 [tid=3007554640] reduced latency: 3:9 Sat Dec 22 10:21:17 2018 DMAIN <0000> Transceiver.cpp:1039 [tid=3007521872] ClockInterface: sending IND CLOCK 292365 Sat Dec 22 10:21:17 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3007554640] new latency: 3:10 (underrun 3:292376 vs 1:292229) Sat Dec 22 10:21:18 2018 DMAIN <0000> Transceiver.cpp:1039 [tid=3007521872] ClockInterface: sending IND CLOCK 292581 Sat Dec 22 10:21:18 2018 DMAIN <0000> Transceiver.cpp:1016 [tid=3007554640] reduced latency: 2:10 Sat Dec 22 10:21:19 2018 DMAIN <0000> Transceiver.cpp:1039 [tid=3007521872] ClockInterface: sending IND CLOCK 292797 Sat Dec 22 10:21:19 2018 DMAIN <0000> Transceiver.cpp:1016 [tid=3007554640] reduced latency: 1:10 Sat Dec 22 10:21:19 2018 DDEV <0002> UHDDevice.cpp:861 [tid=3007521872] No packet received, implementation timed-out Sat Dec 22 10:21:19 2018 DDEV <0002> UHDDevice.cpp:865 [tid=3007521872] UHD: Receive timed out Sat Dec 22 10:21:19 2018 DMAIN <0000> radioInterfaceResamp.cpp:178 [tid=3007521872] Receive error 0 Sat Dec 22 10:21:19 2018 DMAIN <0000> Transceiver.cpp:908 [tid=3007521872] radio Interface receive failed, requesting stop. Sat Dec 22 10:21:19 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3007554640] new latency: 1:11 (underrun 0:292830 vs 0:292819) Sat Dec 22 10:21:19 2018 DDEV <0002> UHDDevice.cpp:861 [tid=3007521872] An internal receive buffer has filled at 3113.55 sec. Sat Dec 22 10:21:20 2018 DDEV <0002> UHDDevice.cpp:1485 [tid=3007521872] Skipping buffer data: timestamp=1245558064 time_end=1245418309 Sat Dec 22 10:21:20 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3007554640] new latency: 1:12 (underrun 3:292843 vs 2:292840) Sat Dec 22 10:21:20 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3007554640] new latency: 1:13 (underrun 3:292854 vs 4:292853) Sat Dec 22 10:21:20 2018 DMAIN <0000> osmo-trx.cpp:435 [tid=3025046000] Shutting down transceiver... Sat Dec 22 10:21:20 2018 DMAIN <0000> Transceiver.cpp:307 [tid=3025046000] Stopping the transceiver Sat Dec 22 10:21:20 2018 DMAIN <0000> Transceiver.cpp:320 [tid=3025046000] Stopping the device Sat Dec 22 10:21:20 2018 DMAIN <0000> Transceiver.cpp:333 [tid=3025046000] Transceiver stopped This is syslog from right before this, I cut a few lines before the first osmo-bts-trx logging at 10:00:26 It complains a few times within that few seconds....then at 10:11:08 , 11, then stopping at 10:21:21 Dec 22 09:57:12 localhost dbus[779]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Dec 22 09:57:12 localhost systemd[1]: Started Network Manager Script Dispatcher Service. Dec 22 09:57:12 localhost nm-dispatcher: req:1 'dhcp4-change' [eth0]: new request (2 scripts) Dec 22 09:57:12 localhost nm-dispatcher: req:1 'dhcp4-change' [eth0]: start running ordered scripts... Dec 22 10:00:01 localhost CRON[29739]: (root) CMD (/usr/lib/armbian/armbian-truncate-logs) Dec 22 10:00:26 localhost osmo-bts-trx[25938]: #033[0;m#033[1;35m<0000> rsl.c:741 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK Dec 22 10:00:26 localhost osmo-bts-trx[25938]: #033[0;m<0011> lapd_core.c:920 Store content res. (dl=0xb681b498) Dec 22 10:00:27 localhost osmo-bts-trx[25938]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb681b498 state LAPD_STATE_MF_EST) Dec 22 10:00:27 localhost osmo-bts-trx[25938]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb681b498 state LAPD_STATE_MF_EST) Dec 22 10:00:28 localhost osmo-bts-trx[25938]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb681b498 state LAPD_STATE_MF_EST) Dec 22 10:00:29 localhost osmo-bts-trx[25938]: #033[0;m#033[1;35m<0000> rsl.c:720 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK Dec 22 10:05:01 localhost CRON[29783]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Dec 22 10:11:08 localhost osmo-bts-trx[25938]: #033[0;m#033[1;35m<0000> rsl.c:741 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK Dec 22 10:11:11 localhost osmo-bts-trx[25938]: #033[0;m#033[1;35m<0000> rsl.c:720 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK Dec 22 10:15:01 localhost CRON[29858]: (root) CMD (/usr/lib/armbian/armbian-truncate-logs) Dec 22 10:15:02 localhost CRON[29859]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Dec 22 10:17:01 localhost CRON[29877]: (root) CMD (?? cd / && run-parts --report /etc/cron.hourly) Dec 22 10:21:21 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> bts.c:250 Shutting down BTS 0, Reason No clock from osmo-trx Dec 22 10:21:24 localhost osmo-bts-trx[25938]: #033[0;mShutdown timer expired Dec 22 10:21:24 localhost osmo-bts-trx[25938]: ((*)) Dec 22 10:21:24 localhost osmo-bts-trx[25938]:?? | Dec 22 10:21:24 localhost osmo-bts-trx[25938]:? / \ OsmoBTS Dec 22 10:21:24 localhost systemd[1]: osmo-bts-trx.service: Main process exited, code=exited, status=42/n/a Dec 22 10:21:24 localhost systemd[1]: osmo-bts-trx.service: Unit entered failed state. Dec 22 10:21:24 localhost systemd[1]: osmo-bts-trx.service: Failed with result 'exit-code'. Dec 22 10:21:26 localhost systemd[1]: osmo-bts-trx.service: Service hold-off time over, scheduling restart. Dec 22 10:21:26 localhost systemd[1]: Stopped Osmocom osmo-bts for osmo-trx. Dec 22 10:21:26 localhost systemd[1]: Started Osmocom osmo-bts for osmo-trx. Dec 22 10:21:26 localhost osmo-bts-trx[29913]: <0017> control_if.c:911 CTRL at 127.0.0.1 4238 Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m<0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241 Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m<0012> input/ipaccess.c:882 enabling ipaccess BTS mode, OML connecting to 127.0.0.1:3002 Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:754 Open transceiver for phy0.0 Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m<0012> input/ipa.c:128 127.0.0.1:3002 connection done Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m<0012> input/ipaccess.c:705 received ID get from 1801/0/0 Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:229 O&M Get Attributes [0], Manufacturer Dependent State is unsupported by TRX. Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:1055 ADM state already was Unlocked Dec 22 10:21:27 localhost osmo-bts-trx[29913]: #033[0;m<0012> input/ipa.c:128 127.0.0.1:3003 connection done Dec 22 10:21:27 localhost osmo-bts-trx[29913]: #033[0;m<0012> input/ipaccess.c:705 received ID get from 1801/0/0 Dec 22 10:21:28 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:21:30 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:21:32 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:21:34 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:21:36 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:21:38 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:21:40 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:21:42 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:21:44 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:21:46 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:21:48 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:21:50 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:21:52 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:21:54 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:21:56 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:21:58 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:22:00 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:22:02 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:22:04 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:22:06 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:22:08 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:22:10 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:22:11 localhost dhclient[5395]: DHCPREQUEST of 192.168.1.170 on eth0 to 192.168.1.1 port 67 Dec 22 10:22:11 localhost dhclient[5395]: DHCPACK of 192.168.1.170 from 192.168.1.1 Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2789] dhcp4 (eth0):?? address 192.168.1.170 Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2791] dhcp4 (eth0):?? plen 24 (255.255.255.0) Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2792] dhcp4 (eth0):?? gateway 192.168.1.1 Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2793] dhcp4 (eth0):?? server identifier 192.168.1.1 Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2793] dhcp4 (eth0):?? lease time 3600 Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2794] dhcp4 (eth0):?? hostname 'orangepizero' Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2795] dhcp4 (eth0):?? nameserver '192.168.1.1' Dec 22 10:22:11 localhost dbus[779]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2796] dhcp4 (eth0):?? domain name 'lan' Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2797] dhcp4 (eth0): state changed bound -> bound Dec 22 10:22:11 localhost systemd[1]: Starting Network Manager Script Dispatcher Service... Dec 22 10:22:11 localhost dhclient[5395]: bound to 192.168.1.170 -- renewal in 1598 seconds. Dec 22 10:22:11 localhost dbus[779]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Dec 22 10:22:11 localhost systemd[1]: Started Network Manager Script Dispatcher Service. Dec 22 10:22:11 localhost nm-dispatcher: req:1 'dhcp4-change' [eth0]: new request (2 scripts) Dec 22 10:22:11 localhost nm-dispatcher: req:1 'dhcp4-change' [eth0]: start running ordered scripts... Dec 22 10:22:12 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:22:14 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:22:16 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:22:18 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:22:20 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 10:22:22 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Then, as I restart trx-uhd again, ( by kbd uparrow ) carrier comes back and phone registers within a few seconds..... I see nothing upsetting in syslog that could explain cpu outage, besides, this is a 4-core Orange Pi Zero, I do not however know what quirks in Armbian Linux could lock out processing, when total load is 95% or so out of 400% ( i.e. 75% idle ) If there is anything I could do to bring clarity, please suggest.... Regards, Gullik On 2018-12-22 10:42, Harald Welte wrote: > On Sat, Dec 22, 2018 at 10:00:50AM +0100, Gullik Webjorn wrote: >> At 3 am the trx stopped again. This time it exited (itself) after logging >> large amounts of packet loss, > The interesting question is: Was there some kind of cron job or other activity > running at 3am on that system, which could cause a system load high enough to > make the flow between B100, kernel USB stack, libusb, UHD and osmo-trx-uhd > interrupt? I will investigate as I possibly can > > Something like this is likely the root cause of the problem. > > Sure, osmo-trx could "plaster around" it by having a more elegant recovery > mechanism, but failing fast due to exit and letting osmo-trx-uhd respawn > (normally executed via systemd) isn't actually all too bad. > > What's definitely a real problem that needs immediate fixing is if we > somehow get stack with osmo-trx continuing to run, but failing to > transmit a valid signal wihout exit + respawn. That HAS happened for me, with the screen filled with logging of packet loss, pointing at line 1319 in | uhd_device::recv_async_msg() | > > Regards, > Harald -------------- next part -------------- An HTML attachment was scrubbed... URL: From domi at tomcsanyi.net Sat Dec 22 12:32:39 2018 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Sat, 22 Dec 2018 13:32:39 +0100 (CET) Subject: osmo-uhd-trx In-Reply-To: <27605323-c38f-3271-ae20-51ec92d1be5a@corevalue.se> References: <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> <86598f32-b8fe-9e9d-22a9-5ec7348dd359@corevalue.se> <575d4103-bfb6-c269-9b03-55727e523afa@corevalue.se> <4c1991aa-3e36-a9ed-c004-c4181aed9690@corevalue.se> <2af53f98-3303-ccb5-50f4-4f27a53866a4@corevalue.se> <20181222094209.GR2961@nataraja> <27605323-c38f-3271-ae20-51ec92d1be5a@corevalue.se> Message-ID: <0B8FA68B-CF43-4B28-82A1-D66D5242B752@tomcsanyi.net> Hello Gullik, If possible please set up some kind of monitoring of key system parameters (load, memory etc.) so we can determine if there is any irregularities happening before the issue. Also it would help us to see if there is any regularity in the time intervals the issue happens. I for my servers use Zabbix for this, but it would be way too complicated I think for this purpose. So any simple monitoring system that retains historic data (for the last, let?s say 24 hours) would be good. Just my 2cents... Domi 2018. dec. 22. d?tummal, 12:25 id?pontban Gullik Webjorn ?rta: > Hello Harald, long time..... > > This is syslog for the time... > > Dec 22 03:15:01 localhost CRON[25895]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) > Dec 22 03:16:22 localhost osmo-bts-trx[18200]: #033[0;m<0007> l1sap.c:510 1338262/1009/16/22/46 Invalid condition detected: Frame difference is 1338262-1338205=57 > 1! > Dec 22 03:17:01 localhost CRON[25911]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) > > here trx uhd has logged lots of lost packets > > 03:36:19, so 2 seconds before next syslog entry, all within the same second, filling the terminal buffer, so I cannot see loggings immediately before > > > > Dec 22 03:19:38 localhost osmo-bts-trx[18200]: #033[0;m#033[1;36m<0001> bts.c:250 Shutting down BTS 0, Reason No clock from osmo-trx > > Dec 22 03:19:41 localhost osmo-bts-trx[18200]: #033[0;mShutdown timer expired > Dec 22 03:19:41 localhost osmo-bts-trx[18200]: ((*)) > Dec 22 03:19:41 localhost osmo-bts-trx[18200]: | > Dec 22 03:19:41 localhost osmo-bts-trx[18200]: / \ OsmoBTS > Dec 22 03:19:41 localhost systemd[1]: osmo-bts-trx.service: Main process exited, code=exited, status=42/n/a > Dec 22 03:19:41 localhost systemd[1]: osmo-bts-trx.service: Unit entered failed state. > Dec 22 03:19:41 localhost systemd[1]: osmo-bts-trx.service: Failed with result 'exit-code'. > Dec 22 03:19:43 localhost systemd[1]: osmo-bts-trx.service: Service hold-off time over, scheduling restart. > Dec 22 03:19:43 localhost systemd[1]: Stopped Osmocom osmo-bts for osmo-trx. > Dec 22 03:19:43 localhost systemd[1]: Started Osmocom osmo-bts for osmo-trx. > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: <0017> control_if.c:911 CTRL at 127.0.0.1 4238 > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m<0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241 > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m<0012> input/ipaccess.c:882 enabling ipaccess BTS mode, OML connecting to 127.0.0.1:3002 > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;33m<000b> trx_if.c:754 Open transceiver for phy0.0 > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m<0012> input/ipa.c:128 127.0.0.1:3002 connection done > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m<0012> input/ipaccess.c:705 received ID get from 1801/0/0 > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:229 O&M Get Attributes [0], Manufacturer Dependent State is unsupported by TRX. > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug! > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug! > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug! > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug! > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug! > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug! > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug! > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> oml.c:1055 ADM state already was Unlocked > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m<0012> input/ipa.c:128 127.0.0.1:3003 connection done > Dec 22 03:19:43 localhost osmo-bts-trx[25938]: #033[0;m<0012> input/ipaccess.c:705 received ID get from 1801/0/0 > Dec 22 03:19:45 localhost osmo-bts-trx[25938]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 03:19:47 localhost osmo-bts-trx[25938]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 03:19:49 localhost osmo-bts-trx[25938]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > > > > I just had the same stopping again, here is a snippet from that trx terminal......... > > Sat Dec 22 10:21:16 2018 DMAIN <0000> Transceiver.cpp:1016 [tid=3007554640] reduced latency: 3:9 > Sat Dec 22 10:21:17 2018 DMAIN <0000> Transceiver.cpp:1039 [tid=3007521872] ClockInterface: sending IND CLOCK 292365 > Sat Dec 22 10:21:17 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3007554640] new latency: 3:10 (underrun 3:292376 vs 1:292229) > Sat Dec 22 10:21:18 2018 DMAIN <0000> Transceiver.cpp:1039 [tid=3007521872] ClockInterface: sending IND CLOCK 292581 > Sat Dec 22 10:21:18 2018 DMAIN <0000> Transceiver.cpp:1016 [tid=3007554640] reduced latency: 2:10 > Sat Dec 22 10:21:19 2018 DMAIN <0000> Transceiver.cpp:1039 [tid=3007521872] ClockInterface: sending IND CLOCK 292797 > Sat Dec 22 10:21:19 2018 DMAIN <0000> Transceiver.cpp:1016 [tid=3007554640] reduced latency: 1:10 > Sat Dec 22 10:21:19 2018 DDEV <0002> UHDDevice.cpp:861 [tid=3007521872] No packet received, implementation timed-out > Sat Dec 22 10:21:19 2018 DDEV <0002> UHDDevice.cpp:865 [tid=3007521872] UHD: Receive timed out > Sat Dec 22 10:21:19 2018 DMAIN <0000> radioInterfaceResamp.cpp:178 [tid=3007521872] Receive error 0 > Sat Dec 22 10:21:19 2018 DMAIN <0000> Transceiver.cpp:908 [tid=3007521872] radio Interface receive failed, requesting stop. > Sat Dec 22 10:21:19 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3007554640] new latency: 1:11 (underrun 0:292830 vs 0:292819) > Sat Dec 22 10:21:19 2018 DDEV <0002> UHDDevice.cpp:861 [tid=3007521872] An internal receive buffer has filled at 3113.55 sec. > Sat Dec 22 10:21:20 2018 DDEV <0002> UHDDevice.cpp:1485 [tid=3007521872] Skipping buffer data: timestamp=1245558064 time_end=1245418309 > Sat Dec 22 10:21:20 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3007554640] new latency: 1:12 (underrun 3:292843 vs 2:292840) > Sat Dec 22 10:21:20 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3007554640] new latency: 1:13 (underrun 3:292854 vs 4:292853) > Sat Dec 22 10:21:20 2018 DMAIN <0000> osmo-trx.cpp:435 [tid=3025046000] Shutting down transceiver... > Sat Dec 22 10:21:20 2018 DMAIN <0000> Transceiver.cpp:307 [tid=3025046000] Stopping the transceiver > Sat Dec 22 10:21:20 2018 DMAIN <0000> Transceiver.cpp:320 [tid=3025046000] Stopping the device > Sat Dec 22 10:21:20 2018 DMAIN <0000> Transceiver.cpp:333 [tid=3025046000] Transceiver stopped > > This is syslog from right before this, I cut a few lines before the first osmo-bts-trx logging at 10:00:26 > > It complains a few times within that few seconds....then at 10:11:08 , 11, then stopping at 10:21:21 > > Dec 22 09:57:12 localhost dbus[779]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' > Dec 22 09:57:12 localhost systemd[1]: Started Network Manager Script Dispatcher Service. > Dec 22 09:57:12 localhost nm-dispatcher: req:1 'dhcp4-change' [eth0]: new request (2 scripts) > Dec 22 09:57:12 localhost nm-dispatcher: req:1 'dhcp4-change' [eth0]: start running ordered scripts... > Dec 22 10:00:01 localhost CRON[29739]: (root) CMD (/usr/lib/armbian/armbian-truncate-logs) > Dec 22 10:00:26 localhost osmo-bts-trx[25938]: #033[0;m#033[1;35m<0000> rsl.c:741 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK > Dec 22 10:00:26 localhost osmo-bts-trx[25938]: #033[0;m<0011> lapd_core.c:920 Store content res. (dl=0xb681b498) > Dec 22 10:00:27 localhost osmo-bts-trx[25938]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb681b498 state LAPD_STATE_MF_EST) > Dec 22 10:00:27 localhost osmo-bts-trx[25938]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb681b498 state LAPD_STATE_MF_EST) > Dec 22 10:00:28 localhost osmo-bts-trx[25938]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb681b498 state LAPD_STATE_MF_EST) > Dec 22 10:00:29 localhost osmo-bts-trx[25938]: #033[0;m#033[1;35m<0000> rsl.c:720 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK > Dec 22 10:05:01 localhost CRON[29783]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) > Dec 22 10:11:08 localhost osmo-bts-trx[25938]: #033[0;m#033[1;35m<0000> rsl.c:741 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK > Dec 22 10:11:11 localhost osmo-bts-trx[25938]: #033[0;m#033[1;35m<0000> rsl.c:720 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK > Dec 22 10:15:01 localhost CRON[29858]: (root) CMD (/usr/lib/armbian/armbian-truncate-logs) > Dec 22 10:15:02 localhost CRON[29859]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) > Dec 22 10:17:01 localhost CRON[29877]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) > Dec 22 10:21:21 localhost osmo-bts-trx[25938]: #033[0;m#033[1;36m<0001> bts.c:250 Shutting down BTS 0, Reason No clock from osmo-trx > Dec 22 10:21:24 localhost osmo-bts-trx[25938]: #033[0;mShutdown timer expired > Dec 22 10:21:24 localhost osmo-bts-trx[25938]: ((*)) > Dec 22 10:21:24 localhost osmo-bts-trx[25938]: | > Dec 22 10:21:24 localhost osmo-bts-trx[25938]: / \ OsmoBTS > Dec 22 10:21:24 localhost systemd[1]: osmo-bts-trx.service: Main process exited, code=exited, status=42/n/a > Dec 22 10:21:24 localhost systemd[1]: osmo-bts-trx.service: Unit entered failed state. > Dec 22 10:21:24 localhost systemd[1]: osmo-bts-trx.service: Failed with result 'exit-code'. > Dec 22 10:21:26 localhost systemd[1]: osmo-bts-trx.service: Service hold-off time over, scheduling restart. > Dec 22 10:21:26 localhost systemd[1]: Stopped Osmocom osmo-bts for osmo-trx. > Dec 22 10:21:26 localhost systemd[1]: Started Osmocom osmo-bts for osmo-trx. > Dec 22 10:21:26 localhost osmo-bts-trx[29913]: <0017> control_if.c:911 CTRL at 127.0.0.1 4238 > Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m<0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241 > Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m<0012> input/ipaccess.c:882 enabling ipaccess BTS mode, OML connecting to 127.0.0.1:3002 > Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:754 Open transceiver for phy0.0 > Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m<0012> input/ipa.c:128 127.0.0.1:3002 connection done > Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m<0012> input/ipaccess.c:705 received ID get from 1801/0/0 > Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:229 O&M Get Attributes [0], Manufacturer Dependent State is unsupported by TRX. > Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug! > Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug! > Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug! > Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug! > Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug! > Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug! > Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug! > Dec 22 10:21:26 localhost osmo-bts-trx[29913]: #033[0;m#033[1;36m<0001> oml.c:1055 ADM state already was Unlocked > Dec 22 10:21:27 localhost osmo-bts-trx[29913]: #033[0;m<0012> input/ipa.c:128 127.0.0.1:3003 connection done > Dec 22 10:21:27 localhost osmo-bts-trx[29913]: #033[0;m<0012> input/ipaccess.c:705 received ID get from 1801/0/0 > Dec 22 10:21:28 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:21:30 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:21:32 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:21:34 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:21:36 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:21:38 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:21:40 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:21:42 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:21:44 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:21:46 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:21:48 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:21:50 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:21:52 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:21:54 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:21:56 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:21:58 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:22:00 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:22:02 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:22:04 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:22:06 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:22:08 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:22:10 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:22:11 localhost dhclient[5395]: DHCPREQUEST of 192.168.1.170 on eth0 to 192.168.1.1 port 67 > Dec 22 10:22:11 localhost dhclient[5395]: DHCPACK of 192.168.1.170 from 192.168.1.1 > Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2789] dhcp4 (eth0): address 192.168.1.170 > Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2791] dhcp4 (eth0): plen 24 (255.255.255.0) > Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2792] dhcp4 (eth0): gateway 192.168.1.1 > Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2793] dhcp4 (eth0): server identifier 192.168.1.1 > Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2793] dhcp4 (eth0): lease time 3600 > Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2794] dhcp4 (eth0): hostname 'orangepizero' > Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2795] dhcp4 (eth0): nameserver '192.168.1.1' > Dec 22 10:22:11 localhost dbus[779]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' > Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2796] dhcp4 (eth0): domain name 'lan' > Dec 22 10:22:11 localhost NetworkManager[789]: [1545470531.2797] dhcp4 (eth0): state changed bound -> bound > Dec 22 10:22:11 localhost systemd[1]: Starting Network Manager Script Dispatcher Service... > Dec 22 10:22:11 localhost dhclient[5395]: bound to 192.168.1.170 -- renewal in 1598 seconds. > Dec 22 10:22:11 localhost dbus[779]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' > Dec 22 10:22:11 localhost systemd[1]: Started Network Manager Script Dispatcher Service. > Dec 22 10:22:11 localhost nm-dispatcher: req:1 'dhcp4-change' [eth0]: new request (2 scripts) > Dec 22 10:22:11 localhost nm-dispatcher: req:1 'dhcp4-change' [eth0]: start running ordered scripts... > Dec 22 10:22:12 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:22:14 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:22:16 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:22:18 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:22:20 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > Dec 22 10:22:22 localhost osmo-bts-trx[29913]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) > > > Then, as I restart trx-uhd again, ( by kbd uparrow ) carrier comes back and phone registers within a few seconds..... > > > > I see nothing upsetting in syslog that could explain cpu outage, besides, this is a 4-core Orange Pi Zero, I do not however know what quirks > > in Armbian Linux could lock out processing, when total load is 95% or so out of 400% ( i.e. 75% idle ) > > If there is anything I could do to bring clarity, please suggest.... > > Regards, > > Gullik > > > >> On 2018-12-22 10:42, Harald Welte wrote: >>> On Sat, Dec 22, 2018 at 10:00:50AM +0100, Gullik Webjorn wrote: >>> At 3 am the trx stopped again. This time it exited (itself) after logging >>> large amounts of packet loss, >> The interesting question is: Was there some kind of cron job or other activity >> running at 3am on that system, which could cause a system load high enough to >> make the flow between B100, kernel USB stack, libusb, UHD and osmo-trx-uhd >> interrupt? > I will investigate as I possibly can >> >> Something like this is likely the root cause of the problem. >> >> Sure, osmo-trx could "plaster around" it by having a more elegant recovery >> mechanism, but failing fast due to exit and letting osmo-trx-uhd respawn >> (normally executed via systemd) isn't actually all too bad. >> >> What's definitely a real problem that needs immediate fixing is if we >> somehow get stack with osmo-trx continuing to run, but failing to >> transmit a valid signal wihout exit + respawn. > That HAS happened for me, with the screen filled with logging of packet loss, pointing at line 1319 in > uhd_device::recv_async_msg() > >> >> Regards, >> Harald -------------- next part -------------- An HTML attachment was scrubbed... URL: From gullik.webjorn at corevalue.se Sat Dec 22 13:12:43 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Sat, 22 Dec 2018 14:12:43 +0100 Subject: Where rxgain and power Message-ID: <74fa621e-25c9-b61f-6915-96b530ce6d38@corevalue.se> Hi, Where am I supposed to set initial rx-gain and tx-power ( tx-attenuation) ? I see no suitable keywords in the BTS ( bts-uhd ) nor in the BSC. btw, sdr is Ettus B100 driven by uhd-trx, and shows 10 dB attenuation. Regards, Gullik From gullik.webjorn at corevalue.se Sat Dec 22 13:58:41 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Sat, 22 Dec 2018 14:58:41 +0100 Subject: Where rxgain and power In-Reply-To: <74fa621e-25c9-b61f-6915-96b530ce6d38@corevalue.se> References: <74fa621e-25c9-b61f-6915-96b530ce6d38@corevalue.se> Message-ID: <567c05e7-1e70-835d-cc53-2ec2822459e3@corevalue.se> Found it, in the BSC, bts 0, trx 0, max_power_red Gullik On 2018-12-22 14:12, Gullik Webjorn wrote: > Hi, > > Where am I supposed to set initial rx-gain and tx-power ( > tx-attenuation) ? > > I see no suitable keywords in the BTS ( bts-uhd ) nor in the BSC. > > btw, sdr is Ettus B100 driven by uhd-trx, and shows 10 dB attenuation. > > Regards, > > Gullik > From gullik.webjorn at corevalue.se Sat Dec 22 18:38:52 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Sat, 22 Dec 2018 19:38:52 +0100 Subject: osmo-uhd-trx In-Reply-To: <20181222094209.GR2961@nataraja> References: <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> <86598f32-b8fe-9e9d-22a9-5ec7348dd359@corevalue.se> <575d4103-bfb6-c269-9b03-55727e523afa@corevalue.se> <4c1991aa-3e36-a9ed-c004-c4181aed9690@corevalue.se> <2af53f98-3303-ccb5-50f4-4f27a53866a4@corevalue.se> <20181222094209.GR2961@nataraja> Message-ID: <01818d0f-3b75-f874-f569-ab4026115f4f@corevalue.se> > What's definitely a real problem that needs immediate fixing is if we > somehow get stack with osmo-trx continuing to run, but failing to > transmit a valid signal wihout exit + respawn. > > Regards, > Harald Well, here a footprint from the trx-uhd console. I interrupted the process with a ^c at the end, carrier was lost, when restarted by a kbd ^ everything went back to normal and MS associated without manual intervention. Sorry to clutter the list with long logs, hoping you might spot something....... Gullik Sat Dec 22 19:22:40 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3008439376] new latency: 0:204923 (underrun 0:42138 vs 3:42136) Sat Dec 22 19:22:40 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.1 sec. Sat Dec 22 19:22:40 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.1 sec. Sat Dec 22 19:22:40 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.1 sec. Sat Dec 22 19:22:40 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.1 sec. Sat Dec 22 19:22:40 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.1 sec. Sat Dec 22 19:22:40 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3008439376] new latency: 0:204924 (underrun 5:42149 vs 0:42148) Sat Dec 22 19:22:40 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.1 sec. Sat Dec 22 19:22:40 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.1 sec. Sat Dec 22 19:22:40 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.2 sec. Sat Dec 22 19:22:40 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.2 sec. Sat Dec 22 19:22:40 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.2 sec. Sat Dec 22 19:22:40 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.2 sec. Sat Dec 22 19:22:40 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3008439376] new latency: 0:204925 (underrun 2:42161 vs 5:42159) Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.2 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.2 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.2 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.2 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.2 sec. Sat Dec 22 19:22:41 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3008439376] new latency: 0:204926 (underrun 7:42172 vs 2:42171) Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.3 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.3 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.3 sec. Sat Dec 22 19:22:41 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3008439376] new latency: 0:204927 (underrun 3:42184 vs 7:42182) Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.3 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.3 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.3 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.3 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.3 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.3 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.3 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.3 sec. Sat Dec 22 19:22:41 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3008439376] new latency: 0:204928 (underrun 5:42196 vs 3:42194) Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.4 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.4 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.4 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.4 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.4 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.4 sec. Sat Dec 22 19:22:41 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3008439376] new latency: 0:204929 (underrun 6:42208 vs 5:42206) Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.4 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.4 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.4 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.5 sec. Sat Dec 22 19:22:41 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3008439376] new latency: 0:204930 (underrun 1:42220 vs 6:42218) Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.5 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.5 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.5 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.5 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.5 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.5 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.5 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.5 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.5 sec. Sat Dec 22 19:22:41 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3008439376] new latency: 0:204931 (underrun 3:42232 vs 1:42230) Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.5 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.5 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.6 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.6 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.6 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.6 sec. Sat Dec 22 19:22:41 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3008439376] new latency: 0:204932 (underrun 2:42244 vs 3:42242) Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.6 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.6 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.6 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.6 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.6 sec. Sat Dec 22 19:22:41 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3008439376] new latency: 0:204933 (underrun 1:42256 vs 2:42254) Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.6 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.6 sec. Sat Dec 22 19:22:41 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 12858.6 sec. ^Csignal 2 received shutting down Sat Dec 22 19:22:41 2018 DMAIN <0000> osmo-trx.cpp:435 [tid=3025398256] Shutting down transceiver... Sat Dec 22 19:22:41 2018 DMAIN <0000> Transceiver.cpp:307 [tid=3025398256] Stopping the transceiver Sat Dec 22 19:22:41 2018 DMAIN <0000> Transceiver.cpp:320 [tid=3025398256] Stopping the device Sat Dec 22 19:22:41 2018 DMAIN <0000> Transceiver.cpp:333 [tid=3025398256] Transceiver stopped root at orangepizero:~# syslog at the time..... Dec 22 19:15:01 localhost CRON[3654]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Dec 22 19:17:01 localhost CRON[3677]: (root) CMD (?? cd / && run-parts --report /etc/cron.hourly) Dec 22 19:22:21 localhost osmo-bts-trx[1576]: #033[0;m<0007> l1sap.c:510 242502/182/00/48/18 Invalid condition detected: Frame difference is 242502-242403=99 > 1! Dec 22 19:22:42 localhost osmo-bts-trx[1576]: #033[0;m#033[1;36m<0001> bts.c:250 Shutting down BTS 0, Reason No clock from osmo-trx Dec 22 19:22:45 localhost osmo-bts-trx[1576]: #033[0;mShutdown timer expired Dec 22 19:22:45 localhost osmo-bts-trx[1576]: ((*)) Dec 22 19:22:45 localhost osmo-bts-trx[1576]:?? | Dec 22 19:22:45 localhost osmo-bts-trx[1576]:? / \ OsmoBTS Dec 22 19:22:45 localhost systemd[1]: osmo-bts-trx.service: Main process exited, code=exited, status=42/n/a Dec 22 19:22:45 localhost systemd[1]: osmo-bts-trx.service: Unit entered failed state. Dec 22 19:22:45 localhost systemd[1]: osmo-bts-trx.service: Failed with result 'exit-code'. Dec 22 19:22:47 localhost systemd[1]: osmo-bts-trx.service: Service hold-off time over, scheduling restart. Dec 22 19:22:47 localhost systemd[1]: Stopped Osmocom osmo-bts for osmo-trx. Dec 22 19:22:47 localhost systemd[1]: Started Osmocom osmo-bts for osmo-trx. Dec 22 19:22:47 localhost osmo-bts-trx[3726]: <0017> control_if.c:911 CTRL at 127.0.0.1 4238 Dec 22 19:22:47 localhost osmo-bts-trx[3726]: #033[0;m<0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241 Dec 22 19:22:47 localhost osmo-bts-trx[3726]: #033[0;m<0012> input/ipaccess.c:882 enabling ipaccess BTS mode, OML connecting to 127.0.0.1:3002 Dec 22 19:22:47 localhost osmo-bts-trx[3726]: #033[0;m#033[1;33m<000b> trx_if.c:754 Open transceiver for phy0.0 Dec 22 19:22:47 localhost osmo-bts-trx[3726]: #033[0;m<0012> input/ipa.c:128 127.0.0.1:3002 connection done Dec 22 19:22:47 localhost osmo-bts-trx[3726]: #033[0;m<0012> input/ipaccess.c:705 received ID get from 1801/0/0 Dec 22 19:22:47 localhost osmo-bts-trx[3726]: #033[0;m#033[1;36m<0001> oml.c:229 O&M Get Attributes [0], Manufacturer Dependent State is unsupported by TRX. Dec 22 19:22:47 localhost osmo-bts-trx[3726]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 19:22:47 localhost osmo-bts-trx[3726]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 19:22:47 localhost osmo-bts-trx[3726]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 19:22:47 localhost osmo-bts-trx[3726]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 19:22:47 localhost osmo-bts-trx[3726]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 19:22:47 localhost osmo-bts-trx[3726]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 19:22:47 localhost osmo-bts-trx[3726]: #033[0;m#033[1;36m<0001> oml.c:681 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug! Dec 22 19:22:47 localhost osmo-bts-trx[3726]: #033[0;m#033[1;36m<0001> oml.c:1055 ADM state already was Unlocked Dec 22 19:22:48 localhost osmo-bts-trx[3726]: #033[0;m<0012> input/ipa.c:128 127.0.0.1:3003 connection done Dec 22 19:22:48 localhost osmo-bts-trx[3726]: #033[0;m<0012> input/ipaccess.c:705 received ID get from 1801/0/0 Dec 22 19:22:49 localhost osmo-bts-trx[3726]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 19:22:51 localhost osmo-bts-trx[3726]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 19:22:53 localhost osmo-bts-trx[3726]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 19:22:55 localhost osmo-bts-trx[3726]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 22 19:22:57 localhost osmo-bts-trx[3726]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) From dechaoforever at qq.com Sun Dec 23 05:15:27 2018 From: dechaoforever at qq.com (=?gb18030?B?y67UxtauvOQ=?=) Date: Sun, 23 Dec 2018 13:15:27 +0800 Subject: How to enable AUTHENTICATION procedure in osmo-nitb? Message-ID: Hi ALL. Recently I setup osmo-nitb on my laptop, by using it I can send SMS and make a call between 2 phones successfully. The solution is LimeSDR + osmo-trx-lms + osmo-bts-trx + osmo-nitb. But when I check the logs of osmo-nitb, cannot find AUTHENTICATION message. How to trigger AUTHENTICATION ? These days I went through the osmonitb-usermanual.pdf but still cannot get it. I will be appreciated if you can help me. Here is the LOGS, running-config and test subscriber info. ============================LOGS============================ ezio at mylab:~$ osmo-nitb -c ~/.osmocom/osmo-nitb.cfg -l ~/.osmocom/hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM DB: Database initialized. DB: Database prepared. <0005> abis_nm.c:1601 Get Attr (bts=0) <0005> abis_nm.c:1601 Get Attr (bts=0) <0005> abis_nm.c:381 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=unknown 0x0 <0005> abis_nm.c:1938 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART <0005> abis_nm.c:381 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1619 Set BTS Attr (bts=0) <0005> abis_nm.c:1938 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART <0005> abis_nm.c:381 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=GPRS-CELL(f1) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=Unlocked <0005> abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:550 OC=BTS(01) INST=(00,ff,ff) Get Attributes Response for BTS0 <0005> abis_nm.c:463 BTS0 Get Attributes Response Info: 70 bytes total with 0 unreported attributes <0005> abis_nm.c:507 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. <0005> abis_nm.c:507 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:507 BTS0 feature 'CBCH' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:573 BTS0: ARI reported sw[0/2]: osmobts is 0.8.1.192-fc88 <0005> abis_nm.c:446 BTS0 reported variant: omso-bts-trx <0005> abis_nm.c:550 OC=BTS(01) INST=(00,ff,ff) Get Attributes Response for BTS0 <0005> abis_nm.c:463 BTS0 Get Attributes Response Info: 32 bytes total with 1 unreported attributes <0005> abis_nm.c:468 BTS0 Attribute Manufacturer Dependent State is unreported <0005> abis_nm.c:573 BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown <0005> abis_nm.c:771 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Opstart ACK <0005> abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) ADM=Unlocked <0004> acc_ramp.c:162 (bts=0,trx=0) ACC RAMP: administrative state Unlocked -> Unlocked <0004> acc_ramp.c:166 (bts=0,trx=0) ACC RAMP: operational state NULL -> Disabled <0004> acc_ramp.c:175 (bts=0,trx=0) ACC RAMP: ignoring state change because RSL link is down <0005> abis_nm.c:1938 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=OK(ff) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:1636 Set TRX Attr (bts=0,trx=0) <0005> abis_nm.c:1938 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:1938 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:2757 (bts=0,trx=0) IPA RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=0) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=1) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=2) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,02) Sending OPSTART <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=3) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,03) Sending OPSTART <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=4) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,04) Sending OPSTART <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=5) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,05) Sending OPSTART <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=6) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,06) Sending OPSTART <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=7) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,07) Sending OPSTART <0005> abis_nm.c:381 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=BTS(01) INST=(00,ff,ff) Opstart ACK <0005> abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0004> acc_ramp.c:162 (bts=0,trx=0) ACC RAMP: administrative state Unlocked -> Unlocked <0004> acc_ramp.c:166 (bts=0,trx=0) ACC RAMP: operational state Disabled -> Enabled <0004> acc_ramp.c:175 (bts=0,trx=0) ACC RAMP: ignoring state change because RSL link is down <0005> abis_nm.c:771 OC=RADIO-CARRIER(02) INST=(00,00,ff) Opstart ACK <0005> abis_nm.c:779 OC=RADIO-CARRIER(02) INST=(00,00,ff) Set Radio Carrier Attributes ACK <0004> acc_ramp.c:162 (bts=0,trx=0) ACC RAMP: administrative state Unlocked -> Unlocked <0004> acc_ramp.c:166 (bts=0,trx=0) ACC RAMP: operational state Enabled -> Enabled <0004> acc_ramp.c:175 (bts=0,trx=0) ACC RAMP: ignoring state change because RSL link is down <0005> abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=RADIO-CARRIER(02) INST=(00,00,ff) Opstart ACK <0005> abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Opstart ACK <0005> abis_nm.c:2599 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xe1): RSL CONNECT ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,00) Set Channel Attributes ACK <0004> bsc_init.c:312 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 514 using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63 <0003> system_information.c:637 Serving cell: 514 <0003> bsc_init.c:108 SI1: 55 06 19 8f 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e5 04 00 2b <0003> bsc_init.c:108 SI2: 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00 <0003> bsc_init.c:110 SI2bis: OFF <0003> bsc_init.c:110 SI2ter: OFF <0003> bsc_init.c:110 SI2quater: OFF <0003> bsc_init.c:108 SI3: 49 06 1b 00 00 00 f1 10 00 01 49 03 05 27 47 40 e5 04 00 29 2b 2b 2b <0003> bsc_init.c:108 SI4: 31 06 1c 00 f1 10 00 01 47 40 e5 04 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0003> bsc_init.c:108 SI5: 49 06 1d 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b <0003> bsc_init.c:110 SI5bis: OFF <0003> bsc_init.c:110 SI5ter: OFF <0003> bsc_init.c:108 SI6: 2d 06 1e 00 00 00 f1 10 00 01 27 ff 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,00) Opstart ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,01) Set Channel Attributes ACK <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,01) Opstart ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,02) Set Channel Attributes ACK <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,02) Opstart ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,03) Set Channel Attributes ACK <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,03) Opstart ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,04) Set Channel Attributes ACK <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,04) Opstart ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,05) Set Channel Attributes ACK <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,05) Opstart ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,06) Set Channel Attributes ACK <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,06) Opstart ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,07) Set Channel Attributes ACK <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,07) Opstart ACK <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: Location updating (ra=0x0b, neci=0x01, chreq_reason=0x03) <0000> chan_alloc.c:353 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH <0004> abis_rsl.c:1924 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(514) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0b ta=0 <0004> abis_rsl.c:595 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1603 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 <0002> gsm_04_08.c:1407 LOCATION UPDATING REQUEST: MI(TMSI)=792947918 type=NORMAL <0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS. <0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS. <- Can't find any subscriber for this ID <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 <0002> gsm_04_08.c:565 IDENTITY RESPONSE: MI(IMSI)=46001********** <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 <0002> gsm_04_08.c:565 IDENTITY RESPONSE: MI(IMEI)=358634076823520 <0002> gsm_04_08.c:522 -> LOCATION UPDATE ACCEPT <0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x02 to MS. <0002> gsm_04_08.c:892 -> MM INFO <0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x32 to MS. <0002> gsm_subscriber.c:341 Subscriber 46001********** ATTACHED LAC=1 <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 <0002> gsm_04_08.c:1421 TMSI Reallocation Completed. Subscriber: 46001********** <0002> gsm_04_08.c:323 Location Updating completed for 46001********** <0000> chan_alloc.c:487 (bts=0,trx=0,ts=0,ss=0) starting release sequence <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE REQUESTED <0003> gsm_04_08_utils.c:251 Sending Channel Release: Chan: Number: 0 Type: 1 <0004> abis_rsl.c:777 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 RELEASE INDICATION <0004> abis_rsl.c:1731 (bts=0,trx=0,ts=0,ss=0) T3111 expired: releasing RF Channel <0004> abis_rsl.c:869 (bts=0,trx=0,ts=0,ss=0) RF Channel Release <0004> abis_rsl.c:939 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state RELEASE REQUESTED -> NONE <0000> chan_alloc.c:612 (bts=0) channel load average is 3.03% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: other (ra=0x1e, neci=0x01, chreq_reason=0x04) <0000> chan_alloc.c:353 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH <0004> abis_rsl.c:1924 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(514) SS(0) lctype SDCCH r=OTHER ra=0x1e ta=0 <0004> abis_rsl.c:595 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1603 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 <0002> gsm_04_08.c:1016 <- CM SERVICE REQUEST serv_type=0x04 MI(TMSI)=1532175428 <0002> gsm_04_08_utils.c:667 -> CM SERVICE ACK <0000> chan_alloc.c:612 (bts=0) channel load average is 0.10% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=3 ESTABLISH INDICATION <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=3 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=9 <0001> transaction.c:71 subscr=0x1728b00, net=0x15a78c0 <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=3 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=9 <0000> chan_alloc.c:487 (bts=0,trx=0,ts=0,ss=0) starting release sequence <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE REQUESTED <0000> abis_rsl.c:1201 (bts=0,trx=0,ts=0,ss=0) RSL RLL RELEASE REQ (link_id=0x03, reason=1) <0003> gsm_04_08_utils.c:251 Sending Channel Release: Chan: Number: 0 Type: 1 <0004> abis_rsl.c:777 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=3 RELEASE CONFIRMATION <0004> abis_rsl.c:2098 (bts=0,trx=0,ts=0,ss=0) waiting for SAPI=0 to be released. <0002> gsm_subscriber.c:190 Subscriber 46001********** not paged yet. <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 RELEASE INDICATION <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: other (ra=0x1f, neci=0x01, chreq_reason=0x04) <0000> chan_alloc.c:353 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=1 as SDCCH <0004> abis_rsl.c:1924 (bts=0,trx=0,ts=0,ss=1) Activating ARFCN(514) SS(1) lctype SDCCH r=OTHER ra=0x1f ta=0 <0004> abis_rsl.c:595 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=1) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1603 (bts=0,trx=0,ts=0,ss=1) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=1) state ACTIVATION REQUESTED -> ACTIVE <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=0 ESTABLISH INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=6 <0003> gsm_04_08.c:1462 PAGING RESPONSE: MI(TMSI)=1532175428 <0003> gsm_04_08.c:1495 <- Channel was requested by 46001********** <0001> transaction.c:71 subscr=0x175ae00, net=0x15a78c0 <0000> abis_rsl.c:1159 (bts=0,trx=0,ts=0,ss=1) RSL RLL ESTABLISH REQ (link_id=0x03) <0004> abis_rsl.c:1731 (bts=0,trx=0,ts=0,ss=0) T3111 expired: releasing RF Channel <0004> abis_rsl.c:869 (bts=0,trx=0,ts=0,ss=0) RF Channel Release <0004> abis_rsl.c:939 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state RELEASE REQUESTED -> NONE <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=3 ESTABLISH CONFIRM <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=3 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=9 <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=3 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=9 <0000> chan_alloc.c:487 (bts=0,trx=0,ts=0,ss=1) starting release sequence <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=1) state ACTIVE -> RELEASE REQUESTED <0000> abis_rsl.c:1201 (bts=0,trx=0,ts=0,ss=1) RSL RLL RELEASE REQ (link_id=0x03, reason=1) <0003> gsm_04_08_utils.c:251 Sending Channel Release: Chan: Number: 1 Type: 1 <0004> abis_rsl.c:777 (bts=0,trx=0,ts=0,ss=1) DEACTivate SACCH CMD <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=3 RELEASE CONFIRMATION <0004> abis_rsl.c:2098 (bts=0,trx=0,ts=0,ss=1) waiting for SAPI=0 to be released. <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=0 DATA INDICATION <0004> bsc_api.c:686 Got data in non active state(RELEASE REQUESTED), discarding. <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=0 RELEASE INDICATION <0004> abis_rsl.c:1731 (bts=0,trx=0,ts=0,ss=1) T3111 expired: releasing RF Channel <0004> abis_rsl.c:869 (bts=0,trx=0,ts=0,ss=1) RF Channel Release <0004> abis_rsl.c:939 (bts=0,trx=0,ts=0,ss=1) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=1) state RELEASE REQUESTED -> NONE <0000> chan_alloc.c:612 (bts=0) channel load average is 5.12% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: call re-establishment (ra=0x4f, neci=0x01, chreq_reason=0x02) <0000> chan_alloc.c:353 (bts=0,trx=0,ts=2,pchan=TCH/F) Allocating lchan=0 as TCH_F <0004> abis_rsl.c:1924 (bts=0,trx=0,ts=2,ss=0) Activating ARFCN(514) SS(0) lctype TCH_F r=CALL ra=0x4f ta=0 <0004> abis_rsl.c:595 (bts=0,trx=0,ts=2,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=2,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1603 (bts=0,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=2,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 ESTABLISH INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 <0002> gsm_04_08.c:1016 <- CM SERVICE REQUEST serv_type=0x01 MI(TMSI)=1532175428 <0002> gsm_04_08_utils.c:667 -> CM SERVICE ACK <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=3 <0001> gsm_04_08.c:3894 (bts 0 trx 0 ts 2 ti 8 sub 25332) Received 'SETUP' from MS in state 0 (NULL) <0001> gsm_04_08.c:3899 Unknown transaction ID 8, creating new trans. <0001> transaction.c:71 subscr=0x172d9a0, net=0x15a78c0 <0001> gsm_04_08.c:1623 new state NULL -> INITIATED <0001> gsm_04_08.c:2302 Subscriber 46001********** (25332) sends SETUP to 25332 <0001> gsm_04_08.c:1685 (bts 0 trx 0 ts 2 ti 8 sub 25332) Sending 'MNCC_SETUP_IND' to MNCC. <0001> gsm_04_08.c:3796 (bts 0 trx 0 ts 2 ti 08 sub 25332) Received 'MNCC_CALL_PROC_REQ' from MNCC in state 1 (INITIATED) <0001> gsm_04_08.c:1623 new state INITIATED -> MO_CALL_PROC <0001> gsm_04_08.c:138 (bts 0 trx 0 ts 2 ti 80) Sending 'CALL_PROC' to MS. <0001> gsm_04_08.c:3796 (bts 0 trx 0 ts 2 ti 08 sub 25332) Received 'MNCC_LCHAN_MODIFY' from MNCC in state 3 (MO_CALL_PROC) <0003> gsm_04_08_utils.c:517 -> CHANNEL MODE MODIFY mode=0x01 <0001> transaction.c:71 subscr=0x172d9a0, net=0x15a78c0 <0001> gsm_04_08.c:3796 (bts 0 trx 0 ts 2 ti ff sub 25332) Received 'MNCC_SETUP_REQ' from MNCC in state 0 (NULL) <0001> gsm_04_08.c:2226 starting timer T303 with 30 seconds <0001> gsm_04_08.c:1623 new state NULL -> CALL_PRESENT <0001> gsm_04_08.c:138 (bts 0 trx 0 ts 2 ti 00) Sending 'SETUP' to MS. <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0003> gsm_04_08_utils.c:542 CHANNEL MODE MODIFY ACK <0004> abis_rsl.c:2344 (bts=0,trx=0,ts=2,ss=0) IPAC_BIND speech_mode=0x10 RTP_PAYLOAD=3 <0003> osmo_msc.c:76 MSC assign complete (do nothing). <0004> abis_rsl.c:1624 (bts=0,trx=0,ts=2,ss=0) CHANNEL MODE MODIFY ACK <0004> abis_rsl.c:2525 (bts=0,trx=0,ts=2,ss=0) IPAC_CRCX_ACK LOCAL_IP=127.0.0.1 LOCAL_PORT=16384 CON_ID=0 <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=3 <0001> gsm_04_08.c:3894 (bts 0 trx 0 ts 2 ti 0 sub 25332) Received 'RELEASE_COMPL' from MS in state 6 (CALL_PRESENT) <0001> gsm_04_08.c:1665 stopping pending timer T303 <0001> gsm_04_08.c:1685 (bts 0 trx 0 ts 2 ti 0 sub 25332) Sending 'MNCC_REJ_IND' to MNCC. <0001> gsm_04_08.c:3796 (bts 0 trx 0 ts 2 ti 08 sub 25332) Received 'MNCC_REL_REQ' from MNCC in state 3 (MO_CALL_PROC) <0001> gsm_04_08.c:2226 starting timer T308 with 10 seconds <0001> gsm_04_08.c:1623 new state MO_CALL_PROC -> RELEASE_REQ <0001> gsm_04_08.c:138 (bts 0 trx 0 ts 2 ti 80) Sending 'RELEASE' to MS. <0001> gsm_04_08.c:1623 new state CALL_PRESENT -> NULL <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=3 <0001> gsm_04_08.c:3894 (bts 0 trx 0 ts 2 ti 8 sub 25332) Received 'RELEASE_COMPL' from MS in state 19 (RELEASE_REQ) <0001> gsm_04_08.c:1665 stopping pending timer T308 <0001> gsm_04_08.c:1685 (bts 0 trx 0 ts 2 ti 8 sub 25332) Sending 'MNCC_REL_CNF' to MNCC. <0001> gsm_04_08.c:1623 new state RELEASE_REQ -> NULL <0000> chan_alloc.c:487 (bts=0,trx=0,ts=2,ss=0) starting release sequence <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=2,ss=0) state ACTIVE -> RELEASE REQUESTED <0003> gsm_04_08_utils.c:251 Sending Channel Release: Chan: Number: 0 Type: 2 <0004> abis_rsl.c:777 (bts=0,trx=0,ts=2,ss=0) DEACTivate SACCH CMD <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 RELEASE INDICATION <0004> abis_rsl.c:1731 (bts=0,trx=0,ts=2,ss=0) T3111 expired: releasing RF Channel <0004> abis_rsl.c:869 (bts=0,trx=0,ts=2,ss=0) RF Channel Release <0004> abis_rsl.c:2544 (bts=0,trx=0,ts=2,ss=0) IPAC_DLCX_IND <0004> abis_rsl.c:939 (bts=0,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=2,ss=0) state RELEASE REQUESTED -> NONE <0000> chan_alloc.c:612 (bts=0) channel load average is 1.24% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds ============================running-config============================ OpenBSC# sh run Current configuration: ! password foo ! log stderr logging filter all 1 logging color 1 logging print category 0 logging timestamp 0 logging print file 1 % Invalid log level 0 for rll % Invalid log level 0 for cc % Invalid log level 0 for mm % Invalid log level 0 for rr % Invalid log level 0 for rsl % Invalid log level 0 for nm logging level mncc notice logging level pag notice logging level meas notice logging level sccp notice logging level msc notice logging level mgcp notice logging level ho notice logging level db notice logging level ref notice logging level gprs debug logging level ns info logging level bssgp debug logging level llc debug logging level sndcp debug logging level nat notice logging level ctrl notice logging level smpp debug logging level filter debug logging level ranap debug logging level sua debug logging level pcu debug logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice logging level lstats notice logging level lgsup notice logging level loap notice logging level lss7 notice logging level lsccp notice logging level lsua notice logging level lm3ua notice logging level lmgcp notice logging level ljibuf notice ! stats interval 5 ! line vty no login ! e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive network network country code 001 mobile network code 01 short name OpenBSC long name OpenBSC auth policy token authorized-regexp .* location updating reject cause 13 encryption a5 0 neci 1 paging any use tch 0 rrlp mode none mm info 1 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 dyn_ts_allow_tch_f 0 subscriber-keep-in-ram 0 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 periodic location update 30 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 no access-control-class-ramping access-control-class-ramping-step-interval dynamic access-control-class-ramping-step-size 1 early-classmark-sending forbidden early-classmark-sending-3g allowed ip.access unit_id 1801 0 oml ip.access stream_id 255 line 0 neighbor-list mode automatic codec-support fr gprs mode none no force-combined-si trx 0 rf_locked 0 arfcn 514 nominal power 23 max_power_red 20 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config SDCCH8 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 mncc-int default-codec tch-f fr default-codec tch-h hr nitb subscriber-create-on-demand assign-tmsi end ============================test subscriber info============================ OpenBSC# sh sub id 4 ID: 4, Authorized: 1 Extension: 25332 LAC: 1/0x1 IMSI: 46001********** TMSI: 5B532444 A3A8 algorithm id: 4 A3A8 Ki: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f Expiration Time: Sun, 23 Dec 2018 13:53:49 +0800 Paging: not paging Requests: 0 Use count: 1 OpenBSC# =========================== THANKS A LOT! -------------- next part -------------- An HTML attachment was scrubbed... URL: From domi at tomcsanyi.net Sun Dec 23 07:00:55 2018 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Sun, 23 Dec 2018 08:00:55 +0100 (CET) Subject: How to enable AUTHENTICATION procedure in osmo-nitb? In-Reply-To: References: Message-ID: <801AFFEE-2784-4CC1-8115-3286EB8C17A6@tomcsanyi.net> Hello, I would start by changing the encryption type to a5 1 ;) Cheers, Domi 2018. dec. 23. d?tummal, 6:23 id?pontban ???? ?rta: > Hi ALL. > Recently I setup osmo-nitb on my laptop, by using it I can send SMS and make a call between 2 phones successfully. > The solution is LimeSDR + osmo-trx-lms + osmo-bts-trx + osmo-nitb. > But when I check the logs of osmo-nitb, cannot find AUTHENTICATION message. > How to trigger AUTHENTICATION ? These days I went through the osmonitb-usermanual.pdf but still cannot get it. > I will be appreciated if you can help me. > Here is the LOGS, running-config and test subscriber info. > ============================LOGS============================ > ezio at mylab:~$ osmo-nitb -c ~/.osmocom/osmo-nitb.cfg -l ~/.osmocom/hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM > DB: Database initialized. > DB: Database prepared. > <0005> abis_nm.c:1601 Get Attr (bts=0) > <0005> abis_nm.c:1601 Get Attr (bts=0) > <0005> abis_nm.c:381 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=unknown 0x0 > <0005> abis_nm.c:1938 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART > <0005> abis_nm.c:381 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) ADM=unknown 0x0 > <0005> abis_nm.c:1619 Set BTS Attr (bts=0) > <0005> abis_nm.c:1938 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART > <0005> abis_nm.c:381 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) ADM=unknown 0x0 > <0005> abis_nm.c:381 OC=GPRS-CELL(f1) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) ADM=unknown 0x0 > <0005> abis_nm.c:381 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) ADM=unknown 0x0 > <0005> abis_nm.c:381 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) ADM=unknown 0x0 > <0005> abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=Unlocked > <0005> abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 > <0005> abis_nm.c:550 OC=BTS(01) INST=(00,ff,ff) Get Attributes Response for BTS0 > <0005> abis_nm.c:463 BTS0 Get Attributes Response Info: 70 bytes total with 0 unreported attributes > <0005> abis_nm.c:507 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. > <0005> abis_nm.c:507 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. > <0005> abis_nm.c:507 BTS0 feature 'CBCH' reported via OML does not match statically set feature: 1 != 0. Please fix. > <0005> abis_nm.c:573 BTS0: ARI reported sw[0/2]: osmobts is 0.8.1.192-fc88 > <0005> abis_nm.c:446 BTS0 reported variant: omso-bts-trx > <0005> abis_nm.c:550 OC=BTS(01) INST=(00,ff,ff) Get Attributes Response for BTS0 > <0005> abis_nm.c:463 BTS0 Get Attributes Response Info: 32 bytes total with 1 unreported attributes > <0005> abis_nm.c:468 BTS0 Attribute Manufacturer Dependent State is unreported > <0005> abis_nm.c:573 BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown > <0005> abis_nm.c:771 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Opstart ACK > <0005> abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) ADM=Unlocked > <0004> acc_ramp.c:162 (bts=0,trx=0) ACC RAMP: administrative state Unlocked -> Unlocked > <0004> acc_ramp.c:166 (bts=0,trx=0) ACC RAMP: operational state NULL -> Disabled > <0004> acc_ramp.c:175 (bts=0,trx=0) ACC RAMP: ignoring state change because RSL link is down > <0005> abis_nm.c:1938 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART > <0005> abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=OK(ff) ADM=unknown 0x0 > <0005> abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) Software Activated Report > <0005> abis_nm.c:1636 Set TRX Attr (bts=0,trx=0) > <0005> abis_nm.c:1938 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART > <0005> abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report > <0005> abis_nm.c:1938 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Sending OPSTART > <0005> abis_nm.c:2757 (bts=0,trx=0) IPA RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 > <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=0) > <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 > <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=1) > <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 > <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=2) > <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,02) Sending OPSTART > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 > <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=3) > <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,03) Sending OPSTART > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 > <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=4) > <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,04) Sending OPSTART > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 > <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=5) > <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,05) Sending OPSTART > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 > <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=6) > <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,06) Sending OPSTART > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 > <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=7) > <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,07) Sending OPSTART > <0005> abis_nm.c:381 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:381 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked > <0005> abis_nm.c:771 OC=BTS(01) INST=(00,ff,ff) Opstart ACK > <0005> abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked > <0004> acc_ramp.c:162 (bts=0,trx=0) ACC RAMP: administrative state Unlocked -> Unlocked > <0004> acc_ramp.c:166 (bts=0,trx=0) ACC RAMP: operational state Disabled -> Enabled > <0004> acc_ramp.c:175 (bts=0,trx=0) ACC RAMP: ignoring state change because RSL link is down > <0005> abis_nm.c:771 OC=RADIO-CARRIER(02) INST=(00,00,ff) Opstart ACK > <0005> abis_nm.c:779 OC=RADIO-CARRIER(02) INST=(00,00,ff) Set Radio Carrier Attributes ACK > <0004> acc_ramp.c:162 (bts=0,trx=0) ACC RAMP: administrative state Unlocked -> Unlocked > <0004> acc_ramp.c:166 (bts=0,trx=0) ACC RAMP: operational state Enabled -> Enabled > <0004> acc_ramp.c:175 (bts=0,trx=0) ACC RAMP: ignoring state change because RSL link is down > <0005> abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked > <0005> abis_nm.c:771 OC=RADIO-CARRIER(02) INST=(00,00,ff) Opstart ACK > <0005> abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=OK(ff) ADM=Unlocked > <0005> abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked > <0005> abis_nm.c:771 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Opstart ACK > <0005> abis_nm.c:2599 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xe1): RSL CONNECT ACK > <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,00) Set Channel Attributes ACK > <0004> bsc_init.c:312 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 514 using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63 > <0003> system_information.c:637 Serving cell: 514 > <0003> bsc_init.c:108 SI1: 55 06 19 8f 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e5 04 00 2b > <0003> bsc_init.c:108 SI2: 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00 > <0003> bsc_init.c:110 SI2bis: OFF > <0003> bsc_init.c:110 SI2ter: OFF > <0003> bsc_init.c:110 SI2quater: OFF > <0003> bsc_init.c:108 SI3: 49 06 1b 00 00 00 f1 10 00 01 49 03 05 27 47 40 e5 04 00 29 2b 2b 2b > <0003> bsc_init.c:108 SI4: 31 06 1c 00 f1 10 00 01 47 40 e5 04 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b > <0003> bsc_init.c:108 SI5: 49 06 1d 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b > <0003> bsc_init.c:110 SI5bis: OFF > <0003> bsc_init.c:110 SI5ter: OFF > <0003> bsc_init.c:108 SI6: 2d 06 1e 00 00 00 f1 10 00 01 27 ff 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked > <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,00) Opstart ACK > <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,01) Set Channel Attributes ACK > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked > <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,01) Opstart ACK > <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,02) Set Channel Attributes ACK > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked > <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,02) Opstart ACK > <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,03) Set Channel Attributes ACK > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked > <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,03) Opstart ACK > <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,04) Set Channel Attributes ACK > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked > <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,04) Opstart ACK > <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,05) Set Channel Attributes ACK > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked > <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,05) Opstart ACK > <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,06) Set Channel Attributes ACK > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked > <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,06) Opstart ACK > <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,07) Set Channel Attributes ACK > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked > <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,07) Opstart ACK > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: Location updating (ra=0x0b, neci=0x01, chreq_reason=0x03) > <0000> chan_alloc.c:353 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH > <0004> abis_rsl.c:1924 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(514) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0b ta=0 > <0004> abis_rsl.c:595 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED > <0004> abis_rsl.c:1603 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION > <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 > <0002> gsm_04_08.c:1407 LOCATION UPDATING REQUEST: MI(TMSI)=792947918 type=NORMAL > <0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS. > <0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS. > <- Can't find any subscriber for this ID > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION > <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 > <0002> gsm_04_08.c:565 IDENTITY RESPONSE: MI(IMSI)=46001********** > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION > <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 > <0002> gsm_04_08.c:565 IDENTITY RESPONSE: MI(IMEI)=358634076823520 > <0002> gsm_04_08.c:522 -> LOCATION UPDATE ACCEPT > <0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x02 to MS. > <0002> gsm_04_08.c:892 -> MM INFO > <0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x32 to MS. > <0002> gsm_subscriber.c:341 Subscriber 46001********** ATTACHED LAC=1 > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION > <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 > <0002> gsm_04_08.c:1421 TMSI Reallocation Completed. Subscriber: 46001********** > <0002> gsm_04_08.c:323 Location Updating completed for 46001********** > <0000> chan_alloc.c:487 (bts=0,trx=0,ts=0,ss=0) starting release sequence > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE REQUESTED > <0003> gsm_04_08_utils.c:251 Sending Channel Release: Chan: Number: 0 Type: 1 > <0004> abis_rsl.c:777 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 RELEASE INDICATION > <0004> abis_rsl.c:1731 (bts=0,trx=0,ts=0,ss=0) T3111 expired: releasing RF Channel > <0004> abis_rsl.c:869 (bts=0,trx=0,ts=0,ss=0) RF Channel Release > <0004> abis_rsl.c:939 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state RELEASE REQUESTED -> NONE > <0000> chan_alloc.c:612 (bts=0) channel load average is 3.03% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: other (ra=0x1e, neci=0x01, chreq_reason=0x04) > <0000> chan_alloc.c:353 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH > <0004> abis_rsl.c:1924 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(514) SS(0) lctype SDCCH r=OTHER ra=0x1e ta=0 > <0004> abis_rsl.c:595 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED > <0004> abis_rsl.c:1603 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION > <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 > <0002> gsm_04_08.c:1016 <- CM SERVICE REQUEST serv_type=0x04 MI(TMSI)=1532175428 > <0002> gsm_04_08_utils.c:667 -> CM SERVICE ACK > <0000> chan_alloc.c:612 (bts=0) channel load average is 0.10% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=3 ESTABLISH INDICATION > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=3 DATA INDICATION > <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=9 > <0001> transaction.c:71 subscr=0x1728b00, net=0x15a78c0 > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=3 DATA INDICATION > <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=9 > <0000> chan_alloc.c:487 (bts=0,trx=0,ts=0,ss=0) starting release sequence > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE REQUESTED > <0000> abis_rsl.c:1201 (bts=0,trx=0,ts=0,ss=0) RSL RLL RELEASE REQ (link_id=0x03, reason=1) > <0003> gsm_04_08_utils.c:251 Sending Channel Release: Chan: Number: 0 Type: 1 > <0004> abis_rsl.c:777 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=3 RELEASE CONFIRMATION > <0004> abis_rsl.c:2098 (bts=0,trx=0,ts=0,ss=0) waiting for SAPI=0 to be released. > <0002> gsm_subscriber.c:190 Subscriber 46001********** not paged yet. > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 RELEASE INDICATION > <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: other (ra=0x1f, neci=0x01, chreq_reason=0x04) > <0000> chan_alloc.c:353 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=1 as SDCCH > <0004> abis_rsl.c:1924 (bts=0,trx=0,ts=0,ss=1) Activating ARFCN(514) SS(1) lctype SDCCH r=OTHER ra=0x1f ta=0 > <0004> abis_rsl.c:595 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=1) state NONE -> ACTIVATION REQUESTED > <0004> abis_rsl.c:1603 (bts=0,trx=0,ts=0,ss=1) CHANNEL ACTIVATE ACK > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=1) state ACTIVATION REQUESTED -> ACTIVE > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=0 ESTABLISH INDICATION > <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=6 > <0003> gsm_04_08.c:1462 PAGING RESPONSE: MI(TMSI)=1532175428 > <0003> gsm_04_08.c:1495 <- Channel was requested by 46001********** > <0001> transaction.c:71 subscr=0x175ae00, net=0x15a78c0 > <0000> abis_rsl.c:1159 (bts=0,trx=0,ts=0,ss=1) RSL RLL ESTABLISH REQ (link_id=0x03) > <0004> abis_rsl.c:1731 (bts=0,trx=0,ts=0,ss=0) T3111 expired: releasing RF Channel > <0004> abis_rsl.c:869 (bts=0,trx=0,ts=0,ss=0) RF Channel Release > <0004> abis_rsl.c:939 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state RELEASE REQUESTED -> NONE > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=3 ESTABLISH CONFIRM > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=3 DATA INDICATION > <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=9 > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=3 DATA INDICATION > <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=9 > <0000> chan_alloc.c:487 (bts=0,trx=0,ts=0,ss=1) starting release sequence > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=1) state ACTIVE -> RELEASE REQUESTED > <0000> abis_rsl.c:1201 (bts=0,trx=0,ts=0,ss=1) RSL RLL RELEASE REQ (link_id=0x03, reason=1) > <0003> gsm_04_08_utils.c:251 Sending Channel Release: Chan: Number: 1 Type: 1 > <0004> abis_rsl.c:777 (bts=0,trx=0,ts=0,ss=1) DEACTivate SACCH CMD > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=3 RELEASE CONFIRMATION > <0004> abis_rsl.c:2098 (bts=0,trx=0,ts=0,ss=1) waiting for SAPI=0 to be released. > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=0 DATA INDICATION > <0004> bsc_api.c:686 Got data in non active state(RELEASE REQUESTED), discarding. > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=0 RELEASE INDICATION > <0004> abis_rsl.c:1731 (bts=0,trx=0,ts=0,ss=1) T3111 expired: releasing RF Channel > <0004> abis_rsl.c:869 (bts=0,trx=0,ts=0,ss=1) RF Channel Release > <0004> abis_rsl.c:939 (bts=0,trx=0,ts=0,ss=1) RF CHANNEL RELEASE ACK > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=1) state RELEASE REQUESTED -> NONE > <0000> chan_alloc.c:612 (bts=0) channel load average is 5.12% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: call re-establishment (ra=0x4f, neci=0x01, chreq_reason=0x02) > <0000> chan_alloc.c:353 (bts=0,trx=0,ts=2,pchan=TCH/F) Allocating lchan=0 as TCH_F > <0004> abis_rsl.c:1924 (bts=0,trx=0,ts=2,ss=0) Activating ARFCN(514) SS(0) lctype TCH_F r=CALL ra=0x4f ta=0 > <0004> abis_rsl.c:595 (bts=0,trx=0,ts=2,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=2,ss=0) state NONE -> ACTIVATION REQUESTED > <0004> abis_rsl.c:1603 (bts=0,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=2,ss=0) state ACTIVATION REQUESTED -> ACTIVE > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 ESTABLISH INDICATION > <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 > <0002> gsm_04_08.c:1016 <- CM SERVICE REQUEST serv_type=0x01 MI(TMSI)=1532175428 > <0002> gsm_04_08_utils.c:667 -> CM SERVICE ACK > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION > <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=3 > <0001> gsm_04_08.c:3894 (bts 0 trx 0 ts 2 ti 8 sub 25332) Received 'SETUP' from MS in state 0 (NULL) > <0001> gsm_04_08.c:3899 Unknown transaction ID 8, creating new trans. > <0001> transaction.c:71 subscr=0x172d9a0, net=0x15a78c0 > <0001> gsm_04_08.c:1623 new state NULL -> INITIATED > <0001> gsm_04_08.c:2302 Subscriber 46001********** (25332) sends SETUP to 25332 > <0001> gsm_04_08.c:1685 (bts 0 trx 0 ts 2 ti 8 sub 25332) Sending 'MNCC_SETUP_IND' to MNCC. > <0001> gsm_04_08.c:3796 (bts 0 trx 0 ts 2 ti 08 sub 25332) Received 'MNCC_CALL_PROC_REQ' from MNCC in state 1 (INITIATED) > <0001> gsm_04_08.c:1623 new state INITIATED -> MO_CALL_PROC > <0001> gsm_04_08.c:138 (bts 0 trx 0 ts 2 ti 80) Sending 'CALL_PROC' to MS. > <0001> gsm_04_08.c:3796 (bts 0 trx 0 ts 2 ti 08 sub 25332) Received 'MNCC_LCHAN_MODIFY' from MNCC in state 3 (MO_CALL_PROC) > <0003> gsm_04_08_utils.c:517 -> CHANNEL MODE MODIFY mode=0x01 > <0001> transaction.c:71 subscr=0x172d9a0, net=0x15a78c0 > <0001> gsm_04_08.c:3796 (bts 0 trx 0 ts 2 ti ff sub 25332) Received 'MNCC_SETUP_REQ' from MNCC in state 0 (NULL) > <0001> gsm_04_08.c:2226 starting timer T303 with 30 seconds > <0001> gsm_04_08.c:1623 new state NULL -> CALL_PRESENT > <0001> gsm_04_08.c:138 (bts 0 trx 0 ts 2 ti 00) Sending 'SETUP' to MS. > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION > <0003> gsm_04_08_utils.c:542 CHANNEL MODE MODIFY ACK > <0004> abis_rsl.c:2344 (bts=0,trx=0,ts=2,ss=0) IPAC_BIND speech_mode=0x10 RTP_PAYLOAD=3 > <0003> osmo_msc.c:76 MSC assign complete (do nothing). > <0004> abis_rsl.c:1624 (bts=0,trx=0,ts=2,ss=0) CHANNEL MODE MODIFY ACK > <0004> abis_rsl.c:2525 (bts=0,trx=0,ts=2,ss=0) IPAC_CRCX_ACK LOCAL_IP=127.0.0.1 LOCAL_PORT=16384 CON_ID=0 > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION > <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=3 > <0001> gsm_04_08.c:3894 (bts 0 trx 0 ts 2 ti 0 sub 25332) Received 'RELEASE_COMPL' from MS in state 6 (CALL_PRESENT) > <0001> gsm_04_08.c:1665 stopping pending timer T303 > <0001> gsm_04_08.c:1685 (bts 0 trx 0 ts 2 ti 0 sub 25332) Sending 'MNCC_REJ_IND' to MNCC. > <0001> gsm_04_08.c:3796 (bts 0 trx 0 ts 2 ti 08 sub 25332) Received 'MNCC_REL_REQ' from MNCC in state 3 (MO_CALL_PROC) > <0001> gsm_04_08.c:2226 starting timer T308 with 10 seconds > <0001> gsm_04_08.c:1623 new state MO_CALL_PROC -> RELEASE_REQ > <0001> gsm_04_08.c:138 (bts 0 trx 0 ts 2 ti 80) Sending 'RELEASE' to MS. > <0001> gsm_04_08.c:1623 new state CALL_PRESENT -> NULL > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION > <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=3 > <0001> gsm_04_08.c:3894 (bts 0 trx 0 ts 2 ti 8 sub 25332) Received 'RELEASE_COMPL' from MS in state 19 (RELEASE_REQ) > <0001> gsm_04_08.c:1665 stopping pending timer T308 > <0001> gsm_04_08.c:1685 (bts 0 trx 0 ts 2 ti 8 sub 25332) Sending 'MNCC_REL_CNF' to MNCC. > <0001> gsm_04_08.c:1623 new state RELEASE_REQ -> NULL > <0000> chan_alloc.c:487 (bts=0,trx=0,ts=2,ss=0) starting release sequence > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=2,ss=0) state ACTIVE -> RELEASE REQUESTED > <0003> gsm_04_08_utils.c:251 Sending Channel Release: Chan: Number: 0 Type: 2 > <0004> abis_rsl.c:777 (bts=0,trx=0,ts=2,ss=0) DEACTivate SACCH CMD > <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 RELEASE INDICATION > <0004> abis_rsl.c:1731 (bts=0,trx=0,ts=2,ss=0) T3111 expired: releasing RF Channel > <0004> abis_rsl.c:869 (bts=0,trx=0,ts=2,ss=0) RF Channel Release > <0004> abis_rsl.c:2544 (bts=0,trx=0,ts=2,ss=0) IPAC_DLCX_IND > <0004> abis_rsl.c:939 (bts=0,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK > <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=2,ss=0) state RELEASE REQUESTED -> NONE > <0000> chan_alloc.c:612 (bts=0) channel load average is 1.24% > <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds > > ============================running-config============================ > OpenBSC# sh run > > Current configuration: > ! > password foo > ! > log stderr > logging filter all 1 > logging color 1 > logging print category 0 > logging timestamp 0 > logging print file 1 > % Invalid log level 0 for rll > % Invalid log level 0 for cc > % Invalid log level 0 for mm > % Invalid log level 0 for rr > % Invalid log level 0 for rsl > % Invalid log level 0 for nm > logging level mncc notice > logging level pag notice > logging level meas notice > logging level sccp notice > logging level msc notice > logging level mgcp notice > logging level ho notice > logging level db notice > logging level ref notice > logging level gprs debug > logging level ns info > logging level bssgp debug > logging level llc debug > logging level sndcp debug > logging level nat notice > logging level ctrl notice > logging level smpp debug > logging level filter debug > logging level ranap debug > logging level sua debug > logging level pcu debug > logging level lglobal notice > logging level llapd notice > logging level linp notice > logging level lmux notice > logging level lmi notice > logging level lmib notice > logging level lsms notice > logging level lctrl notice > logging level lgtp notice > logging level lstats notice > logging level lgsup notice > logging level loap notice > logging level lss7 notice > logging level lsccp notice > logging level lsua notice > logging level lm3ua notice > logging level lmgcp notice > logging level ljibuf notice > ! > stats interval 5 > ! > line vty > no login > ! > e1_input > e1_line 0 driver ipa > e1_line 0 port 0 > no e1_line 0 keepalive > network > network country code 001 > mobile network code 01 > short name OpenBSC > long name OpenBSC > auth policy token > authorized-regexp .* > location updating reject cause 13 > encryption a5 0 > neci 1 > paging any use tch 0 > rrlp mode none > mm info 1 > handover 0 > handover window rxlev averaging 10 > handover window rxqual averaging 1 > handover window rxlev neighbor averaging 10 > handover power budget interval 6 > handover power budget hysteresis 3 > handover maximum distance 9999 > dyn_ts_allow_tch_f 0 > subscriber-keep-in-ram 0 > 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 > periodic location update 30 > 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 > no access-control-class-ramping > access-control-class-ramping-step-interval dynamic > access-control-class-ramping-step-size 1 > early-classmark-sending forbidden > early-classmark-sending-3g allowed > ip.access unit_id 1801 0 > oml ip.access stream_id 255 line 0 > neighbor-list mode automatic > codec-support fr > gprs mode none > no force-combined-si > trx 0 > rf_locked 0 > arfcn 514 > nominal power 23 > max_power_red 20 > rsl e1 tei 0 > timeslot 0 > phys_chan_config CCCH+SDCCH4 > hopping enabled 0 > timeslot 1 > phys_chan_config SDCCH8 > 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 > mncc-int > default-codec tch-f fr > default-codec tch-h hr > nitb > subscriber-create-on-demand > assign-tmsi > end > > ============================test subscriber info============================ > OpenBSC# sh sub id 4 > ID: 4, Authorized: 1 > Extension: 25332 > LAC: 1/0x1 > IMSI: 46001********** > TMSI: 5B532444 > A3A8 algorithm id: 4 > A3A8 Ki: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f > Expiration Time: Sun, 23 Dec 2018 13:53:49 +0800 > Paging: not paging Requests: 0 > Use count: 1 > OpenBSC# > > =========================== > THANKS A LOT! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dechaoforever at qq.com Sun Dec 23 08:44:38 2018 From: dechaoforever at qq.com (=?gb18030?B?y67UxtauvOQ=?=) Date: Sun, 23 Dec 2018 16:44:38 +0800 Subject: How to enable AUTHENTICATION procedure in osmo-nitb? Message-ID: Hi Domi. Thank you. : ) After changing encryption type to A5/1, I can see AUTH REQ. ------------------------ from dechao iPad ------------------ Original ------------------ From: Tomcs?nyi, Domonkos Date: Sun,Dec 23,2018 3:01 PM To: ???? Cc: openbsc Subject: Re: How to enable AUTHENTICATION procedure in osmo-nitb? Hello, I would start by changing the encryption type to a5 1 ;) Cheers, Domi 2018. dec. 23. d?tummal, 6:23 id?pontban ???? ?rta: Hi ALL. Recently I setup osmo-nitb on my laptop, by using it I can send SMS and make a call between 2 phones successfully. The solution is LimeSDR + osmo-trx-lms + osmo-bts-trx + osmo-nitb. But when I check the logs of osmo-nitb, cannot find AUTHENTICATION message. How to trigger AUTHENTICATION ? These days I went through the osmonitb-usermanual.pdf but still cannot get it. I will be appreciated if you can help me. Here is the LOGS, running-config and test subscriber info. ============================LOGS============================ ezio at mylab:~$ osmo-nitb -c ~/.osmocom/osmo-nitb.cfg -l ~/.osmocom/hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM DB: Database initialized. DB: Database prepared. <0005> abis_nm.c:1601 Get Attr (bts=0) <0005> abis_nm.c:1601 Get Attr (bts=0) <0005> abis_nm.c:381 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=unknown 0x0 <0005> abis_nm.c:1938 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART <0005> abis_nm.c:381 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1619 Set BTS Attr (bts=0) <0005> abis_nm.c:1938 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART <0005> abis_nm.c:381 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=GPRS-CELL(f1) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=Unlocked <0005> abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) ADM=unknown 0x0 <0005> abis_nm.c:550 OC=BTS(01) INST=(00,ff,ff) Get Attributes Response for BTS0 <0005> abis_nm.c:463 BTS0 Get Attributes Response Info: 70 bytes total with 0 unreported attributes <0005> abis_nm.c:507 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. <0005> abis_nm.c:507 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:507 BTS0 feature 'CBCH' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:573 BTS0: ARI reported sw[0/2]: osmobts is 0.8.1.192-fc88 <0005> abis_nm.c:446 BTS0 reported variant: omso-bts-trx <0005> abis_nm.c:550 OC=BTS(01) INST=(00,ff,ff) Get Attributes Response for BTS0 <0005> abis_nm.c:463 BTS0 Get Attributes Response Info: 32 bytes total with 1 unreported attributes <0005> abis_nm.c:468 BTS0 Attribute Manufacturer Dependent State is unreported <0005> abis_nm.c:573 BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown <0005> abis_nm.c:771 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Opstart ACK <0005> abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) ADM=Unlocked <0004> acc_ramp.c:162 (bts=0,trx=0) ACC RAMP: administrative state Unlocked -> Unlocked <0004> acc_ramp.c:166 (bts=0,trx=0) ACC RAMP: operational state NULL -> Disabled <0004> acc_ramp.c:175 (bts=0,trx=0) ACC RAMP: ignoring state change because RSL link is down <0005> abis_nm.c:1938 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=OK(ff) ADM=unknown 0x0 <0005> abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:1636 Set TRX Attr (bts=0,trx=0) <0005> abis_nm.c:1938 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:1938 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:2757 (bts=0,trx=0) IPA RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=0) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=1) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=2) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,02) Sending OPSTART <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=3) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,03) Sending OPSTART <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=4) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,04) Sending OPSTART <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=5) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,05) Sending OPSTART <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=6) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,06) Sending OPSTART <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=unknown 0x0 <0005> abis_nm.c:1831 Set Chan Attr (bts=0,trx=0,ts=7) <0005> abis_nm.c:1938 OC=CHANNEL(03) INST=(00,00,07) Sending OPSTART <0005> abis_nm.c:381 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=BTS(01) INST=(00,ff,ff) Opstart ACK <0005> abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0004> acc_ramp.c:162 (bts=0,trx=0) ACC RAMP: administrative state Unlocked -> Unlocked <0004> acc_ramp.c:166 (bts=0,trx=0) ACC RAMP: operational state Disabled -> Enabled <0004> acc_ramp.c:175 (bts=0,trx=0) ACC RAMP: ignoring state change because RSL link is down <0005> abis_nm.c:771 OC=RADIO-CARRIER(02) INST=(00,00,ff) Opstart ACK <0005> abis_nm.c:779 OC=RADIO-CARRIER(02) INST=(00,00,ff) Set Radio Carrier Attributes ACK <0004> acc_ramp.c:162 (bts=0,trx=0) ACC RAMP: administrative state Unlocked -> Unlocked <0004> acc_ramp.c:166 (bts=0,trx=0) ACC RAMP: operational state Enabled -> Enabled <0004> acc_ramp.c:175 (bts=0,trx=0) ACC RAMP: ignoring state change because RSL link is down <0005> abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=RADIO-CARRIER(02) INST=(00,00,ff) Opstart ACK <0005> abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Opstart ACK <0005> abis_nm.c:2599 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xe1): RSL CONNECT ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,00) Set Channel Attributes ACK <0004> bsc_init.c:312 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 514 using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63 <0003> system_information.c:637 Serving cell: 514 <0003> bsc_init.c:108 SI1: 55 06 19 8f 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e5 04 00 2b <0003> bsc_init.c:108 SI2: 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00 <0003> bsc_init.c:110 SI2bis: OFF <0003> bsc_init.c:110 SI2ter: OFF <0003> bsc_init.c:110 SI2quater: OFF <0003> bsc_init.c:108 SI3: 49 06 1b 00 00 00 f1 10 00 01 49 03 05 27 47 40 e5 04 00 29 2b 2b 2b <0003> bsc_init.c:108 SI4: 31 06 1c 00 f1 10 00 01 47 40 e5 04 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0003> bsc_init.c:108 SI5: 49 06 1d 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b <0003> bsc_init.c:110 SI5bis: OFF <0003> bsc_init.c:110 SI5ter: OFF <0003> bsc_init.c:108 SI6: 2d 06 1e 00 00 00 f1 10 00 01 27 ff 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,00) Opstart ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,01) Set Channel Attributes ACK <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,01) Opstart ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,02) Set Channel Attributes ACK <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,02) Opstart ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,03) Set Channel Attributes ACK <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,03) Opstart ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,04) Set Channel Attributes ACK <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,04) Opstart ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,05) Set Channel Attributes ACK <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,05) Opstart ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,06) Set Channel Attributes ACK <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,06) Opstart ACK <0005> abis_nm.c:775 OC=CHANNEL(03) INST=(00,00,07) Set Channel Attributes ACK <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:771 OC=CHANNEL(03) INST=(00,00,07) Opstart ACK <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: Location updating (ra=0x0b, neci=0x01, chreq_reason=0x03) <0000> chan_alloc.c:353 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH <0004> abis_rsl.c:1924 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(514) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0b ta=0 <0004> abis_rsl.c:595 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1603 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 <0002> gsm_04_08.c:1407 LOCATION UPDATING REQUEST: MI(TMSI)=792947918 type=NORMAL <0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS. <0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS. <- Can't find any subscriber for this ID <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 <0002> gsm_04_08.c:565 IDENTITY RESPONSE: MI(IMSI)=46001********** <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 <0002> gsm_04_08.c:565 IDENTITY RESPONSE: MI(IMEI)=358634076823520 <0002> gsm_04_08.c:522 -> LOCATION UPDATE ACCEPT <0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x02 to MS. <0002> gsm_04_08.c:892 -> MM INFO <0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x32 to MS. <0002> gsm_subscriber.c:341 Subscriber 46001********** ATTACHED LAC=1 <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 <0002> gsm_04_08.c:1421 TMSI Reallocation Completed. Subscriber: 46001********** <0002> gsm_04_08.c:323 Location Updating completed for 46001********** <0000> chan_alloc.c:487 (bts=0,trx=0,ts=0,ss=0) starting release sequence <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE REQUESTED <0003> gsm_04_08_utils.c:251 Sending Channel Release: Chan: Number: 0 Type: 1 <0004> abis_rsl.c:777 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 RELEASE INDICATION <0004> abis_rsl.c:1731 (bts=0,trx=0,ts=0,ss=0) T3111 expired: releasing RF Channel <0004> abis_rsl.c:869 (bts=0,trx=0,ts=0,ss=0) RF Channel Release <0004> abis_rsl.c:939 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state RELEASE REQUESTED -> NONE <0000> chan_alloc.c:612 (bts=0) channel load average is 3.03% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> chan_alloc.c:612 (bts=0) channel load average is 0.00% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: other (ra=0x1e, neci=0x01, chreq_reason=0x04) <0000> chan_alloc.c:353 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH <0004> abis_rsl.c:1924 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(514) SS(0) lctype SDCCH r=OTHER ra=0x1e ta=0 <0004> abis_rsl.c:595 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1603 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 <0002> gsm_04_08.c:1016 <- CM SERVICE REQUEST serv_type=0x04 MI(TMSI)=1532175428 <0002> gsm_04_08_utils.c:667 -> CM SERVICE ACK <0000> chan_alloc.c:612 (bts=0) channel load average is 0.10% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=3 ESTABLISH INDICATION <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=3 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=9 <0001> transaction.c:71 subscr=0x1728b00, net=0x15a78c0 <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=3 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=9 <0000> chan_alloc.c:487 (bts=0,trx=0,ts=0,ss=0) starting release sequence <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE REQUESTED <0000> abis_rsl.c:1201 (bts=0,trx=0,ts=0,ss=0) RSL RLL RELEASE REQ (link_id=0x03, reason=1) <0003> gsm_04_08_utils.c:251 Sending Channel Release: Chan: Number: 0 Type: 1 <0004> abis_rsl.c:777 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=3 RELEASE CONFIRMATION <0004> abis_rsl.c:2098 (bts=0,trx=0,ts=0,ss=0) waiting for SAPI=0 to be released. <0002> gsm_subscriber.c:190 Subscriber 46001********** not paged yet. <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=0) SAPI=0 RELEASE INDICATION <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: other (ra=0x1f, neci=0x01, chreq_reason=0x04) <0000> chan_alloc.c:353 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=1 as SDCCH <0004> abis_rsl.c:1924 (bts=0,trx=0,ts=0,ss=1) Activating ARFCN(514) SS(1) lctype SDCCH r=OTHER ra=0x1f ta=0 <0004> abis_rsl.c:595 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=1) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1603 (bts=0,trx=0,ts=0,ss=1) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=1) state ACTIVATION REQUESTED -> ACTIVE <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=0 ESTABLISH INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=6 <0003> gsm_04_08.c:1462 PAGING RESPONSE: MI(TMSI)=1532175428 <0003> gsm_04_08.c:1495 <- Channel was requested by 46001********** <0001> transaction.c:71 subscr=0x175ae00, net=0x15a78c0 <0000> abis_rsl.c:1159 (bts=0,trx=0,ts=0,ss=1) RSL RLL ESTABLISH REQ (link_id=0x03) <0004> abis_rsl.c:1731 (bts=0,trx=0,ts=0,ss=0) T3111 expired: releasing RF Channel <0004> abis_rsl.c:869 (bts=0,trx=0,ts=0,ss=0) RF Channel Release <0004> abis_rsl.c:939 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=0) state RELEASE REQUESTED -> NONE <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=3 ESTABLISH CONFIRM <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=3 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=9 <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=3 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=9 <0000> chan_alloc.c:487 (bts=0,trx=0,ts=0,ss=1) starting release sequence <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=1) state ACTIVE -> RELEASE REQUESTED <0000> abis_rsl.c:1201 (bts=0,trx=0,ts=0,ss=1) RSL RLL RELEASE REQ (link_id=0x03, reason=1) <0003> gsm_04_08_utils.c:251 Sending Channel Release: Chan: Number: 1 Type: 1 <0004> abis_rsl.c:777 (bts=0,trx=0,ts=0,ss=1) DEACTivate SACCH CMD <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=3 RELEASE CONFIRMATION <0004> abis_rsl.c:2098 (bts=0,trx=0,ts=0,ss=1) waiting for SAPI=0 to be released. <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=0 DATA INDICATION <0004> bsc_api.c:686 Got data in non active state(RELEASE REQUESTED), discarding. <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=0,ss=1) SAPI=0 RELEASE INDICATION <0004> abis_rsl.c:1731 (bts=0,trx=0,ts=0,ss=1) T3111 expired: releasing RF Channel <0004> abis_rsl.c:869 (bts=0,trx=0,ts=0,ss=1) RF Channel Release <0004> abis_rsl.c:939 (bts=0,trx=0,ts=0,ss=1) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=0,ss=1) state RELEASE REQUESTED -> NONE <0000> chan_alloc.c:612 (bts=0) channel load average is 5.12% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: call re-establishment (ra=0x4f, neci=0x01, chreq_reason=0x02) <0000> chan_alloc.c:353 (bts=0,trx=0,ts=2,pchan=TCH/F) Allocating lchan=0 as TCH_F <0004> abis_rsl.c:1924 (bts=0,trx=0,ts=2,ss=0) Activating ARFCN(514) SS(0) lctype TCH_F r=CALL ra=0x4f ta=0 <0004> abis_rsl.c:595 (bts=0,trx=0,ts=2,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=2,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1603 (bts=0,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=2,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 ESTABLISH INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=5 <0002> gsm_04_08.c:1016 <- CM SERVICE REQUEST serv_type=0x01 MI(TMSI)=1532175428 <0002> gsm_04_08_utils.c:667 -> CM SERVICE ACK <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=3 <0001> gsm_04_08.c:3894 (bts 0 trx 0 ts 2 ti 8 sub 25332) Received 'SETUP' from MS in state 0 (NULL) <0001> gsm_04_08.c:3899 Unknown transaction ID 8, creating new trans. <0001> transaction.c:71 subscr=0x172d9a0, net=0x15a78c0 <0001> gsm_04_08.c:1623 new state NULL -> INITIATED <0001> gsm_04_08.c:2302 Subscriber 46001********** (25332) sends SETUP to 25332 <0001> gsm_04_08.c:1685 (bts 0 trx 0 ts 2 ti 8 sub 25332) Sending 'MNCC_SETUP_IND' to MNCC. <0001> gsm_04_08.c:3796 (bts 0 trx 0 ts 2 ti 08 sub 25332) Received 'MNCC_CALL_PROC_REQ' from MNCC in state 1 (INITIATED) <0001> gsm_04_08.c:1623 new state INITIATED -> MO_CALL_PROC <0001> gsm_04_08.c:138 (bts 0 trx 0 ts 2 ti 80) Sending 'CALL_PROC' to MS. <0001> gsm_04_08.c:3796 (bts 0 trx 0 ts 2 ti 08 sub 25332) Received 'MNCC_LCHAN_MODIFY' from MNCC in state 3 (MO_CALL_PROC) <0003> gsm_04_08_utils.c:517 -> CHANNEL MODE MODIFY mode=0x01 <0001> transaction.c:71 subscr=0x172d9a0, net=0x15a78c0 <0001> gsm_04_08.c:3796 (bts 0 trx 0 ts 2 ti ff sub 25332) Received 'MNCC_SETUP_REQ' from MNCC in state 0 (NULL) <0001> gsm_04_08.c:2226 starting timer T303 with 30 seconds <0001> gsm_04_08.c:1623 new state NULL -> CALL_PRESENT <0001> gsm_04_08.c:138 (bts 0 trx 0 ts 2 ti 00) Sending 'SETUP' to MS. <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0003> gsm_04_08_utils.c:542 CHANNEL MODE MODIFY ACK <0004> abis_rsl.c:2344 (bts=0,trx=0,ts=2,ss=0) IPAC_BIND speech_mode=0x10 RTP_PAYLOAD=3 <0003> osmo_msc.c:76 MSC assign complete (do nothing). <0004> abis_rsl.c:1624 (bts=0,trx=0,ts=2,ss=0) CHANNEL MODE MODIFY ACK <0004> abis_rsl.c:2525 (bts=0,trx=0,ts=2,ss=0) IPAC_CRCX_ACK LOCAL_IP=127.0.0.1 LOCAL_PORT=16384 CON_ID=0 <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=3 <0001> gsm_04_08.c:3894 (bts 0 trx 0 ts 2 ti 0 sub 25332) Received 'RELEASE_COMPL' from MS in state 6 (CALL_PRESENT) <0001> gsm_04_08.c:1665 stopping pending timer T303 <0001> gsm_04_08.c:1685 (bts 0 trx 0 ts 2 ti 0 sub 25332) Sending 'MNCC_REJ_IND' to MNCC. <0001> gsm_04_08.c:3796 (bts 0 trx 0 ts 2 ti 08 sub 25332) Received 'MNCC_REL_REQ' from MNCC in state 3 (MO_CALL_PROC) <0001> gsm_04_08.c:2226 starting timer T308 with 10 seconds <0001> gsm_04_08.c:1623 new state MO_CALL_PROC -> RELEASE_REQ <0001> gsm_04_08.c:138 (bts 0 trx 0 ts 2 ti 80) Sending 'RELEASE' to MS. <0001> gsm_04_08.c:1623 new state CALL_PRESENT -> NULL <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0000> gsm_04_08.c:3999 Dispatching 04.08 message, pdisc=3 <0001> gsm_04_08.c:3894 (bts 0 trx 0 ts 2 ti 8 sub 25332) Received 'RELEASE_COMPL' from MS in state 19 (RELEASE_REQ) <0001> gsm_04_08.c:1665 stopping pending timer T308 <0001> gsm_04_08.c:1685 (bts 0 trx 0 ts 2 ti 8 sub 25332) Sending 'MNCC_REL_CNF' to MNCC. <0001> gsm_04_08.c:1623 new state RELEASE_REQ -> NULL <0000> chan_alloc.c:487 (bts=0,trx=0,ts=2,ss=0) starting release sequence <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=2,ss=0) state ACTIVE -> RELEASE REQUESTED <0003> gsm_04_08_utils.c:251 Sending Channel Release: Chan: Number: 0 Type: 2 <0004> abis_rsl.c:777 (bts=0,trx=0,ts=2,ss=0) DEACTivate SACCH CMD <0000> abis_rsl.c:2127 (bts=0,trx=0,ts=2,ss=0) SAPI=0 RELEASE INDICATION <0004> abis_rsl.c:1731 (bts=0,trx=0,ts=2,ss=0) T3111 expired: releasing RF Channel <0004> abis_rsl.c:869 (bts=0,trx=0,ts=2,ss=0) RF Channel Release <0004> abis_rsl.c:2544 (bts=0,trx=0,ts=2,ss=0) IPAC_DLCX_IND <0004> abis_rsl.c:939 (bts=0,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=2,ss=0) state RELEASE REQUESTED -> NONE <0000> chan_alloc.c:612 (bts=0) channel load average is 1.24% <0000> chan_alloc.c:625 (bts=0) T3122 wait indicator set to 10 seconds ============================running-config============================ OpenBSC# sh run Current configuration: ! password foo ! log stderr logging filter all 1 logging color 1 logging print category 0 logging timestamp 0 logging print file 1 % Invalid log level 0 for rll % Invalid log level 0 for cc % Invalid log level 0 for mm % Invalid log level 0 for rr % Invalid log level 0 for rsl % Invalid log level 0 for nm logging level mncc notice logging level pag notice logging level meas notice logging level sccp notice logging level msc notice logging level mgcp notice logging level ho notice logging level db notice logging level ref notice logging level gprs debug logging level ns info logging level bssgp debug logging level llc debug logging level sndcp debug logging level nat notice logging level ctrl notice logging level smpp debug logging level filter debug logging level ranap debug logging level sua debug logging level pcu debug logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice logging level lstats notice logging level lgsup notice logging level loap notice logging level lss7 notice logging level lsccp notice logging level lsua notice logging level lm3ua notice logging level lmgcp notice logging level ljibuf notice ! stats interval 5 ! line vty no login ! e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive network network country code 001 mobile network code 01 short name OpenBSC long name OpenBSC auth policy token authorized-regexp .* location updating reject cause 13 encryption a5 0 neci 1 paging any use tch 0 rrlp mode none mm info 1 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 dyn_ts_allow_tch_f 0 subscriber-keep-in-ram 0 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 periodic location update 30 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 no access-control-class-ramping access-control-class-ramping-step-interval dynamic access-control-class-ramping-step-size 1 early-classmark-sending forbidden early-classmark-sending-3g allowed ip.access unit_id 1801 0 oml ip.access stream_id 255 line 0 neighbor-list mode automatic codec-support fr gprs mode none no force-combined-si trx 0 rf_locked 0 arfcn 514 nominal power 23 max_power_red 20 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config SDCCH8 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 mncc-int default-codec tch-f fr default-codec tch-h hr nitb subscriber-create-on-demand assign-tmsi end ============================test subscriber info============================ OpenBSC# sh sub id 4 ID: 4, Authorized: 1 Extension: 25332 LAC: 1/0x1 IMSI: 46001********** TMSI: 5B532444 A3A8 algorithm id: 4 A3A8 Ki: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f Expiration Time: Sun, 23 Dec 2018 13:53:49 +0800 Paging: not paging Requests: 0 Use count: 1 OpenBSC# =========================== THANKS A LOT! -------------- next part -------------- An HTML attachment was scrubbed... URL: From shingy92 at gmail.com Mon Dec 24 07:07:48 2018 From: shingy92 at gmail.com (Shingirai Simba) Date: Mon, 24 Dec 2018 09:07:48 +0200 Subject: osmo MSC - Roaming Interworking Message-ID: Hie My last work with osmo when it was an NITB. I noticed that with the new split, we have sigtran SS7. I woul like to know if it can handle roaming with other GSM networks. Regards shingy -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Dec 24 16:19:16 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 24 Dec 2018 17:19:16 +0100 Subject: osmo MSC - Roaming Interworking In-Reply-To: References: Message-ID: <20181224161916.GA2961@nataraja> Hi Shingirai, On Mon, Dec 24, 2018 at 09:07:48AM +0200, Shingirai Simba wrote: > My last work with osmo when it was an NITB. I noticed that with the new > split, we have sigtran SS7. I woul like to know if it can handle roaming > with other GSM networks. We implement SS7/SIGTRAN and use it on the A interface between osmo-bsc and osmo-msc. We do not implement TCAP/MAP from the MSC upwards to HLR or other MSC. There have been several projects to work on this in the past, but unfortunately the amount of contribution and/or commercial interest newer was sufficient for a complete implementation. Let us know if you'd like to help in that area. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From snehasish.cse at LIVE.COM Mon Dec 24 09:42:06 2018 From: snehasish.cse at LIVE.COM (Snehasish Kar) Date: Mon, 24 Dec 2018 09:42:06 +0000 Subject: Adding priority for EMLPP service in paging type 1 Message-ID: Hello Everyone I was trying to set priority bit in paging type 1. I tried modifying the function rsl_paging_cmd in abis_rsl.c . But when i am checking the same in wireshark, I couldn't view it. Any help on this. BR -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2018-12-22 19-07-17.png Type: image/png Size: 178259 bytes Desc: Screenshot from 2018-12-22 19-07-17.png URL: From laforge at gnumonks.org Tue Dec 25 22:54:45 2018 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 25 Dec 2018 23:54:45 +0100 Subject: Adding priority for EMLPP service in paging type 1 In-Reply-To: References: Message-ID: <81DC58B6-C9B8-4B82-88C1-591F5EFF80EC@gnumonks.org> Please kindly share your patches and related pcap traces of the resulting messages for our review and feedback. Thanks! -- Sent from a mobile device. Please excuse my brevity. From snehasish.cse at live.com Wed Dec 26 11:52:11 2018 From: snehasish.cse at live.com (Snehasish Kar) Date: Wed, 26 Dec 2018 11:52:11 +0000 Subject: Adding priority for EMLPP service in paging type 1 In-Reply-To: <81DC58B6-C9B8-4B82-88C1-591F5EFF80EC@gnumonks.org> References: , <81DC58B6-C9B8-4B82-88C1-591F5EFF80EC@gnumonks.org> Message-ID: Hello Mr. Welte Please find the patches: 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,0x8f); //just a random msg to see the P1 rest octets in wirehark + msg->dst = bts->c0->rsl_link; return abis_rsl_sendmsg(msg); 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,0x8f); new_cc_state(trans, GSM_CSTATE_CALL_PRESENT); rate_ctr_inc(&trans->net->msc_ctrs->ctr[MSC_CTR_CALL_MT_SETUP]); BR Snehasish ________________________________ From: Harald Welte Sent: Wednesday, December 26, 2018 4:24 AM To: Snehasish Kar; openbsc at lists.osmocom.org Subject: Re: Adding priority for EMLPP service in paging type 1 Please kindly share your patches and related pcap traces of the resulting messages for our review and feedback. Thanks! -- Sent from a mobile device. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gullik.webjorn at corevalue.se Wed Dec 26 15:28:31 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Wed, 26 Dec 2018 16:28:31 +0100 Subject: osmo-uhd-trx In-Reply-To: <01818d0f-3b75-f874-f569-ab4026115f4f@corevalue.se> References: <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> <86598f32-b8fe-9e9d-22a9-5ec7348dd359@corevalue.se> <575d4103-bfb6-c269-9b03-55727e523afa@corevalue.se> <4c1991aa-3e36-a9ed-c004-c4181aed9690@corevalue.se> <2af53f98-3303-ccb5-50f4-4f27a53866a4@corevalue.se> <20181222094209.GR2961@nataraja> <01818d0f-3b75-f874-f569-ab4026115f4f@corevalue.se> Message-ID: <8009be46-778c-2eb2-f543-833cb0126ebc@corevalue.se> Feedback: I have upgraded "nightly" installation from dec-19 with the following: replaced osmo-bts-trx_0.8.1.194.8564_armhf.deb with osmo-bts-trx_0.8.1.199.5c93_armhf.deb This seems to have solved the instabilities I saw and logged, I now get just clock indications on the trx-uhd terminal, and phones camp properly and do not loose carrier. One remaining issue is that I have no call progress when originating calls on MS toward fixed network / asterisk / sip. SIP-originated calls behave normally. tcpdump shows proper SIP messages regardless of direction. I have not replaced any other components, but will se which have changed 19-dec to 25-dec and test with them. I hope you are having a nice Christmas, I sure have.... Gullik From laforge at gnumonks.org Wed Dec 26 20:58:30 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 26 Dec 2018 21:58:30 +0100 Subject: Adding priority for EMLPP service in paging type 1 In-Reply-To: References: <81DC58B6-C9B8-4B82-88C1-591F5EFF80EC@gnumonks.org> Message-ID: <20181226205830.GB2559@nataraja> 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) From snehasish.cse at live.com Wed Dec 26 14:13:38 2018 From: snehasish.cse at live.com (Snehasish Kar) Date: Wed, 26 Dec 2018 14:13:38 +0000 Subject: Adding priority for EMLPP service in paging type 1 In-Reply-To: References: , <81DC58B6-C9B8-4B82-88C1-591F5EFF80EC@gnumonks.org>, Message-ID: Hello Mr. Welte Please find the updated patches: 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, 0x00); //just a random msg to see the P1 rest octets in wirehark + msg->dst = bts->c0->rsl_link; return abis_rsl_sendmsg(msg); 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,0x8f); new_cc_state(trans, GSM_CSTATE_CALL_PRESENT); rate_ctr_inc(&trans->net->msc_ctrs->ctr[MSC_CTR_CALL_MT_SETUP]); ________________________________ From: Snehasish Kar Sent: Wednesday, December 26, 2018 5:22 PM To: Harald Welte Cc: openbsc at lists.osmocom.org Subject: Re: Adding priority for EMLPP service in paging type 1 Hello Mr. Welte Please find the patches: 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,0x8f); //just a random msg to see the P1 rest octets in wirehark + msg->dst = bts->c0->rsl_link; return abis_rsl_sendmsg(msg); 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,0x8f); new_cc_state(trans, GSM_CSTATE_CALL_PRESENT); rate_ctr_inc(&trans->net->msc_ctrs->ctr[MSC_CTR_CALL_MT_SETUP]); BR Snehasish ________________________________ From: Harald Welte Sent: Wednesday, December 26, 2018 4:24 AM To: Snehasish Kar; openbsc at lists.osmocom.org Subject: Re: Adding priority for EMLPP service in paging type 1 Please kindly share your patches and related pcap traces of the resulting messages for our review and feedback. Thanks! -- Sent from a mobile device. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gullik.webjorn at corevalue.se Thu Dec 27 09:15:01 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Thu, 27 Dec 2018 10:15:01 +0100 Subject: osmo-uhd-trx In-Reply-To: <8009be46-778c-2eb2-f543-833cb0126ebc@corevalue.se> References: <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> <86598f32-b8fe-9e9d-22a9-5ec7348dd359@corevalue.se> <575d4103-bfb6-c269-9b03-55727e523afa@corevalue.se> <4c1991aa-3e36-a9ed-c004-c4181aed9690@corevalue.se> <2af53f98-3303-ccb5-50f4-4f27a53866a4@corevalue.se> <20181222094209.GR2961@nataraja> <01818d0f-3b75-f874-f569-ab4026115f4f@corevalue.se> <8009be46-778c-2eb2-f543-833cb0126ebc@corevalue.se> Message-ID: <222bd978-aaa1-2035-8bb2-b3a2dbf9d835@corevalue.se> I have had 100% good stability over the night. However, osmo-bts-trx logs the following every 5-10 minutes. There has been no "activity" nightly on the gsm network. Gullik Dec 27 09:08:57 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:741 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK Dec 27 09:09:00 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:720 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK Dec 27 09:10:12 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:741 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK Dec 27 09:10:15 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:720 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK Dec 27 09:12:03 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:741 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK Dec 27 09:12:03 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:920 Store content res. (dl=0xb67ec498) Dec 27 09:12:04 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 09:12:04 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 09:12:05 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 09:12:06 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:720 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK Dec 27 09:17:27 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:741 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK Dec 27 09:17:27 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:920 Store content res. (dl=0xb67ec498) Dec 27 09:17:28 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 09:17:29 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 09:17:29 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 09:17:30 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:720 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK Dec 27 09:32:46 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:741 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK Dec 27 09:32:46 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:920 Store content res. (dl=0xb67ec498) Dec 27 09:32:48 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 09:32:48 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 09:32:48 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 09:32:49 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:720 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK Dec 27 09:42:04 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:741 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK Dec 27 09:42:05 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:920 Store content res. (dl=0xb67ec498) Dec 27 09:42:06 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 09:42:06 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 09:42:06 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 09:42:08 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:720 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK Dec 27 09:47:32 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:741 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK Dec 27 09:47:32 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:920 Store content res. (dl=0xb67ec498) Dec 27 09:47:33 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 09:47:34 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 09:47:34 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 09:47:35 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:720 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK Dec 27 10:02:51 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:741 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK Dec 27 10:02:51 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:920 Store content res. (dl=0xb67ec498) Dec 27 10:02:52 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 10:02:53 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 10:02:53 localhost osmo-bts-trx[20109]: #033[0;m<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 state LAPD_STATE_MF_EST) Dec 27 10:02:54 localhost osmo-bts-trx[20109]: #033[0;m#033[1;35m<0000> rsl.c:720 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK From gullik.webjorn at corevalue.se Thu Dec 27 19:39:05 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Thu, 27 Dec 2018 20:39:05 +0100 Subject: osmo-uhd-trx In-Reply-To: <222bd978-aaa1-2035-8bb2-b3a2dbf9d835@corevalue.se> References: <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> <86598f32-b8fe-9e9d-22a9-5ec7348dd359@corevalue.se> <575d4103-bfb6-c269-9b03-55727e523afa@corevalue.se> <4c1991aa-3e36-a9ed-c004-c4181aed9690@corevalue.se> <2af53f98-3303-ccb5-50f4-4f27a53866a4@corevalue.se> <20181222094209.GR2961@nataraja> <01818d0f-3b75-f874-f569-ab4026115f4f@corevalue.se> <8009be46-778c-2eb2-f543-833cb0126ebc@corevalue.se> <222bd978-aaa1-2035-8bb2-b3a2dbf9d835@corevalue.se> Message-ID: Gentlemen, While upgrading to osmo-bts-trx_0.8.1.199.5c93_armhf.deb solved most of the problem, the main issue seems to remain. The latest version reduced failure rate from 1-3 / hour, to 18 hours, but did not eliminate the problem, i.e. a spinning trx-uhd. I enclose a snippet from console: Thu Dec 27 18:53:00 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3007431760] new latency: 7:33599 (underrun 1:1683315 vs 6:1683313) Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3007431760] new latency: 7:33600 (underrun 6:1683326 vs 1:1683325) Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3007431760] new latency: 7:33601 (underrun 5:1683338 vs 6:1683336) Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DDEV <0002> UHDDevice.cpp:1319 [tid=2997609552] Packet loss between host and device at 103454 sec. Thu Dec 27 18:53:00 2018 DMAIN <0000> Transceiver.cpp:1005 [tid=3007431760] new latency: 7:33602 (underrun 6:1683350 vs 5:1683348) as you can see this is very similar to running osmo-bts-trx_0.8.1.194.8564_armhf.deb, but only happened after 18 hours seemingly stable. syslog says: Dec 27 18:53:37 localhost osmo-bts-trx[2166]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 27 18:53:39 localhost osmo-bts-trx[2166]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 27 18:53:41 localhost osmo-bts-trx[2166]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) Dec 27 18:53:43 localhost osmo-bts-trx[2166]: #033[0;m#033[1;33m<000b> trx_if.c:178 No satisfactory response from transceiver for phy0.0 (CMD POWEROFF) so bts-trx and trx-uhd have lost synch with each other. Just restarting trx-uhd resolved the situation, if bts-trx had timed out, it would have restarted, and I assume the whole thing recovered. next time it stops, I will kill -9 bts-trx, it should restart auto, and I will see if it does not matter WHICH process is restarted, I earlier believed the problem was in the trx-uhd, but replacing bts-trx was the factor to go to "almost stable". I will report my findings, if you have any more intelligent suggestions to how to narrow this down, please go ahead..... Regards, Gullik On 2018-12-27 10:15, Gullik Webjorn wrote: > I have had 100% good stability over the night. However, osmo-bts-trx > logs the following every 5-10 minutes. > > There has been no "activity" nightly on the gsm network. > > Gullik > > Dec 27 09:08:57 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:741 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK > Dec 27 09:09:00 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:720 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK > Dec 27 09:10:12 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:741 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK > Dec 27 09:10:15 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:720 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK > Dec 27 09:12:03 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:741 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK > Dec 27 09:12:03 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:920 Store content res. (dl=0xb67ec498) > Dec 27 09:12:04 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 09:12:04 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 09:12:05 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 09:12:06 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:720 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK > > Dec 27 09:17:27 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:741 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK > Dec 27 09:17:27 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:920 Store content res. (dl=0xb67ec498) > Dec 27 09:17:28 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 09:17:29 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 09:17:29 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 09:17:30 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:720 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK > > Dec 27 09:32:46 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:741 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK > Dec 27 09:32:46 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:920 Store content res. (dl=0xb67ec498) > Dec 27 09:32:48 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 09:32:48 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 09:32:48 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 09:32:49 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:720 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK > > Dec 27 09:42:04 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:741 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK > Dec 27 09:42:05 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:920 Store content res. (dl=0xb67ec498) > Dec 27 09:42:06 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 09:42:06 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 09:42:06 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 09:42:08 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:720 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK > > Dec 27 09:47:32 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:741 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK > Dec 27 09:47:32 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:920 Store content res. (dl=0xb67ec498) > Dec 27 09:47:33 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 09:47:34 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 09:47:34 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 09:47:35 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:720 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK > > Dec 27 10:02:51 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:741 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK > Dec 27 10:02:51 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:920 Store content res. (dl=0xb67ec498) > Dec 27 10:02:52 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 10:02:53 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 10:02:53 localhost osmo-bts-trx[20109]: #033[0;m<0011> > lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb67ec498 > state LAPD_STATE_MF_EST) > Dec 27 10:02:54 localhost osmo-bts-trx[20109]: > #033[0;m#033[1;35m<0000> rsl.c:720 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gullik.webjorn at corevalue.se Fri Dec 28 11:17:16 2018 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Fri, 28 Dec 2018 12:17:16 +0100 Subject: Call progress on nightly build In-Reply-To: References: <8d649696-77b6-6149-0a2d-e81ff5e68c33@corevalue.se> <00c7a116-c87d-633b-db5a-36184fad8f79@corevalue.se> <2fed3a6b-24f2-73e1-2d72-ba663ad57e01@corevalue.se> <9f673257-9bdc-2ab9-29cf-d2b9ececd234@sysmocom.de> <86598f32-b8fe-9e9d-22a9-5ec7348dd359@corevalue.se> Message-ID: A newbe find. I just deduced that call progress is PLMN based when using osmo-msc with an external nmcc, such as asterisk. Thus, the solution to the problem "no call progress tones", is to modify the asterisk extensions with a progress statement. Since msc treats mobiles just as a number of sip clients, all calls, including mobile - mobile are directed via the external nmcc, and in this case it is asterisks responsibility to generate "call progress". I modified exten => _07575760XX,1,Dial(SIP/GSM/${EXTEN}) to exten => _07575760XX,1,Progress() exten => _07575760XX,2,Dial(SIP/GSM/${EXTEN}) this did the trick....the insight gets deeper.... Gullik From snehasish.cse at live.com Sat Dec 29 11:53:05 2018 From: snehasish.cse at live.com (Snehasish Kar) Date: Sat, 29 Dec 2018 11:53:05 +0000 Subject: Adding priority for EMLPP service in paging type 1 In-Reply-To: <20181226205830.GB2559@nataraja> References: <81DC58B6-C9B8-4B82-88C1-591F5EFF80EC@gnumonks.org> , <20181226205830.GB2559@nataraja> Message-ID: Snehasish Kar has shared a OneDrive file with you. To view it, click the link below. [https://r1.res.office365.com/owa/prem/images/dc-generic_20.png] emlpp_test.pcapng Hello Harald I have updated the abis_rsl.c. But I have a small confusion, please correct me, the IE for EMLPP is of 2 Bytes out of which the second octet contains only last 3 bits as priority and msgb_tv_put allows to set only one octet, thus on setting anything above 5 it shows call_priority as 0 and anything less than that as 4. Please let me know where I am going wrong.Below is the patch and pcap has been attached. 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, 0x00); + msg->dst = bts->c0->rsl_link; Best Regards 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 holger at freyther.de Sun Dec 30 15:26:53 2018 From: holger at freyther.de (Holger Freyther) Date: Sun, 30 Dec 2018 15:26:53 +0000 Subject: Scaling up virtual bts tests for the BTS test - how I hold it wrong? Message-ID: <079E0BD2-5621-4092-BEAD-EFB6A8E9D812@freyther.de> After a lot of work[1] the gsm tester can finally: * Start a virtual bts * Mobile/virtphy processes * Complete LUs for 10 MS. The next step (besides having a proper test verdict) is scaling this beyond what a simple physical set-up can provide. Let's go to 100+ BTS and 10k subscribers but somehow I am still holding it wrongly and would like to have feedback to see how to evolve the gsm tester. What do I need to change to scale this up and how to externally parameterize it? * suite.conf: Add one line per virtual bts to reserve (I would prefer to specify type+num) * resources.prod.conf: Add more Virtual BTS. I started to pick IPs from 127.0.1.0/24 as it avoids having to configure special IPs. * register_default_mass.py: I need to somehow know how many BTS (and NITBs) were reserved. Or in the long run the topology of how to connect M BTS to N BSCs? Currently I can run until I get an exception but that is not desirable. What's missing: * High-level API of the SuiteRun to get me the toplogy of the network. It seems undesirable in the specific suite to discover how many BTSs were reserved in suite.conf or what the topology is. * ARFCN usage. Besides the redundancy all my BTS currently have the same ARFCN. There should be an easy way to configure an band+arfcn pool. * IMSI/MSISDN pooling. I would like to specify pools of IMSI/MSISDN pairs (and size) and then draw from it. I needs these to program into the mobile, NITB/HLR/AuC and for client to client SMS transfers. * Configure these capacities from the outside. Changing from 1 to 256 BTS should be a single line (or even a parameter change). Any idea or comment on how to achieve this? cheers holger [1] Hindsight is 20/20 and the difficulty was not adding scripting to mobile but getting the GSM tester to spawn the network and we are unfortunately not done yet. From pespin at sysmocom.de Sun Dec 30 23:21:54 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 31 Dec 2018 00:21:54 +0100 Subject: Scaling up virtual bts tests for the BTS test - how I hold it wrong? In-Reply-To: <079E0BD2-5621-4092-BEAD-EFB6A8E9D812@freyther.de> References: <079E0BD2-5621-4092-BEAD-EFB6A8E9D812@freyther.de> Message-ID: <72c0e399-c4dd-a08f-b6f7-bd25fc6dd4af@sysmocom.de> Hi Holger, On 12/30/18 4:26 PM, Holger Freyther wrote: > What do I need to change to scale this up and how to externally parameterize it? > > * suite.conf: > Add one line per virtual bts to reserve (I would prefer to specify type+num) You can already do that, by using the "times" attribute for each object in suite.conf. See for instance what's done in osmo-gsm-tester/suites/gprs/suite.conf: modem: - times: 2 features: - gprs - voice One can similarly do the same to request allocation of 100 sysmoBTS: bts: - type: osmo-bts-sysmo times: 100 > > * resources.prod.conf: > Add more Virtual BTS. I started to pick IPs from 127.0.1.0/24 as it avoids having to configure special IPs. > 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. > > * 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. > > What's missing: > > * High-level API of the SuiteRun to get me the toplogy of the network. It seems undesirable in the specific suite to discover how many BTSs were reserved in suite.conf or what the topology is. See my last text above. > > * 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. There's a task for that, see https://osmocom.org/issues/2230. Unfortunately the algorithm to allocate ARFCN from available ones is a bit complex (lots of restrictions) and wasn't really required so far, so it's not yet implemented. As a workaround, you may want to add a modifier for ARFCN, similar to what is already done for other variables in osmo-gsm-tester/example/scenrios/mod-bts0-*.conf 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: [suite.conf] resources: ip_address: - times: 4 #or as much as needed bts: - band: GSM-1800 times: 2 - band: GSM-900 modifiers: bts: - arfcn: 868 - arfcn: 870 - arfcn: 124 # or whatever is valid for GSM900 * Band attribute should actually be reworked to be a list of supported bands for that BTS, then each BTS in resources.conf have a list with all bands supported by that BTS. * I don't think arfcn modifier is there yet, but not sure now. Grep for "modifier" in suite.py and resource.py to see how it is implemented. > > * IMSI/MSISDN pooling. I would like to specify pools of IMSI/MSISDN pairs (and size) and then draw from it. I needs these to program into the mobile, NITB/HLR/AuC and for client to client SMS transfers. See my comments regarding IP addr pools. Fine for me, but I'm not sure if its needed in this case, since there's already methods to allocate sequentially incrementing MSISDN and IMSI. > > * 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. 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 Mon Dec 31 16:43:00 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 31 Dec 2018 17:43:00 +0100 Subject: OsmoDevCon 2019 registration Message-ID: <20181231164300.GN20066@nataraja> Dear fellow Osmocom developers, I'm a bit surprised to notice that not more people have signed up for OsmoDevCon 2019. I guess it was mostly an oversight when the date was originally announced, and not a lack of interest? ;) All details about the event are available at the related wiki page at: https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019 Please enter your name at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019#Requested in case you would like to attend. Registering early allows proper planning. Thanks! Looking forward to meeting old and new Osmocom developers in April 2019. 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 snehasish.cse at live.com Mon Dec 31 13:34:06 2018 From: snehasish.cse at live.com (Snehasish Kar) Date: Mon, 31 Dec 2018 13:34:06 +0000 Subject: Adding priority for EMLPP service in paging type 1 In-Reply-To: <20181226205830.GB2559@nataraja> References: <81DC58B6-C9B8-4B82-88C1-591F5EFF80EC@gnumonks.org> , <20181226205830.GB2559@nataraja> Message-ID: Snehasish Kar has shared a OneDrive file with you. To view it, click the link below. [https://r1.res.office365.com/owa/prem/images/dc-generic_20.png] emlpp_test 1.pcapng 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: airprobe.pcapng Type: application/x-pcapng Size: 4792548 bytes Desc: airprobe.pcapng URL: