OpenBSC January 2018

openbsc@lists.osmocom.org

29 participants
52 discussions

fairwaves HO patches
by Neels Hofmeyr 23 Feb '18

23 Feb '18

Hi Ivan, as I'm working towards load-based handover and incorporating your patches, I found that most of it is concerned with libmsc. In contrast, I am currently working on osmo-bsc, in libbsc, and would like to ask your advice. Some parts of the patch aren't easy to understand for me, and I'd like to make sure that I am not dismissing parts of it as non-applicable to libbsc even though they might be important. Since your patches were written, the code has changed. Now that we have the separate osmo-bsc, we will need two layers of handover: intra-BSC and inter-BSC. Intra-BSC is a handover between two cells that are serviced by the same BSC, and the higher layers (MSC) should not even notice that anything has happened -- MSC has asked the BSC to service a call by BSSAP Assignment, and the BSC is free to choose and change around the lchans it assigns to that. That is the layer I'm currently dug into. Inter-BSC is a handover between cells that are serviced by two different BSCs. That seems to be the land your patch is improving. The MSC is involved and so is MNCC. (Both MSC and BSC levels will need their own DTAP cache, and they are by definition completely independent -- MSC caches the DTAP coming from MNCC during Inter-BSC handover, BSC caches DTAP from MSC during Intra-BSC handover.) Since your patch is applied onto openbsc.git, where all of BSC and MSC are still one osmo-nitb, I want to make sure that I sort your patch right. Do some of its semantics apply to osmo-bsc master, even if the code changed? The smaller patches are either already applied to osmo-bsc master, or I've submitted them on gerrit just now: handover_decision: Add more log messages to get more information about HO causes in logs handover_decision: Fix condition for power budget handover attempt handover_logic: set correct link to bts for subscriber_connection in case of moving this connection to another bts Remaining are a small and *the* complex one: transaction: Add new function trans_find_by_lchan handover: Implement proper handover procedure handling at any stage of the call Here is the last one with inline questions, I hope they are not too stupid; or too long, it ended up being a lot to read. Thanks in advance for taking a look: > commit f7f4dc5e3b0dd61b8322946597147baef5d0464b > Author: Ivan Kluchnikov <kluchnikovi(a)gmail.com> > Date: Wed Aug 23 18:09:50 2017 +0300 > > handover: Implement proper handover procedure handling at any stage of the call > > Enhancements for each stage of handover procedure should be implemented in order to support handover at any stage of the call. > For these purposes new in_handover state and ho_queue for call control messages was introduced for gsm_subscriber_connection. > > Stage 1: HO-Command is sent to MS > gsm_subscriber_connection state should be changed to in_handover=1. > In this state all transmission of signalling layer messages (except RR messages needed for handover procedure) > should be suspended until resuming is indicated. > All call control messages for connection received from network side should be buffered in ho_queue. > All call control messages for connection received from MS side should be ignored. > Channel mode modification procedures should be also suspended. > > Stage 2: HO-Detect is received from MS > Audio path should be switched on network side. > > Stage 3-1: HO-Complete is received from MS > Resumption procedure after successful handover should be performed: > - gsm_subscriber_connection state should be changed to normal (in_handover=0). > - all buffered call control messages (ho_queue) should be sent to MS on new lchan. > - suspended channel mode modification procedures should be performed on new lchan. > > Stage 3-2: HO-Fail is received from MS > Resumption procedure after failed handover should be performed: > - gsm_subscriber_connection state should be changed to normal (in_handover=0). > - all buffered call control messages (ho_queue) should be sent to MS on old lchan. > - suspended channel mode modification procedures should be performed on old lchan. > > Stage 3-3: T3103 expired: Handover has failed without HO-Complete or HO-Fail > Resumption procedure should not be performed in case of T3103 expired: > - gsm_subscriber_connection state should be changed to normal (in_handover=0). > - all buffered call control messages (ho_queue) should be cleaned without sending them to MS. > - suspended channel mode modification procedures should not be performed. > > Change-Id: Icb9b5c35ef0c894af2ea762e539f1a9216447fb7 > > diff --git a/openbsc/include/openbsc/bsc_api.h b/openbsc/include/openbsc/bsc_api.h > index 3a931199..baacbeda 100644 > --- a/openbsc/include/openbsc/bsc_api.h > +++ b/openbsc/include/openbsc/bsc_api.h > @@ -51,5 +51,6 @@ int gsm0808_cipher_mode(struct gsm_subscriber_connection *conn, int cipher, > int gsm0808_page(struct gsm_bts *bts, unsigned int page_group, > unsigned int mi_len, uint8_t *mi, int chan_type); > int gsm0808_clear(struct gsm_subscriber_connection *conn); > +int gsm0808_ho_clear(struct gsm_subscriber_connection *conn); > > #endif > diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h > index ac573c49..542b2611 100644 > --- a/openbsc/include/openbsc/gsm_data.h > +++ b/openbsc/include/openbsc/gsm_data.h > @@ -138,6 +138,8 @@ struct gsm_subscriber_connection { > struct gsm_network *network; > > int in_release; > + int in_handover; > + struct llist_head ho_queue; > struct gsm_lchan *lchan; /* BSC */ > struct gsm_lchan *ho_lchan; /* BSC */ > struct gsm_bts *bts; /* BSC */ > diff --git a/openbsc/src/libbsc/bsc_api.c b/openbsc/src/libbsc/bsc_api.c > index 8a4c85ff..71e82d03 100644 > --- a/openbsc/src/libbsc/bsc_api.c > +++ b/openbsc/src/libbsc/bsc_api.c > @@ -253,11 +253,14 @@ struct gsm_subscriber_connection *bsc_subscr_con_allocate(struct gsm_lchan *lcha > conn->bts = lchan->ts->trx->bts; > lchan->conn = conn; > llist_add_tail(&conn->entry, &net->subscr_conns); > + INIT_LLIST_HEAD(&conn->ho_queue); > return conn; > } > > void bsc_subscr_con_free(struct gsm_subscriber_connection *conn) > { > + struct msgb *msg; > + > if (!conn) > return; > > @@ -283,6 +286,11 @@ void bsc_subscr_con_free(struct gsm_subscriber_connection *conn) > conn->secondary_lchan->conn = NULL; > } > > + while (!llist_empty(&conn->ho_queue)) { > + msg = msgb_dequeue(&conn->ho_queue); > + msgb_free(msg); > + } > + > llist_del(&conn->entry); > talloc_free(conn); > } > @@ -747,6 +755,17 @@ int gsm0808_clear(struct gsm_subscriber_connection *conn) > return 0; > } > > +/* > + * Release handover RF Channel. > + */ > +int gsm0808_ho_clear(struct gsm_subscriber_connection *conn) > +{ > + if (conn->ho_lchan) > + bsc_clear_handover(conn, 1); > + > + return 0; > +} > + > static void send_sapi_reject(struct gsm_subscriber_connection *conn, int link_id) > { > struct bsc_api *api; > diff --git a/openbsc/src/libbsc/handover_logic.c b/openbsc/src/libbsc/handover_logic.c > index af4e8013..b7085c34 100644 > --- a/openbsc/src/libbsc/handover_logic.c > +++ b/openbsc/src/libbsc/handover_logic.c > @@ -186,10 +186,17 @@ static void ho_T3103_cb(void *_ho) > { > struct bsc_handover *ho = _ho; > struct gsm_network *net = ho->new_lchan->ts->trx->bts->network; > + struct msgb *msg; > > DEBUGP(DHO, "HO T3103 expired\n"); > rate_ctr_inc(&net->bsc_ctrs->ctr[BSC_CTR_HANDOVER_TIMEOUT]); > > + ho->new_lchan->conn->in_handover = 0; > + while (!llist_empty(&ho->new_lchan->conn->ho_queue)) { > + msg = msgb_dequeue(&ho->new_lchan->conn->ho_queue); > + msgb_free(msg); > + } > + (Your ho_queue seems to live in libbsc, while most of the patch seems to be concerned with libmsc. But nevermind, from jolly's patches I already have a similar queue in osmo-bsc, and we'll probably use yours for libmsc.) > ho->new_lchan->conn->ho_lchan = NULL; > ho->new_lchan->conn = NULL; > lchan_release(ho->new_lchan, 0, RSL_REL_LOCAL_END); > @@ -214,6 +221,8 @@ static int ho_chan_activ_ack(struct gsm_lchan *new_lchan) > > gsm48_send_ho_cmd(ho->old_lchan, new_lchan, 0, ho->ho_ref); > > + new_lchan->conn->in_handover = 1; > + In current osmo-bsc master, we already set conn->ho_lchan before sending out the chan activation request. I'd actually assume setting the flag only now, after the activ ack, is a bit too late? > /* start T3103. We can continue either with T3103 expiration, > * 04.08 HANDOVER COMPLETE or 04.08 HANDOVER FAIL */ > ho->T3103.cb = ho_T3103_cb; > @@ -221,7 +230,8 @@ static int ho_chan_activ_ack(struct gsm_lchan *new_lchan) > osmo_timer_schedule(&ho->T3103, 10, 0); > > /* create a RTP connection */ > - if (is_ipaccess_bts(new_lchan->ts->trx->bts)) > + if (is_ipaccess_bts(new_lchan->ts->trx->bts) && > + new_lchan->tch_mode != GSM48_CMODE_SIGN) > rsl_ipacc_crcx(new_lchan); Please explain ... what case / behavior is this fixing? Do we ever see CMODE_SIGN handovers? Would we also need to check for GSM48_CMODE_DATA_*? > @@ -273,6 +283,11 @@ static int ho_gsm48_ho_compl(struct gsm_lchan *new_lchan) > if (is_e1_bts(new_lchan->conn->bts)) > switch_trau_mux(ho->old_lchan, new_lchan); > > + if (ho->old_lchan->conn->mncc_rtp_connect_pending) { > + new_lchan->abis_ip.connect_port = ho->old_lchan->abis_ip.connect_port; > + new_lchan->abis_ip.connect_ip = ho->old_lchan->abis_ip.connect_ip; > + } > + So if an RTP connect to MNCC is pending, we copy the old lchan's RTP port and IP? Which is this, the MNCC / call router side IP and port? Why not set this at the initiation of the HO already? > @@ -295,27 +310,9 @@ static int ho_gsm48_ho_compl(struct gsm_lchan *new_lchan) > static int ho_gsm48_ho_fail(struct gsm_lchan *old_lchan) > { > struct gsm_network *net = old_lchan->ts->trx->bts->network; > - struct bsc_handover *ho; > - struct gsm_lchan *new_lchan; > - > - ho = bsc_ho_by_old_lchan(old_lchan); > - if (!ho) { > - LOGP(DHO, LOGL_ERROR, "unable to find HO record\n"); > - return -ENODEV; > - } > > rate_ctr_inc(&net->bsc_ctrs->ctr[BSC_CTR_HANDOVER_FAILED]); > > - new_lchan = ho->new_lchan; > - > - /* release the channel and forget about it */ > - ho->new_lchan->conn->ho_lchan = NULL; > - ho->new_lchan->conn = NULL; > - handover_free(ho); > - > - lchan_release(new_lchan, 0, RSL_REL_LOCAL_END); > - > - I'm puzzled by this removal. No actions during ho_fail? Is this really intended, or just some rebase artifact? > return 0; > } > > diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c > index e5402d0a..84338d72 100644 > --- a/openbsc/src/libmsc/gsm_04_08.c > +++ b/openbsc/src/libmsc/gsm_04_08.c > @@ -147,6 +147,15 @@ static int gsm48_conn_sendmsg(struct msgb *msg, struct gsm_subscriber_connection > sign_link->trx->bts->nr, > sign_link->trx->nr, msg->lchan->ts->nr, > gh->proto_discr, gh->msg_type); > + > + if (conn->in_handover) { > + msgb_enqueue(&conn->ho_queue, msg); > + DEBUGP(DCC, "(bts %d trx %d ts %d) Suspend message sending to MS, " > + "active HO procedure.\n", > + sign_link->trx->bts->nr, > + sign_link->trx->nr, msg->lchan->ts->nr); > + return 0; > + } (here DTAP handled in libmsc ends up in the ho_queue that otherwise seems to live in libbsc ... as I said above this queue will probably move to libmsc altogether to become part of osmo-msc master.) > } > > return gsm0808_submit_dtap(conn, msg, 0, 0); > @@ -1749,11 +1758,8 @@ static int switch_for_handover(struct gsm_lchan *old_lchan, > struct rtp_socket *old_rs, *new_rs, *other_rs; > > /* Ask the new socket to send to the already known port. */ > - if (new_lchan->conn->mncc_rtp_bridge) { > - LOGP(DHO, LOGL_DEBUG, "Forwarding RTP\n"); > - rsl_ipacc_mdcx(new_lchan, > - old_lchan->abis_ip.connect_ip, > - old_lchan->abis_ip.connect_port, 0); > + if (new_lchan->ts->trx->bts->network->mncc_state) { > + /* Audio path should be switched after receiving ho detect message.*/ > return 0; > } I notice that in the current head, the entire switch_for_handover() has been dropped; it was doing libbsc lchan stuff from within libmsc. Hence we must have added similar logic in osmo-bsc.git and completely dropped this. I think the commit re-implementing handover in osmo-bsc is http://git.osmocom.org/osmo-bsc/commit/?id=39c609b7c924524172ad311bdf89f92b… It appears that lchan->abis_ip.connect_ip and connect_port aren't used at all in osmo-bsc master, but are still present in the struct. I'll ask others about that. In any case, the code base has changed substantially, and this patch hunk no longer applies at all. Am I interpreting this hunk correctly: it moves the ipacc_mdcx to tell the new lchan about its RTP peer to a later stage? In current osmo-bsc master, it seems that this ipacc_mdcx happens as soon as the ipacc_crcx is complete, seen in osmo-bsc/src/osmo-bsc/osmo_bsc_audio.c in handle_abisip_signal(), always using the IP:port the MSC sent us. > > @@ -1821,8 +1827,10 @@ static int handle_abisip_signal(unsigned int subsys, unsigned int signal, > if (subsys != SS_ABISIP) > return 0; > > + net = lchan->ts->trx->bts->network; > + > /* RTP bridge handling */ > - if (lchan->conn && lchan->conn->mncc_rtp_bridge) > + if (lchan->conn && net->mncc_state) > return tch_rtp_signal(lchan, signal); What are the semantics here? It seems odd to move from a check of a conn-specific state (conn->mncc_rtp_bridge) to a check of a global value (net->mncc_state). In any case, this is MNCC related and should not impact Intra-BSC handover, right? > > /* in case we use direct BTS-to-BTS RTP */ > @@ -1851,7 +1859,6 @@ static int handle_abisip_signal(unsigned int subsys, unsigned int signal, > > /* check if any transactions on this lchan still have > * a tch_recv_mncc request pending */ > - net = lchan->ts->trx->bts->network; > llist_for_each_entry(trans, &net->trans_list, entry) { > if (trans->conn && trans->conn->lchan == lchan && trans->tch_recv) { > DEBUGP(DCC, "pending tch_recv_mncc request\n"); > @@ -2017,6 +2024,13 @@ static int tch_recv_mncc(struct gsm_network *net, uint32_t callref, int enable) > switch (bts->type) { > case GSM_BTS_TYPE_NANOBTS: > case GSM_BTS_TYPE_OSMO_SYSMO: > if (ipacc_rtp_direct) { > LOGP(DCC, LOGL_ERROR, "Error: RTP proxy is disabled\n"); > return -EINVAL; > } > + /* RTP bridge handling */ > + if (lchan->conn && net->mncc_state) { > + return 0; > + } If we have a conn and using external MNCC, don't continue at all? I'm not following, would be nice if the comment explained why we need to drop out here. (added some more code context manually) > /* In case, we don't have a RTP socket to the BTS yet, the BTS > * will not be connected to our RTP proxy and the socket will > * not be assigned to the application interface. This method > * will be called again, once the audio socket is created and > * connected. */ > if (!lchan->abis_ip.rtp_socket) { > DEBUGP(DCC, "queue tch_recv_mncc request (%d)\n", enable); > return 0; > } > if (enable) { > /* connect the TCH's to our RTP proxy */ > rc = rsl_ipacc_mdcx_to_rtpsock(lchan); > if (rc < 0) > return rc; > /* assign socket to application interface */ > rtp_socket_upstream(lchan->abis_ip.rtp_socket, > net, callref); > } else > rtp_socket_upstream(lchan->abis_ip.rtp_socket, > net, 0); > break; > > @@ -3325,6 +3339,41 @@ static void mncc_recv_rtp_err(struct gsm_network *net, uint32_t callref, int cmd > return mncc_recv_rtp(net, callref, cmd, 0, 0, 0, 0); > } > > +static void mncc_recv_rtp_modify(struct gsm_lchan *lchan, uint32_t callref) This is to tell the call router that the payload type has changed, right? I've asked in the redmine about whether/how we'd convey an RTP payload change to the MNCC in case of an Intra-BSC handover... https://osmocom.org/issues/1606#note-45 > +{ > + int msg_type; > + struct gsm_network *net = lchan->ts->trx->bts->network; > + > + LOGP(DMNCC, LOGL_NOTICE, "%s sending pending RTP modify ind.\n", > + gsm_lchan_name(lchan)); > + > + switch (lchan->abis_ip.rtp_payload) { > + case RTP_PT_GSM_FULL: > + msg_type = GSM_TCHF_FRAME; > + break; > + case RTP_PT_GSM_EFR: > + msg_type = GSM_TCHF_FRAME_EFR; > + break; > + case RTP_PT_GSM_HALF: > + msg_type = GSM_TCHH_FRAME; > + break; > + case RTP_PT_AMR: > + msg_type = GSM_TCH_FRAME_AMR; > + break; > + default: > + LOGP(DMNCC, LOGL_ERROR, "%s unknown payload type %d\n", > + gsm_lchan_name(lchan), lchan->abis_ip.rtp_payload); > + msg_type = 0; > + break; > + } > + > + mncc_recv_rtp(net, callref, MNCC_RTP_MODIFY, > + lchan->abis_ip.bound_ip, > + lchan->abis_ip.bound_port, > + lchan->abis_ip.rtp_payload, > + msg_type); > +} > + > static int tch_rtp_create(struct gsm_network *net, uint32_t callref) > { > struct gsm_bts *bts; > @@ -3374,6 +3423,9 @@ static int tch_rtp_create(struct gsm_network *net, uint32_t callref) > LOGP(DMNCC, LOGL_DEBUG, "RTP create: codec=%s, chan_type=%s\n", > get_value_string(gsm48_chan_mode_names, m), > get_value_string(gsm_chan_t_names, lchan->type)); > + if (trans->conn->in_handover) { > + return 0; > + } Am I reading right: if we're doing handover, the MSC shouldn't sent another BSSAP Assignment to the BSC; instead, the BSC level figures out another lchan and done ... ? > return gsm0808_assign_req(trans->conn, m, > lchan->type != GSM_LCHAN_TCH_H); > } > @@ -3420,23 +3472,21 @@ static int tch_rtp_connect(struct gsm_network *net, void *arg) > * same package! > */ > trans->conn->mncc_rtp_connect_pending = 1; > + if (trans->conn->in_handover) { > + lchan->abis_ip.connect_port = rtp->port; > + lchan->abis_ip.connect_ip = rtp->ip; > + return 0; > + } > return rsl_ipacc_mdcx(lchan, rtp->ip, rtp->port, 0); We're not telling the BTS about the call router's IP:port anymore? Please explain... > } > > static int tch_rtp_signal(struct gsm_lchan *lchan, int signal) > { > struct gsm_network *net; > - struct gsm_trans *tmp, *trans = NULL; > + struct gsm_trans *trans; > > net = lchan->ts->trx->bts->network; > - llist_for_each_entry(tmp, &net->trans_list, entry) { > - if (!tmp->conn) > - continue; > - if (tmp->conn->lchan != lchan && tmp->conn->ho_lchan != lchan) > - continue; > - trans = tmp; > - break; > - } > + trans = trans_find_by_lchan(lchan); > > if (!trans) { > LOGP(DMNCC, LOGL_ERROR, "%s IPA abis signal but no transaction.\n", > @@ -3459,7 +3509,7 @@ static int tch_rtp_signal(struct gsm_lchan *lchan, int signal) > maybe_switch_for_handover(lchan); > break; > case S_ABISIP_MDCX_ACK: > - if (lchan->conn->mncc_rtp_connect_pending) { > + if (lchan->conn->mncc_rtp_connect_pending && !lchan->conn->in_handover) { if we're in handover, we don't need to tell MNCC that RTP got connected, because that already happened when the call got established initially? So mncc_rtp_connect_pending has a second meaning during handover? > lchan->conn->mncc_rtp_connect_pending = 0; > LOGP(DMNCC, LOGL_NOTICE, "%s sending pending RTP connect ind.\n", > gsm_lchan_name(lchan)); > mncc_recv_rtp_sock(net, trans, MNCC_RTP_CONNECT); > } > break; > @@ -3471,6 +3521,134 @@ static int tch_rtp_signal(struct gsm_lchan *lchan, int signal) > return 0; > } > > +static void ho_queue_clean(struct gsm_subscriber_connection *conn) > +{ > + struct msgb *msg; > + while (!llist_empty(&conn->ho_queue)) { > + msg = msgb_dequeue(&conn->ho_queue); > + msgb_free(msg); > + } > +} > + > +static void ho_resumption(struct gsm_lchan *lchan, struct gsm_trans *trans) > +{ > + struct msgb *msg; > + enum gsm48_chan_mode m; > + > + while (!llist_empty(&lchan->conn->ho_queue)) { > + msg = msgb_dequeue(&lchan->conn->ho_queue); > + gsm48_conn_sendmsg(msg, lchan->conn, trans); > + } > + > + if (trans->conn->mncc_rtp_create_pending && > + lchan->tch_mode == GSM48_CMODE_SIGN) { > + m = mncc_codec_for_mode(lchan->type); > + gsm0808_assign_req(lchan->conn, m, lchan->type != GSM_LCHAN_TCH_H); Wait, now we *do* send a BSSAP Assignment after all? (excuse if I'm being noob, I'm still finding my way through handover in general) shouldn't we rather dequeue the cached DTAP after this instead of before? > + } > + > + if (trans->conn->mncc_rtp_connect_pending) { > + rsl_ipacc_mdcx(lchan, lchan->abis_ip.connect_ip, lchan->abis_ip.connect_port, 0); > + } > +} > + > +static int ho_complete(struct gsm_lchan *new_lchan) > +{ > + struct gsm_trans *trans; > + > + new_lchan->conn->in_handover = 0; > + trans = trans_find_by_lchan(new_lchan); > + if (!trans) { > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but no transaction for new_lchan.\n", > + gsm_lchan_name(new_lchan)); > + ho_queue_clean(new_lchan->conn); > + return 0; > + } > + > + ho_resumption(new_lchan, trans); > + return 0; > +} > + > +static int ho_fail(struct gsm_lchan *old_lchan) > +{ > + struct gsm_trans *trans; > + > + old_lchan->conn->in_handover = 0; > + trans = trans_find_by_lchan(old_lchan); > + if (trans) > + ho_resumption(old_lchan, trans); > + else { > + LOGP(DHO, LOGL_ERROR, "%s HO fail, but no transaction for old_lchan.\n", > + gsm_lchan_name(old_lchan)); > + ho_queue_clean(old_lchan->conn); > + } > + > + gsm0808_ho_clear(old_lchan->conn); > + return 0; > +} > + > +static int ho_detect(struct gsm_lchan *new_lchan) > +{ > + struct gsm_trans *trans; > + struct gsm_lchan *old_lchan; > + > + trans = trans_find_by_lchan(new_lchan); > + > + if (!trans) { > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but no transaction for new_lchan" > + " with enabled tch_recv.\n", > + gsm_lchan_name(new_lchan)); > + return 0; > + } > + > + if (!new_lchan->conn->mncc_rtp_bridge) { > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but connection not in mncc_rtp_bridge mode.\n", > + gsm_lchan_name(new_lchan)); > + return 0; > + } > + > + old_lchan = bsc_handover_pending(new_lchan); > + if (!old_lchan) { > + LOGP(DHO, LOGL_ERROR, "%s HO detected, but no old_lchan for handover.\n", > + gsm_lchan_name(new_lchan)); > + return 0; > + } > + > + LOGP(DHO, LOGL_DEBUG, "HO detected, forwarding RTP\n"); > + rsl_ipacc_mdcx(new_lchan, > + old_lchan->abis_ip.connect_ip, > + old_lchan->abis_ip.connect_port, 0); > + > + mncc_recv_rtp_modify(new_lchan, trans->callref); > + > + return 0; > +} > + > +/* some other part of the code sends us a signal */ > +static int handle_lchan_signal(unsigned int subsys, unsigned int signal, > + void *handler_data, void *signal_data) > +{ > + struct lchan_signal_data *lchan_data; > + struct gsm_lchan *lchan; > + > + lchan_data = signal_data; > + switch (subsys) { > + case SS_LCHAN: > + lchan = lchan_data->lchan; > + if (!lchan->conn) > + return 0; > + switch (signal) { > + case S_LCHAN_HANDOVER_DETECT: > + return ho_detect(lchan); > + case S_LCHAN_HANDOVER_COMPL: > + return ho_complete(lchan); > + case S_LCHAN_HANDOVER_FAIL: > + return ho_fail(lchan); > + } > + break; > + } > + > + return 0; > +} > > static struct downstate { > uint32_t states; > @@ -3853,6 +4031,11 @@ static int gsm0408_rcv_cc(struct gsm_subscriber_connection *conn, struct msgb *m > gsm48_cc_msg_name(msg_type), trans?(trans->cc.state):0, > gsm48_cc_state_name(trans?(trans->cc.state):0)); > > + if (conn->in_handover) { > + DEBUGP(DCC, "Message unhandled, handover procedure.\n"); > + return 0; > + } > + If in handover, drop all CC on the floor? How about a call release, i.e. I hang up while I'm coincidentally being handovered? > /* Create transaction */ > if (!trans) { > DEBUGP(DCC, "Unknown transaction ID %x, " > > > Thanks again! ~N

3 4

On the use of 'decmatch' in TTCN-3
by Harald Welte 01 Feb '18

01 Feb '18

Hi, I know that TTCN-3 is still new to a lot of you, but we are writing tons of integration testing against the various osmocom programs in it. It is quite amazing technology, and I would like to ask you to bear with me reading this mail :) Pau was stating the question earlier today on not finding an example on how to use decmatch. Indeed, it took me some months to find that gem in the TTCN-3 world. It solves the problem that you often have during test of layered protocol stacks: you have separate encoders/decoders for each protocol layer, and now you want to match on some of the *inner* payload. So normally, you have some kind of header definition + a binary (octetstring) payload. This happens in RSL with the L3_INFO IE, and just the same on BSSAP/DTAP where again the L3 message (for example call control) is encapsulated inside one information element. Now you have multiple options of addressing the problem: a) hand-written calls to the decoder function b) write na 'emulation' for the entire protocol layer c) use decmatch. a) would look like this (pseudo-code): var octetstring l3oct; var RSL_Message rsl RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, ?)) -> value rsl { var PDU_ML3_MS_NW l3 := dec_PDU_ML3_MS_NW(rsl.payload); if (match(l3, some_template)) { ... do something } ... } Which uses the built-in pattern-matching on the RSL port to match any message that matches the tr_RSL_DATA_REQ template, and stores the resulting RSL message in a variable. It then uses an explicit call to the decoder function of the L3 message, and then uses regular conditional expressions for further matching on that inner L3 payload. This is more or less how you would write in C, python or any other quite imperative programming languages. It's very verbose, time consuming and un-abstract/elegant. TTCN-3 has many declarative aspects to it. Code like the above is a waste of your time :) b) would mean that you implement some test component that handles the RSL messages on its bottom side test port, and the L3 messages on its top side test port. That is a possible way, and if you need a lot of state/logic of RSL, it maeks sense. But what if you really simply want to have a match? Then it would be a lot of effort and a large detour. c) decmatch to the rescue! You can write RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, decmatch tr_RRM_RR_STATUS)) which means: * do a receive on the RSL test port, and match on an incoming RSL message that matches the tr_RSL_DATA_REQ template, with channel number specified, link_id any (?), *and* if the octetstring payload, if decoded, matches the template tr_RRM_RR_STATUS ! This is *extremely* powerful and expressive. It allows you to condense complex, parametric template matching over multiple proocol layers. It would in the end match RSL DATA REQUEST, only if they contained a [valid] encoded RR STATUS. See https://gerrit.osmocom.org/6229 for the actual test case I used for the above examples. Please also note that I never had to even write the function name of the decoder (dec_PDU_ML3_MS_NW), but TTCN-3 *automatically* figures out which decoder function it must call in order to decode from the binary octetstring. Happy (TTCN-3) hacking + Osmocom bugfixing, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 2

grcardsim: fails with "bad echo value"
by Marek Sebera 31 Jan '18

31 Jan '18

Hi, sim card by identification ATR: 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8 GREEN CARD, Grcard (Hong Kong ) Co.,Limited, LTE Usim Card (Telecommunication) Celcom Postpaid 3G (Telecommunication) when trying to program using ./pySim-prog.py -n OpenBSC -i 901700000003080 -c 001 -x 001 -y 02 -s 1791198229180000075 -d /dev/ttyUSB0 -a 58001006 -t grcardsim pySim-prog.py fails with following stacktrace Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 636, in <module> card.program(cp) File "/home/username/pysim/pySim/cards.py", line 271, in program self._scc.verify_chv(5, pin) File "/home/username/pysim/pySim/commands.py", line 111, in verify_chv return self._tp.send_apdu_checksw(self.cla_byte + '2000' + ('%02X' % schv_no) + '08' + fc) File "/home/username/pysim/pySim/transport/__init__.py", line 85, in send_apdu_checksw rv = self.send_apdu(pdu) File "/home/username/pysim/pySim/transport/__init__.py", line 68, in send_apdu data, sw = self.send_apdu_raw(pdu) File "/home/username/pysim/pySim/transport/serial.py", line 202, in send_apdu_raw self._tx_string(pdu[5:]) File "/home/username/pysim/pySim/transport/serial.py", line 168, in _tx_string raise ProtocolError("Bad echo value (Expected: %s, got %s)" % (b2h(s), b2h(r))) pySim.exceptions.ProtocolError: Bad echo value (Expected: 33353338333033303331333033303336, got 3335333833303330333330333033366e) - using usb sim card reader which creates standard serial line on /dev/ttyUSB0 programming also fails when using Gemalto Ezio Shield ./pySim-prog.py -n OpenBSC -i 901700000003080 -c 001 -x 001 -y 02 -s 1791198229180000075 -p 0 -a 58001006 -t grcardsim fails with following stacktrace Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 636, in <module> card.program(cp) File "/home/smarek/Documents/PROJEKTY/SECURITY/TELCO/SIMCARDS/pysim/pySim/cards.py", line 271, in program self._scc.verify_chv(5, pin) File "/home/smarek/Documents/PROJEKTY/SECURITY/TELCO/SIMCARDS/pysim/pySim/commands.py", line 111, in verify_chv return self._tp.send_apdu_checksw(self.cla_byte + '2000' + ('%02X' % chv_no) + '08' + fc) File "/home/smarek/Documents/PROJEKTY/SECURITY/TELCO/SIMCARDS/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed ! Expected 9000 and got 6b00. Thank you for your help MS

3 9

Pysim - "Unable to connect with protocol: T0 or T1. Card is unpowered."
by Osmocom Mailing List 31 Jan '18

31 Jan '18

Hey, I ordered a generic blank LTE SIM card from ebay. When I try to read it I get the following message. "Unable to connect with protocol: T0 or T1. Card is unpowered." Before you ask, no, the sim is not in the wrong position. Check the attached images. Am I doing something wrong or is the card faulty? The reader is working, I was able to read/write to a SuperSIM (X-sim) and it detected a bunch of commercial SIMs from local operators (wasn't able to read any SIM specific value but I think that's normal). I just want to know if I should open a report agains the seller. Images: https://imgur.com/a/jrtPL Here's the technical data: READER Model: Gemalto PC USB-TR (now, IDBridge CT30) Specifications: https://www.gemalto.com/products/pc_link_readers/index.html SIM (acording to ebay listing) Name: LTE Blank USIM Card SIM Card Size: Standard SIM Card,Micro SIM Card and Nano SIM Card, 3 in 1 Compatible: 4G FDD LTE WCDMA GSM Feature: Can be written ICCID, IMSI, KI, OPC . Application: For Telecommunications Operator Thanks, Filipe Laíns <https://github.com/FFY00> Sent via Migadu.com, world's easiest email hosting

