OpenBSC January 2019

openbsc@lists.osmocom.org

25 participants
44 discussions

by Martin Nagy

Hi all, After buying a super Sim Kit (16 in 1) from China, I tried the reader (green PCB inside a blue transparent plastic case with a blue LED) and SIM (identified as a fakesupersim) with pysim tool. However i am getting the following error: /pySim-prog.py -n 26C3 -c 49 -x 262 -y 42 -z 1234 -j 1 -t auto Insert card now (or CTRL-C to cancel) Autodetected card type fakemagicsim Generated card parameters : > Name : 26C3 > SMSP : e1ffffffffffffffffffffffff058100945555ffffffffffff000000 > ICCID : 8949262427518313026 > MCC/MNC : 262/42 > IMSI : 262422461512085 > Ki : 7b74741a1ee14337ec23f9ab92a13648 > OPC : ccd867d60797d8d45354a51b3ef568ff Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 530, in <module> card.program(cp) File "/home/nadicek/pysim/pysim/pySim/cards.py", line 231, in program self._scc.update_binary('6f30', hplmn + 'ff' * (tl-3)) File "/home/nadicek/pysim/pysim/pySim/commands.py", line 53, in update_binary return self._tp.send_apdu_checksw(pdu) File "/home/nadicek/pysim/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed ! Expected 9000 and got 9804. I checked mailing lists and haven’t found anybody who had similar problem with pysim. Also I have tried forcing different models of SIM, but nothing is working. Obviously I can remove this check from the script file (__init__.py in /pySim/transport), however somebody had a reason to put such condition there. I would like to ask if it is safe to remove that line of code and the purpose of that line of code. Thanks a lot and best regards Martin

1 month

Re: Help with sccp library

by mosbah abdelkader

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

2 months, 1 week

dynamic traffic channels

by Neels Hofmeyr

On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels

4 months

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.

6 years, 6 months

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

6 years, 7 months

Limesdr mini on Orange Pi Zero

by Gullik Webjorn

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

6 years, 7 months

channel statistics

by Neels Hofmeyr

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

6 years, 7 months

Reset GSM tester state?

by Holger Freyther

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

6 years, 7 months

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

by jenkins＠lists.osmocom.org

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

6 years, 7 months

Enable / disable of a bts / trx

by Gullik Webjorn

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

6 years, 7 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2019