- OpenBSC - lists.osmocom.org

git tagging
by Max 14 Dec '16

14 Dec '16

Hi. With the migration to gerrit the situation around version tagging become even funnier than before. For example right now in libosmocore v0.9.3 does not exist as a git tag, only as entry in debian/changelog. Versions 0.9.5 and 0.9.6 are committed in reversed order - see output of git log --tags --show-notes --decorate | grep 'tag:' | head So the questions are: - how can I add tag '0.9.3' to commit abc46af90fde9e9435dee5f4f472aec3f68d3353 in libosmocore - how can we prevent the inverted commit situation as with 0.9.6 and 0.9.5 in future? - what's the general guidelines for tagging new versions? Do we go through gerrit or ask responsible person (who?) to do it manually? Or even auto-tag commit matching certain criteria? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

3 4

Re: libosmocore[master]: Catch-up with git version tags
by Neels Hofmeyr 14 Dec '16

14 Dec '16

On Tue, Dec 13, 2016 at 10:58:12PM +0000, Holger Freyther wrote: > Patch Set 1: Code-Review-1 > > The point of TODO-RELEASE is to remember ABI changes. An ABI change requires increasing the version number of the .so files (see the libtool link in Makefile.am for exact rules but we only bump for incompatible versions). Another point here could be that we can't just create a new minor tag without checking this? Does our non-existent policy dictate that an ABI version change should cause a bump in a "middle" version number? i.e. if a commit has been merged that has ABI changes and I want to tag a commit in order to reference it from another project's configure.ac, am I forced to make a bigger version bump than just 0.9.4 -> 0.9.5? All this would be good topics for the next OsmoDevCon... ~N

1 0

Re: Osmo-bts/Osmocom-bb virtual layer 1
by Sebastian Stumpf 14 Dec '16

14 Dec '16

Hi Harald, > why send a private response and not a mail to the mailing list? Sorry, not intended - misclicked on respond instead of respond to all! :) > If you want, I can give you commit access so you can push your private > branches to git.osmocom.org. I just created an account on osmocom.org and logged in to gerrit via osmocom.org/openid (account: BastusIII). As I have never used git-send-email I prefer the commit access. Thank you! I would call the branches stumpf/virt-phy for both osmo-bts and osmocom-bb. With kind regards, Sebastian Am 12.12.2016 15:15 schrieb "Harald Welte" <laforge(a)gnumonks.org>: Hi Sebastian, why send a private response and not a mail to the mailing list? I think they all are interested to read this. On Mon, Dec 12, 2016 at 01:57:05PM +0100, Sebastian Stumpf wrote: > I have not published the Code yet as the vlayer still lacks some basic > functionality. Would you suggest to do so already? yes, by all means. There's a difference between having code in the public for review / improvements by others and submitting it for inclsion into master as it is considered "fixed" If you want, I can give you commit access so you can push your private branches to git.osmocom.org. For that, you would have to create an account on gerrit.osmocom.org (which requires first creating one on osmocom.org) If you prefer to simply send a patchset by git-send-email or to host you git repos on github or any other git hosting site, that's fine, too. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 4

Re: RBS 2308
by Rajitha peiris 13 Dec '16

13 Dec '16

Hi dear.... i am tired with rbs 2308.... i have purchased nano bts....but i will try to improve that also.... if you have any updates pls letme... On Harald Welte <laforge(a)gnumonks.org>, Dec 12, 2016 2:45 AM wrote: Hi Rajitha, On Sun, Dec 11, 2016 at 01:02:19PM +0000, Rajitha peiris wrote: > i was spent more time on it....these days i am reading on oml 2000 ...if there new updates i will tell you.... If you run into a specific issue, please always feel free to contact this list. But make sure to include your full config file, openbsc log output and pcap protocol trace. We need sufficient data for any kind of investigation. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

new sanitizer breakage: SIGSEGV in sgsn_create_pdp_ctx()
by Neels Hofmeyr 13 Dec '16

13 Dec '16

