March 2017 - OpenBSC - lists.osmocom.org

Thoughts on a next generation MIB/VTY replacement

by Harald Welte

Hi All, Using zebra/quagga VTY code was a great idea back then and has served us nicely in all those years. I like the general style of the command-line based interface with its various nodes, the strict syntax checking, the tab completion and the interactive context-sensivive help. However, it feels a bit 20ieth-century-ish to have to manually write code to parse and to save the respective values. This is not a productive way to spend our development resources, and it is error prone. The "save" can be forgotten, resulting in non-saveable config parameters. The save can store values that the "parse" function will not be able to read again, etc. Furthermore, the VTY is inherently a human user interface, not intended for programmatic consumption. For programmatic access, we have developed the control interface. In reality though, only 1% of the parameters available in the VTY are exported via the control interface. And rather than adding all the missing bits and pieces with hand-crafted code to the control interface, we should have a generic way to define a new configuration value, and that value should then be automatically parse- and storable via VTY as well as a programmatic interface. The next "problem' is that the current telnet connections live within the process of the application. This means that a user can effectively "stall" the main application by performing I/O intensive operation on the VTY, or even on as many VTY/telnet sessions as he wants. There shouldn't be any need for this, at least not for something as mundane as performing configuration changes. Of course the VTY has different use cases such as runtime introspection of system state as well as logging. But still. Yet another concern is "VTY and telnet port proliferation". Particularly with the conversion from NITB to BSC+MSC+HLR, we are yet again getting more network elements with their own telnet ports. Remembering the port numbers is clumsy. It would be more convenient if a single command line interface could provide access to the configuration and the state of multiple different processes / network elements. Last, but not least, the current implementation is fixed to telnet, without any form of authentication, and without a path to migrate e.g. to something like SSL or SSH. I don't think it is a major concern (you can always SSH to the system and then telnet locally). So what I had in mind for quite some time (actually since netconf 1.2 about one year ago), is to have some kind of an external "VTY/MIB daemon" (or even separate daemons for each) which maintains a hierarchical database of configuration values. The MIB deamon simply offers an API (via client library) to GET or SET the individual values, or to NOTIFY an application about a changed value. This API is both used by the actual Osmocom programs to obtain their configuration (and obtain updates to it during runtime), as well as by the "VTY daemon" providing interactive shell access to it. Finally, other external applications could use the same interface/client library to do the same. A proxy to SNMP or REST interfaces can be imagined, for even more interfacing with the outside world. What I don't like about many existing MIBs I've used (as a sysadmin/user, not a developer) is their simple type system. You can often specify any random value to such a MIB, even one that is completely useless. A simple INT or STRING type is not sufficient, we really want the ability to have ENUM types, to have integers with ranges, etc. - just like we have in the VTY. Also, the MIBs I've used typically are nothing more than a hierarchical key-value store. They do not contain the information required for interactive, context-sensitive help needed for the "VTY" feel :( This is btw also the problem I have with OpenWRT's uci: It just has keys and values, with no way to constrain those values to something that's reasonable to the given program/context that is being configured, and there's no help or other information associated with those keys and values. So what I would like to see in this context, is some way to have a machine-parseable description of a "MIB/config item", together with syntax, ranges, enum values, help texts, etc (ideally in the C source code, possibly in comments?) which is used by some kind of MIB compiler to build up the hierarchical structure of the MIB and all of its keys as well as their permitted values and syntax reference. This information is then available to the VTY/telnet connections, irrespective of whether a given application [using those values] is running at all. Once an application starts, it can query for the configuration values it is interested in and populate its internal data structures from it. Ideally, one would even be able to generate a 'struct' from the MIB compiler, so that there is no need to explicitly call a "get" function on each single configuration value, but one simply gets a C-language 'struct' with all the values filled in by the client library. As stated above, there should be some way how he MIB can notify applications about changes to certain nodes in the MIB tree, so the application[s] can react to that. I don't have a clear picture yet how transaction logic (like changing multiple values and then committing them at once) would work, or whether applications should even be able to reject/revert a modification? In either case, I just wanted to share my thoughts on this. I know it sounds rather complex, but I think the investment in some kind of unified configuration database system would save us of a lot of boilerplate code and subtle bugs and inconsistencies. I've created https://osmocom.org/issues/1975 with above text to keep track of it, but I think at this point it's more of a mailing list discussion rather than something we can put into an issue. I guess the progress would rather be * first discuss it here and/or at OsmoDevCon * create something like a specification in the wiki * then follow-up with actual tickets on the work items All of this is brainstorming and vaporware, but I can't help to think of better ways of doing this. If somebody has experience with any existing systems and wants to share if and how they might fit, or what other ideas are useful to borrow: Please share! 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)

7 years

6
8
0 0

RFC: speed up gerrit verifications by using dependency artifacts

by André Boddenberg

Hi, some weeks a go the topic about using dependency-artifacts to speed up gerrit verifications was mentioned by Neels in the "RFC: jenkins pipeline" thread [1]. I was curious and wrote a bash script (osmo-artifacts.sh) [2], which enables build jobs to archive and fetch dependencies. Instead of Docker it simply uses archives to store them. An artifact's name has the following form: ( n(${project}.${branch}.${shortRev}_) ).tar.gz Openbsc builds are 50 % faster when using artifacts. [3] The jenkins.sh [2] script had to be slightly modified i.e. basically split into two functions: 1) buildProjectDeps() 2) buildProject() A third function to generate the artifact name has been added. The template.sh [2] script illustrates this description. What do you think about the result/artifactStore/approach in general? A cleanUpArtifactStore.sh script running as a cron job is already on my mind, but imo it's a good point to discuss the intermediate result. blobb [1] http://lists.osmocom.org/pipermail/openbsc/2017-March/010400.html [2] git clone https://github.com/blobbsen/diy-artifacts.git [3] https://jenkins.blobb.me/job/openBSC_multi-configuration_withArtifacts_test…

7 years, 1 month

4
6
0 0

weekly test report (w13 2017)

by Joachim Steiger

Hi, this is the BTS test report for week13 2017. BTS models which have been tested with OsmoNITB are: - sysmoBTS1002 - octasic OCTBTS3500 - ettus USRP B200 - nanoBTS model:165G All test cases have passed. For additional information related to test cases, timeslots configuration and voice codecs used, please visit: https://osmocom.org/projects/cellular-infrastructure/wiki/Weekly_BTS_Tests following are some git hashes/version strings of tested components: libosmo-abis: 5e87fdfcabc9cabe0025d7350b7ab31cdc4b6fa3 libosmocore: d78c973cd89fc7c119573357cfbebb891dbc697a libosmo-netif: 5fe77a4656f3590c343861ea96bcec18e370e437 libosmo-sccp: 8e708d1f2da1b187f631bf08172a5194a85b1a23 libsmpp34: cc0bcd6bc051d5ccaf32cdbbc28f073369900857 openbsc: b1e6b3749389ec5b3f33d5ac0fcc7f43df3f4641 openggsn: 19e19e3609508d121ba46c165e5ed1502a3cf9da osmo-bts: e16b59357411ffa4903ac110ac4ce46d343e878d osmo-bts-octphy: e16b59357411ffa4903ac110ac4ce46d343e878d osmo-pcu: e6d26ec09c2bcd2126416a58cb23af27318ec67e osmo-trx: e0c12189d455eb0d17299e4504749ce36629e18b sysmobts: OsmoBTS version 0.4.0.414-e16b5 sysmobts: Osmo-PCU version 0.2.900-e6d2 octbts: (name='octsdr_gsm', desc='Software Define Radio', ver='02.07.00-B1039', ver_hdr='02.07.00-B1039') octbts: (platform='Opus2', version='OCTSYS_VERSION=01.02.19.B1;OCTODK_VERSION=01.15.01-B1;OCTADF_VERSION=04.05.01-B2637;') nanobts: Equipment_Version='165g029_79' nanobts: Software_Version='168d462_v200b202d0' if you are interested in the details, drop me a mail and i'll forward the whole report. kind regards -- - Joachim Steiger <jsteiger(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 Directors: Harald Welte

7 years, 1 month

1
0
0 0

commit python script to openbsc/contrib

by Keith Whyte

Hi all. I have a python script I'd like to commit to openbsc/contrib. It reads the SMS table, gives stats and retrieves individual messages. - should maybe go in openbsc/contrib/sms ? Anyway, should I submit this via gerrit + code review or is there another way? There's really no point in having jenkins look at it, right? Thanks! k.

7 years, 1 month

2
1
0 0

pysim has moved to gerrit

by Neels Hofmeyr

pysim patches are managed by gerrit from now on. ~N

7 years, 1 month

1
0
0 0

[PATCH 0/2] fixes for pysim

by Philipp Maier

Hello, I would like to propose the two changes for pysim, the first is for fixing the sysmo-usim-sjs1 support and the second fixes the missing support for writing the ICCID to a sysmo-usim-sjs1. If there are no major concerns with that I would like to merge the two patches to master. Repo: https://git.osmocom.org/pysim Branch: pmaier/fixfci regards, Philipp Maier Philipp Maier (2): Fix select control parameter fix writing of ICCID for sysmo-usim-sjs1 pySim/cards.py | 15 ++++++++------- pySim/commands.py | 11 +++++++++-- 2 files changed, 17 insertions(+), 9 deletions(-) -- 1.9.1

7 years, 1 month

5
9
0 0

Updates on Osmocom Conference 2017

by Harald Welte

OsmoCon 2017 updates There are some updates related to OsmoCon2017, the first Osmocom Conference, held on April 21st, 2017 in Berlin, Germany. See http://osmocom.org/news/68 for the web version of this announcement. == Summary == Summary (for those too busy to read the full post): * Schedule of talks has been released http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017#Schedule * Travel Grants available for participants who are otherwise unable to travel to Berlin: http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_TravelGrants * Social Event details available, including menu: http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_SocialEvent * April 21st is approaching fast, make sure you get your Ticket in time. Limited number of seats available http://shop.sysmocom.de/products/ticket-for-osmocon-2017 == Details == === Schedule has been released === The list of talks with their abstracts has been on the website for quite some time, but now we actually have put together a schedule based on those talks. Please see http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017#Schedule for the schedule. As you can see, the day is fully packed with talks about Osmocom cellular infrastructure projects. We had to cut some talk slots short (30min instead of 45min), but I'm confident that it is good to cover a wider range of topics, while at the same time avoiding fragmenting the audience with multiple tracks. === Travel Grants === We are happy to announce that we have received donations to permit for providing travel grants! This means that any attendee who is otherwise not able to cover their travel to OsmoCon 2017 (e.g. because their interest in Osmocom is not related to their work, or because their employer doesn't pay the travel expenses) can now apply for such a travel grant. For more details see http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_TravelGrants and/or constact osmocon2017(a)sysmocom.de. === Social Event === Tech Talks are nice and fine, but what many people enjoy even more at conferences is the informal networking combined with good food. For this, we have the social event at night, which is open to all attendees. See more details about it at http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_SocialEvent -- - 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)

7 years, 1 month

1
0
0 0

gerrit openid login: osmocom.org vs. projects.osmocom.org

by Neels Hofmeyr

Has someone made osmocom.org login redirect to projects.osmocom.org? Because since recently I observe this: I go to osmocom.org, click on "Sign in". It *redirects* me to projects.osmocom.org/login. I log in. I go to gerrit, enter, as always https://osmocom.org/openid I get another login screen, this time on osmocom.org without 'projects.' Interesting, there seem to be two realms, maybe from cookie rules. Ok then, I add projects to the openid, for gerrit login: https://projects.osmocom.org/openid and it works, nice. However, now I seem to be logged in as a kind of ghost of my user. I'm logged in as 'nhofmeyr(a)sysmocom.de', but no patches are on my page and I don't have the voting nor admin permissions I normally have. When instead of clicking on "Sign in" on osmocom.org redmine, I *manually* enter https://osmocom.org/login (omitting projects.), I can login on osmocom.org and my gerrit user works out. I notice that with projects.osmocom.org I am user ID 1000073, while with osmocom.org I am 1000005. In the gerrit user database, I see distinct user IDs: ▶ ssh go 'gerrit gsql -c "select * from account_external_ids where account_id = 1000073 or account_id = 1000005"' ACCOUNT_ID | EMAIL_ADDRESS | EXTERNAL_ID -----------+-----------------------+-------------------------------------------- 1000005 | nhofmeyr(a)sysmocom.de | https://osmocom.org/openid/user/91 1000005 | NULL | username:neels 1000073 | nhofmeyr(a)sysmocom.de | https://projects.osmocom.org/openid/user/91 When I manually patch up the 1000073 to 1000005 in the last row, both openid URLs work out to the correct user. So gerrit potentially gets confused by one and the same user, fails to match the email addresses rather than the openid provider. Looking at the other registered users, most use the osmocom.org and not projects.osmocom.org, so you all may be susceptible to the same issue. I also see that four have entered http:// as openid, without SSL, which seems to me is something we should rather not allow. For example, laforge's user is shadowed in the same way just because of the non-https: 1000004 | laforge(a)gnumonks.org | https://osmocom.org/openid/user/7 1000021 | laforge(a)gnumonks.org | http://osmocom.org/openid/user/7 If redirecting to projects.o.o is intentional and the way to go (TM), I should probably pre-empt problems for existing users by creating external ids with 'projects' in the openid url, pointing at the proper existing users. Otherwise we should avoid magical forwarding of osmocom.org logins to projects.osmocom.org. ~N

7 years, 1 month

2
4
0 0

GSM Audio Problems and

by Edwin Reed-Sanchez

Dear Osmocom list We are getting several audio problems and dropped calls. The audio sounds like static. We are also getting large frame correction in the logs, and SACCH deactivation timeout. Any ideas what could be the likely culprit? 2017-03-24_14:30:57.93546 <001a> rtp_proxy.c:295 Correcting frame difference of 74518293571 frames 2017-03-24_14:31:11.45899 <001a> rtp_proxy.c:295 Correcting frame difference of 1 frames 2017-03-24_14:31:11.51590 <001a> rtp_proxy.c:295 Correcting frame difference of 2 frames 2017-03-24_14:31:11.65513 <001a> rtp_proxy.c:295 Correcting frame difference of 1 frames 2017-03-24_14:32:08.95028 <0004> abis_rsl.c:1343 (bts=1,trx=0,ts=1,ss=0) SACCH deactivation timeout. 2017-03-24_14:37:10.11844 <0004> abis_rsl.c:662 (bts=1,trx=0,ts=1,ss=0) is back in operation.

7 years, 1 month

2
3
0 0

python on FreeBSD in libosmocore

by Thorsten Alteholz

Hi, as python2 will disappear sooner or later, I tried to replace all python2 references in libosmocore by the generic "python" [1]. Unfortunately the build fails on FreeBSD[2]. Google didn't want to explain me why there might be /usr/bin/python2 but no /usr/bin/python, so do you have any idea what is wrong here? Thorsten [1] https://gerrit.osmocom.org/#/c/2158/ [2] http://jenkins.osmocom.org/jenkins/job/libosmocore-gerrit/903/label=FreeBSD…

7 years, 1 month

3
2
0 0

runtime cpu-detection for osmo-trx

by Philipp Maier

Dear list members, dear Mr. Tsou, we had a couple of problems with the SSE support in Transceiver52 of osmo-trx. The problem was that the -march=native, that is used when compiling the x86 code in Transceiver52M/x86/. This would create a platform dependent binary that can not be easily moved to another platform. (e.g. binary is compiled on a machine that does support SSE4.1, but used on a machine that only supports SSE3) In order to solve the problem, we have added logic to detect the CPU type at runtime and to switch between the base implementation (Transceiver52M/common) and between the platform specific implementation. Since there might be different compilers out there, which do not support the -msse3 and -msse4.1 options, we also modified the build system to detect if the compiler supports -msse3 and -msse4.1. If no support can be detected, there is a hard fallback to the generic implementation. The patches are currently in the review process, you can find them below: https://gerrit.osmocom.org/2098 buildenv: Turn off native architecture builds https://gerrit.osmocom.org/2099 cosmetic: Make parameter lists uniform https://gerrit.osmocom.org/2100 ssedetect: Add runtime CPU detection https://gerrit.osmocom.org/2101 cosmetic: Add info about SSE support https://gerrit.osmocom.org/2102 buildenv: Make build CPU invariant https://gerrit.osmocom.org/2103 cosmetic: remove code duplication https://gerrit.osmocom.org/2104 Add test program to verify convolution implementation https://gerrit.osmocom.org/2134 buildenv: Split up SSE3 and SSE4.1 code There is also a readmine ticket concerning this change: https://osmocom.org/issues/1869 It would be very kind if you could have a look at the changes and, if possible, to approve them. regards, Philipp Maier -- Philipp Maier <pmaier(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

7 years, 1 month

2
1
0 0

weekly test report (w12 2017)

by Joachim Steiger

