OpenBSC

openbsc@lists.osmocom.org

11 participants
4172 discussions

Osmo-SGSN/3G PS unstable behavior question

by Mykola Shchetinin

Hello, dear Osmocom community, Has somebody been looking at the issue https://osmocom.org/issues/1977 recently? Or, in other words: has anybody got the 3G Packet Switched network working in Osmocom reliably? I am looking for hints that might help me to fix the issue or for possible hacks/fixes if somebody has implemented something like that in their setups. Thank you! Kind regards, Mykola

6 years, 6 months

Limesdr mini on Orange Pi Zero

by Gullik Webjorn

I have now moved the Limesdr mini back and forth between the Orange Pi Zero and a Supermicro (i386). On the Pi Zero I get the following on the console: Tue Jan 22 20:36:43 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043130448] ClockInterface: sending IND CLOCK 321960 Tue Jan 22 20:36:44 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043130448] ClockInterface: sending IND CLOCK 322176 Tue Jan 22 20:36:45 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043130448] chan 0 recv buffer of len 2500 expect 894a7c got 895e68 (895e68) diff=13ec Tue Jan 22 20:36:45 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043130448] chan 0 recv buffer of len 2500 expect 895440 got 897024 (897024) diff=1be4 Tue Jan 22 20:36:45 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043130448] chan 0 recv buffer of len 2500 expect 895e04 got 897de4 (897de4) diff=1fe0 The DDEV message can continue for a long time, and typically then ends with the transceiver exiting. It can however sometimes recover, and the first message of recovery is a IND Clock message, after that the transceiver restarts, and all is again well for some undefined time. I have followed your suggestions, and rebuilt --with-neon-vfpv4 , and I have enabled debugging. If I understand correctly, the function is readSamples, and is the actual input from the Lime rx. The length seems always correct, since I do not get that log entry, but rather that the time has "slipped", i.e. the LMS api has not delivered anything for "diff" time, or the timestamp received has "jumped" in the Lime. This indicates to me that this specific arm cpu in combination with limesdr mini and the software "drops data". I will gladly try to debug or narrow this down, but ask for some suggestions on how to proceed. One thought is to save a timestamp each time through readSamples and compare to some constant to determine that the problem is NOT that we are unable to read as fast as required. reading 2500 samples would take 2.3 mS if I understand this, so we need to cal readsamples at about this rate.... Possible causes could be something *else* locking out the program.

6 years, 6 months

Re: Build failure of network:osmocom:nightly/libosmocore in xUbuntu_18.04/i586

by Neels Hofmeyr

hopefully fixed by https://gerrit.osmocom.org/c/libosmocore/+/12841 ~N On Mon, Feb 04, 2019 at 08:00:24PM +0000, OBS Notification wrote: > Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/l… > > Package network:osmocom:nightly/libosmocore failed to build in xUbuntu_18.04/i586 > > Check out the package for editing: > osc checkout network:osmocom:nightly libosmocore > > Last lines of build log: > [ 369s] - --> N (configured as T-2147483648 18446744073709551615 s) rc=0; state=N T=-2147483648, 2147483647.000000 s remaining > [ 369s] + --> N (configured as T-2147483648 4294967295 s) rc=0; state=N T=-2147483648, 2147483647.000000 s remaining > [ 369s] - test T=0: > [ 369s] --> O (no timer configured for this state) > [ 369s] - test no timer: > [ 369s] --> X (no timer configured for this state) > [ 369s] - test undefined timer, using default_val arg of osmo_tdef_fsm_inst_state_chg(), here passed as 999: > [ 369s] - --> Y (configured as T666 18446744073709551615 -) rc=0; state=Y T=666, 999.000000 s remaining > [ 369s] + --> Y (configured as T666 4294967295 -) rc=0; state=Y T=666, 999.000000 s remaining > [ 369s] - test disallowed transition: > [ 369s] --> Z (no timer configured for this state) > [ 369s] --> B (configured as T2 100 ms) rc=0; state=B T=2, 1.000000 s remaining > [ 369s] 52. testsuite.at:329: 52. tdef (testsuite.at:329): FAILED (testsuite.at:332) > [ 369s] debian/rules:26: recipe for target 'override_dh_auto_test' failed > [ 369s] make[1]: *** [override_dh_auto_test] Error 1 > [ 369s] make[1]: Leaving directory '/usr/src/packages/BUILD' > [ 369s] debian/rules:15: recipe for target 'build' failed > [ 369s] make: *** [build] Error 2 > [ 369s] dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 > [ 369s] > [ 369s] cloud122 failed "build libosmocore_1.0.1.26.0fd6.dsc" at Mon Feb 4 19:59:58 UTC 2019. > [ 369s] > [ 369s] ### VM INTERACTION START ### > [ 372s] [ 336.663635] sysrq: SysRq : Power Off > [ 372s] [ 336.707211] reboot: Power down > [ 377s] ### VM INTERACTION END ### > [ 377s] > [ 377s] cloud122 failed "build libosmocore_1.0.1.26.0fd6.dsc" at Mon Feb 4 20:00:06 UTC 2019. > [ 377s] > > -- > Configure notifications at https://build.opensuse.org/user/notifications > openSUSE Build Service (https://build.opensuse.org/) -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

6 years, 6 months

channel statistics

by Neels Hofmeyr

After 35c3 and talking about statistics, it has become apparent to me that we lack a good way of monitoring channel usage / availability; TL;DR: I think we need min/max aggregators that sync with the stats push/poll time period. This is just an idea I'm getting, not planning on implementing anything now, nor have I really done my homework and tried to achieve useful stats. Has anyone discussed this before / created an issue / solved it in a different way? Here goes... IIUC we have counters that we can poll/push in a given time period, so that the data we get out makes sense and has no "holes" or "overlaps" in it. However, we also have highly volatile numbers that are extremely interesting for an operator to see: how many channels of which kind are currently still available? I asked around and one solution I heard is to poll the CTRL interface once per second and aggregate min/max values before sending on to statistics once per minute. That could be considered close enough, but we can do better. Polling momentary values has holes in it, and doesn't scale well. If, e.g., one new channel request comes in while at the same time another channel is released, we might for a short time hit a situation of no more channels being available, and the polling might just miss that and would show more available channels than we factually had. If hypothetically scaling up such a situation: we might actually have turned down 5 channel requests while the polled number still shows available lchans at all times. So, we should allow: - seeing peak usage - in a pushing-stats fashion - that is still useful when sampled only, say, once per minute. One idea would be to push out a new number as soon as channel availability changes, but that again doesn't scale well (might generate too many events when monitoring a large number of cells). So I'm thinking that we should aggregate the minimum-available lchan counts within osmo-bsc per stats timeframe. There should be separate minimum-available numbers for each lchan kind. I guess minimum-available is more useful than maximum-used lchans, but we could also provide both. Also, if I want to find out how many lchans I need to add to provide adequate service, it would be good to somehow determine the maximum number of "concurrent" turned down channel requests. We probably already have that in a per-second moving average? But here again, if I sample a per-second moving average only once per minute, I will miss the maximum value that this per-second value has reached in that minute. This probably also needs a think-over from a practical "I want useful stats" POV. Or am I missing something? Thanks, ~N -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

6 years, 7 months

Reset GSM tester state?

by Holger Freyther

A wild guess but can any of you check if the GSM tester state is corrupt again? My test with virtual equipment failed the last two times I tried with no IP addresses available and the production run seems broken as well. thank you! holger

6 years, 7 months

Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #372

by jenkins＠lists.osmocom.org

See <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/372/display/redire…> Changes: [laforge] latest-packages: Add libosmo-dsp [laforge] osmocom-*-packages: clone via https:// not via unencrypted git:// ------------------------------------------ [...truncated 738.40 KB...] CC RANAP_RAB-SubflowCombinationBitRate.lo CC RANAP_RAB-TrCH-Mapping.lo CC RANAP_RAB-TrCH-MappingItem.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_RABParametersList.h:14, from RANAP_RABParametersList.c:7: ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:23: warning: ‘struct MemberN’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberN { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberN { ^~~~~~~~~~~~~ In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_RABParametersList.h:14, from RANAP_RABParametersList.c:7: ../../include/osmocom/ranap/RANAP_RABParametersList.h:29:23: warning: ‘struct MemberB’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberB { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_RABParametersList.h:29:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberB { ^~~~~~~~~~~~~ CC RANAP_RAC.lo CC RANAP_RAI.lo CC RANAP_RAListofIdleModeUEs.lo CC RANAP_NotEmptyRAListofIdleModeUEs.lo CC RANAP_RAofIdleModeUEs.lo CC RANAP_LAListofIdleModeUEs.lo CC RANAP_RAT-Type.lo CC RANAP_RateControlAllowed.lo CC RANAP_RedirectAttemptFlag.lo CC RANAP_RedirectionCompleted.lo CC RANAP_RejectCauseValue.lo CC RANAP_RelocationRequirement.lo CC RANAP_RelocationType.lo CC RANAP_RepetitionNumber0.lo CC RANAP_RepetitionNumber1.lo CC RANAP_ReportArea.lo CC RANAP_ReportInterval.lo CC RANAP_ReportAmount.lo CC RANAP_RequestedGPSAssistanceData.lo CC RANAP_RequestedGANSSAssistanceData.lo CC RANAP_RequestedLocationRelatedDataType.lo CC RANAP_RequestedMBMSIPMulticastAddressandAPNRequest.lo CC RANAP_MBMSIPMulticastAddressandAPNlist.lo CC RANAP_RequestedMulticastServiceList.lo CC RANAP_Requested-RAB-Parameter-Values.lo CC RANAP_Requested-RAB-Parameter-ExtendedMaxBitrateList.lo CC RANAP_Requested-RAB-Parameter-ExtendedGuaranteedBitrateList.lo CC RANAP_Requested-RAB-Parameter-MaxBitrateList.lo CC RANAP_Requested-RAB-Parameter-GuaranteedBitrateList.lo CC RANAP_RequestType.lo CC RANAP_ResidualBitErrorRatio.lo CC RANAP_ResponseTime.lo CC RANAP_RIMInformation.lo CC RANAP_RIM-Transfer.lo CC RANAP_RIMRoutingAddress.lo CC RANAP_RNC-ID.lo CC RANAP_RNCTraceInformation.lo CC RANAP_RNSAPRelocationParameters.lo CC RANAP_RRC-Container.lo CC RANAP_RTLoadValue.lo CC RANAP_RSRVCC-HO-Indication.lo CC RANAP_RSRVCC-Information.lo CC RANAP_RSRVCC-Operation-Possible.lo CC RANAP_SAC.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_RABParametersList.h:14, from ../../include/osmocom/ranap/RANAP_RNSAPRelocationParameters.h:14, from RANAP_RNSAPRelocationParameters.c:7: ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:23: warning: ‘struct MemberN’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberN { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberN { ^~~~~~~~~~~~~ In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_RABParametersList.h:14, from ../../include/osmocom/ranap/RANAP_RNSAPRelocationParameters.h:14, from RANAP_RNSAPRelocationParameters.c:7: ../../include/osmocom/ranap/RANAP_RABParametersList.h:29:23: warning: ‘struct MemberB’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberB { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_RABParametersList.h:29:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberB { ^~~~~~~~~~~~~ CC RANAP_SAI.lo CC RANAP_SAPI.lo CC RANAP_SessionUpdateID.lo CC RANAP_Shared-Network-Information.lo CC RANAP_Session-Re-establishment-Indicator.lo CC RANAP_SignallingIndication.lo CC RANAP_SDU-ErrorRatio.lo CC RANAP_SDU-FormatInformationParameters.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:14, from ../../include/osmocom/ranap/RANAP_Shared-Network-Information.h:14, from RANAP_Shared-Network-Information.c:7: ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:23: warning: ‘struct MemberA’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberA { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberA { ^~~~~~~~~~~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:23: warning: ‘struct MemberM’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberM { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberM { ^~~~~~~~~~~~~ CC RANAP_SDU-FormatInformationParameterItem.lo CC RANAP_SDU-Parameters.lo CC RANAP_SDU-ParameterItem.lo CC RANAP_SNA-Access-Information.lo CC RANAP_SNAC.lo CC RANAP_Service-Handover.lo CC RANAP_Source-ToTarget-TransparentContainer.lo CC RANAP_SourceeNodeB-ToTargeteNodeB-TransparentContainer.lo CC RANAP_SourceCellID.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_AuthorisedPLMNs.h:14, from ../../include/osmocom/ranap/RANAP_SNA-Access-Information.h:14, from RANAP_SNA-Access-Information.c:7: ../../include/osmocom/ranap/RANAP_AuthorisedPLMNs.h:27:23: warning: ‘struct MemberC’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberC { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_AuthorisedPLMNs.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberC { ^~~~~~~~~~~~~ CC RANAP_SourceBSS-ToTargetBSS-TransparentContainer.lo CC RANAP_SourceID.lo CC RANAP_SourceRNC-ID.lo CC RANAP_SourceRNC-ToTargetRNC-TransparentContainer.lo CC RANAP_IRAT-Measurement-Configuration.lo CC RANAP_IRATmeasurementParameters.lo CC RANAP_RSRQ-Type.lo CC RANAP_RSRQ-Extension.lo CC RANAP_EUTRANFrequencies.lo CC RANAP_MeasBand.lo CC RANAP_SubscriberProfileIDforRFP.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_EUTRANFrequencies.h:14, from ../../include/osmocom/ranap/RANAP_IRATmeasurementParameters.h:15, from ../../include/osmocom/ranap/RANAP_IRAT-Measurement-Configuration.h:15, from RANAP_IRAT-Measurement-Configuration.c:7: ../../include/osmocom/ranap/RANAP_EUTRANFrequencies.h:27:23: warning: ‘struct MemberJ’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberJ { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_EUTRANFrequencies.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberJ { ^~~~~~~~~~~~~ CC RANAP_SourceStatisticsDescriptor.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_EUTRANFrequencies.h:14, from ../../include/osmocom/ranap/RANAP_IRATmeasurementParameters.h:15, from RANAP_IRATmeasurementParameters.c:7: ../../include/osmocom/ranap/RANAP_EUTRANFrequencies.h:27:23: warning: ‘struct MemberJ’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberJ { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_EUTRANFrequencies.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberJ { ^~~~~~~~~~~~~ CC RANAP_SupportedRAB-ParameterBitrateList.lo CC RANAP_SupportedBitrate.lo CC RANAP_SourceUTRANCellID.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_EUTRANFrequencies.h:14, from RANAP_EUTRANFrequencies.c:7: ../../include/osmocom/ranap/RANAP_EUTRANFrequencies.h:27:23: warning: ‘struct MemberJ’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberJ { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_EUTRANFrequencies.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberJ { ^~~~~~~~~~~~~ CC RANAP_SRB-ID.lo CC RANAP_SRB-TrCH-Mapping.lo CC RANAP_SRB-TrCH-MappingItem.lo CC RANAP_SRVCC-HO-Indication.lo CC RANAP_SRVCC-Information.lo CC RANAP_SRVCC-Operation-Possible.lo CC RANAP_SubflowSDU-Size.lo CC RANAP_TAC.lo CC RANAP_TAI.lo CC RANAP_Target-ToSource-TransparentContainer.lo CC RANAP_TargeteNodeB-ToSourceeNodeB-TransparentContainer.lo CC RANAP_TargetBSS-ToSourceBSS-TransparentContainer.lo CC RANAP_TargetCellId.lo CC RANAP_TargetENB-ID.lo CC RANAP_TargetRNC-ID.lo CC RANAP_TargetID.lo CC RANAP_TargetRNC-ToSourceRNC-TransparentContainer.lo CC RANAP_TBCD-STRING.lo CC RANAP_TemporaryUE-ID.lo CC RANAP_Time-UE-StayedInCell.lo CC RANAP_Time-UE-StayedInCell-EnhancedGranularity.lo CC RANAP_TimeToMBMSDataTransfer.lo CC RANAP_TimingDifferenceULDL.lo /bin/bash: line 1: 9944 Segmentation fault /bin/bash ../../libtool --silent --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.4.0.1-04b5\" -DPACKAGE_STRING=\"osmo-iuh\ 0.4.0.1-04b5\" -DPACKAGE_BUGREPORT=\"openbsc(a)lists.osmocom.org\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"osmo-iuh\" -DVERSION=\"0.4.0.1-04b5\" -DSTDC_HEADERS=1 -I. -Wall -I../../include -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -g -O2 -Wall -MT RANAP_TimeToMBMSDataTransfer.lo -MD -MP -MF .deps/RANAP_TimeToMBMSDataTransfer.Tpo -c -o RANAP_TimeToMBMSDataTransfer.lo RANAP_TimeToMBMSDataTransfer.c Makefile:2506: recipe for target 'RANAP_TimeToMBMSDataTransfer.lo' failed make[4]: *** [RANAP_TimeToMBMSDataTransfer.lo] Error 139 make[4]: *** Waiting for unfinished jobs.... make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src/ranap' Makefile:642: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src' Makefile:454: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src' Makefile:458: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh' Makefile:382: recipe for target 'all' failed make: *** [all] Error 2 [WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully. Emitted 1390 C/C++ compilation units (100%) successfully 1390 C/C++ compilation units (100%) are ready for analysis For more details, please look at: /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt Build step 'Execute shell' marked build as failure

6 years, 7 months

Enable / disable of a bts / trx

by Gullik Webjorn

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

6 years, 7 months

Osmo metrics and counters

by Omar Ramadan

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

6 years, 7 months

TOA loop / reporting

by Sylvain Munaut

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

6 years, 7 months

New osmocom CNI versions released

by Harald Welte

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

6 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC