OpenBSC

openbsc@lists.osmocom.org

20 participants
4286 discussions

[PATCH] Extend L1SAP PH-DATA with presence information
by msuraev＠sysmocom.de 20 Feb '16

20 Feb '16

From: Max <msuraev(a)sysmocom.de> Previously the presence of header and data blocks were communicated in-band which decreases code readability and makes it unnecessary hard to add support for new hardware. Note: both OsmoBTS and OsmoPCU have to be modified to take advantage of extended ph_data_param structure. --- include/osmocom/gsm/l1sap.h | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/include/osmocom/gsm/l1sap.h b/include/osmocom/gsm/l1sap.h index 9f3fe98..1af8ba8 100644 --- a/include/osmocom/gsm/l1sap.h +++ b/include/osmocom/gsm/l1sap.h @@ -25,6 +25,16 @@ enum osmo_mph_info_type { PRIM_INFO_DEACT_CIPH, /*!< \brief Deactivation of ciphering */ }; +/*! \brief PH-DATA presence information */ +enum osmo_ph_pres_info_type { + PRES_INFO_INVALID = 0, /*!< \brief Data is invalid */ + PRES_INFO_HEADER = 1, /*!< \brief Only header is present and valid */ + PRES_INFO_FIRST = 3, /*!< \brief First half of data + header are valid (2nd half may be present but invalid) */ + PRES_INFO_SECOND = 5, /*!< \brief Second half of data + header are valid (1st halfmay be present but invalid) */ + PRES_INFO_BOTH = 7, /*!< \brief Both parts + header are present and valid */ + PRES_INFO_UNKNOWN +}; + /*! \brief for PH-RANDOM_ACCESS.req */ struct ph_rach_req_param { uint8_t ra; /*!< \brief Random Access */ @@ -48,6 +58,7 @@ struct ph_data_param { uint8_t chan_nr; /*!< \brief Channel Number (Like RSL) */ uint32_t fn; /*!< \brief GSM Frame Number */ int8_t rssi; /*!< \brief RSSI of receivedindication */ + enum osmo_ph_pres_info_type pdch_presence_info; /*!< \brief Info regarding presence/validity of header and data parts */ }; /*! \brief for TCH.{req,ind} | TCH-RTS.ind */ -- 2.7.1

3 2

[PATCH 1/3] Ignore files generated by cscope tool
by msuraev＠sysmocom.de 20 Feb '16

20 Feb '16

From: Max <msuraev(a)sysmocom.de> Signed-off-by: Max <msuraev(a)sysmocom.de> --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 6cc9aa5..a22fd4f 100644 --- a/.gitignore +++ b/.gitignore @@ -5,6 +5,7 @@ Makefile.in Makefile .deps +src/cscope* aclocal.m4 autom4te.cache -- 2.7.1

2 3

[PATCH] Fix OsmoPCU integration
by msuraev＠sysmocom.de 20 Feb '16

20 Feb '16

From: Max <msuraev(a)sysmocom.de> Add support for explicitly passing PH-DATA presence info. Remove in-band passing of presence information and replace corresponding check. This also fixes integration between Octasic BTS hw and OsmoPCU: previously osmo-bts-octphy have not provided in-band presence information which cause off-by-one errors and misinterpretation of ph_data_ind by PCU. Note: this requires libosmocore version with osmo_ph_pres_info_type support integrated. --- include/osmo-bts/scheduler_backend.h | 2 +- src/common/l1sap.c | 5 +++-- src/common/scheduler.c | 3 ++- src/osmo-bts-octphy/l1_if.c | 1 + src/osmo-bts-trx/scheduler_trx.c | 16 +++++++--------- 5 files changed, 14 insertions(+), 13 deletions(-) diff --git a/include/osmo-bts/scheduler_backend.h b/include/osmo-bts/scheduler_backend.h index 9f663cd..1614250 100644 --- a/include/osmo-bts/scheduler_backend.h +++ b/include/osmo-bts/scheduler_backend.h @@ -42,7 +42,7 @@ struct msgb *_sched_dequeue_prim(struct l1sched_trx *l1t, int8_t tn, uint32_t fn enum trx_chan_type chan); int _sched_compose_ph_data_ind(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, - enum trx_chan_type chan, uint8_t *l2, uint8_t l2_len, float rssi); + enum trx_chan_type chan, uint8_t *l2, uint8_t l2_len, float rssi, enum osmo_ph_pres_info_type presence_info); int _sched_compose_tch_ind(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, enum trx_chan_type chan, uint8_t *tch, uint8_t tch_len); diff --git a/src/common/l1sap.c b/src/common/l1sap.c index 8056034..ac398d3 100644 --- a/src/common/l1sap.c +++ b/src/common/l1sap.c @@ -744,6 +744,7 @@ static int l1sap_ph_data_ind(struct gsm_bts_trx *trx, uint8_t tn; uint32_t fn; int8_t rssi; + enum osmo_ph_pres_info_type pr_info = data_ind->pdch_presence_info; rssi = data_ind->rssi; chan_nr = data_ind->chan_nr; @@ -767,11 +768,11 @@ static int l1sap_ph_data_ind(struct gsm_bts_trx *trx, return 0; } /* drop incomplete UL block */ - if (data[0] != 7) + if (pr_info != PRES_INFO_BOTH) return 0; /* PDTCH / PACCH frame handling */ pcu_tx_data_ind(&trx->ts[tn], 0, fn, 0 /* ARFCN */, - L1SAP_FN2MACBLOCK(fn), data + 1, len - 1, rssi); + L1SAP_FN2MACBLOCK(fn), data, len, rssi); return 0; } diff --git a/src/common/scheduler.c b/src/common/scheduler.c index e9d2423..07c2e12 100644 --- a/src/common/scheduler.c +++ b/src/common/scheduler.c @@ -268,7 +268,7 @@ found_msg: } int _sched_compose_ph_data_ind(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, - enum trx_chan_type chan, uint8_t *l2, uint8_t l2_len, float rssi) + enum trx_chan_type chan, uint8_t *l2, uint8_t l2_len, float rssi, enum osmo_ph_pres_info_type presence_info) { struct msgb *msg; struct osmo_phsap_prim *l1sap; @@ -284,6 +284,7 @@ int _sched_compose_ph_data_ind(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, l1sap->u.data.link_id = trx_chan_desc[chan].link_id; l1sap->u.data.fn = fn; l1sap->u.data.rssi = (int8_t) (rssi); + l1sap->u.data.pdch_presence_info = presence_info; msg->l2h = msgb_put(msg, l2_len); if (l2_len) memcpy(msg->l2h, l2, l2_len); diff --git a/src/osmo-bts-octphy/l1_if.c b/src/osmo-bts-octphy/l1_if.c index 3215aa1..781d589 100644 --- a/src/osmo-bts-octphy/l1_if.c +++ b/src/osmo-bts-octphy/l1_if.c @@ -1032,6 +1032,7 @@ static int handle_ph_data_ind(struct octphy_hdl *fl1, l1sap->u.data.chan_nr = chan_nr; l1sap->u.data.fn = fn; l1sap->u.data.rssi = rssi; + l1sap->u.data.pdch_presence_info = PRES_INFO_BOTH; /* FIXME: consider EDGE support */ l1sap_up(trx, l1sap); diff --git a/src/osmo-bts-trx/scheduler_trx.c b/src/osmo-bts-trx/scheduler_trx.c index 15c05e8..243539d 100644 --- a/src/osmo-bts-trx/scheduler_trx.c +++ b/src/osmo-bts-trx/scheduler_trx.c @@ -190,7 +190,7 @@ got_msg: l1if_process_meas_res(l1t->trx, tn, fn, trx_chan_desc[chan].chan_nr | tn, 456, 456, -110, 0); - _sched_compose_ph_data_ind(l1t, tn, 0, chan, NULL, 0, -110); + _sched_compose_ph_data_ind(l1t, tn, 0, chan, NULL, 0, -110, PRES_INFO_INVALID); } } @@ -841,7 +841,7 @@ int rx_data_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, l1if_process_meas_res(l1t->trx, tn, fn, trx_chan_desc[chan].chan_nr | tn, n_errors, n_bits_total, *rssi_sum / *rssi_num, *toa_sum / *toa_num); - return _sched_compose_ph_data_ind(l1t, tn, *first_fn, chan, l2, l2_len, *rssi_sum / *rssi_num); + return _sched_compose_ph_data_ind(l1t, tn, *first_fn, chan, l2, l2_len, *rssi_sum / *rssi_num, PRES_INFO_UNKNOWN); } int rx_pdtch_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, @@ -856,7 +856,7 @@ int rx_pdtch_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, uint8_t *rssi_num = &chan_state->rssi_num; float *toa_sum = &chan_state->toa_sum; uint8_t *toa_num = &chan_state->toa_num; - uint8_t l2[54+1]; + uint8_t l2[54]; int n_errors, n_bits_total; int rc; @@ -906,7 +906,7 @@ int rx_pdtch_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, *mask = 0x0; /* decode */ - rc = pdtch_decode(l2 + 1, *bursts_p, NULL, &n_errors, &n_bits_total); + rc = pdtch_decode(l2, *bursts_p, NULL, &n_errors, &n_bits_total); /* Send uplnk measurement information to L2 */ l1if_process_meas_res(l1t->trx, tn, fn, trx_chan_desc[chan].chan_nr | tn, @@ -919,10 +919,8 @@ int rx_pdtch_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, return 0; } - l2[0] = 7; /* valid frame */ - return _sched_compose_ph_data_ind(l1t, tn, (fn + GSM_HYPERFRAME - 3) % GSM_HYPERFRAME, chan, - l2, rc + 1, *rssi_sum / *rssi_num); + l2, rc + 1, *rssi_sum / *rssi_num, PRES_INFO_BOTH); } int rx_tchf_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, @@ -1038,7 +1036,7 @@ int rx_tchf_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, /* FACCH */ if (rc == GSM_MACBLOCK_LEN) { _sched_compose_ph_data_ind(l1t, tn, (fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME, chan, - tch_data + amr, GSM_MACBLOCK_LEN, rssi); + tch_data + amr, GSM_MACBLOCK_LEN, rssi, PRES_INFO_UNKNOWN); bfi: if (rsl_cmode == RSL_CMOD_SPD_SPEECH) { /* indicate bad frame */ @@ -1204,7 +1202,7 @@ int rx_tchh_fn(struct l1sched_trx *l1t, uint8_t tn, uint32_t fn, chan_state->ul_ongoing_facch = 1; _sched_compose_ph_data_ind(l1t, tn, (fn + GSM_HYPERFRAME - 10 - ((fn % 26) >= 19)) % GSM_HYPERFRAME, chan, - tch_data + amr, GSM_MACBLOCK_LEN, rssi); + tch_data + amr, GSM_MACBLOCK_LEN, rssi, PRES_INFO_UNKNOWN); bfi: if (rsl_cmode == RSL_CMOD_SPD_SPEECH) { /* indicate bad frame */ -- 2.7.1

1 0

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 18 Feb '16

18 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 18 Feb '16

18 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC