OpenBSC

openbsc@lists.osmocom.org

4315 discussions

Re: NEWSDR'13 Workshop / OpenBSC / OsmocomBB (Harald Welte)
by Robin Coxe 30 Mar '13

30 Mar '13

I've never heard of either this workshop or the SDR Boston Listserv and don't know any of the people on the organizing committee. One of the moderators of the mailing list, which I just joined, is an EE professor at Northeastern University, Miriam Lesser, who is well known in the FPGA community. Since I'm based in Boston, I'll plan to attend provided I'm not traveling for my day job. If anyone would like to participate by proxy, please let me know. [If I can get my act together in time, I may demo OpenBTS ported to a Xilinx Zynq using the new Close-Haul GAPfiller RF front end.] -Robin

1 0

Problem with flashing BS-11
by Sergey V. Efimov 27 Mar '13

27 Mar '13

Hello All, Did anyone ever experienced such strange problems when downloading firmware into BS-11? === $ bs11_config bs11_config (C) 2009-2010 by Harald Welte and Dieter Spaar This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY LMT LOGON: ACK PHASE: 1 Software required Abis-link: Down <0005> abis_nm.c:1196 Software Load (BTS 0, File "BTSBMC76.SWI") Software Load Initiate ACK === ...and then nothing happens for hours. I.e., no progress percentage, segment acknowledges, etc. Does it mean that BTS is broken or something other? Regards, Sergey.

1 1

Range Networks: Open Source Cellular Networks
by Markus Zielonka 27 Mar '13

27 Mar '13

"Range Networks formally introduced today its executive management team to deliver a complete open source software version of the cellular system. Range Networks says it is the world’s leading provider of American-made commercial open source cellular systems and is slashing the cost to own and operate mobile networks." http://www.dailywireless.org/2013/03/26/range-networks-open-source-cellular…

1 0

Leak/Double-free handling in SGSN
by Holger Hans Peter Freyther 26 Mar '13

26 Mar '13

Hi, I was discussing this crash[1] with Jan at the 29C3 and recently in Iceland. On top of that Katarina pointed me to the best practises[2] of talloc. In general I disagree with them[3] but they provide a nice solution for the SGSN/MSGB ownership issue. Methods that send a msgb should create a new local context and attach it to a global context for all local contexts (so we see them in the leak report). This would probably be done with a helper function in libosmocore. Once the msgb is created, we will steal it into the local context. Then we pass it down the rabbit hole. Once it is reaching the write_queue it is stolen back (or into a write queue context). The initial caller will free his local context. And now there are three options: a.) The msgb has made it into the write_queue. b.) The msgb has been already deleted due to an error c.) The msgb is still in the local context and will be freed. Using the talloc_steal and the local context will make sure we do not leak and do not double free. We can (and should) add a warning to see under which circumstances the msgb has not been freed. I think the implementation of this will be about 10-15 lines of code (probably too optimistic). comments? holger [1] http://openbsc.osmocom.org/trac/ticket/55 [2] http://talloc.samba.org/talloc/doc/html/libtalloc__bestpractices.html [3] Most of our functions only allocate one object. There is no point in having a hierachy of ROOT -> SingleObject. This indirection is wasteful in most cases.

1 1

Re: A scalabe solution to connect ip-based BSS to legacy GSM networks
by Dmitri Soloviev 25 Mar '13

25 Mar '13

This is just a proposal how a scalable cost-effective solution can look like. It is not implemented yet, but the goal is to work out a right approach. I developed quite similar things in 2003, when I interfaced ip.access BSC to S-12 and AXE-10. This is a piece of operator infrastructure, desired to be sold to MNO. In Russia it also assumes certification procedure, held by authorized center. On Mon, Mar 25, 2013 at 1:16 PM, John Wu <jwjohn0(a)gmail.com> wrote: > Hi Dmitri, > Have you developed the solution connect private GSM network to operator > core network? > But this should be allowed by the local operator, right? > > > On Sat, Mar 23, 2013 at 5:09 PM, Dmitri Soloviev <dmi3sol(a)gmail.com>wrote: > >> Hi >> >> we've got several requests to extend existing GSM networks with our radio >> equipment, where ip transport is appreciated. >> >> Please take a look at my vision of interfacing A-over-ip to a legacy GSM >> A-interface. >> >> Building blocks: >> >> 1. OpenBSC with ip.access-compatible A-over-ip interface >> >> 2. MGCP-controlled transcoder, built with Sangoma D-series cards. Can be >> assumed as a shared resource, available for several BSC instances. >> http://www.sangoma.com/assets/docs/datasheets/en/d500.pdf >> >> 3. TelscaleSS7card - a stand-alone signaling and media gateway, with 2 E1 >> and 2 Ethernet interfaces, running embedded linux on board. >> It converts A-over-ip to A-interface, acts as MGCP call agent for BTSs, >> transcoders and other telscaleSS7cards. A card is implemented in PCI form >> factor, but bus is used just to provide power supply. >> In other words, a card can act either as a combined SG+MG, converting >> A-over-ip into SS7 and RTP into E1 timeslot, or just a MG, converting RTP >> into E1, without any impact on the host system. >> >> >> When a [signaling gateway + call agent] detects ASSIGNMENT_REQUEST or >> HANDOVER_REQUEST, it stores cic value. As soon as ASSIGNMENT_COMPLETE or >> HO_REQ_ACK is detected, it builds RTP chain that unites >> BTS<->transcoder<->media_gateway. The chain is broken after the call is >> finished. >> >> Depending on the chosen cross plane, 4U 19" industrial PC can carry >> several BSC instances with transcoding, serving about 20 E1 interfaces (ea >> about 80 ARFCNs). Performance requirements for industrial PC cards are also >> negligible: computer will run OpenBSC and configure transcoder cards, being >> controlled by means of MGCP. >> >> >> >> Best Regards, >> Dmitri >> > >

1 0

A scalabe solution to connect ip-based BSS to legacy GSM networks
by Dmitri Soloviev 23 Mar '13

23 Mar '13

Hi we've got several requests to extend existing GSM networks with our radio equipment, where ip transport is appreciated. Please take a look at my vision of interfacing A-over-ip to a legacy GSM A-interface. Building blocks: 1. OpenBSC with ip.access-compatible A-over-ip interface 2. MGCP-controlled transcoder, built with Sangoma D-series cards. Can be assumed as a shared resource, available for several BSC instances. http://www.sangoma.com/assets/docs/datasheets/en/d500.pdf 3. TelscaleSS7card - a stand-alone signaling and media gateway, with 2 E1 and 2 Ethernet interfaces, running embedded linux on board. It converts A-over-ip to A-interface, acts as MGCP call agent for BTSs, transcoders and other telscaleSS7cards. A card is implemented in PCI form factor, but bus is used just to provide power supply. In other words, a card can act either as a combined SG+MG, converting A-over-ip into SS7 and RTP into E1 timeslot, or just a MG, converting RTP into E1, without any impact on the host system. When a [signaling gateway + call agent] detects ASSIGNMENT_REQUEST or HANDOVER_REQUEST, it stores cic value. As soon as ASSIGNMENT_COMPLETE or HO_REQ_ACK is detected, it builds RTP chain that unites BTS<->transcoder<->media_gateway. The chain is broken after the call is finished. Depending on the chosen cross plane, 4U 19" industrial PC can carry several BSC instances with transcoding, serving about 20 E1 interfaces (ea about 80 ARFCNs). Performance requirements for industrial PC cards are also negligible: computer will run OpenBSC and configure transcoder cards, being controlled by means of MGCP. Best Regards, Dmitri

1 0

Calls to non-existent extensions
by "Philip Kai Stefan Schütz" 19 Mar '13

19 Mar '13

Hello, I am using a setup consisting of an ip.access nanoBTS (165) and the sysmocom sysmoBSC for detecting and analysing malware on mobile phones. So far, I sniff the IP traffic at the Uplink-Interface and the traffic between the nanoBTS and the sysmoBSC for SMS. Now I want to extend my project and detect calls. When analysing a pcap file I can easily find a call that has been connected by the BSC in the RSL protocol. However, if the call could not be connected (because the dialed number is not in the HLR), I can not find any sign of a connection between BTS and BSC whatsoever. When analysing a new malware, I don't know the number the malware dials, so I can't give the extension to a second phone. I thought the BTS transferred the dialed number to the BSC, the BSC knows the extension doesn't exist and refuses the connection. In which protocol can I find the attempt to connect and the dialed number? Another solution I thought of was using Asterisk with a softphone that all calls are routed to. Is that possible? Is there any way to use the sysmoBSC with an Asterisk server? I found lots of tutorials on how to use openBSC with Asterisk, but nothing on osmo-nitb+Asterisk and the sysmoBSC. Asterisk would run on a second machine connected to the sysmoBSC of course. Regards, Philip

1 0

Re: lchan->s and integer overflow
by jolly 15 Mar '13

