- OpenBSC - lists.osmocom.org

Fail messages while applying patch
by ನಾಗೇಶ್ 23 Nov '09

23 Nov '09

Hi, When applying patch (as described in Debian_Getting_Started page), I get messages as shown in screenshot. What do these mean ? N.

3 2

GSM Standard for CDR ?
by ನಾಗೇಶ್ 22 Nov '09

22 Nov '09

Hi, Is there a GSM standard for Call Detail Record (CDR) ? I did Google for it, but I guess I am not using the right search terms. N.

1 0

nanoBTS without EFR support ?
by Sylvain Munaut 22 Nov '09

22 Nov '09

Hi, I was wondering if anyone heard of a nanoBTS without EFR support ? I have one here that responds with BIND_NACK if the codec is EFR but works ok if I set V1 Sylvain

3 3

[PATCH] Release lchan directly when refcount drops to zero
by Holger Freyther 22 Nov '09

22 Nov '09

Hi all, I have written this small patch yesterday. It is removing the "auto release" after timeout from lchan and will directly release the channel ones the ref count drops to zero. This means that any use of the lchan after a put_lchan is illegal (the code using a timeout used to workaround this issue). I have changed three call sites to follow this convention, I have added a BUG_ON into the abis_rsl method. From a quick test (Location Updating Request and a call) the BUG_ON in the abis_rsl.c is hit by: - The lchan release code (okay... a false warning and avoided by increasing use_count and decreasing it...) - CM Service Request Ack and such is sent without anyone holding a reference to it. I think this warning is safe to ignore for now as no one has simply claimed the channel. I plan to fix this in January/February when moving our MSC code over to the On Waves BSC abstraction. The benefit of this change is that we free our channels a lot earlier. I think this change would be beneficial for the 26C3 and I would like to hear opinions and see some testing with it. regards z.

3 5

[RFC] nanoBTS startup sequence (problems on coldstart)
by Holger Freyther 22 Nov '09

22 Nov '09

Hi Harald, I have one problem with the BTS on cold start. OpenBSC is sending the RSL connect, Radio Carrier/Baseband attributes too early and we are receiving NACKs from the BTS and the RSL link is never established. The first question is if others have seen this problem? I have solved the problem my moving the OP start/set attributes/RSL connect of the RC and Baseband out of the state change code into the "Software Activated Report". Doing a quick check it seems to still work and solve my cold start problem. Do you think this is a legitimate workaround for the problem right now? In the future we probably should attempt to have a better state machine, report errors, retry and such things... regards holger

5 8

Redudant channel assignement
by 246tnt＠gmail.com 21 Nov '09

21 Nov '09

When making a call from my test phone (a T610 here), I see the BSC assigning more than one channel ... For example, with a MO call : <0010> abis_rsl.c:1182 Activating ARFCN(514) TS(2) SS(0) lctype TCH/F chan_nr=0x0a r=OTHER ra=0xe7 <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=2) chan_nr=0x0a CHANNEL ACTIVATE ACK <0010> abis_rsl.c:1182 Activating ARFCN(514) TS(3) SS(0) lctype TCH/F chan_nr=0x0b r=OTHER ra=0xf8 <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=3) chan_nr=0x0b CHANNEL ACTIVATE ACK <0010> abis_rsl.c:1182 Activating ARFCN(514) TS(4) SS(0) lctype TCH/F chan_nr=0x0c r=OTHER ra=0xe3 <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=4) chan_nr=0x0c CHANNEL ACTIVATE ACK <0001> abis_rsl.c:1286 channel=(bts=0,trx=0,ts=4) chan_nr=0x0c sapi=0 ESTABLISH INDICATION <0004> gsm_04_08.c:1280 <- CM SERVICE REQUEST serv_type=0x01 mi_type=0x04 M(874908265) ... <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=4) chan_nr=0x0c CHANNEL MODE MODIFY ACK <0010> abis_rsl.c:1526 channel=(bts=0,trx=0,ts=4) chan_nr=0x0c IPAC_DISCONNECT_IND CAUSE=0x0f(Normal event, unspecified) <0001> abis_rsl.c:1286 channel=(bts=0,trx=0,ts=4) chan_nr=0x0c sapi=0 RELEASE INDICATION <0010> abis_rsl.c:721 RF Channel Release CMD channel=(bts=0,trx=0,ts=4) chan_nr=0x0c <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=4) chan_nr=0x0c RF CHANNEL RELEASE ACK <0002> gsm_subscriber_base.c:150 subscr 201 usage decreased usage to: 0 <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=2) chan_nr=0x0a CONNECTION FAIL: CAUSE=0x01(Radio Link Failure) RELEASING. <0010> abis_rsl.c:721 RF Channel Release CMD channel=(bts=0,trx=0,ts=2) chan_nr=0x0a <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=2) chan_nr=0x0a RF CHANNEL RELEASE ACK <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=3) chan_nr=0x0b CONNECTION FAIL: CAUSE=0x01(Radio Link Failure) RELEASING. <0010> abis_rsl.c:721 RF Channel Release CMD channel=(bts=0,trx=0,ts=3) chan_nr=0x0b <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=3) chan_nr=0x0b RF CHANNEL RELEASE ACK <0010> abis_rsl.c:721 RF Channel Release CMD channel=(bts=0,trx=0,ts=2) chan_nr=0x0a <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=2) chan_nr=0x0a RF CHANNEL RELEASE ACK <0010> abis_rsl.c:721 RF Channel Release CMD channel=(bts=0,trx=0,ts=3) chan_nr=0x0b <0010> abis_rsl.c:1001 channel=(bts=0,trx=0,ts=3) chan_nr=0x0b RF CHANNEL RELEASE ACK As you see, there was 3 TCH assigned ... (and of course two of those ultimately failed with Radio Link Failure ...). Is anyone else seeing this ? Sylvain

3 4

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

20 Nov '09

this patch fixes (not all) compiler warnings. diff --git a/openbsc/include/openbsc/talloc.h b/openbsc/include/openbsc/talloc.h index f7f7643..cd7ca17 100644 --- a/openbsc/include/openbsc/talloc.h +++ b/openbsc/include/openbsc/talloc.h @@ -189,4 +189,8 @@ char *talloc_asprintf_append_buffer(char *s, const char *fmt, ...) PRINTF_ATTRIB void talloc_set_abort_fn(void (*abort_fn)(const char *reason)); +void talloc_ctx_init(void); +void on_dso_load_token(void); +void on_dso_load_rrlp(void); + #endif 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); switch (foh->obj_class) { diff --git a/openbsc/src/db.c b/openbsc/src/db.c index b86348c..59dac2c 100644 --- a/openbsc/src/db.c +++ b/openbsc/src/db.c @@ -265,7 +265,7 @@ static int get_equipment_by_subscr(struct gsm_subscriber *subscr) { dbi_result result; const char *string; - unsigned int cm1; + unsigned char cm1; const unsigned char *cm2, *cm3; struct gsm_equipment *equip = &subscr->equipment; diff --git a/openbsc/src/rtp_proxy.c b/openbsc/src/rtp_proxy.c index b92526e..42c2d15 100644 --- a/openbsc/src/rtp_proxy.c +++ b/openbsc/src/rtp_proxy.c @@ -676,7 +676,7 @@ int rtp_socket_proxy(struct rtp_socket *this, struct rtp_socket *other) int rtp_socket_upstream(struct rtp_socket *this, struct gsm_network *net, u_int32_t callref) { DEBUGP(DMUX, "rtp_socket_proxy(this=%p, callref=%lu)\n", - this, callref); + this, (unsigned long)callref); if (callref) { this->rx_action = RTP_RECV_UPSTREAM; diff --git a/openbsc/src/vty_interface.c b/openbsc/src/vty_interface.c index d623b3d..e3de43a 100644 --- a/openbsc/src/vty_interface.c +++ b/openbsc/src/vty_interface.c @@ -36,6 +36,8 @@ #include <openbsc/db.h> #include <openbsc/talloc.h> +int bsc_vty_init_extra(struct gsm_network *net); + static struct gsm_network *gsmnet; struct cmd_node net_node = { @@ -624,7 +626,7 @@ DEFUN(show_e1ts, "show e1_timeslot [line_nr] [ts_nr]", SHOW_STR "Display information about a E1 timeslot\n") { - struct e1inp_line *line; + struct e1inp_line *line = NULL; struct e1inp_ts *ts; int ts_nr; @@ -638,12 +640,14 @@ DEFUN(show_e1ts, return CMD_SUCCESS; } if (argc >= 1) { - int num = atoi(argv[0]); + int num = atoi(argv[0]), found = 0; llist_for_each_entry(line, &e1inp_line_list, list) { - if (line->num == num) + if (line->num == num) { + found = 1; break; + } } - if (!line || line->num != num) { + if (found < 0) { vty_out(vty, "E1 line %s is invalid%s", argv[0], VTY_NEWLINE); return CMD_WARNING; diff --git a/openbsc/tests/sms/sms_test.c b/openbsc/tests/sms/sms_test.c index fa09636..2ce2cc6 100644 --- a/openbsc/tests/sms/sms_test.c +++ b/openbsc/tests/sms/sms_test.c @@ -24,6 +24,7 @@ #include <sys/types.h> #include <openbsc/debug.h> #include <openbsc/msgb.h> +#include <openbsc/gsm_data.h> #include <openbsc/gsm_utils.h> int main(int argc, char** argv) diff --git a/openbsc/tests/timer/timer_test.c b/openbsc/tests/timer/timer_test.c index 26fcbc9..1515652 100644 --- a/openbsc/tests/timer/timer_test.c +++ b/openbsc/tests/timer/timer_test.c @@ -26,17 +26,17 @@ static void timer_fired(unsigned long data); static struct timer_list timer_one = { - .cb = timer_fired, + .cb = (void *)timer_fired, .data = (void*)1, }; static struct timer_list timer_two = { - .cb = timer_fired, + .cb = (void *)timer_fired, .data = (void*)2, }; static struct timer_list timer_three = { - .cb = timer_fired, + .cb = (void *)timer_fired, .data = (void*)3, };

3 2

patch: fix of double free bug
by Andreas.Eversberg 20 Nov '09

20 Nov '09

this patch fixes double free of paging request. the function paging_T3113_expired() must call paging_remove_request() first. then the cbfn may be called. the cbfn function cannot eventually remove the paging request again, because it is not in the list anymore. the result of paging timeout was a crash. diff --git a/openbsc/src/paging.c b/openbsc/src/paging.c index 5a9643c..164a08b 100644 --- a/openbsc/src/paging.c +++ b/openbsc/src/paging.c @@ -224,11 +243,13 @@ static void paging_T3113_expired(void *data) sig_data.bts = req->bts; sig_data.lchan = NULL; + /* must be destroyed before calling cbfn, to prevent double free */ + paging_remove_request(&req->bts->paging, req); + dispatch_signal(SS_PAGING, S_PAGING_COMPLETED, &sig_data); if (req->cbfn) req->cbfn(GSM_HOOK_RR_PAGING, GSM_PAGING_EXPIRED, NULL, NULL, req->cbfn_param); - paging_remove_request(&req->bts->paging, req); } static int _paging_request(struct gsm_bts *bts, struct gsm_subscriber *subscr,

3 2

[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