From infibiti16 at gmail.com Mon May 6 06:45:54 2019 From: infibiti16 at gmail.com (BT Infinite) Date: Mon, 6 May 2019 14:45:54 +0800 Subject: Problem 2 Message-ID: <5ccfd824.1c69fb81.a110e.2c93@mx.google.com> Make Host Layer23 Command cannot build these library. I writer make command but it show those problems. (Picture 1). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: error3.png Type: image/png Size: 160452 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: error4.png Type: image/png Size: 46120 bytes Desc: not available URL: From pespin at sysmocom.de Mon May 6 08:21:33 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 6 May 2019 10:21:33 +0200 Subject: Problem 2 In-Reply-To: <5ccfd824.1c69fb81.a110e.2c93@mx.google.com> References: <5ccfd824.1c69fb81.a110e.2c93@mx.google.com> Message-ID: <386581d5-9f0c-e7e3-cddd-7508a99704b3@sysmocom.de> Hi, It seems you are not using the correct build toolchain. PS: Please don't send images to ml unless really needed. In this case it's far easier copyig text from your terminal here. If lots of text is required, use pastebin. On 5/6/19 8:45 AM, BT Infinite wrote: > Make Host Layer23 Command cannot build these library. > > I writer make command but it show those problems. (Picture 1). > -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From axilirator at gmail.com Mon May 6 10:49:26 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 6 May 2019 13:49:26 +0300 Subject: Problem 2 In-Reply-To: <386581d5-9f0c-e7e3-cddd-7508a99704b3@sysmocom.de> References: <5ccfd824.1c69fb81.a110e.2c93@mx.google.com> <386581d5-9f0c-e7e3-cddd-7508a99704b3@sysmocom.de> Message-ID: > It seems you are not using the correct build toolchain. > Error: so such instruction `eor ...` ... or the toolchain is not installed at all. I've seen such error message in such cases. Please use the correct mailing list next time: baseband-devel at lists.osmocom.org With best regards, Vadim Yanitskiy. From laforge at gnumonks.org Mon May 6 11:15:52 2019 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 6 May 2019 13:15:52 +0200 Subject: Large increase in osmo-bsc SCCPlite test failures Message-ID: <20190506111552.GB8616@nataraja> Dear all, as you can see at https://jenkins.osmocom.org/jenkins/job/ttcn3-bsc-test-sccplite/test_results_analyzer/ there has been a large increase in test failures of the SCCPlite related tests in osmo-bsc over the last two builds/tests. Does anyone know what kind of changes they made which could have impacted the relted behavior? We don't see any such failures on AoIP, leading me to suspect that some changes were tested only for AoIP but not for SCCPlite? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue May 7 14:55:13 2019 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 7 May 2019 16:55:13 +0200 Subject: osmo_quote_str_c() In-Reply-To: <20190412012341.GA10236@my.box> References: <20190412012341.GA10236@my.box> Message-ID: <20190507145513.GT8616@nataraja> Hi Neels, On Fri, Apr 12, 2019 at 03:23:41AM +0200, Neels Hofmeyr wrote: > I think here is a bug: ACK. > Looks like the allocated len should be stored in a local variable to pass to > osmo_quote_str_buf2(). ACK. See https://gerrit.osmocom.org/#/c/libosmocore/+/13901 > And if I'm right, what is the 32 for? At least 32?? At least 32 bytes to have some minimum buffer size for things like printing "NULL" or the like. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Wed May 8 00:21:09 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 8 May 2019 02:21:09 +0200 Subject: ttcn3: bsc-sccplite Message-ID: <20190508002109.GA28855@my.box> Looking at https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-sccplite/test_results_analyzer/ looks quite horrible since build 357. However, with my own manual tests, all of those pass. It looks like most of those failures are sporadic, and I cannot reproduce them. I am not sure how to find out what is going there, I can just say that osmo-bsc looks quite stable AFAICT and that it seems to be non-determinism / timing in the ttcn3 and/or system load causing the failures. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From rafael at rhizomatica.org Wed May 8 12:39:51 2019 From: rafael at rhizomatica.org (Rafael Diniz) Date: Wed, 8 May 2019 09:39:51 -0300 Subject: External clock source for LimeSDR mini Message-ID: <22fa1b27-c090-e61e-179d-fcf770e95d33@rhizomatica.org> Hi all, Could anyone advise me which solution should I look for feeding the LimeSDR mini with external clock GPSDO locked? Btw, which you think it's a better option for a home brew BTS: the LimeSDR mini with external clock plus an intel mini-pc, or the LimeNet mini? Cheers, Rafael Diniz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From tyruskam at gmail.com Thu May 9 09:44:05 2019 From: tyruskam at gmail.com (ty) Date: Thu, 9 May 2019 12:44:05 +0300 Subject: OpenBSC installed but missing ipaccess and abisip-find Message-ID: Hello. I just followed the step by step procedure outlined in the wiki to compile OpenBSC on Ubuntu 16.04 LTS for the ip.access nanoBTS. My problem is that the folder ipaccess which has the ipaccess.config is missing and so is the abisip-find file. Any leads on why this is happening? I had seen somewhere that the above can be found in the osmocom-ipaccess-utils from the repo but that too is unavailable. Many thanks -tyrus -------------- next part -------------- An HTML attachment was scrubbed... URL: From pespin at sysmocom.de Thu May 9 14:15:39 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Thu, 9 May 2019 16:15:39 +0200 Subject: OpenBSC installed but missing ipaccess and abisip-find In-Reply-To: References: Message-ID: Hi, ipaccess related binaries have been removed from openbsc.git in 07bcda7554a981cb23af9eb4ea9f5e23573580c6, and have been actually maintained (and deb packages generated) in osmo-bsc.git. You definetly want to build them from there. Please point us to related docs if they are outdated. -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From laforge at gnumonks.org Thu May 9 19:37:26 2019 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 9 May 2019 21:37:26 +0200 Subject: OpenBSC installed but missing ipaccess and abisip-find In-Reply-To: References: Message-ID: <20190509193726.GV27066@nataraja> Hi Ty, aside from Pau's comment, I'm wondering why you aren't using the binary packages we provide. I of course understand there's tons of reasons why you would want to build code from source (trust, security, ...) but then typically if you build from source, then Please also note that OpenBSC/OsmoNITB from openbsc.git is discontinued since 2017. Please use new "CNI" stack with software from osmo-bsc.git, osmo-msc.git, osmo-hlr.git, etc. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From tyruskam at gmail.com Fri May 10 08:20:15 2019 From: tyruskam at gmail.com (ty) Date: Fri, 10 May 2019 11:20:15 +0300 Subject: OpenBSC installed but missing ipaccess and abisip-find In-Reply-To: <20190509193726.GV27066@nataraja> References: <20190509193726.GV27066@nataraja> Message-ID: Thanks for the revert Pau. Then the Wiki is outdated https://osmocom.org/projects/openbsc/wiki/Building_OpenBSC Thank you Harald. Managed to find the .debs and installed them successfully. Problem is the abisip-find doesn't find the nanoBTS which is clearly powered on. Any insight into this. In addition, I'm getting this symbol error when I run osmo-nitb tyrus at the-jedi-council:~/openbsc/openbsc/src/osmo-nitb$ ./osmo-nitb .*/osmo-nitb: /usr/lib/i386-linux-gnu/libosmoctrl.so.0: no version information available (required by ./osmo-nitb)* *./osmo-nitb: relocation error: ./osmo-nitb: symbol ctrl_vty_init, version LIBOSMOCTRL_1.0 not defined in file libosmoctrl.so.0 with link time reference* Any idea what could be broken? I have an idea it's a linker issue but not too sure how to troubleshoot this. Also was nice attending your talk when you were last in Nairobi. Good work. Many thanks On Thu, May 9, 2019 at 10:40 PM Harald Welte wrote: > Hi Ty, > > aside from Pau's comment, I'm wondering why you aren't using the binary > packages > we provide. I of course understand there's tons of reasons why you would > want > to build code from source (trust, security, ...) but then typically if you > build > from source, then > > Please also note that OpenBSC/OsmoNITB from openbsc.git is discontinued > since 2017. > > Please use new "CNI" stack with software from osmo-bsc.git, osmo-msc.git, > osmo-hlr.git, etc. > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pespin at sysmocom.de Mon May 13 09:30:05 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 13 May 2019 11:30:05 +0200 Subject: OpenBSC installed but missing ipaccess and abisip-find In-Reply-To: References: <20190509193726.GV27066@nataraja> Message-ID: Hi. On 5/10/19 10:20 AM, ty wrote: > > tyrus at the-jedi-council:~/openbsc/openbsc/src/osmo-nitb$ ./osmo-nitb > .*/osmo-nitb: /usr/lib/i386-linux-gnu/libosmoctrl.so.0: no version > information available (required by ./osmo-nitb)* > *./osmo-nitb: relocation error: ./osmo-nitb: symbol ctrl_vty_init, > version LIBOSMOCTRL_1.0 not defined in file libosmoctrl.so.0 with link > time reference* > * > * You say you installed programs from .deb but you are still running the version of osmo-nitb from your compiled version. Use the one from packages to avoid this kind of issues, otherwise the version you built and the ones from the .deb packages won't much unless you really know what you are doing. -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From tyruskam at gmail.com Mon May 13 12:31:03 2019 From: tyruskam at gmail.com (ty) Date: Mon, 13 May 2019 15:31:03 +0300 Subject: OpenBSC installed but missing ipaccess and abisip-find In-Reply-To: References: <20190509193726.GV27066@nataraja> Message-ID: Hi Pau Once again I truly appreciate your revert. You're right. I managed to pull the osmoBsc and compiled it together with the dependencies. Every thing works fine until I ran 'make' which throws this struct error In file included from gsm_04_80_utils.c:22:0: /usr/local/include/osmocom/gsm/gsm0480.h:120:14: note: declared here struct msgb *gsm0480_create_ussd_release_complete(void) ^ CC gsm_data.o CC handover_cfg.o CC handover_decision.o CC handover_decision_2.o CC handover_fsm.o CC handover_logic.o CC handover_vty.o CC lchan_fsm.o CC lchan_rtp_fsm.o lchan_rtp_fsm.c: In function ?mgcp_pick_codec?: lchan_rtp_fsm.c:841:12: error: ?struct mgcp_conn_peer? has no member named ?param_present? verb_info->param_present = true; ^ lchan_rtp_fsm.c:842:12: error: ?struct mgcp_conn_peer? has no member named ?param? verb_info->param.amr_octet_aligned_present = true; ^ lchan_rtp_fsm.c:851:12: error: ?struct mgcp_conn_peer? has no member named ?param? verb_info->param.amr_octet_aligned = true; ^ lchan_rtp_fsm.c:854:12: error: ?struct mgcp_conn_peer? has no member named ?param? verb_info->param.amr_octet_aligned = lchan->conn->sccp.msc->amr_octet_aligned; ^ Makefile:616: recipe for target 'lchan_rtp_fsm.o' failed make[3]: *** [lchan_rtp_fsm.o] Error 1 make[3]: Leaving directory '/home/tyrus/osmo-bsc/src/osmo-bsc' Makefile:405: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/home/tyrus/osmo-bsc/src' Makefile:448: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/tyrus/osmo-bsc' Makefile:380: recipe for target 'all' failed make: *** [all] Error 2 So I have tried all weekend to debug it but unfortunately haven't made much headway. Any leads? Many thanks On Mon, May 13, 2019 at 12:30 PM Pau Espin Pedrol wrote: > Hi. > > On 5/10/19 10:20 AM, ty wrote: > > > > tyrus at the-jedi-council:~/openbsc/openbsc/src/osmo-nitb$ ./osmo-nitb > > .*/osmo-nitb: /usr/lib/i386-linux-gnu/libosmoctrl.so.0: no version > > information available (required by ./osmo-nitb)* > > *./osmo-nitb: relocation error: ./osmo-nitb: symbol ctrl_vty_init, > > version LIBOSMOCTRL_1.0 not defined in file libosmoctrl.so.0 with link > > time reference* > > * > > * > > You say you installed programs from .deb but you are still running the > version of osmo-nitb from your compiled version. Use the one from > packages to avoid this kind of issues, otherwise the version you built > and the ones from the .deb packages won't much unless you really know > what you are doing. > > -- > - Pau Espin Pedrol http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Alt-Moabit 93 > * 10559 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Geschaeftsfuehrer / Managing Director: Harald Welte > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvvelichkov at gmail.com Mon May 13 17:28:21 2019 From: vvvelichkov at gmail.com (Vasil Velichkov) Date: Mon, 13 May 2019 20:28:21 +0300 Subject: OpenBSC installed but missing ipaccess and abisip-find In-Reply-To: References: <20190509193726.GV27066@nataraja> Message-ID: <7f366334-a7bb-6996-d489-e184fd890a5d@gmail.com> Hi Ty, On 13/05/2019 15.31, ty wrote: > In file included from gsm_04_80_utils.c:22:0: > /usr/local/include/osmocom/gsm/gsm0480.h:120:14: note: declared here > ?struct msgb *gsm0480_create_ussd_release_complete(void) > ? ? ? ? ? ? ? ^ Most probably this is a deprecation warning that you could ignore. > ? CC? ? ? ?lchan_rtp_fsm.o > lchan_rtp_fsm.c: In function ?mgcp_pick_codec?: > lchan_rtp_fsm.c:841:12: error: ?struct mgcp_conn_peer? has no member > named ?param_present? > ? ?verb_info->param_present = true; > ? ? ? ? ? ? ^ > lchan_rtp_fsm.c:842:12: error: ?struct mgcp_conn_peer? has no member > named ?param? > ?verb_info->param.amr_octet_aligned_present = true; > ? ? ? ? ? ? ^ > lchan_rtp_fsm.c:851:12: error: ?struct mgcp_conn_peer? has no member > named ?param? > ?verb_info->param.amr_octet_aligned = true; > ? ? ? ? ? ? ^ > lchan_rtp_fsm.c:854:12: error: ?struct mgcp_conn_peer? has no member > named ?param? > ?verb_info->param.amr_octet_aligned = > lchan->conn->sccp.msc->amr_octet_aligned; > ? ? ? ? ? ? ^ > Makefile:616: recipe for target 'lchan_rtp_fsm.o' failed > make[3]: *** [lchan_rtp_fsm.o] Error 1 > make[3]: Leaving directory '/home/tyrus/osmo-bsc/src/osmo-bsc' Install the latest version of osmo-mgw from its maser branch and try again.? These two members were added in commit 228e59158 and it seems you have installed an older version. Regards, Vasil -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sat May 18 10:55:16 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 18 May 2019 12:55:16 +0200 Subject: osmo_fsm and sub-second timeouts Message-ID: <20190518105516.GI10927@nataraja> Hi all! As some of you know, I'm currently using libosmocore, and specifically osmo_fsm inside some cortex-m microcontroller projects. One of the features I need there: FSM timeouts below 1s. osmo_fsm uses osmo_timer_list as underlying timer, and that timer can express any timeval (seconds + microseconds) as timeout. Only the osmo_fsm API doesn't expose that part. What I could now do: Simply add osmo_fsm_inst_state_chg2 which takes one more argument for microseconds. However, I find that "second, microsecond" style with two arguments everywhere quite clumsy. So what I'm instead suggesting is to add new API that use one single timeout value (like the current API), but specify the timeout in milliseconds. The old API then becomes a wrapper around the new API, simply multiplyin timeouts by a factor of 1000. Does anyone think this is too restrictive? I currently cannot think of use cases where timeouts below one 1ms or with granularity below 1ms matter *and* where one would want to use osmo-fsm. But given how speeds of systems (both processors and communications systems) are increasing, it might be that we'd eventually need that? I'd currently assume osmo_fsm with all of its internal logging, etc. is too heavy-weight for such super-time-constrained use cases. And in terms of value range: Assuming a 32bit architecture, the scale of a 2^32 microsecond value is sufficient to express timeouts up to 1193 hours, which in turn is about 49 days. Any comments, ideas, thoughts? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat May 18 11:05:49 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 18 May 2019 13:05:49 +0200 Subject: osmo_fsm and time_t Message-ID: <20190518110549.GJ10927@nataraja> Hi Neels, in the following commit: commit 89991fdb7c01fa42e323577b4026985e580763cf Author: Neels Hofmeyr Date: Mon Jan 28 19:06:53 2019 +0100 you introduce language about restricting the timeout to a signed 32bit value, as time_t is not well-defined on 32bit systems. What I'm somehow missing is where we are using time_t in this context? Neither osmo_fsm code nor the underlying osmo_timer_list seems to be using time_t. So why would we bother about time_t here? Thanks for sharing your thoughts. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Thu May 23 02:12:02 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 23 May 2019 04:12:02 +0200 Subject: osmo_fsm and time_t In-Reply-To: <20190518110549.GJ10927@nataraja> References: <20190518110549.GJ10927@nataraja> Message-ID: <20190523021202.GA2449@my.box> On Sat, May 18, 2019 at 01:05:49PM +0200, Harald Welte wrote: > Hi Neels, > > in the following commit: > > commit 89991fdb7c01fa42e323577b4026985e580763cf > Author: Neels Hofmeyr > Date: Mon Jan 28 19:06:53 2019 +0100 > > you introduce language about restricting the timeout to a signed 32bit value, > as time_t is not well-defined on 32bit systems. > > What I'm somehow missing is where we are using time_t in this context? Neither > osmo_fsm code nor the underlying osmo_timer_list seems to be using time_t. I think I was first considering to use time_t, but since that didn't provide a fixed range in a cross-platform way, I chose int32_t instead. IIRC. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laforge at gnumonks.org Fri May 24 09:36:33 2019 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 24 May 2019 11:36:33 +0200 Subject: New features without tests :/ Message-ID: <20190524093633.GN4554@nataraja> Dear fellow Osmocom developers, I just would like to use this as a gentle reminder that we shouldn't be merging new features without having automatic tests for them in place. What comes to my mind immediately right now (but I'm sure there are other examples) is the "subscriber create on demand" feature. I couldn't find any tests in HLR_Tests.ttcn about this feature. What this means is, that it will *eventually* break unnoticed, particularly until somebody is using that feature and updating frequently to master, which is unlikely to happen. Either you run a production system and then you don't follow master, or you're just playing around and then that feature is probably not something you'd be using in many cases. What actually bugs me most about it, is that the tests should have been written first. For most of our development [1], the existing infrastructure in terms of TTCN3 Modules is very strong, and adding related tests is rather quick. This means it's *very* feasible to write the tests first and then the actual code. In fact, my own experience shows that development is much faster this way, as maual testing of the entire stack with phones is sloooow. This is not to complain to Oliver or any single person, but just a general reminder to all of us. That includes first and foremost myself as I'm merging most of the development, but is addressed to all of the developers and reviewers: IF something doesn't have a test, but could reasonably be tested without spending a multitude of the development time on tests, we should mandate that tests are available at the time of merge. We of course cannot mandate or enforce that developers write the tests first and follow test-driven development methodology. But I would at least strongly encourage everyone to try that. If you first spend tons of time with manual testing and then write a test case, it's much less efficient as you spend time for both. OTOTH, if you first invest the time into writing the test, then the development can make very quick progress and you save a lot of time that would otherwise be wasted with manual testing. Regards, Harald [1] I'm referring to rather self-cntained, small features. For sure, e.g. testing inter-MSC-HO requires lots of new tsting infrastructure to be developed, as does testing of the PCU. So yes, there are exception. -- - Harald Welte http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From osmith at sysmocom.de Fri May 24 10:06:45 2019 From: osmith at sysmocom.de (Oliver Smith) Date: Fri, 24 May 2019 12:06:45 +0200 Subject: New features without tests :/ In-Reply-To: <20190524093633.GN4554@nataraja> References: <20190524093633.GN4554@nataraja> Message-ID: <51ab21d7-8eb6-6cdb-2ca7-e537a4771032@sysmocom.de> Dear Harald and ML, thank you for the feedback. I fully agree with your mail, and will create the missing tests for "subscriber create on demand" (and the related check IMEI code) soon. And for future features, try to write them first. Regards, Oliver On 5/24/19 11:36 AM, Harald Welte wrote: > Dear fellow Osmocom developers, > > I just would like to use this as a gentle reminder that we shouldn't be > merging new features without having automatic tests for them in place. > > What comes to my mind immediately right now (but I'm sure there are other > examples) is the "subscriber create on demand" feature. I couldn't find > any tests in HLR_Tests.ttcn about this feature. > > What this means is, that it will *eventually* break unnoticed, particularly > until somebody is using that feature and updating frequently to master, > which is unlikely to happen. Either you run a production system and then > you don't follow master, or you're just playing around and then that > feature is probably not something you'd be using in many cases. > > What actually bugs me most about it, is that the tests should have been > written first. For most of our development [1], the existing infrastructure > in terms of TTCN3 Modules is very strong, and adding related tests is > rather quick. This means it's *very* feasible to write the tests first > and then the actual code. In fact, my own experience shows that development > is much faster this way, as maual testing of the entire stack with phones > is sloooow. > > This is not to complain to Oliver or any single person, but just a general > reminder to all of us. That includes first and foremost myself as I'm > merging most of the development, but is addressed to all of the developers > and reviewers: IF something doesn't have a test, but could reasonably be > tested without spending a multitude of the development time on tests, we > should mandate that tests are available at the time of merge. > > We of course cannot mandate or enforce that developers write the tests first > and follow test-driven development methodology. But I would at least strongly > encourage everyone to try that. If you first spend tons of time with manual > testing and then write a test case, it's much less efficient as you spend time > for both. OTOTH, if you first invest the time into writing the test, then > the development can make very quick progress and you save a lot of time > that would otherwise be wasted with manual testing. > > Regards, > Harald > > [1] I'm referring to rather self-cntained, small features. For sure, > e.g. testing inter-MSC-HO requires lots of new tsting infrastructure to be > developed, as does testing of the PCU. So yes, there are exception. > -- - Oliver Smith https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From keith at rhizomatica.org Fri May 24 12:41:39 2019 From: keith at rhizomatica.org (Keith) Date: Fri, 24 May 2019 14:41:39 +0200 Subject: New features without tests :/ In-Reply-To: <20190524093633.GN4554@nataraja> References: <20190524093633.GN4554@nataraja> Message-ID: On 24/05/2019 11:36, Harald Welte wrote: > Dear fellow Osmocom developers, [...] Hi Harald.. I certainly have in mind that in order to continue developing, especially if it involves anything approaching a "new feature", I need to learn how to write tests, and then of course to test the tests before using the tests to test! Given that ttcn3 is still a new language to me, this represents something of a learning curve, of course. I know that there is a docker setup (I haven't played with it yet)? - I'm just wondering if there is a easier (better) way than each individual developer running there own entire ttcn3/osmo stack test environment? Maybe I'm over estimating the complexity of that? Thanks. k From laforge at gnumonks.org Fri May 24 17:21:10 2019 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 24 May 2019 19:21:10 +0200 Subject: New features without tests :/ In-Reply-To: References: <20190524093633.GN4554@nataraja> Message-ID: <20190524172109.GC22070@nataraja> Hi Keith, On Fri, May 24, 2019 at 02:41:39PM +0200, Keith wrote: > Given that ttcn3 is still a new language to me, > this represents something of a learning curve, of course. I underestand and appreciate that. IT was new to all of us some ~2.5 years ago. The advantage *now* is that we pretty much have the infrastructure in place for most of the things we'd typically encounter in testing (with exception of the PCU), and plenty of examples (the existing test cases). This should hopefully make writing new tests a lesser challenge. From a syntactical point of view, it's luckily not so far from C. And for sure one can simply hack at it without understanding the full language and/or all of its concepts. Eric is currently going thorugh this, and just got his first new test (about initial TA in channel activation) merged. > I know that there is a docker setup (I haven't played with it yet)? - > I'm just wondering if there is a easier (better) way than each > individual developer running there own entire ttcn3/osmo stack test > environment? For executing the test suite, the dockerized setup is clearly the lowest entrance barrier. It requires virtually zero configuration (aside from docker being around) - but building the images, etc. of course takes time - and we don't use ccache in that setup, so build times are long. I wuold assume that in order to have quick development cycles and to control various things interactively one would normally want to run the testsuite natively while developing tests. There's a bit of hassle involved in that, in order to get the adresses/ports/etc. all configured in a way to work. But that should be one-time exercise... We can have jenkins jobs to execute newly developed tests from personal branches on build hosts, if you think that would make it simpler. But honestly, I think one wants to see the test running locally, quickly edit a line, restart, ... > Maybe I'm over estimating the complexity of that? executing the tests shouldn't be the complex part - at least not more complex than setting up a cellular network with elements of different suppliers, where all kinds of addresses, parameters, etc. have to be set up (i.e. not having all the 'atomagic' Osmocom stuff we introduced to simplify nitb-like setups, with automatic routing key management, ...) Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat May 25 09:01:26 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 25 May 2019 11:01:26 +0200 Subject: RFC: Quoted strings with spaces in CTRL protocol? Message-ID: <20190525090126.GF22070@nataraja> Hi! I've been working on a patch for OsmoBSC which generates CTRL traps from OML Failure Event Reports as received from BTSs. This is quite obvious, of course we want failures generate traps, right? The problem starts with the fact that Failure Event Reports can contain arbitrary strings ("Additional Text IE"), and that such text of course can contain spaces. My current patch (https://gerrit.osmocom.org/#/c/osmo-bsc/+/14177) would produce TRAPs like this: b'TRAP 0 bts.0.oml_failure_report "processing failure","failure ceased","TC_pcu_oml_alert"' [where the b'' part is from python as I used osmo_ctrl.py to print the above] As we never formally specified anything about the CTRL protocol apart from using ',' as a separator between fields, this is a somewhat grey area. What do you guys think? Do you know of existing CTRL interface usage where spaces are present in the 'value' part of the message? Do you know of existing code that would break should we introduce support for quoted strings with spaces inside the 'value' part? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)