The sanitizer build used to get through to testing the PCU, now it already fails at openbsc's sgsn test. This happens in the recently added test_pdp_deactivation_with_pdp_ctx: http://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/388/consoleFull commit 1611df5226199da2bf2fba3d22d93cc1a6c6c777 Commit: Pravin Kumarvel <pmanohar(a)radisys.com> CommitDate: Mon Dec 12 17:20:39 2016 +0530 Support Deactivate PDP Context Request from network https://gerrit.osmocom.org/1262 I can reproduce the segmentation fault locally, but only when the sanitizer is enabled. When stepping up to the failure and checking the parameters, all seems to be in order; immediately when trying to step into sgsn_create_pdp_ctx(), the SIGSEGV is fired. So far the actual failure is not clear to me, I haven't found the 0x02 pointer yet that asan complains about: ==21897==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000002 I found a use-after-free which isn't the cause for above asan failure: gsm0408_gprs_access_cancelled(mm, GMM_CAUSE_GPRS_NOTALLOWED); LOGMMCTXP(LOGL_NOTICE, mm, "No PDP context to deactivate\n"); gsm0408_gprs_access_cancelled() calls mm_ctx_cleanup_free(), and after that the local mm is non-NULL but freed. Change the order to: LOGMMCTXP(LOGL_NOTICE, mm, "No PDP context to deactivate\n"); gsm0408_gprs_access_cancelled(mm, GMM_CAUSE_GPRS_NOTALLOWED); (This second issue is shown when removing test_pdp_deactivation_with_pdp_ctx() from test_pdp_deactivation()) The cause for the asan failure shown above and in jenkins still evades me. But I'm afraid we have to revert the patch. Please run the asan build on this patch and re-submit when the cause is clear. How to asan build has been discussed recently: http://lists.osmocom.org/pipermail/openbsc/2016-November/009901.html ~N -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

2 2

TbfTest fails sanitizer build, please take a look @tbf-folks
by Neels Hofmeyr 13 Dec '16

13 Dec '16

Dear authors of Tbf, can you make sense of this build failure? https://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/373/console It shows that the expected stderr output of the TbfTest deviates, and the test exits prematurely. interesting output: +tbf_dl.cpp:766:65: runtime error: load of value 32767, which is not a valid value for type 'egprs_puncturing_values' -- got ack for BSN=1258 -- got ack for BSN=1259 -- got ack for BSN=1260 +- got NACK for BSN=1258 +- got NACK for BSN=1259 +- got NACK for BSN=1260 To help reproducing it, find below the jenkins script that runs this sanitizer build. Thanks for any patches that could fix our sanitizer build! ~Neels #!/bin/sh set -ex export BUILDDIR=$PWD/build/ export PKG_CONFIG_PATH=$BUILDDIR/lib/pkgconfig export LD_LIBRARY_PATH=$BUILDDIR/lib/ export PATH="$PATH:$HOME/osmo-ci/scripts" build() { RET=$PWD git clone git://git.osmocom.org/$1 source/$1 cd source/$1 git checkout -b build-branch origin/$2 cd $3 autoreconf --install --force ./configure --prefix=$BUILDDIR $4 make check CFLAGS+="-fsanitize=address -fsanitize=undefined" CXXFLAGS+="-fsanitize=address -fsanitize=undefined" ASAN_OPTIONS="detect_leaks=0" UBSAN_OPTIONS="print_stacktrace=1:halt_on_error=1" \ || cat-testlogs.sh make install CFLAGS+="-fsanitize=address -fsanitize=undefined" CXXFLAGS+="-fsanitize=address -fsanitize=undefined" cd $RET } rm -rf $BUILDDIR rm -rf source mkdir -p source mkdir -p $BUILDDIR/include/sysmocom/femtobts git clone git://git.sysmocom.de/sysmo-bts/layer1-api.git source/layer1-api/ cp source/layer1-api/include/* $BUILDDIR/include/sysmocom/femtobts/ build libosmocore $LIBOSMOCORE_BRANCH ./ build libosmo-abis $LIBOSMOABIS_BRANCH ./ build libosmo-netif $LIBOSMONETIF_BRANCH ./ build libosmo-sccp $LIBOSMOSCCP_BRANCH ./ # gcc ice's #build libsmpp34 $LIBSMPP_BRANCH build openggsn $OPENGGSN_BRANCH ./ build openbsc $OPENBSC_BRANCH ./openbsc "--enable-nat --enable-osmo-bsc --enable-vty-tests --enable-external-tests" build osmo-pcu $OSMOPCU_BRANCH ./ "--enable-sysmocom-dsp --enable-vty-tests" build osmo-bts $OSMOBTS_BRANCH ./ "--enable-sysmocom-bts --enable-trx" -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

2 6

Osmo-bts/Osmocom-bb virtual layer 1
by Sebastian Stumpf 12 Dec '16

12 Dec '16

Hi, I further implemented the base of the virtual layer with the purpose of replacing the um-air interface with a multicast-socket solution. This has been started by Harald Welte some time ago in the Osmobts - laforge/virt-bts branch. As I was not really confident enough to create an official new branch before someone had a look on what I did, so I developed in copies of the osmocom-bb and osmo-bts projects on my github-page (https://github.com/BastusIII/osmocom-bb-virt/tree/stumpf/virt-um and https://github.com/BastusIII/osmo-bts-virt/tree/stumpf/virt-bts) If someone finds to time to have a look into them (structure, path, implementation) and give me feedback about it, I would be glad :). Please use the following config files that i have tested: - https://github.com/BastusIII/osmocom-config-files/blob/master/openbsc-virtu… - https://github.com/BastusIII/osmocom-config-files/blob/master/osmobts-virtu… - https://github.com/BastusIII/osmocom-config-files/blob/master/osmocom-bb-mo… What works: BTS: - downlink over gsmtap and a multicast socket - OML and RSL on abis properly established and seems to work - virtual-um connection establishment Osmocom-bb: - virtual-um -- l23 app connection establishment (bridging osmocon, no serial link needed) - BCCH downlink handling and forwarding to l23 app - handling of some l1ctl requests from l23 (e.g. power management had to be mocked, so l23 gets a response and is satisfied) What not: BTS: - missing uplink handling Osmocom-bb - missing uplink routines (RACH, TCH, dedicated channels) - handlers for l23 requests only partially implemented (missing TCH, RACH, ... I a currently a bit overwhelmed by the mass of messages exchanged between l23-app (used mobile, btw.) and the virtual-um and hanging because mobile gets a sync timeout. I am looking forward to hear from you :). Sebastian Stumpf

2 2

Re: RBS 2308
by Rajitha peiris 11 Dec '16

11 Dec '16

hi dear... i was spent more time on it....these days i am reading on oml 2000 ...if there new updates i will tell you.... regards rajitha Sent from my Mi phone On Holger Freyther <holger(a)freyther.de>, Dec 10, 2016 8:42 PM wrote: > On 10 Dec 2016, at 03:10, Rajitha peiris <raji.oshin(a)hotmail.com> wrote: > > > Hi all.. Hi! > Anyone have success with rbs 2308 ??? > If you have any idea pls share ... your contribution will be very welcome! Do you think you can still spend time on improving OpenBSC in 2016? regards holger

2 1

openbsc build was broken due to change in libosmocore: missing doc for 'log gsmtap [HOSTNAME]'
by Neels Hofmeyr 11 Dec '16

11 Dec '16

The libosmocore commit aa00f99be2e4cc64ede20d8c9548b83054696581 adds a VTY item that's missing a doc string, hence breaking the openbsc build (which actually checks the doc strings unlike the libosmocore build job). I pushed the fix I734b22c950242541322e902887bf779c14ba10fd and things should light up "green" (aka blue) again. BTW, in a RL discussion lynxis suggested that it would be good if libosmocore commits were also checked against breaking openbsc. A point against it is that often something in libosmocore is changed and requires a follow-up in openbsc -- if the libosmocore build rejects commits that break openbsc, it would make it impossible to get these changes in. The workaround could be to have a secondary build job that merely comments on gerrit whether the openbsc build still works, without having -V voting powers. Anyway, so far I think it is sufficient to catch these hopefully few cases once the regular master build on jenkins.osmocore.org goes up red, like now. ~N -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

2 1

Re:OpenBSC Digest, Vol 26, Issue 7
by Rajitha peiris 11 Dec '16

11 Dec '16

anyone know about rbs 2308 is supported yet or not...or still under experimental stage... thanks regards rajitha peiris sri Lanka Sent from my Mi phone On "openbsc-request(a)lists.osmocom.org" <openbsc-request(a)lists.osmocom.org>, Dec 7, 2016 11:11 PM wrote: Send OpenBSC mailing list submissions to openbsc(a)lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request(a)lists.osmocom.org You can reach the person managing the list at openbsc-owner(a)lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: Paging not answered in m2m call (Holger Freyther) 2. Re: Paging not answered in m2m call (Kristian Martens) ---------------------------------------------------------------------- Message: 1 Date: Wed, 7 Dec 2016 18:13:10 +0100 From: Holger Freyther <holger(a)freyther.de> To: Kristian Martens <kristian.martens(a)ng4t.com> Cc: openbsc(a)lists.osmocom.org Subject: Re: Paging not answered in m2m call Message-ID: <D782A7D5-AD0D-4BE0-9898-2AEC6151BAB0(a)freyther.de> Content-Type: text/plain; charset=us-ascii > On 07 Dec 2016, at 17:52, Kristian Martens <kristian.martens(a)ng4t.com> wrote: > > Hello, Hi! > two UEs (A and B) are successfully registered in a network. Now A tries > to call B. B is paged by the core via A interface but the sysmoBSC/BTS > does not seem to page the UE (or UE does not answer paging). What could > be the reason for this behaviour? How could the problem be debugged? > Please find the attached pcap for your reference. nice MNC! The P-TMSI doesn't really look that random but it might be an index into an internal data structure? So on A this looks right. The LAI is 262-79-1 and this is where you are paging. In general it might be: * osmo-bsc doesn't translate this to actual paging. E.g. not linking/ handling the location area identifier. You could trace the RSL protocol and see if a paging command is being sent (periodically) to the BTS? * The MS still has a radio channel open. I notice that clear command is being sent so this is unlikely to be the case. Also IMSI seems to be match.. maybe the MS still calculates the paging group wrongly? That is far fetched though. holger ------------------------------ Message: 2 Date: Wed, 7 Dec 2016 18:41:08 +0100 From: Kristian Martens <kristian.martens(a)ng4t.com> To: Holger Freyther <holger(a)freyther.de> Cc: openbsc(a)lists.osmocom.org Subject: Re: Paging not answered in m2m call Message-ID: <9a4bcc68-e884-0f48-8a26-989b7edf5bca(a)ng4t.com> Content-Type: text/plain; charset="utf-8" Hi, I have captured a trace. Can you find something out? Thanks, Kristian Am 07.12.2016 um 18:13 schrieb Holger Freyther: >> On 07 Dec 2016, at 17:52, Kristian Martens <kristian.martens(a)ng4t.com> wrote: >> >> Hello, > Hi! > >> two UEs (A and B) are successfully registered in a network. Now A tries >> to call B. B is paged by the core via A interface but the sysmoBSC/BTS >> does not seem to page the UE (or UE does not answer paging). What could >> be the reason for this behaviour? How could the problem be debugged? >> Please find the attached pcap for your reference. > > nice MNC! The P-TMSI doesn't really look that random but it might be an > index into an internal data structure? > > So on A this looks right. The LAI is 262-79-1 and this is where you are > paging. In general it might be: > > * osmo-bsc doesn't translate this to actual paging. E.g. not linking/ > handling the location area identifier. You could trace the RSL protocol > and see if a paging command is being sent (periodically) to the BTS? > > * The MS still has a radio channel open. I notice that clear command is > being sent so this is unlikely to be the case. Also IMSI seems to be > match.. maybe the MS still calculates the paging group wrongly? That is > far fetched though. > > > holger -------------- next part -------------- A non-text attachment was scrubbed... Name: 20161207_nopaging.pcap Type: application/octet-stream Size: 26302 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161207/dccfca29/at…> ------------------------------ Subject: Digest Footer _______________________________________________ OpenBSC mailing list OpenBSC(a)lists.osmocom.org https://lists.osmocom.org/mailman/listinfo/openbsc ------------------------------ End of OpenBSC Digest, Vol 26, Issue 7 **************************************

2 1