From gerrit-no-reply at lists.osmocom.org Wed Jun 1 06:24:29 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 06:24:29 +0000 Subject: [PATCH] libosmocore[master]: Add Finite State Machine abstraction code Message-ID: Review at https://gerrit.osmocom.org/163 Add Finite State Machine abstraction code This code is supposed to formalize some of the state machine handling in Osmocom code. Change-Id: I0b0965a912598c1f6b84042a99fea9d522642466 --- M include/Makefile.am A include/osmocom/core/fsm.h M src/Makefile.am A src/fsm.c M tests/Makefile.am A tests/fsm/fsm_test.c A tests/fsm/fsm_test.err M tests/testsuite.at 8 files changed, 546 insertions(+), 3 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/63/163/1 diff --git a/include/Makefile.am b/include/Makefile.am index 2e58d7e..b775c9f 100644 --- a/include/Makefile.am +++ b/include/Makefile.am @@ -17,6 +17,7 @@ osmocom/core/crcgen.h \ osmocom/core/endian.h \ osmocom/core/defs.h \ + osmocom/core/fsm.h \ osmocom/core/gsmtap.h \ osmocom/core/gsmtap_util.h \ osmocom/core/linuxlist.h \ diff --git a/include/osmocom/core/fsm.h b/include/osmocom/core/fsm.h new file mode 100644 index 0000000..0e6a372 --- /dev/null +++ b/include/osmocom/core/fsm.h @@ -0,0 +1,87 @@ +#pragma once + +#include + +#include +#include +#include + +/*! \defgroup fsm Finite State Machine abstraction + * @{ + */ + +/*! \file fsm.h + * \brief Finite State Machine + */ + +struct osmo_fsm_inst; + +/*! \brief description of a rule in the FSM */ +struct osmo_fsm_state { + /*! \brief bit-mask of permitted input events for this state */ + uint32_t in_event_mask; + /*! \brief bit-mask to which other states this state may transiton */ + uint32_t out_state_mask; + /*! \brief human-readable name of this state */ + const char *name; + /*! \brief function pointer to be called for this state */ + void (*action)(struct osmo_fsm_inst *fi, uint32_t event, void *data); +}; + +/*! \brief a description of an osmocom finite state machine */ +struct osmo_fsm { + /*! \brief global list */ + struct llist_head list; + /*! \brief list of instances of this FSM */ + struct llist_head instances; + /*! \brief human readable name */ + const char *name; + /*! \brief table of state transition rules */ + struct osmo_fsm_state *states; + /*! \brief bit-mask of events permitted in all states */ + uint32_t allstate_event_mask; + /*! \brief function pointer to be called for allstate events */ + void (*allstate_action)(struct osmo_fsm_inst *fi, uint32_t event, void *data); + /*! \brief number of entries in \ref states */ + unsigned int num_states; + /*! \brief logging sub-system for this FSM */ + int log_subsys; + /*! \brief human-readable names of events */ + const struct value_string *event_names; +}; + +/*! \brief a single instanceof an osmocom finite state machine */ +struct osmo_fsm_inst { + /*! \brief member in the fsm->instances list */ + struct llist_head list; + /*! \brief back-pointer to the FSM of which we are an instance */ + struct osmo_fsm *fsm; + /*! \brief human readable name */ + const char *name; + /*! \brief some private data of this instance */ + void *priv; + /*! \brief logging level for this FSM */ + int log_level; + /*! \brief current state of the FSM */ + uint32_t state; + + /*! \brief timer call-back for states with time-out */ + void (*timer_cb)(struct osmo_fsm_inst *fi); + /*! \brief timer number for states with time-out */ + int T; + /*! \brief timer back-end for states with time-out */ + struct osmo_timer_list timer; +}; + +struct osmo_fsm_inst *osmo_fsm_inst_alloc(struct osmo_fsm *fsm, void *ctx, void *priv, + int log_level); +void osmo_fsm_inst_free(struct osmo_fsm_inst *fi); +const char *osmo_fsm_event_name(struct osmo_fsm *fsm, uint32_t event); +const char *osmo_fsm_inst_name(struct osmo_fsm_inst *fi); +const char *osmo_fsm_state_name(struct osmo_fsm *fsm, uint32_t state); +int osmo_fsm_inst_state_chg(struct osmo_fsm_inst *fi, uint32_t new_state, + unsigned long timeout_secs, int T); +int osmo_fsm_dispatch(struct osmo_fsm_inst *fi, uint32_t event, void *data); +int osmo_fsm_register(struct osmo_fsm *fsm); + +/*! @} */ diff --git a/src/Makefile.am b/src/Makefile.am index 45a77e3..7a6f464 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -9,7 +9,7 @@ libosmocore_la_LIBADD = $(BACKTRACE_LIB) $(TALLOC_LIBS) libosmocore_la_SOURCES = timer.c select.c signal.c msgb.c bits.c \ - bitvec.c bitcomp.c statistics.c \ + bitvec.c bitcomp.c statistics.c fsm.c \ write_queue.c utils.c socket.c \ logging.c logging_syslog.c rate_ctr.c \ gsmtap_util.c crc16.c panic.c backtrace.c \ diff --git a/src/fsm.c b/src/fsm.c new file mode 100644 index 0000000..10be332 --- /dev/null +++ b/src/fsm.c @@ -0,0 +1,283 @@ +/* Osmocom generic Finite State Machine implementation + * + * (C) 2016 by Harald Welte + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301, USA. + */ + +#include + +#include +#include +#include +#include + +/*! \addtogroup fsm + * @{ + */ + +/*! \file fsm.c + * \brief Finite State Machine abstraction + * + * This is a generic C-language abstraction for implementing finite + * state machines within the Osmocom framework. It is intended to + * replace existing hand-coded or even only implicitly existing FSMs + * all over the existing code base. + * + * An libosmocore FSM is described by its \ref osmo_fsm description, + * which in turn refers to an array of \ref osmo_fsm_state descriptor, + * each describing a single state in the FSM. + * + * The general idea is that all actions performed within one state are + * located at one position in the code (the state's action function), + * as opposed to the 'message-centric' view of e.g. the existing + * state machines of the LAPD(m) coe, where there is one message for + * eahc possible event (primitive), and the function then needs to + * concern itself on how to handle that event over all possible states. + * + * For each state, there is a bit-mask of permitted input events for + * this state, as well as a bit-mask of permitted new output states to + * which the state can change. Furthermore, there is a function + * pointer implementing the actual handling of the input events. + * + * As there can often be many concurrent FSMs of one given class, we + * introduce the concept of \ref osmo_fsm_inst, i.e. an FSM instance. + * The instance keeps the actual state, while the \ref osmo_fsm + * descriptor contains the static/const descriptor of the FSM's states + * and possible transitions. + * + * osmo_fsm are integrated with the libosmocore logging system. The + * logging sub-system is determined by the FSM descriptor, as we assume + * one FSM (let's say one related to a location update procedure) is + * inevitably always tied to a sub-system. The logging level however + * is configurable for each FMS instance, to ensure that e.g. DEBUG + * logging can be used for the LU procedure of one subscriber, while + * NOTICE level is used for all other subscribers. + */ + +static LLIST_HEAD(g_fsms); + +/*! \brief register a FSM with the core + * + * A FSM descriptor needs to be registered with the core before any + * instances can be created for it. + * + * \param[in] fsm Descriptor of Finite State Machine to be registered + * \returns 0 on success; negative on error + */ +int osmo_fsm_register(struct osmo_fsm *fsm) +{ + /* FIXME:check for duplicate name? */ + llist_add_tail(&fsm->list, &g_fsms); + INIT_LLIST_HEAD(&fsm->instances); + + return 0; +} + +/*! \brief unregister a FSM from the core + * + * Once the FSM descriptor is unregistered, active instances can still + * use it, but no new instances may be created for it. + * + * \param[in] fsm Descriptor of Finite State Machine to be removed + */ +void osmo_fsm_unregister(struct osmo_fsm *fsm) +{ + llist_del(&fsm->list); +} + +/* small wrapper function around timer expiration (for logging) */ +static void fsm_tmr_cb(void *data) +{ + struct osmo_fsm_inst *fi = data; + struct osmo_fsm *fsm = fi->fsm; + + LOGP(fsm->log_subsys, fi->log_level, "%s(%s): Timeout of T%u\n", + osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), fi->T); + + fi->timer_cb(fi); +} + +/*! \brief allocate a new instance of a specified FSM + * \param[in] fsm Descriptor of the FSM + * \param[in] ctx talloc context from which to allocate memory + * \param[in] priv private data reference store in fsm instance + * \param[in] log_level The log level for events of this FSM + * \returns newly-allocated, initialized and registered FSM instance + */ +struct osmo_fsm_inst *osmo_fsm_inst_alloc(struct osmo_fsm *fsm, void *ctx, void *priv, + int log_level) +{ + struct osmo_fsm_inst *fi = talloc_zero(ctx, struct osmo_fsm_inst); + fi->fsm = fsm; + fi->priv = priv; + fi->log_level = log_level; + fi->timer.data = fi; + fi->timer.cb = fsm_tmr_cb; + llist_add(&fi->list, &fsm->instances); + return fi; +} + +/*! \brief delete a given instance of a FSM + * \param[in] fsm The FSM to be un-registered and deleted + */ +void osmo_fsm_inst_free(struct osmo_fsm_inst *fi) +{ + osmo_timer_del(&fi->timer); + llist_del(&fi->list); + talloc_free(fi); +} + +/*! \brief get human-readable name of FSM event + * \param[in] fsm FSM descriptor of event + * \param[in] event Event integer value + * \returns string rendering of the event + */ +const char *osmo_fsm_event_name(struct osmo_fsm *fsm, uint32_t event) +{ + static char buf[32]; + if (!fsm->event_names) { + snprintf(buf, sizeof(buf), "%u", event); + return buf; + } else + return get_value_string(fsm->event_names, event); +} + +/*! \brief get human-readable name of FSM instance + * \param[in] fi FSM instance + * \returns string rendering of the FSM identity + */ +const char *osmo_fsm_inst_name(struct osmo_fsm_inst *fi) +{ + if (fi->name) + return fi->name; + else + return fi->fsm->name; +} + +/*! \brief get human-readable name of FSM instance + * \param[in] fsm FSM descriptor + * \param[in] state FSM state number + * \returns string rendering of the FSM state + */ +const char *osmo_fsm_state_name(struct osmo_fsm *fsm, uint32_t state) +{ + static char buf[32]; + if (state >= fsm->num_states) { + snprintf(buf, sizeof(buf), "unknown %u", state); + return buf; + } else + return fsm->states[state].name; +} + +/*! \brief perform a state change of the given FSM instance + * + * All changes to the FSM instance state must be made via this + * function. It verifies that the existing state actually permits a + * transiiton to new_state. + * + * timeout_secs and T are optional parameters, and only have any effect + * if timeout_secs is not 0. If the timeout function is used, then the + * new_state is entered, and the FSM instances timer is set to expire + * in timeout_secs functions. At that time, the FSM's timer_cb + * function will be called for handling of the timeout by the user. + * + * \param[in] fi FSM instance whose state is to change + * \param[in] new_state The new state into which we should change + * \param[in] timeout_secs Timeout in seconds (if !=0) + * \param[in] T Timer number (if \ref timeout_secs != 0) + * \returns 0 on success; negative on error + */ +int osmo_fsm_inst_state_chg(struct osmo_fsm_inst *fi, uint32_t new_state, + unsigned long timeout_secs, int T) +{ + struct osmo_fsm *fsm = fi->fsm; + struct osmo_fsm_state *st = &fsm->states[fi->state]; + + /* validate if new_state is a valid state */ + if (!(st->out_state_mask & (1 << new_state))) { + LOGP(fsm->log_subsys, LOGL_ERROR, "%s(%s): transition to " + "state %s not permitted!\n", + osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_state_name(fsm, new_state)); + return -EPERM; + } + + LOGP(fsm->log_subsys, fi->log_level, "%s(%s): state_chg to %s\n", + osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_state_name(fsm, new_state)); + + fi->state = new_state; + + if (timeout_secs) { + if (!fi->timer_cb) + LOGP(fsm->log_subsys, LOGL_ERROR, "cannot start " + "timer for FSM without timer call-back\n"); + else { + fi->T = T; + osmo_timer_schedule(&fi->timer, timeout_secs, 0); + } + } + + return 0; +} + +/*! \brief dispatch an event to an osmocom finite state machine instance + * + * Any incoming events to \ref osmo_fsm instances must be dispatched to + * them via this function. It verifies, whether the event is permitted + * based on the current state of the FSM. If not, -1 is returned. + * + * \param[in] fi FSM instance + * \param[in] event Event to send to FSM instance + * \param[in] data Data to pass along with the event + * \returns 0 in case of success; negative on error + */ +int osmo_fsm_dispatch(struct osmo_fsm_inst *fi, uint32_t event, void *data) +{ + struct osmo_fsm *fsm = fi->fsm; + struct osmo_fsm_state *fs; + + OSMO_ASSERT(fi->state < fsm->num_states); + + fs = &fi->fsm->states[fi->state]; + + + LOGP(fsm->log_subsys, fi->log_level, "%s(%s): Received Event %s\n", + osmo_fsm_inst_name(fi), osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_event_name(fsm, event)); + + if (((1 << event) & fsm->allstate_event_mask) && fsm->allstate_action) { + fsm->allstate_action(fi, event, data); + return 0; + } + + if (!((1 << event) & fs->in_event_mask)) { + LOGP(fsm->log_subsys, LOGL_ERROR, "%s(%s): Event %s not " + "permitted\n", osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_event_name(fsm, event)); + return -1; + } + fs->action(fi, event, data); + + return 0; +} + +/*! @} */ diff --git a/tests/Makefile.am b/tests/Makefile.am index 55aaa07..263af0a 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -13,7 +13,7 @@ vty/vty_test comp128/comp128_test utils/utils_test \ smscb/gsm0341_test stats/stats_test \ bitvec/bitvec_test msgb/msgb_test bits/bitcomp_test \ - sim/sim_test tlv/tlv_test gsup/gsup_test + sim/sim_test tlv/tlv_test gsup/gsup_test fsm/fsm_test if ENABLE_MSGFILE check_PROGRAMS += msgfile/msgfile_test @@ -118,6 +118,9 @@ gsup_gsup_test_SOURCES = gsup/gsup_test.c gsup_gsup_test_LDADD = $(top_builddir)/src/gsm/libosmogsm.la $(top_builddir)/src/libosmocore.la +fsm_fsm_test_SOURCES = fsm/fsm_test.c +fsm_fsm_test_LDADD = $(top_builddir)/src/libosmocore.la + # The `:;' works around a Bash 3.2 bug when the output is not writeable. $(srcdir)/package.m4: $(top_srcdir)/configure.ac :;{ \ @@ -152,7 +155,8 @@ vty/vty_test.ok comp128/comp128_test.ok \ utils/utils_test.ok stats/stats_test.ok \ bitvec/bitvec_test.ok msgb/msgb_test.ok bits/bitcomp_test.ok \ - sim/sim_test.ok tlv/tlv_test.ok gsup/gsup_test.ok + sim/sim_test.ok tlv/tlv_test.ok gsup/gsup_test.ok \ + fsm/fsm_test.ok DISTCLEANFILES = atconfig diff --git a/tests/fsm/fsm_test.c b/tests/fsm/fsm_test.c new file mode 100644 index 0000000..d8db908 --- /dev/null +++ b/tests/fsm/fsm_test.c @@ -0,0 +1,152 @@ +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +enum { + DMAIN, +}; + +static void *g_ctx; + + +enum test_fsm_states { + ST_NULL = 0, + ST_ONE, + ST_TWO, +}; + +enum test_fsm_evt { + EV_A, + EV_B, +}; + +static void test_fsm_null(struct osmo_fsm_inst *fi, uint32_t event, void *data) +{ + switch (event) { + case EV_A: + OSMO_ASSERT(data == (void *) 23); + osmo_fsm_inst_state_chg(fi, ST_ONE, 0, 0); + break; + default: + OSMO_ASSERT(0); + break; + } +} + +static void test_fsm_one(struct osmo_fsm_inst *fi, uint32_t event, void *data) +{ + switch (event) { + case EV_B: + OSMO_ASSERT(data == (void *) 42); + osmo_fsm_inst_state_chg(fi,ST_TWO, 1, 2342); + break; + default: + OSMO_ASSERT(0); + break; + } +} + +static void test_fsm_tmr_cb(struct osmo_fsm_inst *fi) +{ + OSMO_ASSERT(fi->T == 2342); + OSMO_ASSERT(fi->state == ST_TWO); + LOGP(DMAIN, LOGL_INFO, "Timer\n"); + + exit(0); +} + +static struct osmo_fsm_state test_fsm_states[] = { + [ST_NULL] = { + .in_event_mask = (1 << EV_A), + .out_state_mask = (1 << ST_ONE), + .name = "NULL", + .action = test_fsm_null, + }, + [ST_ONE]= { + .in_event_mask = (1 << EV_B), + .out_state_mask = (1 << ST_TWO), + .name = "ONE", + .action= test_fsm_one, + }, + [ST_TWO]= { + .in_event_mask = 0, + .name = "TWO", + .action = NULL, + }, +}; + +static struct osmo_fsm fsm = { + .name = "Test FSM", + .states = test_fsm_states, + .num_states = ARRAY_SIZE(test_fsm_states), + .log_subsys = DMAIN, +}; + +static int foo(void) +{ + struct osmo_fsm_inst *fi; + + LOGP(DMAIN, LOGL_INFO, "Checking FSM allocation\n"); + fi = osmo_fsm_inst_alloc(&fsm, g_ctx, NULL, LOGL_DEBUG); + OSMO_ASSERT(fi); + OSMO_ASSERT(fi->fsm == &fsm); + OSMO_ASSERT(!strcmp(osmo_fsm_inst_name(fi), fsm.name)); + OSMO_ASSERT(fi->state == ST_NULL); + OSMO_ASSERT(fi->log_level == LOGL_DEBUG); + + /* Try invalid state transition */ + osmo_fsm_dispatch(fi, EV_B, (void *) 42); + OSMO_ASSERT(fi->state == ST_NULL); + + /* Legitimate state transition */ + osmo_fsm_dispatch(fi, EV_A, (void *) 23); + OSMO_ASSERT(fi->state == ST_ONE); + + /* Legitimate transition with timer */ + fi->timer_cb = test_fsm_tmr_cb; + osmo_fsm_dispatch(fi, EV_B, (void *) 42); + OSMO_ASSERT(fi->state == ST_TWO); + + + return 0; +} + +static const struct log_info_cat default_categories[] = { + [DMAIN] = { + .name = "DMAIN", + .description = "Main", + .enabled = 1, .loglevel = LOGL_DEBUG, + }, +}; + +static const struct log_info log_info = { + .cat = default_categories, + .num_cat = ARRAY_SIZE(default_categories), +}; + +int main(int argc, char **argv) +{ + struct log_target *stderr_target; + + log_init(&log_info, NULL); + stderr_target = log_target_create_stderr(); + log_add_target(stderr_target); + + g_ctx = NULL; + osmo_fsm_register(&fsm); + + foo(); + + while (1) { + osmo_select_main(0); + } + + exit(0); +} diff --git a/tests/fsm/fsm_test.err b/tests/fsm/fsm_test.err new file mode 100644 index 0000000..1d0bce2 --- /dev/null +++ b/tests/fsm/fsm_test.err @@ -0,0 +1,9 @@ +<0000> fsm/fsm_test.c:94 Checking FSM allocation +<0000> fsm.c:111 Test FSM(NULL): Event 1 not permitted +<0000> fsm.c:117 Test FSM(NULL): Received Event 0 +<0000> fsm.c:81 Test FSM(NULL): state_chg to ONE +<0000> fsm.c:117 Test FSM(ONE): Received Event 1 +<0000> fsm.c:81 Test FSM(ONE): state_chg to TWO +<0000> fsm.c:30 Test FSM(TWO): Timeout of T2342 +<0000> fsm/fsm_test.c:60 Timer + \ No newline at end of file diff --git a/tests/testsuite.at b/tests/testsuite.at index d49f7ff..93373c1 100644 --- a/tests/testsuite.at +++ b/tests/testsuite.at @@ -201,3 +201,10 @@ cat $abs_srcdir/gsup/gsup_test.ok > expout AT_CHECK([$abs_top_builddir/tests/gsup/gsup_test], [0], [expout], [ignore]) AT_CLEANUP + +AT_SETUP([fsm]) +AT_KEYWORDS([fsm]) +cat $abs_srcdir/fsm/fsm_test.ok > expout +cat $abs_srcdir/fsm/fsm_test.err > experr +AT_CHECK([$abs_top_builddir/tests/fsm/fsm_test], [0], [expout], [experr]) +AT_CLEANUP -- To view, visit https://gerrit.osmocom.org/163 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I0b0965a912598c1f6b84042a99fea9d522642466 Gerrit-PatchSet: 1 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: Harald Welte From gerrit-no-reply at lists.osmocom.org Wed Jun 1 06:27:50 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 06:27:50 +0000 Subject: [PATCH] libosmocore[master]: Add Finite State Machine abstraction code In-Reply-To: References: Message-ID: Hello Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/163 to look at the new patch set (#2). Add Finite State Machine abstraction code This code is supposed to formalize some of the state machine handling in Osmocom code. Change-Id: I0b0965a912598c1f6b84042a99fea9d522642466 --- M include/Makefile.am A include/osmocom/core/fsm.h M src/Makefile.am A src/fsm.c M tests/Makefile.am A tests/fsm/fsm_test.c A tests/fsm/fsm_test.err A tests/fsm/fsm_test.ok M tests/testsuite.at 9 files changed, 546 insertions(+), 3 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/63/163/2 diff --git a/include/Makefile.am b/include/Makefile.am index 2e58d7e..b775c9f 100644 --- a/include/Makefile.am +++ b/include/Makefile.am @@ -17,6 +17,7 @@ osmocom/core/crcgen.h \ osmocom/core/endian.h \ osmocom/core/defs.h \ + osmocom/core/fsm.h \ osmocom/core/gsmtap.h \ osmocom/core/gsmtap_util.h \ osmocom/core/linuxlist.h \ diff --git a/include/osmocom/core/fsm.h b/include/osmocom/core/fsm.h new file mode 100644 index 0000000..0e6a372 --- /dev/null +++ b/include/osmocom/core/fsm.h @@ -0,0 +1,87 @@ +#pragma once + +#include + +#include +#include +#include + +/*! \defgroup fsm Finite State Machine abstraction + * @{ + */ + +/*! \file fsm.h + * \brief Finite State Machine + */ + +struct osmo_fsm_inst; + +/*! \brief description of a rule in the FSM */ +struct osmo_fsm_state { + /*! \brief bit-mask of permitted input events for this state */ + uint32_t in_event_mask; + /*! \brief bit-mask to which other states this state may transiton */ + uint32_t out_state_mask; + /*! \brief human-readable name of this state */ + const char *name; + /*! \brief function pointer to be called for this state */ + void (*action)(struct osmo_fsm_inst *fi, uint32_t event, void *data); +}; + +/*! \brief a description of an osmocom finite state machine */ +struct osmo_fsm { + /*! \brief global list */ + struct llist_head list; + /*! \brief list of instances of this FSM */ + struct llist_head instances; + /*! \brief human readable name */ + const char *name; + /*! \brief table of state transition rules */ + struct osmo_fsm_state *states; + /*! \brief bit-mask of events permitted in all states */ + uint32_t allstate_event_mask; + /*! \brief function pointer to be called for allstate events */ + void (*allstate_action)(struct osmo_fsm_inst *fi, uint32_t event, void *data); + /*! \brief number of entries in \ref states */ + unsigned int num_states; + /*! \brief logging sub-system for this FSM */ + int log_subsys; + /*! \brief human-readable names of events */ + const struct value_string *event_names; +}; + +/*! \brief a single instanceof an osmocom finite state machine */ +struct osmo_fsm_inst { + /*! \brief member in the fsm->instances list */ + struct llist_head list; + /*! \brief back-pointer to the FSM of which we are an instance */ + struct osmo_fsm *fsm; + /*! \brief human readable name */ + const char *name; + /*! \brief some private data of this instance */ + void *priv; + /*! \brief logging level for this FSM */ + int log_level; + /*! \brief current state of the FSM */ + uint32_t state; + + /*! \brief timer call-back for states with time-out */ + void (*timer_cb)(struct osmo_fsm_inst *fi); + /*! \brief timer number for states with time-out */ + int T; + /*! \brief timer back-end for states with time-out */ + struct osmo_timer_list timer; +}; + +struct osmo_fsm_inst *osmo_fsm_inst_alloc(struct osmo_fsm *fsm, void *ctx, void *priv, + int log_level); +void osmo_fsm_inst_free(struct osmo_fsm_inst *fi); +const char *osmo_fsm_event_name(struct osmo_fsm *fsm, uint32_t event); +const char *osmo_fsm_inst_name(struct osmo_fsm_inst *fi); +const char *osmo_fsm_state_name(struct osmo_fsm *fsm, uint32_t state); +int osmo_fsm_inst_state_chg(struct osmo_fsm_inst *fi, uint32_t new_state, + unsigned long timeout_secs, int T); +int osmo_fsm_dispatch(struct osmo_fsm_inst *fi, uint32_t event, void *data); +int osmo_fsm_register(struct osmo_fsm *fsm); + +/*! @} */ diff --git a/src/Makefile.am b/src/Makefile.am index 45a77e3..7a6f464 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -9,7 +9,7 @@ libosmocore_la_LIBADD = $(BACKTRACE_LIB) $(TALLOC_LIBS) libosmocore_la_SOURCES = timer.c select.c signal.c msgb.c bits.c \ - bitvec.c bitcomp.c statistics.c \ + bitvec.c bitcomp.c statistics.c fsm.c \ write_queue.c utils.c socket.c \ logging.c logging_syslog.c rate_ctr.c \ gsmtap_util.c crc16.c panic.c backtrace.c \ diff --git a/src/fsm.c b/src/fsm.c new file mode 100644 index 0000000..6b58fe3 --- /dev/null +++ b/src/fsm.c @@ -0,0 +1,283 @@ +/* Osmocom generic Finite State Machine implementation + * + * (C) 2016 by Harald Welte + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301, USA. + */ + +#include + +#include +#include +#include +#include + +/*! \addtogroup fsm + * @{ + */ + +/*! \file fsm.c + * \brief Finite State Machine abstraction + * + * This is a generic C-language abstraction for implementing finite + * state machines within the Osmocom framework. It is intended to + * replace existing hand-coded or even only implicitly existing FSMs + * all over the existing code base. + * + * An libosmocore FSM is described by its \ref osmo_fsm description, + * which in turn refers to an array of \ref osmo_fsm_state descriptor, + * each describing a single state in the FSM. + * + * The general idea is that all actions performed within one state are + * located at one position in the code (the state's action function), + * as opposed to the 'message-centric' view of e.g. the existing + * state machines of the LAPD(m) coe, where there is one message for + * eahc possible event (primitive), and the function then needs to + * concern itself on how to handle that event over all possible states. + * + * For each state, there is a bit-mask of permitted input events for + * this state, as well as a bit-mask of permitted new output states to + * which the state can change. Furthermore, there is a function + * pointer implementing the actual handling of the input events. + * + * As there can often be many concurrent FSMs of one given class, we + * introduce the concept of \ref osmo_fsm_inst, i.e. an FSM instance. + * The instance keeps the actual state, while the \ref osmo_fsm + * descriptor contains the static/const descriptor of the FSM's states + * and possible transitions. + * + * osmo_fsm are integrated with the libosmocore logging system. The + * logging sub-system is determined by the FSM descriptor, as we assume + * one FSM (let's say one related to a location update procedure) is + * inevitably always tied to a sub-system. The logging level however + * is configurable for each FMS instance, to ensure that e.g. DEBUG + * logging can be used for the LU procedure of one subscriber, while + * NOTICE level is used for all other subscribers. + */ + +static LLIST_HEAD(g_fsms); + +/*! \brief register a FSM with the core + * + * A FSM descriptor needs to be registered with the core before any + * instances can be created for it. + * + * \param[in] fsm Descriptor of Finite State Machine to be registered + * \returns 0 on success; negative on error + */ +int osmo_fsm_register(struct osmo_fsm *fsm) +{ + /* FIXME:check for duplicate name? */ + llist_add_tail(&fsm->list, &g_fsms); + INIT_LLIST_HEAD(&fsm->instances); + + return 0; +} + +/*! \brief unregister a FSM from the core + * + * Once the FSM descriptor is unregistered, active instances can still + * use it, but no new instances may be created for it. + * + * \param[in] fsm Descriptor of Finite State Machine to be removed + */ +void osmo_fsm_unregister(struct osmo_fsm *fsm) +{ + llist_del(&fsm->list); +} + +/* small wrapper function around timer expiration (for logging) */ +static void fsm_tmr_cb(void *data) +{ + struct osmo_fsm_inst *fi = data; + struct osmo_fsm *fsm = fi->fsm; + + LOGP(fsm->log_subsys, fi->log_level, "%s(%s): Timeout of T%u\n", + osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), fi->T); + + fi->timer_cb(fi); +} + +/*! \brief allocate a new instance of a specified FSM + * \param[in] fsm Descriptor of the FSM + * \param[in] ctx talloc context from which to allocate memory + * \param[in] priv private data reference store in fsm instance + * \param[in] log_level The log level for events of this FSM + * \returns newly-allocated, initialized and registered FSM instance + */ +struct osmo_fsm_inst *osmo_fsm_inst_alloc(struct osmo_fsm *fsm, void *ctx, void *priv, + int log_level) +{ + struct osmo_fsm_inst *fi = talloc_zero(ctx, struct osmo_fsm_inst); + fi->fsm = fsm; + fi->priv = priv; + fi->log_level = log_level; + fi->timer.data = fi; + fi->timer.cb = fsm_tmr_cb; + llist_add(&fi->list, &fsm->instances); + return fi; +} + +/*! \brief delete a given instance of a FSM + * \param[in] fsm The FSM to be un-registered and deleted + */ +void osmo_fsm_inst_free(struct osmo_fsm_inst *fi) +{ + osmo_timer_del(&fi->timer); + llist_del(&fi->list); + talloc_free(fi); +} + +/*! \brief get human-readable name of FSM event + * \param[in] fsm FSM descriptor of event + * \param[in] event Event integer value + * \returns string rendering of the event + */ +const char *osmo_fsm_event_name(struct osmo_fsm *fsm, uint32_t event) +{ + static char buf[32]; + if (!fsm->event_names) { + snprintf(buf, sizeof(buf), "%u", event); + return buf; + } else + return get_value_string(fsm->event_names, event); +} + +/*! \brief get human-readable name of FSM instance + * \param[in] fi FSM instance + * \returns string rendering of the FSM identity + */ +const char *osmo_fsm_inst_name(struct osmo_fsm_inst *fi) +{ + if (fi->name) + return fi->name; + else + return fi->fsm->name; +} + +/*! \brief get human-readable name of FSM instance + * \param[in] fsm FSM descriptor + * \param[in] state FSM state number + * \returns string rendering of the FSM state + */ +const char *osmo_fsm_state_name(struct osmo_fsm *fsm, uint32_t state) +{ + static char buf[32]; + if (state >= fsm->num_states) { + snprintf(buf, sizeof(buf), "unknown %u", state); + return buf; + } else + return fsm->states[state].name; +} + +/*! \brief perform a state change of the given FSM instance + * + * All changes to the FSM instance state must be made via this + * function. It verifies that the existing state actually permits a + * transiiton to new_state. + * + * timeout_secs and T are optional parameters, and only have any effect + * if timeout_secs is not 0. If the timeout function is used, then the + * new_state is entered, and the FSM instances timer is set to expire + * in timeout_secs functions. At that time, the FSM's timer_cb + * function will be called for handling of the timeout by the user. + * + * \param[in] fi FSM instance whose state is to change + * \param[in] new_state The new state into which we should change + * \param[in] timeout_secs Timeout in seconds (if !=0) + * \param[in] T Timer number (if \ref timeout_secs != 0) + * \returns 0 on success; negative on error + */ +int osmo_fsm_inst_state_chg(struct osmo_fsm_inst *fi, uint32_t new_state, + unsigned long timeout_secs, int T) +{ + struct osmo_fsm *fsm = fi->fsm; + struct osmo_fsm_state *st = &fsm->states[fi->state]; + + /* validate if new_state is a valid state */ + if (!(st->out_state_mask & (1 << new_state))) { + LOGP(fsm->log_subsys, LOGL_ERROR, "%s(%s): transition to " + "state %s not permitted!\n", + osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_state_name(fsm, new_state)); + return -EPERM; + } + + LOGP(fsm->log_subsys, fi->log_level, "%s(%s): state_chg to %s\n", + osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_state_name(fsm, new_state)); + + fi->state = new_state; + + if (timeout_secs) { + if (!fi->timer_cb) + LOGP(fsm->log_subsys, LOGL_ERROR, "cannot start " + "timer for FSM without timer call-back\n"); + else { + fi->T = T; + osmo_timer_schedule(&fi->timer, timeout_secs, 0); + } + } + + return 0; +} + +/*! \brief dispatch an event to an osmocom finite state machine instance + * + * Any incoming events to \ref osmo_fsm instances must be dispatched to + * them via this function. It verifies, whether the event is permitted + * based on the current state of the FSM. If not, -1 is returned. + * + * \param[in] fi FSM instance + * \param[in] event Event to send to FSM instance + * \param[in] data Data to pass along with the event + * \returns 0 in case of success; negative on error + */ +int osmo_fsm_dispatch(struct osmo_fsm_inst *fi, uint32_t event, void *data) +{ + struct osmo_fsm *fsm = fi->fsm; + struct osmo_fsm_state *fs; + + OSMO_ASSERT(fi->state < fsm->num_states); + + fs = &fi->fsm->states[fi->state]; + + + LOGP(fsm->log_subsys, fi->log_level, "%s(%s): Received Event %s\n", + osmo_fsm_inst_name(fi), osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_event_name(fsm, event)); + + if (((1 << event) & fsm->allstate_event_mask) && fsm->allstate_action) { + fsm->allstate_action(fi, event, data); + return 0; + } + + if (!((1 << event) & fs->in_event_mask)) { + LOGP(fsm->log_subsys, LOGL_ERROR, "%s(%s): Event %s not " + "permitted\n", osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_event_name(fsm, event)); + return -1; + } + fs->action(fi, event, data); + + return 0; +} + +/*! @} */ diff --git a/tests/Makefile.am b/tests/Makefile.am index 55aaa07..263af0a 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -13,7 +13,7 @@ vty/vty_test comp128/comp128_test utils/utils_test \ smscb/gsm0341_test stats/stats_test \ bitvec/bitvec_test msgb/msgb_test bits/bitcomp_test \ - sim/sim_test tlv/tlv_test gsup/gsup_test + sim/sim_test tlv/tlv_test gsup/gsup_test fsm/fsm_test if ENABLE_MSGFILE check_PROGRAMS += msgfile/msgfile_test @@ -118,6 +118,9 @@ gsup_gsup_test_SOURCES = gsup/gsup_test.c gsup_gsup_test_LDADD = $(top_builddir)/src/gsm/libosmogsm.la $(top_builddir)/src/libosmocore.la +fsm_fsm_test_SOURCES = fsm/fsm_test.c +fsm_fsm_test_LDADD = $(top_builddir)/src/libosmocore.la + # The `:;' works around a Bash 3.2 bug when the output is not writeable. $(srcdir)/package.m4: $(top_srcdir)/configure.ac :;{ \ @@ -152,7 +155,8 @@ vty/vty_test.ok comp128/comp128_test.ok \ utils/utils_test.ok stats/stats_test.ok \ bitvec/bitvec_test.ok msgb/msgb_test.ok bits/bitcomp_test.ok \ - sim/sim_test.ok tlv/tlv_test.ok gsup/gsup_test.ok + sim/sim_test.ok tlv/tlv_test.ok gsup/gsup_test.ok \ + fsm/fsm_test.ok DISTCLEANFILES = atconfig diff --git a/tests/fsm/fsm_test.c b/tests/fsm/fsm_test.c new file mode 100644 index 0000000..d8db908 --- /dev/null +++ b/tests/fsm/fsm_test.c @@ -0,0 +1,152 @@ +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +enum { + DMAIN, +}; + +static void *g_ctx; + + +enum test_fsm_states { + ST_NULL = 0, + ST_ONE, + ST_TWO, +}; + +enum test_fsm_evt { + EV_A, + EV_B, +}; + +static void test_fsm_null(struct osmo_fsm_inst *fi, uint32_t event, void *data) +{ + switch (event) { + case EV_A: + OSMO_ASSERT(data == (void *) 23); + osmo_fsm_inst_state_chg(fi, ST_ONE, 0, 0); + break; + default: + OSMO_ASSERT(0); + break; + } +} + +static void test_fsm_one(struct osmo_fsm_inst *fi, uint32_t event, void *data) +{ + switch (event) { + case EV_B: + OSMO_ASSERT(data == (void *) 42); + osmo_fsm_inst_state_chg(fi,ST_TWO, 1, 2342); + break; + default: + OSMO_ASSERT(0); + break; + } +} + +static void test_fsm_tmr_cb(struct osmo_fsm_inst *fi) +{ + OSMO_ASSERT(fi->T == 2342); + OSMO_ASSERT(fi->state == ST_TWO); + LOGP(DMAIN, LOGL_INFO, "Timer\n"); + + exit(0); +} + +static struct osmo_fsm_state test_fsm_states[] = { + [ST_NULL] = { + .in_event_mask = (1 << EV_A), + .out_state_mask = (1 << ST_ONE), + .name = "NULL", + .action = test_fsm_null, + }, + [ST_ONE]= { + .in_event_mask = (1 << EV_B), + .out_state_mask = (1 << ST_TWO), + .name = "ONE", + .action= test_fsm_one, + }, + [ST_TWO]= { + .in_event_mask = 0, + .name = "TWO", + .action = NULL, + }, +}; + +static struct osmo_fsm fsm = { + .name = "Test FSM", + .states = test_fsm_states, + .num_states = ARRAY_SIZE(test_fsm_states), + .log_subsys = DMAIN, +}; + +static int foo(void) +{ + struct osmo_fsm_inst *fi; + + LOGP(DMAIN, LOGL_INFO, "Checking FSM allocation\n"); + fi = osmo_fsm_inst_alloc(&fsm, g_ctx, NULL, LOGL_DEBUG); + OSMO_ASSERT(fi); + OSMO_ASSERT(fi->fsm == &fsm); + OSMO_ASSERT(!strcmp(osmo_fsm_inst_name(fi), fsm.name)); + OSMO_ASSERT(fi->state == ST_NULL); + OSMO_ASSERT(fi->log_level == LOGL_DEBUG); + + /* Try invalid state transition */ + osmo_fsm_dispatch(fi, EV_B, (void *) 42); + OSMO_ASSERT(fi->state == ST_NULL); + + /* Legitimate state transition */ + osmo_fsm_dispatch(fi, EV_A, (void *) 23); + OSMO_ASSERT(fi->state == ST_ONE); + + /* Legitimate transition with timer */ + fi->timer_cb = test_fsm_tmr_cb; + osmo_fsm_dispatch(fi, EV_B, (void *) 42); + OSMO_ASSERT(fi->state == ST_TWO); + + + return 0; +} + +static const struct log_info_cat default_categories[] = { + [DMAIN] = { + .name = "DMAIN", + .description = "Main", + .enabled = 1, .loglevel = LOGL_DEBUG, + }, +}; + +static const struct log_info log_info = { + .cat = default_categories, + .num_cat = ARRAY_SIZE(default_categories), +}; + +int main(int argc, char **argv) +{ + struct log_target *stderr_target; + + log_init(&log_info, NULL); + stderr_target = log_target_create_stderr(); + log_add_target(stderr_target); + + g_ctx = NULL; + osmo_fsm_register(&fsm); + + foo(); + + while (1) { + osmo_select_main(0); + } + + exit(0); +} diff --git a/tests/fsm/fsm_test.err b/tests/fsm/fsm_test.err new file mode 100644 index 0000000..1d0bce2 --- /dev/null +++ b/tests/fsm/fsm_test.err @@ -0,0 +1,9 @@ +<0000> fsm/fsm_test.c:94 Checking FSM allocation +<0000> fsm.c:111 Test FSM(NULL): Event 1 not permitted +<0000> fsm.c:117 Test FSM(NULL): Received Event 0 +<0000> fsm.c:81 Test FSM(NULL): state_chg to ONE +<0000> fsm.c:117 Test FSM(ONE): Received Event 1 +<0000> fsm.c:81 Test FSM(ONE): state_chg to TWO +<0000> fsm.c:30 Test FSM(TWO): Timeout of T2342 +<0000> fsm/fsm_test.c:60 Timer + \ No newline at end of file diff --git a/tests/fsm/fsm_test.ok b/tests/fsm/fsm_test.ok new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/tests/fsm/fsm_test.ok diff --git a/tests/testsuite.at b/tests/testsuite.at index d49f7ff..93373c1 100644 --- a/tests/testsuite.at +++ b/tests/testsuite.at @@ -201,3 +201,10 @@ cat $abs_srcdir/gsup/gsup_test.ok > expout AT_CHECK([$abs_top_builddir/tests/gsup/gsup_test], [0], [expout], [ignore]) AT_CLEANUP + +AT_SETUP([fsm]) +AT_KEYWORDS([fsm]) +cat $abs_srcdir/fsm/fsm_test.ok > expout +cat $abs_srcdir/fsm/fsm_test.err > experr +AT_CHECK([$abs_top_builddir/tests/fsm/fsm_test], [0], [expout], [experr]) +AT_CLEANUP -- To view, visit https://gerrit.osmocom.org/163 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I0b0965a912598c1f6b84042a99fea9d522642466 Gerrit-PatchSet: 2 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Wed Jun 1 06:29:12 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 06:29:12 +0000 Subject: openbsc[master]: gprs: use new uint8_t * for kv in gprs_cipher_run() In-Reply-To: References: Message-ID: Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/162 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ib5bfe1fb05c693347b11ff4faadd3fc2205ebd76 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: lynxis lazus Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Wed Jun 1 06:29:15 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 06:29:15 +0000 Subject: [MERGED] openbsc[master]: gprs: use new uint8_t * for kv in gprs_cipher_run() In-Reply-To: References: Message-ID: Harald Welte has submitted this change and it was merged. Change subject: gprs: use new uint8_t * for kv in gprs_cipher_run() ...................................................................... gprs: use new uint8_t * for kv in gprs_cipher_run() libosmocore changed in bf990bb8 Update internal GPRS cipher API from uint_64 to uint8_t*. Fix a warning. Change-Id: Ib5bfe1fb05c693347b11ff4faadd3fc2205ebd76 --- M openbsc/src/gprs/gprs_llc.c 1 file changed, 2 insertions(+), 2 deletions(-) Approvals: Harald Welte: Looks good to me, approved Jenkins Builder: Verified diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index 4cf5163..883f0cc 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -410,7 +410,7 @@ uint8_t cipher_out[GSM0464_CIPH_MAX_BLOCK]; uint32_t iv; int rc, i; - uint64_t kc = *(uint64_t *)&lle->llme->kc; + uint8_t *kc = lle->llme->kc; /* Compute the 'Input' Paraemeter */ iv = gprs_cipher_gen_input_ui(iov_ui, sapi, nu, oc); @@ -611,7 +611,7 @@ uint16_t crypt_len = llhp.data_len + 3; uint8_t cipher_out[GSM0464_CIPH_MAX_BLOCK]; uint32_t iv; - uint64_t kc = *(uint64_t *)&lle->llme->kc; + uint8_t *kc = lle->llme->kc; int rc, i; if (lle->llme->algo == GPRS_ALGO_GEA0) { -- To view, visit https://gerrit.osmocom.org/162 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: Ib5bfe1fb05c693347b11ff4faadd3fc2205ebd76 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: lynxis lazus Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Wed Jun 1 06:29:39 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 06:29:39 +0000 Subject: openbsc[master]: add .gitreview In-Reply-To: References: Message-ID: Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/161 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ie7cdf16232181d4b8093e61f2d8a3faed9010d4f Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: lynxis lazus Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Wed Jun 1 06:29:42 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 06:29:42 +0000 Subject: [MERGED] openbsc[master]: add .gitreview In-Reply-To: References: Message-ID: Harald Welte has submitted this change and it was merged. Change subject: add .gitreview ...................................................................... add .gitreview A .gitreview file is required to use git review. More information about git review https://www.mediawiki.org/wiki/Gerrit/git-review Change-Id: Ie7cdf16232181d4b8093e61f2d8a3faed9010d4f --- A .gitreview 1 file changed, 3 insertions(+), 0 deletions(-) Approvals: Harald Welte: Looks good to me, approved Jenkins Builder: Verified diff --git a/.gitreview b/.gitreview new file mode 100644 index 0000000..ee67509 --- /dev/null +++ b/.gitreview @@ -0,0 +1,3 @@ +[gerrit] +host=gerrit.osmocom.org +project=openbsc -- To view, visit https://gerrit.osmocom.org/161 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: Ie7cdf16232181d4b8093e61f2d8a3faed9010d4f Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: lynxis lazus Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Wed Jun 1 06:34:29 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 06:34:29 +0000 Subject: libosmocore[master]: Add functions to detect HR/FR SID frames In-Reply-To: References: Message-ID: Patch Set 1: Code-Review-1 (2 comments) https://gerrit.osmocom.org/#/c/160/1/include/osmocom/codec/codec.h File include/osmocom/codec/codec.h: Line 46: bool osmo_check_sid_hr(uint8_t *rtp_payload, size_t payload_len); the other functions are calld osmo__, while your new functions are osmo__, which is a minor inconsistency. But let's ignore that. https://gerrit.osmocom.org/#/c/160/1/src/codec/gsm610.c File src/codec/gsm610.c: Line 320: return false; mh, this code doesn't really look very nice, like lots of copy+paste. why not have a 'const unsigned int sid_bits[] array with the bit numbers, and a nice for-loop to iterate over sid_bits? -- To view, visit https://gerrit.osmocom.org/160 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I4051e3c0d4fb9ee93d7e9e0ef4abaf9f18e227ca Gerrit-PatchSet: 1 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: Max Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: Yes From gerrit-no-reply at lists.osmocom.org Wed Jun 1 06:36:43 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 06:36:43 +0000 Subject: osmo-pcu[master]: encoding/rlc_copy_from_aligned_buffer: export written payloa... In-Reply-To: References: Message-ID: Patch Set 2: Code-Review-1 (1 comment) https://gerrit.osmocom.org/#/c/142/2/tests/edge/EdgeTest.cpp File tests/edge/EdgeTest.cpp: Line 527: &llc, &write_offset, &num_chunks, data, false, NULL); I think rather than just not testing the count_payload feature added, you should actually test the newly-introdcued counting fetaure here, too. I.e. have it count, and OSMO_ASSERT on the expected number of bits. -- To view, visit https://gerrit.osmocom.org/142 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I0e622acb1f13f7489946baf049de4ba1cde6a1fc Gerrit-PatchSet: 2 Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Owner: lynxis lazus Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: Yes From gerrit-no-reply at lists.osmocom.org Wed Jun 1 07:53:17 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 07:53:17 +0000 Subject: [PATCH] libosmocore[master]: Add Finite State Machine abstraction code In-Reply-To: References: Message-ID: Hello Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/163 to look at the new patch set (#3). Add Finite State Machine abstraction code This code is supposed to formalize some of the state machine handling in Osmocom code. Change-Id: I0b0965a912598c1f6b84042a99fea9d522642466 --- M include/Makefile.am A include/osmocom/core/fsm.h M src/Makefile.am A src/fsm.c M tests/Makefile.am A tests/fsm/fsm_test.c A tests/fsm/fsm_test.err A tests/fsm/fsm_test.ok M tests/testsuite.at 9 files changed, 547 insertions(+), 3 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/63/163/3 diff --git a/include/Makefile.am b/include/Makefile.am index 2e58d7e..b775c9f 100644 --- a/include/Makefile.am +++ b/include/Makefile.am @@ -17,6 +17,7 @@ osmocom/core/crcgen.h \ osmocom/core/endian.h \ osmocom/core/defs.h \ + osmocom/core/fsm.h \ osmocom/core/gsmtap.h \ osmocom/core/gsmtap_util.h \ osmocom/core/linuxlist.h \ diff --git a/include/osmocom/core/fsm.h b/include/osmocom/core/fsm.h new file mode 100644 index 0000000..0e6a372 --- /dev/null +++ b/include/osmocom/core/fsm.h @@ -0,0 +1,87 @@ +#pragma once + +#include + +#include +#include +#include + +/*! \defgroup fsm Finite State Machine abstraction + * @{ + */ + +/*! \file fsm.h + * \brief Finite State Machine + */ + +struct osmo_fsm_inst; + +/*! \brief description of a rule in the FSM */ +struct osmo_fsm_state { + /*! \brief bit-mask of permitted input events for this state */ + uint32_t in_event_mask; + /*! \brief bit-mask to which other states this state may transiton */ + uint32_t out_state_mask; + /*! \brief human-readable name of this state */ + const char *name; + /*! \brief function pointer to be called for this state */ + void (*action)(struct osmo_fsm_inst *fi, uint32_t event, void *data); +}; + +/*! \brief a description of an osmocom finite state machine */ +struct osmo_fsm { + /*! \brief global list */ + struct llist_head list; + /*! \brief list of instances of this FSM */ + struct llist_head instances; + /*! \brief human readable name */ + const char *name; + /*! \brief table of state transition rules */ + struct osmo_fsm_state *states; + /*! \brief bit-mask of events permitted in all states */ + uint32_t allstate_event_mask; + /*! \brief function pointer to be called for allstate events */ + void (*allstate_action)(struct osmo_fsm_inst *fi, uint32_t event, void *data); + /*! \brief number of entries in \ref states */ + unsigned int num_states; + /*! \brief logging sub-system for this FSM */ + int log_subsys; + /*! \brief human-readable names of events */ + const struct value_string *event_names; +}; + +/*! \brief a single instanceof an osmocom finite state machine */ +struct osmo_fsm_inst { + /*! \brief member in the fsm->instances list */ + struct llist_head list; + /*! \brief back-pointer to the FSM of which we are an instance */ + struct osmo_fsm *fsm; + /*! \brief human readable name */ + const char *name; + /*! \brief some private data of this instance */ + void *priv; + /*! \brief logging level for this FSM */ + int log_level; + /*! \brief current state of the FSM */ + uint32_t state; + + /*! \brief timer call-back for states with time-out */ + void (*timer_cb)(struct osmo_fsm_inst *fi); + /*! \brief timer number for states with time-out */ + int T; + /*! \brief timer back-end for states with time-out */ + struct osmo_timer_list timer; +}; + +struct osmo_fsm_inst *osmo_fsm_inst_alloc(struct osmo_fsm *fsm, void *ctx, void *priv, + int log_level); +void osmo_fsm_inst_free(struct osmo_fsm_inst *fi); +const char *osmo_fsm_event_name(struct osmo_fsm *fsm, uint32_t event); +const char *osmo_fsm_inst_name(struct osmo_fsm_inst *fi); +const char *osmo_fsm_state_name(struct osmo_fsm *fsm, uint32_t state); +int osmo_fsm_inst_state_chg(struct osmo_fsm_inst *fi, uint32_t new_state, + unsigned long timeout_secs, int T); +int osmo_fsm_dispatch(struct osmo_fsm_inst *fi, uint32_t event, void *data); +int osmo_fsm_register(struct osmo_fsm *fsm); + +/*! @} */ diff --git a/src/Makefile.am b/src/Makefile.am index 45a77e3..7a6f464 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -9,7 +9,7 @@ libosmocore_la_LIBADD = $(BACKTRACE_LIB) $(TALLOC_LIBS) libosmocore_la_SOURCES = timer.c select.c signal.c msgb.c bits.c \ - bitvec.c bitcomp.c statistics.c \ + bitvec.c bitcomp.c statistics.c fsm.c \ write_queue.c utils.c socket.c \ logging.c logging_syslog.c rate_ctr.c \ gsmtap_util.c crc16.c panic.c backtrace.c \ diff --git a/src/fsm.c b/src/fsm.c new file mode 100644 index 0000000..6b58fe3 --- /dev/null +++ b/src/fsm.c @@ -0,0 +1,283 @@ +/* Osmocom generic Finite State Machine implementation + * + * (C) 2016 by Harald Welte + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301, USA. + */ + +#include + +#include +#include +#include +#include + +/*! \addtogroup fsm + * @{ + */ + +/*! \file fsm.c + * \brief Finite State Machine abstraction + * + * This is a generic C-language abstraction for implementing finite + * state machines within the Osmocom framework. It is intended to + * replace existing hand-coded or even only implicitly existing FSMs + * all over the existing code base. + * + * An libosmocore FSM is described by its \ref osmo_fsm description, + * which in turn refers to an array of \ref osmo_fsm_state descriptor, + * each describing a single state in the FSM. + * + * The general idea is that all actions performed within one state are + * located at one position in the code (the state's action function), + * as opposed to the 'message-centric' view of e.g. the existing + * state machines of the LAPD(m) coe, where there is one message for + * eahc possible event (primitive), and the function then needs to + * concern itself on how to handle that event over all possible states. + * + * For each state, there is a bit-mask of permitted input events for + * this state, as well as a bit-mask of permitted new output states to + * which the state can change. Furthermore, there is a function + * pointer implementing the actual handling of the input events. + * + * As there can often be many concurrent FSMs of one given class, we + * introduce the concept of \ref osmo_fsm_inst, i.e. an FSM instance. + * The instance keeps the actual state, while the \ref osmo_fsm + * descriptor contains the static/const descriptor of the FSM's states + * and possible transitions. + * + * osmo_fsm are integrated with the libosmocore logging system. The + * logging sub-system is determined by the FSM descriptor, as we assume + * one FSM (let's say one related to a location update procedure) is + * inevitably always tied to a sub-system. The logging level however + * is configurable for each FMS instance, to ensure that e.g. DEBUG + * logging can be used for the LU procedure of one subscriber, while + * NOTICE level is used for all other subscribers. + */ + +static LLIST_HEAD(g_fsms); + +/*! \brief register a FSM with the core + * + * A FSM descriptor needs to be registered with the core before any + * instances can be created for it. + * + * \param[in] fsm Descriptor of Finite State Machine to be registered + * \returns 0 on success; negative on error + */ +int osmo_fsm_register(struct osmo_fsm *fsm) +{ + /* FIXME:check for duplicate name? */ + llist_add_tail(&fsm->list, &g_fsms); + INIT_LLIST_HEAD(&fsm->instances); + + return 0; +} + +/*! \brief unregister a FSM from the core + * + * Once the FSM descriptor is unregistered, active instances can still + * use it, but no new instances may be created for it. + * + * \param[in] fsm Descriptor of Finite State Machine to be removed + */ +void osmo_fsm_unregister(struct osmo_fsm *fsm) +{ + llist_del(&fsm->list); +} + +/* small wrapper function around timer expiration (for logging) */ +static void fsm_tmr_cb(void *data) +{ + struct osmo_fsm_inst *fi = data; + struct osmo_fsm *fsm = fi->fsm; + + LOGP(fsm->log_subsys, fi->log_level, "%s(%s): Timeout of T%u\n", + osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), fi->T); + + fi->timer_cb(fi); +} + +/*! \brief allocate a new instance of a specified FSM + * \param[in] fsm Descriptor of the FSM + * \param[in] ctx talloc context from which to allocate memory + * \param[in] priv private data reference store in fsm instance + * \param[in] log_level The log level for events of this FSM + * \returns newly-allocated, initialized and registered FSM instance + */ +struct osmo_fsm_inst *osmo_fsm_inst_alloc(struct osmo_fsm *fsm, void *ctx, void *priv, + int log_level) +{ + struct osmo_fsm_inst *fi = talloc_zero(ctx, struct osmo_fsm_inst); + fi->fsm = fsm; + fi->priv = priv; + fi->log_level = log_level; + fi->timer.data = fi; + fi->timer.cb = fsm_tmr_cb; + llist_add(&fi->list, &fsm->instances); + return fi; +} + +/*! \brief delete a given instance of a FSM + * \param[in] fsm The FSM to be un-registered and deleted + */ +void osmo_fsm_inst_free(struct osmo_fsm_inst *fi) +{ + osmo_timer_del(&fi->timer); + llist_del(&fi->list); + talloc_free(fi); +} + +/*! \brief get human-readable name of FSM event + * \param[in] fsm FSM descriptor of event + * \param[in] event Event integer value + * \returns string rendering of the event + */ +const char *osmo_fsm_event_name(struct osmo_fsm *fsm, uint32_t event) +{ + static char buf[32]; + if (!fsm->event_names) { + snprintf(buf, sizeof(buf), "%u", event); + return buf; + } else + return get_value_string(fsm->event_names, event); +} + +/*! \brief get human-readable name of FSM instance + * \param[in] fi FSM instance + * \returns string rendering of the FSM identity + */ +const char *osmo_fsm_inst_name(struct osmo_fsm_inst *fi) +{ + if (fi->name) + return fi->name; + else + return fi->fsm->name; +} + +/*! \brief get human-readable name of FSM instance + * \param[in] fsm FSM descriptor + * \param[in] state FSM state number + * \returns string rendering of the FSM state + */ +const char *osmo_fsm_state_name(struct osmo_fsm *fsm, uint32_t state) +{ + static char buf[32]; + if (state >= fsm->num_states) { + snprintf(buf, sizeof(buf), "unknown %u", state); + return buf; + } else + return fsm->states[state].name; +} + +/*! \brief perform a state change of the given FSM instance + * + * All changes to the FSM instance state must be made via this + * function. It verifies that the existing state actually permits a + * transiiton to new_state. + * + * timeout_secs and T are optional parameters, and only have any effect + * if timeout_secs is not 0. If the timeout function is used, then the + * new_state is entered, and the FSM instances timer is set to expire + * in timeout_secs functions. At that time, the FSM's timer_cb + * function will be called for handling of the timeout by the user. + * + * \param[in] fi FSM instance whose state is to change + * \param[in] new_state The new state into which we should change + * \param[in] timeout_secs Timeout in seconds (if !=0) + * \param[in] T Timer number (if \ref timeout_secs != 0) + * \returns 0 on success; negative on error + */ +int osmo_fsm_inst_state_chg(struct osmo_fsm_inst *fi, uint32_t new_state, + unsigned long timeout_secs, int T) +{ + struct osmo_fsm *fsm = fi->fsm; + struct osmo_fsm_state *st = &fsm->states[fi->state]; + + /* validate if new_state is a valid state */ + if (!(st->out_state_mask & (1 << new_state))) { + LOGP(fsm->log_subsys, LOGL_ERROR, "%s(%s): transition to " + "state %s not permitted!\n", + osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_state_name(fsm, new_state)); + return -EPERM; + } + + LOGP(fsm->log_subsys, fi->log_level, "%s(%s): state_chg to %s\n", + osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_state_name(fsm, new_state)); + + fi->state = new_state; + + if (timeout_secs) { + if (!fi->timer_cb) + LOGP(fsm->log_subsys, LOGL_ERROR, "cannot start " + "timer for FSM without timer call-back\n"); + else { + fi->T = T; + osmo_timer_schedule(&fi->timer, timeout_secs, 0); + } + } + + return 0; +} + +/*! \brief dispatch an event to an osmocom finite state machine instance + * + * Any incoming events to \ref osmo_fsm instances must be dispatched to + * them via this function. It verifies, whether the event is permitted + * based on the current state of the FSM. If not, -1 is returned. + * + * \param[in] fi FSM instance + * \param[in] event Event to send to FSM instance + * \param[in] data Data to pass along with the event + * \returns 0 in case of success; negative on error + */ +int osmo_fsm_dispatch(struct osmo_fsm_inst *fi, uint32_t event, void *data) +{ + struct osmo_fsm *fsm = fi->fsm; + struct osmo_fsm_state *fs; + + OSMO_ASSERT(fi->state < fsm->num_states); + + fs = &fi->fsm->states[fi->state]; + + + LOGP(fsm->log_subsys, fi->log_level, "%s(%s): Received Event %s\n", + osmo_fsm_inst_name(fi), osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_event_name(fsm, event)); + + if (((1 << event) & fsm->allstate_event_mask) && fsm->allstate_action) { + fsm->allstate_action(fi, event, data); + return 0; + } + + if (!((1 << event) & fs->in_event_mask)) { + LOGP(fsm->log_subsys, LOGL_ERROR, "%s(%s): Event %s not " + "permitted\n", osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_event_name(fsm, event)); + return -1; + } + fs->action(fi, event, data); + + return 0; +} + +/*! @} */ diff --git a/tests/Makefile.am b/tests/Makefile.am index 55aaa07..263af0a 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -13,7 +13,7 @@ vty/vty_test comp128/comp128_test utils/utils_test \ smscb/gsm0341_test stats/stats_test \ bitvec/bitvec_test msgb/msgb_test bits/bitcomp_test \ - sim/sim_test tlv/tlv_test gsup/gsup_test + sim/sim_test tlv/tlv_test gsup/gsup_test fsm/fsm_test if ENABLE_MSGFILE check_PROGRAMS += msgfile/msgfile_test @@ -118,6 +118,9 @@ gsup_gsup_test_SOURCES = gsup/gsup_test.c gsup_gsup_test_LDADD = $(top_builddir)/src/gsm/libosmogsm.la $(top_builddir)/src/libosmocore.la +fsm_fsm_test_SOURCES = fsm/fsm_test.c +fsm_fsm_test_LDADD = $(top_builddir)/src/libosmocore.la + # The `:;' works around a Bash 3.2 bug when the output is not writeable. $(srcdir)/package.m4: $(top_srcdir)/configure.ac :;{ \ @@ -152,7 +155,8 @@ vty/vty_test.ok comp128/comp128_test.ok \ utils/utils_test.ok stats/stats_test.ok \ bitvec/bitvec_test.ok msgb/msgb_test.ok bits/bitcomp_test.ok \ - sim/sim_test.ok tlv/tlv_test.ok gsup/gsup_test.ok + sim/sim_test.ok tlv/tlv_test.ok gsup/gsup_test.ok \ + fsm/fsm_test.ok DISTCLEANFILES = atconfig diff --git a/tests/fsm/fsm_test.c b/tests/fsm/fsm_test.c new file mode 100644 index 0000000..d8db908 --- /dev/null +++ b/tests/fsm/fsm_test.c @@ -0,0 +1,152 @@ +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +enum { + DMAIN, +}; + +static void *g_ctx; + + +enum test_fsm_states { + ST_NULL = 0, + ST_ONE, + ST_TWO, +}; + +enum test_fsm_evt { + EV_A, + EV_B, +}; + +static void test_fsm_null(struct osmo_fsm_inst *fi, uint32_t event, void *data) +{ + switch (event) { + case EV_A: + OSMO_ASSERT(data == (void *) 23); + osmo_fsm_inst_state_chg(fi, ST_ONE, 0, 0); + break; + default: + OSMO_ASSERT(0); + break; + } +} + +static void test_fsm_one(struct osmo_fsm_inst *fi, uint32_t event, void *data) +{ + switch (event) { + case EV_B: + OSMO_ASSERT(data == (void *) 42); + osmo_fsm_inst_state_chg(fi,ST_TWO, 1, 2342); + break; + default: + OSMO_ASSERT(0); + break; + } +} + +static void test_fsm_tmr_cb(struct osmo_fsm_inst *fi) +{ + OSMO_ASSERT(fi->T == 2342); + OSMO_ASSERT(fi->state == ST_TWO); + LOGP(DMAIN, LOGL_INFO, "Timer\n"); + + exit(0); +} + +static struct osmo_fsm_state test_fsm_states[] = { + [ST_NULL] = { + .in_event_mask = (1 << EV_A), + .out_state_mask = (1 << ST_ONE), + .name = "NULL", + .action = test_fsm_null, + }, + [ST_ONE]= { + .in_event_mask = (1 << EV_B), + .out_state_mask = (1 << ST_TWO), + .name = "ONE", + .action= test_fsm_one, + }, + [ST_TWO]= { + .in_event_mask = 0, + .name = "TWO", + .action = NULL, + }, +}; + +static struct osmo_fsm fsm = { + .name = "Test FSM", + .states = test_fsm_states, + .num_states = ARRAY_SIZE(test_fsm_states), + .log_subsys = DMAIN, +}; + +static int foo(void) +{ + struct osmo_fsm_inst *fi; + + LOGP(DMAIN, LOGL_INFO, "Checking FSM allocation\n"); + fi = osmo_fsm_inst_alloc(&fsm, g_ctx, NULL, LOGL_DEBUG); + OSMO_ASSERT(fi); + OSMO_ASSERT(fi->fsm == &fsm); + OSMO_ASSERT(!strcmp(osmo_fsm_inst_name(fi), fsm.name)); + OSMO_ASSERT(fi->state == ST_NULL); + OSMO_ASSERT(fi->log_level == LOGL_DEBUG); + + /* Try invalid state transition */ + osmo_fsm_dispatch(fi, EV_B, (void *) 42); + OSMO_ASSERT(fi->state == ST_NULL); + + /* Legitimate state transition */ + osmo_fsm_dispatch(fi, EV_A, (void *) 23); + OSMO_ASSERT(fi->state == ST_ONE); + + /* Legitimate transition with timer */ + fi->timer_cb = test_fsm_tmr_cb; + osmo_fsm_dispatch(fi, EV_B, (void *) 42); + OSMO_ASSERT(fi->state == ST_TWO); + + + return 0; +} + +static const struct log_info_cat default_categories[] = { + [DMAIN] = { + .name = "DMAIN", + .description = "Main", + .enabled = 1, .loglevel = LOGL_DEBUG, + }, +}; + +static const struct log_info log_info = { + .cat = default_categories, + .num_cat = ARRAY_SIZE(default_categories), +}; + +int main(int argc, char **argv) +{ + struct log_target *stderr_target; + + log_init(&log_info, NULL); + stderr_target = log_target_create_stderr(); + log_add_target(stderr_target); + + g_ctx = NULL; + osmo_fsm_register(&fsm); + + foo(); + + while (1) { + osmo_select_main(0); + } + + exit(0); +} diff --git a/tests/fsm/fsm_test.err b/tests/fsm/fsm_test.err new file mode 100644 index 0000000..0fc843d --- /dev/null +++ b/tests/fsm/fsm_test.err @@ -0,0 +1,10 @@ +<0000> fsm/fsm_test.c:96 Checking FSM allocation +<0000> fsm.c:264 Test FSM(NULL): Received Event 1 +<0000> fsm.c:275 Test FSM(NULL): Event 1 not permitted +<0000> fsm.c:264 Test FSM(NULL): Received Event 0 +<0000> fsm.c:224 Test FSM(NULL): state_chg to ONE +<0000> fsm.c:264 Test FSM(ONE): Received Event 1 +<0000> fsm.c:224 Test FSM(ONE): state_chg to TWO +<0000> fsm.c:110 Test FSM(TWO): Timeout of T2342 +<0000> fsm/fsm_test.c:60 Timer + \ No newline at end of file diff --git a/tests/fsm/fsm_test.ok b/tests/fsm/fsm_test.ok new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/tests/fsm/fsm_test.ok diff --git a/tests/testsuite.at b/tests/testsuite.at index d49f7ff..93373c1 100644 --- a/tests/testsuite.at +++ b/tests/testsuite.at @@ -201,3 +201,10 @@ cat $abs_srcdir/gsup/gsup_test.ok > expout AT_CHECK([$abs_top_builddir/tests/gsup/gsup_test], [0], [expout], [ignore]) AT_CLEANUP + +AT_SETUP([fsm]) +AT_KEYWORDS([fsm]) +cat $abs_srcdir/fsm/fsm_test.ok > expout +cat $abs_srcdir/fsm/fsm_test.err > experr +AT_CHECK([$abs_top_builddir/tests/fsm/fsm_test], [0], [expout], [experr]) +AT_CLEANUP -- To view, visit https://gerrit.osmocom.org/163 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I0b0965a912598c1f6b84042a99fea9d522642466 Gerrit-PatchSet: 3 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Wed Jun 1 07:57:10 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 07:57:10 +0000 Subject: [PATCH] libosmocore[master]: Add Finite State Machine abstraction code In-Reply-To: References: Message-ID: Hello Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/163 to look at the new patch set (#4). Add Finite State Machine abstraction code This code is supposed to formalize some of the state machine handling in Osmocom code. Change-Id: I0b0965a912598c1f6b84042a99fea9d522642466 --- M include/Makefile.am A include/osmocom/core/fsm.h M src/Makefile.am A src/fsm.c M tests/Makefile.am A tests/fsm/fsm_test.c A tests/fsm/fsm_test.err A tests/fsm/fsm_test.ok M tests/testsuite.at 9 files changed, 548 insertions(+), 3 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/63/163/4 diff --git a/include/Makefile.am b/include/Makefile.am index 2e58d7e..b775c9f 100644 --- a/include/Makefile.am +++ b/include/Makefile.am @@ -17,6 +17,7 @@ osmocom/core/crcgen.h \ osmocom/core/endian.h \ osmocom/core/defs.h \ + osmocom/core/fsm.h \ osmocom/core/gsmtap.h \ osmocom/core/gsmtap_util.h \ osmocom/core/linuxlist.h \ diff --git a/include/osmocom/core/fsm.h b/include/osmocom/core/fsm.h new file mode 100644 index 0000000..0e6a372 --- /dev/null +++ b/include/osmocom/core/fsm.h @@ -0,0 +1,87 @@ +#pragma once + +#include + +#include +#include +#include + +/*! \defgroup fsm Finite State Machine abstraction + * @{ + */ + +/*! \file fsm.h + * \brief Finite State Machine + */ + +struct osmo_fsm_inst; + +/*! \brief description of a rule in the FSM */ +struct osmo_fsm_state { + /*! \brief bit-mask of permitted input events for this state */ + uint32_t in_event_mask; + /*! \brief bit-mask to which other states this state may transiton */ + uint32_t out_state_mask; + /*! \brief human-readable name of this state */ + const char *name; + /*! \brief function pointer to be called for this state */ + void (*action)(struct osmo_fsm_inst *fi, uint32_t event, void *data); +}; + +/*! \brief a description of an osmocom finite state machine */ +struct osmo_fsm { + /*! \brief global list */ + struct llist_head list; + /*! \brief list of instances of this FSM */ + struct llist_head instances; + /*! \brief human readable name */ + const char *name; + /*! \brief table of state transition rules */ + struct osmo_fsm_state *states; + /*! \brief bit-mask of events permitted in all states */ + uint32_t allstate_event_mask; + /*! \brief function pointer to be called for allstate events */ + void (*allstate_action)(struct osmo_fsm_inst *fi, uint32_t event, void *data); + /*! \brief number of entries in \ref states */ + unsigned int num_states; + /*! \brief logging sub-system for this FSM */ + int log_subsys; + /*! \brief human-readable names of events */ + const struct value_string *event_names; +}; + +/*! \brief a single instanceof an osmocom finite state machine */ +struct osmo_fsm_inst { + /*! \brief member in the fsm->instances list */ + struct llist_head list; + /*! \brief back-pointer to the FSM of which we are an instance */ + struct osmo_fsm *fsm; + /*! \brief human readable name */ + const char *name; + /*! \brief some private data of this instance */ + void *priv; + /*! \brief logging level for this FSM */ + int log_level; + /*! \brief current state of the FSM */ + uint32_t state; + + /*! \brief timer call-back for states with time-out */ + void (*timer_cb)(struct osmo_fsm_inst *fi); + /*! \brief timer number for states with time-out */ + int T; + /*! \brief timer back-end for states with time-out */ + struct osmo_timer_list timer; +}; + +struct osmo_fsm_inst *osmo_fsm_inst_alloc(struct osmo_fsm *fsm, void *ctx, void *priv, + int log_level); +void osmo_fsm_inst_free(struct osmo_fsm_inst *fi); +const char *osmo_fsm_event_name(struct osmo_fsm *fsm, uint32_t event); +const char *osmo_fsm_inst_name(struct osmo_fsm_inst *fi); +const char *osmo_fsm_state_name(struct osmo_fsm *fsm, uint32_t state); +int osmo_fsm_inst_state_chg(struct osmo_fsm_inst *fi, uint32_t new_state, + unsigned long timeout_secs, int T); +int osmo_fsm_dispatch(struct osmo_fsm_inst *fi, uint32_t event, void *data); +int osmo_fsm_register(struct osmo_fsm *fsm); + +/*! @} */ diff --git a/src/Makefile.am b/src/Makefile.am index 45a77e3..7a6f464 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -9,7 +9,7 @@ libosmocore_la_LIBADD = $(BACKTRACE_LIB) $(TALLOC_LIBS) libosmocore_la_SOURCES = timer.c select.c signal.c msgb.c bits.c \ - bitvec.c bitcomp.c statistics.c \ + bitvec.c bitcomp.c statistics.c fsm.c \ write_queue.c utils.c socket.c \ logging.c logging_syslog.c rate_ctr.c \ gsmtap_util.c crc16.c panic.c backtrace.c \ diff --git a/src/fsm.c b/src/fsm.c new file mode 100644 index 0000000..6b58fe3 --- /dev/null +++ b/src/fsm.c @@ -0,0 +1,283 @@ +/* Osmocom generic Finite State Machine implementation + * + * (C) 2016 by Harald Welte + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301, USA. + */ + +#include + +#include +#include +#include +#include + +/*! \addtogroup fsm + * @{ + */ + +/*! \file fsm.c + * \brief Finite State Machine abstraction + * + * This is a generic C-language abstraction for implementing finite + * state machines within the Osmocom framework. It is intended to + * replace existing hand-coded or even only implicitly existing FSMs + * all over the existing code base. + * + * An libosmocore FSM is described by its \ref osmo_fsm description, + * which in turn refers to an array of \ref osmo_fsm_state descriptor, + * each describing a single state in the FSM. + * + * The general idea is that all actions performed within one state are + * located at one position in the code (the state's action function), + * as opposed to the 'message-centric' view of e.g. the existing + * state machines of the LAPD(m) coe, where there is one message for + * eahc possible event (primitive), and the function then needs to + * concern itself on how to handle that event over all possible states. + * + * For each state, there is a bit-mask of permitted input events for + * this state, as well as a bit-mask of permitted new output states to + * which the state can change. Furthermore, there is a function + * pointer implementing the actual handling of the input events. + * + * As there can often be many concurrent FSMs of one given class, we + * introduce the concept of \ref osmo_fsm_inst, i.e. an FSM instance. + * The instance keeps the actual state, while the \ref osmo_fsm + * descriptor contains the static/const descriptor of the FSM's states + * and possible transitions. + * + * osmo_fsm are integrated with the libosmocore logging system. The + * logging sub-system is determined by the FSM descriptor, as we assume + * one FSM (let's say one related to a location update procedure) is + * inevitably always tied to a sub-system. The logging level however + * is configurable for each FMS instance, to ensure that e.g. DEBUG + * logging can be used for the LU procedure of one subscriber, while + * NOTICE level is used for all other subscribers. + */ + +static LLIST_HEAD(g_fsms); + +/*! \brief register a FSM with the core + * + * A FSM descriptor needs to be registered with the core before any + * instances can be created for it. + * + * \param[in] fsm Descriptor of Finite State Machine to be registered + * \returns 0 on success; negative on error + */ +int osmo_fsm_register(struct osmo_fsm *fsm) +{ + /* FIXME:check for duplicate name? */ + llist_add_tail(&fsm->list, &g_fsms); + INIT_LLIST_HEAD(&fsm->instances); + + return 0; +} + +/*! \brief unregister a FSM from the core + * + * Once the FSM descriptor is unregistered, active instances can still + * use it, but no new instances may be created for it. + * + * \param[in] fsm Descriptor of Finite State Machine to be removed + */ +void osmo_fsm_unregister(struct osmo_fsm *fsm) +{ + llist_del(&fsm->list); +} + +/* small wrapper function around timer expiration (for logging) */ +static void fsm_tmr_cb(void *data) +{ + struct osmo_fsm_inst *fi = data; + struct osmo_fsm *fsm = fi->fsm; + + LOGP(fsm->log_subsys, fi->log_level, "%s(%s): Timeout of T%u\n", + osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), fi->T); + + fi->timer_cb(fi); +} + +/*! \brief allocate a new instance of a specified FSM + * \param[in] fsm Descriptor of the FSM + * \param[in] ctx talloc context from which to allocate memory + * \param[in] priv private data reference store in fsm instance + * \param[in] log_level The log level for events of this FSM + * \returns newly-allocated, initialized and registered FSM instance + */ +struct osmo_fsm_inst *osmo_fsm_inst_alloc(struct osmo_fsm *fsm, void *ctx, void *priv, + int log_level) +{ + struct osmo_fsm_inst *fi = talloc_zero(ctx, struct osmo_fsm_inst); + fi->fsm = fsm; + fi->priv = priv; + fi->log_level = log_level; + fi->timer.data = fi; + fi->timer.cb = fsm_tmr_cb; + llist_add(&fi->list, &fsm->instances); + return fi; +} + +/*! \brief delete a given instance of a FSM + * \param[in] fsm The FSM to be un-registered and deleted + */ +void osmo_fsm_inst_free(struct osmo_fsm_inst *fi) +{ + osmo_timer_del(&fi->timer); + llist_del(&fi->list); + talloc_free(fi); +} + +/*! \brief get human-readable name of FSM event + * \param[in] fsm FSM descriptor of event + * \param[in] event Event integer value + * \returns string rendering of the event + */ +const char *osmo_fsm_event_name(struct osmo_fsm *fsm, uint32_t event) +{ + static char buf[32]; + if (!fsm->event_names) { + snprintf(buf, sizeof(buf), "%u", event); + return buf; + } else + return get_value_string(fsm->event_names, event); +} + +/*! \brief get human-readable name of FSM instance + * \param[in] fi FSM instance + * \returns string rendering of the FSM identity + */ +const char *osmo_fsm_inst_name(struct osmo_fsm_inst *fi) +{ + if (fi->name) + return fi->name; + else + return fi->fsm->name; +} + +/*! \brief get human-readable name of FSM instance + * \param[in] fsm FSM descriptor + * \param[in] state FSM state number + * \returns string rendering of the FSM state + */ +const char *osmo_fsm_state_name(struct osmo_fsm *fsm, uint32_t state) +{ + static char buf[32]; + if (state >= fsm->num_states) { + snprintf(buf, sizeof(buf), "unknown %u", state); + return buf; + } else + return fsm->states[state].name; +} + +/*! \brief perform a state change of the given FSM instance + * + * All changes to the FSM instance state must be made via this + * function. It verifies that the existing state actually permits a + * transiiton to new_state. + * + * timeout_secs and T are optional parameters, and only have any effect + * if timeout_secs is not 0. If the timeout function is used, then the + * new_state is entered, and the FSM instances timer is set to expire + * in timeout_secs functions. At that time, the FSM's timer_cb + * function will be called for handling of the timeout by the user. + * + * \param[in] fi FSM instance whose state is to change + * \param[in] new_state The new state into which we should change + * \param[in] timeout_secs Timeout in seconds (if !=0) + * \param[in] T Timer number (if \ref timeout_secs != 0) + * \returns 0 on success; negative on error + */ +int osmo_fsm_inst_state_chg(struct osmo_fsm_inst *fi, uint32_t new_state, + unsigned long timeout_secs, int T) +{ + struct osmo_fsm *fsm = fi->fsm; + struct osmo_fsm_state *st = &fsm->states[fi->state]; + + /* validate if new_state is a valid state */ + if (!(st->out_state_mask & (1 << new_state))) { + LOGP(fsm->log_subsys, LOGL_ERROR, "%s(%s): transition to " + "state %s not permitted!\n", + osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_state_name(fsm, new_state)); + return -EPERM; + } + + LOGP(fsm->log_subsys, fi->log_level, "%s(%s): state_chg to %s\n", + osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_state_name(fsm, new_state)); + + fi->state = new_state; + + if (timeout_secs) { + if (!fi->timer_cb) + LOGP(fsm->log_subsys, LOGL_ERROR, "cannot start " + "timer for FSM without timer call-back\n"); + else { + fi->T = T; + osmo_timer_schedule(&fi->timer, timeout_secs, 0); + } + } + + return 0; +} + +/*! \brief dispatch an event to an osmocom finite state machine instance + * + * Any incoming events to \ref osmo_fsm instances must be dispatched to + * them via this function. It verifies, whether the event is permitted + * based on the current state of the FSM. If not, -1 is returned. + * + * \param[in] fi FSM instance + * \param[in] event Event to send to FSM instance + * \param[in] data Data to pass along with the event + * \returns 0 in case of success; negative on error + */ +int osmo_fsm_dispatch(struct osmo_fsm_inst *fi, uint32_t event, void *data) +{ + struct osmo_fsm *fsm = fi->fsm; + struct osmo_fsm_state *fs; + + OSMO_ASSERT(fi->state < fsm->num_states); + + fs = &fi->fsm->states[fi->state]; + + + LOGP(fsm->log_subsys, fi->log_level, "%s(%s): Received Event %s\n", + osmo_fsm_inst_name(fi), osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_event_name(fsm, event)); + + if (((1 << event) & fsm->allstate_event_mask) && fsm->allstate_action) { + fsm->allstate_action(fi, event, data); + return 0; + } + + if (!((1 << event) & fs->in_event_mask)) { + LOGP(fsm->log_subsys, LOGL_ERROR, "%s(%s): Event %s not " + "permitted\n", osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_event_name(fsm, event)); + return -1; + } + fs->action(fi, event, data); + + return 0; +} + +/*! @} */ diff --git a/tests/Makefile.am b/tests/Makefile.am index 55aaa07..263af0a 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -13,7 +13,7 @@ vty/vty_test comp128/comp128_test utils/utils_test \ smscb/gsm0341_test stats/stats_test \ bitvec/bitvec_test msgb/msgb_test bits/bitcomp_test \ - sim/sim_test tlv/tlv_test gsup/gsup_test + sim/sim_test tlv/tlv_test gsup/gsup_test fsm/fsm_test if ENABLE_MSGFILE check_PROGRAMS += msgfile/msgfile_test @@ -118,6 +118,9 @@ gsup_gsup_test_SOURCES = gsup/gsup_test.c gsup_gsup_test_LDADD = $(top_builddir)/src/gsm/libosmogsm.la $(top_builddir)/src/libosmocore.la +fsm_fsm_test_SOURCES = fsm/fsm_test.c +fsm_fsm_test_LDADD = $(top_builddir)/src/libosmocore.la + # The `:;' works around a Bash 3.2 bug when the output is not writeable. $(srcdir)/package.m4: $(top_srcdir)/configure.ac :;{ \ @@ -152,7 +155,8 @@ vty/vty_test.ok comp128/comp128_test.ok \ utils/utils_test.ok stats/stats_test.ok \ bitvec/bitvec_test.ok msgb/msgb_test.ok bits/bitcomp_test.ok \ - sim/sim_test.ok tlv/tlv_test.ok gsup/gsup_test.ok + sim/sim_test.ok tlv/tlv_test.ok gsup/gsup_test.ok \ + fsm/fsm_test.ok DISTCLEANFILES = atconfig diff --git a/tests/fsm/fsm_test.c b/tests/fsm/fsm_test.c new file mode 100644 index 0000000..6492c07 --- /dev/null +++ b/tests/fsm/fsm_test.c @@ -0,0 +1,153 @@ +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +enum { + DMAIN, +}; + +static void *g_ctx; + + +enum test_fsm_states { + ST_NULL = 0, + ST_ONE, + ST_TWO, +}; + +enum test_fsm_evt { + EV_A, + EV_B, +}; + +static void test_fsm_null(struct osmo_fsm_inst *fi, uint32_t event, void *data) +{ + switch (event) { + case EV_A: + OSMO_ASSERT(data == (void *) 23); + osmo_fsm_inst_state_chg(fi, ST_ONE, 0, 0); + break; + default: + OSMO_ASSERT(0); + break; + } +} + +static void test_fsm_one(struct osmo_fsm_inst *fi, uint32_t event, void *data) +{ + switch (event) { + case EV_B: + OSMO_ASSERT(data == (void *) 42); + osmo_fsm_inst_state_chg(fi,ST_TWO, 1, 2342); + break; + default: + OSMO_ASSERT(0); + break; + } +} + +static void test_fsm_tmr_cb(struct osmo_fsm_inst *fi) +{ + OSMO_ASSERT(fi->T == 2342); + OSMO_ASSERT(fi->state == ST_TWO); + LOGP(DMAIN, LOGL_INFO, "Timer\n"); + + exit(0); +} + +static struct osmo_fsm_state test_fsm_states[] = { + [ST_NULL] = { + .in_event_mask = (1 << EV_A), + .out_state_mask = (1 << ST_ONE), + .name = "NULL", + .action = test_fsm_null, + }, + [ST_ONE]= { + .in_event_mask = (1 << EV_B), + .out_state_mask = (1 << ST_TWO), + .name = "ONE", + .action= test_fsm_one, + }, + [ST_TWO]= { + .in_event_mask = 0, + .name = "TWO", + .action = NULL, + }, +}; + +static struct osmo_fsm fsm = { + .name = "Test FSM", + .states = test_fsm_states, + .num_states = ARRAY_SIZE(test_fsm_states), + .log_subsys = DMAIN, +}; + +static int foo(void) +{ + struct osmo_fsm_inst *fi; + + LOGP(DMAIN, LOGL_INFO, "Checking FSM allocation\n"); + fi = osmo_fsm_inst_alloc(&fsm, g_ctx, NULL, LOGL_DEBUG); + OSMO_ASSERT(fi); + OSMO_ASSERT(fi->fsm == &fsm); + OSMO_ASSERT(!strcmp(osmo_fsm_inst_name(fi), fsm.name)); + OSMO_ASSERT(fi->state == ST_NULL); + OSMO_ASSERT(fi->log_level == LOGL_DEBUG); + + /* Try invalid state transition */ + osmo_fsm_dispatch(fi, EV_B, (void *) 42); + OSMO_ASSERT(fi->state == ST_NULL); + + /* Legitimate state transition */ + osmo_fsm_dispatch(fi, EV_A, (void *) 23); + OSMO_ASSERT(fi->state == ST_ONE); + + /* Legitimate transition with timer */ + fi->timer_cb = test_fsm_tmr_cb; + osmo_fsm_dispatch(fi, EV_B, (void *) 42); + OSMO_ASSERT(fi->state == ST_TWO); + + + return 0; +} + +static const struct log_info_cat default_categories[] = { + [DMAIN] = { + .name = "DMAIN", + .description = "Main", + .enabled = 1, .loglevel = LOGL_DEBUG, + }, +}; + +static const struct log_info log_info = { + .cat = default_categories, + .num_cat = ARRAY_SIZE(default_categories), +}; + +int main(int argc, char **argv) +{ + struct log_target *stderr_target; + + log_init(&log_info, NULL); + stderr_target = log_target_create_stderr(); + log_add_target(stderr_target); + log_set_print_filename(stderr_target, 0); + + g_ctx = NULL; + osmo_fsm_register(&fsm); + + foo(); + + while (1) { + osmo_select_main(0); + } + + exit(0); +} diff --git a/tests/fsm/fsm_test.err b/tests/fsm/fsm_test.err new file mode 100644 index 0000000..5bbde4e --- /dev/null +++ b/tests/fsm/fsm_test.err @@ -0,0 +1,10 @@ +Checking FSM allocation +Test FSM(NULL): Received Event 1 +Test FSM(NULL): Event 1 not permitted +Test FSM(NULL): Received Event 0 +Test FSM(NULL): state_chg to ONE +Test FSM(ONE): Received Event 1 +Test FSM(ONE): state_chg to TWO +Test FSM(TWO): Timeout of T2342 +Timer + \ No newline at end of file diff --git a/tests/fsm/fsm_test.ok b/tests/fsm/fsm_test.ok new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/tests/fsm/fsm_test.ok diff --git a/tests/testsuite.at b/tests/testsuite.at index d49f7ff..93373c1 100644 --- a/tests/testsuite.at +++ b/tests/testsuite.at @@ -201,3 +201,10 @@ cat $abs_srcdir/gsup/gsup_test.ok > expout AT_CHECK([$abs_top_builddir/tests/gsup/gsup_test], [0], [expout], [ignore]) AT_CLEANUP + +AT_SETUP([fsm]) +AT_KEYWORDS([fsm]) +cat $abs_srcdir/fsm/fsm_test.ok > expout +cat $abs_srcdir/fsm/fsm_test.err > experr +AT_CHECK([$abs_top_builddir/tests/fsm/fsm_test], [0], [expout], [experr]) +AT_CLEANUP -- To view, visit https://gerrit.osmocom.org/163 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I0b0965a912598c1f6b84042a99fea9d522642466 Gerrit-PatchSet: 4 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Wed Jun 1 08:19:04 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 08:19:04 +0000 Subject: libosmocore[master]: Add Finite State Machine abstraction code In-Reply-To: References: Message-ID: Patch Set 4: it's really weird. When I build the exact same version (even cloned from gerrit!), 'make check' works perfectly fine, just as expected. -- To view, visit https://gerrit.osmocom.org/163 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I0b0965a912598c1f6b84042a99fea9d522642466 Gerrit-PatchSet: 4 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Wed Jun 1 09:04:39 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Wed, 1 Jun 2016 09:04:39 +0000 Subject: libosmocore[master]: Add Finite State Machine abstraction code In-Reply-To: References: Message-ID: Patch Set 4: make distcheck fails and fsm_test.err doesn't seem to be in the EXTRA_DIST -- To view, visit https://gerrit.osmocom.org/163 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I0b0965a912598c1f6b84042a99fea9d522642466 Gerrit-PatchSet: 4 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Wed Jun 1 09:24:14 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 09:24:14 +0000 Subject: [PATCH] libosmocore[master]: Add Finite State Machine abstraction code In-Reply-To: References: Message-ID: Hello Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/163 to look at the new patch set (#5). Add Finite State Machine abstraction code This code is supposed to formalize some of the state machine handling in Osmocom code. Change-Id: I0b0965a912598c1f6b84042a99fea9d522642466 --- M include/Makefile.am A include/osmocom/core/fsm.h M src/Makefile.am A src/fsm.c M tests/Makefile.am A tests/fsm/fsm_test.c A tests/fsm/fsm_test.err A tests/fsm/fsm_test.ok M tests/testsuite.at 9 files changed, 548 insertions(+), 3 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/63/163/5 diff --git a/include/Makefile.am b/include/Makefile.am index 2e58d7e..b775c9f 100644 --- a/include/Makefile.am +++ b/include/Makefile.am @@ -17,6 +17,7 @@ osmocom/core/crcgen.h \ osmocom/core/endian.h \ osmocom/core/defs.h \ + osmocom/core/fsm.h \ osmocom/core/gsmtap.h \ osmocom/core/gsmtap_util.h \ osmocom/core/linuxlist.h \ diff --git a/include/osmocom/core/fsm.h b/include/osmocom/core/fsm.h new file mode 100644 index 0000000..0e6a372 --- /dev/null +++ b/include/osmocom/core/fsm.h @@ -0,0 +1,87 @@ +#pragma once + +#include + +#include +#include +#include + +/*! \defgroup fsm Finite State Machine abstraction + * @{ + */ + +/*! \file fsm.h + * \brief Finite State Machine + */ + +struct osmo_fsm_inst; + +/*! \brief description of a rule in the FSM */ +struct osmo_fsm_state { + /*! \brief bit-mask of permitted input events for this state */ + uint32_t in_event_mask; + /*! \brief bit-mask to which other states this state may transiton */ + uint32_t out_state_mask; + /*! \brief human-readable name of this state */ + const char *name; + /*! \brief function pointer to be called for this state */ + void (*action)(struct osmo_fsm_inst *fi, uint32_t event, void *data); +}; + +/*! \brief a description of an osmocom finite state machine */ +struct osmo_fsm { + /*! \brief global list */ + struct llist_head list; + /*! \brief list of instances of this FSM */ + struct llist_head instances; + /*! \brief human readable name */ + const char *name; + /*! \brief table of state transition rules */ + struct osmo_fsm_state *states; + /*! \brief bit-mask of events permitted in all states */ + uint32_t allstate_event_mask; + /*! \brief function pointer to be called for allstate events */ + void (*allstate_action)(struct osmo_fsm_inst *fi, uint32_t event, void *data); + /*! \brief number of entries in \ref states */ + unsigned int num_states; + /*! \brief logging sub-system for this FSM */ + int log_subsys; + /*! \brief human-readable names of events */ + const struct value_string *event_names; +}; + +/*! \brief a single instanceof an osmocom finite state machine */ +struct osmo_fsm_inst { + /*! \brief member in the fsm->instances list */ + struct llist_head list; + /*! \brief back-pointer to the FSM of which we are an instance */ + struct osmo_fsm *fsm; + /*! \brief human readable name */ + const char *name; + /*! \brief some private data of this instance */ + void *priv; + /*! \brief logging level for this FSM */ + int log_level; + /*! \brief current state of the FSM */ + uint32_t state; + + /*! \brief timer call-back for states with time-out */ + void (*timer_cb)(struct osmo_fsm_inst *fi); + /*! \brief timer number for states with time-out */ + int T; + /*! \brief timer back-end for states with time-out */ + struct osmo_timer_list timer; +}; + +struct osmo_fsm_inst *osmo_fsm_inst_alloc(struct osmo_fsm *fsm, void *ctx, void *priv, + int log_level); +void osmo_fsm_inst_free(struct osmo_fsm_inst *fi); +const char *osmo_fsm_event_name(struct osmo_fsm *fsm, uint32_t event); +const char *osmo_fsm_inst_name(struct osmo_fsm_inst *fi); +const char *osmo_fsm_state_name(struct osmo_fsm *fsm, uint32_t state); +int osmo_fsm_inst_state_chg(struct osmo_fsm_inst *fi, uint32_t new_state, + unsigned long timeout_secs, int T); +int osmo_fsm_dispatch(struct osmo_fsm_inst *fi, uint32_t event, void *data); +int osmo_fsm_register(struct osmo_fsm *fsm); + +/*! @} */ diff --git a/src/Makefile.am b/src/Makefile.am index 45a77e3..7a6f464 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -9,7 +9,7 @@ libosmocore_la_LIBADD = $(BACKTRACE_LIB) $(TALLOC_LIBS) libosmocore_la_SOURCES = timer.c select.c signal.c msgb.c bits.c \ - bitvec.c bitcomp.c statistics.c \ + bitvec.c bitcomp.c statistics.c fsm.c \ write_queue.c utils.c socket.c \ logging.c logging_syslog.c rate_ctr.c \ gsmtap_util.c crc16.c panic.c backtrace.c \ diff --git a/src/fsm.c b/src/fsm.c new file mode 100644 index 0000000..6b58fe3 --- /dev/null +++ b/src/fsm.c @@ -0,0 +1,283 @@ +/* Osmocom generic Finite State Machine implementation + * + * (C) 2016 by Harald Welte + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301, USA. + */ + +#include + +#include +#include +#include +#include + +/*! \addtogroup fsm + * @{ + */ + +/*! \file fsm.c + * \brief Finite State Machine abstraction + * + * This is a generic C-language abstraction for implementing finite + * state machines within the Osmocom framework. It is intended to + * replace existing hand-coded or even only implicitly existing FSMs + * all over the existing code base. + * + * An libosmocore FSM is described by its \ref osmo_fsm description, + * which in turn refers to an array of \ref osmo_fsm_state descriptor, + * each describing a single state in the FSM. + * + * The general idea is that all actions performed within one state are + * located at one position in the code (the state's action function), + * as opposed to the 'message-centric' view of e.g. the existing + * state machines of the LAPD(m) coe, where there is one message for + * eahc possible event (primitive), and the function then needs to + * concern itself on how to handle that event over all possible states. + * + * For each state, there is a bit-mask of permitted input events for + * this state, as well as a bit-mask of permitted new output states to + * which the state can change. Furthermore, there is a function + * pointer implementing the actual handling of the input events. + * + * As there can often be many concurrent FSMs of one given class, we + * introduce the concept of \ref osmo_fsm_inst, i.e. an FSM instance. + * The instance keeps the actual state, while the \ref osmo_fsm + * descriptor contains the static/const descriptor of the FSM's states + * and possible transitions. + * + * osmo_fsm are integrated with the libosmocore logging system. The + * logging sub-system is determined by the FSM descriptor, as we assume + * one FSM (let's say one related to a location update procedure) is + * inevitably always tied to a sub-system. The logging level however + * is configurable for each FMS instance, to ensure that e.g. DEBUG + * logging can be used for the LU procedure of one subscriber, while + * NOTICE level is used for all other subscribers. + */ + +static LLIST_HEAD(g_fsms); + +/*! \brief register a FSM with the core + * + * A FSM descriptor needs to be registered with the core before any + * instances can be created for it. + * + * \param[in] fsm Descriptor of Finite State Machine to be registered + * \returns 0 on success; negative on error + */ +int osmo_fsm_register(struct osmo_fsm *fsm) +{ + /* FIXME:check for duplicate name? */ + llist_add_tail(&fsm->list, &g_fsms); + INIT_LLIST_HEAD(&fsm->instances); + + return 0; +} + +/*! \brief unregister a FSM from the core + * + * Once the FSM descriptor is unregistered, active instances can still + * use it, but no new instances may be created for it. + * + * \param[in] fsm Descriptor of Finite State Machine to be removed + */ +void osmo_fsm_unregister(struct osmo_fsm *fsm) +{ + llist_del(&fsm->list); +} + +/* small wrapper function around timer expiration (for logging) */ +static void fsm_tmr_cb(void *data) +{ + struct osmo_fsm_inst *fi = data; + struct osmo_fsm *fsm = fi->fsm; + + LOGP(fsm->log_subsys, fi->log_level, "%s(%s): Timeout of T%u\n", + osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), fi->T); + + fi->timer_cb(fi); +} + +/*! \brief allocate a new instance of a specified FSM + * \param[in] fsm Descriptor of the FSM + * \param[in] ctx talloc context from which to allocate memory + * \param[in] priv private data reference store in fsm instance + * \param[in] log_level The log level for events of this FSM + * \returns newly-allocated, initialized and registered FSM instance + */ +struct osmo_fsm_inst *osmo_fsm_inst_alloc(struct osmo_fsm *fsm, void *ctx, void *priv, + int log_level) +{ + struct osmo_fsm_inst *fi = talloc_zero(ctx, struct osmo_fsm_inst); + fi->fsm = fsm; + fi->priv = priv; + fi->log_level = log_level; + fi->timer.data = fi; + fi->timer.cb = fsm_tmr_cb; + llist_add(&fi->list, &fsm->instances); + return fi; +} + +/*! \brief delete a given instance of a FSM + * \param[in] fsm The FSM to be un-registered and deleted + */ +void osmo_fsm_inst_free(struct osmo_fsm_inst *fi) +{ + osmo_timer_del(&fi->timer); + llist_del(&fi->list); + talloc_free(fi); +} + +/*! \brief get human-readable name of FSM event + * \param[in] fsm FSM descriptor of event + * \param[in] event Event integer value + * \returns string rendering of the event + */ +const char *osmo_fsm_event_name(struct osmo_fsm *fsm, uint32_t event) +{ + static char buf[32]; + if (!fsm->event_names) { + snprintf(buf, sizeof(buf), "%u", event); + return buf; + } else + return get_value_string(fsm->event_names, event); +} + +/*! \brief get human-readable name of FSM instance + * \param[in] fi FSM instance + * \returns string rendering of the FSM identity + */ +const char *osmo_fsm_inst_name(struct osmo_fsm_inst *fi) +{ + if (fi->name) + return fi->name; + else + return fi->fsm->name; +} + +/*! \brief get human-readable name of FSM instance + * \param[in] fsm FSM descriptor + * \param[in] state FSM state number + * \returns string rendering of the FSM state + */ +const char *osmo_fsm_state_name(struct osmo_fsm *fsm, uint32_t state) +{ + static char buf[32]; + if (state >= fsm->num_states) { + snprintf(buf, sizeof(buf), "unknown %u", state); + return buf; + } else + return fsm->states[state].name; +} + +/*! \brief perform a state change of the given FSM instance + * + * All changes to the FSM instance state must be made via this + * function. It verifies that the existing state actually permits a + * transiiton to new_state. + * + * timeout_secs and T are optional parameters, and only have any effect + * if timeout_secs is not 0. If the timeout function is used, then the + * new_state is entered, and the FSM instances timer is set to expire + * in timeout_secs functions. At that time, the FSM's timer_cb + * function will be called for handling of the timeout by the user. + * + * \param[in] fi FSM instance whose state is to change + * \param[in] new_state The new state into which we should change + * \param[in] timeout_secs Timeout in seconds (if !=0) + * \param[in] T Timer number (if \ref timeout_secs != 0) + * \returns 0 on success; negative on error + */ +int osmo_fsm_inst_state_chg(struct osmo_fsm_inst *fi, uint32_t new_state, + unsigned long timeout_secs, int T) +{ + struct osmo_fsm *fsm = fi->fsm; + struct osmo_fsm_state *st = &fsm->states[fi->state]; + + /* validate if new_state is a valid state */ + if (!(st->out_state_mask & (1 << new_state))) { + LOGP(fsm->log_subsys, LOGL_ERROR, "%s(%s): transition to " + "state %s not permitted!\n", + osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_state_name(fsm, new_state)); + return -EPERM; + } + + LOGP(fsm->log_subsys, fi->log_level, "%s(%s): state_chg to %s\n", + osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_state_name(fsm, new_state)); + + fi->state = new_state; + + if (timeout_secs) { + if (!fi->timer_cb) + LOGP(fsm->log_subsys, LOGL_ERROR, "cannot start " + "timer for FSM without timer call-back\n"); + else { + fi->T = T; + osmo_timer_schedule(&fi->timer, timeout_secs, 0); + } + } + + return 0; +} + +/*! \brief dispatch an event to an osmocom finite state machine instance + * + * Any incoming events to \ref osmo_fsm instances must be dispatched to + * them via this function. It verifies, whether the event is permitted + * based on the current state of the FSM. If not, -1 is returned. + * + * \param[in] fi FSM instance + * \param[in] event Event to send to FSM instance + * \param[in] data Data to pass along with the event + * \returns 0 in case of success; negative on error + */ +int osmo_fsm_dispatch(struct osmo_fsm_inst *fi, uint32_t event, void *data) +{ + struct osmo_fsm *fsm = fi->fsm; + struct osmo_fsm_state *fs; + + OSMO_ASSERT(fi->state < fsm->num_states); + + fs = &fi->fsm->states[fi->state]; + + + LOGP(fsm->log_subsys, fi->log_level, "%s(%s): Received Event %s\n", + osmo_fsm_inst_name(fi), osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_event_name(fsm, event)); + + if (((1 << event) & fsm->allstate_event_mask) && fsm->allstate_action) { + fsm->allstate_action(fi, event, data); + return 0; + } + + if (!((1 << event) & fs->in_event_mask)) { + LOGP(fsm->log_subsys, LOGL_ERROR, "%s(%s): Event %s not " + "permitted\n", osmo_fsm_inst_name(fi), + osmo_fsm_state_name(fsm, fi->state), + osmo_fsm_event_name(fsm, event)); + return -1; + } + fs->action(fi, event, data); + + return 0; +} + +/*! @} */ diff --git a/tests/Makefile.am b/tests/Makefile.am index 55aaa07..73b2d6a 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -13,7 +13,7 @@ vty/vty_test comp128/comp128_test utils/utils_test \ smscb/gsm0341_test stats/stats_test \ bitvec/bitvec_test msgb/msgb_test bits/bitcomp_test \ - sim/sim_test tlv/tlv_test gsup/gsup_test + sim/sim_test tlv/tlv_test gsup/gsup_test fsm/fsm_test if ENABLE_MSGFILE check_PROGRAMS += msgfile/msgfile_test @@ -118,6 +118,9 @@ gsup_gsup_test_SOURCES = gsup/gsup_test.c gsup_gsup_test_LDADD = $(top_builddir)/src/gsm/libosmogsm.la $(top_builddir)/src/libosmocore.la +fsm_fsm_test_SOURCES = fsm/fsm_test.c +fsm_fsm_test_LDADD = $(top_builddir)/src/libosmocore.la + # The `:;' works around a Bash 3.2 bug when the output is not writeable. $(srcdir)/package.m4: $(top_srcdir)/configure.ac :;{ \ @@ -152,7 +155,8 @@ vty/vty_test.ok comp128/comp128_test.ok \ utils/utils_test.ok stats/stats_test.ok \ bitvec/bitvec_test.ok msgb/msgb_test.ok bits/bitcomp_test.ok \ - sim/sim_test.ok tlv/tlv_test.ok gsup/gsup_test.ok + sim/sim_test.ok tlv/tlv_test.ok gsup/gsup_test.ok \ + fsm/fsm_test.ok fsm/fsm_test.err DISTCLEANFILES = atconfig diff --git a/tests/fsm/fsm_test.c b/tests/fsm/fsm_test.c new file mode 100644 index 0000000..6492c07 --- /dev/null +++ b/tests/fsm/fsm_test.c @@ -0,0 +1,153 @@ +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +enum { + DMAIN, +}; + +static void *g_ctx; + + +enum test_fsm_states { + ST_NULL = 0, + ST_ONE, + ST_TWO, +}; + +enum test_fsm_evt { + EV_A, + EV_B, +}; + +static void test_fsm_null(struct osmo_fsm_inst *fi, uint32_t event, void *data) +{ + switch (event) { + case EV_A: + OSMO_ASSERT(data == (void *) 23); + osmo_fsm_inst_state_chg(fi, ST_ONE, 0, 0); + break; + default: + OSMO_ASSERT(0); + break; + } +} + +static void test_fsm_one(struct osmo_fsm_inst *fi, uint32_t event, void *data) +{ + switch (event) { + case EV_B: + OSMO_ASSERT(data == (void *) 42); + osmo_fsm_inst_state_chg(fi,ST_TWO, 1, 2342); + break; + default: + OSMO_ASSERT(0); + break; + } +} + +static void test_fsm_tmr_cb(struct osmo_fsm_inst *fi) +{ + OSMO_ASSERT(fi->T == 2342); + OSMO_ASSERT(fi->state == ST_TWO); + LOGP(DMAIN, LOGL_INFO, "Timer\n"); + + exit(0); +} + +static struct osmo_fsm_state test_fsm_states[] = { + [ST_NULL] = { + .in_event_mask = (1 << EV_A), + .out_state_mask = (1 << ST_ONE), + .name = "NULL", + .action = test_fsm_null, + }, + [ST_ONE]= { + .in_event_mask = (1 << EV_B), + .out_state_mask = (1 << ST_TWO), + .name = "ONE", + .action= test_fsm_one, + }, + [ST_TWO]= { + .in_event_mask = 0, + .name = "TWO", + .action = NULL, + }, +}; + +static struct osmo_fsm fsm = { + .name = "Test FSM", + .states = test_fsm_states, + .num_states = ARRAY_SIZE(test_fsm_states), + .log_subsys = DMAIN, +}; + +static int foo(void) +{ + struct osmo_fsm_inst *fi; + + LOGP(DMAIN, LOGL_INFO, "Checking FSM allocation\n"); + fi = osmo_fsm_inst_alloc(&fsm, g_ctx, NULL, LOGL_DEBUG); + OSMO_ASSERT(fi); + OSMO_ASSERT(fi->fsm == &fsm); + OSMO_ASSERT(!strcmp(osmo_fsm_inst_name(fi), fsm.name)); + OSMO_ASSERT(fi->state == ST_NULL); + OSMO_ASSERT(fi->log_level == LOGL_DEBUG); + + /* Try invalid state transition */ + osmo_fsm_dispatch(fi, EV_B, (void *) 42); + OSMO_ASSERT(fi->state == ST_NULL); + + /* Legitimate state transition */ + osmo_fsm_dispatch(fi, EV_A, (void *) 23); + OSMO_ASSERT(fi->state == ST_ONE); + + /* Legitimate transition with timer */ + fi->timer_cb = test_fsm_tmr_cb; + osmo_fsm_dispatch(fi, EV_B, (void *) 42); + OSMO_ASSERT(fi->state == ST_TWO); + + + return 0; +} + +static const struct log_info_cat default_categories[] = { + [DMAIN] = { + .name = "DMAIN", + .description = "Main", + .enabled = 1, .loglevel = LOGL_DEBUG, + }, +}; + +static const struct log_info log_info = { + .cat = default_categories, + .num_cat = ARRAY_SIZE(default_categories), +}; + +int main(int argc, char **argv) +{ + struct log_target *stderr_target; + + log_init(&log_info, NULL); + stderr_target = log_target_create_stderr(); + log_add_target(stderr_target); + log_set_print_filename(stderr_target, 0); + + g_ctx = NULL; + osmo_fsm_register(&fsm); + + foo(); + + while (1) { + osmo_select_main(0); + } + + exit(0); +} diff --git a/tests/fsm/fsm_test.err b/tests/fsm/fsm_test.err new file mode 100644 index 0000000..5bbde4e --- /dev/null +++ b/tests/fsm/fsm_test.err @@ -0,0 +1,10 @@ +Checking FSM allocation +Test FSM(NULL): Received Event 1 +Test FSM(NULL): Event 1 not permitted +Test FSM(NULL): Received Event 0 +Test FSM(NULL): state_chg to ONE +Test FSM(ONE): Received Event 1 +Test FSM(ONE): state_chg to TWO +Test FSM(TWO): Timeout of T2342 +Timer + \ No newline at end of file diff --git a/tests/fsm/fsm_test.ok b/tests/fsm/fsm_test.ok new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/tests/fsm/fsm_test.ok diff --git a/tests/testsuite.at b/tests/testsuite.at index d49f7ff..93373c1 100644 --- a/tests/testsuite.at +++ b/tests/testsuite.at @@ -201,3 +201,10 @@ cat $abs_srcdir/gsup/gsup_test.ok > expout AT_CHECK([$abs_top_builddir/tests/gsup/gsup_test], [0], [expout], [ignore]) AT_CLEANUP + +AT_SETUP([fsm]) +AT_KEYWORDS([fsm]) +cat $abs_srcdir/fsm/fsm_test.ok > expout +cat $abs_srcdir/fsm/fsm_test.err > experr +AT_CHECK([$abs_top_builddir/tests/fsm/fsm_test], [0], [expout], [experr]) +AT_CLEANUP -- To view, visit https://gerrit.osmocom.org/163 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I0b0965a912598c1f6b84042a99fea9d522642466 Gerrit-PatchSet: 5 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Wed Jun 1 09:47:11 2016 From: gerrit-no-reply at lists.osmocom.org (Max) Date: Wed, 1 Jun 2016 09:47:11 +0000 Subject: [PATCH] libosmocore[master]: Add functions to detect HR/FR SID frames In-Reply-To: References: Message-ID: Hello Harald Welte, Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/160 to look at the new patch set (#2). Add functions to detect HR/FR SID frames Add functions which check if given FR or HR frame (packed in RTP) contains SID (SIlence Descriptor) and corresponding tests. Related: OS#22 Change-Id: I4051e3c0d4fb9ee93d7e9e0ef4abaf9f18e227ca --- M include/osmocom/codec/codec.h M src/codec/gsm610.c M src/codec/gsm620.c M tests/codec/codec_test.c M tests/codec/codec_test.ok 5 files changed, 108 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/60/160/2 diff --git a/include/osmocom/codec/codec.h b/include/osmocom/codec/codec.h index b7bcc78..f7a8ad9 100644 --- a/include/osmocom/codec/codec.h +++ b/include/osmocom/codec/codec.h @@ -1,6 +1,7 @@ #pragma once #include +#include #include @@ -41,6 +42,8 @@ AMR_GOOD = 1 }; +bool osmo_fr_check_sid(uint8_t *rtp_payload, size_t payload_len); +bool osmo_hr_check_sid(uint8_t *rtp_payload, size_t payload_len); int osmo_amr_rtp_enc(uint8_t *payload, uint8_t cmr, enum osmo_amr_type ft, enum osmo_amr_quality bfi); int osmo_amr_rtp_dec(const uint8_t *payload, int payload_len, uint8_t *cmr, diff --git a/src/codec/gsm610.c b/src/codec/gsm610.c index 35f6011..47faea2 100644 --- a/src/codec/gsm610.c +++ b/src/codec/gsm610.c @@ -22,6 +22,10 @@ */ #include +#include + +#include +#include /* GSM FR - subjective importance bit ordering */ /* This array encodes GSM 05.03 Table 2. @@ -292,3 +296,38 @@ 11, /* LARc1:0 */ 29, /* LARc5:0 */ }; + +/*! \brief Check whether RTP frame contains FR SID code word according to + * TS 101 318 ?5.1.2 + * \param[in] rtp_payload Buffer with RTP payload + * \param[in] payload_len Length of payload + * \returns true if code word is found, false otherwise + */ +bool osmo_fr_check_sid(uint8_t *rtp_payload, size_t payload_len) +{ + struct bitvec bv; + uint16_t i, z_bits[] = { 59, 60, 62, 63, 65, 66, 68, 69, 71, 72, 74, 75, + 77, 78, 80, 81, 83, 84, 86, 87, 89, 90, 92, 93, + 95, 96, 115, 116, 118, 119, 121, 122, 124, 125, + 127, 128, 130, 131, 133, 134, 136, 137, 139, + 140, 142, 143, 145, 146, 148, 149, 151, 152, + 171, 172, 174, 175, 177, 178, 180, 181, 183, + 184, 186, 187, 189, 190, 192, 193, 195, 196, + 198, 199, 201, 202, 204, 205, 207, 208, 227, + 228, 230, 231, 233, 234, 236, 237, 239, 242, + 245, 248, 251, 254, 257, 260, 263 }; + + /* signature does not match Full Rate SID */ + if ((rtp_payload[0] >> 4) != 0xD) + return false; + + bv.data = rtp_payload; + bv.data_len = payload_len; + + /* code word is all 0 at given bits, numbered from 1 */ + for (i = 0; i < ARRAY_SIZE(z_bits); i++) + if (bitvec_get_bit_pos(&bv, z_bits[i]) != ZERO) + return false; + + return true; +} diff --git a/src/codec/gsm620.c b/src/codec/gsm620.c index f4ac9ad..6f1a95b 100644 --- a/src/codec/gsm620.c +++ b/src/codec/gsm620.c @@ -22,6 +22,10 @@ */ #include +#include + +#include +#include /* GSM HR unvoiced (mode=0) frames - subjective importance bit ordering */ /* This array encode mapping between GSM 05.03 Table 3a (bits @@ -260,3 +264,31 @@ 82, /* Code 3:6 */ 81, /* Code 3:7 */ }; + +static inline uint16_t mask(const uint8_t msb) +{ + const uint16_t m = (uint16_t)1 << (msb - 1); + return (m - 1) ^ m; +} + +/*! \brief Check whether RTP frame contains HR SID code word according to + * TS 101 318 ?5.2.2 + * \param[in] rtp_payload Buffer with RTP payload + * \param[in] payload_len Length of payload + * \returns true if code word is found, false otherwise + */ +bool osmo_hr_check_sid(uint8_t *rtp_payload, size_t payload_len) +{ + uint8_t i, bits[] = { 1, 2, 8, 9, 5, 4, 9, 5, 4, 9, 5, 4, 9, 5 }; + struct bitvec bv; + bv.data = rtp_payload; + bv.data_len = payload_len; + bv.cur_bit = 33; + + /* code word is all 1 at given bits, numbered from 1, MODE is always 3 */ + for (i = 0; i < ARRAY_SIZE(bits); i++) + if (bitvec_get_uint(&bv, bits[i]) != mask(bits[i])) + return false; + + return true; +} diff --git a/tests/codec/codec_test.c b/tests/codec/codec_test.c index 4905dd3..5b934b1 100644 --- a/tests/codec/codec_test.c +++ b/tests/codec/codec_test.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include @@ -68,6 +69,26 @@ cmpr(_cmr, cmr), cmpr(_ft, ft), cmpr(_bfi, bfi), cmi, sti); } +uint8_t fr[] = {0xd8, 0xa9, 0xb5, 0x1d, 0xda, 0xa8, 0x82, 0xcc, 0xec, 0x52, + 0x29, 0x05, 0xa8, 0xc3, 0xe3, 0x0e, 0xb0, 0x89, 0x7a, 0xee, + 0x42, 0xca, 0xc4, 0x97, 0x22, 0xe6, 0x9e, 0xa8, 0xb8, 0xec, + 0x52, 0x26, 0xbd}; +uint8_t sid_fr[] = {0xd7, 0x27, 0x93, 0xe5, 0xe3, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; + +uint8_t hr[] = {0x06, 0x46, 0x76, 0xb1, 0x8e, 0x48, 0x9a, 0x2f, 0x5e, 0x4c, + 0x22, 0x2b, 0x62, 0x25}; +uint8_t sid_hr[] = {0x03, 0x8e, 0xb6, 0xcb, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff}; + +static void test_sid_xr(uint8_t *t, size_t len, bool hr) +{ + printf("%s SID ? %s:: %d\n", hr ? "HR" : "FR", osmo_hexdump(t, len), + hr ? osmo_hr_check_sid(t, len) : osmo_fr_check_sid(t, len)); +} + int main(int argc, char **argv) { printf("AMR RTP payload decoder test:\n"); @@ -79,6 +100,13 @@ test_amr_rt(AMR_12_2, AMR_12_2, AMR_GOOD); test_amr_rt(AMR_7_40, AMR_7_40, AMR_BAD); test_amr_rt(AMR_7_40, AMR_7_40, AMR_GOOD); + printf("FR RTP payload SID test:\n"); + test_sid_xr(sid_fr, 33, false); + test_sid_xr(fr, 33, false); + + printf("HR RTP payload SID test:\n"); + test_sid_xr(sid_hr, 14, true); + test_sid_xr(hr, 14, true); return 0; } diff --git a/tests/codec/codec_test.ok b/tests/codec/codec_test.ok index 0f76fef..2af7cc7 100644 --- a/tests/codec/codec_test.ok +++ b/tests/codec/codec_test.ok @@ -7,3 +7,9 @@ [33/33] AMR 12,2 kbit/s (GSM-EFR), CMR: OK, FT: OK, BFI: OK, CMI: -1, STI: -1 [21/21] AMR 7,40 kbit/s (TDMA-EFR), CMR: OK, FT: OK, BFI: OK, CMI: -1, STI: -1 [21/21] AMR 7,40 kbit/s (TDMA-EFR), CMR: OK, FT: OK, BFI: OK, CMI: -1, STI: -1 +FR RTP payload SID test: +FR SID ? d7 27 93 e5 e3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 :: 1 +FR SID ? d8 a9 b5 1d da a8 82 cc ec 52 29 05 a8 c3 e3 0e b0 89 7a ee 42 ca c4 97 22 e6 9e a8 b8 ec 52 26 bd :: 0 +HR RTP payload SID test: +HR SID ? 03 8e b6 cb ff ff ff ff ff ff ff ff ff ff :: 1 +HR SID ? 06 46 76 b1 8e 48 9a 2f 5e 4c 22 2b 62 25 :: 0 -- To view, visit https://gerrit.osmocom.org/160 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I4051e3c0d4fb9ee93d7e9e0ef4abaf9f18e227ca Gerrit-PatchSet: 2 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: Max Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Wed Jun 1 10:30:34 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Wed, 1 Jun 2016 10:30:34 +0000 Subject: osmo-pcu[master]: RFC: remove this == NULL checks In-Reply-To: References: Message-ID: Patch Set 1: Code-Review-1 Here's my guess: If a class has no virtual functions, the functions are essentially static and merely get passed the 'this' pointer of the instance called upon. For an inline foo() const function, the compiler is instructed to insert the code in-place, nevermind it being a class member namespace wise. The actual value of 'this' happens during runtime. The compiler can try hard to avoid NULL there, but it's easy to achieve at runtime. MyClass *instance = NULL; instance->my_non_virtual_function(); In this code, the NULL 'this' is actually passed into the function body. (For a virtual function, the program would first try to look up the function pointer in the virtual function table, which would probably result in a segfault.) Plus: Jacob wrote it. My opinion of Jacob's compiler knowledge is highly esteemed. Let's ask him first. Plus: Coverity warned about one of those. On the counter argument, the compiler does complain about comparison of 'this' against NULL. However, I trust that Jacob had his reasons in these particular instances. Would be nice to get rid of the warning though. Giving -1 but it's more like a -0 until we have more precise knowledge. -- To view, visit https://gerrit.osmocom.org/136 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ifddaef70bb0a4402050c817b1000d515c3a7118b Gerrit-PatchSet: 1 Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Owner: lynxis lazus Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Wed Jun 1 10:44:05 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 10:44:05 +0000 Subject: libosmocore[master]: Add functions to detect HR/FR SID frames In-Reply-To: References: Message-ID: Patch Set 2: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/160 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I4051e3c0d4fb9ee93d7e9e0ef4abaf9f18e227ca Gerrit-PatchSet: 2 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: Max Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Wed Jun 1 10:44:06 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 10:44:06 +0000 Subject: [MERGED] libosmocore[master]: Add functions to detect HR/FR SID frames In-Reply-To: References: Message-ID: Harald Welte has submitted this change and it was merged. Change subject: Add functions to detect HR/FR SID frames ...................................................................... Add functions to detect HR/FR SID frames Add functions which check if given FR or HR frame (packed in RTP) contains SID (SIlence Descriptor) and corresponding tests. Related: OS#22 Change-Id: I4051e3c0d4fb9ee93d7e9e0ef4abaf9f18e227ca Reviewed-on: https://gerrit.osmocom.org/160 Tested-by: Jenkins Builder Reviewed-by: Harald Welte --- M include/osmocom/codec/codec.h M src/codec/gsm610.c M src/codec/gsm620.c M tests/codec/codec_test.c M tests/codec/codec_test.ok 5 files changed, 108 insertions(+), 0 deletions(-) Approvals: Harald Welte: Looks good to me, approved Jenkins Builder: Verified diff --git a/include/osmocom/codec/codec.h b/include/osmocom/codec/codec.h index b7bcc78..f7a8ad9 100644 --- a/include/osmocom/codec/codec.h +++ b/include/osmocom/codec/codec.h @@ -1,6 +1,7 @@ #pragma once #include +#include #include @@ -41,6 +42,8 @@ AMR_GOOD = 1 }; +bool osmo_fr_check_sid(uint8_t *rtp_payload, size_t payload_len); +bool osmo_hr_check_sid(uint8_t *rtp_payload, size_t payload_len); int osmo_amr_rtp_enc(uint8_t *payload, uint8_t cmr, enum osmo_amr_type ft, enum osmo_amr_quality bfi); int osmo_amr_rtp_dec(const uint8_t *payload, int payload_len, uint8_t *cmr, diff --git a/src/codec/gsm610.c b/src/codec/gsm610.c index 35f6011..47faea2 100644 --- a/src/codec/gsm610.c +++ b/src/codec/gsm610.c @@ -22,6 +22,10 @@ */ #include +#include + +#include +#include /* GSM FR - subjective importance bit ordering */ /* This array encodes GSM 05.03 Table 2. @@ -292,3 +296,38 @@ 11, /* LARc1:0 */ 29, /* LARc5:0 */ }; + +/*! \brief Check whether RTP frame contains FR SID code word according to + * TS 101 318 ?5.1.2 + * \param[in] rtp_payload Buffer with RTP payload + * \param[in] payload_len Length of payload + * \returns true if code word is found, false otherwise + */ +bool osmo_fr_check_sid(uint8_t *rtp_payload, size_t payload_len) +{ + struct bitvec bv; + uint16_t i, z_bits[] = { 59, 60, 62, 63, 65, 66, 68, 69, 71, 72, 74, 75, + 77, 78, 80, 81, 83, 84, 86, 87, 89, 90, 92, 93, + 95, 96, 115, 116, 118, 119, 121, 122, 124, 125, + 127, 128, 130, 131, 133, 134, 136, 137, 139, + 140, 142, 143, 145, 146, 148, 149, 151, 152, + 171, 172, 174, 175, 177, 178, 180, 181, 183, + 184, 186, 187, 189, 190, 192, 193, 195, 196, + 198, 199, 201, 202, 204, 205, 207, 208, 227, + 228, 230, 231, 233, 234, 236, 237, 239, 242, + 245, 248, 251, 254, 257, 260, 263 }; + + /* signature does not match Full Rate SID */ + if ((rtp_payload[0] >> 4) != 0xD) + return false; + + bv.data = rtp_payload; + bv.data_len = payload_len; + + /* code word is all 0 at given bits, numbered from 1 */ + for (i = 0; i < ARRAY_SIZE(z_bits); i++) + if (bitvec_get_bit_pos(&bv, z_bits[i]) != ZERO) + return false; + + return true; +} diff --git a/src/codec/gsm620.c b/src/codec/gsm620.c index f4ac9ad..6f1a95b 100644 --- a/src/codec/gsm620.c +++ b/src/codec/gsm620.c @@ -22,6 +22,10 @@ */ #include +#include + +#include +#include /* GSM HR unvoiced (mode=0) frames - subjective importance bit ordering */ /* This array encode mapping between GSM 05.03 Table 3a (bits @@ -260,3 +264,31 @@ 82, /* Code 3:6 */ 81, /* Code 3:7 */ }; + +static inline uint16_t mask(const uint8_t msb) +{ + const uint16_t m = (uint16_t)1 << (msb - 1); + return (m - 1) ^ m; +} + +/*! \brief Check whether RTP frame contains HR SID code word according to + * TS 101 318 ?5.2.2 + * \param[in] rtp_payload Buffer with RTP payload + * \param[in] payload_len Length of payload + * \returns true if code word is found, false otherwise + */ +bool osmo_hr_check_sid(uint8_t *rtp_payload, size_t payload_len) +{ + uint8_t i, bits[] = { 1, 2, 8, 9, 5, 4, 9, 5, 4, 9, 5, 4, 9, 5 }; + struct bitvec bv; + bv.data = rtp_payload; + bv.data_len = payload_len; + bv.cur_bit = 33; + + /* code word is all 1 at given bits, numbered from 1, MODE is always 3 */ + for (i = 0; i < ARRAY_SIZE(bits); i++) + if (bitvec_get_uint(&bv, bits[i]) != mask(bits[i])) + return false; + + return true; +} diff --git a/tests/codec/codec_test.c b/tests/codec/codec_test.c index 4905dd3..5b934b1 100644 --- a/tests/codec/codec_test.c +++ b/tests/codec/codec_test.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include @@ -68,6 +69,26 @@ cmpr(_cmr, cmr), cmpr(_ft, ft), cmpr(_bfi, bfi), cmi, sti); } +uint8_t fr[] = {0xd8, 0xa9, 0xb5, 0x1d, 0xda, 0xa8, 0x82, 0xcc, 0xec, 0x52, + 0x29, 0x05, 0xa8, 0xc3, 0xe3, 0x0e, 0xb0, 0x89, 0x7a, 0xee, + 0x42, 0xca, 0xc4, 0x97, 0x22, 0xe6, 0x9e, 0xa8, 0xb8, 0xec, + 0x52, 0x26, 0xbd}; +uint8_t sid_fr[] = {0xd7, 0x27, 0x93, 0xe5, 0xe3, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; + +uint8_t hr[] = {0x06, 0x46, 0x76, 0xb1, 0x8e, 0x48, 0x9a, 0x2f, 0x5e, 0x4c, + 0x22, 0x2b, 0x62, 0x25}; +uint8_t sid_hr[] = {0x03, 0x8e, 0xb6, 0xcb, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff}; + +static void test_sid_xr(uint8_t *t, size_t len, bool hr) +{ + printf("%s SID ? %s:: %d\n", hr ? "HR" : "FR", osmo_hexdump(t, len), + hr ? osmo_hr_check_sid(t, len) : osmo_fr_check_sid(t, len)); +} + int main(int argc, char **argv) { printf("AMR RTP payload decoder test:\n"); @@ -79,6 +100,13 @@ test_amr_rt(AMR_12_2, AMR_12_2, AMR_GOOD); test_amr_rt(AMR_7_40, AMR_7_40, AMR_BAD); test_amr_rt(AMR_7_40, AMR_7_40, AMR_GOOD); + printf("FR RTP payload SID test:\n"); + test_sid_xr(sid_fr, 33, false); + test_sid_xr(fr, 33, false); + + printf("HR RTP payload SID test:\n"); + test_sid_xr(sid_hr, 14, true); + test_sid_xr(hr, 14, true); return 0; } diff --git a/tests/codec/codec_test.ok b/tests/codec/codec_test.ok index 0f76fef..2af7cc7 100644 --- a/tests/codec/codec_test.ok +++ b/tests/codec/codec_test.ok @@ -7,3 +7,9 @@ [33/33] AMR 12,2 kbit/s (GSM-EFR), CMR: OK, FT: OK, BFI: OK, CMI: -1, STI: -1 [21/21] AMR 7,40 kbit/s (TDMA-EFR), CMR: OK, FT: OK, BFI: OK, CMI: -1, STI: -1 [21/21] AMR 7,40 kbit/s (TDMA-EFR), CMR: OK, FT: OK, BFI: OK, CMI: -1, STI: -1 +FR RTP payload SID test: +FR SID ? d7 27 93 e5 e3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 :: 1 +FR SID ? d8 a9 b5 1d da a8 82 cc ec 52 29 05 a8 c3 e3 0e b0 89 7a ee 42 ca c4 97 22 e6 9e a8 b8 ec 52 26 bd :: 0 +HR RTP payload SID test: +HR SID ? 03 8e b6 cb ff ff ff ff ff ff ff ff ff ff :: 1 +HR SID ? 06 46 76 b1 8e 48 9a 2f 5e 4c 22 2b 62 25 :: 0 -- To view, visit https://gerrit.osmocom.org/160 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: I4051e3c0d4fb9ee93d7e9e0ef4abaf9f18e227ca Gerrit-PatchSet: 3 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: Max Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Wed Jun 1 10:50:43 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Wed, 1 Jun 2016 10:50:43 +0000 Subject: osmo-pcu[master]: add KPI counter to count bytes for RLC and LLC frames In-Reply-To: References: Message-ID: Patch Set 2: (3 comments) https://gerrit.osmocom.org/#/c/145/2//COMMIT_MSG Commit Message: Line 9: rlc.dl_bytes bytes before sending rlc "before sending"? Doesn't 'dl' mean 'downloaded'? Line 15: it would be good to have this explanation of counter items as comment in the code instead, because it is very helpful and should not be "hidden" in a commit log. https://gerrit.osmocom.org/#/c/145/2/src/bts.cpp File src/bts.cpp: Line 79: { "rlc.ul_payload_bytes", "RLC UL Payload Bytes "}, I'd prefer if DL and UL were spelled out, because of limited space I'd shorten 'Bytes' to 'b' instead. If it's not enough space maybe use 'haul' instead of 'payload'? Or use 'recvd' and 'sent' instead of DL and UL? The item just above used 'sent', so actually we should stay with that. It is about 'sent' and 'received' bytes, isn't it? Or did I get this wrong entirely? Anyway, I'd prefer it spelled out :) -- To view, visit https://gerrit.osmocom.org/145 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I9a98a5a375d39b3f4990360056c4d6145e755f4d Gerrit-PatchSet: 2 Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Owner: lynxis lazus Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr Gerrit-HasComments: Yes From nhofmeyr at sysmocom.de Wed Jun 1 10:53:46 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 1 Jun 2016 12:53:46 +0200 Subject: Gerrit and Jenkins: merge conflict vs. +1 Verified Message-ID: <20160601105346.GA1888@dub6> On Tue, May 31, 2016 at 11:25:38AM +0000, lynxis lazus wrote: > Review at https://gerrit.osmocom.org/145 I'm confused. Gerrit says this change could not be merged. Then how on earth can Jenkins add a +1 for a successful build to it?? Something about these gerrit merge conflicts is completely wrong. I'd appreciate if we could clarify this. Any ideas on how to find out? ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From gerrit-no-reply at lists.osmocom.org Wed Jun 1 10:57:03 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 10:57:03 +0000 Subject: osmo-pcu[master]: add KPI counter to count bytes for RLC and LLC frames In-Reply-To: References: Message-ID: Patch Set 2: (2 comments) https://gerrit.osmocom.org/#/c/145/2//COMMIT_MSG Commit Message: Line 9: rlc.dl_bytes bytes before sending rlc > "before sending"? Doesn't 'dl' mean 'downloaded'? In the GSM world, DL is downlink and UL is uplink. Line 15: > it would be good to have this explanation of counter items as comment in th It belongs into the user manual, which I have also requested lynxis to do. -- To view, visit https://gerrit.osmocom.org/145 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I9a98a5a375d39b3f4990360056c4d6145e755f4d Gerrit-PatchSet: 2 Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Owner: lynxis lazus Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr Gerrit-HasComments: Yes From nhofmeyr at sysmocom.de Wed Jun 1 11:11:52 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 1 Jun 2016 13:11:52 +0200 Subject: [PATCH] openbsc[master]: rename enum gprs_mm_state to gprs_gmm_state In-Reply-To: References: Message-ID: <20160601111152.GB1888@dub6> WTF? This has +2 and +1 from Jenkins, and no "merge conflict". Yet when I click on 'submit', Gerrit says: 'Code Review - Error change is new [continue]' Also, the two following commits from the same branch were not merge conflicted yesterday after I submitted them. Today they are marked as conflict. This nonsense is really getting on my case. These commits are really trivial, yet Gerrit can't get its shit together. This is ONE LETTER! I hate it when simple tasks get overcomplicated by automation (that fails). I'm tempted to merge to master manually, but I should rather calm down and we should resolve the underlying problems, or we'll face this over and over again. I'm going to merge over 100 Iu branch commits like this, so it's worth it. I tried to search online for answers but so far I'm completely stumped. Any ideas? For now I tried to hit the 'rebase' button. Of course now I have to wait for another jenkins +1. Not sure how to handle this -- if I just +1 manually and submit, I may introduce errors. If I don't, this might race indefinitely, while other changes get merged to master I have to repeatedly rebase and wait for jenkins, and my change may never merge, however simple it is. Also, every single patch sitting in the queue has to be rebased all the time, apparently. Really? Again, any ideas? ~Neels On Tue, May 31, 2016 at 11:53:26AM +0000, Neels Hofmeyr wrote: > > Review at https://gerrit.osmocom.org/157 > > rename enum gprs_mm_state to gprs_gmm_state > > Change-Id: Ibba054d15c55c7ac570e64ff66ea57964be095e3 > --- > M openbsc/include/openbsc/gprs_sgsn.h > 1 file changed, 2 insertions(+), 2 deletions(-) > > > git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/57/157/1 > > diff --git a/openbsc/include/openbsc/gprs_sgsn.h b/openbsc/include/openbsc/gprs_sgsn.h > index 898b7a5..5fbbf28 100644 > --- a/openbsc/include/openbsc/gprs_sgsn.h > +++ b/openbsc/include/openbsc/gprs_sgsn.h > @@ -23,7 +23,7 @@ > enum gsm48_gsm_cause; > > /* TS 04.08 4.1.3.3 GMM mobility management states on the network side */ > -enum gprs_mm_state { > +enum gprs_gmm_state { > GMM_DEREGISTERED, /* 4.1.3.3.1.1 */ > GMM_COMMON_PROC_INIT, /* 4.1.3.3.1.2 */ > GMM_REGISTERED_NORMAL, /* 4.1.3.3.2.1 */ > @@ -98,7 +98,7 @@ > struct llist_head list; > > char imsi[GSM23003_IMSI_MAX_DIGITS+1]; > - enum gprs_mm_state mm_state; > + enum gprs_gmm_state mm_state; > uint32_t p_tmsi; > uint32_t p_tmsi_old; /* old P-TMSI before new is confirmed */ > uint32_t p_tmsi_sig; > > -- > To view, visit https://gerrit.osmocom.org/157 > To unsubscribe, visit https://gerrit.osmocom.org/settings > > Gerrit-MessageType: newchange > Gerrit-Change-Id: Ibba054d15c55c7ac570e64ff66ea57964be095e3 > Gerrit-PatchSet: 1 > Gerrit-Project: openbsc > Gerrit-Branch: master > Gerrit-Owner: Neels Hofmeyr > Gerrit-Reviewer: daniel -- - Neels Hofmeyr 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From gerrit-no-reply at lists.osmocom.org Wed Jun 1 11:14:42 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Wed, 1 Jun 2016 11:14:42 +0000 Subject: osmo-pcu[master]: RFC: remove this == NULL checks In-Reply-To: References: Message-ID: Patch Set 1: all checks of (this == null) will be eliminated by GCC >= 6.1 (https://gcc.gnu.org/gcc-6/changes.html, Value range propagation now assumes that the this pointer of C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop). As a temporary work-around -fno-delete-null-pointer-checks can be used. Wrong code can be identified by using -fsanitize=undefined.) But given the "make check" failure we seem to expect that. You will need to move the null check before calling the function or create a method wrapper where the tbf pointer is passed so we can do the null check there. -- To view, visit https://gerrit.osmocom.org/136 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ifddaef70bb0a4402050c817b1000d515c3a7118b Gerrit-PatchSet: 1 Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Owner: lynxis lazus Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Wed Jun 1 12:02:01 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 12:02:01 +0000 Subject: [PATCH] libosmocore[master]: osmo-auc-gen: Print hex values without intermittent spaces Message-ID: Review at https://gerrit.osmocom.org/164 osmo-auc-gen: Print hex values without intermittent spaces When generating some authentication vectors using the osmo-auc-gen utility, it used to print values like this: AUTN: f7 55 bc 47 de d0 00 00 f9 ed 4b 3f 6c 2a 97 6f which is quite difficult to copy+paste on the terminal. Now it generates the following format: Change-Id: I2805615e0c2087ca632e0658b37a9e06929620b6 AUTN: f755bc47ded00000f9ed4b3f6c2a976f --- M utils/osmo-auc-gen.c 1 file changed, 7 insertions(+), 7 deletions(-) git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/64/164/1 diff --git a/utils/osmo-auc-gen.c b/utils/osmo-auc-gen.c index b026e28..3b3e557 100644 --- a/utils/osmo-auc-gen.c +++ b/utils/osmo-auc-gen.c @@ -48,18 +48,18 @@ static void dump_auth_vec(struct osmo_auth_vector *vec) { - printf("RAND:\t%s\n", osmo_hexdump(vec->rand, sizeof(vec->rand))); + printf("RAND:\t%s\n", osmo_hexdump_nospc(vec->rand, sizeof(vec->rand))); if (vec->auth_types & OSMO_AUTH_TYPE_UMTS) { - printf("AUTN:\t%s\n", osmo_hexdump(vec->autn, sizeof(vec->autn))); - printf("IK:\t%s\n", osmo_hexdump(vec->ik, sizeof(vec->ik))); - printf("CK:\t%s\n", osmo_hexdump(vec->ck, sizeof(vec->ck))); - printf("RES:\t%s\n", osmo_hexdump(vec->res, vec->res_len)); + printf("AUTN:\t%s\n", osmo_hexdump_nospc(vec->autn, sizeof(vec->autn))); + printf("IK:\t%s\n", osmo_hexdump_nospc(vec->ik, sizeof(vec->ik))); + printf("CK:\t%s\n", osmo_hexdump_nospc(vec->ck, sizeof(vec->ck))); + printf("RES:\t%s\n", osmo_hexdump_nospc(vec->res, vec->res_len)); } if (vec->auth_types & OSMO_AUTH_TYPE_GSM) { - printf("SRES:\t%s\n", osmo_hexdump(vec->sres, sizeof(vec->sres))); - printf("Kc:\t%s\n", osmo_hexdump(vec->kc, sizeof(vec->kc))); + printf("SRES:\t%s\n", osmo_hexdump_nospc(vec->sres, sizeof(vec->sres))); + printf("Kc:\t%s\n", osmo_hexdump_nospc(vec->kc, sizeof(vec->kc))); } } -- To view, visit https://gerrit.osmocom.org/164 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I2805615e0c2087ca632e0658b37a9e06929620b6 Gerrit-PatchSet: 1 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: Harald Welte From gerrit-no-reply at lists.osmocom.org Wed Jun 1 12:02:16 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 12:02:16 +0000 Subject: libosmocore[master]: osmo-auc-gen: Print hex values without intermittent spaces In-Reply-To: References: Message-ID: Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/164 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I2805615e0c2087ca632e0658b37a9e06929620b6 Gerrit-PatchSet: 1 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Wed Jun 1 12:08:17 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Wed, 1 Jun 2016 12:08:17 +0000 Subject: [MERGED] openbsc[master]: rename enum gprs_mm_state to gprs_gmm_state In-Reply-To: References: Message-ID: Neels Hofmeyr has submitted this change and it was merged. Change subject: rename enum gprs_mm_state to gprs_gmm_state ...................................................................... rename enum gprs_mm_state to gprs_gmm_state Change-Id: Ibba054d15c55c7ac570e64ff66ea57964be095e3 --- 0 files changed, 0 insertions(+), 0 deletions(-) Approvals: Neels Hofmeyr: Looks good to me, approved Jenkins Builder: Verified -- To view, visit https://gerrit.osmocom.org/157 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: Ibba054d15c55c7ac570e64ff66ea57964be095e3 Gerrit-PatchSet: 2 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr Gerrit-Reviewer: daniel From gerrit-no-reply at lists.osmocom.org Wed Jun 1 12:10:41 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 12:10:41 +0000 Subject: [MERGED] libosmocore[master]: osmo-auc-gen: Print hex values without intermittent spaces In-Reply-To: References: Message-ID: Harald Welte has submitted this change and it was merged. Change subject: osmo-auc-gen: Print hex values without intermittent spaces ...................................................................... osmo-auc-gen: Print hex values without intermittent spaces When generating some authentication vectors using the osmo-auc-gen utility, it used to print values like this: AUTN: f7 55 bc 47 de d0 00 00 f9 ed 4b 3f 6c 2a 97 6f which is quite difficult to copy+paste on the terminal. Now it generates the following format: Change-Id: I2805615e0c2087ca632e0658b37a9e06929620b6 AUTN: f755bc47ded00000f9ed4b3f6c2a976f Reviewed-on: https://gerrit.osmocom.org/164 Reviewed-by: Harald Welte Tested-by: Jenkins Builder --- M utils/osmo-auc-gen.c 1 file changed, 7 insertions(+), 7 deletions(-) Approvals: Harald Welte: Looks good to me, approved Jenkins Builder: Verified diff --git a/utils/osmo-auc-gen.c b/utils/osmo-auc-gen.c index b026e28..3b3e557 100644 --- a/utils/osmo-auc-gen.c +++ b/utils/osmo-auc-gen.c @@ -48,18 +48,18 @@ static void dump_auth_vec(struct osmo_auth_vector *vec) { - printf("RAND:\t%s\n", osmo_hexdump(vec->rand, sizeof(vec->rand))); + printf("RAND:\t%s\n", osmo_hexdump_nospc(vec->rand, sizeof(vec->rand))); if (vec->auth_types & OSMO_AUTH_TYPE_UMTS) { - printf("AUTN:\t%s\n", osmo_hexdump(vec->autn, sizeof(vec->autn))); - printf("IK:\t%s\n", osmo_hexdump(vec->ik, sizeof(vec->ik))); - printf("CK:\t%s\n", osmo_hexdump(vec->ck, sizeof(vec->ck))); - printf("RES:\t%s\n", osmo_hexdump(vec->res, vec->res_len)); + printf("AUTN:\t%s\n", osmo_hexdump_nospc(vec->autn, sizeof(vec->autn))); + printf("IK:\t%s\n", osmo_hexdump_nospc(vec->ik, sizeof(vec->ik))); + printf("CK:\t%s\n", osmo_hexdump_nospc(vec->ck, sizeof(vec->ck))); + printf("RES:\t%s\n", osmo_hexdump_nospc(vec->res, vec->res_len)); } if (vec->auth_types & OSMO_AUTH_TYPE_GSM) { - printf("SRES:\t%s\n", osmo_hexdump(vec->sres, sizeof(vec->sres))); - printf("Kc:\t%s\n", osmo_hexdump(vec->kc, sizeof(vec->kc))); + printf("SRES:\t%s\n", osmo_hexdump_nospc(vec->sres, sizeof(vec->sres))); + printf("Kc:\t%s\n", osmo_hexdump_nospc(vec->kc, sizeof(vec->kc))); } } -- To view, visit https://gerrit.osmocom.org/164 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: I2805615e0c2087ca632e0658b37a9e06929620b6 Gerrit-PatchSet: 2 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder From holger at freyther.de Wed Jun 1 12:17:02 2016 From: holger at freyther.de (Holger Freyther) Date: Wed, 1 Jun 2016 14:17:02 +0200 Subject: [PATCH] openbsc[master]: rename enum gprs_mm_state to gprs_gmm_state In-Reply-To: <20160601111152.GB1888@dub6> References: <20160601111152.GB1888@dub6> Message-ID: > On 01 Jun 2016, at 13:11, Neels Hofmeyr wrote: Hi! > This nonsense is really getting on my case. These commits are really trivial, > yet Gerrit can't get its shit together. This is ONE LETTER! > I hate it when simple tasks get overcomplicated by automation (that fails). your super negative attitude is super annoying too. I don't have to spend time reviewing, so please go back to patchwork and be happy (but I remember your cursing about setting up a MTA as well). holger From nhofmeyr at sysmocom.de Wed Jun 1 12:21:52 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 1 Jun 2016 14:21:52 +0200 Subject: Gerrit: submitting a branch Message-ID: <20160601122152.GA3191@dub6> So after some blood boiling to my head (sorry about that), I hit rebase, waited for jenkins and then the change could be merged. Next I have to hit rebase on all following commits submitted from the same branch. It would be nice if Gerrit could have the series of branch commits in-a-row and rebase them together in one flush, especially since they depend on each other. Also I find it hard to see the intended sequence of branch commits. The sorting of patches changes by updating the patch submission, so the branch commits in the Gerrit UI are potentially re-ordered regularly. Would it make sense to locally merge the branch to master and submit the resulting merge-commit for review instead? Then Gerrit would treat it as a single patch, yet the merge commit could contain any number of "sub" commits? It would also be nice if Gerrit didn't complain about merge conflicts that are in fact no merge conflicts -- I'm stumped on that topic. Any help would be appreciated. Sorry again and thanks for any hints! ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From gerrit-no-reply at lists.osmocom.org Wed Jun 1 12:28:38 2016 From: gerrit-no-reply at lists.osmocom.org (Max) Date: Wed, 1 Jun 2016 12:28:38 +0000 Subject: openbsc[master]: sgsn: fix use of libosmocore GPRS encryption plugins from LL... In-Reply-To: References: Message-ID: Patch Set 1: Code-Review-1 Instead of casting uint8_t *kc to uint64_t and back we should use it directly. Also the size of kc in gprs-llc_llme should be adjusted to accommodate for GEA4. Related ticket: OS#1582 -- To view, visit https://gerrit.osmocom.org/128 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I1f1b7454a0de5b7f4734aca4d03dbe67db5de189 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Max Gerrit-Reviewer: Neels Hofmeyr Gerrit-HasComments: No From holger at freyther.de Wed Jun 1 12:29:05 2016 From: holger at freyther.de (Holger Freyther) Date: Wed, 1 Jun 2016 14:29:05 +0200 Subject: Stopping Gerrit on Sunday Message-ID: <729756F1-18FF-4893-8618-CDA990E9834B@freyther.de> Hi Guys, I am a bit fed-up to have to receive Neels non-productive mails every single day and given my tight work schedule let's have him win, declare Gerrit a failure and return to patchwork. The twist is that I am no longer willing to clean behind everyone on the patchwork UI. So somebody else needs to sign-up for the patch merging and gardening in the WebUI. My proposal would be: * Sunday morning we change all ACLs (no more pushes, no more merges/submits/reviews) * Luckily we have all patches in our patchwork and can continue from there. agreed? holger From gerrit-no-reply at lists.osmocom.org Wed Jun 1 13:37:51 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 13:37:51 +0000 Subject: [MERGED] openbsc[master]: prepare sgsn_mm_ctx for Gb and Iu mode (UMTS) In-Reply-To: References: Message-ID: Harald Welte has submitted this change and it was merged. Change subject: prepare sgsn_mm_ctx for Gb and Iu mode (UMTS) ...................................................................... prepare sgsn_mm_ctx for Gb and Iu mode (UMTS) Explicitly mark those sgsn_mm_ctx members that apply for Gb mode and (upcoming) Iu mode, respectively. Add some comments in sgsn_mm_ctx. Change-Id: Ife9b02549f284e2547f16117cf43d7a36948fc4b Tweaked-By: Neels Hofmeyr --- M openbsc/include/openbsc/gprs_sgsn.h M openbsc/src/gprs/gprs_gmm.c M openbsc/src/gprs/gprs_llc.c M openbsc/src/gprs/gprs_sgsn.c M openbsc/src/gprs/sgsn_cdr.c M openbsc/src/gprs/sgsn_libgtp.c M openbsc/src/gprs/sgsn_vty.c M openbsc/tests/sgsn/sgsn_test.c 8 files changed, 135 insertions(+), 86 deletions(-) Approvals: Harald Welte: Looks good to me, approved Jenkins Builder: Verified diff --git a/openbsc/include/openbsc/gprs_sgsn.h b/openbsc/include/openbsc/gprs_sgsn.h index 5fbbf28..0e574d8 100644 --- a/openbsc/include/openbsc/gprs_sgsn.h +++ b/openbsc/include/openbsc/gprs_sgsn.h @@ -92,10 +92,28 @@ uint8_t ti; }; +enum sgsn_ran_type { + /* GPRS/EDGE via Gb */ + MM_CTX_T_GERAN_Gb, + /* UMTS via Iu */ + MM_CTX_T_UTRAN_Iu, + /* GPRS/EDGE via Iu */ + MM_CTX_T_GERAN_Iu, +}; + +struct service_info { + uint8_t type; + uint16_t pdp_status; +}; + +struct ue_conn_ctx; + /* According to TS 03.60, Table 5: SGSN MM and PDP Contexts */ /* Extended by 3GPP TS 23.060, Table 6: SGSN MM and PDP Contexts */ struct sgsn_mm_ctx { struct llist_head list; + + enum sgsn_ran_type ran_type; char imsi[GSM23003_IMSI_MAX_DIGITS+1]; enum gprs_gmm_state mm_state; @@ -106,10 +124,32 @@ /* Opt: Software Version Numbber / TS 23.195 */ char msisdn[GSM_EXTENSION_LENGTH]; struct gprs_ra_id ra; - uint16_t cell_id; - uint32_t cell_id_age; - uint16_t sac; /* Iu: Service Area Code */ - uint32_t sac_age;/* Iu: Service Area Code age */ + struct { + uint16_t cell_id; /* Gb only */ + uint32_t cell_id_age; /* Gb only */ + uint8_t radio_prio_sms; + + /* Additional bits not present in the GSM TS */ + uint16_t nsei; + uint16_t bvci; + struct gprs_llc_llme *llme; + uint32_t tlli; + uint32_t tlli_new; + } gb; + struct { + int new_key; + uint16_t sac; /* Iu: Service Area Code */ + uint32_t sac_age; /* Iu: Service Area Code age */ + /* CSG ID */ + /* CSG Membership */ + /* Access Mode */ + /* Seelected CN Operator ID (TS 23.251) */ + /* CSG Subscription Data */ + /* LIPA Allowed */ + /* Voice Support Match Indicator */ + struct ue_conn_ctx *ue_ctx; + struct service_info service; + } iu; /* VLR number */ uint32_t new_sgsn_addr; /* Authentication Triplet */ @@ -118,30 +158,38 @@ /* Iu: CK, IK, KSI */ /* CKSN */ enum gprs_ciph_algo ciph_algo; + struct { uint8_t len; uint8_t buf[50]; /* GSM 04.08 10.5.5.12a, extended in TS 24.008 */ } ms_radio_access_capa; + /* Supported Codecs (SRVCC) */ struct { uint8_t len; uint8_t buf[8]; /* GSM 04.08 10.5.5.12, extended in TS 24.008 */ } ms_network_capa; + /* UE Netowrk Capability (E-UTRAN) */ uint16_t drx_parms; + /* Active Time value for PSM */ int mnrg; /* MS reported to HLR? */ int ngaf; /* MS reported to MSC/VLR? */ int ppf; /* paging for GPRS + non-GPRS? */ + /* Subscribed Charging Characteristics */ + /* Trace Reference */ + /* Trace Type */ + /* Trigger ID */ + /* OMC Identity */ /* SMS Parameters */ int recovery; - uint8_t radio_prio_sms; + /* Access Restriction */ + /* GPRS CSI (CAMEL) */ + /* MG-CSI (CAMEL) */ + /* Subscribed UE-AMBR */ + /* UE-AMBR */ + /* APN Subscribed */ struct llist_head pdp_list; - /* Additional bits not present in the GSM TS */ - struct gprs_llc_llme *llme; - uint32_t tlli; - uint32_t tlli_new; - uint16_t nsei; - uint16_t bvci; struct rate_ctr_group *ctrg; struct osmo_timer_list timer; unsigned int T; /* Txxxx number */ diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index 2bbc5ff..889ac98 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -151,16 +151,16 @@ /* Store BVCI/NSEI in MM context */ static void msgid2mmctx(struct sgsn_mm_ctx *mm, const struct msgb *msg) { - mm->bvci = msgb_bvci(msg); - mm->nsei = msgb_nsei(msg); + mm->gb.bvci = msgb_bvci(msg); + mm->gb.nsei = msgb_nsei(msg); } /* Store BVCI/NSEI in MM context */ static void mmctx2msgid(struct msgb *msg, const struct sgsn_mm_ctx *mm) { - msgb_tlli(msg) = mm->tlli; - msgb_bvci(msg) = mm->bvci; - msgb_nsei(msg) = mm->nsei; + msgb_tlli(msg) = mm->gb.tlli; + msgb_bvci(msg) = mm->gb.bvci; + msgb_nsei(msg) = mm->gb.nsei; } static void mm_ctx_cleanup_free(struct sgsn_mm_ctx *ctx, const char *log_text) @@ -904,8 +904,8 @@ strncpy(ctx->imsi, mi_string, sizeof(ctx->imsi) - 1); #endif } - ctx->tlli = msgb_tlli(msg); - ctx->llme = llme; + ctx->gb.tlli = msgb_tlli(msg); + ctx->gb.llme = llme; msgid2mmctx(ctx, msg); break; case GSM_MI_TYPE_TMSI: @@ -920,8 +920,8 @@ ctx = sgsn_mm_ctx_alloc(msgb_tlli(msg), &ra_id); ctx->p_tmsi = tmsi; } - ctx->tlli = msgb_tlli(msg); - ctx->llme = llme; + ctx->gb.tlli = msgb_tlli(msg); + ctx->gb.llme = llme; msgid2mmctx(ctx, msg); break; default: @@ -932,7 +932,7 @@ } /* Update MM Context with currient RA and Cell ID */ ctx->ra = ra_id; - ctx->cell_id = cid; + ctx->gb.cell_id = cid; /* Update MM Context with other data */ ctx->drx_parms = drx_par; ctx->ms_radio_access_capa.len = ms_ra_acc_cap_len; @@ -952,10 +952,10 @@ #endif /* Even if there is no P-TMSI allocated, the MS will switch from * foreign TLLI to local TLLI */ - ctx->tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL); + ctx->gb.tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL); /* Inform LLC layer about new TLLI but keep old active */ - gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new, + gprs_llgmm_assign(ctx->gb.llme, ctx->gb.tlli, ctx->gb.tlli_new, GPRS_ALGO_GEA0, NULL); ctx->pending_req = GSM48_MT_GMM_ATTACH_REQ; @@ -1182,7 +1182,7 @@ "TLLI: %08x (%08x), RA: %d-%d-%d-%d\n", msgb_tlli(msg), mmctx->p_tmsi, mmctx->p_tmsi_old, - mmctx->tlli, mmctx->tlli_new, + mmctx->gb.tlli, mmctx->gb.tlli_new, mmctx->ra.mcc, mmctx->ra.mnc, mmctx->ra.lac, mmctx->ra.rac); @@ -1219,7 +1219,7 @@ /* Update the MM context with the new RA-ID */ bssgp_parse_cell_id(&mmctx->ra, msgb_bcid(msg)); /* Update the MM context with the new (i.e. foreign) TLLI */ - mmctx->tlli = msgb_tlli(msg); + mmctx->gb.tlli = msgb_tlli(msg); /* FIXME: Update the MM context with the MS radio acc capabilities */ /* FIXME: Update the MM context with the MS network capabilities */ @@ -1246,10 +1246,10 @@ #endif /* Even if there is no P-TMSI allocated, the MS will switch from * foreign TLLI to local TLLI */ - mmctx->tlli_new = gprs_tmsi2tlli(mmctx->p_tmsi, TLLI_LOCAL); + mmctx->gb.tlli_new = gprs_tmsi2tlli(mmctx->p_tmsi, TLLI_LOCAL); /* Inform LLC layer about new TLLI but keep old active */ - gprs_llgmm_assign(mmctx->llme, mmctx->tlli, mmctx->tlli_new, + gprs_llgmm_assign(mmctx->gb.llme, mmctx->gb.tlli, mmctx->gb.tlli_new, GPRS_ALGO_GEA0, NULL); /* Look at PDP Context Status IE and see if MS's view of @@ -1369,8 +1369,8 @@ mmctx->p_tmsi_old = 0; mmctx->pending_req = 0; /* Unassign the old TLLI */ - mmctx->tlli = mmctx->tlli_new; - gprs_llgmm_assign(mmctx->llme, 0xffffffff, mmctx->tlli_new, + mmctx->gb.tlli = mmctx->gb.tlli_new; + gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, GPRS_ALGO_GEA0, NULL); mmctx->mm_state = GMM_REGISTERED_NORMAL; rc = 0; @@ -1387,8 +1387,8 @@ mmctx->p_tmsi_old = 0; mmctx->pending_req = 0; /* Unassign the old TLLI */ - mmctx->tlli = mmctx->tlli_new; - gprs_llgmm_assign(mmctx->llme, 0xffffffff, mmctx->tlli_new, + mmctx->gb.tlli = mmctx->gb.tlli_new; + gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, GPRS_ALGO_GEA0, NULL); mmctx->mm_state = GMM_REGISTERED_NORMAL; rc = 0; @@ -1404,8 +1404,8 @@ mmctx->p_tmsi_old = 0; mmctx->pending_req = 0; /* Unassign the old TLLI */ - mmctx->tlli = mmctx->tlli_new; - //gprs_llgmm_assign(mmctx->llme, 0xffffffff, mmctx->tlli_new, GPRS_ALGO_GEA0, NULL); + mmctx->gb.tlli = mmctx->gb.tlli_new; + //gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, GPRS_ALGO_GEA0, NULL); rc = 0; break; case GSM48_MT_GMM_AUTH_CIPH_RESP: @@ -2077,7 +2077,7 @@ int gsm0408_gprs_force_reattach(struct sgsn_mm_ctx *mmctx) { int rc; - gprs_llgmm_reset(mmctx->llme); + gprs_llgmm_reset(mmctx->gb.llme); rc = gsm48_tx_gmm_detach_req( mmctx, GPRS_DET_T_MT_REATT_REQ, GMM_CAUSE_IMPL_DETACHED); @@ -2101,7 +2101,7 @@ if (mmctx) { msgid2mmctx(mmctx, msg); rate_ctr_inc(&mmctx->ctrg->ctr[GMM_CTR_PKTS_SIG_IN]); - mmctx->llme = llme; + mmctx->gb.llme = llme; } /* MMCTX can be NULL */ diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index 883f0cc..4d21963 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -56,8 +56,8 @@ dup.ms_ra_cap.v = mmctx->ms_radio_access_capa.buf; /* make sure we only send it to the right llme */ - OSMO_ASSERT(msgb_tlli(msg) == mmctx->llme->tlli - || msgb_tlli(msg) == mmctx->llme->old_tlli); + OSMO_ASSERT(msgb_tlli(msg) == mmctx->gb.llme->tlli + || msgb_tlli(msg) == mmctx->gb.llme->old_tlli); } memcpy(&dup.qos_profile, qos_profile_default, sizeof(qos_profile_default)); diff --git a/openbsc/src/gprs/gprs_sgsn.c b/openbsc/src/gprs/gprs_sgsn.c index 65f789d..8bb6850 100644 --- a/openbsc/src/gprs/gprs_sgsn.c +++ b/openbsc/src/gprs/gprs_sgsn.c @@ -97,7 +97,7 @@ struct sgsn_mm_ctx *ctx; llist_for_each_entry(ctx, &sgsn_mm_ctxts, list) { - if ((tlli == ctx->tlli || tlli == ctx->tlli_new) && + if ((tlli == ctx->gb.tlli || tlli == ctx->gb.tlli_new) && gprs_ra_id_equals(raid, &ctx->ra)) return ctx; } @@ -165,7 +165,8 @@ return NULL; memcpy(&ctx->ra, raid, sizeof(ctx->ra)); - ctx->tlli = tlli; + ctx->ran_type = MM_CTX_T_GERAN_Gb; + ctx->gb.tlli = tlli; ctx->mm_state = GMM_DEREGISTERED; ctx->auth_triplet.key_seq = GSM_KEY_SEQ_INVAL; ctx->ctrg = rate_ctr_group_alloc(ctx, &mmctx_ctrg_desc, tlli); @@ -196,8 +197,8 @@ void sgsn_mm_ctx_cleanup_free(struct sgsn_mm_ctx *mm) { - struct gprs_llc_llme *llme = mm->llme; - uint32_t tlli = mm->tlli; + struct gprs_llc_llme *llme = mm->gb.llme; + uint32_t tlli = mm->gb.tlli; struct sgsn_pdp_ctx *pdp, *pdp2; struct sgsn_signal_data sig_data; @@ -308,7 +309,7 @@ LOGPDPCTXP(LOGL_INFO, pdp, "Forcing release of PDP context\n"); /* Force the deactivation of the SNDCP layer */ - sndcp_sm_deactivate_ind(&pdp->mm->llme->lle[pdp->sapi], pdp->nsapi); + sndcp_sm_deactivate_ind(&pdp->mm->gb.llme->lle[pdp->sapi], pdp->nsapi); memset(&sig_data, 0, sizeof(sig_data)); sig_data.pdp = pdp; @@ -751,7 +752,7 @@ struct sgsn_mm_ctx *mmctx = NULL; llist_for_each_entry(mmctx, &sgsn_mm_ctxts, list) { - if (llme == mmctx->llme) { + if (llme == mmctx->gb.llme) { gsm0408_gprs_access_cancelled(mmctx, SGSN_ERROR_CAUSE_NONE); return; } diff --git a/openbsc/src/gprs/sgsn_cdr.c b/openbsc/src/gprs/sgsn_cdr.c index d0cb712..bf0d6f7 100644 --- a/openbsc/src/gprs/sgsn_cdr.c +++ b/openbsc/src/gprs/sgsn_cdr.c @@ -94,7 +94,7 @@ mmctx->imsi, mmctx->imei, mmctx->msisdn, - mmctx->cell_id, + mmctx->gb.cell_id, mmctx->ra.lac, mmctx->hlr, ev); @@ -179,7 +179,7 @@ pdp->mm ? pdp->mm->imsi : "N/A", pdp->mm ? pdp->mm->imei : "N/A", pdp->mm ? pdp->mm->msisdn : "N/A", - pdp->mm ? pdp->mm->cell_id : -1, + pdp->mm ? pdp->mm->gb.cell_id : -1, pdp->mm ? pdp->mm->ra.lac : -1, pdp->mm ? pdp->mm->hlr : "N/A", ev, diff --git a/openbsc/src/gprs/sgsn_libgtp.c b/openbsc/src/gprs/sgsn_libgtp.c index aaf7e7a..f7a4ca0 100644 --- a/openbsc/src/gprs/sgsn_libgtp.c +++ b/openbsc/src/gprs/sgsn_libgtp.c @@ -239,7 +239,7 @@ pdp->userloc_given = 1; pdp->userloc.l = 8; pdp->userloc.v[0] = 0; /* CGI for GERAN */ - bssgp_create_cell_id(&pdp->userloc.v[1], &mmctx->ra, mmctx->cell_id); + bssgp_create_cell_id(&pdp->userloc.v[1], &mmctx->ra, mmctx->gb.cell_id); /* include the IMEI(SV) */ pdp->imeisv_given = 1; @@ -341,7 +341,7 @@ } /* Activate the SNDCP layer */ - sndcp_sm_activate_ind(&pctx->mm->llme->lle[pctx->sapi], pctx->nsapi); + sndcp_sm_activate_ind(&pctx->mm->gb.llme->lle[pctx->sapi], pctx->nsapi); /* Inform others about it */ memset(&sig_data, 0, sizeof(sig_data)); @@ -388,7 +388,7 @@ if (pctx->mm) { /* Deactivate the SNDCP layer */ - sndcp_sm_deactivate_ind(&pctx->mm->llme->lle[pctx->sapi], pctx->nsapi); + sndcp_sm_deactivate_ind(&pctx->mm->gb.llme->lle[pctx->sapi], pctx->nsapi); /* Confirm deactivation of PDP context to MS */ rc = gsm48_tx_gsm_deact_pdp_acc(pctx); @@ -521,9 +521,9 @@ ud = msgb_put(msg, len); memcpy(ud, packet, len); - msgb_tlli(msg) = mm->tlli; - msgb_bvci(msg) = mm->bvci; - msgb_nsei(msg) = mm->nsei; + msgb_tlli(msg) = mm->gb.tlli; + msgb_bvci(msg) = mm->gb.bvci; + msgb_nsei(msg) = mm->gb.nsei; switch (mm->mm_state) { case GMM_REGISTERED_SUSPENDED: @@ -531,12 +531,12 @@ memset(&pinfo, 0, sizeof(pinfo)); pinfo.mode = BSSGP_PAGING_PS; pinfo.scope = BSSGP_PAGING_BVCI; - pinfo.bvci = mm->bvci; + pinfo.bvci = mm->gb.bvci; pinfo.imsi = mm->imsi; pinfo.ptmsi = &mm->p_tmsi; pinfo.drx_params = mm->drx_parms; pinfo.qos[0] = 0; // FIXME - bssgp_tx_paging(mm->nsei, 0, &pinfo); + bssgp_tx_paging(mm->gb.nsei, 0, &pinfo); rate_ctr_inc(&mm->ctrg->ctr[GMM_CTR_PAGING_PS]); /* FIXME: queue the packet we received from GTP */ break; @@ -544,7 +544,7 @@ break; default: LOGP(DGPRS, LOGL_ERROR, "GTP DATA IND for TLLI %08X in state " - "%u\n", mm->tlli, mm->mm_state); + "%u\n", mm->gb.tlli, mm->mm_state); msgb_free(msg); return -1; } @@ -557,7 +557,7 @@ /* It is easier to have a global count */ pdp->cdr_bytes_out += len; - return sndcp_unitdata_req(msg, &mm->llme->lle[pdp->sapi], + return sndcp_unitdata_req(msg, &mm->gb.llme->lle[pdp->sapi], pdp->nsapi, mm); } diff --git a/openbsc/src/gprs/sgsn_vty.c b/openbsc/src/gprs/sgsn_vty.c index f16c95a..02c0f31 100644 --- a/openbsc/src/gprs/sgsn_vty.c +++ b/openbsc/src/gprs/sgsn_vty.c @@ -431,12 +431,12 @@ vty_out(vty, "%sMM Context for IMSI %s, IMEI %s, P-TMSI %08x%s", pfx, mm->imsi, mm->imei, mm->p_tmsi, VTY_NEWLINE); vty_out(vty, "%s MSISDN: %s, TLLI: %08x%s HLR: %s", - pfx, mm->msisdn, mm->tlli, mm->hlr, VTY_NEWLINE); + pfx, mm->msisdn, mm->gb.tlli, mm->hlr, VTY_NEWLINE); vty_out(vty, "%s MM State: %s, Routeing Area: %u-%u-%u-%u, " "Cell ID: %u%s", pfx, get_value_string(gprs_mm_st_strs, mm->mm_state), mm->ra.mcc, mm->ra.mnc, mm->ra.lac, mm->ra.rac, - mm->cell_id, VTY_NEWLINE); + mm->gb.cell_id, VTY_NEWLINE); vty_out_rate_ctr_group(vty, " ", mm->ctrg); diff --git a/openbsc/tests/sgsn/sgsn_test.c b/openbsc/tests/sgsn/sgsn_test.c index afff30f..3fb359b 100644 --- a/openbsc/tests/sgsn/sgsn_test.c +++ b/openbsc/tests/sgsn/sgsn_test.c @@ -174,7 +174,7 @@ lle = gprs_lle_get_or_create(tlli, 3); ctx = sgsn_mm_ctx_alloc(tlli, raid); ctx->mm_state = GMM_REGISTERED_NORMAL; - ctx->llme = lle->llme; + ctx->gb.llme = lle->llme; ictx = sgsn_mm_ctx_by_tlli(tlli, raid); OSMO_ASSERT(ictx == ctx); @@ -729,7 +729,7 @@ ctx = alloc_mm_ctx(local_tlli, &raid); /* inject the detach */ - send_0408_message(ctx->llme, local_tlli, &raid, + send_0408_message(ctx->gb.llme, local_tlli, &raid, detach_req, ARRAY_SIZE(detach_req)); /* verify that a single message (hopefully the Detach Accept) has been @@ -770,7 +770,7 @@ ctx = alloc_mm_ctx(local_tlli, &raid); /* inject the detach */ - send_0408_message(ctx->llme, local_tlli, &raid, + send_0408_message(ctx->gb.llme, local_tlli, &raid, detach_req, ARRAY_SIZE(detach_req)); /* verify that no message (and therefore no Detach Accept) has been @@ -967,14 +967,14 @@ OSMO_ASSERT(sgsn_tx_counter == 1); /* inject the identity response (IMEI) */ - send_0408_message(ctx->llme, foreign_tlli, &raid, + send_0408_message(ctx->gb.llme, foreign_tlli, &raid, ident_resp_imei, ARRAY_SIZE(ident_resp_imei)); /* we expect an identity request (IMSI) */ OSMO_ASSERT(sgsn_tx_counter == 1); /* inject the identity response (IMSI) */ - send_0408_message(ctx->llme, foreign_tlli, &raid, + send_0408_message(ctx->gb.llme, foreign_tlli, &raid, ident_resp_imsi, ARRAY_SIZE(ident_resp_imsi)); /* check that the MM context has not been removed due to a failed @@ -996,7 +996,7 @@ /* we got an auth & ciph request */ /* inject the auth & ciph response */ - send_0408_message(ctx->llme, foreign_tlli, &raid, + send_0408_message(ctx->gb.llme, foreign_tlli, &raid, auth_ciph_resp, ARRAY_SIZE(auth_ciph_resp)); /* check that the MM context has not been removed due to a @@ -1018,7 +1018,7 @@ local_tlli = gprs_tmsi2tlli(ptmsi1, TLLI_LOCAL); /* inject the attach complete */ - send_0408_message(ctx->llme, local_tlli, &raid, + send_0408_message(ctx->gb.llme, local_tlli, &raid, attach_compl, ARRAY_SIZE(attach_compl)); OSMO_ASSERT(ctx->mm_state == GMM_REGISTERED_NORMAL); @@ -1027,7 +1027,7 @@ OSMO_ASSERT(sgsn_tx_counter == 0); /* inject the detach */ - send_0408_message(ctx->llme, local_tlli, &raid, + send_0408_message(ctx->gb.llme, local_tlli, &raid, detach_req, ARRAY_SIZE(detach_req)); /* verify that things are gone */ @@ -1555,14 +1555,14 @@ OSMO_ASSERT(sgsn_tx_counter == 1); /* inject the identity response (IMEI) */ - send_0408_message(ctx->llme, foreign_tlli, &raid, + send_0408_message(ctx->gb.llme, foreign_tlli, &raid, ident_resp_imei, ARRAY_SIZE(ident_resp_imei)); /* we expect an identity request (IMSI) */ OSMO_ASSERT(sgsn_tx_counter == 1); /* inject the identity response (IMSI) */ - send_0408_message(ctx->llme, foreign_tlli, &raid, + send_0408_message(ctx->gb.llme, foreign_tlli, &raid, ident_resp_imsi, ARRAY_SIZE(ident_resp_imsi)); /* check that the MM context has not been removed due to a failed @@ -1580,7 +1580,7 @@ local_tlli = gprs_tmsi2tlli(ptmsi1, TLLI_LOCAL); /* inject the attach complete */ - send_0408_message(ctx->llme, local_tlli, &raid, + send_0408_message(ctx->gb.llme, foreign_tlli, &raid, attach_compl, ARRAY_SIZE(attach_compl)); OSMO_ASSERT(ctx->mm_state == GMM_REGISTERED_NORMAL); @@ -1707,7 +1707,7 @@ OSMO_ASSERT(sgsn_tx_counter == 1); /* inject the identity response (IMEI) */ - send_0408_message(ctx->llme, foreign_tlli, &raid, + send_0408_message(ctx->gb.llme, foreign_tlli, &raid, ident_resp_imei, ARRAY_SIZE(ident_resp_imei)); /* check that the MM context has not been removed due to a failed @@ -1740,7 +1740,7 @@ /* inject the attach complete */ local_tlli = gprs_tmsi2tlli(ptmsi1, TLLI_LOCAL); - send_0408_message(ctx->llme, local_tlli, &raid, + send_0408_message(ctx->gb.llme, local_tlli, &raid, attach_compl, ARRAY_SIZE(attach_compl)); /* we don't expect a response */ @@ -1753,7 +1753,7 @@ printf(" - Repeated RA Update Request\n"); /* inject the RA update request */ - send_0408_message(ctx->llme, local_tlli, &raid, + send_0408_message(ctx->gb.llme, local_tlli, &raid, ra_upd_req, ARRAY_SIZE(ra_upd_req)); /* we expect an RA update accept */ @@ -1766,7 +1766,7 @@ ptmsi2 = ctx->p_tmsi; /* repeat the RA update request */ - send_0408_message(ctx->llme, local_tlli, &raid, + send_0408_message(ctx->gb.llme, local_tlli, &raid, ra_upd_req, ARRAY_SIZE(ra_upd_req)); /* we expect an RA update accept */ @@ -1780,7 +1780,7 @@ /* inject the RA update complete */ local_tlli = gprs_tmsi2tlli(ptmsi2, TLLI_LOCAL); - send_0408_message(ctx->llme, local_tlli, &raid, + send_0408_message(ctx->gb.llme, local_tlli, &raid, ra_upd_complete, ARRAY_SIZE(ra_upd_complete)); /* we don't expect a response */ @@ -1791,7 +1791,7 @@ OSMO_ASSERT(ctx->p_tmsi == ptmsi2); /* inject the detach */ - send_0408_message(ctx->llme, local_tlli, &raid, + send_0408_message(ctx->gb.llme, local_tlli, &raid, detach_req, ARRAY_SIZE(detach_req)); /* verify that things are gone */ @@ -1931,7 +1931,7 @@ OSMO_ASSERT(last_dl_parse_ctx.tlli == ms_tlli); /* inject the identity response (IMEI) */ - send_0408_message(ctx->llme, ms_tlli, &raid1, + send_0408_message(ctx->gb.llme, ms_tlli, &raid1, ident_resp_imei, ARRAY_SIZE(ident_resp_imei)); /* check that the MM context has not been removed due to a failed @@ -1951,7 +1951,7 @@ /* inject the attach complete */ ms_tlli = gprs_tmsi2tlli(ptmsi1, TLLI_LOCAL); - send_0408_message(ctx->llme, ms_tlli, &raid1, + send_0408_message(ctx->gb.llme, ms_tlli, &raid1, attach_compl, ARRAY_SIZE(attach_compl)); /* we don't expect a response */ @@ -1964,7 +1964,7 @@ printf(" - RA Update Request (RA 1 -> RA 1)\n"); /* inject the RA update request */ - send_0408_message(ctx->llme, ms_tlli, &raid1, + send_0408_message(ctx->gb.llme, ms_tlli, &raid1, ra_upd_req1, ARRAY_SIZE(ra_upd_req1)); /* we expect an RA update accept */ @@ -1983,7 +1983,7 @@ /* inject the RA update complete */ ms_tlli = gprs_tmsi2tlli(ptmsi1, TLLI_LOCAL); - send_0408_message(ctx->llme, ms_tlli, &raid1, + send_0408_message(ctx->gb.llme, ms_tlli, &raid1, ra_upd_complete, ARRAY_SIZE(ra_upd_complete)); /* we don't expect a response */ @@ -1992,7 +1992,7 @@ OSMO_ASSERT(ctx->mm_state == GMM_REGISTERED_NORMAL); OSMO_ASSERT(ctx->p_tmsi_old == 0); OSMO_ASSERT(ctx->p_tmsi == ptmsi1); - OSMO_ASSERT(ctx->tlli == ms_tlli); + OSMO_ASSERT(ctx->gb.tlli == ms_tlli); printf(" - RA Update Request (RA 1 -> RA 2)\n"); @@ -2000,7 +2000,7 @@ ms_tlli = gprs_tmsi2tlli(ptmsi1, TLLI_FOREIGN); /* It is coming from RA 1 => ra_upd_req1 */ - send_0408_message(ctx->llme, ms_tlli, &raid2, + send_0408_message(ctx->gb.llme, ms_tlli, &raid2, ra_upd_req1, ARRAY_SIZE(ra_upd_req1)); /* we expect an RA update accept */ @@ -2013,7 +2013,7 @@ ms_tlli = gprs_tmsi2tlli(0x12345678, TLLI_FOREIGN); /* It is coming from RA 1 => ra_upd_req1 */ - send_0408_message(ctx->llme, ms_tlli, &raid2, + send_0408_message(ctx->gb.llme, ms_tlli, &raid2, ra_upd_req_other, ARRAY_SIZE(ra_upd_req_other)); /* we expect an RA update reject (and a LLC XID RESET) */ @@ -2051,7 +2051,7 @@ OSMO_ASSERT(ictx != NULL); OSMO_ASSERT(ictx == ctx); - send_0408_message(ctx->llme, ms_tlli, &raid2, + send_0408_message(ctx->gb.llme, ms_tlli, &raid2, attach_compl, ARRAY_SIZE(attach_compl)); /* we don't expect a response */ @@ -2064,7 +2064,7 @@ printf(" - RA Update Request (RA 2 -> RA 2)\n"); /* inject the RA update request */ - send_0408_message(ctx->llme, ms_tlli, &raid2, + send_0408_message(ctx->gb.llme, ms_tlli, &raid2, ra_upd_req2, ARRAY_SIZE(ra_upd_req2)); /* we expect an RA update accept */ @@ -2082,7 +2082,7 @@ /* inject the RA update complete */ ms_tlli = gprs_tmsi2tlli(ptmsi1, TLLI_LOCAL); - send_0408_message(ctx->llme, ms_tlli, &raid2, + send_0408_message(ctx->gb.llme, ms_tlli, &raid2, ra_upd_complete, ARRAY_SIZE(ra_upd_complete)); /* we don't expect a response */ @@ -2091,11 +2091,11 @@ OSMO_ASSERT(ctx->mm_state == GMM_REGISTERED_NORMAL); OSMO_ASSERT(ctx->p_tmsi_old == 0); OSMO_ASSERT(ctx->p_tmsi == ptmsi1); - OSMO_ASSERT(ctx->tlli == ms_tlli); + OSMO_ASSERT(ctx->gb.tlli == ms_tlli); /* inject the detach */ - send_0408_message(ctx->llme, ms_tlli, &raid2, + send_0408_message(ctx->gb.llme, ms_tlli, &raid2, detach_req, ARRAY_SIZE(detach_req)); /* verify that things are gone */ -- To view, visit https://gerrit.osmocom.org/158 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: Ife9b02549f284e2547f16117cf43d7a36948fc4b Gerrit-PatchSet: 2 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Wed Jun 1 13:38:00 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 13:38:00 +0000 Subject: [MERGED] openbsc[master]: create_pdp_conf(): factor out PDP context accept dispatch as... In-Reply-To: References: Message-ID: Harald Welte has submitted this change and it was merged. Change subject: create_pdp_conf(): factor out PDP context accept dispatch as send_act_pdp_cont_acc() ...................................................................... create_pdp_conf(): factor out PDP context accept dispatch as send_act_pdp_cont_acc() Change-Id: Ibf60e18707ff4aa2e60291e5595386ddda8d8190 --- M openbsc/src/gprs/sgsn_libgtp.c 1 file changed, 14 insertions(+), 9 deletions(-) Approvals: Harald Welte: Looks good to me, approved Jenkins Builder: Verified diff --git a/openbsc/src/gprs/sgsn_libgtp.c b/openbsc/src/gprs/sgsn_libgtp.c index f7a4ca0..504590b 100644 --- a/openbsc/src/gprs/sgsn_libgtp.c +++ b/openbsc/src/gprs/sgsn_libgtp.c @@ -304,10 +304,22 @@ { 0, 0 } }; +static int send_act_pdp_cont_acc(struct sgsn_pdp_ctx *pctx) +{ + struct sgsn_signal_data sig_data; + + /* Inform others about it */ + memset(&sig_data, 0, sizeof(sig_data)); + sig_data.pdp = pctx; + osmo_signal_dispatch(SS_SGSN, S_SGSN_PDP_ACT, &sig_data); + + /* Send PDP CTX ACT to MS */ + return gsm48_tx_gsm_act_pdp_acc(pctx); +} + /* The GGSN has confirmed the creation of a PDP Context */ static int create_pdp_conf(struct pdp_t *pdp, void *cbp, int cause) { - struct sgsn_signal_data sig_data; struct sgsn_pdp_ctx *pctx = cbp; uint8_t reject_cause; @@ -342,14 +354,7 @@ /* Activate the SNDCP layer */ sndcp_sm_activate_ind(&pctx->mm->gb.llme->lle[pctx->sapi], pctx->nsapi); - - /* Inform others about it */ - memset(&sig_data, 0, sizeof(sig_data)); - sig_data.pdp = pctx; - osmo_signal_dispatch(SS_SGSN, S_SGSN_PDP_ACT, &sig_data); - - /* Send PDP CTX ACT to MS */ - return gsm48_tx_gsm_act_pdp_acc(pctx); + return send_act_pdp_cont_acc(pctx); reject: /* -- To view, visit https://gerrit.osmocom.org/159 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: Ibf60e18707ff4aa2e60291e5595386ddda8d8190 Gerrit-PatchSet: 2 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: daniel From gerrit-no-reply at lists.osmocom.org Wed Jun 1 13:38:28 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 13:38:28 +0000 Subject: [MERGED] osmo-pcu[master]: rlc.h: correct gprs_rlc_data comment In-Reply-To: References: Message-ID: Harald Welte has submitted this change and it was merged. Change subject: rlc.h: correct gprs_rlc_data comment ...................................................................... rlc.h: correct gprs_rlc_data comment It's the block data, not the history. Also add including LI headers. Change-Id: Id4d99d1d21c7fa372771fd569d87bbcf2c6b6d22 Reviewed-on: https://gerrit.osmocom.org/144 Reviewed-by: Harald Welte Tested-by: Jenkins Builder --- M src/rlc.h 1 file changed, 2 insertions(+), 2 deletions(-) Approvals: Harald Welte: Looks good to me, approved Jenkins Builder: Verified diff --git a/src/rlc.h b/src/rlc.h index 03659da..ad10b3a 100644 --- a/src/rlc.h +++ b/src/rlc.h @@ -113,9 +113,9 @@ uint8_t *prepare(size_t block_data_length); void put_data(const uint8_t *data, size_t len); - /* block history */ + /* block data including LI headers */ uint8_t block[RLC_MAX_LEN]; - /* block len of history */ + /* block data len including LI headers*/ uint8_t len; struct gprs_rlc_data_block_info block_info; -- To view, visit https://gerrit.osmocom.org/144 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: Id4d99d1d21c7fa372771fd569d87bbcf2c6b6d22 Gerrit-PatchSet: 3 Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Owner: lynxis lazus Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Wed Jun 1 13:38:35 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 13:38:35 +0000 Subject: [MERGED] osmo-pcu[master]: decoding: remove superfluous double-semicolon In-Reply-To: References: Message-ID: Harald Welte has submitted this change and it was merged. Change subject: decoding: remove superfluous double-semicolon ...................................................................... decoding: remove superfluous double-semicolon Change-Id: I48ec24f2e10620279cbcbf39c70a4be6438f6b0f Reviewed-on: https://gerrit.osmocom.org/140 Reviewed-by: Harald Welte Tested-by: Jenkins Builder --- M src/decoding.cpp 1 file changed, 1 insertion(+), 1 deletion(-) Approvals: Harald Welte: Looks good to me, approved Jenkins Builder: Verified diff --git a/src/decoding.cpp b/src/decoding.cpp index 5f64ac0..2600879 100644 --- a/src/decoding.cpp +++ b/src/decoding.cpp @@ -267,7 +267,7 @@ * so drop it (this may happen with EGPRS since * there is no M flag. */ num_chunks -= 1; - break;; + break; } chunks[i].length = data_len - offs; } -- To view, visit https://gerrit.osmocom.org/140 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: I48ec24f2e10620279cbcbf39c70a4be6438f6b0f Gerrit-PatchSet: 3 Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Owner: lynxis lazus Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Wed Jun 1 13:57:26 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 13:57:26 +0000 Subject: osmo-pcu[master]: add KPI counter to count bytes for RLC and LLC frames In-Reply-To: References: Message-ID: Patch Set 2: (1 comment) https://gerrit.osmocom.org/#/c/145/2/src/bts.cpp File src/bts.cpp: Line 79: { "rlc.ul_payload_bytes", "RLC UL Payload Bytes "}, > I'd prefer if DL and UL were spelled out, As indicated, UL and DL have quite fixed meaning inside the cellular world, and we use them in various places. Unlike Rx and Tx, UL and DL are well-defined and don't depend on the point-of-view of the observer. Rx of the MS is different than Rx of the PCU. PCU Rx from Um interface is different direction than Rx frm SGSN on Gb interface, so that's very confusing. UL and DL leave no room for (mis)interpretation. -- To view, visit https://gerrit.osmocom.org/145 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I9a98a5a375d39b3f4990360056c4d6145e755f4d Gerrit-PatchSet: 2 Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Owner: lynxis lazus Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr Gerrit-HasComments: Yes From gerrit-no-reply at lists.osmocom.org Wed Jun 1 13:58:29 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Wed, 1 Jun 2016 13:58:29 +0000 Subject: libosmocore[master]: add vty call show asciidoc: generate a documentation for cou... In-Reply-To: References: Message-ID: Patch Set 1: Please add escaping of the strings as requested, so we can get this merged ASAP. -- To view, visit https://gerrit.osmocom.org/70 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia8af883167e5ee631059299b107ea83c8bbffdfb Gerrit-PatchSet: 1 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: lynxis lazus Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: lynxis lazus Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Wed Jun 1 14:53:38 2016 From: gerrit-no-reply at lists.osmocom.org (lynxis lazus) Date: Wed, 1 Jun 2016 14:53:38 +0000 Subject: osmo-pcu[master]: RFC: remove this == NULL checks In-Reply-To: References: Message-ID: Patch Set 1: > all checks of (this == null) will be eliminated by GCC >= 6.1 > (https://gcc.gnu.org/gcc-6/changes.html, Value range propagation > now assumes that the this pointer of C++ member functions is > non-null. This eliminates common null pointer checks but also > breaks some non-conforming code-bases (such as Qt-5, Chromium, > KDevelop). As a temporary work-around -fno-delete-null-pointer-checks > can be used. Wrong code can be identified by using > -fsanitize=undefined.) > > But given the "make check" failure we seem to expect that. You will > need to move the null check before calling the function or create a > method wrapper where the tbf pointer is passed so we can do the > null check there. thanks for the explanation. this is also the reason, why make check fails on my laptop. gcc --version gcc (GCC) 6.1.1 20160501 -- To view, visit https://gerrit.osmocom.org/136 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ifddaef70bb0a4402050c817b1000d515c3a7118b Gerrit-PatchSet: 1 Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Owner: lynxis lazus Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr Gerrit-Reviewer: lynxis lazus Gerrit-HasComments: No From msuraev at sysmocom.de Wed Jun 1 15:18:57 2016 From: msuraev at sysmocom.de (Max) Date: Wed, 1 Jun 2016 17:18:57 +0200 Subject: speech frame loss compensation Message-ID: <574EFCE1.1020304@sysmocom.de> Hi. Right now in osmobts when sending/receiving frames with osmo_rtp_* it's assumed that no frame is lost and timestamp is always advanced in 160ms steps. In practice (especially when DTX is in place) frames do get lost so we have to adjust the step to compensate. I've tried to do it as follows: - store frame number of last used frame on receiving/sending - check how far current frame number from old one - convert frame number delta to ms: each frame is 4.615 ms long - if delta in ms is bigger than default 160 than use it However the result sound not much better than using hardcoded value which suggest that I might be doing FN -> ms conversion (or smth else) wrong. Any ideas/advices? -- Max Suraev 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 From msuraev at sysmocom.de Wed Jun 1 16:01:59 2016 From: msuraev at sysmocom.de (Max) Date: Wed, 1 Jun 2016 18:01:59 +0200 Subject: Stopping Gerrit on Sunday In-Reply-To: <729756F1-18FF-4893-8618-CDA990E9834B@freyther.de> References: <729756F1-18FF-4893-8618-CDA990E9834B@freyther.de> Message-ID: <574F06F7.5080000@sysmocom.de> Hi. I don't think hasty decisions would benefit anyone. Personally I favor gerrit over patchwork because it's easier for me to grab particular patch, fix it and than send back for review with gerrit taking care of versioning, jenkins (re)test etc. I also have an impression that gerrit gives better overview of awaiting patches which decrease the chance that some patch would be "lost" in ML. -- Max Suraev 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 From a.cudbardb at freeradius.org Wed Jun 1 16:36:11 2016 From: a.cudbardb at freeradius.org (Arran Cudbard-Bell) Date: Wed, 1 Jun 2016 12:36:11 -0400 Subject: Stopping Gerrit on Sunday In-Reply-To: <574F06F7.5080000@sysmocom.de> References: <729756F1-18FF-4893-8618-CDA990E9834B@freyther.de> <574F06F7.5080000@sysmocom.de> Message-ID: > On Jun 1, 2016, at 12:01 PM, Max wrote: > > Hi. > > I don't think hasty decisions would benefit anyone. Personally I favor > gerrit over patchwork because it's easier for me to grab particular > patch, fix it and than send back for review with gerrit taking care of > versioning, jenkins (re)test etc. I also have an impression that gerrit > gives better overview of awaiting patches which decrease the chance that > some patch would be "lost" in ML. +1 If you're not going to be convinced to transition to evil proprietary closed software, Gerrit is pretty nice for patch submitters and does seem to offer good CI integration and overviews. There are some serious advantages to GitHub, beyond ease of use and efficiency though. You can see where we transitioned (Early 2010) from just mailing list patches to using GitHub. https://www.openhub.net/p/freeradius (See contributors Per Month graph) -Arran Arran Cudbard-Bell FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From holger at freyther.de Wed Jun 1 18:37:47 2016 From: holger at freyther.de (Holger Freyther) Date: Wed, 1 Jun 2016 20:37:47 +0200 Subject: speech frame loss compensation In-Reply-To: <574EFCE1.1020304@sysmocom.de> References: <574EFCE1.1020304@sysmocom.de> Message-ID: <742AC70C-F66B-4519-B996-045E9F589528@freyther.de> > On 01 Jun 2016, at 17:18, Max wrote: > > Hi. > > Right now in osmobts when sending/receiving frames with osmo_rtp_* it's > assumed that no frame is lost and timestamp is always advanced in 160ms > steps. In practice (especially when DTX is in place) frames do get lost > so we have to adjust the step to compensate. > > However the result sound not much better than using hardcoded value > which suggest that I might be doing FN -> ms conversion (or smth else) > wrong. Any ideas/advices? Don't do it. I don't find the relevant spec within the time frame I had but I think I recently saw a piece of documentation that SQN (and timestamp) should only be incremented if data is being sent. Either in the RTP RFC, RTP AMR RFC or the A over IP spec.. I think I saw it while going through the documents Harald had pointed while I introduced my ideas for the SIP connector. holger From alexander.chemeris at gmail.com Wed Jun 1 19:51:47 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 1 Jun 2016 22:51:47 +0300 Subject: speech frame loss compensation In-Reply-To: References: <574EFCE1.1020304@sysmocom.de> <742AC70C-F66B-4519-B996-045E9F589528@freyther.de> Message-ID: On Jun 1, 2016 9:37 PM, "Holger Freyther" wrote: > > > > On 01 Jun 2016, at 17:18, Max wrote: > > > > Hi. > > > > > Right now in osmobts when sending/receiving frames with osmo_rtp_* it's > > assumed that no frame is lost and timestamp is always advanced in 160ms > > steps. In practice (especially when DTX is in place) frames do get lost > > so we have to adjust the step to compensate. > > > > > > However the result sound not much better than using hardcoded value > > which suggest that I might be doing FN -> ms conversion (or smth else) > > wrong. Any ideas/advices? > > Don't do it. I don't find the relevant spec within the time frame I had but I think I recently saw a piece of documentation that SQN (and timestamp) should only be incremented if data is being sent. > > Either in the RTP RFC, RTP AMR RFC or the A over IP spec.. I think I saw it while going through the documents Harald had pointed while I introduced my ideas for the SIP connector. > It's in the RTP RFC. Sequence number is incremented by 1 with every packet, even if the packet is sent after a long pause (due to DTX). This way you know when you miss a packet. Timestamp is measured in samples and this is incremented by a number of samples since the last packet. This way you know when to start playing the packet in case of DTX. A proper RTP library or rather a jitter buffer should handle this automatically, but I'm not sure how does ortp handle it. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerrit-no-reply at lists.osmocom.org Wed Jun 1 23:44:34 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Wed, 1 Jun 2016 23:44:34 +0000 Subject: [PATCH] openbsc[master]: TEST commit, outdated without conflict Message-ID: Review at https://gerrit.osmocom.org/165 TEST commit, outdated without conflict Change-Id: I534719345e271876f562e5a6fe3f959f27dede19 --- M openbsc/src/libcommon/gsm_data.c M openbsc/src/libmsc/db.c 2 files changed, 3 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/65/165/1 diff --git a/openbsc/src/libcommon/gsm_data.c b/openbsc/src/libcommon/gsm_data.c index 4e235fd..24b6845 100644 --- a/openbsc/src/libcommon/gsm_data.c +++ b/openbsc/src/libcommon/gsm_data.c @@ -17,6 +17,7 @@ * */ +/* Another test change */ #include #include diff --git a/openbsc/src/libmsc/db.c b/openbsc/src/libmsc/db.c index b3235bb..df807f7 100644 --- a/openbsc/src/libmsc/db.c +++ b/openbsc/src/libmsc/db.c @@ -19,6 +19,8 @@ * */ +/* FOO MOO GOO */ + #include #include #include -- To view, visit https://gerrit.osmocom.org/165 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I534719345e271876f562e5a6fe3f959f27dede19 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Wed Jun 1 23:44:34 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Wed, 1 Jun 2016 23:44:34 +0000 Subject: [PATCH] openbsc[master]: TEST commit, outdated without conflict, newest in branch Message-ID: Review at https://gerrit.osmocom.org/166 TEST commit, outdated without conflict, newest in branch Change-Id: I451e65ce261ff55ca3b7a8bc7f08c71e20924eec --- M openbsc/src/libmsc/db.c 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/66/166/1 diff --git a/openbsc/src/libmsc/db.c b/openbsc/src/libmsc/db.c index df807f7..f93462e 100644 --- a/openbsc/src/libmsc/db.c +++ b/openbsc/src/libmsc/db.c @@ -19,7 +19,7 @@ * */ -/* FOO MOO GOO */ +/* FOO MOO GOO test 123 */ #include #include -- To view, visit https://gerrit.osmocom.org/166 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I451e65ce261ff55ca3b7a8bc7f08c71e20924eec Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Wed Jun 1 23:48:11 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Wed, 1 Jun 2016 23:48:11 +0000 Subject: openbsc[master]: TEST commit, outdated without conflict, newest in branch In-Reply-To: References: Message-ID: Patch Set 1: test comment -- To view, visit https://gerrit.osmocom.org/166 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I451e65ce261ff55ca3b7a8bc7f08c71e20924eec Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Neels Hofmeyr Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Wed Jun 1 23:48:28 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Wed, 1 Jun 2016 23:48:28 +0000 Subject: openbsc[master]: TEST commit, outdated without conflict In-Reply-To: References: Message-ID: Patch Set 1: Code-Review-1 test comment -- To view, visit https://gerrit.osmocom.org/165 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I534719345e271876f562e5a6fe3f959f27dede19 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Wed Jun 1 23:49:18 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Wed, 1 Jun 2016 23:49:18 +0000 Subject: openbsc[master]: TEST commit, outdated without conflict In-Reply-To: References: Message-ID: Patch Set 1: -Code-Review comment -- To view, visit https://gerrit.osmocom.org/165 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I534719345e271876f562e5a6fe3f959f27dede19 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Thu Jun 2 00:26:22 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 00:26:22 +0000 Subject: [PATCH] openbsc[master]: rename gsm0408_gprs_rcvmsg() to gsm0408_gprs_rcvmsg_gb() Message-ID: Review at https://gerrit.osmocom.org/167 rename gsm0408_gprs_rcvmsg() to gsm0408_gprs_rcvmsg_gb() This is the entry point for GMM from Gb. We will create a new one for Iu, so let's be explicit rather than implicit. Change-Id: I3457080e5a0af6329907d68fa4ae4db9b89a76c3 --- M openbsc/include/openbsc/gprs_gmm.h M openbsc/src/gprs/gprs_gmm.c M openbsc/src/gprs/gprs_llc.c M openbsc/tests/sgsn/sgsn_test.c 4 files changed, 5 insertions(+), 5 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/67/167/1 diff --git a/openbsc/include/openbsc/gprs_gmm.h b/openbsc/include/openbsc/gprs_gmm.h index 702b9b9..e0d8f77 100644 --- a/openbsc/include/openbsc/gprs_gmm.h +++ b/openbsc/include/openbsc/gprs_gmm.h @@ -10,7 +10,7 @@ int gsm48_tx_gsm_act_pdp_acc(struct sgsn_pdp_ctx *pdp); int gsm48_tx_gsm_deact_pdp_acc(struct sgsn_pdp_ctx *pdp); -int gsm0408_gprs_rcvmsg(struct msgb *msg, struct gprs_llc_llme *llme); +int gsm0408_gprs_rcvmsg_gb(struct msgb *msg, struct gprs_llc_llme *llme); int gsm0408_gprs_force_reattach(struct sgsn_mm_ctx *mmctx); int gsm0408_gprs_force_reattach_oldmsg(struct msgb *msg); void gsm0408_gprs_access_granted(struct sgsn_mm_ctx *mmctx); diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index 889ac98..1e10701 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -2087,8 +2087,8 @@ return rc; } -/* Main entry point for incoming 04.08 GPRS messages */ -int gsm0408_gprs_rcvmsg(struct msgb *msg, struct gprs_llc_llme *llme) +/* Main entry point for incoming 04.08 GPRS messages from Gb */ +int gsm0408_gprs_rcvmsg_gb(struct msgb *msg, struct gprs_llc_llme *llme) { struct gsm48_hdr *gh = (struct gsm48_hdr *) msgb_gmmh(msg); uint8_t pdisc = gsm48_hdr_pdisc(gh); diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index 4d21963..71178c9 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -663,7 +663,7 @@ switch (llhp.sapi) { case GPRS_SAPI_GMM: /* send LL_UNITDATA_IND to GMM */ - rc = gsm0408_gprs_rcvmsg(msg, lle->llme); + rc = gsm0408_gprs_rcvmsg_gb(msg, lle->llme); break; case GPRS_SAPI_SNDCP3: case GPRS_SAPI_SNDCP5: diff --git a/openbsc/tests/sgsn/sgsn_test.c b/openbsc/tests/sgsn/sgsn_test.c index 3fb359b..48f013d 100644 --- a/openbsc/tests/sgsn/sgsn_test.c +++ b/openbsc/tests/sgsn/sgsn_test.c @@ -196,7 +196,7 @@ msg = create_msg(data, data_len); msgb_tlli(msg) = tlli; bssgp_create_cell_id(msgb_bcid(msg), bssgp_raid, 0); - gsm0408_gprs_rcvmsg(msg, llme); + gsm0408_gprs_rcvmsg_gb(msg, llme); msgb_free(msg); } -- To view, visit https://gerrit.osmocom.org/167 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I3457080e5a0af6329907d68fa4ae4db9b89a76c3 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte From gerrit-no-reply at lists.osmocom.org Thu Jun 2 00:26:22 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 00:26:22 +0000 Subject: [PATCH] openbsc[master]: gprs_gmm.c: Don't try to de-reference NULL mmctx Message-ID: Review at https://gerrit.osmocom.org/168 gprs_gmm.c: Don't try to de-reference NULL mmctx There was a comment in the code that certain GMM messages require a valid mmctx pointer. However, nothing actually checked if that pointer was in fact non-NULL. We plainly crashed if a MS would send us the wrong message in the wrong state. Original patch by Harald Welte, but it broke message validity checking, resulting in sgsn_test failure. This re-implements the NULL check in a different way, as explained by in-code comment. Change-Id: I34b47b9e63691c9bc9904573000c74877217f679 --- M openbsc/src/gprs/gprs_gmm.c 1 file changed, 32 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/68/168/1 diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index 1e10701..e788e3d 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -1339,6 +1339,15 @@ return rc; } + /* + * For a few messages, mmctx may be NULL. For most, we want to ensure a + * non-NULL mmctx. At the same time, we want to keep the message + * validity check intact, so that all message types appear in the + * switch statement and the default case thus means "unknown message". + * If we split the switch in two parts to check non-NULL halfway, the + * unknown-message check breaks, or we'd need to duplicate the switch + * cases in both parts. Just keep one large switch and add some gotos. + */ switch (gh->msg_type) { case GSM48_MT_GMM_RA_UPD_REQ: rc = gsm48_rx_gmm_ra_upd_req(mmctx, msg, llme); @@ -1348,20 +1357,30 @@ break; /* For all the following types mmctx can not be NULL */ case GSM48_MT_GMM_ID_RESP: + if (!mmctx) + goto null_mmctx; rc = gsm48_rx_gmm_id_resp(mmctx, msg); break; case GSM48_MT_GMM_STATUS: + if (!mmctx) + goto null_mmctx; rc = gsm48_rx_gmm_status(mmctx, msg); break; case GSM48_MT_GMM_DETACH_REQ: + if (!mmctx) + goto null_mmctx; rc = gsm48_rx_gmm_det_req(mmctx, msg); break; case GSM48_MT_GMM_DETACH_ACK: + if (!mmctx) + goto null_mmctx; LOGMMCTXP(LOGL_INFO, mmctx, "-> DETACH ACK\n"); mm_ctx_cleanup_free(mmctx, "GPRS DETACH ACK"); rc = 0; break; case GSM48_MT_GMM_ATTACH_COMPL: + if (!mmctx) + goto null_mmctx; /* only in case SGSN offered new P-TMSI */ LOGMMCTXP(LOGL_INFO, mmctx, "-> ATTACH COMPLETE\n"); mmctx_timer_stop(mmctx, 3350); @@ -1380,6 +1399,8 @@ osmo_signal_dispatch(SS_SGSN, S_SGSN_ATTACH, &sig_data); break; case GSM48_MT_GMM_RA_UPD_COMPL: + if (!mmctx) + goto null_mmctx; /* only in case SGSN offered new P-TMSI */ LOGMMCTXP(LOGL_INFO, mmctx, "-> ROUTING AREA UPDATE COMPLETE\n"); mmctx_timer_stop(mmctx, 3350); @@ -1398,6 +1419,8 @@ osmo_signal_dispatch(SS_SGSN, S_SGSN_UPDATE, &sig_data); break; case GSM48_MT_GMM_PTMSI_REALL_COMPL: + if (!mmctx) + goto null_mmctx; LOGMMCTXP(LOGL_INFO, mmctx, "-> PTMSI REALLLICATION COMPLETE\n"); mmctx_timer_stop(mmctx, 3350); mmctx->t3350_mode = GMM_T3350_MODE_NONE; @@ -1409,6 +1432,8 @@ rc = 0; break; case GSM48_MT_GMM_AUTH_CIPH_RESP: + if (!mmctx) + goto null_mmctx; rc = gsm48_rx_gmm_auth_ciph_resp(mmctx, msg); break; default: @@ -1419,6 +1444,13 @@ } return rc; + +null_mmctx: + LOGP(DMM, LOGL_ERROR, + "Received GSM 04.08 message type 0x%02x," + " but no MM context available\n", + gh->msg_type); + return -EINVAL; } static void mmctx_timer_cb(void *_mm) -- To view, visit https://gerrit.osmocom.org/168 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I34b47b9e63691c9bc9904573000c74877217f679 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Thu Jun 2 00:26:22 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 00:26:22 +0000 Subject: [PATCH] openbsc[master]: gprs_gmm.c: Make TLLI handling specific to Gb interface Message-ID: Review at https://gerrit.osmocom.org/169 gprs_gmm.c: Make TLLI handling specific to Gb interface Soem of the operations we perform in the GMM layer are specific to the GPRS/EDGE radio access network and its Gb interface. Let's make them conditional to that in preparation of supporting an Iu interface. Change-Id: I02e83dcae05673158884ae88a48f1c108d28f5a2 --- M openbsc/src/gprs/gprs_gmm.c 1 file changed, 59 insertions(+), 35 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/69/169/1 diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index e788e3d..d521342 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -904,8 +904,10 @@ strncpy(ctx->imsi, mi_string, sizeof(ctx->imsi) - 1); #endif } - ctx->gb.tlli = msgb_tlli(msg); - ctx->gb.llme = llme; + if (ctx->ran_type == MM_CTX_T_GERAN_Gb) { + ctx->gb.tlli = msgb_tlli(msg); + ctx->gb.llme = llme; + } msgid2mmctx(ctx, msg); break; case GSM_MI_TYPE_TMSI: @@ -920,8 +922,10 @@ ctx = sgsn_mm_ctx_alloc(msgb_tlli(msg), &ra_id); ctx->p_tmsi = tmsi; } - ctx->gb.tlli = msgb_tlli(msg); - ctx->gb.llme = llme; + if (ctx->ran_type == MM_CTX_T_GERAN_Gb) { + ctx->gb.tlli = msgb_tlli(msg); + ctx->gb.llme = llme; + } msgid2mmctx(ctx, msg); break; default: @@ -932,7 +936,8 @@ } /* Update MM Context with currient RA and Cell ID */ ctx->ra = ra_id; - ctx->gb.cell_id = cid; + if (ctx->ran_type == MM_CTX_T_GERAN_Gb) + ctx->gb.cell_id = cid; /* Update MM Context with other data */ ctx->drx_parms = drx_par; ctx->ms_radio_access_capa.len = ms_ra_acc_cap_len; @@ -950,13 +955,16 @@ } ctx->mm_state = GMM_COMMON_PROC_INIT; #endif - /* Even if there is no P-TMSI allocated, the MS will switch from - * foreign TLLI to local TLLI */ - ctx->gb.tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL); - /* Inform LLC layer about new TLLI but keep old active */ - gprs_llgmm_assign(ctx->gb.llme, ctx->gb.tlli, ctx->gb.tlli_new, - GPRS_ALGO_GEA0, NULL); + if (ctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Even if there is no P-TMSI allocated, the MS will + * switch from foreign TLLI to local TLLI */ + ctx->gb.tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL); + + /* Inform LLC layer about new TLLI but keep old active */ + gprs_llgmm_assign(ctx->gb.llme, ctx->gb.tlli, ctx->gb.tlli_new, + GPRS_ALGO_GEA0, NULL); + } ctx->pending_req = GSM48_MT_GMM_ATTACH_REQ; return gsm48_gmm_authorize(ctx); @@ -1218,8 +1226,10 @@ /* Update the MM context with the new RA-ID */ bssgp_parse_cell_id(&mmctx->ra, msgb_bcid(msg)); - /* Update the MM context with the new (i.e. foreign) TLLI */ - mmctx->gb.tlli = msgb_tlli(msg); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Update the MM context with the new (i.e. foreign) TLLI */ + mmctx->gb.tlli = msgb_tlli(msg); + } /* FIXME: Update the MM context with the MS radio acc capabilities */ /* FIXME: Update the MM context with the MS network capabilities */ @@ -1244,13 +1254,16 @@ sig_data.mm = mmctx; osmo_signal_dispatch(SS_SGSN, S_SGSN_UPDATE, &sig_data); #endif - /* Even if there is no P-TMSI allocated, the MS will switch from - * foreign TLLI to local TLLI */ - mmctx->gb.tlli_new = gprs_tmsi2tlli(mmctx->p_tmsi, TLLI_LOCAL); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Even if there is no P-TMSI allocated, the MS will switch from + * foreign TLLI to local TLLI */ + mmctx->gb.tlli_new = gprs_tmsi2tlli(mmctx->p_tmsi, TLLI_LOCAL); - /* Inform LLC layer about new TLLI but keep old active */ - gprs_llgmm_assign(mmctx->gb.llme, mmctx->gb.tlli, mmctx->gb.tlli_new, - GPRS_ALGO_GEA0, NULL); + /* Inform LLC layer about new TLLI but keep old active */ + gprs_llgmm_assign(mmctx->gb.llme, mmctx->gb.tlli, + mmctx->gb.tlli_new, GPRS_ALGO_GEA0, + NULL); + } /* Look at PDP Context Status IE and see if MS's view of * activated/deactivated NSAPIs agrees with our view */ @@ -1270,10 +1283,13 @@ rc = gsm48_tx_gmm_ra_upd_rej(msg, reject_cause); if (mmctx) mm_ctx_cleanup_free(mmctx, "GPRS RA UPDATE REJ"); - else - /* TLLI unassignment */ - gprs_llgmm_assign(llme, llme->tlli, 0xffffffff, GPRS_ALGO_GEA0, - NULL); + else { + if (llme) { + /* TLLI unassignment */ + gprs_llgmm_assign(llme, llme->tlli, 0xffffffff, + GPRS_ALGO_GEA0, NULL); + } + } return rc; } @@ -1387,10 +1403,13 @@ mmctx->t3350_mode = GMM_T3350_MODE_NONE; mmctx->p_tmsi_old = 0; mmctx->pending_req = 0; - /* Unassign the old TLLI */ - mmctx->gb.tlli = mmctx->gb.tlli_new; - gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, - GPRS_ALGO_GEA0, NULL); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Unassign the old TLLI */ + mmctx->gb.tlli = mmctx->gb.tlli_new; + gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, + mmctx->gb.tlli_new, + GPRS_ALGO_GEA0, NULL); + } mmctx->mm_state = GMM_REGISTERED_NORMAL; rc = 0; @@ -1407,10 +1426,12 @@ mmctx->t3350_mode = GMM_T3350_MODE_NONE; mmctx->p_tmsi_old = 0; mmctx->pending_req = 0; - /* Unassign the old TLLI */ - mmctx->gb.tlli = mmctx->gb.tlli_new; - gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, - GPRS_ALGO_GEA0, NULL); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Unassign the old TLLI */ + mmctx->gb.tlli = mmctx->gb.tlli_new; + gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, + GPRS_ALGO_GEA0, NULL); + } mmctx->mm_state = GMM_REGISTERED_NORMAL; rc = 0; @@ -1426,9 +1447,11 @@ mmctx->t3350_mode = GMM_T3350_MODE_NONE; mmctx->p_tmsi_old = 0; mmctx->pending_req = 0; - /* Unassign the old TLLI */ - mmctx->gb.tlli = mmctx->gb.tlli_new; - //gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, GPRS_ALGO_GEA0, NULL); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Unassign the old TLLI */ + mmctx->gb.tlli = mmctx->gb.tlli_new; + //gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, GPRS_ALGO_GEA0, NULL); + } rc = 0; break; case GSM48_MT_GMM_AUTH_CIPH_RESP: @@ -2109,7 +2132,8 @@ int gsm0408_gprs_force_reattach(struct sgsn_mm_ctx *mmctx) { int rc; - gprs_llgmm_reset(mmctx->gb.llme); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) + gprs_llgmm_reset(mmctx->gb.llme); rc = gsm48_tx_gmm_detach_req( mmctx, GPRS_DET_T_MT_REATT_REQ, GMM_CAUSE_IMPL_DETACHED); -- To view, visit https://gerrit.osmocom.org/169 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I02e83dcae05673158884ae88a48f1c108d28f5a2 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte From gerrit-no-reply at lists.osmocom.org Thu Jun 2 00:32:19 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 00:32:19 +0000 Subject: openbsc[master]: TEST commit, outdated without conflict In-Reply-To: References: Message-ID: Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/165 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I534719345e271876f562e5a6fe3f959f27dede19 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Thu Jun 2 00:32:32 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 00:32:32 +0000 Subject: openbsc[master]: TEST commit, outdated without conflict, newest in branch In-Reply-To: References: Message-ID: Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/166 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I451e65ce261ff55ca3b7a8bc7f08c71e20924eec Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Thu Jun 2 00:32:41 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 00:32:41 +0000 Subject: [ABANDON] openbsc[master]: TEST commit, outdated without conflict In-Reply-To: References: Message-ID: Neels Hofmeyr has abandoned this change. Change subject: TEST commit, outdated without conflict ...................................................................... Abandoned test -- To view, visit https://gerrit.osmocom.org/165 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: I534719345e271876f562e5a6fe3f959f27dede19 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Thu Jun 2 00:33:04 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 00:33:04 +0000 Subject: [ABANDON] openbsc[master]: TEST commit, outdated without conflict, newest in branch In-Reply-To: References: Message-ID: Neels Hofmeyr has abandoned this change. Change subject: TEST commit, outdated without conflict, newest in branch ...................................................................... Abandoned test -- To view, visit https://gerrit.osmocom.org/166 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: I451e65ce261ff55ca3b7a8bc7f08c71e20924eec Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Thu Jun 2 01:02:16 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 01:02:16 +0000 Subject: [PATCH] openbsc[master]: rename gsm0408_gprs_rcvmsg() to gsm0408_gprs_rcvmsg_gb() Message-ID: Review at https://gerrit.osmocom.org/170 rename gsm0408_gprs_rcvmsg() to gsm0408_gprs_rcvmsg_gb() This is the entry point for GMM from Gb. We will create a new one for Iu, so let's be explicit rather than implicit. Change-Id: I93c074bf99db041117c0dc03dc8255879845a875 --- M openbsc/include/openbsc/gprs_gmm.h M openbsc/src/gprs/gprs_gmm.c M openbsc/src/gprs/gprs_llc.c M openbsc/tests/sgsn/sgsn_test.c 4 files changed, 5 insertions(+), 5 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/70/170/1 diff --git a/openbsc/include/openbsc/gprs_gmm.h b/openbsc/include/openbsc/gprs_gmm.h index 702b9b9..e0d8f77 100644 --- a/openbsc/include/openbsc/gprs_gmm.h +++ b/openbsc/include/openbsc/gprs_gmm.h @@ -10,7 +10,7 @@ int gsm48_tx_gsm_act_pdp_acc(struct sgsn_pdp_ctx *pdp); int gsm48_tx_gsm_deact_pdp_acc(struct sgsn_pdp_ctx *pdp); -int gsm0408_gprs_rcvmsg(struct msgb *msg, struct gprs_llc_llme *llme); +int gsm0408_gprs_rcvmsg_gb(struct msgb *msg, struct gprs_llc_llme *llme); int gsm0408_gprs_force_reattach(struct sgsn_mm_ctx *mmctx); int gsm0408_gprs_force_reattach_oldmsg(struct msgb *msg); void gsm0408_gprs_access_granted(struct sgsn_mm_ctx *mmctx); diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index 889ac98..1e10701 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -2087,8 +2087,8 @@ return rc; } -/* Main entry point for incoming 04.08 GPRS messages */ -int gsm0408_gprs_rcvmsg(struct msgb *msg, struct gprs_llc_llme *llme) +/* Main entry point for incoming 04.08 GPRS messages from Gb */ +int gsm0408_gprs_rcvmsg_gb(struct msgb *msg, struct gprs_llc_llme *llme) { struct gsm48_hdr *gh = (struct gsm48_hdr *) msgb_gmmh(msg); uint8_t pdisc = gsm48_hdr_pdisc(gh); diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index 4d21963..71178c9 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -663,7 +663,7 @@ switch (llhp.sapi) { case GPRS_SAPI_GMM: /* send LL_UNITDATA_IND to GMM */ - rc = gsm0408_gprs_rcvmsg(msg, lle->llme); + rc = gsm0408_gprs_rcvmsg_gb(msg, lle->llme); break; case GPRS_SAPI_SNDCP3: case GPRS_SAPI_SNDCP5: diff --git a/openbsc/tests/sgsn/sgsn_test.c b/openbsc/tests/sgsn/sgsn_test.c index 3fb359b..48f013d 100644 --- a/openbsc/tests/sgsn/sgsn_test.c +++ b/openbsc/tests/sgsn/sgsn_test.c @@ -196,7 +196,7 @@ msg = create_msg(data, data_len); msgb_tlli(msg) = tlli; bssgp_create_cell_id(msgb_bcid(msg), bssgp_raid, 0); - gsm0408_gprs_rcvmsg(msg, llme); + gsm0408_gprs_rcvmsg_gb(msg, llme); msgb_free(msg); } -- To view, visit https://gerrit.osmocom.org/170 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I93c074bf99db041117c0dc03dc8255879845a875 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte From gerrit-no-reply at lists.osmocom.org Thu Jun 2 01:02:16 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 01:02:16 +0000 Subject: [PATCH] openbsc[master]: gprs_gmm.c: Don't try to de-reference NULL mmctx Message-ID: Review at https://gerrit.osmocom.org/171 gprs_gmm.c: Don't try to de-reference NULL mmctx There was a comment in the code that certain GMM messages require a valid mmctx pointer. However, nothing actually checked if that pointer was in fact non-NULL. We plainly crashed if a MS would send us the wrong message in the wrong state. Original patch by Harald Welte, but it broke message validity checking, resulting in sgsn_test failure. This re-implements the NULL check in a different way, as explained by in-code comment. Change-Id: I7908de65bec91599f7042549b832cbbd7ae5a9a8 --- M openbsc/src/gprs/gprs_gmm.c 1 file changed, 32 insertions(+), 0 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/71/171/1 diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index 1e10701..e788e3d 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -1339,6 +1339,15 @@ return rc; } + /* + * For a few messages, mmctx may be NULL. For most, we want to ensure a + * non-NULL mmctx. At the same time, we want to keep the message + * validity check intact, so that all message types appear in the + * switch statement and the default case thus means "unknown message". + * If we split the switch in two parts to check non-NULL halfway, the + * unknown-message check breaks, or we'd need to duplicate the switch + * cases in both parts. Just keep one large switch and add some gotos. + */ switch (gh->msg_type) { case GSM48_MT_GMM_RA_UPD_REQ: rc = gsm48_rx_gmm_ra_upd_req(mmctx, msg, llme); @@ -1348,20 +1357,30 @@ break; /* For all the following types mmctx can not be NULL */ case GSM48_MT_GMM_ID_RESP: + if (!mmctx) + goto null_mmctx; rc = gsm48_rx_gmm_id_resp(mmctx, msg); break; case GSM48_MT_GMM_STATUS: + if (!mmctx) + goto null_mmctx; rc = gsm48_rx_gmm_status(mmctx, msg); break; case GSM48_MT_GMM_DETACH_REQ: + if (!mmctx) + goto null_mmctx; rc = gsm48_rx_gmm_det_req(mmctx, msg); break; case GSM48_MT_GMM_DETACH_ACK: + if (!mmctx) + goto null_mmctx; LOGMMCTXP(LOGL_INFO, mmctx, "-> DETACH ACK\n"); mm_ctx_cleanup_free(mmctx, "GPRS DETACH ACK"); rc = 0; break; case GSM48_MT_GMM_ATTACH_COMPL: + if (!mmctx) + goto null_mmctx; /* only in case SGSN offered new P-TMSI */ LOGMMCTXP(LOGL_INFO, mmctx, "-> ATTACH COMPLETE\n"); mmctx_timer_stop(mmctx, 3350); @@ -1380,6 +1399,8 @@ osmo_signal_dispatch(SS_SGSN, S_SGSN_ATTACH, &sig_data); break; case GSM48_MT_GMM_RA_UPD_COMPL: + if (!mmctx) + goto null_mmctx; /* only in case SGSN offered new P-TMSI */ LOGMMCTXP(LOGL_INFO, mmctx, "-> ROUTING AREA UPDATE COMPLETE\n"); mmctx_timer_stop(mmctx, 3350); @@ -1398,6 +1419,8 @@ osmo_signal_dispatch(SS_SGSN, S_SGSN_UPDATE, &sig_data); break; case GSM48_MT_GMM_PTMSI_REALL_COMPL: + if (!mmctx) + goto null_mmctx; LOGMMCTXP(LOGL_INFO, mmctx, "-> PTMSI REALLLICATION COMPLETE\n"); mmctx_timer_stop(mmctx, 3350); mmctx->t3350_mode = GMM_T3350_MODE_NONE; @@ -1409,6 +1432,8 @@ rc = 0; break; case GSM48_MT_GMM_AUTH_CIPH_RESP: + if (!mmctx) + goto null_mmctx; rc = gsm48_rx_gmm_auth_ciph_resp(mmctx, msg); break; default: @@ -1419,6 +1444,13 @@ } return rc; + +null_mmctx: + LOGP(DMM, LOGL_ERROR, + "Received GSM 04.08 message type 0x%02x," + " but no MM context available\n", + gh->msg_type); + return -EINVAL; } static void mmctx_timer_cb(void *_mm) -- To view, visit https://gerrit.osmocom.org/171 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I7908de65bec91599f7042549b832cbbd7ae5a9a8 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Thu Jun 2 01:02:16 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 01:02:16 +0000 Subject: [PATCH] openbsc[master]: gprs_gmm.c: Make TLLI handling specific to Gb interface Message-ID: Review at https://gerrit.osmocom.org/172 gprs_gmm.c: Make TLLI handling specific to Gb interface Soem of the operations we perform in the GMM layer are specific to the GPRS/EDGE radio access network and its Gb interface. Let's make them conditional to that in preparation of supporting an Iu interface. Change-Id: I3efb7c5087afe8e2331ec17bd9fac5029f4bee6c --- M openbsc/src/gprs/gprs_gmm.c 1 file changed, 59 insertions(+), 35 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/72/172/1 diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index e788e3d..d521342 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -904,8 +904,10 @@ strncpy(ctx->imsi, mi_string, sizeof(ctx->imsi) - 1); #endif } - ctx->gb.tlli = msgb_tlli(msg); - ctx->gb.llme = llme; + if (ctx->ran_type == MM_CTX_T_GERAN_Gb) { + ctx->gb.tlli = msgb_tlli(msg); + ctx->gb.llme = llme; + } msgid2mmctx(ctx, msg); break; case GSM_MI_TYPE_TMSI: @@ -920,8 +922,10 @@ ctx = sgsn_mm_ctx_alloc(msgb_tlli(msg), &ra_id); ctx->p_tmsi = tmsi; } - ctx->gb.tlli = msgb_tlli(msg); - ctx->gb.llme = llme; + if (ctx->ran_type == MM_CTX_T_GERAN_Gb) { + ctx->gb.tlli = msgb_tlli(msg); + ctx->gb.llme = llme; + } msgid2mmctx(ctx, msg); break; default: @@ -932,7 +936,8 @@ } /* Update MM Context with currient RA and Cell ID */ ctx->ra = ra_id; - ctx->gb.cell_id = cid; + if (ctx->ran_type == MM_CTX_T_GERAN_Gb) + ctx->gb.cell_id = cid; /* Update MM Context with other data */ ctx->drx_parms = drx_par; ctx->ms_radio_access_capa.len = ms_ra_acc_cap_len; @@ -950,13 +955,16 @@ } ctx->mm_state = GMM_COMMON_PROC_INIT; #endif - /* Even if there is no P-TMSI allocated, the MS will switch from - * foreign TLLI to local TLLI */ - ctx->gb.tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL); - /* Inform LLC layer about new TLLI but keep old active */ - gprs_llgmm_assign(ctx->gb.llme, ctx->gb.tlli, ctx->gb.tlli_new, - GPRS_ALGO_GEA0, NULL); + if (ctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Even if there is no P-TMSI allocated, the MS will + * switch from foreign TLLI to local TLLI */ + ctx->gb.tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL); + + /* Inform LLC layer about new TLLI but keep old active */ + gprs_llgmm_assign(ctx->gb.llme, ctx->gb.tlli, ctx->gb.tlli_new, + GPRS_ALGO_GEA0, NULL); + } ctx->pending_req = GSM48_MT_GMM_ATTACH_REQ; return gsm48_gmm_authorize(ctx); @@ -1218,8 +1226,10 @@ /* Update the MM context with the new RA-ID */ bssgp_parse_cell_id(&mmctx->ra, msgb_bcid(msg)); - /* Update the MM context with the new (i.e. foreign) TLLI */ - mmctx->gb.tlli = msgb_tlli(msg); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Update the MM context with the new (i.e. foreign) TLLI */ + mmctx->gb.tlli = msgb_tlli(msg); + } /* FIXME: Update the MM context with the MS radio acc capabilities */ /* FIXME: Update the MM context with the MS network capabilities */ @@ -1244,13 +1254,16 @@ sig_data.mm = mmctx; osmo_signal_dispatch(SS_SGSN, S_SGSN_UPDATE, &sig_data); #endif - /* Even if there is no P-TMSI allocated, the MS will switch from - * foreign TLLI to local TLLI */ - mmctx->gb.tlli_new = gprs_tmsi2tlli(mmctx->p_tmsi, TLLI_LOCAL); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Even if there is no P-TMSI allocated, the MS will switch from + * foreign TLLI to local TLLI */ + mmctx->gb.tlli_new = gprs_tmsi2tlli(mmctx->p_tmsi, TLLI_LOCAL); - /* Inform LLC layer about new TLLI but keep old active */ - gprs_llgmm_assign(mmctx->gb.llme, mmctx->gb.tlli, mmctx->gb.tlli_new, - GPRS_ALGO_GEA0, NULL); + /* Inform LLC layer about new TLLI but keep old active */ + gprs_llgmm_assign(mmctx->gb.llme, mmctx->gb.tlli, + mmctx->gb.tlli_new, GPRS_ALGO_GEA0, + NULL); + } /* Look at PDP Context Status IE and see if MS's view of * activated/deactivated NSAPIs agrees with our view */ @@ -1270,10 +1283,13 @@ rc = gsm48_tx_gmm_ra_upd_rej(msg, reject_cause); if (mmctx) mm_ctx_cleanup_free(mmctx, "GPRS RA UPDATE REJ"); - else - /* TLLI unassignment */ - gprs_llgmm_assign(llme, llme->tlli, 0xffffffff, GPRS_ALGO_GEA0, - NULL); + else { + if (llme) { + /* TLLI unassignment */ + gprs_llgmm_assign(llme, llme->tlli, 0xffffffff, + GPRS_ALGO_GEA0, NULL); + } + } return rc; } @@ -1387,10 +1403,13 @@ mmctx->t3350_mode = GMM_T3350_MODE_NONE; mmctx->p_tmsi_old = 0; mmctx->pending_req = 0; - /* Unassign the old TLLI */ - mmctx->gb.tlli = mmctx->gb.tlli_new; - gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, - GPRS_ALGO_GEA0, NULL); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Unassign the old TLLI */ + mmctx->gb.tlli = mmctx->gb.tlli_new; + gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, + mmctx->gb.tlli_new, + GPRS_ALGO_GEA0, NULL); + } mmctx->mm_state = GMM_REGISTERED_NORMAL; rc = 0; @@ -1407,10 +1426,12 @@ mmctx->t3350_mode = GMM_T3350_MODE_NONE; mmctx->p_tmsi_old = 0; mmctx->pending_req = 0; - /* Unassign the old TLLI */ - mmctx->gb.tlli = mmctx->gb.tlli_new; - gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, - GPRS_ALGO_GEA0, NULL); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Unassign the old TLLI */ + mmctx->gb.tlli = mmctx->gb.tlli_new; + gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, + GPRS_ALGO_GEA0, NULL); + } mmctx->mm_state = GMM_REGISTERED_NORMAL; rc = 0; @@ -1426,9 +1447,11 @@ mmctx->t3350_mode = GMM_T3350_MODE_NONE; mmctx->p_tmsi_old = 0; mmctx->pending_req = 0; - /* Unassign the old TLLI */ - mmctx->gb.tlli = mmctx->gb.tlli_new; - //gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, GPRS_ALGO_GEA0, NULL); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Unassign the old TLLI */ + mmctx->gb.tlli = mmctx->gb.tlli_new; + //gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, GPRS_ALGO_GEA0, NULL); + } rc = 0; break; case GSM48_MT_GMM_AUTH_CIPH_RESP: @@ -2109,7 +2132,8 @@ int gsm0408_gprs_force_reattach(struct sgsn_mm_ctx *mmctx) { int rc; - gprs_llgmm_reset(mmctx->gb.llme); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) + gprs_llgmm_reset(mmctx->gb.llme); rc = gsm48_tx_gmm_detach_req( mmctx, GPRS_DET_T_MT_REATT_REQ, GMM_CAUSE_IMPL_DETACHED); -- To view, visit https://gerrit.osmocom.org/172 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I3efb7c5087afe8e2331ec17bd9fac5029f4bee6c Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte From gerrit-no-reply at lists.osmocom.org Thu Jun 2 01:02:17 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 01:02:17 +0000 Subject: [PATCH] openbsc[master]: gprs_gmm.c: Perform LLME operations only if we have one Message-ID: Review at https://gerrit.osmocom.org/173 gprs_gmm.c: Perform LLME operations only if we have one In case the GMM message did not arrive over a Gb interface, there is no LLME (and thus the associated pointer is NULL). Don't try to perform operations on a NULL LLME. Change-Id: If7f24161cd2826f8ee238d4bc1090adf555cea4e --- M openbsc/src/gprs/gprs_gmm.c 1 file changed, 7 insertions(+), 5 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/73/173/1 diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index d521342..c8f687b 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -1208,10 +1208,12 @@ } if (!mmctx) { - /* send a XID reset to re-set all LLC sequence numbers - * in the MS */ - LOGMMCTXP(LOGL_NOTICE, mmctx, "LLC XID RESET\n"); - gprs_llgmm_reset(llme); + if (llme) { + /* send a XID reset to re-set all LLC sequence numbers + * in the MS */ + LOGMMCTXP(LOGL_NOTICE, mmctx, "LLC XID RESET\n"); + gprs_llgmm_reset(llme); + } /* The MS has to perform GPRS attach */ /* Device is still IMSI attached for CS but initiate GPRS ATTACH, * see GSM 04.08, 4.7.5.1.4 and G.6 */ @@ -1314,7 +1316,7 @@ /* MMCTX can be NULL when called */ - if (!mmctx && + if (llme && !mmctx && gh->msg_type != GSM48_MT_GMM_ATTACH_REQ && gh->msg_type != GSM48_MT_GMM_RA_UPD_REQ) { LOGP(DMM, LOGL_NOTICE, "Cannot handle GMM for unknown MM CTX\n"); -- To view, visit https://gerrit.osmocom.org/173 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: If7f24161cd2826f8ee238d4bc1090adf555cea4e Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte From gerrit-no-reply at lists.osmocom.org Thu Jun 2 01:02:17 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 01:02:17 +0000 Subject: [PATCH] openbsc[master]: sgsn_mm_ctx_cleanup_free(): clean up LLME iff present (Gb, n... Message-ID: Review at https://gerrit.osmocom.org/174 sgsn_mm_ctx_cleanup_free(): clean up LLME iff present (Gb, not Iu) Assert that llme is unused for non-Gb (Iu) connections, and clean up otherwise. Make sure the cleanup is left below the sgsn_mm_ctx_free() call, as the comment states. Change-Id: I891ae21afc1f4f60580b822273b5435e0e17d46f --- M openbsc/src/gprs/gprs_sgsn.c 1 file changed, 10 insertions(+), 3 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/74/174/1 diff --git a/openbsc/src/gprs/gprs_sgsn.c b/openbsc/src/gprs/gprs_sgsn.c index 8bb6850..722edec 100644 --- a/openbsc/src/gprs/gprs_sgsn.c +++ b/openbsc/src/gprs/gprs_sgsn.c @@ -197,10 +197,15 @@ void sgsn_mm_ctx_cleanup_free(struct sgsn_mm_ctx *mm) { - struct gprs_llc_llme *llme = mm->gb.llme; + struct gprs_llc_llme *llme = NULL; uint32_t tlli = mm->gb.tlli; struct sgsn_pdp_ctx *pdp, *pdp2; struct sgsn_signal_data sig_data; + + if (mm->ran_type == MM_CTX_T_GERAN_Gb) + llme = mm->gb.llme; + else + OSMO_ASSERT(mm->gb.llme == NULL); /* Forget about ongoing look-ups */ if (mm->ggsn_lookup) { @@ -237,8 +242,10 @@ sgsn_mm_ctx_free(mm); mm = NULL; - /* TLLI unassignment, must be called after sgsn_mm_ctx_free */ - gprs_llgmm_assign(llme, tlli, 0xffffffff, GPRS_ALGO_GEA0, NULL); + if (llme) { + /* TLLI unassignment, must be called after sgsn_mm_ctx_free */ + gprs_llgmm_assign(llme, tlli, 0xffffffff, GPRS_ALGO_GEA0, NULL); + } } -- To view, visit https://gerrit.osmocom.org/174 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I891ae21afc1f4f60580b822273b5435e0e17d46f Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: daniel From gerrit-no-reply at lists.osmocom.org Thu Jun 2 01:02:17 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 01:02:17 +0000 Subject: [PATCH] openbsc[master]: gprs: more conditionals for Gb specific actions Message-ID: Review at https://gerrit.osmocom.org/175 gprs: more conditionals for Gb specific actions Change-Id: I213d21b9ddbf19e56269defcc6aa65aca4947140 --- M openbsc/src/gprs/gprs_gmm.c M openbsc/src/gprs/gprs_sgsn.c M openbsc/src/gprs/sgsn_libgtp.c 3 files changed, 14 insertions(+), 8 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/75/175/1 diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index c8f687b..68ba326 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -1227,8 +1227,8 @@ rate_ctr_inc(&mmctx->ctrg->ctr[GMM_CTR_PKTS_SIG_IN]); /* Update the MM context with the new RA-ID */ - bssgp_parse_cell_id(&mmctx->ra, msgb_bcid(msg)); if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + bssgp_parse_cell_id(&mmctx->ra, msgb_bcid(msg)); /* Update the MM context with the new (i.e. foreign) TLLI */ mmctx->gb.tlli = msgb_tlli(msg); } diff --git a/openbsc/src/gprs/gprs_sgsn.c b/openbsc/src/gprs/gprs_sgsn.c index 722edec..8f9f453 100644 --- a/openbsc/src/gprs/gprs_sgsn.c +++ b/openbsc/src/gprs/gprs_sgsn.c @@ -315,8 +315,10 @@ LOGPDPCTXP(LOGL_INFO, pdp, "Forcing release of PDP context\n"); - /* Force the deactivation of the SNDCP layer */ - sndcp_sm_deactivate_ind(&pdp->mm->gb.llme->lle[pdp->sapi], pdp->nsapi); + if (pdp->mm->ran_type == MM_CTX_T_GERAN_Gb) { + /* Force the deactivation of the SNDCP layer */ + sndcp_sm_deactivate_ind(&pdp->mm->gb.llme->lle[pdp->sapi], pdp->nsapi); + } memset(&sig_data, 0, sizeof(sig_data)); sig_data.pdp = pdp; diff --git a/openbsc/src/gprs/sgsn_libgtp.c b/openbsc/src/gprs/sgsn_libgtp.c index 504590b..d138500 100644 --- a/openbsc/src/gprs/sgsn_libgtp.c +++ b/openbsc/src/gprs/sgsn_libgtp.c @@ -352,9 +352,11 @@ goto reject; } - /* Activate the SNDCP layer */ - sndcp_sm_activate_ind(&pctx->mm->gb.llme->lle[pctx->sapi], pctx->nsapi); - return send_act_pdp_cont_acc(pctx); + if (pctx->mm->ran_type == MM_CTX_T_GERAN_Gb) { + /* Activate the SNDCP layer */ + sndcp_sm_activate_ind(&pctx->mm->gb.llme->lle[pctx->sapi], pctx->nsapi); + return send_act_pdp_cont_acc(pctx); + } reject: /* @@ -392,8 +394,10 @@ osmo_signal_dispatch(SS_SGSN, S_SGSN_PDP_DEACT, &sig_data); if (pctx->mm) { - /* Deactivate the SNDCP layer */ - sndcp_sm_deactivate_ind(&pctx->mm->gb.llme->lle[pctx->sapi], pctx->nsapi); + if (pctx->mm->ran_type == MM_CTX_T_GERAN_Gb) { + /* Deactivate the SNDCP layer */ + sndcp_sm_deactivate_ind(&pctx->mm->gb.llme->lle[pctx->sapi], pctx->nsapi); + } /* Confirm deactivation of PDP context to MS */ rc = gsm48_tx_gsm_deact_pdp_acc(pctx); -- To view, visit https://gerrit.osmocom.org/175 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I213d21b9ddbf19e56269defcc6aa65aca4947140 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: daniel From gerrit-no-reply at lists.osmocom.org Thu Jun 2 01:02:45 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 01:02:45 +0000 Subject: [ABANDON] openbsc[master]: gprs_gmm.c: Make TLLI handling specific to Gb interface In-Reply-To: References: Message-ID: Neels Hofmeyr has abandoned this change. Change subject: gprs_gmm.c: Make TLLI handling specific to Gb interface ...................................................................... Abandoned resent -- To view, visit https://gerrit.osmocom.org/169 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: I02e83dcae05673158884ae88a48f1c108d28f5a2 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte From gerrit-no-reply at lists.osmocom.org Thu Jun 2 01:02:54 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 01:02:54 +0000 Subject: [ABANDON] openbsc[master]: gprs_gmm.c: Don't try to de-reference NULL mmctx In-Reply-To: References: Message-ID: Neels Hofmeyr has abandoned this change. Change subject: gprs_gmm.c: Don't try to de-reference NULL mmctx ...................................................................... Abandoned resent -- To view, visit https://gerrit.osmocom.org/168 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: I34b47b9e63691c9bc9904573000c74877217f679 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Thu Jun 2 01:02:59 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 01:02:59 +0000 Subject: [ABANDON] openbsc[master]: rename gsm0408_gprs_rcvmsg() to gsm0408_gprs_rcvmsg_gb() In-Reply-To: References: Message-ID: Neels Hofmeyr has abandoned this change. Change subject: rename gsm0408_gprs_rcvmsg() to gsm0408_gprs_rcvmsg_gb() ...................................................................... Abandoned resent -- To view, visit https://gerrit.osmocom.org/167 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: I3457080e5a0af6329907d68fa4ae4db9b89a76c3 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Thu Jun 2 01:12:15 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 01:12:15 +0000 Subject: openbsc[master]: gprs_gmm.c: Don't try to de-reference NULL mmctx In-Reply-To: References: Message-ID: Patch Set 1: (1 comment) https://gerrit.osmocom.org/#/c/171/1/openbsc/src/gprs/gprs_gmm.c File openbsc/src/gprs/gprs_gmm.c: Line 1442: rc = gsm48_tx_gmm_status(mmctx, GMM_CAUSE_MSGT_NOTEXIST_NOTIMPL); actually, there should be an 'if (mmctx)' for this, because gsm48_tx_gmm_status() dereferences mmctx without checking. -- To view, visit https://gerrit.osmocom.org/171 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I7908de65bec91599f7042549b832cbbd7ae5a9a8 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Neels Hofmeyr Gerrit-HasComments: Yes From nhofmeyr at sysmocom.de Thu Jun 2 01:45:58 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 2 Jun 2016 03:45:58 +0200 Subject: Gerrit: submitting a branch In-Reply-To: Message-ID: <20160602014558.GA2004@dub6> On Wed, Jun 01, 2016 at 09:02:47PM +0200, Holger Freyther wrote: > > On 01 Jun 2016, at 14:21, Neels Hofmeyr wrote: > > > > It would also be nice if Gerrit didn't complain about merge conflicts that are > > in fact no merge conflicts -- I'm stumped on that topic. Any help would be > > appreciated. > > https://code.google.com/p/gerrit/issues/detail?id=2734 Thanks! #5 is extremely helpful in understanding Gerrit: I did absolutely not expect the term "merge conflict" to actually mean "path conflict". https://code.google.com/p/gerrit/issues/detail?id=2734#c5 What the post says to be "Automatically resolve conflicts" is probably "Allow content merges" in our Gerrit version. It's now enabled in our projects (thanks Holger). Next I'd like to retry the "Rebase if necessary". Currently openbsc was on "Merge if necessary", which, it seems, creates merges that make the history more complex than rebases would. I've put openbsc to "Rebase if necessary" now and posted the next couple iups commits to for/master. This time I don't see "Merge conflicts", probably thanks to "Allow content merges"; excellent. I have yet another problem: it seems I can't re-submit a branch; during push, I get an error saying: ! [remote rejected] HEAD -> refs/for/master (no new changes) I've resolved "no new changes" before by manually removing the Change-Id from each commit message (kind of unsatisfactory solution). This means I can't submit fixes to the branch commits. I would like to add the NULL check described in the comment here: https://gerrit.osmocom.org/#/c/171/1/openbsc/src/gprs/gprs_gmm.c but it seems I would have to abandon the entire set and submit it again, and would also have to amend every commit message to generate a new Change-Id in it. (This particular change could well be added in a later commit, but it makes me wonder how we work with requests to tweak such a commit in general.) https://groups.google.com/forum/?_escaped_fragment_=topic/repo-discuss/NeuQmv4LdOc#!topic/repo-discuss/NeuQmv4LdOc ^ This looks like gerrit and branches just don't mix too well. https://groups.google.com/forum/?_escaped_fragment_=topic/repo-discuss/tmiyz6GCRaw#!topic/repo-discuss/tmiyz6GCRaw ^ In here there's also the suggestion to push a merge-commit to for/master instead, so I might try it next time... BTW I think I was wrong about the shuffling of commits in the listing. It appears the newest branch commit is always on the bottom. (Except in "Related changes", where it is always on top.) I guess we should have a "submitting branches in gerrit" wiki page once we've settled for our favourite strategy. ~Neels -- - Neels Hofmeyr 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Thu Jun 2 02:02:06 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 2 Jun 2016 04:02:06 +0200 Subject: Stopping Gerrit on Sunday In-Reply-To: <729756F1-18FF-4893-8618-CDA990E9834B@freyther.de> References: <729756F1-18FF-4893-8618-CDA990E9834B@freyther.de> Message-ID: <20160602020206.GB2004@dub6> On Wed, Jun 01, 2016 at 02:29:05PM +0200, Holger Freyther wrote: > Hi Guys, > > I am a bit fed-up to have to receive Neels non-productive mails every single day and given my tight work schedule let's have him win, declare Gerrit a failure and return to patchwork. Let's have this on a non-personal level, and let's have consensus. I don't win either way. My goofiness of handling gerrit should not be too relevant. If dropping gerrit means losing your reviews, my choice is to keep gerrit. Secondly, it's not your personal responsibility to resolve my gerrit problems. There's others around in the internet too. If your schedule is tight, please don't bother with that! I'm posting to openbsc@, not hfreyther at . It seems we won't get branch reviews smoothed out, but by far most of our work is indeed single patch submission. And we've discussed/resolved pretty much all other problems so far. I know that Lynxis and others like gerrit. Even if consensus to drop gerrit converges, IMHO sunday would be too soon. Let's have other people's opinions first. ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Thu Jun 2 02:09:25 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 2 Jun 2016 04:09:25 +0200 Subject: [PATCH] openbsc[master]: rename enum gprs_mm_state to gprs_gmm_state In-Reply-To: References: <20160601111152.GB1888@dub6> Message-ID: <20160602020925.GC2004@dub6> On Wed, Jun 01, 2016 at 02:17:02PM +0200, Holger Freyther wrote: > your super negative attitude is super annoying too. I don't have to spend time reviewing, so please go back to patchwork and be happy (but I remember your cursing about setting up a MTA as well). I should not have posted that mail. My apologies. ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From alexander.chemeris at gmail.com Thu Jun 2 04:11:12 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 2 Jun 2016 07:11:12 +0300 Subject: speech frame loss compensation In-Reply-To: <574EFCE1.1020304@sysmocom.de> References: <574EFCE1.1020304@sysmocom.de> Message-ID: Hi Max, Could you explain what are you trying to solve? I may be able to help, but I don't really understand what you're trying to achieve. Your conversion to ms is wrong. Narrowband codecs have 8000 samplerate, so with 160 samples in a packet, packet duration is 160/8000 = 20ms. But I don't see why do you need this conversion? I would think that working with samples is a better approach, because you operate with integers and don't have issues associated with floating numbers (rounding issues, comparison requires epsilon, etc). Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co On Jun 1, 2016 6:19 PM, "Max" wrote: > Hi. > > Right now in osmobts when sending/receiving frames with osmo_rtp_* it's > assumed that no frame is lost and timestamp is always advanced in 160ms > steps. In practice (especially when DTX is in place) frames do get lost > so we have to adjust the step to compensate. > > I've tried to do it as follows: > - store frame number of last used frame on receiving/sending > - check how far current frame number from old one > - convert frame number delta to ms: each frame is 4.615 ms long > - if delta in ms is bigger than default 160 than use it > > However the result sound not much better than using hardcoded value > which suggest that I might be doing FN -> ms conversion (or smth else) > wrong. Any ideas/advices? > > -- > Max Suraev 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuraev at sysmocom.de Thu Jun 2 08:37:01 2016 From: msuraev at sysmocom.de (Max) Date: Thu, 2 Jun 2016 10:37:01 +0200 Subject: speech frame loss compensation In-Reply-To: References: <574EFCE1.1020304@sysmocom.de> Message-ID: <574FF02D.2090300@sysmocom.de> Sure. I'm working on DTX support in OsmoBTS. The BSC side for DTX uplink (phone skipping some frames when there#s no voice) is pretty much ready. I've tested with nanobts and it works fine. When I try it with osmobts there's audible delay in voice after the talking is resumed after pause (dtx kicked in). This delay (and following distortion which I guess is cause by codec trying to "catch-up") appear regardless of the channel/codec (fr, hr, amr...). When I compare graphs in wireshark's rtp analysis I can see that in osmobts (unlike in nanobts) there are multiple spikes in forward diff (difference between actual arrival time and time in rtp packet). This and the comment in src/common/l1sap.c:633 suggest that we have to account for extra delay by changing the way we adjust rtp_socket->rx_user_ts. Right now both when sending and receiving with osmo_rtp_* we increment rx_user_ts and tx_timestamp in steps of 160. Both end-up as "userts" parameter to oRTP's rtp_session_sendm_with_ts ()/rtp_session_recvm_with_ts() . So it's not exactly timestamp in RTP, it's relative to 1st packet - the oRTP is supposed to take care of syncing it with actual timestamp. On 06/02/2016 06:11 AM, Alexander Chemeris wrote: > > Hi Max, > > Could you explain what are you trying to solve? I may be able to help, > but I don't really understand what you're trying to achieve. > > Your conversion to ms is wrong. Narrowband codecs have 8000 > samplerate, so with 160 samples in a packet, packet duration is > 160/8000 = 20ms. But I don't see why do you need this conversion? I > would think that working with samples is a better approach, because > you operate with integers and don't have issues associated with > floating numbers (rounding issues, comparison requires epsilon, etc). > > Please excuse typos. Written with a touchscreen keyboard. > > -- > Regards, > Alexander Chemeris > CEO Fairwaves, Inc. > https://fairwaves.co > > On Jun 1, 2016 6:19 PM, "Max" > wrote: > > Hi. > > Right now in osmobts when sending/receiving frames with osmo_rtp_* > it's > assumed that no frame is lost and timestamp is always advanced in > 160ms > steps. In practice (especially when DTX is in place) frames do get > lost > so we have to adjust the step to compensate. > > I've tried to do it as follows: > - store frame number of last used frame on receiving/sending > - check how far current frame number from old one > - convert frame number delta to ms: each frame is 4.615 ms long > - if delta in ms is bigger than default 160 than use it > > However the result sound not much better than using hardcoded value > which suggest that I might be doing FN -> ms conversion (or smth else) > wrong. Any ideas/advices? > > -- > Max Suraev > > 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 > -- Max Suraev 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 msuraev at sysmocom.de Thu Jun 2 08:47:47 2016 From: msuraev at sysmocom.de (Max) Date: Thu, 2 Jun 2016 10:47:47 +0200 Subject: Regression in osmo-pcu with UHD trx ? In-Reply-To: <57486F94.2010202@diateam.net> References: <57486F94.2010202@diateam.net> Message-ID: <574FF2B3.9020708@sysmocom.de> Hi. Could you please make a ticket in http://projects.osmocom.org/ to make sure this won't get lost in ML archives? -- Max Suraev 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 pierre.baudry at diateam.net Thu Jun 2 09:02:23 2016 From: pierre.baudry at diateam.net (Pierre Baudry) Date: Thu, 2 Jun 2016 11:02:23 +0200 Subject: Regression in osmo-pcu with UHD trx ? In-Reply-To: <4FE60FD8-9BA3-444E-BB20-056857F6BA48@freyther.de> References: <57486F94.2010202@diateam.net> <1E1383C7-81F2-4C58-A154-B0FF09C51305@freyther.de> <574BFEAE.90805@diateam.net> <4FE60FD8-9BA3-444E-BB20-056857F6BA48@freyther.de> Message-ID: <574FF61F.4040803@diateam.net> On 30/05/2016 21:34, Holger Freyther wrote: > argh. Could you go to f1a7b8fc6651f92a8b7f3f27b7ca05d07f4e44e0 and > revert it and then try again? Does it work better? > > holger > This specific problem is gone (I can see data flows and even some packets) but data service is still practically unusable, I get a lot of "Scheduling Ack/Nack, because MS is stalled." messages. On 02/06/2016 10:47, Max wrote: > Hi. > > Could you please make a ticket in http://projects.osmocom.org/ to make > sure this won't get lost in ML archives? Yes, I just wanted to make sure that I wasn't the only one experiencing this problem. I am now bisecting d87e1d6ab747423d3668c74d16201a5d967accf0..f1a7b8fc6651f92a8b7f3f27b7ca05d07f4e44e0 commits to identify which commit introduced these reliability problems From gerrit-no-reply at lists.osmocom.org Thu Jun 2 11:36:12 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Thu, 2 Jun 2016 11:36:12 +0000 Subject: openbsc[master]: gprs: more conditionals for Gb specific actions In-Reply-To: References: Message-ID: Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/175 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I213d21b9ddbf19e56269defcc6aa65aca4947140 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: daniel Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Thu Jun 2 11:36:47 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Thu, 2 Jun 2016 11:36:47 +0000 Subject: openbsc[master]: sgsn_mm_ctx_cleanup_free(): clean up LLME iff present (Gb, n... In-Reply-To: References: Message-ID: Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/174 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I891ae21afc1f4f60580b822273b5435e0e17d46f Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: daniel Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Thu Jun 2 11:37:17 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Thu, 2 Jun 2016 11:37:17 +0000 Subject: openbsc[master]: gprs_gmm.c: Perform LLME operations only if we have one In-Reply-To: References: Message-ID: Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/173 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: If7f24161cd2826f8ee238d4bc1090adf555cea4e Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Thu Jun 2 11:37:43 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Thu, 2 Jun 2016 11:37:43 +0000 Subject: openbsc[master]: gprs_gmm.c: Make TLLI handling specific to Gb interface In-Reply-To: References: Message-ID: Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/172 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I3efb7c5087afe8e2331ec17bd9fac5029f4bee6c Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Thu Jun 2 11:38:36 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Thu, 2 Jun 2016 11:38:36 +0000 Subject: openbsc[master]: gprs_gmm.c: Don't try to de-reference NULL mmctx In-Reply-To: References: Message-ID: Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/171 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I7908de65bec91599f7042549b832cbbd7ae5a9a8 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Thu Jun 2 11:38:52 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Thu, 2 Jun 2016 11:38:52 +0000 Subject: openbsc[master]: rename gsm0408_gprs_rcvmsg() to gsm0408_gprs_rcvmsg_gb() In-Reply-To: References: Message-ID: Patch Set 1: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/170 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I93c074bf99db041117c0dc03dc8255879845a875 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Thu Jun 2 11:40:55 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Thu, 2 Jun 2016 11:40:55 +0000 Subject: openbsc[master]: Add regexp authorization policy for IMSI In-Reply-To: References: Message-ID: Patch Set 2: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/104 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I525f4b80676de47d1d422686da2ca012301b0129 Gerrit-PatchSet: 2 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Max Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From gerrit-no-reply at lists.osmocom.org Thu Jun 2 11:50:59 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 11:50:59 +0000 Subject: [PATCH] openbsc[master]: comment tweak for bsc_handover_start() Message-ID: Review at https://gerrit.osmocom.org/176 comment tweak for bsc_handover_start() Have a comment only in the .c file to remove dup, tweak wording. Change-Id: If054dad877a1ca750cd72be9c9d90bcf087bf741 --- M openbsc/include/openbsc/handover.h M openbsc/src/libbsc/handover_logic.c 2 files changed, 3 insertions(+), 6 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/76/176/1 diff --git a/openbsc/include/openbsc/handover.h b/openbsc/include/openbsc/handover.h index bd0d8ad..3fe71a2 100644 --- a/openbsc/include/openbsc/handover.h +++ b/openbsc/include/openbsc/handover.h @@ -3,9 +3,6 @@ struct gsm_subscriber_connection; -/* Hand over the specified logical channel to the specified new BTS. - * This is the main entry point for the actual handover algorithm, - * after it has decided it wants to initiate HO to a specific BTS */ int bsc_handover_start(struct gsm_lchan *old_lchan, struct gsm_bts *bts); /* clear any operation for this connection */ diff --git a/openbsc/src/libbsc/handover_logic.c b/openbsc/src/libbsc/handover_logic.c index 2b8c386..641cee4 100644 --- a/openbsc/src/libbsc/handover_logic.c +++ b/openbsc/src/libbsc/handover_logic.c @@ -85,9 +85,9 @@ return NULL; } -/* Hand over the specified logical channel to the specified new BTS. - * This is the main entry point for the actual handover algorithm, - * after it has decided it wants to initiate HO to a specific BTS */ +/* Hand over the specified logical channel to the specified new BTS. This is + * the main entry point for the actual handover algorithm, after the decision + * whether to initiate HO to a specific BTS. */ int bsc_handover_start(struct gsm_lchan *old_lchan, struct gsm_bts *bts) { struct gsm_lchan *new_lchan; -- To view, visit https://gerrit.osmocom.org/176 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: If054dad877a1ca750cd72be9c9d90bcf087bf741 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Thu Jun 2 11:50:59 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 11:50:59 +0000 Subject: [PATCH] openbsc[master]: debug log: cosmetic fixes Message-ID: Review at https://gerrit.osmocom.org/177 debug log: cosmetic fixes Drop erroneous C from a DEBUGPC, should be on a new line. Drop underscores from IPAC_PDCH_[DE]ACT: all other log messages for IPAC PDCH are without underscores -- git grep "P(.*IPAC.PDCH.*ACT" Change-Id: I8fb7a1c1beabb1f4388517383fd0bdc082d557ca --- M openbsc/src/libbsc/abis_rsl.c 1 file changed, 2 insertions(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/77/177/1 diff --git a/openbsc/src/libbsc/abis_rsl.c b/openbsc/src/libbsc/abis_rsl.c index c3a0c5c..abe2f9b 100644 --- a/openbsc/src/libbsc/abis_rsl.c +++ b/openbsc/src/libbsc/abis_rsl.c @@ -1224,7 +1224,7 @@ LOGP(DRSL, LOGL_ERROR, "%s CHANNEL MODE MODIFY NACK\n", ts_name); break; case RSL_MT_IPAC_PDCH_ACT_ACK: - DEBUGPC(DRSL, "%s IPAC PDCH ACT ACK\n", ts_name); + DEBUGP(DRSL, "%s IPAC PDCH ACT ACK\n", ts_name); msg->lchan->ts->flags |= TS_F_PDCH_MODE; break; case RSL_MT_IPAC_PDCH_ACT_NACK: @@ -1951,7 +1951,7 @@ dh->c.msg_discr = ABIS_RSL_MDISC_DED_CHAN; dh->chan_nr = gsm_ts2chan_nr(ts, 0); - DEBUGP(DRSL, "%s IPAC_PDCH_%sACT\n", gsm_ts_name(ts), + DEBUGP(DRSL, "%s IPAC PDCH %sACT\n", gsm_ts_name(ts), act ? "" : "DE"); msg->dst = ts->trx->rsl_link; -- To view, visit https://gerrit.osmocom.org/177 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I8fb7a1c1beabb1f4388517383fd0bdc082d557ca Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Thu Jun 2 11:50:59 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 11:50:59 +0000 Subject: [PATCH] openbsc[master]: cosmetic: declare local var at top Message-ID: Review at https://gerrit.osmocom.org/178 cosmetic: declare local var at top Change-Id: Ie6f3394a18b6157f14469f676fff6849a503b694 --- M openbsc/src/libbsc/bsc_init.c 1 file changed, 1 insertion(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/78/178/1 diff --git a/openbsc/src/libbsc/bsc_init.c b/openbsc/src/libbsc/bsc_init.c index 5c27862..1012425 100644 --- a/openbsc/src/libbsc/bsc_init.c +++ b/openbsc/src/libbsc/bsc_init.c @@ -309,6 +309,7 @@ struct input_signal_data *isd = signal_data; struct gsm_bts_trx *trx = isd->trx; int ts_no, lchan_no; + int i; if (subsys != SS_L_INPUT) return -EINVAL; @@ -327,8 +328,6 @@ generate_cell_chan_list(ca, trx->bts); llist_for_each_entry(cur_trx, &trx->bts->trx_list, list) { - int i; - for (i = 0; i < ARRAY_SIZE(cur_trx->ts); i++) generate_ma_for_ts(&cur_trx->ts[i]); } -- To view, visit https://gerrit.osmocom.org/178 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Ie6f3394a18b6157f14469f676fff6849a503b694 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Thu Jun 2 11:51:00 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 11:51:00 +0000 Subject: [PATCH] openbsc[master]: dyn PDCH: Fix free slot search for chan_alloc_reverse == true Message-ID: Review at https://gerrit.osmocom.org/179 dyn PDCH: Fix free slot search for chan_alloc_reverse == true For chan_alloc_reverse, _lc_find_trx() should return the last free slot instead of the first. Original patch by jolly, but split in two by nhofmeyr. Change-Id: Ie919bfcaabab5286cbbbb1dbda0c140c62289503 --- M openbsc/src/libbsc/chan_alloc.c 1 file changed, 14 insertions(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/79/179/1 diff --git a/openbsc/src/libbsc/chan_alloc.c b/openbsc/src/libbsc/chan_alloc.c index de9da81..8600846 100644 --- a/openbsc/src/libbsc/chan_alloc.c +++ b/openbsc/src/libbsc/chan_alloc.c @@ -75,12 +75,24 @@ _lc_find_trx(struct gsm_bts_trx *trx, enum gsm_phys_chan_config pchan) { struct gsm_bts_trx_ts *ts; - int j, ss; + int j, start, stop, dir, ss; if (!trx_is_usable(trx)) return NULL; - for (j = 0; j < 8; j++) { + if (trx->bts->chan_alloc_reverse) { + /* check TS 7..0 */ + start = 7; + stop = -1; + dir = -1; + } else { + /* check TS 0..7 */ + start = 0; + stop = 8; + dir = 1; + } + + for (j = start; j != stop; j += dir) { ts = &trx->ts[j]; if (!ts_is_usable(ts)) continue; -- To view, visit https://gerrit.osmocom.org/179 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Ie919bfcaabab5286cbbbb1dbda0c140c62289503 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Thu Jun 2 11:51:00 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 11:51:00 +0000 Subject: [PATCH] openbsc[master]: dyn PDCH: allow allocating TCH/F on TCH/F_PDCH slots Message-ID: Review at https://gerrit.osmocom.org/180 dyn PDCH: allow allocating TCH/F on TCH/F_PDCH slots See comment added in the code. Original patch by jolly, but split in two, added comment and flipped the if() logic for readability by nhofmeyr. Change-Id: Iddd575873a2fe819fc182a6b3d4186caea1997e5 --- M openbsc/src/libbsc/chan_alloc.c 1 file changed, 10 insertions(+), 8 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/80/180/1 diff --git a/openbsc/src/libbsc/chan_alloc.c b/openbsc/src/libbsc/chan_alloc.c index 8600846..cd25bd9 100644 --- a/openbsc/src/libbsc/chan_alloc.c +++ b/openbsc/src/libbsc/chan_alloc.c @@ -96,14 +96,16 @@ ts = &trx->ts[j]; if (!ts_is_usable(ts)) continue; - /* ip.access dynamic TCH/F + PDCH combination */ - if (ts->pchan == GSM_PCHAN_TCH_F_PDCH && - pchan == GSM_PCHAN_TCH_F) { - /* we can only consider such a dynamic channel - * if the PDCH is currently inactive */ - if (ts->flags & TS_F_PDCH_MODE) - continue; - } else if (ts->pchan != pchan) + /* + * pchan must match; but when looking for TCH/F, allow a match + * with TCH/F_PDCH, to return dynamic TCH/F_PDCH slots to the + * channel allocator. Thus the channel allocator can pick a + * TCH/F_PDCH time slot and disable its PDCH later on (no need + * to check whether PDCH mode is currently active here). + */ + if (!(ts->pchan == pchan + || (ts->pchan == GSM_PCHAN_TCH_F_PDCH + && pchan == GSM_PCHAN_TCH_F))) continue; /* check if all sub-slots are allocated yet */ for (ss = 0; ss < subslots_per_pchan[pchan]; ss++) { -- To view, visit https://gerrit.osmocom.org/180 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Iddd575873a2fe819fc182a6b3d4186caea1997e5 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Thu Jun 2 11:51:00 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 11:51:00 +0000 Subject: [PATCH] openbsc[master]: dyn PDCH: Automatically deactivate/activate PDCH on TCH/F+PD... Message-ID: Review at https://gerrit.osmocom.org/181 dyn PDCH: Automatically deactivate/activate PDCH on TCH/F+PDCH channel Handle shared TCH/F+PDCH channels as regular TCH/F channels. Prior to activation, deactivate PDCH mode. After deactivation, restore PDCH mode. Change-Id: I5b7cff07ad9ac281a212daff8106a7d65c3c3145 --- M openbsc/include/openbsc/gsm_data_shared.h M openbsc/src/libbsc/abis_rsl.c M openbsc/src/libbsc/bsc_init.c 3 files changed, 45 insertions(+), 3 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/81/181/1 diff --git a/openbsc/include/openbsc/gsm_data_shared.h b/openbsc/include/openbsc/gsm_data_shared.h index c3d5978..7f9b0cc 100644 --- a/openbsc/include/openbsc/gsm_data_shared.h +++ b/openbsc/include/openbsc/gsm_data_shared.h @@ -256,6 +256,12 @@ struct gsm48_req_ref *rqd_ref; struct gsm_subscriber_connection *conn; + + struct { + /* channel activation type and handover ref */ + uint8_t act_type; + uint8_t ho_ref; + } dyn_pdch; #else /* Number of different GsmL1_Sapi_t used in osmo_bts_sysmo is 23. * Currently we don't share these headers so this is a magic number. */ diff --git a/openbsc/src/libbsc/abis_rsl.c b/openbsc/src/libbsc/abis_rsl.c index abe2f9b..59176df 100644 --- a/openbsc/src/libbsc/abis_rsl.c +++ b/openbsc/src/libbsc/abis_rsl.c @@ -470,6 +470,15 @@ if (rc < 0) return rc; + /* if channel is in PDCH mode, deactivate PDCH first */ + if (lchan->ts->pchan == GSM_PCHAN_TCH_F_PDCH + && (lchan->ts->flags & TS_F_PDCH_MODE)) { + /* store activation type and handover reference */ + lchan->dyn_pdch.act_type = act_type; + lchan->dyn_pdch.ho_ref = ho_ref; + return rsl_ipacc_pdch_activate(lchan->ts, 0); + } + ta = lchan->rqd_ta; /* BS11 requires TA shifted by 2 bits */ @@ -746,6 +755,11 @@ LOGP(DRSL, LOGL_NOTICE, "%s CHAN REL ACK but state %s\n", gsm_lchan_name(lchan), gsm_lchans_name(lchan->state)); + + /* Put PDCH channel back into PDCH mode first */ + if (lchan->ts->pchan == GSM_PCHAN_TCH_F_PDCH) + return rsl_ipacc_pdch_activate(lchan->ts, 1); + do_lchan_free(lchan); return 0; @@ -1187,6 +1201,26 @@ return 0; } +static int rsl_rx_pdch_act_ack(struct msgb *msg) +{ + msg->lchan->ts->flags |= TS_F_PDCH_MODE; + + /* We have activated PDCH, so now the channel is available again. */ + do_lchan_free(msg->lchan); + + return 0; +} + +static int rsl_rx_pdch_deact_ack(struct msgb *msg) +{ + msg->lchan->ts->flags &= ~TS_F_PDCH_MODE; + + rsl_chan_activate_lchan(msg->lchan, msg->lchan->dyn_pdch.act_type, + msg->lchan->dyn_pdch.ho_ref); + + return 0; +} + static int abis_rsl_rx_dchan(struct msgb *msg) { struct abis_rsl_dchan_hdr *rslh = msgb_l2(msg); @@ -1225,14 +1259,14 @@ break; case RSL_MT_IPAC_PDCH_ACT_ACK: DEBUGP(DRSL, "%s IPAC PDCH ACT ACK\n", ts_name); - msg->lchan->ts->flags |= TS_F_PDCH_MODE; + rc = rsl_rx_pdch_act_ack(msg); break; case RSL_MT_IPAC_PDCH_ACT_NACK: LOGP(DRSL, LOGL_ERROR, "%s IPAC PDCH ACT NACK\n", ts_name); break; case RSL_MT_IPAC_PDCH_DEACT_ACK: DEBUGP(DRSL, "%s IPAC PDCH DEACT ACK\n", ts_name); - msg->lchan->ts->flags &= ~TS_F_PDCH_MODE; + rc = rsl_rx_pdch_deact_ack(msg); break; case RSL_MT_IPAC_PDCH_DEACT_NACK: LOGP(DRSL, LOGL_ERROR, "%s IPAC PDCH DEACT NACK\n", ts_name); diff --git a/openbsc/src/libbsc/bsc_init.c b/openbsc/src/libbsc/bsc_init.c index 1012425..110e160 100644 --- a/openbsc/src/libbsc/bsc_init.c +++ b/openbsc/src/libbsc/bsc_init.c @@ -328,8 +328,10 @@ generate_cell_chan_list(ca, trx->bts); llist_for_each_entry(cur_trx, &trx->bts->trx_list, list) { - for (i = 0; i < ARRAY_SIZE(cur_trx->ts); i++) + for (i = 0; i < ARRAY_SIZE(cur_trx->ts); i++) { generate_ma_for_ts(&cur_trx->ts[i]); + cur_trx->ts[i].flags |= TS_F_PDCH_MODE; + } } } if (isd->link_type == E1INP_SIGN_RSL) -- To view, visit https://gerrit.osmocom.org/181 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I5b7cff07ad9ac281a212daff8106a7d65c3c3145 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Thu Jun 2 11:51:00 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 11:51:00 +0000 Subject: [PATCH] openbsc[master]: dyn pdch: send PDCH ACT for each TCH/F_PDCH on TRX RSL UP Message-ID: Review at https://gerrit.osmocom.org/182 dyn pdch: send PDCH ACT for each TCH/F_PDCH on TRX RSL UP Add dyn_pdch_init() and call from inp_sig_cb() upon RSL UP. Revert the |= TS_F_PDCH_MODE chunk from previous commit, since this flag will now be set after dyn_pdch_init() sent out the PDCH ACT, i.e. when the PDCH ACT ACK messages are received. Change-Id: I7bfc70527162c95b3d7ea853eda6376b4f1f1161 --- M openbsc/src/libbsc/bsc_init.c 1 file changed, 34 insertions(+), 4 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/82/182/1 diff --git a/openbsc/src/libbsc/bsc_init.c b/openbsc/src/libbsc/bsc_init.c index 110e160..02c949c 100644 --- a/openbsc/src/libbsc/bsc_init.c +++ b/openbsc/src/libbsc/bsc_init.c @@ -302,6 +302,36 @@ generate_ma_for_ts(&trx->ts[i]); } +static void dyn_pdch_init(struct gsm_bts_trx *trx) +{ + unsigned int i; + struct gsm_bts_trx_ts *ts; + int rc; + unsigned int pdch_act_count = 0; + + for (i = 0; i < TRX_NR_TS; i++) { + ts = &trx->ts[i]; + if (ts->pchan == GSM_PCHAN_TCH_F_PDCH) { + rc = rsl_ipacc_pdch_activate(ts, 1); + if (rc != 0) { + LOGP(DRSL, LOGL_ERROR, + "Failed to activate PDCH on" + " BTS %u TRX %u TS %u: %d\n", + trx->bts->nr, trx->nr, i, rc); + continue; + } + pdch_act_count ++; + } + } + + if (pdch_act_count) { + LOGP(DRSL, LOGL_NOTICE, + "Activated PDCH on %u dynamic TCH/F_PDCH time slots" + " for BTS %u TRX %u\n", + pdch_act_count, trx->bts->nr, trx->nr); + } +} + /* Callback function to be called every time we receive a signal from INPUT */ static int inp_sig_cb(unsigned int subsys, unsigned int signal, void *handler_data, void *signal_data) @@ -328,14 +358,14 @@ generate_cell_chan_list(ca, trx->bts); llist_for_each_entry(cur_trx, &trx->bts->trx_list, list) { - for (i = 0; i < ARRAY_SIZE(cur_trx->ts); i++) { + for (i = 0; i < ARRAY_SIZE(cur_trx->ts); i++) generate_ma_for_ts(&cur_trx->ts[i]); - cur_trx->ts[i].flags |= TS_F_PDCH_MODE; - } } } - if (isd->link_type == E1INP_SIGN_RSL) + if (isd->link_type == E1INP_SIGN_RSL) { bootstrap_rsl(trx); + dyn_pdch_init(trx); + } break; case S_L_INP_TEI_DN: LOGP(DLMI, LOGL_ERROR, "Lost some E1 TEI link: %d %p\n", isd->link_type, trx); -- To view, visit https://gerrit.osmocom.org/182 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I7bfc70527162c95b3d7ea853eda6376b4f1f1161 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Thu Jun 2 11:53:58 2016 From: gerrit-no-reply at lists.osmocom.org (Neels Hofmeyr) Date: Thu, 2 Jun 2016 11:53:58 +0000 Subject: openbsc[master]: dyn pdch: send PDCH ACT for each TCH/F_PDCH on TRX RSL UP In-Reply-To: References: Message-ID: Patch Set 1: forgot to mention: see OS#1565 -- To view, visit https://gerrit.osmocom.org/182 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I7bfc70527162c95b3d7ea853eda6376b4f1f1161 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Neels Hofmeyr Gerrit-HasComments: No From laforge at gnumonks.org Thu Jun 2 12:04:33 2016 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 2 Jun 2016 14:04:33 +0200 Subject: gerrit: refs/users vs. refs/heads/users In-Reply-To: <20160525110552.GA6661@dub6> References: <20160525110552.GA6661@dub6> Message-ID: <20160602120433.GM23339@nataraja> On Wed, May 25, 2016 at 01:05:52PM +0200, Neels Hofmeyr wrote: > Hi all, > > I have just changed the access configuration of gerrit.osmocom.org: [...] > Opinions welcome! Thanks, I think it pretty much represents the best option that I could think of... -- - 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 Thu Jun 2 11:53:19 2016 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 2 Jun 2016 13:53:19 +0200 Subject: Gerrit mails, from address, verbosity, etc In-Reply-To: <44F3A00E-2E73-40E9-80F2-09D0B7CBC4A8@freyther.de> References: <44F3A00E-2E73-40E9-80F2-09D0B7CBC4A8@freyther.de> Message-ID: <20160602115319.GL23339@nataraja> Dear all, I'm not very happy with the many gerrit mails on this list. By now it is dificult to point out an actual discussion thread among all the many gerrit auto-generated messages. The point is: You cannot reasonably respond to a gerrit-generated mail by replying to it, so you don't need to read it in the same folder/location/point-in-time as the actual human-initiated mails/discussion. So I think I'm now in favor of having all the gerrit mails removed from tis list and have them on a separate list. What's the general feeling of others about it? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Thu Jun 2 12:17:51 2016 From: holger at freyther.de (Holger Freyther) Date: Thu, 2 Jun 2016 14:17:51 +0200 Subject: Gerrit mails, from address, verbosity, etc In-Reply-To: <20160602115319.GL23339@nataraja> References: <44F3A00E-2E73-40E9-80F2-09D0B7CBC4A8@freyther.de> <20160602115319.GL23339@nataraja> Message-ID: <1C68E741-A438-4D75-A7B1-EEEB2E422745@freyther.de> > On 02 Jun 2016, at 13:53, Harald Welte wrote: > > Dear all, Hi! > I'm not very happy with the many gerrit mails on this list. By now it > is dificult to point out an actual discussion thread among all the many > gerrit auto-generated messages. > > The point is: You cannot reasonably respond to a gerrit-generated mail > by replying to it, so you don't need to read it in the same > folder/location/point-in-time as the actual human-initiated > mails/discussion. > > So I think I'm now in favor of having all the gerrit mails removed from > tis list and have them on a separate list. > > What's the general feeling of others about it? I agree it is too many mails. I would like to see the patch (and updated patches) and comments to it. "Merged", "+2" with no human comment should probably not be here. Is this something you can deal with? holger PS: Don't hold your breath but mail -> gerrit using the http API (and ignoring who commented, unless I can forge that easily) seems quite easy to do as well. From laforge at gnumonks.org Thu Jun 2 12:17:23 2016 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 2 Jun 2016 14:17:23 +0200 Subject: Stopping Gerrit on Sunday In-Reply-To: <729756F1-18FF-4893-8618-CDA990E9834B@freyther.de> References: <729756F1-18FF-4893-8618-CDA990E9834B@freyther.de> Message-ID: <20160602121723.GN23339@nataraja> Hi Holger, On Wed, Jun 01, 2016 at 02:29:05PM +0200, Holger Freyther wrote: > I am a bit fed-up to have to receive Neels non-productive mails every > single day and given my tight work schedule let's have him win, > declare Gerrit a failure and return to patchwork. Pleaes don't, it will just be more confusing and fragment our developments further. I actually come to like gerrit quite a bit. However, that's mostly as a reviwer. I will be pushing plenty of changes to gerrit over the next few days, so I will also know the pleasure of branches / patchets. I understand there are issues, but as Neels has alsso pointed out, let's not be too quick. We can still decide to go back after another 1-2 months or so. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From gerrit-no-reply at lists.osmocom.org Thu Jun 2 12:30:33 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 12:30:33 +0000 Subject: [PATCH] openbsc[master]: comment tweak for bsc_handover_start() Message-ID: Review at https://gerrit.osmocom.org/183 comment tweak for bsc_handover_start() Have a comment only in the .c file to remove dup, tweak wording. Change-Id: I6d19e2b5a794f8b5d8fb71791719447362c5ce85 --- M openbsc/include/openbsc/handover.h M openbsc/src/libbsc/handover_logic.c 2 files changed, 3 insertions(+), 6 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/83/183/1 diff --git a/openbsc/include/openbsc/handover.h b/openbsc/include/openbsc/handover.h index bd0d8ad..3fe71a2 100644 --- a/openbsc/include/openbsc/handover.h +++ b/openbsc/include/openbsc/handover.h @@ -3,9 +3,6 @@ struct gsm_subscriber_connection; -/* Hand over the specified logical channel to the specified new BTS. - * This is the main entry point for the actual handover algorithm, - * after it has decided it wants to initiate HO to a specific BTS */ int bsc_handover_start(struct gsm_lchan *old_lchan, struct gsm_bts *bts); /* clear any operation for this connection */ diff --git a/openbsc/src/libbsc/handover_logic.c b/openbsc/src/libbsc/handover_logic.c index 2b8c386..641cee4 100644 --- a/openbsc/src/libbsc/handover_logic.c +++ b/openbsc/src/libbsc/handover_logic.c @@ -85,9 +85,9 @@ return NULL; } -/* Hand over the specified logical channel to the specified new BTS. - * This is the main entry point for the actual handover algorithm, - * after it has decided it wants to initiate HO to a specific BTS */ +/* Hand over the specified logical channel to the specified new BTS. This is + * the main entry point for the actual handover algorithm, after the decision + * whether to initiate HO to a specific BTS. */ int bsc_handover_start(struct gsm_lchan *old_lchan, struct gsm_bts *bts) { struct gsm_lchan *new_lchan; -- To view, visit https://gerrit.osmocom.org/183 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I6d19e2b5a794f8b5d8fb71791719447362c5ce85 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Holger Freyther Gerrit-Reviewer: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Thu Jun 2 12:30:34 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 12:30:34 +0000 Subject: [PATCH] openbsc[master]: dyn PDCH: Add new_lchan argument to bsc_handover_start() Message-ID: Review at https://gerrit.osmocom.org/184 dyn PDCH: Add new_lchan argument to bsc_handover_start() This is useful if the caller already allocated a new lchan, which will be used to dynamically re-assign lchans. The old behavior is maintained by passing NULL. Change-Id: I2b7151f32f0c04c22f294eb5dd3c7d7dfddf35e7 --- M openbsc/include/openbsc/handover.h M openbsc/src/libbsc/handover_decision.c M openbsc/src/libbsc/handover_logic.c M openbsc/src/libmsc/vty_interface_layer3.c 4 files changed, 15 insertions(+), 10 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/84/184/1 diff --git a/openbsc/include/openbsc/handover.h b/openbsc/include/openbsc/handover.h index 3fe71a2..a4844c5 100644 --- a/openbsc/include/openbsc/handover.h +++ b/openbsc/include/openbsc/handover.h @@ -3,7 +3,8 @@ struct gsm_subscriber_connection; -int bsc_handover_start(struct gsm_lchan *old_lchan, struct gsm_bts *bts); +int bsc_handover_start(struct gsm_lchan *old_lchan, struct gsm_lchan *new_lchan, + struct gsm_bts *bts); /* clear any operation for this connection */ void bsc_clear_handover(struct gsm_subscriber_connection *conn, int free_lchan); diff --git a/openbsc/src/libbsc/handover_decision.c b/openbsc/src/libbsc/handover_decision.c index 0f07bca..8b92177 100644 --- a/openbsc/src/libbsc/handover_decision.c +++ b/openbsc/src/libbsc/handover_decision.c @@ -48,7 +48,7 @@ } /* and actually try to handover to that cell */ - return bsc_handover_start(lchan, new_bts); + return bsc_handover_start(lchan, NULL, new_bts); } /* did we get a RXLEV for a given cell in the given report? */ diff --git a/openbsc/src/libbsc/handover_logic.c b/openbsc/src/libbsc/handover_logic.c index 641cee4..3e38fda 100644 --- a/openbsc/src/libbsc/handover_logic.c +++ b/openbsc/src/libbsc/handover_logic.c @@ -87,10 +87,13 @@ /* Hand over the specified logical channel to the specified new BTS. This is * the main entry point for the actual handover algorithm, after the decision - * whether to initiate HO to a specific BTS. */ -int bsc_handover_start(struct gsm_lchan *old_lchan, struct gsm_bts *bts) + * whether to initiate HO to a specific BTS. + * + * If new_lchan is NULL, allocate a new lchan. If not NULL, new_lchan must be a + * newly allocated lchan passed in by the caller. */ +int bsc_handover_start(struct gsm_lchan *old_lchan, struct gsm_lchan *new_lchan, + struct gsm_bts *new_bts) { - struct gsm_lchan *new_lchan; struct bsc_handover *ho; static uint8_t ho_ref; int rc; @@ -101,19 +104,20 @@ return -EBUSY; DEBUGP(DHO, "(old_lchan on BTS %u, new BTS %u)\n", - old_lchan->ts->trx->bts->nr, bts->nr); + old_lchan->ts->trx->bts->nr, new_bts->nr); - osmo_counter_inc(bts->network->stats.handover.attempted); + osmo_counter_inc(new_bts->network->stats.handover.attempted); if (!old_lchan->conn) { LOGP(DHO, LOGL_ERROR, "Old lchan lacks connection data.\n"); return -ENOSPC; } - new_lchan = lchan_alloc(bts, old_lchan->type, 0); + if (!new_lchan) + new_lchan = lchan_alloc(new_bts, old_lchan->type, 0); if (!new_lchan) { LOGP(DHO, LOGL_NOTICE, "No free channel\n"); - osmo_counter_inc(bts->network->stats.handover.no_channel); + osmo_counter_inc(new_bts->network->stats.handover.no_channel); return -ENOSPC; } diff --git a/openbsc/src/libmsc/vty_interface_layer3.c b/openbsc/src/libmsc/vty_interface_layer3.c index 5d74e04..2ad7eab 100644 --- a/openbsc/src/libmsc/vty_interface_layer3.c +++ b/openbsc/src/libmsc/vty_interface_layer3.c @@ -641,7 +641,7 @@ } /* now start the handover */ - ret = bsc_handover_start(conn->lchan, bts); + ret = bsc_handover_start(conn->lchan, NULL, bts); if (ret != 0) { vty_out(vty, "%% Handover failed with errno %d.%s", ret, VTY_NEWLINE); -- To view, visit https://gerrit.osmocom.org/184 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I2b7151f32f0c04c22f294eb5dd3c7d7dfddf35e7 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Holger Freyther From gerrit-no-reply at lists.osmocom.org Thu Jun 2 12:30:34 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 12:30:34 +0000 Subject: [PATCH] openbsc[master]: dyn PDCH: Fix TCH/F+PDCH allocation and direction of chan_al... Message-ID: Review at https://gerrit.osmocom.org/185 dyn PDCH: Fix TCH/F+PDCH allocation and direction of chan_alloc() Always allow TCH/F+PDCH allocation, even if the current PDCH mode is not TCH/F. (This is required to allocate a TCH/F channel with active PDCH, that needs to be deactivated later.) Fix the reverse search of a free slot ("channel allocator ascending"). Change-Id: Id38386c1e6e201d7e9b1dfeae732641486d28a77 --- M openbsc/src/libbsc/chan_alloc.c 1 file changed, 18 insertions(+), 10 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/85/185/1 diff --git a/openbsc/src/libbsc/chan_alloc.c b/openbsc/src/libbsc/chan_alloc.c index de9da81..abbe500 100644 --- a/openbsc/src/libbsc/chan_alloc.c +++ b/openbsc/src/libbsc/chan_alloc.c @@ -75,23 +75,31 @@ _lc_find_trx(struct gsm_bts_trx *trx, enum gsm_phys_chan_config pchan) { struct gsm_bts_trx_ts *ts; - int j, ss; + int j, start, stop, dir, ss; if (!trx_is_usable(trx)) return NULL; - for (j = 0; j < 8; j++) { + if (trx->bts->chan_alloc_reverse) { + /* check TS 7..0 */ + start = 7; + stop = -1; + dir = -1; + } else { + /* check TS 0..7 */ + start = 0; + stop = 8; + dir = 1; + } + + for (j = start; j != stop; j += dir) { ts = &trx->ts[j]; if (!ts_is_usable(ts)) continue; - /* ip.access dynamic TCH/F + PDCH combination */ - if (ts->pchan == GSM_PCHAN_TCH_F_PDCH && - pchan == GSM_PCHAN_TCH_F) { - /* we can only consider such a dynamic channel - * if the PDCH is currently inactive */ - if (ts->flags & TS_F_PDCH_MODE) - continue; - } else if (ts->pchan != pchan) + /* pchan must match. */ + if (ts->pchan != pchan + && (ts->pchan != GSM_PCHAN_TCH_F_PDCH + || pchan != GSM_PCHAN_TCH_F)) continue; /* check if all sub-slots are allocated yet */ for (ss = 0; ss < subslots_per_pchan[pchan]; ss++) { -- To view, visit https://gerrit.osmocom.org/185 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Id38386c1e6e201d7e9b1dfeae732641486d28a77 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Holger Freyther From gerrit-no-reply at lists.osmocom.org Thu Jun 2 12:30:34 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 12:30:34 +0000 Subject: [PATCH] openbsc[master]: add DHODEC debug category, tweak DHO name Message-ID: Review at https://gerrit.osmocom.org/186 add DHODEC debug category, tweak DHO name Change-Id: If19caca84327ac0267a7e1f0efc84a614b154486 --- M openbsc/include/openbsc/debug.h M openbsc/src/libcommon/debug.c 2 files changed, 9 insertions(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/86/186/1 diff --git a/openbsc/include/openbsc/debug.h b/openbsc/include/openbsc/debug.h index 189ca47..aaa1ad0 100644 --- a/openbsc/include/openbsc/debug.h +++ b/openbsc/include/openbsc/debug.h @@ -22,6 +22,7 @@ DMSC, DMGCP, DHO, + DHODEC, DDB, DREF, DGPRS, diff --git a/openbsc/src/libcommon/debug.c b/openbsc/src/libcommon/debug.c index 7fb3ecb..e9befb3 100644 --- a/openbsc/src/libcommon/debug.c +++ b/openbsc/src/libcommon/debug.c @@ -107,7 +107,14 @@ }, [DHO] = { .name = "DHO", - .description = "Hand-Over", + .description = "Hand-Over Process", + .color = "\033[1;38m", + .enabled = 1, .loglevel = LOGL_NOTICE, + }, + [DHODEC] = { + .name = "DHODEC", + .description = "Hand-Over Decision", + .color = "\033[1;38m", .enabled = 1, .loglevel = LOGL_NOTICE, }, [DDB] = { -- To view, visit https://gerrit.osmocom.org/186 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: If19caca84327ac0267a7e1f0efc84a614b154486 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Holger Freyther From gerrit-no-reply at lists.osmocom.org Thu Jun 2 12:30:34 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 12:30:34 +0000 Subject: [PATCH] openbsc[master]: dyn PDCH: Automatically deactivate/activate PDCH on TCH/F+PD... Message-ID: Review at https://gerrit.osmocom.org/187 dyn PDCH: Automatically deactivate/activate PDCH on TCH/F+PDCH channel Handle shared TCH/F+PDCH channels as regular TCH/F channels. Prior to activation, deactivate PDCH mode. After deactivation, restore PDCH mode. Change-Id: Ided47641eebfdb815592b307bf38b5fb36663be5 --- M openbsc/include/openbsc/gsm_data_shared.h M openbsc/src/libbsc/abis_rsl.c M openbsc/src/libbsc/bsc_init.c 3 files changed, 43 insertions(+), 3 deletions(-) git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/87/187/1 diff --git a/openbsc/include/openbsc/gsm_data_shared.h b/openbsc/include/openbsc/gsm_data_shared.h index c3d5978..72e8cc4 100644 --- a/openbsc/include/openbsc/gsm_data_shared.h +++ b/openbsc/include/openbsc/gsm_data_shared.h @@ -256,6 +256,10 @@ struct gsm48_req_ref *rqd_ref; struct gsm_subscriber_connection *conn; + + /* channel activation type and handover ref */ + uint8_t act_type; + uint8_t ho_ref; #else /* Number of different GsmL1_Sapi_t used in osmo_bts_sysmo is 23. * Currently we don't share these headers so this is a magic number. */ diff --git a/openbsc/src/libbsc/abis_rsl.c b/openbsc/src/libbsc/abis_rsl.c index c3a0c5c..b56f7a7 100644 --- a/openbsc/src/libbsc/abis_rsl.c +++ b/openbsc/src/libbsc/abis_rsl.c @@ -470,6 +470,15 @@ if (rc < 0) return rc; + /* if channel is in PDCH mode, deactivate PDCH first */ + if (lchan->ts->pchan == GSM_PCHAN_TCH_F_PDCH + && (lchan->ts->flags & TS_F_PDCH_MODE)) { + /* store activation type and handover reference */ + lchan->act_type = act_type; + lchan->ho_ref = ho_ref; + return rsl_ipacc_pdch_activate(lchan->ts, 0); + } + ta = lchan->rqd_ta; /* BS11 requires TA shifted by 2 bits */ @@ -746,6 +755,11 @@ LOGP(DRSL, LOGL_NOTICE, "%s CHAN REL ACK but state %s\n", gsm_lchan_name(lchan), gsm_lchans_name(lchan->state)); + + /* Put PDCH channel back into PDCH mode first */ + if (lchan->ts->pchan == GSM_PCHAN_TCH_F_PDCH) + return rsl_ipacc_pdch_activate(lchan->ts, 1); + do_lchan_free(lchan); return 0; @@ -1187,6 +1201,26 @@ return 0; } +static int rsl_rx_pdch_act_ack(struct msgb *msg) +{ + msg->lchan->ts->flags |= TS_F_PDCH_MODE; + + /* We have activated PDCH, so now the channel is available again. */ + do_lchan_free(msg->lchan); + + return 0; +} + +static int rsl_rx_pdch_deact_ack(struct msgb *msg) +{ + msg->lchan->ts->flags &= ~TS_F_PDCH_MODE; + + rsl_chan_activate_lchan(msg->lchan, msg->lchan->act_type, + msg->lchan->ho_ref); + + return 0; +} + static int abis_rsl_rx_dchan(struct msgb *msg) { struct abis_rsl_dchan_hdr *rslh = msgb_l2(msg); @@ -1225,14 +1259,14 @@ break; case RSL_MT_IPAC_PDCH_ACT_ACK: DEBUGPC(DRSL, "%s IPAC PDCH ACT ACK\n", ts_name); - msg->lchan->ts->flags |= TS_F_PDCH_MODE; + rc = rsl_rx_pdch_act_ack(msg); break; case RSL_MT_IPAC_PDCH_ACT_NACK: LOGP(DRSL, LOGL_ERROR, "%s IPAC PDCH ACT NACK\n", ts_name); break; case RSL_MT_IPAC_PDCH_DEACT_ACK: DEBUGP(DRSL, "%s IPAC PDCH DEACT ACK\n", ts_name); - msg->lchan->ts->flags &= ~TS_F_PDCH_MODE; + rc = rsl_rx_pdch_deact_ack(msg); break; case RSL_MT_IPAC_PDCH_DEACT_NACK: LOGP(DRSL, LOGL_ERROR, "%s IPAC PDCH DEACT NACK\n", ts_name); diff --git a/openbsc/src/libbsc/bsc_init.c b/openbsc/src/libbsc/bsc_init.c index 5c27862..04452f7 100644 --- a/openbsc/src/libbsc/bsc_init.c +++ b/openbsc/src/libbsc/bsc_init.c @@ -329,8 +329,10 @@ llist_for_each_entry(cur_trx, &trx->bts->trx_list, list) { int i; - for (i = 0; i < ARRAY_SIZE(cur_trx->ts); i++) + for (i = 0; i < ARRAY_SIZE(cur_trx->ts); i++) { generate_ma_for_ts(&cur_trx->ts[i]); + cur_trx->ts[i].flags |= TS_F_PDCH_MODE; + } } } if (isd->link_type == E1INP_SIGN_RSL) -- To view, visit https://gerrit.osmocom.org/187 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Ided47641eebfdb815592b307bf38b5fb36663be5 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Holger Freyther From gerrit-no-reply at lists.osmocom.org Thu Jun 2 12:31:52 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 12:31:52 +0000 Subject: [ABANDON] openbsc[master]: comment tweak for bsc_handover_start() In-Reply-To: References: Message-ID: Holger Freyther has abandoned this change. Change subject: comment tweak for bsc_handover_start() ...................................................................... Abandoned -- To view, visit https://gerrit.osmocom.org/183 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: I6d19e2b5a794f8b5d8fb71791719447362c5ce85 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Holger Freyther Gerrit-Reviewer: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Thu Jun 2 12:32:00 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 12:32:00 +0000 Subject: [ABANDON] openbsc[master]: dyn PDCH: Add new_lchan argument to bsc_handover_start() In-Reply-To: References: Message-ID: Holger Freyther has abandoned this change. Change subject: dyn PDCH: Add new_lchan argument to bsc_handover_start() ...................................................................... Abandoned -- To view, visit https://gerrit.osmocom.org/184 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: I2b7151f32f0c04c22f294eb5dd3c7d7dfddf35e7 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Holger Freyther From gerrit-no-reply at lists.osmocom.org Thu Jun 2 12:32:09 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 12:32:09 +0000 Subject: [ABANDON] openbsc[master]: dyn PDCH: Fix TCH/F+PDCH allocation and direction of chan_al... In-Reply-To: References: Message-ID: Holger Freyther has abandoned this change. Change subject: dyn PDCH: Fix TCH/F+PDCH allocation and direction of chan_alloc() ...................................................................... Abandoned -- To view, visit https://gerrit.osmocom.org/185 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: Id38386c1e6e201d7e9b1dfeae732641486d28a77 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Holger Freyther From gerrit-no-reply at lists.osmocom.org Thu Jun 2 12:32:16 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 12:32:16 +0000 Subject: [ABANDON] openbsc[master]: add DHODEC debug category, tweak DHO name In-Reply-To: References: Message-ID: Holger Freyther has abandoned this change. Change subject: add DHODEC debug category, tweak DHO name ...................................................................... Abandoned -- To view, visit https://gerrit.osmocom.org/186 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: If19caca84327ac0267a7e1f0efc84a614b154486 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Holger Freyther From gerrit-no-reply at lists.osmocom.org Thu Jun 2 12:32:21 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 12:32:21 +0000 Subject: [ABANDON] openbsc[master]: dyn PDCH: Automatically deactivate/activate PDCH on TCH/F+PD... In-Reply-To: References: Message-ID: Holger Freyther has abandoned this change. Change subject: dyn PDCH: Automatically deactivate/activate PDCH on TCH/F+PDCH channel ...................................................................... Abandoned -- To view, visit https://gerrit.osmocom.org/187 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: Ided47641eebfdb815592b307bf38b5fb36663be5 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Holger Freyther From laforge at gnumonks.org Thu Jun 2 12:40:19 2016 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 2 Jun 2016 14:40:19 +0200 Subject: Gerrit mails, from address, verbosity, etc In-Reply-To: <1C68E741-A438-4D75-A7B1-EEEB2E422745@freyther.de> References: <44F3A00E-2E73-40E9-80F2-09D0B7CBC4A8@freyther.de> <20160602115319.GL23339@nataraja> <1C68E741-A438-4D75-A7B1-EEEB2E422745@freyther.de> Message-ID: <20160602124019.GS23339@nataraja> Hi Holger, On Thu, Jun 02, 2016 at 02:17:51PM +0200, Holger Freyther wrote: > I agree it is too many mails. I would like to see the patch (and > updated patches) and comments to it. "Merged", "+2" with no human > comment should probably not be here. Is this something you can deal > with? I _think_ so. But in the case of doubt, it could all be moved. I think if the list has 90% patches + reviews, it will be uninteresting for people outside the development team to subscribe to it, and users could feel intimidated to actually raise questions. At the same time, the project is too small to start separate -user and -devel mailing lists, either. But let's see what other have to say about it. > PS: Don't hold your breath but mail -> gerrit using the http API (and > ignoring who commented, unless I can forge that easily) seems quite > easy to do as well. Great, but I think it's not the most important issue to spend time on at this point... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From gerrit-no-reply at lists.osmocom.org Thu Jun 2 13:54:17 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 13:54:17 +0000 Subject: [MERGED] openbsc[master]: rename gsm0408_gprs_rcvmsg() to gsm0408_gprs_rcvmsg_gb() In-Reply-To: References: Message-ID: Holger Freyther has submitted this change and it was merged. Change subject: rename gsm0408_gprs_rcvmsg() to gsm0408_gprs_rcvmsg_gb() ...................................................................... rename gsm0408_gprs_rcvmsg() to gsm0408_gprs_rcvmsg_gb() This is the entry point for GMM from Gb. We will create a new one for Iu, so let's be explicit rather than implicit. Change-Id: I93c074bf99db041117c0dc03dc8255879845a875 --- M openbsc/include/openbsc/gprs_gmm.h M openbsc/src/gprs/gprs_gmm.c M openbsc/src/gprs/gprs_llc.c M openbsc/tests/sgsn/sgsn_test.c 4 files changed, 5 insertions(+), 5 deletions(-) Approvals: Harald Welte: Looks good to me, approved Jenkins Builder: Verified diff --git a/openbsc/include/openbsc/gprs_gmm.h b/openbsc/include/openbsc/gprs_gmm.h index 702b9b9..e0d8f77 100644 --- a/openbsc/include/openbsc/gprs_gmm.h +++ b/openbsc/include/openbsc/gprs_gmm.h @@ -10,7 +10,7 @@ int gsm48_tx_gsm_act_pdp_acc(struct sgsn_pdp_ctx *pdp); int gsm48_tx_gsm_deact_pdp_acc(struct sgsn_pdp_ctx *pdp); -int gsm0408_gprs_rcvmsg(struct msgb *msg, struct gprs_llc_llme *llme); +int gsm0408_gprs_rcvmsg_gb(struct msgb *msg, struct gprs_llc_llme *llme); int gsm0408_gprs_force_reattach(struct sgsn_mm_ctx *mmctx); int gsm0408_gprs_force_reattach_oldmsg(struct msgb *msg); void gsm0408_gprs_access_granted(struct sgsn_mm_ctx *mmctx); diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index 889ac98..1e10701 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -2087,8 +2087,8 @@ return rc; } -/* Main entry point for incoming 04.08 GPRS messages */ -int gsm0408_gprs_rcvmsg(struct msgb *msg, struct gprs_llc_llme *llme) +/* Main entry point for incoming 04.08 GPRS messages from Gb */ +int gsm0408_gprs_rcvmsg_gb(struct msgb *msg, struct gprs_llc_llme *llme) { struct gsm48_hdr *gh = (struct gsm48_hdr *) msgb_gmmh(msg); uint8_t pdisc = gsm48_hdr_pdisc(gh); diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index 4d21963..71178c9 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -663,7 +663,7 @@ switch (llhp.sapi) { case GPRS_SAPI_GMM: /* send LL_UNITDATA_IND to GMM */ - rc = gsm0408_gprs_rcvmsg(msg, lle->llme); + rc = gsm0408_gprs_rcvmsg_gb(msg, lle->llme); break; case GPRS_SAPI_SNDCP3: case GPRS_SAPI_SNDCP5: diff --git a/openbsc/tests/sgsn/sgsn_test.c b/openbsc/tests/sgsn/sgsn_test.c index 3fb359b..48f013d 100644 --- a/openbsc/tests/sgsn/sgsn_test.c +++ b/openbsc/tests/sgsn/sgsn_test.c @@ -196,7 +196,7 @@ msg = create_msg(data, data_len); msgb_tlli(msg) = tlli; bssgp_create_cell_id(msgb_bcid(msg), bssgp_raid, 0); - gsm0408_gprs_rcvmsg(msg, llme); + gsm0408_gprs_rcvmsg_gb(msg, llme); msgb_free(msg); } -- To view, visit https://gerrit.osmocom.org/170 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: I93c074bf99db041117c0dc03dc8255879845a875 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Thu Jun 2 13:54:37 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 13:54:37 +0000 Subject: [MERGED] openbsc[master]: gprs_gmm.c: Don't try to de-reference NULL mmctx In-Reply-To: References: Message-ID: Holger Freyther has submitted this change and it was merged. Change subject: gprs_gmm.c: Don't try to de-reference NULL mmctx ...................................................................... gprs_gmm.c: Don't try to de-reference NULL mmctx There was a comment in the code that certain GMM messages require a valid mmctx pointer. However, nothing actually checked if that pointer was in fact non-NULL. We plainly crashed if a MS would send us the wrong message in the wrong state. Original patch by Harald Welte, but it broke message validity checking, resulting in sgsn_test failure. This re-implements the NULL check in a different way, as explained by in-code comment. Change-Id: I7908de65bec91599f7042549b832cbbd7ae5a9a8 --- M openbsc/src/gprs/gprs_gmm.c 1 file changed, 32 insertions(+), 0 deletions(-) Approvals: Harald Welte: Looks good to me, approved Jenkins Builder: Verified diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index 1e10701..e788e3d 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -1339,6 +1339,15 @@ return rc; } + /* + * For a few messages, mmctx may be NULL. For most, we want to ensure a + * non-NULL mmctx. At the same time, we want to keep the message + * validity check intact, so that all message types appear in the + * switch statement and the default case thus means "unknown message". + * If we split the switch in two parts to check non-NULL halfway, the + * unknown-message check breaks, or we'd need to duplicate the switch + * cases in both parts. Just keep one large switch and add some gotos. + */ switch (gh->msg_type) { case GSM48_MT_GMM_RA_UPD_REQ: rc = gsm48_rx_gmm_ra_upd_req(mmctx, msg, llme); @@ -1348,20 +1357,30 @@ break; /* For all the following types mmctx can not be NULL */ case GSM48_MT_GMM_ID_RESP: + if (!mmctx) + goto null_mmctx; rc = gsm48_rx_gmm_id_resp(mmctx, msg); break; case GSM48_MT_GMM_STATUS: + if (!mmctx) + goto null_mmctx; rc = gsm48_rx_gmm_status(mmctx, msg); break; case GSM48_MT_GMM_DETACH_REQ: + if (!mmctx) + goto null_mmctx; rc = gsm48_rx_gmm_det_req(mmctx, msg); break; case GSM48_MT_GMM_DETACH_ACK: + if (!mmctx) + goto null_mmctx; LOGMMCTXP(LOGL_INFO, mmctx, "-> DETACH ACK\n"); mm_ctx_cleanup_free(mmctx, "GPRS DETACH ACK"); rc = 0; break; case GSM48_MT_GMM_ATTACH_COMPL: + if (!mmctx) + goto null_mmctx; /* only in case SGSN offered new P-TMSI */ LOGMMCTXP(LOGL_INFO, mmctx, "-> ATTACH COMPLETE\n"); mmctx_timer_stop(mmctx, 3350); @@ -1380,6 +1399,8 @@ osmo_signal_dispatch(SS_SGSN, S_SGSN_ATTACH, &sig_data); break; case GSM48_MT_GMM_RA_UPD_COMPL: + if (!mmctx) + goto null_mmctx; /* only in case SGSN offered new P-TMSI */ LOGMMCTXP(LOGL_INFO, mmctx, "-> ROUTING AREA UPDATE COMPLETE\n"); mmctx_timer_stop(mmctx, 3350); @@ -1398,6 +1419,8 @@ osmo_signal_dispatch(SS_SGSN, S_SGSN_UPDATE, &sig_data); break; case GSM48_MT_GMM_PTMSI_REALL_COMPL: + if (!mmctx) + goto null_mmctx; LOGMMCTXP(LOGL_INFO, mmctx, "-> PTMSI REALLLICATION COMPLETE\n"); mmctx_timer_stop(mmctx, 3350); mmctx->t3350_mode = GMM_T3350_MODE_NONE; @@ -1409,6 +1432,8 @@ rc = 0; break; case GSM48_MT_GMM_AUTH_CIPH_RESP: + if (!mmctx) + goto null_mmctx; rc = gsm48_rx_gmm_auth_ciph_resp(mmctx, msg); break; default: @@ -1419,6 +1444,13 @@ } return rc; + +null_mmctx: + LOGP(DMM, LOGL_ERROR, + "Received GSM 04.08 message type 0x%02x," + " but no MM context available\n", + gh->msg_type); + return -EINVAL; } static void mmctx_timer_cb(void *_mm) -- To view, visit https://gerrit.osmocom.org/171 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: I7908de65bec91599f7042549b832cbbd7ae5a9a8 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr From gerrit-no-reply at lists.osmocom.org Thu Jun 2 13:54:37 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 13:54:37 +0000 Subject: [MERGED] openbsc[master]: gprs_gmm.c: Make TLLI handling specific to Gb interface In-Reply-To: References: Message-ID: Holger Freyther has submitted this change and it was merged. Change subject: gprs_gmm.c: Make TLLI handling specific to Gb interface ...................................................................... gprs_gmm.c: Make TLLI handling specific to Gb interface Soem of the operations we perform in the GMM layer are specific to the GPRS/EDGE radio access network and its Gb interface. Let's make them conditional to that in preparation of supporting an Iu interface. Change-Id: I3efb7c5087afe8e2331ec17bd9fac5029f4bee6c --- M openbsc/src/gprs/gprs_gmm.c 1 file changed, 59 insertions(+), 35 deletions(-) Approvals: Harald Welte: Looks good to me, approved Jenkins Builder: Verified diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index e788e3d..d521342 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -904,8 +904,10 @@ strncpy(ctx->imsi, mi_string, sizeof(ctx->imsi) - 1); #endif } - ctx->gb.tlli = msgb_tlli(msg); - ctx->gb.llme = llme; + if (ctx->ran_type == MM_CTX_T_GERAN_Gb) { + ctx->gb.tlli = msgb_tlli(msg); + ctx->gb.llme = llme; + } msgid2mmctx(ctx, msg); break; case GSM_MI_TYPE_TMSI: @@ -920,8 +922,10 @@ ctx = sgsn_mm_ctx_alloc(msgb_tlli(msg), &ra_id); ctx->p_tmsi = tmsi; } - ctx->gb.tlli = msgb_tlli(msg); - ctx->gb.llme = llme; + if (ctx->ran_type == MM_CTX_T_GERAN_Gb) { + ctx->gb.tlli = msgb_tlli(msg); + ctx->gb.llme = llme; + } msgid2mmctx(ctx, msg); break; default: @@ -932,7 +936,8 @@ } /* Update MM Context with currient RA and Cell ID */ ctx->ra = ra_id; - ctx->gb.cell_id = cid; + if (ctx->ran_type == MM_CTX_T_GERAN_Gb) + ctx->gb.cell_id = cid; /* Update MM Context with other data */ ctx->drx_parms = drx_par; ctx->ms_radio_access_capa.len = ms_ra_acc_cap_len; @@ -950,13 +955,16 @@ } ctx->mm_state = GMM_COMMON_PROC_INIT; #endif - /* Even if there is no P-TMSI allocated, the MS will switch from - * foreign TLLI to local TLLI */ - ctx->gb.tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL); - /* Inform LLC layer about new TLLI but keep old active */ - gprs_llgmm_assign(ctx->gb.llme, ctx->gb.tlli, ctx->gb.tlli_new, - GPRS_ALGO_GEA0, NULL); + if (ctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Even if there is no P-TMSI allocated, the MS will + * switch from foreign TLLI to local TLLI */ + ctx->gb.tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL); + + /* Inform LLC layer about new TLLI but keep old active */ + gprs_llgmm_assign(ctx->gb.llme, ctx->gb.tlli, ctx->gb.tlli_new, + GPRS_ALGO_GEA0, NULL); + } ctx->pending_req = GSM48_MT_GMM_ATTACH_REQ; return gsm48_gmm_authorize(ctx); @@ -1218,8 +1226,10 @@ /* Update the MM context with the new RA-ID */ bssgp_parse_cell_id(&mmctx->ra, msgb_bcid(msg)); - /* Update the MM context with the new (i.e. foreign) TLLI */ - mmctx->gb.tlli = msgb_tlli(msg); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Update the MM context with the new (i.e. foreign) TLLI */ + mmctx->gb.tlli = msgb_tlli(msg); + } /* FIXME: Update the MM context with the MS radio acc capabilities */ /* FIXME: Update the MM context with the MS network capabilities */ @@ -1244,13 +1254,16 @@ sig_data.mm = mmctx; osmo_signal_dispatch(SS_SGSN, S_SGSN_UPDATE, &sig_data); #endif - /* Even if there is no P-TMSI allocated, the MS will switch from - * foreign TLLI to local TLLI */ - mmctx->gb.tlli_new = gprs_tmsi2tlli(mmctx->p_tmsi, TLLI_LOCAL); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Even if there is no P-TMSI allocated, the MS will switch from + * foreign TLLI to local TLLI */ + mmctx->gb.tlli_new = gprs_tmsi2tlli(mmctx->p_tmsi, TLLI_LOCAL); - /* Inform LLC layer about new TLLI but keep old active */ - gprs_llgmm_assign(mmctx->gb.llme, mmctx->gb.tlli, mmctx->gb.tlli_new, - GPRS_ALGO_GEA0, NULL); + /* Inform LLC layer about new TLLI but keep old active */ + gprs_llgmm_assign(mmctx->gb.llme, mmctx->gb.tlli, + mmctx->gb.tlli_new, GPRS_ALGO_GEA0, + NULL); + } /* Look at PDP Context Status IE and see if MS's view of * activated/deactivated NSAPIs agrees with our view */ @@ -1270,10 +1283,13 @@ rc = gsm48_tx_gmm_ra_upd_rej(msg, reject_cause); if (mmctx) mm_ctx_cleanup_free(mmctx, "GPRS RA UPDATE REJ"); - else - /* TLLI unassignment */ - gprs_llgmm_assign(llme, llme->tlli, 0xffffffff, GPRS_ALGO_GEA0, - NULL); + else { + if (llme) { + /* TLLI unassignment */ + gprs_llgmm_assign(llme, llme->tlli, 0xffffffff, + GPRS_ALGO_GEA0, NULL); + } + } return rc; } @@ -1387,10 +1403,13 @@ mmctx->t3350_mode = GMM_T3350_MODE_NONE; mmctx->p_tmsi_old = 0; mmctx->pending_req = 0; - /* Unassign the old TLLI */ - mmctx->gb.tlli = mmctx->gb.tlli_new; - gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, - GPRS_ALGO_GEA0, NULL); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Unassign the old TLLI */ + mmctx->gb.tlli = mmctx->gb.tlli_new; + gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, + mmctx->gb.tlli_new, + GPRS_ALGO_GEA0, NULL); + } mmctx->mm_state = GMM_REGISTERED_NORMAL; rc = 0; @@ -1407,10 +1426,12 @@ mmctx->t3350_mode = GMM_T3350_MODE_NONE; mmctx->p_tmsi_old = 0; mmctx->pending_req = 0; - /* Unassign the old TLLI */ - mmctx->gb.tlli = mmctx->gb.tlli_new; - gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, - GPRS_ALGO_GEA0, NULL); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Unassign the old TLLI */ + mmctx->gb.tlli = mmctx->gb.tlli_new; + gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, + GPRS_ALGO_GEA0, NULL); + } mmctx->mm_state = GMM_REGISTERED_NORMAL; rc = 0; @@ -1426,9 +1447,11 @@ mmctx->t3350_mode = GMM_T3350_MODE_NONE; mmctx->p_tmsi_old = 0; mmctx->pending_req = 0; - /* Unassign the old TLLI */ - mmctx->gb.tlli = mmctx->gb.tlli_new; - //gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, GPRS_ALGO_GEA0, NULL); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + /* Unassign the old TLLI */ + mmctx->gb.tlli = mmctx->gb.tlli_new; + //gprs_llgmm_assign(mmctx->gb.llme, 0xffffffff, mmctx->gb.tlli_new, GPRS_ALGO_GEA0, NULL); + } rc = 0; break; case GSM48_MT_GMM_AUTH_CIPH_RESP: @@ -2109,7 +2132,8 @@ int gsm0408_gprs_force_reattach(struct sgsn_mm_ctx *mmctx) { int rc; - gprs_llgmm_reset(mmctx->gb.llme); + if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) + gprs_llgmm_reset(mmctx->gb.llme); rc = gsm48_tx_gmm_detach_req( mmctx, GPRS_DET_T_MT_REATT_REQ, GMM_CAUSE_IMPL_DETACHED); -- To view, visit https://gerrit.osmocom.org/172 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: I3efb7c5087afe8e2331ec17bd9fac5029f4bee6c Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Thu Jun 2 13:54:37 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 13:54:37 +0000 Subject: [MERGED] openbsc[master]: gprs_gmm.c: Perform LLME operations only if we have one In-Reply-To: References: Message-ID: Holger Freyther has submitted this change and it was merged. Change subject: gprs_gmm.c: Perform LLME operations only if we have one ...................................................................... gprs_gmm.c: Perform LLME operations only if we have one In case the GMM message did not arrive over a Gb interface, there is no LLME (and thus the associated pointer is NULL). Don't try to perform operations on a NULL LLME. Change-Id: If7f24161cd2826f8ee238d4bc1090adf555cea4e --- M openbsc/src/gprs/gprs_gmm.c 1 file changed, 7 insertions(+), 5 deletions(-) Approvals: Harald Welte: Looks good to me, approved Jenkins Builder: Verified diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index d521342..c8f687b 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -1208,10 +1208,12 @@ } if (!mmctx) { - /* send a XID reset to re-set all LLC sequence numbers - * in the MS */ - LOGMMCTXP(LOGL_NOTICE, mmctx, "LLC XID RESET\n"); - gprs_llgmm_reset(llme); + if (llme) { + /* send a XID reset to re-set all LLC sequence numbers + * in the MS */ + LOGMMCTXP(LOGL_NOTICE, mmctx, "LLC XID RESET\n"); + gprs_llgmm_reset(llme); + } /* The MS has to perform GPRS attach */ /* Device is still IMSI attached for CS but initiate GPRS ATTACH, * see GSM 04.08, 4.7.5.1.4 and G.6 */ @@ -1314,7 +1316,7 @@ /* MMCTX can be NULL when called */ - if (!mmctx && + if (llme && !mmctx && gh->msg_type != GSM48_MT_GMM_ATTACH_REQ && gh->msg_type != GSM48_MT_GMM_RA_UPD_REQ) { LOGP(DMM, LOGL_NOTICE, "Cannot handle GMM for unknown MM CTX\n"); -- To view, visit https://gerrit.osmocom.org/173 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: If7f24161cd2826f8ee238d4bc1090adf555cea4e Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Thu Jun 2 13:54:37 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 13:54:37 +0000 Subject: [MERGED] openbsc[master]: sgsn_mm_ctx_cleanup_free(): clean up LLME iff present (Gb, n... In-Reply-To: References: Message-ID: Holger Freyther has submitted this change and it was merged. Change subject: sgsn_mm_ctx_cleanup_free(): clean up LLME iff present (Gb, not Iu) ...................................................................... sgsn_mm_ctx_cleanup_free(): clean up LLME iff present (Gb, not Iu) Assert that llme is unused for non-Gb (Iu) connections, and clean up otherwise. Make sure the cleanup is left below the sgsn_mm_ctx_free() call, as the comment states. Change-Id: I891ae21afc1f4f60580b822273b5435e0e17d46f --- M openbsc/src/gprs/gprs_sgsn.c 1 file changed, 10 insertions(+), 3 deletions(-) Approvals: Harald Welte: Looks good to me, approved Jenkins Builder: Verified diff --git a/openbsc/src/gprs/gprs_sgsn.c b/openbsc/src/gprs/gprs_sgsn.c index 8bb6850..722edec 100644 --- a/openbsc/src/gprs/gprs_sgsn.c +++ b/openbsc/src/gprs/gprs_sgsn.c @@ -197,10 +197,15 @@ void sgsn_mm_ctx_cleanup_free(struct sgsn_mm_ctx *mm) { - struct gprs_llc_llme *llme = mm->gb.llme; + struct gprs_llc_llme *llme = NULL; uint32_t tlli = mm->gb.tlli; struct sgsn_pdp_ctx *pdp, *pdp2; struct sgsn_signal_data sig_data; + + if (mm->ran_type == MM_CTX_T_GERAN_Gb) + llme = mm->gb.llme; + else + OSMO_ASSERT(mm->gb.llme == NULL); /* Forget about ongoing look-ups */ if (mm->ggsn_lookup) { @@ -237,8 +242,10 @@ sgsn_mm_ctx_free(mm); mm = NULL; - /* TLLI unassignment, must be called after sgsn_mm_ctx_free */ - gprs_llgmm_assign(llme, tlli, 0xffffffff, GPRS_ALGO_GEA0, NULL); + if (llme) { + /* TLLI unassignment, must be called after sgsn_mm_ctx_free */ + gprs_llgmm_assign(llme, tlli, 0xffffffff, GPRS_ALGO_GEA0, NULL); + } } -- To view, visit https://gerrit.osmocom.org/174 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: I891ae21afc1f4f60580b822273b5435e0e17d46f Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder From gerrit-no-reply at lists.osmocom.org Thu Jun 2 13:54:37 2016 From: gerrit-no-reply at lists.osmocom.org (Holger Freyther) Date: Thu, 2 Jun 2016 13:54:37 +0000 Subject: [MERGED] openbsc[master]: gprs: more conditionals for Gb specific actions In-Reply-To: References: Message-ID: Holger Freyther has submitted this change and it was merged. Change subject: gprs: more conditionals for Gb specific actions ...................................................................... gprs: more conditionals for Gb specific actions Change-Id: I213d21b9ddbf19e56269defcc6aa65aca4947140 --- M openbsc/src/gprs/gprs_gmm.c M openbsc/src/gprs/gprs_sgsn.c M openbsc/src/gprs/sgsn_libgtp.c 3 files changed, 14 insertions(+), 8 deletions(-) Approvals: Harald Welte: Looks good to me, approved Jenkins Builder: Verified diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index c8f687b..68ba326 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -1227,8 +1227,8 @@ rate_ctr_inc(&mmctx->ctrg->ctr[GMM_CTR_PKTS_SIG_IN]); /* Update the MM context with the new RA-ID */ - bssgp_parse_cell_id(&mmctx->ra, msgb_bcid(msg)); if (mmctx->ran_type == MM_CTX_T_GERAN_Gb) { + bssgp_parse_cell_id(&mmctx->ra, msgb_bcid(msg)); /* Update the MM context with the new (i.e. foreign) TLLI */ mmctx->gb.tlli = msgb_tlli(msg); } diff --git a/openbsc/src/gprs/gprs_sgsn.c b/openbsc/src/gprs/gprs_sgsn.c index 722edec..8f9f453 100644 --- a/openbsc/src/gprs/gprs_sgsn.c +++ b/openbsc/src/gprs/gprs_sgsn.c @@ -315,8 +315,10 @@ LOGPDPCTXP(LOGL_INFO, pdp, "Forcing release of PDP context\n"); - /* Force the deactivation of the SNDCP layer */ - sndcp_sm_deactivate_ind(&pdp->mm->gb.llme->lle[pdp->sapi], pdp->nsapi); + if (pdp->mm->ran_type == MM_CTX_T_GERAN_Gb) { + /* Force the deactivation of the SNDCP layer */ + sndcp_sm_deactivate_ind(&pdp->mm->gb.llme->lle[pdp->sapi], pdp->nsapi); + } memset(&sig_data, 0, sizeof(sig_data)); sig_data.pdp = pdp; diff --git a/openbsc/src/gprs/sgsn_libgtp.c b/openbsc/src/gprs/sgsn_libgtp.c index 504590b..d138500 100644 --- a/openbsc/src/gprs/sgsn_libgtp.c +++ b/openbsc/src/gprs/sgsn_libgtp.c @@ -352,9 +352,11 @@ goto reject; } - /* Activate the SNDCP layer */ - sndcp_sm_activate_ind(&pctx->mm->gb.llme->lle[pctx->sapi], pctx->nsapi); - return send_act_pdp_cont_acc(pctx); + if (pctx->mm->ran_type == MM_CTX_T_GERAN_Gb) { + /* Activate the SNDCP layer */ + sndcp_sm_activate_ind(&pctx->mm->gb.llme->lle[pctx->sapi], pctx->nsapi); + return send_act_pdp_cont_acc(pctx); + } reject: /* @@ -392,8 +394,10 @@ osmo_signal_dispatch(SS_SGSN, S_SGSN_PDP_DEACT, &sig_data); if (pctx->mm) { - /* Deactivate the SNDCP layer */ - sndcp_sm_deactivate_ind(&pctx->mm->gb.llme->lle[pctx->sapi], pctx->nsapi); + if (pctx->mm->ran_type == MM_CTX_T_GERAN_Gb) { + /* Deactivate the SNDCP layer */ + sndcp_sm_deactivate_ind(&pctx->mm->gb.llme->lle[pctx->sapi], pctx->nsapi); + } /* Confirm deactivation of PDP context to MS */ rc = gsm48_tx_gsm_deact_pdp_acc(pctx); -- To view, visit https://gerrit.osmocom.org/175 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: I213d21b9ddbf19e56269defcc6aa65aca4947140 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder From pablo at gnumonks.org Thu Jun 2 17:28:35 2016 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Thu, 2 Jun 2016 19:28:35 +0200 Subject: Gerrit mails, from address, verbosity, etc In-Reply-To: <20160602124019.GS23339@nataraja> References: <44F3A00E-2E73-40E9-80F2-09D0B7CBC4A8@freyther.de> <20160602115319.GL23339@nataraja> <1C68E741-A438-4D75-A7B1-EEEB2E422745@freyther.de> <20160602124019.GS23339@nataraja> Message-ID: <20160602172835.GA3473@salvia> On Thu, Jun 02, 2016 at 02:40:19PM +0200, Harald Welte wrote: > Hi Holger, > > On Thu, Jun 02, 2016 at 02:17:51PM +0200, Holger Freyther wrote: > > I agree it is too many mails. I would like to see the patch (and > > updated patches) and comments to it. "Merged", "+2" with no human > > comment should probably not be here. Is this something you can deal > > with? > > I _think_ so. But in the case of doubt, it could all be moved. I think > if the list has 90% patches + reviews, it will be uninteresting for > people outside the development team to subscribe to it, and users could > feel intimidated to actually raise questions. At the same time, the > project is too small to start separate -user and -devel mailing lists, > either. > > But let's see what other have to say about it. I would be pretty much supporting a different list for all these automated emails. Or is there a way Gerrit can interact better with email by restoring the previous workflow? I'm feeling like a robot here ;). I follow the mailing list from time to time, whenver I have some spare time, to follow track of what others are working on. My feeling is that this is not helping me. Are you really getting a plus with this new tool? What is in your opinion what really improves in your workflow since you use Gerrit? I just have concerns that this may just kill the little community we have? Cheers, Pablo From laforge at gnumonks.org Thu Jun 2 17:46:08 2016 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 2 Jun 2016 19:46:08 +0200 Subject: Gerrit mails, from address, verbosity, etc In-Reply-To: <20160602172835.GA3473@salvia> References: <44F3A00E-2E73-40E9-80F2-09D0B7CBC4A8@freyther.de> <20160602115319.GL23339@nataraja> <1C68E741-A438-4D75-A7B1-EEEB2E422745@freyther.de> <20160602124019.GS23339@nataraja> <20160602172835.GA3473@salvia> Message-ID: <20160602174608.GY23339@nataraja> Hi Pablo, On Thu, Jun 02, 2016 at 07:28:35PM +0200, Pablo Neira Ayuso wrote: > I would be pretty much supporting a different list for all these > automated emails. Or is there a way Gerrit can interact better with > email by restoring the previous workflow? Same concerns here. So make that "+2" for all gerrit mails on separate list. > I follow the mailing list from time to time, whenver I have some spare > time, to follow track of what others are working on. My feeling is > that this is not helping me. indeed, that was triggering my initial mail on this thread. > Are you really getting a plus with this new tool? What is in your > opinion what really improves in your workflow since you use Gerrit? I was very skeptical in the beginning, but from the maintainer point of view it is actually extremely useful. So I would recommend you give it a try from the point of "let's keep track of patches from various contributors, review them, provide feedback and eventually merge them" point of view. Comparing it to patchwork feels like comparing w3m to firefox ;) Some plus points: * you can immediately and automatically see who has reviewed and voted on each change (as opposed to manually collected "Acked-by" or the like) * when subsequent versions of a patch are submitted, you can easily see the diff between the previous (or any previous) version and the current version, with change requests (comments) interspersed into the diff, so you can see directly if your requests have been incorporated in the later version * all the review from all people is gathered in context of the particular code line / code lines, rather than spread over multiple diferent mails (one per reviwer) in an e-mail thread. * changes run through jenkins (build test, make check, make distcheck, or whatever tests you have there) automatically and are not eligible for merge if they cause such failures. This avoids merging patches only to discover immediately afterwards that they don't build or don't pass So I would really love to keep the above benefits. > I just have concerns that this may just kill the little community we > have? The many mails to the regular mailing lits: Yes, I really see the danger of this. But once those are a be on a separate list, that aspect doesn't matter anymore. Yes, every submitter needs to do some configuration before sending in a patch. But then, we're not the only software project that uses gerrit, so it's not an unusually high barrier. And then, the number of contributors is relatively small, so we can help them with the setup, if needed. 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 gerrit-no-reply at lists.osmocom.org Thu Jun 2 18:04:58 2016 From: gerrit-no-reply at lists.osmocom.org (Harald Welte) Date: Thu, 2 Jun 2016 18:04:58 +0000 Subject: libosmocore[master]: Add Finite State Machine abstraction code In-Reply-To: References: Message-ID: Patch Set 5: Code-Review-2 I'll likely submit an extended version soon -- To view, visit https://gerrit.osmocom.org/163 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I0b0965a912598c1f6b84042a99fea9d522642466 Gerrit-PatchSet: 5 Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Owner: Harald Welte Gerrit-Reviewer: Harald Welte Gerrit-Reviewer: Holger Freyther Gerrit-Reviewer: Jenkins Builder Gerrit-HasComments: No From laforge at gnumonks.org Thu Jun 2 18:56:22 2016 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 2 Jun 2016 20:56:22 +0200 Subject: Gerrit mails, from address, verbosity, etc In-Reply-To: <20160602172835.GA3473@salvia> References: <44F3A00E-2E73-40E9-80F2-09D0B7CBC4A8@freyther.de> <20160602115319.GL23339@nataraja> <1C68E741-A438-4D75-A7B1-EEEB2E422745@freyther.de> <20160602124019.GS23339@nataraja> <20160602172835.GA3473@salvia> Message-ID: <20160602185622.GA23339@nataraja> FYI, we have just switched the gerrit e-mail notifications from this list to a new gerrit-log at lists.osmocom.org mailing list, which can be found at https://lists.osmocom.org/mailman/listinfo/gerrit-log So if you want tho subscribe to the notifications, feel free to subscribe to that separate list. If not, simply stay on the project lists (openbsc at lists.osmocom.org, osmo-net-gprs at lists.osmocom.org) and you will not see any such auto-generated mails anymore. Sorry for any inconvenience caused. 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 Fri Jun 3 01:24:44 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 3 Jun 2016 03:24:44 +0200 Subject: building 3G now needs --enable-iu Message-ID: <20160603012444.GA5985@dub6> Dear 3G folks, this is to draw your attention to the new --enable-iu flag added to openbsc's ./configure on the sysmocom/iups branch (and awaiting approval on gerrit right now https://gerrit.osmocom.org/189 ). So if you update your sysmocom/iups branch and want to re-build for 3G, you now have to pass --enable-iu to ./configure, or no Iu* interface support will actually be built. (This means we can omit libasn1c etc. for a 2G build.) * We should probably add --enable-iu to the jenkins build soon -- either to always include it, or if we have the build time, as another matrix multiplier, I mean build once with --enable-iu and once without. It would make sense to add --enable-iu to jenkins before I go on to submit any more IuPS branch commits for review. * But we should merge the 3G branches in the other repositories to their masters before adding --enable-iu to the jenkins build: asn1c.git aper-prefix libosmo-sccp.git sysmocom/iu libosmo-sigtran.git sysmocom/sctp Any help there would be appreciated. * To be able to add --enable-iu to jenkins, we need to add asn1c, libasn1c, libosmo-sigtran and osmo-iuh to the build. I will have my attention directed mostly to other tasks, but I hope we can get these things done along the way. ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Fri Jun 3 09:10:59 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 3 Jun 2016 11:10:59 +0200 Subject: speech frame loss compensation In-Reply-To: References: <574EFCE1.1020304@sysmocom.de> <742AC70C-F66B-4519-B996-045E9F589528@freyther.de> Message-ID: <20160603091058.GH23339@nataraja> Hi Alexander and Max, I don't really have to add anything to what Alexander wrote, but to make it super-clear: On Wed, Jun 01, 2016 at 10:51:47PM +0300, Alexander Chemeris wrote: > Sequence number is incremented by 1 with every packet, even if the packet is > sent after a long pause (due to DTX). This way you know when you miss a packet. correct, and makes sense. > Timestamp is measured in samples and this is incremented by a number of samples > since the last packet. This way you know when to start playing the packet in > case of DTX. correct. How would a receiver ever know when to play back a given packet, if there was no constantly-incrementing timestamp generated by the transmitter sample clock. So this clock needs to continue to coult (like a ADC sample clock), whether we currently transmit RTP codec frames, or whether we currently suppress sending some codec frames. So in short: sqeuence numbers will increment by one with each frame transmitted, and timestamp will expose gaps while DTX is used. > A proper RTP library or rather a jitter buffer should handle this > automatically, but I'm not sure how does ortp handle it. that's the receiving side. The transmitter will have to put correct values in the frames, which we are not doing in osmo-bts at the moment. -- - 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 Tue Jun 7 00:19:27 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 7 Jun 2016 02:19:27 +0200 Subject: jenkins build stuck? Message-ID: <20160607001927.GA2684@dub6> It seems that http://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/186/ is stuck: Configuration OpenBSC-gerrit ? --disable-mgcp-transcoding,--enable-smpp,linux_amd64_ubuntu_1504 is still in the queue: Ubuntu-1504-64 is offline and http://jenkins.osmocom.org/jenkins/computer/Ubuntu-1504-64/log : ERROR: [06/06/16 15:46:34] [SSH] Error deleting file. java.util.concurrent.TimeoutException at java.util.concurrent.FutureTask.get(FutureTask.java:205) at hudson.plugins.sshslaves.SSHLauncher.afterDisconnect(SSHLauncher.java:1279) at hudson.slaves.SlaveComputer$3.run(SlaveComputer.java:618) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) [06/06/16 15:46:34] [SSH] Connection closed. ERROR: [06/06/16 15:46:34] [SSH] Error deleting file. java.lang.IllegalStateException: Cannot open session, you need to establish a connection first. at com.trilead.ssh2.Connection.openSession(Connection.java:1124) at com.trilead.ssh2.Connection.exec(Connection.java:1551) at hudson.plugins.sshslaves.SSHLauncher$3.run(SSHLauncher.java:1259) [06/06/16 15:46:34] [SSH] Opening SSH connection to 127.0.6.1:2222. at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Tue Jun 7 00:26:16 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 7 Jun 2016 02:26:16 +0200 Subject: jenkins build stuck? In-Reply-To: <20160607001927.GA2684@dub6> References: <20160607001927.GA2684@dub6> Message-ID: <20160607002616.GA8617@dub6> One of the builds for this patch failed already. It seems the ssh is not retrying to connect but just failed ~12 hours ago and will sit there forever; so I removed the scheduled build. Alas, the next build (for the same patch) goes stuck the same way, so the build slave seems to be offline for reals. How to fix? ~Neels On Tue, Jun 07, 2016 at 02:19:27AM +0200, Neels Hofmeyr wrote: > It seems that http://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/186/ is stuck: > > Configuration OpenBSC-gerrit ? --disable-mgcp-transcoding,--enable-smpp,linux_amd64_ubuntu_1504 is still in the queue: Ubuntu-1504-64 is offline > > and http://jenkins.osmocom.org/jenkins/computer/Ubuntu-1504-64/log : > > ERROR: [06/06/16 15:46:34] [SSH] Error deleting file. > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at hudson.plugins.sshslaves.SSHLauncher.afterDisconnect(SSHLauncher.java:1279) > at hudson.slaves.SlaveComputer$3.run(SlaveComputer.java:618) > at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > [06/06/16 15:46:34] [SSH] Connection closed. > ERROR: [06/06/16 15:46:34] [SSH] Error deleting file. > java.lang.IllegalStateException: Cannot open session, you need to establish a connection first. > at com.trilead.ssh2.Connection.openSession(Connection.java:1124) > at com.trilead.ssh2.Connection.exec(Connection.java:1551) > at hudson.plugins.sshslaves.SSHLauncher$3.run(SSHLauncher.java:1259) > [06/06/16 15:46:34] [SSH] Opening SSH connection to 127.0.6.1:2222. > at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From holger at freyther.de Tue Jun 7 05:28:44 2016 From: holger at freyther.de (Holger Freyther) Date: Tue, 7 Jun 2016 07:28:44 +0200 Subject: jenkins build stuck? In-Reply-To: <20160607002616.GA8617@dub6> References: <20160607001927.GA2684@dub6> <20160607002616.GA8617@dub6> Message-ID: > On 07 Jun 2016, at 02:26, Neels Hofmeyr wrote: Hi! > One of the builds for this patch failed already. > > It seems the ssh is not retrying to connect but just failed ~12 hours ago and > will sit there forever; so I removed the scheduled build. > > Alas, the next build (for the same patch) goes stuck the same way, so the build > slave seems to be offline for reals. How to fix? sorry about that. I fixed it and it builds again but it will break again as well. Long story: At OsmoDevCon I upgraded jenkins to a less vulnerable version. This required a JDK/JRE upgrade on our Debian6.0/i386 (Linux syscall compat by FreeBSD) build system and somehow this still failed. So in a rush I moved the builds to use the Ubuntu based AMD64 build that has been used for the asciidoc generation. Now to the bad stuff. The VM/jail is not reboot safe as on boot /usr/local and other directories are not in the path _and_ the VirtualBox disk image is a plain file in a filesystem with quota. It runs out of quota because once a day the zfs-snap tool runs and makes snapshots of all volumes (it can't exclude a specific one) and this means that even removing files will not lead to more space. The Plan: Sysmocom has agreed to move the builder from my own machine to a newly rented one and then I will use bhyve + ZFS disk volume (block device backed by ZFS) and the problem will be gone. The only issue is that I didn't have time for that the last two weekends. holger PS: I will probably write a small script to undo some of the work zfs-snap did everyday. From robert.steve07 at gmail.com Tue Jun 7 10:53:32 2016 From: robert.steve07 at gmail.com (robert) Date: Tue, 7 Jun 2016 13:53:32 +0300 Subject: fn-advance value Message-ID: <4CBD6753-6E03-457E-9800-CB42A3CE2368@gmail.com> Hi, in some tutorials fn-advance value is set to 20 and in some other tutorials it is set to 30. What is better to choose and does it really affect the performance of the BTS. Best regards, From sebastian.stumpf87 at googlemail.com Thu Jun 2 11:35:39 2016 From: sebastian.stumpf87 at googlemail.com (Sebastian Stumpf) Date: Thu, 2 Jun 2016 13:35:39 +0200 Subject: osmo-bts - branch:laforge/virt_phy - questions on virtual layer implementation Message-ID: Hi, as a part of my master thesis I am currently trying to complete the implementation of the virtual physical layer in the laforge/virt-bts branch in osmo-bts.git. I already set up the projects and analyzed/debugged some of the code. Now I have a few things to ask or be confirmed by the pros :). 1. The sent messages on the virtual physical layer will be wrapped in a GSM_TAP header. I would like to analyze and implement the Uplink (MS->BTS) on the BTS side first, by sending dummy messages a small program and then processing them in the BTS. Unfortunately I don't have these dummy messages. Can anyone of you provide me with some examples for the msgs coming from the MS side (Access Burst on RACH, Uplink Burst on TCH, RSSI on SACCH, Location Update Request on SDCCH, Authentication Response on SDCCH) or tell me how else I can get my fingers on them? 2. Did I correctly understand that the virt_um_rcv_cb() method in l1_id.c will unwrap incoming GSM_TAP messages and distribute/forward them to layer2? Is the correct l2 interface to use l1sap.c from the common part? E.g. l1sap_ph_rach_ind(..) for incoming RACH msg from MS. 3. Does any logic to unwrap and forward GSM_TAP messages already exist or was that solely used for logging via wireshark by now. 4. I added some comments to the code, mostly to document my own unterstandings. But as I am no expert yet, they might contain some logical errors. Can I keep these in the code when commiting or better remove them? 5. Should I create a new branch for my work (e.g. stumpf/virt_phy) or commit to the existing? Not so important Questions: 6. I had a compilation error caused by 2 missing methods in the main.c.I added empty method bodies for bts_model_phy_link_set_defaults(..) and bts_model_phy_instance_set_defaults(..) and everything seems okay so far. Can I do that or did I miss something here? 7. To check if I receive incoming messages from the registered virtual UM multicast socket I periodically wrote a dummy text to it with a small program. As the registered callback method virt_um_rcvcb(..) wasn't called I checked the initialization of the multicast socket (virtual_um.c->virt_um_init(..)). After some research it seems that mcast sockets do not support a call of connect() after a bind(). Removing the call that connects the socket to the multicast group and port, seems to work. Is that okay or are there any problems I could run into by not connecting to the mcast socket? I think connect() is usally used on tcp sockets. Thank you very much in advance for your answers! Kind Regards, Sebastian Stumpf From sbormike at gmail.com Mon Jun 6 09:00:40 2016 From: sbormike at gmail.com (mike sbor) Date: Mon, 6 Jun 2016 12:00:40 +0300 Subject: about rssi encoding of ublox raw data Message-ID: Hello, I am trying to generate ephemeris data (that I get from a ublox receiver) in RRLP format. I have came across the following discussing n openbsc mailing list. http://openbsc.osmocom.narkive.com/8rLcJRc2/rrlp-ephemeris-data#post9 at the end of the discussion, Dieter Spaar wrote that he found a bug fix for a problem. Can you please guide me about where to look for this feature in the git repository? In the discussion, Slyvian has attached a project but I am not sure whether this bug fix is there or not Thanks a lot rifo -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Jun 8 12:12:04 2016 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 8 Jun 2016 14:12:04 +0200 Subject: osmo-bts - branch:laforge/virt_phy - questions on virtual layer implementation In-Reply-To: References: Message-ID: <20160608121204.GB1439@nataraja> Hi Sebastian, you posted to the list without subscribing to it first, so your post was stuck in the moderator queue, whcih only gets reviewd very unfrequently, sorry. On Thu, Jun 02, 2016 at 01:35:39PM +0200, Sebastian Stumpf wrote: > as a part of my master thesis I am currently trying to complete the > implementation of the virtual physical layer in the laforge/virt-bts > branch in osmo-bts.git. great! > 1. The sent messages on the virtual physical layer will be wrapped > in a GSM_TAP header. I would like to analyze and implement the Uplink > (MS->BTS) on the BTS side first, by sending dummy messages a small > program and then processing them in the BTS. Unfortunately I don't > have these dummy messages. Can anyone of you provide me with some > examples for the msgs coming from the MS side (Access Burst on RACH, > Uplink Burst on TCH, RSSI on SACCH, Location Update Request on SDCCH, > Authentication Response on SDCCH) or tell me how else I can get my > fingers on them? I think rather than creating custom code to generate the messages for testing, it makes more sense to modify OsmocomBB to generate the required messages and send them over GSMTAP. Basically replace anything below the L1CTL protocol of OsmocomBB with a virtual GSMTAP layer. Encoding the messages is the simple part. Implementing all the protocol logic and state machines on top of it is the hard part, and without that it will be difficult to test osmo-bts-virtual. Also, I would recommend to first complete the downlink path, i.e. osmo-bts-virt downlink transmission into GSMTAP (should be thre more or less already), and then add the receptionof downlink GSMTAP to OsmocomBB. At some point, OsmocomBB should be able to detect your virtual BTS just like it would detect a real BTS when used with a real phone. From that point onwards, it will try to send RACH requesets and establish a SDDCH for location update, and you can implement it step by step. > 2. Did I correctly understand that the virt_um_rcv_cb() method in > l1_id.c will unwrap incoming GSM_TAP messages and distribute/forward > them to layer2? yes. > Is the correct l2 interface to use l1sap.c from the > common part? E.g. l1sap_ph_rach_ind(..) for incoming RACH msg from MS. yes. > 3. Does any logic to unwrap and forward GSM_TAP messages already > exist or was that solely used for logging via wireshark by now. I don't think any GSMTAP parser/receiver outside wireshark exists so far, sorry. > 4. I added some comments to the code, mostly to document my own > unterstandings. But as I am no expert yet, they might contain some > logical errors. Can I keep these in the code when commiting or better > remove them? feel free to submit an 'add comments to the code' patch via gerrit against master, and we will review it and (hopefully) merge it. This patch/patchset should not introduce any logical changes, just contain the comments. > 5. Should I create a new branch for my work (e.g. stumpf/virt_phy) or > commit to the existing? I think the best strategy is to rebase the laforge/virt-bts on current master, and then build your own branch on top of that. > 6. I had a compilation error caused by 2 missing methods in the > main.c.I added empty method bodies for > bts_model_phy_link_set_defaults(..) and > bts_model_phy_instance_set_defaults(..) and everything seems okay so > far. Can I do that or did I miss something here? The two methods have been added to the phy_link abstraction betewen the bts-model-* and commonpart after the laforge/virt-bts was created. You can simply use empty functions for the time being, yes. > 7. To check if I receive incoming messages from the registered > virtual UM multicast socket I periodically wrote a dummy text to it > with a small program. As the registered callback method > virt_um_rcvcb(..) wasn't called I checked the initialization of the > multicast socket (virtual_um.c->virt_um_init(..)). sorry to hear that. As indicated, I started with downlink first, and the next logical step would have been on te OsmocomBB side, and I never got further. > After some research it seems that mcast sockets do not support a call > of connect() after a bind(). Removing the call that connects the > socket to the multicast group and port, seems to work. Is that okay or > are there any problems I could run into by not connecting to the mcast > socket? It's been many years (probably about 15!) since I last wrote IP multicast applications, so I didn't recall the detailed semantics,sorry. Indeed your research seems right. So drop the connect(). > I think connect() is usally used on tcp sockets. it is equally usual to use it on UDP sockets, if yo have a stream between two peers. If you don't conncet the socket, you cannot use write/send/send, but you have to use sendto() and always pass the destination address of the packet with every syscall, rather than setting it once at time of stream establishment. So I wanted to use the same logic for UDP multicast sockets, but apparently that doesn't work, you thus probably have to use an explicit sendto() for all frames, like for other unconnected UDP unicast sockets, too. > Thank you very much in advance for your answers! Thanks for working on this, looking forward to your patches! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From sbormike at gmail.com Sat Jun 11 08:19:19 2016 From: sbormike at gmail.com (mike sbor) Date: Sat, 11 Jun 2016 11:19:19 +0300 Subject: RRLP encoding related Message-ID: Hello, I am trying to generate ephemeris data (that I get from a ublox receiver) in RRLP format. I have came across the following discussing n openbsc mailing list. http://openbsc.osmocom.narkive.com/8rLcJRc2/rrlp-ephemeris-data#post9 at the end of the discussion, Dieter Spaar wrote that he found a bug fix for a problem. Can you please guide me about where to look for this feature in the git repository? In the discussion, Slyvian has attached a project but I am not sure whether this bug fix is there or not I am planning to buy/manufacture the board that Slyvian has designed for ublox lea 6 and try producing assisted gps data in rrlp format http://openbsc.osmocom.org/trac/wiki/osmo-lea6t-gps Thanks a lot for your help rifo -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuraev at sysmocom.de Mon Jun 13 15:08:11 2016 From: msuraev at sysmocom.de (Max) Date: Mon, 13 Jun 2016 17:08:11 +0200 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> Message-ID: <575ECC5B.1050309@sysmocom.de> Hi. I'd like to get back to the status of this one. Are there any patches available somewhere which I could try? Do we have a ticket to track this or shall I make one? On 04/12/2016 02:04 AM, Tom Tsou wrote: > Harald, > > Thank you for the thorough log analysis which is greatly helpful. > > On Sat, Apr 9, 2016 at 3:25 AM, Harald Welte wrote: >> Looking at the got log, the above function call of >> oml_mo_tx_sw_act_rep() for the baseband transceiver was always sent >> unconditionally from within check_tranceiver_availability() even in >> Jolly's original osmo-bts-trx code from February 2013, see commit >> acc71ffb4b61b3354bbb2fa14981e4e6a46946e6. THe code even states that iti >> s a HACK and it should only be done once we receive CLOCK indications >> from osmo-trx. However, even that is wrong, as CLOCK is already >> received in Frame 11, too soon to make that a criterion. > I noticed the behavior surrounding check_transceiver_availability() > seemed suspect, but I wasn't sure about related effects. Indeed, if I > restrict sections of check_transceiver_availability() containing > oml_mo_tx_sw_act_rep() to running once, I am able to reach a > functional OML setup (sometimes to the point of TCH channel > establishment). > > Related is the question of when osmo-trx should send CLOCK > indications. Right now a CLOCK indications is sent with arrival of > commands on the control interface. After starting, CLOCK indications > are sent at an one second interval (216 frames). The indications sent > from the control interface are why osmo-bts is receiving CLOCK so > early. > >> Solution: >> * OML initialization (the most complex part of Abis) needs to be >> more properly handled. No part of the code should do something like >> dynamically sending software activation reports at runtime. In >> osm-bts-trx, every time 'transceiver_available' goes from 0->1 (which >> apparently can happen even after start), a software activation report >> is sent to the BSC. This is wrong. The software is only activated >> once during boot, and it is activated not before the parent MOs for >> BTS and Site Manager are enabled. > I can confirm that the sending of SW activation reports is currently > broken and prevents usable operation with osmo-bts-trx. To start, I'll > look into a better approach to the 'transceiver_available' state and > limiting SW activation messages. Hopefully that can at least get us to > a usable state with osmo-bts-trx. > >> Unrelated to that, osmo-bts-trx desparately needs to avoid the use of >> global variables. Each gsm_bts_trx / gsm_bts / phy_link / phy_instance >> has private data store for implementation-specific state. global >> variables have always been discouraged. > Agreed and noted. > > -TT -- Max Suraev 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 msuraev at sysmocom.de Mon Jun 13 15:15:17 2016 From: msuraev at sysmocom.de (Max) Date: Mon, 13 Jun 2016 17:15:17 +0200 Subject: osmo-trx issues Message-ID: <575ECE05.7000300@sysmocom.de> Hi. While running osmo-trx with B200 I've noticed following log messages repeated multiple times: 1) WARNING 3011271488 16:59:00.1 Transceiver.cpp:674:pullRadioVector: Clipping detected on received RACH or Normal Burst 2) ERR 3011304256 16:58:12.9 UHDDevice.cpp:1512:write: Skipping buffer data: timestamp=210353475 time_end=202360063 How bad is that: are those break everything completely or can be sometimes ignored? What could be causing it and what can be done to try to fix it (hw/sw)? Note, I run it as follows: sudo chrt 20 ./Transceiver52M/osmo-trx -- Max Suraev 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 Mon Jun 13 16:04:03 2016 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 13 Jun 2016 18:04:03 +0200 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> Message-ID: <20160613160403.GY28336@nataraja> Hi Tom and others, On Mon, Apr 11, 2016 at 05:04:13PM -0700, Tom Tsou wrote: > Related is the question of when osmo-trx should send CLOCK > indications. Right now a CLOCK indications is sent with arrival of > commands on the control interface. After starting, CLOCK indications > are sent at an one second interval (216 frames). The indications sent > from the control interface are why osmo-bts is receiving CLOCK so > early. I don't know, to be honest. I didn't write osmo-bts-trx. Other PHY layers we interact send us information on the GSM frame number with every frame number increment. We also receive PH-ReadyToSend.ind in line with GSM PHY layer specifications for each frame to be sent. osmo-bts simply responds to those and all clock handling is entirely in the PHY. As osmo-trx dosen't do that (it's only half of a PHY layer), the missing part (scheduler) is implemented inside osmo-bts-trx. This scheduler is then generating the equivalent of the PH-ReadyToSend.ind towards the L1SAP and the common part of OsmoBTS. So in osmo-bts-trx it seems that there is code in trx_sched_clock() that tries to generate the frame numbers locally in between perios of no "CLOCK IND" from osmo-trx by starting an osmo_timer for it. This seems a bit ugly but of course reduces the number of UDP packets that we need to process. If osmo-bts-trx users have not experienced any timing related issues, I think there is no reason to introduce any changes itno this part, i.e. keep the frequency of the "CLOCK IND" frames as-is, to also remain compatible with other OpenBTS-like transceiver implementations. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Mon Jun 13 16:58:46 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 13 Jun 2016 19:58:46 +0300 Subject: osmo-trx issues In-Reply-To: <575ECE05.7000300@sysmocom.de> References: <575ECE05.7000300@sysmocom.de> Message-ID: Hi Max, On Mon, Jun 13, 2016 at 6:15 PM, Max wrote: > While running osmo-trx with B200 I've noticed following log messages > repeated multiple times: > > 1) WARNING 3011271488 16:59:00.1 Transceiver.cpp:674:pullRadioVector: > Clipping detected on received RACH or Normal Burst This means that your phone transmit at a level which saturates BTS's receive chain. Osmo-trx can't demodulate the signal and prints this message. I don't have much experience with USRPs, but general way to avoid this is: 1) Decrease "ms max power", so that phone starts with lower power, 2) Reduce "rxgain" in osmo-bts config 3) Add an attenuator to your Tx/Rx chains. > 2) ERR 3011304256 16:58:12.9 UHDDevice.cpp:1512:write: Skipping buffer > data: timestamp=210353475 time_end=202360063 This means that you're loosing samples between the device and UHD. Can't help you much here, because it's device specific. May be Thomas can suggest something. This is not the end of the world, but it may lead to all kinds of unstable behavior similar to when you have really bad radio link and bursts are dropped randomly. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From alexander.chemeris at gmail.com Mon Jun 13 18:39:18 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 13 Jun 2016 21:39:18 +0300 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: <20160613160403.GY28336@nataraja> References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> <20160613160403.GY28336@nataraja> Message-ID: On Mon, Jun 13, 2016 at 7:04 PM, Harald Welte wrote: > On Mon, Apr 11, 2016 at 05:04:13PM -0700, Tom Tsou wrote: > >> Related is the question of when osmo-trx should send CLOCK >> indications. Right now a CLOCK indications is sent with arrival of >> commands on the control interface. After starting, CLOCK indications >> are sent at an one second interval (216 frames). The indications sent >> from the control interface are why osmo-bts is receiving CLOCK so >> early. > > I don't know, to be honest. I didn't write osmo-bts-trx. Other PHY > layers we interact send us information on the GSM frame number with > every frame number increment. > > We also receive PH-ReadyToSend.ind in line with GSM PHY layer > specifications for each frame to be sent. osmo-bts simply responds to > those and all clock handling is entirely in the PHY. > > As osmo-trx dosen't do that (it's only half of a PHY layer), the > missing part (scheduler) is implemented inside osmo-bts-trx. This > scheduler is then generating the equivalent of the PH-ReadyToSend.ind > towards the L1SAP and the common part of OsmoBTS. > > So in osmo-bts-trx it seems that there is code in trx_sched_clock() that > tries to generate the frame numbers locally in between perios of no > "CLOCK IND" from osmo-trx by starting an osmo_timer for it. This seems > a bit ugly but of course reduces the number of UDP packets that we need > to process. > > If osmo-bts-trx users have not experienced any timing related issues, I > think there is no reason to introduce any changes itno this part, i.e. > keep the frequency of the "CLOCK IND" frames as-is, to also remain > compatible with other OpenBTS-like transceiver implementations. I don't remember issues with this part, but looking into the code I don't see much log printing there, so even if we encountered them, they probably wen unnoticed. Which is not a good behavior. I personally think that sending CLOCK IND every frame is a good idea. if we do this, we only need to check for lost CLOCK IND's and the code becomes much simpler. We're already sending 8 times more UDP packets even in idle mode (8 downlink bursts per frame), and 16 times more in fully loaded mode (downlink + uplink), and if we're running multi-TRX system, than proportion is even higher. We can do more 'perf' monitoring, but my feeling is that the impact will be a minor. If we find that UDP adds significant overhead, we can switch to a more efficient IPC (UNIX sockets?), but I seriously doubt that this will be needed. As a side note, we (Fairwaves) will be able to look into these issues deeply only in a few months in the best case. So if there are any volunteers who want to get all these issues fixes before that, don't hold your breath. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From msuraev at sysmocom.de Tue Jun 14 08:07:52 2016 From: msuraev at sysmocom.de (Max) Date: Tue, 14 Jun 2016 10:07:52 +0200 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> <20160613160403.GY28336@nataraja> Message-ID: <575FBB58.5060203@sysmocom.de> Which branch is used in practice? I've looked at gerrit/fairwaves/master and the difference seems pretty small so I'm puzzled as to which commit fixes it. On 06/13/2016 08:39 PM, Alexander Chemeris wrote: > On Mon, Jun 13, 2016 at 7:04 PM, Harald Welte wrote: >> On Mon, Apr 11, 2016 at 05:04:13PM -0700, Tom Tsou wrote: >> >>> Related is the question of when osmo-trx should send CLOCK >>> indications. Right now a CLOCK indications is sent with arrival of >>> commands on the control interface. After starting, CLOCK indications >>> are sent at an one second interval (216 frames). The indications sent >>> from the control interface are why osmo-bts is receiving CLOCK so >>> early. >> I don't know, to be honest. I didn't write osmo-bts-trx. Other PHY >> layers we interact send us information on the GSM frame number with >> every frame number increment. >> >> We also receive PH-ReadyToSend.ind in line with GSM PHY layer >> specifications for each frame to be sent. osmo-bts simply responds to >> those and all clock handling is entirely in the PHY. >> >> As osmo-trx dosen't do that (it's only half of a PHY layer), the >> missing part (scheduler) is implemented inside osmo-bts-trx. This >> scheduler is then generating the equivalent of the PH-ReadyToSend.ind >> towards the L1SAP and the common part of OsmoBTS. >> >> So in osmo-bts-trx it seems that there is code in trx_sched_clock() that >> tries to generate the frame numbers locally in between perios of no >> "CLOCK IND" from osmo-trx by starting an osmo_timer for it. This seems >> a bit ugly but of course reduces the number of UDP packets that we need >> to process. >> >> If osmo-bts-trx users have not experienced any timing related issues, I >> think there is no reason to introduce any changes itno this part, i.e. >> keep the frequency of the "CLOCK IND" frames as-is, to also remain >> compatible with other OpenBTS-like transceiver implementations. > I don't remember issues with this part, but looking into the code I > don't see much log printing there, so even if we encountered them, > they probably wen unnoticed. Which is not a good behavior. > > I personally think that sending CLOCK IND every frame is a good idea. > if we do this, we only need to check for lost CLOCK IND's and the code > becomes much simpler. We're already sending 8 times more UDP packets > even in idle mode (8 downlink bursts per frame), and 16 times more in > fully loaded mode (downlink + uplink), and if we're running multi-TRX > system, than proportion is even higher. We can do more 'perf' > monitoring, but my feeling is that the impact will be a minor. If we > find that UDP adds significant overhead, we can switch to a more > efficient IPC (UNIX sockets?), but I seriously doubt that this will be > needed. > > As a side note, we (Fairwaves) will be able to look into these issues > deeply only in a few months in the best case. So if there are any > volunteers who want to get all these issues fixes before that, don't > hold your breath. > -- Max Suraev 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 alexander.chemeris at gmail.com Tue Jun 14 12:21:56 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 14 Jun 2016 15:21:56 +0300 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: <575FBB58.5060203@sysmocom.de> References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> <20160613160403.GY28336@nataraja> <575FBB58.5060203@sysmocom.de> Message-ID: On Tue, Jun 14, 2016 at 11:07 AM, Max wrote: > Which branch is used in practice? I've looked at gerrit/fairwaves/master > and the difference seems pretty small so I'm puzzled as to which commit > fixes it. We're using fairwaves/master, but there is no special "fix" for this bug there. Something has changed in the generic code (i.e. unrelated to osmo-trx cupport) since we branched off, and that generic change broke a (fragile) working state of the code. As Harald mentioned, A-bis procedures are still pretty much a hack still. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From alexander.chemeris at gmail.com Tue Jun 14 12:32:55 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 14 Jun 2016 15:32:55 +0300 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: <20160409102553.GE16522@nataraja> References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> Message-ID: Hi Harald, On Sat, Apr 9, 2016 at 1:25 PM, Harald Welte wrote: > On Sat, Apr 09, 2016 at 10:49:41AM +0200, Harald Welte wrote: > Solution: > * OML initialization (the most complex part of Abis) needs to be > more properly handled. No part of the code should do something like > dynamically sending software activation reports at runtime. In > osm-bts-trx, every time 'transceiver_available' goes from 0->1 (which > apparently can happen even after start), a software activation report > is sent to the BSC. This is wrong. The software is only activated > once during boot, and it is activated not before the parent MOs for > BTS and Site Manager are enabled. If we or someone else is to fix this - do you have a suggestion on the best way to do that? E.g. should relevant state checks be added into oml_* functions, or should the whole OML part rewritten as a proper state machine. I'm trying to understand how much effort is required to fix this once and for all. > Unrelated to that, osmo-bts-trx desparately needs to avoid the use of > global variables. Each gsm_bts_trx / gsm_bts / phy_link / phy_instance > has private data store for implementation-specific state. global > variables have always been discouraged. Is there something where use of global variable in osmo-bts is a real issue? I completely agree that using global variables is a punishable practice, but the question for me is what is the impact of it in this specific case and is there any immediate benefits from getting this fixed. That would greatly help us justify the effort to clean it up. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From msuraev at sysmocom.de Tue Jun 14 12:55:53 2016 From: msuraev at sysmocom.de (Max) Date: Tue, 14 Jun 2016 14:55:53 +0200 Subject: osmo-trx issues In-Reply-To: References: <575ECE05.7000300@sysmocom.de> Message-ID: <575FFED9.4010904@sysmocom.de> Thanks, setting in open-bsc.cfg: ... bts 0 ... ms max power 16 and in osmo-bts.cfg: ... phy 0 instance 0 osmotrx rx-gain 1 ... fixed it for me on B200. It still doesn't work due to abis issues with osmo-bts-trx so I don't know if those values are optimal but it removes the warning. On 06/13/2016 06:58 PM, Alexander Chemeris wrote: > Hi Max, > > On Mon, Jun 13, 2016 at 6:15 PM, Max wrote: >> While running osmo-trx with B200 I've noticed following log messages >> repeated multiple times: >> >> 1) WARNING 3011271488 16:59:00.1 Transceiver.cpp:674:pullRadioVector: >> Clipping detected on received RACH or Normal Burst > This means that your phone transmit at a level which saturates BTS's > receive chain. Osmo-trx can't demodulate the signal and prints this > message. > > I don't have much experience with USRPs, but general way to avoid this is: > 1) Decrease "ms max power", so that phone starts with lower power, > 2) Reduce "rxgain" in osmo-bts config > 3) Add an attenuator to your Tx/Rx chains. > >> 2) ERR 3011304256 16:58:12.9 UHDDevice.cpp:1512:write: Skipping buffer >> data: timestamp=210353475 time_end=202360063 > This means that you're loosing samples between the device and UHD. > Can't help you much here, because it's device specific. May be Thomas > can suggest something. > > This is not the end of the world, but it may lead to all kinds of > unstable behavior similar to when you have really bad radio link and > bursts are dropped randomly. > > -- Max Suraev 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 tom at tsou.cc Tue Jun 14 17:19:56 2016 From: tom at tsou.cc (Tom Tsou) Date: Tue, 14 Jun 2016 10:19:56 -0700 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: <575FBB58.5060203@sysmocom.de> References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> <20160613160403.GY28336@nataraja> <575FBB58.5060203@sysmocom.de> Message-ID: Hi Max, On Tue, Jun 14, 2016 at 1:07 AM, Max wrote: > Which branch is used in practice? I've looked at gerrit/fairwaves/master > and the difference seems pretty small so I'm puzzled as to which commit > fixes it. The issue is command timing and improperly handled order of events. Some time back I checked the diff's between fairwaves/master and master, but wasn't able to find where the difference in sequencing was taking place. I'm puzzled about this as well, but, as Harald says, the real solution is not resolving the differences between fairwaves and master branches, but properly handling the OML initialization in master. The workaround for osmo-bts-trx master is as follows: 1. Remove CLK IND from the osmo-trx control loop 2. Start osmo-trx 3. Start osmo-bts-trx 4. Externally Issue the POWERON command to osmo-trx This delays CLK IND packets from prematurely reaching osmo-bts and allows the OML sequencing to take place. This is obviously a hack I suspect a real fix will involve some modification to the osmo-trx socket interface. -TT From msuraev at sysmocom.de Tue Jun 14 17:23:26 2016 From: msuraev at sysmocom.de (Max) Date: Tue, 14 Jun 2016 19:23:26 +0200 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> <20160613160403.GY28336@nataraja> <575FBB58.5060203@sysmocom.de> Message-ID: <57603D8E.6050301@sysmocom.de> I see. Will give it a shot tomorrow. If you have any patches/branches I can use as a starting point - let me know. On 06/14/2016 07:19 PM, Tom Tsou wrote: > Hi Max, > > On Tue, Jun 14, 2016 at 1:07 AM, Max wrote: >> Which branch is used in practice? I've looked at gerrit/fairwaves/master >> and the difference seems pretty small so I'm puzzled as to which commit >> fixes it. > The issue is command timing and improperly handled order of events. > Some time back I checked the diff's between fairwaves/master and > master, but wasn't able to find where the difference in sequencing was > taking place. I'm puzzled about this as well, but, as Harald says, the > real solution is not resolving the differences between fairwaves and > master branches, but properly handling the OML initialization in > master. > > The workaround for osmo-bts-trx master is as follows: > > 1. Remove CLK IND from the osmo-trx control loop > 2. Start osmo-trx > 3. Start osmo-bts-trx > 4. Externally Issue the POWERON command to osmo-trx > > This delays CLK IND packets from prematurely reaching osmo-bts and > allows the OML sequencing to take place. This is obviously a hack I > suspect a real fix will involve some modification to the osmo-trx > socket interface. > > -TT -- Max Suraev 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 tom at tsou.cc Tue Jun 14 17:43:32 2016 From: tom at tsou.cc (Tom Tsou) Date: Tue, 14 Jun 2016 10:43:32 -0700 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: <57603D8E.6050301@sysmocom.de> References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> <20160613160403.GY28336@nataraja> <575FBB58.5060203@sysmocom.de> <57603D8E.6050301@sysmocom.de> Message-ID: On Tue, Jun 14, 2016 at 10:23 AM, Max wrote: > I see. Will give it a shot tomorrow. If you have any patches/branches I > can use as a starting point - let me know. This branch will remove the CLK IND sending from the non-receive frames. git://git.osmocom.org/osmo-trx clkind OML initialization needs to happen on osmo-bts-trx before it starts receiving CLK IND packets. This means that the osmo-trx POWERON command needs to be delayed from osmo-bts-trx or sent to osmo-trx externally. I tested with the latter. -TT From msuraev at sysmocom.de Wed Jun 15 17:08:34 2016 From: msuraev at sysmocom.de (Max) Date: Wed, 15 Jun 2016 19:08:34 +0200 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> <20160613160403.GY28336@nataraja> <575FBB58.5060203@sysmocom.de> <57603D8E.6050301@sysmocom.de> Message-ID: <57618B92.9060308@sysmocom.de> I've tried it with manually sending POWERON - the issue with CHAN RQD is gone but the phone still does not work. I'll look into OML/RSL/whatever is preventing it from working. On 06/14/2016 07:43 PM, Tom Tsou wrote: > On Tue, Jun 14, 2016 at 10:23 AM, Max wrote: >> I see. Will give it a shot tomorrow. If you have any patches/branches I >> can use as a starting point - let me know. > This branch will remove the CLK IND sending from the non-receive frames. > > git://git.osmocom.org/osmo-trx clkind > > OML initialization needs to happen on osmo-bts-trx before it starts > receiving CLK IND packets. This means that the osmo-trx POWERON > command needs to be delayed from osmo-bts-trx or sent to osmo-trx > externally. I tested with the latter. > > -TT -- Max Suraev 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 msuraev at sysmocom.de Wed Jun 15 17:11:06 2016 From: msuraev at sysmocom.de (Max) Date: Wed, 15 Jun 2016 19:11:06 +0200 Subject: osmo-trx repo Message-ID: <57618C2A.20107@sysmocom.de> Hi. Repository over git.osmocom.org/osmo-trx is not (yet?) converted to gerrit. Can I get commit access so I can push (not to master of course) some branches for review/testing if necessary? -- Max Suraev 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 tom at tsou.cc Wed Jun 15 19:38:42 2016 From: tom at tsou.cc (Tom Tsou) Date: Wed, 15 Jun 2016 12:38:42 -0700 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: <57618B92.9060308@sysmocom.de> References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> <20160613160403.GY28336@nataraja> <575FBB58.5060203@sysmocom.de> <57603D8E.6050301@sysmocom.de> <57618B92.9060308@sysmocom.de> Message-ID: On Wed, Jun 15, 2016 at 10:08 AM, Max wrote: > I've tried it with manually sending POWERON - the issue with CHAN RQD is > gone but the phone still does not work. I'll look into OML/RSL/whatever > is preventing it from working. Make sure that the static variable 'settsc_enabled' is set. diff --git a/src/osmo-bts-trx/trx_if.c b/src/osmo-bts-trx/trx_if.c index a4c16dc..8c9a839 100644 --- a/src/osmo-bts-trx/trx_if.c +++ b/src/osmo-bts-trx/trx_if.c @@ -47,7 +47,7 @@ //#define TOA_RSSI_DEBUG int transceiver_available = 0; -int settsc_enabled = 0; +int settsc_enabled = 1; int setbsic_enabled = 0; -TT From alexander.chemeris at gmail.com Wed Jun 15 19:50:50 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 15 Jun 2016 22:50:50 +0300 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> <20160613160403.GY28336@nataraja> <575FBB58.5060203@sysmocom.de> <57603D8E.6050301@sysmocom.de> <57618B92.9060308@sysmocom.de> Message-ID: On Jun 15, 2016 10:38 PM, "Tom Tsou" wrote: > > On Wed, Jun 15, 2016 at 10:08 AM, Max wrote: > > I've tried it with manually sending POWERON - the issue with CHAN RQD is > > gone but the phone still does not work. I'll look into OML/RSL/whatever > > is preventing it from working. > > Make sure that the static variable 'settsc_enabled' is set. > > diff --git a/src/osmo-bts-trx/trx_if.c b/src/osmo-bts-trx/trx_if.c > index a4c16dc..8c9a839 100644 > --- a/src/osmo-bts-trx/trx_if.c > +++ b/src/osmo-bts-trx/trx_if.c > @@ -47,7 +47,7 @@ > //#define TOA_RSSI_DEBUG > > int transceiver_available = 0; > -int settsc_enabled = 0; > +int settsc_enabled = 1; > int setbsic_enabled = 0; Could you explain why is that required? I don't remember the code exactly, but IIRC this is equivalent to setting or removing 'tsc' line in the config file. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at tsou.cc Wed Jun 15 20:19:44 2016 From: tom at tsou.cc (Tom Tsou) Date: Wed, 15 Jun 2016 13:19:44 -0700 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> <20160613160403.GY28336@nataraja> <575FBB58.5060203@sysmocom.de> <57603D8E.6050301@sysmocom.de> <57618B92.9060308@sysmocom.de> Message-ID: On Wed, Jun 15, 2016 at 12:50 PM, Alexander Chemeris wrote: >> diff --git a/src/osmo-bts-trx/trx_if.c b/src/osmo-bts-trx/trx_if.c >> index a4c16dc..8c9a839 100644 >> --- a/src/osmo-bts-trx/trx_if.c >> +++ b/src/osmo-bts-trx/trx_if.c >> @@ -47,7 +47,7 @@ >> //#define TOA_RSSI_DEBUG >> >> int transceiver_available = 0; >> -int settsc_enabled = 0; >> +int settsc_enabled = 1; >> int setbsic_enabled = 0; > > Could you explain why is that required? Because osmo-trx only supports setting the training sequence through the SETTSC command. There is some history of the code that I am not familiar with. There is a SETBSIC command on the osmo-bts side of the interface, but that command does not exist in osmo-trx side. Perhaps SETBSIC previously existed in OpenBTS at one point in time? > I don't remember the code exactly, but IIRC this is equivalent to setting or > removing 'tsc' line in the config file. I'm not aware SETTSC vs SETBSIC configuration outside of those static variables. -TT From tom at tsou.cc Thu Jun 16 01:03:29 2016 From: tom at tsou.cc (Tom Tsou) Date: Wed, 15 Jun 2016 18:03:29 -0700 Subject: Regression in osmo-pcu with UHD trx ? In-Reply-To: References: Message-ID: On Mon, May 30, 2016 at 2:58 AM, Saurabh Sharan wrote: >> Date: Fri, 27 May 2016 18:02:28 +0200 >> From: Pierre Baudry >> I noticed that since several weeks that osmo-pcu did not work as good as >> previously. > > Yes we have also seen similar failures for GPRS calls in the osmo-pcu. Our setup uses NuRAN hardware with osmo-bts-sysmo I can confirm the same behaviour on B200 using master branches of osmo-pcu, osmo-bts-trx, and osmo-trx. >> The latest "good" revision I am aware of is commit >> d87e1d6ab747423d3668c74d16201a5d967accf0 (2015/12/14) Confirm. >> Can somebody confirm or reproduce this attitude ? > > The PCU log that we have during failure matches with the one you have reported. > We have tried a workaround for this GPRS call failure by forcing two-phase-access in osmo-pcu.cfg. > Based on our analysis done till now it seems One phase access of GPRS is broken. Confirm matching PCU log and that enabling two-phase-access works around the issue. -TT From laforge at gnumonks.org Thu Jun 16 06:53:30 2016 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 16 Jun 2016 08:53:30 +0200 Subject: osmo-trx repo In-Reply-To: <57618C2A.20107@sysmocom.de> References: <57618C2A.20107@sysmocom.de> Message-ID: <20160616065329.GO4397@nataraja> Hi Max, On Wed, Jun 15, 2016 at 07:11:06PM +0200, Max wrote: > Repository over git.osmocom.org/osmo-trx is not (yet?) converted to > gerrit. Can I get commit access so I can push (not to master of course) > some branches for review/testing if necessary? You should have write/push permission now, please re-check. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From msuraev at sysmocom.de Thu Jun 16 08:45:14 2016 From: msuraev at sysmocom.de (Max) Date: Thu, 16 Jun 2016 10:45:14 +0200 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> <20160613160403.GY28336@nataraja> <575FBB58.5060203@sysmocom.de> <57603D8E.6050301@sysmocom.de> <57618B92.9060308@sysmocom.de> Message-ID: <5762671A.6080804@sysmocom.de> Neat, the test call passed through. Now we got to find a place to send poweron automatically at the right moment instead of manual activation. On 06/15/2016 09:38 PM, Tom Tsou wrote: > On Wed, Jun 15, 2016 at 10:08 AM, Max wrote: >> I've tried it with manually sending POWERON - the issue with CHAN RQD is >> gone but the phone still does not work. I'll look into OML/RSL/whatever >> is preventing it from working. > Make sure that the static variable 'settsc_enabled' is set. > > diff --git a/src/osmo-bts-trx/trx_if.c b/src/osmo-bts-trx/trx_if.c > index a4c16dc..8c9a839 100644 > --- a/src/osmo-bts-trx/trx_if.c > +++ b/src/osmo-bts-trx/trx_if.c > @@ -47,7 +47,7 @@ > //#define TOA_RSSI_DEBUG > > int transceiver_available = 0; > -int settsc_enabled = 0; > +int settsc_enabled = 1; > int setbsic_enabled = 0; > > -TT -- Max Suraev 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 msuraev at sysmocom.de Thu Jun 16 08:52:00 2016 From: msuraev at sysmocom.de (Max) Date: Thu, 16 Jun 2016 10:52:00 +0200 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> <20160613160403.GY28336@nataraja> <575FBB58.5060203@sysmocom.de> <57603D8E.6050301@sysmocom.de> <57618B92.9060308@sysmocom.de> Message-ID: <576268B0.4040403@sysmocom.de> Curiously I've noticed following error messages while testing osmo-bts-trx: <0010> lapd_core.c:1508 N(S) sequence error: N(S)=0, V(R)=1 <0010> lapd_core.c:1508 N(S) sequence error: N(S)=1, V(R)=2 <0010> lapd_core.c:1508 N(S) sequence error: N(S)=2, V(R)=3 <0010> lapd_core.c:1508 N(S) sequence error: N(S)=3, V(R)=4 <0010> lapd_core.c:1508 N(S) sequence error: N(S)=4, V(R)=5 <0010> lapd_core.c:1508 N(S) sequence error: N(S)=5, V(R)=6 Not sure if it's related. On 06/15/2016 09:38 PM, Tom Tsou wrote: > On Wed, Jun 15, 2016 at 10:08 AM, Max wrote: >> I've tried it with manually sending POWERON - the issue with CHAN RQD is >> gone but the phone still does not work. I'll look into OML/RSL/whatever >> is preventing it from working. > Make sure that the static variable 'settsc_enabled' is set. > > diff --git a/src/osmo-bts-trx/trx_if.c b/src/osmo-bts-trx/trx_if.c > index a4c16dc..8c9a839 100644 > --- a/src/osmo-bts-trx/trx_if.c > +++ b/src/osmo-bts-trx/trx_if.c > @@ -47,7 +47,7 @@ > //#define TOA_RSSI_DEBUG > > int transceiver_available = 0; > -int settsc_enabled = 0; > +int settsc_enabled = 1; > int setbsic_enabled = 0; > > -TT -- Max Suraev 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 msuraev at sysmocom.de Thu Jun 16 08:55:34 2016 From: msuraev at sysmocom.de (Max) Date: Thu, 16 Jun 2016 10:55:34 +0200 Subject: osmo-trx issues In-Reply-To: References: <575ECE05.7000300@sysmocom.de> Message-ID: <57626986.9030106@sysmocom.de> Hi. A little follow-up. When testing calls after manual poweron using clkind branch of osmo-trx I've noticed following: WARNING 3077733184 10:50:06.4 Transceiver.cpp:749:driveControl: NOHANDOVER at timeslot 1 subslot 0 WARNING 3077733184 10:50:08.2 Transceiver.cpp:749:driveControl: NOHANDOVER at timeslot 1 subslot 0 WARNING 3077733184 10:50:08.2 Transceiver.cpp:749:driveControl: NOHANDOVER at timeslot 1 subslot 0 WARNING 3077733184 10:50:12.0 Transceiver.cpp:749:driveControl: NOHANDOVER at timeslot 2 subslot 0 WARNING 3077733184 10:50:13.0 Transceiver.cpp:749:driveControl: NOHANDOVER at timeslot 2 subslot 0 WARNING 3077733184 10:50:32.2 Transceiver.cpp:749:driveControl: NOHANDOVER at timeslot 2 subslot 0 WARNING 3077733184 10:50:32.5 Transceiver.cpp:749:driveControl: NOHANDOVER at timeslot 2 subslot 0 Looking at the code which produced it does not reveal much - just a debug print upon reception of some command. Why is it a warning? What's bad about it? On 06/13/2016 06:58 PM, Alexander Chemeris wrote: > Hi Max, > > On Mon, Jun 13, 2016 at 6:15 PM, Max wrote: >> While running osmo-trx with B200 I've noticed following log messages >> repeated multiple times: >> >> 1) WARNING 3011271488 16:59:00.1 Transceiver.cpp:674:pullRadioVector: >> Clipping detected on received RACH or Normal Burst > This means that your phone transmit at a level which saturates BTS's > receive chain. Osmo-trx can't demodulate the signal and prints this > message. > > I don't have much experience with USRPs, but general way to avoid this is: > 1) Decrease "ms max power", so that phone starts with lower power, > 2) Reduce "rxgain" in osmo-bts config > 3) Add an attenuator to your Tx/Rx chains. > >> 2) ERR 3011304256 16:58:12.9 UHDDevice.cpp:1512:write: Skipping buffer >> data: timestamp=210353475 time_end=202360063 > This means that you're loosing samples between the device and UHD. > Can't help you much here, because it's device specific. May be Thomas > can suggest something. > > This is not the end of the world, but it may lead to all kinds of > unstable behavior similar to when you have really bad radio link and > bursts are dropped randomly. > > -- Max Suraev 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 msuraev at sysmocom.de Thu Jun 16 10:48:00 2016 From: msuraev at sysmocom.de (Max) Date: Thu, 16 Jun 2016 12:48:00 +0200 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: References: Message-ID: <576283E0.8060503@sysmocom.de> Hi. I've pushed fix which works with both master and clkind branches of osmo-trx into gerrit #296 - please have a look. Note: I've only tested it with USRP B200. It's far from complete OML implementation but at least I can get call through. On 04/09/2016 12:55 AM, Tom Tsou wrote: > Hi Harald, > > On Wed, Apr 6, 2016 at 12:59 AM, Harald Welte wrote: >> Can you or somebody else interested in getting this resolved provide a >> full bug report, including >> * debug log output on OsmoNITB side for for the rsl and nm >> * debug log output on OsmoBTS side for oml / transceiver interface or >> anything else related >> * pcap file of A-bis traffic between OsmoBTS and OsmoNITB, as well as >> the control commands between osmo-bts-trx and osmo-trx > Attached are the logs for master branches of OpenBSC, OsmoBTS, and > OsmoTRX leading up to the following RACH access behavior. > > <0004> abis_rsl.c:1423 BTS 0 CHAN RQD: no resources for SDCCH 0x2 > > Hopefully, somebody more familiar than myself with A-bis and related > L1/L2 dependencies can provide some insight on why the above is > happening or where to start debugging. I'll be happy to test any > subsequent changes or look into specific parts of the A-bis code. > > -TT -- Max Suraev 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 nhofmeyr at sysmocom.de Thu Jun 16 11:43:44 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 16 Jun 2016 13:43:44 +0200 Subject: Regression in osmo-pcu with UHD trx ? In-Reply-To: References: Message-ID: <20160616114344.GB2119@dub6> On Wed, Jun 15, 2016 at 06:03:29PM -0700, Tom Tsou wrote: > On Mon, May 30, 2016 at 2:58 AM, Saurabh Sharan > wrote: > >> Date: Fri, 27 May 2016 18:02:28 +0200 > >> From: Pierre Baudry > >> I noticed that since several weeks that osmo-pcu did not work as good as > >> previously. > > > > Yes we have also seen similar failures for GPRS calls in the osmo-pcu. Our setup uses NuRAN hardware with osmo-bts-sysmo > > I can confirm the same behaviour on B200 using master branches of > osmo-pcu, osmo-bts-trx, and osmo-trx. > > >> The latest "good" revision I am aware of is commit > >> d87e1d6ab747423d3668c74d16201a5d967accf0 (2015/12/14) > > Confirm. Maybe related: I have recently found osmo-pcu master to not work for ip.access nanobts (and probably for all BTS models) and traced it to commit f1a7b8f tbf: Add state WAIT_ASSIGN See https://gerrit.osmocom.org/218 We still have to come to a conclusion on whether we want to merge the revert. If anyone is aware of this, any details would be appreciated. Thanks! ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Thu Jun 16 12:04:23 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 16 Jun 2016 14:04:23 +0200 Subject: gerrit on all repos? Message-ID: <20160616120423.GC2119@dub6> On Wed, Jun 15, 2016 at 07:11:06PM +0200, Max wrote: > Repository over git.osmocom.org/osmo-trx is not (yet?) converted to gerrit. I believe that we could move all repositories to gerrit now. Are there reasons to keep some of the repositories out of gerrit? Almost all of my problems with gerrit have been resolved, and the last one is solved by not pushing private branches to gerrit. Instead, I have my own bare git clones on our sysmocom-office machine to sync my home and office work. It would be nice to be able to publicly push private branches again, and indeed I think the fix for gerrit wouldn't be too difficult, but for now I'm fine. I would like to switch all projects to 'rebase-if-necessary', but first want to verify the differences to the cherry-pick strategy. IIRC cherry-pick is no good for commits that depend on each other, but only 80% sure about that... ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Thu Jun 16 15:00:41 2016 From: msuraev at sysmocom.de (Max) Date: Thu, 16 Jun 2016 17:00:41 +0200 Subject: multitrx with osmotrx Message-ID: <5762BF19.7060102@sysmocom.de> Hi. I've noticed check for device type around Transceiver52M/UHDDevice.cpp:772 - seems like USRP B200 is not supported for multitrx configurations: sudo chrt 20 ./Transceiver52M/osmo-trx -c 2 sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -c ~/.config/osmocom/osmo-bts-trx.cfg -i 192.168.122.1 -t 2 Where does this limitation comes from? Is it just smth which is not implemented (yet) or it's impossible to implement due to X and Y? -- Max Suraev 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 pierre.baudry at diateam.net Thu Jun 16 15:21:11 2016 From: pierre.baudry at diateam.net (Pierre Baudry) Date: Thu, 16 Jun 2016 17:21:11 +0200 Subject: multitrx with osmotrx In-Reply-To: <5762BF19.7060102@sysmocom.de> References: <5762BF19.7060102@sysmocom.de> Message-ID: <5762C3E7.70401@diateam.net> On 16/06/2016 17:00, Max wrote: > Hi. > > I've noticed check for device type around > Transceiver52M/UHDDevice.cpp:772 - seems like USRP B200 is not supported > for multitrx configurations: > sudo chrt 20 ./Transceiver52M/osmo-trx -c 2 > sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -c > ~/.config/osmocom/osmo-bts-trx.cfg -i 192.168.122.1 -t 2 > > Where does this limitation comes from? Is it just smth which is not > implemented (yet) or it's impossible to implement due to X and Y? > Hi Max, multitrx is intended for multi-channel USRPs such as USRP B210 or UmTRX However, you could try Thomas's work on multi-arfcn transceiver which can be found here: https://github.com/ttsou/osmo-trx/tree/mcbts From keith at rhizomatica.org Thu Jun 16 15:28:51 2016 From: keith at rhizomatica.org (Keith) Date: Thu, 16 Jun 2016 16:28:51 +0100 Subject: multitrx with osmotrx In-Reply-To: <5762BF19.7060102@sysmocom.de> References: <5762BF19.7060102@sysmocom.de> Message-ID: <8a35d6fb-966f-d3e7-de4e-e66cbccf2fe4@rhizomatica.org> On 16/06/2016 16:00, Max wrote: > Hi. Hi Max. > > I've noticed check for device type around > Transceiver52M/UHDDevice.cpp:772 - seems like USRP B200 is not supported > for multitrx configurations: > sudo chrt 20 ./Transceiver52M/osmo-trx -c 2 > sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -c > ~/.config/osmocom/osmo-bts-trx.cfg -i 192.168.122.1 -t 2 I'm sure Alexander will chime in and confirm, but I'm fairly sure that -c is only for Fairwaves hardware > Where does this limitation comes from? Is it just smth which is not > implemented (yet) or it's impossible to implement due to X and Y? > I have a feeling that the answer here will be that "multiple TRX is only supported on the UmTRX", however, this sparked a memory and a query: In the distant past Thomas worked on a multiARFCN implementation and I kind of remember a suggestion that this could work on a USRP, although the practical problems with RF amplification made it probably not feasable, or economically viable. https://github.com/ttsou/openbts-multi-arfcn show's updates > 4 years ago. I'm not sure if any of this made it into the Transceiver for osmo-trx I'd love to know. Keith. From tom at tsou.cc Thu Jun 16 17:10:50 2016 From: tom at tsou.cc (Tom Tsou) Date: Thu, 16 Jun 2016 10:10:50 -0700 Subject: multitrx with osmotrx In-Reply-To: <5762C3E7.70401@diateam.net> References: <5762BF19.7060102@sysmocom.de> <5762C3E7.70401@diateam.net> Message-ID: On Thu, Jun 16, 2016 at 8:21 AM, Pierre Baudry wrote: > On 16/06/2016 17:00, Max wrote: >> I've noticed check for device type around >> Transceiver52M/UHDDevice.cpp:772 - seems like USRP B200 is not supported >> for multitrx configurations: >> sudo chrt 20 ./Transceiver52M/osmo-trx -c 2 >> sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -c >> ~/.config/osmocom/osmo-bts-trx.cfg -i 192.168.122.1 -t 2 >> >> Where does this limitation comes from? Is it just smth which is not >> implemented (yet) or it's impossible to implement due to X and Y? B200 is a single RF channel device. > However, you could try Thomas's work on multi-arfcn transceiver which > can be found here: https://github.com/ttsou/osmo-trx/tree/mcbts Now that GPRS is working with osmo-bts-trx and osmo-trx, I will begin merging the multi-carrier transceiver chain in the coming week. The history is that multi-arfcn was initially developed on the single channel USRP2. In later devices, such as the UmTRX and B210, there were advantages in both simplicity and RF performance from separate discrete channels, and that became the preferred multi-channel approach used for later testing. There are still, however, benefits (i.e. cost and higher capacity support) to the multi-carrier approach on a single physical RF channel that make it worthwhile to support in mainline. -TT From tom at tsou.cc Thu Jun 16 17:44:55 2016 From: tom at tsou.cc (Tom Tsou) Date: Thu, 16 Jun 2016 10:44:55 -0700 Subject: Regression in osmo-pcu with UHD trx ? In-Reply-To: <20160616114344.GB2119@dub6> References: <20160616114344.GB2119@dub6> Message-ID: On Thu, Jun 16, 2016 at 4:43 AM, Neels Hofmeyr wrote: > Maybe related: I have recently found osmo-pcu master to not work for ip.access > nanobts (and probably for all BTS models) and traced it to commit > f1a7b8f tbf: Add state WAIT_ASSIGN > > See https://gerrit.osmocom.org/218 > > We still have to come to a conclusion on whether we want to merge the revert. > If anyone is aware of this, any details would be appreciated. Reverting "f1a7b8f tbf: Add state WAIT_ASSIGN" restores single phase GPRS access on osmo-bts-trx / osmo-trx. End-to-end functionality appears fine, but I cannot comment on if or how the change affects protocol or performance on a more detailed level. -TT From laforge at gnumonks.org Fri Jun 17 15:13:16 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 17 Jun 2016 17:13:16 +0200 Subject: multitrx with osmotrx In-Reply-To: References: <5762BF19.7060102@sysmocom.de> <5762C3E7.70401@diateam.net> Message-ID: <20160617151316.GC7879@nataraja> Hi Tom, On Thu, Jun 16, 2016 at 10:10:50AM -0700, Tom Tsou wrote: > There are still, however, benefits (i.e. cost and higher capacity > support) to the multi-carrier approach on a single physical RF channel > that make it worthwhile to support in mainline. I strongly agree. Multi-TRX is a feature for a single BTS with multiple transceivers (and one of them, per sectors). Having those on separate physical radio ports means you need to use external (expensive/lossy) combiners to combine those signals before amplification and feeding the transmit antenna. -- - 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 Fri Jun 17 17:47:20 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 17 Jun 2016 19:47:20 +0200 Subject: gerrit and branches Message-ID: <20160617174720.GB16677@dub6> Today I've taken another close look at branches and gerrit, and have written down my conclusions here: http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit#Submitting-Branches In summary: * Branch re-submission needs the workaround of tweaking the first commit. It would be nice to fix gerrit to not need this, but for the time being the effort of cosmetically changing the first commit log is acceptable. * It *is* possible to have private branches in the gerrit repos and still be able to submit them to master, with the proper project config. I have thus switched all our gerrit projects' configs to rebase-if-necessary with the flags as described on the wiki page. (Except for osmo-pcap, where we still disallow content merges.) I will now go back to pushing my "private" developments to the public repository (gerrit) under the neels/ or sysmocom/ namespaces. ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From holger at freyther.de Fri Jun 17 18:18:30 2016 From: holger at freyther.de (Holger Freyther) Date: Fri, 17 Jun 2016 20:18:30 +0200 Subject: gerrit and branches In-Reply-To: <20160617174720.GB16677@dub6> References: <20160617174720.GB16677@dub6> Message-ID: <69D401D8-B989-4B4A-BE74-52D7AA9CAB51@freyther.de> > On 17 Jun 2016, at 19:47, Neels Hofmeyr wrote: > Hi! > * Branch re-submission needs the workaround of tweaking the first commit. > It would be nice to fix gerrit to not need this, but for the time being the > effort of cosmetically changing the first commit log is acceptable. did you file a bug report for it? It looks like there is also a better fix for the rebase if necessary change. So maybe it is fixing that issue too? https://bugs.chromium.org/p/gerrit/issues/detail?id=2167&colspec=ID%20Type%20Stars%20Milestone%20Status%20Priority%20Owner%20Summary https://gerrit-review.googlesource.com/#/c/54550/ > I will now go back to pushing my "private" developments to the public > repository (gerrit) under the neels/ or sysmocom/ namespaces. cool. thank you for your investigation. holger From laforge at gnumonks.org Thu Jun 16 12:45:10 2016 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 16 Jun 2016 14:45:10 +0200 Subject: gerrit on all repos? In-Reply-To: <20160616120423.GC2119@dub6> References: <20160616120423.GC2119@dub6> Message-ID: <843BC2F1-7A53-4F2C-A927-F459C78B0EB3@gnumonks.org> Hi Neels, The question is what the respective project maintainers want. osmo-trx is not maintained by Holger or me, so we don't want to impose our preferences to other people. The same applies to all of the many other got repositories on osmocom.org. Regards, -- Sent from a mobile device. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Sat Jun 18 08:31:50 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 18 Jun 2016 11:31:50 +0300 Subject: osmo-trx repo In-Reply-To: <20160616065329.GO4397@nataraja> References: <57618C2A.20107@sysmocom.de> <20160616065329.GO4397@nataraja> Message-ID: Hi Harald, On Thu, Jun 16, 2016 at 9:53 AM, Harald Welte wrote: > Hi Max, > > On Wed, Jun 15, 2016 at 07:11:06PM +0200, Max wrote: >> Repository over git.osmocom.org/osmo-trx is not (yet?) converted to >> gerrit. Can I get commit access so I can push (not to master of course) >> some branches for review/testing if necessary? > > You should have write/push permission now, please re-check. It seems I also lost push access to osmo-trx repo. Please, could you check? I'm getting the following when I'm trying to push: $ git push origin fairwaves/limesdr-support fatal: remote error: access denied or repository not exported: /osmo-trx.git $ git remote -v origin git://git.osmocom.org/osmo-trx.git (fetch) origin git://git.osmocom.org/osmo-trx.git (push) -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From msuraev at sysmocom.de Mon Jun 20 08:05:02 2016 From: msuraev at sysmocom.de (Max) Date: Mon, 20 Jun 2016 10:05:02 +0200 Subject: osmo-trx repo In-Reply-To: <20160616065329.GO4397@nataraja> References: <57618C2A.20107@sysmocom.de> <20160616065329.GO4397@nataraja> Message-ID: <5767A3AE.1000801@sysmocom.de> Works for me now, thanks. On 06/16/2016 08:53 AM, Harald Welte wrote: > Hi Max, > > On Wed, Jun 15, 2016 at 07:11:06PM +0200, Max wrote: >> Repository over git.osmocom.org/osmo-trx is not (yet?) converted to >> gerrit. Can I get commit access so I can push (not to master of course) >> some branches for review/testing if necessary? > You should have write/push permission now, please re-check. > -- Max Suraev 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 nhofmeyr at sysmocom.de Mon Jun 20 15:55:00 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 20 Jun 2016 17:55:00 +0200 Subject: testing gerrit, might be down shortly Message-ID: <20160620155500.GA25075@ass40.sysmocom.de> I'm testing things related to our gerrit bug report, if it's not working for you right now it may be because I'm restarting gerrit to test with/out our fix. I'll repost when I'm done. ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Mon Jun 20 16:27:49 2016 From: msuraev at sysmocom.de (Max) Date: Mon, 20 Jun 2016 18:27:49 +0200 Subject: release process Message-ID: <57681985.4090606@sysmocom.de> Hi. So far release process for new versions of osmocom components was rather quiet (unless I'm looking at the wrong place). This is different from many other open source projects some of which do announcements in ML, some use blogposts etc. Is there any interest/value in the release announcements for osmocom projects? Or maybe partially (applications but not libraries for example)? Or only major but not minor? Or not at all? To me personally the value is twofold: a) we generate some news which might be good thing to attract attention of potential contributors (if we won't overdo it :) and b) it makes it clear when some feature is "officially shipped" so we have to start paying attention to things like backward compatibility. Of course writing such announcements is boring regardless of a medium so if we follow this road we should automate the process as much as possible. What do you guys think? -- Max Suraev 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 nhofmeyr at sysmocom.de Mon Jun 20 18:21:01 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 20 Jun 2016 20:21:01 +0200 Subject: gerrit and branches In-Reply-To: <69D401D8-B989-4B4A-BE74-52D7AA9CAB51@freyther.de> References: <20160617174720.GB16677@dub6> <69D401D8-B989-4B4A-BE74-52D7AA9CAB51@freyther.de> Message-ID: <20160620182101.GB25075@ass40.sysmocom.de> On Fri, Jun 17, 2016 at 08:18:30PM +0200, Holger Freyther wrote: > > * Branch re-submission needs the workaround of tweaking the first commit. > > It would be nice to fix gerrit to not need this, but for the time being the > > effort of cosmetically changing the first commit log is acceptable. > > did you file a bug report for it? I coined it a feature request... https://bugs.chromium.org/p/gerrit/issues/detail?id=4210 > It looks like there is also a better fix for the rebase if necessary change. So maybe it is fixing that issue too? The fix in question was already in our gerrit version. I found our issue is entirely different. I have no idea why your patch helped... I suspect we had some confusion with the "Create a new change for every commit not in the target branch" config item. But the NullPointer you fixed has since been fixed by someone else on stable-2.12 :) so that was an actual bug. I commented in abundant detail... https://bugs.chromium.org/p/gerrit/issues/detail?id=4158 ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From holger at freyther.de Mon Jun 20 18:22:42 2016 From: holger at freyther.de (Holger Freyther) Date: Mon, 20 Jun 2016 20:22:42 +0200 Subject: gerrit and branches In-Reply-To: <20160620182101.GB25075@ass40.sysmocom.de> References: <20160617174720.GB16677@dub6> <69D401D8-B989-4B4A-BE74-52D7AA9CAB51@freyther.de> <20160620182101.GB25075@ass40.sysmocom.de> Message-ID: <2DB2281C-FBA1-4481-A028-25004B8EEC85@freyther.de> > On 20 Jun 2016, at 20:21, Neels Hofmeyr wrote: > Hi! > I found our issue is entirely different. I have no idea why your patch > helped... I suspect we had some confusion with the "Create a new change > for every commit not in the target branch" config item. > > But the NullPointer you fixed has since been fixed by someone else on > stable-2.12 :) so that was an actual bug. I have two fixes, one to rebase if necessary and the other the NPE. > > I commented in abundant detail... > > https://bugs.chromium.org/p/gerrit/issues/detail?id=4158 From nhofmeyr at sysmocom.de Mon Jun 20 18:46:15 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 20 Jun 2016 20:46:15 +0200 Subject: DONE -- was: testing gerrit, might be down shortly In-Reply-To: <20160620155500.GA25075@ass40.sysmocom.de> References: <20160620155500.GA25075@ass40.sysmocom.de> Message-ID: <20160620184615.GA3343@ass40.sysmocom.de> I'm done testing. At first I tested a bit on openbsc.git, so apologies for those gerrit mails. I've then added the sandbox repository, so most of the testing mail flood has been spared; and there will be no more testing mails now :) Thank you for your patience. ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Mon Jun 20 18:58:39 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 20 Jun 2016 20:58:39 +0200 Subject: gerrit and branches In-Reply-To: <2DB2281C-FBA1-4481-A028-25004B8EEC85@freyther.de> References: <20160617174720.GB16677@dub6> <69D401D8-B989-4B4A-BE74-52D7AA9CAB51@freyther.de> <20160620182101.GB25075@ass40.sysmocom.de> <2DB2281C-FBA1-4481-A028-25004B8EEC85@freyther.de> Message-ID: <20160620185838.GB3343@ass40.sysmocom.de> On Mon, Jun 20, 2016 at 08:22:42PM +0200, Holger Freyther wrote: > I have two fixes, one to rebase if necessary and the other the NPE. As I said, someone else fixed the NPE slightly differently since: https://gerrit.googlesource.com/gerrit/+/929f7bb7a9c566210d5e1ba54ecc423aa27f5ff8%5E!/#F0 I couldn't reproduce the rebase-if-necessary fix, the problem as explained in the issue remained: https://bugs.chromium.org/p/gerrit/issues/detail?id=4158 ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Tue Jun 21 08:51:34 2016 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 21 Jun 2016 10:51:34 +0200 Subject: OsmoTRX / BER, RSSI and Link Quality Message-ID: <20160621085134.GF5199@nataraja> Hi Tom and List, we're currently introducing some code that will make more use of measurement related information associated with the PH-RACH.req and PH-DATA.ind coming from the PHY up into L2. The first part is to introduce a reasonable BER limit fo 17% for RACH ghost elimination, but I have more plans for unifying the measurement processing/generation accross all supported BTS models. For osmo-bts-{sysmo,lc15,octphy} it is clear to me how to get the related information on RSSI, BER and LinkQuality for each of the RACH and DATA indications from the PHY. However, how can I get the related information from osmo-bts-trx? osmo-bts-trx seems to lack any BER reporting toward the common part, which among other things is the reason why link/rate adaption in the PCU can not work with it. Could you sched some light on this? -- - 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 Jun 21 08:39:15 2016 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 21 Jun 2016 10:39:15 +0200 Subject: release process In-Reply-To: <57681985.4090606@sysmocom.de> References: <57681985.4090606@sysmocom.de> Message-ID: <20160621083915.GE5199@nataraja> Hi Max, On Mon, Jun 20, 2016 at 06:27:49PM +0200, Max wrote: > To me personally the value is twofold: a) we generate some news which > might be good thing to attract attention of potential contributors (if > we won't overdo it :) and b) it makes it clear when some feature is > "officially shipped" so we have to start paying attention to things like > backward compatibility. I completely agree. The lack of a proper release process with release announcements, the availability of (signed) tar-balls for the source code, as well as (possibly) the availability of OBS-built packages for those releases is a problem. The question is: Who will volunteer to do that? :) -- - 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 Tue Jun 21 11:24:01 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 21 Jun 2016 13:24:01 +0200 Subject: conversations in gerrit "lost" here Message-ID: <20160621112401.GA14455@ass40.sysmocom.de> I am a bit ambiguous on our use of comments in gerrit. We do discuss at least some fairly interesting things in the comments on patches waiting for approval in gerrit. When these discussions are attempted on openbsc@ or osmocom-net-gprs@, you tend to block off and redirect the discussion back to the gerrit comments infrastructure. However, we have moved the gerrit mails to a separate and very noisy mailing list, and these potentially interesting discussions are moved essentially out of the public focus. Also, if we in future would like to investigate discussion on some topic, we need to search both the main ML and the gerrit ML. IMHO it would make sense to copy the human originated comments to our "human" mailing lists, so that the automatic jenkins and gerrit notifications remain on the noisy ML while we see all discussions here. Is that easy to achieve (filter on originator of comment), and would you guys agree? ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Tue Jun 21 11:28:31 2016 From: msuraev at sysmocom.de (Max) Date: Tue, 21 Jun 2016 13:28:31 +0200 Subject: conversations in gerrit "lost" here In-Reply-To: <20160621112401.GA14455@ass40.sysmocom.de> References: <20160621112401.GA14455@ass40.sysmocom.de> Message-ID: <576924DF.5040304@sysmocom.de> I think such comments usually require context in a form of patch diff so interested person got to go to gerrit anyway so there's not much sense in duplicating them into ML. On 06/21/2016 01:24 PM, Neels Hofmeyr wrote: > I am a bit ambiguous on our use of comments in gerrit. > > We do discuss at least some fairly interesting things in the comments on > patches waiting for approval in gerrit. > > When these discussions are attempted on openbsc@ or osmocom-net-gprs@, you > tend to block off and redirect the discussion back to the gerrit comments > infrastructure. > > However, we have moved the gerrit mails to a separate and very noisy > mailing list, and these potentially interesting discussions are moved > essentially out of the public focus. > > Also, if we in future would like to investigate discussion on some topic, > we need to search both the main ML and the gerrit ML. > > IMHO it would make sense to copy the human originated comments to our > "human" mailing lists, so that the automatic jenkins and gerrit > notifications remain on the noisy ML while we see all discussions here. > > Is that easy to achieve (filter on originator of comment), > and would you guys agree? > > ~Neels > -- Max Suraev 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 msuraev at sysmocom.de Tue Jun 21 14:16:15 2016 From: msuraev at sysmocom.de (Max) Date: Tue, 21 Jun 2016 16:16:15 +0200 Subject: multitrx with osmotrx In-Reply-To: References: <5762BF19.7060102@sysmocom.de> <5762C3E7.70401@diateam.net> Message-ID: <57694C2F.4070306@sysmocom.de> Thanks for explanation. In case of B210 I've got following error: <000b> trx_if.c:380 transceiver (phy0.1) rejected TRX command with response: 'RSP SETTSC 1 7' What could be causing it? Is there some special setting(s) required for 2nd TRX? On 06/16/2016 07:10 PM, Tom Tsou wrote: > On Thu, Jun 16, 2016 at 8:21 AM, Pierre Baudry > wrote: >> On 16/06/2016 17:00, Max wrote: >>> I've noticed check for device type around >>> Transceiver52M/UHDDevice.cpp:772 - seems like USRP B200 is not supported >>> for multitrx configurations: >>> sudo chrt 20 ./Transceiver52M/osmo-trx -c 2 >>> sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -c >>> ~/.config/osmocom/osmo-bts-trx.cfg -i 192.168.122.1 -t 2 >>> >>> Where does this limitation comes from? Is it just smth which is not >>> implemented (yet) or it's impossible to implement due to X and Y? > B200 is a single RF channel device. > >> However, you could try Thomas's work on multi-arfcn transceiver which >> can be found here: https://github.com/ttsou/osmo-trx/tree/mcbts > Now that GPRS is working with osmo-bts-trx and osmo-trx, I will begin > merging the multi-carrier transceiver chain in the coming week. > > The history is that multi-arfcn was initially developed on the single > channel USRP2. In later devices, such as the UmTRX and B210, there > were advantages in both simplicity and RF performance from separate > discrete channels, and that became the preferred multi-channel > approach used for later testing. > > There are still, however, benefits (i.e. cost and higher capacity > support) to the multi-carrier approach on a single physical RF channel > that make it worthwhile to support in mainline. > > -TT -- Max Suraev 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 nhofmeyr at sysmocom.de Tue Jun 21 15:01:29 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 21 Jun 2016 17:01:29 +0200 Subject: conversations in gerrit "lost" here In-Reply-To: <576924DF.5040304@sysmocom.de> References: <20160621112401.GA14455@ass40.sysmocom.de> <576924DF.5040304@sysmocom.de> Message-ID: <20160621150129.GB8184@ass40.sysmocom.de> On Tue, Jun 21, 2016 at 01:28:31PM +0200, Max wrote: > I think such comments usually require context in a form of patch diff so > interested person got to go to gerrit anyway so there's not much sense > in duplicating them into ML. For example the last couple comments on https://gerrit.osmocom.org/331 would be interesting for people not reading the gerrit ML, and each mail has a link to the related patch? Admittedly, the numerous short voting comments on the patches leading up to https://gerrit.osmocom.org/255 would certainly constitute noise. I still think it's suboptimal to drift into discussions off of the ML... ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Tue Jun 21 15:02:07 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 21 Jun 2016 17:02:07 +0200 Subject: osmo-bts[master]: fix lc15 build: put src/common/libbts.a left of -losmogsm References: Message-ID: <20160621150207.GC8184@ass40.sysmocom.de> So, it appears we should add litecell15 to our osmo-bts build? We didn't catch my breaking it with the gsm_chan_t_names change. ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Tue Jun 21 15:10:12 2016 From: msuraev at sysmocom.de (Max) Date: Tue, 21 Jun 2016 17:10:12 +0200 Subject: osmo-bts[master]: fix lc15 build: put src/common/libbts.a left of -losmogsm In-Reply-To: <20160621150207.GC8184@ass40.sysmocom.de> References: <20160621150207.GC8184@ass40.sysmocom.de> Message-ID: <576958D4.3090303@sysmocom.de> I think we should add all supported BTS models to test matrix. On 06/21/2016 05:02 PM, Neels Hofmeyr wrote: > So, it appears we should add litecell15 to our osmo-bts build? > We didn't catch my breaking it with the gsm_chan_t_names change. > > ~Neels > -- Max Suraev 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 msuraev at sysmocom.de Tue Jun 21 16:05:19 2016 From: msuraev at sysmocom.de (Max) Date: Tue, 21 Jun 2016 18:05:19 +0200 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: References: Message-ID: <576965BF.4050608@sysmocom.de> Hi. A little update: the current master works with fr codec but not with amr. I'm looking into it but in general - is there some version somewhere which works with amr for somebody on some hw? -- Max Suraev 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 alexander.chemeris at gmail.com Tue Jun 21 16:44:48 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 21 Jun 2016 19:44:48 +0300 Subject: osmo-bts-trx: "CHAN RQD: no resources for SDCCH" on master In-Reply-To: References: <20160409084941.GD16522@nataraja> <20160409102553.GE16522@nataraja> <20160613160403.GY28336@nataraja> <575FBB58.5060203@sysmocom.de> <57603D8E.6050301@sysmocom.de> <57618B92.9060308@sysmocom.de> Message-ID: On Wed, Jun 15, 2016 at 11:19 PM, Tom Tsou wrote: > On Wed, Jun 15, 2016 at 12:50 PM, Alexander Chemeris > wrote: >>> diff --git a/src/osmo-bts-trx/trx_if.c b/src/osmo-bts-trx/trx_if.c >>> index a4c16dc..8c9a839 100644 >>> --- a/src/osmo-bts-trx/trx_if.c >>> +++ b/src/osmo-bts-trx/trx_if.c >>> @@ -47,7 +47,7 @@ >>> //#define TOA_RSSI_DEBUG >>> >>> int transceiver_available = 0; >>> -int settsc_enabled = 0; >>> +int settsc_enabled = 1; >>> int setbsic_enabled = 0; >> >> Could you explain why is that required? > > Because osmo-trx only supports setting the training sequence through > the SETTSC command. There is some history of the code that I am not > familiar with. There is a SETBSIC command on the osmo-bts side of the > interface, but that command does not exist in osmo-trx side. Perhaps > SETBSIC previously existed in OpenBTS at one point in time? SETBSIC was introduced for osmocom-bb-trx (an OsmocomBB phone operating as a BTS). These phones didn't have a function to set TSC, but had a function to set BSIC, so Andreas added SETBSIC command to work around this. OsmoBTS has sent both commands, because it doesn't know whether it's connected to osmo-trx or to osmocom-bb-trx - an unsupported command was historically just ignored. Has this behaviour changed recently? I don't think there is any issues with sending SETBSIC to osmo-trx except a warning in the log. >> I don't remember the code exactly, but IIRC this is equivalent to setting or >> removing 'tsc' line in the config file. > > I'm not aware SETTSC vs SETBSIC configuration outside of those static variables. I was sure that I saw that removing "bsic" parameter stopped osmo-bts from sending SETBSIC, but now I don't see that in the code. That should be the best way to handle this - only send TSC of BSIC based on configuration. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From alexander.chemeris at gmail.com Tue Jun 21 17:01:24 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 21 Jun 2016 20:01:24 +0300 Subject: multitrx with osmotrx In-Reply-To: <20160617151316.GC7879@nataraja> References: <5762BF19.7060102@sysmocom.de> <5762C3E7.70401@diateam.net> <20160617151316.GC7879@nataraja> Message-ID: Hi Harald, On Fri, Jun 17, 2016 at 6:13 PM, Harald Welte wrote: > On Thu, Jun 16, 2016 at 10:10:50AM -0700, Tom Tsou wrote: >> There are still, however, benefits (i.e. cost and higher capacity >> support) to the multi-carrier approach on a single physical RF channel >> that make it worthwhile to support in mainline. > > I strongly agree. Multi-TRX is a feature for a single BTS with multiple > transceivers (and one of them, per sectors). Having those on separate > physical radio ports means you need to use external (expensive/lossy) > combiners to combine those signals before amplification and feeding the > transmit antenna. I completely agree that multi-arfcn support should be in the master. That said, I don't agree that it's always superior to existing approach we have with UmTRX/UmSITE where we use separate radio paths for different TRX. We couldn't achieve power efficiency and flexibility if we were using multi-arfcn approach. Not to mention that single ARFCN per TRX allows us to use simpler receivers. You also don't need a combiner if you want to route two TRX to a single antenna - X-Pol antennas are very popular and easy to get. And for more powerful BTS's (like 10W per channel) you can get real benefit from diversity receive, which again requires separate radio paths for both channels. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From msuraev at sysmocom.de Tue Jun 21 17:03:44 2016 From: msuraev at sysmocom.de (Max) Date: Tue, 21 Jun 2016 19:03:44 +0200 Subject: iphone backdoor? Message-ID: <57697370.5030504@sysmocom.de> Hi. While testing I've got iphone (non-jailbroken) which regularly attempts to send following sms to number 447537410247 (uk?): REG-REQ?v=3;t=C335D183C5A2FC0E2501543EBCEB8263D55683FB63A2E8CAF98B8874D940263F;r=165209558 without asking user for anything. Is this some sort of Apple's backdoor? Or GCHQ is so bored that they are trying to spy on me? :) Have you guys seen this before? -- Max Suraev 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 ivan.kluchnikov at fairwaves.co Tue Jun 21 18:25:09 2016 From: ivan.kluchnikov at fairwaves.co (Ivan Kluchnikov) Date: Tue, 21 Jun 2016 21:25:09 +0300 Subject: iphone backdoor? In-Reply-To: <57697370.5030504@sysmocom.de> References: <57697370.5030504@sysmocom.de> Message-ID: Hi Max, It seems the answer is here: https://discussions.apple.com/thread/3827428?tstart=0 2016-06-21 20:03 GMT+03:00 Max : > Hi. > > While testing I've got iphone (non-jailbroken) which regularly attempts > to send following sms to number 447537410247 (uk?): > > REG-REQ?v=3;t=C335D183C5A2FC0E2501543EBCEB8263D55683FB63A2E8CAF98B8874D940263F;r=165209558 > > without asking user for anything. > > Is this some sort of Apple's backdoor? Or GCHQ is so bored that they are > trying to spy on me? :) > Have you guys seen this before? > > -- > Max Suraev 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 alexander.chemeris at gmail.com Tue Jun 21 18:36:13 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 21 Jun 2016 21:36:13 +0300 Subject: OsmoTRX / BER, RSSI and Link Quality In-Reply-To: <20160621085134.GF5199@nataraja> References: <20160621085134.GF5199@nataraja> Message-ID: Hi Harald, On Tue, Jun 21, 2016 at 11:51 AM, Harald Welte wrote: > The first part is to introduce a reasonable BER limit fo 17% for RACH > ghost elimination, but I have more plans for unifying the measurement > processing/generation accross all supported BTS models. > > For osmo-bts-{sysmo,lc15,octphy} it is clear to me how to get the > related information on RSSI, BER and LinkQuality for each of the RACH > and DATA indications from the PHY. > > However, how can I get the related information from osmo-bts-trx? > > osmo-bts-trx seems to lack any BER reporting toward the common part, > which among other things is the reason why link/rate adaption in the PCU > can not work with it. I introduced BER calculations in osmo-bts-trx some time ago for DATA, so the data is there - see gsm0503_coding.c, *_decode() functions. I also updated the code to pass this information to upper layers - see rx_tchf_fn(), rx_tchh_fn(), rx_pdtch_fn() in scheduler_trx.c. I tested that the data actually gets to measurement reports for TCH and SDDCH, but I don't remember if we tested this for GPRS. Are you sure it doesn't work with the current master? If so, it probably got broken during the rebase or after that. I didn't do that for RACH, because currently RACH gating is performed in osmo-trx and works pretty well as far as I can tell, so osmo-bts-trx gets RACH's which are valid with high probability. We can introduce an option to turn osmo-trx built-in RACH gating and rely on osmo-bts instead and then compare which one works better. That should be a minor change - I'm happy to implement this a bit later. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From choukoumoun at gmail.com Wed Jun 22 08:29:22 2016 From: choukoumoun at gmail.com (Choukou Moun) Date: Wed, 22 Jun 2016 10:29:22 +0200 Subject: iphone backdoor? In-Reply-To: References: <57697370.5030504@sysmocom.de> Message-ID: Hello Max. Are you using openbsc for intercept this information ? What procedure are you using to give that ? Openbsc, simtrace ? Best, Choukoumoun. Le 21 juin 2016 20:25, "Ivan Kluchnikov" a ?crit : > Hi Max, > > It seems the answer is here: > https://discussions.apple.com/thread/3827428?tstart=0 > > 2016-06-21 20:03 GMT+03:00 Max : > >> Hi. >> >> While testing I've got iphone (non-jailbroken) which regularly attempts >> to send following sms to number 447537410247 (uk?): >> >> REG-REQ?v=3;t=C335D183C5A2FC0E2501543EBCEB8263D55683FB63A2E8CAF98B8874D940263F;r=165209558 >> >> without asking user for anything. >> >> Is this some sort of Apple's backdoor? Or GCHQ is so bored that they are >> trying to spy on me? :) >> Have you guys seen this before? >> >> -- >> Max Suraev 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 msuraev at sysmocom.de Wed Jun 22 09:37:52 2016 From: msuraev at sysmocom.de (Max) Date: Wed, 22 Jun 2016 11:37:52 +0200 Subject: iphone backdoor? In-Reply-To: References: <57697370.5030504@sysmocom.de> Message-ID: <576A5C70.4050902@sysmocom.de> Thanks! I especially like the "It's designed not too cost anything, if it does cost you anything, it will be something your carrier has set up." bit in the answer :-D :-D :-D On 06/21/2016 08:25 PM, Ivan Kluchnikov wrote: > Hi Max, > > It seems the answer is here: > https://discussions.apple.com/thread/3827428?tstart=0 > > 2016-06-21 20:03 GMT+03:00 Max >: > > Hi. > > While testing I've got iphone (non-jailbroken) which regularly > attempts > to send following sms to number 447537410247 (uk?): > REG-REQ?v=3;t=C335D183C5A2FC0E2501543EBCEB8263D55683FB63A2E8CAF98B8874D940263F;r=165209558 > > without asking user for anything. > > Is this some sort of Apple's backdoor? Or GCHQ is so bored that > they are > trying to spy on me? :) > Have you guys seen this before? > > -- > Max Suraev > > 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 > > -- Max Suraev 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 ralph at schmid.xxx Wed Jun 22 10:02:59 2016 From: ralph at schmid.xxx (Ralph A. Schmid, dk5ras) Date: Wed, 22 Jun 2016 12:02:59 +0200 Subject: iphone backdoor? In-Reply-To: <576A5C70.4050902@sysmocom.de> References: <57697370.5030504@sysmocom.de> <576A5C70.4050902@sysmocom.de> Message-ID: <014e01d1cc6d$41f21220$c5d63660$@schmid.xxx> I have seen such messages with BlackBerries, trying to send a silent message to some shortcut phone number, like 73456. Even a SIM can do this via SIM toolkit. On an OpenBTS demonstration in a place without any commercial coverage two subscribers started hammering onto my system, frantically trying to send something to the same German cellphone number. Guess it had to do with the quite expensive cars on the parking lot, seems two of them panicked and wanted to call for help, assuming that the strange MCC/MNC could mean being stolen :-) Ralph. > -----Original Message----- > From: OpenBSC [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of > Max > Sent: Wednesday, June 22, 2016 11:38 AM > To: Ivan Kluchnikov > Cc: OpenBSC Mailing List > Subject: Re: iphone backdoor? > > Thanks! I especially like the "It's designed not too cost anything, if it does cost > you anything, it will be something your carrier has set up." bit in the answer :- > D :-D :-D > > On 06/21/2016 08:25 PM, Ivan Kluchnikov wrote: > > Hi Max, > > > > It seems the answer is here: > > https://discussions.apple.com/thread/3827428?tstart=0 > > > > 2016-06-21 20:03 GMT+03:00 Max > >: > > > > Hi. > > > > While testing I've got iphone (non-jailbroken) which regularly > > attempts > > to send following sms to number 447537410247 (uk?): > > > > REG- > REQ?v=3;t=C335D183C5A2FC0E2501543EBCEB8263D55683FB63A2E8CAF98B88 > 74 > > D940263F;r=165209558 > > > > without asking user for anything. > > > > Is this some sort of Apple's backdoor? Or GCHQ is so bored that > > they are > > trying to spy on me? :) > > Have you guys seen this before? > > > > -- > > Max Suraev > > > 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 > > > > > > -- > Max Suraev 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 msuraev at sysmocom.de Wed Jun 22 14:29:51 2016 From: msuraev at sysmocom.de (Max) Date: Wed, 22 Jun 2016 16:29:51 +0200 Subject: osmotrx init problem Message-ID: <576AA0DF.2040806@sysmocom.de> Hi. I've got following problem while trying to make osmotrx work in multitrx setting on USRP B210: sudo chrt 20 ./Transceiver52M/osmo-trx -c 2 sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -t 2 -c ~/.config/osmocom/osmo-bts-mtrx.cfg -d DRTP:DCC:DRSL:DOML:DL1C:DTRX The bts quits from trx_if.c after checking "if (tcm->critical) {...". The command sequence seems to be the same for both phy0.0 and phy0.1 However 0.0 one accepts SETTSC command and 0.1 rejects it: trx_if.c:380 transceiver (phy0.1) rejected TRX command with response: 'RSP SETTSC 1 7' So far I fail to see where this difference comes from. Full log: <0001> oml.c:1249 Initializing OML attribute definitions <000b> trx_if.c:560 Open transceiver for phy0.0 <000b> trx_if.c:222 Adding new control 'CMD POWEROFF' <000b> trx_if.c:169 Sending control 'CMD POWEROFF' to phy0.0 <000b> trx_if.c:560 Open transceiver for phy0.1 <000b> trx_if.c:348 Response message: 'RSP POWEROFF 0' <0001> oml.c:547 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug! <000b> trx_if.c:222 Adding new control 'CMD POWEROFF' <000b> trx_if.c:169 Sending control 'CMD POWEROFF' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP POWEROFF 0' <0001> oml.c:884 ADM state already was Unlocked <000b> trx_if.c:222 Adding new control 'CMD RXTUNE 1783400' <000b> trx_if.c:169 Sending control 'CMD RXTUNE 1783400' to phy0.0 <000b> trx_if.c:222 Adding new control 'CMD TXTUNE 1878400' <000b> trx_if.c:222 Adding new control 'CMD SETTSC 7' <000b> trx_if.c:222 Adding new control 'CMD POWERON' <000b> trx_if.c:222 Adding new control 'CMD SETRXGAIN 1' <000b> trx_if.c:222 Adding new control 'CMD SETPOWER 0' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 0 4' <0005> paging.c:545 Paging: BS_AG_BLKS_RES = 0 != 1 not fully supported <000b> trx_if.c:348 Response message: 'RSP RXTUNE 0 1783400' <000b> trx_if.c:169 Sending control 'CMD TXTUNE 1878400' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP TXTUNE 0 1878400' <000b> trx_if.c:169 Sending control 'CMD SETTSC 7' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETTSC 0 7' <000b> trx_if.c:169 Sending control 'CMD POWERON' to phy0.0 <0005> paging.c:545 Paging: BS_AG_BLKS_RES = 0 != 1 not fully supported <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 1 7' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 2 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 3 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 4 13' <000b> trx_if.c:348 Response message: 'RSP POWERON 0' <000b> trx_if.c:169 Sending control 'CMD SETRXGAIN 1' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETRXGAIN 0 1' <000b> trx_if.c:169 Sending control 'CMD SETPOWER 0' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETPOWER 0 0' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 0 4' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 0 4' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 1 7' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 1 7' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 2 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 2 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 3 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 3 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 4 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 4 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 5 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 5 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 5 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 6 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 6 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 6 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 7 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 7 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 7 13' <0001> oml.c:884 ADM state already was Unlocked <000b> trx_if.c:222 Adding new control 'CMD RXTUNE 1783800' <000b> trx_if.c:169 Sending control 'CMD RXTUNE 1783800' to phy0.1 <000b> trx_if.c:222 Adding new control 'CMD TXTUNE 1878800' <000b> trx_if.c:222 Adding new control 'CMD SETTSC 7' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 0 7' <000b> trx_if.c:348 Response message: 'RSP RXTUNE 0 1783800' <000b> trx_if.c:169 Sending control 'CMD TXTUNE 1878800' to phy0.1 <000b> trx_if.c:348 Response message: 'RSP TXTUNE 0 1878800' <000b> trx_if.c:169 Sending control 'CMD SETTSC 7' to phy0.1 <000b> trx_if.c:348 Response message: 'RSP SETTSC 1 7' <000b> trx_if.c:380 transceiver (phy0.1) rejected TRX command with response: 'RSP SETTSC 1 7' <0001> bts.c:203 Shutting down BTS 0, Reason TRX-CTRL-MSG: CRITICAL <000b> trx_if.c:222 Adding new control 'CMD POWEROFF' <000b> trx_if.c:169 Sending control 'CMD POWEROFF' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP POWEROFF 0' <0001> oml.c:547 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:884 ADM state already was Unlocked <000b> trx_if.c:222 Adding new control 'CMD POWERON' <000b> trx_if.c:169 Sending control 'CMD POWERON' to phy0.0 <000b> trx_if.c:222 Adding new control 'CMD SETRXGAIN 1' <000b> trx_if.c:222 Adding new control 'CMD SETPOWER 0' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 0 4' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 1 7' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 2 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 3 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 4 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 5 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 6 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 7 13' <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <000b> trx_if.c:348 Response message: 'RSP POWERON 0' <000b> trx_if.c:169 Sending control 'CMD SETRXGAIN 1' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETRXGAIN 0 1' <000b> trx_if.c:169 Sending control 'CMD SETPOWER 0' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETPOWER 0 0' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 0 4' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 0 4' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 1 7' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 1 7' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 2 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 2 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 3 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 3 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 4 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 4 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 5 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 5 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 6 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 6 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 7 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 7 13' <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 0 7' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 1 1' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 2 1' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 3 1' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 4 1' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 5 1' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 6 1' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 7 1' <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <000b> trx_if.c:138 Clock indication: fn=999376 <000b> trx_if.c:470 TX burst tn=0 fn=999396 pwr=0 <000b> trx_if.c:470 TX burst tn=1 fn=999396 pwr=0 <000b> trx_if.c:470 TX burst tn=2 fn=999396 pwr=0 ... -- Max Suraev 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 robert.steve07 at gmail.com Tue Jun 28 10:38:28 2016 From: robert.steve07 at gmail.com (robert) Date: Tue, 28 Jun 2016 13:38:28 +0300 Subject: openBSC paging issue Message-ID: <1E967584-2181-4F79-9F81-4A7D584263B7@gmail.com> Hi, when trying to work with multiple BTS as noted in http://umtrx.org/multi-bts-with-osmocom-and-a-single-umtrx/ , I faced a problem related to paging. When I start the BTS, I can send SMS to any connected phone but after a few minutes no SMS is sent and I can?t even make calls. I noticed that the target phone is not being paged anymore. If I restart the openBSC instance the old pending messages get sent sometimes. Also if I run the same code but with only one OSMO-BTS instance, everything works fine. I would really appreciate some help. Best regards, From nhofmeyr at sysmocom.de Tue Jun 28 11:30:20 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 28 Jun 2016 13:30:20 +0200 Subject: [PATCH 1/2] add basic .gitignore Message-ID: <1467113421-24000-1-git-send-email-nhofmeyr@sysmocom.de> From: Neels Hofmeyr --- .gitignore | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..3e0ee03 --- /dev/null +++ b/.gitignore @@ -0,0 +1,43 @@ +# build results +*.o +*.lo +*.la + +# tests +CommonLibs/BitVectorTest +CommonLibs/ConfigurationTest +CommonLibs/F16Test +CommonLibs/InterthreadTest +CommonLibs/LogTest +CommonLibs/RegexpTest +CommonLibs/SocketsTest +CommonLibs/TimevalTest +CommonLibs/URLEncodeTest +CommonLibs/VectorTest + +# automake/autoconf +*.in +.deps +.libs +.dirstamp +*~ +Makefile +config.log +config.status +config.h +config.guess +config.sub +config/* +configure +compile +aclocal.m4 +autom4te.cache +depcomp +install-sh +libtool +ltmain.sh +missing +stamp-h1 + +# vim +*.sw? -- 2.1.4 From nhofmeyr at sysmocom.de Tue Jun 28 11:30:21 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 28 Jun 2016 13:30:21 +0200 Subject: [PATCH 2/2] configure.ac: check for boost/config.hpp header In-Reply-To: <1467113421-24000-1-git-send-email-nhofmeyr@sysmocom.de> References: <1467113421-24000-1-git-send-email-nhofmeyr@sysmocom.de> Message-ID: <1467113421-24000-2-git-send-email-nhofmeyr@sysmocom.de> From: Neels Hofmeyr --- configure.ac | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure.ac b/configure.ac index 6c6ca2e..06423b8 100644 --- a/configure.ac +++ b/configure.ac @@ -119,6 +119,9 @@ AM_CONDITIONAL(ARCH_ARM_A15, [test "x$with_neon_vfpv4" = "xyes"]) PKG_CHECK_MODULES(LIBUSB, libusb-1.0) +AC_CHECK_HEADER([boost/config.hpp],[], + [AC_MSG_ERROR([boost/config.hpp not found, install e.g. libboost-all-dev])]) + dnl Output files AC_CONFIG_FILES([\ Makefile \ -- 2.1.4 From nhofmeyr at sysmocom.de Tue Jun 28 11:40:18 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 28 Jun 2016 13:40:18 +0200 Subject: [PATCH 2/2] configure.ac: check for boost/config.hpp header In-Reply-To: <1467113421-24000-2-git-send-email-nhofmeyr@sysmocom.de> References: <1467113421-24000-1-git-send-email-nhofmeyr@sysmocom.de> <1467113421-24000-2-git-send-email-nhofmeyr@sysmocom.de> Message-ID: <20160628114018.GA26882@ass40.sysmocom.de> On Tue, Jun 28, 2016 at 01:30:21PM +0200, Neels Hofmeyr wrote: > + [AC_MSG_ERROR([boost/config.hpp not found, install e.g. libboost-all-dev])]) rather make this libboost-dev, will resend for convenience. libboost-all-dev also brings in python-dev with hundreds of megabytes, all just to have boost/shared_ptr.hpp. ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Tue Jun 28 11:40:43 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 28 Jun 2016 13:40:43 +0200 Subject: [PATCH] configure.ac: check for boost/config.hpp header Message-ID: <1467114043-26961-1-git-send-email-nhofmeyr@sysmocom.de> From: Neels Hofmeyr --- configure.ac | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure.ac b/configure.ac index 6c6ca2e..c4db4d2 100644 --- a/configure.ac +++ b/configure.ac @@ -119,6 +119,9 @@ AM_CONDITIONAL(ARCH_ARM_A15, [test "x$with_neon_vfpv4" = "xyes"]) PKG_CHECK_MODULES(LIBUSB, libusb-1.0) +AC_CHECK_HEADER([boost/config.hpp],[], + [AC_MSG_ERROR([boost/config.hpp not found, install e.g. libboost-dev])]) + dnl Output files AC_CONFIG_FILES([\ Makefile \ -- 2.1.4 From nhofmeyr at sysmocom.de Tue Jun 28 12:19:01 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 28 Jun 2016 14:19:01 +0200 Subject: for osmo-trx: [PATCH 2/2] configure.ac: check for boost/config.hpp header In-Reply-To: <20160628114018.GA26882@ass40.sysmocom.de> References: <1467113421-24000-1-git-send-email-nhofmeyr@sysmocom.de> <1467113421-24000-2-git-send-email-nhofmeyr@sysmocom.de> <20160628114018.GA26882@ass40.sysmocom.de> Message-ID: <20160628121901.GA31948@ass40.sysmocom.de> And to clarify, these are for osmo-trx, which might not be obvious. ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Tue Jun 28 13:25:48 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 28 Jun 2016 15:25:48 +0200 Subject: dynamic traffic channels In-Reply-To: <20160628080528.GE3849@nataraja> References: <20160628080528.GE3849@nataraja> Message-ID: <20160628132547.GC31948@ass40.sysmocom.de> On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Tue Jun 28 15:45:48 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 28 Jun 2016 17:45:48 +0200 Subject: GPRS on osmo-trx not working Message-ID: <20160628154548.GA19189@ass40.sysmocom.de> Hi List, Voice is working well, but I can't seem to get GPRS working on osmo-trx. I used the standard debian 8.4 packages for UHD which seem to work, and documented that at http://osmocom.org/projects/osmotrx/wiki/OsmoTRX#Dependencies I also tried to use a PCU from before EDGE support was merged, so that's not causing it. Any ideas on what might be causing this? With sysmobts, for example, I needed to configure the pcu with --enable-sysmocom-dsp. Any such things with osmo-trx? I'm running both pcu and osmo-bts-trx as root with -r 1. Some of the log messages look quite bad, like 20160628170840743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 I didn't do the rts-advance increase by 5, because when that log message is issued, the PCU is not running yet: 20160628170837632 DL1C <0006> scheduler.c:240 Prim for trx=0 ts=0 at fn=272652 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=272658) Below are some logs and attached are the config files. The identical setup is working for other BTS models, the osmo-bts.cfg is the only difference. Thanks for any hints! ~Neels TRX: linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0-unknown opening configuration table from path :memory: Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 1 EDGE support............ Disabled External Reference...... Disabled C0 Filler Table......... Disabled Diversity............... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 -- Operating over USB 2. -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 32.000000 MHz -- Actually got clock rate 32.000000 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Asking for clock rate 26.000000 MHz -- Actually got clock rate 26.000000 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting B210 4 SPS -- Transceiver active with 1 channel(s) NOTICE 140232141276928 17:27:18.0 Transceiver.cpp:241:start: Starting the transceiver NOTICE 140232141244160 17:27:18.5 Transceiver.cpp:380:pushRadioVector: dumping STALE burst in TRX->USRP interface ^ I see ~130 of these notices of a stale burst, but all with an identical timestamp, and only once after osmo-bts-trx starts up. PCU: 20160628170840742 DL1IF <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS 20160628170840742 DL1IF <0001> osmobts_sock.cpp:285 osmo-bts PCU socket has been connected 20160628170840742 DL1IF <0001> pcu_l1_if.cpp:359 BTS available 20160628170840742 DNS <0008> gprs_ns.c:233 NSVCI=65534 Creating NS-VC 20160628170840742 DNS <0008> gprs_ns.c:233 NSVCI=1800 Creating NS-VC 20160628170840742 DNS <0008> gprs_ns.c:1568 NSEI=1800 RESET procedure based on API request 20160628170840742 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170840742 DL1IF <0001> pcu_l1_if.cpp:83 Sending activate request: trx=0 ts=5 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:486 PDCH: trx=0 ts=5 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:83 Sending activate request: trx=0 ts=6 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:486 PDCH: trx=0 ts=6 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:83 Sending activate request: trx=0 ts=7 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:486 PDCH: trx=0 ts=7 20160628170843743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170846743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170849743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170852743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170855743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170858743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170901743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170904744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170907744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170910744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170913744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170916744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170919744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170922744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170925745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170928745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170931745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170934745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170937745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170940745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170943746 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) SGSN: <0010> gprs_ns.c:233 NSVCI=65534 Creating NS-VC 20160628170817898 DGPRS <000f> sgsn_main.c:361 VTY at 127.0.0.1 4245 20160628170817898 DGPRS <000f> sgsn_main.c:370 CTRL at 127.0.0.1 4251 20160628170817898 DLGTP <0023> gtp.c:701 GTP: gtp_newgsn() started 20160628170840743 DNS <0010> gprs_ns.c:233 NSVCI=65535 Creating NS-VC 20160628170840743 DNS <0010> gprs_ns.c:1262 Creating NS-VC for BSS at 10.9.1.120:23000 20160628170840743 DNS <0010> gprs_ns.c:834 NSVCI=65535(invalid) Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170840743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170840743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170840743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170843743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170843743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170843743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170843743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170846743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170846743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170846743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170846743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170847899 DGPRS <000f> gprs_sgsn.c:790 Checking for inactive LLMEs, time = 16442 20160628170849743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170849743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170849743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170849743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170852743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170852743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170852743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170852743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170855743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170855743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170855743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170855743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170858743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170858743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170858743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170858743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170901744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170901744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170901744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170901744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170904744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170904744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170904744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170904744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170907744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170907744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170907744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170907744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170910744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170910744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170910744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170910744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170913744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170913744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170913744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170913744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170916744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170916744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170916744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170916744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170917900 DGPRS <000f> gprs_sgsn.c:790 Checking for inactive LLMEs, time = 16472 20160628170919744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170919744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170919745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170919745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170922745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170922745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170922745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170922745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170925745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170925745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170925745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170925745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170928745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170928745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170928745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170928745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170931745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170931745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170931745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170931745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170934745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170934745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170934745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170934745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170937745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170937745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170937745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170937745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170940746 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170940746 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170940746 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170940746 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170943746 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170943746 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170943746 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170943746 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170946746 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170946746 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170946746 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170946746 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 osmo-bts-trx: [...] 20160628170836837 DOML <0001> oml.c:217 OC=CHANNEL INST=(00,00,06) Tx STATE CHG REP 20160628170836877 DOML <0001> oml.c:817 OC=CHANNEL INST=(00,00,07) SET CHAN ATTR (TSC = 7) 20160628170836877 DL1C <0006> scheduler.c:1273 Configuring multiframe with PDCH trx=0 ts=7 20160628170836877 DOML <0001> oml.c:884 ADM state already was Unlocked 20160628170836877 DOML <0001> oml.c:249 OC=CHANNEL INST=(00,00,07) AVAIL STATE Dependency -> OK 20160628170836877 DOML <0001> oml.c:256 OC=CHANNEL INST=(00,00,07) OPER STATE Disabled -> Enabled 20160628170836877 DPCU <0009> pcu_sock.c:627 PCU socket not connected, dropping message 20160628170836877 DOML <0001> oml.c:217 OC=CHANNEL INST=(00,00,07) Tx STATE CHG REP 20160628170836984 DL1C <0006> scheduler_trx.c:1433 GSM clock skew: old fn=272611, new fn=272536 20160628170837632 DL1C <0006> scheduler.c:240 Prim for trx=0 ts=0 at fn=272652 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=272658) 20160628170840742 DPCU <0009> pcu_sock.c:824 PCU socket connected to external PCU 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PDTCH on trx=0 ts=5 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PTCCH on trx=0 ts=5 20160628170840743 DRSL <0000> rsl.c:579 (bts=0,trx=0,ts=5,ss=0) not sending CHAN ACT ACK 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PDTCH on trx=0 ts=6 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PTCCH on trx=0 ts=6 20160628170840743 DRSL <0000> rsl.c:579 (bts=0,trx=0,ts=6,ss=0) not sending CHAN ACT ACK 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PDTCH on trx=0 ts=7 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PTCCH on trx=0 ts=7 20160628170840743 DRSL <0000> rsl.c:579 (bts=0,trx=0,ts=7,ss=0) not sending CHAN ACT ACK 20160628170857756 DL1C <0006> scheduler_trx.c:907 Received incomplete PDTCH block ending at fn=276994 (42/104) for PDTCH 20160628170857756 DL1C <0006> scheduler_trx.c:921 Received bad PDTCH block ending at fn=276994 (42/104) for PDTCH 20160628170940774 DL1C <0006> scheduler_trx.c:907 Received incomplete PDTCH block ending at fn=286315 (3/104) for PDTCH 20160628170940775 DL1C <0006> scheduler_trx.c:921 Received bad PDTCH block ending at fn=286315 (3/104) for PDTCH 20160628170945250 DL1C <0006> scheduler_trx.c:907 Received incomplete PDTCH block ending at fn=287285 (37/104) for PDTCH 20160628170945250 DL1C <0006> scheduler_trx.c:921 Received bad PDTCH block ending at fn=287285 (37/104) for PDTCH -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- ! ! OsmoBTS (0.0.1.100-0455-dirty) configuration saved from vty !! ! log stderr logging filter all 1 logging color 1 logging print category 1 logging timestamp 1 logging print extended-timestamp 1 logging level all everything logging level rsl info logging level oml info logging level rll notice logging level rr notice logging level meas notice logging level pag info logging level l1c notice logging level l1p notice logging level dsp info logging level abis notice logging level rtp notice logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice ! line vty no login ! phy 0 instance 0 osmotrx rx-gain 1 bts 0 band 1800 ipa unit-id 1800 0 oml remote-ip 10.9.1.120 settsc gsmtap-sapi ccch gsmtap-sapi pdtch trx 0 phy 0 instance 0 -------------- next part -------------- ! ! OpenBSC (0.15.0.167-69da1-dirty) configuration saved from vty !! password foo ! log stderr logging filter all 1 logging color 1 logging print category 1 logging timestamp 1 logging print extended-timestamp 1 logging level all everything logging level rll debug logging level cc notice logging level mm debug logging level rr notice logging level rsl debug logging level nm debug logging level mncc notice logging level pag notice logging level meas notice logging level sccp notice logging level msc notice logging level mgcp notice logging level ho notice logging level db notice logging level ref notice logging level gprs notice logging level ns info logging level bssgp notice logging level llc notice logging level sndcp notice logging level nat notice logging level ctrl notice logging level smpp notice logging level filter notice logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice logging level lstats notice ! stats interval 5 ! line vty no login ! e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive ipa bind 10.9.1.120 network network country code 1 mobile network code 868 short name dynch long name dynch auth policy closed location updating reject cause 13 encryption a5 0 neci 1 paging any use tch 0 rrlp mode none mm info 1 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 timer t3101 10 timer t3103 0 timer t3105 0 timer t3107 0 timer t3109 4 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3122 10 timer t3141 0 dtx-used 0 subscriber-keep-in-ram 0 bts 0 type sysmobts band DCS1800 cell_identity 0 location_area_code 1 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 periodic location update 30 radio-link-timeout 32 channel allocator ascending rach tx integer 9 rach max transmission 7 channel-descrption attach 1 channel-descrption bs-pa-mfrms 5 channel-descrption bs-ag-blks-res 1 ip.access unit_id 1800 0 oml ip.access stream_id 255 line 0 neighbor-list mode automatic codec-support fr gprs mode gprs gprs routing area 0 gprs network-control-order nc1 gprs cell bvci 1800 gprs cell timer blocking-timer 3 gprs cell timer blocking-retries 3 gprs cell timer unblocking-retries 3 gprs cell timer reset-timer 3 gprs cell timer reset-retries 3 gprs cell timer suspend-timer 10 gprs cell timer suspend-retries 3 gprs cell timer resume-timer 10 gprs cell timer resume-retries 3 gprs cell timer capability-update-timer 10 gprs cell timer capability-update-retries 3 gprs nsei 1800 gprs ns timer tns-block 3 gprs ns timer tns-block-retries 3 gprs ns timer tns-reset 3 gprs ns timer tns-reset-retries 3 gprs ns timer tns-test 30 gprs ns timer tns-alive 3 gprs ns timer tns-alive-retries 10 gprs nsvc 0 nsvci 1800 gprs nsvc 0 local udp port 23000 gprs nsvc 0 remote udp port 23000 gprs nsvc 0 remote ip 10.9.1.120 no force-combined-si trx 0 rf_locked 0 arfcn 868 nominal power 23 max_power_red 18 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config SDCCH8 hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config PDCH hopping enabled 0 timeslot 6 phys_chan_config PDCH hopping enabled 0 timeslot 7 phys_chan_config PDCH hopping enabled 0 mncc-int default-codec tch-f fr default-codec tch-h hr nitb subscriber-create-on-demand assign-tmsi smpp policy closed no smpp-first -------------- next part -------------- pcu flow-control-interval 10 cs 2 alloc-algorithm dynamic alpha 0 gamma 0 log stderr logging filter all 1 logging color 1 logging print category 1 logging timestamp 1 logging print extended-timestamp 1 -------------- next part -------------- ! ! Osmocom SGSN configuration ! ! line vty no login log stderr logging filter all 1 logging color 1 logging print category 1 logging timestamp 1 logging print extended-timestamp 1 ! sgsn gtp local-ip 127.0.0.1 ggsn 0 remote-ip 127.0.0.2 ggsn 0 gtp-version 1 auth-policy accept-all ! ns timer tns-block 3 timer tns-block-retries 3 timer tns-reset 3 timer tns-reset-retries 3 timer tns-test 30 timer tns-alive 3 timer tns-alive-retries 10 encapsulation udp local-ip 10.9.1.120 encapsulation udp local-port 23000 encapsulation framerelay-gre enabled 0 ! bssgp ! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From tom at tsou.cc Wed Jun 29 00:18:49 2016 From: tom at tsou.cc (Tom Tsou) Date: Tue, 28 Jun 2016 17:18:49 -0700 Subject: osmotrx init problem In-Reply-To: <576AA0DF.2040806@sysmocom.de> References: <576AA0DF.2040806@sysmocom.de> Message-ID: Hi Max, On Wed, Jun 22, 2016 at 7:29 AM, Max wrote: > I've got following problem while trying to make osmotrx work in multitrx > setting on USRP B210: > sudo chrt 20 ./Transceiver52M/osmo-trx -c 2 > sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -t 2 -c > ~/.config/osmocom/osmo-bts-mtrx.cfg -d DRTP:DCC:DRSL:DOML:DL1C:DTRX > > The bts quits from trx_if.c after checking "if (tcm->critical) {...". > The command sequence seems to be the same for both phy0.0 and phy0.1 > However 0.0 one accepts SETTSC command and 0.1 rejects it: > trx_if.c:380 transceiver (phy0.1) rejected TRX command with response: > 'RSP SETTSC 1 7' Please try the updated osmotrx master. TSC rejection was based on legacy behavior where the SETTSC command would instantiate internal DSP resources, so the allowed timing of the command was restricted. That restriction no longer exists. Note that OsmoTRX only supports one TSC value for all channels. SETTSC will only error if sent to a TRX channel other than 0 with a TSC value that differs from the internal TSC value. -TT From tom at tsou.cc Wed Jun 29 00:50:36 2016 From: tom at tsou.cc (Tom Tsou) Date: Tue, 28 Jun 2016 17:50:36 -0700 Subject: GPRS on osmo-trx not working In-Reply-To: <20160628154548.GA19189@ass40.sysmocom.de> References: <20160628154548.GA19189@ass40.sysmocom.de> Message-ID: Hi Neels, On Tue, Jun 28, 2016 at 8:45 AM, Neels Hofmeyr wrote: > Voice is working well, but I can't seem to get GPRS working on osmo-trx. Generally this is strange behavior because there no difference between GPRS and non-GPRS bursts at the osmo-trx level. > I also tried to use a PCU from before EDGE support was merged, so that's > not causing it. > > Any ideas on what might be causing this? > With sysmobts, for example, I needed to configure the pcu with > --enable-sysmocom-dsp. Any such things with osmo-trx? I'm using the latest PCU version 189742b6 with reverted commit "f1a7b8f tbf: Add state WAIT_ASSIGN". I did pass any build time arguments. > Some of the log messages look quite bad, like > 20160628170840743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 > > I didn't do the rts-advance increase by 5, because when that log message is > issued, the PCU is not running yet: > 20160628170837632 DL1C <0006> scheduler.c:240 Prim for trx=0 ts=0 at fn=272652 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=272658) I have not encountered this error and have not modified 'rts-advance'. My general concern is packet loss at the RF level, but this error looks like it may be more related to initialization and O&M. > NOTICE 140232141276928 17:27:18.0 Transceiver.cpp:241:start: Starting the transceiver > NOTICE 140232141244160 17:27:18.5 Transceiver.cpp:380:pushRadioVector: dumping STALE burst in TRX->USRP interface > ^ I see ~130 of these notices of a stale burst, but all with an identical timestamp, and only > once after osmo-bts-trx starts up. You may see these messages at startup as the transport syncs, which is not a concern. I will try testing with you're log files. The rxgain at 1 in osmo-bts.cfg is definitely low. I'm using a setting of 25 with a VERT900 antenna at roughly a 5 meter test distance. -TT From nhofmeyr at sysmocom.de Wed Jun 29 15:31:30 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 29 Jun 2016 17:31:30 +0200 Subject: GPRS on osmo-trx not working In-Reply-To: References: <20160628154548.GA19189@ass40.sysmocom.de> Message-ID: <20160629153130.GB1873@dub6> Hi Tom, thanks for your investigation! It turns out my basic setup of IP addresses was wrong. When I started up the CN, error messages already appeared *without* any mobile device even involved. So I noticed that the main difference to the other BTS models is that for TRX, I also run osmo-bts on my host machine. My configuration files instructed the programs to communicate over my eth0 IP address in the local network, 10.9.1.120. When I change all of these configs to 127.0.0.42 (an implicitly created loopback address), I no longer get the "NS RESET ACK Discarding unexpected..." errors. I haven't fully understood why this fixes it yet, but it seems the SGSN sent the NS RESET ACK to itself... :P Nevertheless, thanks again, I highly appreciate your effort! On Tue, Jun 28, 2016 at 05:50:36PM -0700, Tom Tsou wrote: > I'm using the latest PCU version 189742b6 with reverted commit > "f1a7b8f tbf: Add state WAIT_ASSIGN". I did pass any build time > arguments. Yes, that's my default setup, too. > > 20160628170837632 DL1C <0006> scheduler.c:240 Prim for trx=0 ts=0 at fn=272652 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=272658) It seems to me that it's related to an initial clock sync of sorts... 20160629171522824 DL1C <0006> scheduler_trx.c:1420 GSM clock skew: old fn=463983, new fn=463888 20160629171523170 DL1C <0006> scheduler_trx.c:1420 GSM clock skew: old fn=463963, new fn=463888 20160629171523817 DL1C <0006> scheduler.c:240 Prim for trx=0 ts=0 at fn=464004 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=464010) Ignoring it for now. ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed Jun 29 16:10:51 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 29 Jun 2016 18:10:51 +0200 Subject: scope of scheduler.c and trx_sched_* Message-ID: <20160629161051.GA5293@dub6> I notice that apparently osmo-bts-trx is the only caller of the trx_sched_* API, yet it is implemented in common/scheduler.c and compiled to libl1sched.a. Is osmo-bts-trx really the only caller? Also in osmo-bts-trx, the "trx" to me means SDR, like B200. But any BTS has one or more TRXs. So why isn't it osmo-bts-sdr? That's why I thought: maybe trx_sched_ is for all BTS models? Thanks for any clarification / confirmation :) ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Wed Jun 29 17:37:33 2016 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 29 Jun 2016 19:37:33 +0200 Subject: dynamic traffic channels In-Reply-To: <20160628132547.GC31948@ass40.sysmocom.de> References: <20160628080528.GE3849@nataraja> <20160628132547.GC31948@ass40.sysmocom.de> Message-ID: <20160629173733.GG3894@nataraja> Hi Neels, On Tue, Jun 28, 2016 at 03:25:48PM +0200, Neels Hofmeyr wrote: > On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > > [translated from german] > > is it certain that we switch a channel to PDCH only when > > gprs mode != none? I'm not sure if your response covers the question I raised. What if you have a openbsc.cfg with a bts that has 'gprs mode none' but still has a timeslot in GSM_PCHAN_TCH_F_PDCH mode? The intended operation in that case is that it will be treated as a pure TCH/F, and no attempts to switch to PDCH are made. -- - 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 Wed Jun 29 17:42:18 2016 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 29 Jun 2016 19:42:18 +0200 Subject: scope of scheduler.c and trx_sched_* In-Reply-To: <20160629161051.GA5293@dub6> References: <20160629161051.GA5293@dub6> Message-ID: <20160629174218.GH3894@nataraja> Hi Neels, On Wed, Jun 29, 2016 at 06:10:51PM +0200, Neels Hofmeyr wrote: > I notice that apparently osmo-bts-trx is the only caller of the trx_sched_* > API, yet it is implemented in common/scheduler.c and compiled to > libl1sched.a. Is osmo-bts-trx really the only caller? Yes. > Also in osmo-bts-trx, the "trx" to me means SDR, like B200. > But any BTS has one or more TRXs. So why isn't it osmo-bts-sdr? In osmo-bts-trx, "TRX" means "A program behaving like an OpenBTS tranceiver and implementing the UDP based protocol of that", where the preferred implementation used by most people with osmo-bts-trx is probably "osmo-trx". It should probably still work with the original OpenBTS TRX or with the one from yateBTS. Note that all of this is a threoretical statement, I haven't used either of those configurations. > That's why I thought: maybe trx_sched_ is for all BTS models? It's always useful to look at a call graph. > Thanks for any clarification / confirmation :) simply look at the git log. commit 5538f5cff824f19d5dc8781cbb93525ad45ad833 and those following explain what was done and why it was done. The most important user I care about is osmo-bts-virtual, which also needs all the L1 scheduling parts. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From tom at tsou.cc Wed Jun 29 19:02:56 2016 From: tom at tsou.cc (Tom Tsou) Date: Wed, 29 Jun 2016 12:02:56 -0700 Subject: GPRS on osmo-trx not working In-Reply-To: <20160629153130.GB1873@dub6> References: <20160628154548.GA19189@ass40.sysmocom.de> <20160629153130.GB1873@dub6> Message-ID: On Wed, Jun 29, 2016 at 8:31 AM, Neels Hofmeyr wrote: > It turns out my basic setup of IP addresses was wrong. OK. That's good to know because I modified the addressed in your configuration and did not find the same errors. > When I started up the CN, error messages already appeared *without* any mobile > device even involved. So I noticed that the main difference to the other BTS > models is that for TRX, I also run osmo-bts on my host machine. I see various error messages that occur in different layers at startup. I can definitely confirm that some of these messages are caused by initial Tx/Rx chain and device synchronization. Given that these initialization errors (e.g. early stale bursts, dropped packets) are harmless as long as they only happen once, I'm OK with ignoring them for now. I assume there are other effects and similar concerns that take place higher up the chain. > 20160629171522824 DL1C <0006> scheduler_trx.c:1420 GSM clock skew: old fn=463983, new fn=463888 > 20160629171523170 DL1C <0006> scheduler_trx.c:1420 GSM clock skew: old fn=463963, new fn=463888 > 20160629171523817 DL1C <0006> scheduler.c:240 Prim for trx=0 ts=0 at fn=464004 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=464010) > > Ignoring it for now. With different log settings I do see the 'rts-advance' messages. I'm ignoring these for now as well. Another non-startup error message I found is bad PDTCH and PTCCH and blocks under ideal RF signal conditions. It appears that you have seen this behavior as well. DL1C <0006> scheduler_trx.c:835 Received bad data frame at fn=372020 (12/104) for PTCCH DL1C <0006> scheduler_trx.c:918 Received bad PDTCH block ending at fn=310516 (76/104) for PDTCH The cause of these errors with excellent signal is the following piece of code where zero-filled buffers are passed to the decoder. I have no idea why this is done. Removing the code prevents the bad PDTCH/PTCCH blocks with no loss of GPRS functionality. diff --git a/src/common/scheduler.c b/src/common/scheduler.c @@ -1598,10 +1598,6 @@ int trx_sched_ul_burst() func(l1t, tn, fn, chan, bid, bits, rssi, toa); } else if (chan != TRXC_RACH && !l1cs->ho_rach_detect) { - sbit_t spare[148]; - - memset(spare, 0, 148); - func(l1t, tn, fn, chan, bid, spare, -128, 0); } -TT From keith at rhizomatica.org Wed Jun 29 22:34:00 2016 From: keith at rhizomatica.org (Keith Whyte) Date: Wed, 29 Jun 2016 23:34:00 +0100 Subject: Is there a maximum separation in Mhz for ARFCNs on one BTS? Message-ID: <57744CD8.8080402@rhizomatica.org> Hi all, Would somebody who is familiar with the relevant part of the GSM spec be able to comment? I'm wondering if there's any issue in GSM running a dual TRX BTS with two ARFCNs on opposite ends of the band? For example, in GSM850, this would mean the downlinks could be on 869.2 and 893.8 Mhz so the phone could have to tune across a wider range between the SDCCH and TCH for example. Thanks! From alexander.chemeris at gmail.com Wed Jun 29 22:49:33 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 30 Jun 2016 01:49:33 +0300 Subject: GPRS on osmo-trx not working In-Reply-To: References: <20160628154548.GA19189@ass40.sysmocom.de> <20160629153130.GB1873@dub6> Message-ID: On Jun 29, 2016 10:04 PM, "Tom Tsou" wrote: > > On Wed, Jun 29, 2016 at 8:31 AM, Neels Hofmeyr wrote: > Another non-startup error message I found is bad PDTCH and PTCCH and > blocks under ideal RF signal conditions. It appears that you have seen > this behavior as well. > > DL1C <0006> scheduler_trx.c:835 Received bad data frame at fn=372020 > (12/104) for PTCCH > DL1C <0006> scheduler_trx.c:918 Received bad PDTCH block ending at > fn=310516 (76/104) for PDTCH > > The cause of these errors with excellent signal is the following piece > of code where zero-filled buffers are passed to the decoder. I have no > idea why this is done. Removing the code prevents the bad PDTCH/PTCCH > blocks with no loss of GPRS functionality. > > diff --git a/src/common/scheduler.c b/src/common/scheduler.c > @@ -1598,10 +1598,6 @@ int trx_sched_ul_burst() > > func(l1t, tn, fn, chan, bid, bits, rssi, toa); > } else if (chan != TRXC_RACH && !l1cs->ho_rach_detect) { > - sbit_t spare[148]; > - > - memset(spare, 0, 148); > - func(l1t, tn, fn, chan, bid, spare, -128, 0); > } Each L2 frame consists of several L1 bursts, so you need to accumulate them all before you can pass them to Viterbi for decoding. If I remember this part of the code correctly, this zeroing is required to make this work when there are lost bursts. E.g. if you need 4 bursts, but you only received bursts 0, 1 and 2 you should let the device know that your missing burst 3. If you don't do that, decoder won't run at all and to will miss what could be a decodable frame. By disabling this code you essentially start decoding only perfect frames, which are obviously decoded fine in perfect conditions. I.e. this only makes the actual problem, whatever it is. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at tsou.cc Wed Jun 29 23:30:38 2016 From: tom at tsou.cc (Tom Tsou) Date: Wed, 29 Jun 2016 16:30:38 -0700 Subject: GPRS on osmo-trx not working In-Reply-To: References: <20160628154548.GA19189@ass40.sysmocom.de> <20160629153130.GB1873@dub6> Message-ID: On Wed, Jun 29, 2016 at 3:49 PM, Alexander Chemeris wrote: > If I remember this part of the code correctly, this zeroing is required to > make this work when there are lost bursts. E.g. if you need 4 bursts, but > you only received bursts 0, 1 and 2 you should let the device know that your > missing burst 3. If you don't do that, decoder won't run at all and to will > miss what could be a decodable frame. I see. In that case, the PDTCH behavior may not be unusual, but PTCCH case is certainly strange. On PTCCH, the spare burst seems to be triggering such that the 4 segment block sent to the decoder is always all zeros. I'm testing in controlled conditions and closely monitoring signal levels. I don't think we're missing PTCCH bursts in this case. I seems like osmo-bts is attempting to decode something that doesn't actually exist. -TT From makhof09 at gmail.com Wed Jun 15 06:26:05 2016 From: makhof09 at gmail.com (sms makhof) Date: Wed, 15 Jun 2016 06:26:05 -0000 Subject: OpenBSC Message-ID: Hi all I am installing OpenBSC.I just following http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC (I am just Building libosmocore, Building libosmo-abis, Building libosmo-netif, Building OpenBSC and install library.) But when I tried to run OpenBSC,I encounter with this error(problem). user12 at ubuntu:~$ cd '/home/user12/openbsc/openbsc/src/osmo-nitb' user12 at ubuntu:~/openbsc/openbsc/src/osmo-nitb$ sudo ./osmo-nitb <0005> bsc_init.c:492 Failed to parse the config file: 'openbsc.cfg' Or how do I run the software(OpenBSC)! Or do I have to install something missing? Note: My Linux is version 12.04 . Please help me. thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From makhof09 at gmail.com Sat Jun 18 12:57:59 2016 From: makhof09 at gmail.com (sms makhof) Date: Sat, 18 Jun 2016 17:27:59 +0430 Subject: error install openbsc Message-ID: Hi all I am installing OpenBSC.I just following http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC (I am just Building libosmocore, Building libosmo-abis, Building libosmo-netif, Building OpenBSC and install library.) But when I tried to run OpenBSC,I encounter with this error(problem). user12 at ubuntu:~$ cd '/home/user12/openbsc/openbsc/src/osmo-nitb' user12 at ubuntu:~/openbsc/openbsc/src/osmo-nitb$ sudo ./osmo-nitb <0005> bsc_init.c:492 Failed to parse the config file: 'openbsc.cfg' Or how do I run the software(OpenBSC)! Or do I have to install something missing? Note: My Linux is version ubuntu 12.04 . Please help me. thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: