OpenBSC

openbsc@lists.osmocom.org

4315 discussions

[PATCH] logging: fix parsing of logging mask (-d DMI case)
by pablo＠gnumonks.org 11 Aug '11

11 Aug '11

From: Pablo Neira Ayuso <pablo(a)gnumonks.org> Without this patch, `-d DMI' enables logging for DMI and DMIB. Signed-off-by: Pablo Neira Ayuso <pablo(a)gnumonks.org> --- src/logging.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/logging.c b/src/logging.c index 11d63ac..e85e8fc 100644 --- a/src/logging.c +++ b/src/logging.c @@ -157,6 +157,11 @@ void log_parse_category_mask(struct log_target* target, const char *_mask) for (i = 0; i < osmo_log_info->num_cat; ++i) { char* colon = strstr(category_token, ","); int length = strlen(category_token); + int cat_length = strlen(osmo_log_info->cat[i].name); + + /* Use longest length not to match subocurrences. */ + if (cat_length > length) + length = cat_length; if (!osmo_log_info->cat[i].name) continue; -- 1.7.2.5

2 1

[PATCH] RSL: add timer for lchan activation/deactivation without BTS response
by Harald Welte 10 Aug '11

10 Aug '11

The timer callback will simply reset the lchan state to NONE in order to prevent channels getting stuck in 'activation requested' or 'deactivation requested' states. --- openbsc/src/libbsc/abis_rsl.c | 36 +++++++++++++++++++++++++++++++++++- 1 files changed, 35 insertions(+), 1 deletions(-) diff --git a/openbsc/src/libbsc/abis_rsl.c b/openbsc/src/libbsc/abis_rsl.c index f20b4f2..239c8c8 100644 --- a/openbsc/src/libbsc/abis_rsl.c +++ b/openbsc/src/libbsc/abis_rsl.c @@ -178,6 +178,27 @@ static void print_rsl_cause(int lvl, const uint8_t *cause_v, uint8_t cause_len) LOGPC(DRSL, lvl, "%02x ", cause_v[i]); } +static void lchan_act_tmr_cb(void *data) +{ + struct gsm_lchan *lchan = data; + + LOGP(DRSL, LOGL_NOTICE, "%s Timeout during activation!\n", + gsm_lchan_name(lchan)); + + lchan->state = LCHAN_S_NONE; +} + +static void lchan_deact_tmr_cb(void *data) +{ + struct gsm_lchan *lchan = data; + + LOGP(DRSL, LOGL_NOTICE, "%s Timeout during deactivation!\n", + gsm_lchan_name(lchan)); + + lchan->state = LCHAN_S_NONE; +} + + /* Send a BCCH_INFO message as per Chapter 8.5.1 */ int rsl_bcch_info(struct gsm_bts_trx *trx, uint8_t type, const uint8_t *data, int len) @@ -609,6 +630,11 @@ static int rsl_rf_chan_release(struct gsm_lchan *lchan, int error) msg->trx->bts->network->T3111 + 2, 0); } + /* Start another timer or assume the BTS sends a ACK/NACK? */ + lchan->act_timer.cb = lchan_deact_tmr_cb; + lchan->act_timer.data = lchan; + osmo_timer_schedule(&lchan->act_timer, 4, 0); + rc = abis_rsl_sendmsg(msg); /* BTS will respond by RF CHAN REL ACK */ @@ -626,6 +652,8 @@ static int rsl_rx_rf_chan_rel_ack(struct gsm_lchan *lchan) DEBUGP(DRSL, "%s RF CHANNEL RELEASE ACK\n", gsm_lchan_name(lchan)); + osmo_timer_del(&lchan->act_timer); + if (lchan->state != LCHAN_S_REL_REQ && lchan->state != LCHAN_S_REL_ERR) LOGP(DRSL, LOGL_NOTICE, "%s CHAN REL ACK but state %s\n", gsm_lchan_name(lchan), @@ -791,6 +819,8 @@ static int rsl_rx_chan_act_ack(struct msgb *msg) if (rslh->ie_chan != RSL_IE_CHAN_NR) return -EINVAL; + osmo_timer_del(&msg->lchan->act_timer); + if (msg->lchan->state != LCHAN_S_ACT_REQ) LOGP(DRSL, LOGL_NOTICE, "%s CHAN ACT ACK, but state %s\n", gsm_lchan_name(msg->lchan), @@ -1257,7 +1287,11 @@ static int rsl_rx_chan_rqd(struct msgb *msg) lchan->rsl_cmode = RSL_CMOD_SPD_SIGN; lchan->tch_mode = GSM48_CMODE_SIGN; - /* FIXME: Start another timer or assume the BTS sends a ACK/NACK? */ + /* Start another timer or assume the BTS sends a ACK/NACK? */ + lchan->act_timer.cb = lchan_act_tmr_cb; + lchan->act_timer.data = lchan; + osmo_timer_schedule(&lchan->act_timer, 4, 0); + rsl_chan_activate_lchan(lchan, 0x00, rqd_ta, 0); DEBUGP(DRSL, "%s Activating ARFCN(%u) SS(%u) lctype %s " -- 1.7.5.4

1 1

[PATCH 0/2] couple of openbsc fixes
by pablo＠gnumonks.org 10 Aug '11

10 Aug '11

From: Pablo Neira Ayuso <pablo(a)gnumonks.org> Hi Harald, These are a couple of fixes that we have applied to openBSC in the CCC camp. Daniel's fixes a crash, mine fixes one malformed TCH frame issue which was the cause of quite often unexpected closures of MNCC <-> LCR connections. You can find them in the fixes branch. Please, merge them. Daniel Willmann (1): libbsc: Don't free secondary lchan if it is NULL. Pablo Neira Ayuso (1): trau: fix wrong message size for GSM_TCHF_FRAME passed to MNCC openbsc/src/libbsc/bsc_api.c | 6 +++++- openbsc/src/libtrau/trau_mux.c | 1 + 2 files changed, 6 insertions(+), 1 deletions(-) -- 1.7.2.5

2 3

[PATCH 0/3] updates for Nokia support
by pablo＠gnumonks.org 10 Aug '11

10 Aug '11

From: Pablo Neira Ayuso <pablo(a)gnumonks.org> Hi Harald, This patchset contains two updates for the Nokia support in the following scenario: the BSC stops after having configured the BTS, then the BTS is launched again but LAPD reports unknown TEI. To fix this, we report to the E1 driver about unknown TEI so it can resend the SABM message. ... and one patch from Daniel who thinks that we have to promote some logs messages from debugging to error. You can find them in the nokia-pablo branch. We are using them in the camp. Please, merge them. Daniel Willmann (1): mncc: promote log level from debug to errors Pablo Neira Ayuso (2): LAPD: Propagate lapd_receive() errors to the E1 driver NOKIA: Resend SABM on unknown TEI from LAPD openbsc/include/openbsc/signal.h | 1 + openbsc/src/libabis/e1_input.c | 1 + openbsc/src/libabis/input/dahdi.c | 20 ++++++++++++++++---- openbsc/src/libabis/input/lapd.c | 14 ++++++++++++-- openbsc/src/libabis/input/lapd.h | 16 ++++++++++++++-- openbsc/src/libbsc/bts_nokia_site.c | 9 ++++++++- openbsc/src/libmsc/gsm_04_08.c | 10 +++++----- 7 files changed, 57 insertions(+), 14 deletions(-)

2 4

Sudden connection drop
by Seungju Kim 09 Aug '11

09 Aug '11

Hello, I have been testing the data setup and I found another issue. I couldn't really find out exactly what causes this. This happens rarely but it does happen time to time. I am attaching the log file of the issue. I looked through the log but I could not find anything else interesting in the log. http://pastebin.com/tQ0mcyeu This is the log file of the issue. I'll be glad to hear any thoughts about this. Envoyé de mon iPhone

1 0

what type of RRLP protocol supported in OpenBSC
by Akib Sayyed 07 Aug '11

07 Aug '11

OpenBSC support RRLP protocol but in RRLP we have 2 modes E-OTD A-GPS what modes are supported?? if E-OTD is supported can we use OpenBSC to triangulate normal Cellphones like Motorola C123 ?? -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

2 1

GPRS issue after idle
by Seungju Kim 06 Aug '11

06 Aug '11

Hello,I got everything up and running. Including EDGE data. The throughput of the data from the osmo-sgsn is pretty good. But recently I have spotted a problem with the SGSN. The sgsn loses the phones SNDCP entity after idling or making a phone call. Please see the log from the sgsn http://pastebin.com/2W9dZdvW

2 7

OpenBSC + LCR
by Gus Bourg 05 Aug '11

05 Aug '11

Hello all, I'm attempting to make my OpenBSC setup work with LCR and Asterisk. I'm not sure if the problem that I'm running into is specific to the nature of my setup (running a Nokia BTS) or is a misconfiguration issue with LCR. When I run without LCR and Asterisk I can call between phones, SMS etc. With LCR I have no such luck. I can place a call into the mobile from Asterisk, and the mobile rings, but when I answer the call hangs up. A pastebin of the LCR log can be found here: http://pastebin.com/DbM3TfFp Any insight into the cause would be much appreciated. :) Thanks, Gus

1 0

[PATCH] GPRS: Fix the parsing/interpretation of the PDP CTX status IE
by Harald Welte 05 Aug '11

05 Aug '11

The byte ordering is a bit odd: The least significant byte is ahead of the most significant byte, different from everything else in GSM that seems to be big-endian. Thanks to Seungju Kim <admin(a)manateeshome.com> for repoerting the bug. --- openbsc/src/gprs/gprs_gmm.c | 24 ++++++++++++++++-------- 1 files changed, 19 insertions(+), 11 deletions(-) diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index 098e4c2..c9fe517 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -867,7 +867,7 @@ static int gsm48_tx_gmm_ra_upd_rej(struct msgb *old_msg, uint8_t cause) } static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx, - uint16_t pdp_status) + uint8_t *pdp_status) { struct sgsn_pdp_ctx *pdp, *pdp2; /* 24.008 4.7.5.1.3: If the PDP context status information element is @@ -878,11 +878,20 @@ static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx, * being in state PDP-INACTIVE. */ llist_for_each_entry_safe(pdp, pdp2, &mmctx->pdp_list, list) { - if (!(pdp_status & (1 << pdp->nsapi))) { - LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " - "due to PDP CTX STATUS IE= 0x%04x\n", - pdp->nsapi, pdp_status); - sgsn_delete_pdp_ctx(pdp); + if (pdp->nsapi < 8) { + if (!(pdp_status[0] & (1 << pdp->nsapi))) { + LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " + "due to PDP CTX STATUS IE= 0x%02x%02x\n", + pdp->nsapi, pdp_status[1], pdp_status[0]); + sgsn_delete_pdp_ctx(pdp); + } + } else { + if (!(pdp_status[1] & (1 << (pdp->nsapi - 8)))) { + LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " + "due to PDP CTX STATUS IE= 0x%02x%02x\n", + pdp->nsapi, pdp_status[1], pdp_status[0]); + sgsn_delete_pdp_ctx(pdp); + } } } } @@ -975,8 +984,7 @@ static int gsm48_rx_gmm_ra_upd_req(struct sgsn_mm_ctx *mmctx, struct msgb *msg, /* Look at PDP Context Status IE and see if MS's view of * activated/deactivated NSAPIs agrees with our view */ if (TLVP_PRESENT(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)) { - uint16_t pdp_status = ntohs(*(uint16_t *) - TLVP_VAL(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)); + uint8_t *pdp_status = TLVP_VAL(&tp, GSM48_IE_GMM_PDP_CTX_STATUS); process_ms_ctx_status(mmctx, pdp_status); } -- 1.7.5.4 --CE+1k2dSO48ffgeK--

1 0

[PATCH] GPRS: Fix the byte ordering of the PDP context status IE
by Harald Welte 04 Aug '11

04 Aug '11

It seems that 24.008 Section 10.5.7.1 specifies the IE to be encoded in little endian... --- openbsc/src/gprs/gprs_gmm.c | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index 098e4c2..f83219f 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -870,6 +870,7 @@ static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx, uint16_t pdp_status) { struct sgsn_pdp_ctx *pdp, *pdp2; + uint16_t pdp_status_reordered; /* 24.008 4.7.5.1.3: If the PDP context status information element is * included in ROUTING AREA UPDATE REQUEST message, then the network * shall deactivate all those PDP contexts locally (without peer to @@ -877,8 +878,13 @@ static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx, * state PDP-INACTIVE on network side but are indicated by the MS as * being in state PDP-INACTIVE. */ + /* 24.008 10.5.7.1 indicates that the byte ordering is in fact + * little endian, i.e. the first octet contains NSAPI0..7 and + * the second payload octet NSAPI8..15 */ + pdp_status_reordered = (pdp_status & 0xff << 8) || (pdp_status >> 8); + llist_for_each_entry_safe(pdp, pdp2, &mmctx->pdp_list, list) { - if (!(pdp_status & (1 << pdp->nsapi))) { + if (!(pdp_status_reordered & (1 << pdp->nsapi))) { LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " "due to PDP CTX STATUS IE= 0x%04x\n", pdp->nsapi, pdp_status); @@ -977,6 +983,10 @@ static int gsm48_rx_gmm_ra_upd_req(struct sgsn_mm_ctx *mmctx, struct msgb *msg, if (TLVP_PRESENT(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)) { uint16_t pdp_status = ntohs(*(uint16_t *) TLVP_VAL(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)); + /* pdp_status is now in big endian, which is the wrong + * order. the wire encoding is little endian! We cannot + * simply drop the ntohs() above, as we migh be running + * on a big endian machine. */ process_ms_ctx_status(mmctx, pdp_status); } -- 1.7.5.4 --iq/fWD14IMVFWBCD--

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC