Dear all,
I had to spend a large portion of my spare time last night in order to
add a new jenkins build slave in a way that it works. What should have
been very simple by following the wiki at
https://osmocom.org/projects/osmocom-servers/wiki/Jenkins_Node_Setup
turned out into a long process of failures that still continue, see
http://jenkins.osmocom.org/jenkins/job/osmo-bts-gerrit/1325/
I'm really not happy about the lack of discipline in keeping the documentation
in sync - or even bothering to state in the wiki "FIXME, some stuff
needs to be done which is not documented". Having very incomplete
documentation that suggests something is a very easy and
straight-forward task is possibly worse than having no documentation,
at which point the reader/user is clear about this being a
time-consuming procedure that involved manual recreation of a manual
setup.
We do now have "build-2.osmocom.org", which is a Ryzen 1700X eight-core
CPU with 64GB RAM. It natively runs Debian 9 (stretch) and has a
Debian8 build slave inside a lxc container.
I've updated the wiki page, but I don't think "copy over the ~/docker directory
whose contents is not under revision control and then run ./update.sh" is
all that good an idea either.
Adding more build slaves to a jenkins setup should be the most natural and
normal thing to do. After all, the entire system is designed to scale out
by adding more build slaves.
I think the right process here would be to have a script that generates
the build slave[s]. My preference would be to have a lxc template for
it, so any new build host simply needs to lxc-create from that template.
Is anyone willing to contribute in that area?
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)
Hello openbsc community!
We are encountering the ff issue: When using basic phones, we have observed
that the timestamps on the SMS are in UTC, even if we changed the linux
system timezone to a different one. Also, if the basic phone will do an
auto-update of date and time from the network, it will use the time in UTC.
Do you have suggestions on how to change the network timezone configuration
for the osmo-nitb? There is a timezone command mentioned in the osmo-nitb
vty reference manual (timezone <-19-19> (0|15|30|45), ex. timezone 8 0 ).
If we put that config under the BTS level (in osmo-nitb.cfg), osmo-nitb
will complain that there is a config error. If we put that under the
network level, osmo-nitb does not complain, but it doesn't seem to work as
expected.
Let me know if addtl info is needed. Thank you in advance!
Trying to get the newest 2G+3G developments thru the test suites (including the
vty ones), I face a problem with this VTY definition from libosmo-sccp:
routing-key RCONTEXT DPC [si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)] [ssn SSN]
It turns out the square braces indicating optional parameters cannot contain
spaces.
To test, I created
foo [a] [b]
which works as
OsmoMSC(config-msc)# foo ?
[a] a
OsmoMSC(config-msc)# foo b
% Unknown command.
OsmoMSC(config-msc)# foo a
ok
OsmoMSC(config-msc)# foo a ?
[b] b
OsmoMSC(config-msc)# foo a b
ok
So far so good, but with:
foo [a AA] [b]
I get
OsmoMSC(config-msc)# foo ?
[a a
OsmoMSC(config-msc)# foo a
% There is no matched command.
OsmoMSC(config-msc)# foo a val
% Unknown command.
The way this would work is
foo [a] [AA] [b]
and means that I can issue either 'foo', 'foo a', 'foo a val' or 'foo a val b'.
Not that helpful really.
With above command
routing-key RCONTEXT DPC [si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)] [ssn SSN]
it seems to me it is intended as optionally providing none, si or both si and ssn?
I guess we need separate command definitions:
routing-key RCONTEXT DPC
routing-key RCONTEXT DPC si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)
routing-key RCONTEXT DPC si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup) ssn SSN
Does that make sense?
Until we fix it, the vty tests will not be able to match up the vty doc
parameters and the python tests will fail.
I grepped for all square brace vty definitions we have; the only ones attempting to include multiple args in square braces are in osmo_ss7_vty.c:
./libosmo-sccp/src/osmo_ss7_vty.c-265- "update route POINT_CODE MASK linkset LS_NAME [priority PRIO] [qos-class (CLASS|default)]",
./libosmo-sccp/src/osmo_ss7_vty.c-781- "routing-key RCONTEXT DPC [si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)] [ssn SSN]}",
They aren't usable.
(the 'update route...' is part of the _sg vty command set and thus not caught
by osmo-msc or -bsc vty tests; osmo-stp has no vty tests so far, AFAICT)
These appear to be all square brace vty definitions, most enclose only a single
element and are fine:
▶ grep -n '\<DEFUN\>(' -A1 $(find . -name "*.c") | grep '[[]'
./osmo-sgsn/src/gprs/sgsn_vty.c-534- "show mm-context tlli HEX [pdp]",
./osmo-sgsn/src/gprs/sgsn_vty.c-553- "show mm-context imsi IMSI [pdp]",
./osmo-sgsn/src/gprs/sgsn_vty.c-570- "show mm-context all [pdp]",
./osmo-sgsn/src/gprs/gb_proxy_vty.c:461:DEFUN(show_gbproxy, show_gbproxy_cmd, "show gbproxy [stats]",
./osmo-sgsn/src/gprs/gb_proxy_vty.c-552- "delete-gbproxy-peer <0-65534> (only-bvc|only-nsvc|all) [dry-run]",
./osmo-bsc/src/osmo-bsc/osmo_bsc_vty.c-63- "msc [<0-1000>]", "Configure MSC details\n" "MSC connection to configure\n")
./osmo-bsc/src/libbsc/bsc_vty.c:319:DEFUN(show_bts, show_bts_cmd, "show bts [<0-255>]",
./osmo-bsc/src/libbsc/bsc_vty.c:1629:DEFUN(cfg_bts_dtxu, cfg_bts_dtxu_cmd, "dtx uplink [force]",
./osmo-bsc/src/libbsc/bsc_vty.c-3947- "bts <0-255> trx <0-255> timeslot <0-7> sub-slot <0-7> (activate|deactivate) (hr|fr|efr|amr) [<0-7>]",
./osmo-mgw/src/libosmo-legacy-mgcp/mgcp_vty.c-229- "show mgcp [stats]",
./libosmo-sccp/src/osmo_ss7_vty.c-110- "point-code format <1-24> [<1-23>] [<1-22>]",
./libosmo-sccp/src/osmo_ss7_vty.c-265- "update route POINT_CODE MASK linkset LS_NAME [priority PRIO] [qos-class (CLASS|default)]",
./libosmo-sccp/src/osmo_ss7_vty.c-781- "routing-key RCONTEXT DPC [si (aal2|bicc|b-isup|h248|isup|sat-isup|sccp|tup)] [ssn SSN]}",
./libosmo-sccp/examples/sccp_test_vty.c-39- "connect-req <0-16777216> [DATA]",
./libosmo-sccp/examples/sccp_test_vty.c-53- "connect-resp <0-16777216> [DATA]",
./libosmocore/src/gb/gprs_ns_vty.c:216:DEFUN(show_nse, show_nse_cmd, "show ns (nsei|nsvc) <0-65535> [stats]",
./libosmocore/src/gb/gprs_bssgp_vty.c:153:DEFUN(show_bvc, show_bvc_cmd, "show bssgp nsei <0-65535> [stats]",
./libosmocore/src/vty/command.c-2965- "no service terminal-length [<0-512>]",
./libosmocore/src/vty/logging_vty.c-520- "log gsmtap [HOSTNAME]",
~N
I just added a new repository: osmo-dev.git.
For a long time I have been using hacked-up tools to help me in daily
Osmocom development. A recent addition was a generator for a top-level
makefile that allows one-line do-what-I-mean rebuild.
That's the point where I thought it made sense to share, in case anyone
else is interested in this kind of convenience.
The name is taken from osmo-ci. osmo-ci is for continuous integation on
our jenkins, osmo-dev is for development at home. I considered adding to
osmo-ci, but the aims are actually different from osmo-ci.
There are two README files, one explaining how the top-level makefile
works, one in src/ explains my little git robots that are also included.
The future will bring more *.deps and *.opts configs...
osmo-dev is on gerrit, feel free to contribute / test / fix!
If you don't agree with the naming and separate repos decision, I'd be
fine to change that...
~N
Hi all,
Yesterday and today I've been working to get the test suites for M3UA,
SUA and GGSN(GTP) integrated into jenkins.osmocom.org.
Some more background can be found at
http://laforge.gnumonks.org/blog/20170820-osmocom-testsuites/ with links
to the respective jenkins jobs and git repositories of test cases and
Dockerfiles + Makefiles.
It's important to note that those tests are neither a competition nor a
replacement for both the unit tests as well as osmo-gsm-tester. I'm not
quite sure how to call them, maybe "connected tests" or the like, as
they interact with our running network elements over the various
protocols/interfaces.
The parts that I'm not entirely sure about yet is:
1) does it really make sense to build docker images for both tester and IUT
(osmo-stp in cases of M3UA/SUA tests, openggsn in case of ggsn tests)?
Running both in docker containers attached to the same (internal,
non-routed/public) network allows the processes to talk to each other
without interfering the build host networking in any way, so it
seemed like a convenient choice.
Whether or not it makes sense to update both the tester and IUT
container in a single jenkins job - I'm not sure. Any ideas?
2) trigger. So far I went for the nightly trigger at ~ 4am GMT. This
is sufficient for now, but it could of course be triggered by polling
git of both the tester and the IUT.
3) version information. I would like to get proper version information
into jenkins, so we don't just know "nightly test on day X" but see
on the jenkins Web UI which particular git version of IUT (and
tester) was tested. Any help appreciated!
4) archiving logs. It would be great to keep the logs of not only the
last test execution around. Sure, jenkins has stdout (of the tester)
and junit-xml (of the tester). But things like the log file
generated by the IUT is currently only present for the last test
execution. Any help appreciated!
I'm currently wokring on docker images for osmo-sgsn, osmo-nitb,
osmo-bts-virt and virtphy, so we can extend above-mentioned setup
to cover also the 'sysinfo + nitb vty' as well as the lapdm and pcu
tests that I wrote in TTCN-3.
After that, I plan to direct my attention more to the development of
more test casese in those respective test suites, rather than optimizing
the Jenkins integration.
Any help both with more test cases as well as jenkins would be much
appreciated. I think the hard part has been creating the entire
toolchain and access to the various interfaces (Gp, Gb, Um, VTY, ...)
and now it should be rather easy to write more tests.
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)
Hi.
We're building nightly .deb over at
https://build.opensuse.org/project/monitor/network:osmocom:nightly for several distro
flavors including Ubuntu 16.10 which is already reached End of Life stage.
Shall we just drop such EoL distros from nightly builds?
--
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
In the current osmo-msc.git split-up effort that will render openbsc.git to be
legacy, there are a couple of very large commits on gerrit. In normal
circumstances, my comment to these would be: "split this up!"
The way they came to be was: for a long time we were developing features on
branches, with numerous separate small-sized commits. There were these problems
with that:
Many commits partly or fully reverted earlier commits. It doesn't make sense to
look at small and incomplete steps in wrong directions.
Rebasing this work onto recent developments became ludicrously cumbersome:
solved merge conflicts were re-appearing with near every single following small
commit, multiplying the effort for every little conflict resolution.
It was necessary to pull these commits together to fewer steps for conflict
resolution, but some refactorings were done in-between other back-and-forth
changes; combining patches by topics would also have been prohibitive effort.
The first step was thus to plain squash *all* into *one*. That is the current
state of the libvlr changes (already merged), mscsplit changes (being merged
now), IuCS (coming up) and AoIP+sigtran (coming up).
If it serves review, I am ready and willing to split these up into smaller
bits, but if we can avoid spending time on that by reviewing the commits as
whole, we can reduce time spent on cosmetics. The special nature of these
patches is that they do pretty much completely overhaul the internal wiring and
data structures: it makes sense to look at it as a whole and it's hard to pull
out separate changes that are orthogonal.
So though this should not be the default style of our commits, this is a
special situation. Do request a split up if you see a need. Otherwise we will
merge them in these large code bombs as a basis for further dev.
Thanks!
~N
Hi,
I have read that silent-calls in GSM can be used to make a call to a target MS and listen to it without having the target knowing it. Is this theoretically possible ? If yes, can it be done in OpenBSC ?
Hi Neels and Harald,
Is the problem related to an issue, reported by Max?
https://osmocom.org/issues/2386
As I already commented, there is one possible reason:
Currently, the conv_acc_sse.c is being compiled with
both -msse3 -msse4.1 CFLAGS. Some compilers (or different
versions) may use the msse4.1 instruction set to optimize
the whole byte code, even in the places where they are not
actually used. So, one possible solution is to separate the
conv_acc_sse.c to conv_acc_sse_3.c and conv_acc_sse_41.c,
and then compile them with -msse3 -msse4.1 flags respectively.
If I had some basic compile / check access to the build host,
I could check whether my assumption is correct.
With best regards,
Vadim Yanitskiy.
