From nhofmeyr at sysmocom.de Wed Nov 1 01:00:01 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 1 Nov 2017 02:00:01 +0100 Subject: osmo-iuh fails to regenerate from asn1 sources Message-ID: <20171101010001.GA18706@my.box> I just noticed that osmo-iuh is not able to generate Iu protocols from ASN.1 sources anymore. This has probably been the case for a while, but it was uncovered by the osmo-clean-workspace.sh scripts recently introduced. There are some .h and .c files missing that sed wants to modify. I get: sed -i '6i#include ' RANAP_ChosenEncryptionAlgorithm.h RANAP_ChosenIntegrityProtectionAlgorithm.h RANAP_IMSI.h RANAP_PLMNidentity.h RANAP_RAB-ReleaseFailedList.c RANAP_RAB-ReleaseList.c RANAP_RAB-SetupOrModifyList.c RANAP_ResetResourceList.c RANAP_ResetResourceAckList.c sed: can't read RANAP_ChosenEncryptionAlgorithm.h: No such file or directory sed: can't read RANAP_ChosenIntegrityProtectionAlgorithm.h: No such file or directory sed: can't read RANAP_IMSI.h: No such file or directory sed: can't read RANAP_PLMNidentity.h: No such file or directory sed: can't read RANAP_RAB-ReleaseFailedList.c: No such file or directory sed: can't read RANAP_RAB-ReleaseList.c: No such file or directory sed: can't read RANAP_RAB-SetupOrModifyList.c: No such file or directory sed: can't read RANAP_ResetResourceList.c: No such file or directory sed: can't read RANAP_ResetResourceAckList.c: No such file or directory Makefile:2711: recipe for target 'regenerate-from-asn1-source' failed make[1]: *** [regenerate-from-asn1-source] Error 2 make[1]: Leaving directory '/n/s/osmo/make-3G/osmo-iuh/src/ranap' Notably, jenkins produces slightly different output, see https://jenkins.osmocom.org/jenkins/job/osmo-iuh/34/label=linux_amd64_debian8/console https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-iuh/1/a1=default,a2=default,a3=default,a4=default,label=linux_amd64_debian8/console Does anyone know what could have caused this? ~N -------------- 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 Wed Nov 1 07:59:12 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 1 Nov 2017 08:59:12 +0100 Subject: .deb updates in Debian/Ubuntu repos In-Reply-To: References: <11c4047b-3f0f-ecc6-3f90-08a09cc8d465@sysmocom.de> Message-ID: <20171101075912.xvgpld4b4v3yvkpt@nataraja> Hi Max, Thorsten, On Tue, Oct 31, 2017 at 11:11:23PM +0100, Thorsten Alteholz wrote: > On Tue, 24 Oct 2017, Max wrote: > if there is a SONAME change, the package name should change. The link in the > dev package should point to the new version. And ... > > > The library package named libosmonetif3.install > > According to https://wiki.debian.org/TransitionBestPractices it should be renamed to > > libosmonetif4.install because we're changing "current" component of libversion. > > ... yes, this as well (not only this file but all others that belong to this > package as well) ... which is BTW what is more or less obvious and what I did for all the releases for the osmocom:latest feed that I created on the weekend. > > We should also change debian/control to reflect this rename, but what about > > "Conflicts:" in there? > > I've tried reading > > https://debian-handbook.info/browse/stable/sect.package-meta-information.html but > > still not sure how it should be applied in case of shared libraries. > > > > Shall we put libosmonetif3 in Conflicts? Both libosmonetif3 and libosmonetif2? > > Shall we use /Replaces instead? If so, for which version(s)? > > Replaces: is only for two packages with the same functionality, so a > Conflicts: would be right. It should be for each version available earlier > (there might be an old version left during an upgrade). Why would it conflict? The point of having the LIBVERSION "current" as part of the .so name is that you can have both installed at the same time, and that applications are linked against a specific version. So let's say I have an incompatible older version of the library installed, some older programs can still use it, while the newer library is used by newer / newly linked applications. I see situations like this quite normally on any debian system: ii libreadline5:amd64 5.2+dfsg-3+b1 amd64 GNU readline and history libraries, run-time libraries ii libreadline7:amd64 7.0-3 amd64 GNU readline and history libraries, run-time libraries -- - 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 Nov 1 10:43:04 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 1 Nov 2017 11:43:04 +0100 Subject: osmo-iuh fails to regenerate from asn1 sources In-Reply-To: <20171101010001.GA18706@my.box> References: <20171101010001.GA18706@my.box> Message-ID: <20171101104304.uup5hq444oj5xz2g@nataraja> On Wed, Nov 01, 2017 at 02:00:01AM +0100, Neels Hofmeyr wrote: > I just noticed that osmo-iuh is not able to generate Iu protocols from ASN.1 > sources anymore. This has probably been the case for a while, but it was > uncovered by the osmo-clean-workspace.sh scripts recently introduced. Can you please post the exact steps to reproduce? On my laptop, the following works: * call osmo-clean-workspace.sh * call autoreconf -fi * call ./configure * cd src/ranap && make regenerate-from-asn1-source > There are some .h and .c files missing that sed wants to modify. I get: Not here. Works as expected. Even with a cleanly rebuilt asn1c. Are you sure your asn1c is compiled from the osmocom git repot aper-prefix branch? -- - 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 Nov 1 10:49:20 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 1 Nov 2017 11:49:20 +0100 Subject: osmo-iuh fails to regenerate from asn1 sources In-Reply-To: <20171101104304.uup5hq444oj5xz2g@nataraja> References: <20171101010001.GA18706@my.box> <20171101104304.uup5hq444oj5xz2g@nataraja> Message-ID: <20171101104920.bxv5umcjx6way2ml@nataraja> Hi Neels, from https://jenkins.osmocom.org/jenkins/job/osmo-iuh/label=linux_amd64_debian8/34/consoleFull =============================== asn1c =============================== + mkdir -p /home/osmocom-build/jenkins/workspace/osmo-iuh/label/linux_amd64_debian8/deps + cd /home/osmocom-build/jenkins/workspace/osmo-iuh/label/linux_amd64_debian8/deps + osmo-deps.sh asn1c aper-prefix Cloning into 'asn1c'... HEAD is now at 6dcd9ca build: Add a simple gitignore file... + cd asn1c + autoreconf --install --force clearly the "aper-prefix" is being ignored, as 6dcd9ca is the master branch and not the aper-prefix branch. Is the automatic update of osmo-ci not working since at least October 27 when commit 7c5e34cba004837189c92ca015856a06288872e0 Author: Neels Hofmeyr Date: Fri Oct 27 22:31:14 2017 +0200 was introduced? -- - 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 Wed Nov 1 12:53:48 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 1 Nov 2017 13:53:48 +0100 Subject: osmo-iuh fails to regenerate from asn1 sources In-Reply-To: <20171101104920.bxv5umcjx6way2ml@nataraja> References: <20171101010001.GA18706@my.box> <20171101104304.uup5hq444oj5xz2g@nataraja> <20171101104920.bxv5umcjx6way2ml@nataraja> Message-ID: <20171101125348.GA1358@my.box> On Wed, Nov 01, 2017 at 11:49:20AM +0100, Harald Welte wrote: > clearly the "aper-prefix" is being ignored, as 6dcd9ca is the master branch > and not the aper-prefix branch. Damn, thanks, I missed that. > Is the automatic update of osmo-ci not working since at least October 27 when the update-osmo-ci-on-slaves job was never set to update automatically, it seemed like a good idea at the time. But by now all of us expect everything to update automatically after the gerrit submit, so I set it up to "Poll SCM" now. Now I'm trying to figure out why osmo-deps.sh fails to set up the proper branch. Somehow, even though the script is installed (manual testing on build slave in /tmp works as expected), the jenkins job still uses an old one... I noticed another failure in using 'checkout -f' to update a specific branch -- it's a deja vu, I've had these problems before: if I have a git clone that once did 'checkout [-f] branch', and if then origin/branch gets updates, doing another 'checkout -f branch' only goes back to the local tracking-branch of origin/branch. We never pull in changes from origin/branch anymore as soon as a local branch exists. Last time solutions were using 'git reset --hard', which confuses local branches, and finally to just wipe the clone every time. This time I think it's best to always prepend 'origin/', so that 'checkout -f' goes into detached-HEAD state onto the newest fetched revision. Fixing things now.... ~N -------------- 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 Wed Nov 1 13:08:46 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 1 Nov 2017 14:08:46 +0100 Subject: osmo-iuh fails to regenerate from asn1 sources In-Reply-To: <20171101125348.GA1358@my.box> References: <20171101010001.GA18706@my.box> <20171101104304.uup5hq444oj5xz2g@nataraja> <20171101104920.bxv5umcjx6way2ml@nataraja> <20171101125348.GA1358@my.box> Message-ID: <20171101130846.ylovo7lojryebcog@nataraja> Hi Neels, On Wed, Nov 01, 2017 at 01:53:48PM +0100, Neels Hofmeyr wrote: > I noticed another failure in using 'checkout -f' to update a specific branch -- > it's a deja vu, I've had these problems before: if I have a git clone that once > did 'checkout [-f] branch', and if then origin/branch gets updates, doing > another 'checkout -f branch' only goes back to the local tracking-branch of > origin/branch. We never pull in changes from origin/branch anymore as soon as a > local branch exists. Last time solutions were using 'git reset --hard', which > confuses local branches, and finally to just wipe the clone every time. "checkout -f -B local_foo origin/foo" is IMHO the corect approach, which I also do in my Dockerfiles, AFAIR. Checking out a remote branch name using a local branch name (e.g. expanding aper_prefix to origin/aper_prefix if aper_prefix doesn't exist) is a mis-feature in git, IMHO. It's confusing. Even when working with git interactively, I always explicitly qualify branch names wit their 'remote' such as 'origin'. When working with half a dozen or more remotes in a given repository it becomes very confusing otherwise anyway. > This time I think it's best to always prepend 'origin/', so that 'checkout -f' > goes into detached-HEAD state onto the newest fetched revision. correct. And '-B foo' is an "and create a local branch with the naem 'foo' and overwrite any existing branch with the name 'foo' if it exists" -- - 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 Wed Nov 1 13:14:12 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 1 Nov 2017 14:14:12 +0100 Subject: osmo-iuh fails to regenerate from asn1 sources In-Reply-To: <20171101125348.GA1358@my.box> References: <20171101010001.GA18706@my.box> <20171101104304.uup5hq444oj5xz2g@nataraja> <20171101104920.bxv5umcjx6way2ml@nataraja> <20171101125348.GA1358@my.box> Message-ID: <20171101131412.GB1358@my.box> On Wed, Nov 01, 2017 at 01:53:48PM +0100, Neels Hofmeyr wrote: > Fixing things now.... OsmocomBuild1 had stale copies of osmo-ci scripts in /usr/local/bin, which overrode those kept in ~/bin. Also checked the other build slaves, all good. I removed the FreeBSD slave from "update-osmo-ci-on-slaves". We now have OsmocomBuild1 (user osmocom-build on build slave's root fs), build1-debian9-lxc (lxc "docker" on the same machine). build2-deb8build (lxc "deb8build" on build-2 machine). There's also that deb9build lxc on build-2, but it doesn't seem to be connected. ~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 Wed Nov 1 13:48:27 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 1 Nov 2017 14:48:27 +0100 Subject: build slaves: deb8 + deb9? Message-ID: <20171101134827.GC1358@my.box> We currently do gerrit verifications on debian8-amd64 only. Only osmo-hlr has also deb9 set as build slave to test. I'd move over to deb9 now and no longer build on deb8. What do you guys think, should we build on both deb8 and deb9? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From pespin at sysmocom.de Wed Nov 1 14:05:31 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 1 Nov 2017 15:05:31 +0100 Subject: build slaves: deb8 + deb9? In-Reply-To: <20171101134827.GC1358@my.box> References: <20171101134827.GC1358@my.box> Message-ID: On 01/11/17 14:48, Neels Hofmeyr wrote: > We currently do gerrit verifications on debian8-amd64 only. Only osmo-hlr has > also deb9 set as build slave to test. > > I'd move over to deb9 now and no longer build on deb8. > What do you guys think, should we build on both deb8 and deb9? > > ~N > I'm fine with moving to deb9 only as long as nobody can find an important point against doing so. -- - 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 Nov 1 14:56:31 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 1 Nov 2017 15:56:31 +0100 Subject: build slaves: deb8 + deb9? In-Reply-To: <20171101134827.GC1358@my.box> References: <20171101134827.GC1358@my.box> Message-ID: <20171101145631.6eol327g6lbfnvhp@nataraja> Hi Neels, On Wed, Nov 01, 2017 at 02:48:27PM +0100, Neels Hofmeyr wrote: > We currently do gerrit verifications on debian8-amd64 only. Only osmo-hlr has > also deb9 set as build slave to test. > > I'd move over to deb9 now and no longer build on deb8. > What do you guys think, should we build on both deb8 and deb9? I don't really care all too much, but I am wondering why we are changing a "known working" system. In the end, we are providing packages for Debian >= 8 and Ubuntu >= 16.04. Debian 8 is officially supported until June 2018, and Debian LTS will support it until April 2020. I would argue that the we provide Debian 8 builds at least until June 2018. That of course doesn't determine where we do the build testing before a patch is merged, but in case we start using features not available on Debian 8, we will then only find out once the nightly packages are built, as opposed to before the patch is merged. OTOTH, there are some more interesting warnings generated by later gcc versions in later distributions. All in all, I don't have a strong opinion one way or another. But I am arguing against change without a clear reason/purpose. For example, if the new Debian 9 build-slaves were automatically generated by ansible or Dockerfiles, then that would be a strong argument to migrate, as we could much more easily scale if later needed with such a setup. 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 Wed Nov 1 16:10:01 2017 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Wed, 1 Nov 2017 16:10:01 +0000 (GMT) Subject: =?UTF-8?Q?Build_failed_in_Jenkins:_Coverity-?= =?UTF-8?Q?Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1657?= In-Reply-To: <225533143.43.1509466192187.JavaMail.jenkins@jenkins.osmocom.org> References: <225533143.43.1509466192187.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <1326134411.50.1509552601709.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 1.84 MB...] test_apps/Makefile.am:17: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:17: warning: source file '$(TESTAPPS_SOURCE_DIR)/esme.c' is in a subdirectory, test_apps/Makefile.am:17: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/generic_nack_test.c' is in a subdirectory, test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/outbind_test.c' is in a subdirectory, test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/tcp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/smpp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/sendwp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_test.c' is in a subdirectory, test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_test.c' is in a subdirectory, test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here binaries/Makefile.am: installing 'aux_config/depcomp' test_apps/Makefile.am:26: warning: variable 'analizer_SOURCES' is defined but no program or test_apps/Makefile.am:26: library has 'analizer' as canonical name (possible typo) test_apps/Makefile.am:17: warning: variable 'esme_SOURCES' is defined but no program or test_apps/Makefile.am:17: library has 'esme' as canonical name (possible typo) test_apps/Makefile.am:4: warning: variable 'sendwp_SOURCES' is defined but no program or test_apps/Makefile.am:4: library has 'sendwp' as canonical name (possible typo) test_apps/Makefile.am:30: warning: variable 'analizer_LDFLAGS' is defined but no program or test_apps/Makefile.am:30: library has 'analizer' as canonical name (possible typo) test_apps/Makefile.am:24: warning: variable 'esme_LDFLAGS' is defined but no program or test_apps/Makefile.am:24: library has 'esme' as canonical name (possible typo) test_apps/Makefile.am:11: warning: variable 'sendwp_LDFLAGS' is defined but no program or test_apps/Makefile.am:11: library has 'sendwp' as canonical name (possible typo) + ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom 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 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 stdlib.h... (cached) yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking for stdint.h... (cached) yes checking for string.h... (cached) yes checking for LIBXML2... no checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking for memset... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating def_frame/Makefile config.status: creating def_list/Makefile config.status: creating binaries/Makefile config.status: creating test_apps/Makefile config.status: creating libsmpp34.pc config.status: creating aux_config/config.h config.status: executing depfiles commands config.status: executing libtool commands + make -j 3 echo 1.12.0.11-0f76 > .version-t && mv .version-t .version make all-recursive make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34' Making all in binaries make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c -o libsmpp34_la-smpp34_dumpBuf.lo `test -f '../src/smpp34_dumpBuf.c' || echo './'`../src/smpp34_dumpBuf.c /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c -o libsmpp34_la-smpp34_dumpPdu.lo `test -f '../src/smpp34_dumpPdu.c' || echo './'`../src/smpp34_dumpPdu.c /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c -o libsmpp34_la-smpp34_pack.lo `test -f '../src/smpp34_pack.c' || echo './'`../src/smpp34_pack.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_pack.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpPdu.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpBuf.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -o libsmpp34_la-smpp34_dumpBuf.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_dumpBuf.Tpo .deps/libsmpp34_la-smpp34_dumpBuf.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c -o libsmpp34_la-smpp34_unpack.lo `test -f '../src/smpp34_unpack.c' || echo './'`../src/smpp34_unpack.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_unpack.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -o libsmpp34_la-smpp34_pack.o >/dev/null 2>&1 libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -o libsmpp34_la-smpp34_dumpPdu.o >/dev/null 2>&1 libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -o libsmpp34_la-smpp34_unpack.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_pack.Tpo .deps/libsmpp34_la-smpp34_pack.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c -o libsmpp34_la-smpp34_structs.lo `test -f '../src/smpp34_structs.c' || echo './'`../src/smpp34_structs.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_structs.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -o libsmpp34_la-smpp34_structs.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_structs.Tpo .deps/libsmpp34_la-smpp34_structs.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c -o libsmpp34_la-smpp34_params.lo `test -f '../src/smpp34_params.c' || echo './'`../src/smpp34_params.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_params.o mv -f .deps/libsmpp34_la-smpp34_unpack.Tpo .deps/libsmpp34_la-smpp34_unpack.Plo gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -fPIC -g -O2 -MT core.o -MD -MP -MF .deps/core.Tpo -c -o core.o `test -f '../test_pdu/core.c' || echo './'`../test_pdu/core.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -o libsmpp34_la-smpp34_params.o >/dev/null 2>&1 mv -f .deps/core.Tpo .deps/core.Po gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -fPIC -g -O2 -MT submit_multi_resp_test.o -MD -MP -MF .deps/submit_multi_resp_test.Tpo -c -o submit_multi_resp_test.o `test -f '../test_pdu/submit_multi_resp_test.c' || echo './'`../test_pdu/submit_multi_resp_test.c make[2]: *** No rule to make target '../binaries/libsmpp34.la', needed by 'submit_multi_resp_test'. Stop. make[2]: *** Waiting for unfinished jobs.... mv -f .deps/libsmpp34_la-smpp34_dumpPdu.Tpo .deps/libsmpp34_la-smpp34_dumpPdu.Plo mv -f .deps/submit_multi_resp_test.Tpo .deps/submit_multi_resp_test.Po mv -f .deps/libsmpp34_la-smpp34_params.Tpo .deps/libsmpp34_la-smpp34_params.Plo make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries' Makefile:460: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34' Makefile:368: recipe for target 'all' failed make: *** [all] Error 2 [WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully. Emitted 454 C/C++ compilation units (100%) successfully 454 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 debian at alteholz.de Wed Nov 1 19:11:11 2017 From: debian at alteholz.de (Thorsten Alteholz) Date: Wed, 1 Nov 2017 20:11:11 +0100 (CET) Subject: .deb updates in Debian/Ubuntu repos In-Reply-To: <20171101075912.xvgpld4b4v3yvkpt@nataraja> References: <11c4047b-3f0f-ecc6-3f90-08a09cc8d465@sysmocom.de> <20171101075912.xvgpld4b4v3yvkpt@nataraja> Message-ID: Hi Harald, On Wed, 1 Nov 2017, Harald Welte wrote: >> Replaces: is only for two packages with the same functionality, so a >> Conflicts: would be right. It should be for each version available earlier >> (there might be an old version left during an upgrade). > > Why would it conflict? The point of having the LIBVERSION "current" as part of the > .so name is that you can have both installed at the same time, and that applications > are linked against a specific version. So let's say I have an incompatible older > version of the library installed, some older programs can still use it, while the newer > library is used by newer / newly linked applications. you are right, this is not a technical Conflicts: but rather a policy one. In Debian only one version of a source package is allowed in the archive (one for each release). So when you upload libosmo-netif which builds libosmonetif3 and afterwards the newer libosmo-netif that builds libosmonetif4, the former source package will be removed. This results in a missing source package for libosmonetif3. This situation is detectd by the archive software that takes care of transitions and unless all packages that depend on libosmonetif3 will be rebuilt with libosmonetif4, the package may not migrate from unstable to testing and hence never appears in any release. So in the end you have a libosmonetif3 on your computer that never will be used and such should be removed, therefore the Conflicts:. > I see situations like this quite normally on any debian system: > > ii libreadline5:amd64 5.2+dfsg-3+b1 amd64 GNU readline and history libraries, run-time libraries > ii libreadline7:amd64 7.0-3 amd64 GNU readline and history libraries, run-time libraries Sure, from time to time you really need two versions of a library. So if you look at your example: dpkg-query --showformat='${binary:Package}\t${source:Package}\t${Version}\n' --show "libreadline*:amd64" libreadline-dev:amd64 readline 7.0-3 libreadline5:amd64 readline5 5.2+dfsg-3+b1 libreadline6:amd64 readline6 6.3-9 libreadline7:amd64 readline 7.0-3 you can see that each version of libreadline* also has a different source package readline* Thorsten From jenkins at lists.osmocom.org Thu Nov 2 16:09:52 2017 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Thu, 2 Nov 2017 16:09:52 +0000 (GMT) Subject: =?UTF-8?Q?Build_failed_in_Jenkins:_Coverity-?= =?UTF-8?Q?Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1658?= In-Reply-To: <1326134411.50.1509552601709.JavaMail.jenkins@jenkins.osmocom.org> References: <1326134411.50.1509552601709.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <589264158.53.1509638992683.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 1.84 MB...] test_apps/Makefile.am:17: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:17: warning: source file '$(TESTAPPS_SOURCE_DIR)/esme.c' is in a subdirectory, test_apps/Makefile.am:17: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/generic_nack_test.c' is in a subdirectory, test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/outbind_test.c' is in a subdirectory, test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/tcp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/smpp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/sendwp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_test.c' is in a subdirectory, test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_test.c' is in a subdirectory, test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here binaries/Makefile.am: installing 'aux_config/depcomp' test_apps/Makefile.am:26: warning: variable 'analizer_SOURCES' is defined but no program or test_apps/Makefile.am:26: library has 'analizer' as canonical name (possible typo) test_apps/Makefile.am:17: warning: variable 'esme_SOURCES' is defined but no program or test_apps/Makefile.am:17: library has 'esme' as canonical name (possible typo) test_apps/Makefile.am:4: warning: variable 'sendwp_SOURCES' is defined but no program or test_apps/Makefile.am:4: library has 'sendwp' as canonical name (possible typo) test_apps/Makefile.am:30: warning: variable 'analizer_LDFLAGS' is defined but no program or test_apps/Makefile.am:30: library has 'analizer' as canonical name (possible typo) test_apps/Makefile.am:24: warning: variable 'esme_LDFLAGS' is defined but no program or test_apps/Makefile.am:24: library has 'esme' as canonical name (possible typo) test_apps/Makefile.am:11: warning: variable 'sendwp_LDFLAGS' is defined but no program or test_apps/Makefile.am:11: library has 'sendwp' as canonical name (possible typo) + ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom 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 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 stdlib.h... (cached) yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking for stdint.h... (cached) yes checking for string.h... (cached) yes checking for LIBXML2... no checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking for memset... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating def_frame/Makefile config.status: creating def_list/Makefile config.status: creating binaries/Makefile config.status: creating test_apps/Makefile config.status: creating libsmpp34.pc config.status: creating aux_config/config.h config.status: executing depfiles commands config.status: executing libtool commands + make -j 3 echo 1.12.0.11-0f76 > .version-t && mv .version-t .version make all-recursive make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34' Making all in binaries make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c -o libsmpp34_la-smpp34_dumpBuf.lo `test -f '../src/smpp34_dumpBuf.c' || echo './'`../src/smpp34_dumpBuf.c /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c -o libsmpp34_la-smpp34_dumpPdu.lo `test -f '../src/smpp34_dumpPdu.c' || echo './'`../src/smpp34_dumpPdu.c /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c -o libsmpp34_la-smpp34_pack.lo `test -f '../src/smpp34_pack.c' || echo './'`../src/smpp34_pack.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpBuf.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_pack.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpPdu.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -o libsmpp34_la-smpp34_dumpBuf.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_dumpBuf.Tpo .deps/libsmpp34_la-smpp34_dumpBuf.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c -o libsmpp34_la-smpp34_unpack.lo `test -f '../src/smpp34_unpack.c' || echo './'`../src/smpp34_unpack.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_unpack.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -o libsmpp34_la-smpp34_pack.o >/dev/null 2>&1 libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -o libsmpp34_la-smpp34_dumpPdu.o >/dev/null 2>&1 libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -o libsmpp34_la-smpp34_unpack.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_pack.Tpo .deps/libsmpp34_la-smpp34_pack.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c -o libsmpp34_la-smpp34_structs.lo `test -f '../src/smpp34_structs.c' || echo './'`../src/smpp34_structs.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_structs.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -o libsmpp34_la-smpp34_structs.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_structs.Tpo .deps/libsmpp34_la-smpp34_structs.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c -o libsmpp34_la-smpp34_params.lo `test -f '../src/smpp34_params.c' || echo './'`../src/smpp34_params.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_params.o mv -f .deps/libsmpp34_la-smpp34_unpack.Tpo .deps/libsmpp34_la-smpp34_unpack.Plo gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -fPIC -g -O2 -MT core.o -MD -MP -MF .deps/core.Tpo -c -o core.o `test -f '../test_pdu/core.c' || echo './'`../test_pdu/core.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -o libsmpp34_la-smpp34_params.o >/dev/null 2>&1 mv -f .deps/core.Tpo .deps/core.Po gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -fPIC -g -O2 -MT submit_multi_resp_test.o -MD -MP -MF .deps/submit_multi_resp_test.Tpo -c -o submit_multi_resp_test.o `test -f '../test_pdu/submit_multi_resp_test.c' || echo './'`../test_pdu/submit_multi_resp_test.c make[2]: *** No rule to make target '../binaries/libsmpp34.la', needed by 'submit_multi_resp_test'. Stop. make[2]: *** Waiting for unfinished jobs.... mv -f .deps/libsmpp34_la-smpp34_dumpPdu.Tpo .deps/libsmpp34_la-smpp34_dumpPdu.Plo mv -f .deps/submit_multi_resp_test.Tpo .deps/submit_multi_resp_test.Po mv -f .deps/libsmpp34_la-smpp34_params.Tpo .deps/libsmpp34_la-smpp34_params.Plo make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries' Makefile:460: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34' Makefile:368: recipe for target 'all' failed make: *** [all] Error 2 [WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully. Emitted 454 C/C++ compilation units (100%) successfully 454 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 osmocom at alteholz.de Thu Nov 2 18:26:45 2017 From: osmocom at alteholz.de (Thorsten Alteholz) Date: Thu, 2 Nov 2017 19:26:45 +0100 (CET) Subject: build slaves: deb8 + deb9? In-Reply-To: <20171101134827.GC1358@my.box> References: <20171101134827.GC1358@my.box> Message-ID: Hi, On Wed, 1 Nov 2017, Neels Hofmeyr wrote: > We currently do gerrit verifications on debian8-amd64 only. Only osmo-hlr has > also deb9 set as build slave to test. > > I'd move over to deb9 now and no longer build on deb8. > What do you guys think, should we build on both deb8 and deb9? is there a reason why you build the packages directly on the host? Wouldn't it be better to build it in a chroot (for example with sbuild like the Debian buildd). Thus you would be independent of the OS version of the host and could build for deb8, deb9, deb10, and whatever you want. Thorsten From laforge at gnumonks.org Thu Nov 2 20:57:44 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 02 Nov 2017 21:57:44 +0100 Subject: build slaves: deb8 + deb9? In-Reply-To: References: <20171101134827.GC1358@my.box> Message-ID: Well, they hardly build on a "host" anymore. Lots of them build in a docker image, and on build2, the Debian8 is a lxc container. Our goal is to move more builds to docker, and/or to create the build environment (whether lxc or docker or VM or chroot) automatically. For most builds that's easy, but for manuals, doxygen, coverity and some others it requires special privileges. One way to solve this is to build the special jobs only on very specific build slaves and use the regular (auto-generated) build slaves only for gerrit and non-gerrit buildjobs. -- Sent from a mobile device. Please excuse my brevity. From jenkins at lists.osmocom.org Fri Nov 3 16:09:54 2017 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Fri, 3 Nov 2017 16:09:54 +0000 (GMT) Subject: =?UTF-8?Q?Build_failed_in_Jenkins:_Coverity-?= =?UTF-8?Q?Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1659?= In-Reply-To: <589264158.53.1509638992683.JavaMail.jenkins@jenkins.osmocom.org> References: <589264158.53.1509638992683.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <2099833716.57.1509725394934.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 1.79 MB...] test_apps/Makefile.am:17: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:17: warning: source file '$(TESTAPPS_SOURCE_DIR)/esme.c' is in a subdirectory, test_apps/Makefile.am:17: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/generic_nack_test.c' is in a subdirectory, test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/outbind_test.c' is in a subdirectory, test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/tcp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/smpp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/sendwp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_test.c' is in a subdirectory, test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_test.c' is in a subdirectory, test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here binaries/Makefile.am: installing 'aux_config/depcomp' test_apps/Makefile.am:26: warning: variable 'analizer_SOURCES' is defined but no program or test_apps/Makefile.am:26: library has 'analizer' as canonical name (possible typo) test_apps/Makefile.am:17: warning: variable 'esme_SOURCES' is defined but no program or test_apps/Makefile.am:17: library has 'esme' as canonical name (possible typo) test_apps/Makefile.am:4: warning: variable 'sendwp_SOURCES' is defined but no program or test_apps/Makefile.am:4: library has 'sendwp' as canonical name (possible typo) test_apps/Makefile.am:30: warning: variable 'analizer_LDFLAGS' is defined but no program or test_apps/Makefile.am:30: library has 'analizer' as canonical name (possible typo) test_apps/Makefile.am:24: warning: variable 'esme_LDFLAGS' is defined but no program or test_apps/Makefile.am:24: library has 'esme' as canonical name (possible typo) test_apps/Makefile.am:11: warning: variable 'sendwp_LDFLAGS' is defined but no program or test_apps/Makefile.am:11: library has 'sendwp' as canonical name (possible typo) + ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom 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 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 stdlib.h... (cached) yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking for stdint.h... (cached) yes checking for string.h... (cached) yes checking for LIBXML2... no checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking for memset... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating def_frame/Makefile config.status: creating def_list/Makefile config.status: creating binaries/Makefile config.status: creating test_apps/Makefile config.status: creating libsmpp34.pc config.status: creating aux_config/config.h config.status: executing depfiles commands config.status: executing libtool commands + make -j 3 echo 1.12.0.11-0f76 > .version-t && mv .version-t .version make all-recursive make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34' Making all in binaries make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c -o libsmpp34_la-smpp34_dumpBuf.lo `test -f '../src/smpp34_dumpBuf.c' || echo './'`../src/smpp34_dumpBuf.c /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c -o libsmpp34_la-smpp34_dumpPdu.lo `test -f '../src/smpp34_dumpPdu.c' || echo './'`../src/smpp34_dumpPdu.c /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c -o libsmpp34_la-smpp34_pack.lo `test -f '../src/smpp34_pack.c' || echo './'`../src/smpp34_pack.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_pack.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpBuf.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpPdu.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -o libsmpp34_la-smpp34_dumpBuf.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_dumpBuf.Tpo .deps/libsmpp34_la-smpp34_dumpBuf.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c -o libsmpp34_la-smpp34_unpack.lo `test -f '../src/smpp34_unpack.c' || echo './'`../src/smpp34_unpack.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_unpack.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -o libsmpp34_la-smpp34_pack.o >/dev/null 2>&1 libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -o libsmpp34_la-smpp34_dumpPdu.o >/dev/null 2>&1 libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -o libsmpp34_la-smpp34_unpack.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_pack.Tpo .deps/libsmpp34_la-smpp34_pack.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c -o libsmpp34_la-smpp34_structs.lo `test -f '../src/smpp34_structs.c' || echo './'`../src/smpp34_structs.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_structs.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -o libsmpp34_la-smpp34_structs.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_structs.Tpo .deps/libsmpp34_la-smpp34_structs.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c -o libsmpp34_la-smpp34_params.lo `test -f '../src/smpp34_params.c' || echo './'`../src/smpp34_params.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_params.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -o libsmpp34_la-smpp34_params.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_unpack.Tpo .deps/libsmpp34_la-smpp34_unpack.Plo gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -fPIC -g -O2 -MT core.o -MD -MP -MF .deps/core.Tpo -c -o core.o `test -f '../test_pdu/core.c' || echo './'`../test_pdu/core.c mv -f .deps/libsmpp34_la-smpp34_dumpPdu.Tpo .deps/libsmpp34_la-smpp34_dumpPdu.Plo gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -fPIC -g -O2 -MT submit_multi_resp_test.o -MD -MP -MF .deps/submit_multi_resp_test.Tpo -c -o submit_multi_resp_test.o `test -f '../test_pdu/submit_multi_resp_test.c' || echo './'`../test_pdu/submit_multi_resp_test.c make[2]: *** No rule to make target '../binaries/libsmpp34.la', needed by 'submit_multi_resp_test'. Stop. make[2]: *** Waiting for unfinished jobs.... mv -f .deps/core.Tpo .deps/core.Po mv -f .deps/libsmpp34_la-smpp34_params.Tpo .deps/libsmpp34_la-smpp34_params.Plo mv -f .deps/submit_multi_resp_test.Tpo .deps/submit_multi_resp_test.Po make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries' Makefile:460: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34' Makefile:368: recipe for target 'all' failed make: *** [all] Error 2 [WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully. Emitted 454 C/C++ compilation units (100%) successfully 454 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 nhofmeyr at sysmocom.de Fri Nov 3 17:34:11 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 3 Nov 2017 18:34:11 +0100 Subject: New "osmocom:latest" package feed In-Reply-To: <20171030202806.cfeeynqemkkv7bul@nataraja> References: <20171028220059.7znzjsn3ae3hgbmg@nataraja> <20171030173926.GB9921@my.box> <20171030202806.cfeeynqemkkv7bul@nataraja> Message-ID: <20171103173411.ct7f37gsh2ri22q6@my.box> On Mon, Oct 30, 2017 at 09:28:06PM +0100, Harald Welte wrote: > I'm wondering if it wouldn't make more sense to have git branches (as opposed to tags) > for those "overall project releases". This way we could actually - if needed - add > fixes or other backports to the respective release branch in the repository, and > the OBS builds for that release would simply follow those branches? Until we backport something, a tag would suffice, but indeed, using branches could simplify (skip the need for) updating the git target for "network:osmocom:release-xyz" feeds. ~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 Nov 3 17:59:00 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 3 Nov 2017 18:59:00 +0100 Subject: GPRS EXperiments In-Reply-To: <2d735e03-3bd5-afb1-b7ba-31f794987492@rhizomatica.org> References: <2d735e03-3bd5-afb1-b7ba-31f794987492@rhizomatica.org> Message-ID: <20171103175900.a6nerjpxnk6hoclc@my.box> (BTW, for GPRS we use osmocom-net-gprs at lists.osmocom.org but admittedly, almost all osmocom communication is taking place on openbsc@) On Mon, Oct 30, 2017 at 12:12:03PM -0600, Keith wrote: > I've installed up to date versions of osmo-bts and osmo-pcu > on sysmobts 2050 hardware and it's working great! > Dynamic channels are really nice, with half rate TCH and AMR > working perfectly. Thanks for all that work! Good to hear that! > I configured pcodns1 in the ggsn to point to this DNS > server, AND I setup a port 53 redirect to catch quite a lot > of traffic from android that likes to just talk directly to > 8.8.8.8 anyway. Interesting, this sounds like it would make for a good wiki page on osmocom.org. > games. Such is the sad state of affairs on today's internet. > Fortunately, we have iptables and ip sets and we have AS > blocks assigned to certain bandwidth hungry corporations :-) So instead of compromising net neutrality by giving the rich more bandwidth, you do it by cutting the big ones out instead ;) > I have observed that if I initiate any data transfer from > the network side then the uplink is established. By the same > token, If I transfer a file from the network (http download > or some such), the same applies. The link stays active and > the IM chat session is very responsive alongside the file > transfer. Shortly after the file transfer completes, the > uplink is quiet again and the latency in the IM session > becomes a problem. It might be related to a basic problem we still have with data services: we don't cache anything. If a PDP context is still being established, we drop data transfers to the floor, instead of storing them and sending them through when the context is established. I'm personally not familiar with the details there, but that's my current understanding. So a first ping would get lost, a second one within a timeframe that still has the PDP context open will go through. I think the idea there is that generally, higher level data communication should attempt to resend, but in practice that often doesn't seem to work that well. Not sure how to configure the PDP context timeout, or whether we even can. Theoretically, if you had on your phone a regular ping running in the background ... it's ugly, but yea. Caching those first packets is quite complex, especially for SGSNs sitting on a small device like a sysmoBTS with limited memory. I guess something could be tried there, by limiting resources used for caching in intelligent ways... Someone would need to fund that, or go ahead and try. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jenkins at lists.osmocom.org Sat Nov 4 16:09:50 2017 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Sat, 4 Nov 2017 16:09:50 +0000 (GMT) Subject: =?UTF-8?Q?Build_failed_in_Jenkins:_Coverity-?= =?UTF-8?Q?Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1660?= In-Reply-To: <2099833716.57.1509725394934.JavaMail.jenkins@jenkins.osmocom.org> References: <2099833716.57.1509725394934.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <1663046189.60.1509811791023.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 1.84 MB...] test_apps/Makefile.am:17: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:17: warning: source file '$(TESTAPPS_SOURCE_DIR)/esme.c' is in a subdirectory, test_apps/Makefile.am:17: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/generic_nack_test.c' is in a subdirectory, test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/outbind_test.c' is in a subdirectory, test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/tcp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/smpp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/sendwp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_test.c' is in a subdirectory, test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_test.c' is in a subdirectory, test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here binaries/Makefile.am: installing 'aux_config/depcomp' test_apps/Makefile.am:26: warning: variable 'analizer_SOURCES' is defined but no program or test_apps/Makefile.am:26: library has 'analizer' as canonical name (possible typo) test_apps/Makefile.am:17: warning: variable 'esme_SOURCES' is defined but no program or test_apps/Makefile.am:17: library has 'esme' as canonical name (possible typo) test_apps/Makefile.am:4: warning: variable 'sendwp_SOURCES' is defined but no program or test_apps/Makefile.am:4: library has 'sendwp' as canonical name (possible typo) test_apps/Makefile.am:30: warning: variable 'analizer_LDFLAGS' is defined but no program or test_apps/Makefile.am:30: library has 'analizer' as canonical name (possible typo) test_apps/Makefile.am:24: warning: variable 'esme_LDFLAGS' is defined but no program or test_apps/Makefile.am:24: library has 'esme' as canonical name (possible typo) test_apps/Makefile.am:11: warning: variable 'sendwp_LDFLAGS' is defined but no program or test_apps/Makefile.am:11: library has 'sendwp' as canonical name (possible typo) + ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom 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 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 stdlib.h... (cached) yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking for stdint.h... (cached) yes checking for string.h... (cached) yes checking for LIBXML2... no checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking for memset... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating def_frame/Makefile config.status: creating def_list/Makefile config.status: creating binaries/Makefile config.status: creating test_apps/Makefile config.status: creating libsmpp34.pc config.status: creating aux_config/config.h config.status: executing depfiles commands config.status: executing libtool commands + make -j 3 echo 1.12.0.11-0f76 > .version-t && mv .version-t .version make all-recursive make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34' Making all in binaries make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c -o libsmpp34_la-smpp34_dumpBuf.lo `test -f '../src/smpp34_dumpBuf.c' || echo './'`../src/smpp34_dumpBuf.c /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c -o libsmpp34_la-smpp34_dumpPdu.lo `test -f '../src/smpp34_dumpPdu.c' || echo './'`../src/smpp34_dumpPdu.c /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c -o libsmpp34_la-smpp34_pack.lo `test -f '../src/smpp34_pack.c' || echo './'`../src/smpp34_pack.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpPdu.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_pack.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpBuf.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -o libsmpp34_la-smpp34_dumpBuf.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_dumpBuf.Tpo .deps/libsmpp34_la-smpp34_dumpBuf.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c -o libsmpp34_la-smpp34_unpack.lo `test -f '../src/smpp34_unpack.c' || echo './'`../src/smpp34_unpack.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_unpack.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -o libsmpp34_la-smpp34_pack.o >/dev/null 2>&1 libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -o libsmpp34_la-smpp34_dumpPdu.o >/dev/null 2>&1 libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -o libsmpp34_la-smpp34_unpack.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_pack.Tpo .deps/libsmpp34_la-smpp34_pack.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c -o libsmpp34_la-smpp34_structs.lo `test -f '../src/smpp34_structs.c' || echo './'`../src/smpp34_structs.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_structs.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -o libsmpp34_la-smpp34_structs.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_structs.Tpo .deps/libsmpp34_la-smpp34_structs.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c -o libsmpp34_la-smpp34_params.lo `test -f '../src/smpp34_params.c' || echo './'`../src/smpp34_params.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_params.o mv -f .deps/libsmpp34_la-smpp34_dumpPdu.Tpo .deps/libsmpp34_la-smpp34_dumpPdu.Plo gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -fPIC -g -O2 -MT core.o -MD -MP -MF .deps/core.Tpo -c -o core.o `test -f '../test_pdu/core.c' || echo './'`../test_pdu/core.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -o libsmpp34_la-smpp34_params.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_unpack.Tpo .deps/libsmpp34_la-smpp34_unpack.Plo gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -fPIC -g -O2 -MT submit_multi_resp_test.o -MD -MP -MF .deps/submit_multi_resp_test.Tpo -c -o submit_multi_resp_test.o `test -f '../test_pdu/submit_multi_resp_test.c' || echo './'`../test_pdu/submit_multi_resp_test.c make[2]: *** No rule to make target '../binaries/libsmpp34.la', needed by 'submit_multi_resp_test'. Stop. make[2]: *** Waiting for unfinished jobs.... mv -f .deps/core.Tpo .deps/core.Po mv -f .deps/submit_multi_resp_test.Tpo .deps/submit_multi_resp_test.Po mv -f .deps/libsmpp34_la-smpp34_params.Tpo .deps/libsmpp34_la-smpp34_params.Plo make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries' Makefile:460: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34' Makefile:368: recipe for target 'all' failed make: *** [all] Error 2 [WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully. Emitted 454 C/C++ compilation units (100%) successfully 454 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 pespin at sysmocom.de Sat Nov 4 21:11:19 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Sat, 4 Nov 2017 22:11:19 +0100 Subject: =?UTF-8?Q?Re:_Build_failed_in_Jenkins:_Coverity-Upload_=c2=bb_linux?= =?UTF-8?Q?=5famd64=5fdebian8_#1660?= In-Reply-To: <1663046189.60.1509811791023.JavaMail.jenkins@jenkins.osmocom.org> References: <2099833716.57.1509725394934.JavaMail.jenkins@jenkins.osmocom.org> <1663046189.60.1509811791023.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: Hi, It seems to be failing because libsmpp34 is built with "make -j 3" and afaik it doesn't support parallel compilation. I've seen the same error when doing that myself iirc. -- - 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 lorenzo.cavallini at gmail.com Sun Nov 5 15:26:10 2017 From: lorenzo.cavallini at gmail.com (Lorenzo Cavallini) Date: Sun, 05 Nov 2017 16:26:10 +0100 Subject: GPRS on Ettus B210 hardware Message-ID: <1509895570.19663.11.camel@gmail.com> Hello everyone, I'm trying to setup OpenBSC to use GPRS on Ettus hardware with (B210). I followed what's written here more or less: https://osmocom.org/projec ts/cellular-infrastructure/wiki/OpenBSC_GPRS however for some reason I cannot get this to work. This is the first time that I try to setup GPRS with OpenBSC and even though I have a lot of experience working with OpenBSC for 2G stuff, this time I cannot figure out what's wrong. Here's the log from osmo-bts-trx when osmo-pcu connects: <0001> oml.c:76 Sending PCU version report to BSC: 0.4.0.2-bfc5 <0009> pcu_sock.c:336 Sending data indication: sapi=BCCH arfcn=0 block=0 data=01 06 00 90 00 19 5a 6f c9 e0 84 10 ab 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0009> pcu_sock.c:588 Activate request received: TRX=0 TX=2 <0000> rsl.c:669 (bts=0,trx=0,ts=2,ss=0) not sending CHAN ACT ACK <0009> pcu_sock.c:588 Activate request received: TRX=0 TX=3 <0000> rsl.c:669 (bts=0,trx=0,ts=3,ss=0) not sending CHAN ACT ACK <0009> pcu_sock.c:588 Activate request received: TRX=0 TX=4 <0000> rsl.c:669 (bts=0,trx=0,ts=4,ss=0) not sending CHAN ACT ACK <0009> pcu_sock.c:588 Activate request received: TRX=0 TX=5 <0000> rsl.c:669 (bts=0,trx=0,ts=5,ss=0) not sending CHAN ACT ACK <0009> pcu_sock.c:588 Activate request received: TRX=0 TX=6 <0000> rsl.c:669 (bts=0,trx=0,ts=6,ss=0) not sending CHAN ACT ACK <0009> pcu_sock.c:588 Activate request received: TRX=0 TX=7 <0000> rsl.c:669 (bts=0,trx=0,ts=7,ss=0) not sending CHAN ACT ACK <0009> pcu_sock.c:307 Sending rts request: is_ptcch=0 arfcn=0 block=0 <0009> pcu_sock.c:487 Data request received: sapi=PDTCH arfcn=514 block=0 data=47 94 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0009> pcu_sock.c:307 Sending rts request: is_ptcch=0 arfcn=0 block=1 <0009> pcu_sock.c:487 Data request received: sapi=PDTCH arfcn=514 block=1 data=47 94 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0009> pcu_sock.c:307 Sending rts request: is_ptcch=0 arfcn=0 block=2 <0009> pcu_sock.c:487 Data request received: sapi=PDTCH arfcn=514 block=2 data=47 94 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0009> pcu_sock.c:307 Sending rts request: is_ptcch=1 arfcn=1 block=0 <0009> pcu_sock.c:487 Data request received: sapi=PTCCH arfcn=1 block=0 data=2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0009> pcu_sock.c:307 Sending rts request: is_ptcch=0 arfcn=0 block=3 <0009> pcu_sock.c:487 Data request received: sapi=PDTCH arfcn=514 block=3 data=47 94 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0009> pcu_sock.c:307 Sending rts request: is_ptcch=0 arfcn=0 block=4 <0009> pcu_sock.c:487 Data request received: sapi=PDTCH arfcn=514 block=4 data=47 94 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b the last part (Sending rts request: ...) just repeats over and over. Here's the log from osmo-pcu: <000b> telnet_interface.c:101 telnet at 127.0.0.1 4240 <0001> osmobts_sock.cpp:229 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:288 osmo-bts PCU socket /tmp/pcu_bts has been connected <0001> osmobts_sock.cpp:292 Sending version 0.4.0.2-bfc5 to BTS. <0001> pcu_l1_if.cpp:107 Sending 0.4.0.2-bfc5 TXT as PCU_VERSION to BTS <0001> pcu_l1_if.cpp:427 BTS available <0008> gprs_ns.c:263 NSVCI=65534 Creating NS-VC <0008> gprs_ns.c:1619 Listening for nsip packets from 127.0.0.1:23000 on 0.0.0.0:23000 <0008> gprs_ns.c:1638 NS UDP socket at 0.0.0.0:23000 <0008> gprs_ns.c:263 NSVCI=1800 Creating NS-VC <0008> gprs_ns.c:1656 NSEI=1800 RESET procedure based on API request <0008> gprs_ns.c:446 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) <0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=2 <0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=2 <0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=3 <0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=3 <0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=4 <0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=4 <0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=5 <0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=5 <0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=6 <0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=6 <0001> pcu_l1_if.cpp:119 Sending activate request: trx=0 ts=7 <0001> pcu_l1_if.cpp:554 PDCH: trx=0 ts=7 <0008> gprs_ns.c:887 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) <0008> gprs_ns.c:707 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) <0008> gprs_ns.c:995 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) <0008> gprs_ns.c:1004 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 <0008> gprs_ns.c:555 NSEI=1800 Tx NS UNBLOCK (NSVCI=1800) <0008> gprs_ns.c:1411 NSEI=1800 Rx NS UNBLOCK <000a> gprs_bssgp_pcu.cpp:541 NS-VC 1800 is unblocked. <0009> gprs_bssgp_pcu.cpp:820 Sending reset on BVCI 0 <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=0) Tx BVC-RESET CAUSE=O&M intervention <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <0008> gprs_ns.c:1417 NSEI=1800 Rx NS UNBLOCK ACK <0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK <0009> gprs_bssgp_pcu.cpp:828 Sending reset on BVCI 1800 <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <0009> gprs_bssgp.c:301 Cell 901-70-1-0 CI 0 on BVCI 1800 <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <0009> gprs_bssgp.c:301 Cell 901-70-1-0 CI 0 on BVCI 1800 <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK <0009> gprs_bssgp_pcu.cpp:836 Sending unblock on BVCI 1800 <0009> gprs_bssgp_bss.c:270 BSSGP (BVCI=1800) Tx BVC-BLOCK <0009> gprs_bssgp.c:301 Cell 901-70-1-0 CI 0 on BVCI 1800 <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK <0009> gprs_bssgp_pcu.cpp:836 Sending unblock on BVCI 1800 <0009> gprs_bssgp_bss.c:270 BSSGP (BVCI=1800) Tx BVC-BLOCK <0009> gprs_bssgp.c:301 Cell 901-70-1-0 CI 0 on BVCI 1800 <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <0009> gprs_bssgp_pcu.cpp:349 Rx BSSGP BVCI=0 (SIGN) PDU type BVC- UNBLOCK unknown <0009> gprs_bssgp_util.c:236 BSSGP BVCI=0 Tx STATUS, cause=Protocol error - unspecified <0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK <0009> gprs_bssgp_pcu.cpp:836 Sending unblock on BVCI 1800 <0009> gprs_bssgp_bss.c:270 BSSGP (BVCI=1800) Tx BVC-BLOCK <0009> gprs_bssgp.c:301 Cell 901-70-1-0 CI 0 on BVCI 1800 <0009> gprs_bssgp_bss.c:290 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <0009> gprs_bssgp_pcu.cpp:349 Rx BSSGP BVCI=0 (SIGN) PDU type BVC- UNBLOCK unknown <0009> gprs_bssgp_util.c:236 BSSGP BVCI=0 Tx STATUS, cause=Protocol error - unspecified <0009> gprs_bssgp_pcu.cpp:299 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK and like osmo-bts-trx, the last part (Sending unblock ...) repeats forever. Basically the two processes are stuck like these and nothing works, only 2G. The other components (ggsn, osmo-sgsn and osmo-nitb) seems to be fine, I'm not getting any error output in the their logs. The configuration should be fine, I just followed the mentioned link and all the components can talk to each other, so it's not an ip/port issue on my local system. Any help in this would be appreciated. Reading this ML seems like GPRS works for everyone except me...might be related to Ettus B210, I don't know to be honest, but I had no issue so far with OpenBSC and 2G. Eventually I can debug the source and provide more information if required. Everything was built from latest git repositories, might be related to recent split in osmo-nitb and gprs? Thanks for your help! Lorenzo From jenkins at lists.osmocom.org Sun Nov 5 16:14:38 2017 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Sun, 5 Nov 2017 16:14:38 +0000 (GMT) Subject: =?UTF-8?Q?Jenkins_build_is_back_to_normal_:_Cove?= =?UTF-8?Q?rity-Upload_=C2=BB_linux=5Famd64=5Fdebian8_#1661?= In-Reply-To: <1663046189.60.1509811791023.JavaMail.jenkins@jenkins.osmocom.org> References: <1663046189.60.1509811791023.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <866144330.63.1509898478910.JavaMail.jenkins@jenkins.osmocom.org> See From laforge at gnumonks.org Sun Nov 5 19:28:34 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 6 Nov 2017 04:28:34 +0900 Subject: Build failed in =?iso-8859-1?Q?Jenkins?= =?iso-8859-1?Q?=3A_Coverity-Upload_=BB?= linux_amd64_debian8 #1660 In-Reply-To: References: <2099833716.57.1509725394934.JavaMail.jenkins@jenkins.osmocom.org> <1663046189.60.1509811791023.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <20171105192834.7wrvqgwwpozypskf@nataraja> Hi Pau, On Sat, Nov 04, 2017 at 10:11:19PM +0100, Pau Espin Pedrol wrote: > It seems to be failing because libsmpp34 is built with "make -j 3" and afaik > it doesn't support parallel compilation. I've seen the same error when doing > that myself iirc. would have been great to see a patch against the respective osmo-ci.git script submitted to gerrit. I did follow-up on that yesterday (see http://git.osmocom.org/osmo-ci/commit/?id=43aa00dbd4f0b3cca7708f21494ee0229e390b76) and it seemed to work fine. -- - 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 Tue Nov 7 01:26:11 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 7 Nov 2017 02:26:11 +0100 Subject: building osmo-iuh and libsctp Message-ID: <20171107012611.g32yvrgwipzu2yb5@my.box> I've recently upgraded my OS to debian 9 and suddenly have difficulty building osmo-iuh: the osmo-hnbgw linking step complains about a missing sctp_send, which is resolved by adding -lsctp to LDADD. But I'm puzzled why this comes from a system upgrade and not a code change. Does anyone have an idea what could cause this, or what would have hidden the linking error before? What's the proper way to add -lsctp? The dependency comes from libosmo-ranap using libosmo-sigtran - should the libosmo-sigtran.pc include -lsctp? - should we add a libsctp detection to osmo-iuh's configure.ac (copy from libosmo-sccp) and use $(SCTP_LIBS) constants in Makefile.am LDADD? - is everything correct and my OS has a problem instead? Thanks for any input... ~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 Tue Nov 7 05:05:25 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 7 Nov 2017 14:05:25 +0900 Subject: building osmo-iuh and libsctp In-Reply-To: <20171107012611.g32yvrgwipzu2yb5@my.box> References: <20171107012611.g32yvrgwipzu2yb5@my.box> Message-ID: <20171107050525.vy4jy3kqahbuemp5@nataraja> Hi Neels, On Tue, Nov 07, 2017 at 02:26:11AM +0100, Neels Hofmeyr wrote: > I've recently upgraded my OS to debian 9 and suddenly have difficulty building > osmo-iuh: the osmo-hnbgw linking step complains about a missing sctp_send, > which is resolved by adding -lsctp to LDADD. But I'm puzzled why this comes > from a system upgrade and not a code change. Does anyone have an idea what > could cause this, or what would have hidden the linking error before? I agree, it's puzzling. > What's the proper way to add -lsctp? The dependency comes from libosmo-ranap > using libosmo-sigtran > - should the libosmo-sigtran.pc include -lsctp? yes, but I'm not sure if it's the right way to simply hard-code it in libosmo-sigtran.pc.in, or if it (possibly rather) should be the result of `pkg-config --libs libsctp` > - should we add a libsctp detection to osmo-iuh's configure.ac (copy from > libosmo-sccp) and use $(SCTP_LIBS) constants in Makefile.am LDADD? no, that's clearly wrong, as sctp_send symbol is (according to your statement) used by libosmo-sigtrn and not directly by libosmo-ranap or osmo-iuh. > - is everything correct and my OS has a problem instead? the interesting question is why it's suddenly failing now, and why e.g. I don't have any build errors on debian unstable here. Or why the debian9 package generation on OBS is working. -- - 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 Nov 7 09:28:02 2017 From: ron.menez at entropysolution.com (Ron) Date: Tue, 7 Nov 2017 09:28:02 +0000 Subject: Whitelisting/Blacklisiting of IMSI Message-ID: <09E301EC-DAB2-4A49-95A6-77DC93191F6D@entropysolution.com> Hi All, May we request on how to allow specific number of IMSI in OSMO-BSC? We tried the following using the REGEXP below, but all kinds of IMSIs are still able to camp. First try: auth policy regexp authorized-regexp ^12312\d{10}$ Second try: auth policy regexp authorized-regexp 12312\d{10} We also tried to used the access-list imsi-allow under BSC and then declare it under MSC configuration but still has the same behavior. All kinds of IMSIs are still allowed. First try: bsc access-list TEST imsi-allow ^12312\d{10}$ access-list-name TEST msc 0 access-list-name TEST Second try: bsc access-list TEST imsi-allow 12312\d{10} access-list-name TEST msc 0 access-list-name TEST We also tried to to used the access-list imsi-deny using the same regular expressions, unfortunately, still have the same outcome. All IMSIs are still allowed. First try: bsc access-list TEST imsi-deny ^12312\d{10}$ 16 16 access-list-name TEST msc 0 access-list-name TEST Second try: bsc access-list TEST imsi-deny ^12312\d{10}$ 16 16 access-list-name TEST msc 0 access-list-name TEST But using access-list imsi-deny to a specific IMSI, we successfully block it. Is there a way to block a number of different IMSIs only? What regular expression format is used by OSMO-BSC? Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Tue Nov 7 11:33:23 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 7 Nov 2017 12:33:23 +0100 Subject: GPRS on Ettus B210 hardware In-Reply-To: <1509895570.19663.11.camel@gmail.com> References: <1509895570.19663.11.camel@gmail.com> Message-ID: <20171107113323.GA2896@ass40.sysmocom.de> Hi Lorenzo, please note that that wiki page hasn't been updated in a while. Most of it should have remained the same though. On Sun, Nov 05, 2017 at 04:26:10PM +0100, Lorenzo Cavallini wrote: > <0008> gprs_ns.c:263 NSVCI=65534 Creating NS-VC [...] > <0008> gprs_ns.c:707 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) > <0008> gprs_ns.c:995 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) > <0008> gprs_ns.c:1004 NS RESET ACK Discarding unexpected message for > NS-VCI 1800 from SGSN NSEI=1800 looking at the source code for this, it seems that your setup is not expecting a RESET ACK for that particular NSEI / NSVCI. Maybe some setting still mismatches? If you can't find anything, do also send your config files along. I'll also point you at the new wiki page for the split setup that includes GPRS -- but it isn't fully verified yet and doesn't include PCU setup: https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From pespin at sysmocom.de Tue Nov 7 11:36:03 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 7 Nov 2017 12:36:03 +0100 Subject: Range of "ipa unit-id" site_id vty config Message-ID: Hi, I see the range for ipa unit-d site_id range of values is 0-65534 as configured in the VTY: osmo-bts/src/common/vty.c 397: "ipa unit-id <0-65534> <0-255>", However, being it a uint16_t having 2^16=65536 values, I would expect the range to be 0-65535 (finished in 5, not 4). The only reason I can think of is that the last address is somehow reserved and must not be used. Does somebody know if that's the case? I couldn't find any documentation and as far as I can tell our code doesn't seem to handle the site_id=65535 case specially. If it is not reserved, then I can send a patch to change the range to be 0-65535. I actually see the same range pattern in lots of places around osmocom vty parameters, which makes me think somebody may have initially introduced the wrong number and then people have been copy-pasting the same number over and over again when adding new parameters: $ ag "0-65534" libosmocore/src/gb/gprs_ns_vty.c 269: "nse <0-65535> nsvci <0-65534>", libosmo-sccp/src/osmo_ss7_vty.c 420: "listen " XUA_VAR_STR " <0-65534>", 442: "no listen " XUA_VAR_STR " <0-65534>", osmo-sgsn/src/gprs/gb_proxy_vty.c 149: "sgsn nsei <0-65534>", 364: "secondary-sgsn nsei <0-65534>", 532: "delete-gbproxy-peer <0-65534> bvci <2-65534>", 553: "delete-gbproxy-peer <0-65534> (only-bvc|only-nsvc|all) [dry-run]", 626: "delete-gbproxy-link <0-65534> (tlli|imsi|sgsn-nsei) IDENT", 698: "delete-gbproxy-link <0-65534> (stale|de-registered)", osmo-bsc/src/libbsc/bsc_vty.c 1850: "ip.access unit_id <0-65534> <0-255>", openbsc/openbsc/src/libmgcp/mgcp_vty.c 294: "bind port <0-65534>", 337: "rtp bts-base <0-65534>", 350: "rtp bts-range <0-65534> <0-65534>", 360: "rtp net-range <0-65534> <0-65534>", 370: "rtp net-base <0-65534>", 378: "rtp base <0-65534>", 383: "rtp transcoder-range <0-65534> <0-65534>", 393: "rtp transcoder-base <0-65534>", 596: "number endpoints <0-65534>", 755: "transcoder-remote-base <0-65534>", 1119: "tap-call <0-64> ENDPOINT (bts-in|bts-out|net-in|net-out) A.B.C.D <0-65534>", openbsc/openbsc/src/libbsc/bsc_vty.c 1803: "ip.access unit_id <0-65534> <0-255>", osmo-mgw/src/libosmo-mgcp-client/mgcp_client_vty.c 130: "mgw bts-base <0-65534>", 140: "mgcpgw bts-base <0-65534>", osmo-mgw/src/libosmo-legacy-mgcp/mgcp_vty.c 294: "bind port <0-65534>", 337: "rtp bts-base <0-65534>", 350: "rtp bts-range <0-65534> <0-65534>", 360: "rtp net-range <0-65534> <0-65534>", 370: "rtp net-base <0-65534>", 378: "rtp base <0-65534>", 383: "rtp transcoder-range <0-65534> <0-65534>", 393: "rtp transcoder-base <0-65534>", 606: "number endpoints <0-65534>", 765: "transcoder-remote-base <0-65534>", 1130: "tap-call <0-64> ENDPOINT (bts-in|bts-out|net-in|net-out) A.B.C.D <0-65534>", osmo-mgw/src/libosmo-mgcp/mgcp_vty.c 264: "bind port <0-65534>", 297: "rtp net-range <0-65534> <0-65534>", 509: "number endpoints <0-65534>", 947: "tap-rtp <0-64> ENDPOINT CONN (in|out) A.B.C.D <0-65534>", osmo-bts/src/common/vty.c 397: "ipa unit-id <0-65534> <0-255>", 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 nhofmeyr at sysmocom.de Tue Nov 7 11:43:30 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 7 Nov 2017 12:43:30 +0100 Subject: building osmo-iuh and libsctp In-Reply-To: <20171107050525.vy4jy3kqahbuemp5@nataraja> References: <20171107012611.g32yvrgwipzu2yb5@my.box> <20171107050525.vy4jy3kqahbuemp5@nataraja> Message-ID: <20171107114330.GC2896@ass40.sysmocom.de> I guess I need to investigate some more...... ~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 Nov 7 13:01:41 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 7 Nov 2017 14:01:41 +0100 Subject: Range of "ipa unit-id" site_id vty config In-Reply-To: References: Message-ID: <20171107130141.GD2896@ass40.sysmocom.de> Hmm, looks like a general policy to keep the 0xffff available as special value in case we ever need it, rather than a correctness requirement. I think though it's not worth the trouble changing all of those, because it entails checking each and every one to be absolutely sure. About the recent gsm-tester patches: I'd rather have a is_int(min, max) function in osmo-gsm-tester and leave the values as-is. For that validator you can return a lambda like def int_validator(min=0, max=65535): return lambda x: x >= min and x <= max ~N -------------- 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 Tue Nov 7 21:16:24 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 8 Nov 2017 06:16:24 +0900 Subject: Range of "ipa unit-id" site_id vty config In-Reply-To: References: Message-ID: <20171107211624.kejxxh2jlvgjaus7@nataraja> On Tue, Nov 07, 2017 at 12:36:03PM +0100, Pau Espin Pedrol wrote: > Hi, > > I see the range for ipa unit-d site_id range of values is 0-65534 as > configured in the VTY: > > osmo-bts/src/common/vty.c > 397: "ipa unit-id <0-65534> <0-255>", > > osmo-bsc/src/libbsc/bsc_vty.c > 1850: "ip.access unit_id <0-65534> <0-255>", > > openbsc/openbsc/src/libbsc/bsc_vty.c > 1803: "ip.access unit_id <0-65534> <0-255>", > > osmo-bts/src/common/vty.c > 397: "ipa unit-id <0-65534> <0-255>", > > However, being it a uint16_t having 2^16=65536 values, I would expect the > range to be 0-65535 (finished in 5, not 4). The only reason I can think of > is that the last address is somehow reserved and must not be used. Does > somebody know if that's the case? I couldn't find any documentation and as > far as I can tell our code doesn't seem to handle the site_id=65535 case > specially. If it is not reserved, then I can send a patch to change the > range to be 0-65535. I don't actually know, as we don't know what ip.access' thoughts were when designing this. There mihgt be something we forgot. I'd vote to keep as-is as it doesn't hurt to have one less unit id vs. the risk to break some setup. > $ ag "0-65534" > libosmocore/src/gb/gprs_ns_vty.c > 269: "nse <0-65535> nsvci <0-65534>", > osmo-sgsn/src/gprs/gb_proxy_vty.c > 149: "sgsn nsei <0-65534>", > 364: "secondary-sgsn nsei <0-65534>", > 532: "delete-gbproxy-peer <0-65534> bvci <2-65534>", > 553: "delete-gbproxy-peer <0-65534> (only-bvc|only-nsvc|all) [dry-run]", > 626: "delete-gbproxy-link <0-65534> (tlli|imsi|sgsn-nsei) IDENT", > 698: "delete-gbproxy-link <0-65534> (stale|de-registered)", I cannot find any reference in 08.14 or 01.16 to why NSVCI 0xffff is reserved, so it could be changed > libosmo-sccp/src/osmo_ss7_vty.c > 420: "listen " XUA_VAR_STR " <0-65534>", > 442: "no listen " XUA_VAR_STR " <0-65534>", > > openbsc/openbsc/src/libmgcp/mgcp_vty.c > 294: "bind port <0-65534>", > 337: "rtp bts-base <0-65534>", > 350: "rtp bts-range <0-65534> <0-65534>", > 360: "rtp net-range <0-65534> <0-65534>", > 370: "rtp net-base <0-65534>", > 378: "rtp base <0-65534>", > 383: "rtp transcoder-range <0-65534> <0-65534>", > 393: "rtp transcoder-base <0-65534>", > 755: "transcoder-remote-base <0-65534>", > 1119: "tap-call <0-64> ENDPOINT (bts-in|bts-out|net-in|net-out) A.B.C.D <0-65534>", > > osmo-mgw/src/libosmo-mgcp-client/mgcp_client_vty.c > 130: "mgw bts-base <0-65534>", > 140: "mgcpgw bts-base <0-65534>", > > osmo-mgw/src/libosmo-legacy-mgcp/mgcp_vty.c > 294: "bind port <0-65534>", > 337: "rtp bts-base <0-65534>", > 350: "rtp bts-range <0-65534> <0-65534>", > 360: "rtp net-range <0-65534> <0-65534>", > 370: "rtp net-base <0-65534>", > 378: "rtp base <0-65534>", > 383: "rtp transcoder-range <0-65534> <0-65534>", > 393: "rtp transcoder-base <0-65534>", > 765: "transcoder-remote-base <0-65534>", > 1130: "tap-call <0-64> ENDPOINT (bts-in|bts-out|net-in|net-out) A.B.C.D <0-65534>", > > osmo-mgw/src/libosmo-mgcp/mgcp_vty.c > 264: "bind port <0-65534>", > 297: "rtp net-range <0-65534> <0-65534>", > 947: "tap-rtp <0-64> ENDPOINT CONN (in|out) A.B.C.D <0-65534>", port numbers go to 65535, so all the above can be changed. > openbsc/openbsc/src/libmgcp/mgcp_vty.c > 596: "number endpoints <0-65534>", > > osmo-mgw/src/libosmo-legacy-mgcp/mgcp_vty.c > 606: "number endpoints <0-65534>", > > osmo-mgw/src/libosmo-mgcp/mgcp_vty.c > 509: "number endpoints <0-65534>", not sure. dexter as done lots of work on the code, he should be able to comment -- - 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 Wed Nov 8 02:50:49 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 8 Nov 2017 03:50:49 +0100 Subject: gerrit disk was full Message-ID: <20171108025049.r7l6ox6d6xbujbys@my.box> Just now the gerrit disk quota filled up. It hit the limit at 7.6G disk usage. I gave it 10G of space via zfs to not get pulled in too deeply, we may want to investigate whether anything filled it up unintendedly/erratically. When I look at the listing I made when writing https://osmocom.org/projects/osmocom-servers/wiki/Osmocomorg_Web_Servers gerrit already had 7.19 G disk usage then. It seems some snapshot may have filled up the rest now, and the remaining 400Mb are from new commit objects / repos repack? It's too late now for me to wait for a du to complete... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From lorenzo.cavallini at gmail.com Wed Nov 8 09:07:11 2017 From: lorenzo.cavallini at gmail.com (Lorenzo Cavallini) Date: Wed, 8 Nov 2017 10:07:11 +0100 Subject: GPRS on Ettus B210 hardware In-Reply-To: <20171107113323.GA2896@ass40.sysmocom.de> References: <1509895570.19663.11.camel@gmail.com> <20171107113323.GA2896@ass40.sysmocom.de> Message-ID: Hi, thanks for your answer. You are right, it was a configuration problem related to the SGSN. In particular, the encapsulation local-ip parameter in the ns section. I was using the same value used for gtp localip, but this was creating the issue. Now I set this ip to some random local ip (127.0.0.10) and it works fine. Can you explain what the encapsulation setting is actually doing? The documentation is not very clear on this, I thought this was supposed to be the same value as the gtp localip. Everything else is working fine anyway. By the way, do you recommend to switch to the "split" architecture right now? Or is there a timeline for when OsmoNITB will be deprecated? Thanks! Lorenzo On Tue, Nov 7, 2017 at 12:33 PM, Neels Hofmeyr wrote: > Hi Lorenzo, > > please note that that wiki page hasn't been updated in a while. Most of it > should have remained the same though. > > On Sun, Nov 05, 2017 at 04:26:10PM +0100, Lorenzo Cavallini wrote: > > <0008> gprs_ns.c:263 NSVCI=65534 Creating NS-VC > [...] > > <0008> gprs_ns.c:707 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) > > <0008> gprs_ns.c:995 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) > > <0008> gprs_ns.c:1004 NS RESET ACK Discarding unexpected message for > > NS-VCI 1800 from SGSN NSEI=1800 > > looking at the source code for this, it seems that your setup is not > expecting a RESET ACK for that particular NSEI / NSVCI. Maybe some setting > still mismatches? > > If you can't find anything, do also send your config files along. > > I'll also point you at the new wiki page for the split setup that includes > GPRS -- but it isn't fully verified yet and doesn't include PCU setup: > https://osmocom.org/projects/cellular-infrastructure/wiki/ > Osmocom_Network_In_The_Box > > ~N > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Wed Nov 8 13:33:04 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 8 Nov 2017 14:33:04 +0100 Subject: GPRS on Ettus B210 hardware In-Reply-To: References: <1509895570.19663.11.camel@gmail.com> <20171107113323.GA2896@ass40.sysmocom.de> Message-ID: <20171108133304.hmi2rsr46bot7dce@my.box> On Wed, Nov 08, 2017 at 10:07:11AM +0100, Lorenzo Cavallini wrote: > Can you explain what the encapsulation setting is actually doing? It's the address where the PCU talks to the SGSN, so it needs to be reachable by your BSS. If you're on a single box (using osmo-trx or everything on one sysmoBTS) it can be a loopback (like you picked), otherwise it needs to be an IP on a public interface. The address is passed to osmo-bts, which in turn tells osmo-pcu where to find the SGSN. > I thought this was supposed to be the same value as the gtp localip. GTP is from the SGSN to the GGSN side: BSS | Core Network PCU <--GRPS-NS--> SGSN <--GTP--> GGSN > By the way, do you recommend to switch to the "split" architecture right now? > Or is there a timeline for when OsmoNITB will be deprecated? Thanks! It certainly doesn't make sense to set up a long term installation based on the OsmoNITB anymore: our development focus has already moved away from OsmoNITB, and as of now it will mainly sit there and age. The main remaining issue for the split components now is that the OsmoMSC still needs the old osmo-bsc_mgcp instead of the new osmo-mgw -- but that is going to change pretty soon and will be trivial to adjust. The other detail is that I am still busy verifying that the wiki pages that help you set up the split components are indeed accurate. So, you may still experience minor challenges finding your way across to a split installation, which we will be more than happy to help out with and iron out our documentation in the process. Infrastructure wise we have the split components tested in the osmo-gsm-tester every day, we have sysmoBTS images running the split components (201705 feed), we have nightly builds for all the programs in the form of Debian and Ubuntu feeds. The split components get you various juicy benefits, like one central HLR for MSC and SGSN, seamless 3G support and UMTS authentication (Milenage). And congratulations to your working setup :) ~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 Wed Nov 8 13:51:15 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 8 Nov 2017 14:51:15 +0100 Subject: Range of "ipa unit-id" site_id vty config In-Reply-To: <20171107211624.kejxxh2jlvgjaus7@nataraja> References: <20171107211624.kejxxh2jlvgjaus7@nataraja> Message-ID: <20171108135115.5r3ag42bjpsbbhfd@my.box> On Wed, Nov 08, 2017 at 06:16:24AM +0900, Harald Welte wrote: > > openbsc/openbsc/src/libmgcp/mgcp_vty.c > > 596: "number endpoints <0-65534>", > > > > osmo-mgw/src/libosmo-legacy-mgcp/mgcp_vty.c > > 606: "number endpoints <0-65534>", > > > > osmo-mgw/src/libosmo-mgcp/mgcp_vty.c > > 509: "number endpoints <0-65534>", > > not sure. dexter as done lots of work on the code, he should be able to comment heh, noticing now, if each endpoint has four or more RTP/C ports, while we have in total 65535 ports available, the number of endpoints will hardly ever be able to surpass 16384. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From keith at rhizomatica.org Wed Nov 8 14:58:46 2017 From: keith at rhizomatica.org (Keith) Date: Wed, 8 Nov 2017 09:58:46 -0500 Subject: GPRS EXperiments In-Reply-To: <20171103175900.a6nerjpxnk6hoclc@my.box> References: <2d735e03-3bd5-afb1-b7ba-31f794987492@rhizomatica.org> <20171103175900.a6nerjpxnk6hoclc@my.box> Message-ID: <22696755-a4fa-3d50-41e9-6bf5a3e21315@rhizomatica.org> On 03/11/2017 12:59, Neels Hofmeyr wrote: > So instead of compromising net neutrality by giving the rich more bandwidth, > you do it by cutting the big ones out instead ;) Hi Neels! Net Neutrality is a non-thing. It doesn't exist. Never has, never will. Therefore it cannot be compromised. While many net-freedom activists and net celebs have created a lot of blah blah blah and patted themselves on the back in recent years over this, the de-facto reality remains that the network infrastructure has never been free or anything that even resembles any definition of "free". Ask anybody who has had their small server DDOS'd off the network for political reasons, or any other reason. Today's internet belongs to the corporations and everyday more to those that control the physical infra, and those that have CDNs and POPs in every provider's datacentre. You simply cannot compete with that. The internet is pure capitalist, if you have money to buy access, you can have access and bandwidth to supply services, if not, then f**k you. Take a look at the price to the average consumer of anything more than a 256K or even 128K uplink in Mexico. The whole concept of "net neutrality" is toxic. Everytime we say or write the phrase, somewhere in the world, a baby penguin dies. My apologies to the list for drifting dangerously off topic. It (probably) won't happen again. ;-) k/ From pespin at sysmocom.de Wed Nov 8 16:53:34 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 8 Nov 2017 17:53:34 +0100 Subject: Range of "ipa unit-id" site_id vty config In-Reply-To: <20171107211624.kejxxh2jlvgjaus7@nataraja> References: <20171107211624.kejxxh2jlvgjaus7@nataraja> Message-ID: <0ccfb1da-b533-db8a-04bf-654a0624ac7c@sysmocom.de> On 07/11/17 22:16, Harald Welte wrote: > On Tue, Nov 07, 2017 at 12:36:03PM +0100, Pau Espin Pedrol wrote: >> Hi, >> >> I see the range for ipa unit-d site_id range of values is 0-65534 as >> configured in the VTY: >> >> osmo-bts/src/common/vty.c >> 397: "ipa unit-id <0-65534> <0-255>", >> >> osmo-bsc/src/libbsc/bsc_vty.c >> 1850: "ip.access unit_id <0-65534> <0-255>", >> >> openbsc/openbsc/src/libbsc/bsc_vty.c >> 1803: "ip.access unit_id <0-65534> <0-255>", >> >> osmo-bts/src/common/vty.c >> 397: "ipa unit-id <0-65534> <0-255>", >> >> However, being it a uint16_t having 2^16=65536 values, I would expect the >> range to be 0-65535 (finished in 5, not 4). The only reason I can think of >> is that the last address is somehow reserved and must not be used. Does >> somebody know if that's the case? I couldn't find any documentation and as >> far as I can tell our code doesn't seem to handle the site_id=65535 case >> specially. If it is not reserved, then I can send a patch to change the >> range to be 0-65535. > > I don't actually know, as we don't know what ip.access' thoughts were when > designing this. There mihgt be something we forgot. I'd vote to keep as-is > as it doesn't hurt to have one less unit id vs. the risk to break some setup. > >> $ ag "0-65534" >> libosmocore/src/gb/gprs_ns_vty.c >> 269: "nse <0-65535> nsvci <0-65534>", >> osmo-sgsn/src/gprs/gb_proxy_vty.c >> 149: "sgsn nsei <0-65534>", >> 364: "secondary-sgsn nsei <0-65534>", >> 532: "delete-gbproxy-peer <0-65534> bvci <2-65534>", >> 553: "delete-gbproxy-peer <0-65534> (only-bvc|only-nsvc|all) [dry-run]", >> 626: "delete-gbproxy-link <0-65534> (tlli|imsi|sgsn-nsei) IDENT", >> 698: "delete-gbproxy-link <0-65534> (stale|de-registered)", > > I cannot find any reference in 08.14 or 01.16 to why NSVCI 0xffff is reserved, > so it could be changed After having a quick deeper look, I saw the following written in libosmocore/src/gb/gprs_ns.c:53 * This implementation has the following limitations: * - Only one NS-VC for each NSE: No load-sharing function * - NSVCI 65535 and 65534 are reserved for internal use And I see several checks against 0xff and 0xfe in the code playing with dummy ids. I guess it's worth looking at it, because we should then either remove use of 65534 or try to fix the implementation and provide the 2 ports missing. But I agree it's probably not a high priority. -- - 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 nhofmeyr at sysmocom.de Thu Nov 9 04:40:13 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 9 Nov 2017 05:40:13 +0100 Subject: osmo-bsc access lists semantics are confusing Message-ID: <20171109044013.eif5botaudqiu5hy@my.box> I'm just now looking through osmo-bsc libfilter, and I would have expected a kind of top-down behavior like for firewalls: imsi-deny .* imsi-allow 12345.* imsi-deny 1234567.* imsi-allow 123456789.* imsi-deny .*[13579] i.e. start out denying everything. Except allow IMSIs starting with 12345. Except deny those that continue with 67. Unless they continue with 6789, allow those. Finally only service even-numbered IMSIs here. That would be quite powerful. Instead, what I see is that first, we go through the entire access list regarding only the allow-imsi entries. If any one of them matches, break the loop and return acceptance *right away*. If no accept rule matched, go through the list again, and see if any deny rule matches. If there is one, break and return failure right away. This was for the "local" per-msc rules, we also have a "global" rule set on the bsc level, which follows after that. For that, we currently actually completely ignore all allow rules, and only return error if any deny rule matches. In the end, if nothing matched, return acceptance. A code comment says that for the "global" rules, we want to deny first and accept second, so precisely reverse from the "local" level, but as a user I would find that rather confusing. See auth_imsi() in bsc_msg_filter.c. So in short, to get the intended behavior outlined above, you are forced to cram all rules into a single regex, sort of like imsi-allow 12345\(67\|6789\).*[02468] imsi-deny .* which I don't actually know how to express as you can see... or maybe imsi-allow 12345[^6].*[02468] imsi-allow 123456[^7].*[02468] imsi-deny .* My questions are: - Is it implemented this way for performance considerations? - Are we not going to change this, even assuming that we regard changes being useful, because we don't want to break with previous configs? - When looking in auth_imsi(), the access list names are: auth_imsi() name | comments | osmo-bsc passes bsc_lst "local" vty 'msc' level access rules nat_lst "global" vty 'bsc' level access rules Needless to say that "local", "global", "nat", "bsc" and "msc" are quite hard to follow. From the osmo-bsc filter code's perspective, there may be multiple MSCs configured, and per-msc config could be seen as more specific ("local") than bsc level, which applies to all MSCs ("global")... Was that the intention or is the local/global actually swapped by accident? (I notice that this feature seems to be intended for osmo-bsc-nat, and there's also a concept of a super-global blacklist that is always NULL in osmo-bsc.) Here's a patch to add imsi-allow evaluation on the "global" level; other than the comment says, I use the same order of 'allow' first and 'deny' second to be consistent: https://gerrit.osmocom.org/4750 Otherwise I believe this could benefit from some refactoring, but probably we don't have time/funding to care about that, do we... ~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 Thu Nov 9 05:22:50 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 9 Nov 2017 06:22:50 +0100 Subject: GPRS EXperiments In-Reply-To: <22696755-a4fa-3d50-41e9-6bf5a3e21315@rhizomatica.org> References: <2d735e03-3bd5-afb1-b7ba-31f794987492@rhizomatica.org> <20171103175900.a6nerjpxnk6hoclc@my.box> <22696755-a4fa-3d50-41e9-6bf5a3e21315@rhizomatica.org> Message-ID: <20171109052250.dhhmovu6gntlio5g@my.box> On Wed, Nov 08, 2017 at 09:58:46AM -0500, Keith wrote: > The whole concept of "net neutrality" is toxic. > > Everytime we say or write the phrase, somewhere in the > world, a baby penguin dies. > My apologies to the list for drifting dangerously off topic. > It (probably) won't happen again. Ah oh, you were actually posting on list, lol :) Reading up to now I assumed it was a private mail :D I accept your word on it not being a thing, but I'll keep net-neutrality as a utopian ideal phrase along with world peace and halting human made climate change. I hope creatures dying isn't causal to writing these phrases... I did like the Rap News issue on it: http://www.youtube.com/watch?v=k-xSP_T0VqU but surely the "sacred principle of stacking money" has been in it all the time. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From holger at freyther.de Thu Nov 9 06:39:51 2017 From: holger at freyther.de (Holger Freyther) Date: Thu, 9 Nov 2017 14:39:51 +0800 Subject: osmo-bsc access lists semantics are confusing In-Reply-To: <20171109044013.eif5botaudqiu5hy@my.box> References: <20171109044013.eif5botaudqiu5hy@my.box> Message-ID: <32F732F8-CD70-470D-9615-364FD6206081@freyther.de> > On 9. Nov 2017, at 12:40, Neels Hofmeyr wrote: > > My questions are: > > - Is it implemented this way for performance considerations? The performance consideration doesn't have anything to do with the order of matches. Not to use longest matching rule might be considered a performance consideration (both at runtime and implementation). Because there is no longest match a rule set (think of it in terms of first and then second rule) can not work. imsi-deny "all" imsi-allow "neels" In hindsight what would have been better is to define a policy "deny/allow" per access-list and then people can build opt-in or opt-out (allow every one but neels): access-list foo default allow access-list foo imsi-deny "neels" (deny everone one but neels): access-list foo default deny access-list foo imsi-allow "neels" Usecases where something like this. In this group only XYZ country IMSIs are allowed. But if you operate this as a testcell allow your own IMSI as well. Or for test cells.. No local IMSIs but allow my local IMSI. > - Are we not going to change this, even assuming that we regard changes being > useful, because we don't want to break with previous configs? I think any existing user of osmo-bsc already will already have difficulties to upgrade, changing the access lists might not make a big difference? > - When looking in auth_imsi(), the access list names are: > auth_imsi() name | comments | osmo-bsc passes > bsc_lst "local" vty 'msc' level access rules > nat_lst "global" vty 'bsc' level access rules > Needless to say that "local", "global", "nat", "bsc" and "msc" are quite > hard to follow. Sorry about that. I haven't looked at the code but it started in the NAT and then was generalized to be used in the BSC as well. > From the osmo-bsc filter code's perspective, there may be multiple MSCs > configured, and per-msc config could be seen as more specific ("local") than > bsc level, which applies to all MSCs ("global")... Was that the intention or > is the local/global actually swapped by accident? > (I notice that this feature seems to be intended for osmo-bsc-nat, and > there's also a concept of a super-global blacklist that is always NULL in > osmo-bsc.) super-global? Hehe. In terms of terminology and system. Upstream for the BSC is a MSC (or bsc-nat that emulates the A-link of a MSC) and the upstream for the bsc-nat is a real MSC (or another nat). Local depends where you are so just saying "BSC" might not be that clear either? holger From nhofmeyr at sysmocom.de Thu Nov 9 14:44:10 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 9 Nov 2017 15:44:10 +0100 Subject: OsmoBSC now *requires* an OsmoMGW to run alongside it Message-ID: <20171109144410.hnsrr44jirqkvuca@my.box> There has been a profound change in RTP handling by OsmoBSC: we now require an OsmoMGW to run alongside it to manage RTP streams, and to be able to provide intra-BSC handover. Kindly refer to https://osmocom.org/news/80 ~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 Fri Nov 10 00:54:29 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 10 Nov 2017 09:54:29 +0900 Subject: OsmoBSC now *requires* an OsmoMGW to run alongside it In-Reply-To: <20171109144410.hnsrr44jirqkvuca@my.box> References: <20171109144410.hnsrr44jirqkvuca@my.box> Message-ID: <20171110005429.oso4hc63fu65uju7@nataraja> Just to add to that: On Thu, Nov 09, 2017 at 03:44:10PM +0100, Neels Hofmeyr wrote: > There has been a profound change in RTP handling by OsmoBSC: we now require an > OsmoMGW to run alongside it to manage RTP streams, and to be able to provide > intra-BSC handover. Kindly refer to https://osmocom.org/news/80 This is only applicable to users of OsmoBSC from osmo-bsc.git (with 3GPP AoIP interface), and not to users of legacy OsmoBSC-SCCPlite from openbsc.git. Also not applicable to any OsmoNITB users. We should consider releasing/tagging a new OsmoBSC version with this change included. That obviously requires us to first clean up the dependency situation, i.e. make sure we tag those dependencies and update the minimum required versions in osmo-bsc. -- - 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 Fri Nov 10 14:47:24 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 10 Nov 2017 15:47:24 +0100 Subject: osmo-bsc access lists semantics are confusing In-Reply-To: <32F732F8-CD70-470D-9615-364FD6206081@freyther.de> References: <20171109044013.eif5botaudqiu5hy@my.box> <32F732F8-CD70-470D-9615-364FD6206081@freyther.de> Message-ID: <20171110144724.i5cz4dw4pnktmwsr@my.box> On Thu, Nov 09, 2017 at 02:39:51PM +0800, Holger Freyther wrote: > > - Are we not going to change this, even assuming that we regard changes being > > useful, because we don't want to break with previous configs? > > I think any existing user of osmo-bsc already will already have difficulties > to upgrade, changing the access lists might not make a big difference? I guess if we implement a change, it should be a VTY switch that is off by default. Meaning that we might as well wait until someone needs this and is willing to fund that development. Thinking about it again, the current state of the code is actually powerful enough for filtering IMSIs. ~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 Nov 10 15:02:10 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 10 Nov 2017 16:02:10 +0100 Subject: build failures Message-ID: <20171110150210.vdtqayt3rvswzalw@my.box> I am receiving a lot of build failure mails every day for quite a while now ... not finding any time to look at them, I hope you guys are onto those? ~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 Sat Nov 11 01:35:29 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 11 Nov 2017 10:35:29 +0900 Subject: build failures In-Reply-To: <20171110150210.vdtqayt3rvswzalw@my.box> References: <20171110150210.vdtqayt3rvswzalw@my.box> Message-ID: <20171111013529.tkue7kih4y7sodhl@nataraja> Hi Neels, On Fri, Nov 10, 2017 at 04:02:10PM +0100, Neels Hofmeyr wrote: > I am receiving a lot of build failure mails every day for quite a while now ... Would be useful for you to state what kind of build failures reported by whom/what. There are gerrit build failurs, osmocom:nightly build failures, osmocom:latest, ... > not finding any time to look at them, I hope you guys are onto those? I have the feeling this is mostly me at the moment, and I am not entirely happy with the fact that sometimes it appears to me that I have to pick up whatever other people are not looking into. But then, the last week I've been 9 hours ahead of European time zone, so for "nightly" builds I had the "pleasure" of noticing them much sooner than others. The only long-running OBS build failure that we're seeing is the one related to libosmocore failing "make check" on some OBS buildhosts, but by far not on all of them, due to some CPU flags. It's really sad that this has been going on for months without anyone apparenty trying to properly investigate it (cat /proc/cpuinfo as part of make check) or reproducing this in qemu which can selectively disable any cpu flag. 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 nhofmeyr at sysmocom.de Sat Nov 11 18:20:42 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 11 Nov 2017 19:20:42 +0100 Subject: SGSN rejects GMM Attach if HLR has the subscriber but no auth tokens Message-ID: <20171111182042.7dspn7mntzruwals@my.box> I found the interesting situation while trying to find the minimal network-in-the-box installation with the new split components: For CS, the MSC/VLR happily accept a subscriber that has no auth tokens in the HLR, as long as the IMSI is present in the HLR and authentication is set to optional. For PS, the SGSN on auth policy remote naturally asks the HLR for auth tuples for the subscriber. The HLR then finds the IMSI allright, but no 2G nor 3G auth tokens, and says so to the SGSN. That leads to total rejection: HLR: DLINP <0006> ../../../src/libosmo-abis/src/input/ipa.c:383 connected read/write DLINP <0006> ../../../src/libosmo-abis/src/input/ipa.c:338 message received DAUC <0003> ../../../src/osmo-hlr/src/db_auc.c:127 IMSI='901700000014701': No 2G Auth Data DAUC <0003> ../../../src/osmo-hlr/src/db_auc.c:163 IMSI='901700000014701': No 3G Auth Data SGSN: <000f> ../../../../src/osmo-sgsn/src/gprs/gprs_subscriber.c:493 SUBSCR(901700000014701) GPRS send auth info req failed, GMM cause = 'Network failure' (17) <0002> ../../../../src/osmo-sgsn/src/gprs/sgsn_auth.c:236 MM(901700000014701/ccb050ce) Missing auth tuples, authorization not possible <0002> ../../../../src/osmo-sgsn/src/gprs/gprs_gmm.c:1140 MM(901700000014701/ccb050ce) Not authorized, rejecting ATTACH REQUEST with cause 'Network failure' (17) <0002> ../../../../src/osmo-sgsn/src/gprs/gprs_gmm.c:491 MM(901700000014701/ccb050ce) <- GPRS ATTACH REJECT: Network failure It appears that in the SGSN, I either have to accept all IMSIs or also have auth tokens for each IMSI in the HLR. There's apparently no way to just accept IMSIs (without cryptographic auth) as long as the IMSIs exists in the HLR. In production networks, we usually have auth tokens for each SIM, but in open / community networks, IIUC operating without auth+ciph is an important option in Osmocom. It appears to me that we should support this case. Or do we already support it by issuing accept-all policy, and rely on the subscriber being rejected by the MSC before establishing GMM? (In that case we can't use the HLR at all, i.e. not for other IMSIs where we'd know auth tokens.) What do you guys think? Should we open an issue on it? Related: I'm often confused by the SGSN auth code and have wished before that it were a well-defined FSM instead... like the libvlr... ~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 Sat Nov 11 15:45:37 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 12 Nov 2017 00:45:37 +0900 Subject: Running osmo-bsc-sccplite with osmo-msc Message-ID: <20171111154537.fdh32eaqgydkyg5t@nataraja> Dear Osmocom Community, I've spent some time the least few days to handle SCCPlite in osmo-stp, and to do some initial testing of interoperability of osmo-bsc-sccplite with osmo-msc. The result are a few commits to osmo-sccp.git and openbsc.git which I'll push into gerrit as soon as I'm on land again (sitting in an airplane right now). Once those commits are merged, we can run osmo-bsc-sccplite with osmo-msc via osmo-stp. Why is this needed? While we don't want to see or support any new osmo-bsc-sccplite deployments, we still have existing users that we need to continue to support. Supporting them is easier if we can test it better, and as Osmocom now has a MSc, it would be logical to have some [manual, automatic] testing setups this way. It also means that we hopefully can create testing setups for osmo-bsc_nat, which could so far only be tested (like osmo-bsc-sccplite) with live access to a "real" MSC at an operator. Right now, this of course only handles signaling, i.e. we should be able to test LU, SMS and call signaling, including hand-over. Voice stream handling between SCCPlite and M3UA-AoIP is unfortunately quite different and will need further code in osmo-msc as well as osmo-stp. But still this should be rather straight-forward as a later next step for full interoperability. == How to configure this === osmo-bsc-sccplite side On the osmo-bsc-sccplite side, the config file looks like this ---- msc dest 127.0.0.1 5000 0 <1> token mahlzeit <2> ---- <1> the IP address and port must be the IP:Port of where osmo-stp listens for IPA <2> this 'token' must be identical to the AS configured on osmo-stp === osmo-stp side On the osmo-stp side, the config file looks like this: ---- cs7 instance 0 xua rkm routing-key-allocation dynamic-permitted as mahlzeit ipa <1> routing-key 0 0.23.4 <2> point-code override dpc 0.23.1 <3> route-table system listen m3ua 2905 accept-asp-connections dynamic-permitted listen ipa 5000 <4> accept-asp-connections dynamic-permitted ---- <1> This defines an AS with the name 'mahlzeit' matching the osmo-bsc-sccplite token <2> The point-code on the BSC side is set to 0.23.4 <3> The point-code of the MSC side is set to 0.23.1 (the compile-time default of osmo-msc) <4> Bind IPA protocol to TCP port 5000 Please note that no point code information is configured on the BSC side in the case of SCCPlite. The SCCP calling/called party address in SCCPlite don't contain a PC but only SSN, and there is no M3UA/MTP3 label with point code information either. Hence, OsmoSTP will insert the point code information into both the SCCP level as well as the stp-internal routing label of each message. The MSC will receive a SCCP message with PC+SSN in a M3UA message with OPC and DPC in a way that enables the STP to route any responses back to the BSC. If you have multiple osmo-bsc-sccplite in such a configuration, they will all need to have a different point code, just like an AoIP speaking osmo-bsc. The difference is only that in SCCPlite the point-codes are configured on the STP side, while in the AoIP they are configured on the BSC side. === osmo-msc side No special configuration is required on osmo-msc at this point. In order to properly handle voice channels, we likely have to introduce some additional per-BSC configuration statements at a later point. 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 Sun Nov 12 12:56:56 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Sun, 12 Nov 2017 13:56:56 +0100 Subject: Running osmo-bsc-sccplite with osmo-msc In-Reply-To: <20171111154537.fdh32eaqgydkyg5t@nataraja> References: <20171111154537.fdh32eaqgydkyg5t@nataraja> Message-ID: <34e08d75-1091-8f65-fcaf-f05f5dd957ef@sysmocom.de> Hi Harald, if I understood correctly: after your patches, osmo-msc can speak SCCPlite to osmo-bsc-sccplite (osmo-bsc in openbsc.git) but still cannot communicate with new osmo-bsc in osmo-bsc.git. This means if somebody is willing to use osmo-bsc with SCCPlite, the older one in openbsc.git must be used. Am I correct? 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 Sun Nov 12 13:20:46 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 12 Nov 2017 22:20:46 +0900 Subject: Running osmo-bsc-sccplite with osmo-msc In-Reply-To: <34e08d75-1091-8f65-fcaf-f05f5dd957ef@sysmocom.de> References: <20171111154537.fdh32eaqgydkyg5t@nataraja> <34e08d75-1091-8f65-fcaf-f05f5dd957ef@sysmocom.de> Message-ID: <20171112132046.usqjqq7mkumer2t6@nataraja> Hi Pau, On Sun, Nov 12, 2017 at 01:56:56PM +0100, Pau Espin Pedrol wrote: > if I understood correctly: after your patches, osmo-msc can speak SCCPlite > to osmo-bsc-sccplite (osmo-bsc in openbsc.git) Not entirely. OsmoSTP can now have signaling links of M3UA and IPA type, so it can convert between both protocol stackings, passing through the SCCP and BSSAP/BSSMAP on top. In theory not much is needed to use libosmo-sigtran with IPA directly from osmo-msc, but I don't know if it's useful to spend time in this. In the 3GPP AoIP setup we also require OsmoSTP between BSC + MSC, so there are reasons to keep the setup as close to the "legacy interop" one. > but still cannot communicate with new osmo-bsc in osmo-bsc.git. No. With current master after my patches, a single osmo-msc instance will connect via M3UA to osmo-stp. Multiple BSCs can then attach to osmo-stp via either M3UA or IPA/SCCPlite and talk to that single instance of OsmoMSC. > This means if somebody is willing to use osmo-bsc with SCCPlite, the > older one in openbsc.git must be used. Am I correct? Yes. We cannot achieve this functionality by using M3UA between BSC and STP, and then connecting to a SCCPlite MSC from the STP. The reason is simple: SCCPlite as we know it doesn't contain any addressing information beyond the SSN, i.e. it is not possible for the MSC to distinguish from/to which given BSC to send messages. The differentiator from the BSC side is the underlying TCP connection, so each BSC must have a separate IPA/SCCPlite connection to the MSC. If we want to support new osmo-bsc to talk SCCPlite, we need to 1) verify that the existing client-side IPA implementation of libosmo-sigtran works properly 2) figure out a way how to configure this for the client from the VTY 3) establish direct MGCP interoperability between external MSC and osmo-mgw I don't have any plans for this for the time being. 1+2 should be rather easy, the code already exists but is simply not used/tested. '3' is the more interesting question - but actually also should more or less "just work" if the AoIP transport IP/Port TLVs are not in the BSSAP, osmo-bsc simply has to suppress sending MGCP commands for the A-side, but continue sending MGCP commands for the Abis side. 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 nhofmeyr at sysmocom.de Sun Nov 12 21:13:44 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 12 Nov 2017 22:13:44 +0100 Subject: build failures In-Reply-To: <20171111013529.tkue7kih4y7sodhl@nataraja> References: <20171110150210.vdtqayt3rvswzalw@my.box> <20171111013529.tkue7kih4y7sodhl@nataraja> Message-ID: <20171112211344.eepysaogdzzo6jfm@my.box> On Sat, Nov 11, 2017 at 10:35:29AM +0900, Harald Welte wrote: > Would be useful for you to state what kind of build failures reported by > whom/what. There are gerrit build failurs, osmocom:nightly build failures, > osmocom:latest, ... I'm losing track, all sorts of them, and the amount is such that I have no idea whether they are anticipated / already looked at by someone actively making changes. For the last two weeks my decision was to not spend time there. > The only long-running OBS build failure that we're seeing is the one > related to libosmocore failing "make check" on some OBS buildhosts, but > by far not on all of them, due to some CPU flags. It's really sad that > this has been going on for months without anyone apparenty trying to > properly investigate it (cat /proc/cpuinfo as part of make check) or > reproducing this in qemu which can selectively disable any cpu flag. I would appreciate if those people familiar with the CPU features related code would look at it; I would have to start learning about it and the convolutional coding stuff (?) first... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From motosingh at yahoo.co.uk Thu Nov 16 14:59:04 2017 From: motosingh at yahoo.co.uk (Dees) Date: Thu, 16 Nov 2017 14:59:04 +0000 (UTC) Subject: [osmo-hlr 0.1.0.7-8db4] testsuite: 4 failed References: <1367760566.2197383.1510844344504.ref@mail.yahoo.com> Message-ID: <1367760566.2197383.1510844344504@mail.yahoo.com> Hi All, Was trying to build osmocom 3g system. Its failing in running test on osmo-hlr, any clues? ## --------------------------------- #### osmo-hlr 0.1.0.7-8db4 test suite. #### --------------------------------- ## Regression tests. ? 1: auc? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ok? 2: auc_ts_55_205_test_sets? ? ? ? ? ? ? ? ? ? ? ? ?ok? 3: gsup_server? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ok? 4: db? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? FAILED (testsuite.at:30) ## ------------- #### Test results. #### ------------- ## ERROR: All 4 tests were run,1 failed unexpectedly. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testsuite.log Type: application/octet-stream Size: 36867 bytes Desc: not available URL: From pshinjo at sec.t-labs.tu-berlin.de Thu Nov 16 14:54:15 2017 From: pshinjo at sec.t-labs.tu-berlin.de (Shinjo Park) Date: Thu, 16 Nov 2017 15:54:15 +0100 Subject: RFC: new type for NAS/EPS in gsmtap.h and question Message-ID: <1676633.vrP4Qaqq7O@brandenburg> Hi list, While I was experimenting with osmo-qcdiag and other LTE stuff, I want to add NAS/EPS as a new payload type for gsmtap.h. Unlike GSM and UMTS, LTE introduced separate layer for encryption of NAS and RRC. As a result, while NAS messages are piggybacked to LTE RRC, but after NAS security had been activated only encrypted NAS messages are available at RRC layer. This is reflected into the baseband diagnostics of various makers: Qualcomm provides separate diagnostic item for LTE NAS (both encrypted and plain) and RRC. Separate payload type for LTE RRC and LTE NAS will solve this issue. I can submit a patch if this looks positive. Also, I have a question regarding ARFCN field. Currently (in version 2) ARFCN is a 16-bit integer, with 2-bit of flags (PCS band, uplink) therefore making 14-bits available for raw value. This causes some problem in LTE: 1) EARFCNs for uplink are starting from 18000, which is larger than 2^14 2) There are EARFCNs even larger than 2^16 (Bands 65+, LTE-U frequencies) 3) No separate indicator for ARFCNs used by UMTS/LTE-TDD network Also in UMTS, there are overlapping UARFCNs between bands, which necessitates a separate field for band indicator. Changes regarding these will break the GSMTAP header structure, therefore I want to discuss about how these could be addressed. Best Regards, Shinjo -- Shinjo Park Security in Telecommunications TU Berlin / Telekom Innovation Laboratories Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany Phone: +49 30 8353 58272 From nhofmeyr at sysmocom.de Fri Nov 17 01:24:01 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 17 Nov 2017 02:24:01 +0100 Subject: news for sanitizer builds Message-ID: <20171117012401.cfvcfk4ckzlblb6h@my.box> I recently found sanitizer build failures, for example in libosmocore, which our gerrit build job doesn't catch. At first I thought something was amiss and maybe our gerrit sanitizer build were broken. Instead, it turns out my debian9 gcc -fsanitize=address -fsanitize=undefined finds many more issues that the debian8 one does not. https://jenkins.osmocom.org/jenkins/job/gerrit-libosmocore/36/a2=default,a3=default,a4=default,arch=amd64,label=linux_amd64_debian9/ I already have a long series for mem leak fixes for libosmocore, mostly in the regression testing code, but I count three real mem leak fixes in libosmocore production code. My plan is to merge the fixes and then actually move the libosmocore-gerrit to debian 9 (or at least add debian 9) to make sure we don't add insanities that the debian 9 build would find. See https://gerrit.osmocom.org/4861 to https://gerrit.osmocom.org/4875. I'm also taking a look at the other CellNet builds. The root motivation was to find out why osmo-hnbgw doesn't work for me anymore currently. ~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 Fri Nov 17 10:02:32 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Fri, 17 Nov 2017 11:02:32 +0100 Subject: news for sanitizer builds In-Reply-To: <20171117012401.cfvcfk4ckzlblb6h@my.box> References: <20171117012401.cfvcfk4ckzlblb6h@my.box> Message-ID: <4dfcff26-7405-39dd-0fbc-2107488a3e0a@sysmocom.de> On 17/11/17 02:24, Neels Hofmeyr wrote: > My plan is to merge the fixes and then actually move the libosmocore-gerrit to > debian 9 (or at least add debian 9) to make sure we don't add insanities that > the debian 9 build would find. > Another point in favor of moving to debian9 in jenkins build slaves :) -- - 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 Fri Nov 17 10:57:17 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 17 Nov 2017 11:57:17 +0100 Subject: debian 9 build slaves (Re: news for sanitizer builds) In-Reply-To: <4dfcff26-7405-39dd-0fbc-2107488a3e0a@sysmocom.de> References: <20171117012401.cfvcfk4ckzlblb6h@my.box> <4dfcff26-7405-39dd-0fbc-2107488a3e0a@sysmocom.de> Message-ID: <20171117105717.g4awjiaec43bukyn@nataraja> On Fri, Nov 17, 2017 at 11:02:32AM +0100, Pau Espin Pedrol wrote: > Another point in favor of moving to debian9 in jenkins build slaves :) if somebody writes/completes the Dockerfile or ansible playbook for it, I'm all for it. But let's not again start with manually-created build slaves. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jeanyves.ouattara at outlook.fr Fri Nov 17 15:11:39 2017 From: jeanyves.ouattara at outlook.fr (ouattara jean yves) Date: Fri, 17 Nov 2017 15:11:39 +0000 Subject: [libosmo-sccp 0.8.1.16-b393] testsuite: 4 5 failed Message-ID: Hello, I'm trying to build openbsc for 2g from this : http://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source Thank you for your work. At the "make check" of libosmo-sccp, 2 tests failed. Can you help me fix that please ? Sincerely, Jean Yves OUATTARA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testsuite.log Type: text/x-log Size: 44211 bytes Desc: testsuite.log URL: From laforge at gnumonks.org Sat Nov 18 07:09:07 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 18 Nov 2017 08:09:07 +0100 Subject: [libosmo-sccp 0.8.1.16-b393] testsuite: 4 5 failed In-Reply-To: References: Message-ID: <20171118070907.mcecxn3l2ahg7yau@nataraja> Hi! On Fri, Nov 17, 2017 at 03:11:39PM +0000, ouattara jean yves wrote: > I'm trying to build openbsc for 2g from this : > http://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source > > Thank you for your work. It would be interesting to understand why you are building from source rather than using the nightly or latest binary packages. It's easier to use the ready-made packages for getting started, and then if you want to make modifications build from source as needed. > At the "make check" of libosmo-sccp, 2 tests failed. Can you help me > fix that please ? > > /home/lte/osmo/src/libosmo-sccp/tests/xua/xua_test: error while loading shared libraries: libosmonetif.so.4: cannot open shared object file: No such file or directory You appear to have forgotten to call "ldconfig" to update your dynamic linker cache after installing a new shared library (such as libosmo-netif)? 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 Sat Nov 18 18:53:02 2017 From: radiarisainanasitraka at yahoo.fr (Radiarisainana Sitraka) Date: Sat, 18 Nov 2017 18:53:02 +0000 (UTC) Subject: 3G AUTHENTICATION References: <985933764.1547731.1511031182158.ref@mail.yahoo.com> Message-ID: <985933764.1547731.1511031182158@mail.yahoo.com> Hello,Simple curiosity, it's possible to use authentication 2G and having data interconnection? 3G with osmo-iuh !? Chears, -------------- next part -------------- An HTML attachment was scrubbed... URL: From radiarisainanasitraka at yahoo.fr Sat Nov 18 18:55:20 2017 From: radiarisainanasitraka at yahoo.fr (Radiarisainana Sitraka) Date: Sat, 18 Nov 2017 18:55:20 +0000 (UTC) Subject: 2G and 3G authentication References: <900753729.1552371.1511031320262.ref@mail.yahoo.com> Message-ID: <900753729.1552371.1511031320262@mail.yahoo.com> hello, needs helps for some question : is it possible to use 2g authentication for having 3g data interconnection with osmo-iuh !? -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sat Nov 18 19:16:45 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 18 Nov 2017 20:16:45 +0100 Subject: 2G and 3G authentication In-Reply-To: <900753729.1552371.1511031320262@mail.yahoo.com> References: <900753729.1552371.1511031320262.ref@mail.yahoo.com> <900753729.1552371.1511031320262@mail.yahoo.com> Message-ID: <20171118191645.cvypzvnegcb2jf56@nataraja> Hi! On Sat, Nov 18, 2017 at 06:55:20PM +0000, Radiarisainana Sitraka wrote: > needs helps for some question : is it possible to use 2g authentication for having 3g data interconnection with osmo-iuh !? Yes, this is actually how we initially did the osmo-iuh development: Use a 2G SIM card and use the compatibility mapping. NOTE: This only works if you use an actual 2G SIM that has no USIM application installed. -- - 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 Sat Nov 18 19:56:27 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 18 Nov 2017 20:56:27 +0100 Subject: osmo-mgw endpoint allocation Message-ID: <20171118195627.qrkpzy3yrkdhiy7h@nataraja> Hi all, we recently had some (verbal) discussions on how to handle endpoint allocations in a scenario where a single osmo-mgw shall be used by both osmo-bsc and osmo-msc (in a "NITB style" setup). There was some thinking about whether we should somehow divide fixed ranges of the rtp-bridge endpoints between the BSC and the MSC and how to avoid having to manually configure those. I think I now found the proper solution for this: The call agent must not even fully qualify the endpoint, but it can ask the MGW to allocate one! To quote from the MGCP RFC: EndpointId is the identifier for the connection endpoint in the gateway where CreateConnection executes. The EndpointId can be fully-specified by assigning a value to the parameter EndpointId in the function call or it may be under-specified by using the "any of" wildcard convention. If the endpoint is underspecified, the endpoint identifier SHALL be assigned by the gateway and its complete value returned in the SpecificEndPointId parameter of the response. When the "any of" wildcard is used, the endpoint assigned MUST be in- service and MUST NOT already have any connections on it. If no such endpoint is available, error code 410 (no endpoint available) SHOULD be returned. The "all of" wildcard MUST NOT be used. So in our concrete example, the BSC (or MSC) could simply ask for "rtpbridge/*@mgw" as end-point name in CRCX, and the MGW would then dynamically allocate a suitable free rtpbridge endpoint type and return it in the call agent in the BSC (or MSC). No shared knowledge about endpoint number allocations / ranges or the like required. Now we only need to implement this in osmo-mgw ;) Related: https://osmocom.org/issues/2631 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 nhofmeyr at sysmocom.de Sat Nov 18 22:16:50 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 18 Nov 2017 23:16:50 +0100 Subject: osmo_fsm timer_cb fudge up Message-ID: <20171118221650.vk2duwokdwcfylhf@my.box> I'm finding heap use after free related to osmo_fsm: - When dispatching a timer_cb event, we want to set fi->T back to 0. (see fsm_tmr_cb()) - So that we know which timer fired, we leave fi->T at its current value for the timer_cb to be able to make decisions based on that. This is used for example in fsm_timeout_cb() in osmo-bsc/osmo_bsc_mgcp.c. - In other code, the timer_cb event may decide to fire events or call functions which effect an FSM instance teardown and deallocation, meaning that in fsm_tmr_cb(), we are *not* allowed to generally assume the fi still exists. If we set fi->T = 0 after the timer_cb() was called, we may write to freed mem. - Also, if the timer_cb effects events with their own timeout, we will also overwrite the fi->T value with zero after another timer has set its value in T, causing failures to evaluate that timer later on. Solutions so far: - set fi->T = 0 first, and pass T to the timer_cb as arg instead. I think this is the best and cleanest, but also the hardest in terms of backwards compat. I have a patch that adds timer_cb2() that features a T arg; we need to submit that, move all code that wants to use T to that timer_cb2(), and then we can move the fi->T = 0 to before the timer_cb(). Actually, this is not being backwards compatible at all, because all code trying to use fi->T as usual will need adjustment, we break API either way and might as well add T to the timer_cb directly instead... :/ - Actually not set fi->T = 0 at all. We will have T holding the value of the timer that fired last, all old code will still find this T in fi->T, and after the cb, we just leave it as it was. Does it really need to be cleared? This has no compatibility issues and solves the use after free as well as setting a new T from timer_cb() issues. Going for this one so far. Thoughts? ~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 Nov 19 10:46:10 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 19 Nov 2017 11:46:10 +0100 Subject: debian 9 build slaves (Re: news for sanitizer builds) In-Reply-To: <20171117105717.g4awjiaec43bukyn@nataraja> References: <20171117012401.cfvcfk4ckzlblb6h@my.box> <4dfcff26-7405-39dd-0fbc-2107488a3e0a@sysmocom.de> <20171117105717.g4awjiaec43bukyn@nataraja> Message-ID: <20171119104610.mcglrgnr76xkugqd@my.box> On Fri, Nov 17, 2017 at 11:57:17AM +0100, Harald Welte wrote: > On Fri, Nov 17, 2017 at 11:02:32AM +0100, Pau Espin Pedrol wrote: > > > Another point in favor of moving to debian9 in jenkins build slaves :) > > if somebody writes/completes the Dockerfile or ansible playbook for it, > I'm all for it. But let's not again start with manually-created build slaves. I understand that we don't want to set up new build slaves without going for docker/ansible. But for gerrit verifications, switching to deb9 is easy, since we have a deb9 slave ready: jobs/gerrit-verifications.yml - slave_axis: !!python/tuple [linux_amd64_debian8] + slave_axis: !!python/tuple [linux_amd64_debian9] The hard part is/was to get all the reposes to pass the deb9 sanitizer scrutiny. BTW, I changed the osmo-iuh-gerrit job manually to do deb9 as well, fully aware that the config might be overwritten by a job update anytime, just to quickly test what happens on deb9. In other news... I still haven't resolved why on my laptop osmo-hnbgw doesn't build without adding -lsctp -- on the deb9 slave, it links fine without it. I'm pretty stumped on that, have a patch that adds -lsctp again, but ??? Also still haven't resolved why osmo-hnbgw crashes for any attach request for me. I have the gut feeling that these are related, looking forward to finding out what the heck is going on there and finally resolve this elaborate side track. ~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 Nov 19 13:10:14 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 19 Nov 2017 14:10:14 +0100 Subject: [osmo-hlr 0.1.0.7-8db4] testsuite: 4 failed In-Reply-To: <1367760566.2197383.1510844344504@mail.yahoo.com> References: <1367760566.2197383.1510844344504.ref@mail.yahoo.com> <1367760566.2197383.1510844344504@mail.yahoo.com> Message-ID: <20171119131014.ougnj2lc35uqg3ru@my.box> On Thu, Nov 16, 2017 at 02:59:04PM +0000, Dees wrote: > Hi All, > Was trying to build osmocom 3g system. > Its failing in running test on osmo-hlr, any clues? > ## --------------------------------- #### osmo-hlr 0.1.0.7-8db4 test suite. #### --------------------------------- ## > Regression tests. > ? 1: auc? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ok? 2: auc_ts_55_205_test_sets? ? ? ? ? ? ? ? ? ? ? ? ?ok? 3: gsup_server? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ok? 4: db? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? FAILED (testsuite.at:30) > ## ------------- #### Test results. #### ------------- ## > ERROR: All 4 tests were run,1 failed unexpectedly. > > Hi Dees, the error from your log is: -DDB (2067) abort at 18 in [INSERT INTO subscriber (imsi) VALUES ($imsi)]: UNIQUE constraint failed: subscriber.imsi +DDB (2067) abort at 35 in [INSERT INTO subscriber (imsi) VALUES ($imsi)]: UNIQUE constraint failed: subscriber.imsi which is the identical error as the test run intends to produce, except that "at 18" became "at 35" for no apparent reason. I wonder what that number is supposed to mean ... 35 could point at the IMSI value, while 18 doesn't make any sense at all. I cannot reproduce your failure locally, my test outcome expects '18', and that's what the test gives me. It has been '18' from the start in the git history of that file. Anyway, this is an error message produced by sqlite, and maybe they have fixed the number '18' to point closer to the IMSI instead? I am using libsqlite 3.16.2-5 on Debian 9, what version are you running? ...we may need to disable that error output for the test or mangle the output somehow... ~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 Nov 20 09:41:16 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 20 Nov 2017 10:41:16 +0100 Subject: osmo-mgw endpoint allocation In-Reply-To: <20171118195627.qrkpzy3yrkdhiy7h@nataraja> References: <20171118195627.qrkpzy3yrkdhiy7h@nataraja> Message-ID: <935746bf-bd6c-adc5-23ff-837018e74429@sysmocom.de> Hey, good news to hear that. I guess this also simplifies the code in osmo-mgw clients (osmo-bsc, osmo-msc) as they don't require to manage specific ranges anymore, right? Or do we still want to maintain that possibility? Regards, Pau -- - 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 msuraev at sysmocom.de Mon Nov 20 09:59:46 2017 From: msuraev at sysmocom.de (Max) Date: Mon, 20 Nov 2017 10:59:46 +0100 Subject: simtrace at use Message-ID: <31836ae8-f1de-16a7-933f-eb3697ca31c3@sysmocom.de> Hi. I've stumbled upon awesome hack which seems to be relevant: https://ha.cking.ch/s8_data_line_locator/ It uses Simtrace to check how hw implant communicates with its sim. The guy also tried to sniff GPRS traffic but failed (because he've used OpenBTS, he-he :) - I wonder if it would work better with OsmoBTS. Anyone else played with similar device already? -- 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 laforge at gnumonks.org Mon Nov 20 10:08:47 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 20 Nov 2017 11:08:47 +0100 Subject: osmo-mgw endpoint allocation In-Reply-To: <935746bf-bd6c-adc5-23ff-837018e74429@sysmocom.de> References: <20171118195627.qrkpzy3yrkdhiy7h@nataraja> <935746bf-bd6c-adc5-23ff-837018e74429@sysmocom.de> Message-ID: <20171120100847.auy57r5liuzfdud4@nataraja> On Mon, Nov 20, 2017 at 10:41:16AM +0100, Pau Espin Pedrol wrote: > I guess this also simplifies the code in osmo-mgw clients (osmo-bsc, > osmo-msc) as they don't require to manage specific ranges anymore, right? Or > do we still want to maintain that possibility? For osmo-bsc, we have to anticipate: 1 3GPP AoIP, at which point he MGCP between osmo-bsc and osmo-mgw is entirely private and we can avoid any management of specific ranges for RTP. 2 3GPP AoIP after re-introducing E1/T1 BTS support. Here, specific endpoints will have to be supported: Here, there's a 1:1 relationship between allocating a given radio channel (TCH) and the respective E1 line/timeslot/sub-slot. So basically, the endpoint name will be a property of the lchan, and that configuration is part of the vty/config. 3 IPA SCCPlite. Here we receive the MGCP from the (non-osmocom) MSC, in the format like 1 at mgw where 1 is the CIC. What we could do is to receive + mangle that MGCP inside osmo-bsc: * use number in front of @ to resolve subscriber_conn * rewrite "1 at mgw" to "rtpbridge/*@mgw" or the like and forward it From that point onwards it should be identical to case '1' above with 3GPP AoIP For osmo-msc, any signaling between the msc-local MGW and the MSC itself is again private and not exposed to any other (possibly non-osmocom) network elements, so no management of ranges/pools in the client. So I guess the answer to your question is: Yes, we can remvoe any management of endpoint ranges from the client library. Either we let the MGW choose an endpoint within a certain class (like "rtpbridge/*@mgw") or we already know the endpoint (E1 BTS) from the lchan and will hence be able to ask explicitly for something like "dahdi/S0/P1/T3/SS2 at mgw" which is "dahdi driver, slot 0, port 1, timeslot 3, sub-slot 2. No resource managemen is required in the mgcp client, as the resource management/allocation is done by lchan allocator already. -- - 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 Mon Nov 20 11:30:18 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 20 Nov 2017 12:30:18 +0100 Subject: LOGPFSM Message-ID: <20171120113018.7xy2osy5au64epwp@my.box> Hi dexter, I just noticed this patch that is merged, with the lines + LOGPFSML(reset->fsm, LOGL_NOTICE, "fsm-state (msc-reset): %s, fsm-event: %s\n", get_value_string(fsm_state_names, ST_CONN), get_value_string(fsm_evt_names, event)); If you take a look at the log output this produces, you should see that LOGPFSM already contains information that it is an FSM, which state it is in, and that just before that an FSM event has fired. This log statement seems obsolete? Here's an example where you did everything right, just add a message to the FSM logging: + LOGPFSML(reset->fsm, LOGL_NOTICE, "SIGTRAN connection down, reconnecting...\n"); I marked in the (merged) patch those logging lines that seem to merely duplicate what we already see in the logs: https://gerrit.osmocom.org/4754 ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From motosingh at yahoo.co.uk Mon Nov 20 15:36:51 2017 From: motosingh at yahoo.co.uk (Dees) Date: Mon, 20 Nov 2017 15:36:51 +0000 (UTC) Subject: [osmo-hlr 0.1.0.7-8db4] testsuite: 4 failed In-Reply-To: <20171119131014.ougnj2lc35uqg3ru@my.box> References: <1367760566.2197383.1510844344504.ref@mail.yahoo.com> <1367760566.2197383.1510844344504@mail.yahoo.com> <20171119131014.ougnj2lc35uqg3ru@my.box> Message-ID: <1736064355.3257052.1511192212009@mail.yahoo.com> Hi Neels, Thanks for checking. I was trying to build on Ubutun LTS 14.04 and sqlite3 version is?3.8.2.? I believe 3.8.2 is latest stable version in 14.04. Kind regards,Dees root at ip-172-31-7-26:/home/ubuntu# lsb_release -aNo LSB modules are available.Distributor ID: UbuntuDescription:? ? Ubuntu 14.04.5 LTSRelease:? ? ? ? 14.04Codename:? ? ? ?trusty root at ip-172-31-7-26:/home/ubuntu# sqlite3 -version3.8.2 2013-12-06 14:53:30 27392118af4c38c5203a04b8013e1afdb1cebd0d From: Neels Hofmeyr To: Dees Cc: "openbsc at lists.osmocom.org" Sent: Sunday, 19 November 2017, 13:10 Subject: Re: [osmo-hlr 0.1.0.7-8db4] testsuite: 4 failed On Thu, Nov 16, 2017 at 02:59:04PM +0000, Dees wrote: > Hi All, > Was trying to build osmocom 3g system. > Its failing in running test on osmo-hlr, any clues? > ## --------------------------------- #### osmo-hlr 0.1.0.7-8db4 test suite. #### --------------------------------- ## > Regression tests. > ? 1: auc? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ok? 2: auc_ts_55_205_test_sets? ? ? ? ? ? ? ? ? ? ? ? ?ok? 3: gsup_server? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ok? 4: db? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? FAILED (testsuite.at:30) > ## ------------- #### Test results. #### ------------- ## > ERROR: All 4 tests were run,1 failed unexpectedly. > > Hi Dees, the error from your log is: -DDB (2067) abort at 18 in [INSERT INTO subscriber (imsi) VALUES ($imsi)]: UNIQUE constraint failed: subscriber.imsi +DDB (2067) abort at 35 in [INSERT INTO subscriber (imsi) VALUES ($imsi)]: UNIQUE constraint failed: subscriber.imsi which is the identical error as the test run intends to produce, except that "at 18" became "at 35" for no apparent reason. I wonder what that number is supposed to mean ... 35 could point at the IMSI value, while 18 doesn't make any sense at all. I cannot reproduce your failure locally, my test outcome expects '18', and that's what the test gives me. It has been '18' from the start in the git history of that file. Anyway, this is an error message produced by sqlite, and maybe they have fixed the number '18' to point closer to the IMSI instead? I am using libsqlite 3.16.2-5 on Debian 9, what version are you running? ...we may need to disable that error output for the test or mangle the output somehow... ~N -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Tue Nov 21 02:06:24 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 21 Nov 2017 03:06:24 +0100 Subject: why osmo-hnbgw doesn't build for me, and remaining puzzle Message-ID: <20171121020624.nbw2crfz7aap4vey@my.box> Ever since I upgraded to debian 9, osmo-hnbgw failed to link in my build: /usr/bin/ld: hnbgw.o: undefined reference to symbol 'sctp_send@@VERS_1' I noticed that adding -lsctp to the build fixed that, yet noticed that no build slaves nor anyone else seemed to need that. Some events coincided my re-install of deb9: - There has always been an -lsctp in the Makefile.am for osmo-hnbgw, but it was recently dropped in http://git.osmocom.org/osmo-iuh/commit/?id=7235ea02d78299471d58f4202d8c8d685b1d5772 - I adopted the jenkins.sh -Werror flags in some builds to get fatal warnings. Passed by './configure CFLAGS=-Werror'. Someone else added this in jenkins.sh and I assumed that was a good way to do things. - I noticed that I couldn't see debug symbols in gdb, so added 'CLFAGS=-g' in my builds. read on... Comparing with a docker build kindly provided by laforge, I noticed that a plain 'clone; ./configure; make' does actually succeed on my system! It is a convolution of CFLAGS causing the error. By passing a 'CFLAGS=foo' to the osmo-iuh configure script, not only do I add 'foo', but I override CFLAGS defaults, and actually *remove* other CFLAGS. Turns out, whether I pass CFLAGS=-g or not, -g is always part of the build command lines: '-g -O2' is the default. Funnily enough, with CFLAGS=-g passed, I end up removing the -O2 option. A conclusion here is that in jenkins.sh, we should *not* pass CFLAGS to configure, so that we don't override any default CFLAGS. A configure option like --with-strict-warnings can add to CFLAGS in configure.ac instead So now I guess because I added CFLAGS=-Werror before, I ended up removing -g. Hence I saw a need to add -g again, goof. Did so in all builds while I was at it, hence -g ended up in osmo-iuh as well. The -g stuck around, and building osmo-iuh with CFLAGS=-g does, as I already said, effectively remove the -O2 option for all things built in osmo-iuh. Now I'm confused. Why does a lack of -O2 break a linkage. It's not the osmo-hnbgw linkage per se that seems to be the cause. I can link that last step with or without -O2 successfully. It must be a combination of building a depending library without -O2 and then linking that to osmo-iuh. I diffed the entire build log between a succeeding and a failing build of osmo-iuh, and really the only difference everywhere is that the succeeding build uses -O2 everywhere. The only differences in config.log are the same: most conftest programs have -O2 removed, few have a -g added. The conftest conclusions are all identical. My big question now is: sctp_send() is actually called from hnbgw.c directly. So IIUC, we should in fact be required to pass -lsctp to the linker for osmo-hnbgw. If that is correct, how am I allowed to skip that by passing -O2? That's all I figured out so far. I still would like to find out why this can happen, any ideas would be appreciated. Anyone should be able to reproduce this by building osmo-iuh with ./configure CFLAGS=-g ~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 Tue Nov 21 07:19:06 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 21 Nov 2017 08:19:06 +0100 Subject: why osmo-hnbgw doesn't build for me, and remaining puzzle In-Reply-To: <20171121020624.nbw2crfz7aap4vey@my.box> References: <20171121020624.nbw2crfz7aap4vey@my.box> Message-ID: <20171121071906.l6b4lxpjihppav6f@nataraja> On Tue, Nov 21, 2017 at 03:06:24AM +0100, Neels Hofmeyr wrote: > Now I'm confused. Why does a lack of -O2 break a linkage. because it removes dead code. > It's not the osmo-hnbgw linkage per se that seems to be the cause. I can link > that last step with or without -O2 successfully. It must be a combination of > building a depending library without -O2 and then linking that to osmo-iuh. > > I diffed the entire build log between a succeeding and a failing build of > osmo-iuh, and really the only difference everywhere is that the succeeding > build uses -O2 everywhere. > > The only differences in config.log are the same: most conftest programs have > -O2 removed, few have a -g added. The conftest conclusions are all identical. > > My big question now is: sctp_send() is actually called from hnbgw.c directly. this is the big surprise here, as this shouldn't be the case ever we introduced libosmo-sigtran. > So IIUC, we should in fact be required to pass -lsctp to the linker for > osmo-hnbgw. If that is correct, how am I allowed to skip that by passing -O2? Because the call to sctp_send() is in dead code, specifically in a static function that the compiler will drop during optimziation. Hence the offending symbol reference is gone at the time of linking if any -O is used. In I8d52b11e3f476ffd77f3ab185b679817cd3b2163 I introduce the -Wall and then in subseqent Ifbcb21d43e17bf512bc7b219e590410e06c434ca I remove it. There's also an interesting catch in I9dbad21e75a55ad91b12d3d3ee8bd6dfb5326c3e and plenty of warnings fixes in c7a158211fa59ac27c70faa0813a27e2f3a7a569 -- - 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 Tue Nov 21 11:02:47 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 21 Nov 2017 12:02:47 +0100 Subject: why osmo-hnbgw doesn't build for me, and remaining puzzle In-Reply-To: <20171121071906.l6b4lxpjihppav6f@nataraja> References: <20171121020624.nbw2crfz7aap4vey@my.box> <20171121071906.l6b4lxpjihppav6f@nataraja> Message-ID: <20171121110247.GA3553@ass40.sysmocom.de> On Tue, Nov 21, 2017 at 08:19:06AM +0100, Harald Welte wrote: > In I8d52b11e3f476ffd77f3ab185b679817cd3b2163 I introduce the -Wall and > then in subseqent Ifbcb21d43e17bf512bc7b219e590410e06c434ca I remove > [the dead function]. yeeees now things are starting to make sense. Thanks for this catch! > There's also an interesting catch in I9dbad21e75a55ad91b12d3d3ee8bd6dfb5326c3e > and plenty of warnings fixes in c7a158211fa59ac27c70faa0813a27e2f3a7a569 Can't find c7a158211fa59ac27c70faa0813a27e2f3a7a569, is it I516700eab2aa7c3412dd62775c4960aed9d4b682? ~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 Nov 21 11:36:09 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 21 Nov 2017 12:36:09 +0100 Subject: [osmo-hlr 0.1.0.7-8db4] testsuite: 4 failed In-Reply-To: <1736064355.3257052.1511192212009@mail.yahoo.com> References: <1367760566.2197383.1510844344504.ref@mail.yahoo.com> <1367760566.2197383.1510844344504@mail.yahoo.com> <20171119131014.ougnj2lc35uqg3ru@my.box> <1736064355.3257052.1511192212009@mail.yahoo.com> Message-ID: <20171121113609.GB3553@ass40.sysmocom.de> On Mon, Nov 20, 2017 at 03:36:51PM +0000, Dees wrote: > Hi Neels, > Thanks for checking. > I was trying to build on Ubutun LTS 14.04 and sqlite3 version is?3.8.2.? I believe 3.8.2 is latest stable version in 14.04. > Kind regards,Dees 14.04 is rather old, but that's not an excuse for having a regression test vulnerable for false positives. So I pushed https://gerrit.osmocom.org/4948 for review. To work a round the issue until that is merged, you could either skip the 'make check' or update the expected output to match your current message: cd osmo-hlr/tests/db make update_exp ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From gskmoss at gmail.com Wed Nov 22 22:46:57 2017 From: gskmoss at gmail.com (GSK MOSS) Date: Thu, 23 Nov 2017 01:46:57 +0300 Subject: Osmo-bts.cfg Open-bsc.cfg tutorial Message-ID: Hello! I read a tutorial called "CalypsoBTS" ( http://osmocom.org/projects/baseband/wiki/CalypsoBTS). Everything was good before I ran "Osmo-bts.cfg". I got a error : " *There is no such command. Error occurred during reading the below line: fn-advance 30*". How to fix it? Are there any tutorials for beginners how configure these "Osmo-bts.cfg" "Open-bsc.cfg" files? I need just to run "fake base station" for testing android app. Is there any another ways to run it with motorola? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rayansalhab at hotmail.com Wed Nov 22 10:23:46 2017 From: rayansalhab at hotmail.com (Rayan Salhab) Date: Wed, 22 Nov 2017 10:23:46 +0000 Subject: /usr/bin/lc15bts-mgr can't find GPS 3D fix to for calibration Message-ID: Hi, We have a Litecell 1.5 unit. It is updated to the latest packages on the nightly build and configured to an osmo-bsc set up on an another machine. On mobile phones, the network does not show the short or long name set, instead it shows just numbers "09070" and calls can not be made. This has happened to us before when there was problem with the clock calibration on the BTS. A GPS device is attached to the BTS, and when running cgps, there is a 3D Fix and a correct GPS location coordinates show up. The lc15 bts should be able to calibrate automatically using the lc15bts-mgr package, however, it seems like it is failing to do so. When we tried stopping the lc15bts-mgr service and start it manually to log the output by running: /usr/bin/lc15bts-mgr -s -c /etc/osmocom/lc15bts-mgr.cfg We notice the following errors: ``` Failed to open /mnt/storage/var/run/lc15bts-mgr/volt-supply-max due to 'No such file or directory' error <0000> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_misc.c:315 Total hours of Operation: 393 <0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:271 Going to calibrate the system. <0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:121 Last GPS 3D fix can not read (-2). Last GPS 3D fix sets to zero <0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:126 GPS has no fix <0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:126 Going to check for watchdog notification. <0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:67 Missing watchdog events: e:0x000000000000002e,m:0x000000000000007f <0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:126 Going to check for watchdog notification. <0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:67 Missing watchdog events: e:0x000000000000002f,m:0x000000000000007f <0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:271 Going to calibrate the system. <0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:121 Last GPS 3D fix can not read (-2). Last GPS 3D fix sets to zero <0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:126 GPS has no fix <0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:126 Going to check for watchdog notification. <0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:67 Missing watchdog events: e:0x000000000000002f,m:0x000000000000007f ``` It seems the lc15bts_mgr service can not read the values from the GPS device for some reason, can someone please advise what might be causing this issue? Best Regards, Rayan -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Thu Nov 23 07:02:32 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Thu, 23 Nov 2017 14:02:32 +0700 Subject: Osmo-bts.cfg Open-bsc.cfg tutorial Message-ID: Hi, > I read a tutorial called "CalypsoBTS" The tutorial has been updated. Check out a new version please. https://osmocom.org/projects/baseband/wiki/CalypsoBTS > *There is no such command. Error occurred during reading > the below line: fn-advance 30*". How to fix it? Are there > any tutorials for beginners how configure these > "Osmo-bts.cfg" "Open-bsc.cfg" files? The configuration suggested by the previous version of this tutorial is obsolete. I may find the actual configuration examples in 'doc/examples/' of almost each project. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gskmoss at gmail.com Thu Nov 23 14:19:47 2017 From: gskmoss at gmail.com (GSK MOSS) Date: Thu, 23 Nov 2017 17:19:47 +0300 Subject: osmo-bts-trx init problem Message-ID: Hello! I got this problem: *root at pc:~/osmocom# osmo-bts-trx -c ~/.osmocom/osmo-bts.cfg((*)) | / \ OsmoBTS<0017> control_if.c:828 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:595 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:409 transceiver (phy0.0) rejected TRX command with response: 'RSP SETTSC -1'* *<0001> bts.c:210 Shutting down BTS 0, Reason TRX-CTRL-MSG: CRITICAL* *<0007> l1sap.c:462 Invalid condition detected: Frame difference is 2452951-0 > 1!* *Shutdown timer expired* What is the problem and how can fix it? I used 1 phone and cfg files (from this tutorial https://osmocom.org/projects/baseband/wiki/CalypsoBTS): - OsmoNITB: 'doc/examples/osmo-nitb/sysmobts/openbsc.cfg' - OsmoBTS: 'doc/examples/trx/osmo-bts.cfg' thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Heusse at imag.fr Thu Nov 23 16:15:57 2017 From: Martin.Heusse at imag.fr (Martin Heusse) Date: Thu, 23 Nov 2017 17:15:57 +0100 Subject: RFC: new type for NAS/EPS in gsmtap.h and question Message-ID: <3F02A3AC-BA0B-4181-A2A5-D799DE4F29C6@imag.fr> Hi, working on a diagnostic interface, I also ran into the lack of a gsmtap type for LTE NAS plain messages. So I am supporting Shinzo's request for a new GSMTAP_TYPE_LTE_NAS (or GSMTAP_TYPE_LTE_UU) type in packet-gsmtap.h. This type would play a similar role to that of GSMTAP_TYPE_UM for GSM, if my understanding is correct. Best regards, Martin > Unlike GSM and UMTS, LTE introduced separate layer for encryption of NAS and > RRC. As a result, while NAS messages are piggybacked to LTE RRC, but after NAS > security had been activated only encrypted NAS messages are available at RRC > layer. This is reflected into the baseband diagnostics of various makers: > Qualcomm provides separate diagnostic item for LTE NAS (both encrypted and > plain) and RRC. Separate payload type for LTE RRC and LTE NAS will solve this > issue. I can submit a patch if this looks positive. > > From laforge at gnumonks.org Thu Nov 23 17:02:33 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 23 Nov 2017 18:02:33 +0100 Subject: RFC: new type for NAS/EPS in gsmtap.h and question In-Reply-To: <3F02A3AC-BA0B-4181-A2A5-D799DE4F29C6@imag.fr> References: <3F02A3AC-BA0B-4181-A2A5-D799DE4F29C6@imag.fr> Message-ID: <20171123170233.rwgvvn3iqileewp2@nataraja> Hi Martin and Shinjo, On Thu, Nov 23, 2017 at 05:15:57PM +0100, Martin Heusse wrote: > working on a diagnostic interface, I also ran into the lack of a gsmtap type for LTE NAS plain messages. > So I am supporting Shinzo's request for a new GSMTAP_TYPE_LTE_NAS (or GSMTAP_TYPE_LTE_UU) type in packet-gsmtap.h. Sorry for not following-up to this earlier. I agree it is needed, and will follow-up to Shinjo's original mail. -- - 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 Thu Nov 23 17:13:05 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 23 Nov 2017 18:13:05 +0100 Subject: RFC: new type for NAS/EPS in gsmtap.h and question In-Reply-To: <1676633.vrP4Qaqq7O@brandenburg> References: <1676633.vrP4Qaqq7O@brandenburg> Message-ID: <20171123171305.rixhd75agp7k4cpe@nataraja> Hi Shinjo, On Thu, Nov 16, 2017 at 03:54:15PM +0100, Shinjo Park wrote: > While I was experimenting with osmo-qcdiag and other LTE stuff, I want to add > NAS/EPS as a new payload type for gsmtap.h. perfectly fine. > Unlike GSM and UMTS, LTE introduced separate layer for encryption of NAS and > RRC. As a result, while NAS messages are piggybacked to LTE RRC, but after NAS > security had been activated only encrypted NAS messages are available at RRC > layer. This is reflected into the baseband diagnostics of various makers: > Qualcomm provides separate diagnostic item for LTE NAS (both encrypted and > plain) and RRC. Separate payload type for LTE RRC and LTE NAS will solve this > issue. I can submit a patch if this looks positive. Yes, please send a patch both for the gsmtap header file in libosmocore as well as for the wireshark dissector. > Also, I have a question regarding ARFCN field. Currently (in version 2) ARFCN > is a 16-bit integer, with 2-bit of flags (PCS band, uplink) therefore making > 14-bits available for raw value. This causes some problem in LTE: Well, the field was really intended for GSM ARFCN, and not for UARFCN or EARFCN. All of GSMTAP was intended for GSM, everything else was just a rather dirty addition. > 1) EARFCNs for uplink are starting from 18000, which is larger than 2^14 > 2) There are EARFCNs even larger than 2^16 (Bands 65+, LTE-U frequencies) > 3) No separate indicator for ARFCNs used by UMTS/LTE-TDD network ACK. > Also in UMTS, there are overlapping UARFCNs between bands, which necessitates > a separate field for band indicator. ACK. > Changes regarding these will break the GSMTAP header structure, > therefore I want to discuss about how these could be addressed. Basically, we'll need a new version of the header, and then have a dissector for both the old and the new format. UMTS/LTE applications that care about U/EARFCN can then make use of the new header version while existing legacy programs continue to use the old format. The new common header should be much shorter. It shouldn't even contain fields like timeslot / subslot that don't make sense on non-TDMA systems. Even ARFCN could be removed and, and then be part of a type-specific 'next header' or 'option header'. so something like struct gsmtap_v3_header { uint8_t version; uint8_t hdr_len; uint8_t type; uint8_t antenna_nr; int8_t signal_dbm; int8_t snr_db; uint8_t sub_type; uint8_t res; /* or maybe expand sub_type to 16bits? */ }; followed by struct gsmtap_opt_hdr_gsm { uint16_t arfcn; uint8_t timeslot; uint8_t sub_slot; }; struct gsmtap_opt_hdr_umts { uint32_t uarfcn; uint8_t band; ... }; struct gsmtap_opt_hdr_lte { uint32_t earfcn; ... }; seems like a good idea to me. -- - 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 Thu Nov 23 21:44:07 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 23 Nov 2017 22:44:07 +0100 Subject: osmo-bts-trx init problem In-Reply-To: References: Message-ID: <20171123214407.45d4j2ndaizygskx@my.box> On Thu, Nov 23, 2017 at 05:19:47PM +0300, GSK MOSS wrote: > Hello! > > I got this problem: [...] > *Shutdown timer expired* what does the OsmoNITB log say? Do the ipa unit id values match the OsmoNITB bts config? ~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 Nov 24 01:19:42 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 24 Nov 2017 02:19:42 +0100 Subject: load based handover Message-ID: <20171124011942.sihpd3ttlv6fcrat@my.box> Hi Jolly, my current task is to implement load based handover between BTS, and in old tradition of adopting your code to implement dynamic timeslots on osmo-{bts,bsc}, I am now looking at the openbsc.git jolly/new_handover branch. I notice that, on that branch, there are improvements on the "old" handover, followed by a new elaborate handover_2 algorithm, which looks very sane at first sight, paired with an elaborate test suite. So my question is whether handover_2.c has some obvious shortcomings or open issues that need to be resolved before I can consider merging that to OsmoBSC's master branch. Should we still keep the "old" handover decision code around as well for particular reasons, or would it make sense to adopt handover_2.c by default? Is one better than the other in particular situations? And ... do you remember any high level conclusions from when you implemented the branch, things I should be aware of when testing and adopting the code? Did it work out as expected? How well tested is it? 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 Fri Nov 24 03:28:46 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 24 Nov 2017 04:28:46 +0100 Subject: default point codes Message-ID: <20171124032846.7rlfupqdlcez2tnu@my.box> Looking at https://osmocom.org/projects/cellular-infrastructure/wiki/Point_Codes OsmoMSC currently uses 0.23.1 for A-and-Iu, and 0.23.2 for Iu only if Iu is on a different cs7 instance than A (i.e. practically never). Either way that doesn't really make sense to me. If OsmoMSC is connecting to the same STP for A and Iu, it is sufficient to have one point-code for the two SSNs for A (BSSAP) and Iu (RANAP) and hence use one cs7 instance for both. If it is connecting to two different STPs, the point codes do not collide anyway, and it makes no sense to use a different one for Iu. It only confuses the defaults, e.g. the wiki page was wrong until I fixed it just now. I would rather have just 0.23.1 for the MSC for all SSNs. See ss7_setup() in msc_main.c. Agreed? ~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 Nov 24 03:42:46 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 24 Nov 2017 04:42:46 +0100 Subject: default point codes In-Reply-To: <20171124032846.7rlfupqdlcez2tnu@my.box> References: <20171124032846.7rlfupqdlcez2tnu@my.box> Message-ID: <20171124034246.ajyy3goilzojv3bx@my.box> On Fri, Nov 24, 2017 at 04:28:46AM +0100, Neels Hofmeyr wrote: > Looking at https://osmocom.org/projects/cellular-infrastructure/wiki/Point_Codes > > I would rather have just 0.23.1 for the MSC for all SSNs. https://gerrit.osmocom.org/#/c/5020/ ~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 Fri Nov 24 07:39:24 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 24 Nov 2017 08:39:24 +0100 Subject: load based handover In-Reply-To: <20171124011942.sihpd3ttlv6fcrat@my.box> References: <20171124011942.sihpd3ttlv6fcrat@my.box> Message-ID: <20171124073924.brvvlfs3rodw7jdx@nataraja> Hi Neels, please find the original discussion related to the "new" algorithm attached for your reference, in case you were not aware of it. It had meanwhile been migrated to https://osmocom.org/projects/openbsc/wiki/Proposed_New_Handover_Algorithm On Fri, Nov 24, 2017 at 02:19:42AM +0100, Neels Hofmeyr wrote: > And ... do you remember any high level conclusions from when you implemented > the branch, things I should be aware of when testing and adopting the code? Did > it work out as expected? How well tested is it? I would also be interested in hearing about this. We know that at least some users were using it in the past, but that's already quite some time in the past. Would be great if those users could speak up and hence do their part in contributing to the merge of a feature that they use. -- - 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 embedded message was scrubbed... From: jolly Subject: New handover algorithm Date: Thu, 16 May 2013 10:01:15 +0200 Size: 6851 URL: -------------- next part -------------- An embedded message was scrubbed... From: Harald Welte Subject: Re: New handover algorithm Date: Thu, 16 May 2013 12:44:10 +0200 Size: 2779 URL: -------------- next part -------------- An embedded message was scrubbed... From: jolly Subject: Re: New handover algorithm Date: Thu, 16 May 2013 13:10:46 +0200 Size: 2990 URL: From laforge at gnumonks.org Fri Nov 24 07:34:23 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 24 Nov 2017 08:34:23 +0100 Subject: default point codes In-Reply-To: <20171124032846.7rlfupqdlcez2tnu@my.box> References: <20171124032846.7rlfupqdlcez2tnu@my.box> Message-ID: <20171124073423.h6fcwzhvnjb7g7jt@nataraja> Hi Neels, On Fri, Nov 24, 2017 at 04:28:46AM +0100, Neels Hofmeyr wrote: > Looking at https://osmocom.org/projects/cellular-infrastructure/wiki/Point_Codes which I btw crated from the compile-time information I found in the code, but apparently not saw all related pieces. > OsmoMSC currently uses 0.23.1 for A-and-Iu, > and 0.23.2 for Iu only if Iu is on a different cs7 instance than A (i.e. > practically never). Ah, this particular behavior seems to have slipped my reading of the code. > Either way that doesn't really make sense to me. If OsmoMSC is connecting to > the same STP for A and Iu, it is sufficient to have one point-code for the two > SSNs for A (BSSAP) and Iu (RANAP) and hence use one cs7 instance for both. Yes, it's sufficient. Nevertheless, people do use "secondary point codes" for similar reasons people are using "secondary IP adresses" in IP networks, e.g. separate IP addresses for individual services so later on you can run them on separate machines without having to reconfigure your routing or all of the peers. > If it is connecting to two different STPs, the point codes do not collide > anyway, this is only correct if those two STPs are in separate MTP-level networks, again similar to the IP sphere: If you have two STPs in one company network (or one national network, or the international network) then the addresses are global across that network. Only if you decide to have two networks that don't direclty route on point codes you can have identical point codes in both networks. You could not easily transport e.g. ISUP across such a boundary withouta proxy, but you could use a STP with Global Title Translation to use the SCCP address to get the new point code while transitioning a gateway between the two networks. > and it makes no sense to use a different one for Iu. It only confuses > the defaults, e.g. the wiki page was wrong until I fixed it just now. > > I would rather have just 0.23.1 for the MSC for all SSNs. fine with me. Whoever wants it differently can always configure it differently. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From axilirator at gmail.com Fri Nov 24 09:43:30 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Fri, 24 Nov 2017 16:43:30 +0700 Subject: osmo-bts-trx init problem Message-ID: Hi, > <000b> trx_if.c:409 transceiver (phy0.0) rejected TRX command > with response: 'RSP SETTSC -1' > > What is the problem and how can fix it? The OsmocomBB transceiver is a legacy transceiver, so please add the following line to your 'osmo-bts.cfg': osmotrx legacy-setbsic And please let me know about the results, I'll correct the wiki. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gskmoss at gmail.com Fri Nov 24 15:04:10 2017 From: gskmoss at gmail.com (GSK MOSS) Date: Fri, 24 Nov 2017 18:04:10 +0300 Subject: osmo-bts-trx init problem In-Reply-To: References: Message-ID: Hi, I added the line to 'osmo-bts.cfg' and got in terminal something like this: *PH-RTS-IND: Unable to determine actual BS_AG_BLKS_RES value as SI3 is not available yet, fallback to 1.* and this : * Invalid condition detected: Frame difference is 1685248-0 > 1* What sould I do with that? what is the problem? I thought that I forgot to change ARFCN in "openbsc.cfg" and then after changing ARFCN in "openbsc.cfg" I can't even init it. Terminal says: *root at pc:~# osmo-nitb -c ~/.osmocom/openbsc.cfg -l ~/.osmocom/hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM<0005> abis_nm.c:2800 (bts=0,trx=0) Changing adm. state Unlocked -> Unlocked [vty]Reading config failed. Exiting.* May be the problem is in *"*hlr.sqlite3"? I don't know. By the way, how can I make new *"*hlr.sqlite3"? I lost the tutorial about it. Help me, pls. Thanks! 2017-11-24 12:43 GMT+03:00 Vadim Yanitskiy : > Hi, > > > <000b> trx_if.c:409 transceiver (phy0.0) rejected TRX command > > with response: 'RSP SETTSC -1' > > > > What is the problem and how can fix it? > > The OsmocomBB transceiver is a legacy transceiver, so please add > the following line to your 'osmo-bts.cfg': > > osmotrx legacy-setbsic > > And please let me know about the results, I'll correct the wiki. > > With best regards, > Vadim Yanitskiy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gskmoss at gmail.com Fri Nov 24 15:21:33 2017 From: gskmoss at gmail.com (GSK MOSS) Date: Fri, 24 Nov 2017 18:21:33 +0300 Subject: osmo-bts-trx init problem In-Reply-To: References: Message-ID: added my cfg files and hlr 2017-11-24 18:04 GMT+03:00 GSK MOSS : > Hi, > I added the line to 'osmo-bts.cfg' and got in terminal something like this: > > > > > *PH-RTS-IND: Unable to determine actual BS_AG_BLKS_RES value as SI3 is not > available yet, fallback to 1.* > and this : > > * Invalid condition detected: Frame difference is 1685248-0 > 1* > What sould I do with that? what is the problem? I thought that I forgot to > change ARFCN in "openbsc.cfg" and then > after changing ARFCN in "openbsc.cfg" I can't even init it. Terminal says: > > > > *root at pc:~# osmo-nitb -c ~/.osmocom/openbsc.cfg -l ~/.osmocom/hlr.sqlite3 > -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM<0005> abis_nm.c:2800 (bts=0,trx=0) > Changing adm. state Unlocked -> Unlocked [vty]Reading config failed. > Exiting.* > > May be the problem is in *"*hlr.sqlite3"? I don't know. By the way, how > can I make new *"*hlr.sqlite3"? I lost the tutorial about it. Help me, > pls. Thanks! > > > > 2017-11-24 12:43 GMT+03:00 Vadim Yanitskiy : > >> Hi, >> >> > <000b> trx_if.c:409 transceiver (phy0.0) rejected TRX command >> > with response: 'RSP SETTSC -1' >> > >> > What is the problem and how can fix it? >> >> The OsmocomBB transceiver is a legacy transceiver, so please add >> the following line to your 'osmo-bts.cfg': >> >> osmotrx legacy-setbsic >> >> And please let me know about the results, I'll correct the wiki. >> >> With best regards, >> Vadim Yanitskiy. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hlr.sqlite3 Type: application/octet-stream Size: 27648 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openbsc.cfg Type: application/octet-stream Size: 1334 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-bts.cfg Type: application/octet-stream Size: 588 bytes Desc: not available URL: From laforge at gnumonks.org Fri Nov 24 19:28:35 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 24 Nov 2017 20:28:35 +0100 Subject: Eclipse TITAN public release of SS7/SIGTRAN core protocols Message-ID: <20171124192835.GK3109@nataraja> Hi all, I've mentioned this many months before, but Ericsson has now (well, a month ago) finally made a public announcement about the public release of their SS7/SIGTRAN core protocols in TTCN-3. You can read more about it at https://www.eclipse.org/forums/index.php/t/1089686/ - where they actually even refer to us as being the trigger to release them. There are still many tests to write beyond those currently existing. Most recently I wrote a set of MGCP tests for our new osmo-mgw, which Philipp is now using to iron out some kinks in the codebase. The past week I've been working on simulating the minimal subset of N numbers of BSCs and N numbers of MSCs from a single test suite in order to test osmo-bsc_nat, and specifically the "IMSI-based routing to different MSCs" feature that Daniel has been working on. It's still work in progress, but definitely the by far most complex TTCN-3 project that I've written so far. After completing that, I would like to spend some more time on OsmoBTS and OsmoBSC related tests. The difficulty here is that the more we get to the RAN / air interface, the less existing prtoocols / codecs exist, so e.g. A-bis RSL would first have to be implemented. The good part is that it's actually super easy using the expressive syntax of the TITAN "raw" codec. Basically you define the structure of the data in files like http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_RR_Types.ttcn and you don't have to write a single line for encoding/parsing :) 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 Mon Nov 27 03:00:12 2017 From: radiarisainanasitraka at yahoo.fr (Radiarisainana Sitraka) Date: Mon, 27 Nov 2017 03:00:12 +0000 (UTC) Subject: OSMO-IUH References: <1554785252.4952727.1511751612371.ref@mail.yahoo.com> Message-ID: <1554785252.4952727.1511751612371@mail.yahoo.com> Hello, I heard that it's possible to connect to a femtocell without knowing Ki and Opc... of the sim-card like the conferences of Nico Golde and Ranvinshar on the poisoning the femtocell.My question is , is it possible to make the? same with the osmo-iuh on the future !? Chears, -------------- next part -------------- An HTML attachment was scrubbed... URL: From domi at tomcsanyi.net Mon Nov 27 09:35:12 2017 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Mon, 27 Nov 2017 10:35:12 +0100 (CET) Subject: OSMO-IUH In-Reply-To: <1554785252.4952727.1511751612371@mail.yahoo.com> References: <1554785252.4952727.1511751612371.ref@mail.yahoo.com> <1554785252.4952727.1511751612371@mail.yahoo.com> Message-ID: <488119B8-57E4-451B-A809-48AD17928481@tomcsanyi.net> Hi, No. Cheers, Domi 2017. nov. 27. d?tummal, 4:01 id?pontban Radiarisainana Sitraka ?rta: > Hello, > > I heard that it's possible to connect to a femtocell without knowing Ki and Opc... of the sim-card like the conferences of Nico Golde and Ranvinshar on the poisoning the femtocell.My question is , is it possible to make the same with the osmo-iuh on the future !? > > > Chears, -------------- next part -------------- An HTML attachment was scrubbed... URL: From pshinjo at sec.t-labs.tu-berlin.de Mon Nov 27 10:11:58 2017 From: pshinjo at sec.t-labs.tu-berlin.de (Shinjo Park) Date: Mon, 27 Nov 2017 11:11:58 +0100 Subject: RFC: new type for NAS/EPS in gsmtap.h and question In-Reply-To: <20171123213447.jgumhjpkxn3g7j2v@nataraja> References: <1676633.vrP4Qaqq7O@brandenburg> <20171123213447.jgumhjpkxn3g7j2v@nataraja> Message-ID: <9393420.BgeNa6r4Vq@brandenburg> 2017? 11? 23? ??? ?? 10? 34? 47? CET? Harald Welte ?? ? ?: > On Thu, Nov 23, 2017 at 09:47:25PM +0100, Martin Heusse wrote: > > Harald, Shinjo, > > please find below is a tiny patch to add > > #define GSMTAP_TYPE_LTE_NAS 0x12 > > to packet-gsmtap.h > > and the corresponding code that uses it. > > great, feel free to push this to the wireshark gerrit. > > I've made a corresponding change in libosmocore, see > https://gerrit.osmocom.org/5018 > Forwarding the discussion at Wireshark gerrit at https://code.wireshark.org/ review/#/c/24554/4: Devices dumping NAS messages can give both encrypted and plain messages. At least for Qualcomm LTE basebands it is true. Therefore using sub_type for differentiating encrypted and plain NAS messages were discussed there. This will likely introduce another modifications to gsmtap.h, and therefore want to discuss more about this topic also here. Shinjo -- Shinjo Park Security in Telecommunications TU Berlin / Telekom Innovation Laboratories Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany Phone: +49 30 8353 58272 From nhofmeyr at sysmocom.de Mon Nov 27 12:13:01 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 27 Nov 2017 13:13:01 +0100 Subject: osmo-bts-trx init problem In-Reply-To: References: Message-ID: <20171127121301.glwlcwwhyycivtkw@my.box> On Fri, Nov 24, 2017 at 06:04:10PM +0300, GSK MOSS wrote: > * Invalid condition detected: Frame difference is 1685248-0 > 1* I'm not 100% sure but I think this is just some startup condition that you can safely ignore. > Reading config failed. > Exiting. those usually also output why reading the config failed. Do you get a more detailed error message? I took your attached openbsc.cfg and successfully started osmo-nitb with it, so maybe you just messed up the config name or something so that osmo-nitb *can't find* your file? > May be the problem is in *"*hlr.sqlite3"? I don't know. Ususally that wouldn't result in "reading config failed". The db file is hardly ever the problem though, I wouldn't think it is in your case either. If you want a new db file, simply move it out of the way / rename it / delete it, and osmo-nitb will create a fresh empty one automatically. After that you can use the telnet VTY to add subscribers again. A general remark: it would be appreciated if you sent mails to this list not in HTML format, but just in plain text. We read mails in plain text, and your line breaks are messed up because you're sending in HTML. 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 Nov 27 12:30:01 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 27 Nov 2017 13:30:01 +0100 Subject: Eclipse TITAN public release of SS7/SIGTRAN core protocols In-Reply-To: <20171124192835.GK3109@nataraja> References: <20171124192835.GK3109@nataraja> Message-ID: <20171127123001.gcnjat3a32oa7rvg@my.box> On Fri, Nov 24, 2017 at 08:28:35PM +0100, Harald Welte wrote: > Hi all, > > I've mentioned this many months before, but Ericsson has now (well, a > month ago) finally made a public announcement about the public release > of their SS7/SIGTRAN core protocols in TTCN-3. You can read more about > it at https://www.eclipse.org/forums/index.php/t/1089686/ - where they > actually even refer to us as being the trigger to release them. Heh, nice one, complete with an introductory paragraph :) > so e.g. A-bis RSL would first have to be implemented. The good part is > that it's actually super easy using the expressive syntax of the TITAN > "raw" codec. Basically you define the structure of the data in files > like http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_RR_Types.ttcn > and you don't have to write a single line for encoding/parsing :) So you write a "titan struct" and get the binary en/decoding from it, even with conditional presence and cross conditions and all. nice. Makes me think, could one use that in production code to parse/encode messages? It's C after all, isn't it. I wonder what its C representation looks like, whether it makes working with it any easier than the TLV code we're using. ~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 Mon Nov 27 13:06:11 2017 From: djks74 at gmail.com (Sandi Suhendro) Date: Mon, 27 Nov 2017 20:06:11 +0700 Subject: osmo-bts-trx init problem In-Reply-To: <20171127121301.glwlcwwhyycivtkw@my.box> References: <20171127121301.glwlcwwhyycivtkw@my.box> Message-ID: Dear Neels, Vadim, I tried the osmocomBB with my C118 also C117, and I install gnuarm and osmocomBB with sylvain and jolly to try both. seems the configuration is fine, but i have problem on the osmocombb tranceiver. my problem is : here are the log output from my transceiver : https://pastebin.com/8Y1qXWh8 then my osmonitb seems not moving cause transceiver not sync as I presumed: (its working for the configuration) https://pastebin.com/5wPhePfT also my osmo-bts stuck since its not sync with transceiver I guess : https://pastebin.com/T2s8GJ7e this is the tcpdump for osmocombb with osmonitb: https://wsi.li/1c4JhMOIUqOk/746634 THEN... I also tried with openbts, and the transceiver was terminated after I start ./transceiver -a 51 -r 99. here are the tcpdump with openbts, seems problem is from the transceiver? https://wsi.li/huJmuT6TSh3o/746634 so... hope you guys the problem from the indication I have? Thanks in advance. regards, Sandi On Mon, Nov 27, 2017 at 7:13 PM, Neels Hofmeyr wrote: > On Fri, Nov 24, 2017 at 06:04:10PM +0300, GSK MOSS wrote: > > * Invalid condition detected: Frame difference is 1685248-0 > 1* > > I'm not 100% sure but I think this is just some startup condition that you > can > safely ignore. > > > Reading config failed. > > Exiting. > > those usually also output why reading the config failed. > Do you get a more detailed error message? > > I took your attached openbsc.cfg and successfully started osmo-nitb with > it, so > maybe you just messed up the config name or something so that osmo-nitb > *can't > find* your file? > > > May be the problem is in *"*hlr.sqlite3"? I don't know. > > Ususally that wouldn't result in "reading config failed". The db file is > hardly > ever the problem though, I wouldn't think it is in your case either. > > If you want a new db file, simply move it out of the way / rename it / > delete > it, and osmo-nitb will create a fresh empty one automatically. After that > you > can use the telnet VTY to add subscribers again. > > > A general remark: it would be appreciated if you sent mails to this list > not in > HTML format, but just in plain text. We read mails in plain text, and your > line > breaks are messed up because you're sending in HTML. Thanks! > > ~N > -- best regards, Krazy Sandi Blue Soho Recordings Number One Recordings -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Nov 27 14:06:10 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 27 Nov 2017 15:06:10 +0100 Subject: Eclipse TITAN public release of SS7/SIGTRAN core protocols In-Reply-To: <20171127123001.gcnjat3a32oa7rvg@my.box> References: <20171124192835.GK3109@nataraja> <20171127123001.gcnjat3a32oa7rvg@my.box> Message-ID: <20171127140610.GQ24341@nataraja> Hi Neels, On Mon, Nov 27, 2017 at 01:30:01PM +0100, Neels Hofmeyr wrote: > On Fri, Nov 24, 2017 at 08:28:35PM +0100, Harald Welte wrote: > > so e.g. A-bis RSL would first have to be implemented. The good part is > > that it's actually super easy using the expressive syntax of the TITAN > > "raw" codec. Basically you define the structure of the data in files > > like http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_RR_Types.ttcn > > and you don't have to write a single line for encoding/parsing :) > > So you write a "titan struct" and get the binary en/decoding from it, even with > conditional presence and cross conditions and all. nice. Correct. A partial RSL implementation can be seen at http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/RSL_Types.ttcn My plan is to use this together with the A code for BSC level tests, so one can perform some procedure/activity on both A-bis and A and test if the BSC does what's expected. > Makes me think, could one use that in production code to parse/encode messages? I wouldn't want to try, at least not on the kind of low-performance systems that we normally work on. > It's C after all, isn't it. It's C++. > I wonder what its C representation looks like, You can simply compile a the TTCN module ("make compile") and you get the resulting generated C++ code. > whether it makes working with it any easier than the TLV code we're using. I think our TLV dode is exceptionally comfortable for a very low-overhead C-language approach. What is the difficulty? Of course it only handles the TLV structure and not the content of any IE. But that's because it is a TLV parser and not anything else... -- - 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 Nov 27 15:02:33 2017 From: djks74 at gmail.com (Sandi Suhendro) Date: Mon, 27 Nov 2017 22:02:33 +0700 Subject: osmo-bts-trx init problem In-Reply-To: References: <20171127121301.glwlcwwhyycivtkw@my.box> Message-ID: Hi all, The BTS work with Sylvain/testing now, but not with jolly/testing branch. strange! regards, Sandi On Mon, Nov 27, 2017 at 8:06 PM, Sandi Suhendro wrote: > Dear Neels, Vadim, > I tried the osmocomBB with my C118 also C117, and I install gnuarm and > osmocomBB with sylvain and jolly to try both. > seems the configuration is fine, but i have problem on the osmocombb > tranceiver. > my problem is : > > here are the log output from my transceiver : > https://pastebin.com/8Y1qXWh8 > > then my osmonitb seems not moving cause transceiver not sync as I > presumed: (its working for the configuration) > https://pastebin.com/5wPhePfT > > also my osmo-bts stuck since its not sync with transceiver I guess : > https://pastebin.com/T2s8GJ7e > > this is the tcpdump for osmocombb with osmonitb: > https://wsi.li/1c4JhMOIUqOk/746634 > > > > THEN... > I also tried with openbts, and the transceiver was terminated after I > start ./transceiver -a 51 -r 99. > here are the tcpdump with openbts, seems problem is from the transceiver? > https://wsi.li/huJmuT6TSh3o/746634 > > so... > hope you guys the problem from the indication I have? > > Thanks in advance. > > regards, > Sandi > > > > On Mon, Nov 27, 2017 at 7:13 PM, Neels Hofmeyr > wrote: > >> On Fri, Nov 24, 2017 at 06:04:10PM +0300, GSK MOSS wrote: >> > * Invalid condition detected: Frame difference is 1685248-0 > 1* >> >> I'm not 100% sure but I think this is just some startup condition that >> you can >> safely ignore. >> >> > Reading config failed. >> > Exiting. >> >> those usually also output why reading the config failed. >> Do you get a more detailed error message? >> >> I took your attached openbsc.cfg and successfully started osmo-nitb with >> it, so >> maybe you just messed up the config name or something so that osmo-nitb >> *can't >> find* your file? >> >> > May be the problem is in *"*hlr.sqlite3"? I don't know. >> >> Ususally that wouldn't result in "reading config failed". The db file is >> hardly >> ever the problem though, I wouldn't think it is in your case either. >> >> If you want a new db file, simply move it out of the way / rename it / >> delete >> it, and osmo-nitb will create a fresh empty one automatically. After that >> you >> can use the telnet VTY to add subscribers again. >> >> >> A general remark: it would be appreciated if you sent mails to this list >> not in >> HTML format, but just in plain text. We read mails in plain text, and >> your line >> breaks are messed up because you're sending in HTML. Thanks! >> >> ~N >> > > > > -- > best regards, > Krazy Sandi > Blue Soho Recordings > Number One Recordings > -- best regards, Krazy Sandi Blue Soho Recordings Number One Recordings -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Mon Nov 27 23:20:13 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Tue, 28 Nov 2017 06:20:13 +0700 Subject: osmo-bts-trx init problem In-Reply-To: References: <20171127121301.glwlcwwhyycivtkw@my.box> Message-ID: Hi Sandi, > here are the log output from my transceiver : > https://pastebin.com/8Y1qXWh8 According to the attached log, you don't have any clock indications... > sudo ./transceiver -a 51 -r 99 > ... > <0011> trx.c:365 Setting C0 ARFCN to 51 (GSM900) Please read the wiki carefully! You are doing wrong. What are you expecting here? Please refer: http://osmocom.org/projects/baseband/wiki/CalypsoBTS#Clock-source > use RSSI or cell_log applications to find cells with good > signal and remember the ARFCN numbers. One of them will be > used as a clock source for our own base station. http://osmocom.org/projects/baseband/wiki/CalypsoBTS#OsmoNITB-configuration > Channel configuration > > Set a proper ARFCN for running BTS (don't confuse with > a clock source). Also, set a corresponding band name. The AFRCN value, passed to the OsmocomBB transceiver, is a channel of the clock reference cell. The AFRCN value specified in the OsmoNiTB configuration is a C0 channel of the BTS you are going to run. Don't confuse them please. > I also tried with openbts, and the transceiver was terminated > after I start ./transceiver -a 51 -r 99. Again, read the wiki: http://osmocom.org/projects/baseband/wiki/CalypsoBTS#CalypsoBTS-with-OpenBTS > Run the TRX firmware on the phone as described above. No need to > start transceiver, OpenBTS will run it automatically. > The BTS work with Sylvain/testing now, > but not with jolly/testing branch. I just tested the latest versions of OsmoNiTB & OsmoBTS. Everything works as expected. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Nov 29 18:11:48 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 29 Nov 2017 19:11:48 +0100 Subject: LimeSDR support in osmocom:{nightly,latest} package feeds Message-ID: <20171129181148.GV3851@nataraja> Dear all, starting from today, we're packaging LimeSuite and (as needed) other dependencies required for using osmo-trx/osmo-bts-trx with LimeSDR in the network:osmocom:nightly and network:osmocom:latest feeds. The package versions are fixed and are not tracking "master" of e.g. limesuite. Only the Osmocom packages are tracking master. Due to the unfortunate fact that the first LimeSuite with osmo-trx support (17.09.0) requiring a cmake later than what Debian 8 ships, LimeSDR support is not working with all of the Distributions/Versions that the rest of the Osmocom stack supports. It appears that LimeSuite also has some build issues on ARM architectures, about which I've submitted an upstream bug report at https://github.com/myriadrf/LimeSuite/issues/151 But at least for x86_64 and i586 architecture, LimeSDR should be supported by the Osmocom package feeds , on Debian 9.0, Ubuntu 16.04, 16.10, 17.04 and 17.10. We will shortly use those packages as part of our osmo-gsm-tester setup at the sysmocom lab, at which point they should receive extensive testing. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)