Hi, this is the BTS test report for week12 2017. BTS models which have been tested with OsmoNITB are: - sysmoBTS1002 - octasic OCTBTS3500 - ettus USRP B200 - nanoBTS model:165G All test cases have passed. For additional information related to test cases, timeslots configuration and voice codecs used, please visit: https://osmocom.org/projects/cellular-infrastructure/wiki/Weekly_BTS_Tests following are some git hashes/version strings of tested components: libosmo-abis: 1e04d4b7a2c845589da20d891cc5e3c471cfe983 libosmocore: 62d6f2570358730965162f7dd756a6e2d07627b2 libosmo-netif: 3a060c59bec7a4a5b22849938b8b4c7b7ecb4c01 libosmo-sccp: 8e708d1f2da1b187f631bf08172a5194a85b1a23 libsmpp34: cc0bcd6bc051d5ccaf32cdbbc28f073369900857 openbsc: dd22a30d75090ebe2ba08056bfa04a92aa8d6ba1 openggsn: 19e19e3609508d121ba46c165e5ed1502a3cf9da osmo-bts: b609ee879eb798f8f3836223b4702745f3f6491e osmo-bts-octphy: b609ee879eb798f8f3836223b4702745f3f6491e osmo-pcu: 0a8fae8d141c2cfa4387ffe9b35402d5b8cc85cd osmo-trx: 14d13b67dcd4fa35b03cbbef0c5ddd2622b89155 sysmobts: OsmoBTS version 0.4.0.410-b609 sysmobts: Osmo-PCU version 0.2.896-0a8f octbts: (name='octsdr_gsm', desc='Software Define Radio', ver='02.07.00-B1039', ver_hdr='02.07.00-B1039') octbts: (platform='Opus2', version='OCTSYS_VERSION=01.02.19.B1 OCTODK_VERSION=01.15.01-B1;OCTADF_VERSION=04.05.01-B2637;') nanobts: Equipment_Version='165g029_79' nanobts: Software_Version='168d462_v200b202d0' if you are interested in the details, drop me a mail and i'll forward the whole report. kind regards -- - Joachim Steiger <jsteiger(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 Directors: Harald Welte

7 years, 1 month

1
0
0 0

weekly test report (w11 2017)

by Joachim Steiger

Hi, this is the BTS test report for week11 2017. BTS models which have been tested with OsmoNITB are: - sysmoBTS1002 - octasic OCTBTS3500 - ettus USRP B200 - nanoBTS model:165G All test cases passed except for one for one config of the octasic bts: 3 TCH/H, 3 PDCH in this config the gprs did not work as expected. sorry no logs this time. For additional information related to test cases, timeslots configuration and voice codecs used, please visit: https://osmocom.org/projects/cellular-infrastructure/wiki/Weekly_BTS_Tests if you are interested in the details, drop me a mail and i'll forward the whole report. kind regards -- - Joachim Steiger <jsteiger(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 Directors: Harald Welte

7 years, 1 month

2
2
0 0

[PATCH] osmo-pcap[master]: debian: Add -dbg packages for the osmo-pcap-client and osmo-...

by Holger Freyther

Review at https://gerrit.osmocom.org/2000 debian: Add -dbg packages for the osmo-pcap-client and osmo-pcap-server Currently looking at a weird issue. Make it possible to install the -dbg packages. Change-Id: I7d6c8e491be459151c1531b86f28bb1dc2ee8bb4 --- M debian/changelog M debian/control M debian/rules 3 files changed, 15 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-pcap refs/changes/00/2000/1 diff --git a/debian/changelog b/debian/changelog index 6e4df55..13bce30 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,6 +1,7 @@ osmo-pcap (0.0.11) UNRELEASED; urgency=medium * Add "source ip A.B.C.D" option to use specific address. + * Add osmo-pcap-client-dbg/osmo-pcap-server-dbg package -- Holger Hans Peter Freyther <holger(a)moiji-mobile.com> Tue, 17 Jan 2017 09:12:52 +0100 diff --git a/debian/control b/debian/control index 3364e34..2677bc0 100644 --- a/debian/control +++ b/debian/control @@ -17,3 +17,13 @@ Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends} Description: Collect traces from other systems. + +Package: osmo-pcap-client-dbg +Architecture: any +Depends: osmo-pcap-client (= ${binary:Version}) +Description: Debug symbols of osmo-pcap-client-dbg + +Package: osmo-pcap-server-dbg +Architecture: any +Depends: osmo-pcap-server (= ${binary:Version}) +Description: Debug symbols of osmo-pcap-server-dbg diff --git a/debian/rules b/debian/rules index 78ddc43..872097c 100755 --- a/debian/rules +++ b/debian/rules @@ -39,3 +39,7 @@ install -d -m 0755 $(CURDIR)/debian/osmo-pcap-server/etc/cron.daily/ install -m 0755 $(CURDIR)/contrib/osmo_pcap_clean_old $(CURDIR)/debian/osmo-pcap-server/etc/cron.daily/ + +override_dh_strip: + dh_strip -posmo-pcap-client --dbg-package=osmo-pcap-client-dbg + dh_strip -posmo-pcap-server --dbg-package=osmo-pcap-server-dbg -- To view, visit https://gerrit.osmocom.org/2000 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I7d6c8e491be459151c1531b86f28bb1dc2ee8bb4 Gerrit-PatchSet: 1 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Holger Freyther <holger(a)freyther.de>

7 years, 1 month

2
3
0 0

[PATCH] osmo-pcap[master]: debian: Make a new release with the new feature

by Holger Freyther

Review at https://gerrit.osmocom.org/1999 debian: Make a new release with the new feature Change-Id: Ibe86b761b494e0fb78bbbc78e3c1982e44185750 --- M debian/changelog 1 file changed, 6 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-pcap refs/changes/99/1999/1 diff --git a/debian/changelog b/debian/changelog index fd4259c..6e4df55 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +osmo-pcap (0.0.11) UNRELEASED; urgency=medium + + * Add "source ip A.B.C.D" option to use specific address. + + -- Holger Hans Peter Freyther <holger(a)moiji-mobile.com> Tue, 17 Jan 2017 09:12:52 +0100 + osmo-pcap (0.0.10) unstable; urgency=medium * New release with new features -- To view, visit https://gerrit.osmocom.org/1999 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Ibe86b761b494e0fb78bbbc78e3c1982e44185750 Gerrit-PatchSet: 1 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Holger Freyther <holger(a)freyther.de>

7 years, 1 month

2
3
0 0

test failures in current OpenBSC

by Max

Hi. A little heads-up - the current master of OpenBSC is failing at 'make check' stage - see http://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/2019/IU=--disable-iu,… for example. Until this is fixed, any patches for OpenBSC won't be accepted by jenkins. If you hit this - please retrigger corresponding failed build in jenkins once it's fixed. -- 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

7 years, 1 month

2
1
0 0

nightly packages failures

by Neels Hofmeyr

openggsn failed because README was renamed to README.md without adjusting the debian installation rules (possibly the same change occured in other repositories, Harald?) the osmo-auc-gen_test.sh still fails on 32bit systems, to be fixed by https://gerrit.osmocom.org/2089 (please review) ~N

7 years, 1 month

2
1
0 0

git.osmocom.org cgit improvements

by Harald Welte

Hi all, today I've deployed some cgit improvements on https://git.osmocom.org/, in the hope that it makes this tool even more useful: 1) syntax highlighting of source code (requested by Hoernchen) The source code is now highlighted by pygments. I don't really understand why somebody would want to look at source code a lot in a browser, but well, it was as easy as to enable the existing pygments based filter plugin. 2) rendering of "about" page from README.md As you might have noticed, I've introduced a README.md in a number of repositoires, and cgit is now rendering an about page for every repository, e.g. at http://git.osmocom.org/libosmo-abis/about/ 3) gerrit change-ID hyperlink generation All gerrit Change-IDs in commit messages are now automatically converted to hyperlinks to the respective gerrit change, see e.g. the below example: http://git.osmocom.org/openbsc/commit/?id=6dd0fc685b7149f67a5fe17a5bce55c44… Please note that this works for the "Change-Id" line of the actual change, but also for change-ids in the free text (e.g. "this depends on change-id ... in libosmocore") 4) Osmocom ticket/issue hyperlink generation Any Line that matches the "^((Relate|Close|Fixe)[ds]):" prefix is scanned for occurrences of "OS#(\d+)" which are then amended with hyperlinks to the respective issue on osmocom.org Please note the OS# prefix is mandatory, so things like "OS#1614, 1615" will not work, as can be seen at http://git.osmocom.org/osmo-pcu/commit/?id=0a8fae8d141c2cfa4387ffe9b35402d5… Please format your commit messages accordingly. 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)

7 years, 1 month

3
3
0 0

coverity scan for vlr_2G and vlr_3G

by Neels Hofmeyr

It seems that we won't be merging vlr_2G or vlr_3G into openbsc.git's master, at least not soon. Instead we're likely to move to a new git repository altogether to mark the changed setup. We could switch 'Osmocom' over to vlr_3G and assume that it includes the others, but that's not accurate at all. The VLR stuff cuts away half the code from openbsc.git's master and 3G the other half. well, almost :) So I thought we could repurpose two of the unused coverity scan projects we have for the vlr_2G and vlr_3G branches. Or maybe one for vlr_3G would be enough. It seems we can't change the name of a coverity project. Maybe we can just use the OpenBSC one for vlr_3G without changing the name? We could possibly also include a separate build within the tar sent to the Osmocom job, I can also check that out. Or I can try and register a brand new one. Any preferences? ~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

7 years, 2 months

3
4
0 0

OsmoTRX runtime CPU optimization detection

by Harald Welte

FYI, Philipp has been working on some patches to do the OsmoTRX cpu instruction set extension detection at runtime rather than compile-time. See "Bug #1869: osmo-trx binary cannot be moved to similar CPU" https://osmocom.org/issues/1869#change-3394 As not everyone is following each redmine ticket or gerrit patch: I would like the OsmoTRX folks (Tom, Alexander, ...) to have a look at this. For convenience, the latest update to the ticket and the associated links to the gerrit patches below: --- The matching implementation is now selected dynamically during runtime. In order to be sure that the convolution part did not break, I wrote a small test program to compute some testvectors. I compared the results before and after my changes. They match up. I made only minimal changes to the conversion code, so I skipped testing that as well. The SSE relevant sources are compiled with $(SIMD_FLAGS) now. The sources only contain the SSE implementation and the decision logic to defer to the correct implementation during runtime. That should run fine on non SSE3 / SSE4.1 CPUs, since the decision logic is not vectorize-able. However, we can divide this up further as discussed. https://gerrit.osmocom.org/2098 buildenv: Turn off native architecture builds https://gerrit.osmocom.org/2099 cosmetic: Make parameter lists uniform https://gerrit.osmocom.org/2100 ssedetect: Add runtime CPU detection https://gerrit.osmocom.org/2101 cosmetic: Add info about SSE support https://gerrit.osmocom.org/2102 buildenv: Make build CPU invariant https://gerrit.osmocom.org/2103 cosmetic: remove code duplication https://gerrit.osmocom.org/2104 Add test program to verify convolution implementation --- -- - 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)

7 years, 2 months

1
0
0 0

Re: [MERGED] openbsc[master]: gprs_sgsn.c: initialize ptmsi with 0xdeadbeef

by Neels Hofmeyr

> - uint32_t ptmsi; > + uint32_t ptmsi = 0xdeadbeef; GSM_RESERVED_TMSI would make more sense here I guess (the "invalid TMSI" value). ~N

7 years, 2 months

1
0
0 0

Re: Build failure of network:osmocom:nightly/libosmocore in xUbuntu_16.10/i586

by Neels Hofmeyr

should be fixed by https://gerrit.osmocom.org/2089 On Wed, Mar 15, 2017 at 07:52:33PM +0000, OBS Notification wrote: > Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/l… > > Package network:osmocom:nightly/libosmocore failed to build in xUbuntu_16.10/i586 > > Check out the package for editing: > osc checkout network:osmocom:nightly libosmocore > > Last lines of build log: > [ 143s] RAND: 6a61050765caa32c90371370e5d6dc2d > [ 143s] -AUTN: afb993e4f4b8000069cdeebb4a4b5b58 > [ 144s] +AUTN: 504693e4f4b80000e3963072c50f0b91 > [ 144s] IK: c348c2fe2f3e1fb37a7ae1638163bd98 > [ 144s] CK: e740c156278705a14e1a99ba6d31334f > [ 144s] RES: 7c04e86a67967fcd > [ 144s] SRES: 1b9297a7 > [ 144s] Kc: 10687b71e4eb94c5 > [ 144s] -SQN: 281474976710655 > [ 144s] +SQN: 4294967295 > [ 144s] > [ 144s] > [ 144s] > osmo-auc-gen -3 -a milenage -r 39fa2f4e3d523d8619a73b4f65c3e14d -k EB215756028D60E3275E613320AEC880 -o FB2A3D1B360F599ABAB99DB8669F8308 -A 979498b1f72d3e28c59fa2e72f9c > [ 144s] 40. testsuite.at:253: 40. osmo-auc-gen (testsuite.at:253): FAILED (testsuite.at:257) > [ 144s] debian/rules:26: recipe for target 'override_dh_auto_test' failed > [ 144s] make[1]: *** [override_dh_auto_test] Error 1 > [ 144s] make[1]: Leaving directory '/usr/src/packages/BUILD' > [ 144s] debian/rules:15: recipe for target 'build' failed > [ 144s] make: *** [build] Error 2 > [ 144s] dpkg-buildpackage: error: debian/rules build gave error exit status 2 > [ 144s] > [ 144s] build85 failed "build libosmocore_0.9.6.20170315.dsc" at Wed Mar 15 19:52:15 UTC 2017. > [ 144s] > [ 144s] ### VM INTERACTION START ### > [ 146s] [ 136.282415] reboot: Power down > [ 147s] ### VM INTERACTION END ### > [ 147s] > [ 147s] build85 failed "build libosmocore_0.9.6.20170315.dsc" at Wed Mar 15 19:52:19 UTC 2017. > [ 147s] > > -- > Configure notifications at https://build.opensuse.org/user/notifications > openSUSE Build Service (https://build.opensuse.org/)

7 years, 2 months

1
0
0 0

NITB: high cpu usage and "crossed" messages when SMS table grows

by Keith

Hi all, I temporarily disabled a cron job we run at rhizomatica that purges the hlr SMS table of sent messages every day. After a few days I noticed slightly sluggish behaviour in the VTY, and sure enough, the nitb was consuming 100% cpu, not always, but presumably whenever it does a queue run. I also just heard that in the last few days, we got a number of reports from users, some confirmed by photos of the phones, about messages being delivered to the wrong destination. Apologies if this has been touched on before. I am not finding where I can directly search this list archives. Anyway, it might not be so bad to bring it up, as the cron job purging via cron job calling sqlite3 is not ideal, and anyway.. this crossed messages shouldn't happen, right? I imagine we'd like to track this one down. Keith.

7 years, 2 months

4
7
0 0

osmo-bts-trx channel activation

by Max

Hi. This has been asked last year but to no avail, let's try again. How logical channels are (de)activated in osmo-bts-trx? For example in all the other models there's sapi_deactivate_cb() callback but osmo-bts-trx doesn't seem to be using sapi_cmd at all. To put this into perspective - while working on https://projects.osmocom.org/issues/1575 I got to activate/deactivate lchans when SI3 is received. This already works for sysmobts but I'd like to do the same for osmo-bts-trx as well. Is there any documentation somewhere describing how it works there? Or maybe someone more familiar with the code could help to shed the light on it? -- 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

7 years, 2 months

2
1
0 0

autoconf and .deb question

by Max

Hi. There's strange thing about the way autoconf and debian/rules interact for OpenBSC: - in openbsc/include/openbsc/Makefile.am gsm_data_shared.h and common_cs.h are in noinst_HEADERS - in debian/openbsc-dev.install they are marked for installation And this actually works! If you run "dpkg-buildpackage -uc -us -tc" you'll get openbsc-dev*.deb with those headers properly installed. It's nice but feels a bit too much like magic. Any ideas how dh_install (or smth else?) manages to work around it? Should we be worried that it might break some time in future? Should we move those headers away from noinst_* section? -- 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

7 years, 2 months

2
1
0 0

IMSI: Inf ?

by Keith

This is a bit vague again... I have found across our sites several entries with a value of Inf for IMSI on a create-on-demand subscriber: For example: sqlite> select * from Subscriber where id=284054; 284054|2017-03-08 21:19:40|2017-03-08 21:19:40|Inf||20649|0||0| I also have some Inf values for IMEI in Equipment: sqlite> select id,created,imei from Equipment where id = 95108; 95108|2014-03-13 03:18:06|Inf Not a big deal for operations, just thought I'd mention it as I noticed while restoring backups, (sqlite3 doesn't like to reimport the Inf value it writes itself with .dump)

7 years, 2 months

1
0
0 0

BS-11 Serial Interface

by Alexander Huemer

Hi, I have a Siemens BS-11 with the factory cable for the LMT that has a DSUB-9 plug on the non-BTS end. When I connect a USB<-->RS232 adapter and run either $ cu -l /dev/ttyUSB or bs11_config -p /dev/ttyUSB0 I do not get any output when I switch on the BTS. I tried with nullmodem adapter and without just to be sure since I often mix up the pinouts. I was not able to measure any voltage on any of the DSUB-9 pins when the BTS is powered up, but believe that on either RX or TX there should be the voltage level of the serial line since RS232 is active low. Has somebody seen this behavior? -Alex

7 years, 2 months

2
1
0 0

FYI: Build failure of network:osmocom:nightly/osmo-pcu in xUbuntu_16.10/x86_64

by Neels Hofmeyr

fyi, we're still getting daily failures by the opensuse builds, which should be fixed once https://gerrit.osmocom.org/2007 is merged. ~N On Sat, Mar 11, 2017 at 07:57:26PM +0000, OBS Notification wrote: > Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o… > > Package network:osmocom:nightly/osmo-pcu failed to build in xUbuntu_16.10/x86_64 > > Check out the package for editing: > osc checkout network:osmocom:nightly osmo-pcu > > Last lines of build log: > [ 111s] from bts.cpp:21: > [ 111s] /usr/include/c++/6/cstdlib:185:3: note: candidate: __int128 std::abs(__int128) > [ 111s] abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; } > [ 111s] ^~~ > [ 111s] /usr/include/c++/6/cstdlib:180:3: note: candidate: long long int std::abs(long long int) > [ 111s] abs(long long __x) { return __builtin_llabs (__x); } > [ 111s] ^~~ > [ 111s] /usr/include/c++/6/cstdlib:172:3: note: candidate: long int std::abs(long int) > [ 111s] abs(long __i) { return __builtin_labs(__i); } > [ 111s] ^~~ > [ 111s] Makefile:778: recipe for target 'bts.lo' failed > [ 111s] make[2]: *** [bts.lo] Error 1 > [ 111s] make[2]: Leaving directory '/usr/src/packages/BUILD/src' > [ 111s] Makefile:403: recipe for target 'all-recursive' failed > [ 111s] make[1]: *** [all-recursive] Error 1 > [ 111s] make[1]: Leaving directory '/usr/src/packages/BUILD' > [ 111s] dh_auto_build: make -j1 returned exit code 2 > [ 111s] debian/rules:12: recipe for target 'build' failed > [ 111s] make: *** [build] Error 2 > [ 111s] dpkg-buildpackage: error: debian/rules build gave error exit status 2 > [ 111s] > [ 111s] lamb16 failed "build osmo-pcu_0.3.20170311.dsc" at Sat Mar 11 19:57:22 UTC 2017. > [ 111s] > [ 111s] ### VM INTERACTION START ### > [ 115s] [ 102.127065] reboot: Power down > [ 115s] ### VM INTERACTION END ### > [ 115s] > [ 115s] lamb16 failed "build osmo-pcu_0.3.20170311.dsc" at Sat Mar 11 19:57:26 UTC 2017. > [ 115s] > > -- > Configure notifications at https://build.opensuse.org/user/notifications > openSUSE Build Service (https://build.opensuse.org/)

7 years, 2 months

1
0
0 0

RFC: jenkins pipeline

by Klaus Müller

Hi, >> So, what would be the actual benefits? >>* complete job config in git? (to be confirmed) Just to clarify, the Pipeline plugin on its own doesn't provide a complete config handling in git. This means only the code shown in image [3] lives in git, configurations within the "General" or "Build Triggers" tab will still be handled in the web-ui.*** For the sake of completeness the JobDSL plugin [2][ has to be mention. This plugin allows to put the entire job configuration to git and deploys jobs without previous manual setup in the web-ui. >>* faster because less things have to be rebuilt? (to be confirmed) Somehow I doubt that this improvement dependents on the Pipeline plugin, but I know to few details to have an opinion based on facts. :) >>* faster because easily parallelizable/easier integration with docker? (to be >> confirmed) first point: e.g. Pipeline can trigger "down-stream-projects/stages" after one specific part of a parallel-block/matrix-configurations-project is finished. second point: Pipeline brings a docker wrapper, so one don't have to pass one build script holding the entire build sequence when invoking the container. You can invoke as much scripts as you want within the docker wrapper. (no black-box god-script :) >> If dr.blobb and/or Max could clarify these points that would be great >> (while I guess they will clarify in depth only after actual trials). >> First tests could run on a privately setup Jenkins ... dr.blobb? For sure, let's use this Jenkins instance [1] for trials. Everyone is welcome to sign up and send me a mail to get the necessary permissions. I start migrating the OpenBSC build pipeline to Pipeline and keep you updated. Is this mailing list the appropriate communication channel? Is there already a osmocom ci wiki page, which I overlooked? I'd be happy to contribute! ~André *** Some "web-ui configurations" can be injected from the jenkinsfile, though. [1] https://jenkins.blobb.me/view/osmocom/ [2] https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin [2.5] https://jenkinsci.github.io/job-dsl-plugin/#method/javaposse.jobdsl.dsl.Dsl… [3] http://tinyurl.com/zbavrtp

7 years, 2 months

6
9
0 0

Re: BS-11 Serial Interface

by Dieter Spaar

Hello Alexander, On Sat, 11 Mar 2017 00:42:32 +0100, "Alexander Huemer" <alexander.huemer(a)xx.vu> wrote: > > I was not able to measure any voltage on any of the DSUB-9 pins when the=20 > BTS is powered up, but believe that on either RX or TX there should be=20 > the voltage level of the serial line since RS232 is active low. > Has somebody seen this behavior? Maybe there is something wrong with the cable? This is from my notes about the BS-11 serial interface: The four E1 BNC connectors are here. 5 6 7 8 x x x x x x x x 1 2 3 4 2: LMT Tx (out) 6: LMT Rx (in) 4: +5V 8: GND There are two more 8-pin connectors below, you have to connect the cable to the top one (below the E1 BNC connectors). The same with some pictures is also here: https://osmocom.org/projects/openbsc/wiki/BS11LMT Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

7 years, 2 months

1
0
0 0

Re: libosmocore build failure cascade

by Vadim Yanitskiy

Hi Max, > On a related note - are you working on moving OsmoBTS to libosmocoding? Not a whole OsmoBTS :) GSM 05.03 transcoding routines only. Right now, I am testing dynamic TS switching on UmTRX. > Are there some missing pieces before this can be done? Almost done, now we need to switch OsmoBTS to use libosmocore's implementation and remove the old code. With best regards, Vadim Yanitskiy.

7 years, 2 months

1
0
0 0

Unknown HFC multiport controller

by Alexander Huemer

Hi, I have a Siemens BS-11 and a HFC IOB1E1 PCI card. The linux kernel is not very happy with the card, I get Unknown HFC multiport controller (vendor:1397 device:30b1 subvendor:1397 subdevice:b543) Please contact the driver maintainer for support. The same error is mentioned in [1] but with different subdevice id, which I believe does not matter. I am not sure why vendor ID 1397 (PCI_VENDOR_ID_CCD) and device ID 30b1 (PCI_DEVICE_ID_CCD_HFCE1) are not valid. Consulting [2] I was under the impression that this is the expectation of the driver. [1] does not provide an answer as far as I can see. Would anybody know what the problem is here? -Alex [1] http://lists.osmocom.org/pipermail/openbsc/2009-August/001838.html [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/driver…

7 years, 2 months

1
0
0 0

MNCC ABI changes

by Holger Freyther

Hi, as part of looking into early media (and at some point handover handling) I would like to use MNCC_RTP_CONNECT and supply "recvonly", "sendonly" attributes. The gsm_mncc_rtp structure does not carry this information though. struct gsm_mncc_rtp { uint32_t msg_type; uint32_t callref; uint32_t ip; uint16_t port; uint32_t payload_type; uint32_t payload_msg_type; }; The content of payload_msg_type currently holds anything between 0x300 and 0x03ff and I would like to split this field into two uint16_t. The reason is not to change the size of the structure (and maybe not dump the protocol version). It would be a backward compatible change. Is anyone open for such tricks? Otherwise I will bump protocol version and change the ABI (and try to update the various active users of this protocol). holger

7 years, 2 months

2
1
0 0

SMS not received in mobile - Virtual layer1 (osmo-nitb + osmo-bts + osmocom-bb/mobile)

by Sebastian Stumpf

Hi, Some of my sent SMS are not received by my mobile and I try to figure out if this is a problem with my virtual layer 1, configuration or something in the layers 2+. I use: osmo-nitb: 1 subscriber in hlr (id 1, ext 017519191919) osmo-bts: virt-phy, arfcn 666, TS0=CCCH+SDCCH4, TS1=SDCCH8 MS layer23 app mobile: is the subscriber from osmo-nitb MS layer1 virt-phy: virtual gsmtap layer between bts and mobile I want: Send a sms to subscriber 017519191919. osmo-nitb VTY: OpenBSC# subscriber id 1 sms sender id 1 send Test I have 2 outcomes, first one is the failure. See https://www.dropbox.com/s/eunpfioq518t09a/mobile--ms-virt--bts-virt--bsc-ni… for the pcap. Do not wonder about the duplicated gsmtap messages from mobile, the ones to ip 225.0.0.1 are over virt-phy layer, the ones to localhost from the gsmtap logging option from mobile. Filter them out via "gsmtap && (ip.dst != 127.0.0.1)". 602-613: RR channel establishment with RA and IA as reaction to paging in 590 627,631: SABM from BTS to establish async balanced mode on SAPI3 (SMS) and the ACK from MS 656,684,699: I-Data frames on SAPI3 containing the sms 660,688,703: ReceiveReady's from MS (That ACK all I-frames before N(R)-1 as far as I understood) For me, that looks good and I really do not understand why the MS will not answer with the CP-ACK/RP-ACK after receiving the SMS Data in 699. The LAPDM link will stay up for some more time and be used by the network for retransmission of the sms (1149), but MS will never react to it on the SMS layer (CP-ACK, RP-ACK). Here is the console log for the mobile (https://www.dropbox.com/s/6gug5cd4up5qv7y/mobile--ms-virt--bts-virt--bsc-ni…). The paging is answered in line 378: Fri Mar 10 10:42:06 2017 DLLAPD <0012> lapd_core.c:793 SABM(E) received in state LAPD_STATE_IDLE Second outcome is a successfully sent sms from network to ms. See https://www.dropbox.com/s/ghdn7pc0j4vifbe/mobile--ms-virt--bts-virt--bsc-ni… for the pcap. What is different here? There is no paging, but the sms is sent within the dedicated channel used for the location update initiated by the phone started up. Why there is another outcome, I don't know. 169-181: RR channel establishment with RA and IA as part of mibiles startup routine to make location update 188,416: Location udpdate procedure on SAPI0 230,234: SABM from BTS to establish async balanced mode on SAPI3 (SMS) and the ACK from MS 396,444: I-Data frames on SAPI3 containing the sms 400,449: RR's from MS 450: CP-ACK for BTS 482,499: RP-ACK I-Frames for Network (osmo-nitb) Again, the console log of the mobile (https://www.dropbox.com/s/cujsn40d43g6wxk/mobile--ms-virt--bts-virt--bsc-ni…). The SABM on SAPI3 on downlink is received in line 206: Fri Mar 10 11:06:13 2017 DLLAPD <0012> lapd_core.c:793 SABM(E) received in state LAPD_STATE_IDLE The signaling looks quite similar in both cases, but one time the mobiles sms handler responds to CP-DATA msg containing the SMS, the other time not. Can someone find an error in the signaling I did not see? Is there a known Bug? To be honest, I last merged my branch with master some time ago (~ Jan 18 2017) and thus did not update osmo-nitb and the libraries since then to avoid compatibility problems. Have there been recent changes that could cause that behavior? Thank you and Kind Regards, Sebastian

7 years, 2 months

1
0
0 0

about reusing subscriber connections

by Neels Hofmeyr

Testing with the nano3G, e.g. when sending a large SMS, I see that multiple CM Service Requests may come in on the same IuCS connection. The code so far assumed that a CM Service Request would always come in on a fresh, unauthenticated connection (after iuRelease): the ProcessAccessReQuest FSM always starts out with establishing identities, authentication, ciphering. Now I've added code to accept a CM Service Request on an already accepted connection, by sending back an immediate CM Service Accept without even invoking the PARQ FSM. But that might not be such a good idea: I face the same for a Location Updating. A phone may choose to send a periodic LU on an already open and accepted connection (I guess). So we should allow that by sending back a LU Accept right away, without another authentication dance. But we also want to tell the HLR about the LU. The VLR FSMs may also have other actions in mind that the MSC doesn't know or care about. So: To not re-invent the wheel outside of libvlr, I would go on and add a flag to the LU and PARQ FSMs to indicate that the request is coming in on an already accepted connection, to jump directly to the post-ciphering FSM state. But I'd like to hear whether you guys have some thoughts or experience on this. For the case of the large multi-part SMS, we usually are fast enough in releasing the conn after each SMS fragment. For the next fragment, another initialUE message with a CM Service Request starts the PARQ FSM, auth+ciph is re-established, and the next part goes through. But sometimes the UE has already started to send another CM Service Request to initiate the next SMS fragment before it acked the previous one -- meaning that before we get as far as being done and issuing an iuRelease from the CN, the UE already sends another fresh CM Service Request on the same conn. That means we don't have to re-establish auth, quite nice actually. To allow cascades like these, we might also decide to iuRelease slightly later, giving the UE another second to re-use the open connection, so that we have less message overhead and use less auth tuples -- I wouldn't actually give it much more than a second; after about five seconds, the UE usually does an iuRelease itself. That sounds sane, but actually https://osmocom.org/issues/1816 holds against that: when I send USSD requests *from the phone* rapidly without leaving time to iuRelease, only the first USSD goes through from the UE to the CN. The second one is never received on the IuCS wire. That would indicate that the phone expects a conn to close right away from the CN, always. When I wait for iuRelease before sending another USSD, the MO USSD gets its own conn established and all is well. This behaves identically for both the femto cell kinds I have for testing. But, today, seeing multiple CM Service Requests on the same conn for SMS makes me think that #1816 might be a bug in the USSD dispatch of my phone. If MO SMS can do CM Service Requests on an already open conn, why should MO USSD not be able to do the same? I think in the old, pre-VLR code, we would accept multiple CM Service Requests on the same conn without problems, because the semantics were "re-entrant", calling secure_connection() in multiple places, which was skipped when some flag that we're already authenticated was set. The VLR paradigm is different: it "locks down" a new conn until that is accepted (authenticated and ciphered, according to config). Once a conn is accepted, the rest of the code does not need to bother with asking for securing a connection. So far receiving a CM Service Request is semantically identical with starting a new conn. That's why I would explicitly add a parameter to FSM invocation to skip over auth+ciph in case the conn is already accepted, but still do any HLR actions as needed. What still bugs me is: when the phone knows that a conn is open, why should it bother with a CM Service Request, it could just start sending the real meat right away. Re-using from the CN side: In https://osmocom.org/issues/1712#note-7 I noted that the code should not page when a connection is already open. https://osmocom.org/issues/1862 asks for not attempting to send USSD from the CN to the UE when a conn is there but not authenticated/ciphered yet. When the conn is accepted, we can immediately send the MT messages -- however, if the conn is there but still busy authenticating, we must neither page nor can we send messages right away. We should then add an item to the queue of actions to carry out after a paging response, without dispatching a paging request; and ensure that the queue is also worked off in case we receive a CM Service Request or LU Request instead of a Paging Response ... actually, this might already work, but I should test for it. P.S.: Also wondering, could it happen that we receive a Paging Response on an already accepted connection? Wouldn't make much sense, but might be possible to provoke ;) Any facts/thoughts on this stuff are welcome. ~N

7 years, 2 months

1
0
0 0

Re: libosmocore build failure cascade

by Vadim Yanitskiy

Hi Neels, Max and others, Sorry, I didn't expect such build failures. It seems, some of them was already fixed before I noticed this mail. I was a bit busy with OsmoBTS testing, so let me some time to go through this issues and let me know, if I should fix something else. Before submitting a new change, I do the following: - make check - make distcheck Should I test something else in the future? With best regards, Vadim Yanitskiy.

7 years, 2 months

3
2
0 0

Re: New Defects reported by Coverity Scan for Osmocom

by Neels Hofmeyr

From libosmo-abis beb10ef02a10d73537a97f6f21aad36664c9b266 "add basic unixsocket support": On Wed, Mar 08, 2017 at 08:39:07AM -0800, scan-admin(a)coverity.com wrote: > *** CID 163920: (TAINTED_SCALAR) > /source-Osmocom/libosmo-abis/src/input/unixsocket.c: 90 in unixsocket_read_cb() > 84 uint8_t controldata; > 85 int ret; > 86 > 87 if (!msg) > 88 return -ENOMEM; > 89 > >>> CID 163920: (TAINTED_SCALAR) > >>> Calling function "read" taints argument "msg->data". > 90 ret = read(bfd->fd, msg->data, UNIXSOCKET_ALLOC_SIZE - 16); What this seems to complain about is that we're writing arbitrary data to msg->data, and in lapd_receive() pass this to a LOGP that prints a hexdump of it. In osmo_hexdump, we of course do hex_chars[buf[i] >> 4] which we know to always work out to one of '0'..'f' for *any* data. This point seems to be missed by covertiy scan and it believes we may end up with an invalid index to hex_chars[]. So this is a false positive. Marked it as such. > *** CID 163919: Security best practices violations (STRING_OVERFLOW) > /source-Osmocom/libosmo-abis/src/input/unixsocket.c: 236 in unixsocket_line_update() > 230 struct unixsocket_line *config; > 231 char sock_path[PATH_MAX]; > 232 int ret = 0; > 233 int i; > 234 > 235 if (line->sock_path) > >>> CID 163919: Security best practices violations (STRING_OVERFLOW) > >>> Note: This defect has an elevated risk because the source argument is a parameter of the current function. > 236 strcpy(sock_path, line->sock_path); Please always use osmo_strlcpy(), here with sizeof(sock_path). > 237 else > 238 sprintf(sock_path, "%s%d", UNIXSOCKET_SOCK_PATH_DEFAULT, > 239 line->num); > 240 > 241 LOGP(DLINP, LOGL_NOTICE, "line update (line=%p)\n", line); > > ** CID 163918: Memory - illegal accesses (BUFFER_SIZE_WARNING) > /source-Osmocom/openbsc/openbsc/src/libbsc/bsc_subscriber.c: 83 in bsc_subscr_set_imsi() > > The next one is from me, in 6d804b1a7e375213cb4b3e437c2b9b8c68872164 "add struct bsc_subscr, separating libbsc from gsm_subscriber": > ________________________________________________________________________________________________________ > *** CID 163918: Memory - illegal accesses (BUFFER_SIZE_WARNING) > /source-Osmocom/openbsc/openbsc/src/libbsc/bsc_subscriber.c: 83 in bsc_subscr_set_imsi() > 77 } > 78 > 79 void bsc_subscr_set_imsi(struct bsc_subscr *bsub, const char *imsi) > 80 { > 81 if (!bsub) > 82 return; > >>> CID 163918: Memory - illegal accesses (BUFFER_SIZE_WARNING) > >>> Calling strncpy with a maximum size argument of 16 bytes on destination array "bsub->imsi" of size 16 bytes might leave the destination string unterminated. > 83 strncpy(bsub->imsi, imsi, sizeof(bsub->imsi)); Again, I should use osmo_strlcpy(), which correctly handles sizeof(buf), other than strncpy which might leave the string unterminated. ~N

7 years, 2 months

1
0
0 0

libosmocore build failure cascade

by Neels Hofmeyr

As you may have noticed, Vadim's new coding generation code caused numerous builds to fall on their faces. The reasons why what failed are not so trivial, so let me explain. In short, - we place generated artifacts in the $builddir, which ensures clean builds after removing the $builddir. Because we do that, we sometimes need to also -I$(builddir)/include for builds where $(builddir) != $(srcdir). - for generated files, it is important to have proper make dependencies to rebuild them when the sources for generation change. - in build jobs, it is important to wipe the workspace clean, particularly in the presence of generated source files that don't have proper make dependencies. What I saw today: (1) libosmocore master build failed https://jenkins.osmocom.org/jenkins/job/libosmocore/866/ (2) gerrit libosmocore patch checking build *succeeded* for the failing patch (3) libosmocore build actually first *succeeded* even in clean src dir (4) libosmocore build from different dir on clean *system* failed (5) new generated files ended up in $srcdir (6) debian build complained about files present but not installed My first guess was: the gerrit job fails to clean the workspace and hence works because old headers remain; the master build fails because it properly cleans up the workspace and checks building from another dir. Not at all :) (1) In fact the libosmocore *master* build failed because it did not properly clean up the workspace. The old headers remained, but lacked some symbols that were now undefined during compilation. --> added rm -rf *; git checkout . to the libosmocore master build. --> https://gerrit.osmocom.org/2002 ensures regeneration by changed gen code (If there are more deps that could be added there, please go ahead!) (2) The gerrit libosmocore patch succeeded because it properly cleans up the workspace, and does not check building from a separate dir. So it regenerated all headers in $srcdir, which is fine when also building in $srcdir. --> https://gerrit.osmocom.org/1998 tests separate dir in jenkins.sh (3) If I still have libosmocore headers in e.g. /usr/local/include, the build will take those when missing in the src tree and may actually succeed. So I had to go and rm -rf /usr/local/include/osmocom to reproduce the failure. :/ (4) Build from different dir fails because coding/gsm0503_interleaving.c #includes a header that is generated in $builddir (already before this patch), but coding/Makefile.am did not -I$(builddir)/include. --> https://gerrit.osmocom.org/2003 adds -I builddir in coding/ (5) While generating files in $srcdir does not necessarily break builds, it's better to write to $builddir instead -- removing $builddir then clears the build state completely. Fixed up to generate to $builddir, also in: --> https://gerrit.osmocom.org/1996 generates gsm0503 to builddir (6) *All* files part of 'make install' need to be mentioned in debian/*, either as files to be ignored or files to be installed. Max fixed it in: --> https://gerrit.osmocom.org/1989 --> do we want to add deb build checking to the gerrit job? I spent some time on cleaning failures from that patch, but then spent some extra time to help us not run into these problems again... Thanks for being aware of these issues. ~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

7 years, 2 months

2
1
0 0

osmo-sip-connector in bad state

by OMAR RAMADAN

