OpenBSC February 2016

openbsc@lists.osmocom.org

20 participants
86 discussions

hnbgw should reconnect to CN
by Neels Hofmeyr 19 Feb '16

19 Feb '16

Hi list, during testing of OsmoCSCN, I find that osmo-hnbgw connects to the CN servers once, but when such a CN component restarts, no new connection is established. Sequence: - start hnbgw, which continuously tries to connect to CS and PS CN servers every five seconds (osmo-cscn and dummy-cn in my case). - start dummy-cn, hnbgw connects. - start osmo-cscn, hnbgw connects. - osmo-cscn segfaults ;) - hnbgw logs the disconnect - I restart osmo-cscn - but hnbgw never attempts to reconnect to osmo-cscn. - so I have to restart hnbgw, hnb-test and its VTY connection "all the time", which is cumbersome. I briefly tried to resolve the issue, but I'm losing patience. I tried to enable the DLINP debug logging but found that hnbgw's VTY doesn't allow me to manipulate logging levels, apparently. Next I'd have liked to set the hnbgw_log_info to indicate [DLINP] = { .loglevel = LOGL_DEBUG } but DLINP is negative. Does this really have to be as fiendish? I guess the INT2IDX() macro doesn't apply here, as it would cause index overlaps with the other D* constants. It can be really hard to find my way around the Osmo source code, with the little non-obvious things accumulating... I did find that much: the reconnect flag passed to osmo_stream_cli_open2() is effective only while state == STREAM_CLI_STATE_CONNECTING, i.e. until a first connection is established. Now, if upon disconnect, something were to set the state back to cli->state = STREAM_CLI_STATE_CONNECTING my guess is that the cli_timer_cb() would indeed attempt to reconnect as I intend. BTW, what does cli stand for? Not command-line interface, is it. If I stayed onto this I'd probably solve the issue. My focus should be on an IuCS Location Update though, so comments or help is appreciated :) So long I'll carry on with the workaround, restarting hnbgw "all the time". Thanks! ~Neels -- - 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: Holger Freyther, Harald Welte

3 4

osmo-iuh/src/regen-common-includes.sh
by Neels Hofmeyr 19 Feb '16

19 Feb '16

I noticed that osmo-iuh/src/regen-common-includes.sh doesn't do anything useful (anymore). Should it be redirected towards osmo-iuh/include or can we drop it? osmo-iuh/src/regen-common-includes.sh: [[[ #!/bin/sh #for f in `(cd ../asn1/hnbap/asn1c && ls --color=none -1 *.h)`; do echo "#include \"$f\""; done for f in ranap/*.h; do echo "#include \"$f\""; done ]]] Thanks ~Neels -- - 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: Holger Freyther, Harald Welte

2 1

hnb_cs_lu.msc
by Neels Hofmeyr 17 Feb '16

17 Feb '16

Hi Harald, in osmo-iuh/doc/hnb_cs_lu.msc I find that after the location update request from the UE, an identity request "should" follow from the CN. Yesterday I made my first pcap using our hNodeB and that weighty black UE we use for testing, and saw that the MSC indeed sends out an identity request at that time [1], however, the UE simply never responds to it. My question: is the hnb_cs_lu.msc declarative and definitely correct, or could it be that in 3G, UEs in general expect authentication first, as the "osmo-iuh/pcap/UPP RANAP.pcap" suggests (starting at packet #335). Since my sources tell me (i.e. Daniel) that an identity request at that time is indeed kinda special practise by openbsc to collect all IMEIs we possibly can, I'm going for authentication first. Just wanted to make sure you agree that the hnb_cs_lu.msc may be erratic in that case. Thanks! ~Neels [1] near openbsc/src/libmsc/gsm_04_08.c:589 (thanks Daniel!) -- - 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: Holger Freyther, Harald Welte

2 2

Re: autoreconf v2.69 with subdir-objects: ./configure creates directory 'src/tests/\$(top_srcdir)'
by Neels Hofmeyr 17 Feb '16

17 Feb '16

Dear autoconf, I have received no reply yet, so am taking the liberty to <bump>. BTW, is there a way to verify that this report has reached someone, besides waiting for an email reply? Thanks! ~Neels On Thu, Jan 14, 2016 at 02:40:38PM +0100, Neels Hofmeyr wrote: > Dear autoconf, > > I am observing a bug with `autoreconf -i`. > To my/our knowledge, this is not due to an error in > our configuration but a genuine bug from 'subdir-objects'. > > The symptom: after running ./configure, I find a directory > src/tests/\$(top_srcdir) > > (The string that looks like a variable that is to be expanded is written to the > file system in verbatim, as the directory name.) > > The weird dir contains only a .deps dir with dependency files for the src/* > files (not for src/tests/* files as one might expect). > > If I remove 'subdir-objects' from configure.ac, the weird dir is not created. > > > Reproduction recipe on debian stable: > > ▶ autoreconf --version > autoreconf (GNU Autoconf) 2.69 > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+/Autoconf: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Written by David J. MacKenzie and Akim Demaille. > > > ▶ git clone git://git.osmocom.org/osmo-iuh > Cloning into 'osmo-iuh'... > remote: Counting objects: 5945, done. > remote: Compressing objects: 100% (2661/2661), done. > remote: Total 5945 (delta 4991), reused 3757 (delta 3228) > Receiving objects: 100% (5945/5945), 12.11 MiB | 8.97 MiB/s, done. > Resolving deltas: 100% (4991/4991), done. > Checking connectivity... done. > > ▶ cd osmo-iuh/ > > ▶ sed -i 's/^PKG_/dnl &/' configure.ac > > ▶ autoreconf -i > aclocal: warning: couldn't open directory 'm4': No such file or directory > libtoolize: putting auxiliary files in `.'. > libtoolize: copying file `./ltmain.sh' > libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. > libtoolize: copying file `m4/libtool.m4' > libtoolize: copying file `m4/ltoptions.m4' > libtoolize: copying file `m4/ltsugar.m4' > libtoolize: copying file `m4/ltversion.m4' > libtoolize: copying file `m4/lt~obsolete.m4' > libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. > configure.ac:5: installing './compile' > configure.ac:5: installing './config.guess' > configure.ac:5: installing './config.sub' > configure.ac:7: installing './install-sh' > configure.ac:7: installing './missing' > src/Makefile.am: installing './depcomp' > > ▶ ./configure > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking how to print strings... printf > checking for gcc... gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking whether gcc understands -c and -o together... yes > checking for a sed that does not truncate output... /bin/sed > checking for grep that handles long lines and -e... /bin/grep > checking for egrep... /bin/grep -E > checking for fgrep... /bin/grep -F > checking for ld used by gcc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B > checking the name lister (/usr/bin/nm -B) interface... BSD nm > checking whether ln -s works... yes > checking the maximum length of command line arguments... 1572864 > checking whether the shell understands some XSI constructs... yes > checking whether the shell understands "+="... yes > checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop > checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop > checking for /usr/bin/ld option to reload object files... -r > checking for objdump... objdump > checking how to recognize dependent libraries... pass_all > checking for dlltool... no > checking how to associate runtime and link libraries... printf %s\n > checking for ar... ar > checking for archiver @FILE support... @ > checking for strip... strip > checking for ranlib... ranlib > checking for gawk... no > checking for mawk... mawk > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for sysroot... no > checking for mt... mt > checking if mt is a manifest tool... no > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking for dlfcn.h... yes > checking for objdir... .libs > checking if gcc supports -fno-rtti -fno-exceptions... no > checking for gcc option to produce PIC... -fPIC -DPIC > checking if gcc PIC flag -fPIC -DPIC works... yes > checking if gcc static flag -static works... yes > checking if gcc supports -c -o file.o... yes > checking if gcc supports -c -o file.o... (cached) yes > checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... yes > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... /bin/mkdir -p > checking whether make sets $(MAKE)... yes > checking for style of include used by make... GNU > checking whether make supports nested variables... yes > checking dependency style of gcc... gcc3 > checking whether make supports nested variables... (cached) yes > checking whether make sets $(MAKE)... (cached) yes > checking for gcc... (cached) gcc > checking whether we are using the GNU C compiler... (cached) yes > checking whether gcc accepts -g... (cached) yes > checking for gcc option to accept ISO C89... (cached) none needed > checking whether gcc understands -c and -o together... (cached) yes > checking for ANSI C header files... (cached) yes > checking that generated files are newer than configure... done > configure: creating ./config.status > config.status: creating libosmo-ranap.pc > config.status: creating src/Makefile > config.status: creating src/hnbap/Makefile > config.status: creating src/ranap/Makefile > config.status: creating src/rua/Makefile > config.status: creating src/tests/Makefile > config.status: creating Makefile > config.status: creating include/Makefile > config.status: creating include/osmocom/Makefile > config.status: creating include/osmocom/hnbap/Makefile > config.status: creating include/osmocom/ranap/Makefile > config.status: creating include/osmocom/rua/Makefile > config.status: executing libtool commands > config.status: executing depfiles commands > config.status: executing src/tests/atconfig commands > > ▶ ls -F src/tests/ > atconfig Makefile test_common.h test-hnbap.ok $(top_srcdir)/ > dummy_cn_sua.c Makefile.am test-helpers.c test-ranap.c > hnb-test.c Makefile.in test-helpers.ok test-ranap.ok > hnb-test.h test_common.c test-hnbap.c testsuite.at > > > Observe '$(top_srcdir)/' in file listing. > > > ▶ ls -aR src/tests/\$$top_srcdir$/ > src/tests/$(top_srcdir)/: > ./ ../ src/ > > src/tests/$(top_srcdir)/src: > ./ ../ .deps/ > > src/tests/$(top_srcdir)/src/.deps: > ./ hnbap_common.Po hnbap_encoder.Po rua_decoder.Po rua_msg_factory.Po > ../ hnbap_decoder.Po rua_common.Po rua_encoder.Po > > > > Please excuse my not trying to verify the bug with the latest sources. To my > knowledge, this bug applies to the latest released version (2.69) and I hope it > will not be an effort to you if the bug is already known to be fixed. > > Thank you for your time! > > ~Neels > > (I am not subscribed to any autoconf ML, hence a Cc to my sender address is > appreciated) -- - 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: Holger Freyther, Harald Welte

2 2

libasn1c config.h
by Neels Hofmeyr 17 Feb '16

17 Feb '16

Hi, you may be aware that the '#include "config.h"' in libasn1c's asn_system.h breaks builds with the out-of-the-box 'make install'. So far we go to the installed header and remove that line. This time I've removed the line from the source tree before building, and I can't find any effect really. My source tree has no config.h file to begin with. But I'm not sure what would be a point of failure there. When I commit this, will I break something I merely happen to not be using? Any autoconf guru here that could resolve this with a quick glance? http://git.osmocom.org/libasn1c/tree/configure.ac http://git.osmocom.org/libasn1c/tree/include/asn1c/asn_system.h Thanks, ~Neels -- - 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: Holger Freyther, Harald Welte

2 2

Re: Query regarding GTP-U code implementation in upstream linux kernel
by Andreas Schultz 16 Feb '16

16 Feb '16

Hi Niti, On 02/16/2016 08:53 AM, Niti Rohilla wrote: > Hi All, > > I want to enable GTP-U in OpenVswitch. I have implemented the code for the GTP-U in ovs and submitted the same on ovs-dev. > > As currently, GTP-U support is not available in upstream linux kernel, so to create a GTP port in ovs we have to load the openvswitch kernel > module to linux kernel. > > I have received some review comments stating that first I have to implement the code for GTP-U in upstream linux kernel in netdev net-next > tree then it can be incorporated into ovs. > > I want to know the process of how to implement and get the code for GTP-U into upstream linux kernel. > > If anybody is working on the same how can I help them to get it in into the upstream linux kernel quickly. I'm a bit out of touch with OVS, so my idea on how this should work might be wrong. As far as I understand OVS, the way forward would be to use the lwtunnel infrastructure to enable OVS to use a kernel GTP module. Our current OVS module ([1], [2]) is not (yet) using lwtunnel, but we do plan on switching to that. So far, we have been coordinating the GTP kernel module development on the OpenBSC ML [3]. The goal is to upstream it as soon as all the basics are covered (smallish netlink API changes, final touches on IPv6 and maybe lwtunnel). On the OVS side, someone would then need to implement the necessary ops to handle GTP lwtunnel integration. Andreas [1]: http://git.osmocom.org/osmo-gtp-kernel [2]: https://github.com/RoadRunnr/osmo-ggsn [3]: https://lists.osmocom.org/mailman/listinfo/openbsc > > > Thanks & Regards > Niti Rohilla > > =====-----=====-----===== > Notice: The information contained in this e-mail > message and/or attachments to it may contain > confidential or privileged information. If you are > not the intended recipient, any dissemination, use, > review, distribution, printing or copying of the > information contained in this e-mail message > and/or attachments to it are strictly prohibited. If > you have received this communication in error, > please notify us by reply e-mail or telephone and > immediately and permanently delete the message > and any attachments. Thank you >

1 0

MSC split: is_siemens_bts() in libmsc/gsm_04_08.c / conn->bts vs. lchan->ts->trx->bts
by Neels Hofmeyr 15 Feb '16

15 Feb '16

I'm trying to get rid of all BTS backpointers in libmsc. In libmsc/gsm_04_08.c, in gsm48_rx_mm_serv_req(), I find: if (is_siemens_bts(bts)) send_siemens_mrpci(msg->lchan, classmark2-1); My conclusion so far is that this "hook" should move to the BSC code, but I could use some comforting approval by more apt contenders... Some detail: send_siemens_mrpci() is found in libbsc/gsm_04_08_utils.c: int send_siemens_mrpci(struct gsm_lchan *lchan, uint8_t *classmark2_lv) { struct rsl_mrpci mrpci; if (classmark2_lv[0] < 2) return -EINVAL; mrpci.power_class = classmark2_lv[1] & 0x7; mrpci.vgcs_capable = classmark2_lv[2] & (1 << 1); mrpci.vbs_capable = classmark2_lv[2] & (1 <<2); mrpci.gsm_phase = (classmark2_lv[1]) >> 5 & 0x3; return rsl_siemens_mrpci(lchan, &mrpci); } IIUC the Siemens BS11 BTS needs to be tickled with a vendor-specific RSL message as soon as a CM service request (GSM48_MT_MM_CM_SERV_REQ) or a paging response is received from a subscriber. Only the BSC knows which BTS is involved, so I'd try to find some place in libbsc/ or osmo-bsc/ to move this away to. The same function is called from gsm48_handle_paging_resp() in libbsc. Any shortcuts / workarounds or could this also be dropped entirely? It does look like that particular case is indeed missing from osmo-bsc. Who is this Mister PCI anyway? ;) The gsm48_handle_paging_resp() function leads me to another, more general question: often, there are two bts pointers around, namely the gsm_subscriber_connection->bts as well as the lchan->ts->trx->bts Are these typically/always/never expected to be the same bts struct? (In this function, both bts pointers are used, and I'd like to understand why.) Thanks! ~Neels -- - 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: Holger Freyther, Harald Welte

3 4

Patch to make openbsc find libsmpp34
by Ruben Undheim 15 Feb '16

15 Feb '16

Hi, This patch lets the build script for openbsc find the libsmpp34 installation with the help of pkg-config instead of assuming the header files are in /usr/include. diff --git a/openbsc/src/libmsc/Makefile.am b/openbsc/src/libmsc/Makefile.am index 18bfa0c..5195890 100644 --- a/openbsc/src/libmsc/Makefile.am +++ b/openbsc/src/libmsc/Makefile.am @@ -1,6 +1,6 @@ AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir) AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOVTY_CFLAGS) \ - $(LIBOSMOABIS_CFLAGS) $(COVERAGE_CFLAGS) $(LIBCRYPTO_CFLAGS) + $(LIBOSMOABIS_CFLAGS) $(COVERAGE_CFLAGS) $(LIBCRYPTO_CFLAGS) $(LIBSMPP34_CFLAGS) noinst_HEADERS = meas_feed.h diff --git a/openbsc/src/utils/Makefile.am b/openbsc/src/utils/Makefile.am index f6255a0..4521130 100644 --- a/openbsc/src/utils/Makefile.am +++ b/openbsc/src/utils/Makefile.am @@ -1,5 +1,6 @@ AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir) -AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(LIBOSMOABIS_CFLAGS) $(COVERAGE_CFLAGS) $(SQLITE3_CFLAGS) +AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(LIBOSMOABIS_CFLAGS) $(COVERAGE_CFLAGS) $(SQLITE3_CFLAGS) \ + $(LIBSMPP34_CFLAGS) AM_LDFLAGS = $(COVERAGE_LDFLAGS) noinst_HEADERS = meas_db.h diff --git a/openbsc/tests/smpp/Makefile.am b/openbsc/tests/smpp/Makefile.am index 06e7af6..9ab15c5 100644 --- a/openbsc/tests/smpp/Makefile.am +++ b/openbsc/tests/smpp/Makefile.am @@ -1,5 +1,5 @@ AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_srcdir)/src/libmsc -AM_CFLAGS=-Wall -ggdb3 $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBOSMOSCCP_CFLAGS) $(LIBOSMOABIS_CFLAGS) $(COVERAGE_CFLAGS) +AM_CFLAGS=-Wall -ggdb3 $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBOSMOSCCP_CFLAGS) $(LIBOSMOABIS_CFLAGS) $(COVERAGE_CFLAGS) $(LIBSMPP34_CFLAGS) AM_LDFLAGS = $(COVERAGE_LDFLAGS) EXTRA_DIST = smpp_test.ok smpp_test.err It is needed if building with the debian package for libsmpp34. Best regards, Ruben

1 0

EDGE over osmo-pcu
by Jacob Erlbeck 14 Feb '16

14 Feb '16

Hi everybody, we have just done the first download of an Internet page using the current bleeding EDGE development version of the OSMO-PCU. Supported are MCS-1 to MCS-9 in downlink and MCS-1 to MCS-4 in uplink direction. The download of 'www.osmocom.org' has been documented in a PCAP file and can be downloaded from https://openbsc.osmocom.org/trac/wiki/osmo-pcu To decode the data blocks, an experimental patch for the gsmtab dissector is also available from there. Cheers Jacob -- - Jacob Erlbeck <jerlbeck(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: Holger Freyther, Harald Welte

4 8

libosmocore does not build in Ubuntu
by Ruben Undheim 12 Feb '16

12 Feb '16

Hi, Can someone here help me debug the failing build of libosmocore in Ubuntu? See: https://launchpadlibrarian.net/235791225/buildlog_ubuntu-xenial-amd64.libos… The test case "gprs-bssgp" fails with following output: stderr: MESSAGE to 0x7f0000ff, msg length 12 02 00 81 01 01 82 0b 56 04 82 0b 55 All NS-VCs for NSEI 2901 are either dead or blocked! All NS-VCs for NSEI 2901 are either dead or blocked! BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified BSSGP BVCI=1234 Rx BVC STATUS, cause=Unknown BVCI NSEI=2901/BVCI=2989 Cannot handle PDU type 34 for unknown BVCI, NS BVCI 2989 Unable to resolve NSEI 4660 to NS-VC! Assert failed rc >= 0 gb/gprs_bssgp_test.c:234 I think it is related to the hardening option "-D_FORTIFY_SOURCE=2". What is interesting is that it builds correctly in Debian, but not Ubuntu. The issue has apparently been observed before: http://comments.gmane.org/gmane.comp.mobile.osmocom.baseband.devel/4149 If this gets fixed quickly, it might go into the next Ubuntu LTS version which has import freeze Feb 18th. Cheers, Ruben

2 7

← Newer
1
2
3
4
5
6
7
8
9
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC February 2016