January 2019 - OpenBSC - lists.osmocom.org

Google Summer of Code 2019

by Vadim Yanitskiy

Dear Osmocom community, starting from 16th of January (until 7th of February) we can apply Google Summer of Code as an Open source mentor organization. Many well-known projects, such as Debian, FFmpeg, Apache, Git, GCC, GNURadio and others, have been participating last year. Personally, I think it's a great opportunity to move some of our projects forward. I would like to know your opinions about this idea, should we participate? I would be happy to be a mentor. With best regards, Vadim Yanitskiy.

5 years, 2 months

6
13
0 0

GSUP: E-interface messages for inter-MSC HO

by Neels Hofmeyr

Hi Oliver, I've already spent some time on a first draft for the new messages we will need to implement the E-interface via GSUP for inter-MSC handover. It would be excellent if you could take over from what I have so far. I placed the draft in osmo-msc/doc/interMSC_HO_GSUP_msgs.txt on my branch neels/ho: http://git.osmocom.org/osmo-msc/tree/doc/interMSC_HO_GSUP_msgs.txt?h=neels/… Anyone else is also more than welcome to take a look and remark on anything that might seem a bad idea, etc. This is the result of me reading a MAP trace of two MSCs negotiating inter-MSC handovers, and of reading the 29.002, 29.010,... specs. I'm not permitted to freely share the trace, let me know if you need details. The most interesting bits in the draft are - the new message types - the newly added IEs (see "Of which are newly added...") The tasks for you would be: - Spell out the protocol messages in common/chapters/gsup.adoc - Implement the definitions in gsup.h - Implement encoding and decoding, and tests It is not so trivial to understand what goes with which message; maybe you don't even need to know in detail? But if any info is still missing for you to grok what's going on, don't hesitate to ask, as always. Also interesting to figure out: Implement the IPA routing for which I added the source_name and destination_name IEs: N osmo-mscs connected to one osmo-hlr forward messages to each other via GSUP. - Connect two GSUP clients (test programs?) to a running osmo-hlr instance, and to extend the gsup_server so that we can use the source_name/destination_name IEs to forward GSUP messages between the two clients. (I added these because I'm fairly certain there is no existing in-band IPA protocol bits that would allow such routing; but I only briefly skimmed it, wouldn't hurt if you could verify that again.) The aim is to have plain gsup_client API to allow me to "just send messages back and fort". - The session_id/session_state: we still need to figure out how to avoid collisions in session_id numbers, as any peer may at any point re-use the same session_id. Vadim suggested using a TI flag that gets flipped between sender and receiver, but since there are more than two peers, I guess we should treat each session_id as subordinate to a Request's source_name. IOW, any peer owns the entire session_id number space itself for sending out Request message types, and a Response or Error message type echos this session_id back with the source_name then having become the destination_name; it is perfectly legal for two peers to use the same session_id and collisions are avoided by Request vs. Response/Error. Something like... MSC-A MSC-B MSC-B' -------> FOO_REQUEST(source=alice, destination=bob, id=3, state=BEGIN) <------- FOO_RESPONSE(source=bob, destination=alice, id=3, state=CONTINUE) -------> BAR_REQUEST(source=alice, destination=bob, id=3, state=CONTINUE) <------- BAR_RESPONSE(source=alice, destination=bob, id=3, state=CONTINUE) ---------------> FOO_REQUEST(source=alice, destination=fred, id=4, state=BEGIN) <--------------- FOO_ERROR(source=fred, destination=alice, id=4, state=CONTINUE) ---------------> END_REQUEST(source=alice, destination=fred, id=4, state=END) -------> END_REQUEST(source=alice, destination=bob, id=3, state=END) (We could possibly omit the source_name in Response/Error message types, because the Requestor already knows the peer from sending out the Request; but for sanity, maybe rather always keep both names.) Does this make sense / am I missing something? - And we need to make sure that we can freely re-use the session_id IE on the E-interface without conflicting with the Supplementary Services session_id / without confusing the gsup_client API. Please create issues on osmocom.org for these tasks as you see fit. There is no pressing need yet to get this done *right now*, I have yet to complete the inter-BSC HO in osmo-msc before I can start using GSUP. But it would be great to just build on working API once I need it. I would be super grateful if you could relieve me of the burden of spelling out these details. From the meetings I assume that sysmocom agrees; please manage that, too, and let me know if any other tasks are more important... Thanks!! ~N -- - Neels Hofmeyr <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

5 years, 3 months

4
11
0 0

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.

5 years, 3 months

2
10
0 0

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

5 years, 3 months

2
1
0 0

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

5 years, 3 months

4
5
0 0

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

5 years, 3 months

2
2
0 0

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

5 years, 3 months

2
1
0 0

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.

5 years, 3 months

3
3
0 0

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

5 years, 3 months

2
1
0 0

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

5 years, 3 months

1
0
0 0

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

by jenkins＠lists.osmocom.org

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

5 years, 3 months

1
1
0 0

msgb_wrap_with_TL(): the hallmark of wrong choices made

by Neels Hofmeyr

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

5 years, 3 months

2
3
0 0

OS#3764: backward compatibility: It's not just API

by Harald Welte

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

5 years, 3 months

1
0
0 0

Problems installing libosmocore / gr-gsm on my Mac

by Andrea Pellegrin

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

5 years, 3 months

3
2
0 0

Scaling up virtual bts tests for the BTS test - how I hold it wrong?

by Holger Freyther

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.

5 years, 3 months

2
5
0 0

tagging new versions / problems

by Harald Welte

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

5 years, 3 months

3
4
0 0

two general code review questions

by Neels Hofmeyr

Should we now put copyright comments in header files as well? re https://gerrit.osmocom.org/c/osmo-msc/+/11642/3/include/osmocom/msc/sgs_ifa… When I see structs containing talloc'd char*, should I generally give code review to use fixed char arrays instead? I think it ends up being simpler semantically as well as better in terms of mem allocation. Right? e.g. https://gerrit.osmocom.org/c/osmo-msc/+/11642/30/include/osmocom/msc/sgs_se… and #21 Thanks for your opinions... ~N

5 years, 4 months

2
2
0 0

SMS sm_rp_mr set only when conn already established

by Neels Hofmeyr

Hi folks, just now while resolving some unrelated merge conflict, I notice this bit of code we have in osmo-msc master. (It has recently been tweaked, but the code in question has been like this for a long time.) https://git.osmocom.org/osmo-msc/tree/src/libmsc/gsm_04_11.c#n1057 static struct gsm_trans *gsm411_alloc_mt_trans(struct gsm_network *net, struct vlr_subscr *vsub) { struct ran_conn *conn; struct gsm_trans *trans; int tid; LOGP(DLSMS, LOGL_INFO, "Going to send a MT SMS\n"); /* Generate a new transaction ID */ tid = trans_assign_trans_id(net, vsub, GSM48_PDISC_SMS, 0); if (tid == -1) { LOGP(DLSMS, LOGL_ERROR, "No available transaction IDs\n"); return NULL; } /* Attempt to find an existing connection */ conn = connection_for_subscr(vsub); /* Allocate a new transaction */ trans = gsm411_trans_init(net, vsub, conn, tid); if (!trans) return NULL; if (conn) { <===== if no active communication, this is NULL /* Generate unique RP Message Reference */ trans->sms.sm_rp_mr = conn->next_rp_ref++; <===== here } /* Use SAPI 3 (see GSM 04.11, section 2.3) */ trans->dlci = UM_SAPI_SMS; return trans; } We often create an MT SMS transaction when no connection to the subscriber is currently available, which is the case if we create the SMS transaction and only page later. (To prove that, the call flow is gsm411_send_sms(vsub) trans = gsm411_alloc_mt_trans(vsub) gsm411_rp_sendmsg(trans) gsm411_smr_send() srdownstatelist[0] = gsm411_rl_data_req() gsm411_mn_send() gsm411_mm_send() gsm411_mmsms_est_req() trans->paging_request = subscr_request_conn(...) ) But we only assign an sm_rp_mr reference number when the conn is already present. That means when we send an SMS, the sm_rp_mr reference is unset when we still need to page first?? Does anyone know this code well? I'm almost certain we should always set an RP reference? (i.e. drop the 'if (conn)' condition) What errors could arise from this? It seems that we would always send an RP reference of zero for all SMS that require paging. Could that be a reason Rhizomatica sometimes saw SMS delivered to the wrong recipient? So, does anyone already know that I'm on the wrong track here -- otherwise I'll create an issue for this, probably also needing tests. ~N

5 years, 4 months

2
2
0 0

Checking out LimeSDR Mini with osmocom. It seems good!!

by Gullik Webjorn

Tue 15-jan-2019 LimeSDR transmit check. Fired up old HP 8614A signal generator at 1880 Mhz, and let it stabilize for 1 hour. Level measurement after adjusting ALC, 0dBm = -0.4 dBm as checked with spectrum analyzer Checked level with HP L423A probe. Check of LimeSDR mini output. Output as seen on spectrum analyzer -1.0 dBm. This correlates with LMS7002 datasheet with a possible 1 dB loss between chip and analyzer, including SMA-BNC coax adapter, 2 m foam insulated RG58 size cable, BNC - N connector. So, for practical purposes the LimeSDR mini provides 0 dBm ( +/- 1.4 dBm ) LimeSDR receive check. Receive antenna rigged with a 1/10 dB splitter, -10 dB port connected to spectrum analyzer, -1 dB port to LimeSDR. Connect single Nokia Handset, and make a call from osmobsc to fixed phone, so that only one mobile is using TCH. Move phone to get different uplink levels and correlate these to spectrum analyzer. Since carrier is TDMA, use peak hold on analyzer. Active subscriber connections: conn ID=31, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1@mgw BTS 1, TRX 0, Timeslot 1, Lchan 0: Type TCH_F Connection: 1, State: ESTABLISHED BS Power: 10 dBm, MS Power: 10 dBm Channel Mode / Codec: SPEECH_V1 No Subscriber Bound IP: 192.168.1.75 Port 16384 RTP_TYPE2=0 CONN_ID=0 Conn. IP: 192.168.1.70 Port 4110 RTP_TYPE=3 SPEECH_MODE=0x00 Measurement Report: Flags: MS Timing Offset: 0 L1 MS Power: 10 dBm, Timing Advance: 4 RXL-FULL-dl: -51 dBm, RXL-SUB-dl: -51 dBm RXQ-FULL-dl: 0, RXQ-SUB-dl: 0 RXL-FULL-ul: -54 dBm, RXL-SUB-ul: -54 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 Level on uplink -54 dBm, indicated on spectrum analyzer -53 (-63) dBm. OsmoBSC# show conn Active subscriber connections: conn ID=31, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1@mgw BTS 1, TRX 0, Timeslot 1, Lchan 0: Type TCH_F Connection: 1, State: ESTABLISHED BS Power: 10 dBm, MS Power: 10 dBm Channel Mode / Codec: SPEECH_V1 No Subscriber Bound IP: 192.168.1.75 Port 16384 RTP_TYPE2=0 CONN_ID=0 Conn. IP: 192.168.1.70 Port 4110 RTP_TYPE=3 SPEECH_MODE=0x00 Measurement Report: Flags: MS Timing Offset: 0 L1 MS Power: 10 dBm, Timing Advance: 4 RXL-FULL-dl: -69 dBm, RXL-SUB-dl: -69 dBm RXQ-FULL-dl: 0, RXQ-SUB-dl: 0 RXL-FULL-ul: -59 dBm, RXL-SUB-ul: -59 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 Mobile moved to another location within the lab. Level on uplink -59 dBm, indicated on spectrum analyzer -60 (-70) dBm. Conclusion: For such a simple low cost SDR, the accuracy seems within a couple of dB. Instruments used were are not "professional grade", at least not w.r. 2019, but I estimate I can measure within +/- 2 dB or so with this crude config. Power output is 10 times lower than I expected, I was probably mislead by some review on the web, and had to go down to the actual scematic and datasheet to understand that the expected level should be around 0 dBm. (thanks for pointing this out, Harald) For practical use outside a lab output is far too low. My plan is to add a small simple booster to bring level up to +15 which would allow me to cover my 2 acre lot without breaking any rules. Else, I am impressed, good value for a low price tag. I had expected far worse than indicated accuracy. Best Regards, Gullik

5 years, 4 months

2
2
0 0

Re: Re: Re: OsmoTRX - osmo-trx-usrp-1 Aborted :: Assertion 'px != 0' failed

by Sergey Mayzus

5 years, 4 months

1
0
0 0

osmo-hlr db upgrade behavior poll

by Neels Hofmeyr

Hi all, when reviewing osmo-hlr db schema upgrades, I came up with the idea that we shouldn't upgrade automatically. That's why, for schema updates, osmo-hlr now refuses to start and requires one start with the --db-upgrade option. Our systemd service file does not include that option. The result is that after an upgraded osmo-hlr binary, admins may have to take extra action to upgrade the DB. The rationale is that if someone by accident launches a newer osmo-hlr only once, with automatic upgrade the user is then stuck with the newer version DB, since we don't make a backup and we don't provide a downgrade path. I'm now wondering whether that is really necessary. In the daily churn, it creates noise. How to make this less noisy? - Users could add the --db-upgrade option to the service file to always upgrade. (But it is cumbersome to have a .service file that differs from the installed version) - We could also add a cfg file option to allow-db-upgrades. - We could drop the behavior and always upgrade. In the lack of strong opinions, this will probably stay as it is. I'd just like to hear what you guys think about it. Is it annoying or a good idea? Thanks! ~N

5 years, 4 months

4
4
0 0

default TA vty config for OSMO-PCU?

by Keith

Hey list.. so i want to do some experiments setting the default TA in the PCU to the distance from the tower to the main population centre, rather than have it set to 220 (invalid) So, this email is not about the details of that issue, rather just a quick question. In the interim while this gets finally done right, would we accept adding a default-timing-advance param to the vty config? Otherwise I can patch and compile version for each BTS, but the vty config would be WAY more handy! thnx k/

5 years, 4 months

2
2
0 0

SMS Sender Name Using Alphanumeric Characters

by Ron

Hi Community, Is it possible to send SMS using alphanumeric characters as a sender address? We tried it using an Open-Source SMS GW and it can send alphanumeric information in the sender address. Unfortunately, the SMS sent through API was not received to the test phone and the logs below are seen in OSMO-MSC. <000c> smpp_smsc.c:729 [entropy] Rx SUBMIT-SM (09170000023/1/1) <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. We also tried sending SMS with only Numeric information in the sender address and the SMS was received successfully by the test phone. We can share the traces taken and the configurations used if needed. TIA. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

5 years, 4 months

3
5
0 0

A ramble about MSC, sip-connector and asterisk.

by Gullik Webjorn

Hi, Some weeks ago I managed to integrate osmobts with my asterisk server. In the beginning, I did not get any call progress, ( as opposed to running WITHOUT asterisk ). I realized that defining the msc to sipconnector socket effectively disabled all the logic related to this. To remedy the situation, I set an asterisk "progress statement" whenever the extensions.conf indicated a number belonging to my GSM network. This works OK, but now, I don't get call progress on calls toward PSTN. These extensions do not have "progress" statements, since all SIP phones interpret the call progress sip messages such as RINGING. I am interested in your comments whether msc + sipconnector should emulate mobiles as "sip phones", it does seem to just silently drop call progress messages, and is this the way it should work? The functionality IS there, since when osmobts was bridging the calls, call progress WAS there. Well, I kludged up a solution for the GSM-only situation, and this seems suboptimal. I guess some clever asterisk hacking would solve that, possibly having a redundant progress statement on ALL extensions would do it, but would I not lose "actual" call progress signals from the PSTN, since asterisk would emulate them? Another way would be a small "local" asterisk.....before the *real* one. Boldly moving on to MultiBTS and handover.... Gullik

5 years, 4 months

4
4
0 0

OsmoTRX + LimeSDR + Pine64

by Alex

Hi everyone, I'm facing a little strange problem with latest version of OsmoTRX and LimeSDR on a Pine64 board. I've built everything from source (latest git commit) Here is the console output of osmo-trx-lms root@pine64:~/osmo-trx# osmo-trx-lms -C /opt/osmocom/etc/osmo-trx-limesdr.cfg Sun Jan 13 22:11:40 2019 DLGLOBAL <0004> telnet_interface.c:104 Available via telnet 127.0.0.1 4237 Sun Jan 13 22:11:40 2019 DLCTRL <000b> control_if.c:911 CTRL at 127.0.0.1 4236 Sun Jan 13 22:11:40 2019 DMAIN <0000> osmo-trx.cpp:430 [tid=281473725702144] Config Settings Log Level............... 0 Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 GSM BTS Address......... 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ 0 Reference............... 0 C0 Filler Table......... 1 Multi-Carrier........... 0 Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 Tx Antennas............. 'BAND1' Rx Antennas............. 'LNAW' Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:68 [tid=281473725702144] creating LMS device... Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:156 [tid=281473725702144] Opening LMS device.. Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:162 [tid=281473725702144] Devices found: 1 Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:172 [tid=281473725702144] Device [0]: LimeSDR Mini, media=USB 2.0, module=FT601, addr=24607:1027, serial=1D4259C8DFD3CD Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:181 [tid=281473725702144] Using device[0] Sun Jan 13 22:11:40 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] Reference clock 40.00 MHz Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:191 [tid=281473725702144] Init LMS device Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:113 [tid=281473725702144] Sample Rate: Min=100000 Max=3.072e+07 Step=0 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:201 [tid=281473725702144] Setting sample rate to 1.08333e+06 4 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:207 [tid=281473725702144] Sample Rate: Host=1.08333e+06 RF=3.46667e+07 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:214 [tid=281473725702144] Setting Internal clock reference Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:218 [tid=281473725702144] Setting VCTCXO to 180 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:113 [tid=281473725702144] LPFBWRange Rx: Min=1.4001e+06 Max=1.3e+08 Step=0 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:113 [tid=281473725702144] LPFBWRange Tx: Min=1.4001e+06 Max=1.3e+08 Step=0 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:242 [tid=281473725702144] LPFBW: Rx=1.4001e+06 Tx=5.2e+06 Sun Jan 13 22:11:41 2019 DMAIN <0000> LMSDevice.cpp:203 [tid=281473725702144] Antennas configured successfully Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:251 [tid=281473725702144] Setting LPFBW chan 0 Sun Jan 13 22:11:44 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] RX LPF configured Sun Jan 13 22:11:44 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] Filter calibrated. Filter order-4th, filter bandwidth set to 5.2 MHz.Real pole 1st order filter set to 2.5 MHz. Preemphasis filter not active Sun Jan 13 22:11:44 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] TX LPF configured Sun Jan 13 22:11:44 2019 DDEV <0002> LMSDevice.cpp:256 [tid=281473725702144] Calibrating chan 0 Sun Jan 13 22:11:44 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] Rx calibration finished Sun Jan 13 22:11:44 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] Tx calibration finished osmo-trx-lms: Threads.cpp:133: void Thread::start(void* (*)(void*), void*): Assertion `!res' failed. signal 6 received talloc report on 'OsmoTRX' (total 3427 bytes in 17 blocks) telnet_connection contains 1 bytes in 1 blocks (ref 0) 0xf748b60 logging contains 3043 bytes in 9 blocks (ref 0) 0xf6c44f0 struct trx_ctx contains 383 bytes in 5 blocks (ref 0) 0xf6c4220 msgb contains 0 bytes in 1 blocks (ref 0) 0xf6c41b0 full talloc report on 'OsmoTRX' (total 3427 bytes in 17 blocks) telnet_connection contains 1 bytes in 1 blocks (ref 0) 0xf748b60 logging contains 3043 bytes in 9 blocks (ref 0) 0xf6c44f0 Configure logging Set the log level for a specified category Main generic category TRX CTRL interface Device/Driver specific code Logging from within LimeSuite itself Library-internal global log family LAPD in libosmogsm A-bis Intput Subsystem A-bis B-Subchannel TRAU Frame Multiplex A-bis Input Driver for Signalling A-bis Input Driver for B-Channels (voice) Layer3 Short Message Service (SMS) Control Interface GPRS GTP library Statistics messages and logging Generic Subscriber Update Protocol Osmocom Authentication Protocol libosmo-sigtran Signalling System 7 libosmo-sigtran SCCP Implementation libosmo-sigtran SCCP User Adaptation libosmo-sigtran MTP3 User Adaptation libosmo-mgcp Media Gateway Control Protocol libosmo-netif Jitter Buffer Deprecated alias for 'no logging level force-all' contains 798 bytes in 1 blocks (ref 0) 0xf7019a0 logging level (main|trxctrl|dev|lms|lglobal|llapd|linp|lmux|lmi|lmib|lsms|lctrl|lgtp|lstats|lgsup|loap|lss7|lsccp|lsua|lm3ua|lmgcp|ljibuf) everything contains 150 bytes in 1 blocks (ref 0) 0xf7017f0 Configure logging Set the log level for a specified category Main generic category TRX CTRL interface Device/Driver specific code Logging from within LimeSuite itself Library-internal global log family LAPD in libosmogsm A-bis Intput Subsystem A-bis B-Subchannel TRAU Frame Multiplex A-bis Input Driver for Signalling A-bis Input Driver for B-Channels (voice) Layer3 Short Message Service (SMS) Control Interface GPRS GTP library Statistics messages and logging Generic Subscriber Update Protocol Osmocom Authentication Protocol libosmo-sigtran Signalling System 7 libosmo-sigtran SCCP Implementation libosmo-sigtran SCCP User Adaptation libosmo-sigtran MTP3 User Adaptation libosmo-mgcp Media Gateway Control Protocol libosmo-netif Jitter Buffer Log debug messages and higher levels Log informational messages and higher levels Log noticeable messages and higher levels Log error messages and higher levels Log only fatal messages contains 933 bytes in 1 blocks (ref 0) 0xf7013e0 logging level (main|trxctrl|dev|lms|lglobal|llapd|linp|lmux|lmi|lmib|lsms|lctrl|lgtp|lstats|lgsup|loap|lss7|lsccp|lsua|lm3ua|lmgcp|ljibuf) (debug|info|notice|error|fatal) contains 171 bytes in 1 blocks (ref 0) 0xf701230 struct log_target contains 214 bytes in 2 blocks (ref 0) 0xf6c4940 struct log_category contains 46 bytes in 1 blocks (ref 0) 0xf6c4a50 struct log_info contains 776 bytes in 2 blocks (ref 0) 0xf6c4560 struct log_info_cat contains 736 bytes in 1 blocks (ref 0) 0xf6c45f0 struct trx_ctx contains 383 bytes in 5 blocks (ref 0) 0xf6c4220 LNAW contains 5 bytes in 1 blocks (ref 0) 0xf748fd0 BAND1 contains 6 bytes in 1 blocks (ref 0) 0xf748ec0 127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0xf6c4470 127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0xf6c43f0 msgb contains 0 bytes in 1 blocks (ref 0) 0xf6c41b0 Aborted Can someone provide me a little light on this? I've some doubts about the usb power output, but I'm facing this also with a powered usb hub. Thank you and best regards Alex

5 years, 4 months

2
3
0 0

SMS Sender Name using Alphanumeric

by Ron

Hi Community, Is it possible to send SMS using alphanumeric information as a sender address? We tried it using an Open-Source SMS GW and it can send alphanumeric information in the sender address. Unfortunately, the SMS sent through API was not received to the test phone and the logs below are seen in OSMO-MSC. <000c> smpp_smsc.c:729 [entropy] Rx SUBMIT-SM (09170000023/1/1) <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. We also tried sending SMS with only Numeric information in the sender address and the SMS was received successfully by the test phone. Also attached in this email are the traces and configuration files used and taken during the testing. Kindly advice if we missed something in our configuration. TIA. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

5 years, 4 months

1
0
0 0

GSM MS Tx power levels (was Re: uncalibrated general-purpose SDRs (was Re: Balancing BTS'es for handover))

by Mychaela Falconia

Harald Welte wrote: > [...] the big difference is that the mobile has been calibrated to > (if I remember) 2dB accuracy, The GSM 05.05 spec indeed sets a tolerance of 2 dB under normal conditions or 2.5 dB under extreme conditions on the mobile station's maximum power output level for each band. These tolerances get looser for the lower power control level, up to 5 dB under normal conditions or 6 dB under extreme conditions for the lowest PCL. However, as someone who is intimately familiar with the actual calibration procedures performed by MS manufacturers (just did it myself less than 48 hours ago for a new batch of boards), I can tell you how it is actually done. There is a table of target power levels in dBm, and the calibration station goes through the full set of allowed PCLs (5-19 for EGSM and GSM850, or 0-15 for DCS and PCS) and steers the Tx power output (as measured by the test instrument, usually R&S CMU200) for each PCL to the dBm number in the table. But there is a hack in this setup which most MS manufacturers fail to disclose: with all GSM MS RF designs I have laid my hands on so far, including the one I've inherited from Openmoko (OK, I admit that all of my experience is with old stuff, not any of the recent stuff from MTK or Spreadtrum, but don't blame me, blame MTK and Spreadtrum for not publicly releasing their full chip docs and reference firmware source code), the MS hardware is oftentimes not actually capable of putting out the maximum power output prescribed by the spec (33 dBm for low bands or 30 dBm for high bands) while staying in the linear range of the PA (the range in which the relation between the APC control voltage and RF Vout is mostly linear), and thus the calibration procedure has to be fudged. In the case of Openmoko, they set the calibration targets for the highest power levels to 31.8 dBm and 28.8 dBm instead of 33/30 (for low and high bands, respectively), the next PCL down is set to 30.5/27.5 instead of 31/28, and then the proper official numbers from the spec further down. I have to do the same on my current GSM MS boards: when I tried putting out the full 33/30 dBm at the maximum PCL as the spec calls for, I can usually hit it if I crank the PA really high, but then it goes out of its linear range, and lacking better RF kung-fu, I have to assume that it's bad.. The maximum Tx power level fudging done by manufacturers in my or Openmoko's position is 1.2 dB, which is less than the spec tolerance of 2 dB, thus manufacturers like OM who did this fudging had no problems passing type approval tests, but I really wish I could find someone with more professional GSM MS design and manufacturing experience who could explain what actually happens, why we are not able hit the highest power levels while staying in the PA's linear range (the PA datasheet says it can put out 34.2 dBm in the low bands and 32.0 dBm in the high bands), and how the RF hw design might be improved so we can put out the highest power levels without fudging. Aside from the just-described fudging, the actual calibration tolerance (the maximum error between what the calibration procedure aims for and what actually comes out as measured by the CMU200) is less than 0.7 dB - and those ~0.5-0.6 dB errors happen mostly toward the lower power levels where the spec tolerances are the loosest; the maximum power level is calibrated to the shifted target number to better than 0.1 dB. M~

5 years, 4 months

1
0
0 0

Balancing BTS'es for handover

by Gullik Webjorn

Below is a measurement on my "most distant" BTS, BTS 1. From what I see, downlink is 35 dB below uplink, which of course is natural when the MS can produce 30 dBm, and the BTS which in this case uses a bareback Limesdr min, can only produce 10 dBm. the bsc parameter ms max power is set to 15 for both bts 0 and bts 1. However, it seems MS output power is *much* stronger. Further, my understanding is that it is the BTS level measurements that decides when to handover, i.e. measurements in the upstream, and not the MS receive levels... Since there is such a mismatch between the micro BTS and the MS, maybe the RX should be attenuated, to bring upsteram levels more equal to downstream. OsmoBSC# show conns Active subscriber connections: conn ID=6, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1@mgw BTS 0, TRX 0, Timeslot 1, Lchan 0: Type TCH_F Connection: 1, State: ESTABLISHED BS Power: 20 dBm, MS Power: 16 dBm Channel Mode / Codec: SPEECH_V1 No Subscriber Bound IP: 127.0.0.1 Port 16390 RTP_TYPE2=0 CONN_ID=0 Conn. IP: 192.168.1.70 Port 4186 RTP_TYPE=3 SPEECH_MODE=0x00 Measurement Report: Flags: MS Timing Offset: 0 L1 MS Power: 16 dBm, Timing Advance: 0 RXL-FULL-dl: -110 dBm, RXL-SUB-dl: -110 dBm RXQ-FULL-dl: 5, RXQ-SUB-dl: 5 RXL-FULL-ul: -74 dBm, RXL-SUB-ul: -73 dBm RXQ-FULL-ul: 3, RXQ-SUB-ul: 1 What are *your* experiences with "power control" and with "handover". Best Regards, Gullik

5 years, 4 months

3
5
0 0

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

by jenkins＠lists.osmocom.org

See <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/356/display/redire…> ------------------------------------------ [...truncated 723.64 KB...] CC RANAP_GeographicalArea.lo CC RANAP_GeographicalCoordinates.lo CC RANAP_GA-EllipsoidArc.lo CC RANAP_GA-AltitudeAndDirection.lo CC RANAP_GA-Point.lo CC RANAP_GA-PointWithAltitude.lo CC RANAP_GA-PointWithAltitudeAndUncertaintyEllipsoid.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_IE-Extensions.h:15, from ../../include/osmocom/ranap/RANAP_GeographicalCoordinates.h:16, from ../../include/osmocom/ranap/RANAP_GA-Point.h:14, from ../../include/osmocom/ranap/RANAP_GeographicalArea.h:14, from RANAP_GeographicalArea.c:7: ../../include/osmocom/ranap/RANAP_GA-Polygon.h:26:23: warning: ‘struct Member’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct Member { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_GA-Polygon.h:26:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct Member { ^~~~~~~~~~~~~ CC RANAP_GA-PointWithUnCertainty.lo CC RANAP_GA-PointWithUnCertaintyEllipse.lo CC RANAP_GA-Polygon.lo CC RANAP_GA-UncertaintyEllipse.lo CC RANAP_GERAN-BSC-Container.lo CC RANAP_GERAN-Cell-ID.lo CC RANAP_GERAN-Classmark.lo CC RANAP_GlobalCN-ID.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_GA-Polygon.h:14, from RANAP_GA-Polygon.c:7: ../../include/osmocom/ranap/RANAP_GA-Polygon.h:26:23: warning: ‘struct Member’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct Member { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_GA-Polygon.h:26:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct Member { ^~~~~~~~~~~~~ CC RANAP_GlobalRNC-ID.lo CC RANAP_GTP-TEI.lo CC RANAP_GuaranteedBitrate.lo CC RANAP_HigherBitratesThan16MbpsFlag.lo CC RANAP_HS-DSCH-MAC-d-Flow-ID.lo CC RANAP_IMEI.lo CC RANAP_IMEIGroup.lo CC RANAP_IMEIList.lo CC RANAP_IMEISV.lo CC RANAP_IMEISVGroup.lo CC RANAP_IMEISVList.lo CC RANAP_ImmediateMDT.lo CC RANAP_IMSI.lo CC RANAP_IncludeVelocity.lo CC RANAP_InformationExchangeID.lo CC RANAP_InformationExchangeType.lo CC RANAP_InformationRequested.lo CC RANAP_InformationRequestType.lo CC RANAP_InformationTransferID.lo CC RANAP_InformationTransferType.lo CC RANAP_IntegrityProtectionAlgorithm.lo CC RANAP_IntegrityProtectionInformation.lo CC RANAP_IntegrityProtectionKey.lo CC RANAP_InterSystemInformationTransferType.lo CC RANAP_InterSystemInformation-TransparentContainer.lo CC RANAP_IPMulticastAddress.lo CC RANAP_IuSignallingConnectionIdentifier.lo CC RANAP_KeyStatus.lo CC RANAP_IuTransportAssociation.lo CC RANAP_LA-LIST.lo CC RANAP_LAC.lo CC RANAP_LAI.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_LA-LIST.h:14, from RANAP_LA-LIST.c:7: ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:23: warning: ‘struct MemberA’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberA { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberA { ^~~~~~~~~~~~~ CC RANAP_LastKnownServiceArea.lo CC RANAP_LastVisitedUTRANCell-Item.lo CC RANAP_LHN-ID.lo CC RANAP_Links-to-log.lo CC RANAP_ListOF-SNAs.lo CC RANAP_ListOfInterfacesToTrace.lo CC RANAP_InterfacesToTraceItem.lo CC RANAP_LoadValue.lo CC RANAP_LocationRelatedDataRequestType.lo CC RANAP_LocationRelatedDataRequestTypeSpecificToGERANIuMode.lo CC RANAP_LocationReportingTransferInformation.lo CC RANAP_ReportChangeOfSAI.lo CC RANAP_PeriodicReportingIndicator.lo CC RANAP_DirectReportingIndicator.lo CC RANAP_L3-Information.lo CC RANAP_M1Report.lo CC RANAP_M2Report.lo CC RANAP_M4Report.lo CC RANAP_M4-Collection-Parameters.lo CC RANAP_M4-Period.lo CC RANAP_M4-Threshold.lo CC RANAP_M5Report.lo CC RANAP_M5-Period.lo CC RANAP_M6Report.lo CC RANAP_M6-Period.lo CC RANAP_M7Report.lo CC RANAP_M7-Period.lo CC RANAP_Management-Based-MDT-Allowed.lo CC RANAP_MaxBitrate.lo CC RANAP_MaxSDU-Size.lo CC RANAP_MBMS-PTP-RAB-ID.lo CC RANAP_MBMSBearerServiceType.lo CC RANAP_MBMSCNDe-Registration.lo CC RANAP_MBMSCountingInformation.lo CC RANAP_MBMSHCIndicator.lo CC RANAP_MBMSIPMulticastAddressandAPNRequest.lo CC RANAP_MBMSLinkingInformation.lo CC RANAP_MBMSRegistrationRequestType.lo CC RANAP_MBMSServiceArea.lo CC RANAP_MBMSSessionDuration.lo CC RANAP_MBMSSessionIdentity.lo CC RANAP_MBMSSessionRepetitionNumber.lo CC RANAP_MDT-Activation.lo CC RANAP_MDTAreaScope.lo CC RANAP_MDT-Configuration.lo CC RANAP_MDTMode.lo CC RANAP_MDT-PLMN-List.lo CC RANAP_MDT-Report-Parameters.lo CC RANAP_MeasurementQuantity.lo CC RANAP_MeasurementsToActivate.lo CC RANAP_MSISDN.lo CC RANAP_NAS-SequenceNumber.lo CC RANAP_NAS-PDU.lo CC RANAP_NAS-SynchronisationIndicator.lo CC RANAP_NewBSS-To-OldBSS-Information.lo CC RANAP_NonSearchingIndication.lo CC RANAP_NRTLoadInformationValue.lo CC RANAP_NumberOfIuInstances.lo CC RANAP_NumberOfSteps.lo CC RANAP_Offload-RAB-Parameters.lo CC RANAP_Offload-RAB-Parameters-APN.lo CC RANAP_Offload-RAB-Parameters-ChargingCharacteristics.lo CC RANAP_OldBSS-ToNewBSS-Information.lo CC RANAP_OMC-ID.lo CC RANAP_Out-Of-UTRAN.lo CC RANAP_PagingAreaID.lo CC RANAP_PagingCause.lo CC RANAP_PDP-TypeInformation.lo CC RANAP_PDP-Type.lo CC RANAP_PDP-TypeInformation-extension.lo CC RANAP_PDP-Type-extension.lo CC RANAP_PDUType14FrameSequenceNumber.lo CC RANAP_PeriodicLocationInfo.lo CC RANAP_PermanentNAS-UE-ID.lo CC RANAP_PermittedEncryptionAlgorithms.lo CC RANAP_PermittedIntegrityProtectionAlgorithms.lo CC RANAP_LABased.lo CC RANAP_LAI-List.lo CC RANAP_LoggedMDT.lo CC RANAP_LoggingInterval.lo CC RANAP_LoggingDuration.lo CC RANAP_PLMNidentity.lo CC RANAP_PLMNs-in-shared-network.lo CC RANAP_Port-Number.lo CC RANAP_PositioningDataDiscriminator.lo CC RANAP_PositioningDataSet.lo CC RANAP_PositioningMethodAndUsage.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:14, from RANAP_PLMNs-in-shared-network.c:7: ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:23: warning: ‘struct MemberA’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberA { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberA { ^~~~~~~~~~~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:23: warning: ‘struct MemberM’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberM { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberM { ^~~~~~~~~~~~~ CC RANAP_PositioningPriority.lo CC RANAP_PositionData.lo CC RANAP_PositionDataSpecificToGERANIuMode.lo CC RANAP_Pre-emptionCapability.lo CC RANAP_Pre-emptionVulnerability.lo CC RANAP_PriorityLevel.lo CC RANAP_Priority-Class-Indicator.lo CC RANAP_ProvidedData.lo CC RANAP_P-TMSI.lo /bin/bash: line 1: 2491 Illegal instruction /bin/bash ../../libtool --silent --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.13-45696\" -DPACKAGE_STRING=\"osmo-iuh\ 0.3.0.13-45696\" -DPACKAGE_BUGREPORT=\"openbsc(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.3.0.13-45696\" -DSTDC_HEADERS=1 -I. -Wall -I../../include -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -g -O2 -Wall -MT RANAP_PriorityLevel.lo -MD -MP -MF .deps/RANAP_PriorityLevel.Tpo -c -o RANAP_PriorityLevel.lo RANAP_PriorityLevel.c Makefile:2506: recipe for target 'RANAP_PriorityLevel.lo' failed make[4]: *** [RANAP_PriorityLevel.lo] Error 132 make[4]: *** Waiting for unfinished jobs.... In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:14, from ../../include/osmocom/ranap/RANAP_Shared-Network-Information.h:14, from ../../include/osmocom/ranap/RANAP_ProvidedData.h:14, from RANAP_ProvidedData.c:7: ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:23: warning: ‘struct MemberA’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberA { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberA { ^~~~~~~~~~~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:23: warning: ‘struct MemberM’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberM { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberM { ^~~~~~~~~~~~~ make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src/ranap' Makefile:642: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src' Makefile:454: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src' Makefile:458: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh' Makefile:382: recipe for target 'all' failed make: *** [all] Error 2 [WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully. Emitted 1161 C/C++ compilation units (100%) successfully 1161 C/C++ compilation units (100%) are ready for analysis For more details, please look at: /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt Build step 'Execute shell' marked build as failure

5 years, 4 months

1
1
0 0

Status of 2-bts osmobts @ gullik

by Gullik Webjorn

Just a short update: Orange Pi Zero (armhf) + Ettus B100 ARFCN 871 osmo-trx-uhd_0.4.0.124 unstable after 5-120 minutes. Supermicro I386 + Limesdr mini ARFCN 881 osmo-trx-lms_0.4.0_i386 (built from latest source ) relatively stable. Incoming and outgoing calls OK. PSTN access OK. Sometimes fails with "communication error" as displayed on Nokia, main suspicion is failed trx-uhd ( without handover) will investigate further. Not sure which BTS it was on. As for LimeSDR mini support, best so far, has run overnight. Gullik

5 years, 4 months

2
3
0 0

OsmoTRX - osmo-trx-usrp-1 Aborted :: Assertion 'px != 0' failed

by Sergey Mayzus

5 years, 4 months

2
2
0 0

Some progress and some questions....

by Gullik Webjorn

I have now built osmo-trx-lms and osmo-bts-trx from source on an i386 platform. I have beacon, and two phones registered, the configuration from msc and up is the one I had three weeks ago, which more or less worked, but with large stability problems. I guess *this* report is the most interesting for you now.... I build from the "master", and target debian9 on i386. I have not been able to make a call yet, possibly because I might have messed up some library the MSC is dependent on, but I will work on that. What is interesting is that bts 0 trx 0 is running trx-uhd with a B100, and seems quite stable. Moreover, bts 1 trx 0 is running on the i386 and seems happy so far, after 30 minutes. This is Limesdr mini. I have just copied the bts0 to trx 0 section from my original config, duplicated it and changed bts0 to bts1, and the ipa unit-id 1805 0, and of course the ip addresses. I will comment the various lines in my configs, as I have understood them, and look forward to your comments, or maybe a keyword list explaining what each parameter is used for. ! osmo-bsc default configuration ! (assumes STP to run on 127.0.0.1 and uses default point codes) ! e1_input e1_line 0 driver ipa network network country code 1 mobile network code 1 encryption a5 0 neci 1 paging any use tch 0 handover 0 handover algorithm 1 handover1 window rxlev averaging 10 handover1 window rxqual averaging 1 handover1 window rxlev neighbor averaging 10 handover1 power budget interval 6 handover1 power budget hysteresis 3 handover1 maximum distance 9999 dyn_ts_allow_tch_f 0 periodic location update 30 ! here is the first bts - trx section. The ip.access id must match the one in the BTS, where it is called ipa. bts 0 type sysmobts band DCS1800 cell_identity 0 location_area_code 1 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 radio-link-timeout 32 channel allocator ascending rach tx integer 9 rach max transmission 7 channel-descrption attach 1 channel-descrption bs-pa-mfrms 5 channel-descrption bs-ag-blks-res 1 early-classmark-sending forbidden ip.access unit_id 1801 0 oml ip.access stream_id 255 line 0 codec-support fr gprs mode none trx 0 rf_locked 0 arfcn 871 nominal power 20 ! to use full TRX power, set max_power_red 0 max_power_red 3 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 ! this is BTS1. The ! osmo-bsc default configuration ! (assumes STP to run on 127.0.0.1 and uses default point codes) ! e1_input e1_line 0 driver ipa network network country code 1 mobile network code 1 encryption a5 0 neci 1 paging any use tch 0 handover 0 handover algorithm 1 handover1 window rxlev averaging 10 handover1 window rxqual averaging 1 handover1 window rxlev neighbor averaging 10 handover1 power budget interval 6 handover1 power budget hysteresis 3 handover1 maximum distance 9999 dyn_ts_allow_tch_f 0 periodic location update 30 *bts 0** *** type sysmobts band DCS1800 cell_identity 0 location_area_code 1 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 radio-link-timeout 32 channel allocator ascending rach tx integer 9 rach max transmission 7 channel-descrption attach 1 channel-descrption bs-pa-mfrms 5 channel-descrption bs-ag-blks-res 1 early-classmark-sending forbidden * ip.access unit_id 1801 0** * oml ip.access stream_id 255 line 0 codec-support fr gprs mode none trx 0 rf_locked 0 * arfcn 871** * nominal power 20 ! to use full TRX power, set max_power_red 0 max_power_red 3 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 *bts 1** *** type sysmobts band DCS1800 cell_identity 0 location_area_code 1 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 radio-link-timeout 32 channel allocator ascending rach tx integer 9 rach max transmission 7 channel-descrption attach 1 channel-descrption bs-pa-mfrms 5 channel-descrption bs-ag-blks-res 1 early-classmark-sending forbidden * ip.access unit_id 1805 0** * oml ip.access stream_id 255 line 0 codec-support fr gprs mode none trx 0 rf_locked 0 * arfcn 881** * nominal power 20 ! to use full TRX power, set max_power_red 0 max_power_red 3 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 msc 0 no bsc-welcome-text no bsc-msc-lost-text no bsc-grace-text type normal allow-emergency allow amr-config 12_2k forbidden amr-config 10_2k forbidden amr-config 7_95k forbidden amr-config 7_40k forbidden amr-config 6_70k forbidden amr-config 5_90k allowed amr-config 5_15k forbidden amr-config 4_75k forbidden codec-list fr1 fr2 fr3 hr1 hr3 mgw remote-ip 127.0.0.1 mgw remote-port 2427 mgw local-port 2727 mgw endpoint-range 1 31 bsc mid-call-timeout 0 no missing-msc-text Does this look OK to you?? Regards, Gullik

5 years, 4 months

1
1
0 0

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

by jenkins＠lists.osmocom.org

See <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/352/display/redire…> ------------------------------------------ [...truncated 1.15 MB...] CC libarch_sse_4_1_la-convert_sse_4_1.lo CCLD libarch_sse_4_1.la CCLD libarch_sse_3.la ar: `u' modifier ignored since `D' is the default (see `U') ar: `u' modifier ignored since `D' is the default (see `U') CCLD libarch.la ar: `u' modifier ignored since `D' is the default (see `U') make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/x86' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' make[4]: Nothing to be done for 'all-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' Making all in device make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' Making all in uhd make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device/uhd' CXX UHDDevice.lo CXXLD libdevice.la ar: `u' modifier ignored since `D' is the default (see `U') make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device/uhd' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[4]: Nothing to be done for 'all-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' CXX radioVector.lo CXX radioClock.lo CXX Transceiver.lo CXX signalVector.lo CXX ChannelizerBase.lo CXX radioBuffer.lo CXX sigProcLib.lo CXX radioInterface.lo CXX Channelizer.lo CXX Synthesis.lo CXX Resampler.lo CXX radioInterfaceResamp.lo CXX radioInterfaceMulti.lo CXX osmo_trx_uhd-osmo-trx.o CXXLD libtransceiver_common.la ar: `u' modifier ignored since `D' is the default (see `U') CXXLD osmo-trx-uhd make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' Making all in contrib make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' Making all in systemd make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib/systemd' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib/systemd' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' Making all in tests make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' Making all in CommonLibs make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs' CXX PRBSTest.o CXX BitVectorTest.o CXX SocketsTest.o CXX InterthreadTest.o CXX TimevalTest.o CXX LogTest.o CXX VectorTest.o CXXLD BitVectorTest CXXLD VectorTest CXXLD TimevalTest CXXLD SocketsTest CXXLD LogTest CXXLD PRBSTest CXXLD InterthreadTest make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs' Making all in Transceiver52M make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M' CC convolve_test-convolve_test.o CCLD convolve_test make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx' + make install Making install in doc make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc' Making install in examples make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples' make[3]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' /usr/bin/install -c -m 644 osmo-trx-uhd/osmo-trx-uhd.cfg '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' make install-data-hook make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples' for f in $(find . -type f -name '*.cfg*' | sed -e 's,^.,,'); do \ j="/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/doc/osmo-trx/examples/$f" && \ mkdir -p "$(dirname $j)" && \ /usr/bin/install -c -m 644 ./$f $j; \ done make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/examples' Making install in manuals make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/manuals' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/manuals' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/manuals' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc/manuals' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/doc' Making install in CommonLibs make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs' make[2]: Nothing to be done for 'install-exec-am'. make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/CommonLibs' Making install in GSM make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM' make[2]: Nothing to be done for 'install-exec-am'. make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/GSM' Making install in Transceiver52M make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' Making install in arch make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' Making install in common make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/common' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/common' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/common' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/common' Making install in x86 make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/x86' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/x86' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/x86' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch/x86' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/arch' Making install in device make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' Making install in uhd make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device/uhd' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device/uhd' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device/uhd' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device/uhd' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M/device' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' /bin/bash ../libtool --mode=install /usr/bin/install -c osmo-trx-uhd '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' libtool: install: /usr/bin/install -c osmo-trx-uhd /home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin/osmo-trx-uhd /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev2' /usr/bin/install -c -m 644 std_inband.rbf '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev2' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev4' /usr/bin/install -c -m 644 std_inband.rbf '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/usrp/rev4' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/Transceiver52M' Making install in contrib make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' Making install in systemd make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib/systemd' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib/systemd' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib/systemd' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib/systemd' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/contrib' Making install in tests make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' Making install in CommonLibs make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/CommonLibs' Making install in Transceiver52M make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests/Transceiver52M' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx/tests' make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx' make[2]: Nothing to be done for 'install-exec-am'. make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-trx' + popd ~/osmo-ci/coverity/source-Osmocom Emitted 2332 C/C++ compilation units (100%) successfully 2332 C/C++ compilation units (100%) are ready for analysis The cov-build utility completed successfully. + cd /home/osmocom-build/osmo-ci/coverity/source-Osmocom + rm -f Osmocom.tgz + tar czf Osmocom.tgz cov-int + set +x curl \ --form token="$token" \ --form email=holger(a)freyther.de --form file=(a)Osmocom.tgz \ --form version=Version --form description=AutoUpload \ https://scan.coverity.com/builds?project=Osmocom % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (51) SSL: no alternative certificate subject name matches target host name 'scan.coverity.com' Build step 'Execute shell' marked build as failure

5 years, 4 months

1
1
0 0

Limesdr mini and nightly builds....

by Gullik Webjorn

Hi, I have just received a limesdr mini, and I am trying to get that sdr to the same level as I had with uhd B100. I managed to get the whole config working properly, but stability was bad, as you have read. As I was recommended, I have been runnig "nightly" binaries, and see where I end up.... :-) limesdr installed in Orange Pi Zero, (armhf). Limesuite 18.10.0-1, LimeUtil seems happy, and I can see the SDR However, I cannot get stability enough to get a stable signal.... Gullik TRX LIME CONFIG log stderr logging filter all 1 logging color 1 logging print category 1 logging timestamp 1 logging print file basename logging level set-all info ! line vty no login ! trx bind-ip 127.0.0.1 remote-ip 127.0.0.1 base-port 5700 egprs disable tx-sps 4 rx-sps 4 rt-prio 18 chan 0 tx-path BAND1 rx-path LNAW bsc 1.3.0.287 or .284 will not run, fails with error in sysmalloc(), so I try running .283, from dec 19.... maybe this problem is armhf related...?? this is the bsc config...... osmobsc config file ! osmo-bsc default configuration ! (assumes STP to run on 127.0.0.1 and uses default point codes) ! e1_input e1_line 0 driver ipa network network country code 1 mobile network code 1 encryption a5 0 neci 1 paging any use tch 0 handover 0 handover algorithm 1 handover1 window rxlev averaging 10 handover1 window rxqual averaging 1 handover1 window rxlev neighbor averaging 10 handover1 power budget interval 6 handover1 power budget hysteresis 3 handover1 maximum distance 9999 dyn_ts_allow_tch_f 0 periodic location update 30 bts 0 type sysmobts band DCS1800 cell_identity 0 location_area_code 1 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 radio-link-timeout 32 channel allocator ascending rach tx integer 9 rach max transmission 7 channel-descrption attach 1 channel-descrption bs-pa-mfrms 5 channel-descrption bs-ag-blks-res 1 early-classmark-sending forbidden ip.access unit_id 1801 0 oml ip.access stream_id 255 line 0 codec-support fr gprs mode none trx 0 rf_locked 0 arfcn 871 nominal power 20 ! to use full TRX power, set max_power_red 0 max_power_red 3 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 msc 0 no bsc-welcome-text no bsc-msc-lost-text no bsc-grace-text type normal allow-emergency allow amr-config 12_2k forbidden amr-config 10_2k forbidden amr-config 7_95k forbidden amr-config 7_40k forbidden amr-config 6_70k forbidden amr-config 5_90k allowed amr-config 5_15k forbidden amr-config 4_75k forbidden codec-list fr1 fr2 fr3 hr1 hr3 mgw remote-ip 127.0.0.1 mgw remote-port 2427 mgw local-port 2727 mgw endpoint-range 1 31 bsc mid-call-timeout 0 no missing-msc-text bsc does not seem to want to speak with trx-lms, I don't understand which config entry is wrong.... osmo_bsc_main.c:284 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 871 using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63 <0007> a_reset.c:106 A-RESET(msc-0)[0xdb2e98]{DISC}: (re)sending BSSMAP RESET message... <0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0007> osmo_bsc_bssap.c:58 RESET ACK from MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0007> a_reset.c:74 A-RESET(msc-0)[0xdb2e98]{DISC}: SIGTRAN connection succeded. <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-0-CCCH_SDCCH4)[0xddfcd8]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-1-TCH_F)[0xde0038]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-2-TCH_F)[0xde0398]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-3-TCH_F)[0xde06f8]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-4-TCH_F)[0xde0a58]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-5-TCH_F)[0xde0db8]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-6-TCH_F)[0xde1118]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-7-TCH_F)[0xde1478]{UNUSED}: Event TS_EV_OML_READY not permitted <0015> input/ipaccess.c:248 Sign link vanished, dead socket <0015> input/ipaccess.c:74 Forcing socket shutdown with no signal link set <0015> bts_ipaccess_nanobts.c:416 (bts=0) Dropping OML link. <0015> bts_ipaccess_nanobts.c:397 (bts=0,trx=0) Dropping RSL link. <0015> input/ipa.c:262 accept()ed new link from 127.0.0.1 to port 3002 <0004> abis_nm.c:538 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. <0004> abis_nm.c:538 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. So, has anyone config files for Limesdr mini -> trx-lms -> osmo-bts-trx_0.8.1.199 -> osmo-msc or can point me in the right direction.... Gullik

5 years, 4 months

3
13
0 0

Please be aware: doxygen: confusion about \ref and \a

by Neels Hofmeyr

Researching for a discussion at https://gerrit.osmocom.org/c/libosmocore/+/12384 made me realize that our use of doxygen keywords is currently confused. TLDR: - Links to structs, members and functions are implicit in doxygen. - Don't use '\ref', except to link to sections or files. - Don't use '\a', it is merely cosmetic and breaks reading flow for some. Details: (*) We are often using '\ref' wrongly, and also '\a' is merely cosmetic. Example: osmo_crc16(), see param 'len' intending to reference the 'buffer' param: /*! Compute 16bit CCITT polynome 0x8408 (x^0 + x^5 + x^12) over given buffer. * \param crc[in] previous CRC value * \param buffer[in] data pointer * \param len[in] number of bytes in input \ref buffer * \return updated CRC value */ uint16_t osmo_crc16(uint16_t crc, uint8_t const *buffer, size_t len) ... It looks perfectly sane, but this is wrong for more than one reason: - '\ref' is not actually about code elements. It is about referencing pages or code sections. See http://www.doxygen.nl/manual/commands.html#cmdref "Creates a reference to a named section, subsection, page or anchor." Doxygen complains with e.g.: "gsmtap_util.c:192: warning: unable to resolve reference to `data' for \ref command" Luckily '\ref' doesn't break implicit linking, which is probably why the misconception that we need to include them arose in the first place. - There *AREN'T* any references to function arguments at all!! It is not possible in doxygen to create a formal link to a function argument. You can reference struct members, functions, ... but not arguments. API code often uses '\a' (at least 320 times in libosmocore), but that does not add a formal link, either. '\a' is only and simply putting a term in italics. http://www.doxygen.nl/manual/commands.html#cmda There are currently at least 260 uses of '\ref' in libosmocore, of which only a few are correct. An example of correct use is gsmtap_source_init(): http://ftp.osmocom.org/api/latest/libosmocore/core/html/group__gsmtap.html#… /*! [...] integrated with libosmocore \ref select */ which renders as integrated with libosmocore [Select loop abstraction] Ironically, the same gsmtap_source_init() also includes examples of incorrect use, ignore those for this argument, please. (*) Hyperlinks are fully automatic and implicit. Notice that formal links are detected automatically, without the need for an explicit doxygen marker. For example, look at the API doc for osmo_cgi_name2(): http://ftp.osmocom.org/api/latest/libosmocore/gsm/html/gsm23003_8c.html#af9… It has a link to osmo_cgi_name(), with a doxygen source of /*! Same as osmo_cgi_name(), but uses a different static buffer. [...] I will hence continue to omit '\a' and '\ref', and will actually ask patch submitters to omit them in code review. ~N

5 years, 4 months

2
1
0 0

Adding priority for EMLPP service in paging type 1

by Snehasish Kar

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

5 years, 4 months

3
7
0 0

pysim-read errors

by devifr

All, I have the following error when I run pySim-read.py: Traceback (most recent call last): File "pySim-read.py", line 86, in <module> sl = SerialSimLink(device=opts.device, baudrate=opts.baudrate) File "/home/macbook/Desktop/pyscard-1.9.7/pysim/pySim/transport/serial.py", line 45, in __init__ baudrate = baudrate, File "/home/macbook/.local/lib/python2.7/site-packages/serial/serialutil.py", line 240, in __init__ self.open() File "/home/macbook/.local/lib/python2.7/site-packages/serial/serialposix.py", line 268, in open raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg)) serial.serialutil.SerialException: [Errno 2] could not open port /dev/ttyUSB0: [Errno 2] No such file or directory: '/dev/ttyUSB0' Exception AttributeError: "'SerialSimLink' object has no attribute '_sl'" in <bound method SerialSimLink.__del__ of <pySim.transport.serial.SerialSimLink object at 0x7ff879094d10>> ignored I'm no Linux and/or Python guru but from what I can gather is that it's having issues with identifying the card reader on dev/ttyUSB0. To address that issue, I've confirmed my current card reader (identiv SCR3310) is working when I've ran the pcsc_scan script: PC/SC device scanner V 1.5.2 (c) 2001-2017, Ludovic Rousseau <ludovic.rousseau(a)free.fr> Using reader plug'n play mechanism Scanning present readers... 0: SCR3310 Smart Card Reader [CCID Interface] (53311828708432) 00 00 Wed Jan 2 12:02:36 2019 Reader 0: SCR3310 Smart Card Reader [CCID Interface] (53311828708432) 00 00 Card state: Card inserted, ATR: 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8 ATR: 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8 + TS = 3B --> Direct Convention + T0 = 9F, Y(1): 1001, K: 15 (historical bytes) TA(1) = 95 --> Fi=512, Di=16, 32 cycles/ETU 125000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 156250 bits/s TD(1) = 80 --> Y(i+1) = 1000, Protocol T = 0 ----- TD(2) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface bytes following ----- TA(3) = C3 --> Clock stop: no preference - Class accepted by the card: (3G) A 5V B 3V + Historical bytes: 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 Category indicator byte: 80 (compact TLV data object) Tag: 3, len: 1 (card service data byte) Card service data byte: E0 - Application selection: by full DF name - Application selection: by partial DF name - BER-TLV data objects available in EF.DIR - EF.DIR and EF.ATR access services: by GET RECORD(s) command - Card with MF Tag: 7, len: 3 (card capabilities) Selection methods: FE - DF selection by full DF name - DF selection by partial DF name - DF selection by path - DF selection by file identifier - Implicit DF selection - Short EF identifier supported - Record number supported Data coding byte: 21 - Behaviour of write functions: proprietary - Value 'FF' for the first byte of BER-TLV tag fields: invalid - Data unit in quartets: 2 Command chaining, length fields and logical channels: 13 - Logical channel number assignment: by the card - Maximum number of logical channels: 4 Tag: 5, len: 7 (card issuer's data) Card issuer data: 86 81 02 86 98 44 18 + TCK = A8 (correct checksum) Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8 GREEN CARD, Grcard (Hong Kong ) Co.,Limited, LTE Usim Card (Telecommunication) Celcom Postpaid 3G (Telecommunication) Additionally, I've ran the following command (dmesg | tail -6) to determine what path my card reader is mounted to: macbook@ubuntu:~/Desktop/pyscard-1.9.7/pysim$ dmesg | tail -n 6 [ 7079.120203] usb 3-3.1: new full-speed USB device number 6 using xhci_hcd [ 7079.223962] usb 3-3.1: New USB device found, idVendor=04e6, idProduct=5116 [ 7079.223965] usb 3-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [ 7079.223968] usb 3-3.1: Product: SCR33xx v2.0 USB SC Reader [ 7079.223969] usb 3-3.1: Manufacturer: Identive [ 7079.223971] usb 3-3.1: SerialNumber: 53311828708432 My questions are this, is there a known work around for this errors that I've posted above? Also, if my card is not mounting to dev/ttyUSB0, where do they mount to? I've looked in /mnt, /media as well as /dev....no joy. I've searched the Open BSC archives as well as scoured the web for an answer to this issue and I'm coming up blank. One last thing, I've ran this python script on an Ubuntu VM and Dual Boot. Same issue both machines. I've also tried this script with an Alcor card reader. Same output. Any help is greatly appreciated. Thanks, Derek

5 years, 4 months

2
2
0 0

got traces for inter-MSC Handover?

by Neels Hofmeyr

Hi all, my current task is implementing inter-MSC Handover for OsmoMSC. It would be immensely helpful to look at network traces of the messages carrying out an inter-MSC handover. Primarily for 2G (BSSAP), but 3G (RANAP) might also be interesting. The part on the A-interface (BSSAP) is interesting for both the outgoing (orig. MSC and BSS) as well as the incoming (remote MSC and BSS) sides. Most interesting would be some kind of trace of communication between the two MSCs, the E-interface (MAP) negotiating the HO as well as the call forwarding between the two MSCs, if at all available. We are exploring various avenues to obtain inter-MSC HO traces, so far to no avail. If anyone reading this is able to help out, that would be highly appreciated and super helpful to be interoperable. Thanks! ~N -- - Neels Hofmeyr <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

5 years, 4 months

1
0
0 0

35c3 feedback

by Keith

Hi all. 1) SIP Connector handling of TON GSM340_TYPE_INTERNATIONAL Apparently at least one person was frustrated at the congress by not being able to call out using the numbers stored in their GSM handset using the form +CountryCode. As we know this appears at Call Control with TON intl, which sip connector then prefixes with '+' before sending to SIP The reason for lack of service at ccc was that the Yate pbx does not support this number scheme and needed the 00 prefix. This would have been trivial to patch had we known, and it prompts me to think this should probably be implemented as a runtime config option in sip section 'tonintl prefix' or some such? It would seem correct for it to be restricted to the set of either '00' or '+', no other options really makes sense, not even "no prefix". right? 2) 3G data instabilities ( Just a quick observation note, no pcap! ) I happened to notice that pinging a 3G handset from the network side (default ping: 1 sec internal, 64 ICMP bytes) keeps the connection "alive" and using 3G data is then a pleasant experience, IM, email, browsing, SIP call all working nicely. peak max download speed of 16Mbps was reported at one time by m.speedof.me However, stopping the ping results in loss of data conex within a few seconds, and the behaviour from users point of view is then strikingly similar to what's observed on 2G; and I am more or less convinced has to do with the unknown Timing Advance issues in the PCU. So I thought I'd note it down here. k/

5 years, 4 months

4
4
0 0

35c3: found induction charger in GSM room

by Neels Hofmeyr

Is anyone missing a phone induction charger pad after congress? We found one left behind when clearing out the GSM room. ~N

5 years, 4 months

1
0
0 0

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

by jenkins＠lists.osmocom.org

See <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/345/display/redire…> ------------------------------------------ [...truncated 682.86 KB...] ^~~~ ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberA { ^~~~~~~~~~~~~ CC RANAP_ListOF-SNAs.lo CC RANAP_ListOfInterfacesToTrace.lo CC RANAP_InterfacesToTraceItem.lo CC RANAP_LoadValue.lo CC RANAP_LocationRelatedDataRequestType.lo CC RANAP_LocationRelatedDataRequestTypeSpecificToGERANIuMode.lo CC RANAP_LocationReportingTransferInformation.lo CC RANAP_ReportChangeOfSAI.lo CC RANAP_PeriodicReportingIndicator.lo CC RANAP_DirectReportingIndicator.lo CC RANAP_L3-Information.lo CC RANAP_M1Report.lo CC RANAP_M2Report.lo CC RANAP_M4Report.lo CC RANAP_M4-Collection-Parameters.lo CC RANAP_M4-Period.lo CC RANAP_M4-Threshold.lo CC RANAP_M5Report.lo CC RANAP_M5-Period.lo CC RANAP_M6Report.lo CC RANAP_M6-Period.lo CC RANAP_M7Report.lo CC RANAP_M7-Period.lo CC RANAP_Management-Based-MDT-Allowed.lo CC RANAP_MaxBitrate.lo CC RANAP_MaxSDU-Size.lo CC RANAP_MBMS-PTP-RAB-ID.lo CC RANAP_MBMSBearerServiceType.lo CC RANAP_MBMSCNDe-Registration.lo CC RANAP_MBMSCountingInformation.lo CC RANAP_MBMSHCIndicator.lo CC RANAP_MBMSIPMulticastAddressandAPNRequest.lo CC RANAP_MBMSLinkingInformation.lo CC RANAP_MBMSRegistrationRequestType.lo CC RANAP_MBMSServiceArea.lo CC RANAP_MBMSSessionDuration.lo CC RANAP_MBMSSessionIdentity.lo CC RANAP_MBMSSessionRepetitionNumber.lo CC RANAP_MDT-Activation.lo CC RANAP_MDTAreaScope.lo CC RANAP_MDT-Configuration.lo CC RANAP_MDTMode.lo CC RANAP_MDT-PLMN-List.lo CC RANAP_MDT-Report-Parameters.lo CC RANAP_MeasurementQuantity.lo CC RANAP_MeasurementsToActivate.lo CC RANAP_MSISDN.lo CC RANAP_NAS-PDU.lo CC RANAP_NAS-SequenceNumber.lo CC RANAP_NAS-SynchronisationIndicator.lo CC RANAP_NewBSS-To-OldBSS-Information.lo CC RANAP_NonSearchingIndication.lo CC RANAP_NRTLoadInformationValue.lo CC RANAP_NumberOfIuInstances.lo CC RANAP_NumberOfSteps.lo CC RANAP_Offload-RAB-Parameters.lo CC RANAP_Offload-RAB-Parameters-APN.lo CC RANAP_Offload-RAB-Parameters-ChargingCharacteristics.lo CC RANAP_OldBSS-ToNewBSS-Information.lo CC RANAP_OMC-ID.lo CC RANAP_Out-Of-UTRAN.lo CC RANAP_PagingAreaID.lo CC RANAP_PagingCause.lo CC RANAP_PDP-TypeInformation.lo CC RANAP_PDP-Type.lo CC RANAP_PDP-TypeInformation-extension.lo CC RANAP_PDP-Type-extension.lo CC RANAP_PDUType14FrameSequenceNumber.lo CC RANAP_PeriodicLocationInfo.lo CC RANAP_PermanentNAS-UE-ID.lo CC RANAP_PermittedEncryptionAlgorithms.lo CC RANAP_PermittedIntegrityProtectionAlgorithms.lo CC RANAP_LABased.lo CC RANAP_LAI-List.lo CC RANAP_LoggedMDT.lo CC RANAP_LoggingInterval.lo CC RANAP_LoggingDuration.lo CC RANAP_PLMNidentity.lo CC RANAP_PLMNs-in-shared-network.lo CC RANAP_Port-Number.lo CC RANAP_PositioningDataDiscriminator.lo CC RANAP_PositioningMethodAndUsage.lo CC RANAP_PositioningDataSet.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:14, from RANAP_PLMNs-in-shared-network.c:7: ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:23: warning: ‘struct MemberA’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberA { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberA { ^~~~~~~~~~~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:23: warning: ‘struct MemberM’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberM { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberM { ^~~~~~~~~~~~~ CC RANAP_PositioningPriority.lo CC RANAP_PositionData.lo CC RANAP_PositionDataSpecificToGERANIuMode.lo CC RANAP_Pre-emptionCapability.lo CC RANAP_Pre-emptionVulnerability.lo CC RANAP_PriorityLevel.lo CC RANAP_Priority-Class-Indicator.lo CC RANAP_ProvidedData.lo CC RANAP_P-TMSI.lo CC RANAP_QueuingAllowed.lo CC RANAP_RAB-AsymmetryIndicator.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:14, from ../../include/osmocom/ranap/RANAP_Shared-Network-Information.h:14, from ../../include/osmocom/ranap/RANAP_ProvidedData.h:14, from RANAP_ProvidedData.c:7: ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:23: warning: ‘struct MemberA’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberA { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberA { ^~~~~~~~~~~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:23: warning: ‘struct MemberM’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberM { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberM { ^~~~~~~~~~~~~ CC RANAP_RABased.lo CC RANAP_RAI-List.lo CC RANAP_RABDataVolumeReport.lo CC RANAP_RAB-ID.lo CC RANAP_RAB-Parameter-ExtendedGuaranteedBitrateList.lo CC RANAP_RAB-Parameter-ExtendedMaxBitrateList.lo CC RANAP_RAB-Parameter-GuaranteedBitrateList.lo CC RANAP_RAB-Parameter-MaxBitrateList.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:14, from RANAP_RABDataVolumeReport.c:7: ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:23: warning: ‘struct MemberN’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberN { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberN { ^~~~~~~~~~~~~ CC RANAP_RAB-Parameters.lo CC RANAP_RABParametersList.lo CC RANAP_RAB-SubflowCombinationBitRate.lo CC RANAP_RAB-TrCH-Mapping.lo CC RANAP_RAB-TrCH-MappingItem.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_RABParametersList.h:14, from RANAP_RABParametersList.c:7: ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:23: warning: ‘struct MemberN’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberN { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberN { ^~~~~~~~~~~~~ In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_RABParametersList.h:14, from RANAP_RABParametersList.c:7: ../../include/osmocom/ranap/RANAP_RABParametersList.h:29:23: warning: ‘struct MemberB’ declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberB { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’ void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_RABParametersList.h:29:2: note: in expansion of macro ‘A_SEQUENCE_OF’ A_SEQUENCE_OF(struct MemberB { ^~~~~~~~~~~~~ CC RANAP_RAC.lo CC RANAP_RAI.lo CC RANAP_RAListofIdleModeUEs.lo CC RANAP_NotEmptyRAListofIdleModeUEs.lo CC RANAP_RAofIdleModeUEs.lo CC RANAP_LAListofIdleModeUEs.lo CC RANAP_RAT-Type.lo CC RANAP_RateControlAllowed.lo CC RANAP_RedirectAttemptFlag.lo CC RANAP_RedirectionCompleted.lo CC RANAP_RejectCauseValue.lo CC RANAP_RelocationRequirement.lo CC RANAP_RelocationType.lo CC RANAP_RepetitionNumber0.lo CC RANAP_RepetitionNumber1.lo CC RANAP_ReportArea.lo CC RANAP_ReportInterval.lo CC RANAP_ReportAmount.lo CC RANAP_RequestedGPSAssistanceData.lo CC RANAP_RequestedGANSSAssistanceData.lo CC RANAP_RequestedLocationRelatedDataType.lo CC RANAP_RequestedMBMSIPMulticastAddressandAPNRequest.lo CC RANAP_MBMSIPMulticastAddressandAPNlist.lo CC RANAP_RequestedMulticastServiceList.lo CC RANAP_Requested-RAB-Parameter-Values.lo CC RANAP_Requested-RAB-Parameter-ExtendedMaxBitrateList.lo CC RANAP_Requested-RAB-Parameter-ExtendedGuaranteedBitrateList.lo CC RANAP_Requested-RAB-Parameter-MaxBitrateList.lo CC RANAP_Requested-RAB-Parameter-GuaranteedBitrateList.lo CC RANAP_RequestType.lo CC RANAP_ResponseTime.lo CC RANAP_ResidualBitErrorRatio.lo CC RANAP_RIMInformation.lo CC RANAP_RIM-Transfer.lo CC RANAP_RIMRoutingAddress.lo /bin/bash: line 1: 16651 Segmentation fault /bin/bash ../../libtool --silent --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.13-45696\" -DPACKAGE_STRING=\"osmo-iuh\ 0.3.0.13-45696\" -DPACKAGE_BUGREPORT=\"openbsc(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.3.0.13-45696\" -DSTDC_HEADERS=1 -I. -Wall -I../../include -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -g -O2 -Wall -MT RANAP_ResponseTime.lo -MD -MP -MF .deps/RANAP_ResponseTime.Tpo -c -o RANAP_ResponseTime.lo RANAP_ResponseTime.c Makefile:2506: recipe for target 'RANAP_ResponseTime.lo' failed make[4]: *** [RANAP_ResponseTime.lo] Error 139 make[4]: *** Waiting for unfinished jobs.... make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src/ranap' Makefile:642: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src' Makefile:454: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src' Makefile:458: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh' Makefile:382: recipe for target 'all' failed make: *** [all] Error 2 [WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully. Emitted 1261 C/C++ compilation units (100%) successfully 1261 C/C++ compilation units (100%) are ready for analysis For more details, please look at: /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt Build step 'Execute shell' marked build as failure

5 years, 4 months

1
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2019