15 Mar '13

hi, (somehow i already sent this patch to the list. but it seems to be gone.) this patch should fix the underrun problem. it will only send radio link failure to bsc one and then stop processing timeout counter. regards, andreas

3 6

[PATCH] Fix: Stop RADIO LINK TIMEOUT couter S from counting, if it has reached 0
by Andreas Eversberg 14 Mar '13

14 Mar '13

In case that the counter S reached 0, it will stay 0. Subsequent received good and bad SACCH frames must not cause to trigger radio link failure again. Once the BSC has been indicated about link failure, it will release channel. The counting of S has been moved to a seperate function. This patch will ensure that the link failure is indicated only once. But even if the link failure would be sent multiple times, the BSC should ignore it. The BSC releases the channel and may only reuse it after confirm from BTS. (There cannot be any link failure indications after confirm of channel release.) The allowed timeout value range is 4..64, as defined in TS 05.08, so if the BSC sends an attribute with value out of range or other failure criterion, the Set BTS Attributes message is NACKed. --- src/common/oml.c | 12 ++++++++-- src/osmo-bts-sysmo/l1_if.c | 50 +++++++++++++++++++++++++++---------------- 2 files changed, 40 insertions(+), 22 deletions(-) diff --git a/src/common/oml.c b/src/common/oml.c index 4e2dead..bf90ff1 100644 --- a/src/common/oml.c +++ b/src/common/oml.c @@ -446,10 +446,16 @@ static int oml_rx_set_bts_attr(struct gsm_bts *bts, struct msgb *msg) btsb->interference.intave = *TLVP_VAL(&tp, NM_ATT_INTAVE_PARAM); /* 9.4.14 Connection Failure Criterion */ - if (TLVP_PRESENT(&tp, NM_ATT_CONN_FAIL_CRIT) && - (TLVP_LEN(&tp, NM_ATT_CONN_FAIL_CRIT) >= 2) && - *TLVP_VAL(&tp, NM_ATT_CONN_FAIL_CRIT) == 0x01) { + if (TLVP_PRESENT(&tp, NM_ATT_CONN_FAIL_CRIT)) { const uint8_t *val = TLVP_VAL(&tp, NM_ATT_CONN_FAIL_CRIT); + + if (TLVP_LEN(&tp, NM_ATT_CONN_FAIL_CRIT) < 2 + || val[0] != 0x01 || val[1] < 4 || val[1] > 64) { + LOGP(DOML, LOGL_NOTICE, "Given Conn. Failure Criterion " + "not supported. Please use critetion 0x01 with " + "RADIO_LINK_TIMEOUT value of 4..64\n"); + return oml_fom_ack_nack(msg, NM_NACK_PARAM_RANGE); + } btsb->radio_link_timeout = val[1]; } /* if val[0] != 0x01: can be 'operator dependent' and needs to diff --git a/src/osmo-bts-sysmo/l1_if.c b/src/osmo-bts-sysmo/l1_if.c index df660c5..bdba4c2 100644 --- a/src/osmo-bts-sysmo/l1_if.c +++ b/src/osmo-bts-sysmo/l1_if.c @@ -647,11 +647,39 @@ static int process_meas_res(struct gsm_lchan *lchan, GsmL1_MeasParam_t *m) return lchan_new_ul_meas(lchan, &ulm); } +/* process radio link timeout counter S */ +static void radio_link_timeout(struct gsm_lchan *lchan, int bad_frame) +{ + struct gsm_bts_role_bts *btsb = lchan->ts->trx->bts->role; + + /* if link loss criterion already reached */ + if (lchan->s == 0) + return; + + if (bad_frame) { + /* count down radio link counter S */ + lchan->s--; + DEBUGP(DMEAS, "counting down radio link counter S=%d\n", + lchan->s); + if (lchan->s == 0) + rsl_tx_conn_fail(lchan, RSL_ERR_RADIO_LINK_FAIL); + return; + } + + if (lchan->s < btsb->radio_link_timeout) { + /* count up radio link counter S */ + lchan->s += 2; + if (lchan->s > btsb->radio_link_timeout) + lchan->s = btsb->radio_link_timeout; + DEBUGP(DMEAS, "counting up radio link counter S=%d\n", + lchan->s); + } +} + static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *data_ind, struct msgb *l1p_msg) { struct gsm_bts_trx *trx = fl1->priv; - struct gsm_bts_role_bts *btsb = trx->bts->role; struct osmo_phsap_prim pp; struct gsm_lchan *lchan; struct lapdm_entity *le; @@ -681,25 +709,9 @@ static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *data_i switch (data_ind->sapi) { case GsmL1_Sapi_Sacch: - /* process radio link timeout coniter S */ - if (data_ind->msgUnitParam.u8Size == 0) { - /* count down radio link counter S */ - lchan->s--; - DEBUGP(DMEAS, "counting down radio link counter S=%d\n", - lchan->s); - if (lchan->s == 0) - rsl_tx_conn_fail(lchan, - RSL_ERR_RADIO_LINK_FAIL); + radio_link_timeout(lchan, (data_ind->msgUnitParam.u8Size == 0)); + if (data_ind->msgUnitParam.u8Size == 0) break; - } - if (lchan->s < btsb->radio_link_timeout) { - /* count up radio link counter S */ - lchan->s += 2; - if (lchan->s > btsb->radio_link_timeout) - lchan->s = btsb->radio_link_timeout; - DEBUGP(DMEAS, "counting up radio link counter S=%d\n", - lchan->s); - } /* save the SACCH L1 header in the lchan struct for RSL MEAS RES */ if (data_ind->msgUnitParam.u8Size < 2) { LOGP(DL1C, LOGL_NOTICE, "SACCH with size %u<2 !?!\n", -- 1.7.3.4 --------------050705040601090706090209--

1 0

[PATCH] Fix: Stop RADIO LINK TIMEOUT couter S from counting, if it has reached 0
by Andreas Eversberg 14 Mar '13

14 Mar '13

In case that the counter S reached 0, it will stay 0. Subsequent received good and bad SACCH frames must not cause to trigger radio link failure again. Once the BSC has been indicated about link failure, it will release channel. This patch will ensure that the link failure is indicated only once. But even if the link failure would be sent multiple times, the BSC should ignore it. The BSC releases the channel and may only reuse it after confirm from BTS. (There cannot be any link failure indications after confirm of channel release.) The minimum timeout value is 4, as defined in TS 05.08, so if the BSC sends an attribute with a value < 4, this (wrong) value is ignored and the default value of 32 is used. --- src/common/oml.c | 6 +++--- src/osmo-bts-sysmo/l1_if.c | 7 +++++-- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/src/common/oml.c b/src/common/oml.c index 4e2dead..afedefd 100644 --- a/src/common/oml.c +++ b/src/common/oml.c @@ -447,10 +447,10 @@ static int oml_rx_set_bts_attr(struct gsm_bts *bts, struct msgb *msg) /* 9.4.14 Connection Failure Criterion */ if (TLVP_PRESENT(&tp, NM_ATT_CONN_FAIL_CRIT) && - (TLVP_LEN(&tp, NM_ATT_CONN_FAIL_CRIT) >= 2) && - *TLVP_VAL(&tp, NM_ATT_CONN_FAIL_CRIT) == 0x01) { + (TLVP_LEN(&tp, NM_ATT_CONN_FAIL_CRIT) >= 2)) { const uint8_t *val = TLVP_VAL(&tp, NM_ATT_CONN_FAIL_CRIT); - btsb->radio_link_timeout = val[1]; + if (val[0] == 0x01 && val[1] >= 4) + btsb->radio_link_timeout = val[1]; } /* if val[0] != 0x01: can be 'operator dependent' and needs to * be parsed by bts driver */ diff --git a/src/osmo-bts-sysmo/l1_if.c b/src/osmo-bts-sysmo/l1_if.c index df660c5..5728df0 100644 --- a/src/osmo-bts-sysmo/l1_if.c +++ b/src/osmo-bts-sysmo/l1_if.c @@ -681,8 +681,11 @@ static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *data_i switch (data_ind->sapi) { case GsmL1_Sapi_Sacch: - /* process radio link timeout coniter S */ + /* process radio link timeout counter S */ if (data_ind->msgUnitParam.u8Size == 0) { + /* if link loss criterion already reached */ + if (lchan->s == 0) + break; /* count down radio link counter S */ lchan->s--; DEBUGP(DMEAS, "counting down radio link counter S=%d\n", @@ -692,7 +695,7 @@ static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *data_i RSL_ERR_RADIO_LINK_FAIL); break; } - if (lchan->s < btsb->radio_link_timeout) { + if (lchan->s > 0 && lchan->s < btsb->radio_link_timeout) { /* count up radio link counter S */ lchan->s += 2; if (lchan->s > btsb->radio_link_timeout) -- 1.7.3.4 --------------050806080900000401040704--

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC