From laforge at gnumonks.org Mon Jan 1 17:47:05 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 1 Jan 2018 18:47:05 +0100 Subject: Osmocom Year 2017 Review Message-ID: <20180101174705.GG20410@nataraja> Dear all, I've written up a "short" review of what I perceive as the most important events in the Osmocom Cellular Infrastructure projects in 2017. See http://osmocom.org/news/84 for all details, or below for a raw copy+paste: h1. Osmocom Review 2017 This is a review of the most significant changes and events in the Osmocom Cellular Infrastructure projects in 2017 h2. January 2017 * announce of first ever public [[OsmoCon:]] conference in April * osmo-bts ** Add Abis OML failure event reporting ** fix memory leaks in osmo-bts-{sysmo,lc15} at every channel activation * openbsc/osmo-bsc ** support multiple UARFCNs in SI2quater * osmo-hlr ** add test suite for 2G and 3G authentication ** fix UMTS AKA re-sync h2. February 2017 * weekly manual testing with related weekly test reports to mailing list * "heads-up about the (lack of a )future of osmo-nitb":http://lists.osmocom.org/pipermail/openbsc/2017-February/010300.html * "heads-up about libosmo-sccp SIGTRAN work":http://lists.osmocom.org/pipermail/openbsc/2017-February/010274.html * "sysmo-usim-tool":http://lists.osmocom.org/pipermail/openbsc/2017-February/010317.html * libosmo-abis ** unix domain socket support (for Ericsson L2TP) * osmo-bts ** fix AMR HR DTX FSM logic ** fix SACCH sending fo system information with enum value > 7 ** osmo-bts-trx: fix RXGAIN and POWER parameters on second TRX ** fix TCH/H interleaving table bit position ** sysmoBTS 1020/1100: slow power ramp-up on TRX enable * osmo-sgsn ** fix PDP context activation memory allocation bug ** integrate support for UMTS AKA * openggsn ** fix kernel-gtp tunnel creation/removal for GTPv1 ** release 0.93 h3. March 2017 * "cgit improvements":http://lists.osmocom.org/pipermail/openbsc/2017-March/010448.html (about page, change-ID hyperlinks, issue hyperlinks) * Add README.md files to all our repositories * libosmocore ** migrate gsm 05.03 coding from OsmoBTS to libosmocore ** fix SQN / SEQ handling in UMTS AKA ** 3GPP AoIP message encoding/decoding * libosmo-abis ** fix ever-increasing jitter buffer * libosmo-netif ** handle SCTP in in stream server ** doxygen documentation on stream an datagram modules * osmo-bts ** octphy: CBCH support ** include MS timing offset in RSL measurements * osmo-sgsn ** handle IMSIs with leading zeroes * osmo-bsc ** fix T3186 encoding in SI13 ** Improved Ericsson OM2000/RBS2000 support ** new ctrl2soap proxy in python * osmo-hlr ** add CTRL interface ** fix SQN/SEQ handling in UMTS AKA h3. April 2017 * "update of coding style for longer line lengths":http://lists.osmocom.org/pipermail/openbsc/2017-April/010502.html * [[osmo-dev-con:OsmoCon2017]] and [[osmo-dev-con:OsmoDevCon2017]] * libosmocore ** "control interface for osmo_fsm":http://lists.osmocom.org/pipermail/openbsc/2017-April/010542.html * libosmo-netif ** fix file descriptor leak in error paths ** work around linux kenrel SCTP bug with sender_dry_events ** RTP marker bit support * libosmo-sccp ** Add new [[libosmo-sigtran:]] library with SS7 AS/ASP Link/Linkset handling, M3UA support, new FSM based SCCP implementation ** Add [[osmo-stp:]] program * osmo-bts ** inform BSC of PCU disconnect ** fix measurement reporting period ** exclude idle channels from uplink measurement processing ** octphy: measurement reports h3. May 2017 * libosmocore ** fix embedded builds ** import and generalise 'sercomm' from osmocom-bb into libosmocore ** SSE optimized convolutional coder ** fix wrong GSM FR codec SID frame generation ** doxygen docs for libosmocoding * osmo-bsc ** TS 04.14 mobile station side loop control * osmo-bts ** consistently check all RSL and OML TLVs for minimum length value ** fix bit-order in every HR codec parameter (spec compliance) ** OML get/set attribute handling ** SI2quater support ** bypass radio link timeout for lab testing * osmo-bsc ** PCU socket support for BSC-colocated PCU for Ericsson RBS2000 ** reelase 1.0.1 * "M3UA and SUA testing as part of jenkins":http://lists.osmocom.org/pipermail/openbsc/2017-May/010698.html * "osmo-gsm-tester produces successful runs with NITB as well as new AoIP":http://lists.osmocom.org/pipermail/openbsc/2017-May/010760.html h3. June 2017 * libosmocore ** doxygen autobrief ** doxygen documentation for libosmogb * osmo-bts ** use CLOCK_MONOTONIC timer for GSM frame timer ** PDTCH loopback support h3. July 2017 * "Plan for openbsc.git split and code review":http://lists.osmocom.org/pipermail/openbsc/2017-July/010914.html * libosmocore ** PDP charging characteristics in GSUP ** PRBS sequence generators ** multicast IP related helper functions ** 'make release' target * libosmo-sccp ** SCCP address book * osmo-bts ** new virtual BTS @osmo-bts-virtual@ for testing without radio hardware ** don't send dummy UI frames on unused BCCH slots on TC=5 ** GSMTAP: don't log/send fill frames consisting of only padding * osmo-hlr ** change to default GSUP port 4222 h3. August 2017 * "Support for SMPP Delivery Receipt / GSM03.40 Status Report":http://lists.osmocom.org/pipermail/openbsc/2017-August/011023.html * "Jenkins now executing M3UA, SUA and GGSN testsuite":http://lists.osmocom.org/pipermail/openbsc/2017-August/011043.html * libosmocore ** fix crash in lapd_est_req() * libosmo-abis ** release 0.4.0 * osmo-bts ** osmo-bts-trx: fix MS power control loop ** release 0.6.0 ** support sending/removing SI13 to/from PCU * osmo-bsc ** indicate R99+ MSC in SI3 to enable UMTS AKA over GERAN * osmo-sgsn ** properly report GERAN/UTRAN mode in PDP CTX ACT REQ to GGSN * osmo-msc ** implement IuCS support ** split openbsc.git into osmo-bsc.git, osmo-msc.git and osmo-sgsn.git * openggsn ** Add IPv6 address pool and IPV6 user (inner) plane support ** release 0.94 h3. September 2017 * libosmocore.git ** "'show talloc-context' VTY introspection":http://lists.osmocom.org/pipermail/openbsc/2017-June/010771.html ** CTRL parsing unit tests ** unification of vty exit/end commands * osmo-hlr ** CTRL interface tests -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ron.menez at entropysolution.com Tue Jan 2 01:44:26 2018 From: ron.menez at entropysolution.com (Ron) Date: Tue, 2 Jan 2018 01:44:26 +0000 Subject: GPS Timing Out-of-Sync Monitoring Message-ID: <222CF943-3A06-4531-93E8-A456A61C6A03@entropysolution.com> Hi All, Happy New Year. I?m not sure if it is appropriate to asked this in this forum or to the SDR vendor but here goes. Is there a way to monitor if the GPS Timing is still sync or not while all the OSMO elements are running? We are using an Ettus B210 with a GPSDO, osmo-trx, osmo-bts-trx, and osmo-nitb running in UBUNTU 16.04 TIA. Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From anindya.s at toshniwalcontrols.com Wed Jan 3 11:20:45 2018 From: anindya.s at toshniwalcontrols.com (Anindya Sankar Roy) Date: Wed, 3 Jan 2018 16:50:45 +0530 Subject: Unable to make calls Message-ID: Hello, I have built osmo-bsc, osmo-msc, osmo-hlr, osmo-stp, osmo-mgcp and connected them successfuly in the same computer. When I try to make calls it gives the folowing error in MGCP osmo-mgw -c newmgw.cfg <0001> telnet_interface.c:104 telnet at 127.0.0.1 4243 <0011> mgw_main.c:336 Configured for MGCP. <0011> mgcp_protocol.c:827 DLCX: endpoint:0x1 deleting connection ... <0011> mgcp_protocol.c:832 DLCX: endpoint:0x1 endpoint is not holding a connection. <0011> mgcp_protocol.c:827 DLCX: endpoint:0x2 deleting connection ... <0011> mgcp_protocol.c:832 DLCX: endpoint:0x2 endpoint is not holding a connection. <0011> mgcp_protocol.c:453 CRCX: creating new connection ... <0011> mgcp_protocol.c:79 endpoint:1 RTP-setup: Endpoint is in loopback mode, stopping here! <0000> mgcp_network.c:188 endpoint:0x1 Failed to send dummy RTP packet. <0011> mgcp_protocol.c:650 CRCX: endpoint:0x1 connection successfully created <0011> mgcp_protocol.c:827 DLCX: endpoint:0x1 deleting connection ... <0011> mgcp_protocol.c:895 DLCX: endpoint:0x1 missing ci (connectionIdentifier), will remove all connections at once <0011> mgcp_protocol.c:453 CRCX: creating new connection ... <0011> mgcp_protocol.c:79 endpoint:1 RTP-setup: Endpoint is in loopback mode, stopping here! <0000> mgcp_network.c:188 endpoint:0x1 Failed to send dummy RTP packet. PFA configuration files for all the blocks that I have been using to run the system and also the pcap trace. Please tell me what am I doing wrong due to which I am unable to make calls. Thanks Anindya? calltrace.pcap ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: newmgw.cfg Type: application/octet-stream Size: 143 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-msc.cfg Type: application/octet-stream Size: 335 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-bsc.cfg Type: application/octet-stream Size: 3030 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-stp.cfg Type: application/octet-stream Size: 424 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-hlr.cfg Type: application/octet-stream Size: 305 bytes Desc: not available URL: From alexander.chemeris at gmail.com Thu Jan 4 05:16:17 2018 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 4 Jan 2018 14:16:17 +0900 Subject: Handover log Message-ID: Hello, all, I wonder if anyone has thought about introducing a handover log (to a file or a DB) to OsmoBSC/OsmoNITB? For small deployments <6 BTS you can just add every BTS to neighbor lists of each other and don't worry, but once you get above that, you face a handover optimization issue. I.e. which BTS should be neighbors of which other ones. Initial assigning of the neighbors can be done by simply looking at coverage maps of each BTS. But once the network is actually used there is a lot of useful information about the network performance which can be extracted from the handover history - which cells have issues handing over to each other, etc. -- Regards, Alexander Chemeris. CTO/Founder, Fairwaves, Inc. https://fairwaves.co From stsp at stsp.name Fri Jan 5 17:04:59 2018 From: stsp at stsp.name (Stefan Sperling) Date: Fri, 5 Jan 2018 18:04:59 +0100 Subject: question about 'lai & lac' paging Message-ID: <20180105170458.GA19240@byrne.stsp.name> I am trying to fix issue OS#2754 "Paging on LAI not working". There are two tests related to this issue: 1) osmo-bsc/tests/bssap/bssap_test 2) TC_paging_imsi_nochan_lai in osmo-ttcn3-hacks/bss The first test is successful with my patch below. But the second test fails. It looks as if the MSC expects a response which is not delivered. I am unsure if the test has wrong expectations or if osmo-bsc is not sending a required response? The test's verdict is: Test case TC_paging_imsi_nochan_lai finished. Verdict: fail reason: Timeout expecting { msg_disc := { msg_group := RSL_MDISC_CCHAN (6), transparent := false }, msg_type := RSL_MT_PAGING_CMD (21), ies := { { iei := ?, body := { chan_nr := { u := { ch0 := RSL_CHAN_NR_PCH_AGCH (18) }, tn := ? } } }, { iei := ?, body := { paging_group := ? } }, { iei := ?, body := { ms_identity := { len := ?, payload := ? } } }, * } } Note that the existing ttcn3 test for the LAC case, which is already supported, and also covered by the bssap_test, fails in the same way: Test case TC_paging_imsi_nochan_lac finished. Verdict: fail reason: Timeout expecting { msg_disc := { msg_group := RSL_MDISC_CCHAN (6), transparent := false }, msg_type := RSL_MT_PAGING_CMD (21), ies := { { iei := ?, body := { chan_nr := { u := { ch0 := RSL_CHAN_NR_PCH_AGCH (18) }, tn := ? } } }, { iei := ?, body := { paging_group := ? } }, { iei := ?, body := { ms_identity := { len := ?, payload := ? } } }, * } } Any hints how to proceed? Thanks, Stefan >From 01200d452971cd20c8a0304e180c2d11ff399d3f Mon Sep 17 00:00:00 2001 From: Stefan Sperling Date: Fri, 5 Jan 2018 17:22:11 +0100 Subject: [PATCH] Implement support for paging by LAI. This is very similar to the paging by LAC case. We can simply extract the LAC at a different offset. Change-Id: Ic3c62ff0fccea586794ea4b3c275a0685cc9326e Related: OS#2751 --- src/osmo-bsc/osmo_bsc_bssap.c | 9 +++++++++ tests/bssap/bssap_test.c | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/src/osmo-bsc/osmo_bsc_bssap.c b/src/osmo-bsc/osmo_bsc_bssap.c index 45861ccc..9bc59623 100644 --- a/src/osmo-bsc/osmo_bsc_bssap.c +++ b/src/osmo-bsc/osmo_bsc_bssap.c @@ -288,6 +288,15 @@ static int bssmap_handle_paging(struct bsc_msc_data *msc, lac = GSM_LAC_RESERVED_ALL_BTS; switch (cell_ident) { + case CELL_IDENT_LAI_AND_LAC: + if (data_length != 6) { + LOGP(DMSC, LOGL_ERROR, "Paging IMSI %s: Cell Identifier List for BSS (0x%x)" + " has invalid length: %u, paging entire BSS anyway (%s)\n", + mi_string, CELL_IDENT_BSS, data_length, osmo_hexdump(data, data_length)); + } + lac = osmo_load16be(&data[4]); + break; + case CELL_IDENT_LAC: if (data_length != 3) { LOGP(DMSC, LOGL_ERROR, "Paging IMSI %s: Cell Identifier List for LAC (0x%x)" diff --git a/tests/bssap/bssap_test.c b/tests/bssap/bssap_test.c index 579cae23..2fa2b1fe 100644 --- a/tests/bssap/bssap_test.c +++ b/tests/bssap/bssap_test.c @@ -71,7 +71,7 @@ struct { { "001952080859512069000743940904010844601a060415f5490065", /* ^^^^^^^^^^^^ Cell Identifier List: LAI */ - GSM_LAC_RESERVED_ALL_BTS, 0 + 0x65, 0 }, }; -- 2.14.1 From laforge at gnumonks.org Sat Jan 6 10:20:37 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 6 Jan 2018 11:20:37 +0100 Subject: question about 'lai & lac' paging In-Reply-To: <20180105170458.GA19240@byrne.stsp.name> References: <20180105170458.GA19240@byrne.stsp.name> Message-ID: <20180106102037.GA22559@nataraja> Hi Stefan, On Fri, Jan 05, 2018 at 06:04:59PM +0100, Stefan Sperling wrote: > I am trying to fix issue OS#2754 "Paging on LAI not working". > But the second test fails. It looks as if the MSC expects a response > which is not delivered. I am unsure if the test has wrong expectations > or if osmo-bsc is not sending a required response? It's not a "response", but the BSC converts the (single) BSSMAP PAGING into 0-N (typically 1-N) "RSL PAGING CMD" towards the BTSs. The TTCN-3 tests always simulate the entire surrounding of the program in a fixture. So for the BSC tests, it doesn't just simulate the MSC, but simulates the MSC and BTSs (and soon also the MGW) to be able to control all external interfaces. The cell identifier list included in the BSSMAP paging tells the BSC which BTSs it should start to page. The current code (AFAIR) a) doesn't understand the concept of the list but only looks at the first element? b) doesn't understand a lot of the different address formats (CGI, CI, ...) > Test case TC_paging_imsi_nochan_lai finished. Verdict: fail reason: > Timeout expecting { msg_disc := { msg_group := RSL_MDISC_CCHAN (6), > transparent := false }, msg_type := RSL_MT_PAGING_CMD (21), ies := { { > iei := ?, body := { chan_nr := { u := { ch0 := RSL_CHAN_NR_PCH_AGCH (18) > }, tn := ? } } }, { iei := ?, body := { paging_group := ? } }, { iei := > ?, body := { ms_identity := { len := ?, payload := ? } } }, * } } This means that one one of the BTSs where we expect the RSL PAGING it didn't arrive. > Any hints how to proceed? you can verify the test correctness by monitoring the RSL link and checking which of the BTSs (if any) get the RSL PAGING CMD and which not, and whether that reflects the LAC/CI values configured in osmo-bsc.cfg. Regarding your patch: I think it falls quite a bit short. > switch (cell_ident) { > + case CELL_IDENT_LAI_AND_LAC: > + if (data_length != 6) { > + LOGP(DMSC, LOGL_ERROR, "Paging IMSI %s: Cell Identifier List for BSS (0x%x)" > + " has invalid length: %u, paging entire BSS anyway (%s)\n", > + mi_string, CELL_IDENT_BSS, data_length, osmo_hexdump(data, data_length)); > + } > + lac = osmo_load16be(&data[4]); > + break; please don't just use magic numbers like 6 + 4 but actually define structs or otherwise parse the data. Also, a LAI includes MCC+MNC, so you must verify if all parameters match. Also, as indicated, the existing code does not traverse the cell identification list yet, does it? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Sun Jan 7 17:23:56 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 7 Jan 2018 18:23:56 +0100 Subject: Handover log In-Reply-To: References: Message-ID: <20180107172356.GA18097@my.box> On Thu, Jan 04, 2018 at 02:16:17PM +0900, Alexander Chemeris wrote: > Hello, all, > > I wonder if anyone has thought about introducing a handover log (to a > file or a DB) to OsmoBSC/OsmoNITB? Seems like a good idea. The main question is how to implement it in a way that is easy to evaluate. We have those rate rounters that could easily count handovers per BTS, but to count between each pair of BTSes is an exponential thing. I'm not closely familiar with them, but we also have external DB storage mechanisms of events; I wonder whether we have documentation for those? I can't find much on it, just know we used it on 34c3. The simplistic approach would be to just output logging statements. We have the HO (handover) and soon the HODEC (handover decision) logging categories, with minor effort that logging could be made easily parsable by external tooling. So all for it, as always the questions are how to and who will implement. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From msuraev at sysmocom.de Sun Jan 7 17:30:55 2018 From: msuraev at sysmocom.de (Max) Date: Sun, 7 Jan 2018 18:30:55 +0100 Subject: build slaves Message-ID: Hi. Seems like jobs which update osmo-ci and osmo-python-tests on build slaves are failing for 20+ days. This only happens for some of the slaves but not the others. I'd like to understand why this is happening and, ideally, fix it. However, there're few obstacles: - there seems to be no "console output" or logs available for those jobs - am I looking at the wrong place? - we don't seems to have any docs on the wiki about the build slaves On a related note, do we have a ticket tracking progress on automated build slave creation? -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Sun Jan 7 18:15:07 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 7 Jan 2018 19:15:07 +0100 Subject: question about 'lai & lac' paging In-Reply-To: <20180106102037.GA22559@nataraja> References: <20180105170458.GA19240@byrne.stsp.name> <20180106102037.GA22559@nataraja> Message-ID: <20180107181507.GC18097@my.box> On Sat, Jan 06, 2018 at 11:20:37AM +0100, Harald Welte wrote: > please don't just use magic numbers like 6 + 4 but actually define > structs or otherwise parse the data. Also, a LAI includes MCC+MNC, so should probably be using gsm48_decode_lai() in libosmocore/include/osmocom/gsm/gsm48.h > you must verify if all parameters match. since we currently have just a single global MCC+MNC setting, being correct means ignoring paging for mismatching MCC+MNC... I guess we want error log for that case, since the MSC shouldn't even send us paging for mismatching MCC+MNC? > Also, as indicated, the existing code does not traverse the cell > identification list yet, does it? IIUC receiving a LAI identification for paging is not related to a cell identification list? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Sun Jan 7 18:48:48 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 7 Jan 2018 19:48:48 +0100 Subject: stricter rate counter group allocation breaks applications In-Reply-To: <20171220141338.GC2155@nataraja> References: <20171220005000.GA7452@my.box> <20171220141338.GC2155@nataraja> Message-ID: <20180107184848.GD18097@my.box> On Wed, Dec 20, 2017 at 03:13:38PM +0100, Harald Welte wrote: > * how can a patch that breaks 'make check' of osmo-bts/openbsc/osmo-pcu, etc. > be merged to libosmcoore? Isn't that what we have inverse dependencies for > in the gerrit verification jobs? In libosmocore gerrit, we don't test depending projects. We'd find the master jobs failing if we merge a breaking change. > * how can it be that even after the patch is merged, we find the osmo-sgsn issue > only by manual testing and not by automatic testing? I also wondered about this, and AFAICT the reason is that osmo-gsm-tester doesn't do more than one GPRS subscriber. SGSN worked fine with one subscriber, so we need a test that adds a second GPRS user to osmo-gsm-tester... https://osmocom.org/issues/2820 Maybe a titan test would be more fitting to add a number of subscribers? > b) introduce an intermediate stage, something like a "staging" branch. > So the existing code review and gerrit-jenkins-build-testing would > make patches end up in 'staging' first, where then the slower > (hourly/daily/...) tests like osmo-gsm-tester are executed. And > only once that's green, we go towards master. We could cause each and every gerrit patch to trigger osmo-gsm-tester and/or titan test runs; i.e. perfect coverage means "infinite" jenkins job effort and time to wait for V+1. Aiming for perfect coverage before merging patches seems to me to be fighting windmills; we can get better with every failure, but I guess we'll always need reassurance from real-world tests. So far the tradeoff was to rely on master job failures and osmo-gsm-tester failures to be reported. Which works only as long as we watch those and as long as they are able to catch the particular issues. Maybe an IRC bot to report build failures to #osmocom-dev could be nice besides mail notifications... just dreaming. > I don't think that any given single "event network" should dictate the patch > merging. Was of course a selfish, not entirely serious request, with a wink. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Sun Jan 7 21:19:32 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 7 Jan 2018 22:19:32 +0100 Subject: build slaves In-Reply-To: <5d214c1b-498a-669d-7f2b-ee5811e1d26d@sysmocom.de> References: <5d214c1b-498a-669d-7f2b-ee5811e1d26d@sysmocom.de> Message-ID: <20180107211932.GH18097@my.box> On Sun, Jan 07, 2018 at 05:58:40PM +0100, Max wrote: > Hi. > > Seems like jobs which update osmo-ci and osmo-python-tests on build slaves are > failing for 20+ days. This only happens for some of the slaves but not the others. > > I'd like to understand why this is happening and, ideally, fix it. However, there're > few obstacles: It's because of "ImportError: No module named setuptools" since your commit, where you obviously never checked whether setuptools is available on the build slaves: Author: Max AuthorDate: Fri Dec 15 12:12:01 2017 +0100 Commit: Max CommitDate: Fri Dec 15 20:40:41 2017 +0100 Use setuptools for packaging According to https://docs.python.org/3/library/distutils.html the setuptools are used in place of distutils anyway. Using it directly allows us to make packaging more flexible: specify dependencies, automatically find package name etc. Change-Id: I39ee53f352001e47c6df055cbec52d638480253d I see console logs fine. https://jenkins.osmocom.org/jenkins/job/update-osmo-ci-on-slaves/63/label=OsmocomBuild1/console https://jenkins.osmocom.org/jenkins/job/update-osmo-ci-on-slaves/63/label=build2-deb8build/console So do we really need this setuptools thing or can we just revert the change? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From msuraev at sysmocom.de Mon Jan 8 09:27:53 2018 From: msuraev at sysmocom.de (Max) Date: Mon, 8 Jan 2018 10:27:53 +0100 Subject: build slaves In-Reply-To: <20180107211932.GH18097@my.box> References: <5d214c1b-498a-669d-7f2b-ee5811e1d26d@sysmocom.de> <20180107211932.GH18097@my.box> Message-ID: <721ca17f-d1bc-904e-f703-723fa71ea3f4@sysmocom.de> On 07.01.2018 22:19, Neels Hofmeyr wrote: > It's because of > "ImportError: No module named setuptools" > > since your commit, where you obviously never checked whether setuptools is > available on the build slaves My bad, for some reason I was sure it's part of the standard library. > I see console logs fine. > https://jenkins.osmocom.org/jenkins/job/update-osmo-ci-on-slaves/63/label=OsmocomBuild1/console > https://jenkins.osmocom.org/jenkins/job/update-osmo-ci-on-slaves/63/label=build2-deb8build/console I've looked in the wrong place after all - I don't see equivalent for update-osmo-python-on-slaves job. > So do we really need this setuptools thing or can we just revert the change? > Yes, we really need it because that's how jenkins.sh used by update-osmo-python-on-slaves works: by calling python setup.py ... Besides, it's only missing on build1-debian9-lxc - we should bring it on par with build2-deb8build andOsmocomBuild1 slaves. Or, better yet, unify the process of provisioning a build slave. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Mon Jan 8 10:38:10 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 8 Jan 2018 11:38:10 +0100 Subject: osmo-python-tests py3 fail Message-ID: <20180108103810.GA23816@my.box> Hi Max, in osmo-python-tests master, I did python2 setup.py install rm -rf build/ dist/ osmopython.egg-info python3 setup.py install which results in osmotestvty.py installed as py3, causing an encoding problem which I mentioned; py3 is a lot more than print() with braces, see the error log below. So in principle I still don't understand why the py2 scripts need to be made py3 compatible, and why I need to add 'from future' imports to py3 scripts now. There has to be a better way. About the need to rm the installation artifacts, there is no mention of it in the README. And even when I remove those, I still get py2 scripts installed as py3. So anyone is bound to get this error: " osmotestvty.py -p /n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc -w /n/s/osmo-dev/make/osmo-msc -v confpath /n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc, workdir /n/s/osmo-dev/make/osmo-msc Running tests for specific VTY commands test_history (__main__.TestVTY) ... Launch: ./src/osmo-msc/osmo-msc -c /n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc/doc/examples/osmo-msc/osmo-msc.cfg from /n/s/osmo-dev/make/osmo-msc Opening /dev/null Launching: PWD=/n/s/osmo-dev/make/osmo-msc './src/osmo-msc/osmo-msc' '-c' '/n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc/doc/examples/osmo-msc/osmo-msc.cfg' Terminating took 2.679s ERROR test_terminal_length (__main__.TestVTY) ... Launch: ./src/osmo-msc/osmo-msc -c /n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc/doc/examples/osmo-msc/osmo-msc.cfg from /n/s/osmo-dev/make/osmo-msc Launching: PWD=/n/s/osmo-dev/make/osmo-msc './src/osmo-msc/osmo-msc' '-c' '/n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc/doc/examples/osmo-msc/osmo-msc.cfg' Terminating took 2.679s ERROR test_unknown_command (__main__.TestVTY) ... Launch: ./src/osmo-msc/osmo-msc -c /n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc/doc/examples/osmo-msc/osmo-msc.cfg from /n/s/osmo-dev/make/osmo-msc Launching: PWD=/n/s/osmo-dev/make/osmo-msc './src/osmo-msc/osmo-msc' '-c' '/n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc/doc/examples/osmo-msc/osmo-msc.cfg' Terminating took 2.679s ERROR ====================================================================== ERROR: test_history (__main__.TestVTY) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python3.6/dist-packages/osmopython-0.0.6-py3.6.egg/EGG-INFO/scripts/osmotestvty.py", line 56, in test_history File "/usr/local/lib/python3.6/dist-packages/osmopython-0.0.6-py3.6.egg/osmopy/obscvty.py", line 223, in command return self._common_command(request, close) File "/usr/local/lib/python3.6/dist-packages/osmopython-0.0.6-py3.6.egg/osmopy/obscvty.py", line 179, in _common_command self.socket.send("%s\r" % request) TypeError: a bytes-like object is required, not 'str' " With your recent set of changes, you have not only hung all the build slaves' osmo-python-tests updates for 3 weeks, but also dismantled the installation. I wonder how it was possible for this to get past your testing. I will try to get the scripts working for me now. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Jan 8 10:51:49 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 8 Jan 2018 11:51:49 +0100 Subject: build slaves In-Reply-To: <721ca17f-d1bc-904e-f703-723fa71ea3f4@sysmocom.de> References: <5d214c1b-498a-669d-7f2b-ee5811e1d26d@sysmocom.de> <20180107211932.GH18097@my.box> <721ca17f-d1bc-904e-f703-723fa71ea3f4@sysmocom.de> Message-ID: <20180108105149.GA8640@my.box> On Mon, Jan 08, 2018 at 10:27:53AM +0100, Max wrote: > Yes, we really need it because that's how jenkins.sh used by > update-osmo-python-on-slaves works: by calling python setup.py ... How then did it always work until now, without setuptools installed. > Besides, it's only missing on build1-debian9-lxc *And* in the Dockerfile that is building the docker image we use for various tests, which is why we see the same error on various slaves. With the problem I encountered described in the mail I sent a minute ago, I am reluctant to enable the installation of newest osmo-python-tests because then it will likely install osmotestvty.py as py3, which will render numerous py tests unusable. So I will not install setuptools before the osmotestvty.py problem is resolved. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From msuraev at sysmocom.de Mon Jan 8 11:05:31 2018 From: msuraev at sysmocom.de (Max) Date: Mon, 8 Jan 2018 12:05:31 +0100 Subject: osmo-python-tests py3 fail In-Reply-To: <20180108103810.GA23816@my.box> References: <20180108103810.GA23816@my.box> Message-ID: <18af1704-1a72-59cb-7e32-1975f1360a87@sysmocom.de> Sorry for the inconvenience, I'm looking into it - I've made https://osmocom.org/issues/2821 to track this. On 08.01.2018 11:38, Neels Hofmeyr wrote: > With your recent set of changes, you have not only hung all the build slaves' > osmo-python-tests updates for 3 weeks, but also dismantled the installation. I > wonder how it was possible for this to get past your testing. Seem like I had symlink from before which interfered with pip install. I've reproduced it now. I'll see how can we integrate it into jenkins tests in osmo-python-tests. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Mon Jan 8 11:15:07 2018 From: msuraev at sysmocom.de (Max) Date: Mon, 8 Jan 2018 12:15:07 +0100 Subject: osmo-python-tests py3 fail In-Reply-To: <20180108103810.GA23816@my.box> References: <20180108103810.GA23816@my.box> Message-ID: <0858f085-21c2-a390-4808-091161dcd6d0@sysmocom.de> Hi. The quick workaround is available in https://gerrit.osmocom.org/#/c/5677/ Just in case make sure to uninstall older version first - I'm not sure if setup.py handles it correctly. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Mon Jan 8 11:18:36 2018 From: msuraev at sysmocom.de (Max) Date: Mon, 8 Jan 2018 12:18:36 +0100 Subject: osmo-python-tests py3 fail In-Reply-To: <20180108103810.GA23816@my.box> References: <20180108103810.GA23816@my.box> Message-ID: <26afd9a2-9374-6426-8b10-2fd365f93cde@sysmocom.de> On a related note. On 08.01.2018 11:38, Neels Hofmeyr wrote: > With your recent set of changes, you have not only hung all the build slaves' > osmo-python-tests updates for 3 weeks This should not be happening - I do not see any notification for failed builds from update-* jobs. I think it's essential to get those right away to avoid such hiccups in future. I'll look into jobs definitions to see if I can fix those. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Mon Jan 8 11:25:09 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 8 Jan 2018 12:25:09 +0100 Subject: osmo-python-tests py3 fail In-Reply-To: <20180108103810.GA23816@my.box> References: <20180108103810.GA23816@my.box> Message-ID: <20180108112509.GB8640@my.box> Interesting, I notice that now the python scripts are no longer installed in a way where you can find or grep them. In /usr/local/bin, I get "EASY-INSTALL" shims like #!/usr/bin/python2 # EASY-INSTALL-SCRIPT: 'osmopython==0.0.6','osmotestvty.py' __requires__ = 'osmopython==0.0.6' __import__('pkg_resources').run_script('osmopython==0.0.6', 'osmotestvty.py') and in /usr/local/lib/py*, all I get is "egg" files which appear to be zip balls of the actual python scripts. Actual error messages refer to the file inside the zip egg: > File "/usr/local/lib/python3.6/dist-packages/osmopython-0.0.6-py3.6.egg/osmopy/obscvty.py", line 179, in _common_command > self.socket.send("%s\r" % request) > TypeError: a bytes-like object is required, not 'str' I liked to have the scripts in plain sight, I doubt that zipping some py script has any benefits that outweigh unzipping cost ... but I guess it's bearable when aware of this. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From stsp at stsp.name Mon Jan 8 11:43:23 2018 From: stsp at stsp.name (Stefan Sperling) Date: Mon, 8 Jan 2018 12:43:23 +0100 Subject: question about 'lai & lac' paging In-Reply-To: <20180107181507.GC18097@my.box> References: <20180105170458.GA19240@byrne.stsp.name> <20180106102037.GA22559@nataraja> <20180107181507.GC18097@my.box> Message-ID: <20180108114322.GA67306@byrne.stsp.name> On Sun, Jan 07, 2018 at 07:15:07PM +0100, Neels Hofmeyr wrote: > On Sat, Jan 06, 2018 at 11:20:37AM +0100, Harald Welte wrote: > > please don't just use magic numbers like 6 + 4 but actually define > > structs or otherwise parse the data. Also, a LAI includes MCC+MNC, so > > should probably be using gsm48_decode_lai() in libosmocore/include/osmocom/gsm/gsm48.h Indeed, thanks for the hint. > > you must verify if all parameters match. > > since we currently have just a single global MCC+MNC setting, being correct > means ignoring paging for mismatching MCC+MNC... I guess we want error log for > that case, since the MSC shouldn't even send us paging for mismatching MCC+MNC? > > > Also, as indicated, the existing code does not traverse the cell > > identification list yet, does it? > > IIUC receiving a LAI identification for paging is not related to a cell > identification list? There is in fact a list of LAIs but our tests send just one element. The code below is probably better but the test seems to use MCC/MNC values that don't match the configured network -- perhaps a byte-ordering issue? When I run ttcn3 test TC_paging_imsi_nochan_lai I now see: osmo_bsc_bssap.c:365 Not paging IMSI 001010000000009: MCC/MNC in Cell Identifier List (0/10) do not match our network (1/1) I haven't yet looked where ttcn3's MCC/MNC values are set. Any hints? commit f27c6a09f7e96e29b61b313412b27dd0dd67ec90 Author: Stefan Sperling Date: Fri Jan 5 17:22:11 2018 +0100 Implement support for paging by LAI. Also, parse the complete cell identifier list for both LAC and LAI. Change-Id: Ic3c62ff0fccea586794ea4b3c275a0685cc9326e Related: OS#2751 diff --git a/src/osmo-bsc/osmo_bsc_bssap.c b/src/osmo-bsc/osmo_bsc_bssap.c index 45861ccc..9225e6dd 100644 --- a/src/osmo-bsc/osmo_bsc_bssap.c +++ b/src/osmo-bsc/osmo_bsc_bssap.c @@ -228,21 +228,52 @@ static int bssmap_handle_reset(struct bsc_msc_data *msc, return 0; } +/* Page a subscriber based on TMSI and LAC. + * A non-zero return value indicates a fatal out of memory condition. */ +static int +page_subscriber(struct bsc_msc_data *msc, uint16_t tmsi, uint32_t lac, + const char *mi_string, uint8_t chan_needed) +{ + struct bsc_subscr *subscr; + + subscr = bsc_subscr_find_or_create_by_imsi(msc->network->bsc_subscribers, + mi_string); + if (!subscr) { + LOGP(DMSC, LOGL_ERROR, "Failed to allocate a subscriber for %s\n", mi_string); + return -1; + } + + subscr->lac = lac; + subscr->tmsi = tmsi; + + LOGP(DMSC, LOGL_INFO, "Paging request from MSC IMSI: '%s' TMSI: '0x%x/%u' LAC: 0x%x\n", mi_string, tmsi, tmsi, lac); + bsc_grace_paging_request(msc->network->bsc_data->rf_ctrl->policy, + subscr, chan_needed, msc); + + /* the paging code has grabbed its own references */ + bsc_subscr_put(subscr); + + return 0; +} + /* GSM 08.08 ? 3.2.1.19 */ static int bssmap_handle_paging(struct bsc_msc_data *msc, struct msgb *msg, unsigned int payload_length) { - struct bsc_subscr *subscr; struct tlv_parsed tp; char mi_string[GSM48_MI_SIZE]; uint32_t tmsi = GSM_RESERVED_TMSI; - unsigned int lac; + uint16_t lac, *lacp_be; + uint16_t mcc; + uint16_t mnc; uint8_t data_length; + int remain; const uint8_t *data; uint8_t chan_needed = RSL_CHANNEED_ANY; uint8_t cell_ident; tlv_parse(&tp, gsm0808_att_tlvdef(), msg->l4h + 1, payload_length - 1, 0, 0); + remain = payload_length - 1; if (!TLVP_PRESENT(&tp, GSM0808_IE_IMSI)) { LOGP(DMSC, LOGL_ERROR, "Mandatory IMSI not present.\n"); @@ -251,6 +282,7 @@ static int bssmap_handle_paging(struct bsc_msc_data *msc, LOGP(DMSC, LOGL_ERROR, "Wrong content in the IMSI\n"); return -1; } + remain -= TLVP_LEN(&tp, GSM0808_IE_IMSI); if (!TLVP_PRESENT(&tp, GSM0808_IE_CELL_IDENTIFIER_LIST)) { LOGP(DMSC, LOGL_ERROR, "Mandatory CELL IDENTIFIER LIST not present.\n"); @@ -260,6 +292,12 @@ static int bssmap_handle_paging(struct bsc_msc_data *msc, if (TLVP_PRESENT(&tp, GSM0808_IE_TMSI) && TLVP_LEN(&tp, GSM0808_IE_TMSI) == 4) { tmsi = ntohl(tlvp_val32_unal(&tp, GSM0808_IE_TMSI)); + remain -= TLVP_LEN(&tp, GSM0808_IE_TMSI); + } + + if (remain <= 0) { + LOGP(DMSC, LOGL_ERROR, "Payload too short.\n"); + return -1; } /* @@ -280,22 +318,67 @@ static int bssmap_handle_paging(struct bsc_msc_data *msc, LOGP(DMSC, LOGL_ERROR, "Paging IMSI %s: Zero length Cell Identifier List\n", mi_string); return -1; + } else if (data_length > remain) { + LOGP(DMSC, LOGL_ERROR, "Paging IMSI %s: Bogus Cell Identifier List length\n", + mi_string); + return -1; + } + remain = data_length; /* ignore payload data beyond data_length */ + + if (TLVP_PRESENT(&tp, GSM0808_IE_CHANNEL_NEEDED) && TLVP_LEN(&tp, GSM0808_IE_CHANNEL_NEEDED) == 1) + chan_needed = TLVP_VAL(&tp, GSM0808_IE_CHANNEL_NEEDED)[0] & 0x03; + + if (TLVP_PRESENT(&tp, GSM0808_IE_EMLPP_PRIORITY)) { + LOGP(DMSC, LOGL_ERROR, "eMLPP is not handled\n"); } cell_ident = data[0] & 0xf; + remain -= 1; /* cell ident consumed */ /* Default fallback: page entire BSS */ lac = GSM_LAC_RESERVED_ALL_BTS; switch (cell_ident) { + case CELL_IDENT_LAI_AND_LAC: { + struct gsm48_loc_area_id lai; + int i = 0; + while (remain >= sizeof(lai)) { + /* Parse and decode 5-byte LAI list element (see TS 08.08 3.2.2.27). + * Copy data to stack to prevent unaligned access in gsm48_decode_lai(). */ + lai.digits[0] = data[1 + i * sizeof(lai)]; + lai.digits[1] = data[2 + i * sizeof(lai)]; + lai.digits[2] = data[3 + i * sizeof(lai)]; + memcpy(&lai.lac, &data[4 + i * sizeof(lai)], sizeof(lai.lac)); /* don't byte-swap yet */ + if (gsm48_decode_lai(&lai, &mcc, &mnc, &lac) != 0) { + LOGP(DMSC, LOGL_ERROR, "Paging IMSI %s: Invalid LAI in Cell Identifier List " + "for BSS (0x%x), paging entire BSS anyway (%s)\n", + mi_string, CELL_IDENT_BSS, osmo_hexdump(data, data_length)); + lac = GSM_LAC_RESERVED_ALL_BTS; + break; + } + if (mcc == msc->network->country_code && mnc == msc->network->network_code) { + if (page_subscriber(msc, tmsi, lac, mi_string, chan_needed) != 0) + break; + } else + LOGP(DMSC, LOGL_DEBUG, "Not paging IMSI %s: MCC/MNC in Cell Identifier List " + "(%d/%d) do not match our network (%d/%d)\n", mi_string, mcc, mnc, + msc->network->country_code, msc->network->network_code); + + remain -= sizeof(lai); + i++; + } + break; + } + case CELL_IDENT_LAC: - if (data_length != 3) { - LOGP(DMSC, LOGL_ERROR, "Paging IMSI %s: Cell Identifier List for LAC (0x%x)" - " has invalid length: %u, paging entire BSS instead (%s)\n", - mi_string, CELL_IDENT_LAC, data_length, osmo_hexdump(data, data_length)); - break; + lacp_be = (uint16_t *)(&data[1]); + while (remain >= sizeof(*lacp_be)) { + lac = osmo_load16be(lacp_be); + if (page_subscriber(msc, tmsi, lac, mi_string, chan_needed) != 0) + break; + remain -= sizeof(*lacp_be); + lacp_be++; } - lac = osmo_load16be(&data[1]); break; case CELL_IDENT_BSS: @@ -304,39 +387,19 @@ static int bssmap_handle_paging(struct bsc_msc_data *msc, " has invalid length: %u, paging entire BSS anyway (%s)\n", mi_string, CELL_IDENT_BSS, data_length, osmo_hexdump(data, data_length)); } + if (page_subscriber(msc, tmsi, GSM_LAC_RESERVED_ALL_BTS, mi_string, chan_needed) != 0) + break; break; default: LOGP(DMSC, LOGL_NOTICE, "Paging IMSI %s: unimplemented Cell Identifier List (0x%x)," " paging entire BSS instead (%s)\n", mi_string, cell_ident, osmo_hexdump(data, data_length)); + if (page_subscriber(msc, tmsi, GSM_LAC_RESERVED_ALL_BTS, mi_string, chan_needed) != 0) + break; break; } - if (TLVP_PRESENT(&tp, GSM0808_IE_CHANNEL_NEEDED) && TLVP_LEN(&tp, GSM0808_IE_CHANNEL_NEEDED) == 1) - chan_needed = TLVP_VAL(&tp, GSM0808_IE_CHANNEL_NEEDED)[0] & 0x03; - - if (TLVP_PRESENT(&tp, GSM0808_IE_EMLPP_PRIORITY)) { - LOGP(DMSC, LOGL_ERROR, "eMLPP is not handled\n"); - } - - subscr = bsc_subscr_find_or_create_by_imsi(msc->network->bsc_subscribers, - mi_string); - if (!subscr) { - LOGP(DMSC, LOGL_ERROR, "Failed to allocate a subscriber for %s\n", mi_string); - return -1; - } - - subscr->lac = lac; - subscr->tmsi = tmsi; - - LOGP(DMSC, LOGL_INFO, "Paging request from MSC IMSI: '%s' TMSI: '0x%x/%u' LAC: 0x%x\n", mi_string, tmsi, tmsi, lac); - bsc_grace_paging_request(msc->network->bsc_data->rf_ctrl->policy, - subscr, chan_needed, msc); - - /* the paging code has grabbed its own references */ - bsc_subscr_put(subscr); - return 0; } diff --git a/tests/bssap/bssap_test.c b/tests/bssap/bssap_test.c index 579cae23..2fa2b1fe 100644 --- a/tests/bssap/bssap_test.c +++ b/tests/bssap/bssap_test.c @@ -71,7 +71,7 @@ struct { { "001952080859512069000743940904010844601a060415f5490065", /* ^^^^^^^^^^^^ Cell Identifier List: LAI */ - GSM_LAC_RESERVED_ALL_BTS, 0 + 0x65, 0 }, }; From laforge at gnumonks.org Mon Jan 8 12:25:16 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 8 Jan 2018 13:25:16 +0100 Subject: question about 'lai & lac' paging In-Reply-To: <20180108114322.GA67306@byrne.stsp.name> References: <20180105170458.GA19240@byrne.stsp.name> <20180106102037.GA22559@nataraja> <20180107181507.GC18097@my.box> <20180108114322.GA67306@byrne.stsp.name> Message-ID: <20180108122516.GC13147@nataraja> Hi Stefan, On Mon, Jan 08, 2018 at 12:43:23PM +0100, Stefan Sperling wrote: > The code below is probably better but the test seems to use MCC/MNC values > that don't match the configured network -- perhaps a byte-ordering issue? > When I run ttcn3 test TC_paging_imsi_nochan_lai I now see: > osmo_bsc_bssap.c:365 Not paging IMSI 001010000000009: MCC/MNC in Cell Identifier List (0/10) do not match our network (1/1) what do the protocol traces say? If you look with wireshark at both BSSMAP and RSL it should be pretty easy to see if wireshark also thinks there's some wrong encoding. > I haven't yet looked where ttcn3's MCC/MNC values are set. Any hints? See "private function f_enc_mcc_mnc(GsmMcc mcc, GsmMnc mnc)" in library/BSSMAP_Templates.ttcn and its callers. It may very well be buggy. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From djks74 at gmail.com Mon Jan 8 13:39:09 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Mon, 8 Jan 2018 20:39:09 +0700 Subject: osmocomBB with osmo-bts stuck need help Message-ID: Hello list, can someone look at my problem for osmocomBB for what is wrong on my setup? maybe I miss the configuration or something else? I can see the network but cannot registering my phone. my motorolla C117 attached with PL2303. here are the pcap and everything else : this is my osmo-bts config https://pastebin.com/QHE9cTiZ this is my openbsc config https://pastebin.com/efVhWs91 this is the pcap https://wsi.li/tayFOx1GakxK/746634 osmo-bts stuck on this level and cannot going more verbose. https://pastebin.com/2GPtNVw9 -- best regards, DUO -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at stsp.name Mon Jan 8 14:30:03 2018 From: stsp at stsp.name (Stefan Sperling) Date: Mon, 8 Jan 2018 15:30:03 +0100 Subject: question about 'lai & lac' paging In-Reply-To: <20180108122516.GC13147@nataraja> References: <20180105170458.GA19240@byrne.stsp.name> <20180106102037.GA22559@nataraja> <20180107181507.GC18097@my.box> <20180108114322.GA67306@byrne.stsp.name> <20180108122516.GC13147@nataraja> Message-ID: <20180108143003.GB67306@byrne.stsp.name> On Mon, Jan 08, 2018 at 01:25:16PM +0100, Harald Welte wrote: > Hi Stefan, > > On Mon, Jan 08, 2018 at 12:43:23PM +0100, Stefan Sperling wrote: > > The code below is probably better but the test seems to use MCC/MNC values > > that don't match the configured network -- perhaps a byte-ordering issue? > > When I run ttcn3 test TC_paging_imsi_nochan_lai I now see: > > osmo_bsc_bssap.c:365 Not paging IMSI 001010000000009: MCC/MNC in Cell Identifier List (0/10) do not match our network (1/1) > > what do the protocol traces say? If you look with wireshark at both BSSMAP and RSL > it should be pretty easy to see if wireshark also thinks there's some wrong encoding. Wireshark shows "MCC 0" and "MNC 010" in the BSSMAP paging frame. > > I haven't yet looked where ttcn3's MCC/MNC values are set. Any hints? > > See "private function f_enc_mcc_mnc(GsmMcc mcc, GsmMnc mnc)" in library/BSSMAP_Templates.ttcn > and its callers. It may very well be buggy. With Daniel's help I could get the right MCC/MNC in wireshark. See https://gerrit.osmocom.org/#/c/5682 I now see paging happening for both BTS 0 and 2 but the ttcn3 TC_paging_imsi_nochan_lai test is still unhappy (same error). I suppose this means either it does not receive the RSL paging message (which shows up in wireshark) or the message template doesn't match? I've been trying to spot a problem in the template but so far no luck. From axilirator at gmail.com Mon Jan 8 15:35:58 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 8 Jan 2018 21:35:58 +0600 Subject: osmocomBB with osmo-bts stuck need help Message-ID: Hi Sandi, > I can see the network but cannot registering my phone. Try to add the following settings at the end of the OsmoNiTB configuration: > nitb > subscriber-create-on-demand > assign-tmsi And please let me know if this would help. I'll correct the wiki page. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From djks74 at gmail.com Mon Jan 8 16:12:30 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Mon, 8 Jan 2018 23:12:30 +0700 Subject: osmocomBB with osmo-bts stuck need help In-Reply-To: References: Message-ID: Hi Vadim, Thanks for replied. sorry if I make mistake to put the line on configuration, I tried many option to the line and seems Im not success to put at right line https://pastebin.com/zyTGaX2J and just add like this seems not working https://pastebin.com/a1J2dhex Thanks. DUO On Mon, Jan 8, 2018 at 10:35 PM, Vadim Yanitskiy wrote: > Hi Sandi, > > > I can see the network but cannot registering my phone. > > Try to add the following settings at the end of the OsmoNiTB configuration: > > > nitb > > subscriber-create-on-demand > > assign-tmsi > > And please let me know if this would help. I'll correct the wiki page. > > With best regards, > Vadim Yanitskiy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Mon Jan 8 16:38:01 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 8 Jan 2018 22:38:01 +0600 Subject: osmocomBB with osmo-bts stuck need help In-Reply-To: References: Message-ID: Well, > sorry if I make mistake to put the line on configuration > and just add like this seems not working https://pastebin.com/a1J2dhex According to your config, this is incorrect way. The 'nitb' section should be outside the 'network', for example: https://pastebin.com/nQ0cy5pS And thanks, I forgot to add this while writing the wiki... Will fix soon. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Mon Jan 8 17:32:39 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 8 Jan 2018 23:32:39 +0600 Subject: osmocomBB with osmo-bts stuck need help In-Reply-To: References: Message-ID: Let's keep the public conversation, there are no secrets, right? ;) > Here is the pcap attached and here is the osmo-nitb > log https://pastebin.com/NJa0YU08 > > here is the osmo-bts log https://pastebin.com/RZ0au5yA > > hope you know what is wrong. Thanks Have a look at the following log lines: > trx_if.c:217 Enqueuing TRX control command 'CMD NOHANDOVER 0 0' > ... > trx_if.c:371 Response message: 'RSP NOHANDOVER -1' > trx_if.c:403 transceiver (phy0.0) rejected TRX command > with response: 'RSP NOHANDOVER -1' > bts.c:208 Shutting down BTS 0, Reason TRX-CTRL-MSG: CRITICAL For some reason, the OsmocomBB transceiver rejects the command. Despite it's implemented and should work as expected. Let's look at the source code (trx.c:400 _trx_ctrl_cmd_(no)handover): > int n, tn, ss = 0; > > n = sscanf(args, "%d %d", &tn, &ss); > > if ((n < 1) || (tn < 0) || (tn > 7) || (ss < 0) || ((ss > 8))) > return _trx_ctrl_send_resp(trx, cmd, "%d %d %d", -1, tn, ss); > > // ... Try to debug this condition on your side. I cannot reproduce your problem... With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From djks74 at gmail.com Mon Jan 8 17:42:39 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Tue, 9 Jan 2018 00:42:39 +0700 Subject: osmocomBB with osmo-bts stuck need help In-Reply-To: References: Message-ID: OK, Thanks alot Vadim. :-) will try to debug and will keep report. Thanks. DUO On Tue, Jan 9, 2018 at 12:32 AM, Vadim Yanitskiy wrote: > Let's keep the public conversation, > there are no secrets, right? ;) > > > Here is the pcap attached and here is the osmo-nitb > > log https://pastebin.com/NJa0YU08 > > > > here is the osmo-bts log https://pastebin.com/RZ0au5yA > > > > hope you know what is wrong. Thanks > > Have a look at the following log lines: > > > trx_if.c:217 Enqueuing TRX control command 'CMD NOHANDOVER 0 0' > > ... > > trx_if.c:371 Response message: 'RSP NOHANDOVER -1' > > trx_if.c:403 transceiver (phy0.0) rejected TRX command > > with response: 'RSP NOHANDOVER -1' > > bts.c:208 Shutting down BTS 0, Reason TRX-CTRL-MSG: CRITICAL > > For some reason, the OsmocomBB transceiver rejects the command. > Despite it's implemented and should work as expected. > > Let's look at the source code (trx.c:400 _trx_ctrl_cmd_(no)handover): > > > int n, tn, ss = 0; > > > > n = sscanf(args, "%d %d", &tn, &ss); > > > > if ((n < 1) || (tn < 0) || (tn > 7) || (ss < 0) || ((ss > 8))) > > return _trx_ctrl_send_resp(trx, cmd, "%d %d %d", -1, tn, ss); > > > > // ... > > Try to debug this condition on your side. > I cannot reproduce your problem... > > With best regards, > Vadim Yanitskiy. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djks74 at gmail.com Mon Jan 8 18:11:03 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Tue, 9 Jan 2018 01:11:03 +0700 Subject: osmocomBB with osmo-bts stuck need help In-Reply-To: References: Message-ID: Dear Vadim, just FYI, the jolly branch stuck and cannot sync to BTS on my side. I was using Sylvain branch for the test. Thanks. DUO On Tue, Jan 9, 2018 at 12:42 AM, Sandi Suhendro wrote: > OK, > Thanks alot Vadim. :-) will try to debug and will keep report. > > Thanks. > DUO > > > On Tue, Jan 9, 2018 at 12:32 AM, Vadim Yanitskiy > wrote: > >> Let's keep the public conversation, >> there are no secrets, right? ;) >> >> > Here is the pcap attached and here is the osmo-nitb >> > log https://pastebin.com/NJa0YU08 >> > >> > here is the osmo-bts log https://pastebin.com/RZ0au5yA >> > >> > hope you know what is wrong. Thanks >> >> Have a look at the following log lines: >> >> > trx_if.c:217 Enqueuing TRX control command 'CMD NOHANDOVER 0 0' >> > ... >> > trx_if.c:371 Response message: 'RSP NOHANDOVER -1' >> > trx_if.c:403 transceiver (phy0.0) rejected TRX command >> > with response: 'RSP NOHANDOVER -1' >> > bts.c:208 Shutting down BTS 0, Reason TRX-CTRL-MSG: CRITICAL >> >> For some reason, the OsmocomBB transceiver rejects the command. >> Despite it's implemented and should work as expected. >> >> Let's look at the source code (trx.c:400 _trx_ctrl_cmd_(no)handover): >> >> > int n, tn, ss = 0; >> > >> > n = sscanf(args, "%d %d", &tn, &ss); >> > >> > if ((n < 1) || (tn < 0) || (tn > 7) || (ss < 0) || ((ss > 8))) >> > return _trx_ctrl_send_resp(trx, cmd, "%d %d %d", -1, tn, ss); >> > >> > // ... >> >> Try to debug this condition on your side. >> I cannot reproduce your problem... >> >> With best regards, >> Vadim Yanitskiy. >> >> > > > > -- best regards, Krazy Sandi Blue Soho Recordings Number One Recordings -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrejob at netcourrier.com Tue Jan 9 15:59:56 2018 From: pierrejob at netcourrier.com (pierrejob at netcourrier.com) Date: Tue, 9 Jan 2018 16:59:56 +0100 (CET) Subject: project openbsc GSM-GPRS (not 3G), Message-ID: Hi, In the context of a project GSM-GPRS (not 3G), I recovered the sources of the branch Master (github.com/osmocom). - osmo-pcu - openbsc (osmo-nitb, osmo-bsc, osmo-bsc-nat, osmo-bsc-mgcp) - libosmocore - libosmo-abis - libosmo-netif - liosmo-sccp - libsmpp34 - libosmo-ggsn - libosmo-sgsn (it seems not include in the openbsc's directory). Does the Library osmo-sgsn?still need to be generated? because?during the compilation?only the module "osmo-gbproxy" is compiled. When I look at the Makefile (osmo-sgsn/src/gprs), the following lines are commented: #am__append_1 = \ # $(LIBASN1C_CFLAGS) \ # $(LIBOSMOSIGTRAN_CFLAGS) \ # $(LIBOSMORANAP_CFLAGS) \ # $(NULL) bin_PROGRAMS = osmo-gbproxy$(EXEEXT) $(am__EXEEXT_1) #am__append_2 = \ # osmo-sgsn \ # osmo-gtphub \ # $(NULL) #am__append_3 = \ # $(LIBOSMOSIGTRAN_LIBS) \ # $(LIBOSMORANAP_LIBS) \ # $(LIBASN1C_LIBS) \ # $(NULL) Let me know I you think there are mistakes. Thanks Pierre -------------- next part -------------- An HTML attachment was scrubbed... URL: From djks74 at gmail.com Tue Jan 9 17:07:32 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Wed, 10 Jan 2018 00:07:32 +0700 Subject: osmocomBB with osmo-bts stuck need help In-Reply-To: References: Message-ID: Dear Vadim, I tried to install Jolly branch many times and this is the debug result which always stop when sync to BTS. when I flashing my C117 https://pastebin.com/mGGFzmrE then I start transceiver https://pastebin.com/GYeyiKrJ I was thinking the package is broken? testing with sylvain is work, just like yesterday my registering still problem. but this Jolly branch even cannot produce sync. looks like its not connected at all. please help to look. Thanks. Thanks, DUO On Tue, Jan 9, 2018 at 1:11 AM, Sandi Suhendro wrote: > Dear Vadim, > just FYI, the jolly branch stuck and cannot sync to BTS on my side. > I was using Sylvain branch for the test. > > Thanks. > > DUO > > On Tue, Jan 9, 2018 at 12:42 AM, Sandi Suhendro wrote: > >> OK, >> Thanks alot Vadim. :-) will try to debug and will keep report. >> >> Thanks. >> DUO >> >> >> On Tue, Jan 9, 2018 at 12:32 AM, Vadim Yanitskiy >> wrote: >> >>> Let's keep the public conversation, >>> there are no secrets, right? ;) >>> >>> > Here is the pcap attached and here is the osmo-nitb >>> > log https://pastebin.com/NJa0YU08 >>> > >>> > here is the osmo-bts log https://pastebin.com/RZ0au5yA >>> > >>> > hope you know what is wrong. Thanks >>> >>> Have a look at the following log lines: >>> >>> > trx_if.c:217 Enqueuing TRX control command 'CMD NOHANDOVER 0 0' >>> > ... >>> > trx_if.c:371 Response message: 'RSP NOHANDOVER -1' >>> > trx_if.c:403 transceiver (phy0.0) rejected TRX command >>> > with response: 'RSP NOHANDOVER -1' >>> > bts.c:208 Shutting down BTS 0, Reason TRX-CTRL-MSG: CRITICAL >>> >>> For some reason, the OsmocomBB transceiver rejects the command. >>> Despite it's implemented and should work as expected. >>> >>> Let's look at the source code (trx.c:400 _trx_ctrl_cmd_(no)handover): >>> >>> > int n, tn, ss = 0; >>> > >>> > n = sscanf(args, "%d %d", &tn, &ss); >>> > >>> > if ((n < 1) || (tn < 0) || (tn > 7) || (ss < 0) || ((ss > 8))) >>> > return _trx_ctrl_send_resp(trx, cmd, "%d %d %d", -1, tn, ss); >>> > >>> > // ... >>> >>> Try to debug this condition on your side. >>> I cannot reproduce your problem... >>> >>> With best regards, >>> Vadim Yanitskiy. >>> >>> >> >> >> >> > > > -- > best regards, > Krazy Sandi > Blue Soho Recordings > Number One Recordings > -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Tue Jan 9 17:47:39 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Tue, 9 Jan 2018 23:47:39 +0600 Subject: osmocomBB with osmo-bts stuck need help In-Reply-To: References: Message-ID: Hi, > I tried to install Jolly branch many times and this is > the debug result which always stop when sync to BTS. > > I was thinking the package is broken? testing with sylvain > is work, just like yesterday my registering still problem. > but this Jolly branch even cannot produce sync. Hmm, I just found out that both handover related commands are implemented in jolly/testing, but not in sylvain/testing: http://git.osmocom.org/osmocom-bb/tree/src/host/layer23/src/ transceiver/trx.c?h=jolly/testing#n440 http://git.osmocom.org/osmocom-bb/tree/src/host/layer23/src/ transceiver/trx.c?h=sylvain/testing#n369 You can implement a dummy command handler for sylvain/testing. Or use jolly's branch. But as I remember, there was a problem with some firmware images: http://osmocom.org/projects/baseband/wiki/Toolchain > note: as of 2013-10-20, if you use a toolchain with gcc >=4.8, > the firmware can be compiled, but will hang as soon as you want > to sync to an ARFCN. This issue has been fixed in master. > > http://cgit.osmocom.org/osmocom-bb/commit/ > ?id=a903b3c1ee27047c79728b18ff6340d23d1aad2e I think this information is enough to solve your problem. And moreover, we are using the openbsc mailing list, while there is a dedicated one. Let's finish this thread here. And good luck! With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From djks74 at gmail.com Tue Jan 9 17:59:12 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Wed, 10 Jan 2018 00:59:12 +0700 Subject: osmocomBB with osmo-bts stuck need help In-Reply-To: References: Message-ID: Ok. Thanks Vadim. really helpfull. :-) DUO On Wed, Jan 10, 2018 at 12:47 AM, Vadim Yanitskiy wrote: > Hi, > > > I tried to install Jolly branch many times and this is > > the debug result which always stop when sync to BTS. > > > > I was thinking the package is broken? testing with sylvain > > is work, just like yesterday my registering still problem. > > but this Jolly branch even cannot produce sync. > > Hmm, I just found out that both handover related commands > are implemented in jolly/testing, but not in sylvain/testing: > > http://git.osmocom.org/osmocom-bb/tree/src/host/layer23/src/ > transceiver/trx.c?h=jolly/testing#n440 > > http://git.osmocom.org/osmocom-bb/tree/src/host/layer23/src/ > transceiver/trx.c?h=sylvain/testing#n369 > > You can implement a dummy command handler for sylvain/testing. > Or use jolly's branch. But as I remember, there was a problem > with some firmware images: > > http://osmocom.org/projects/baseband/wiki/Toolchain > > > note: as of 2013-10-20, if you use a toolchain with gcc >=4.8, > > the firmware can be compiled, but will hang as soon as you want > > to sync to an ARFCN. This issue has been fixed in master. > > > > http://cgit.osmocom.org/osmocom-bb/commit/ > > ?id=a903b3c1ee27047c79728b18ff6340d23d1aad2e > > I think this information is enough to solve your problem. > And moreover, we are using the openbsc mailing list, while > there is a dedicated one. Let's finish this thread here. > > And good luck! > > > With best regards, > Vadim Yanitskiy. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Jan 9 19:16:40 2018 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 9 Jan 2018 20:16:40 +0100 Subject: project openbsc GSM-GPRS (not 3G), In-Reply-To: References: Message-ID: <20180109191640.GL13147@nataraja> On Tue, Jan 09, 2018 at 04:59:56PM +0100, pierrejob at netcourrier.com wrote: > In the context of a project GSM-GPRS (not 3G), I recovered the sources of the branch Master (github.com/osmocom). Please kindly follow the vast amount of information that we provide on the osmocom.org project website and the related wikis. http://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box is a good entry point. > - osmo-pcu > - libosmocore > - libosmo-abis > - libosmo-netif > - liosmo-sccp > - libsmpp34 you will need all the above. > - libosmo-ggsn > - libosmo-sgsn (it seems not include in the openbsc's directory). there are no such libraries. there are actual *programs* osmo-sgsn and osmo-ggsn. > - openbsc (osmo-nitb, osmo-bsc, osmo-bsc-nat, osmo-bsc-mgcp) this is the old legacy NITB code. You may use that, but please note that all active development for about one year now has been focussing on the new post-NITB architecture with separate OsmoBSC, OsmoMSC and OsmoHLR. > Does the Library osmo-sgsn?still need to be generated? because?during the compilation?only the module "osmo-gbproxy" is compiled. osmo-sgsn is not a library. it is a program implementing the SGSN node, and you need to check it out from the osmo-sgsn repository (http://git.osmocom.org/osmo-sgsn/) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Wed Jan 10 00:24:47 2018 From: holger at freyther.de (Holger Freyther) Date: Wed, 10 Jan 2018 00:24:47 +0000 Subject: Approach to system testing for Osmocom stack Message-ID: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> Hi, the lua binding code was added to be able to automate OpenBSC tests. In theory we should be able to do this for SMS and UpdateLocation (call handling with MNCC exposing is left as a todo) but in practice we miss a piece of software to coordinate this and run the test. We miss it because it is an interesting problem but also I lost time on switching countries, learning new tricks at a project... The basic testing structure looks easy as well. We want to define the number of concurrent subscribers (0, 10, 100, 1000, n) and to make it simple a single test (UL, send SMS, t) and execute the same test for each subscriber and call it a success if y% of tests succeed within time T. The way to measure this is easy as well. The lua script would print some data (e.g. the name of the ms) when it starts and completes. For some degrees of freedom I don't have a good idea.. and feedback is welcome. I am not sure if I should spawn, configure, add subscribers, a flavor of Osmocom cellular? I look into having some set of templates for the config, the stack to launch and in concept it looks awfully similar to something the GSM tester is doing. Shall we leave virtbts/cellular to the Osmocom tester and just focus on coordinating mobile? My feeling is to leave this to the Osmo GSM tester. If we have n subscribers I would launch m copies of "mobile" (but run multiple MS in a single binary). So with 4 MS per mobile process and 10k subs we would end with 2.5k processes + many log messages coming from each. Would that scale with python? Should we look into doing this one in Go? Or can some of GSM tester be used (the template part)? I would probably design this concurrently with Go(besides being the first). any ideas/comments? holger From xidianzhanghao at 126.com Wed Jan 10 02:40:20 2018 From: xidianzhanghao at 126.com (hao_zhang) Date: Wed, 10 Jan 2018 10:40:20 +0800 (GMT+08:00) Subject: help: openbsc and osmocombb transfer problem Message-ID: <61587fd1.f97.160ddf09682.Coremail.xidianzhanghao@126.com> sorry to bother you, I have a question to ask you: i install openbsc and osmocombb in a pc. i want to transfer authentication information (rand) from osmocombb to openbsc, and transfer sres information from openbsc to osmocombb. What should I do? zhanghao -------------- next part -------------- An HTML attachment was scrubbed... URL: From pespin at sysmocom.de Wed Jan 10 09:50:52 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 10 Jan 2018 10:50:52 +0100 Subject: Approach to system testing for Osmocom stack In-Reply-To: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> Message-ID: <176b1459-0e02-49ab-ae1a-475773ac56ac@sysmocom.de> Hi Holger, I never used virtbts but I think it should be quite easy adding support for it in osmo-gsm-tester. The only big issue I can think of is that we need to find a way to differentiate between virtbs and other bts since they use a different communication medium and then that means that the requested modems to run for the test with virtbts need to be selected accordingly (ie. don't allocate an ofono modem from the object pool if we are using a virbts). That can probably accomplished easily too, by adding new attributes to objects to describe that characteristic. It can be a good idea to support this at some point if we want to test for compatibility between "mobile" app + virtbs and other BTS and modems, for instance see if we can place a call between a regular modem with a sysmobts and a "mobile" app + virtbts. Then we can make sure we don't add regressions in the future. Regarding the performance, I imagine osmo-gsm-tester will have a hard time running that amount of objects/processes, as we didn't have this kind of scenarios in mind since it was developed having real hardware in mind. Furthermore, the unit running osmo-gsm-tester is not a big machine so I guess it would have problems running that amount of processes alone. I don't think the language is going to be that important, it depends more on how do you plan intend to manage all of those processes in a efficient way from system OS point of view. Regards, -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From laforge at gnumonks.org Wed Jan 10 11:55:13 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 10 Jan 2018 12:55:13 +0100 Subject: Approach to system testing for Osmocom stack In-Reply-To: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> Message-ID: <20180110115513.GZ13147@nataraja> Hi Holger, On Wed, Jan 10, 2018 at 12:24:47AM +0000, Holger Freyther wrote: > the lua binding code was added to be able to automate OpenBSC tests. > In theory we should be able to do this for SMS and UpdateLocation > (call handling with MNCC exposing is left as a todo) but in practice > we miss a piece of software to coordinate this and run the test. We > miss it because it is an interesting problem but also I lost time on > switching countries, learning new tricks at a project... Sure, I understand. However, it is definitely a part that we're very much looking forward to have :) > The basic testing structure looks easy as well. We want to define the > number of concurrent subscribers (0, 10, 100, 1000, n) and to make it > simple a single test (UL, send SMS, t) and execute the same test for > each subscriber and call it a success if y% of tests succeed within > time T. The way to measure this is easy as well. The lua script would > print some data (e.g. the name of the ms) when it starts and > completes. One might also think of a more structured format to return the data, but that could always added later. One could e.g. print a XML or JSON snippet that's easier to parse/consume by whoever processes it. What I also believe is very important is some kind of rate limiting / staggering when starting up. We know a single-BTS setup will for sure fail lots of LU if you stat 1k MS at the same time. So there should be some kind of provision to say something "start 1000 MS at a rate of 10 per second". I wouldn't go for more elaborate schemes, but simply a single linear rate/slope. > I am not sure if I should spawn, configure, add subscribers, a flavor > of Osmocom cellular? I look into having some set of templates for the > config, the stack to launch and in concept it looks awfully similar to > something the GSM tester is doing. Shall we leave virtbts/cellular to > the Osmocom tester and just focus on coordinating mobile? My feeling > is to leave this to the Osmo GSM tester. Yes, I think it's ok to focus on the "tester" side and not on the IUT (implementation under test) side. So we assume that the user will somehow bring up the [virtual] cellular network before excuting the load test. One preferred way of doing this is - I agree - by reusing those parts from osmo-gsm-tester. > If we have n subscribers I would launch m copies of "mobile" (but run > multiple MS in a single binary). I would argue the number of MS per 'mobile' should be configurable from 1-N. > So with 4 MS per mobile process and 10k subs we would end with 2.5k > processes + many log messages coming from each. The question is how many of those log messages do we need/want. In order to avoid the risk of 'mobile' blocking on writing to stdout/stderr, I think it would be best not to pipe that into other processes but write to files (could even be tmpfs!) and process the files after the run? > Would that scale with python? Should we look into doing this one in > Go? > Or can some of GSM tester be used (the template part)? I'm not sufficiently familiar with osmo-gsm-tester to say if we can use it. On an abstract level, I would think the "defining resources and generating configuration files" part should be reusable, but then it also just uses (jinja2?) templates that anyone can use in python. And whether it's sufficiently scalable to generate thousands of config files, I don't know either. > I would probably design this concurrently with Go(besides being the > first). I would suggest we keep not further the number of programming languages one needs to understand. But then, it's "just" a tool for load testing, so probably not that critical after all. My naive assumption would be that starting 2.5k processes (and processing the SIGCHILD from python should be possible without causing a performance/scalability problem? As indicated, log file processing could be handled later, or one could configure stdio logging to be absolutely minimal (with verbose logs going to files)? My attached test program (not using python 'subprocess' as I couldn't find a way to make it do non-blocking wait for the child to terminate) runs perfectly fine here, even without any rate limiting I get the following on my laptop: $ time ./subproc.py 2018-01-10 12:44:14,811 INFO Beginning starting of processes 2018-01-10 12:44:15,603 INFO Started 2500 processes 2018-01-10 12:44:18,607 INFO Waited for all processes ./subproc.py 2.74s user 1.46s system 108% cpu 3.881 total So 2500 processes could be forked in less than one second, and the starting/reaping in python needed onyl very few seconds of system time - compared with the amount of resources required to run the 'mobile' programs including the GSMTAP socket traffic etc. for sure neglectable? Now of course '/bin/sleep' is a much simpler program to start, but the overhead of the python "orchestration" doesn't change with the resource footprint of the program started. Just my thoughs, as usual. The decision is yours... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: subproc.py Type: text/x-python Size: 979 bytes Desc: not available URL: From msuraev at sysmocom.de Wed Jan 10 14:13:32 2018 From: msuraev at sysmocom.de (Max) Date: Wed, 10 Jan 2018 15:13:32 +0100 Subject: Approach to system testing for Osmocom stack In-Reply-To: <20180110115513.GZ13147@nataraja> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> <20180110115513.GZ13147@nataraja> Message-ID: <06fb6d6f-8237-4c25-6c11-ff037cac778a@sysmocom.de> On 10.01.2018 12:55, Harald Welte wrote: > The question is how many of those log messages do we need/want. In > order to avoid the risk of 'mobile' blocking on writing to > stdout/stderr, I think it would be best not to pipe that into other > processes but write to files (could even be tmpfs!) and process the > files after the run? Another option would be to change "log gsmtap" to not duplicate it to stdout/stderr and use it from mobile. > > My attached test program (not using python 'subprocess' as I couldn't find > a way to make it do non-blocking wait for the child to terminate) runs > perfectly fine here Alternative approach would be using asyncio module - one example can be found in osmo-python-tests/tests/test_py3.py Just a suggestion though - have not tried either with thousands of processes. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From holger at freyther.de Wed Jan 10 22:52:59 2018 From: holger at freyther.de (Holger Freyther) Date: Wed, 10 Jan 2018 22:52:59 +0000 Subject: Approach to system testing for Osmocom stack In-Reply-To: <20180110115513.GZ13147@nataraja> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> <20180110115513.GZ13147@nataraja> Message-ID: > On 10. Jan 2018, at 11:55, Harald Welte wrote: > > Hi Holger, > Sure, I understand. However, it is definitely a part that we're very > much looking forward to have :) me too... I dislike not having made progress here. > One might also think of a more structured format to return the data, but > that could always added later. One could e.g. print a XML or JSON > snippet that's easier to parse/consume by whoever processes it. Good point. There is nothing that prevents us opening a file/socket/pipe from the lua code and writing out something. We would need to write out complete XML/JSON documents (and likely multiple of them) or define a framing ourselves.. > What I also believe is very important is some kind of rate limiting / > staggering when starting up. We know a single-BTS setup will for sure > fail lots of LU if you stat 1k MS at the same time. So there should be > some kind of provision to say something "start 1000 MS at a rate of 10 > per second". I wouldn't go for more elaborate schemes, but simply a > single linear rate/slope. Makes sense. > Yes, I think it's ok to focus on the "tester" side and not on the IUT > (implementation under test) side. So we assume that the user will > somehow bring up the [virtual] cellular network before excuting the load > test. One preferred way of doing this is - I agree - by reusing those > parts from osmo-gsm-tester. Good. I will leave this part. > Now of course '/bin/sleep' is a much simpler program to start, but the > overhead of the python "orchestration" doesn't change with the resource > footprint of the program started. Thanks for looking at the process creation. I was concerned of Python's IO model to read from 2.5k FDs but apparently it has epoll. Computers are powerful and a single python process could be fine here... okay. That reduces some degrees of the freedom. Where to put it? Into the OsmocomBB sources? Osmo GSM tester even if it might not share much code? holger From laforge at gnumonks.org Wed Jan 10 23:39:26 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 11 Jan 2018 00:39:26 +0100 Subject: Approach to system testing for Osmocom stack In-Reply-To: References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> <20180110115513.GZ13147@nataraja> Message-ID: <20180110233926.GE13147@nataraja> Hi Holger, On Wed, Jan 10, 2018 at 10:52:59PM +0000, Holger Freyther wrote: > okay. That reduces some degrees of the freedom. Where to put it? Into the > OsmocomBB sources? Osmo GSM tester even if it might not share much code? If you reuse osmo-gsm-tester code for templates or the like, then it should probably go there. If not, OsmocomBB seems like the more logical place. Would be great if in that case it is some kind of python library/module and a small 'main' wrapper around. This way the library could later be used by whatever is starting both the network and the 'mobile's. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From msuraev at sysmocom.de Thu Jan 11 10:17:24 2018 From: msuraev at sysmocom.de (Max) Date: Thu, 11 Jan 2018 11:17:24 +0100 Subject: multiple log destinations Message-ID: <1dbe46e8-1e53-e840-a259-96b8a2f21a65@sysmocom.de> Hi. We have several kind of logs in libosmocore: 'log stderr', 'log file ...', 'log gsmtap' etc. Some of them are naturally singleton: you can't have 2 stderrs at the same time. Some are naturally parallel - it make sense to log different things into different files. What about "log gsmtap"? On the one hand sending to different hosts might make sense, on the other hand, the receiver can do filtering by itself. The current implementation does not allow multiple "log gsmtap" entries but the code is kinda unclear - I don't understand if that's intentional. So, is it a "bug" or "feature"? Shall we opt for greater flexibility and fix the code to enable multiple gsmtap log destinations? Shall we opt for simplicity and fix the code to make it clear that log gsmtap is singleton? Do you have any use-case in mind where multiple "log gsmtap" would come in handy? Do you foresee any problems arising from multiple "log gsmtap"working in parallel? N. B: this has nothing to do with recording bursts into .pcap, this is about sending log output using the same facility we use for recording frames sent/received over the air. The frame recording is used in OsmoBTS/PCU, the logging is used in all Osmo* projects. Just in case, the patch enabling multiple 'log gsmtap ...' is available in https://gerrit.osmocom.org/#/c/5747/ so you can give it a try. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From radiarisainanasitraka at yahoo.fr Fri Jan 12 08:23:05 2018 From: radiarisainanasitraka at yahoo.fr (Radiarisainana Sitraka) Date: Fri, 12 Jan 2018 08:23:05 +0000 (UTC) Subject: A5/0 mobile Phone References: <734561444.2740617.1515745385736.ref@mail.yahoo.com> Message-ID: <734561444.2740617.1515745385736@mail.yahoo.com> Hello,I have some question, it just for curiosity! It's possible that a phone tell to the bts he did support only A5/0 encryption or it just only the BTS to command the ciphering !? and it is possible to do that for the osmocomBB !? Chears, -------------- next part -------------- An HTML attachment was scrubbed... URL: From djks74 at gmail.com Fri Jan 12 08:59:43 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Fri, 12 Jan 2018 15:59:43 +0700 Subject: Auto create subscribers on OpenBSC Message-ID: Any idea how to make : auto create subscriber = no ?? tried subscriber-create-on-demand but the DB subscriber still auto create. Thanks. DUO -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Fri Jan 12 13:44:29 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 12 Jan 2018 14:44:29 +0100 Subject: A5/0 mobile Phone In-Reply-To: <734561444.2740617.1515745385736@mail.yahoo.com> References: <734561444.2740617.1515745385736.ref@mail.yahoo.com> <734561444.2740617.1515745385736@mail.yahoo.com> Message-ID: <20180112134429.GC2687@my.box> On Fri, Jan 12, 2018 at 08:23:05AM +0000, Radiarisainana Sitraka wrote: > Hello,I have some question, it just for curiosity! It's possible that a phone tell to the bts he did support only A5/0 encryption or it just only the BTS to command the ciphering !? and it is possible to do that for the osmocomBB !? Whether to do Auth / Ciph is up to the MSC to decide. According to spec, phones are required to at least support A5/1. By coincidence, there has been a patch in that area recently: https://gerrit.osmocom.org/#/c/5560/2/src/libmsc/gsm_04_08.c So in principle, there are flags in Classmark 1, 2 and 3 indicating what A5s are supported by the MS, and the MSC matches them up with its own policy. However, any "real" MSC out there is likely to request at least A5/1 Authentication, regardless of your Classmark bits. If A5/1 is marked unsupported, it could even reject your MS altogether. But yes, you could send a crafted Classmark with all A5/N marked unsupported, and that should be possible with osmocom-bb. In the unlikely event that you get through with that, you've found an MSC bug / misconfiguration. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Fri Jan 12 13:47:40 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 12 Jan 2018 14:47:40 +0100 Subject: Auto create subscribers on OpenBSC In-Reply-To: References: Message-ID: <20180112134740.GD2687@my.box> On Fri, Jan 12, 2018 at 03:59:43PM +0700, Sandi Suhendro wrote: > tried subscriber-create-on-demand but the DB subscriber still auto create. Please post the actual config you tried. That should be the right setting. If you use the new osmo-bsc + osmo-msc + osmo-hlr, the entire create-on-demand is not supported at all, so that could be another option. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From djks74 at gmail.com Fri Jan 12 15:23:39 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Fri, 12 Jan 2018 22:23:39 +0700 Subject: Auto create subscribers on OpenBSC In-Reply-To: <20180112134740.GD2687@my.box> References: <20180112134740.GD2687@my.box> Message-ID: Dear Neels, here is the config https://pastebin.com/BKcPUbzb I uses the openbsc + osmo-bts. Thanks. DUO On Fri, Jan 12, 2018 at 8:47 PM, Neels Hofmeyr wrote: > On Fri, Jan 12, 2018 at 03:59:43PM +0700, Sandi Suhendro wrote: > > tried subscriber-create-on-demand but the DB subscriber still auto > create. > > Please post the actual config you tried. That should be the right setting. > > If you use the new osmo-bsc + osmo-msc + osmo-hlr, the entire > create-on-demand > is not supported at all, so that could be another option. > > ~N > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenkins at lists.osmocom.org Fri Jan 12 16:12:14 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Fri, 12 Jan 2018 16:12:14 +0000 (GMT) Subject: =?UTF-8?Q?Build_failed_in_Jenkins:_Coverity-?= =?UTF-8?Q?Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1729?= Message-ID: <1320154899.393.1515773534848.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 2.14 MB...] 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-iuh/doc' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/doc' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/doc' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh' make[3]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/pkgconfig' /usr/bin/install -c -m 644 libosmo-ranap.pc '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/pkgconfig' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh' + popd ~/osmo-ci/coverity/source-Osmocom + build_osmopcu + pushd osmo-pcu ~/osmo-ci/coverity/source-Osmocom/osmo-pcu ~/osmo-ci/coverity/source-Osmocom + do_build --enable-sysmocom-bts=yes --enable-sysmocom-dsp=yes + autoreconf --install --force libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac:21: installing './compile' configure.ac:24: installing './config.guess' configure.ac:24: installing './config.sub' configure.ac:9: installing './install-sh' configure.ac:9: installing './missing' src/Makefile.am: installing './depcomp' tests/Makefile.am:13: warning: source file 'alloc/AllocTest.cpp' is in a subdirectory, tests/Makefile.am:13: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. tests/Makefile.am:29: warning: source file 'bitcomp/BitcompTest.cpp' is in a subdirectory, tests/Makefile.am:29: but option 'subdir-objects' is disabled tests/Makefile.am:29: warning: source file '../src/egprs_rlc_compression.cpp' is in a subdirectory, tests/Makefile.am:29: but option 'subdir-objects' is disabled tests/Makefile.am:88: warning: source file 'codel/codel_test.c' is in a subdirectory, tests/Makefile.am:88: but option 'subdir-objects' is disabled tests/Makefile.am:35: warning: source file 'edge/EdgeTest.cpp' is in a subdirectory, tests/Makefile.am:35: but option 'subdir-objects' is disabled tests/Makefile.am:43: warning: source file 'emu/pcu_emu.cpp' is in a subdirectory, tests/Makefile.am:43: but option 'subdir-objects' is disabled tests/Makefile.am:43: warning: source file 'emu/test_replay_gprs_attach.cpp' is in a subdirectory, tests/Makefile.am:43: but option 'subdir-objects' is disabled tests/Makefile.am:43: warning: source file 'emu/openbsc_clone.c' is in a subdirectory, tests/Makefile.am:43: but option 'subdir-objects' is disabled tests/Makefile.am:43: warning: source file 'emu/test_pdp_activation.cpp' is in a subdirectory, tests/Makefile.am:43: but option 'subdir-objects' is disabled tests/Makefile.am:94: warning: source file 'fn/FnTest.cpp' is in a subdirectory, tests/Makefile.am:94: but option 'subdir-objects' is disabled tests/Makefile.am:72: warning: source file 'llc/LlcTest.cpp' is in a subdirectory, tests/Makefile.am:72: but option 'subdir-objects' is disabled tests/Makefile.am:83: warning: source file 'llist/LListTest.cpp' is in a subdirectory, tests/Makefile.am:83: but option 'subdir-objects' is disabled tests/Makefile.am:61: warning: source file 'ms/MsTest.cpp' is in a subdirectory, tests/Makefile.am:61: but option 'subdir-objects' is disabled tests/Makefile.am:7: warning: source file 'rlcmac/RLCMACTest.cpp' is in a subdirectory, tests/Makefile.am:7: but option 'subdir-objects' is disabled tests/Makefile.am:21: warning: source file 'tbf/TbfTest.cpp' is in a subdirectory, tests/Makefile.am:21: but option 'subdir-objects' is disabled tests/Makefile.am:53: warning: source file 'types/TypesTest.cpp' is in a subdirectory, tests/Makefile.am:53: but option 'subdir-objects' is disabled + ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom --enable-sysmocom-bts=yes --enable-sysmocom-dsp=yes configure: WARNING: unrecognized options: --enable-sysmocom-bts checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking whether make sets $(MAKE)... (cached) yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking how to run the C++ preprocessor... g++ -E checking for ld used by g++... /usr/bin/ld -m elf_x86_64 checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC -DPIC checking if g++ PIC flag -fPIC -DPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking if g++ supports -c -o file.o... (cached) yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... (cached) GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for pkg-config... /usr/bin/pkg-config checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.20... yes checking for ANSI C header files... (cached) yes checking for LIBOSMOCORE... yes checking for LIBOSMOVTY... yes checking for LIBOSMOGSM... yes checking for LIBOSMOGB... yes checking whether to enable direct DSP access for PDCH of sysmocom-bts... yes checking whether to enable direct PHY access for PDCH of NuRAN Wireless Litecell 1.5 BTS... no checking whether to enable VTY tests... no checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating osmo-pcu.pc config.status: creating include/Makefile config.status: creating src/Makefile config.status: creating examples/Makefile config.status: creating tests/Makefile config.status: creating Makefile config.status: executing tests/atconfig commands config.status: executing depfiles commands config.status: executing libtool commands configure: WARNING: unrecognized options: --enable-sysmocom-bts + make -j 3 Making all in include make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' Making all in src make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' CXX gprs_debug.lo CXX csn1.lo CXX gsm_rlcmac.lo CXX gprs_bssgp_pcu.lo gprs_bssgp_pcu.cpp:967:2: warning: #warning "This causes ASAN to complain. It is not critical for normal operation but should be fixed nevertheless" [-Wcpp] #warning "This causes ASAN to complain. It is not critical for normal operation but should be fixed nevertheless" ^ gprs_bssgp_pcu.cpp:76:12: warning: 'int parse_ra_cap(tlv_parsed*, MS_Radio_Access_capability_t*)' defined but not used [-Wunused-function] static int parse_ra_cap(struct tlv_parsed *tp, MS_Radio_Access_capability_t *rac) ^ CXX gprs_rlcmac.lo CXX gprs_rlcmac_sched.lo CXX gprs_rlcmac_meas.lo CXX gprs_rlcmac_ts_alloc.lo CXX gprs_ms.lo CXX gprs_ms_storage.lo CXX gsm_timer.lo CXX pcu_l1_if.lo CC pcu_vty.lo CXX pcu_vty_functions.lo CC mslot_class.lo CXX tbf.lo In file included from bts.h:37:0, from pcu_vty_functions.cpp:26: tbf.h: In function 'void tbf_print_vty_info(vty*, gprs_rlcmac_tbf*)': tbf.h:623:21: error: 'gprs_rlc_ul_window gprs_rlcmac_ul_tbf::m_window' is protected gprs_rlc_ul_window m_window; ^ pcu_vty_functions.cpp:70:38: error: within this context gprs_rlc_ul_window *win = &ul_tbf->m_window; ^ In file included from bts.h:37:0, from pcu_vty_functions.cpp:26: tbf.h:562:21: error: 'gprs_rlc_dl_window gprs_rlcmac_dl_tbf::m_window' is protected gprs_rlc_dl_window m_window; ^ pcu_vty_functions.cpp:82:38: error: within this context gprs_rlc_dl_window *win = &dl_tbf->m_window; ^ Makefile:763: recipe for target 'pcu_vty_functions.lo' failed make[1]: *** [pcu_vty_functions.lo] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' Makefile:448: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 1 [WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully. Emitted 1876 C/C++ compilation units (100%) successfully 1876 C/C++ compilation units (100%) are ready for analysis For more details, please look at: /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt Build step 'Execute shell' marked build as failure From laforge at gnumonks.org Sat Jan 13 13:02:11 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 13 Jan 2018 14:02:11 +0100 Subject: Make docker rebuild if apt repository changes Message-ID: <20180113130211.jivdkpf2lwpnaza6@nataraja> Hi Neels, I've seen some discusion (unfortunately on the sysmocom internal jaberr room, not on a public osmocom channel) related to the docker based jenkins verification jobs as follows: ADD http://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_8.0/Release /tmp/Release RUN apt-get update && apt-get install -y --no-install-recommends libosmocore-dev The "ADD" line will check if the "Release" file of the repository has changed. If yes, the cache will be invalidated, and the following line[s] will be re-run. If no, then the cache will remain. It's sub-optimal in that any change to the repository (even those that are unrelated to the packages used, [libosmocore-dev in this example]) will trigger an image re-build. But at least it will guarantee that any update to the libosmocore-dev package will trigger an image rebuild. See http://git.osmocom.org/docker-playground/tree/osmo-stp-master/Dockerfile for a real-world example Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jenkins at lists.osmocom.org Sat Jan 13 16:15:06 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Sat, 13 Jan 2018 16:15:06 +0000 (GMT) Subject: =?UTF-8?Q?Jenkins_build_is_back_to_normal_:_Cove?= =?UTF-8?Q?rity-Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1730?= In-Reply-To: <1320154899.393.1515773534848.JavaMail.jenkins@jenkins.osmocom.org> References: <1320154899.393.1515773534848.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <1919758109.424.1515860106549.JavaMail.jenkins@jenkins.osmocom.org> See From axilirator at gmail.com Sat Jan 13 22:12:33 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 14 Jan 2018 04:12:33 +0600 Subject: External USSD interface development Message-ID: Dear Harald, In this mail I would like to express my thoughts and ideas regarding to the 'external interface for USSD'. To provide some background for other mailing list members, who are not aware of this topic, I'll explain it in a few sentences. We already have an external interface for SMS - SMPP. But unfortunately, the same cannot be said about USSD. There is no built-in support of any interface, which could be used to handle USSD requests in a separate application. So, at the moment we only handle *#100# (own number request), which is implemented as a part of both OsmoMSC and legacy OsmoNiTB. And if one would like to implement additional USSD commands, it's required to modify and recompile the whole project :/ Fairwaves team already have some draft implementation for legacy OsmoNiTB, which relays on the libosmocore's GSM 04.80 API. And having the external interface in the mainline would be great not only for Fairwaves, but for the whole Osmocom project and its users. The problem is that the current libosmocore's GSM 04.80 API is not complete and requires some critical modifications, which of course cannot be integrated immediately. Moreover, this implementation doesn't follow Osmocom coding style, for example, unlike other functions, where return code rc = 0 means success, there it means error... So, first of all, we need to know, how many projects are using the current API, especially non-Osmocom projects. After that (taking it into account), it shall be decided: - Should we keep the old API / ABI and maintain all new features among with it. This way would force us to duplicate the existing code and use different symbols. Then the old API would continuously became deprecated... - Should we make all the critical changes in the current API (increasing the libosmocore version?). This way would break builds of dependent projects and would suppose fixing compatibility with the new API. But, at the same time, the implementation would be cleaner and closer to the specification, without any deprecated duplication... Personally, I prefer the second way. At the same time, I want to make the modification as much transparent as possible. Speaking about Osmocom projects, the only users of the GSM 04.80 API are OsmoMSC and legacy OsmoNiTB. Both projects utilize it for '*#100#' handling only :/ To be more convincing, let's look at the following code: #define MAX_LEN_USSD_STRING 31 struct ss_request { uint8_t opcode; uint8_t ss_code; uint8_t ussd_text[MAX_LEN_USSD_STRING + 1]; uint8_t transaction_id; uint8_t invoke_id; }; This is what the current API allows you to obtain from a SS-request (e.g. '*#100#') coming from user. And what's wrong here? - The 'ss_request' doesn't indicate a part of the library it comes from. Would be better to use 'gsm0480_ss_request'. - The 'ussd_text' length doesn't follow the specification, where USSD OCTET STRING length is 160 bytes. So, the amount of characters depends on used coding scheme. - The information about SS-message type, component type, text length and used DCS (Data Coding Scheme), etc. is missing. Despite it could be important for the external application. So, let's discuss together all the 'pros and cons', and decide together, how should we facilitate the external USSD interface development. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sat Jan 13 23:00:44 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 14 Jan 2018 00:00:44 +0100 Subject: External USSD interface development In-Reply-To: References: Message-ID: <20180113230042.5m5mehew4asnlvlc@nataraja> Hi Vadim, I'm sorry to respond to your elaborate mail in a very short way: We do not want to break building old versions of OsmoNITB & Co with new library versions. Every time we do this, we are creating problems to our users. We have done this several times in the past, and it's always a pain to handle. Let's assume anyone wants to build an old OsmoNITB version, for example in order to test for a regression (e.g. using 'git bisect'). How would you do this, if for every version you want to test, you need also *all* the matching libosmo* of that time. To make things worse, you don't even know which of the versions you need to use, making it impossible to hunt down when a regression was introduced in an effective way. It would be really nice to have some automatic jenkins build jobs that actually test at least building old code (e.g. openbsc.git) against current 'master' libraries to avoid accidents, and to even clean up some of the incompatibilities we may have introduced since, if possible. It's bad enough if we break this by accident. It's much worse if we do it knowingly. So whatever we do, we have to try our best to keep old APIs stable or backwards-compatible. In most cases, the old API would simply be a compatibility wrapper around the new API. So there's one implementation of a given functionality, but the new users use it directly, while the old users go through a compatibility wrapper. I don't have the details of the USSD code in my head, but I'd be surprised if it wouldn't be possible to simply wrap the new API behind an old API compat wrapper? If you encounter any specific problems, feel free to discuss ways how we can do this. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From radiarisainanasitraka at yahoo.fr Sun Jan 14 02:59:18 2018 From: radiarisainanasitraka at yahoo.fr (Radiarisainana Sitraka) Date: Sun, 14 Jan 2018 02:59:18 +0000 (UTC) Subject: OSMONITB 3G and ROAMING roaming with other operator References: <1159546585.4351785.1515898758715.ref@mail.yahoo.com> Message-ID: <1159546585.4351785.1515898758715@mail.yahoo.com> Hello,Is the osmonitb3G have capabilities to roam with the existing operator in the world!? And, is it possible to launch call and sms to some existing operator !? Chears, -------------- next part -------------- An HTML attachment was scrubbed... URL: From kheimerl at cs.washington.edu Sun Jan 14 06:16:21 2018 From: kheimerl at cs.washington.edu (Kurtis Heimerl) Date: Sat, 13 Jan 2018 22:16:21 -0800 Subject: External USSD interface development In-Reply-To: <20180113230042.5m5mehew4asnlvlc@nataraja> References: <20180113230042.5m5mehew4asnlvlc@nataraja> Message-ID: Hi Vadim, Harald, I wanted to speak up and second the need to fix the USSD system, as Vadim notes it's actually just broken at the moment and doesn't meet the standard. A student in my lab (Rowan, cc'd) recently had to extend it to be able to interface with ussd_airflow, I believe building off of earlier fairwaves patches. We'd also like to be able to upstream those fixes to the community, but it seems that Harald's legacy support issue is the big hangup? Wouldn't it be easier to put related library versions into the changelog or something similar? Git submodules for instance allow you to specify a specific submodule hash and a mechanism like that could free up the interface development. Just some thoughts. Thanks to everyone for bringing this issue up. On Sat, Jan 13, 2018 at 3:00 PM, Harald Welte wrote: > Hi Vadim, > > I'm sorry to respond to your elaborate mail in a very short way: > > We do not want to break building old versions of OsmoNITB & Co > with new library versions. Every time we do this, we are creating > problems to our users. We have done this several times in the > past, and it's always a pain to handle. > > Let's assume anyone wants to build an old OsmoNITB version, for example > in order to test for a regression (e.g. using 'git bisect'). How > would you do this, if for every version you want to test, you need > also *all* the matching libosmo* of that time. To make things worse, > you don't even know which of the versions you need to use, making > it impossible to hunt down when a regression was introduced in an effective > way. > > It would be really nice to have some automatic jenkins build jobs that > actually test at least building old code (e.g. openbsc.git) against > current 'master' libraries to avoid accidents, and to even clean up some > of the incompatibilities we may have introduced since, if possible. > > It's bad enough if we break this by accident. It's much worse if we > do it knowingly. > > So whatever we do, we have to try our best to keep old APIs stable > or backwards-compatible. In most cases, the old API would simply > be a compatibility wrapper around the new API. So there's one > implementation of a given functionality, but the new users use it > directly, while the old users go through a compatibility wrapper. > > I don't have the details of the USSD code in my head, but I'd be surprised > if it wouldn't be possible to simply wrap the new API behind an old > API compat wrapper? If you encounter any specific problems, feel > free to discuss ways how we can do this. > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > ============================================================ > ================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djks74 at gmail.com Sun Jan 14 15:15:59 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Sun, 14 Jan 2018 15:15:59 +0000 Subject: testing osmo-bsc osmo-hlr osmo-msc Message-ID: Hello guys. Im testing the osmo-bsc osmo-hlr osmo-msc. I can make call but sometimes cannot, also same with text message. now the auto create subscriber not working which is Im looking and its very good and nice improovement. I ussually using osmo-sip-connector with openbsc and asterisk, but since I read that osmo-msc handling the features and also for future osmocom GSM stacks, so Im trying to migrate and test it. does my setting for the osmocom stacks is right with this? : osmo-bsc -c ~/osmo/osmo-bsc.cfg osmo-hlr -l hlr.db -c ~/osmo/osmo-hlr.cfg osmo-stp -c ~/osmo/osmo-stp.cfg osmo-mgw -c ~/osmo/osmo-mgw-for-msc.cfg osmo-mgw -c ~/osmo/osmo-mgw-for-bsc.cfg osmo-msc -c ~/osmo/osmo-msc.cfg DId I miss something? Im sure I miss something. :-) and how to connect osmo-msc with asterisk? Thanks. -- Best Regards, DUO -------------- next part -------------- An HTML attachment was scrubbed... URL: From mawais.aslam985 at gmail.com Mon Jan 15 10:03:10 2018 From: mawais.aslam985 at gmail.com (Muhammad Awais Aslam) Date: Mon, 15 Jan 2018 15:03:10 +0500 Subject: Help required for non-sync Handover Message-ID: Hi, We have manged to decode the BSIC in dedicated mode which were not implemented before. Now we are working on the synchronize and non-synchronize Handover. Once we send the fake measurement report to the BTS we get a handover command from the network. That could be synchronized or non-synchronized. In case of synchronized hand over, without making any changes in the TPU clock offset and the frame number and frequency correction, we are able to complete the handover process most of the time. In case of non-synchronized handover, a physical info is required from the network when mobile station would send Handover access burst to the network before the timer expires but we never get physical info during this period. Here we are stuck. Changes: for non-synchronized handover we need to change the TPU offset and frequency correction offset and frame number parameters which we stored during the BSIC decoding. We set these values before we send handover access burst to the network but no success. Anybody who is working on the handover currently or in the past can discuss these things with me so we can figure out why we are not getting the physical info during the non-sync handover. I have also attached the main changed files with this email. I hope someone would give advice how to debug the issue. Regards M. Awais -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mframe_sched.c Type: text/x-csrc Size: 18586 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: prim_fbsb.c Type: text/x-csrc Size: 42447 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: prim_pm.c Type: text/x-csrc Size: 12173 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: prim_rach.c Type: text/x-csrc Size: 8832 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Jan 15 11:57:15 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 Jan 2018 12:57:15 +0100 Subject: Auto create subscribers on OpenBSC In-Reply-To: References: <20180112134740.GD2687@my.box> Message-ID: <20180115115715.GA2776@my.box> > here is the config https://pastebin.com/BKcPUbzb Prepend a 'no' to disable it: nitb no subscriber-create-on-demand ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Jan 15 12:02:05 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 Jan 2018 13:02:05 +0100 Subject: [osmocom/gr-osmosdr] Sdrplay2 (#12) In-Reply-To: References: Message-ID: <20180115120205.GB2776@my.box> The github robot is still telling people to submit patches on the mailing lists. Can we please change that message to link to this wiki page instead? http://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards#Submitting-Patches Thanks! ~N On Fri, Jan 12, 2018 at 09:17:53AM -0800, tsaitgaist wrote: > GitHub is only used to mirror [osmocom projects](http://git.osmocom.org/). Please use the [mailing lists](https://lists.osmocom.org/mailman/listinfo) to [submit patches](http://projects.osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards#Submitting-Patches). > > -- > You are receiving this because you are subscribed to this thread. > Reply to this email directly or view it on GitHub: > https://github.com/osmocom/gr-osmosdr/pull/12#issuecomment-357299416 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From djks74 at gmail.com Mon Jan 15 12:03:39 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Mon, 15 Jan 2018 19:03:39 +0700 Subject: Auto create subscribers on OpenBSC In-Reply-To: References: <20180112134740.GD2687@my.box> <20180115115715.GA2776@my.box> Message-ID: Ahh ok. Im so stupid not really mean with a simple english. Thanks Neels. DUO On Jan 15, 2018 6:57 PM, "Neels Hofmeyr" wrote: > here is the config https://pastebin.com/BKcPUbzb Prepend a 'no' to disable it: nitb no subscriber-create-on-demand ~N -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael at riseup.net Mon Jan 15 12:07:50 2018 From: rafael at riseup.net (Rafael Diniz) Date: Mon, 15 Jan 2018 10:07:50 -0200 Subject: USRP2 and OsmoTRX Message-ID: <9e4b59ba-44fb-eca6-8114-9a2063c1eb8e@riseup.net> Hi people, I'm doing some tests with an old USRP2 + RF900 daughterboard, and I get a very unstable system (with osmo-trx, osmo-bts-trx and osmo-nitb) - some phones can connect, some dont. I'd like to identify the problem - is it a bad GBit ethernet or the lack of a GPSDO connected to the 10MHz port? Here is osmo-trx startup: +++ Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in and supported by CPU Config Settings Log Level............... DEBUG Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 GSM Core Address.........127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 1 EDGE support............ Disabled Reference............... Internal C0 Filler Table......... Disabled Multi-Carrier........... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 INFO 140529100949376 09:57:53.4 UHDDevice.cpp:623:open: Using discovered UHD device type=usrp2,addr=192.168.10.2,name=,serial=024N11043 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes INFO 140529100949376 09:57:54.6 UHDDevice.cpp:441:set_rates: Rates configured for N2XX 4/1 Tx/Rx SPS INFO 140529100949376 09:57:54.7 UHDDevice.cpp:401:init_gains: Supported Tx gain range [0; 0] INFO 140529100949376 09:57:54.7 UHDDevice.cpp:406:init_gains: Supported Rx gain range [0; 70] INFO 140529100949376 09:57:54.7 UHDDevice.cpp:410:init_gains: Default setting Tx gain for channel 0 to 0 INFO 140529100949376 09:57:54.7 UHDDevice.cpp:417:init_gains: Default setting Rx gain for channel 0 to 35 INFO 140529100949376 09:57:54.7 UHDDevice.cpp:712:open: Single USRP: Device: USRP2 / N-Series Device Mboard 0: USRP2 r4 RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: RFX900 RX TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: RFX900 TX -- Transceiver active with 1 channel(s) +++ From osmo-trx I get millions of messages: +++ DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.1 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 7:1142324 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 0:1142349 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 0:1142325 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 1:1142349 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 2:1142349 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 3:1142349 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 4:1142349 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 5:1142349 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 6:1142349 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 7:1142349 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 2:1142325 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 4:1142325 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 6:1142325 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 7:1142325 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 0:1142350 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 0:1142326 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 1:1142350 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 2:1142350 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 3:1142350 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 4:1142350 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 5:1142350 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 6:1142350 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 7:1142350 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 2:1142326 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 4:1142326 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 6:1142326 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 7:1142326 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 0:1142351 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 0:1142327 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 1:1142351 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 2:1142351 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 3:1142351 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 4:1142351 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 5:1142351 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 6:1142351 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 7:1142351 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 3:1142327 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 4:1142327 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 6:1142327 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 7:1142327 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 0:1142352 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 1:1142352 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 0:1142328 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 2:1142352 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 3:1142352 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 4:1142352 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 5:1142352 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 6:1142352 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 7:1142352 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 3:1142328 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 4:1142328 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 6:1142328 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 7:1142328 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 0:1142353 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 1:1142353 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 0:1142329 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 2:1142353 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 3:1142353 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 4:1142353 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 5:1142353 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 6:1142353 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 7:1142353 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 3:1142329 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 4:1142329 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 6:1142329 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 7:1142329 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 0:1142354 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 1:1142354 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 2:1142354 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 3:1142354 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 0:1142330 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 4:1142354 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 5:1142354 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 6:1142354 DEBUG 140529099826944 10:02:27.4 Transceiver.cpp:852:driveTxPriorityQueue: rcvd. burst at: 7:1142354 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 3:1142330 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 4:1142330 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:946:readSamples: Received timestamp = 32693.2 DEBUG 140529101072128 10:02:27.4 Transceiver.cpp:960:driveTxFIFO: radio clock 6:1142330 DEBUG 140529101039360 10:02:27.4 UHDDevice.cpp:902:readSamples: Requested timestamp = 32693.2 +++ and from osmo-bts-trx: +++ (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127677/850/05/16/45 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127677/850/05/16/45 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127683/850/11/22/03 (bts=0,trx=0,ts=0) SDCCH/4(0): PH-RTS.ind: chan_nr=0x20 link_id=0x00 <0007> scheduler.c:418 1127683/850/11/22/03 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x20 link_id=0x00 <0007> scheduler.c:480 1127714/850/16/02/34 (bts=0,trx=0,ts=0) BCCH: PH-RTS.ind: chan_nr=0x80 link_id=0x00 <0007> scheduler.c:418 1127714/850/16/02/34 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x80 link_id=0x00 <0007> scheduler.c:480 1127718/850/20/06/38 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127718/850/20/06/38 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127724/850/00/12/44 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127724/850/00/12/44 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127728/850/04/16/48 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127728/850/04/16/48 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127734/850/10/22/02 (bts=0,trx=0,ts=0) SDCCH/4(0): PH-RTS.ind: chan_nr=0x20 link_id=0x00 <0007> scheduler.c:418 1127734/850/10/22/02 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x20 link_id=0x00 <0007> scheduler.c:480 1127754/850/04/42/22 (bts=0,trx=0,ts=0) SACCH/4(0): PH-RTS.ind: chan_nr=0x20 link_id=0x40 <0007> scheduler.c:418 1127754/850/04/42/22 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x20 link_id=0x40 <0007> scheduler.c:480 1127765/850/15/02/33 (bts=0,trx=0,ts=0) BCCH: PH-RTS.ind: chan_nr=0x80 link_id=0x00 <0007> scheduler.c:418 1127765/850/15/02/33 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x80 link_id=0x00 <0007> scheduler.c:480 1127769/850/19/06/37 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127769/850/19/06/37 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0006> scheduler_trx.c:1619 TRX Clock Ind: elapsed_us= 997110, elapsed_fn=217, error_us=-4345 <0006> scheduler_trx.c:1637 GSM clock jitter: 3322 us (elapsed_fn=1) <0007> scheduler.c:480 1127775/850/25/12/43 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127775/850/25/12/43 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0006> scheduler_trx.c:1660 We were 1 FN slower than TRX, compensated <0007> scheduler.c:480 1127779/850/03/16/47 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127779/850/03/16/47 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127785/850/09/22/01 (bts=0,trx=0,ts=0) SDCCH/4(0): PH-RTS.ind: chan_nr=0x20 link_id=0x00 <0007> scheduler.c:418 1127785/850/09/22/01 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x20 link_id=0x00 <0007> scheduler.c:480 1127816/850/14/02/32 (bts=0,trx=0,ts=0) BCCH: PH-RTS.ind: chan_nr=0x80 link_id=0x00 <0007> scheduler.c:418 1127816/850/14/02/32 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x80 link_id=0x00 <0007> scheduler.c:480 1127820/850/18/06/36 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127820/850/18/06/36 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127826/850/24/12/42 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127826/850/24/12/42 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127830/850/02/16/46 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127830/850/02/16/46 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127836/850/08/22/00 (bts=0,trx=0,ts=0) SDCCH/4(0): PH-RTS.ind: chan_nr=0x20 link_id=0x00 <0007> scheduler.c:418 1127836/850/08/22/00 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x20 link_id=0x00 <0007> scheduler.c:480 1127856/850/02/42/20 (bts=0,trx=0,ts=0) SACCH/4(0): PH-RTS.ind: chan_nr=0x20 link_id=0x40 <0007> scheduler.c:418 1127856/850/02/42/20 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x20 link_id=0x40 <0007> scheduler.c:480 1127867/850/13/02/31 (bts=0,trx=0,ts=0) BCCH: PH-RTS.ind: chan_nr=0x80 link_id=0x00 <0007> scheduler.c:418 1127867/850/13/02/31 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x80 link_id=0x00 <0007> scheduler.c:480 1127871/850/17/06/35 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127871/850/17/06/35 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127877/850/23/12/41 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127877/850/23/12/41 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127881/850/01/16/45 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127881/850/01/16/45 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127887/850/07/22/51 (bts=0,trx=0,ts=0) SDCCH/4(0): PH-RTS.ind: chan_nr=0x20 link_id=0x00 <0007> scheduler.c:418 1127887/850/07/22/51 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x20 link_id=0x00 <0007> scheduler.c:480 1127918/850/12/02/30 (bts=0,trx=0,ts=0) BCCH: PH-RTS.ind: chan_nr=0x80 link_id=0x00 <0007> scheduler.c:418 1127918/850/12/02/30 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x80 link_id=0x00 <0007> scheduler.c:480 1127922/850/16/06/34 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127922/850/16/06/34 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127928/850/22/12/40 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127928/850/22/12/40 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127932/850/00/16/44 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127932/850/00/16/44 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127938/850/06/22/02 (bts=0,trx=0,ts=0) SDCCH/4(0): PH-RTS.ind: chan_nr=0x20 link_id=0x00 <0007> scheduler.c:418 1127938/850/06/22/02 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x20 link_id=0x00 <0007> scheduler.c:480 1127958/850/00/42/22 (bts=0,trx=0,ts=0) SACCH/4(0): PH-RTS.ind: chan_nr=0x20 link_id=0x40 <0007> scheduler.c:418 1127958/850/00/42/22 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x20 link_id=0x40 <0007> scheduler.c:480 1127969/850/11/02/33 (bts=0,trx=0,ts=0) BCCH: PH-RTS.ind: chan_nr=0x80 link_id=0x00 <0007> scheduler.c:418 1127969/850/11/02/33 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x80 link_id=0x00 <0007> scheduler.c:480 1127973/850/15/06/37 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127973/850/15/06/37 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127979/850/21/12/43 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127979/850/21/12/43 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127983/850/25/16/47 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1127983/850/25/16/47 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:480 1127989/850/05/22/01 (bts=0,trx=0,ts=0) SDCCH/4(0): PH-RTS.ind: chan_nr=0x20 link_id=0x00 <0007> scheduler.c:418 1127989/850/05/22/01 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x20 link_id=0x00 <0006> scheduler_trx.c:1619 TRX Clock Ind: elapsed_us= 998173, elapsed_fn=216, error_us=+1333 <0006> scheduler_trx.c:1637 GSM clock jitter: -2537 us (elapsed_fn=0) <0000> rsl.c:2458 (bts=0,trx=0,ts=0,ss=0) Rx RSL DEACTIVATE_SACCH <0006> l1sap.c:1394 deactivating sacch chan_nr=0x20 trx=0 <0006> scheduler.c:1383 Deactivating SACCH/4(0) on trx=0 ts=0 <0000> rsl.c:2458 (bts=0,trx=0,ts=0,ss=0) Rx RSL RF_CHAN_REL <0006> l1sap.c:1378 deactivating channel chan_nr=0x20 trx=0 <0006> scheduler.c:1383 Deactivating SDCCH/4(0) on trx=0 ts=0 <0006> l1sap.c:602 deactivate confirm chan_nr=0x20 trx=0 <0000> rsl.c:580 (bts=0,trx=0,ts=0,ss=0) Tx RF CHAN REL ACK <0007> scheduler.c:480 1128020/850/10/02/32 (bts=0,trx=0,ts=0) BCCH: PH-RTS.ind: chan_nr=0x80 link_id=0x00 <0007> scheduler.c:418 1128020/850/10/02/32 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0x80 link_id=0x00 <0007> scheduler.c:480 1128024/850/14/06/36 (bts=0,trx=0,ts=0) CCCH: PH-RTS.ind: chan_nr=0x90 link_id=0x00 <0007> scheduler.c:418 1128024/850/14/06/36 (bts=0,trx=0,ts=0) : PH-DATA.req: chan_nr=0 +++ From NITB: +++ Mon Jan 15 10:04:11 2018 <0005> abis_nm.c:507 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. Mon Jan 15 10:04:11 2018 <0005> abis_nm.c:507 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. Mon Jan 15 10:04:11 2018 <0005> abis_nm.c:573 BTS0: ARI reported sw[0/2]: sysmobts is 0.7.0.20180114 Mon Jan 15 10:04:11 2018 <0005> abis_nm.c:446 BTS0 reported variant: omso-bts-trx Mon Jan 15 10:04:11 2018 <0005> abis_nm.c:468 BTS0 Attribute Manufacturer Dependent State is unreported Mon Jan 15 10:04:11 2018 <0005> abis_nm.c:573 BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown +++ And after some time, osmo-trx stops reading samples from UHD and osmo-bts-trx shuts down. Thanks, Rafael Diniz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nhofmeyr at sysmocom.de Mon Jan 15 12:20:42 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 Jan 2018 13:20:42 +0100 Subject: New Defects reported by Coverity Scan for Osmocom In-Reply-To: <5a5a334ec1290_15baf13330700ac@ss1435.mail> References: <5a5a334ec1290_15baf13330700ac@ss1435.mail> Message-ID: <20180115122042.GD2776@my.box> The hnbgw ones are my fault, am a bit puzzled that they took this long to show up in coverity. ~N On Sat, Jan 13, 2018 at 04:26:56PM +0000, scan-admin at coverity.com wrote: > > Hi, > > Please find the latest report on new defect(s) introduced to Osmocom found with Coverity Scan. > > 6 new defect(s) introduced to Osmocom found with Coverity Scan. > 3 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. > > New defect(s) Reported-by: Coverity Scan > Showing 6 of 6 defect(s) > > > ** CID 181969: (UNINIT) > /source-Osmocom/osmo-iuh/src/hnbgw_rua.c: 218 in rua_to_scu() > /source-Osmocom/osmo-iuh/src/hnbgw_rua.c: 274 in rua_to_scu() > > > ________________________________________________________________________________________________________ > *** CID 181969: (UNINIT) > /source-Osmocom/osmo-iuh/src/hnbgw_rua.c: 218 in rua_to_scu() > 212 > 213 prim = (struct osmo_scu_prim *) msgb_put(msg, sizeof(*prim)); > 214 osmo_prim_init(&prim->oph, SCCP_SAP_USER, type, PRIM_OP_REQUEST, msg); > 215 > 216 switch (type) { > 217 case OSMO_SCU_PRIM_N_UNITDATA: > >>> CID 181969: (UNINIT) > >>> Using uninitialized value "map". > 218 DEBUGP(DRUA, "rua_to_scu() %s to %s, rua_ctx_id %u (unitdata, no scu_conn_id)\n", > 219 cn_domain_indicator_to_str(cN_DomainIndicator), > 220 osmo_sccp_addr_dump(remote_addr), > 221 map->rua_ctx_id); > 222 break; > 223 default: > /source-Osmocom/osmo-iuh/src/hnbgw_rua.c: 274 in rua_to_scu() > 268 msg->l2h = msgb_put(msg, len); > 269 memcpy(msg->l2h, data, len); > 270 } > 271 > 272 rc = osmo_sccp_user_sap_down(cn->sccp_user, &prim->oph); > 273 > >>> CID 181969: (UNINIT) > >>> Using uninitialized value "map". > 274 if (map && release_context_map) > 275 context_map_deactivate(map); > 276 > 277 return rc; > 278 } > 279 > > ** CID 181968: Uninitialized variables (UNINIT) > /source-Osmocom/osmo-iuh/src/hnbgw_cn.c: 219 in _cn_ranap_rx() > > > ________________________________________________________________________________________________________ > *** CID 181968: Uninitialized variables (UNINIT) > /source-Osmocom/osmo-iuh/src/hnbgw_cn.c: 219 in _cn_ranap_rx() > 213 default: > 214 LOGP(DRANAP, LOGL_NOTICE, "Received suspicious RANAP " > 215 "presence %u from CN, ignoring\n", pdu->present); > 216 break; > 217 } > 218 > >>> CID 181968: Uninitialized variables (UNINIT) > >>> Using uninitialized value "rc". > 219 return rc; > 220 } > 221 > 222 static int handle_cn_ranap(struct hnbgw_cnlink *cnlink, const uint8_t *data, > 223 unsigned int len) > 224 { > > ** CID 181967: Security best practices violations (DC.WEAK_CRYPTO) > /source-Osmocom/osmo-trx/tests/Transceiver52M/convolve_test.c: 22 in gen_floats() [...] > *** CID 135219: API usage errors (PW.PRINTF_ARG_MISMATCH) > /source-Osmocom/osmo-iuh/src/hnbgw_rua.c: 201 in () > 195 break; > 196 case RUA_CN_DomainIndicator_ps_domain: > 197 remote_addr = &hnb->gw->sccp.iups_remote_addr; > 198 is_ps = true; > 199 break; > 200 default: > >>> CID 135219: API usage errors (PW.PRINTF_ARG_MISMATCH) > >>> argument is incompatible with corresponding format string conversion > 201 LOGP(DRUA, LOGL_ERROR, "Unsupported Domain %u\n", > 202 cN_DomainIndicator); > 203 return -1; > 204 } > 205 > 206 if (!cn) { > > ** CID 57733: Uninitialized variables (MISSING_RETURN) > /source-Osmocom/osmo-iuh/src/hnbgw_hnbap.c: 531 in hnbgw_rx_unsuccessful_outcome_msg() > > > ________________________________________________________________________________________________________ > *** CID 57733: Uninitialized variables (MISSING_RETURN) > /source-Osmocom/osmo-iuh/src/hnbgw_hnbap.c: 531 in hnbgw_rx_unsuccessful_outcome_msg() > 525 > 526 } > 527 > 528 static int hnbgw_rx_unsuccessful_outcome_msg(struct hnb_context *hnb, UnsuccessfulOutcome_t *msg) > 529 { > 530 > >>> CID 57733: Uninitialized variables (MISSING_RETURN) > >>> Arriving at the end of a function without returning a value. > 531 } > 532 > 533 > 534 static int _hnbgw_hnbap_rx(struct hnb_context *hnb, HNBAP_PDU_t *pdu) > 535 { > 536 int rc = 0; > > ** CID 57732: Uninitialized variables (MISSING_RETURN) > /source-Osmocom/osmo-iuh/src/hnbgw_hnbap.c: 526 in hnbgw_rx_successful_outcome_msg() > > > ________________________________________________________________________________________________________ > *** CID 57732: Uninitialized variables (MISSING_RETURN) > /source-Osmocom/osmo-iuh/src/hnbgw_hnbap.c: 526 in hnbgw_rx_successful_outcome_msg() > 520 return rc; > 521 } > 522 > 523 static int hnbgw_rx_successful_outcome_msg(struct hnb_context *hnb, SuccessfulOutcome_t *msg) > 524 { > 525 > >>> CID 57732: Uninitialized variables (MISSING_RETURN) > >>> Arriving at the end of a function without returning a value. > 526 } > 527 > 528 static int hnbgw_rx_unsuccessful_outcome_msg(struct hnb_context *hnb, UnsuccessfulOutcome_t *msg) > 529 { > 530 > 531 } > > > ________________________________________________________________________________________________________ > To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRZRgA0iChuO-2FGX0POK2RKsukBc1qHTwF2SHZpn6wOsolg-3D-3D_NeAJonveXivhzKyNx2umY31POArq17SmfipFEiTlbGGbqUVND0YydKGhSS0ma6Kk6mP1n2YFSaNrTLp1JGaaJcs0MJrwL5iMOuvWNY5qWCC0Dvm07rZiRglamZqwZpQTpGx7PVQUSrzdqRrBgAK-2FCbgDBcS51HeEoxyVVR042O9upCKnAJrNdNAqTqjAXH5NK0izNSdH5EGO8-2FFe5A8vMemtfm-2FUx1BqF1HY-2FjRsq10-3D > > To manage Coverity Scan email notifications for "nhofmeyr at sysmocom.de", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4VngPiVJb2v7ebXRF7QR8XkZ9r0tTrYp-2F0MW-2FEWllzpkyCC83LXF7q-2FHm2-2BquI0NN6y2ZgcVxPTvklWSJL2RR9R8Aq2Y2qnMdw30sEcvVsU8-3D_NeAJonveXivhzKyNx2umY31POArq17SmfipFEiTlbGGbqUVND0YydKGhSS0ma6Kk-2FQN-2BGaGcgoQCOxyHuNv6A9FGMIGYPiDbbpbyeDI-2F0L43PIzVtxLnklKhr4QnRvh-2BXgAMLWFqbsZdnylGi5HANKl24TfcI-2BvYFqwtJ9eAN6h98Z-2FSZlQz32-2B4IIjE26VdtxQqGcuUjp3Xt-2B8qHAnL-2B4-2BlJtQFhXA3OhmXWVrzkeY-3D > -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Jan 15 12:29:55 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 Jan 2018 13:29:55 +0100 Subject: testing osmo-bsc osmo-hlr osmo-msc In-Reply-To: References: Message-ID: <20180115122955.GE2776@my.box> On Sun, Jan 14, 2018 at 03:15:59PM +0000, Sandi Suhendro wrote: > now the auto create subscriber not working which is Im looking and its very > good and nice improovement. To reiterate, in the old osmo-nitb, we used to have 'subscriber-create-on-demand', which the new osmo-hlr does not support. It's not an improvement, it's dropping a feature on the floor. > does my setting for the osmocom stacks is right with this? : > > osmo-bsc -c ~/osmo/osmo-bsc.cfg > osmo-hlr -l hlr.db -c ~/osmo/osmo-hlr.cfg > osmo-stp -c ~/osmo/osmo-stp.cfg > osmo-mgw -c ~/osmo/osmo-mgw-for-msc.cfg > osmo-mgw -c ~/osmo/osmo-mgw-for-bsc.cfg > osmo-msc -c ~/osmo/osmo-msc.cfg > > DId I miss something? Im sure I miss something. :-) looks good as long as you also have a BTS. Of course just the invocation commands don't convey anything about the settings. And of course don't make us read your config unless you have an actual problem. > and how to connect osmo-msc with asterisk? The short answer is: use osmo-sip-connector. The long answer should be somewhere on the wiki, but personally I'm not familiar with that. Maybe someone else has a pointer? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Jan 15 12:39:03 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 Jan 2018 13:39:03 +0100 Subject: Help required for non-sync Handover In-Reply-To: References: Message-ID: <20180115123903.GF2776@my.box> Hi Muhammad, On Mon, Jan 15, 2018 at 03:03:10PM +0500, Muhammad Awais Aslam wrote: > Hi, > > We have manged to decode the BSIC in dedicated mode which were not > implemented before. Osmocom lives by contribution. If you have implemented useful parts that we don't support yet, please submit them back to us -- that would be highly appreciated. http://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards#Submitting-Patches > Now we are working on the synchronize and > non-synchronize Handover. Once we send the fake measurement report to the > BTS we get a handover command from the network. That could be synchronized > or non-synchronized. > > In case of synchronized hand over, without making any changes in the TPU > clock offset and the frame number and frequency correction, we are able to > complete the handover process most of the time. > > In case of non-synchronized handover, a physical info is required from the > network when mobile station would send Handover access burst to the network > before the timer expires but we never get physical info during this period. > Here we are stuck. I'm currently working on handover, though my attention is (should be) more on the HO decision making process: trigger handover due to load considerations. In the process though I am touching and testing the stock handover code as well, and have seen some code concerned with sync and async HO. You say that you are able to do sync HO but not async. However, it appeared to me so far that all we ever do is async HO. i.e., in handover_logic.c, we have rc = rsl_chan_activate_lchan(new_lchan, RSL_ACT_INTER_ASYNC, ho->ho_ref); and a patch that is in the pipeline now adds even the possibility to pass _SYNC instead of _ASYNC (while we're still going to pass _ASYNC anyway in all cases, so far). So either you have SYNC and ASYNC mixed up or we're misunderstanding each other... You are asking about osmocom code, right? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laforge at gnumonks.org Mon Jan 15 12:44:43 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 15 Jan 2018 13:44:43 +0100 Subject: [osmocom/gr-osmosdr] Sdrplay2 (#12) In-Reply-To: <20180115120205.GB2776@my.box> References: <20180115120205.GB2776@my.box> Message-ID: <20180115124443.m7t5cmf3nfpqf623@nataraja> hi Neels, On Mon, Jan 15, 2018 at 01:02:05PM +0100, Neels Hofmeyr wrote: > The github robot is still telling people to submit patches on the mailing > lists. Can we please change that message to link to this wiki page instead? > > http://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards#Submitting-Patches Kevin has created this robot, I presume he knows where to modify the related message contents. Kevin? Thanks! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Jan 15 12:45:58 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 15 Jan 2018 13:45:58 +0100 Subject: New Defects reported by Coverity Scan for Osmocom In-Reply-To: <20180115122042.GD2776@my.box> References: <5a5a334ec1290_15baf13330700ac@ss1435.mail> <20180115122042.GD2776@my.box> Message-ID: <20180115124556.zonx5savvvc3jnsr@nataraja> On Mon, Jan 15, 2018 at 01:20:42PM +0100, Neels Hofmeyr wrote: > The hnbgw ones are my fault, am a bit puzzled that they took this long to show up in coverity. I believe msuraev just submitted a patch to (re?) enable osmo-iuh testing. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From msuraev at sysmocom.de Mon Jan 15 12:55:32 2018 From: msuraev at sysmocom.de (Max) Date: Mon, 15 Jan 2018 13:55:32 +0100 Subject: New Defects reported by Coverity Scan for Osmocom In-Reply-To: <20180115124556.zonx5savvvc3jnsr@nataraja> References: <5a5a334ec1290_15baf13330700ac@ss1435.mail> <20180115122042.GD2776@my.box> <20180115124556.zonx5savvvc3jnsr@nataraja> Message-ID: <42fee0a3-58f1-8521-518d-0c0a2b1a5639@sysmocom.de> Yepp, it was accidentally disabled when switching off separate iuh branches. On 15.01.2018 13:45, Harald Welte wrote: > On Mon, Jan 15, 2018 at 01:20:42PM +0100, Neels Hofmeyr wrote: >> The hnbgw ones are my fault, am a bit puzzled that they took this long to show up in coverity. > I believe msuraev just submitted a patch to (re?) enable osmo-iuh testing. > From mawais.aslam985 at gmail.com Mon Jan 15 13:31:32 2018 From: mawais.aslam985 at gmail.com (Muhammad Awais Aslam) Date: Mon, 15 Jan 2018 18:31:32 +0500 Subject: Help required for non-sync Handover In-Reply-To: <20180115123903.GF2776@my.box> References: <20180115123903.GF2776@my.box> Message-ID: Dear Neels, Thanks for the response. > Osmocom lives by contribution. If you have implemented useful parts that we > don't support yet, please submit them back to us -- that would be highly > appreciated. > http://osmocom.org/projects/cellular-infrastructure/wiki/C oding_standards#Submitting-Patches I have already uploaded the code which could be find here: https://gerrit.osmocom.org/5490 > I'm currently working on handover, though my attention is (should be) more on > the HO decision making process: trigger handover due to load considerations. > In the process though I am touching and testing the stock handover code as > well, and have seen some code concerned with sync and async HO. > You say that you are able to do sync HO but not async. However, it appeared to > me so far that all we ever do is async HO. i.e., in handover_logic.c, we have > rc = rsl_chan_activate_lchan(new_lchan, RSL_ACT_INTER_ASYNC, ho->ho_ref); > and a patch that is in the pipeline now adds even the possibility to pass _SYNC > instead of _ASYNC (while we're still going to pass _ASYNC anyway in all cases, > so far). > So either you have SYNC and ASYNC mixed up or we're misunderstanding each > other... You are asking about osmocom code, right? I am talking about the code from OSMOCOM-BB and there is no file name handover_logic.c. I think you are talking about code from openBTS. We took code related to handover from the osmocom-bb jolly branch by manually adding/deleting stuff in the master branch as updating to the latest copy was giving us issues. We added code from the ?Safely change TPU offset on TS change or sync change? commit till the ?Use only sel_si for information about the current cell? commit. Using the handover code in the jolly branch and after making the changes we were able to obtain the handover command from the BTS. The synchronized handover case works sometimes though still not every time, however the non-synchronized case doesn't work at all as we are not able to get the physical information command from the new cell. I'll explain the changes/additions we made to achieve this. Firstly, we noted that in dedicated mode SB burst was not being detected. Changes were required at three main places in order to correctly perform FB/SB detection: - It was seen that the results for SB were being read from DSP API location dsp_api.db_r->a_sch which is for the idle mode. The results had to be read from the dsp_api.ndb->a_sch26 location for the dedicated case if TCH_SB_DSP_TASK is used. - After reading the FB we needed to update the quarter-bit offset of the TPU using the TOA of the FB to sync it with the start of frame of the neighbour cell in order to catch the SB (by changing the vaule of l1s.tpu_offset using the TOA of the FB). - Frequency compensation needed to be performed using the afc_correct function before reading the SB. * We actually kind of cheated a bit by adding 3 frames to the original idle frame in order to give us more time to perform FB/SB detection including the synchronizations mentioned above. This was because we weren't that proficient with the code and someone with more understanding could do this better. The call did not get dropped. We used the initial added ?idle? frame to perform the quarter-bit and frequency compensation which was reversed in the idle frame with the response function to tune back to the serving cell. These things, when added to the code did the trick and BSIC of the neighbours was obtained. Once the BSICs were decoded the measurement report sent to the BTS became meaningful and the handover command was received. Upon receiving handover command, access bursts needed to be sent on the new channel which again was not currently being implemented properly as in order to tune to the new cell we needed to know its quarter-bit offset for start of frame, frequency compensation and absolute frame number which were not previously being obtained. Now that we were able to detect FB and SB these values were stored for the neighbours following detection of these bursts and were used to tune to a neighbour cell in case of a handover to it before the sending of access bursts. However, here is where we are stuck. We were expecting a physical information message following the access bursts but were not able to receive it due to which the handover failed. If only that could be achieved we believe handover should be successful. Either we are not syncing properly to the new cell or we might not be following GSM protocol properly. We also might not be reading the FACCH properly for physical information message after tuning to the new cell as we couldn't really understand that bit very well. We wanted someone expertise on this matter and were hoping our work could be of use. Regards M. Awais On Mon, Jan 15, 2018 at 5:39 PM, Neels Hofmeyr wrote: > Hi Muhammad, > > On Mon, Jan 15, 2018 at 03:03:10PM +0500, Muhammad Awais Aslam wrote: > > Hi, > > > > We have manged to decode the BSIC in dedicated mode which were not > > implemented before. > > Osmocom lives by contribution. If you have implemented useful parts that we > don't support yet, please submit them back to us -- that would be highly > appreciated. > http://osmocom.org/projects/cellular-infrastructure/wiki/ > Coding_standards#Submitting-Patches > > > Now we are working on the synchronize and > > non-synchronize Handover. Once we send the fake measurement report to the > > BTS we get a handover command from the network. That could be > synchronized > > or non-synchronized. > > > > In case of synchronized hand over, without making any changes in the TPU > > clock offset and the frame number and frequency correction, we are able > to > > complete the handover process most of the time. > > > > In case of non-synchronized handover, a physical info is required from > the > > network when mobile station would send Handover access burst to the > network > > before the timer expires but we never get physical info during this > period. > > Here we are stuck. > > I'm currently working on handover, though my attention is (should be) more > on > the HO decision making process: trigger handover due to load > considerations. > > In the process though I am touching and testing the stock handover code as > well, and have seen some code concerned with sync and async HO. > > You say that you are able to do sync HO but not async. However, it > appeared to > me so far that all we ever do is async HO. i.e., in handover_logic.c, we > have > > rc = rsl_chan_activate_lchan(new_lchan, RSL_ACT_INTER_ASYNC, > ho->ho_ref); > > and a patch that is in the pipeline now adds even the possibility to pass > _SYNC > instead of _ASYNC (while we're still going to pass _ASYNC anyway in all > cases, > so far). > > So either you have SYNC and ASYNC mixed up or we're misunderstanding each > other... You are asking about osmocom code, right? > > ~N > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.huemer at xx.vu Mon Jan 15 13:46:30 2018 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Mon, 15 Jan 2018 14:46:30 +0100 Subject: USRP2 and OsmoTRX In-Reply-To: <9e4b59ba-44fb-eca6-8114-9a2063c1eb8e@riseup.net> References: <9e4b59ba-44fb-eca6-8114-9a2063c1eb8e@riseup.net> Message-ID: <20180115134630.GA18427@yade.chaostreff.at> Hi! On Mon, Jan 15, 2018 at 10:07:50AM -0200, Rafael Diniz wrote: > I'm doing some tests with an old USRP2 + RF900 daughterboard, and I get > a very unstable system (with osmo-trx, osmo-bts-trx and osmo-nitb) - > some phones can connect, some dont. I'd like to identify the problem - > is it a bad GBit ethernet or the lack of a GPSDO connected to the 10MHz > port? According to [1] the clock accuracy of the USRP2 is 20ppm. GSM 05.10[2] states that accuracy has to be 0.05ppm or better. That's quite a bit off, so I don't think it's surprising that you don't see much stability. I believe it makes a difference whether the MSs see other BTSs or not. If the MSs see only the unstable BTS it is more likely to work out. Not sure what is the case here. > And after some time, osmo-trx stops reading samples from UHD and > osmo-bts-trx shuts down. Not sure if that is a possible effect of an unstable clock. I could imagine so, but again, I am not sure. I guess the obvious advice is to attach a more stable clock and try again. Kind regards, -Alex [1] http://openbts.org/w/index.php?title=Ettus_Research_USRP [2] http://www.etsi.org/deliver/etsi_gts/05/0510/05.00.00_60/gsmts_0510v050000p.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From rafael at riseup.net Mon Jan 15 15:14:07 2018 From: rafael at riseup.net (Rafael Diniz) Date: Mon, 15 Jan 2018 13:14:07 -0200 Subject: USRP2 and OsmoTRX In-Reply-To: <20180115134630.GA18427@yade.chaostreff.at> References: <9e4b59ba-44fb-eca6-8114-9a2063c1eb8e@riseup.net> <20180115134630.GA18427@yade.chaostreff.at> Message-ID: <679f6e1d-29ca-78b0-4c74-f4aea6098221@riseup.net> Thanks Alex. Do you know if this GPSDO would work: https://www.ebay.com/itm/GPS-Receiver-GPSDO-10MHz-1PPS-GPS-Disciplined-Clock-SINE-WAVE-GPS-RECEIVER/262981677836?hash=item3d3aedf30c:g:8HUAAOSwxu5ZD~MH Feature: POWER:DC12V 1.5A GPS ANT POWER:DC3.3V 1PPS OUTPUT:Square WAVE,3.3Vpp 10M OUTPUT :SINE WAVE,1Vrms (13dBm+-2dB) RS232 OUTPUT:GPS NMEA SIGNAL SIZE:W*H*D=107*55*120mm ACCESSORY:AC110-220-DC12V ADAPTER,GPS ANT. Thanks! Rafael Diniz On 01/15/2018 11:46 AM, Alexander Huemer wrote: > Hi! > > On Mon, Jan 15, 2018 at 10:07:50AM -0200, Rafael Diniz wrote: > >> I'm doing some tests with an old USRP2 + RF900 daughterboard, and I get >> a very unstable system (with osmo-trx, osmo-bts-trx and osmo-nitb) - >> some phones can connect, some dont. I'd like to identify the problem - >> is it a bad GBit ethernet or the lack of a GPSDO connected to the 10MHz >> port? > > According to [1] the clock accuracy of the USRP2 is 20ppm. > GSM 05.10[2] states that accuracy has to be 0.05ppm or better. > That's quite a bit off, so I don't think it's surprising that you don't > see much stability. > I believe it makes a difference whether the MSs see other BTSs or not. > If the MSs see only the unstable BTS it is more likely to work out. > Not sure what is the case here. > >> And after some time, osmo-trx stops reading samples from UHD and >> osmo-bts-trx shuts down. > > Not sure if that is a possible effect of an unstable clock. I could > imagine so, but again, I am not sure. > > I guess the obvious advice is to attach a more stable clock and try > again. > > Kind regards, > -Alex > > [1] http://openbts.org/w/index.php?title=Ettus_Research_USRP > [2] http://www.etsi.org/deliver/etsi_gts/05/0510/05.00.00_60/gsmts_0510v050000p.pdf > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nhofmeyr at sysmocom.de Mon Jan 15 17:00:41 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 Jan 2018 18:00:41 +0100 Subject: New Defects reported by Coverity Scan for Osmocom In-Reply-To: <42fee0a3-58f1-8521-518d-0c0a2b1a5639@sysmocom.de> References: <5a5a334ec1290_15baf13330700ac@ss1435.mail> <20180115122042.GD2776@my.box> <20180115124556.zonx5savvvc3jnsr@nataraja> <42fee0a3-58f1-8521-518d-0c0a2b1a5639@sysmocom.de> Message-ID: <20180115170041.GA5323@my.box> On Mon, Jan 15, 2018 at 01:55:32PM +0100, Max wrote: > Yepp, it was accidentally disabled when switching off separate iuh branches. ah, nice catch, thanks ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Jan 15 17:01:42 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 Jan 2018 18:01:42 +0100 Subject: [osmocom/gr-osmosdr] Sdrplay2 (#12) In-Reply-To: <20180115140120.GA29067@coil> References: <20180115120205.GB2776@my.box> <20180115124443.m7t5cmf3nfpqf623@nataraja> <20180115140120.GA29067@coil> Message-ID: <20180115170142.GB5323@my.box> On Mon, Jan 15, 2018 at 03:01:20PM +0100, Kevin Redon wrote: > I've updated the message to: > GitHub is only used to mirror [osmocom projects](http://git.osmocom.org/). Please read the following instructions to [submit patches](http://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards#Submitting-Patches). Danke!! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Jan 15 17:12:52 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 Jan 2018 18:12:52 +0100 Subject: Help required for non-sync Handover In-Reply-To: References: <20180115123903.GF2776@my.box> Message-ID: <20180115171252.GC5323@my.box> On Mon, Jan 15, 2018 at 06:31:32PM +0500, Muhammad Awais Aslam wrote: > I have already uploaded the code which could be find here: > > https://gerrit.osmocom.org/5490 I see, thanks for that. There have been comments for the patch, but I see you were submitting someone else's work. And now I also understand that this is about osmocom-bb, and not the osmocom core network / BSS implementation. I'm currently working in osmo-bsc, and a colleague is looking/going to look at osmo-msc. I'm personally not familiar with osmocom-bb at all and am not at liberty to spend time on that at the moment, so I'm afraid I need to pass the question on in the hope that others can help instead. > I think you are talking about code from openBTS. Certainly not OpenBTS, which is a project that is completely unrelated to Osmocom. (I'm working on Osmocom as a sysmocom employee.) > We took code related to handover from the osmocom-bb jolly branch by > [...] I am going to link to this description from the gerrit patch, it looks like very useful information, which would be good to have in the commit log as well. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Jan 15 17:14:22 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 Jan 2018 18:14:22 +0100 Subject: Help required for non-sync Handover In-Reply-To: References: <20180115123903.GF2776@my.box> Message-ID: <20180115171422.GD5323@my.box> ...and let me add that osmocom-bb would better be discussed in the baseband-devel@ mailing list, since mails to openbsc@ are expected to be about the core network / BSS part of Osmocom. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From pespin at sysmocom.de Mon Jan 15 19:08:43 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 15 Jan 2018 20:08:43 +0100 Subject: osmo-trx test setup & convolve_test failures on different machines Message-ID: <382c7d81-b862-0bb2-a719-abc441e4f1d2@sysmocom.de> Hi everybody, as some of you may have noticed due to the generated noise in gerrit ml during last days, I have been adding some autotest setup to osmo-trx in order to have several tests being run during gerrit review. Since osmo-trx has some specific code built with NEON instructions, I also added some infrastructure to jenkin.sh to generate and use a prebuilt debian armhf rootfs so we can easily build and run tests using qemu-arm from our local workstations or from jenkins slaves, which will check that support for those architectures doesn't become broken. In order to set up the make check tests, I re-used existing tests and moved them to the tests/ directory. I also moved utils/convolvtest/main.c into "tests/Transceiver52M/convolve_test" [1] to become a test that checks "convolve_{real,complex}" APIs. I noticed, however, that this test prints slightly (or not that slightly) different outputs on different machine architectures, which of course make tests fail as it matches the exact values. So far the output is different in my x86_64 workstation, my i686 netbook (or i586 OBS host) and in my qemu-arm (armhf). As each machine uses different instructions sets, I indeed can understand that there appear small differences due to floating operations and rounding, but sometimes I can see relatively big difference between one implementation and the other one (eg 7.032490 vs 6.655972). I'm thinking about modifying the test to, instead of matching the output exactly, check that for each value in the vector it is similar to a value with a maximum epsilon distance from a reference vector. However, as I don't have any knowledge regarding the maths and theory behind the convolution codes, I must admit I am not sure which epsilon should I be using, or which should be the expected output for the test. It may perhaps make sense to have separate reference output for different architectures, I don't know. Can somebody shed some light on this topic? Any advise or hint is welcome. It would also be nice to have some tests for the "convert" API, which uses optimized instructions sets too. If somebody wants to provide those or any hint on how to implement them that's going to be handy. All the test infrastructure is merged now, only the patch adding the qemu part is not merged but already working in [2], I'll merge it tomorrow if nobody is angry with it. You can find related output for the test I was speaking of for different machine arch (x86_64, i686, arm) in [3] and [4]. [1]https://git.osmocom.org/osmo-trx/tree/tests/Transceiver52M/convolve_test.c [2] https://gerrit.osmocom.org/#/c/5763 [3] https://osmocom.org/issues/2826 [4] https://osmocom.org/issues/2828 -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From alexander.huemer at xx.vu Mon Jan 15 20:07:30 2018 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Mon, 15 Jan 2018 21:07:30 +0100 Subject: USRP2 and OsmoTRX In-Reply-To: <679f6e1d-29ca-78b0-4c74-f4aea6098221@riseup.net> References: <9e4b59ba-44fb-eca6-8114-9a2063c1eb8e@riseup.net> <20180115134630.GA18427@yade.chaostreff.at> <679f6e1d-29ca-78b0-4c74-f4aea6098221@riseup.net> Message-ID: <20180115200730.GB19261@yade.chaostreff.at> Hi! On Mon, Jan 15, 2018 at 01:14:07PM -0200, Rafael Diniz wrote: > Do you know if this GPSDO would work: > https://www.ebay.com/itm/GPS-Receiver-GPSDO-10MHz-1PPS-GPS-Disciplined-Clock-SINE-WAVE-GPS-RECEIVER/262981677836?hash=item3d3aedf30c:g:8HUAAOSwxu5ZD~MH > > Feature: > > POWER:DC12V 1.5A > GPS ANT POWER:DC3.3V > 1PPS OUTPUT:Square WAVE,3.3Vpp > 10M OUTPUT :SINE WAVE,1Vrms (13dBm+-2dB) > RS232 OUTPUT:GPS NMEA SIGNAL > SIZE:W*H*D=107*55*120mm > ACCESSORY:AC110-220-DC12V ADAPTER,GPS ANT. Well, I don't have experience with this particular device. Observations: * Power level of 10MHz output is right, according to [1]. * Waveform is the desired square. * There is no specification of accuracy. Assumption is that it's good enough, but I think it's worth noting that there is no statement. * The 1PPS output is a nice to have, though voltage is too low to be inside spec of the USRP2. I don't know how likely it is to be working anyways. Have you considered using an OCXO for simplicity reasons? There are reasonably priced boards on eBay that have an OCXO and just the necessary components around to run it, like [2,3]. Those should be sufficient regarding accuracy, though output waveform is sine, which is acceptable but not ideal. I have just invested 2 minutes in research. I am sure even better suitable options can be found easily. Kind regards, -Alex [1] https://files.ettus.com/manual/page_usrp2.html [2] https://www.ebay.com/itm/182994166409 [3] https://www.ebay.com/itm/252755180989 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Mon Jan 15 20:23:40 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 Jan 2018 21:23:40 +0100 Subject: osmo-bsc_nat dropped in unrelated patch Message-ID: <20180115202340.GB14510@my.box> Hi dexter, reading a commit of yours apparently merged to osmo-bsc in November, I notice that you "secretly sneaked in" this: diff --git a/src/Makefile.am b/src/Makefile.am index d04f025..dd1ad3d 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -33,5 +33,4 @@ SUBDIRS += \ utils \ ipaccess \ osmo-bsc \ - osmo-bsc_nat \ $(NULL) in a patch that was supposed to "mgcp: use osmo-mgw to switch RTP streams". http://git.osmocom.org/osmo-bsc/commit/?id=39c609b7c924524172ad311bdf89f92b7ccf175a So since we merged that patch, osmo-bsc_nat is no longer part of the osmo-bsc build. That's certainly not intended, is it? Confirm and please fix that. thx! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Jan 15 21:45:05 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 Jan 2018 22:45:05 +0100 Subject: fairwaves HO patches References: Message-ID: <20180115214505.GC14510@my.box> Hi Ivan, as I'm working towards load-based handover and incorporating your patches, I found that most of it is concerned with libmsc. In contrast, I am currently working on osmo-bsc, in libbsc, and would like to ask your advice. Some parts of the patch aren't easy to understand for me, and I'd like to make sure that I am not dismissing parts of it as non-applicable to libbsc even though they might be important. Since your patches were written, the code has changed. Now that we have the separate osmo-bsc, we will need two layers of handover: intra-BSC and inter-BSC. Intra-BSC is a handover between two cells that are serviced by the same BSC, and the higher layers (MSC) should not even notice that anything has happened -- MSC has asked the BSC to service a call by BSSAP Assignment, and the BSC is free to choose and change around the lchans it assigns to that. That is the layer I'm currently dug into. Inter-BSC is a handover between cells that are serviced by two different BSCs. That seems to be the land your patch is improving. The MSC is involved and so is MNCC. (Both MSC and BSC levels will need their own DTAP cache, and they are by definition completely independent -- MSC caches the DTAP coming from MNCC during Inter-BSC handover, BSC caches DTAP from MSC during Intra-BSC handover.) Since your patch is applied onto openbsc.git, where all of BSC and MSC are still one osmo-nitb, I want to make sure that I sort your patch right. Do some of its semantics apply to osmo-bsc master, even if the code changed? The smaller patches are either already applied to osmo-bsc master, or I've submitted them on gerrit just now: handover_decision: Add more log messages to get more information about HO causes in logs handover_decision: Fix condition for power budget handover attempt handover_logic: set correct link to bts for subscriber_connection in case of moving this connection to another bts Remaining are a small and *the* complex one: transaction: Add new function trans_find_by_lchan handover: Implement proper handover procedure handling at any stage of the call Here is the last one with inline questions, I hope they are not too stupid; or too long, it ended up being a lot to read. Thanks in advance for taking a look: > commit f7f4dc5e3b0dd61b8322946597147baef5d0464b > Author: Ivan Kluchnikov > Date: Wed Aug 23 18:09:50 2017 +0300 > > handover: Implement proper handover procedure handling at any stage of the call > > Enhancements for each stage of handover procedure should be implemented in order to support handover at any stage of the call. > For these purposes new in_handover state and ho_queue for call control messages was introduced for gsm_subscriber_connection. > > Stage 1: HO-Command is sent to MS > gsm_subscriber_connection state should be changed to in_handover=1. > In this state all transmission of signalling layer messages (except RR messages needed for handover procedure) > should be suspended until resuming is indicated. > All call control messages for connection received from network side should be buffered in ho_queue. > All call control messages for connection received from MS side should be ignored. > Channel mode modification procedures should be also suspended. > > Stage 2: HO-Detect is received from MS > Audio path should be switched on network side. > > Stage 3-1: HO-Complete is received from MS > Resumption procedure after successful handover should be performed: > - gsm_subscriber_connection state should be changed to normal (in_handover=0). > - all buffered call control messages (ho_queue) should be sent to MS on new lchan. > - suspended channel mode modification procedures should be performed on new lchan. > > Stage 3-2: HO-Fail is received from MS > Resumption procedure after failed handover should be performed: > - gsm_subscriber_connection state should be changed to normal (in_handover=0). > - all buffered call control messages (ho_queue) should be sent to MS on old lchan. > - suspended channel mode modification procedures should be performed on old lchan. > > Stage 3-3: T3103 expired: Handover has failed without HO-Complete or HO-Fail > Resumption procedure should not be performed in case of T3103 expired: > - gsm_subscriber_connection state should be changed to normal (in_handover=0). > - all buffered call control messages (ho_queue) should be cleaned without sending them to MS. > - suspended channel mode modification procedures should not be performed. > > Change-Id: Icb9b5c35ef0c894af2ea762e539f1a9216447fb7 > > diff --git a/openbsc/include/openbsc/bsc_api.h b/openbsc/include/openbsc/bsc_api.h > index 3a931199..baacbeda 100644 > --- a/openbsc/include/openbsc/bsc_api.h > +++ b/openbsc/include/openbsc/bsc_api.h > @@ -51,5 +51,6 @@ int gsm0808_cipher_mode(struct gsm_subscriber_connection *conn, int cipher, > int gsm0808_page(struct gsm_bts *bts, unsigned int page_group, > unsigned int mi_len, uint8_t *mi, int chan_type); > int gsm0808_clear(struct gsm_subscriber_connection *conn); > +int gsm0808_ho_clear(struct gsm_subscriber_connection *conn); > > #endif > diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h > index ac573c49..542b2611 100644 > --- a/openbsc/include/openbsc/gsm_data.h > +++ b/openbsc/include/openbsc/gsm_data.h > @@ -138,6 +138,8 @@ struct gsm_subscriber_connection { > struct gsm_network *network; > > int in_release; > + int in_handover; > + struct llist_head ho_queue; > struct gsm_lchan *lchan; /* BSC */ > struct gsm_lchan *ho_lchan; /* BSC */ > struct gsm_bts *bts; /* BSC */ > diff --git a/openbsc/src/libbsc/bsc_api.c b/openbsc/src/libbsc/bsc_api.c > index 8a4c85ff..71e82d03 100644 > --- a/openbsc/src/libbsc/bsc_api.c > +++ b/openbsc/src/libbsc/bsc_api.c > @@ -253,11 +253,14 @@ struct gsm_subscriber_connection *bsc_subscr_con_allocate(struct gsm_lchan *lcha > conn->bts = lchan->ts->trx->bts; > lchan->conn = conn; > llist_add_tail(&conn->entry, &net->subscr_conns); > + INIT_LLIST_HEAD(&conn->ho_queue); > return conn; > } > > void bsc_subscr_con_free(struct gsm_subscriber_connection *conn) > { > + struct msgb *msg; > + > if (!conn) > return; > > @@ -283,6 +286,11 @@ void bsc_subscr_con_free(struct gsm_subscriber_connection *conn) > conn->secondary_lchan->conn = NULL; > } > > + while (!llist_empty(&conn->ho_queue)) { > + msg = msgb_dequeue(&conn->ho_queue); > + msgb_free(msg); > + } > + > llist_del(&conn->entry); > talloc_free(conn); > } > @@ -747,6 +755,17 @@ int gsm0808_clear(struct gsm_subscriber_connection *conn) > return 0; > } > > +/* > + * Release handover RF Channel. > + */ > +int gsm0808_ho_clear(struct gsm_subscriber_connection *conn) > +{ > + if (conn->ho_lchan) > + bsc_clear_handover(conn, 1); > + > + return 0; > +} > + > static void send_sapi_reject(struct gsm_subscriber_connection *conn, int link_id) > { > struct bsc_api *api; > diff --git a/openbsc/src/libbsc/handover_logic.c b/openbsc/src/libbsc/handover_logic.c > index af4e8013..b7085c34 100644 > --- a/openbsc/src/libbsc/handover_logic.c > +++ b/openbsc/src/libbsc/handover_logic.c > @@ -186,10 +186,17 @@ static void ho_T3103_cb(void *_ho) > { > struct bsc_handover *ho = _ho; > struct gsm_network *net = ho->new_lchan->ts->trx->bts->network; > + struct msgb *msg; > > DEBUGP(DHO, "HO T3103 expired\n"); > rate_ctr_inc(&net->bsc_ctrs->ctr[BSC_CTR_HANDOVER_TIMEOUT]); > > + ho->new_lchan->conn->in_handover = 0; > + while (!llist_empty(&ho->new_lchan->conn->ho_queue)) { > + msg = msgb_dequeue(&ho->new_lchan->conn->ho_queue); > + msgb_free(msg); > + } > + (Your ho_queue seems to live in libbsc, while most of the patch seems to be concerned with libmsc. But nevermind, from jolly's patches I already have a similar queue in osmo-bsc, and we'll probably use yours for libmsc.) > ho->new_lchan->conn->ho_lchan = NULL; > ho->new_lchan->conn = NULL; > lchan_release(ho->new_lchan, 0, RSL_REL_LOCAL_END); > @@ -214,6 +221,8 @@ static int ho_chan_activ_ack(struct gsm_lchan *new_lchan) > > gsm48_send_ho_cmd(ho->old_lchan, new_lchan, 0, ho->ho_ref); > > + new_lchan->conn->in_handover = 1; > + In current osmo-bsc master, we already set conn->ho_lchan before sending out the chan activation request. I'd actually assume setting the flag only now, after the activ ack, is a bit too late? > /* start T3103. We can continue either with T3103 expiration, > * 04.08 HANDOVER COMPLETE or 04.08 HANDOVER FAIL */ > ho->T3103.cb = ho_T3103_cb; > @@ -221,7 +230,8 @@ static int ho_chan_activ_ack(struct gsm_lchan *new_lchan) > osmo_timer_schedule(&ho->T3103, 10, 0); > > /* create a RTP connection */ > - if (is_ipaccess_bts(new_lchan->ts->trx->bts)) > + if (is_ipaccess_bts(new_lchan->ts->trx->bts) && > + new_lchan->tch_mode != GSM48_CMODE_SIGN) > rsl_ipacc_crcx(new_lchan); Please explain ... what case / behavior is this fixing? Do we ever see CMODE_SIGN handovers? Would we also need to check for GSM48_CMODE_DATA_*? > @@ -273,6 +283,11 @@ static int ho_gsm48_ho_compl(struct gsm_lchan *new_lchan) > if (is_e1_bts(new_lchan->conn->bts)) > switch_trau_mux(ho->old_lchan, new_lchan); > > + if (ho->old_lchan->conn->mncc_rtp_connect_pending) { > + new_lchan->abis_ip.connect_port = ho->old_lchan->abis_ip.connect_port; > + new_lchan->abis_ip.connect_ip = ho->old_lchan->abis_ip.connect_ip; > + } > + So if an RTP connect to MNCC is pending, we copy the old lchan's RTP port and IP? Which is this, the MNCC / call router side IP and port? Why not set this at the initiation of the HO already? > @@ -295,27 +310,9 @@ static int ho_gsm48_ho_compl(struct gsm_lchan *new_lchan) > static int ho_gsm48_ho_fail(struct gsm_lchan *old_lchan) > { > struct gsm_network *net = old_lchan->ts->trx->bts->network; > - struct bsc_handover *ho; > - struct gsm_lchan *new_lchan; > - > - ho = bsc_ho_by_old_lchan(old_lchan); > - if (!ho) { > - LOGP(DHO, LOGL_ERROR, "unable to find HO record\n"); > - return -ENODEV; > - } > > rate_ctr_inc(&net->bsc_ctrs->ctr[BSC_CTR_HANDOVER_FAILED]); > > - new_lchan = ho->new_lchan; > - > - /* release the channel and forget about it */ > - ho->new_lchan->conn->ho_lchan = NULL; > - ho->new_lchan->conn = NULL; > - handover_free(ho); > - > - lchan_release(new_lchan, 0, RSL_REL_LOCAL_END); > - > - I'm puzzled by this removal. No actions during ho_fail? Is this really intended, or just some rebase artifact? > return 0; > } > > diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c > index e5402d0a..84338d72 100644 > --- a/openbsc/src/libmsc/gsm_04_08.c > +++ b/openbsc/src/libmsc/gsm_04_08.c > @@ -147,6 +147,15 @@ static int gsm48_conn_sendmsg(struct msgb *msg, struct gsm_subscriber_connection > sign_link->trx->bts->nr, > sign_link->trx->nr, msg->lchan->ts->nr, > gh->proto_discr, gh->msg_type); > + > + if (conn->in_handover) { > + msgb_enqueue(&conn->ho_queue, msg); > + DEBUGP(DCC, "(bts %d trx %d ts %d) Suspend message sending to MS, " > + "active HO procedure.\n", > + sign_link->trx->bts->nr, > + sign_link->trx->nr, msg->lchan->ts->nr); > + return 0; > + } (here DTAP handled in libmsc ends up in the ho_queue that otherwise seems to live in libbsc ... as I said above this queue will probably move to libmsc altogether to become part of osmo-msc master.) > } > > return gsm0808_submit_dtap(conn, msg, 0, 0); > @@ -1749,11 +1758,8 @@ static int switch_for_handover(struct gsm_lchan *old_lchan, > struct rtp_socket *old_rs, *new_rs, *other_rs; > > /* Ask the new socket to send to the already known port. */ > - if (new_lchan->conn->mncc_rtp_bridge) { > - LOGP(DHO, LOGL_DEBUG, "Forwarding RTP\n"); > - rsl_ipacc_mdcx(new_lchan, > - old_lchan->abis_ip.connect_ip, > - old_lchan->abis_ip.connect_port, 0); > + if (new_lchan->ts->trx->bts->network->mncc_state) { > + /* Audio path should be switched after receiving ho detect message.*/ > return 0; > } I notice that in the current head, the entire switch_for_handover() has been dropped; it was doing libbsc lchan stuff from within libmsc. Hence we must have added similar logic in osmo-bsc.git and completely dropped this. I think the commit re-implementing handover in osmo-bsc is http://git.osmocom.org/osmo-bsc/commit/?id=39c609b7c924524172ad311bdf89f92b7ccf175a It appears that lchan->abis_ip.connect_ip and connect_port aren't used at all in osmo-bsc master, but are still present in the struct. I'll ask others about that. In any case, the code base has changed substantially, and this patch hunk no longer applies at all. Am I interpreting this hunk correctly: it moves the ipacc_mdcx to tell the new lchan about its RTP peer to a later stage? In current osmo-bsc master, it seems that this ipacc_mdcx happens as soon as the ipacc_crcx is complete, seen in osmo-bsc/src/osmo-bsc/osmo_bsc_audio.c in handle_abisip_signal(), always using the IP:port the MSC sent us. > > @@ -1821,8 +1827,10 @@ static int handle_abisip_signal(unsigned int subsys, unsigned int signal, > if (subsys != SS_ABISIP) > return 0; > > + net = lchan->ts->trx->bts->network; > + > /* RTP bridge handling */ > - if (lchan->conn && lchan->conn->mncc_rtp_bridge) > + if (lchan->conn && net->mncc_state) > return tch_rtp_signal(lchan, signal); What are the semantics here? It seems odd to move from a check of a conn-specific state (conn->mncc_rtp_bridge) to a check of a global value (net->mncc_state). In any case, this is MNCC related and should not impact Intra-BSC handover, right? > > /* in case we use direct BTS-to-BTS RTP */ > @@ -1851,7 +1859,6 @@ static int handle_abisip_signal(unsigned int subsys, unsigned int signal, > > /* check if any transactions on this lchan still have > * a tch_recv_mncc request pending */ > - net = lchan->ts->trx->bts->network; > llist_for_each_entry(trans, &net->trans_list, entry) { > if (trans->conn && trans->conn->lchan == lchan && trans->tch_recv) { > DEBUGP(DCC, "pending tch_recv_mncc request\n"); > @@ -2017,6 +2024,13 @@ static int tch_recv_mncc(struct gsm_network *net, uint32_t callref, int enable) > switch (bts->type) { > case GSM_BTS_TYPE_NANOBTS: > case GSM_BTS_TYPE_OSMO_SYSMO: > if (ipacc_rtp_direct) { > LOGP(DCC, LOGL_ERROR, "Error: RTP proxy is disabled\n"); > return -EINVAL; > } > + /* RTP bridge handling */ > + if (lchan->conn && net->mncc_state) { > + return 0; > + } If we have a conn and using external MNCC, don't continue at all? I'm not following, would be nice if the comment explained why we need to drop out here. (added some more code context manually) > /* In case, we don't have a RTP socket to the BTS yet, the BTS > * will not be connected to our RTP proxy and the socket will > * not be assigned to the application interface. This method > * will be called again, once the audio socket is created and > * connected. */ > if (!lchan->abis_ip.rtp_socket) { > DEBUGP(DCC, "queue tch_recv_mncc request (%d)\n", enable); > return 0; > } > if (enable) { > /* connect the TCH's to our RTP proxy */ > rc = rsl_ipacc_mdcx_to_rtpsock(lchan); > if (rc < 0) > return rc; > /* assign socket to application interface */ > rtp_socket_upstream(lchan->abis_ip.rtp_socket, > net, callref); > } else > rtp_socket_upstream(lchan->abis_ip.rtp_socket, > net, 0); > break; > > @@ -3325,6 +3339,41 @@ static void mncc_recv_rtp_err(struct gsm_network *net, uint32_t callref, int cmd > return mncc_recv_rtp(net, callref, cmd, 0, 0, 0, 0); > } > > +static void mncc_recv_rtp_modify(struct gsm_lchan *lchan, uint32_t callref) This is to tell the call router that the payload type has changed, right? I've asked in the redmine about whether/how we'd convey an RTP payload change to the MNCC in case of an Intra-BSC handover... https://osmocom.org/issues/1606#note-45 > +{ > + int msg_type; > + struct gsm_network *net = lchan->ts->trx->bts->network; > + > + LOGP(DMNCC, LOGL_NOTICE, "%s sending pending RTP modify ind.\n", > + gsm_lchan_name(lchan)); > + > + switch (lchan->abis_ip.rtp_payload) { > + case RTP_PT_GSM_FULL: > + msg_type = GSM_TCHF_FRAME; > + break; > + case RTP_PT_GSM_EFR: > + msg_type = GSM_TCHF_FRAME_EFR; > + break; > + case RTP_PT_GSM_HALF: > + msg_type = GSM_TCHH_FRAME; > + break; > + case RTP_PT_AMR: > + msg_type = GSM_TCH_FRAME_AMR; > + break; > + default: > + LOGP(DMNCC, LOGL_ERROR, "%s unknown payload type %d\n", > + gsm_lchan_name(lchan), lchan->abis_ip.rtp_payload); > + msg_type = 0; > + break; > + } > + > + mncc_recv_rtp(net, callref, MNCC_RTP_MODIFY, > + lchan->abis_ip.bound_ip, > + lchan->abis_ip.bound_port, > + lchan->abis_ip.rtp_payload, > + msg_type); > +} > + > static int tch_rtp_create(struct gsm_network *net, uint32_t callref) > { > struct gsm_bts *bts; > @@ -3374,6 +3423,9 @@ static int tch_rtp_create(struct gsm_network *net, uint32_t callref) > LOGP(DMNCC, LOGL_DEBUG, "RTP create: codec=%s, chan_type=%s\n", > get_value_string(gsm48_chan_mode_names, m), > get_value_string(gsm_chan_t_names, lchan->type)); > + if (trans->conn->in_handover) { > + return 0; > + } Am I reading right: if we're doing handover, the MSC shouldn't sent another BSSAP Assignment to the BSC; instead, the BSC level figures out another lchan and done ... ? > return gsm0808_assign_req(trans->conn, m, > lchan->type != GSM_LCHAN_TCH_H); > } > @@ -3420,23 +3472,21 @@ static int tch_rtp_connect(struct gsm_network *net, void *arg) > * same package! > */ > trans->conn->mncc_rtp_connect_pending = 1; > + if (trans->conn->in_handover) { > + lchan->abis_ip.connect_port = rtp->port; > + lchan->abis_ip.connect_ip = rtp->ip; > + return 0; > + } > return rsl_ipacc_mdcx(lchan, rtp->ip, rtp->port, 0); We're not telling the BTS about the call router's IP:port anymore? Please explain... > } > > static int tch_rtp_signal(struct gsm_lchan *lchan, int signal) > { > struct gsm_network *net; > - struct gsm_trans *tmp, *trans = NULL; > + struct gsm_trans *trans; > > net = lchan->ts->trx->bts->network; > - llist_for_each_entry(tmp, &net->trans_list, entry) { > - if (!tmp->conn) > - continue; > - if (tmp->conn->lchan != lchan && tmp->conn->ho_lchan != lchan) > - continue; > - trans = tmp; > - break; > - } > + trans = trans_find_by_lchan(lchan); > > if (!trans) { > LOGP(DMNCC, LOGL_ERROR, "%s IPA abis signal but no transaction.\n", > @@ -3459,7 +3509,7 @@ static int tch_rtp_signal(struct gsm_lchan *lchan, int signal) > maybe_switch_for_handover(lchan); > break; > case S_ABISIP_MDCX_ACK: > - if (lchan->conn->mncc_rtp_connect_pending) { > + if (lchan->conn->mncc_rtp_connect_pending && !lchan->conn->in_handover) { if we're in handover, we don't need to tell MNCC that RTP got connected, because that already happened when the call got established initially? So mncc_rtp_connect_pending has a second meaning during handover? > lchan->conn->mncc_rtp_connect_pending = 0; > LOGP(DMNCC, LOGL_NOTICE, "%s sending pending RTP connect ind.\n", > gsm_lchan_name(lchan)); > mncc_recv_rtp_sock(net, trans, MNCC_RTP_CONNECT); > } > break; > @@ -3471,6 +3521,134 @@ static int tch_rtp_signal(struct gsm_lchan *lchan, int signal) > return 0; > } > > +static void ho_queue_clean(struct gsm_subscriber_connection *conn) > +{ > + struct msgb *msg; > + while (!llist_empty(&conn->ho_queue)) { > + msg = msgb_dequeue(&conn->ho_queue); > + msgb_free(msg); > + } > +} > + > +static void ho_resumption(struct gsm_lchan *lchan, struct gsm_trans *trans) > +{ > + struct msgb *msg; > + enum gsm48_chan_mode m; > + > + while (!llist_empty(&lchan->conn->ho_queue)) { > + msg = msgb_dequeue(&lchan->conn->ho_queue); > + gsm48_conn_sendmsg(msg, lchan->conn, trans); > + } > + > + if (trans->conn->mncc_rtp_create_pending && > + lchan->tch_mode == GSM48_CMODE_SIGN) { > + m = mncc_codec_for_mode(lchan->type); > + gsm0808_assign_req(lchan->conn, m, lchan->type != GSM_LCHAN_TCH_H); Wait, now we *do* send a BSSAP Assignment after all? (excuse if I'm being noob, I'm still finding my way through handover in general) shouldn't we rather dequeue the cached DTAP after this instead of before? > + } > + > + if (trans->conn->mncc_rtp_connect_pending) { > + rsl_ipacc_mdcx(lchan, lchan->abis_ip.connect_ip, lchan->abis_ip.connect_port, 0); > + } > +} > + > +static int ho_complete(struct gsm_lchan *new_lchan) > +{ > + struct gsm_trans *trans; > + > + new_lchan->conn->in_handover = 0; > + trans = trans_find_by_lchan(new_lchan); > + if (!trans) { > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but no transaction for new_lchan.\n", > + gsm_lchan_name(new_lchan)); > + ho_queue_clean(new_lchan->conn); > + return 0; > + } > + > + ho_resumption(new_lchan, trans); > + return 0; > +} > + > +static int ho_fail(struct gsm_lchan *old_lchan) > +{ > + struct gsm_trans *trans; > + > + old_lchan->conn->in_handover = 0; > + trans = trans_find_by_lchan(old_lchan); > + if (trans) > + ho_resumption(old_lchan, trans); > + else { > + LOGP(DHO, LOGL_ERROR, "%s HO fail, but no transaction for old_lchan.\n", > + gsm_lchan_name(old_lchan)); > + ho_queue_clean(old_lchan->conn); > + } > + > + gsm0808_ho_clear(old_lchan->conn); > + return 0; > +} > + > +static int ho_detect(struct gsm_lchan *new_lchan) > +{ > + struct gsm_trans *trans; > + struct gsm_lchan *old_lchan; > + > + trans = trans_find_by_lchan(new_lchan); > + > + if (!trans) { > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but no transaction for new_lchan" > + " with enabled tch_recv.\n", > + gsm_lchan_name(new_lchan)); > + return 0; > + } > + > + if (!new_lchan->conn->mncc_rtp_bridge) { > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but connection not in mncc_rtp_bridge mode.\n", > + gsm_lchan_name(new_lchan)); > + return 0; > + } > + > + old_lchan = bsc_handover_pending(new_lchan); > + if (!old_lchan) { > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but no old_lchan for handover.\n", > + gsm_lchan_name(new_lchan)); > + return 0; > + } > + > + LOGP(DHO, LOGL_DEBUG, "HO detected, forwarding RTP\n"); > + rsl_ipacc_mdcx(new_lchan, > + old_lchan->abis_ip.connect_ip, > + old_lchan->abis_ip.connect_port, 0); > + > + mncc_recv_rtp_modify(new_lchan, trans->callref); > + > + return 0; > +} > + > +/* some other part of the code sends us a signal */ > +static int handle_lchan_signal(unsigned int subsys, unsigned int signal, > + void *handler_data, void *signal_data) > +{ > + struct lchan_signal_data *lchan_data; > + struct gsm_lchan *lchan; > + > + lchan_data = signal_data; > + switch (subsys) { > + case SS_LCHAN: > + lchan = lchan_data->lchan; > + if (!lchan->conn) > + return 0; > + switch (signal) { > + case S_LCHAN_HANDOVER_DETECT: > + return ho_detect(lchan); > + case S_LCHAN_HANDOVER_COMPL: > + return ho_complete(lchan); > + case S_LCHAN_HANDOVER_FAIL: > + return ho_fail(lchan); > + } > + break; > + } > + > + return 0; > +} > > static struct downstate { > uint32_t states; > @@ -3853,6 +4031,11 @@ static int gsm0408_rcv_cc(struct gsm_subscriber_connection *conn, struct msgb *m > gsm48_cc_msg_name(msg_type), trans?(trans->cc.state):0, > gsm48_cc_state_name(trans?(trans->cc.state):0)); > > + if (conn->in_handover) { > + DEBUGP(DCC, "Message unhandled, handover procedure.\n"); > + return 0; > + } > + If in handover, drop all CC on the floor? How about a call release, i.e. I hang up while I'm coincidentally being handovered? > /* Create transaction */ > if (!trans) { > DEBUGP(DCC, "Unknown transaction ID %x, " > > > Thanks again! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From Alexander.Chemeris at fairwaves.co Tue Jan 16 00:52:07 2018 From: Alexander.Chemeris at fairwaves.co (Alexander Chemeris) Date: Tue, 16 Jan 2018 09:52:07 +0900 Subject: External USSD interface development In-Reply-To: <20180113230042.5m5mehew4asnlvlc@nataraja> References: <20180113230042.5m5mehew4asnlvlc@nataraja> Message-ID: Hi, Harald, I'm surprised to read this because I'm quite sure that you suggested breaking the API/ABI and increasing the library number yourself, and Vadim worked under the assumption that this is the suggested way to go. On Sun, Jan 14, 2018 at 8:00 AM, Harald Welte wrote: > Let's assume anyone wants to build an old OsmoNITB version, for example > in order to test for a regression (e.g. using 'git bisect'). How > would you do this, if for every version you want to test, you need > also *all* the matching libosmo* of that time. I personally believe that switching all libraries versions is the only right way to do in this situation because there are quite a lot of synchronized changes in both OsmoNITB and the underlying libraries. And specifically with hunting a regression example I would want to use a version of all the code in the exact state as it was before. > To make things worse, > you don't even know which of the versions you need to use, making > it impossible to hunt down when a regression was introduced in an effective > way. I thought that library versions serve exactly this purpose - to know which version to build against? Another way is something similar to what we've done in osmo-combo repo which allows you to specify specific commits in each sub-module to build against. > So whatever we do, we have to try our best to keep old APIs stable > or backwards-compatible. In most cases, the old API would simply > be a compatibility wrapper around the new API. So there's one > implementation of a given functionality, but the new users use it > directly, while the old users go through a compatibility wrapper. I'll let Vadim comment here but from what I remember, the old implementation is broken enough to make it difficult to maintain. I would rather focus on making sure the new API is good enough and we don't need to break things again in the foreseeable future. -- Regards, Alexander Chemeris. CTO/Founder, Fairwaves, Inc. Skype: Alexander.Chemeris Mobile: +1(424)400-7626 https://fairwaves.co Subscribe to Fairwaves news: http://eepurl.com/baL_pf From Alexander.Chemeris at fairwaves.co Tue Jan 16 00:53:51 2018 From: Alexander.Chemeris at fairwaves.co (Alexander Chemeris) Date: Tue, 16 Jan 2018 09:53:51 +0900 Subject: External USSD interface development In-Reply-To: References: <20180113230042.5m5mehew4asnlvlc@nataraja> Message-ID: On Sun, Jan 14, 2018 at 3:16 PM, Kurtis Heimerl wrote: > I wanted to speak up and second the need to fix the USSD system, as Vadim > notes it's actually just broken at the moment and doesn't meet the standard. > A student in my lab (Rowan, cc'd) recently had to extend it to be able to > interface with ussd_airflow, I believe building off of earlier fairwaves > patches. We'd also like to be able to upstream those fixes to the community, Do you have a repo with this integration? This might be interesting for us as well. We're currently implementing USSD services in Erlang but a more non-programmer friendly YAML might be a good option in some cases. -- Regards, Alexander Chemeris. CTO/Founder, Fairwaves, Inc. Skype: Alexander.Chemeris Mobile: +1(424)400-7626 https://fairwaves.co Subscribe to Fairwaves news: http://eepurl.com/baL_pf From rafael at riseup.net Tue Jan 16 02:08:25 2018 From: rafael at riseup.net (Rafael Diniz) Date: Tue, 16 Jan 2018 00:08:25 -0200 Subject: USRP2 and OsmoTRX In-Reply-To: <20180115200730.GB19261@yade.chaostreff.at> References: <9e4b59ba-44fb-eca6-8114-9a2063c1eb8e@riseup.net> <20180115134630.GA18427@yade.chaostreff.at> <679f6e1d-29ca-78b0-4c74-f4aea6098221@riseup.net> <20180115200730.GB19261@yade.chaostreff.at> Message-ID: <42c19497-f672-75b6-f016-4c3df09b7cde@riseup.net> Thanks Alex! I ended up buying this one: https://www.ebay.com/itm/182974939864 Lets see. ; ) On 01/15/2018 06:07 PM, Alexander Huemer wrote: > Hi! > > On Mon, Jan 15, 2018 at 01:14:07PM -0200, Rafael Diniz wrote: >> Do you know if this GPSDO would work: >> https://www.ebay.com/itm/GPS-Receiver-GPSDO-10MHz-1PPS-GPS-Disciplined-Clock-SINE-WAVE-GPS-RECEIVER/262981677836?hash=item3d3aedf30c:g:8HUAAOSwxu5ZD~MH >> >> Feature: >> >> POWER:DC12V 1.5A >> GPS ANT POWER:DC3.3V >> 1PPS OUTPUT:Square WAVE,3.3Vpp >> 10M OUTPUT :SINE WAVE,1Vrms (13dBm+-2dB) >> RS232 OUTPUT:GPS NMEA SIGNAL >> SIZE:W*H*D=107*55*120mm >> ACCESSORY:AC110-220-DC12V ADAPTER,GPS ANT. > > Well, I don't have experience with this particular device. > Observations: > * Power level of 10MHz output is right, according to [1]. > * Waveform is the desired square. > * There is no specification of accuracy. Assumption is that it's good > enough, but I think it's worth noting that there is no statement. > * The 1PPS output is a nice to have, though voltage is too low to be > inside spec of the USRP2. I don't know how likely it is to be working > anyways. > > Have you considered using an OCXO for simplicity reasons? > There are reasonably priced boards on eBay that have an OCXO and just > the necessary components around to run it, like [2,3]. Those should be > sufficient regarding accuracy, though output waveform is sine, which is > acceptable but not ideal. > I have just invested 2 minutes in research. I am sure even better > suitable options can be found easily. > > Kind regards, > -Alex > > [1] https://files.ettus.com/manual/page_usrp2.html > [2] https://www.ebay.com/itm/182994166409 > [3] https://www.ebay.com/itm/252755180989 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From mawais.aslam985 at gmail.com Tue Jan 16 05:46:24 2018 From: mawais.aslam985 at gmail.com (Muhammad Awais Aslam) Date: Tue, 16 Jan 2018 10:46:24 +0500 Subject: Help required for non-sync Handover In-Reply-To: <20180115171422.GD5323@my.box> References: <20180115123903.GF2776@my.box> <20180115171422.GD5323@my.box> Message-ID: Dear Neels, > I'm personally not familiar with osmocom-bb at all and am not at liberty to > spend time on that at the moment, so I'm afraid I need to pass the question on > in the hope that others can help instead. Can we use osmocom for debugging purpose? I mean, during the Handover procedure when MS sends HO access burst to the network, can we use the osmocom to handle this procedure? In this way, can we check if MS is properly sending HO access burst to the right BTS? Any suggestion if want to share to debug the issue would be appreciable. thanks > ...and let me add that osmocom-bb would better be discussed in the > baseband-devel@ mailing list, since mails to openbsc@ are expected to be about > the core network / BSS part of Osmocom. Before I sent email to openbsc ML, I used the baseband-devel ML platform and share everything there but I could not get any help regarding this issue. That's the reason I chose this ML for help. Regards Awais On Mon, Jan 15, 2018 at 10:14 PM, Neels Hofmeyr wrote: > ...and let me add that osmocom-bb would better be discussed in the > baseband-devel@ mailing list, since mails to openbsc@ are expected to be > about > the core network / BSS part of Osmocom. > > ~N > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Jan 16 07:19:30 2018 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 16 Jan 2018 08:19:30 +0100 Subject: osmo-bsc_nat dropped in unrelated patch In-Reply-To: <20180115202340.GB14510@my.box> References: <20180115202340.GB14510@my.box> Message-ID: <20180116071928.bbq52tsklgpswx52@nataraja> Hi Neels, On Mon, Jan 15, 2018 at 09:23:40PM +0100, Neels Hofmeyr wrote: > So since we merged that patch, osmo-bsc_nat is no longer part of the osmo-bsc > build. That's certainly not intended, is it? It is intended, or at least expected. osmo-bsc_nat is heavily tied to SCCPlite. We have freed osmo-bsc from those ties and it implements "generic SCCP" on top of the SCCP User SAP of libosmosigtran. Until somebody will do the same amount of porting in osmo-bsc_nat, I think it is best that the two programs dealing natively with SCCPlite are in openbsc.git. > Confirm and please fix that. thx! If there's an easy fix, it might be worth looking into it. However, I think with all the rework on the SCCP and MGCP side, it makes sense to leave it disabled until we have a clear plan how a new AoIP-enabled osmo-bsc_nat might look like. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From phippsr at cs.washington.edu Tue Jan 16 07:21:08 2018 From: phippsr at cs.washington.edu (Rowan Phipps) Date: Tue, 16 Jan 2018 07:21:08 +0000 Subject: External USSD interface development In-Reply-To: References: <20180113230042.5m5mehew4asnlvlc@nataraja> Message-ID: Hi Alexander, Most of the work I did was based off the libosmocore fairwaves/sup-ussd branch. As that branch stands, the first USSD message and its response are handled fine, where it breaks down, is if the service requests more information from the user. On subsequent messages, it looks like the phone leaves out a few critical bytes including the opcode. After reading the standards documents I still do not understand why this is the case but it was observed on multiple handsets and seems to be normal. Most of the modifications I had to make involved handling the other USSD message types and dealing with the fallout from having the opcode missing. I also added some additional fields to the ss_request struct to track the text length, message type and component type. I changed the max string length from 31 to 160 but I'm not sure if it should be longer. USSD strings are transmitted in a 7 bit packed format where the maximum length is 160 bytes. When expanded out into standard ascii this ends up around 182 characters so maybe the max size should be 182 characters. To tie into an external USSD service, I set up osmo-nitb to forward USSD requests to a python script using sup. This script would then forward the USSD message to another program, ussd_airflow, via a http post request. Ussd_airflow is a Django web server that handles USSD requests and can be configured using YAML files. The version of libosmocore used was forked from the master branch in October and has not been kept up to date since then, although I doubt any of the USSD code has been changed much since then. link: https://github.com/rowanphipps/libosmocore The version of openbsc used was forked from the fairwaves/sup-ussd branch. It was not modified very much although that branch had not been touched since October 2015 so it is reasonably old. link: https://github.com/rowanphipps/openbsc I made some modifications to the ussd_airflow web server to allow it it handle multiple different service codes but the original would work fine as well. documentation: https://django-ussd-airflow.readthedocs.io/en/latest/ original: https://github.com/mwaaas/ussd_airflow modified: https://github.com/rowanphipps/ussd_airflow And here is the repo with my python script to link all the parts together: https://github.com/rowanphipps/sup_airflow As for creating an external interface, the current sup interface could be left exposed with the idea that people could just write scripts to parse these messages and forward them as needed. If this is chosen then the sup protocol needs to be better documented and standardized. Sup seems to have been changed in more recent branches and now functions differently and in a way that the old fairwaves code does not work with. The main advantage of keeping sup is that it is very simple to extend to use with other USSD systems. Let me know if you have any questions regarding the changes I made and how it works. On Mon, Jan 15, 2018 at 4:54 PM Alexander Chemeris < Alexander.Chemeris at fairwaves.co> wrote: > On Sun, Jan 14, 2018 at 3:16 PM, Kurtis Heimerl > wrote: > > I wanted to speak up and second the need to fix the USSD system, as Vadim > > notes it's actually just broken at the moment and doesn't meet the > standard. > > A student in my lab (Rowan, cc'd) recently had to extend it to be able to > > interface with ussd_airflow, I believe building off of earlier fairwaves > > patches. We'd also like to be able to upstream those fixes to the > community, > > Do you have a repo with this integration? This might be interesting > for us as well. We're currently implementing USSD services in Erlang > but a more non-programmer friendly YAML might be a good option in some > cases. > > -- > Regards, > Alexander Chemeris. > CTO/Founder, Fairwaves, Inc. > Skype: Alexander.Chemeris > Mobile: +1(424)400-7626 <(424)%20400-7626> > https://fairwaves.co > > Subscribe to Fairwaves news: http://eepurl.com/baL_pf > -- Thanks! - Rowan Phipps -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Tue Jan 16 13:03:23 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 16 Jan 2018 14:03:23 +0100 Subject: stow fallout, problem in osmo-bts-sysmo build Message-ID: <20180116130323.GB2649@ass40.sysmocom.de> In osmo-bts, we just have the configure flag --enable-sysmocom-bts, and don't pass a header include location. i.e. we expect the header files to exist locally. I'm a bit stumped on why introducing stow would cause this to break. IIUC stow should only affect the installed dependencies, while the sysmocom headers are just placed in a local dir? If we can't fix the osmo-bts build quickly, we'll have to revert the stow patch until that works. https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-bts/36/BTS_MODEL=sysmo,FIRMWARE_VERSION=master,a3=default,label=linux_amd64_debian8/console The build scripts are (obviously) in osmo-bts/contrib/ and osmo-ci/scripts. Any help is appreciated. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From rafael at riseup.net Tue Jan 16 13:12:20 2018 From: rafael at riseup.net (Rafael Diniz) Date: Tue, 16 Jan 2018 11:12:20 -0200 Subject: binary packages problem Message-ID: <1721061b-33d6-e4cd-e6c1-020a6282064c@riseup.net> Hi all, Anyone experiencing this error in Latest packages (Debian 9): "The following packages have unmet dependencies: osmo-mgw : Depends: libosmo-mgcp0 but it is not installable" Nightly works great thou. Cheers, Rafael Diniz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From msuraev at sysmocom.de Tue Jan 16 13:20:13 2018 From: msuraev at sysmocom.de (Max) Date: Tue, 16 Jan 2018 14:20:13 +0100 Subject: stow fallout, problem in osmo-bts-sysmo build In-Reply-To: <20180116130323.GB2649@ass40.sysmocom.de> References: <20180116130323.GB2649@ass40.sysmocom.de> Message-ID: The incomplete fix for osmo-bts is available in https://gerrit.osmocom.org/#/c/5818/ The problem with headers location is fixed, the remaining issues are related to contrib/sysmobts-calib/ tool. -- - Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Tue Jan 16 14:04:15 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 16 Jan 2018 15:04:15 +0100 Subject: stow fallout, problem in osmo-bts-sysmo build In-Reply-To: References: <20180116130323.GB2649@ass40.sysmocom.de> Message-ID: <20180116140415.GC2649@ass40.sysmocom.de> On Tue, Jan 16, 2018 at 02:20:13PM +0100, Max wrote: > The incomplete fix for osmo-bts is available in > https://gerrit.osmocom.org/#/c/5818/ Excellent, didn't see that, thanks for taking this on. Posted some review... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Tue Jan 16 14:10:20 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 16 Jan 2018 15:10:20 +0100 Subject: binary packages problem In-Reply-To: <1721061b-33d6-e4cd-e6c1-020a6282064c@riseup.net> References: <1721061b-33d6-e4cd-e6c1-020a6282064c@riseup.net> Message-ID: <20180116141020.GD2649@ass40.sysmocom.de> On Tue, Jan 16, 2018 at 11:12:20AM -0200, Rafael Diniz wrote: > Hi all, > > Anyone experiencing this error in Latest packages (Debian 9): > "The following packages have unmet dependencies: > osmo-mgw : Depends: libosmo-mgcp0 but it is not installable" > > Nightly works great thou. Thanks for reporting! Apparently we need to update latest... https://osmocom.org/issues/2834 ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From mychaela.falconia at gmail.com Tue Jan 16 18:34:23 2018 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Tue, 16 Jan 2018 10:34:23 -0800 Subject: Help required for non-sync Handover In-Reply-To: References: <20180115123903.GF2776@my.box> <20180115171422.GD5323@my.box> Message-ID: I've already responded to Muhammad off-list, but I feel that everyone else should be aware of it too: if anyone needs to know how a GSM MS should implement handover or any other of the myriad features not supported by OsmocomBB, you should study the official GSM MS firmware source code from some mainstream reputable GSM MS chipset+firmware vendor such as FreeCalypso (former TI), MediaTek or Qualcomm, and see how they do it. I don't know whether or not one can get the official firmware source from Qualcomm or MTK (not my personal area of interest - after all, they are my competitors), but the complete source code for the official GSM MS firmware from TI (which most certainly has working handovers of all types - I've been able to stay on a call without dropping while driving between San Diego and Los Angeles, using a TI-based phone) can be found here: https://bitbucket.org/falconian/fc-magnetite Or to be more pedantic, it is not the raw code salvage from TI (what TI threw in the trash as they exited the baseband chipset business), but rather my own actively maintained version thereof. The original code from TI ran only on their own development boards, the ones with weird names like D-Sample and I-Sample; I have one of those original D-Sample boards, but the board I have is likely the world's last remaining one, hence I have ported the firmware to run on more practically available hardware - it can now run on the same Mot C1xx phones that are targeted by OsmocomBB, and I also have my own GSM MS development board (FCDEV3B) which I have designed and built specifically for the purpose of running this firmware. All of you are more than welcome to study this fully working firmware and see how it implements handovers or whatever other feature you may be interested in, and because you can also run this fw on practically available hardware and see it working, you are not limited to just staring at the code - you can see its debug trace output as it runs, you can examine the state of various internal variables as it does the handovers and other operations, you can add extra debug traces of your own to print out whatever you are interested in, and so forth - that's the power of having a fully functional commercial product quality GSM MS implementation available in full source form, running on practically available hw. M~ From ronemp at gmail.com Tue Jan 16 23:40:49 2018 From: ronemp at gmail.com (Ronan Empig) Date: Wed, 17 Jan 2018 07:40:49 +0800 Subject: OSMO-TRX with OSMO-NITB and OSMO-BTS error Message-ID: Hi, I am using LimeSDR and I would like to setup a mini GSM base station. I am following this instructions: https://discourse.myriadrf.org/t/limesdr-osmo-trx-no-work/1938/27 However, I am getting trouble starting tranceiver: *TERMINAL 1:* ronan at ronan-MS-N014:~/Downloads$ osmo-nitb -c openbsc.cfg -l hlr.sqlite3 -P -C <0005> abis_nm.c:2800 (bts=0,trx=0) Changing adm. state Unlocked -> Unlocked [vty] <001e> telnet_interface.c:104 telnet at 127.0.0.1 4242 <0005> bsc_init.c:465 WARNING: You are running an 'accept-all' network on a BTS that is not barred. This configuration is likely to interfere with production GSM networks and should only be used in a RF shielded environment such as a faraday cage! <0020> input/ipaccess.c:848 enabling ipaccess BSC mode on 0.0.0.0 with OML 3002 and RSL 3003 TCP ports <0017> smpp_smsc.c:1001 SMPP at 0.0.0.0 2775 <0025> control_if.c:854 CTRL at 127.0.0.1 4249 DB: Database initialized. DB: Database prepared. <0020> input/ipa.c:263 accept()ed new link from 127.0.0.1 to port 3002 <0005> abis_nm.c:507 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. <0005> abis_nm.c:507 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:573 BTS0: ARI reported sw[0/2]: sysmobts is 0.7.0.20180115 <0005> abis_nm.c:446 BTS0 reported variant: omso-bts-trx <0005> abis_nm.c:468 BTS0 Attribute Manufacturer Dependent State is unreported <0005> abis_nm.c:573 BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown <0020> input/ipa.c:263 accept()ed new link from 127.0.0.1 to port 3003 <0004> bsc_init.c:311 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 514 using MCC=1 MNC=1 LAC=1 CID=0 BSIC=63 <0020> input/ipaccess.c:243 Sign link vanished, dead socket <0020> input/ipaccess.c:71 Forcing socket shutdown with no signal link set *TERMINAL 2:* ronan at ronan-MS-N014:~/Downloads$ osmo-bts-trx -c osmo-bts.cfg ((*)) | / \ OsmoBTS <0017> control_if.c:854 CTRL at 127.0.0.1 4238 <0010> telnet_interface.c:104 telnet at 127.0.0.1 4241 <0012> input/ipaccess.c:886 enabling ipaccess BTS mode, OML connecting to 127.0.0.1:3002 <000b> trx_if.c:599 Open transceiver for phy0.0 <0012> input/ipa.c:129 connection done. <0012> input/ipaccess.c:707 received ID get <0001> oml.c:229 O&M Get Attributes [0], Manufacturer Dependent State is unsupported by TRX. <0001> oml.c:680 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:1049 ADM state already was Unlocked <0012> input/ipa.c:129 connection done. <0012> input/ipaccess.c:707 received ID get <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1108205-0=1108205 > 1! <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1108421-1108300=121 > 1! <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1108638-1108435=203 > 1! <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1108855-1108652=203 > 1! <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1109072-1108870=202 > 1! <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1109289-1109086=203 > 1! <0001> bts.c:210 Shutting down BTS 0, Reason No clock from osmo-trx <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1112227-1109693=2534 > 1! <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> bts.c:205 BTS is already being shutdown. <000b> trx_if.c:172 No response from transceiver for phy0.0 Shutdown timer expired ronan at ronan-MS-N014:~/Downloads$ *TERMINAL 3:* ronan at ronan-MS-N014:~/Downloads$ sudo osmo-trx -e [sudo] password for ronan: linux; GNU C++ version 5.4.0 20160609 <%2802%29%20016%200609>; Boost_105800; UHD_003.010.002.000-release Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in, but not supported by CPU Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 GSM Core Address.........127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ Enabled Reference............... Internal C0 Filler Table......... Disabled Multi-Carrier........... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 -- Make connection: 'LimeSDR-USB [USB 2.0] 9060B00470E28' -- Reference clock 30.720 MHz -- Device name: LimeSDR-USB -- Reference: 30.72 MHz -- Init LMS7002M(0) -- Ver=7, Rev=1, Mask=1 -- LMS7002M calibration values caching Disable -- Transceiver active with 1 channel(s) NOTICE 139639362156288 07:03:23.5 Transceiver.cpp:791:driveControl: Changing TSC from 0 to 7 NOTICE 139639362156288 07:03:23.5 Transceiver.cpp:244:start: Starting the transceiver ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=174420 time_end=171360 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=174420 time_end=171360 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=179520 time_end=176460 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=179520 time_end=176460 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=184620 time_end=181560 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=184620 time_end=181560 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=190740 time_end=186660 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=190740 time_end=186660 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=196860 time_end=192780 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=196860 time_end=192780 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=201960 time_end=198900 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=201960 time_end=198900 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=207060 time_end=204000 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=207060 time_end=204000 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=213180 time_end=209100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=213180 time_end=209100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=217260 time_end=215220 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=217260 time_end=215220 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=224400 time_end=219300 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=224400 time_end=219300 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=229500 time_end=226440 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=229500 time_end=226440 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=234600 time_end=231540 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=234600 time_end=231540 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=239700 time_end=236640 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=239700 time_end=236640 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=245820 time_end=241740 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=245820 time_end=241740 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=251940 time_end=247860 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=251940 time_end=247860 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=258060 time_end=253980 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=258060 time_end=253980 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=263160 time_end=260100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=263160 time_end=260100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=268260 time_end=265200 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=268260 time_end=265200 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=273360 time_end=270300 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=273360 time_end=270300 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=279480 time_end=275400 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=279480 time_end=275400 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=285600 time_end=281520 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=285600 time_end=281520 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=290700 time_end=287640 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=290700 time_end=287640 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=322320 time_end=292740 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=322320 time_end=292740 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=328440 time_end=324360 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=328440 time_end=324360 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=333540 time_end=330480 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=333540 time_end=330480 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=338640 time_end=335580 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=338640 time_end=335580 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=343740 time_end=340680 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=343740 time_end=340680 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=349860 time_end=345780 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=349860 time_end=345780 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=355980 time_end=351900 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=355980 time_end=351900 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=360060 time_end=358020 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=360060 time_end=358020 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=367200 time_end=362100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=367200 time_end=362100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=372300 time_end=369240 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=372300 time_end=369240 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=378420 time_end=374340 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=378420 time_end=374340 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=383520 time_end=380460 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=383520 time_end=380460 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=389640 time_end=385560 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=389640 time_end=385560 ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:868:check_rx_md_err: Current time: 0, Previous time: 0.359668 ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:868:check_rx_md_err: Current time: 0, Previous time: 0.359668 ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: Current time: 0.120517, Previous time: 0.359668 ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: Current time: 0.120517, Previous time: 0.359668 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=399840 time_end=391680 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=399840 time_end=391680 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=410040 time_end=408000 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=410040 time_end=408000 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=415140 time_end=412080 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=415140 time_end=412080 ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: Current time: 0, Previous time: 0.383206 ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: Current time: 0, Previous time: 0.383206 ERR 139639362090752 07:03:24.8 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=440640 time_end=417180 ERR 139639362090752 07:03:24.8 UHDDevice.cpp:1383:write: Skipping -------------- next part -------------- An HTML attachment was scrubbed... URL: From pespin at sysmocom.de Tue Jan 16 23:55:53 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 17 Jan 2018 00:55:53 +0100 Subject: OSMO-TRX with OSMO-NITB and OSMO-BTS error In-Reply-To: References: Message-ID: Hi, have a look at https://osmocom.org/issues/2723, seems similar to what I have been experiencing recently. Today I spent some more time looking into it and I found out most issues in osmo-trx seem to come from Limesuite layer, in my case returning SOAPY_SDR_TIMEOUT and outputing timeout errors in osmo-trx log. I started writing and testing some improvements into osmo-trx and osmo-bts-trx, which hopefully will make the startup more stable. I think I'll be able to push the changeset tomorrow to gerrit. -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From ronemp at gmail.com Wed Jan 17 02:27:20 2018 From: ronemp at gmail.com (Ronan Empig) Date: Wed, 17 Jan 2018 10:27:20 +0800 Subject: OSMO-TRX with OSMO-NITB and OSMO-BTS error In-Reply-To: References: Message-ID: Hi Pau Thanks a lot on this. Hopefully this will fix our problem Thanks Ronan On Wed, Jan 17, 2018 at 7:55 AM, Pau Espin Pedrol wrote: > Hi, > > have a look at https://osmocom.org/issues/2723, seems similar to what I > have been experiencing recently. Today I spent some more time looking into > it and I found out most issues in osmo-trx seem to come from Limesuite > layer, in my case returning SOAPY_SDR_TIMEOUT and outputing timeout errors > in osmo-trx log. > > I started writing and testing some improvements into osmo-trx and > osmo-bts-trx, which hopefully will make the startup more stable. I think > I'll be able to push the changeset tomorrow to gerrit. > > > -- > - Pau Espin Pedrol http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Alt-Moabit 93 > * 10559 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Geschaeftsfuehrer / Managing Director: Harald Welte > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djks74 at gmail.com Wed Jan 17 05:43:26 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Wed, 17 Jan 2018 12:43:26 +0700 Subject: OSMO-TRX with OSMO-NITB and OSMO-BTS error In-Reply-To: References: Message-ID: Yesss... Hopefully it will be fix soon cause im gonna test more with osno-bsc osmo-hlr osmo-msc which osno-trx has problem with limesdr. Thanks Pespin. :) Regards, DUO On Jan 17, 2018 9:27 AM, "Ronan Empig" wrote: > Hi Pau > > Thanks a lot on this. Hopefully this will fix our problem > > Thanks > Ronan > > On Wed, Jan 17, 2018 at 7:55 AM, Pau Espin Pedrol > wrote: > >> Hi, >> >> have a look at https://osmocom.org/issues/2723, seems similar to what I >> have been experiencing recently. Today I spent some more time looking into >> it and I found out most issues in osmo-trx seem to come from Limesuite >> layer, in my case returning SOAPY_SDR_TIMEOUT and outputing timeout errors >> in osmo-trx log. >> >> I started writing and testing some improvements into osmo-trx and >> osmo-bts-trx, which hopefully will make the startup more stable. I think >> I'll be able to push the changeset tomorrow to gerrit. >> >> >> -- >> - Pau Espin Pedrol http://www.sysmocom.de/ >> ======================================================================= >> * sysmocom - systems for mobile communications GmbH >> * Alt-Moabit 93 >> >> * 10559 Berlin, Germany >> * Sitz / Registered office: Berlin, HRB 134158 B >> * Geschaeftsfuehrer / Managing Director: Harald Welte >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael at riseup.net Wed Jan 17 13:01:19 2018 From: rafael at riseup.net (Rafael Diniz) Date: Wed, 17 Jan 2018 11:01:19 -0200 Subject: OSMO-TRX with OSMO-NITB and OSMO-BTS error In-Reply-To: References: Message-ID: <78a50166-0a52-be20-b536-314fc123cedf@riseup.net> Hi, I don't know if its coincidence, but when trying osmo-trx with a USRP2 in a computer without SSE4.1, osmo-trx was aborting very often, but when working in a computer with SSE4.1, it got much more stable. Best regards, Rafael Diniz On 01/16/2018 09:40 PM, Ronan Empig wrote: > Hi, > > I am using LimeSDR and I would like to setup a mini GSM base station. I > am following this instructions: > > https://discourse.myriadrf.org/t/limesdr-osmo-trx-no-work/1938/27 > > > However, I am getting trouble starting tranceiver: > > *TERMINAL 1:* > > ronan at ronan-MS-N014:~/Downloads$ osmo-nitb -c openbsc.cfg -l hlr.sqlite3 > -P -C > <0005> abis_nm.c:2800 (bts=0,trx=0) Changing adm. state Unlocked -> > Unlocked [vty] > <001e> telnet_interface.c:104 telnet at 127.0.0.1 4242 > <0005> bsc_init.c:465? > WARNING: You are running an 'accept-all' network on a BTS that is not > barred.? This configuration is likely to interfere with production GSM > networks and should only be used in a RF shielded environment such as a > faraday cage! > > <0020> input/ipaccess.c:848 enabling ipaccess BSC mode on 0.0.0.0 with > OML 3002 and RSL 3003 TCP ports > <0017> smpp_smsc.c:1001 SMPP at 0.0.0.0 2775 > <0025> control_if.c:854 CTRL at 127.0.0.1 4249 > DB: Database initialized. > DB: Database prepared. > <0020> input/ipa.c:263 accept()ed new link from 127.0.0.1 to port 3002 > <0005> abis_nm.c:507 BTS0 feature 'EGPRS' reported via OML does not > match statically set feature: 0 != 1. Please fix. > <0005> abis_nm.c:507 BTS0 feature 'OML Alerts' reported via OML does not > match statically set feature: 1 != 0. Please fix. > <0005> abis_nm.c:573 BTS0: ARI reported sw[0/2]: sysmobts is 0.7.0.20180115 > <0005> abis_nm.c:446 BTS0 reported variant: omso-bts-trx > <0005> abis_nm.c:468 BTS0 Attribute Manufacturer Dependent State is > unreported > <0005> abis_nm.c:573 BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown > <0020> input/ipa.c:263 accept()ed new link from 127.0.0.1 to port 3003 > <0004> bsc_init.c:311 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 514 > using MCC=1 MNC=1 LAC=1 CID=0 BSIC=63 > <0020> input/ipaccess.c:243 Sign link vanished, dead socket > <0020> input/ipaccess.c:71 Forcing socket shutdown with no signal link set > > > *TERMINAL 2:* > * > * > ronan at ronan-MS-N014:~/Downloads$ osmo-bts-trx -c osmo-bts.cfg > ((*)) > ? | > ?/ \ OsmoBTS > <0017> control_if.c:854 CTRL at 127.0.0.1 4238 > <0010> telnet_interface.c:104 telnet at 127.0.0.1 4241 > <0012> input/ipaccess.c:886 enabling ipaccess BTS mode, OML connecting > to?127.0.0.1:3002 > <000b> trx_if.c:599 Open transceiver for phy0.0 > <0012> input/ipa.c:129 connection done. > <0012> input/ipaccess.c:707 received ID get > <0001> oml.c:229 O&M Get Attributes [0], Manufacturer Dependent State is > unsupported by TRX. > <0001> oml.c:680 Ignoring T200[0] (150 ms) as sent by BSC due to > suspected LAPDm bug! > <0001> oml.c:680 Ignoring T200[1] (180 ms) as sent by BSC due to > suspected LAPDm bug! > <0001> oml.c:680 Ignoring T200[2] (180 ms) as sent by BSC due to > suspected LAPDm bug! > <0001> oml.c:680 Ignoring T200[3] (1680 ms) as sent by BSC due to > suspected LAPDm bug! > <0001> oml.c:680 Ignoring T200[4] (520 ms) as sent by BSC due to > suspected LAPDm bug! > <0001> oml.c:680 Ignoring T200[5] (165 ms) as sent by BSC due to > suspected LAPDm bug! > <0001> oml.c:680 Ignoring T200[6] (1680 ms) as sent by BSC due to > suspected LAPDm bug! > <0001> oml.c:1049 ADM state already was Unlocked > <0012> input/ipa.c:129 connection done. > <0012> input/ipaccess.c:707 received ID get > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <000b> trx_if.c:172 No response from transceiver for phy0.0 > <0007> l1sap.c:462 Invalid condition detected: Frame difference is > 1108205-0=1108205 > 1! > <0007> l1sap.c:462 Invalid condition detected: Frame difference is > 1108421-1108300=121 > 1! > <0007> l1sap.c:462 Invalid condition detected: Frame difference is > 1108638-1108435=203 > 1! > <0007> l1sap.c:462 Invalid condition detected: Frame difference is > 1108855-1108652=203 > 1! > <0007> l1sap.c:462 Invalid condition detected: Frame difference is > 1109072-1108870=202 > 1! > <0007> l1sap.c:462 Invalid condition detected: Frame difference is > 1109289-1109086=203 > 1! > <0001> bts.c:210 Shutting down BTS 0, Reason No clock from osmo-trx > <0007> l1sap.c:462 Invalid condition detected: Frame difference is > 1112227-1109693=2534 > 1! > <0001> oml.c:1049 ADM state already was Unlocked > <0001> oml.c:1049 ADM state already was Unlocked > <0001> oml.c:1049 ADM state already was Unlocked > <0001> oml.c:1049 ADM state already was Unlocked > <0001> oml.c:1049 ADM state already was Unlocked > <0001> oml.c:1049 ADM state already was Unlocked > <0001> oml.c:1049 ADM state already was Unlocked > <0001> oml.c:1049 ADM state already was Unlocked > <0001> bts.c:205 BTS is already being shutdown. > <000b> trx_if.c:172 No response from transceiver for phy0.0 > Shutdown timer expired > ronan at ronan-MS-N014:~/Downloads$* > * > > *TERMINAL 3:* > * > * > ronan at ronan-MS-N014:~/Downloads$ sudo osmo-trx -e > [sudo] password for ronan:? > linux; GNU C++ version 5.4.0 20160609 ; > Boost_105800; UHD_003.010.002.000-release > > Info: SSE3 support compiled in and supported by CPU > Info: SSE4.1 support compiled in, but not supported by CPU > Config Settings > ?? Log Level............... NOTICE > ?? Device args.............? > ?? TRX Base Port........... 5700 > ?? TRX Address............. 127.0.0.1 > ?? GSM Core Address.........127.0.0.1 > ?? Channels................ 1 > ?? Tx Samples-per-Symbol... 4 > ?? Rx Samples-per-Symbol... 4 > ?? EDGE support............ Enabled > ?? Reference............... Internal > ?? C0 Filler Table......... Disabled > ?? Multi-Carrier........... Disabled > ?? Tuning offset........... 0 > ?? RSSI to dBm offset...... 0 > ?? Swap channels........... 0 > > -- Make connection: 'LimeSDR-USB [USB 2.0] 9060B00470E28' > -- Reference clock 30.720 MHz > -- Device name: LimeSDR-USB > -- Reference: 30.72 MHz > -- Init LMS7002M(0) > -- Ver=7, Rev=1, Mask=1 > -- LMS7002M calibration values caching Disable > -- Transceiver active with 1 channel(s) > NOTICE 139639362156288 07:03:23.5 Transceiver.cpp:791:driveControl: > Changing TSC from 0 to 7 > NOTICE 139639362156288 07:03:23.5 Transceiver.cpp:244:start: Starting > the transceiver > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=174420 time_end=171360 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=174420 time_end=171360 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=179520 time_end=176460 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=179520 time_end=176460 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=184620 time_end=181560 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=184620 time_end=181560 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=190740 time_end=186660 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=190740 time_end=186660 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=196860 time_end=192780 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=196860 time_end=192780 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=201960 time_end=198900 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=201960 time_end=198900 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=207060 time_end=204000 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=207060 time_end=204000 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=213180 time_end=209100 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=213180 time_end=209100 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=217260 time_end=215220 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=217260 time_end=215220 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=224400 time_end=219300 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=224400 time_end=219300 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=229500 time_end=226440 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=229500 time_end=226440 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=234600 time_end=231540 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=234600 time_end=231540 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=239700 time_end=236640 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=239700 time_end=236640 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=245820 time_end=241740 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=245820 time_end=241740 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=251940 time_end=247860 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=251940 time_end=247860 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=258060 time_end=253980 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=258060 time_end=253980 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=263160 time_end=260100 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=263160 time_end=260100 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=268260 time_end=265200 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=268260 time_end=265200 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=273360 time_end=270300 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=273360 time_end=270300 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=279480 time_end=275400 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=279480 time_end=275400 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=285600 time_end=281520 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=285600 time_end=281520 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=290700 time_end=287640 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=290700 time_end=287640 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=322320 time_end=292740 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=322320 time_end=292740 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=328440 time_end=324360 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=328440 time_end=324360 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=333540 time_end=330480 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=333540 time_end=330480 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=338640 time_end=335580 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=338640 time_end=335580 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=343740 time_end=340680 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=343740 time_end=340680 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=349860 time_end=345780 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=349860 time_end=345780 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=355980 time_end=351900 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=355980 time_end=351900 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=360060 time_end=358020 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=360060 time_end=358020 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=367200 time_end=362100 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=367200 time_end=362100 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=372300 time_end=369240 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=372300 time_end=369240 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=378420 time_end=374340 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=378420 time_end=374340 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=383520 time_end=380460 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=383520 time_end=380460 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=389640 time_end=385560 > ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=389640 time_end=385560 > ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:867:check_rx_md_err: UHD: > Loss of monotonic time > ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:867:check_rx_md_err: UHD: > Loss of monotonic time > ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:868:check_rx_md_err: > Current time: 0, Previous time: 0.359668 > ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:868:check_rx_md_err: > Current time: 0, Previous time: 0.359668 > ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: > Loss of monotonic time > ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: > Loss of monotonic time > ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: > Current time: 0.120517, Previous time: 0.359668 > ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: > Current time: 0.120517, Previous time: 0.359668 > ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=399840 time_end=391680 > ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=399840 time_end=391680 > ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=410040 time_end=408000 > ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=410040 time_end=408000 > ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=415140 time_end=412080 > ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=415140 time_end=412080 > ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: > Loss of monotonic time > ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: > Loss of monotonic time > ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: > Current time: 0, Previous time: 0.383206 > ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: > Current time: 0, Previous time: 0.383206 > ERR 139639362090752 07:03:24.8 UHDDevice.cpp:1383:write: Skipping buffer > data: timestamp=440640 time_end=417180 > ERR 139639362090752 07:03:24.8 UHDDevice.cpp:1383:write: Skipping -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From laforge at gnumonks.org Wed Jan 17 13:31:38 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 17 Jan 2018 14:31:38 +0100 Subject: OSMO-TRX with OSMO-NITB and OSMO-BTS error In-Reply-To: <78a50166-0a52-be20-b536-314fc123cedf@riseup.net> References: <78a50166-0a52-be20-b536-314fc123cedf@riseup.net> Message-ID: <20180117133136.6drb4ncbrw4yn3jr@nataraja> On Wed, Jan 17, 2018 at 11:01:19AM -0200, Rafael Diniz wrote: > I don't know if its coincidence, but when trying osmo-trx with a USRP2 > in a computer without SSE4.1, osmo-trx was aborting very often, but when > working in a computer with SSE4.1, it got much more stable. Which version of osmo-trx were you using? We used to have a bug in this area, see http://osmocom.org/issues/2386 fixed in https://gerrit.osmocom.org/#/c/4892/ -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From rafael at riseup.net Wed Jan 17 14:19:14 2018 From: rafael at riseup.net (Rafael Diniz) Date: Wed, 17 Jan 2018 12:19:14 -0200 Subject: OSmux ideas implementation Message-ID: <838216aa-7162-c63f-e366-8f9988d27e04@riseup.net> Hi people, Is there anything implemented from the OSmux[1] ideas? [1] http://ftp.osmocom.org/docs/latest/osmux-reference.pdf Thanks, Rafael Diniz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rafael at riseup.net Wed Jan 17 14:21:52 2018 From: rafael at riseup.net (Rafael Diniz) Date: Wed, 17 Jan 2018 12:21:52 -0200 Subject: OSMO-TRX with OSMO-NITB and OSMO-BTS error In-Reply-To: <20180117133136.6drb4ncbrw4yn3jr@nataraja> References: <78a50166-0a52-be20-b536-314fc123cedf@riseup.net> <20180117133136.6drb4ncbrw4yn3jr@nataraja> Message-ID: <32f4f9e1-cf11-943b-068a-3fc040df3046@riseup.net> Im using 14/01/2018 nightly build on Debian 9, but I need to investigate further the problem. On 01/17/2018 11:31 AM, Harald Welte wrote: > On Wed, Jan 17, 2018 at 11:01:19AM -0200, Rafael Diniz wrote: >> I don't know if its coincidence, but when trying osmo-trx with a USRP2 >> in a computer without SSE4.1, osmo-trx was aborting very often, but when >> working in a computer with SSE4.1, it got much more stable. > > Which version of osmo-trx were you using? We used to have a bug in this > area, see http://osmocom.org/issues/2386 fixed in https://gerrit.osmocom.org/#/c/4892/ > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From pespin at sysmocom.de Wed Jan 17 15:42:00 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 17 Jan 2018 16:42:00 +0100 Subject: libosmocore wiki page and doxygen online documentation Message-ID: <640dfed1-32de-2143-ef0a-d94c692604c9@sysmocom.de> Hi, I was trying to find if the doxygen documentation is uploaded and publicly available somewhere in some web server. Google pointed me to this libosmocore wiki page: ftp://ftp.osmocom.org/api/latest/libosmonetif/ In there, there are several links to stuff like http://www.osmocom.org/doc/libosmocore/latest/html/, but I get access forbidden when trying to use that one. On the other hand, I found somewhere else a link to http://ftp.osmocom.org/api/latest/libosmonetif/html/ which seems to be working. Now the question is: which is the expected way to access the documentation? should "www.osmocom.org" work instead of having to use "ftp.osmocom.org"? -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From pespin at sysmocom.de Wed Jan 17 15:47:35 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 17 Jan 2018 16:47:35 +0100 Subject: OSmux ideas implementation In-Reply-To: <838216aa-7162-c63f-e366-8f9988d27e04@riseup.net> References: <838216aa-7162-c63f-e366-8f9988d27e04@riseup.net> Message-ID: <046a1407-dd70-81f3-39c2-70db9f8df675@sysmocom.de> Hi Rafael, You can find the implementation in libosmo-netif. It's been used for a while in production network in the link between somo-bsc-sccplite<->osmo-bsc_nat https://git.osmocom.org/libosmo-netif/tree/include/osmocom/netif/osmux.h https://git.osmocom.org/libosmo-netif/tree/src/osmux.c https://git.osmocom.org/libosmo-netif/tree/tests/osmux I think OSmux support in new osmo-mgw is still not finished though (WIP), but should work fine in osmo-bsc_mgcp and osmo_bsc_nat from openbsc repository. You can find related OSmux issues in: https://osmocom.org/search?issues=1&q=OSmux -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From rafael at riseup.net Wed Jan 17 16:40:10 2018 From: rafael at riseup.net (Rafael Diniz) Date: Wed, 17 Jan 2018 14:40:10 -0200 Subject: OSmux ideas implementation In-Reply-To: <046a1407-dd70-81f3-39c2-70db9f8df675@sysmocom.de> References: <838216aa-7162-c63f-e366-8f9988d27e04@riseup.net> <046a1407-dd70-81f3-39c2-70db9f8df675@sysmocom.de> Message-ID: <359901bc-5dca-f2ad-f03a-0ca484740e83@riseup.net> Hi Pau, Thanks a lot, I'll try! On 01/17/2018 01:47 PM, Pau Espin Pedrol wrote: > Hi Rafael, > > You can find the implementation in libosmo-netif. It's been used for a > while in production network in the link between > somo-bsc-sccplite<->osmo-bsc_nat > > https://git.osmocom.org/libosmo-netif/tree/include/osmocom/netif/osmux.h > https://git.osmocom.org/libosmo-netif/tree/src/osmux.c > https://git.osmocom.org/libosmo-netif/tree/tests/osmux > > I think OSmux support in new osmo-mgw is still not finished though > (WIP), but should work fine in osmo-bsc_mgcp and osmo_bsc_nat from > openbsc repository. > > You can find related OSmux issues in: > https://osmocom.org/search?issues=1&q=OSmux > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From alexander.huemer at xx.vu Thu Jan 18 00:12:32 2018 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Thu, 18 Jan 2018 01:12:32 +0100 Subject: osmo-trx with USRP1 - libusrp vs. UHD In-Reply-To: <20171221205512.GA4130@nataraja> References: <20171221185724.GA4464@yade.chaostreff.at> <20171221205512.GA4130@nataraja> Message-ID: <20180118001232.GA12278@yade.chaostreff.at> Hi! On Thu, Dec 21, 2017 at 09:55:12PM +0100, Harald Welte wrote: > On Thu, Dec 21, 2017 at 07:57:24PM +0100, Alexander Huemer wrote: > > I played with osmo-trx today and tried to run it with a USRP1 that I > > have laying around, though to no avail. > > I also still have two USRP1 here that don't have a purpose anymore. > > My offer is: If you (or the community in general) works out how to make > USRP1 work with current-day osmo-trx (either via UHD or via a ported > libusrp) on a system like Debian9, I will make sure that a USRP1 > becomes part of the osmo-gsm-tester setup[1] to ensure support for this > board will not bit-rot again. Fair enough. What I did so far is: * Extract libusrp from gnuradio 3.4.2, using git filter-branch to preserve history * Craft custom configure.ac * Update m4 macros * Small fixes here and there libusrp builds without warnings now and can be installed with `make install` as expected. After a trivial fix of osmo-trx with `configure --with-usrp1` it starts without complaining. -- Transceiver active with 1 channel(s) Still, when I try to run a full network with osmo-{stp,hlr,msc,bsc,bts-trx}, osmo-bts-trx aborts with: <000b> trx_if.c:413 transceiver (phy0.0) rejected TRX command with response: 'RSP RXTUNE 1 1763200' <0001> bts.c:210 Shutting down BTS 0, Reason TRX-CTRL-MSG: CRITICAL Shutdown timer expired osmo-trx emits: ALERT 140296268797696 00:38:04.3 USRPDevice.cpp:590:setRxFreq: set RX: 1.7632e+09failed baseband freq: 1.75825e+09 DDC freq: -4.95e+06 residual freq: -0.00447035 ALERT 140296268797696 00:38:04.3 USRPDevice.cpp:590:setRxFreq: set RX: 1.7632e+09failed baseband freq: 1.75825e+09 DDC freq: -4.95e+06 residual freq: -0.00447035 ALERT 140296268797696 00:38:04.3 Transceiver.cpp:766:driveControl: RX failed to tune ALERT 140296268797696 00:38:04.3 Transceiver.cpp:766:driveControl: RX failed to tune I don't think that my clock is too far off, I am using a freshly calibrated clocktamer to feed 52MHz into the USRP. Why the USRP would not be able to tune to ARFCN 777 is not clear to me. E.g. kalibreate has no problem with receiving all ARFCNs in DCS. Should anybody have an idea what to look into, suggestions would be appreciated. Kind regards, -Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From alexander.huemer at xx.vu Thu Jan 18 00:14:49 2018 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Thu, 18 Jan 2018 01:14:49 +0100 Subject: osmo-trx with USRP1 - libusrp vs. UHD In-Reply-To: References: <20171221185724.GA4464@yade.chaostreff.at> <20171221205512.GA4130@nataraja> Message-ID: <20180118001449.GB12278@yade.chaostreff.at> Hi! On Wed, Dec 27, 2017 at 07:00:44AM +0100, Sylvain Munaut wrote: > osmo-trx needs devices that support hardware timestamping of packets (TX/RX). > > The URSP1 UHD driver doesn't support that. All the timestamps are > 'faked' in software. > That's because the FPGA image for USRP1 doesn't support hardware timestamps. > > OpenBTS used a custom FPGA image where hardware timestamping support > was added and they used libusrp (and not UHD) because it was a lower > layer API and that let them access the raw content of the data packets > sent by the USRP. That's needed because with that new FPGA image, the > content of those packets is no longer just samples, but it now has a > header with the timestamps and some flags that needs to be intepreted > to generate the timestamping and removed before converting the > samples. > > A long time ago I wanted to implement support for that FPGA image into > UHD ... and then when I looked into UHD work, I gave up ... (basically > I could never figure out _HOW_ UHD works). Thanks for the great explanation! So, in theory it would be possible to make osmo-trx work with a USRP1 via UHD, though nobody has done (yet) what you described above. Kind regards, -Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Thu Jan 18 09:57:52 2018 From: msuraev at sysmocom.de (Max) Date: Thu, 18 Jan 2018 10:57:52 +0100 Subject: osmo-trx with USRP1 - libusrp vs. UHD In-Reply-To: <20180118001232.GA12278@yade.chaostreff.at> References: <20171221185724.GA4464@yade.chaostreff.at> <20171221205512.GA4130@nataraja> <20180118001232.GA12278@yade.chaostreff.at> Message-ID: <1f2646bf-990e-62d2-3405-0dbcf3bb8277@sysmocom.de> Hi. Just a little side note. On 18.01.2018 01:12, Alexander Huemer wrote: > > After a trivial fix of osmo-trx with `configure --with-usrp1` it starts > without complaining. > Might make sense to push this to gerrit to make it easier for people to follow your steps. -- - Max Suraev http://www.sysmocom.de/ =========================================== * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte From laforge at gnumonks.org Thu Jan 18 13:59:34 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 18 Jan 2018 14:59:34 +0100 Subject: osmo-trx with USRP1 - libusrp vs. UHD In-Reply-To: <20180118001232.GA12278@yade.chaostreff.at> References: <20171221185724.GA4464@yade.chaostreff.at> <20171221205512.GA4130@nataraja> <20180118001232.GA12278@yade.chaostreff.at> Message-ID: <20180118135932.6mairoyi4xxkdwef@nataraja> Hi Alexander, On Thu, Jan 18, 2018 at 01:12:32AM +0100, Alexander Huemer wrote: > What I did so far is: > * Extract libusrp from gnuradio 3.4.2, using git filter-branch to > preserve history > * Craft custom configure.ac > * Update m4 macros > * Small fixes here and there It might make sense to push the results into a git repository. I've created a libusrp.git on git.osmocom.org and gerrit. You should be able to push into it like any other osmocom project on gerrit. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From rafael at riseup.net Thu Jan 18 14:04:10 2018 From: rafael at riseup.net (Rafael Diniz) Date: Thu, 18 Jan 2018 12:04:10 -0200 Subject: osmo-trx with USRP1 - libusrp vs. UHD In-Reply-To: <1f2646bf-990e-62d2-3405-0dbcf3bb8277@sysmocom.de> References: <20171221185724.GA4464@yade.chaostreff.at> <20171221205512.GA4130@nataraja> <20180118001232.GA12278@yade.chaostreff.at> <1f2646bf-990e-62d2-3405-0dbcf3bb8277@sysmocom.de> Message-ID: Can I use a USRP1 without clock modification? Rafael Diniz On 01/18/2018 07:57 AM, Max wrote: > Hi. > > Just a little side note. > > > On 18.01.2018 01:12, Alexander Huemer wrote: >> >> After a trivial fix of osmo-trx with `configure --with-usrp1` it starts >> without complaining. >> > > Might make sense to push this to gerrit to make it easier for people to > follow your steps. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nhofmeyr at sysmocom.de Thu Jan 18 15:32:40 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 18 Jan 2018 16:32:40 +0100 Subject: libosmocore wiki page and doxygen online documentation In-Reply-To: <640dfed1-32de-2143-ef0a-d94c692604c9@sysmocom.de> References: <640dfed1-32de-2143-ef0a-d94c692604c9@sysmocom.de> Message-ID: <20180118153240.GA2818@my.box> On Wed, Jan 17, 2018 at 04:42:00PM +0100, Pau Espin Pedrol wrote: > Hi, > > I was trying to find if the doxygen documentation is uploaded and publicly > available somewhere in some web server. > > Google pointed me to this libosmocore wiki page: > ftp://ftp.osmocom.org/api/latest/libosmonetif/ > > In there, there are several links to stuff like > http://www.osmocom.org/doc/libosmocore/latest/html/, but I get access > forbidden when trying to use that one. > > On the other hand, I found somewhere else a link to > http://ftp.osmocom.org/api/latest/libosmonetif/html/ which seems to be > working. > > Now the question is: which is the expected way to access the documentation? > should "www.osmocom.org" work instead of having to use "ftp.osmocom.org"? Check job https://jenkins.osmocom.org/jenkins/job/Osmocom_API/ ... it does rsync -avz --delete -e "ssh -p 48" ./libosmocore/doc/ api at osmocom.org:web-files/latest/libosmocore/ looks like it uploads to http://ftp.osmocom.org/api/latest/ ftp://ftp.osmocom.org/api/latest/ Looking at the "Generated" footer confirms that... http://www.osmocom.org/doc/libosmocore/latest/html/index.html (which works for me) was generated 2011 (!) We should probably remove the outdated api docs and have a central pointer in the wiki somewhere, maybe in an API wiki page that cross-references back and forth with the Manuals wiki page...? (I'm not going to do it now) BTW, who reads the doxygen API doc anyway ;) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From alexander.huemer at xx.vu Thu Jan 18 16:51:54 2018 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Thu, 18 Jan 2018 17:51:54 +0100 Subject: osmo-trx with USRP1 - libusrp vs. UHD In-Reply-To: <1f2646bf-990e-62d2-3405-0dbcf3bb8277@sysmocom.de> References: <20171221185724.GA4464@yade.chaostreff.at> <20171221205512.GA4130@nataraja> <20180118001232.GA12278@yade.chaostreff.at> <1f2646bf-990e-62d2-3405-0dbcf3bb8277@sysmocom.de> Message-ID: <20180118165154.GA25188@yade.chaostreff.at> On Thu, Jan 18, 2018 at 10:57:52AM +0100, Max wrote: > On 18.01.2018 01:12, Alexander Huemer wrote: > > > >After a trivial fix of osmo-trx with `configure --with-usrp1` it starts > >without complaining. > > Might make sense to push this to gerrit to make it easier for people to > follow your steps. I will. Kind regards, -Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From ronemp at gmail.com Fri Jan 19 01:20:59 2018 From: ronemp at gmail.com (Ronan Empig) Date: Fri, 19 Jan 2018 09:20:59 +0800 Subject: OSMO-TRX with OSMO-NITB and OSMO-BTS error In-Reply-To: References: Message-ID: Hi Pau Any updates on this one? Thanks Ronan On Wed, Jan 17, 2018 at 10:27 AM, Ronan Empig wrote: > Hi Pau > > Thanks a lot on this. Hopefully this will fix our problem > > Thanks > Ronan > > On Wed, Jan 17, 2018 at 7:55 AM, Pau Espin Pedrol > wrote: > >> Hi, >> >> have a look at https://osmocom.org/issues/2723, seems similar to what I >> have been experiencing recently. Today I spent some more time looking into >> it and I found out most issues in osmo-trx seem to come from Limesuite >> layer, in my case returning SOAPY_SDR_TIMEOUT and outputing timeout errors >> in osmo-trx log. >> >> I started writing and testing some improvements into osmo-trx and >> osmo-bts-trx, which hopefully will make the startup more stable. I think >> I'll be able to push the changeset tomorrow to gerrit. >> >> >> -- >> - Pau Espin Pedrol http://www.sysmocom.de/ >> ======================================================================= >> * sysmocom - systems for mobile communications GmbH >> * Alt-Moabit 93 >> * 10559 Berlin, Germany >> * Sitz / Registered office: Berlin, HRB 134158 B >> * Geschaeftsfuehrer / Managing Director: Harald Welte >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronemp at gmail.com Fri Jan 19 05:16:41 2018 From: ronemp at gmail.com (Ronan Empig) Date: Fri, 19 Jan 2018 13:16:41 +0800 Subject: OSMO-TRX with OSMO-NITB and OSMO-BTS error In-Reply-To: References: Message-ID: Hi Jimmy I am copying you on our mailing list. Here is the updates so far on our installation. It is still not working. Ronan On Fri, Jan 19, 2018 at 9:20 AM, Ronan Empig wrote: > Hi Pau > > Any updates on this one? > > Thanks > Ronan > > On Wed, Jan 17, 2018 at 10:27 AM, Ronan Empig wrote: > >> Hi Pau >> >> Thanks a lot on this. Hopefully this will fix our problem >> >> Thanks >> Ronan >> >> On Wed, Jan 17, 2018 at 7:55 AM, Pau Espin Pedrol >> wrote: >> >>> Hi, >>> >>> have a look at https://osmocom.org/issues/2723, seems similar to what I >>> have been experiencing recently. Today I spent some more time looking into >>> it and I found out most issues in osmo-trx seem to come from Limesuite >>> layer, in my case returning SOAPY_SDR_TIMEOUT and outputing timeout errors >>> in osmo-trx log. >>> >>> I started writing and testing some improvements into osmo-trx and >>> osmo-bts-trx, which hopefully will make the startup more stable. I think >>> I'll be able to push the changeset tomorrow to gerrit. >>> >>> >>> -- >>> - Pau Espin Pedrol http://www.sysmocom.de/ >>> ======================================================================= >>> * sysmocom - systems for mobile communications GmbH >>> * Alt-Moabit 93 >>> * 10559 Berlin, Germany >>> * Sitz / Registered office: Berlin, HRB 134158 B >>> * Geschaeftsfuehrer / Managing Director: Harald Welte >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pespin at sysmocom.de Fri Jan 19 11:14:10 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Fri, 19 Jan 2018 12:14:10 +0100 Subject: OSMO-TRX with OSMO-NITB and OSMO-BTS error In-Reply-To: References: Message-ID: Hi Ronan, I did some work to fix some stability problems I saw in osmo-bts-trx while testing osmo-trx with limesdr. They are in gerrit [1] but haven't been reviewed yet and jenkins validation failed due to issue being addressed in [2] which in turn was not merged yet neither. However, while these patches clear a bit the mess in the logs and may fix some eventual issues, the reality is that the problem is still there, and as far as I understand they come from the limesuite layer. It seems it fails to retrieve packets when asked from upper layers, which means the clock is not updated and then osmo-bts-trx stops. I so far went down through the layers to see the paths being used but got lost around the point in which it reads from the fifo in limesuite. I couldn't find yet who is populating that fifo from the device. As a reminder, the issue is being tracked in [3]. [1] https://gerrit.osmocom.org/#/c/5856 [2] https://gerrit.osmocom.org/#/c/5818/ [3] https://osmocom.org/issues/2723 -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From jenkins at lists.osmocom.org Fri Jan 19 16:41:48 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Fri, 19 Jan 2018 16:41:48 +0000 (GMT) Subject: =?UTF-8?Q?Build_failed_in_Jenkins:_Coverity-?= =?UTF-8?Q?Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1736?= Message-ID: <1906024019.762.1516380108333.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 2.16 MB...] CC osmo-bts-sysmo/sysmo_l1_fwd.o CXXLD libgprs.la CXXLD osmo-pcu CXXLD osmo-pcu-remote make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' Making all in examples make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' Making all in tests make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' CXX pcu_emu.o CXX test_replay_gprs_attach.o CC openbsc_clone.o CXX test_pdp_activation.o CXXLD emu/pcu_emu make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[1]: Nothing to be done for 'all-am'. make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' + make install Making install in include make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[2]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/pcu' /usr/bin/install -c -m 644 osmocom/pcu/pcuif_proto.h '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/pcu' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' Making install in src make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' /bin/sh ../libtool --mode=install /usr/bin/install -c osmo-pcu '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' libtool: install: /usr/bin/install -c osmo-pcu /home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin/osmo-pcu make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' Making install in examples make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[2]: 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-pcu.cfg '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' Making install in tests make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' 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-pcu/tests' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[2]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/pkgconfig' /usr/bin/install -c -m 644 osmo-pcu.pc '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/pkgconfig' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' + popd ~/osmo-ci/coverity/source-Osmocom + build_osmobts + pushd osmo-bts ~/osmo-ci/coverity/source-Osmocom/osmo-bts ~/osmo-ci/coverity/source-Osmocom + do_build --enable-sysmocom-bts --enable-trx + autoreconf --install --force libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac:21: installing './compile' configure.ac:23: installing './config.guess' configure.ac:23: installing './config.sub' configure.ac:9: installing './install-sh' configure.ac:9: installing './missing' src/common/Makefile.am: installing './depcomp' src/osmo-bts-sysmo/Makefile.am:25: warning: bin_PROGRAMS was already defined in condition TRUE, which includes condition ENABLE_SYSMOBTS_CALIB ... src/osmo-bts-sysmo/Makefile.am:10: ... 'bin_PROGRAMS' previously defined here src/osmo-bts-sysmo/Makefile.am:12: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:12: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. src/osmo-bts-sysmo/Makefile.am:27: warning: source file 'misc/sysmobts-calib.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:27: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:27: warning: source file 'misc/sysmobts-layer1.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:27: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_misc.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_nl.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_2050.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_vty.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_nl.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_temp.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_calib.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:42: warning: source file 'misc/sysmobts_util.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:42: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:42: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:42: but option 'subdir-objects' is disabled tests/agch/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/agch/Makefile.am:7: but option 'subdir-objects' is disabled tests/cipher/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/cipher/Makefile.am:7: but option 'subdir-objects' is disabled tests/misc/Makefile.am:9: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/misc/Makefile.am:9: but option 'subdir-objects' is disabled tests/paging/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/paging/Makefile.am:7: but option 'subdir-objects' is disabled tests/power/Makefile.am:8: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/power/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/utils.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/l1_if.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/oml.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/l1_transp_hw.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/tch.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/calib_file.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/calib_fixup.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/misc/sysmobts_par.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/eeprom.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/tx_power/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/tx_power/Makefile.am:7: but option 'subdir-objects' is disabled + ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom --enable-sysmocom-bts --enable-trx checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking whether make sets $(MAKE)... (cached) yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for pkg-config... /usr/bin/pkg-config checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.20... yes checking for ANSI C header files... (cached) yes checking for LIBOSMOCORE... yes checking for LIBOSMOVTY... yes checking for LIBOSMOTRAU... yes checking for LIBOSMOGSM... yes checking for LIBOSMOCTRL... yes checking for LIBOSMOABIS... yes checking for LIBOSMOCODEC... yes checking for LIBOSMOCODING... yes checking for ORTP... yes checking whether to enable support for sysmobts calibration tool... no checking whether to enable support for sysmoBTS L1/PHY support... yes checking for sysmocom/femtobts/superfemto.h... no configure: error: sysmocom/femtobts/superfemto.h can not be found in . [WARNING] Build command ./build_Osmocom.sh exited with code 1. Please verify that the build completed successfully. Emitted 1913 C/C++ compilation units (100%) successfully 1913 C/C++ compilation units (100%) are ready for analysis For more details, please look at: /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt Build step 'Execute shell' marked build as failure From jenkins at lists.osmocom.org Sat Jan 20 16:12:39 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Sat, 20 Jan 2018 16:12:39 +0000 (GMT) Subject: =?UTF-8?Q?Build_failed_in_Jenkins:_Coverity-?= =?UTF-8?Q?Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1737?= In-Reply-To: <1906024019.762.1516380108333.JavaMail.jenkins@jenkins.osmocom.org> References: <1906024019.762.1516380108333.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <229539449.785.1516464759937.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 2.12 MB...] CC osmo-bts-sysmo/sysmo_l1_fwd.o CXXLD libgprs.la CXXLD osmo-pcu-remote CXXLD osmo-pcu make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' Making all in examples make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' Making all in tests make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' CXX test_replay_gprs_attach.o CC openbsc_clone.o CXX test_pdp_activation.o CXX pcu_emu.o CXXLD emu/pcu_emu make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[1]: Nothing to be done for 'all-am'. make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' + make install Making install in include make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[2]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/pcu' /usr/bin/install -c -m 644 osmocom/pcu/pcuif_proto.h '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/pcu' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' Making install in src make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' /bin/bash ../libtool --mode=install /usr/bin/install -c osmo-pcu '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' libtool: install: /usr/bin/install -c osmo-pcu /home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin/osmo-pcu make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' Making install in examples make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[2]: 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-pcu.cfg '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' Making install in tests make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' 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-pcu/tests' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[2]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/pkgconfig' /usr/bin/install -c -m 644 osmo-pcu.pc '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/pkgconfig' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' + popd ~/osmo-ci/coverity/source-Osmocom + build_osmobts + pushd osmo-bts ~/osmo-ci/coverity/source-Osmocom/osmo-bts ~/osmo-ci/coverity/source-Osmocom + do_build --enable-sysmocom-bts --enable-trx + autoreconf --install --force libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac:21: installing './compile' configure.ac:23: installing './config.guess' configure.ac:23: installing './config.sub' configure.ac:9: installing './install-sh' configure.ac:9: installing './missing' src/common/Makefile.am: installing './depcomp' src/osmo-bts-sysmo/Makefile.am:25: warning: bin_PROGRAMS was already defined in condition TRUE, which includes condition ENABLE_SYSMOBTS_CALIB ... src/osmo-bts-sysmo/Makefile.am:10: ... 'bin_PROGRAMS' previously defined here src/osmo-bts-sysmo/Makefile.am:12: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:12: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. src/osmo-bts-sysmo/Makefile.am:27: warning: source file 'misc/sysmobts-calib.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:27: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:27: warning: source file 'misc/sysmobts-layer1.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:27: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_misc.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_nl.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_2050.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_vty.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_nl.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_temp.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_calib.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:42: warning: source file 'misc/sysmobts_util.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:42: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:42: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:42: but option 'subdir-objects' is disabled tests/agch/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/agch/Makefile.am:7: but option 'subdir-objects' is disabled tests/cipher/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/cipher/Makefile.am:7: but option 'subdir-objects' is disabled tests/misc/Makefile.am:9: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/misc/Makefile.am:9: but option 'subdir-objects' is disabled tests/paging/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/paging/Makefile.am:7: but option 'subdir-objects' is disabled tests/power/Makefile.am:8: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/power/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/utils.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/l1_if.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/oml.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/l1_transp_hw.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/tch.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/calib_file.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/calib_fixup.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/misc/sysmobts_par.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/eeprom.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/tx_power/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/tx_power/Makefile.am:7: but option 'subdir-objects' is disabled + ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom --enable-sysmocom-bts --enable-trx checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking whether make sets $(MAKE)... (cached) yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for pkg-config... /usr/bin/pkg-config checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.20... yes checking for ANSI C header files... (cached) yes checking for LIBOSMOCORE... yes checking for LIBOSMOVTY... yes checking for LIBOSMOTRAU... yes checking for LIBOSMOGSM... yes checking for LIBOSMOCTRL... yes checking for LIBOSMOABIS... yes checking for LIBOSMOCODEC... yes checking for LIBOSMOCODING... yes checking for ORTP... yes checking whether to enable support for sysmobts calibration tool... no checking whether to enable support for sysmoBTS L1/PHY support... yes checking for sysmocom/femtobts/superfemto.h... no configure: error: sysmocom/femtobts/superfemto.h can not be found in . [WARNING] Build command ./build_Osmocom.sh exited with code 1. Please verify that the build completed successfully. Emitted 1914 C/C++ compilation units (100%) successfully 1914 C/C++ compilation units (100%) are ready for analysis For more details, please look at: /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt Build step 'Execute shell' marked build as failure From alexander.huemer at xx.vu Sat Jan 20 22:44:06 2018 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Sat, 20 Jan 2018 23:44:06 +0100 Subject: osmo-trx with USRP1 - libusrp vs. UHD In-Reply-To: <20180118165154.GA25188@yade.chaostreff.at> References: <20171221185724.GA4464@yade.chaostreff.at> <20171221205512.GA4130@nataraja> <20180118001232.GA12278@yade.chaostreff.at> <1f2646bf-990e-62d2-3405-0dbcf3bb8277@sysmocom.de> <20180118165154.GA25188@yade.chaostreff.at> Message-ID: <20180120224406.GA24560@yade.chaostreff.at> On Thu, Jan 18, 2018 at 05:51:54PM +0100, Alexander Huemer wrote: > On Thu, Jan 18, 2018 at 10:57:52AM +0100, Max wrote: > > On 18.01.2018 01:12, Alexander Huemer wrote: > > > > > >After a trivial fix of osmo-trx with `configure --with-usrp1` it starts > > >without complaining. > > > > Might make sense to push this to gerrit to make it easier for people to > > follow your steps. > > I will. https://gerrit.osmocom.org/#/c/5938/ Kind regards, -Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From alexander.huemer at xx.vu Sun Jan 21 00:53:06 2018 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Sun, 21 Jan 2018 01:53:06 +0100 Subject: osmo-trx with USRP1 - libusrp vs. UHD In-Reply-To: <20180118135932.6mairoyi4xxkdwef@nataraja> References: <20171221185724.GA4464@yade.chaostreff.at> <20171221205512.GA4130@nataraja> <20180118001232.GA12278@yade.chaostreff.at> <20180118135932.6mairoyi4xxkdwef@nataraja> Message-ID: <20180121005306.GB24560@yade.chaostreff.at> On Thu, Jan 18, 2018 at 02:59:34PM +0100, Harald Welte wrote: > On Thu, Jan 18, 2018 at 01:12:32AM +0100, Alexander Huemer wrote: > > What I did so far is: > > * Extract libusrp from gnuradio 3.4.2, using git filter-branch to > > preserve history > > * Craft custom configure.ac > > * Update m4 macros > > * Small fixes here and there > > It might make sense to push the results into a git repository. Agreed. > I've created a libusrp.git on git.osmocom.org and gerrit. Thanks. > You should be able to push into it like any other osmocom project on > gerrit. Given that what I have locally is a git repository with history (from former gnuradio.git, after filter-branch) and the repository on git.osmocom.org is currently empty, I believe pushing into gerrit is not yet the right thing to do, since the remote repository needs a base content first. I can of course discard the history, but I don't think that is beneficial. What about first pushing directly into git and then continuing via gerrit? Kind regards, -Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Sun Jan 21 12:31:17 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 21 Jan 2018 13:31:17 +0100 Subject: osmo-trx with USRP1 - libusrp vs. UHD In-Reply-To: <20180121005306.GB24560@yade.chaostreff.at> References: <20171221185724.GA4464@yade.chaostreff.at> <20171221205512.GA4130@nataraja> <20180118001232.GA12278@yade.chaostreff.at> <20180118135932.6mairoyi4xxkdwef@nataraja> <20180121005306.GB24560@yade.chaostreff.at> Message-ID: <20180121123117.GO17056@nataraja> Hi Alexander, On Sun, Jan 21, 2018 at 01:53:06AM +0100, Alexander Huemer wrote: > I can of course discard the history, but I don't think > that is beneficial. No, let's keep history. > What about first pushing directly into git and then continuing via > gerrit? Yes, makes sense. As I don't seem to have a key of yours on record, and to avoid various other manual configuration steps: Is it possible for you to simply push it somewhere public, so I can fetch it from there, and use that as initial state for the osmocom.org repo? Thanks. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.huemer at xx.vu Sun Jan 21 13:18:29 2018 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Sun, 21 Jan 2018 14:18:29 +0100 Subject: osmo-trx with USRP1 - libusrp vs. UHD In-Reply-To: <20180121123117.GO17056@nataraja> References: <20171221185724.GA4464@yade.chaostreff.at> <20171221205512.GA4130@nataraja> <20180118001232.GA12278@yade.chaostreff.at> <20180118135932.6mairoyi4xxkdwef@nataraja> <20180121005306.GB24560@yade.chaostreff.at> <20180121123117.GO17056@nataraja> Message-ID: <20180121131829.GA11300@yade.chaostreff.at> On Sun, Jan 21, 2018 at 01:31:17PM +0100, Harald Welte wrote: > On Sun, Jan 21, 2018 at 01:53:06AM +0100, Alexander Huemer wrote: > > > I can of course discard the history, but I don't think > > that is beneficial. > > No, let's keep history. > > > What about first pushing directly into git and then continuing via > > gerrit? > > Yes, makes sense. As I don't seem to have a key of yours on record, and > to avoid various other manual configuration steps: Is it possible for > you to simply push it somewhere public, so I can fetch it from there, > and use that as initial state for the osmocom.org repo? Thanks. There should be an ssh key of mine in gerrit, though the other way around isn't a problem either. $ git clone git://yade.xx.vu/libusrp Kind regards, -Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From jenkins at lists.osmocom.org Sun Jan 21 16:12:40 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Sun, 21 Jan 2018 16:12:40 +0000 (GMT) Subject: =?UTF-8?Q?Build_failed_in_Jenkins:_Coverity-?= =?UTF-8?Q?Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1738?= In-Reply-To: <229539449.785.1516464759937.JavaMail.jenkins@jenkins.osmocom.org> References: <229539449.785.1516464759937.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <2088562292.798.1516551160421.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 2.12 MB...] CC osmo-bts-sysmo/sysmo_l1_fwd.o CXXLD libgprs.la CXXLD osmo-pcu CXXLD osmo-pcu-remote make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' Making all in examples make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' Making all in tests make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' CXX pcu_emu.o CXX test_pdp_activation.o CXX test_replay_gprs_attach.o CC openbsc_clone.o CXXLD emu/pcu_emu make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[1]: Nothing to be done for 'all-am'. make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' + make install Making install in include make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[2]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/pcu' /usr/bin/install -c -m 644 osmocom/pcu/pcuif_proto.h '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/pcu' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' Making install in src make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' /bin/bash ../libtool --mode=install /usr/bin/install -c osmo-pcu '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' libtool: install: /usr/bin/install -c osmo-pcu /home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin/osmo-pcu make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' Making install in examples make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[2]: 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-pcu.cfg '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' Making install in tests make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' 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-pcu/tests' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[2]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/pkgconfig' /usr/bin/install -c -m 644 osmo-pcu.pc '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/pkgconfig' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' + popd ~/osmo-ci/coverity/source-Osmocom + build_osmobts + pushd osmo-bts ~/osmo-ci/coverity/source-Osmocom/osmo-bts ~/osmo-ci/coverity/source-Osmocom + do_build --enable-sysmocom-bts --enable-trx + autoreconf --install --force libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac:21: installing './compile' configure.ac:23: installing './config.guess' configure.ac:23: installing './config.sub' configure.ac:9: installing './install-sh' configure.ac:9: installing './missing' src/common/Makefile.am: installing './depcomp' src/osmo-bts-sysmo/Makefile.am:25: warning: bin_PROGRAMS was already defined in condition TRUE, which includes condition ENABLE_SYSMOBTS_CALIB ... src/osmo-bts-sysmo/Makefile.am:10: ... 'bin_PROGRAMS' previously defined here src/osmo-bts-sysmo/Makefile.am:12: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:12: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. src/osmo-bts-sysmo/Makefile.am:27: warning: source file 'misc/sysmobts-calib.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:27: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:27: warning: source file 'misc/sysmobts-layer1.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:27: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_misc.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_nl.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_2050.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_vty.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_nl.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_temp.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_calib.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:42: warning: source file 'misc/sysmobts_util.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:42: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:42: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:42: but option 'subdir-objects' is disabled tests/agch/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/agch/Makefile.am:7: but option 'subdir-objects' is disabled tests/cipher/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/cipher/Makefile.am:7: but option 'subdir-objects' is disabled tests/misc/Makefile.am:9: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/misc/Makefile.am:9: but option 'subdir-objects' is disabled tests/paging/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/paging/Makefile.am:7: but option 'subdir-objects' is disabled tests/power/Makefile.am:8: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/power/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/utils.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/l1_if.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/oml.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/l1_transp_hw.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/tch.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/calib_file.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/calib_fixup.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/misc/sysmobts_par.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/eeprom.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/tx_power/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/tx_power/Makefile.am:7: but option 'subdir-objects' is disabled + ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom --enable-sysmocom-bts --enable-trx checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking whether make sets $(MAKE)... (cached) yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for pkg-config... /usr/bin/pkg-config checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.20... yes checking for ANSI C header files... (cached) yes checking for LIBOSMOCORE... yes checking for LIBOSMOVTY... yes checking for LIBOSMOTRAU... yes checking for LIBOSMOGSM... yes checking for LIBOSMOCTRL... yes checking for LIBOSMOABIS... yes checking for LIBOSMOCODEC... yes checking for LIBOSMOCODING... yes checking for ORTP... yes checking whether to enable support for sysmobts calibration tool... no checking whether to enable support for sysmoBTS L1/PHY support... yes checking for sysmocom/femtobts/superfemto.h... no configure: error: sysmocom/femtobts/superfemto.h can not be found in . [WARNING] Build command ./build_Osmocom.sh exited with code 1. Please verify that the build completed successfully. Emitted 1914 C/C++ compilation units (100%) successfully 1914 C/C++ compilation units (100%) are ready for analysis For more details, please look at: /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt Build step 'Execute shell' marked build as failure From laforge at gnumonks.org Sun Jan 21 17:44:16 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 21 Jan 2018 18:44:16 +0100 Subject: osmo-trx with USRP1 - libusrp vs. UHD In-Reply-To: <20180121131829.GA11300@yade.chaostreff.at> References: <20171221185724.GA4464@yade.chaostreff.at> <20171221205512.GA4130@nataraja> <20180118001232.GA12278@yade.chaostreff.at> <20180118135932.6mairoyi4xxkdwef@nataraja> <20180121005306.GB24560@yade.chaostreff.at> <20180121123117.GO17056@nataraja> <20180121131829.GA11300@yade.chaostreff.at> Message-ID: <20180121174416.GR17056@nataraja> Hi Alexander, libusrp is now at http://git.osmocom.org/libusrp/ and I've just merged the first patch via gerrit. The build verification job (https://jenkins.osmocom.org/jenkins/job/gerrit-libusrp/) and the regular 'master' build job (https://jenkins.osmocom.org/jenkins/job/master-libusrp/) are working as expected. In case one would want debian/ubuntu packages, one would have to add a debian/{rules,control,...} to it. Not sure if somebody wants to work on this. I created https://osmocom.org/issues/2849 to not forget about it. What should be done is to add an axis to osmo-trx to build both --with-usrp1 and without it, to make sure our osmo-trx gerrit + master builds are always building in both configurations. Any volunteers here? Maybe dr.blobb? I created https://osmocom.org/issues/2848 to not forget about it Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.huemer at xx.vu Sun Jan 21 18:04:18 2018 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Sun, 21 Jan 2018 19:04:18 +0100 Subject: osmo-trx with USRP1 - libusrp vs. UHD In-Reply-To: <20180121174416.GR17056@nataraja> References: <20171221185724.GA4464@yade.chaostreff.at> <20171221205512.GA4130@nataraja> <20180118001232.GA12278@yade.chaostreff.at> <20180118135932.6mairoyi4xxkdwef@nataraja> <20180121005306.GB24560@yade.chaostreff.at> <20180121123117.GO17056@nataraja> <20180121131829.GA11300@yade.chaostreff.at> <20180121174416.GR17056@nataraja> Message-ID: <20180121180418.GB27173@yade.chaostreff.at> On Sun, Jan 21, 2018 at 06:44:16PM +0100, Harald Welte wrote: > libusrp is now at http://git.osmocom.org/libusrp/ > and I've just merged the first patch via gerrit. The build verification > job (https://jenkins.osmocom.org/jenkins/job/gerrit-libusrp/) and the regular > 'master' build job (https://jenkins.osmocom.org/jenkins/job/master-libusrp/) > are working as expected. Nice, thanks. > In case one would want debian/ubuntu packages, one would have to add a > debian/{rules,control,...} to it. Not sure if somebody wants to work on > this. I created https://osmocom.org/issues/2849 to not forget about it. That would indeed be useful, though only if it can be proven that it is indeed possible to successfully run osmo-trx with it, which is not the case (yet). It would be great if someone besides me could give the combination USRP1 + libusrp + osmo-trx a try to see if it behaves similar to what I have reported. After all it is possible that something about my setup is weird and the same combination just works for other people. If it does not and the problem is reproducible, maybe somebody has a clue how to fix it. Also, what is now in git is not exactly perfect, please see the commit message of [1]. Somehow the right m4 macros are not adhered that the build environments of the firmware etc. depend on, so those parts don't build at the moment. Even though the currently broken parts are not required for osmo-trx that is not exactly pretty. Maybe somebody here on the list is in the mood to harvest those low hanging fruits? Kind regards, -Alex [1] http://git.osmocom.org/libusrp/commit/?id=ec6adccbbdda1a4614089aaf52f9e1bab75494e7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From ronemp at gmail.com Sun Jan 21 18:06:00 2018 From: ronemp at gmail.com (Ronan Empig) Date: Mon, 22 Jan 2018 02:06:00 +0800 Subject: OSMO-TRX with OSMO-NITB and OSMO-BTS error In-Reply-To: References: Message-ID: Hi Pau I will try the one in gerrit but just to let you know, I have not run the osmo-trx successfully even for a small while. Other people have run it and had some success early on though will encounter errors after some time. I am using an MSI notebook ang am wondering if it has something to do with it as it has AMD chip. Let me know if you can think of something about this. PS: Also, are you guys having the same version/changes in https://github.com/osmocom/osmo-trx ? I use install.sh in the link I sent so if you have updated the github then I will not need to update the files that will be automatically downloaded here. Please let me know. Thanks Ronan On Fri, Jan 19, 2018 at 7:14 PM, Pau Espin Pedrol wrote: > > Hi Ronan, > > I did some work to fix some stability problems I saw in osmo-bts-trx while > testing osmo-trx with limesdr. They are in gerrit [1] but haven't been > reviewed yet and jenkins validation failed due to issue being addressed in > [2] which in turn was not merged yet neither. > > However, while these patches clear a bit the mess in the logs and may fix > some eventual issues, the reality is that the problem is still there, and > as far as I understand they come from the limesuite layer. It seems it > fails to retrieve packets when asked from upper layers, which means the > clock is not updated and then osmo-bts-trx stops. I so far went down > through the layers to see the paths being used but got lost around the > point in which it reads from the fifo in limesuite. I couldn't find yet who > is populating that fifo from the device. > > As a reminder, the issue is being tracked in [3]. > > [1] https://gerrit.osmocom.org/#/c/5856 > [2] https://gerrit.osmocom.org/#/c/5818/ > [3] https://osmocom.org/issues/2723 > > > -- > - Pau Espin Pedrol http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Alt-Moabit 93 > * 10559 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Geschaeftsfuehrer / Managing Director: Harald Welte > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Sun Jan 21 20:16:42 2018 From: holger at freyther.de (Holger Freyther) Date: Sun, 21 Jan 2018 20:16:42 +0000 Subject: Approach to system testing for Osmocom stack In-Reply-To: <20180110233926.GE13147@nataraja> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> <20180110115513.GZ13147@nataraja> <20180110233926.GE13147@nataraja> Message-ID: <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de> > On 10. Jan 2018, at 23:39, Harald Welte wrote: > Hi! > If you reuse osmo-gsm-tester code for templates or the like, then it should > probably go there. If not, OsmocomBB seems like the more logical place. > Would be great if in that case it is some kind of python library/module > and a small 'main' wrapper around. This way the library could later be > used by whatever is starting both the network and the 'mobile's. small progress update. I will use "luasocket" to open a af_unix dgram socket from the testcase, a small json library, the template, log and maybe the process code from osmo-gsm-tester. I will give Python's asyncio a try as well. It has unix socket and subprocess support. Right now there a lot of loose ends but I should be able to make progress from here. holger From ivan.kluchnikov at fairwaves.co Sun Jan 21 20:47:18 2018 From: ivan.kluchnikov at fairwaves.co (Ivan Kluchnikov) Date: Sun, 21 Jan 2018 23:47:18 +0300 Subject: fairwaves HO patches In-Reply-To: <20180115214505.GC14510@my.box> References: <20180115214505.GC14510@my.box> Message-ID: Hi Neels, Sorry for silence, I need to find time to dig into HO code again. I will reply in the next few days. 2018-01-16 0:45 GMT+03:00 Neels Hofmeyr : > Hi Ivan, > > as I'm working towards load-based handover and incorporating your patches, > I > found that most of it is concerned with libmsc. In contrast, I am currently > working on osmo-bsc, in libbsc, and would like to ask your advice. > > Some parts of the patch aren't easy to understand for me, and I'd like to > make > sure that I am not dismissing parts of it as non-applicable to libbsc even > though they might be important. > > Since your patches were written, the code has changed. Now that we have the > separate osmo-bsc, we will need two layers of handover: intra-BSC and > inter-BSC. > > Intra-BSC is a handover between two cells that are serviced by the same > BSC, > and the higher layers (MSC) should not even notice that anything has > happened > -- MSC has asked the BSC to service a call by BSSAP Assignment, and the > BSC is > free to choose and change around the lchans it assigns to that. That is the > layer I'm currently dug into. > > Inter-BSC is a handover between cells that are serviced by two different > BSCs. > That seems to be the land your patch is improving. The MSC is involved and > so > is MNCC. > > (Both MSC and BSC levels will need their own DTAP cache, and they are by > definition completely independent -- MSC caches the DTAP coming from MNCC > during Inter-BSC handover, BSC caches DTAP from MSC during Intra-BSC > handover.) > > Since your patch is applied onto openbsc.git, where all of BSC and MSC are > still one osmo-nitb, I want to make sure that I sort your patch right. Do > some > of its semantics apply to osmo-bsc master, even if the code changed? > > The smaller patches are either already applied to osmo-bsc master, or I've > submitted them on gerrit just now: > > handover_decision: Add more log messages to get more information about HO > causes in logs > handover_decision: Fix condition for power budget handover attempt > handover_logic: set correct link to bts for subscriber_connection in case > of moving this connection to another bts > > Remaining are a small and *the* complex one: > > transaction: Add new function trans_find_by_lchan > handover: Implement proper handover procedure handling at any stage of > the call > > Here is the last one with inline questions, I hope they are not too > stupid; or > too long, it ended up being a lot to read. Thanks in advance for taking a > look: > > > > commit f7f4dc5e3b0dd61b8322946597147baef5d0464b > > Author: Ivan Kluchnikov > > Date: Wed Aug 23 18:09:50 2017 +0300 > > > > handover: Implement proper handover procedure handling at any stage > of the call > > > > Enhancements for each stage of handover procedure should be > implemented in order to support handover at any stage of the call. > > For these purposes new in_handover state and ho_queue for call > control messages was introduced for gsm_subscriber_connection. > > > > Stage 1: HO-Command is sent to MS > > gsm_subscriber_connection state should be changed to in_handover=1. > > In this state all transmission of signalling layer messages (except > RR messages needed for handover procedure) > > should be suspended until resuming is indicated. > > All call control messages for connection received from network side > should be buffered in ho_queue. > > All call control messages for connection received from MS side > should be ignored. > > Channel mode modification procedures should be also suspended. > > > > Stage 2: HO-Detect is received from MS > > Audio path should be switched on network side. > > > > Stage 3-1: HO-Complete is received from MS > > Resumption procedure after successful handover should be performed: > > - gsm_subscriber_connection state should be changed to normal > (in_handover=0). > > - all buffered call control messages (ho_queue) should be sent to > MS on new lchan. > > - suspended channel mode modification procedures should be > performed on new lchan. > > > > Stage 3-2: HO-Fail is received from MS > > Resumption procedure after failed handover should be performed: > > - gsm_subscriber_connection state should be changed to normal > (in_handover=0). > > - all buffered call control messages (ho_queue) should be sent to > MS on old lchan. > > - suspended channel mode modification procedures should be > performed on old lchan. > > > > Stage 3-3: T3103 expired: Handover has failed without HO-Complete or > HO-Fail > > Resumption procedure should not be performed in case of T3103 > expired: > > - gsm_subscriber_connection state should be changed to normal > (in_handover=0). > > - all buffered call control messages (ho_queue) should be cleaned > without sending them to MS. > > - suspended channel mode modification procedures should not be > performed. > > > > Change-Id: Icb9b5c35ef0c894af2ea762e539f1a9216447fb7 > > > > diff --git a/openbsc/include/openbsc/bsc_api.h > b/openbsc/include/openbsc/bsc_api.h > > index 3a931199..baacbeda 100644 > > --- a/openbsc/include/openbsc/bsc_api.h > > +++ b/openbsc/include/openbsc/bsc_api.h > > @@ -51,5 +51,6 @@ int gsm0808_cipher_mode(struct > gsm_subscriber_connection *conn, int cipher, > > int gsm0808_page(struct gsm_bts *bts, unsigned int page_group, > > unsigned int mi_len, uint8_t *mi, int chan_type); > > int gsm0808_clear(struct gsm_subscriber_connection *conn); > > +int gsm0808_ho_clear(struct gsm_subscriber_connection *conn); > > > > #endif > > diff --git a/openbsc/include/openbsc/gsm_data.h > b/openbsc/include/openbsc/gsm_data.h > > index ac573c49..542b2611 100644 > > --- a/openbsc/include/openbsc/gsm_data.h > > +++ b/openbsc/include/openbsc/gsm_data.h > > @@ -138,6 +138,8 @@ struct gsm_subscriber_connection { > > struct gsm_network *network; > > > > int in_release; > > + int in_handover; > > + struct llist_head ho_queue; > > struct gsm_lchan *lchan; /* BSC */ > > struct gsm_lchan *ho_lchan; /* BSC */ > > struct gsm_bts *bts; /* BSC */ > > diff --git a/openbsc/src/libbsc/bsc_api.c b/openbsc/src/libbsc/bsc_api.c > > index 8a4c85ff..71e82d03 100644 > > --- a/openbsc/src/libbsc/bsc_api.c > > +++ b/openbsc/src/libbsc/bsc_api.c > > @@ -253,11 +253,14 @@ struct gsm_subscriber_connection > *bsc_subscr_con_allocate(struct gsm_lchan *lcha > > conn->bts = lchan->ts->trx->bts; > > lchan->conn = conn; > > llist_add_tail(&conn->entry, &net->subscr_conns); > > + INIT_LLIST_HEAD(&conn->ho_queue); > > return conn; > > } > > > > void bsc_subscr_con_free(struct gsm_subscriber_connection *conn) > > { > > + struct msgb *msg; > > + > > if (!conn) > > return; > > > > @@ -283,6 +286,11 @@ void bsc_subscr_con_free(struct > gsm_subscriber_connection *conn) > > conn->secondary_lchan->conn = NULL; > > } > > > > + while (!llist_empty(&conn->ho_queue)) { > > + msg = msgb_dequeue(&conn->ho_queue); > > + msgb_free(msg); > > + } > > + > > llist_del(&conn->entry); > > talloc_free(conn); > > } > > @@ -747,6 +755,17 @@ int gsm0808_clear(struct gsm_subscriber_connection > *conn) > > return 0; > > } > > > > +/* > > + * Release handover RF Channel. > > + */ > > +int gsm0808_ho_clear(struct gsm_subscriber_connection *conn) > > +{ > > + if (conn->ho_lchan) > > + bsc_clear_handover(conn, 1); > > + > > + return 0; > > +} > > + > > static void send_sapi_reject(struct gsm_subscriber_connection *conn, > int link_id) > > { > > struct bsc_api *api; > > diff --git a/openbsc/src/libbsc/handover_logic.c > b/openbsc/src/libbsc/handover_logic.c > > index af4e8013..b7085c34 100644 > > --- a/openbsc/src/libbsc/handover_logic.c > > +++ b/openbsc/src/libbsc/handover_logic.c > > @@ -186,10 +186,17 @@ static void ho_T3103_cb(void *_ho) > > { > > struct bsc_handover *ho = _ho; > > struct gsm_network *net = ho->new_lchan->ts->trx->bts->network; > > + struct msgb *msg; > > > > DEBUGP(DHO, "HO T3103 expired\n"); > > rate_ctr_inc(&net->bsc_ctrs->ctr[BSC_CTR_HANDOVER_TIMEOUT]); > > > > + ho->new_lchan->conn->in_handover = 0; > > + while (!llist_empty(&ho->new_lchan->conn->ho_queue)) { > > + msg = msgb_dequeue(&ho->new_lchan->conn->ho_queue); > > + msgb_free(msg); > > + } > > + > > (Your ho_queue seems to live in libbsc, while most of the patch seems to be > concerned with libmsc. But nevermind, from jolly's patches I already have a > similar queue in osmo-bsc, and we'll probably use yours for libmsc.) > > > ho->new_lchan->conn->ho_lchan = NULL; > > ho->new_lchan->conn = NULL; > > lchan_release(ho->new_lchan, 0, RSL_REL_LOCAL_END); > > @@ -214,6 +221,8 @@ static int ho_chan_activ_ack(struct gsm_lchan > *new_lchan) > > > > gsm48_send_ho_cmd(ho->old_lchan, new_lchan, 0, ho->ho_ref); > > > > + new_lchan->conn->in_handover = 1; > > + > > In current osmo-bsc master, we already set conn->ho_lchan before sending > out > the chan activation request. I'd actually assume setting the flag only now, > after the activ ack, is a bit too late? > > > /* start T3103. We can continue either with T3103 expiration, > > * 04.08 HANDOVER COMPLETE or 04.08 HANDOVER FAIL */ > > ho->T3103.cb = ho_T3103_cb; > > @@ -221,7 +230,8 @@ static int ho_chan_activ_ack(struct gsm_lchan > *new_lchan) > > osmo_timer_schedule(&ho->T3103, 10, 0); > > > > /* create a RTP connection */ > > - if (is_ipaccess_bts(new_lchan->ts->trx->bts)) > > + if (is_ipaccess_bts(new_lchan->ts->trx->bts) && > > + new_lchan->tch_mode != > GSM48_CMODE_SIGN) > > rsl_ipacc_crcx(new_lchan); > > Please explain ... what case / behavior is this fixing? > Do we ever see CMODE_SIGN handovers? > Would we also need to check for GSM48_CMODE_DATA_*? > > > @@ -273,6 +283,11 @@ static int ho_gsm48_ho_compl(struct gsm_lchan > *new_lchan) > > if (is_e1_bts(new_lchan->conn->bts)) > > switch_trau_mux(ho->old_lchan, new_lchan); > > > > + if (ho->old_lchan->conn->mncc_rtp_connect_pending) { > > + new_lchan->abis_ip.connect_port = ho->old_lchan->abis_ip. > connect_port; > > + new_lchan->abis_ip.connect_ip = ho->old_lchan->abis_ip. > connect_ip; > > + } > > + > > So if an RTP connect to MNCC is pending, we copy the old lchan's RTP port > and > IP? Which is this, the MNCC / call router side IP and port? > Why not set this at the initiation of the HO already? > > > > @@ -295,27 +310,9 @@ static int ho_gsm48_ho_compl(struct gsm_lchan > *new_lchan) > > static int ho_gsm48_ho_fail(struct gsm_lchan *old_lchan) > > { > > struct gsm_network *net = old_lchan->ts->trx->bts->network; > > - struct bsc_handover *ho; > > - struct gsm_lchan *new_lchan; > > - > > - ho = bsc_ho_by_old_lchan(old_lchan); > > - if (!ho) { > > - LOGP(DHO, LOGL_ERROR, "unable to find HO record\n"); > > - return -ENODEV; > > - } > > > > rate_ctr_inc(&net->bsc_ctrs->ctr[BSC_CTR_HANDOVER_FAILED]); > > > > - new_lchan = ho->new_lchan; > > - > > - /* release the channel and forget about it */ > > - ho->new_lchan->conn->ho_lchan = NULL; > > - ho->new_lchan->conn = NULL; > > - handover_free(ho); > > - > > - lchan_release(new_lchan, 0, RSL_REL_LOCAL_END); > > - > > - > > I'm puzzled by this removal. No actions during ho_fail? Is this really > intended, or just some rebase artifact? > > > return 0; > > } > > > > diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_ > 08.c > > index e5402d0a..84338d72 100644 > > --- a/openbsc/src/libmsc/gsm_04_08.c > > +++ b/openbsc/src/libmsc/gsm_04_08.c > > @@ -147,6 +147,15 @@ static int gsm48_conn_sendmsg(struct msgb *msg, > struct gsm_subscriber_connection > > sign_link->trx->bts->nr, > > sign_link->trx->nr, msg->lchan->ts->nr, > > gh->proto_discr, gh->msg_type); > > + > > + if (conn->in_handover) { > > + msgb_enqueue(&conn->ho_queue, msg); > > + DEBUGP(DCC, "(bts %d trx %d ts %d) Suspend message > sending to MS, " > > + "active HO procedure.\n", > > + sign_link->trx->bts->nr, > > + sign_link->trx->nr, msg->lchan->ts->nr); > > + return 0; > > + } > > (here DTAP handled in libmsc ends up in the ho_queue that otherwise seems > to > live in libbsc ... as I said above this queue will probably move to libmsc > altogether to become part of osmo-msc master.) > > > } > > > > return gsm0808_submit_dtap(conn, msg, 0, 0); > > @@ -1749,11 +1758,8 @@ static int switch_for_handover(struct gsm_lchan > *old_lchan, > > struct rtp_socket *old_rs, *new_rs, *other_rs; > > > > /* Ask the new socket to send to the already known port. */ > > - if (new_lchan->conn->mncc_rtp_bridge) { > > - LOGP(DHO, LOGL_DEBUG, "Forwarding RTP\n"); > > - rsl_ipacc_mdcx(new_lchan, > > - old_lchan->abis_ip.connect_ip, > > - old_lchan->abis_ip.connect_port, > 0); > > + if (new_lchan->ts->trx->bts->network->mncc_state) { > > + /* Audio path should be switched after receiving ho detect > message.*/ > > return 0; > > } > > I notice that in the current head, the entire switch_for_handover() has > been > dropped; it was doing libbsc lchan stuff from within libmsc. Hence we must > have > added similar logic in osmo-bsc.git and completely dropped this. > > I think the commit re-implementing handover in osmo-bsc is > http://git.osmocom.org/osmo-bsc/commit/?id=39c609b7c924524172ad311bdf89f9 > 2b7ccf175a > > It appears that lchan->abis_ip.connect_ip and connect_port aren't used at > all > in osmo-bsc master, but are still present in the struct. I'll ask others > about > that. > > In any case, the code base has changed substantially, and this patch hunk > no > longer applies at all. > > Am I interpreting this hunk correctly: it moves the ipacc_mdcx to tell the > new > lchan about its RTP peer to a later stage? > > In current osmo-bsc master, it seems that this ipacc_mdcx happens as soon > as > the ipacc_crcx is complete, seen in osmo-bsc/src/osmo-bsc/osmo_bsc_audio.c > in > handle_abisip_signal(), always using the IP:port the MSC sent us. > > > > > > @@ -1821,8 +1827,10 @@ static int handle_abisip_signal(unsigned int > subsys, unsigned int signal, > > if (subsys != SS_ABISIP) > > return 0; > > > > + net = lchan->ts->trx->bts->network; > > + > > /* RTP bridge handling */ > > - if (lchan->conn && lchan->conn->mncc_rtp_bridge) > > + if (lchan->conn && net->mncc_state) > > return tch_rtp_signal(lchan, signal); > > What are the semantics here? It seems odd to move from a check of a > conn-specific state (conn->mncc_rtp_bridge) to a check of a global value > (net->mncc_state). > > In any case, this is MNCC related and should not impact Intra-BSC handover, > right? > > > > > /* in case we use direct BTS-to-BTS RTP */ > > @@ -1851,7 +1859,6 @@ static int handle_abisip_signal(unsigned int > subsys, unsigned int signal, > > > > /* check if any transactions on this lchan still have > > * a tch_recv_mncc request pending */ > > - net = lchan->ts->trx->bts->network; > > llist_for_each_entry(trans, &net->trans_list, entry) { > > if (trans->conn && trans->conn->lchan == lchan && > trans->tch_recv) { > > DEBUGP(DCC, "pending tch_recv_mncc > request\n"); > > @@ -2017,6 +2024,13 @@ static int tch_recv_mncc(struct gsm_network *net, > uint32_t callref, int enable) > > switch (bts->type) { > > case GSM_BTS_TYPE_NANOBTS: > > case GSM_BTS_TYPE_OSMO_SYSMO: > > if (ipacc_rtp_direct) { > > LOGP(DCC, LOGL_ERROR, "Error: RTP proxy is > disabled\n"); > > return -EINVAL; > > } > > + /* RTP bridge handling */ > > + if (lchan->conn && net->mncc_state) { > > + return 0; > > + } > > If we have a conn and using external MNCC, don't continue at all? I'm not > following, would be nice if the comment explained why we need to drop out > here. > > (added some more code context manually) > > > /* In case, we don't have a RTP socket to the BTS yet, the > BTS > > * will not be connected to our RTP proxy and the socket > will > > * not be assigned to the application interface. This method > > * will be called again, once the audio socket is created > and > > * connected. */ > > if (!lchan->abis_ip.rtp_socket) { > > DEBUGP(DCC, "queue tch_recv_mncc request (%d)\n", > enable); > > return 0; > > } > > if (enable) { > > /* connect the TCH's to our RTP proxy */ > > rc = rsl_ipacc_mdcx_to_rtpsock(lchan); > > if (rc < 0) > > return rc; > > /* assign socket to application interface */ > > rtp_socket_upstream(lchan->abis_ip.rtp_socket, > > net, callref); > > } else > > rtp_socket_upstream(lchan->abis_ip.rtp_socket, > > net, 0); > > break; > > > > > > > @@ -3325,6 +3339,41 @@ static void mncc_recv_rtp_err(struct gsm_network > *net, uint32_t callref, int cmd > > return mncc_recv_rtp(net, callref, cmd, 0, 0, 0, 0); > > } > > > > +static void mncc_recv_rtp_modify(struct gsm_lchan *lchan, uint32_t > callref) > > This is to tell the call router that the payload type has changed, right? > I've > asked in the redmine about whether/how we'd convey an RTP payload change > to the > MNCC in case of an Intra-BSC handover... > > https://osmocom.org/issues/1606#note-45 > > > +{ > > + int msg_type; > > + struct gsm_network *net = lchan->ts->trx->bts->network; > > + > > + LOGP(DMNCC, LOGL_NOTICE, "%s sending pending RTP modify ind.\n", > > + gsm_lchan_name(lchan)); > > + > > + switch (lchan->abis_ip.rtp_payload) { > > + case RTP_PT_GSM_FULL: > > + msg_type = GSM_TCHF_FRAME; > > + break; > > + case RTP_PT_GSM_EFR: > > + msg_type = GSM_TCHF_FRAME_EFR; > > + break; > > + case RTP_PT_GSM_HALF: > > + msg_type = GSM_TCHH_FRAME; > > + break; > > + case RTP_PT_AMR: > > + msg_type = GSM_TCH_FRAME_AMR; > > + break; > > + default: > > + LOGP(DMNCC, LOGL_ERROR, "%s unknown payload type %d\n", > > + gsm_lchan_name(lchan), lchan->abis_ip.rtp_payload); > > + msg_type = 0; > > + break; > > + } > > + > > + mncc_recv_rtp(net, callref, MNCC_RTP_MODIFY, > > + lchan->abis_ip.bound_ip, > > + lchan->abis_ip.bound_port, > > + lchan->abis_ip.rtp_payload, > > + msg_type); > > +} > > + > > static int tch_rtp_create(struct gsm_network *net, uint32_t callref) > > { > > struct gsm_bts *bts; > > @@ -3374,6 +3423,9 @@ static int tch_rtp_create(struct gsm_network *net, > uint32_t callref) > > LOGP(DMNCC, LOGL_DEBUG, "RTP create: codec=%s, > chan_type=%s\n", > > get_value_string(gsm48_chan_mode_names, m), > > get_value_string(gsm_chan_t_names, lchan->type)); > > + if (trans->conn->in_handover) { > > + return 0; > > + } > > Am I reading right: if we're doing handover, the MSC shouldn't sent another > BSSAP Assignment to the BSC; instead, the BSC level figures out another > lchan > and done ... ? > > > return gsm0808_assign_req(trans->conn, m, > > lchan->type != GSM_LCHAN_TCH_H); > > } > > @@ -3420,23 +3472,21 @@ static int tch_rtp_connect(struct gsm_network > *net, void *arg) > > * same package! > > */ > > trans->conn->mncc_rtp_connect_pending = 1; > > + if (trans->conn->in_handover) { > > + lchan->abis_ip.connect_port = rtp->port; > > + lchan->abis_ip.connect_ip = rtp->ip; > > + return 0; > > + } > > return rsl_ipacc_mdcx(lchan, rtp->ip, rtp->port, 0); > > We're not telling the BTS about the call router's IP:port anymore? > Please explain... > > > } > > > > static int tch_rtp_signal(struct gsm_lchan *lchan, int signal) > > { > > struct gsm_network *net; > > - struct gsm_trans *tmp, *trans = NULL; > > + struct gsm_trans *trans; > > > > net = lchan->ts->trx->bts->network; > > - llist_for_each_entry(tmp, &net->trans_list, entry) { > > - if (!tmp->conn) > > - continue; > > - if (tmp->conn->lchan != lchan && tmp->conn->ho_lchan != > lchan) > > - continue; > > - trans = tmp; > > - break; > > - } > > + trans = trans_find_by_lchan(lchan); > > > > if (!trans) { > > LOGP(DMNCC, LOGL_ERROR, "%s IPA abis signal but no > transaction.\n", > > @@ -3459,7 +3509,7 @@ static int tch_rtp_signal(struct gsm_lchan *lchan, > int signal) > > maybe_switch_for_handover(lchan); > > break; > > case S_ABISIP_MDCX_ACK: > > - if (lchan->conn->mncc_rtp_connect_pending) { > > + if (lchan->conn->mncc_rtp_connect_pending && > !lchan->conn->in_handover) { > > if we're in handover, we don't need to tell MNCC that RTP got connected, > because that already happened when the call got established initially? > So mncc_rtp_connect_pending has a second meaning during handover? > > > lchan->conn->mncc_rtp_connect_pending = 0; > > LOGP(DMNCC, LOGL_NOTICE, "%s sending pending RTP > connect ind.\n", > > gsm_lchan_name(lchan)); > > mncc_recv_rtp_sock(net, trans, MNCC_RTP_CONNECT); > > } > > break; > > > @@ -3471,6 +3521,134 @@ static int tch_rtp_signal(struct gsm_lchan > *lchan, int signal) > > return 0; > > } > > > > +static void ho_queue_clean(struct gsm_subscriber_connection *conn) > > +{ > > + struct msgb *msg; > > + while (!llist_empty(&conn->ho_queue)) { > > + msg = msgb_dequeue(&conn->ho_queue); > > + msgb_free(msg); > > + } > > +} > > + > > +static void ho_resumption(struct gsm_lchan *lchan, struct gsm_trans > *trans) > > +{ > > + struct msgb *msg; > > + enum gsm48_chan_mode m; > > + > > + while (!llist_empty(&lchan->conn->ho_queue)) { > > + msg = msgb_dequeue(&lchan->conn->ho_queue); > > + gsm48_conn_sendmsg(msg, lchan->conn, trans); > > + } > > + > > + if (trans->conn->mncc_rtp_create_pending && > > + lchan->tch_mode == > GSM48_CMODE_SIGN) { > > + m = mncc_codec_for_mode(lchan->type); > > + gsm0808_assign_req(lchan->conn, m, lchan->type != > GSM_LCHAN_TCH_H); > > Wait, now we *do* send a BSSAP Assignment after all? > (excuse if I'm being noob, I'm still finding my way through handover in > general) > > shouldn't we rather dequeue the cached DTAP after this instead of before? > > > + } > > + > > + if (trans->conn->mncc_rtp_connect_pending) { > > + rsl_ipacc_mdcx(lchan, lchan->abis_ip.connect_ip, > lchan->abis_ip.connect_port, 0); > > + } > > +} > > + > > +static int ho_complete(struct gsm_lchan *new_lchan) > > +{ > > + struct gsm_trans *trans; > > + > > + new_lchan->conn->in_handover = 0; > > + trans = trans_find_by_lchan(new_lchan); > > + if (!trans) { > > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but no transaction > for new_lchan.\n", > > + gsm_lchan_name(new_lchan)); > > + ho_queue_clean(new_lchan->conn); > > + return 0; > > + } > > + > > + ho_resumption(new_lchan, trans); > > + return 0; > > +} > > + > > +static int ho_fail(struct gsm_lchan *old_lchan) > > +{ > > + struct gsm_trans *trans; > > + > > + old_lchan->conn->in_handover = 0; > > + trans = trans_find_by_lchan(old_lchan); > > + if (trans) > > + ho_resumption(old_lchan, trans); > > + else { > > + LOGP(DHO, LOGL_ERROR, "%s HO fail, but no transaction for > old_lchan.\n", > > + gsm_lchan_name(old_lchan)); > > + ho_queue_clean(old_lchan->conn); > > + } > > + > > + gsm0808_ho_clear(old_lchan->conn); > > + return 0; > > +} > > + > > +static int ho_detect(struct gsm_lchan *new_lchan) > > +{ > > + struct gsm_trans *trans; > > + struct gsm_lchan *old_lchan; > > + > > + trans = trans_find_by_lchan(new_lchan); > > + > > + if (!trans) { > > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but no transaction > for new_lchan" > > + " with enabled tch_recv.\n", > > + gsm_lchan_name(new_lchan)); > > + return 0; > > + } > > + > > + if (!new_lchan->conn->mncc_rtp_bridge) { > > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but connection not > in mncc_rtp_bridge mode.\n", > > + gsm_lchan_name(new_lchan)); > > + return 0; > > + } > > + > > + old_lchan = bsc_handover_pending(new_lchan); > > + if (!old_lchan) { > > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but no old_lchan > for handover.\n", > > + gsm_lchan_name(new_lchan)); > > + return 0; > > + } > > + > > + LOGP(DHO, LOGL_DEBUG, "HO detected, forwarding RTP\n"); > > + rsl_ipacc_mdcx(new_lchan, > > + old_lchan->abis_ip.connect_ip, > > + old_lchan->abis_ip.connect_port, 0); > > + > > + mncc_recv_rtp_modify(new_lchan, trans->callref); > > + > > + return 0; > > +} > > + > > +/* some other part of the code sends us a signal */ > > +static int handle_lchan_signal(unsigned int subsys, unsigned int signal, > > + void *handler_data, void *signal_data) > > +{ > > + struct lchan_signal_data *lchan_data; > > + struct gsm_lchan *lchan; > > + > > + lchan_data = signal_data; > > + switch (subsys) { > > + case SS_LCHAN: > > + lchan = lchan_data->lchan; > > + if (!lchan->conn) > > + return 0; > > + switch (signal) { > > + case S_LCHAN_HANDOVER_DETECT: > > + return ho_detect(lchan); > > + case S_LCHAN_HANDOVER_COMPL: > > + return ho_complete(lchan); > > + case S_LCHAN_HANDOVER_FAIL: > > + return ho_fail(lchan); > > + } > > + break; > > + } > > + > > + return 0; > > +} > > > > static struct downstate { > > uint32_t states; > > @@ -3853,6 +4031,11 @@ static int gsm0408_rcv_cc(struct > gsm_subscriber_connection *conn, struct msgb *m > > gsm48_cc_msg_name(msg_type), trans?(trans->cc.state):0, > > gsm48_cc_state_name(trans?(trans->cc.state):0)); > > > > + if (conn->in_handover) { > > + DEBUGP(DCC, "Message unhandled, handover procedure.\n"); > > + return 0; > > + } > > + > > If in handover, drop all CC on the floor? > > How about a call release, i.e. I hang up while I'm coincidentally being > handovered? > > > /* Create transaction */ > > if (!trans) { > > DEBUGP(DCC, "Unknown transaction ID %x, " > > > > > > > > > Thanks again! > > ~N > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pespin at sysmocom.de Sun Jan 21 23:02:28 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 22 Jan 2018 00:02:28 +0100 Subject: OSMO-TRX with OSMO-NITB and OSMO-BTS error In-Reply-To: References: Message-ID: <655c3954-2208-be86-7b4a-c57326ae4ac0@sysmocom.de> Hi Ronan, On 21/01/18 19:06, Ronan Empig wrote: > I am using an MSI notebook ang am wondering if it has something to do > with it as it has AMD chip. I don't think it's going to have any relation with that fact. By the way, I had the same issues whiles running it being detected as a usb3 device as well as for the usb2 case, so that specific factor doesn't seem to be important regarding the clock issues I am seeing. > Also, are you guys having the same version/changes in > https://github.com/osmocom/osmo-trx? ? ? As far as I know, that github repo is a mirror from the official one: https://git.osmocom.org/osmo-trx/ I guess it becomes synced every few hours or so. The patches I did a few days ago in osmo-trx have been already merged and are also already available in the osmo-trx hithub mirror you described. However, as I already stated, the patches may help a bit with some stability issues but won't definitely solve the clocking issues appearing most of the time. -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From rafael at riseup.net Mon Jan 22 01:53:34 2018 From: rafael at riseup.net (Rafael Diniz) Date: Sun, 21 Jan 2018 23:53:34 -0200 Subject: Help migrating away from NITB Message-ID: <3b6d8f24-8207-67aa-c6a0-ea52de13074d@riseup.net> Hi all, I'm starting to get used to the new stack with split components, and all seems to be working fine, SMS and USSD are working, but no voice calls yet. ps ax: 7611 pts/4 S+ 0:00 osmo-mgw -c osmo-mgw-for-bsc.cfg 7653 pts/6 S+ 0:00 osmo-bsc -c osmo-bsc.cfg 7705 pts/3 S+ 0:00 osmo-msc -c osmo-msc.cfg 7760 pts/8 S+ 0:00 osmo-mgw -c osmo-mgw-for-msc.cfg 7785 pts/0 Sl+ 1:59 osmo-trx 7803 pts/7 S+ 0:08 osmo-bts-trx -c osmo-bts.cfg 17288 pts/1 S+ 0:00 osmo-hlr -l hlr.db -c osmo-hlr.cfg 17299 pts/5 S+ 0:02 osmo-stp -c osmo-stp.cfg Config files are deeply based in the nitb.tar in the wiki. I read in an email from December that osmo-bsc_mgcp is still required. Is that the case? Thanks, Rafael Diniz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From pespin at sysmocom.de Mon Jan 22 09:56:44 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 22 Jan 2018 10:56:44 +0100 Subject: Help migrating away from NITB In-Reply-To: <3b6d8f24-8207-67aa-c6a0-ea52de13074d@riseup.net> References: <3b6d8f24-8207-67aa-c6a0-ea52de13074d@riseup.net> Message-ID: Hi Rafael, Yes you still need osmo-msc<->osmo-bsc_mgcp and osmo-bsc<->osmo-mgw. Related task is [1]. As far as I know, the work to use osmo-mgw with osmo-msc is mostly done and available in [2], but it has not been yet merged because some automatic testing bits are still missing. [1] https://osmocom.org/issues/2605 [2] https://gerrit.osmocom.org/#/c/4980/ -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From jenkins at lists.osmocom.org Mon Jan 22 09:59:18 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Mon, 22 Jan 2018 09:59:18 +0000 (GMT) Subject: =?UTF-8?Q?Build_failed_in_Jenkins:_Coverity-?= =?UTF-8?Q?Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1739?= In-Reply-To: <2088562292.798.1516551160421.JavaMail.jenkins@jenkins.osmocom.org> References: <2088562292.798.1516551160421.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <2095591179.836.1516615158362.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 2.12 MB...] CC osmo-bts-sysmo/sysmo_l1_fwd.o CXXLD libgprs.la CXXLD osmo-pcu CXXLD osmo-pcu-remote make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' Making all in examples make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' Making all in tests make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' CXX pcu_emu.o CC openbsc_clone.o CXX test_replay_gprs_attach.o CXX test_pdp_activation.o CXXLD emu/pcu_emu make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[1]: Nothing to be done for 'all-am'. make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' + make install Making install in include make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[2]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/pcu' /usr/bin/install -c -m 644 osmocom/pcu/pcuif_proto.h '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/pcu' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' Making install in src make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' /bin/bash ../libtool --mode=install /usr/bin/install -c osmo-pcu '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' libtool: install: /usr/bin/install -c osmo-pcu /home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin/osmo-pcu make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' Making install in examples make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[2]: 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-pcu.cfg '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' Making install in tests make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' 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-pcu/tests' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[2]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/pkgconfig' /usr/bin/install -c -m 644 osmo-pcu.pc '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/pkgconfig' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' + popd ~/osmo-ci/coverity/source-Osmocom + build_osmobts + pushd osmo-bts ~/osmo-ci/coverity/source-Osmocom/osmo-bts ~/osmo-ci/coverity/source-Osmocom + do_build --enable-sysmocom-bts --enable-trx + autoreconf --install --force libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac:21: installing './compile' configure.ac:23: installing './config.guess' configure.ac:23: installing './config.sub' configure.ac:9: installing './install-sh' configure.ac:9: installing './missing' src/common/Makefile.am: installing './depcomp' src/osmo-bts-sysmo/Makefile.am:25: warning: bin_PROGRAMS was already defined in condition TRUE, which includes condition ENABLE_SYSMOBTS_CALIB ... src/osmo-bts-sysmo/Makefile.am:10: ... 'bin_PROGRAMS' previously defined here src/osmo-bts-sysmo/Makefile.am:12: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:12: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. src/osmo-bts-sysmo/Makefile.am:27: warning: source file 'misc/sysmobts-calib.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:27: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:27: warning: source file 'misc/sysmobts-layer1.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:27: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_misc.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_nl.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_2050.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_vty.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_nl.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_temp.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_calib.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:42: warning: source file 'misc/sysmobts_util.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:42: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:42: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:42: but option 'subdir-objects' is disabled tests/agch/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/agch/Makefile.am:7: but option 'subdir-objects' is disabled tests/cipher/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/cipher/Makefile.am:7: but option 'subdir-objects' is disabled tests/misc/Makefile.am:9: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/misc/Makefile.am:9: but option 'subdir-objects' is disabled tests/paging/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/paging/Makefile.am:7: but option 'subdir-objects' is disabled tests/power/Makefile.am:8: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/power/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/utils.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/l1_if.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/oml.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/l1_transp_hw.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/tch.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/calib_file.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/calib_fixup.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/misc/sysmobts_par.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/eeprom.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/tx_power/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/tx_power/Makefile.am:7: but option 'subdir-objects' is disabled + ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom --enable-sysmocom-bts --enable-trx checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking whether make sets $(MAKE)... (cached) yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for pkg-config... /usr/bin/pkg-config checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.20... yes checking for ANSI C header files... (cached) yes checking for LIBOSMOCORE... yes checking for LIBOSMOVTY... yes checking for LIBOSMOTRAU... yes checking for LIBOSMOGSM... yes checking for LIBOSMOCTRL... yes checking for LIBOSMOABIS... yes checking for LIBOSMOCODEC... yes checking for LIBOSMOCODING... yes checking for ORTP... yes checking whether to enable support for sysmobts calibration tool... no checking whether to enable support for sysmoBTS L1/PHY support... yes checking for sysmocom/femtobts/superfemto.h... no configure: error: sysmocom/femtobts/superfemto.h can not be found in [WARNING] Build command ./build_Osmocom.sh exited with code 1. Please verify that the build completed successfully. Emitted 1914 C/C++ compilation units (100%) successfully 1914 C/C++ compilation units (100%) are ready for analysis For more details, please look at: /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt Build step 'Execute shell' marked build as failure From jenkins at lists.osmocom.org Mon Jan 22 11:10:35 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Mon, 22 Jan 2018 11:10:35 +0000 (GMT) Subject: =?UTF-8?Q?Jenkins_build_is_back_to_normal_:_Cove?= =?UTF-8?Q?rity-Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1740?= In-Reply-To: <2095591179.836.1516615158362.JavaMail.jenkins@jenkins.osmocom.org> References: <2095591179.836.1516615158362.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <21483016.841.1516619435697.JavaMail.jenkins@jenkins.osmocom.org> See From djks74 at gmail.com Mon Jan 22 11:58:58 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Mon, 22 Jan 2018 11:58:58 +0000 Subject: testing osmo-bsc osmo-hlr osmo-msc In-Reply-To: <20180115122955.GE2776@my.box> References: <20180115122955.GE2776@my.box> Message-ID: Dear Neels, seems all good on my setup, I did success with osmo-sip-connector and get bridge with osmo-msc, I can make a call and destination got ring but there is no voice on both side. here is my setup: osmo-bsc -c ~/osmo/osmo-bsc.cfg osmo-hlr -l hlr.db -c ~/osmo/osmo-hlr.cfg osmo-stp -c ~/osmo/osmo-stp.cfg osmo-mgw -c ~/osmo/osmo-mgw-for-msc.cfg osmo-mgw -c ~/osmo/osmo-mgw-for-bsc.cfg osmo-msc -c ~/osmo/osmo-msc.cfg -M /tmp/bsc_mncc osmo-bts-trx -c ~/osmo/osmo-bts.cfg osmo-sip-connector -c ./osmo/osmo-sip-connector.cfg osmo-trx -c 1 -s 4 -e -l INFO Does osmo-msc still bugs? btw, Im using old osmo-trx (before 0.20) its stable for old one with limesdr. since newest osmo-trx with limesdr not stable. Thanks, DUO On Mon, Jan 15, 2018 at 12:29 PM, Neels Hofmeyr wrote: > On Sun, Jan 14, 2018 at 03:15:59PM +0000, Sandi Suhendro wrote: > > now the auto create subscriber not working which is Im looking and its > very > > good and nice improovement. > > To reiterate, in the old osmo-nitb, we used to have > 'subscriber-create-on-demand', which the new osmo-hlr does not support. > It's > not an improvement, it's dropping a feature on the floor. > > > does my setting for the osmocom stacks is right with this? : > > > > osmo-bsc -c ~/osmo/osmo-bsc.cfg > > osmo-hlr -l hlr.db -c ~/osmo/osmo-hlr.cfg > > osmo-stp -c ~/osmo/osmo-stp.cfg > > osmo-mgw -c ~/osmo/osmo-mgw-for-msc.cfg > > osmo-mgw -c ~/osmo/osmo-mgw-for-bsc.cfg > > osmo-msc -c ~/osmo/osmo-msc.cfg > > > > DId I miss something? Im sure I miss something. :-) > > looks good as long as you also have a BTS. > Of course just the invocation commands don't convey anything about the > settings. > And of course don't make us read your config unless you have an actual > problem. > > > and how to connect osmo-msc with asterisk? > > The short answer is: use osmo-sip-connector. The long answer should be > somewhere on the wiki, but personally I'm not familiar with that. Maybe > someone > else has a pointer? > > ~N > -- Best Regards, DUO -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael at riseup.net Tue Jan 23 12:11:28 2018 From: rafael at riseup.net (Rafael Diniz) Date: Tue, 23 Jan 2018 10:11:28 -0200 Subject: Help migrating away from NITB In-Reply-To: References: <3b6d8f24-8207-67aa-c6a0-ea52de13074d@riseup.net> Message-ID: Thanks Pau. I'll tried briefly the MSC in [2]. Should I add some lines in config? Just compiling and running MSC from [2] - not lucky yet. I could read some new messages complaining about codec, but I will investigate further. Thanks! Rafael Diniz On 01/22/2018 07:56 AM, Pau Espin Pedrol wrote: > Hi Rafael, > > Yes you still need osmo-msc<->osmo-bsc_mgcp and osmo-bsc<->osmo-mgw. > > Related task is [1]. > > As far as I know, the work to use osmo-mgw with osmo-msc is mostly done > and available in [2], but it has not been yet merged because some > automatic testing bits are still missing. > > [1] https://osmocom.org/issues/2605 > [2] https://gerrit.osmocom.org/#/c/4980/ > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From holger at freyther.de Sun Jan 28 22:41:33 2018 From: holger at freyther.de (Holger Freyther) Date: Sun, 28 Jan 2018 22:41:33 +0000 Subject: Approach to system testing for Osmocom stack In-Reply-To: <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> <20180110115513.GZ13147@nataraja> <20180110233926.GE13147@nataraja> <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de> Message-ID: <6A55B7E0-9522-4632-82DB-26829346BCD2@freyther.de> > On 21. Jan 2018, at 20:16, Holger Freyther wrote: > Hey! some more progress. I had to learn a bit about asyncio and in the end will be forced to use a stream socket[1] and will end up using the IPA and add a reservation for JSON events. I will probably push my unfinished code to gerrit but it is too early to review. holger > small progress update. I will use "luasocket" to open a af_unix dgram socket > from the testcase, a small json library, the template, log and maybe the > process code from osmo-gsm-tester. I will give Python's asyncio a try as > well. It has unix socket and subprocess support. > > Right now there a lot of loose ends but I should be able to make progress > from here. > > holger [1] There is a asyncio.start_unix_server to create a AF_UNIX socket but only with SOCK_STREAM. The API has (thought not documented) a way to pass a file descriptor but when passing a socket they will check if it is a stream socket and if not fail. This is quite annoying in some ways.. First I want reliable delivery (excludes UDP) and have messages/datagrams (don't want to do an IPA style header..). Second thanks to the BSD socket API the accept will behave exactly the same for TCP, SCTP, UNIX, Bluetooth, etc and the python API allows to pass a socket factory. From laforge at gnumonks.org Mon Jan 29 10:50:17 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 Jan 2018 11:50:17 +0100 Subject: Approach to system testing for Osmocom stack In-Reply-To: <6A55B7E0-9522-4632-82DB-26829346BCD2@freyther.de> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> <20180110115513.GZ13147@nataraja> <20180110233926.GE13147@nataraja> <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de> <6A55B7E0-9522-4632-82DB-26829346BCD2@freyther.de> Message-ID: <20180129105017.GM6630@nataraja> Hi Holger, thanks for your status update. Looking forward to the related code. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From marek.sebera at gmail.com Mon Jan 29 16:39:24 2018 From: marek.sebera at gmail.com (Marek Sebera) Date: Mon, 29 Jan 2018 17:39:24 +0100 Subject: grcardsim: fails with "bad echo value" Message-ID: <386c7c1b-c83a-5bdc-7a9a-c6deb47f54a0@gmail.com> Hi, sim card by identification ATR: 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) when trying to program using ./pySim-prog.py -n OpenBSC -i 901700000003080 -c 001 -x 001 -y 02 -s 1791198229180000075 -d /dev/ttyUSB0 -a 58001006 -t grcardsim pySim-prog.py fails with following stacktrace Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 636, in card.program(cp) File "/home/username/pysim/pySim/cards.py", line 271, in program self._scc.verify_chv(5, pin) File "/home/username/pysim/pySim/commands.py", line 111, in verify_chv return self._tp.send_apdu_checksw(self.cla_byte + '2000' + ('%02X' % schv_no) + '08' + fc) File "/home/username/pysim/pySim/transport/__init__.py", line 85, in send_apdu_checksw rv = self.send_apdu(pdu) File "/home/username/pysim/pySim/transport/__init__.py", line 68, in send_apdu data, sw = self.send_apdu_raw(pdu) File "/home/username/pysim/pySim/transport/serial.py", line 202, in send_apdu_raw self._tx_string(pdu[5:]) File "/home/username/pysim/pySim/transport/serial.py", line 168, in _tx_string raise ProtocolError("Bad echo value (Expected: %s, got %s)" % (b2h(s), b2h(r))) pySim.exceptions.ProtocolError: Bad echo value (Expected: 33353338333033303331333033303336, got 3335333833303330333330333033366e) - using usb sim card reader which creates standard serial line on /dev/ttyUSB0 programming also fails when using Gemalto Ezio Shield ./pySim-prog.py -n OpenBSC -i 901700000003080 -c 001 -x 001 -y 02 -s 1791198229180000075 -p 0 -a 58001006 -t grcardsim fails with following stacktrace Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 636, in card.program(cp) File "/home/smarek/Documents/PROJEKTY/SECURITY/TELCO/SIMCARDS/pysim/pySim/cards.py", line 271, in program self._scc.verify_chv(5, pin) File "/home/smarek/Documents/PROJEKTY/SECURITY/TELCO/SIMCARDS/pysim/pySim/commands.py", line 111, in verify_chv return self._tp.send_apdu_checksw(self.cla_byte + '2000' + ('%02X' % chv_no) + '08' + fc) File "/home/smarek/Documents/PROJEKTY/SECURITY/TELCO/SIMCARDS/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 6b00. Thank you for your help MS -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From holger at freyther.de Mon Jan 29 21:52:34 2018 From: holger at freyther.de (Holger Freyther) Date: Mon, 29 Jan 2018 21:52:34 +0000 Subject: Approach to system testing for Osmocom stack In-Reply-To: <20180129105017.GM6630@nataraja> References: <52E0568B-BD58-4FC2-AC06-CE948E5833D1@freyther.de> <20180110115513.GZ13147@nataraja> <20180110233926.GE13147@nataraja> <722206AD-DA6E-4802-8B62-83E54C5A72FA@freyther.de> <6A55B7E0-9522-4632-82DB-26829346BCD2@freyther.de> <20180129105017.GM6630@nataraja> Message-ID: <54F00998-3383-47E2-8399-E53781864F3D@freyther.de> > On 29. Jan 2018, at 10:50, Harald Welte wrote: > > Hi Holger, > > thanks for your status update. Looking forward to the related code. hehe. It is just a couple of hundred lines so far. It should bring us far enough. Will continue with it in a few minutes. For simplicity I am not segmenting mobile instances (one lua script for one mobile process). holger From laforge at gnumonks.org Mon Jan 29 22:15:38 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 Jan 2018 23:15:38 +0100 Subject: grcardsim: fails with "bad echo value" In-Reply-To: <386c7c1b-c83a-5bdc-7a9a-c6deb47f54a0@gmail.com> References: <386c7c1b-c83a-5bdc-7a9a-c6deb47f54a0@gmail.com> Message-ID: <20180129221538.GY6630@nataraja> Hi Marek, On Mon, Jan 29, 2018 at 05:39:24PM +0100, Marek Sebera wrote: > ATR: 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) The supplier of the cards you mention hasever contributed in any way to pySim. We simply did some protocol tracing of an early GRSIM card (2G, not USIM or LTE) and implemented code for it based on reverse engineering, just like for the early MagicSIM. If you have a different card, it will for sure not work. If you would like to implement support for the card models you are using, please feel free to contribute patches, we're happy to add support for more cards. The only SIM card supplier that ever contributed development of pySim code was sysmocom, and most recently, also fairwaves. So I guess you have the choice of either contributing code for the cards you work with, or use cards where the suppliers actually care about pySim support. Kind regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From marek.sebera at gmail.com Wed Jan 31 09:17:59 2018 From: marek.sebera at gmail.com (Marek Sebera) Date: Wed, 31 Jan 2018 10:17:59 +0100 Subject: grcardsim: fails with "bad echo value" In-Reply-To: <20180129221538.GY6630@nataraja> References: <386c7c1b-c83a-5bdc-7a9a-c6deb47f54a0@gmail.com> <20180129221538.GY6630@nataraja> Message-ID: <5e945259-f051-5fc3-ce3b-51757a8f0c9f@gmail.com> Hi Harald, thank you, I'll be happy to provide patches, as soon as I learn how to communicate with card. Is there anything to start with? Supplier just told us they obtained the SIM cards from "http://www.copysim.cn" and there is no reference to recommended software for programming these cards. I did obtain some informations using various utilities, but all I can now do is to study "ETSI TS 102 221" and implement the card-commands-discovery or bruteforce myself. Or am I wrong, and I've missed some utilities that could aid my fight? I've wrote some shell using both pySim and mitshell/card frameworks, and I've confirmed few things (ie. available commands, and CLA being 0x00, which means these cards are USIM), but passwords for ADM1 PIN (12345678, 44444444, 00000000) do not work. Also card partially responds to CLA 0x80, which probably indicates the availability of proprietary PDUs, as mentioned in grcardsim wiki. Is there any better tool, or am I using best available ones? Also mentioning the "bad echo value", is this related to implementation of specific sim-card, the usb reader/writer (possibly faulty) or the sim card? Because something as simple as ping/pong (or at least this is what it seems like from code) should not fail generally, and it occurs only when I provide "pin_adm" (adm1) and using grcardsim and sysmoUSIM-SJS1 (prefered). Thank you Marek On 01/29/2018 11:15 PM, Harald Welte wrote: > Hi Marek, > > On Mon, Jan 29, 2018 at 05:39:24PM +0100, Marek Sebera wrote: >> ATR: 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) > > The supplier of the cards you mention hasever contributed > in any way to pySim. We simply did some protocol tracing of an early > GRSIM card (2G, not USIM or LTE) and implemented code for it based on reverse > engineering, just like for the early MagicSIM. If you have a different > card, it will for sure not work. > > If you would like to implement support for the card models you are using, > please feel free to contribute patches, we're happy to add support for > more cards. > > The only SIM card supplier that ever contributed development of pySim code > was sysmocom, and most recently, also fairwaves. > > So I guess you have the choice of either contributing code for the cards > you work with, or use cards where the suppliers actually care about pySim > support. > > Kind regards, > Harald > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From domi at tomcsanyi.net Wed Jan 31 12:07:07 2018 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Wed, 31 Jan 2018 13:07:07 +0100 (CET) Subject: grcardsim: fails with "bad echo value" In-Reply-To: <5e945259-f051-5fc3-ce3b-51757a8f0c9f@gmail.com> References: <386c7c1b-c83a-5bdc-7a9a-c6deb47f54a0@gmail.com> <20180129221538.GY6630@nataraja> <5e945259-f051-5fc3-ce3b-51757a8f0c9f@gmail.com> Message-ID: <45F8D2C8-3B54-4C85-B3AD-A7649E2C4A44@tomcsanyi.net> Hi Marek, Are you trying to communicate with the card or program it? Cheers, Domi 2018. jan. 31. d?tummal, 10:18 id?pontban Marek Sebera ?rta: > Hi Harald, > > thank you, I'll be happy to provide patches, as soon as I learn how to > communicate with card. > > Is there anything to start with? Supplier just told us they obtained the > SIM cards from "http://www.copysim.cn" and there is no reference to > recommended software for programming these cards. > > I did obtain some informations using various utilities, but all I can > now do is to study "ETSI TS 102 221" and implement the > card-commands-discovery or bruteforce myself. > > Or am I wrong, and I've missed some utilities that could aid my fight? > > I've wrote some shell using both pySim and mitshell/card frameworks, and > I've confirmed few things (ie. available commands, and CLA being 0x00, > which means these cards are USIM), but passwords for ADM1 PIN (12345678, > 44444444, 00000000) do not work. Also card partially responds to CLA > 0x80, which probably indicates the availability of proprietary PDUs, as > mentioned in grcardsim wiki. Is there any better tool, or am I using > best available ones? > > Also mentioning the "bad echo value", is this related to implementation > of specific sim-card, the usb reader/writer (possibly faulty) or the sim > card? Because something as simple as ping/pong (or at least this is what > it seems like from code) should not fail generally, and it occurs only > when I provide "pin_adm" (adm1) and using grcardsim and sysmoUSIM-SJS1 > (prefered). > > Thank you > Marek > >> On 01/29/2018 11:15 PM, Harald Welte wrote: >> Hi Marek, >> >>> On Mon, Jan 29, 2018 at 05:39:24PM +0100, Marek Sebera wrote: >>> ATR: 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) >> >> The supplier of the cards you mention hasever contributed >> in any way to pySim. We simply did some protocol tracing of an early >> GRSIM card (2G, not USIM or LTE) and implemented code for it based on reverse >> engineering, just like for the early MagicSIM. If you have a different >> card, it will for sure not work. >> >> If you would like to implement support for the card models you are using, >> please feel free to contribute patches, we're happy to add support for >> more cards. >> >> The only SIM card supplier that ever contributed development of pySim code >> was sysmocom, and most recently, also fairwaves. >> >> So I guess you have the choice of either contributing code for the cards >> you work with, or use cards where the suppliers actually care about pySim >> support. >> >> Kind regards, >> Harald >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Jan 31 12:33:21 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 31 Jan 2018 13:33:21 +0100 Subject: grcardsim: fails with "bad echo value" In-Reply-To: <5e945259-f051-5fc3-ce3b-51757a8f0c9f@gmail.com> References: <386c7c1b-c83a-5bdc-7a9a-c6deb47f54a0@gmail.com> <20180129221538.GY6630@nataraja> <5e945259-f051-5fc3-ce3b-51757a8f0c9f@gmail.com> Message-ID: <20180131123321.GW20115@nataraja> you need the exact matching utilities / APDUs / scripts to configure the specific card chip / OS that you have in front of you. Reading ETSI/3GPP specs won't help you, as those documents only describe how the card is used after production/provisioning. What happens with the card during production/provisioning and using what commands/protocols is completely outside of any public/interoperable specification. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From marek.sebera at gmail.com Wed Jan 31 12:44:55 2018 From: marek.sebera at gmail.com (Marek Sebera) Date: Wed, 31 Jan 2018 13:44:55 +0100 Subject: grcardsim: fails with "bad echo value" In-Reply-To: <20180131123321.GW20115@nataraja> References: <386c7c1b-c83a-5bdc-7a9a-c6deb47f54a0@gmail.com> <20180129221538.GY6630@nataraja> <5e945259-f051-5fc3-ce3b-51757a8f0c9f@gmail.com> <20180131123321.GW20115@nataraja> Message-ID: <120783e1-4376-b77c-4a6f-fc1938ff901f@gmail.com> Ok, but when you did the initial "tracing" of APDUs used to program Green Card SIMs, you reversed some existing software? Or did you "bruteforce" it ? On 01/31/2018 01:33 PM, Harald Welte wrote: > you need the exact matching utilities / APDUs / scripts to configure the specific card > chip / OS that you have in front of you. > > Reading ETSI/3GPP specs won't help you, as those documents only describe > how the card is used after production/provisioning. What happens with the > card during production/provisioning and using what commands/protocols > is completely outside of any public/interoperable specification. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From laforge at gnumonks.org Wed Jan 31 12:50:28 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 31 Jan 2018 13:50:28 +0100 Subject: grcardsim: fails with "bad echo value" In-Reply-To: <120783e1-4376-b77c-4a6f-fc1938ff901f@gmail.com> References: <386c7c1b-c83a-5bdc-7a9a-c6deb47f54a0@gmail.com> <20180129221538.GY6630@nataraja> <5e945259-f051-5fc3-ce3b-51757a8f0c9f@gmail.com> <20180131123321.GW20115@nataraja> <120783e1-4376-b77c-4a6f-fc1938ff901f@gmail.com> Message-ID: <20180131125028.GX20115@nataraja> On Wed, Jan 31, 2018 at 01:44:55PM +0100, Marek Sebera wrote: > Ok, but when you did the initial "tracing" of APDUs used to program > Green Card SIMs, you reversed some existing software? Or did you > "bruteforce" it ? we traced the protocol between the windows software of the supplier and the card using the Osmocom SIMtrace. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From osmocom at lains.me Wed Jan 31 13:20:06 2018 From: osmocom at lains.me (Osmocom Mailing List) Date: Wed, 31 Jan 2018 13:20:06 +0000 Subject: Pysim - "Unable to connect with protocol: T0 or T1. Card is unpowered." Message-ID: <1517404806.2549.1@smtp.migadu.com> Hey, I ordered a generic blank LTE SIM card from ebay. When I try to read it I get the following message. "Unable to connect with protocol: T0 or T1. Card is unpowered." Before you ask, no, the sim is not in the wrong position. Check the attached images. Am I doing something wrong or is the card faulty? The reader is working, I was able to read/write to a SuperSIM (X-sim) and it detected a bunch of commercial SIMs from local operators (wasn't able to read any SIM specific value but I think that's normal). I just want to know if I should open a report agains the seller. Images: https://imgur.com/a/jrtPL Here's the technical data: READER Model: Gemalto PC USB-TR (now, IDBridge CT30) Specifications: https://www.gemalto.com/products/pc_link_readers/index.html SIM (acording to ebay listing) Name: LTE Blank USIM Card SIM Card Size: Standard SIM Card,Micro SIM Card and Nano SIM Card, 3 in 1 Compatible: 4G FDD LTE WCDMA GSM Feature: Can be written ICCID, IMSI, KI, OPC . Application: For Telecommunications Operator Thanks, Filipe La?ns Sent via Migadu.com, world's easiest email hosting -------------- next part -------------- An HTML attachment was scrubbed... URL: From marek.sebera at gmail.com Wed Jan 31 13:49:34 2018 From: marek.sebera at gmail.com (Marek Sebera) Date: Wed, 31 Jan 2018 14:49:34 +0100 Subject: grcardsim: fails with "bad echo value" In-Reply-To: <20180131125028.GX20115@nataraja> References: <386c7c1b-c83a-5bdc-7a9a-c6deb47f54a0@gmail.com> <20180129221538.GY6630@nataraja> <5e945259-f051-5fc3-ce3b-51757a8f0c9f@gmail.com> <20180131123321.GW20115@nataraja> <120783e1-4376-b77c-4a6f-fc1938ff901f@gmail.com> <20180131125028.GX20115@nataraja> Message-ID: <384c9970-f15b-03c1-6ef2-b1914d0945cb@gmail.com> Could you maybe tell me, because I haven't found anywhere in docs, which software and its version did you traced? Also is it possible this software has the USIM support within, and could be simply "traced" ? Or maybe newer version of the software will have the support. If the software can be downloaded anywhere, please link me, I'll investigate as much as I can. On 01/31/2018 01:50 PM, Harald Welte wrote: > On Wed, Jan 31, 2018 at 01:44:55PM +0100, Marek Sebera wrote: >> Ok, but when you did the initial "tracing" of APDUs used to program >> Green Card SIMs, you reversed some existing software? Or did you >> "bruteforce" it ? > > we traced the protocol between the windows software of the supplier and the card > using the Osmocom SIMtrace. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From laforge at gnumonks.org Wed Jan 31 14:12:20 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 31 Jan 2018 15:12:20 +0100 Subject: grcardsim: fails with "bad echo value" In-Reply-To: <384c9970-f15b-03c1-6ef2-b1914d0945cb@gmail.com> References: <386c7c1b-c83a-5bdc-7a9a-c6deb47f54a0@gmail.com> <20180129221538.GY6630@nataraja> <5e945259-f051-5fc3-ce3b-51757a8f0c9f@gmail.com> <20180131123321.GW20115@nataraja> <120783e1-4376-b77c-4a6f-fc1938ff901f@gmail.com> <20180131125028.GX20115@nataraja> <384c9970-f15b-03c1-6ef2-b1914d0945cb@gmail.com> Message-ID: <20180131141220.GA20115@nataraja> On Wed, Jan 31, 2018 at 02:49:34PM +0100, Marek Sebera wrote: > Could you maybe tell me, because I haven't found anywhere in docs, which > software and its version did you traced? This was some 5 or more years ago. Clearly I have no recollection of that. I also don't see why I would or should invest time on this. At the time we sourced chinese magic and GRsim cards and developed pySim, it was not possible to get small quantities of programmable cards in Europe or the US, at least mot on the general/open market for a reasonable price, together with knowhow or tools to program them. We have achieved that goal at the time, and after a lot of painful difficulties with GRcard, we have since moved to *much* better cards, and they are generally available together with pySim, the sysmusim-util and even a manual listing the APDUs and explaining the tools usage. So the problem no longe exists. If you need a small quantity of programmable cards, you can obtain them at a very reasonable price. Beforre we started offering the sysmoUSIM cards, we couldn't find programmable SIM cards for under EUR 70 per unit. Now we're at less than 10% of that. In low quantity, shipping globally, available to anyone without going through a Quote/PO/... process. And now you are asking us to spend time and help you with some other cards. Cards of a supplier that has never done anything for the Osmocom or general open source community, never released proper documentation or never contributed any code. You are free to do whatever you want by yourself, and we're very happy to merge any related patches by anoyne interested in adding support for more card types to pySim. But please allow us to spend our time on development of something that really matters, i.e. something that isn't already possible today, rather than spending time on replicating something that's already available to anyone for a very low price. It will not bring the capabilities of Open Source Mobile communications forward. Or would you disagree? > Also is it possible this software has the USIM support within, and could > be simply "traced" ? No. At that point you couldn't even buy USIMs from GRcard. I really think you should bother GRcard with those kind of questions. If somebody is selling a programmable SIM card to you, he should provide you with the tools to progam it. You have obtained a product and want to use it. It's not *our* job to help you make use it. It's the job of whoever sold you those cards. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed Jan 31 14:15:44 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 31 Jan 2018 15:15:44 +0100 Subject: Pysim - "Unable to connect with protocol: T0 or T1. Card is unpowered." In-Reply-To: <1517404806.2549.1@smtp.migadu.com> References: <1517404806.2549.1@smtp.migadu.com> Message-ID: <20180131141544.GB20115@nataraja> On Wed, Jan 31, 2018 at 01:20:06PM +0000, Osmocom Mailing List wrote: > I ordered a generic blank LTE SIM card from ebay. sorry, but there is no such thing as a 'generic blank LTE SIM card'. A "LTE SIM Card" (more precisely an ETSI UICC with USIM and/or ISIM application) is only specified from the point it has been fully provisioned, i.e. at which point it is neither blank nor generic anymore. Everything before that point is up to whatever proprietary protocol/system of the card manufacturer and/or card OS developer/licensor. > I just want to know if I should open a report agains the seller. I guess you should ask your supplier for what kind of tools he can provide you to provision/program the card, and/or how to verify it works correctly. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From marek.sebera at gmail.com Wed Jan 31 16:07:29 2018 From: marek.sebera at gmail.com (Marek Sebera) Date: Wed, 31 Jan 2018 17:07:29 +0100 Subject: grcardsim: fails with "bad echo value" In-Reply-To: <20180131141220.GA20115@nataraja> References: <386c7c1b-c83a-5bdc-7a9a-c6deb47f54a0@gmail.com> <20180129221538.GY6630@nataraja> <5e945259-f051-5fc3-ce3b-51757a8f0c9f@gmail.com> <20180131123321.GW20115@nataraja> <120783e1-4376-b77c-4a6f-fc1938ff901f@gmail.com> <20180131125028.GX20115@nataraja> <384c9970-f15b-03c1-6ef2-b1914d0945cb@gmail.com> <20180131141220.GA20115@nataraja> Message-ID: <35143a93-3182-8e4b-0828-379553531311@gmail.com> Harald, please, I'm not asking you to fix this for me, just to point me in the right direction, in my efforts. Which you did. Investigation with supplier and vendor is already undergoing, and I'll let you know, if I obtain any kind of info, that might be interesting and/or useful for the community. I also have sysmocom SJS1 on the way, so it will shortly stop being pain for me, and I'll have time to invest in reverse-engineering the chinese green cards. Also if I'll have the documentation available, I'll contribute with patch to use with GR-USIM cards. And I disagree that solving or trying to solve the question, whether these chinese sim cards are easy-to-use and programmable, will not do any good. It might not be the most important or interesting topic, but still it is something, and something useful in the end. But as I said in the beginning, please, I'm not asking you to spend much time on my issue. Initial motivation was my idea, that I cannot search or that this should be issue, somebody in this community already tackled, it's not, and I take that as conclusion. Take care Harald, and no hard feelings, really Best Regards Marek Sebera On 01/31/2018 03:12 PM, Harald Welte wrote: > On Wed, Jan 31, 2018 at 02:49:34PM +0100, Marek Sebera wrote: >> Could you maybe tell me, because I haven't found anywhere in docs, which >> software and its version did you traced? > > This was some 5 or more years ago. Clearly I have no recollection of that. > > I also don't see why I would or should invest time on this. At the time > we sourced chinese magic and GRsim cards and developed pySim, it was not > possible to get small quantities of programmable cards in Europe or the US, > at least mot on the general/open market for a reasonable price, together > with knowhow or tools to program them. > > We have achieved that goal at the time, and after a lot of painful > difficulties with GRcard, we have since moved to *much* better cards, and > they are generally available together with pySim, the sysmusim-util and > even a manual listing the APDUs and explaining the tools usage. > > So the problem no longe exists. If you need a small quantity of > programmable cards, you can obtain them at a very reasonable price. > Beforre we started offering the sysmoUSIM cards, we couldn't find > programmable SIM cards for under EUR 70 per unit. Now we're at less > than 10% of that. In low quantity, shipping globally, available to anyone > without going through a Quote/PO/... process. > > And now you are asking us to spend time and help you with some other cards. > Cards of a supplier that has never done anything for the Osmocom or general > open source community, never released proper documentation or never > contributed any code. > > You are free to do whatever you want by yourself, and we're very happy to > merge any related patches by anoyne interested in adding support for more > card types to pySim. But please allow us to spend our time on development > of something that really matters, i.e. something that isn't already > possible today, rather than spending time on replicating something that's > already available to anyone for a very low price. It will not bring the > capabilities of Open Source Mobile communications forward. Or would you > disagree? > >> Also is it possible this software has the USIM support within, and could >> be simply "traced" ? > > No. At that point you couldn't even buy USIMs from GRcard. > > I really think you should bother GRcard with those kind of questions. If somebody is selling a > programmable SIM card to you, he should provide you with the tools to progam it. > > You have obtained a product and want to use it. It's not *our* job to help > you make use it. It's the job of whoever sold you those cards. > > Regards, > Harald > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 851 bytes Desc: OpenPGP digital signature URL: From laforge at gnumonks.org Wed Jan 31 22:38:34 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 31 Jan 2018 23:38:34 +0100 Subject: On the use of 'decmatch' in TTCN-3 Message-ID: <20180131223834.GJ20115@nataraja> Hi, I know that TTCN-3 is still new to a lot of you, but we are writing tons of integration testing against the various osmocom programs in it. It is quite amazing technology, and I would like to ask you to bear with me reading this mail :) Pau was stating the question earlier today on not finding an example on how to use decmatch. Indeed, it took me some months to find that gem in the TTCN-3 world. It solves the problem that you often have during test of layered protocol stacks: you have separate encoders/decoders for each protocol layer, and now you want to match on some of the *inner* payload. So normally, you have some kind of header definition + a binary (octetstring) payload. This happens in RSL with the L3_INFO IE, and just the same on BSSAP/DTAP where again the L3 message (for example call control) is encapsulated inside one information element. Now you have multiple options of addressing the problem: a) hand-written calls to the decoder function b) write na 'emulation' for the entire protocol layer c) use decmatch. a) would look like this (pseudo-code): var octetstring l3oct; var RSL_Message rsl RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, ?)) -> value rsl { var PDU_ML3_MS_NW l3 := dec_PDU_ML3_MS_NW(rsl.payload); if (match(l3, some_template)) { ... do something } ... } Which uses the built-in pattern-matching on the RSL port to match any message that matches the tr_RSL_DATA_REQ template, and stores the resulting RSL message in a variable. It then uses an explicit call to the decoder function of the L3 message, and then uses regular conditional expressions for further matching on that inner L3 payload. This is more or less how you would write in C, python or any other quite imperative programming languages. It's very verbose, time consuming and un-abstract/elegant. TTCN-3 has many declarative aspects to it. Code like the above is a waste of your time :) b) would mean that you implement some test component that handles the RSL messages on its bottom side test port, and the L3 messages on its top side test port. That is a possible way, and if you need a lot of state/logic of RSL, it maeks sense. But what if you really simply want to have a match? Then it would be a lot of effort and a large detour. c) decmatch to the rescue! You can write RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, decmatch tr_RRM_RR_STATUS)) which means: * do a receive on the RSL test port, and match on an incoming RSL message that matches the tr_RSL_DATA_REQ template, with channel number specified, link_id any (?), *and* if the octetstring payload, if decoded, matches the template tr_RRM_RR_STATUS ! This is *extremely* powerful and expressive. It allows you to condense complex, parametric template matching over multiple proocol layers. It would in the end match RSL DATA REQUEST, only if they contained a [valid] encoded RR STATUS. See https://gerrit.osmocom.org/6229 for the actual test case I used for the above examples. Please also note that I never had to even write the function name of the decoder (dec_PDU_ML3_MS_NW), but TTCN-3 *automatically* figures out which decoder function it must call in order to decode from the binary octetstring. Happy (TTCN-3) hacking + Osmocom bugfixing, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed Jan 31 23:01:30 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 1 Feb 2018 00:01:30 +0100 Subject: Submissions for OsmoDevCon 2018 Message-ID: <20180131230130.GK20115@nataraja> Dear Osmocom community, it's already end of January and OsmoDevCon 2018 in April is getting closer and closer. As indicated before, I would like to group the topics by days and put together at least a rough framework shcedule, so that people with specific interests don't have to be present for four full days to make sure they don't miss anything. So I'd like to re-invite all attendees to consider adding a topic/porposal to the wiki page at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2018#section-9 so that we can group different topic areas and put together a rough schedule outline. A proposal doesn't mean you have to give a talk. It could be anything, including * a talk that you would want to listen to, and you're looking for somebody to give it * a discussion about a certain topic * a workshop / hands on session * lightning talks? Like any community event, OsmoDevCon lives by its contributors. I can't wait to hear about all the things you've been up to. Thanks! Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From pespin at sysmocom.de Wed Jan 31 23:18:11 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Thu, 1 Feb 2018 00:18:11 +0100 Subject: On the use of 'decmatch' in TTCN-3 In-Reply-To: <20180131223834.GJ20115@nataraja> References: <20180131223834.GJ20115@nataraja> Message-ID: Hi Harald, thanks for the explanation! However, it's still not clear to me how to get the decoded payload out of the receive statement. From https://www.eclipse.org/forums/index.php/t/1089269/ I saw there's this "@decoded" keyword you can use but I couldn't figure out how to really use it in a proper way, and what exactly I would be getting with it. I'm also wondering if several decmatch expressions can be stacked in a single statment, for instance image something like: RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, decmatch tr_RRM_RR_STATUS(foo, bar, decmatch tr_ANOTHER_TEMPLATE)). Linking it with first question, what I would be getting when using the @decoded keyword in this case? And extra question I asked myself while doing some tests today: is there a way to check if a template received through a function parameter matches a specific template? I tried with match() but from what I understood from the compilation errors, it seems match() actually checks a value vs a template, and not 2 templates. Hm maybe just using "==" would work, I didn't check it. Last query: Did you find a good tutorial or well documented examples for beginners in some specific place? -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From kevredon at mail.tsaitgaist.info Mon Jan 15 14:09:40 2018 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Mon, 15 Jan 2018 14:09:40 -0000 Subject: [osmocom/gr-osmosdr] Sdrplay2 (#12) In-Reply-To: <20180115124443.m7t5cmf3nfpqf623@nataraja> References: <20180115120205.GB2776@my.box> <20180115124443.m7t5cmf3nfpqf623@nataraja> Message-ID: <20180115140120.GA29067@coil> I've updated the message to: GitHub is only used to mirror [osmocom projects](http://git.osmocom.org/). Please read the following instructions to [submit patches](http://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards#Submitting-Patches). On Mon, Jan 15, 2018 at 01:44:43PM +0100, Harald Welte wrote: > Kevin has created this robot, I presume he knows where to modify the related > message contents. Kevin? > > Thanks! > > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) From papazian at mail.ru Wed Jan 31 13:04:17 2018 From: papazian at mail.ru (=?UTF-8?B?0JzQsNGA0LDRgiDQo9C30Y/QutC+0LI=?=) Date: Wed, 31 Jan 2018 13:04:17 -0000 Subject: =?UTF-8?B?IFtvcGVuYnNjIDEuMC4wLjE0LTk4YTJiYV0gdGVzdHN1aXRlOiA0IGZhaWxl?= =?UTF-8?B?ZA==?= Message-ID: <1517398877.305164208@f470.i.mail.ru> Hi!? Please help! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testsuite.log Type: application/octet-stream Size: 47233 bytes Desc: not available URL: