- OpenBSC - lists.osmocom.org

OSMO-BTS-TRX maxdly and maxdlynb Configuration Save issue
by Ron 17 Oct '17

17 Oct '17

Hi All, We tried to edit the maxdly and maxdlynb in osmo-bts-trx through CLI and everything works fine. But after saving the configuration and restarting the osmo-bts-trx instance, it give an unable to parse error. The reason we found is that, the osmo-bts-trx needed the “osmotrx maxdly 2” string to parse the config file correctly but the CLI config save is only “maxdly 2”. So we need to edit the config file manually so that the osmo-bts-trx can parse the config file correctly. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

2 1

Planning for OsmoCon + OsmoDevCon
by Harald Welte 17 Oct '17

17 Oct '17

[cross-post to many lists, please follow-up-to openbsc(a)lists.osmocom.org] Dear all, time is flying, and I would like to start early with discussions and planning about OsmoCon and OsmoDevCon in 2018. It helps to start early. Side note: We have some pending issues about the events from last year at http://osmocom.org/projects/osmo-dev-con/issues - I've incorporated them in the text below. == OsmoDevCon == For OsmoDevCon, I think it's easy: We keep it as-is. Same procedure as every year, which means: * same venue, same catering options * same concept of 'anyone contributing to Osmocom can apply for registration until all seats are taken' * same idea of inviting some few speaker[s] doing other FOSS mobile communications work to join us The parts that we need to change, IMHO: * don't reduce from 4 to 3 days like last year. Have full 4 days again * sort topics per day / half-day, i.e. have "GSM/UMTS Cellular Infrastructure" days for BTS/BSC/NITB/MSC/HLR/SGSN/GGSN & Co, but then have other days for other projects. This would enable people not interested in the [continued evolvement] of the cellular projects be able to skip those days, or to simply meet in an adjacent room for parallel hacking sessions/discussions * try to be a bit more structured with the schedule in general. The existing approach works for people who attend all the event all day long, but not so well for people with other plans / limited time Any further change requests or topics to discuss? Please note that Pablo Neira has offered to kindly host an OsmoDevCon in Seville (Spain). I've attended a number of netfilter workshops he organized there, and he's doing a great job! However, given the large number of attendees from Berlin (and Germany in general), I think this would make things more complicated, and more expensive for most attendees. If you disagree with that assessment: I'm open for having the discussion, I just thought it's more practical/economic to do it in Berlin. === 10 year Anniversary Party === Given that 2018 marks the 10 year anniversary of Dieter and me hacking with the Siemens BS-11 in 2008, I think the 2018 incarnation deserves some special celebration of some form. I have no concrete idea yet, but for sure we should so something, and it should be at/around OsmoDevCon. And for sure we should have a BS-11 around :) == OsmoCon == The public OsmoCon was welcomed and was a success. However, let's start this discussion with a review of last years event. === Registration === * Registrations came in way too late. Two weeks ahead of the event, we were considering to cancel it. And then within the last few days, we had to turn people down due to limited seating capacity * To make planning more reliable, we see on other option but to significantly raise the registration fee combined with an equally significant discount for early booking === Duration === * Many people requested multiple days rather than just one, in order to make more out of (long distance) travels. This is obvious, but as we had no idea how many people would attend at all (or if we have to cancel due to lack of attendance), planning multiple days in the first incarnation would have been high risk and a multitude of work * I would suggest to expand to two or even three days this week, possibly one days with tutorials and the other day with tech talks * Slightly less crammed schedule due to multiple days === Venue === We recognize this yearso venue was not the best option, due to * Bad ventilation in the basemenet * Difficult to find * No space next to the conference room where people can meet / hang out in parallel to talks (not everyone attends every talk) I still like the "understatement" of the venue. I'd prefer any hostel / non-profit / hackerspace / university over luxurious hotels any time. Going to an expensive venue means more or less automatically more expensive ticket fees, which again is more likely to exclude pure community members without a commercial activity related to Osmocom. So any future venue would ideally: * be able to hold slightly more people than this year * have a second room or large lobby in which people can meet for extended coffee breaks in parallel to some talks, as needed * be slightly easier to find (and we have to put up some signs outside and in the lobby) * have better WiFi and/or wired connectivity === Programme / Format === * less crammed over multiple days * some more "interactive" formats were requested, for users to provide feedback to developers * there was some discussion about topics / speakers in redmine last year, but not too much participation [until it was too late]. * I'd suggest a more formal CfP process with a submission deadline that allows us to publish a preliminary schedule long ahead of the event === Video Recordings === I think they were a big success, and it was a very big surprise that the CCC Video Operations Center was volunteering to help such a small and niche-interest event like OsmoCon. We should make sure that we can repeat this for 2018. == Dates / Frequency == Having OsmoCon and OsmoDevCon back to back becomes somewhat long, if OsmoCon is 2-3 days and OsmoDevCon is 4 days. Basically we're looking at a full week for those of you who would like to attend both events. But then, I think the number of people attending both events is actually not all that big. Without checking the details, I think not more than half of the OsmoDevCon attendees were attending OsmoCon. I would expect that tendency to remain or even increase. I still think it's good to keep them back-to-back. In terms of frequency, I would actually suggest we move to a 6-month cycle rather than a 12-month cycle. There's a lot of development going on at all time. I understand that not everyone is able to attend two events just on Osmocom, especially if it's a spare time / hobby type activity. That's ok, I think there's no problem with attending either of the two only, and catching up by video recordings and/or mail on the other. The qeustion is: Should that second event be developer-oriented or user-oriented? Or again both? Any comments here? Ok, that was a somewhat lengthy e-mail. Please make sure to provide any feedback you may have as early as possible, to increase the chances of your feedback being reflected in the planning. Happy hacking, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 8

Integrating openBSC with 3rd party MSC
by Anindya Sankar Roy 17 Oct '17

17 Oct '17

Hello, I need some help regarding configuration of 3rd party msc to the openbsc. I have seen the msc command in the openBSC terminal which I entered and felt like a profile creation for MSC's. But I got little confused doing it, can anyone provide me any documentation regarding basic connection that I need to do in order to get a up and running GSM network. Thanks Anindya

4 14

log level everything
by Keith 17 Oct '17

17 Oct '17

Hi Max! Since https://gerrit.osmocom.org/#/c/3148/ I am no longer able to individually control log levels in the vty. I used to use logging level all everything, then this allowed me to do such as logging level smpp fatal (get rid of annoying bind check every 30 secs) logging level [category i'm interested in] debug Now, all I seem to be able to do is turn all categories to a level with logging level all debug or logging level all notice. individual category directives such as logging level pag fatal make no difference. What am I missing? Thanks! BTW, I get the behaviour I need back by moving your check below the check for "all":: diff --git a/src/vty/logging_vty.c b/src/vty/logging_vty.c index 01480b1..fb2cab8 100644 --- a/src/vty/logging_vty.c +++ b/src/vty/logging_vty.c @@ -213,17 +213,18 @@ DEFUN(logging_level, return CMD_WARNING; } - if (strcmp(argv[1], "everything") == 0) { /* FIXME: remove this check once 'everything' is phased out */ - vty_out(vty, "%% Ignoring deprecated logging level %s%s", argv[1], VTY_NEWLINE); - return CMD_SUCCESS; - } - /* Check for special case where we want to set global log level */ if (!strcmp(argv[0], "all")) { log_set_log_level(tgt, level); return CMD_SUCCESS; } + if (strcmp(argv[1], "everything") == 0) { /* FIXME: remove this check once 'everything' is phased out */ + vty_out(vty, "%% Ignoring deprecated logging level %s%s", argv[1], VTY_NEWLINE); + return CMD_SUCCESS; + } + + if (category < 0) { vty_out(vty, "Invalid category `%s'%s", argv[0], VTY_NEWLINE); return CMD_WARNING;

5 13

Location Update Error
by Sudhanthiradasan R 16 Oct '17

16 Oct '17

Hello, I'm getting below error, when I ran "/usr/local/osmo_built/bin/osmo-nitb -c ./../osmo_cfg/osmo-nitb_2trx.cfg -l ./../osmo_cfg/hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM" <0000> abis_rsl.c:2013 (bts=0,trx=1,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION <0000> gsm_04_08.c:3960 Dispatching 04.08 message, pdisc=5 <0002> gsm_04_08.c:1389 LOCATION UPDATING REQUEST: MI(IMSI)=901550000001016 type=NORMAL <0001> gsm_04_08.c:149 (bts 0 trx 1 ts 0 pd 05) Sending 0x18 to MS. <0000> abis_rsl.c:2013 (bts=0,trx=1,ts=0,ss=0) SAPI=0 ERROR INDICATION <0000> abis_rsl.c:1954 (bts=0,trx=1,ts=0,ss=0) ERROR INDICATION cause=SABM frame with information not allowed in this state in state=ACTIVE <0002> gsm_04_08.c:596 Location Updating Request procedure timedout. <0002> gsm_04_08.c:474 Subscriber 901550000001016: LOCATION UPDATING REJECT LAC=1 BTS=0 <0001> gsm_04_08.c:149 (bts 0 trx 1 ts 0 pd 05) Sending 0x04 to MS. Anyone had the same issue earlier? Is there any solution for this error? Thanks, Sudhanthiradasan R ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ----------------------------------------------------------------------------------------------------------------------------------------------------

2 1

libosmo-netif interface
by Max 15 Oct '17

15 Oct '17

Hi. While looking at osmocom/netif/datagram.h I've noticed that it's organized differently compared to other libosmo*. Most notably, it does not have structure definitions, only brief declarations in datagram.h while the actual definition is in datagram.c This effectively means that client code using the library do not have access to struct internals and have to use various "osmo_dgram_.x_set_*()" functions to manipulate them. This got me curious - what are the pros and cons of this approach? I can see the benefit of being able to change struct internals without changing the API. I can also see the downside in having to define lot's of boilerplate setter/getter functions. What else? Are there other nice things about this approach? Is there a way to avoid or at least simplify setter/getter boilerplate? Are there some other downsides to this? -- 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

2 1

osmo-bts-trx fails frequently on osmo-gsm-tester
by Neels Hofmeyr 10 Oct '17

10 Oct '17

We're still having massive stability problems with osmo-bts-trx on the osmo-gsm-tester. I have run a tcpdump on the ntp port for the past days, and nothing is doing ntp besides the actual ntp service. Today I started ntp while an osmo-bts-trx run was active and what do you know, the osmo-bts-trx process exits immediately. I think this is bad, osmo-bts-trx shouldn't use wall clock time for precise timing needs. Besides that, I have no idea what could cause the clock skews, except maybe that the CPU or the USB are not fast enough?? I'm wondering, is there still such a thing as a separate linux realtime kernel? We will soon take to productive use another main unit which will be a cleanly installed OS. If we see the same problems on that system and can't find a software fix, we may need to reconsider the tester for osmo-bts-trx... ~N

8 26

prng change feedback
by ringsignature＠riseup.net 09 Oct '17

09 Oct '17

Hello, Apologies in advance for not responding to the relevant thread/message IDs. First time poster, long time reader. Reviewing the relevant email thread about "randomness of identifiers" and the design in the proposed changes [0] by Max, it seems that the patch is reasonable with one or two exceptions. Using OpenSSL is neither necessary, nor sufficient. My understanding is that it brings other restrictions on the use of the RNG, the state of the process, as well as a history of serious security concerns. There are a number of OpenSSL forks such as LibreSSL that seem to be addressing memory safety which might be a better choice. Many user space PRNGs now use getrandom() internally with added complexity in user space which does not seem strictly necessary. If the system RNG is properly seeded at boot, getrandom() should not block at any later point in the system's lifetime. After Nadia Heninger's work[1] attacking the Linux PRNG, the kernel team greatly improved the state of the kernel's RNG/RNG interfaces. If the system RNG is not properly seeded, it is game over. Systems running OpenBSC need to have cryptographically secure source of random numbers. If a user space cryptographic library really is required, it would probably be better to use NaCL [2] which is a well designed library for cryptography. It considers many cryptographic concerns such as various side channel attacks and properly handles each concern in a systematic manner. OpenSSL and its family do not seem to have been so carefully designed. There was recently an interesting design posted [3] by djb about the design of "Fast-key-erasure random-number generators" which sounds exactly like what is desired for this use case. It should be extremely easy to implement. Still, the use of getrandom() without re-seeding is probably necessary and should also be sufficient even for non GNU/Linux systems. Returning to Max's patch: [4] - A lack of a good random number generator should be a hard build/runtime failure. [5] - GNU_TLS is suggested and on the mailing list, OpenSSL, neither seems to be needed. Using glibc interface is less complicated than a full user space RNG. Has anyone reviewed it? Can it fail? If so, how does it fail? It is simple enough that intuitively it should be safe. Using the system call directly should ensure the guarantees of the API are met without any issues. The issue of re-seeding [6] is also one worth re-considering. One lesson learned from various problems with TLS is worth considering here as well: it should be secure to expose random outputs from the (P)RNG and still, it is better to _never_ expose random outputs directly to the network or to an attacker. A simple design for that is simply to hash or encrypt random bytes as djb suggests in his [3] design. Raw PRNG bytes may allow an attacker to break your PRNG as was the case with ExtendedRandom and DualEC [7]. The Debian OpenSSL case [8] is also informative, though of a completely different class of worst case failures, one hopes. Regarding the conclusion of the reviewer: merging Max's code while removing the rand() failure mode would be a net improvement for OpenBSC. The build should fail without getrandom(). Is there any system where this is an expected failure mode? Anything more complex probably deserves a design discussion with a well defined threat model for a given system. Happy Hacking, RS As an aside: If for some reason there is no cryptographically secure hardware RNG on the OpenBSC system, one wonders if it might be of interest to use the available RF interfaces as part of a design for such an RNG. There would be concerns about adversarial control of inputs, of course. It is also reasonable to try to have multiple sources of entropy, especially if the only hardware RNG device is one that isn't verifiable by end users such as RDRAND [9]. [0] https://gerrit.osmocom.org/#/c/1526 [1] https://crypto.stanford.edu/RealWorldCrypto/slides/nadia.pdf [2] https://nacl.cr.yp.to/features.html [3] https://blog.cr.yp.to/20170723-random.html [4] https://gerrit.osmocom.org/#/c/1526/8/utils/osmo-auc-gen.c [5] https://gerrit.osmocom.org/#/c/1526/8//COMMIT_MSG [6] https://blog.cr.yp.to/20140205-entropy.html [7] https://en.wikipedia.org/wiki/Bullrun_%28decryption_program%29 [8] https://freedom-to-tinker.com/2013/09/20/software-transparency-debian-opens… [9] https://en.wikipedia.org/wiki/RdRand#Reception

4 24

FYI: upstream asn1c progress
by Harald Welte 09 Oct '17

09 Oct '17

Hi all, upstream asn1c (https://github.com/vlm/asn1c) has made significant progress in 2017. It now has basic support for information object classes, and while doing some S1AP related test I also could compile an unmodified RANAP ASN.1 syntax from osmo-iuh.git commit 8f2fb0cca5f990b26478e9ec1207fa1e39e691eb - i.e. before all the various rewrites and hacks that we added to make it pass the much older asn1c that we were using at the time. In case anyone wants to play with this, I've had success with asn1c up to git commit https://github.com/vlm/asn1c/commit/e700b208bc0b252c85390a80ee63f3687fb2d970 until https://github.com/vlm/asn1c/commit/ea6635bdae9667bcf6111a25d896c556c946c11a unfortunately introduces a regression that's tracked in https://github.com/vlm/asn1c/issues/185 Resolving that regression seems like it requires quite a bit of insight into asn1c internals, which nobody in Osmocom currently has. What's still missing from upstream is APER support. Sadly, he maintainer @vlm states clearly that APER is not a short-term goal for him. However, ss UPER is supported, and there's the somewhat incomplete Eurecom/OAI hacks (with our fixes on top) as well as work in the following pull-request https://github.com/vlm/asn1c/pull/125 I don't think that's such a big issue anymore. It would be best to create somewhat of a test suite and then get the APER code up to a state until it passes that test suite. I'd be happy to put some of my (or sysmocom developer) time into that. But assuming that the regression parsing/compiling the ASN.1 syntax can somehow be fixed, I think there's some clear "light at the end of the tunnel" that we could compile the 3GPP syntax for RUA, HNBAP, RANAP and S1AP as-is, without first rewriting it, and without the asn1tostruct.py hack. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

github.com mirrors for new post split-nitb repos
by Harald Welte 09 Oct '17

09 Oct '17

Hi! yesterday I saw that the github.com mirrors of the osmo-{bsc,msc,hlr,mgw,sgsn,ggsn} repositories had not yet been created so far. We have mirrors on github so we can at times look at what people are doing in public clones of the repositories. This is useful as in the 21st century, a lot of developers have to have adopted a quality of "fork and never contribute back" attitude :/ In the past, we had to ask github staff to manually configure a mirror, as this is not possible to do via their website for some reason. It seems that this is now discouraged and they suggest to use a post-receive hook that replicates to github. I chose another path and used the already existing gerrit replication plugin which we use to replicate form gerrit to git.osmocom.org. This replication plugin is now also pushing to the respective github.com mirrors. I'm contacting github.com staff to convert all repositories to this new-style setup. This ensures the setup is identical for all mirrors, and has the added benefit that we get quicker replication than the once-per-hour poll. The setup is documented at https://osmocom.org/projects/osmocom-servers/wiki/Github_mirrors Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0