OpenBSC October 2018

openbsc@lists.osmocom.org

28 participants
30 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

3 months, 4 weeks

OC-2G merge to osmo-bts

by Harald Welte

Dear Osmocom team, Omar has thankfully submitted patches for inclusion of OC-2G support to gerrit, see https://gerrit.osmocom.org/#/c/osmo-bts/+/11447/ for the bulk of the code. An initial review showed there are *many* parts that are identical to osmo-bts-litecell15, and we generally don't like "copy+paste" programming. In the end we have multiple compies of essentially the same source files, becoming a maintenance problem over time, when fixes are applied to one copy, but not the other. I've manually looked through each of the files and looked at the differences between the oc2g and the lc15 counterpart. == 100% identical to osmo-bts-sysmo or osmo-bts-lc15: oml_router.c oml_router.h misc/oc2gbts_nl.c == 99% identical to lc15 (just names changed) hw_misc.h hw_misc.c l1_transp.h l1_trans_hw.c oc2gbts.c / lc15bts.c oc2gbts_vty.c / lc15bts_vty.c oml.c tch.c utils.c utils.h l1_if.h misc/oc2gbts_bts.h misc/oc2gbts_bid.h misc/oc2gbts_clock.h misc/oc2gbts_clock.c misc/oc2gbts_led.c misc/oc2gbts_swd.c misc/oc2gbts_swd.h == 80% identical to lc15 (some small changes) l1_if.c misc/oc2gbts_bts.c misc/oc2gbts_mgr.c misc/oc2gbts_mgr.h misc/oc2gbts_mgr_nl.c misc/oc2gbts_temp.c misc/oc2gbts_temp.h == more differences compared to lc15, possibly not intentional? / what to do? misc/oc2gbts_temp.c misc/oc2gbts_mgr_vty.c misc/oc2gbts_misc.c misc/oc2gbts_par.c misc/oc2gbts_power.c misc/oc2gbts_util.c So we have to discuss how to go about this. The 100% identical files are easy, one can simply lik the existing implementation. We could also introduce a "src/nuran-common" directory for common code between the different models. For those parts with less similarity, this may require some refactoring, so that common/shared code goes to common/shared files and really only those bits that differ are handled in the respective implementations. Given that osmo-bts-litecell15 also started as copy of osmo-bts-sysmo, there may be room for further unification, but let's not conflate those two discussions. In terms of process, * we could first merge all the copies and then further unify the code, or * we could first modify the existing core/lc15 code to be able to merge OC2G coe without introducing lots of copied code. Any comments/suggestions/ideas? 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)

6 years, 10 months

EUSE with user input

by Michael Benedict

Hi all, The demo EUSE application included with OsmoHLR [1] has been very useful for understanding the flow of information during a USSD session. I would like to extend it to request input from the user and allow > 1 request/response. I have tried changing the session state to `OSMO_GSUP_SESSION_STATE_CONTINUE`, and the gsup_msg_type to `OSMO_GSUP_MSGT_PROC_SS_REQUEST` in `euse_tx_ss`. I see the “You sent…” response on my phone, but do not get an input field. Can anyone advise if this is the correct general approach or point me in the right direction? Thanks for your patience as I figure these things out. Best, —Michael [1] https://github.com/osmocom/osmo-hlr/blob/master/src/osmo-euse-demo.c

6 years, 10 months

osmo-dev

by Neels Hofmeyr

osmo-dev is my personal tooling for building and configuring Osmocom core net components. Since osmith is also using it now and starting to send in patches on gerrit, it is receiving some public attention. Despite cosmetics I might have done differently if I were to rewrite it from scratch, I do (obviously) like the way it works, and would welcome anyone else to give it a spin, too. But I assume you have your own tooling anyway...? So far only I have permission to +2 on gerrit for osmo-dev, I see it as my private setup made available to others, so would retain the last say on it. But it also increasingly becomes osmith's setup, so we can change permissions... ~N

6 years, 10 months

OsmoDevCon 2019 date poll

by Harald Welte

Dear all, I would like to get your input as to when we should schedule OsmoDevCon 2019. NOTE: OsmoDevCon is our "for developers by developers" event, not to be confused with OsmoCon, our public conference. If we want to stay with the usual "Friday through Monday in April" arrangement, we have the following options: April 05-08, 2019 April 12-15, 2019 April 26-29, 2019 The one missing weekend in the list above is the easter weekend, which is probably a good idea to exclude as flights and hotels are more expensive during that time, and people might have other plans during holidays. I would like to invite anyone planning to attend the Osmocom Developer Conference 2019 to participate in the poll at https://dudle.inf.tu-dresden.de/OsmoDevCon2019/ to state their availability/preference. The Dudle only shows the first day of the four days of OsmoDevCon. Looking forward to your feedback so we can settle on a date soon. Thanks! Kind 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)

6 years, 10 months

logging of KPI

by Lars Prehn

Hi everyone, is there some wiki entry / detailed description of how to properly set up reporting to statsd for a set of given metrics (e.g. number of active users / bytes sent per user) on a per component granularity? Best regards, Lars

6 years, 10 months

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

by jenkins＠lists.osmocom.org

See <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/280/display/redire…> Changes: [laforge] gerrot-osmo-bts: Don't use unsupported '/' in labels of axis/matrix jobs ------------------------------------------ [...truncated 720.95 KB...] CC RANAP_LAI.lo CC RANAP_LastKnownServiceArea.lo CC RANAP_LastVisitedUTRANCell-Item.lo CC RANAP_LHN-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_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_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_M7Report.lo CC RANAP_M7-Period.lo CC RANAP_M6-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_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_PositioningMethodAndUsage.lo 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 CC RANAP_RABased.lo CC RANAP_RAI-List.lo CC RANAP_RABDataVolumeReport.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_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 /bin/bash: line 1: 9675 Segmentation fault /bin/bash ../../libtool --silent --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.10-9aad\" -DPACKAGE_STRING=\"osmo-iuh\ 0.3.0.10-9aad\" -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.10-9aad\" -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_RequestedGANSSAssistanceData.lo -MD -MP -MF .deps/RANAP_RequestedGANSSAssistanceData.Tpo -c -o RANAP_RequestedGANSSAssistanceData.lo RANAP_RequestedGANSSAssistanceData.c Makefile:2506: recipe for target 'RANAP_RequestedGANSSAssistanceData.lo' failed make[4]: *** [RANAP_RequestedGANSSAssistanceData.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 1233 C/C++ compilation units (100%) successfully 1233 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, 10 months

ipaccess-proxy not relaying traffic to bsc

by Mihai Ordean

Hey all, First of all let me thanks Neels for his help with the silent_call problem I've been having, which led me to a successful fix. Secondly I was wandering if I could get a bit more help with regards to ipaccess-proxy this time. Now that silent_call is working I want to start manipulating traffic and do some fuzzing. I understand that the ipaccess-proxy is the right tool to use, but I don't seem to get it working. In my current NON ipaccess-proxy setup (which works) I have an osmo-bts which gets data from a USRP B210 via osmo-trx-uhd. On the same machine I also run the osmo-osc. I have configured the OML remote address in the BTS (bts 0 -> oml remote-ip) to a unique localhost (127.0.127.1) and the BSC to listen on that (e1_input -> ipa bind 127.0.127.1). What I want to do is interleave the ipaccess-proxy on this connection (e.g. receive OML from BTS on 127.0.127.2) and forward to the BSC on 127.0.127.1. I have successfully managed to make ipaccess-proxy bind to the specific address (by changing the default IP binding from 0.0.0.0:3002 and 0.0.0.0:3003 to 127.0.127.2:3002 and 3003), and I am receiving traffic from the BTS. However, traffic is never forwarded to the BSC. There seems to be some issue with unrecognized IPA message types. Would anyone be able to provide me with some insight, or perhaps a setup in which ipaccess-proxy worked successfully? I'm also not clear on what ipaccess-proxy is supposed to do. Is it a sniffer (since it binds on 0.0.0.0 by default) or is it a "MITM" relay type of software. I am attaching the output log I get from ipaccess-proxy. -- Mihai

6 years, 10 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC October 2018