OpenBSC

openbsc@lists.osmocom.org

12 participants
4278 discussions

sporadic gerrit build job failue: "broken pipe"
by Neels Hofmeyr 22 Dec '16

22 Dec '16

We get this more often than not in the openbsc build job, I'm still not sure how to fix it: ====================================================================== ERROR: testBSCreload (__main__.TestVTYNAT) ---------------------------------------------------------------------- Traceback (most recent call last): File "./vty_test_runner.py", line 785, in testBSCreload b0 = nat_bsc_sock_test(0, "lol") File "./vty_test_runner.py", line 1276, in nat_bsc_sock_test ipa_handle_resp(bsc, tk, verbose) File "./vty_test_runner.py", line 1260, in ipa_handle_resp x.send(IPA().id_resp(IPA().identity(name = tk.encode('utf-8')))) error: [Errno 32] Broken pipe ---------------------------------------------------------------------- Ran 43 tests in 51.717s FAILED (errors=1) Reducing the nr of executors hasn't had an effect yet. Could there be another cause? Too fragile timing or something? ~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 4

indicating a necessary revision
by Neels Hofmeyr 19 Dec '16

19 Dec '16

When committing a change that needs a specific change from another project, but that other change is still in the gerrit queue and has no final git commit hash yet, it is handy to use the Change-Id to reference the given decision. Harald recently requested that I always include the Change-Id in the commit log. Now Max says: > It's better to update commit log with git commit hash instead of change-id > before final submission. Can we get consensus? Should we modify the commit log from Change-Id to git hash once the required other commit is through? The Change-Id is always there and can be searched for in the git log; and should we ever decide to rehash the git history or move to another version control software (losing all git hashes), the Change-Id would still be there. But the git hash, once it is finalized, can be used directly on the git commandline. I wouldn't have done the extra effort, but if all agree that the git hash is better, I'll change it (and hopefully remember to do it, too). ~N

1 0

osmo-iuh-3G_2016_09
by Radiarisainana Sitraka 19 Dec '16

19 Dec '16

Hello, I have some question, is it possible to run osmo-iuh with the vodafone signal secure 3 !? or should I root it !? Chears,

2 1

libosmocore changes / release process
by Neels Hofmeyr 19 Dec '16

19 Dec '16

When I now change pretty much anything in libosmocore that I want to use in e.g. openbsc.git, I would like to bump the minor revision and reference that in other projects' configure.ac. The effort is ok if it entails only tagging a revision and using that elsewhere. However, this has come down to a lengthy process: " cleanup TODO-RELEASE file if not empty, bumping API versions accordingly (see comments in TODO-RELEASE) update debian/changelog using "gbp dch" command " https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_releas… So, pretty much every commit in libosmocore will be followed by another commit that is adjusting the changelog...? :/ Should we adjust the changelog along with pretty much any change used outside of libosmocore? :/ (probably not, because reverting anything is made cumbersome) Should we rather, like, make a libosmocore release only once a week and somehow track wich other projects need a bump to the required libosmocore version? I think most projects out there make a release tag only every now and then. We could limit to noting the required libosmocore change-id in other projects' commit logs until the next (minor) release is made...? Can we add a fourth level of version that doesn't require a changelog/debian release? So for every small change I make I would tag 0.9.6.1, 0.9.6.2, etc., and at some point we make 0.9.7 along with a changelog adjustment? Thoughts? ~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

3 7

reduce gerrit mails?
by Neels Hofmeyr 15 Dec '16

15 Dec '16

Hi Gerrit users, I follow the gerrit mails to get notified of comments and to catch failing builds. The message that a build started or was successful though doesn't help me much, only clutters up space, really. Do you agree? If yes, I would try to silence the "Build started" and "Build successful" messages in our gerrit, if possible without too much effort... ~N

3 5

[nhofmeyr@sysmocom.de: Re: Help required on : Reproducing the issue]
by Neels Hofmeyr 15 Dec '16

15 Dec '16

On Wed, Dec 14, 2016 at 02:24:23PM +0000, Pravin Kumaravel Manoharan wrote: > I tried to reproduce the issue mentioned in http://lists.osmocom.org/pipermail/openbsc/2016-December/009966.html . > While running sanitizer script I got an error gcc: error: unrecognized command line option '-fsanitize=undefined' > So, to avoid this I removed the option from CFLAGS+= and CXXFLAGS+= . That's odd, all compilers I've used so far apparently support -fsanitize=address -fsanitize=undefined anyway: > Then I got the following error : > ERROR: Address Sanitizer: heap-use-after-free on address 0x60380000a00c at pc 0x436acf bp 0x7ffc4456d4e0 sp 0x7ffc4456d4d8 > but I didn't get any SIGSEGV in sgsn_create_pdp_ctx(). Have you reversed the order of those two lines I wrote about earlier to fix the use-after-free yet? This is what I wrote: > 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()) If you do that, do you still get any asan errors? I hope that you'll be able to reproduce the segfault, since it was seen on both our build server as well as my own laptop... ~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 ----- End forwarded message ----- -- - 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

1 0

git tagging
by Max 15 Dec '16

15 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 15 Dec '16

15 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 14 Dec '16

14 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC