OpenBSC November 2009

openbsc@lists.osmocom.org

18 participants
54 discussions

[PATCH 1/4] [gsm_04_08_gprs] Display the identity type for GMM IDENTITY REQUEST
by Sylvain Munaut 20 Nov '09

20 Nov '09

From: Sylvain Munaut <tnt(a)246tNt.com> Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com> --- openbsc/src/gsm_04_08_gprs.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/openbsc/src/gsm_04_08_gprs.c b/openbsc/src/gsm_04_08_gprs.c index cac28d7..dc1c69f 100644 --- a/openbsc/src/gsm_04_08_gprs.c +++ b/openbsc/src/gsm_04_08_gprs.c @@ -220,7 +220,7 @@ static int gsm48_tx_gmm_id_req(struct msgb *old_msg, u_int8_t id_type) struct msgb *msg = gsm48_msgb_alloc(); struct gsm48_hdr *gh; - DEBUGP(DMM, "-> GPRS IDENTITY REQUEST\n"); + DEBUGP(DMM, "-> GPRS IDENTITY REQUEST: mi_type=%02x\n", id_type); msg->tlli = old_msg->tlli; msg->trx = old_msg->trx; -- 1.6.5.1

2 9

Improper dispatch of MNCC_REL_CNF : callref cleared in gsm48_cc_tx_release ?
by Sylvain Munaut 20 Nov '09

20 Nov '09

Hi, Does anyone see a reason why callref would be cleared in gsm48_cc_tx_release ? That prevents proper dispatch of the subsequent REL_CNF (since trans->callref is now 0) and I don't really see what was the intent in putting it there ? Sylvain

1 0

patch: callref bugfix
by Andreas.Eversberg 18 Nov '09

18 Nov '09

this patch will correct some callref behavior. if a message with an unknown callref is received, a release is sent to the other layer. if a release with an unknown callref is received, it is ignored. no message is sent, if the callref is already gone. diff --git a/openbsc/src/gsm_04_08.c b/openbsc/src/gsm_04_08.c index d6e161a..3f12546 100644 --- a/openbsc/src/gsm_04_08.c +++ b/openbsc/src/gsm_04_08.c @@ -1705,6 +1705,10 @@ static int mncc_recvmsg(struct gsm_network *net, struct gsm_trans *trans, { struct msgb *msg; + /* don't send message, if call is not associated anymore */ + if (!mncc->callref) + return 0; + if (trans) if (trans->lchan) DEBUGP(DCC, "(bts %d trx %d ts %d ti %x sub %s) " @@ -3242,10 +3246,12 @@ int mncc_send(struct gsm_network *net, int msg_type, void *arg) if (!trans) { struct gsm_subscriber *subscr; + if (msg_type == MNCC_REL_REQ) + return 0; /* drop */ if (msg_type != MNCC_SETUP_REQ) { DEBUGP(DCC, "(bts - trx - ts - ti -- sub %s) " "Received '%s' from MNCC with " - "unknown callref %d\n", data->called.number, + "unknown callref %x\n", data->called.number, get_mncc_name(msg_type), data->callref); /* Invalid call reference */ return mncc_release_ind(net, NULL, data->callref, diff --git a/openbsc/src/mncc.c b/openbsc/src/mncc.c index f62541c..1874750 100644 --- a/openbsc/src/mncc.c +++ b/openbsc/src/mncc.c @@ -301,8 +301,20 @@ int mncc_recv(struct gsm_network *net, int msg_type, void *arg) /* create callref, if setup is received */ if (!call) { - if (msg_type != MNCC_SETUP_IND) + if (msg_type == MNCC_REL_IND) return 0; /* drop */ + if (msg_type != MNCC_SETUP_IND) { + struct gsm_mncc rel; + + DEBUGP(DMNCC, "(call %x) Rejecting message %s with unknown ref.\n", + callref, get_mncc_name(msg_type)); + memset(&rel, 0, sizeof(struct gsm_mncc)); + rel.callref = callref; + mncc_set_cause(&rel, GSM48_CAUSE_LOC_PRN_S_LU, + GSM48_CC_CAUSE_INVAL_TRANS_ID); + mncc_send(net, MNCC_REL_REQ, &rel); + return 0; + } /* create call */ if (!(call = talloc_zero(tall_call_ctx, struct gsm_call))) { struct gsm_mncc rel;

2 1

AW: [RFC] nanoBTS startup sequence (problems on coldstart)
by Andreas.Eversberg 18 Nov '09

18 Nov '09

Me2 It is always the case with BS11: - boot BS11 (until finished) - run bsc_hack (not working) - run bsc_hack again (working) -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Bjoern Heller Gesendet: Mittwoch, 18. November 2009 12:22 An: Holger Freyther Cc: openbsc(a)lists.gnumonks.org Betreff: Re: [RFC] nanoBTS startup sequence (problems on coldstart) Me2. Need to restart bsc_hack the first time after nanobts coldboot. Best Regards Björn Heller

1 0

[PATCH] Implement TP-VPF-ENHANCED
by Steffen 'stefreak' Neubauer 18 Nov '09

18 Nov '09

Hello :) Now I've implemented the TP-VPF-ENHANCED. To achieve that I added some goto-stuff - i hope that's ok. I think it makes sense here. It's again untested, but compiles fine. I'm working at the moment on a way to test SMS-PDU decoding. If that's easier you can simply merge the branch tp-vp from git://github.com/stefreak/openbsc.git :) The patch is attached. Greetings, Steffen

4 8

Re: nanoBTS transmit power
by Dieter Spaar 18 Nov '09

18 Nov '09

Hello Holger, On Sat, 14 Nov 2009 19:45:43 +0100, "Holger Freyther" <zecke(a)selfish.org> wrote: > > Good question. I think Dieter knows this best. We have two options that > influence the transmit power. One is the power a mobile station should use to > communicate with us ("ms max power") and then something I don't know > ("max_power_red") but we do have links to the spec in the vty_interface.c "max_power_red" is the power used by the BTS, it reduces the maximum power by a certain amount. Those are the results from a measurement I already posted a while ago to the list: nanoBTS 1800, ARCN 840, no voice/data traffic: NM_ATT_RF_MAXPOWR_R RF output 0 20 dBm 1 18 dBm 2 16 dBm 4 12 dBm 8 4.4 dBm 9 2.0 dBm 10 0.4 dBm 11 -1.6 dBm 12 -3.6 dBm Please be aware that the value "max_power_red" from the config file is divided by two to get NM_ATT_RF_MAXPOWR_R ("max_power_red" is the actual reduction in dB). Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

AW: patch: fix of compiler warnings
by Andreas.Eversberg 17 Nov '09

17 Nov '09

i am not sure, if the variables bts and trx will be used in the future, so i left them as comments. -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther Gesendet: Dienstag, 17. November 2009 10:20 An: openbsc(a)lists.gnumonks.org Betreff: Re: patch: fix of compiler warnings On Monday 16 November 2009 18:52:32 Andreas.Eversberg wrote: > diff --git a/openbsc/src/bsc_init.c b/openbsc/src/bsc_init.c > index 815fe2b..3b451b1 100644 > --- a/openbsc/src/bsc_init.c > +++ b/openbsc/src/bsc_init.c > @@ -433,8 +433,8 @@ int nm_state_event(enum nm_evt evt, u_int8_t > obj_class, void *obj, > static int sw_activ_rep(struct msgb *mb) > { > struct abis_om_fom_hdr *foh = msgb_l3(mb); > - struct gsm_bts *bts = mb->trx->bts; > - struct gsm_bts_trx *trx = gsm_bts_trx_num(bts, > foh->obj_inst.trx_nr); > +// struct gsm_bts *bts = mb->trx->bts; > +// struct gsm_bts_trx *trx = gsm_bts_trx_num(bts, > foh->obj_inst.trx_nr); was this intentional? Is the warning that these are unused? In this case we will just nuke the variable declaration.

1 0

patch: fix of paging result issue
by Andreas.Eversberg 17 Nov '09

17 Nov '09

hi, one of my nokia phones 6310i: V 04.20 04-03-02 NPE-4 (c) NPM. when the subscriber is paged, the phone will answer with "CHREQ_T_PAG_R_ANY" value (ra=0x83). because the phone does not tell use what it wants, i must assume that there may be a need for a traffic channel. without this patch, the call will be made with wrong channel type: <0200> paging.c:113 Going to send paging commands: imsi: '262XXXXXXXXXXX' tmsi: '0x3044ea7a' <0010> abis_rsl.c:1179 Activating ARFCN(121) TS(0) SS(0) lctype SDCCH chan_nr=0x20 r=PAGING ra=0x83 can we figure out which subscriber did the channel request? if so, we can check what channel type is required. (we can look through the transactions and select the required channel type. if a transaction with higher rate is paging, we can assign this channel type.) any ideas? regards, andreas diff --git a/openbsc/src/gsm_04_08_utils.c b/openbsc/src/gsm_04_08_utils.c index 6ffb109..2c30d13 100644 --- a/openbsc/src/gsm_04_08_utils.c +++ b/openbsc/src/gsm_04_08_utils.c @@ -283,7 +283,7 @@ static const enum gsm_chan_t ctype_by_chreq[] = { [CHREQ_T_VOICE_CALL_TCH_H] = GSM_LCHAN_TCH_H, [CHREQ_T_DATA_CALL_TCH_H] = GSM_LCHAN_TCH_H, [CHREQ_T_LOCATION_UPD] = GSM_LCHAN_SDCCH, - [CHREQ_T_PAG_R_ANY] = GSM_LCHAN_SDCCH, + [CHREQ_T_PAG_R_ANY] = GSM_LCHAN_TCH_F, [CHREQ_T_PAG_R_TCH_F] = GSM_LCHAN_TCH_F, [CHREQ_T_PAG_R_TCH_FH] = GSM_LCHAN_TCH_F, };

2 1

patch: fix of configuration file generation
by Andreas.Eversberg 17 Nov '09

17 Nov '09

this patches fixes the generation of the config file. after saving of configuration, no location update was possible anymore. it is self explaining... diff --git a/openbsc/src/vty_interface.c b/openbsc/src/vty_interface.c index 9aa9706..c6e60c0 100644 --- a/openbsc/src/vty_interface.c +++ b/openbsc/src/vty_interface.c @@ -784,7 +784,7 @@ DEFUN(cfg_net_encryption, "encryption a5 (0|1|2)", "Enable or disable encryption (A5) for this network\n") { - gsmnet->auth_policy = atoi(argv[0]); + gsmnet->a5_encryption = atoi(argv[0]); return CMD_SUCCESS; }

2 1

tests with subscriber usage
by Andreas.Eversberg 17 Nov '09

17 Nov '09

hi, i did may tests with the "holger/subscr-ref-handling" branch. i had no subscriber usage leak within may hours of testing. about hunded calls were made with many out-of-range failures, hold/retrieve, and battery removal during call. at the end, all subscribers usage returned back to 0. i did not test SMS, just location updates and voice calls. regards, andreas

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2009