If the SIP server dies in the middle of a call, osmo-sip-connector is in a bad state and generates a never ending stream of error messages: 58): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length packettport(0xb7e9f25 It looks like the messages are generated from sofia-sip and I have managed to suppress the messages by setting the environment variable SU_DEBUG < 3: http://sofia-sip.sourcearchive.com/documentation/1.12.7/tport__internal_8h_… However, it looks like osmo-sip-connector is clearly in a bad state when this happens and we need a way to detect and release these ghosted calls.

7 years, 2 months

4
15
0 0

packages broken by osmo-pcu commit "BTS: Convert relative frame numbers to absolute frame numbers"

by Neels Hofmeyr

Hi, the line if (abs(rfn - m_cur_rfn) > RFN_THRESHOLD) { in your recent osmo-pcu patch breaks the package builds (on ubuntu 16.10 x86_64 as well as i586). 1275a3f91a744e011b0dba82b09124d249c7abb5 / I74f00c11e5739d49f370ce6c357149e81d9aa759 I guess you should cast the uint32_t to e.g. long int explicitly to avoid the overloading ambiguity. abs((long int)(...)) It puzzles me why our gerrit build job did not run into this ambiguity though. My own build on my laptop doesn't even print a warning for this line. https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o… [ 110s] bts.cpp: In member function 'uint32_t BTS::rfn_to_fn(uint32_t)': [ 110s] bts.cpp:553:25: error: call of overloaded 'abs(uint32_t)' is ambiguous [ 110s] if (abs(rfn - m_cur_rfn) > RFN_THRESHOLD) { [ 110s] ^ [ 110s] In file included from /usr/include/c++/6/cstdlib:75:0, [ 110s] from /usr/include/c++/6/stdlib.h:36, [ 110s] from /usr/include/osmocom/core/linuxrbtree.h:97, [ 110s] from /usr/include/osmocom/core/timer.h:35, [ 110s] from ./bts.h:29, [ 110s] from bts.cpp:21: [ 110s] /usr/include/stdlib.h:735:12: note: candidate: int abs(int) [ 110s] extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur; [ 110s] ^~~ [ 110s] In file included from /usr/include/c++/6/stdlib.h:36:0, [ 110s] from /usr/include/osmocom/core/linuxrbtree.h:97, [ 110s] from /usr/include/osmocom/core/timer.h:35, [ 110s] from ./bts.h:29, [ 110s] from bts.cpp:21: [ 110s] /usr/include/c++/6/cstdlib:185:3: note: candidate: __int128 std::abs(__int128) [ 110s] abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; } [ 110s] ^~~ [ 110s] /usr/include/c++/6/cstdlib:180:3: note: candidate: long long int std::abs(long long int) [ 110s] abs(long long __x) { return __builtin_llabs (__x); } [ 110s] ^~~ [ 110s] /usr/include/c++/6/cstdlib:172:3: note: candidate: long int std::abs(long int) [ 110s] abs(long __i) { return __builtin_labs(__i); } [ 110s] ^~~ ~N

7 years, 2 months

1
0
0 0

RFC: jenkins pipeline

by Max

Hi. Right now we have rather sophisticated CI/CD setup which is spread over several services (OBS for nightly packages, jenkins for CI) and repositories. It works well, but if I've got to somehow extend/alter it than I have to look in at least 3 different places: - ocmo-ci repo for common scripts - jenkins job in jenkins web ui - project's jenkins*.sh scripts I think it's not meant to be that way, it's just what has grown organically over the years. Right now we use recent enough jenkins which support Pipelines [1] plugin. The basic idea behind it is that each project has Jenkinsfile [2] in the repository which is self-contained configuration for CI. In theory enabling this plugin should not affect existing jobs as it's entirely separate job type. I suggest following: - enable Pipelines plugin in jenkins - configure new pipelines-based job pointing to non-master branch which we can use as a playground - once we comfortable with it - migrate existing CI (and possibly CD) to pipelines (as time permit) - switch gerrit from old jobs to new pipelines What do you think? Details are available via links below but here are some quick takeaways which motivated me to write this email: - we'll have actual CI job description under version control (right now it just sits in web ui) - we'll have single place to look for CI-related things (ok, maybe 2 places if we still need common library) - it's more eye-candy (it's clear which build step we're in and how long each step took) - it's easier to parallelize (e. g. run sanitizer and regular builds in parallel) On a related note: in general, who's point of contact for things like "please update jenkins plugin X to version Y"? [1] https://jenkins.io/doc/book/pipeline/ [2] https://jenkins.io/doc/book/pipeline/jenkinsfile/ -- 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

7 years, 2 months

4
5
0 0

Osmocom nightly packages

by Martin Hauke

Hi, i'm building osmocom-related packages for openSUSE since a few years on OBS. https://build.opensuse.org/project/show/home:mnhauke:osmocom https://build.opensuse.org/project/show/home:mnhauke:osmocom-iuh Now i'd like to add support for RPM-based distributions to the osmocom-nightly packages. My current plan is to first add support for (open)SUSE based distributions and if there's interest then find out all the subtle changes that are needed for the spec-file to also add support for Redhat/Fedora/CentOS. # Phase1 - openSUSE_Leap_42.2 (x86_64) - openSUSE_Tumbleweed (i586, x86_64) - openSUSE_Factory_ARM (armv7l, aarch64) - SLE_12_SP2 (x86_64) # Phase2 - CentOS_7 (x86_64) - Fedora_25 (i586, x86_64) - RHEL_7 (x86_64) How does the current workflow for the daily check-in of the nightly debian/ubuntu packages look like? There's probably a bunch of scripts that do - git checkout from all relevant repositories - update changelog based on git commit messages - change the package version - create the new tarball - maybe osc local build - upload the tarball and the dsc to OBS - monitor if all the OBS-packages are successfully built and in state published Thanks in advance, Martin

7 years, 2 months

2
1
0 0

osmo-(bts-)trx multi-trx is broken

by Max

Hi. There's been few updates to osmo-bts-trx recently so I've decided to get back to https://projects.osmocom.org/issues/1648 and it seems like it's completely broken: - the "multiplexing" option (osmo-trx -m -c 2) which used to work now leads to startup error of osmo-trx - the "separate channel" option (osmo-trx -c 2) which wasn't working properly but at least phone could see the network, now leads to situation where no network is visible Am I missing some magic combination of .cfg and command-line parameters which could make it work? Am I using too old version of uhd or smth else? The hw has not changed (usrp b210 + external 10MHz reference clock) but maybe I've got to do some calibrations on it? Any ideas as to what could be causing those regressions? Is there anyone out there for whom some multi-trx setup is working? If so, I'd like to compare notes to understand why it isn't working form me. -- 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

7 years, 2 months

4
4
0 0

Virtual layer 1 - Questions

by Sebastian Stumpf

Hi, The virtual layer 1 is currently in a state where the l23 app can successfully connect to the bts and most of the signaling messages will be forwarded and handled. TCH is not yet implemented. I have some problems still, not knowing if these are caused by configuration problems or my coding :). - Trying to initiate a call via the mobile vty will result in VTY: call 1 123 OsmocomBB# % (MS 1) % Call has been rejected call 1 123 OsmocomBB# % (MS 1) % Call has been released And no actual call setup message is transfered over the Um interface. What could be reasons for that? I am using the test-sim option the mobile app offers. - Occasionaly the T3210 timer is fired, which causes a new registering within the network. LOG: gsm48_mm.c:336 timer T3210 (loc. upd. timeout) has fired How can i prevent that? - I did not implement a tdma or multiframe scheduler in the mobile uplink as the logical channel is directly put to the gsmtap-header and thus known by the bts. As Harald used a multiframe based scheduling for the bts downlink, i wonder if this might be necessary, though. To submit msgs with the correct frame number for example. - In my wireshark capture files, the gsmtap messages sent over the multicast sockets are only recognized as UDP messages. I have to "cast" them with the wireshark context menu "Decode as...". Why? I would be super happy if someone of you could check out my project (osmo-bts, branch stumpf/virt-phy + osmocom-bb, branch stumpf/virt-phy) try to run it with the config files lying within the project folders and tell me the problems they see :). Here you can find a wireshark capture file of 2 mobiles connecting to a virt bts. I also tried to init calls from both of them but the call setup is not send. https://www.dropbox.com/s/2ccky4ljc8ngahz/mobilex2--ms-virt--bts-virt--bsc-… Kind Regards, Sebastian Stumpf

7 years, 2 months

2
7
0 0

how to stop paging

by Neels Hofmeyr

I have a general question about the Paging procedure, specifically about how to stop paging. In libbsc, we have Paging management that receives a request to Page from the MSC and then repeatedly Pages the MS on all BTSes N times or until told to stop. In the NITB, we have code closely tied to the BSC and all BTS management, so that when we receive a Paging Response, we can right away stop sending Paging Commands on all BTSes. So can the standalone-BSC: it stops paging when it received a Paging Response. In OsmoMSC with Iu- and A-interfaces, that's not possible. Looking in 08.08, there seems to be no A-interface message that tells the BSCs "thank you, you can stop paging now". If one BSC or RNC has relayed back a Paging Response from one of the cells, the MSC has no way to tell the other base stations that it's fine to stop sending dozens of Pagings out for "minutes", which would be useless now anyway because the MS has called back via another base station already. Is that a fact of life? We continue Paging in all cells where the MS is not visible? Should the BSC/RNC part of the network page only once, so that "stop paging" is a no-op? Of course we first check which LAC the MS was first seen on and page only there. Is the idea to send paging to one cell, and that cell stops Paging by itself when it received a Paging Response that it relays to the MSC? But IIRC Paging is supposed to spread out across other base stations if at first it didn't succeed -- I recall to have read that in HNB-GW specs or somewhere close to that. Our OsmoHNBGW so far simply Pages everywhere. The practical reason I'm asking is that in the msc_vlr tests, I so far explicitly check whether the "stop paging" function was called. Now on the Iu branch, without libbsc, there is no such function. Should I drop those checks because we will never have that? Or should I add some shim function we call just for the tests so far, which will at some point tell the base stations that Paging has concluded? Thanks for any hints, ~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

7 years, 2 months

1
0
0 0

my patches prioritized

by Neels Hofmeyr

I currently have a whole series of patches on gerrit, many of which fail to build. Here are the pivotal ones I am waiting for, the other patches can be mostly ignored until these are through: https://gerrit.osmocom.org/1682 (struct bsc_subscr) Waiting for a comment. VLR and 3G branches build on it. I'm happy to change the patch, but not sure whether I really have to. IMHO there are benefits to this unusual way, but one word ("no") is enough. https://gerrit.osmocom.org/1923 (cosmetic prep for 1924) https://gerrit.osmocom.org/1924 (python tests: VTY connection speedup) These two are needed for the openbsc python tests speedup patches to work. https://gerrit.osmocom.org/1962 (explicitly terminate ctrl_type_vals[]) https://gerrit.osmocom.org/1940 (find unterminated value strings) The first is a fixup for the second to work, the second one is needed for all of the other value_string topic patches to work. I'd like to add this check to jenkins now, so that all incoming value_string[]s are validated. https://gerrit.osmocom.org/1906 (python tests from separate build dir) I usually build 2G and 3G separately, and I'd like to run the py tests in each dev cycle, now that they are faster. So I'd love to merge this. Hope this helps to save some time... ~N

7 years, 2 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC March 2017