2 1

[openbsc 1.0.0.14-98a2ba] testsuite: 4 failed
by Марат Узяков 31 Jan '18

31 Jan '18

Hi! Please help!

1 0

Help migrating away from NITB
by Rafael Diniz 23 Jan '18

23 Jan '18

Hi all, I'm starting to get used to the new stack with split components, and all seems to be working fine, SMS and USSD are working, but no voice calls yet. ps ax: 7611 pts/4 S+ 0:00 osmo-mgw -c osmo-mgw-for-bsc.cfg 7653 pts/6 S+ 0:00 osmo-bsc -c osmo-bsc.cfg 7705 pts/3 S+ 0:00 osmo-msc -c osmo-msc.cfg 7760 pts/8 S+ 0:00 osmo-mgw -c osmo-mgw-for-msc.cfg 7785 pts/0 Sl+ 1:59 osmo-trx 7803 pts/7 S+ 0:08 osmo-bts-trx -c osmo-bts.cfg 17288 pts/1 S+ 0:00 osmo-hlr -l hlr.db -c osmo-hlr.cfg 17299 pts/5 S+ 0:02 osmo-stp -c osmo-stp.cfg Config files are deeply based in the nitb.tar in the wiki. I read in an email from December that osmo-bsc_mgcp is still required. Is that the case? Thanks, Rafael Diniz

2 2

testing osmo-bsc osmo-hlr osmo-msc
by Sandi Suhendro 22 Jan '18

22 Jan '18

Hello guys. Im testing the osmo-bsc osmo-hlr osmo-msc. I can make call but sometimes cannot, also same with text message. now the auto create subscriber not working which is Im looking and its very good and nice improovement. I ussually using osmo-sip-connector with openbsc and asterisk, but since I read that osmo-msc handling the features and also for future osmocom GSM stacks, so Im trying to migrate and test it. does my setting for the osmocom stacks is right with this? : osmo-bsc -c ~/osmo/osmo-bsc.cfg osmo-hlr -l hlr.db -c ~/osmo/osmo-hlr.cfg osmo-stp -c ~/osmo/osmo-stp.cfg osmo-mgw -c ~/osmo/osmo-mgw-for-msc.cfg osmo-mgw -c ~/osmo/osmo-mgw-for-bsc.cfg osmo-msc -c ~/osmo/osmo-msc.cfg DId I miss something? Im sure I miss something. :-) and how to connect osmo-msc with asterisk? Thanks. -- Best Regards, DUO

2 2

Build failed in Jenkins: Coverity-Upload » linux_amd64_debian8 #1736
by jenkins＠lists.osmocom.org 22 Jan '18

22 Jan '18

See <http://jenkins.osmocom.org/jenkins/job/Coverity-Upload/label=linux_amd64_de…> ------------------------------------------ [...truncated 2.16 MB...] CC osmo-bts-sysmo/sysmo_l1_fwd.o CXXLD libgprs.la CXXLD osmo-pcu CXXLD osmo-pcu-remote make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' Making all in examples make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' Making all in tests make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' CXX pcu_emu.o CXX test_replay_gprs_attach.o CC openbsc_clone.o CXX test_pdp_activation.o CXXLD emu/pcu_emu make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[1]: Nothing to be done for 'all-am'. make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' + make install Making install in include make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[2]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/pcu' /usr/bin/install -c -m 644 osmocom/pcu/pcuif_proto.h '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/pcu' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/include' Making install in src make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' /bin/sh ../libtool --mode=install /usr/bin/install -c osmo-pcu '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' libtool: install: /usr/bin/install -c osmo-pcu /home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin/osmo-pcu make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/src' Making install in examples make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[2]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' /usr/bin/install -c -m 644 osmo-pcu.cfg '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/examples' Making install in tests make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[2]: Nothing to be done for 'install-exec-am'. make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu/tests' make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[2]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/pkgconfig' /usr/bin/install -c -m 644 osmo-pcu.pc '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/pkgconfig' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-pcu' + popd ~/osmo-ci/coverity/source-Osmocom + build_osmobts + pushd osmo-bts ~/osmo-ci/coverity/source-Osmocom/osmo-bts ~/osmo-ci/coverity/source-Osmocom + do_build --enable-sysmocom-bts --enable-trx + autoreconf --install --force libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac:21: installing './compile' configure.ac:23: installing './config.guess' configure.ac:23: installing './config.sub' configure.ac:9: installing './install-sh' configure.ac:9: installing './missing' src/common/Makefile.am: installing './depcomp' src/osmo-bts-sysmo/Makefile.am:25: warning: bin_PROGRAMS was already defined in condition TRUE, which includes condition ENABLE_SYSMOBTS_CALIB ... src/osmo-bts-sysmo/Makefile.am:10: ... 'bin_PROGRAMS' previously defined here src/osmo-bts-sysmo/Makefile.am:12: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:12: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. src/osmo-bts-sysmo/Makefile.am:27: warning: source file 'misc/sysmobts-calib.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:27: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:27: warning: source file 'misc/sysmobts-layer1.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:27: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_misc.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_nl.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_2050.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_vty.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_nl.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_temp.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:31: warning: source file 'misc/sysmobts_mgr_calib.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:31: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:42: warning: source file 'misc/sysmobts_util.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:42: but option 'subdir-objects' is disabled src/osmo-bts-sysmo/Makefile.am:42: warning: source file 'misc/sysmobts_par.c' is in a subdirectory, src/osmo-bts-sysmo/Makefile.am:42: but option 'subdir-objects' is disabled tests/agch/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/agch/Makefile.am:7: but option 'subdir-objects' is disabled tests/cipher/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/cipher/Makefile.am:7: but option 'subdir-objects' is disabled tests/misc/Makefile.am:9: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/misc/Makefile.am:9: but option 'subdir-objects' is disabled tests/paging/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/paging/Makefile.am:7: but option 'subdir-objects' is disabled tests/power/Makefile.am:8: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/power/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/utils.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/l1_if.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/oml.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/l1_transp_hw.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/tch.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/calib_file.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/calib_fixup.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/misc/sysmobts_par.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/sysmobts/Makefile.am:8: warning: source file '$(top_srcdir)/src/osmo-bts-sysmo/eeprom.c' is in a subdirectory, tests/sysmobts/Makefile.am:8: but option 'subdir-objects' is disabled tests/tx_power/Makefile.am:7: warning: source file '$(srcdir)/../stubs.c' is in a subdirectory, tests/tx_power/Makefile.am:7: but option 'subdir-objects' is disabled + ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom --enable-sysmocom-bts --enable-trx checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking whether make sets $(MAKE)... (cached) yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for pkg-config... /usr/bin/pkg-config checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.20... yes checking for ANSI C header files... (cached) yes checking for LIBOSMOCORE... yes checking for LIBOSMOVTY... yes checking for LIBOSMOTRAU... yes checking for LIBOSMOGSM... yes checking for LIBOSMOCTRL... yes checking for LIBOSMOABIS... yes checking for LIBOSMOCODEC... yes checking for LIBOSMOCODING... yes checking for ORTP... yes checking whether to enable support for sysmobts calibration tool... no checking whether to enable support for sysmoBTS L1/PHY support... yes checking for sysmocom/femtobts/superfemto.h... no configure: error: sysmocom/femtobts/superfemto.h can not be found in . [WARNING] Build command ./build_Osmocom.sh exited with code 1. Please verify that the build completed successfully. Emitted 1913 C/C++ compilation units (100%) successfully 1913 C/C++ compilation units (100%) are ready for analysis For more details, please look at: /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt Build step 'Execute shell' marked build as failure

1 4

OSMO-TRX with OSMO-NITB and OSMO-BTS error
by Ronan Empig 22 Jan '18

22 Jan '18

Hi, I am using LimeSDR and I would like to setup a mini GSM base station. I am following this instructions: https://discourse.myriadrf.org/t/limesdr-osmo-trx-no-work/1938/27 However, I am getting trouble starting tranceiver: *TERMINAL 1:* ronan@ronan-MS-N014:~/Downloads$ osmo-nitb -c openbsc.cfg -l hlr.sqlite3 -P -C <0005> abis_nm.c:2800 (bts=0,trx=0) Changing adm. state Unlocked -> Unlocked [vty] <001e> telnet_interface.c:104 telnet at 127.0.0.1 4242 <0005> bsc_init.c:465 WARNING: You are running an 'accept-all' network on a BTS that is not barred. This configuration is likely to interfere with production GSM networks and should only be used in a RF shielded environment such as a faraday cage! <0020> input/ipaccess.c:848 enabling ipaccess BSC mode on 0.0.0.0 with OML 3002 and RSL 3003 TCP ports <0017> smpp_smsc.c:1001 SMPP at 0.0.0.0 2775 <0025> control_if.c:854 CTRL at 127.0.0.1 4249 DB: Database initialized. DB: Database prepared. <0020> input/ipa.c:263 accept()ed new link from 127.0.0.1 to port 3002 <0005> abis_nm.c:507 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. <0005> abis_nm.c:507 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:573 BTS0: ARI reported sw[0/2]: sysmobts is 0.7.0.20180115 <0005> abis_nm.c:446 BTS0 reported variant: omso-bts-trx <0005> abis_nm.c:468 BTS0 Attribute Manufacturer Dependent State is unreported <0005> abis_nm.c:573 BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown <0020> input/ipa.c:263 accept()ed new link from 127.0.0.1 to port 3003 <0004> bsc_init.c:311 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 514 using MCC=1 MNC=1 LAC=1 CID=0 BSIC=63 <0020> input/ipaccess.c:243 Sign link vanished, dead socket <0020> input/ipaccess.c:71 Forcing socket shutdown with no signal link set *TERMINAL 2:* ronan@ronan-MS-N014:~/Downloads$ osmo-bts-trx -c osmo-bts.cfg ((*)) | / \ OsmoBTS <0017> control_if.c:854 CTRL at 127.0.0.1 4238 <0010> telnet_interface.c:104 telnet at 127.0.0.1 4241 <0012> input/ipaccess.c:886 enabling ipaccess BTS mode, OML connecting to 127.0.0.1:3002 <000b> trx_if.c:599 Open transceiver for phy0.0 <0012> input/ipa.c:129 connection done. <0012> input/ipaccess.c:707 received ID get <0001> oml.c:229 O&M Get Attributes [0], Manufacturer Dependent State is unsupported by TRX. <0001> oml.c:680 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:680 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:1049 ADM state already was Unlocked <0012> input/ipa.c:129 connection done. <0012> input/ipaccess.c:707 received ID get <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <000b> trx_if.c:172 No response from transceiver for phy0.0 <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1108205-0=1108205 > 1! <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1108421-1108300=121 > 1! <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1108638-1108435=203 > 1! <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1108855-1108652=203 > 1! <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1109072-1108870=202 > 1! <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1109289-1109086=203 > 1! <0001> bts.c:210 Shutting down BTS 0, Reason No clock from osmo-trx <0007> l1sap.c:462 Invalid condition detected: Frame difference is 1112227-1109693=2534 > 1! <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> oml.c:1049 ADM state already was Unlocked <0001> bts.c:205 BTS is already being shutdown. <000b> trx_if.c:172 No response from transceiver for phy0.0 Shutdown timer expired ronan@ronan-MS-N014:~/Downloads$ *TERMINAL 3:* ronan@ronan-MS-N014:~/Downloads$ sudo osmo-trx -e [sudo] password for ronan: linux; GNU C++ version 5.4.0 20160609 <%2802%29%20016%200609>; Boost_105800; UHD_003.010.002.000-release Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in, but not supported by CPU Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 GSM Core Address.........127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ Enabled Reference............... Internal C0 Filler Table......... Disabled Multi-Carrier........... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 -- Make connection: 'LimeSDR-USB [USB 2.0] 9060B00470E28' -- Reference clock 30.720 MHz -- Device name: LimeSDR-USB -- Reference: 30.72 MHz -- Init LMS7002M(0) -- Ver=7, Rev=1, Mask=1 -- LMS7002M calibration values caching Disable -- Transceiver active with 1 channel(s) NOTICE 139639362156288 07:03:23.5 Transceiver.cpp:791:driveControl: Changing TSC from 0 to 7 NOTICE 139639362156288 07:03:23.5 Transceiver.cpp:244:start: Starting the transceiver ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=174420 time_end=171360 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=174420 time_end=171360 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=179520 time_end=176460 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=179520 time_end=176460 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=184620 time_end=181560 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=184620 time_end=181560 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=190740 time_end=186660 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=190740 time_end=186660 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=196860 time_end=192780 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=196860 time_end=192780 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=201960 time_end=198900 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=201960 time_end=198900 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=207060 time_end=204000 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=207060 time_end=204000 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=213180 time_end=209100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=213180 time_end=209100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=217260 time_end=215220 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=217260 time_end=215220 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=224400 time_end=219300 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=224400 time_end=219300 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=229500 time_end=226440 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=229500 time_end=226440 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=234600 time_end=231540 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=234600 time_end=231540 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=239700 time_end=236640 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=239700 time_end=236640 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=245820 time_end=241740 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=245820 time_end=241740 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=251940 time_end=247860 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=251940 time_end=247860 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=258060 time_end=253980 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=258060 time_end=253980 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=263160 time_end=260100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=263160 time_end=260100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=268260 time_end=265200 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=268260 time_end=265200 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=273360 time_end=270300 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=273360 time_end=270300 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=279480 time_end=275400 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=279480 time_end=275400 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=285600 time_end=281520 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=285600 time_end=281520 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=290700 time_end=287640 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=290700 time_end=287640 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=322320 time_end=292740 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=322320 time_end=292740 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=328440 time_end=324360 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=328440 time_end=324360 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=333540 time_end=330480 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=333540 time_end=330480 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=338640 time_end=335580 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=338640 time_end=335580 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=343740 time_end=340680 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=343740 time_end=340680 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=349860 time_end=345780 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=349860 time_end=345780 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=355980 time_end=351900 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=355980 time_end=351900 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=360060 time_end=358020 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=360060 time_end=358020 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=367200 time_end=362100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=367200 time_end=362100 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=372300 time_end=369240 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=372300 time_end=369240 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=378420 time_end=374340 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=378420 time_end=374340 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=383520 time_end=380460 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=383520 time_end=380460 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=389640 time_end=385560 ERR 139639362090752 07:03:24.4 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=389640 time_end=385560 ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:868:check_rx_md_err: Current time: 0, Previous time: 0.359668 ALERT 139639362090752 07:03:24.5 UHDDevice.cpp:868:check_rx_md_err: Current time: 0, Previous time: 0.359668 ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: Current time: 0.120517, Previous time: 0.359668 ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: Current time: 0.120517, Previous time: 0.359668 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=399840 time_end=391680 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=399840 time_end=391680 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=410040 time_end=408000 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=410040 time_end=408000 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=415140 time_end=412080 ERR 139639362090752 07:03:24.7 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=415140 time_end=412080 ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:867:check_rx_md_err: UHD: Loss of monotonic time ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: Current time: 0, Previous time: 0.383206 ALERT 139639362090752 07:03:24.7 UHDDevice.cpp:868:check_rx_md_err: Current time: 0, Previous time: 0.383206 ERR 139639362090752 07:03:24.8 UHDDevice.cpp:1383:write: Skipping buffer data: timestamp=440640 time_end=417180 ERR 139639362090752 07:03:24.8 UHDDevice.cpp:1383:write: Skipping

5 11

osmo-trx with USRP1 - libusrp vs. UHD
by Alexander Huemer 21 Jan '18

21 Jan '18

Hi! I played with osmo-trx today and tried to run it with a USRP1 that I have laying around, though to no avail. osmo-trx supports two kinds of devices, USRP1 via libusrp and UHD. libusrp was last included in gnuradio 3.4.2[1] from Dec 2013, it unsurprisingly does not build on a recent Linux distribution, due to API incompatibilities with boost. The USRP1 would theoretically be supported by UHD, though the device initialization code in osmo-trx explicitly treats it differently, see [2,3]. I found an old ML post[4] from 2015 that pretty much asks the same question but did not get an answer. Supposedly there is a simple reason why USRP1 is not driven via UHD in osmo-trx, but I don't know. Can somebody please enlighten me? Tom, maybe you? I would like to understand whether it is feasible to use an USRP1 with UHD for osmo-trx or one would have to go down the rabbit hole to build libusrp on a modern system. Kind regards, -Alex [1] https://gnuradio.org/releases/gnuradio/ [2] https://git.osmocom.org/osmo-trx/tree/Transceiver52M/UHDDevice.cpp#n512 [3] https://git.osmocom.org/osmo-trx/tree/Transceiver52M/USRPDevice.cpp [4] https://lists.osmocom.org/pipermail/openbsc/2015-January/000058.html

5 14

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2018