From pfc.rivas at gmail.com Mon Oct 8 16:09:59 2012 From: pfc.rivas at gmail.com (Arturo Rivas) Date: Mon, 8 Oct 2012 18:09:59 +0200 Subject: GPRS and PDP Context In-Reply-To: <5061C41C.3010906@fairwaves.ru> References: <50598CFC.2000003@fairwaves.ru> <20120919154810.19091.qmail@stuge.se> <505B3D81.9030605@fairwaves.ru> <20120921072435.GG15271@prithivi.gnumonks.org> <5061C41C.3010906@fairwaves.ru> Message-ID: Hi list! I have a doubts about configuration. First of all, the interface tun0. Have they to be in the same net that mobile phones? I have configured dynip with subnet 192.168.254.0/24 but tun0 is in subnet 192.168.0.1. In addiction 'ggsn' shows 'net: 192.168.0.0/24' in its log. 'osmo-nitb' log shows 'Failure Event Report Type=communication failure Severity=critical failure Probable cause= 03 03 11 Additional Text=' but voice configuration works well. Thank you very much! 2012/9/25 ? > 21.09.2012 09:24, Harald Welte ?????: > > Obtaining an IP address is the _last_ activity, after many other things. > > NS/BSSGP is up. Next you should see some GPRS ATTACH / GPRS ROUTING > > AREA UPDATE. Only after that, you can get to PDP CONTEXT ACTIVATE and > > finally IP traffic. > > Despite my efforts to make use of logging system I do not see anything > like GPRS > ATTACH / GPRS ROUTING AREA UPDATE. > > So either I'm not running enough logging or failure is lurking somewhere > in previous > steps. > Hence the questions: > > - who exactly will report "GPRS ATTACH / GPRS ROUTING AREA UPDATE" > messages? > - how do I check that NS/BSSGP is up? > > -- > best regards, > Max, http://fairwaves.ru > > > -- Best regards, Arturo Rivas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.e.otten at gmail.com Mon Oct 1 22:47:37 2012 From: john.e.otten at gmail.com (John Otten) Date: Mon, 1 Oct 2012 18:47:37 -0400 Subject: OpenBSC and 3G Message-ID: Hello Everyone, I now have OpenBSC (including GPRS) up and running with a fair amount of stability, using an IP.Access 2G BTS. Now I am looking towards the next stage - getting a 3G system operating. I have the use of an IP.Access NodeB that I would like get running with OpenBSC. In performing my due diligence, I found Harald's 3G road map from December 2010 or so. I am wondering what the current state of development is. I see that IP.Access' URSL protocol was an issue back then, because it is proprietary. Has anyone managed to get far enough in their development that they have implemented the protocol? I also see from Dieter Spaar's blog that he is making some progress, but he states his code is not ready for public release. Since I don't see much about 3G on the OpenBSC wiki, I am assuming that no one has any code that they would want to share at this point. I imagine I may have to forge ahead on my own. I am fairly new to GSM development, and I haven't really delved into the OpenBSC source yet (other than to discern what might have caused some problems I encountered), so if anyone has any suggestions on where to begin, or has some issues where I might be able to assist in order to move development further down the road, please let me know. Thanks! John -------------- next part -------------- An HTML attachment was scrubbed... URL: From yannm1 at hotmail.com Tue Oct 2 14:56:00 2012 From: yannm1 at hotmail.com (Yann R. Moupinda) Date: Tue, 2 Oct 2012 16:56:00 +0200 Subject: Analysing the communication between the BSC and the MSC in a sysmoBTS In-Reply-To: References: , Message-ID: Hello everybody First of all, let me introduce myself. My name is Yann Moupinda and I'm a student doing his Master thesis in the field of GSM technology. For my thesis, the company for which i'm working now, bought a sysmoBTS from sysmocom. The sysmoBTS is configured as a stand alone GSM network in a box (NITB) running the osmo-nitb and the osmo-bts programs. An important part of my thesis is to understand how the sysmoBTS works and therefore I did some measurements with wireshark to analyse the data flow between the BTS,BSC and MSC/HLR/VLR/EIR. This is also to see the main differences between a sysmoBTS and a conventional GSM Network. I used the " tcpdump " - command on the loopback interface lo0 to capture the data flow between the GSM components and then, the analysis with wireshark shows me only the data flow between BTS and BSC. It's possible to see such messages like LOCATION UPDATING REQUEST and IDENTITY REQUEST wich are normally, transparently exchanged between Mobile Station (MS) and the Network subsystem (MSC/HLR/VLR/EIR). All these messages are always addressed to, or from the same BSC TCP-port 3003. So i can not see what happens behind this port (behind BSC). In order to get the communication between BSC and MSC, i decided to have a deeper look on the logging messages of the sysmoBTS. Even there, i cannot recognize how the data transmission between BSC and MSC works. Does anyone know how to get this information? Any guidance would be appreciated. I have included one .pcap file and a text file of the logging messages taken while i powered on the mobile phone. Best regards, Yann. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cap_120912_01.pcap Type: application/octet-stream Size: 12162 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logdatei_Handy_Einschalten_270912 Type: application/octet-stream Size: 2990 bytes Desc: not available URL: From peter at stuge.se Tue Oct 2 15:23:28 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 2 Oct 2012 17:23:28 +0200 Subject: Analysing the communication between the BSC and the MSC in a sysmoBTS In-Reply-To: References: Message-ID: <20121002152328.6222.qmail@stuge.se> Hi Yann, Yann R. Moupinda wrote: > An important part of my thesis is to understand how the sysmoBTS works > and therefore I did some measurements with wireshark to analyse the > data flow between the BTS,BSC and MSC/HLR/VLR/EIR. This is also to > see the main differences between a sysmoBTS and a conventional GSM > Network. > So i can not see what happens behind this port (behind BSC). > > In order to get the communication between BSC and MSC, i decided to > have a deeper look on the logging messages of the sysmoBTS. Even there, > i cannot recognize how the data transmission between BSC and MSC works. Start looking at the source code. Pick some entry point for a message that you understand. Follow the call graph through the source code, to learn about the data flow in OpenBSC. You will quickly find what the difference is between OpenBSC and a conventional BSC. //Peter From holger at freyther.de Thu Oct 4 08:10:56 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 4 Oct 2012 10:10:56 +0200 Subject: Analysing the communication between the BSC and the MSC in a sysmoBTS In-Reply-To: <20121002152328.6222.qmail@stuge.se> References: <20121002152328.6222.qmail@stuge.se> Message-ID: <20121004081056.GD7122@localhost> On Tue, Oct 02, 2012 at 05:23:28PM +0200, Peter Stuge wrote: > Hi Yann, > > > Start looking at the source code. Pick some entry point for a message > that you understand. Follow the call graph through the source code, > to learn about the data flow in OpenBSC. You will quickly find what > the difference is between OpenBSC and a conventional BSC. Hi, on top of that the "BSC API"[1] is a good way to start to look at. There are currently two implementations. One for the NITB and one for the classic BSC. The NITB will handle the MSC/AuC/HLR/VLR functionality by direct function calls, the BSC will pack the data into GSM08.08 BSSMAP and send it to a MSC using SCCP-lite (SCCP on the IPA protocol). To use the "classic BSC" one needs a real MSC to connect to. My Smalltalk implementation is not very mature yet. holger [1] http://cgit.osmocom.org/cgit/openbsc/tree/openbsc/src/libbsc/bsc_api.c From osmocom at ngolde.de Tue Oct 2 22:06:01 2012 From: osmocom at ngolde.de (Nico Golde) Date: Wed, 3 Oct 2012 00:06:01 +0200 Subject: Oct 3, 8pm / Osmocom Berlin User Group meeting? Message-ID: <20121002220601.GA19802@nybble.binarybase.org> Hi all! I *think* Harald is pretty busy and also unlikely to attend prospective meeting tomorrow. Also there is bank holiday tomorrow in Germany and at least I personally will use that to stay away from technology for a bit, so I won't come. Nevertheless, I thought I'd write this email to remind people that in theory there is a meeting tomorrow and discuss if other people attend. I personally would propose to shift the meeting to next week (for purely selfish reasons ;). As far as I know, there is no formal presentation tomorrow. Anyway, will anyone attend tomorrow or is everyone in favor of shifting a week? In case it takes place, for the people who did not attend so far, the usual snippet from Harald's mails: Oct 3, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin If you are interested to show up, feel free to do so. There is no registration required. The meeting is free as in "free beer", despite no actual free beer being around. Cheers Nico From peter at stuge.se Tue Oct 2 22:20:10 2012 From: peter at stuge.se (Peter Stuge) Date: Wed, 3 Oct 2012 00:20:10 +0200 Subject: Oct 3, 8pm / Osmocom Berlin User Group meeting? In-Reply-To: <20121002220601.GA19802@nybble.binarybase.org> References: <20121002220601.GA19802@nybble.binarybase.org> Message-ID: <20121002222010.7759.qmail@stuge.se> Hi Nico, all, Thanks for the email! Nico Golde wrote: > Anyway, will anyone attend tomorrow or is everyone in favor > of shifting a week? I can attend tomorrow, but since there is nothing scheduled and I also don't have any suggestions for discussion topics I have nothing against shifting one week. > If you are interested to show up, feel free to do so. In principle this is correct, but please stay tuned to this mailing list discussion so that you do not end up ringing the doorbell at CCC Berlin without there being anyone around to answer it. :) //Peter From kevredon at mail.tsaitgaist.info Wed Oct 3 08:36:58 2012 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Wed, 03 Oct 2012 10:36:58 +0200 Subject: Oct 3, 8pm / Osmocom Berlin User Group meeting? In-Reply-To: <20121002222010.7759.qmail@stuge.se> References: <20121002220601.GA19802@nybble.binarybase.org> <20121002222010.7759.qmail@stuge.se> Message-ID: <1349253355-sup-4566@dennou> Hi, I will not be there either, and have nothing against shifting it :) kevin Excerpts from Peter Stuge's message of Wed Oct 03 00:20:10 +0200 2012: > Hi Nico, all, > > Thanks for the email! > > Nico Golde wrote: > > Anyway, will anyone attend tomorrow or is everyone in favor > > of shifting a week? > From philipp.maier at runningserver.com Wed Oct 3 09:33:29 2012 From: philipp.maier at runningserver.com (Philipp Fabian Benedikt Maier) Date: Wed, 03 Oct 2012 11:33:29 +0200 Subject: Oct 3, 8pm / Osmocom Berlin User Group meeting? In-Reply-To: <1349253355-sup-4566@dennou> References: <20121002220601.GA19802@nybble.binarybase.org> <20121002222010.7759.qmail@stuge.se> <1349253355-sup-4566@dennou> Message-ID: <506C0669.4080701@runningserver.com> Hi folks. Same herel. See you (hopefully) next week. I wish you all a nice holiday. regards, Philipp From osmocom at ngolde.de Mon Oct 8 10:11:35 2012 From: osmocom at ngolde.de (Nico Golde) Date: Mon, 8 Oct 2012 12:11:35 +0200 Subject: Oct 3, 8pm / Osmocom Berlin User Group meeting? In-Reply-To: <506C0669.4080701@runningserver.com> References: <20121002220601.GA19802@nybble.binarybase.org> <20121002222010.7759.qmail@stuge.se> <1349253355-sup-4566@dennou> <506C0669.4080701@runningserver.com> Message-ID: <20121008101135.GA19680@nybble.binarybase.org> Hi, * Philipp Fabian Benedikt Maier [2012-10-03 13:56]: > Same herel. See you (hopefully) next week. I wish you all a nice holiday. I planned for this week now. Anyone else attending? Kind regards Nico From ml at mail.tsaitgaist.info Mon Oct 8 23:19:46 2012 From: ml at mail.tsaitgaist.info (Kevin Redon) Date: Tue, 09 Oct 2012 01:19:46 +0200 Subject: Oct 3, 8pm / Osmocom Berlin User Group meeting? In-Reply-To: <20121008101135.GA19680@nybble.binarybase.org> References: <20121002220601.GA19802@nybble.binarybase.org> <20121002222010.7759.qmail@stuge.se> <1349253355-sup-4566@dennou> <506C0669.4080701@runningserver.com> <20121008101135.GA19680@nybble.binarybase.org> Message-ID: <1349738380-sup-4190@dennou> Hi, I will. kevin Excerpts from Nico Golde's message of Mon Oct 08 12:11:35 +0200 2012: > Hi, > * Philipp Fabian Benedikt Maier [2012-10-03 13:56]: > > Same herel. See you (hopefully) next week. I wish you all a nice holiday. > > I planned for this week now. Anyone else attending? > > Kind regards > Nico From t-openbsc at tobias.org Tue Oct 9 08:01:44 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Tue, 09 Oct 2012 10:01:44 +0200 Subject: Oct 3, 8pm / Osmocom Berlin User Group meeting? In-Reply-To: <1349738380-sup-4190@dennou> References: <20121002220601.GA19802@nybble.binarybase.org> <20121002222010.7759.qmail@stuge.se> <1349253355-sup-4566@dennou> <506C0669.4080701@runningserver.com> <20121008101135.GA19680@nybble.binarybase.org> <1349738380-sup-4190@dennou> Message-ID: <5073D9E8.2050701@tobias.org> Me too. -Tobias On 09.10.12 01:19, Kevin Redon wrote: > Hi, > > I will. > > kevin > > Excerpts from Nico Golde's message of Mon Oct 08 12:11:35 +0200 2012: >> Hi, >> * Philipp Fabian Benedikt Maier [2012-10-03 13:56]: >>> Same herel. See you (hopefully) next week. I wish you all a nice holiday. >> >> I planned for this week now. Anyone else attending? >> >> Kind regards >> Nico > > From yannm1 at hotmail.com Mon Oct 8 19:23:58 2012 From: yannm1 at hotmail.com (Yann R. Moupinda) Date: Mon, 8 Oct 2012 21:23:58 +0200 Subject: Analysing the communication between the BSC and the MSC in a sysmoBTS Message-ID: Hello everyone, thanks for the ideas you gave me about how i can learn more about the communication between BSC and MSC in my sysmoBTS. Since last week i've been looking at the source codes and it's still difficult for me to follow the exchanged messages betwenn BSC and MSC. I don't have high programming skills. Instead of using sysmoBTS as an autonomous self-contained GSM network (NITB mode), i'd like to configure it in the BSC-only mode running the osmo-bts and osmo-bsc. I read that i will need a MSC that can provide an A-over-IP interface using SCCP-lite. I saw that the "on-waves/bsc-master" branch is implementing such a SCCP and works have been done to create a GSM0808 like API and move the MSC code inside OpenBSC over to use this API. So i was wondering how far this project has been developed yet. Do you already have any interesting results that can help me? If not, it can be also interesting for me to know how you did your tests by implementing the bsc-only mode (osmo-bsc)? Did you connect it to a real MSC or did you have anything else emulating the MSC/HLR/VLR/EIR functions? Best regards Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Tue Oct 9 14:57:38 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 9 Oct 2012 16:57:38 +0200 Subject: Analysing the communication between the BSC and the MSC in a sysmoBTS In-Reply-To: References: Message-ID: <20121009145738.GA19399@xiaoyu.lan> On Mon, Oct 08, 2012 at 09:23:58PM +0200, Yann R. Moupinda wrote: > > > > > Hello everyone, > > thanks for the ideas you gave me about how i can learn more about the communication between BSC and MSC in my sysmoBTS. Since last week i've been looking at the source codes and it's still difficult for me to follow the exchanged messages betwenn BSC and MSC. I don't have high programming skills. well, it starts with the organisation of the sourcecode. E.g. src/libmsc contains the MSC functionality. E.g. take a look at osmo_msc.c it is glueing the "BSC API" to the MSC code. compl_layer3 (as of GSM 08.08) will be called for the first message on a newly opened RF connection. dtap will be called for every following message. > > Instead of using sysmoBTS as an autonomous self-contained GSM network (NITB mode), i'd like to configure it in the BSC-only mode running the osmo-bts and osmo-bsc. I read that i will need a MSC that can provide an A-over-IP interface using SCCP-lite. I saw that the "on-waves/bsc-master" branch is implementing such a SCCP and works have been done to create a GSM0808 like API and move the MSC code inside OpenBSC over to use this API. So i was wondering how far this project has been developed yet. Do you already have any interesting results that can help me? If not, it can be also interesting for me to know how you did your tests by implementing the bsc-only mode (osmo-bsc)? Did you connect it to a real MSC or did you have anything else emulating the MSC/HLR/VLR/EIR functions? on-waves/bsc-master is an old vendor branch, the same functionality is available in the master branch of openbsc. The src/osmo-bsc directory holds the BSC implementation. This adds GSM 08.08 parsing and message generation on top of the 'BSC API' (same interface as in osmo_msc.c but different implementation). The osmo-bsc has been used with various proprietary MSCs. There is no free MSC that will just do what you want at this point in time. I have the start of a MSC in Smalltalk but right now it is solving a non-standard usecase and is not a general MSC. Why do you need to see GSM 08.08 messages? From holger at freyther.de Mon Oct 8 20:24:23 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 8 Oct 2012 22:24:23 +0200 Subject: SI Generation and multi-trx setup Message-ID: <20121008202423.GC21775@xiaoyu.lan> Hi Andreas, Harald, the recent "SI generation" fix broke multi trx setups. This is because when the first (c0) TRX is going up bts->si_valid will include SI2 and other SIs scheduled on the BCCH and once the second trx is going up the code decides it only needs to generate the SI5 (and more). But si_valid still includes SI2 and it will be set on the second trx. I have fixed it locally by setting si_valid to 0 early in the set_system_infos routine and added a warning for this case. How should this be properly fixed for master? Will the content of a specific SI differ from TRX0 to TRX1 of a BTS? Should the si_valid be moved to the trx data structure? I have attached my local patch and would like to have a review for it. comments? ideas? holger From zecke at selfish.org Mon Oct 8 20:12:13 2012 From: zecke at selfish.org (Holger Hans Peter Freyther) Date: Mon, 8 Oct 2012 22:12:13 +0200 Subject: [PATCH] bsc_init: Forget which SIs are valid for the trx. Message-ID: The recent commit to improve the SI generation lead to setting the BCCH SIs for all TRX in a multi-trx setup. This is because we create the SIs globally but si_valid appears to be limited to the 'current' trx. Warn if we attempt to set SIs for the BCCH on a trx that does not have a BCCH. --- openbsc/src/libbsc/bsc_init.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/openbsc/src/libbsc/bsc_init.c b/openbsc/src/libbsc/bsc_init.c index e05aec7..7a60e04 100644 --- a/openbsc/src/libbsc/bsc_init.c +++ b/openbsc/src/libbsc/bsc_init.c @@ -129,6 +129,11 @@ static int rsl_si(struct gsm_bts_trx *trx, enum osmo_sysinfo_type i, int si_len) GSM_BTS_SI(bts, i), si_len); break; default: + if (bts->c0 != trx) + LOGP(DRR, LOGL_ERROR, + "Attempting to set BCCH SI%s on wrong BTS/TRX (%d/%d)\n", + get_value_string(osmo_sitype_strs, i), + bts->nr, trx->nr); rc = rsl_bcch_info(trx, osmo_sitype2rsl(i), GSM_BTS_SI(bts, i), si_len); break; @@ -149,6 +154,9 @@ static int set_system_infos(struct gsm_bts_trx *trx) ms_pwr_ctl_lvl(bts->band, bts->ms_max_power); bts->si_common.cell_sel_par.neci = bts->network->neci; + /* Zero, forget the state of the SIs */ + bts->si_valid = 0; + /* First, we determine which of the SI messages we actually need */ if (trx == bts->c0) { -- 1.7.10.4 From andreas at eversberg.eu Tue Oct 9 10:56:54 2012 From: andreas at eversberg.eu (jolly) Date: Tue, 09 Oct 2012 12:56:54 +0200 Subject: SI Generation and multi-trx setup In-Reply-To: <20121008202423.GC21775@xiaoyu.lan> References: <20121008202423.GC21775@xiaoyu.lan> Message-ID: <507402F6.4090608@eversberg.eu> hi holger, since all SI (5 and 6) are equal for all TRX of BTS, the si_valid should stay part of BTS structure. resetting it will break the static assignment feature via VTY. the first part of my patch ensures that only generated SI are set to valid. other static SI may be valid or not, as specified via VTY. the second part calls rsl_si() with only the required SI. i think it is good to keep your error check at rsl_si(). regards, andreas Holger Hans Peter Freyther wrote: > Hi Andreas, Harald, > > the recent "SI generation" fix broke multi trx setups. This is because > when the first (c0) TRX is going up bts->si_valid will include SI2 and > other SIs scheduled on the BCCH and once the second trx is going up the > code decides it only needs to generate the SI5 (and more). > > But si_valid still includes SI2 and it will be set on the second trx. I > have fixed it locally by setting si_valid to 0 early in the set_system_infos > routine and added a warning for this case. > > How should this be properly fixed for master? Will the content of a specific > SI differ from TRX0 to TRX1 of a BTS? Should the si_valid be moved to the > trx data structure? > > I have attached my local patch and would like to have a review for it. > > comments? ideas? > > holger > > > >From bde31667fdd182268fe2172c8c5e21b0c7d085c1 Mon Sep 17 00:00:00 2001 > From: Holger Hans Peter Freyther > Date: Mon, 8 Oct 2012 22:12:13 +0200 > Subject: [PATCH] bsc_init: Forget which SIs are valid for the trx. > > The recent commit to improve the SI generation lead to setting > the BCCH SIs for all TRX in a multi-trx setup. This is because > we create the SIs globally but si_valid appears to be limited > to the 'current' trx. Warn if we attempt to set SIs for the BCCH > on a trx that does not have a BCCH. > --- > openbsc/src/libbsc/bsc_init.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/openbsc/src/libbsc/bsc_init.c b/openbsc/src/libbsc/bsc_init.c > index e05aec7..7a60e04 100644 > --- a/openbsc/src/libbsc/bsc_init.c > +++ b/openbsc/src/libbsc/bsc_init.c > @@ -129,6 +129,11 @@ static int rsl_si(struct gsm_bts_trx *trx, enum osmo_sysinfo_type i, int si_len) > GSM_BTS_SI(bts, i), si_len); > break; > default: > + if (bts->c0 != trx) > + LOGP(DRR, LOGL_ERROR, > + "Attempting to set BCCH SI%s on wrong BTS/TRX (%d/%d)\n", > + get_value_string(osmo_sitype_strs, i), > + bts->nr, trx->nr); > rc = rsl_bcch_info(trx, osmo_sitype2rsl(i), > GSM_BTS_SI(bts, i), si_len); > break; > @@ -149,6 +154,9 @@ static int set_system_infos(struct gsm_bts_trx *trx) > ms_pwr_ctl_lvl(bts->band, bts->ms_max_power); > bts->si_common.cell_sel_par.neci = bts->network->neci; > > + /* Zero, forget the state of the SIs */ > + bts->si_valid = 0; > + > /* First, we determine which of the SI messages we actually need */ > > if (trx == bts->c0) { > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: si-fix.patch URL: From holger at freyther.de Tue Oct 9 13:31:36 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 9 Oct 2012 15:31:36 +0200 Subject: SI Generation and multi-trx setup In-Reply-To: <507402F6.4090608@eversberg.eu> References: <20121008202423.GC21775@xiaoyu.lan> <507402F6.4090608@eversberg.eu> Message-ID: <20121009133136.GA16080@xiaoyu.lan> On Tue, Oct 09, 2012 at 12:56:54PM +0200, jolly wrote: > hi holger, > > since all SI (5 and 6) are equal for all TRX of BTS, the si_valid should > stay part of BTS structure. resetting it will break the static > assignment feature via VTY. what is the reason to re-generate some of the SI when the n-th trx is up? Shouldn't we generate the SI once and then based on the TRX decide which one (gen_si) to send to the BTS? > the first part of my patch ensures that only generated SI are set to > valid. other static SI may be valid or not, as specified via VTY. patch looks fine (didn't review and I don't know much about the static SI generation). Please commit. From andreas at eversberg.eu Tue Oct 9 15:32:23 2012 From: andreas at eversberg.eu (jolly) Date: Tue, 09 Oct 2012 17:32:23 +0200 Subject: SI Generation and multi-trx setup In-Reply-To: <20121009133136.GA16080@xiaoyu.lan> References: <20121008202423.GC21775@xiaoyu.lan> <507402F6.4090608@eversberg.eu> <20121009133136.GA16080@xiaoyu.lan> Message-ID: <50744387.3020904@eversberg.eu> > what is the reason to re-generate some of the SI when the n-th trx is up? > Shouldn't we generate the SI once and then based on the TRX decide which > one (gen_si) to send to the BTS? > here is an update of my patch. it generates only once now. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: si-fix-2.patch URL: From holger at freyther.de Tue Oct 9 20:02:25 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 9 Oct 2012 22:02:25 +0200 Subject: SI Generation and multi-trx setup In-Reply-To: <50744387.3020904@eversberg.eu> References: <20121008202423.GC21775@xiaoyu.lan> <507402F6.4090608@eversberg.eu> <20121009133136.GA16080@xiaoyu.lan> <50744387.3020904@eversberg.eu> Message-ID: <20121009200225.GE1964@xiaoyu.lan> On Tue, Oct 09, 2012 at 05:32:23PM +0200, jolly wrote: > > > what is the reason to re-generate some of the SI when the n-th trx is up? > > Shouldn't we generate the SI once and then based on the TRX decide which > > one (gen_si) to send to the BTS? > > > here is an update of my patch. it generates only once now. well, I think doing it this way is not really helping. Comments and variables are called 'gen'(erate) and in the end the SIs might not be generated. It is quite easy to miss the consequence of the conditions. Right now a config change will be reflected the next time the BTS (and its TRX) are up, after this change one would need to restart OpenBSC. My comment was meant as an ecouragement to check if we could separate the SI generation from the place where we select which ones to send to the BTS. holger From andreas at eversberg.eu Wed Oct 10 07:19:07 2012 From: andreas at eversberg.eu (jolly) Date: Wed, 10 Oct 2012 09:19:07 +0200 Subject: SI Generation and multi-trx setup In-Reply-To: <20121009200225.GE1964@xiaoyu.lan> References: <20121008202423.GC21775@xiaoyu.lan> <507402F6.4090608@eversberg.eu> <20121009133136.GA16080@xiaoyu.lan> <50744387.3020904@eversberg.eu> <20121009200225.GE1964@xiaoyu.lan> Message-ID: <5075216B.9090804@eversberg.eu> Holger Hans Peter Freyther wrote: > My comment was meant as an ecouragement to check if we could separate the SI > generation from the place where we select which ones to send to the BTS. > hi holger, if we want changes of config to be present in the SI whenever a TRX comes up, it is required to generate it when this happens. (so forget my last patch, because it does not do it and also it does it wrong.) i have no better solution in mind right now. can you test my attached patch before i commit it, because i don't have multi TRX setup? regards, andreas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: si-fix-3.patch URL: From m_josenhans at web.de Mon Oct 8 21:43:05 2012 From: m_josenhans at web.de (M. Josenhans) Date: Mon, 08 Oct 2012 23:43:05 +0200 Subject: Erlang command line interface (OTP-version) available Message-ID: <507348E9.6020302@web.de> Hello, the Erlang command line interface (OTP version) is available on Github: https://github.com/josemic/Erlang-command-line-interface_otp This is a telnet commandline server written in Erlang using OTP libraries. It provides features such as command-completion, command-abbreviation, command-help, reading/writing commands from/to file and modular command-registration. Its behaviour is kept similar to the well known, C-written, OpenBSC telnet command line server. It is intended for future inclusion into Osmocom's Erlang projects. The installation instructions are found in the github wiki. Cheers, Michael From t-openbsc at tobias.org Tue Oct 9 11:16:59 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Tue, 09 Oct 2012 13:16:59 +0200 Subject: CSD support for openbsc with the BS-11 Message-ID: <507407AB.8080308@tobias.org> Hi, I just pushed a "tobias/csd" branch to both the openbsc and libosmo-abis git. If you check out those branches you should be able to make CSD calls with a BS-11 and the following parameters: V.110, 9.6kbit/s, transparent mode. The AT-Command to activate this mode is AT+CBST=71,0,0. (If you see an ERROR when entering this command, your phone's baseband most likely doesn't support transparent mode. One of the few exceptions seem to be MediaTek and TI.) There is no Interworking Function in the code - the V.110 frames simply get sent from one phone to the other. This should not be a problem as long as both sides use the exact same parameters. The openbsc tobias/csd branch is based on Harald's laforge/csd branch which already adds code for setting CSD channel modes. Many thanks to Dieter Spaar who found out why I was only seeing garbled data on the uplink, and also to GSMK who let me use lots of my time there to figure out this CSD stuff. Next stop would be to implement RLP to also support V.110 non-transparent mode which is supported by almost all GSM basebands. -Tobias From 246tnt at gmail.com Tue Oct 9 11:29:43 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 9 Oct 2012 13:29:43 +0200 Subject: CSD support for openbsc with the BS-11 In-Reply-To: <507407AB.8080308@tobias.org> References: <507407AB.8080308@tobias.org> Message-ID: fyi, http://pastebin.com/V8a8c1D7 that's the RLP 'pretty print' I hacked together ... Cheers, Sylvain From t-openbsc at tobias.org Tue Oct 9 11:33:44 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Tue, 09 Oct 2012 13:33:44 +0200 Subject: CSD support for openbsc with the BS-11 In-Reply-To: References: <507407AB.8080308@tobias.org> Message-ID: <50740B98.4080407@tobias.org> > fyi, http://pastebin.com/V8a8c1D7 > > that's the RLP 'pretty print' I hacked together ... Nice, thanks! -Tobias From laforge at gnumonks.org Thu Oct 18 10:07:02 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 18 Oct 2012 12:07:02 +0200 Subject: CSD support for openbsc with the BS-11 In-Reply-To: <507407AB.8080308@tobias.org> References: <507407AB.8080308@tobias.org> Message-ID: <20121018100702.GA18868@prithivi.gnumonks.org> Hi Tobias, On Tue, Oct 09, 2012 at 01:16:59PM +0200, Tobias Engel wrote: > I just pushed a "tobias/csd" branch to both the openbsc and libosmo-abis > git. congratulations to making it work. Sorry for my delayed response, I was completley unavailable in recent weeks. I've seen teh openbsc.git branch, but I cannot see any branch in libosmo-abis.git. Can you please check if that branch really has been pushed? Do you see any reason why the code should / could not be merged? From my quick review, I didn't see any ovious location where it would break existing voice call behavior. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From t-openbsc at tobias.org Thu Oct 18 11:27:57 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Thu, 18 Oct 2012 13:27:57 +0200 Subject: CSD support for openbsc with the BS-11 In-Reply-To: <20121018100702.GA18868@prithivi.gnumonks.org> References: <507407AB.8080308@tobias.org> <20121018100702.GA18868@prithivi.gnumonks.org> Message-ID: <507FE7BD.2070302@tobias.org> Hi Harald, > I've seen teh openbsc.git branch, but I cannot see any branch in > libosmo-abis.git. Can you please check if that branch really has been > pushed? the libosmo-abis changes have already been merged, so the csd branch was removed - sorry, I should probably have made a mention to the list about that. > Do you see any reason why the code should / could not be merged? From > my quick review, I didn't see any ovious location where it would break > existing voice call behavior. I think my changes to handle CSD channels are a hack somewhat since the whole signalling code would probably need an overhaul to properly support different channel types. But technically everything should (and actually did, for my tests) work fine for voice calls, too, with these changes. -Tobias From andreas at eversberg.eu Sat Oct 13 05:41:18 2012 From: andreas at eversberg.eu (jolly) Date: Sat, 13 Oct 2012 07:41:18 +0200 Subject: patch to allow setting of various control channel description parameters Message-ID: <5078FEFE.3030202@eversberg.eu> hi, this patch allows to tune control channel. it can be used to speed up GPRS TBF establishment. regards, andreas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Allow-setting-of-Control-Channel-Description-paramet.patch URL: From jolly at eversberg.eu Sat Oct 13 05:27:47 2012 From: jolly at eversberg.eu (Andreas Eversberg) Date: Sat, 13 Oct 2012 07:27:47 +0200 Subject: [PATCH] Allow setting of Control Channel Description parameters via VTY Message-ID: --- openbsc/src/libbsc/bsc_init.c | 8 ++-- openbsc/src/libbsc/bsc_vty.c | 59 ++++++++++++++++++++++++++++++++++++++ openbsc/src/libcommon/gsm_data.c | 3 ++ 3 files changed, 66 insertions(+), 4 deletions(-) diff --git a/openbsc/src/libbsc/bsc_init.c b/openbsc/src/libbsc/bsc_init.c index 2533aa7..f5d7969 100644 --- a/openbsc/src/libbsc/bsc_init.c +++ b/openbsc/src/libbsc/bsc_init.c @@ -421,10 +421,7 @@ static int bootstrap_bts(struct gsm_bts *bts) "GSM networks and should only be used in a RF " "shielded environment such as a faraday cage!\n\n"); - /* Control Channel Description */ - bts->si_common.chan_desc.att = 1; - bts->si_common.chan_desc.bs_pa_mfrms = RSL_BS_PA_MFRMS_5; - bts->si_common.chan_desc.bs_ag_blks_res = 1; + /* Control Channel Description is set from vty/config */ /* T3212 is set from vty/config */ @@ -435,6 +432,9 @@ static int bootstrap_bts(struct gsm_bts *bts) switch (n) { case 0: bts->si_common.chan_desc.ccch_conf = RSL_BCCH_CCCH_CONF_1_C; + /* Limit reserved block to 2 on combined channel */ + if (bts->si_common.chan_desc.bs_ag_blks_res > 2) + bts->si_common.chan_desc.bs_ag_blks_res = 2; break; case 1: bts->si_common.chan_desc.ccch_conf = RSL_BCCH_CCCH_CONF_1_NC; diff --git a/openbsc/src/libbsc/bsc_vty.c b/openbsc/src/libbsc/bsc_vty.c index b91304d..61b0911 100644 --- a/openbsc/src/libbsc/bsc_vty.c +++ b/openbsc/src/libbsc/bsc_vty.c @@ -256,6 +256,12 @@ static void bts_dump_vty(struct vty *vty, struct gsm_bts *bts) VTY_NEWLINE); if (bts->si_common.rach_control.cell_bar) vty_out(vty, " CELL IS BARRED%s", VTY_NEWLINE); + vty_out(vty, "Channel Description Attachment: %s%s", + (bts->si_common.chan_desc.att) ? "yes" : "no", VTY_NEWLINE); + vty_out(vty, "Channel Description BS-PA-MFRMS: %u%s", + bts->si_common.chan_desc.bs_pa_mfrms + 2, VTY_NEWLINE); + vty_out(vty, "Channel Description BS-AG_BLKS-RES: %u%s", + bts->si_common.chan_desc.bs_ag_blks_res, VTY_NEWLINE); vty_out(vty, "System Information present: 0x%08x, static: 0x%08x%s", bts->si_valid, bts->si_mode_static, VTY_NEWLINE); if (is_ipaccess_bts(bts)) @@ -496,6 +502,13 @@ static void config_write_bts_single(struct vty *vty, struct gsm_bts *bts) rach_max_trans_raw2val(bts->si_common.rach_control.max_trans), VTY_NEWLINE); + vty_out(vty, " channel-descrption attach %u%s", + bts->si_common.chan_desc.att, VTY_NEWLINE); + vty_out(vty, " channel-descrption bs-pa-mfrms %u%s", + bts->si_common.chan_desc.bs_pa_mfrms + 2, VTY_NEWLINE); + vty_out(vty, " channel-descrption bs-ag-blks-res %u%s", + bts->si_common.chan_desc.bs_ag_blks_res, VTY_NEWLINE); + if (bts->rach_b_thresh != -1) vty_out(vty, " rach nm busy threshold %u%s", bts->rach_b_thresh, VTY_NEWLINE); @@ -1770,6 +1783,49 @@ DEFUN(cfg_bts_rach_max_trans, return CMD_SUCCESS; } +#define CD_STR "Channel Description\n" + +DEFUN(cfg_bts_chan_desc_att, + cfg_bts_chan_desc_att_cmd, + "channel-descrption attach (0|1)", + CD_STR + "Set if attachment is required\n" + "Attachment is NOT required\n" + "Attachment is required (standard)\n") +{ + struct gsm_bts *bts = vty->index; + bts->si_common.chan_desc.att = atoi(argv[0]); + return CMD_SUCCESS; +} + +DEFUN(cfg_bts_chan_desc_bs_pa_mfrms, + cfg_bts_chan_desc_bs_pa_mfrms_cmd, + "channel-descrption bs-pa-mfrms <2-9>", + CD_STR + "Set number of multiframe periods for paging groups\n" + "Number of multiframe periods for paging groups\n") +{ + struct gsm_bts *bts = vty->index; + int bs_pa_mfrms = atoi(argv[0]); + + bts->si_common.chan_desc.bs_pa_mfrms = bs_pa_mfrms - 2; + return CMD_SUCCESS; +} + +DEFUN(cfg_bts_chan_desc_bs_ag_blks_res, + cfg_bts_chan_desc_bs_ag_blks_res_cmd, + "channel-descrption bs-ag-blks-res <0-7>", + CD_STR + "Set number of blocks reserved for access grant\n" + "Number of blocks reserved for access grant\n") +{ + struct gsm_bts *bts = vty->index; + int bs_ag_blks_res = atoi(argv[0]); + + bts->si_common.chan_desc.bs_ag_blks_res = bs_ag_blks_res; + return CMD_SUCCESS; +} + #define NM_STR "Network Management\n" DEFUN(cfg_bts_rach_nm_b_thresh, @@ -2942,6 +2998,9 @@ int bsc_vty_init(const struct log_info *cat) install_element(BTS_NODE, &cfg_bts_challoc_cmd); install_element(BTS_NODE, &cfg_bts_rach_tx_integer_cmd); install_element(BTS_NODE, &cfg_bts_rach_max_trans_cmd); + install_element(BTS_NODE, &cfg_bts_chan_desc_att_cmd); + install_element(BTS_NODE, &cfg_bts_chan_desc_bs_pa_mfrms_cmd); + install_element(BTS_NODE, &cfg_bts_chan_desc_bs_ag_blks_res_cmd); install_element(BTS_NODE, &cfg_bts_rach_nm_b_thresh_cmd); install_element(BTS_NODE, &cfg_bts_rach_nm_ldavg_cmd); install_element(BTS_NODE, &cfg_bts_cell_barred_cmd); diff --git a/openbsc/src/libcommon/gsm_data.c b/openbsc/src/libcommon/gsm_data.c index 8b030e9..352700a 100644 --- a/openbsc/src/libcommon/gsm_data.c +++ b/openbsc/src/libcommon/gsm_data.c @@ -405,6 +405,9 @@ struct gsm_bts *gsm_bts_alloc_register(struct gsm_network *net, enum gsm_bts_typ bts->si_common.rach_control.tx_integer = 9; /* 12 slots spread - 217/115 slots delay */ bts->si_common.rach_control.max_trans = 3; /* 7 retransmissions */ bts->si_common.rach_control.t2 = 4; /* no emergency calls */ + bts->si_common.chan_desc.att = 1; /* attachment required */ + bts->si_common.chan_desc.bs_pa_mfrms = RSL_BS_PA_MFRMS_5; /* paging frames */ + bts->si_common.chan_desc.bs_ag_blks_res = 1; /* reserved AGCH blocks */ llist_add_tail(&bts->list, &net->bts_list); -- 1.7.3.4 --------------090206010508020805000207-- From laforge at gnumonks.org Thu Oct 18 10:01:54 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 18 Oct 2012 12:01:54 +0200 Subject: patch to allow setting of various control channel description parameters In-Reply-To: <5078FEFE.3030202@eversberg.eu> References: <5078FEFE.3030202@eversberg.eu> Message-ID: <20121018100154.GZ18868@prithivi.gnumonks.org> Hi jolly, On Sat, Oct 13, 2012 at 07:41:18AM +0200, jolly wrote: > this patch allows to tune control channel. it can be used to speed up > GPRS TBF establishment. thanks, applied. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Mon Oct 15 07:42:44 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Oct 2012 09:42:44 +0200 Subject: 29C3 osmo-nitb sprint and issues Message-ID: <20121015074244.GF20812@xiaoyu.lan> Hi, as indicated in the previous mail there are some things to be done before we get to the venue. I would like to experiment with sprints to solve some of the stability issues we had with osmo-nitb. The idea is that we assemble (physically or online) and work on some specific issues of osmo-nitb that impact the quality of service for the upcoming event. I can provide food and snacks during these sprints and guidance on OpenBSC code. The first sprint is scheduled for the 9th, 10th (and maybe 11th) of November. There is no venue for it yet, maybe the CCCB. Please indicate if you are interested to join. The general list of osmo-nitb issues are: * Channel release process. There is a branch I created at the last congress but I have never tested it. This includes making a SAPI=3 local release, using the proper timeouts for the abnormal release making sure the SACCH is deactivated and some more issues. This requires quite a bit of testing. * Allow to block/unblock failing lchans. We have had this issue with Nokia BTS but it can happen on other BTS as well. E.g. a given timeslot might not be allocatable, or we get LCHAN ACT NACK. In that case OpenBSC should block the lchan. * smsqueue/auth/paths. In the past years we have seen that the smsqueue and other parts can get stuck because of the 'subscr_get_con' not being properly called in all error conditions. We need to review the code and check how things get stuck. * Handover testing and patching out the 'timestamp' adjusting or fixing it. Right now it can be used to add a lot of delay by switching cells. cheers holger From brian at movirtu.com Mon Oct 15 07:47:46 2012 From: brian at movirtu.com (Dingani Brian Nkala) Date: Mon, 15 Oct 2012 08:47:46 +0100 Subject: IP Access nanobts dropping OML link to OpenBSC Message-ID: Hi All, I'm very new to OpenBSC and nanoBTS (but have quite a bit of experience in telecoms in general). I recently acquired a brand new ip.access nanoBTS (nanoGSM) for a project I'm working on and I promptly installed OpenBSC on Ubuntu 11.04 successfully without any headaches. So far I've managed to do an "ipaccess-find" and found the BTS, and also set the Unit ID of the nanoBTS + OML address using the "ipaccess-config" utility. My problem is, when I startup osmo-nitb, I can see the BTS trying to connect and then it sends a NACK and OpenBSC drops the links. Below is the output I get on the screen when I startup osmo-nitb: /home/beta/libosmocore/openbsc/openbsc/src/osmo-nitb# ./osmo-nitb -debug=DRLL:DCC:DMM:DRR:DRSL:DNM:DSMS:DMNSMS:DDB:DMEAS -c openbsc.cfg DB: Database initialized. DB: Database prepared. <0007> sms_queue.c:232 Attempting to send 20 SMS <0007> sms_queue.c:292 SMSqueue added 0 messages in 0 rounds <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 32 37 62 31 34 64 30 00 <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Software Activated Report <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 32 37 62 31 34 64 30 00 <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 32 37 62 31 34 64 30 00 <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) OPSTART NACK CAUSE=Message cannot be performed <0005> bsc_init.c:54 Got a NACK going to drop the OML links. <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 32 37 62 31 34 64 30 00 <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Software Activated Report <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 32 37 62 31 34 64 30 00 <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 32 37 62 31 34 64 30 00 <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) OPSTART NACK CAUSE=Message cannot be performed <0005> bsc_init.c:54 Got a NACK going to drop the OML links. And the config file: cat openbsc.cfg ! ! OpenBSC configuration saved from vty ! ! password foo ! line vty no login ! e1_input e1_line 0 driver ipa network network country code 1 mobile network code 1 short name OpenBSC long name OpenBSC auth policy closed location updating reject cause 13 encryption a5 0 neci 1 rrlp mode none mm info 1 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 timer t3101 10 timer t3103 0 timer t3105 0 timer t3107 0 timer t3109 0 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3141 0 bts 0 type nanobts band DCS1800 cell_identity 0 location_area_code 1 training_sequence_code 7 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 channel allocator ascending rach tx integer 9 rach max transmission 7 ip.access unit_id 1801 0 oml ip.access stream_id 255 line 0 gprs mode none trx 0 rf_locked 0 arfcn 514 nominal power 23 max_power_red 20 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 timeslot 1 phys_chan_config SDCCH8 timeslot 2 phys_chan_config TCH/F timeslot 3 phys_chan_config TCH/F timeslot 4 phys_chan_config TCH/F timeslot 5 phys_chan_config TCH/F timeslot 6 phys_chan_config TCH/F timeslot 7 phys_chan_config TCH/F Thanks in advance. -- Dee From laforge at gnumonks.org Sun Oct 21 08:50:36 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 21 Oct 2012 10:50:36 +0200 Subject: IP Access nanobts dropping OML link to OpenBSC In-Reply-To: References: Message-ID: <20121021085036.GF31164@prithivi.gnumonks.org> This NACK might very well be some incompatibility between the specific nanoBTS firmware version and current OpenBSC. I would be useful if you could provide a full pcap trace of the exchange between BTS and OpenBSC. (tcpdump -ni eth0 -s0 -w/tmp/trace.pcap or the like). Have you looked at the protocol trace yet in wireshark? What kind of details can you see about that OPSTART NACK message? Regards, Harald On Mon, Oct 15, 2012 at 08:47:46AM +0100, Dingani Brian Nkala wrote: > Hi All, > > I'm very new to OpenBSC and nanoBTS (but have quite a bit of experience in > telecoms in general). I recently acquired a brand new ip.access nanoBTS > (nanoGSM) for a project I'm working on and I promptly installed OpenBSC on > Ubuntu 11.04 successfully without any headaches. So far I've managed to do > an "ipaccess-find" and found the BTS, and also set the Unit ID of the > nanoBTS + OML address using the "ipaccess-config" utility. My problem is, > when I startup osmo-nitb, I can see the BTS trying to connect and then it > sends a NACK and OpenBSC drops the links. Below is the output I get on the > screen when I startup osmo-nitb: > > /home/beta/libosmocore/openbsc/openbsc/src/osmo-nitb# ./osmo-nitb > -debug=DRLL:DCC:DMM:DRR:DRSL:DNM:DSMS:DMNSMS:DDB:DMEAS -c openbsc.cfg > DB: Database initialized. > DB: Database prepared. > <0007> sms_queue.c:232 Attempting to send 20 SMS > <0007> sms_queue.c:292 SMSqueue added 0 messages in 0 rounds > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE > CHG: OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) SW Activate > Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and > Activating > <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 > 00 13 00 0a 76 31 32 37 62 31 34 64 30 00 > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Software > Activated Report > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART > <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) SW Activate Request: > <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 > 00 13 00 0a 76 31 32 37 62 31 34 64 30 00 > <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) SW Activate > Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and > Activating > <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 > 00 13 00 0a 76 31 32 37 62 31 34 64 30 00 > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: > OP_STATE=Enabled > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) OPSTART NACK > CAUSE=Message cannot be performed > <0005> bsc_init.c:54 Got a NACK going to drop the OML links. > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE > CHG: OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) SW Activate > Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and > Activating > <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 > 00 13 00 0a 76 31 32 37 62 31 34 64 30 00 > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Software > Activated Report > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART > <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) SW Activate Request: > <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 > 00 13 00 0a 76 31 32 37 62 31 34 64 30 00 > <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) SW Activate > Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and > Activating > <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 > 00 13 00 0a 76 31 32 37 62 31 34 64 30 00 > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: > OP_STATE=Enabled > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) OPSTART NACK > CAUSE=Message cannot be performed > <0005> bsc_init.c:54 Got a NACK going to drop the OML links. > > > And the config file: > > cat openbsc.cfg > ! > ! OpenBSC configuration saved from vty > ! ! > password foo > ! > line vty > no login > ! > e1_input > e1_line 0 driver ipa > network > network country code 1 > mobile network code 1 > short name OpenBSC > long name OpenBSC > auth policy closed > location updating reject cause 13 > encryption a5 0 > neci 1 > rrlp mode none > mm info 1 > handover 0 > handover window rxlev averaging 10 > handover window rxqual averaging 1 > handover window rxlev neighbor averaging 10 > handover power budget interval 6 > handover power budget hysteresis 3 > handover maximum distance 9999 > timer t3101 10 > timer t3103 0 > timer t3105 0 > timer t3107 0 > timer t3109 0 > timer t3111 0 > timer t3113 60 > timer t3115 0 > timer t3117 0 > timer t3119 0 > timer t3141 0 > bts 0 > type nanobts > band DCS1800 > cell_identity 0 > location_area_code 1 > training_sequence_code 7 > base_station_id_code 63 > ms max power 15 > cell reselection hysteresis 4 > rxlev access min 0 > channel allocator ascending > rach tx integer 9 > rach max transmission 7 > ip.access unit_id 1801 0 > oml ip.access stream_id 255 line 0 > gprs mode none > trx 0 > rf_locked 0 > arfcn 514 > nominal power 23 > max_power_red 20 > rsl e1 tei 0 > timeslot 0 > phys_chan_config CCCH+SDCCH4 > timeslot 1 > phys_chan_config SDCCH8 > timeslot 2 > phys_chan_config TCH/F > timeslot 3 > phys_chan_config TCH/F > timeslot 4 > phys_chan_config TCH/F > timeslot 5 > phys_chan_config TCH/F > timeslot 6 > phys_chan_config TCH/F > timeslot 7 > phys_chan_config TCH/F > > > Thanks in advance. > > -- > Dee > > > > -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From kelum.nava at gmail.com Mon Oct 15 16:24:10 2012 From: kelum.nava at gmail.com (Kelum Navaratne) Date: Mon, 15 Oct 2012 21:54:10 +0530 Subject: OpenBSC with LCR/SIP Message-ID: Hello list, First of all congratulation to developers of this project making such wonderful project in an interesting subject. I am new to this project and for past few days i managed to go through the documentation and get most of it tested. Thanks for pretty good documentation in most of the areas as well. I have the osmo-nitb working very fine using a nano bts. How ever when i try to install it with LCR to interconnect with external switch, im facing some problems. Initially i thought i must use LCR+Asterisk. But later i figured out there is a built in SIP interface on LCR which there is no need to asterisk or chan_asterisk. I would prefer to use this LCR SIP interface as i dont want to use asterisk and just want to forward all calls to another SIP switch. Now in this context there seems absolutely no documentation on both openbsc and LCR/mISDN lists. Can some one please shed me some light here on how to build a LCR with SIP to be work with osmo-nitb. All i want to test is GSM phone > Osmo-nitb > LCR with SIP > SIP softswitch Thank you very much for every one's effort in this project and would be glad to see some response for this. Best Regards Nava. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Mon Oct 15 17:27:15 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Mon, 15 Oct 2012 22:57:15 +0530 Subject: OpenBSC with LCR/SIP In-Reply-To: References: Message-ID: Hi Nava, I have tried the same some time ago. LCR-SIP implementation seems very nice in what you trying to do without using asterisk. I managed to get calls ring back and forward in a similar setup but i was running into serious problems with RTP/media. This was mainly due to transcoding or rtp-bridge functions. I was some what successful with the help from andreas but could not make it work 100%. May be now there is a fix for the rtp issues which i never tried after that. Give it a try using the latest git clone from LCR and see. As i can remember you need to check out jolly/rtpmux branch in order to get this working. Andreas can give some hint if possible on this. Good luck. Nik. On Mon, Oct 15, 2012 at 9:54 PM, Kelum Navaratne wrote: > Hello list, > > First of all congratulation to developers of this project making such > wonderful project in an interesting subject. I am new to this project and > for past few days i managed to go through the documentation and get most of > it tested. Thanks for pretty good documentation in most of the areas as > well. > > I have the osmo-nitb working very fine using a nano bts. > > How ever when i try to install it with LCR to interconnect with external > switch, im facing some problems. Initially i thought i must use > LCR+Asterisk. But later i figured out there is a built in SIP interface on > LCR which there is no need to asterisk or chan_asterisk. I would prefer to > use this LCR SIP interface as i dont want to use asterisk and just want to > forward all calls to another SIP switch. > > Now in this context there seems absolutely no documentation on both > openbsc and LCR/mISDN lists. > > Can some one please shed me some light here on how to build a LCR with SIP > to be work with osmo-nitb. > > All i want to test is > > GSM phone > Osmo-nitb > LCR with SIP > SIP softswitch > > Thank you very much for every one's effort in this project and would be > glad to see some response for this. > > Best Regards > Nava. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at eversberg.eu Tue Oct 16 08:21:58 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Tue, 16 Oct 2012 10:21:58 +0200 Subject: OpenBSC with LCR/SIP In-Reply-To: References: Message-ID: <507D1926.8070504@eversberg.eu> hi kelum, in order to use sip, you need jolly/new branch of lcr and jolly/rtpmux of openbsc. the sip implementation of LCR is quite simple, so no authentication or oder features - just simple point-to-point SIP. if you run confiure of LCR, check if sip is enabled. in order to add a SIP interface, do the following at interface.conf: [sip] sip [:] [:] earlyb yes tones no you need to define local IP that will be used to connect to remote SIP endpoint. don't use localhost, if the endpoint is on a different machine, because this IP is also used for RTP. if you use same machine, you need to have different ports. you may change local port, by adding a local port or you may change port of SIP endpoint and then add remote port. i have tested it with freeswitch, but asterisk should work also. you may then also try at interface.conf below "[sip]" definition: rtp-brige then the codec (full rate or enhanced full rate) is negotiated between mobile and the remote SIP endpoint. the SIP endpoint must support at least one of it. regards, andreas From kelum.nava at gmail.com Tue Oct 16 13:19:08 2012 From: kelum.nava at gmail.com (Kelum Navaratne) Date: Tue, 16 Oct 2012 18:49:08 +0530 Subject: OpenBSC with LCR/SIP In-Reply-To: <507D1926.8070504@eversberg.eu> References: <507D1926.8070504@eversberg.eu> Message-ID: Hi Andreas, Thank you very much. This is a good start for me. I also need to work with freeswitch. Not asterisk. And simple point to point sip is more than enough and rtp bridge would be fantastic. Would it work with amr codec as well ? Or only gsm full rate/ h. Rate? Im trying to find the lcr git location of jolly/new. Can you please give me the url. I cant find it on openbsc git. Thanks again. Nava. On Tuesday, October 16, 2012, Andreas Eversberg wrote: > hi kelum, > > in order to use sip, you need jolly/new branch of lcr and jolly/rtpmux of > openbsc. the sip implementation of LCR is quite simple, so no > authentication or oder features - just simple point-to-point SIP. if you > run confiure of LCR, check if sip is enabled. in order to add a SIP > interface, do the following at interface.conf: > > [sip] > sip [:] [:] > earlyb yes > tones no > > you need to define local IP that will be used to connect to remote SIP > endpoint. don't use localhost, if the endpoint is on a different machine, > because this IP is also used for RTP. if you use same machine, you need to > have different ports. you may change local port, by adding a local port or > you may change port of SIP endpoint and then add remote port. > > i have tested it with freeswitch, but asterisk should work also. > > you may then also try at interface.conf below "[sip]" definition: > > rtp-brige > > then the codec (full rate or enhanced full rate) is negotiated between > mobile and the remote SIP endpoint. the SIP endpoint must support at least > one of it. > > regards, > > andreas > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller.lennart at googlemail.com Tue Oct 16 08:44:00 2012 From: mueller.lennart at googlemail.com (=?ISO-8859-1?Q?Lennart_M=FCller?=) Date: Tue, 16 Oct 2012 10:44:00 +0200 Subject: Bad signalling message Message-ID: Hi, some problems with latest git clone and nanoBTS 165AU... <0002> gsm_04_08.c:412 -> LOCATION UPDATE ACCEPT <0001> gsm_04_08.c:116 (bts 0 trx 0 ts 0 pd 05) Sending 0x02 to MS. <0002> gsm_04_08.c:754 -> MM INFO <0001> gsm_04_08.c:116 (bts 0 trx 0 ts 0 pd 05) Sending 0x32 to MS. <0002> gsm_subscriber.c:337 Subscriber 262620001000026 ATTACHED LAC=10 <0003> gsm_04_08.c:1158 TX APPLICATION INFO id=0x00, len=4 <0001> gsm_04_08.c:116 (bts 0 trx 0 ts 0 pd 06) Sending 0x38 to MS. <0000> abis_rsl.c:1542 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0002> gsm_04_08.c:1045 TMSI Reallocation Completed. Subscriber: 262620001000026 <0000> chan_alloc.c:429 (bts=0,trx=0,ts=0,ss=0) starting release sequence <0003> gsm_04_08_utils.c:231 Sending Channel Release: Chan: Number: 0 Type: 1 <0004> abis_rsl.c:618 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1017 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel <0004> abis_rsl.c:1017 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel <0000> abis_rsl.c:1542 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0004> bsc_api.c:638 Got data in non active state(RELEASE REQUESTED), discarding. <0019> input/ipaccess.c:454 Bad signalling message,sign_link returned error <0019> input/ipaccess.c:260 Forcing socket shutdown with no signal link set <001b> bsc_init.c:337 Lost some E1 TEI link: 1 0x81e4768 <001b> bsc_init.c:337 Lost some E1 TEI link: 2 0x81e4768 I have no clue if that is a problem of configuration, nanoBTS or abis library. With an old version (Feb 2012), the message... <0019> ipaccess.c:425 Bad signalling message,sign_link returned error. ...appears too, but socket is not being shut down. Thanks, LM -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo at gnumonks.org Tue Oct 16 09:26:55 2012 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Tue, 16 Oct 2012 11:26:55 +0200 Subject: Bad signalling message In-Reply-To: References: Message-ID: <20121016092655.GA17082@1984> On Tue, Oct 16, 2012 at 10:44:00AM +0200, Lennart M?ller wrote: > Hi, > > some problems with latest git clone and nanoBTS 165AU... > > <0002> gsm_04_08.c:412 -> LOCATION UPDATE ACCEPT > <0001> gsm_04_08.c:116 (bts 0 trx 0 ts 0 pd 05) Sending 0x02 to MS. > <0002> gsm_04_08.c:754 -> MM INFO > <0001> gsm_04_08.c:116 (bts 0 trx 0 ts 0 pd 05) Sending 0x32 to MS. > <0002> gsm_subscriber.c:337 Subscriber 262620001000026 ATTACHED LAC=10 > <0003> gsm_04_08.c:1158 TX APPLICATION INFO id=0x00, len=4 > <0001> gsm_04_08.c:116 (bts 0 trx 0 ts 0 pd 06) Sending 0x38 to MS. > <0000> abis_rsl.c:1542 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION > <0002> gsm_04_08.c:1045 TMSI Reallocation Completed. Subscriber: > 262620001000026 > <0000> chan_alloc.c:429 (bts=0,trx=0,ts=0,ss=0) starting release > sequence > <0003> gsm_04_08_utils.c:231 Sending Channel Release: Chan: Number: 0 > Type: 1 > <0004> abis_rsl.c:618 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD > <0004> abis_rsl.c:1017 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive > channel > <0004> abis_rsl.c:1017 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive > channel > <0000> abis_rsl.c:1542 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION > <0004> bsc_api.c:638 Got data in non active state(RELEASE REQUESTED), > discarding. > <0019> input/ipaccess.c:454 Bad signalling message,sign_link returned > error > <0019> input/ipaccess.c:260 Forcing socket shutdown with no signal link > set > <001b> bsc_init.c:337 Lost some E1 TEI link: 1 0x81e4768 > <001b> bsc_init.c:337 Lost some E1 TEI link: 2 0x81e4768 > > I have no clue if that is a problem of configuration, nanoBTS or abis > library. With an old version (Feb 2012), the message... > > <0019> ipaccess.c:425 Bad signalling message,sign_link returned error. > > ...appears too, but socket is not being shut down. This was recently changed to perform robust error handling. But thinking it's too much to close the signalling link on recoverable errors coming from the signalling layer. Would you give a try to the following patch? Thanks. From pablo at gnumonks.org Tue Oct 16 09:24:08 2012 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Tue, 16 Oct 2012 11:24:08 +0200 Subject: [PATCH] ipaccess: relax default behaviour on errors coming from signalling layer Message-ID: This patch relaxes the behaviour on error coming from the signalling layer. This is probably too strict for recoverable errors. Thanks to Lennart M?ller for the report. --- src/input/ipaccess.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/input/ipaccess.c b/src/input/ipaccess.c index d63e796..4f81c43 100644 --- a/src/input/ipaccess.c +++ b/src/input/ipaccess.c @@ -450,10 +450,13 @@ static int handle_ts1_read(struct osmo_fd *bfd) goto err_msg; } if (e1i_ts->line->ops->sign_link(msg) < 0) { + /* Don't close the signalling link if the upper layers report + * an error, that's too strict. + */ LOGP(DLINP, LOGL_ERROR, "Bad signalling message," "sign_link returned error\n"); ret = -EINVAL; - goto err; + msgb_free(msg); } return 0; -- 1.7.10.4 --LZvS9be/3tNcYl/X-- From mueller.lennart at googlemail.com Tue Oct 16 11:11:34 2012 From: mueller.lennart at googlemail.com (=?ISO-8859-1?Q?Lennart_M=FCller?=) Date: Tue, 16 Oct 2012 13:11:34 +0200 Subject: Bad signalling message In-Reply-To: <20121016092655.GA17082@1984> References: <20121016092655.GA17082@1984> Message-ID: 2012/10/16 Pablo Neira Ayuso > This was recently changed to perform robust error handling. > > But thinking it's too much to close the signalling link on recoverable > errors coming from the signalling layer. > > Would you give a try to the following patch? Thanks. > Hi Pablo, thanks for the patch. msgb_free(msg); causes signal 6, I tried the following and it works, but might cause a memory leak... if (e1i_ts->line->ops->sign_link(msg) < 0) { /* Don't close the signalling link if the upper layers report * an error, that's too strict. */ LOGP(DLINP, LOGL_ERROR, "Bad signalling message," "sign_link returned error\n"); ret = -EINVAL; //msgb_free(msg); return(ret); } LM -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo at gnumonks.org Tue Oct 16 12:07:14 2012 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Tue, 16 Oct 2012 14:07:14 +0200 Subject: Bad signalling message In-Reply-To: References: <20121016092655.GA17082@1984> Message-ID: <20121016120714.GA28171@1984> On Tue, Oct 16, 2012 at 01:11:34PM +0200, Lennart M?ller wrote: [...] > Hi Pablo, > thanks for the patch. > msgb_free(msg); causes signal 6, I tried the following and it works, > but might cause a memory leak... > > if (e1i_ts->line->ops->sign_link(msg) < 0) { > /* Don't close the signalling link if the upper layers report > * an error, that's too strict. > */ > LOGP(DLINP, LOGL_ERROR, "Bad signalling message," > "sign_link returned error\n"); > ret = -EINVAL; > //msgb_free(msg); > return(ret); I see. I guess you were hitting SIGABRT also before the patch then. New patch attached. If you're OK with it, I'll push it to git. From pablo at gnumonks.org Tue Oct 16 09:24:08 2012 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Tue, 16 Oct 2012 11:24:08 +0200 Subject: [PATCH] ipaccess: relax default behaviour on errors coming from signalling layer Message-ID: This patch relaxes the behaviour on error coming from the signalling layer. This is probably too strict for recoverable errors. Don't release msgb in this case, as this is controled by the signaling link layer. Thanks to Lennart M?ller for the report. --- src/input/ipaccess.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/input/ipaccess.c b/src/input/ipaccess.c index d63e796..c0c307e 100644 --- a/src/input/ipaccess.c +++ b/src/input/ipaccess.c @@ -450,10 +450,13 @@ static int handle_ts1_read(struct osmo_fd *bfd) goto err_msg; } if (e1i_ts->line->ops->sign_link(msg) < 0) { + /* Don't close the signalling link if the upper layers report + * an error, that's too strict. BTW, the signalling layer is + * resposible for releasing the message. + */ LOGP(DLINP, LOGL_ERROR, "Bad signalling message," "sign_link returned error\n"); ret = -EINVAL; - goto err; } return 0; -- 1.7.10.4 --ibTvN161/egqYuK8-- From holger at freyther.de Tue Oct 16 12:23:51 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 16 Oct 2012 14:23:51 +0200 Subject: Bad signalling message In-Reply-To: <20121016120714.GA28171@1984> References: <20121016092655.GA17082@1984> <20121016120714.GA28171@1984> Message-ID: <20121016122351.GA24367@xiaoyu.lan> On Tue, Oct 16, 2012 at 02:07:14PM +0200, Pablo Neira Ayuso wrote: > I see. I guess you were hitting SIGABRT also before the patch then. > > New patch attached. If you're OK with it, I'll push it to git. Hi Pablo, please be careful about the semantic. What is the semantic when calling the callback? Does the called one always need to free the msgb? is that the case with all users of libosmo-abis? thanks holger From pablo at gnumonks.org Tue Oct 16 13:43:00 2012 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Tue, 16 Oct 2012 15:43:00 +0200 Subject: Bad signalling message In-Reply-To: <20121016122351.GA24367@xiaoyu.lan> References: <20121016092655.GA17082@1984> <20121016120714.GA28171@1984> <20121016122351.GA24367@xiaoyu.lan> Message-ID: <20121016134300.GA2364@1984> Hi Holger, On Tue, Oct 16, 2012 at 02:23:51PM +0200, Holger Hans Peter Freyther wrote: > On Tue, Oct 16, 2012 at 02:07:14PM +0200, Pablo Neira Ayuso wrote: > > I see. I guess you were hitting SIGABRT also before the patch then. > > > > New patch attached. If you're OK with it, I'll push it to git. > > Hi Pablo, > > please be careful about the semantic. What is the semantic when calling > the callback? Does the called one always need to free the msgb? is that > the case with all users of libosmo-abis? ->sign_link(...) calls abis_nm_rcvmsg / abis_rsl_rcvmsg that release the msgb. Still, there some error paths in abis_nm_rcvmsg that leak the msgb: if (oh->placement != ABIS_OM_PLACEMENT_ONLY) ... if (oh->sequence != 0) ... switch (oh->mdisc): unknown oh->mdisc But in the general path, the semantic is consistent. I'll send a patch to fix this for openbsc. In conclusion, I think my patch is correct, please ack and I'll push to git. From peter at stuge.se Tue Oct 16 13:29:38 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 16 Oct 2012 15:29:38 +0200 Subject: Bad signalling message In-Reply-To: <20121016120714.GA28171@1984> References: <20121016092655.GA17082@1984> <20121016120714.GA28171@1984> Message-ID: <20121016132938.8808.qmail@stuge.se> Pablo Neira Ayuso wrote: > +++ b/src/input/ipaccess.c > @@ -450,10 +450,13 @@ static int handle_ts1_read(struct osmo_fd *bfd) > goto err_msg; > } > if (e1i_ts->line->ops->sign_link(msg) < 0) { > + /* Don't close the signalling link if the upper layers report > + * an error, that's too strict. BTW, the signalling layer is > + * resposible for releasing the message. > + */ > LOGP(DLINP, LOGL_ERROR, "Bad signalling message," > "sign_link returned error\n"); > ret = -EINVAL; > - goto err; > } > > return 0; If the code flow will be to fall through to the 'return 0' statement then I suggest to also remove the ret = -EINVAL line inside the condition. I think it creates some confusion about what is really intended. //Peter From pablo at gnumonks.org Tue Oct 16 14:33:12 2012 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Tue, 16 Oct 2012 16:33:12 +0200 Subject: Bad signalling message In-Reply-To: <20121016132938.8808.qmail@stuge.se> References: <20121016092655.GA17082@1984> <20121016120714.GA28171@1984> <20121016132938.8808.qmail@stuge.se> Message-ID: <20121016143312.GA6191@1984> On Tue, Oct 16, 2012 at 03:29:38PM +0200, Peter Stuge wrote: > Pablo Neira Ayuso wrote: > > +++ b/src/input/ipaccess.c > > @@ -450,10 +450,13 @@ static int handle_ts1_read(struct osmo_fd *bfd) > > goto err_msg; > > } > > if (e1i_ts->line->ops->sign_link(msg) < 0) { > > + /* Don't close the signalling link if the upper layers report > > + * an error, that's too strict. BTW, the signalling layer is > > + * resposible for releasing the message. > > + */ > > LOGP(DLINP, LOGL_ERROR, "Bad signalling message," > > "sign_link returned error\n"); > > ret = -EINVAL; > > - goto err; > > } > > > > return 0; > > If the code flow will be to fall through to the 'return 0' statement > then I suggest to also remove the ret = -EINVAL line inside the > condition. I think it creates some confusion about what is really > intended. Right Peter, I'll mangle the patch to do so. Thanks. From pablo at gnumonks.org Tue Oct 16 16:23:17 2012 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Tue, 16 Oct 2012 18:23:17 +0200 Subject: [PATCH] libbsc: fix message leaks on several error paths Message-ID: <1350404597-6616-1-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patch fixes several leak of msgbs in uncommon error paths. --- openbsc/src/libbsc/abis_nm.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/openbsc/src/libbsc/abis_nm.c b/openbsc/src/libbsc/abis_nm.c index ee0dd60..2c8b3ee 100644 --- a/openbsc/src/libbsc/abis_nm.c +++ b/openbsc/src/libbsc/abis_nm.c @@ -635,13 +635,16 @@ int abis_nm_rcvmsg(struct msgb *msg) if (oh->placement != ABIS_OM_PLACEMENT_ONLY) { LOGP(DNM, LOGL_ERROR, "ABIS OML placement 0x%x not supported\n", oh->placement); - if (oh->placement != ABIS_OM_PLACEMENT_FIRST) - return -EINVAL; + if (oh->placement != ABIS_OM_PLACEMENT_FIRST) { + rc = -EINVAL; + goto err; + } } if (oh->sequence != 0) { LOGP(DNM, LOGL_ERROR, "ABIS OML sequence 0x%x != 0x00\n", oh->sequence); - return -EINVAL; + rc = -EINVAL; + goto err; } #if 0 unsigned int l2_len = msg->tail - (uint8_t *)msgb_l2(msg); @@ -671,9 +674,9 @@ int abis_nm_rcvmsg(struct msgb *msg) default: LOGP(DNM, LOGL_ERROR, "unknown ABIS OML message discriminator 0x%x\n", oh->mdisc); - return -EINVAL; + rc = -EINVAL; } - +err: msgb_free(msg); return rc; } -- 1.7.10.4 From peter at stuge.se Tue Oct 16 16:46:05 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 16 Oct 2012 18:46:05 +0200 Subject: [PATCH] libbsc: fix message leaks on several error paths In-Reply-To: <1350404597-6616-1-git-send-email-pablo@gnumonks.org> References: <1350404597-6616-1-git-send-email-pablo@gnumonks.org> Message-ID: <20121016164605.27457.qmail@stuge.se> pablo at gnumonks.org wrote: > @@ -671,9 +674,9 @@ int abis_nm_rcvmsg(struct msgb *msg) > default: > LOGP(DNM, LOGL_ERROR, "unknown ABIS OML message discriminator 0x%x\n", > oh->mdisc); > - return -EINVAL; > + rc = -EINVAL; > } It looks like this is at the end of a switch () statement, so maybe it is a good idea to include a goto statement for clarity, even if that is not absolutely neccessary given how the code looks right now. > - > +err: > msgb_free(msg); > return rc; > } Since the label is not only an error path but also reached during successful flow through the function I suggest to name it something like "done" instead. Thanks a lot for fixing these leaks! //Peter From peter at stuge.se Tue Oct 16 16:53:29 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 16 Oct 2012 18:53:29 +0200 Subject: [PATCH] libbsc: fix message leaks on several error paths In-Reply-To: <20121016164605.27457.qmail@stuge.se> References: <1350404597-6616-1-git-send-email-pablo@gnumonks.org> <20121016164605.27457.qmail@stuge.se> Message-ID: <20121016165329.28265.qmail@stuge.se> Peter Stuge wrote: > > @@ -671,9 +674,9 @@ int abis_nm_rcvmsg(struct msgb *msg) > > default: > > LOGP(DNM, LOGL_ERROR, "unknown ABIS OML message discriminator 0x%x\n", > > oh->mdisc); > > - return -EINVAL; > > + rc = -EINVAL; > > } > > It looks like this is at the end of a switch () statement, so maybe > it is a good idea to include a goto statement for clarity, even if > that is not absolutely neccessary given how the code looks right now. A break; would also be fine I think. Anything to make the flow explicit. //Peter From pablo at gnumonks.org Thu Oct 18 12:19:43 2012 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Thu, 18 Oct 2012 14:19:43 +0200 Subject: [PATCH] libbsc: fix message leaks on several error paths In-Reply-To: <20121016164605.27457.qmail@stuge.se> References: <1350404597-6616-1-git-send-email-pablo@gnumonks.org> <20121016164605.27457.qmail@stuge.se> Message-ID: <20121018121943.GA30436@1984> Hi Peter, On Tue, Oct 16, 2012 at 06:46:05PM +0200, Peter Stuge wrote: > pablo at gnumonks.org wrote: > > @@ -671,9 +674,9 @@ int abis_nm_rcvmsg(struct msgb *msg) > > default: > > LOGP(DNM, LOGL_ERROR, "unknown ABIS OML message discriminator 0x%x\n", > > oh->mdisc); > > - return -EINVAL; > > + rc = -EINVAL; > > } > > It looks like this is at the end of a switch () statement, so maybe > it is a good idea to include a goto statement for clarity, even if > that is not absolutely neccessary given how the code looks right now. > > > > - > > +err: > > msgb_free(msg); > > return rc; > > } > > Since the label is not only an error path but also reached during > successful flow through the function I suggest to name it something > like "done" instead. at the risk of being annoying, I think the patch is good as is. I don't want that this becomes a "bikeshed color" discussion [1], I think the code changes are clear enough. Thanks for your feedback. [1] http://bikeshed.com/ From holger at freyther.de Thu Oct 18 13:09:10 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 18 Oct 2012 15:09:10 +0200 Subject: [PATCH] libbsc: fix message leaks on several error paths In-Reply-To: <20121018121943.GA30436@1984> References: <1350404597-6616-1-git-send-email-pablo@gnumonks.org> <20121016164605.27457.qmail@stuge.se> <20121018121943.GA30436@1984> Message-ID: <20121018130910.GC14524@xiaoyu.lan> On Thu, Oct 18, 2012 at 02:19:43PM +0200, Pablo Neira Ayuso wrote: > I don't want that this becomes a "bikeshed color" discussion [1], I > think the code changes are clear enough. well, there is no way I build a nuclear power plant so the bikeshed is all I have. :) I kind of agree with peter that a 'break' in the default would be nice. It is just one of the habbits (including me writing code like return X;break;). Anyway, feel free to commit the leak fixes. PS: I find it amusing how after a month suddenly no day passes without someone saying his nanoBTS is dropped. So I would like to keep the 'dropping' until someone feels encouraged enough to create a PCAP file and we fix the 'bad' return statement. From pablo at gnumonks.org Thu Oct 18 19:09:25 2012 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Thu, 18 Oct 2012 21:09:25 +0200 Subject: [PATCH] libbsc: fix message leaks on several error paths In-Reply-To: <20121018130910.GC14524@xiaoyu.lan> References: <1350404597-6616-1-git-send-email-pablo@gnumonks.org> <20121016164605.27457.qmail@stuge.se> <20121018121943.GA30436@1984> <20121018130910.GC14524@xiaoyu.lan> Message-ID: <20121018190925.GA25514@1984> On Thu, Oct 18, 2012 at 03:09:10PM +0200, Holger Hans Peter Freyther wrote: > On Thu, Oct 18, 2012 at 02:19:43PM +0200, Pablo Neira Ayuso wrote: > > I don't want that this becomes a "bikeshed color" discussion [1], I > > think the code changes are clear enough. > > well, there is no way I build a nuclear power plant so the bikeshed > is all I have. :) > > I kind of agree with peter that a 'break' in the default would be > nice. It is just one of the habbits (including me writing code like > return X;break;). > > Anyway, feel free to commit the leak fixes. Will do. I'll change that break as you want it before doing so. > PS: I find it amusing how after a month suddenly no day passes without > someone saying his nanoBTS is dropped. So I would like to keep the > 'dropping' until someone feels encouraged enough to create a PCAP file > and we fix the 'bad' return statement. I pushed the patch to libosmo-abis. I can revert it if you want, or feel free to make it yourself, of course. From holger at freyther.de Thu Oct 18 20:47:55 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 18 Oct 2012 22:47:55 +0200 Subject: [PATCH] libbsc: fix message leaks on several error paths In-Reply-To: <20121018190925.GA25514@1984> References: <1350404597-6616-1-git-send-email-pablo@gnumonks.org> <20121016164605.27457.qmail@stuge.se> <20121018121943.GA30436@1984> <20121018130910.GC14524@xiaoyu.lan> <20121018190925.GA25514@1984> Message-ID: <20121018204755.GE14524@xiaoyu.lan> On Thu, Oct 18, 2012 at 09:09:25PM +0200, Pablo Neira Ayuso wrote: > I pushed the patch to libosmo-abis. I can revert it if you want, or > feel free to make it yourself, of course. Reverting would is too drastic, it just makes me sad that none of the one 2-4 people that experienced this went to the bottom of the problem. We might have some message we should handle, or need to improve the returns in the nitb. holger From peter at stuge.se Thu Oct 18 17:16:43 2012 From: peter at stuge.se (Peter Stuge) Date: Thu, 18 Oct 2012 19:16:43 +0200 Subject: [PATCH] libbsc: fix message leaks on several error paths In-Reply-To: <20121018121943.GA30436@1984> References: <1350404597-6616-1-git-send-email-pablo@gnumonks.org> <20121016164605.27457.qmail@stuge.se> <20121018121943.GA30436@1984> Message-ID: <20121018171643.16909.qmail@stuge.se> Pablo Neira Ayuso wrote: > at the risk of being annoying, I think the patch is good as is. > > I don't want that this becomes a "bikeshed color" discussion [1], > I think the code changes are clear enough. The patch is clear and a great improvement. The code in the file *after patching* could be made more clear with only the minimal changes I mentioned. Of course it is subjective what is clear and not. :) I'm happy to send a follow-up patch once you've plugged the leak! //Peter From pablo at gnumonks.org Thu Oct 18 21:40:27 2012 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Thu, 18 Oct 2012 23:40:27 +0200 Subject: [PATCH] libbsc: fix message leaks on several error paths In-Reply-To: <20121018171643.16909.qmail@stuge.se> References: <1350404597-6616-1-git-send-email-pablo@gnumonks.org> <20121016164605.27457.qmail@stuge.se> <20121018121943.GA30436@1984> <20121018171643.16909.qmail@stuge.se> Message-ID: <20121018214027.GA3385@1984> On Thu, Oct 18, 2012 at 07:16:43PM +0200, Peter Stuge wrote: > Pablo Neira Ayuso wrote: > > at the risk of being annoying, I think the patch is good as is. > > > > I don't want that this becomes a "bikeshed color" discussion [1], > > I think the code changes are clear enough. > > The patch is clear and a great improvement. The code in the file > *after patching* could be made more clear with only the minimal > changes I mentioned. Of course it is subjective what is clear and > not. :) > > I'm happy to send a follow-up patch once you've plugged the leak! Never mind, I already pushed it including the break thing :-) From Nicklas_boe at web.de Tue Oct 16 17:51:32 2012 From: Nicklas_boe at web.de (Nicklas Boecking) Date: Tue, 16 Oct 2012 10:51:32 -0700 Subject: NanoBTS Problems Message-ID: <003301cdabc6$e0e5e710$a2b1b530$@web.de> Hello, I'm working with OpenBSC since 2 month. Currently my OpenBSC setup runs with 2 mobile phones which can communicate A5/1 encrypted with each other. I got several problems while running this system with a NanoBTS. I use osmo-nitb. Entries in my HLR receive wrong time values. The time values of the column "created" and "updated" are exactly 2 hours earlier than they should be. The system time of the controller works fine and the time in the logs from "./osmo-nitb -e 1 -T" is correct. Are there any other timers which work with the NanoBTS? Furthermore my network does not run stable. Sometimes following error occurs : input/ipaccess.c:454 Bad signalling Message, sign link returned error input/ipaccess.c:260 Forcing socket shutdown with no signal link set The error usually appears after some authentification "traffic". Sometimes the system runs stable for several hours without any errors. The error leads to a restart of the connection. I'm not sure if this problem has something to do with the first problem. thanks and best regards! Nicklas -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at eversberg.eu Tue Oct 16 10:07:16 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Tue, 16 Oct 2012 12:07:16 +0200 Subject: NanoBTS Problems In-Reply-To: <003301cdabc6$e0e5e710$a2b1b530$@web.de> References: <003301cdabc6$e0e5e710$a2b1b530$@web.de> Message-ID: <507D31D4.3020006@eversberg.eu> Nicklas Boecking wrote: > input/ipaccess.c:454 Bad signalling Message, sign link returned error hi nicklas, i get these message too somtimes. i just put "return 0;" right below line 454 at ipaccess.c of libosmo-abis to ignore it. then it works. i know that this is not a solution. it would be better to check the message and implement/fix it, or better handle unknown messages correctly. regards, andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Tue Oct 16 13:40:00 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 16 Oct 2012 15:40:00 +0200 Subject: NanoBTS Problems In-Reply-To: <003301cdabc6$e0e5e710$a2b1b530$@web.de> References: <003301cdabc6$e0e5e710$a2b1b530$@web.de> Message-ID: <20121016134000.9640.qmail@stuge.se> Nicklas Boecking wrote: > Entries in my HLR receive wrong time values. The time values of the column > "created" and "updated" are exactly 2 hours earlier than they should be. Is that UTC as opposed to local time? //Peter From laforge at gnumonks.org Thu Oct 18 09:57:30 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 18 Oct 2012 11:57:30 +0200 Subject: NanoBTS Problems In-Reply-To: <003301cdabc6$e0e5e710$a2b1b530$@web.de> References: <003301cdabc6$e0e5e710$a2b1b530$@web.de> Message-ID: <20121018095730.GY18868@prithivi.gnumonks.org> On Tue, Oct 16, 2012 at 10:51:32AM -0700, Nicklas Boecking wrote: > Furthermore my network does not run stable. Sometimes following error occurs > : > > input/ipaccess.c:454 Bad signalling Message, sign link returned error > input/ipaccess.c:260 Forcing socket shutdown with no signal link set I strongly suggest you take a pcap capture file (like "tcpdump -ni eth0 -s0 -w/tmp/my.pcap") and figure out which exact message is causing the problem. Then you forward the relevant portion of the pcap file to this list. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mueller.lennart at googlemail.com Sun Oct 21 18:57:31 2012 From: mueller.lennart at googlemail.com (=?ISO-8859-1?Q?Lennart_M=FCller?=) Date: Sun, 21 Oct 2012 20:57:31 +0200 Subject: NanoBTS Problems In-Reply-To: <20121018095730.GY18868@prithivi.gnumonks.org> References: <003301cdabc6$e0e5e710$a2b1b530$@web.de> <20121018095730.GY18868@prithivi.gnumonks.org> Message-ID: 2012/10/18 Harald Welte > > On Tue, Oct 16, 2012 at 10:51:32AM -0700, Nicklas Boecking wrote: > > Furthermore my network does not run stable. Sometimes following error occurs > > : > > > > input/ipaccess.c:454 Bad signalling Message, sign link returned error > > input/ipaccess.c:260 Forcing socket shutdown with no signal link set > > I strongly suggest you take a pcap capture file (like "tcpdump -ni eth0 > -s0 -w/tmp/my.pcap") and figure out which exact message is causing the > problem. Then you forward the relevant portion of the pcap file to this > list. I've attached a trace, no. 35 (data indication) seems to cause the drop. Regards, L.M. -------------- next part -------------- A non-text attachment was scrubbed... Name: BTS-Trace.pcap Type: application/octet-stream Size: 3658 bytes Desc: not available URL: From laforge at gnumonks.org Mon Oct 22 08:22:45 2012 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 22 Oct 2012 10:22:45 +0200 Subject: NanoBTS Problems In-Reply-To: References: <003301cdabc6$e0e5e710$a2b1b530$@web.de> <20121018095730.GY18868@prithivi.gnumonks.org> Message-ID: <20121022082245.GB16109@prithivi.gnumonks.org> Hi Lennart, On Sun, Oct 21, 2012 at 08:57:31PM +0200, Lennart M?ller wrote: > 2012/10/18 Harald Welte > > I strongly suggest you take a pcap capture file (like "tcpdump -ni eth0 > > -s0 -w/tmp/my.pcap") and figure out which exact message is causing the > > problem. Then you forward the relevant portion of the pcap file to this > > list. > > I've attached a trace, no. 35 (data indication) seems to cause the drop. I'm a bit puzzled by this. "MM STATUS" is handled by gsm48_rx_mm_status() which unconditionally returns '0', i.e. our return value for success. gsm0408_rcv_mm(), the calling function, clearly returns this return value of '0' up to the caller gsm0408_dispatch(), which again returns it to its caller. So from what I can tell in the code, I don't see an obvious path how that message should ever return -1 to libosmo-abis, which then drops the link. It would be useful if you could spend some more time to try to hunt this down, possibly by printing a backtrace using "osmo_log_backtrace(DLINP, LOGL_ERROR)" around line 455 of libosmo-abis/src/input/ipaccess.c within in the section/clause: if (e1i_ts->line->ops->sign_link(msg) < 0) { ... } which is where the 'Bad signalling message' error message is printed first. The backtrace will only be addresses, and you would have to use the symbol table to figure out which function caused it (e.g. by using objdump). Pablo: It actually would make sense to include this call to osmo_log_backtrace() as a default in libosmo-abis, what do you think? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From pablo at gnumonks.org Wed Oct 24 07:32:38 2012 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Wed, 24 Oct 2012 09:32:38 +0200 Subject: NanoBTS Problems In-Reply-To: <20121022082245.GB16109@prithivi.gnumonks.org> References: <003301cdabc6$e0e5e710$a2b1b530$@web.de> <20121018095730.GY18868@prithivi.gnumonks.org> <20121022082245.GB16109@prithivi.gnumonks.org> Message-ID: <20121024073238.GA1202@1984> Hi Harald, On Mon, Oct 22, 2012 at 10:22:45AM +0200, Harald Welte wrote: > Hi Lennart, > > On Sun, Oct 21, 2012 at 08:57:31PM +0200, Lennart M?ller wrote: > > 2012/10/18 Harald Welte > > > I strongly suggest you take a pcap capture file (like "tcpdump -ni eth0 > > > -s0 -w/tmp/my.pcap") and figure out which exact message is causing the > > > problem. Then you forward the relevant portion of the pcap file to this > > > list. > > > > I've attached a trace, no. 35 (data indication) seems to cause the drop. > > I'm a bit puzzled by this. > > "MM STATUS" is handled by gsm48_rx_mm_status() which unconditionally > returns '0', i.e. our return value for success. gsm0408_rcv_mm(), the > calling function, clearly returns this return value of '0' up to the > caller gsm0408_dispatch(), which again returns it to its caller. > > So from what I can tell in the code, I don't see an obvious path how > that message should ever return -1 to libosmo-abis, which then drops the > link. > > It would be useful if you could spend some more time to try to hunt this > down, possibly by printing a backtrace using "osmo_log_backtrace(DLINP, > LOGL_ERROR)" around line 455 of libosmo-abis/src/input/ipaccess.c > within in the section/clause: > > if (e1i_ts->line->ops->sign_link(msg) < 0) { > ... > } > > which is where the 'Bad signalling message' error message is printed > first. The backtrace will only be addresses, and you would have to use > the symbol table to figure out which function caused it (e.g. by using > objdump). > > Pablo: It actually would make sense to include this call to > osmo_log_backtrace() as a default in libosmo-abis, what do you think? Not sure that will help. I can do that but, AFAICS, it will not show the code trace in openbsc that spotted that problem (since we would be already out of its scope once libosmo-abis notices the problem). As an alternative, I can develop some little extension for libosmocore to store the packet that triggered the problem in some file like "ipaccess-bad-signalling-link-DATE.pcap". So we can make sure what packet triggered the problem. Let me know if I'm missing anything. From andrew at carrierdetect.com Thu Oct 18 16:02:51 2012 From: andrew at carrierdetect.com (Andrew Back) Date: Thu, 18 Oct 2012 17:02:51 +0100 Subject: BTS hardware trade. Message-ID: Hello, Is there anyone who has 1800MHz or 900MHz hardware and that would be interested in swapping it for 1900MHz kit? Probably a long shot but worth asking! If so, please contact me off-list. Cheers, Andrew -- Andrew Back http://carrierdetect.com From alexander.chemeris at gmail.com Fri Oct 19 13:27:47 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 19 Oct 2012 17:27:47 +0400 Subject: Fwd: Open-source telecom T-shirts In-Reply-To: References: Message-ID: Sorry to those who receive this message twice. I hope Osmocom community finds this small effort interesting as well. ---------- Forwarded message ---------- From: Alexander Chemeris Date: Fri, Oct 19, 2012 at 5:15 PM Subject: Open-source telecom T-shirts To: umtrx , openbts-discuss at lists.sourceforge.net Hi all, We're thinking about making T-shirts with open-source telecom. I've posted a call for ideas in my OpenBTS blog - please contribute. Telecom needs more openness and you could help us promote this! http://openbts.chemeris.ru/2012/10/reklama-open-source-telecom/ We plan to give them for free to the first 10-20 UmTRX buyers. Then you'll be able to buy them from our web-shop or from one of our friends and distributors. If you proposal gets printed, you'll get a free T-shirt as well. PS If you know a good online T-shirt printing service in US or Europe - drop me a line. I've never done this in US/Europe before. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From yannm1 at hotmail.com Mon Oct 22 12:30:41 2012 From: yannm1 at hotmail.com (Yann R. Moupinda) Date: Mon, 22 Oct 2012 14:30:41 +0200 Subject: No subject Message-ID: Hi guys, Does anyone know if the sysmoBTS has any kind of RADUIS server? By entering the " opkg search *rad* " command i didn't get anything. Best regards Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From yannm1 at hotmail.com Mon Oct 22 12:40:50 2012 From: yannm1 at hotmail.com (Yann R. Moupinda) Date: Mon, 22 Oct 2012 14:40:50 +0200 Subject: RADIUS in sysmoBTS ? In-Reply-To: References: Message-ID: Hi guys, Does anyone know if the sysmoBTS has any kind of RADUIS server? By entering the " opkg search *rad* " command i didn't get anything. Best regards Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Mon Oct 22 13:04:14 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 22 Oct 2012 15:04:14 +0200 Subject: RADIUS in sysmoBTS ? In-Reply-To: References: Message-ID: <20121022130414.GC29087@xiaoyu.lan> On Mon, Oct 22, 2012 at 02:40:50PM +0200, Yann R. Moupinda wrote: > Hi guys, > > Does anyone know if the sysmoBTS has any kind of RADUIS server? By entering the " opkg search *rad* " command i didn't get anything. Hi, there is no radius in the feeds and it doesn't appear to be available for Yocto/OpenEmbedded at this time. I can look into building packages at the end of the week. What do you need it for? holger PS: Any luck with tracing at the "BSC API" interface or with an external MSC? From yannm1 at hotmail.com Mon Oct 22 14:00:04 2012 From: yannm1 at hotmail.com (Yann R. Moupinda) Date: Mon, 22 Oct 2012 16:00:04 +0200 Subject: FW: RADIUS in sysmoBTS ? In-Reply-To: <20121022130414.GC29087@xiaoyu.lan> References: , , <20121022130414.GC29087@xiaoyu.lan> Message-ID: Hello, >I can look into building packages at the end of the week. What do you need it for? i try to realise a GSM-WLAN (hotspot) Interworking system. I read that the authentication can be done by using a EAP-SIM protocol standard. For that i need a AAA RADIUS server supporting EAP-SIM (like Freeradius) and wich should be able to communicate with the HLR. > PS: Any luck with tracing at the "BSC API" interface or with an external MSC? I couldn't find a external MSC and because of the time of my thesis, i decided to investigate more about the GSM-WIFI interworking. Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Oct 22 19:12:30 2012 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 22 Oct 2012 21:12:30 +0200 Subject: FW: RADIUS in sysmoBTS ? In-Reply-To: References: <20121022130414.GC29087@xiaoyu.lan> Message-ID: <20121022191230.GK1649@prithivi.gnumonks.org> On Mon, Oct 22, 2012 at 04:00:04PM +0200, Yann R. Moupinda wrote: > >I can look into building packages at the end of the week. What do you need it for? > i try to realise a GSM-WLAN (hotspot) Interworking system. I read that > the authentication can be done by using a EAP-SIM protocol standard. > For that i need a AAA RADIUS server supporting EAP-SIM (like > Freeradius) and wich should be able to communicate with the HLR. There is no external interface to the OsmoNITB internal HLR. You will have to write any such interface yourself, if you need it. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Mon Oct 22 19:21:06 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 22 Oct 2012 21:21:06 +0200 Subject: FW: RADIUS in sysmoBTS ? In-Reply-To: References: <20121022130414.GC29087@xiaoyu.lan> Message-ID: <20121022192106.GE8033@xiaoyu.lan> On Mon, Oct 22, 2012 at 04:00:04PM +0200, Yann R. Moupinda wrote: > > i try to realise a GSM-WLAN (hotspot) Interworking system. I read that the authentication can be done by using a EAP-SIM protocol standard. For that i need a AAA RADIUS server supporting EAP-SIM (like Freeradius) and wich should be able to communicate with the HLR. This sounds like if you need to work with Freeradius yourself. You have a 'toolchain' in your download area. It could have all the depdencies to build Freeradius yourself. The toolchain runs on i686 systems and unpacks to /opt. There is an '*environment-setup*' you will need to source that will setup PATHs and other environment variables. > > PS: Any luck with tracing at the "BSC API" interface or with an external MSC? > > I couldn't find a external MSC and because of the time of my thesis, i decided to investigate more about the GSM-WIFI interworking. Good luck. I am confident that over time we will have a more complete MSC. From holger at freyther.de Mon Oct 22 19:39:30 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 22 Oct 2012 21:39:30 +0200 Subject: Testing OpenBSC with a FakeBTS Message-ID: <20121022193930.GF8033@xiaoyu.lan> Hi, I wrote some code that lets me test OpenBSC without using real hardware, e.g. one is bothered to wait for the nanoBTS to open the OML connection again, one doesn't have the unit for the right band, one doesn't have a dual trx system, or because reproducing the issue is difficult (RF interference, LAPDm timeouts). I have packaged the code with OBS and right now it is only available for debian stable (it can be installed on unstable as long as the stable feeds are inside the sources.list). Install: $ echo 'deb http://download.opensuse.org/repositories/home:/zecke23/Debian_6.0/ ./' > /etc/apt/sources.list.d/ $ aptitude update; aptitude install gnu-smalltalk osmo-st-openbsc-test (the packages are signed but the key expired two years ago, so the question is if you want to trust Debian packages from OpenSUSE) Using: $ gst st> PackageLoader fileInPackage: #FakeBTS ... st> bts := FakeBTS.BTS new. st> bts btsId: '1/0/0' st> bts connect: 'localhost'; waitForBTSReady. ... Testing: There is the FakeBTS.OpenBSCTest class that has methods to require channels and these Lchans can be used to send RSL messages. I don't have a public example at this point though. Vision: I hope this code will be used to do nightly tests of OpenBSC, specially the error paths (e.g. timeouts on handover, timeouts on assignment, timeouts on channel release, etc.) There is a branch that brings DualTRX support and I am going to merge this to master soon. What I am missing is some test launcher code (it can be in python or ruby if someone volunteers) that will launch osmo-bsc/osmo-nitb with a given configuration file and initialize the HLR with a set of given subscribers. enjoy holger PS: Blog post will follow once the code has matured a bit From holger at freyther.de Sat Oct 27 22:34:29 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 28 Oct 2012 00:34:29 +0200 Subject: Testing OpenBSC with a FakeBTS In-Reply-To: <20121022193930.GF8033@xiaoyu.lan> References: <20121022193930.GF8033@xiaoyu.lan> Message-ID: <20121027223429.GB27033@xiaoyu.lan> On Mon, Oct 22, 2012 at 09:39:30PM +0200, Holger Hans Peter Freyther wrote: > Hi, Hi again, I have updated the packages (so aptitude update, aptitude safe-upgrade) and I have comitted and attached a simple Location Updating Request. Start openbsc and roughly do the following: $ gst LUTest.st ... it will fail because of a LU Reject, authorize the subscriber.. $ gst LUTest.st ... the LU should now succeed. Some small explanations. First I create a class that inherits the OpenBSCTest class and create a startTest method (called a selector in Smalltalk). In that method I connect as a new BTS, then require any channel and send a LURequest through this new lchan. I am then read/sending messages until the connection comes to an end. The Smalltalk syntax is explained here[1], it contains a very short explanation of the Smalltalk syntax and features. enjoy holger [1] http://esug.heeg.de/whyusesmalltalktoteachoop/smalltalksyntaxonapostcard/ -------------- next part -------------- " (C) 2012 by Holger Hans Peter Freyther All Rights Reserved This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details. You should have received a copy of the GNU Affero General Public License along with this program. If not, see . " PackageLoader fileInPackage: #FakeBTS. FakeBTS.OpenBSCTest subclass: LUTest [ startTest [ | lchan lu msg | "1. Connect to the BTS" self createAndConnectBTS: '1801/0/0'. "2. Get a LCHAN" lchan := self requireAnyChannel. "3. Send the LU request" lu := GSM48LURequest new. lu lai mcc: 1; mnc: 1; lac: 1. lu mi imsi: '901010000001111'. lchan sendGSM: lu toMessage. "Now deal with what the NITB wants" "4.1 Send the IMEI..." msg := GSM48MSG decode: lchan nextSapi0Msg readStream. (msg isKindOf: GSM48IdentityReq) ifFalse: [^self error: 'Wanted identity request']. (msg idType isIMEI) ifFalse: [^self error: 'Wanted IMEI reqest']. msg := GSM48IdentityResponse new. msg mi imei: '6666666666666666'. lchan sendGSM: msg toMessage. "4.2 LU Accept" msg := GSM48MSG decode: lchan nextSapi0Msg readStream. (msg isKindOf: GSM48LUAccept) ifFalse: [^self error: 'LU failed']. msg := GSM48TMSIReallocationComplete new. lchan sendGSM: msg toMessage. "4.3 MM Information for the time. ignore it" msg := GSM48MSG decode: lchan nextSapi0Msg readStream. (msg isKindOf: GSM48MMInformation) ifFalse: [^self error: 'MM Information']. "4.4 release.. if we now don't close the LCHAN it will remain open for a bit. OpenBSC should and will start the approriate timer soon(tm)" msg := GSM48MSG decode: lchan nextSapi0Msg readStream. (msg isKindOf: GSM48RRChannelRelease) ifFalse: [^self error: 'RR Channel Release']. "4.5.. be nice... for now and send a disconnect." lchan releaseAllSapis. ] ] Eval [ | test | test := LUTest new startTest; stopBts; yourself. ] From Ivan.Kluchnikov at fairwaves.ru Tue Oct 23 10:17:40 2012 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Tue, 23 Oct 2012 14:17:40 +0400 Subject: nanoBTS bring up problem Message-ID: Hi all! We tried to deploy our nanoBTS with osmo-nitb, but unfortunately we had no success. We have the following logs for ipaccess-find, ipaccess-config, osmo-nitb and ipaccess-telnet. We would appreciate it, if someone gives us advice. What does these logs mean? Is it possible, that the problem is in firmware, and we should update it? ./ipaccess-find MAC_Address='00:02:95:00:01:7e' IP_Address='172.44.4.75' Unit_ID='1801/0/0' Location_1='' Location_2='BTS_NBT131G' Equipment_Version='110_029_13' Software_Version='119a002_v149b18d0' Unit_Name='nbts-00-02-95-00-01-7E' Serial_Number='00024616' ./ipaccess-config -n 0x400/0x400 172.44.4.75 <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) OML link established using TRX 0 setting NV Flags/Mask to 0x0400/0x0400 <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xf0): SET NVATTR ACK Set the NV Attributes. ./osmo-nitb --debug=DRLL:DCC:DMM:DRR:DRSL:DNM -c openbsc.cfg DB: Database initialized. DB: Database prepared. <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 36 64 30 00 <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Software Activated Report <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) Software Activated Report <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1379 Set BTS Attr (bts=0) <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 31 00 13 00 0a 76 32 30 39 62 32 36 64 30 00 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 <0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 31 00 13 00 0a 76 32 30 39 62 32 36 64 30 00 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) Software Activated Report <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) OPSTART NACK CAUSE=Message cannot be performed <0005> bsc_init.c:54 Got a NACK going to drop the OML links. ./ipaccess-telnet 172.44.4.75 3210 14851:DBG:CLI_SKT:Remote client 172.44.4.4 connected 16160:DBG:IP_CHANNEL:Assigning RX Client A 16160:DBG:IP_CHAN_RX_A:Attempting connection to 172.44.4.4:3002 20572:DBG:IP_CHANNEL:Assigning RX Client A 20572:DBG:IP_CHAN_RX_A:Attempting connection to 172.44.4.4:3002 21007:DBG:OAM_IM:Set SYSTEM LINK to 65.255 21051:DBG:OAM_MOI:Can Activate?=TRUE 21051:DBG:OAM_MOI:Sw Activate - activating BH idx=1 21051:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=255) 21051:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: BTS:0 flag 3 not setting or set! 21051:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: GPRS NSE:0 flag 3 not setting or set! 21063:DBG:OAM_MOI:Can Activate?=TRUE 21063:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 21063:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=255) 21064:DBG:OAM_MOI:Can Activate?=TRUE 21064:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 21064:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=255) 21067:DBG:GB_OAM:Received OPEN_REQ for NSE 0. 21075:DBG:OAM_IM:Ignored imSetFrameNumber. 21075:DBG:OAM_MOI:oid=BTS:0 publisher attributes set 21077:DBG:OAM_MOI:Can Activate?=TRUE 21078:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 21078:DBG:OAM_MOI:Sw Activate - sending trx boot request to activate TRX idx=1 21078:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=1) 21078:DBG:OAM_MOI:Can Activate?=TRUE 21078:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 21079:DBG:OAM_MOI:Sw Activate - already activated TRX idx=1 21079:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=1) 21079:DBG:OAM_MOI:Can Activate?=TRUE 21079:DBG:OAM_MOI:6110:gprs.cell: EVENT 0x000007d4 rxd in STATE initial 21079:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 21079:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=1) 21079:DBG:OAM_MOI:6112:gprs.cell: EVENT 0x000007cb rxd in STATE waitopenresources 21080:DBG:OAM_MOI:6124:gprs.cell: EVENT 0x000007cd rxd in STATE waitregisterdependencycnf 21080:DBG:OAM_MOI:6125:gprs.cell: EVENT 0x000007cd rxd in STATE waitregisterdependencycnf 21080:DBG:OAM_MOI:6126:gprs.cell: EVENT 0x000007cd rxd in STATE waitregisterdependencycnf 21081:DBG:OAM_MOI:6127:gprs.cell: EVENT 0x000007cd rxd in STATE waitregisterdependencycnf 21081:DBG:OAM_MOI:6128:gprs.cell: EVENT 0x000007cd rxd in STATE waitregisterdependencycnf 21081:DBG:OAM_MOI:6129:gprs.cell: EVENT 0x000007cd rxd in STATE waitregisterdependencycnf 21081:DBG:OAM_MOI:6130:gprs.cell: EVENT 0x000007cd rxd in STATE waitregisterdependencycnf 21081:DBG:OAM_MOI:6131:gprs.cell: EVENT 0x000007cd rxd in STATE waitregisterdependencycnf 21082:DBG:OAM_MOI:6132:gprs.cell: EVENT 0x000007cd rxd in STATE waitregisterdependencycnf 21082:DBG:OAM_MOI:6133:gprs.cell: EVENT 0x000007cd rxd in STATE waitregisterdependencycnf 21083:DBG:OAM_MOI:6134:gprs.cell: EVENT 0x000007cd rxd in STATE waitregisterdependencycnf 21086:DBG:OAM_MOI:Can Activate?=TRUE 21086:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 21086:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=1) 21087:DBG:OAM_MOI:Can Activate?=TRUE 21087:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 21087:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=1) 21088:DBG:OAM_MOI:6166:gprs.cell: EVENT 0x000007ca rxd in STATE waitopencnf 21088:DBG:GB_OAM:Received OPEN_REQ for NSVC 0. 21089:DBG:GB_OAM:Received OPEN_REQ for NSVC 1. 21089:DBG:TRX_BOOT:Sending Cnf idx=1 token=969 task=2 21098:DBG:TRX_BOOT:Sending Cnf idx=1 token=1031 task=2 21519:DBG:OAM_IM:Clear SYSTEM LINK 21523:DBG:OAM_MOI:6426:gprs.cell: EVENT 0x000007c7 rxd in STATE active 21523:DBG:OAM_MOI:6426:gprs.cell: EXITING swactivated 21527:DBG:OAM_RES:Failed to deregister dependency: token=1024 not found (class=1 instance=7) 21527:DBG:OAM_RES:Failed to deregister dependency: token=1017 not found (class=1 instance=6) 21527:DBG:OAM_RES:Failed to deregister dependency: token=1010 not found (class=1 instance=5) 21527:DBG:OAM_RES:Failed to deregister dependency: token=1003 not found (class=1 instance=4) 21527:DBG:OAM_RES:Failed to deregister dependency: token=996 not found (class=1 instance=3) 21527:DBG:OAM_RES:Failed to deregister dependency: token=989 not found (class=1 instance=2) 21528:DBG:OAM_RES:Failed to deregister dependency: token=982 not found (class=1 instance=1) 21528:DBG:OAM_RES:Failed to deregister dependency: token=975 not found (class=1 instance=0) 21528:DBG:OAM_RES:Failed to deregister dependency: token=969 not found (class=0 instance=0) 21528:DBG:OAM_RES:Failed to deregister dependency: token=1031 not found (class=2 instance=0) 21528:DBG:OAM_RES:Failed to deregister dependency: token=964 not found (class=2 instance=0) 21528:DBG:OAM_RES:Failed to deregister dependency: token=964 not found (class=1 instance=0) 21528:DBG:OAM_RES:Failed to deregister dependency: token=1047 not found (class=2 instance=0) 21528:DBG:OAM_RES:Failed to deregister dependency: token=1047 not found (class=1 instance=0) 21608:DBG:DB_EE:Writing 174 bytes of DBX data to block 3 21608:DBG:DB_EE:Re-using existing DBX block 21857:DBG:DB_EE:NV block 3 - wrote block to NV, main and backup OK. 21857:DBG:DB_EE:EE update complete. 21931:DBG:DB_EE:EE update complete. 22004:DBG:DB_EE:EE update complete. 22078:DBG:DB_EE:EE update complete. 22151:DBG:DB_EE:EE update complete. 22225:DBG:DB_EE:EE update complete. 22298:DBG:DB_EE:EE update complete. 22371:DBG:DB_EE:EE update complete. -- Regards, Ivan Kluchnikov. http://fairwaves.ru From Ivan.Kluchnikov at fairwaves.ru Tue Oct 23 12:10:01 2012 From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov) Date: Tue, 23 Oct 2012 16:10:01 +0400 Subject: nanoBTS bring up problem In-Reply-To: References: Message-ID: Hi! We solved this problem, it seems, that ipaccess-config didn't work correctly for our nanoBTS. We set primary OML link IP and port using ipaccess-telnet and nanoBTS bring up. Now we have working osmo-nitb. 2012/10/23 Ivan Kluchnikov : > Hi all! > > We tried to deploy our nanoBTS with osmo-nitb, but unfortunately we > had no success. > We have the following logs for ipaccess-find, ipaccess-config, > osmo-nitb and ipaccess-telnet. > We would appreciate it, if someone gives us advice. > What does these logs mean? > Is it possible, that the problem is in firmware, and we should update it? > > ./ipaccess-find > MAC_Address='00:02:95:00:01:7e' IP_Address='172.44.4.75' > Unit_ID='1801/0/0' Location_1='' Location_2='BTS_NBT131G' > Equipment_Version='110_029_13' Software_Version='119a002_v149b18d0' > Unit_Name='nbts-00-02-95-00-01-7E' Serial_Number='00024616' > > ./ipaccess-config -n 0x400/0x400 172.44.4.75 > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE > CHG: OP_STATE=Disabled AVAIL=Not installed(07) > OML link established using TRX 0 > setting NV Flags/Mask to 0x0400/0x0400 > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) > IPACCESS(0xf0): SET NVATTR ACK > Set the NV Attributes. > > ./osmo-nitb --debug=DRLL:DCC:DMM:DRR:DRSL:DNM -c openbsc.cfg > DB: Database initialized. > DB: Database prepared. > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE > CHG: OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) SW Activate > Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and > Activating > <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 > 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 42 12 00 08 31 31 39 61 30 > 30 32 00 13 00 0a 76 32 30 39 62 32 36 64 30 00 > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Software > Activated Report > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART > <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) SW Activate Request: > <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 > 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 > <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) SW Activate > Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and > Activating > <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 > 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: > OP_STATE=Enabled > <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART > <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) Software Activated Report > <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1379 Set BTS Attr (bts=0) > <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART > <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) SW > Activate Request: <0005> abis_nm.c:418 Software Activate Request, > ACKing and Activating > <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 31 > 00 13 00 0a 76 32 30 39 62 32 36 64 30 00 42 12 00 08 31 31 39 61 30 > 30 32 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 > <0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) SW Activate > Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and > Activating > <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 31 > 00 13 00 0a 76 32 30 39 62 32 36 64 30 00 42 12 00 08 31 31 39 61 30 > 30 32 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 > <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) Software Activated Report > <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) SW Activate > Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and > Activating > <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 > 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 > <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) SW Activate > Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and > Activating > <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 > 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 > <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) SW Activate > Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and > Activating > <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 > 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 > <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: > OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) OPSTART NACK > CAUSE=Message cannot be performed > <0005> bsc_init.c:54 Got a NACK going to drop the OML links. > > ./ipaccess-telnet 172.44.4.75 3210 > 14851:DBG:CLI_SKT:Remote client 172.44.4.4 connected > 16160:DBG:IP_CHANNEL:Assigning RX Client A > 16160:DBG:IP_CHAN_RX_A:Attempting connection to 172.44.4.4:3002 > 20572:DBG:IP_CHANNEL:Assigning RX Client A > 20572:DBG:IP_CHAN_RX_A:Attempting connection to 172.44.4.4:3002 > 21007:DBG:OAM_IM:Set SYSTEM LINK to 65.255 > 21051:DBG:OAM_MOI:Can Activate?=TRUE > 21051:DBG:OAM_MOI:Sw Activate - activating BH idx=1 > 21051:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=255) > 21051:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: BTS:0 flag 3 not > setting or set! > 21051:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: GPRS NSE:0 flag > 3 not setting or set! > 21063:DBG:OAM_MOI:Can Activate?=TRUE > 21063:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 > 21063:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=255) > 21064:DBG:OAM_MOI:Can Activate?=TRUE > 21064:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 > 21064:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=255) > 21067:DBG:GB_OAM:Received OPEN_REQ for NSE 0. > 21075:DBG:OAM_IM:Ignored imSetFrameNumber. > 21075:DBG:OAM_MOI:oid=BTS:0 publisher attributes set > 21077:DBG:OAM_MOI:Can Activate?=TRUE > 21078:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 > 21078:DBG:OAM_MOI:Sw Activate - sending trx boot request to activate TRX idx=1 > 21078:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=1) > 21078:DBG:OAM_MOI:Can Activate?=TRUE > 21078:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 > 21079:DBG:OAM_MOI:Sw Activate - already activated TRX idx=1 > 21079:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=1) > 21079:DBG:OAM_MOI:Can Activate?=TRUE > 21079:DBG:OAM_MOI:6110:gprs.cell: EVENT 0x000007d4 rxd in STATE initial > 21079:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 > 21079:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=1) > 21079:DBG:OAM_MOI:6112:gprs.cell: EVENT 0x000007cb rxd in STATE > waitopenresources > 21080:DBG:OAM_MOI:6124:gprs.cell: EVENT 0x000007cd rxd in STATE > waitregisterdependencycnf > 21080:DBG:OAM_MOI:6125:gprs.cell: EVENT 0x000007cd rxd in STATE > waitregisterdependencycnf > 21080:DBG:OAM_MOI:6126:gprs.cell: EVENT 0x000007cd rxd in STATE > waitregisterdependencycnf > 21081:DBG:OAM_MOI:6127:gprs.cell: EVENT 0x000007cd rxd in STATE > waitregisterdependencycnf > 21081:DBG:OAM_MOI:6128:gprs.cell: EVENT 0x000007cd rxd in STATE > waitregisterdependencycnf > 21081:DBG:OAM_MOI:6129:gprs.cell: EVENT 0x000007cd rxd in STATE > waitregisterdependencycnf > 21081:DBG:OAM_MOI:6130:gprs.cell: EVENT 0x000007cd rxd in STATE > waitregisterdependencycnf > 21081:DBG:OAM_MOI:6131:gprs.cell: EVENT 0x000007cd rxd in STATE > waitregisterdependencycnf > 21082:DBG:OAM_MOI:6132:gprs.cell: EVENT 0x000007cd rxd in STATE > waitregisterdependencycnf > 21082:DBG:OAM_MOI:6133:gprs.cell: EVENT 0x000007cd rxd in STATE > waitregisterdependencycnf > 21083:DBG:OAM_MOI:6134:gprs.cell: EVENT 0x000007cd rxd in STATE > waitregisterdependencycnf > 21086:DBG:OAM_MOI:Can Activate?=TRUE > 21086:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 > 21086:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=1) > 21087:DBG:OAM_MOI:Can Activate?=TRUE > 21087:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 > 21087:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=1) > 21088:DBG:OAM_MOI:6166:gprs.cell: EVENT 0x000007ca rxd in STATE waitopencnf > 21088:DBG:GB_OAM:Received OPEN_REQ for NSVC 0. > 21089:DBG:GB_OAM:Received OPEN_REQ for NSVC 1. > 21089:DBG:TRX_BOOT:Sending Cnf idx=1 token=969 task=2 > 21098:DBG:TRX_BOOT:Sending Cnf idx=1 token=1031 task=2 > 21519:DBG:OAM_IM:Clear SYSTEM LINK > 21523:DBG:OAM_MOI:6426:gprs.cell: EVENT 0x000007c7 rxd in STATE active > 21523:DBG:OAM_MOI:6426:gprs.cell: EXITING swactivated > 21527:DBG:OAM_RES:Failed to deregister dependency: token=1024 not > found (class=1 instance=7) > 21527:DBG:OAM_RES:Failed to deregister dependency: token=1017 not > found (class=1 instance=6) > 21527:DBG:OAM_RES:Failed to deregister dependency: token=1010 not > found (class=1 instance=5) > 21527:DBG:OAM_RES:Failed to deregister dependency: token=1003 not > found (class=1 instance=4) > 21527:DBG:OAM_RES:Failed to deregister dependency: token=996 not found > (class=1 instance=3) > 21527:DBG:OAM_RES:Failed to deregister dependency: token=989 not found > (class=1 instance=2) > 21528:DBG:OAM_RES:Failed to deregister dependency: token=982 not found > (class=1 instance=1) > 21528:DBG:OAM_RES:Failed to deregister dependency: token=975 not found > (class=1 instance=0) > 21528:DBG:OAM_RES:Failed to deregister dependency: token=969 not found > (class=0 instance=0) > 21528:DBG:OAM_RES:Failed to deregister dependency: token=1031 not > found (class=2 instance=0) > 21528:DBG:OAM_RES:Failed to deregister dependency: token=964 not found > (class=2 instance=0) > 21528:DBG:OAM_RES:Failed to deregister dependency: token=964 not found > (class=1 instance=0) > 21528:DBG:OAM_RES:Failed to deregister dependency: token=1047 not > found (class=2 instance=0) > 21528:DBG:OAM_RES:Failed to deregister dependency: token=1047 not > found (class=1 instance=0) > 21608:DBG:DB_EE:Writing 174 bytes of DBX data to block 3 > 21608:DBG:DB_EE:Re-using existing DBX block > 21857:DBG:DB_EE:NV block 3 - wrote block to NV, main and backup OK. > 21857:DBG:DB_EE:EE update complete. > 21931:DBG:DB_EE:EE update complete. > 22004:DBG:DB_EE:EE update complete. > 22078:DBG:DB_EE:EE update complete. > 22151:DBG:DB_EE:EE update complete. > 22225:DBG:DB_EE:EE update complete. > 22298:DBG:DB_EE:EE update complete. > 22371:DBG:DB_EE:EE update complete. > > > -- > Regards, > Ivan Kluchnikov. > http://fairwaves.ru -- Regards, Ivan Kluchnikov. http://fairwaves.ru From akibsayyed at gmail.com Wed Oct 24 10:29:30 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Wed, 24 Oct 2012 13:29:30 +0300 Subject: Anyone selling NanoBTS Message-ID: if anyone selling nano bts please let me know -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at bluewave.im Wed Oct 24 10:42:06 2012 From: stuart at bluewave.im (Stuart Baggs) Date: Wed, 24 Oct 2012 11:42:06 +0100 Subject: Anyone selling NanoBTS In-Reply-To: References: Message-ID: We have a few model 165G for sale. They're brand new and work in the 1800 MHz band. We also have a history of selling to other group members. Thanks Stuart Sent from my iPhone On 24 Oct 2012, at 11:29, Akib Sayyed wrote: > if anyone selling nano bts please let me know > > -- > Akib Sayyed > Matrix-Shell > akibsayyed at gmail.com > akibsayyed at matrixshell.com > Mob:- +91-966-514-2243 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lnve at s21sec.com Wed Oct 24 11:04:01 2012 From: lnve at s21sec.com (Leonardo Nve) Date: Wed, 24 Oct 2012 13:04:01 +0200 Subject: Anyone selling NanoBTS In-Reply-To: References: Message-ID: <9B2D2769-8AD9-4D6F-AEE4-B96FC4CBAFDC@s21sec.com> I have one of 1900 band to sell, 900? i can send you photos if you want. -- Leonardo Nve Project Manager departamento Auditoria Grupo S21sec Gesti?n, S.A. Telefono 628275870 -- La informaci?n contenida en este mail, as? como los archivos adjuntos,es CONFIDENCIAL. Grupo S21sec Gesti?n, S.A. garantiza la adopci?n de las medidas necesarias para asegurar el tratamiento confidencial de los datos de car?cter personal. En el caso de que el destinatario del correo no sea usted, le rogamos env?e una notificaci?n al remitente y lo destruya de forma inmediata. La lectura y/o manipulaci?n de esta informaci?n en la situaci?n se?alada anteriormente ser? considerada ilegal, permitiendo a la empresa remitente realizar acciones legales de diferente envergadura. El 24/10/2012, a las 12:29, Akib Sayyed escribi?: > if anyone selling nano bts please let me know > > -- > Akib Sayyed > Matrix-Shell > akibsayyed at gmail.com > akibsayyed at matrixshell.com > Mob:- +91-966-514-2243 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From t-openbsc at tobias.org Wed Oct 24 15:52:50 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Wed, 24 Oct 2012 17:52:50 +0200 Subject: [libosmocore PATCH 0/3] Make openbsc also compile/run on OSX Message-ID: <1351093973-1287-1-git-send-email-t-openbsc@tobias.org> These are some minor modifications to make openbsc also run on OSX. You have to have these MacPorts installed: pkgconfig automake autoconf libtool libdbi libdbi-drivers sqlite3 ... and set: export LDFLAGS='-L/opt/local/lib' export CPPFLAGS='-I/opt/local/include' Everything else should work as usual. Tobias Engel (3): Define struct iphdr for OSX Do not use --version-script linker flag on OSX Add "extern" keywords configure.ac | 12 ++++++++++++ include/osmocom/gsm/abis_nm.h | 10 +++++----- src/gb/Makefile.am | 2 +- src/gb/gprs_ns_frgre.c | 2 +- src/gsm/Makefile.am | 2 +- 5 files changed, 20 insertions(+), 8 deletions(-) -- 1.7.10.2 (Apple Git-33) From t-openbsc at tobias.org Wed Oct 24 15:52:51 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Wed, 24 Oct 2012 17:52:51 +0200 Subject: [libosmocore PATCH 1/3] Define struct iphdr for OSX In-Reply-To: <1351093973-1287-1-git-send-email-t-openbsc@tobias.org> References: <1351093973-1287-1-git-send-email-t-openbsc@tobias.org> Message-ID: <1351093973-1287-2-git-send-email-t-openbsc@tobias.org> Use FreeBSD struct iphdr definition for OSX also. From the commentary in the source file: On BSD the IPv4 struct is called struct ip and instead of iXX the members are called ip_XX. One could change this code to use struct ip but that would require to define _BSD_SOURCE and that might have other complications. Instead make sure struct iphdr is present on FreeBSD. --- src/gb/gprs_ns_frgre.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gb/gprs_ns_frgre.c b/src/gb/gprs_ns_frgre.c index 2344381..e557c7e 100644 --- a/src/gb/gprs_ns_frgre.c +++ b/src/gb/gprs_ns_frgre.c @@ -48,7 +48,7 @@ struct gre_hdr { uint16_t ptype; } __attribute__ ((packed)); -#if defined(__FreeBSD__) +#if defined(__FreeBSD__) || defined(__APPLE__) /** * On BSD the IPv4 struct is called struct ip and instead of iXX * the members are called ip_XX. One could change this code to use -- 1.7.10.2 (Apple Git-33) From jrees at arbor.net Wed Oct 24 16:12:47 2012 From: jrees at arbor.net (Jim Rees) Date: Wed, 24 Oct 2012 12:12:47 -0400 Subject: [libosmocore PATCH 1/3] Define struct iphdr for OSX In-Reply-To: <1351093973-1287-2-git-send-email-t-openbsc@tobias.org> References: <1351093973-1287-1-git-send-email-t-openbsc@tobias.org> <1351093973-1287-2-git-send-email-t-openbsc@tobias.org> Message-ID: Wouldn't it be better to use #ifndef __linux__? Who else uses struct iphdr? From t-openbsc at tobias.org Wed Oct 24 15:52:52 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Wed, 24 Oct 2012 17:52:52 +0200 Subject: [libosmocore PATCH 2/3] Do not use --version-script linker flag on OSX In-Reply-To: <1351093973-1287-1-git-send-email-t-openbsc@tobias.org> References: <1351093973-1287-1-git-send-email-t-openbsc@tobias.org> Message-ID: <1351093973-1287-3-git-send-email-t-openbsc@tobias.org> Add a check to not use --version-script linker flag if compiled on OSX since it doesn't exist there --- configure.ac | 12 ++++++++++++ src/gb/Makefile.am | 2 +- src/gsm/Makefile.am | 2 +- 3 files changed, 14 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index f119c90..24ddd0c 100644 --- a/configure.ac +++ b/configure.ac @@ -17,6 +17,18 @@ LT_INIT([pic-only]) AC_CONFIG_MACRO_DIR([m4]) +dnl check os: some linker flags not available on osx +case $host in +*-darwin*) + ;; +*) + LTLDFLAGS_OSMOGB='-Wl,--version-script=$(srcdir)/libosmogb.map' + LTLDFLAGS_OSMOGSM='-Wl,--version-script=$(srcdir)/libosmogsm.map' + ;; +esac +AC_SUBST(LTLDFLAGS_OSMOGB) +AC_SUBST(LTLDFLAGS_OSMOGSM) + dnl checks for header files AC_HEADER_STDC AC_CHECK_HEADERS(execinfo.h sys/select.h sys/socket.h syslog.h ctype.h) diff --git a/src/gb/Makefile.am b/src/gb/Makefile.am index c137766..04d2108 100644 --- a/src/gb/Makefile.am +++ b/src/gb/Makefile.am @@ -11,7 +11,7 @@ noinst_HEADERS = common_vty.h if ENABLE_GB lib_LTLIBRARIES = libosmogb.la -libosmogb_la_LDFLAGS = -Wl,--version-script=$(srcdir)/libosmogb.map -version-info $(LIBVERSION) +libosmogb_la_LDFLAGS = $(LTLDFLAGS_OSMOGB) -version-info $(LIBVERSION) libosmogb_la_LIBADD = \ $(top_builddir)/src/libosmocore.la \ $(top_builddir)/src/vty/libosmovty.la \ diff --git a/src/gsm/Makefile.am b/src/gsm/Makefile.am index b72a8d4..0544e0a 100644 --- a/src/gsm/Makefile.am +++ b/src/gsm/Makefile.am @@ -21,7 +21,7 @@ libosmogsm_la_SOURCES = a5.c rxlev_stat.c tlv_parser.c comp128.c gsm_utils.c \ milenage/aes-encblock.c milenage/aes-internal.c \ milenage/aes-internal-enc.c milenage/milenage.c gan.c -libosmogsm_la_LDFLAGS = -Wl,--version-script=$(srcdir)/libosmogsm.map -version-info $(LIBVERSION) +libosmogsm_la_LDFLAGS = $(LTLDFLAGS_OSMOGSM) -version-info $(LIBVERSION) libosmogsm_la_LIBADD = $(top_builddir)/src/libosmocore.la EXTRA_DIST = libosmogsm.map -- 1.7.10.2 (Apple Git-33) From t-openbsc at tobias.org Wed Oct 24 15:52:53 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Wed, 24 Oct 2012 17:52:53 +0200 Subject: [libosmocore PATCH 3/3] Add "extern" keywords In-Reply-To: <1351093973-1287-1-git-send-email-t-openbsc@tobias.org> References: <1351093973-1287-1-git-send-email-t-openbsc@tobias.org> Message-ID: <1351093973-1287-4-git-send-email-t-openbsc@tobias.org> Without the "extern" keyword the variables in this header file will be seen as empty definitions when compiled on OSX. --- include/osmocom/gsm/abis_nm.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/osmocom/gsm/abis_nm.h b/include/osmocom/gsm/abis_nm.h index cc01765..320ac3e 100644 --- a/include/osmocom/gsm/abis_nm.h +++ b/include/osmocom/gsm/abis_nm.h @@ -14,10 +14,10 @@ enum abis_nm_msgtype; enum gsm_phys_chan_config; -const enum abis_nm_msgtype abis_nm_reports[4]; -const enum abis_nm_msgtype abis_nm_no_ack_nack[3]; -const enum abis_nm_msgtype abis_nm_sw_load_msgs[9]; -const enum abis_nm_msgtype abis_nm_nacks[33]; +extern const enum abis_nm_msgtype abis_nm_reports[4]; +extern const enum abis_nm_msgtype abis_nm_no_ack_nack[3]; +extern const enum abis_nm_msgtype abis_nm_sw_load_msgs[9]; +extern const enum abis_nm_msgtype abis_nm_nacks[33]; extern const struct value_string abis_nm_obj_class_names[]; extern const struct value_string abis_nm_adm_state_names[]; @@ -26,7 +26,7 @@ const char *abis_nm_nack_cause_name(uint8_t cause); const char *abis_nm_nack_name(uint8_t nack); const char *abis_nm_event_type_name(uint8_t cause); const char *abis_nm_severity_name(uint8_t cause); -const struct tlv_definition abis_nm_att_tlvdef; +extern const struct tlv_definition abis_nm_att_tlvdef; const char *abis_nm_opstate_name(uint8_t os); const char *abis_nm_avail_name(uint8_t avail); const char *abis_nm_test_name(uint8_t test); -- 1.7.10.2 (Apple Git-33) From peter at stuge.se Wed Oct 24 16:16:28 2012 From: peter at stuge.se (Peter Stuge) Date: Wed, 24 Oct 2012 18:16:28 +0200 Subject: [libosmocore PATCH 0/3] Make openbsc also compile/run on OSX In-Reply-To: <1351093973-1287-1-git-send-email-t-openbsc@tobias.org> References: <1351093973-1287-1-git-send-email-t-openbsc@tobias.org> Message-ID: <20121024161628.20783.qmail@stuge.se> Tobias Engel wrote: > You have to have these MacPorts installed: > pkgconfig > automake > autoconf > libtool > libdbi > libdbi-drivers > sqlite3 > > ... and set: > export LDFLAGS='-L/opt/local/lib' > export CPPFLAGS='-I/opt/local/include' What requires these flags to be set manually? //Peter From t-openbsc at tobias.org Wed Oct 24 16:49:00 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Wed, 24 Oct 2012 18:49:00 +0200 Subject: [libosmocore PATCH 0/3] Make openbsc also compile/run on OSX In-Reply-To: <20121024161628.20783.qmail@stuge.se> References: <1351093973-1287-1-git-send-email-t-openbsc@tobias.org> <20121024161628.20783.qmail@stuge.se> Message-ID: <50881BFC.1010303@tobias.org> >> ... and set: >> export LDFLAGS='-L/opt/local/lib' >> export CPPFLAGS='-I/opt/local/include' > > What requires these flags to be set manually? These are the locations where software gets installed by MacPorts and they are not normally searched by gcc. -Tobias From peter at stuge.se Wed Oct 24 17:37:13 2012 From: peter at stuge.se (Peter Stuge) Date: Wed, 24 Oct 2012 19:37:13 +0200 Subject: [libosmocore PATCH 0/3] Make openbsc also compile/run on OSX In-Reply-To: <50881BFC.1010303@tobias.org> References: <1351093973-1287-1-git-send-email-t-openbsc@tobias.org> <20121024161628.20783.qmail@stuge.se> <50881BFC.1010303@tobias.org> Message-ID: <20121024173713.28062.qmail@stuge.se> Tobias Engel wrote: > >> export LDFLAGS='-L/opt/local/lib' > >> export CPPFLAGS='-I/opt/local/include' > > > > What requires these flags to be set manually? > > These are the locations where software gets installed by MacPorts Which software, in this case? The purpose of pkgconfig is to avoid dealing with these flags manually. //Peter From t-openbsc at tobias.org Wed Oct 24 18:23:16 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Wed, 24 Oct 2012 20:23:16 +0200 Subject: [libosmocore PATCH 0/3] Make openbsc also compile/run on OSX In-Reply-To: <20121024173713.28062.qmail@stuge.se> References: <1351093973-1287-1-git-send-email-t-openbsc@tobias.org> <20121024161628.20783.qmail@stuge.se> <50881BFC.1010303@tobias.org> <20121024173713.28062.qmail@stuge.se> Message-ID: <50883214.3070909@tobias.org> On 24.10.12 19:37, Peter Stuge wrote: > Tobias Engel wrote: >>>> export LDFLAGS='-L/opt/local/lib' >>>> export CPPFLAGS='-I/opt/local/include' >>> >>> What requires these flags to be set manually? >> >> These are the locations where software gets installed by MacPorts > > Which software, in this case? The purpose of pkgconfig is to avoid > dealing with these flags manually. libdbi, for example. There is no .pc file installed with the libdbi port: $ port contents libdbi Port libdbi contains: /opt/local/include/dbi/dbd.h /opt/local/include/dbi/dbi-dev.h /opt/local/include/dbi/dbi.h /opt/local/lib/libdbi.1.dylib /opt/local/lib/libdbi.a /opt/local/lib/libdbi.dylib /opt/local/lib/libdbi.la -Tobias From laforge at gnumonks.org Sat Oct 27 08:06:22 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 27 Oct 2012 10:06:22 +0200 Subject: [libosmocore PATCH 0/3] Make openbsc also compile/run on OSX In-Reply-To: <1351093973-1287-1-git-send-email-t-openbsc@tobias.org> References: <1351093973-1287-1-git-send-email-t-openbsc@tobias.org> Message-ID: <20121027080622.GW31205@prithivi.gnumonks.org> Hi Tobias, On Wed, Oct 24, 2012 at 05:52:50PM +0200, Tobias Engel wrote: > These are some minor modifications to make openbsc also run on OSX. thanks for the patches, I've pushed the libosmocore ones now. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From t-openbsc at tobias.org Wed Oct 24 15:53:47 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Wed, 24 Oct 2012 17:53:47 +0200 Subject: [openbsc PATCH 0/3] Make openbsc also compile/run on OSX Message-ID: <1351094030-1325-1-git-send-email-t-openbsc@tobias.org> These are some minor modifications to make openbsc run on OSX. You have to have these MacPorts installed: pkgconfig automake autoconf libtool libdbi libdbi-drivers sqlite3 ... and set: export LDFLAGS='-L/opt/local/lib' export CPPFLAGS='-I/opt/local/include' Everything else should work as usual. Tobias Engel (3): Remove interface argument when compiled on OSX Remove unused librt dependency Set byte order defines when compiled on OSX openbsc/src/ipaccess/ipaccess-find.c | 4 ++++ openbsc/src/libmgcp/mgcp_network.c | 8 +++++++- openbsc/src/libtrau/rtp_proxy.c | 8 +++++++- openbsc/tests/mgcp/Makefile.am | 2 +- 4 files changed, 19 insertions(+), 3 deletions(-) -- 1.7.10.2 (Apple Git-33) From t-openbsc at tobias.org Wed Oct 24 15:53:48 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Wed, 24 Oct 2012 17:53:48 +0200 Subject: [openbsc PATCH 1/3] Remove interface argument when compiled on OSX In-Reply-To: <1351094030-1325-1-git-send-email-t-openbsc@tobias.org> References: <1351094030-1325-1-git-send-email-t-openbsc@tobias.org> Message-ID: <1351094030-1325-2-git-send-email-t-openbsc@tobias.org> Since it is not possible to bind a socket to a specific interface on OSX, remove the option to specify the interface when compiled on OSX. --- openbsc/src/ipaccess/ipaccess-find.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/openbsc/src/ipaccess/ipaccess-find.c b/openbsc/src/ipaccess/ipaccess-find.c index 3f9bf41..8c9cffb 100644 --- a/openbsc/src/ipaccess/ipaccess-find.c +++ b/openbsc/src/ipaccess/ipaccess-find.c @@ -40,12 +40,14 @@ static int udp_sock(const char *ifname) if (fd < 0) return fd; +#ifndef __APPLE__ if (ifname) { rc = setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, ifname, strlen(ifname)); if (rc < 0) goto err; } +#endif sa.sin_family = AF_INET; sa.sin_port = htons(3006); @@ -172,12 +174,14 @@ int main(int argc, char **argv) printf("ipaccess-find (C) 2009 by Harald Welte\n"); printf("This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY\n\n"); +#ifndef __APPLE__ if (argc < 2) { fprintf(stdout, "you might need to specify the outgoing\n" " network interface, e.g. ``%s eth0''\n", argv[0]); } else { ifname = argv[1]; } +#endif bfd.cb = bfd_cb; bfd.when = BSC_FD_READ | BSC_FD_WRITE; -- 1.7.10.2 (Apple Git-33) From jrees at arbor.net Wed Oct 24 16:14:38 2012 From: jrees at arbor.net (Jim Rees) Date: Wed, 24 Oct 2012 12:14:38 -0400 Subject: [openbsc PATCH 1/3] Remove interface argument when compiled on OSX In-Reply-To: <1351094030-1325-2-git-send-email-t-openbsc@tobias.org> References: <1351094030-1325-1-git-send-email-t-openbsc@tobias.org> <1351094030-1325-2-git-send-email-t-openbsc@tobias.org> Message-ID: I would make this #ifdef SO_BINDTODEVICE. From laforge at gnumonks.org Sat Oct 27 08:08:05 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 27 Oct 2012 10:08:05 +0200 Subject: [openbsc PATCH 1/3] Remove interface argument when compiled on OSX In-Reply-To: References: <1351094030-1325-1-git-send-email-t-openbsc@tobias.org> <1351094030-1325-2-git-send-email-t-openbsc@tobias.org> Message-ID: <20121027080805.GY31205@prithivi.gnumonks.org> On Wed, Oct 24, 2012 at 12:14:38PM -0400, Jim Rees wrote: > I would make this #ifdef SO_BINDTODEVICE. I agree, please re-submit based on that. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Wed Oct 24 16:20:47 2012 From: peter at stuge.se (Peter Stuge) Date: Wed, 24 Oct 2012 18:20:47 +0200 Subject: [openbsc PATCH 1/3] Remove interface argument when compiled on OSX In-Reply-To: <1351094030-1325-2-git-send-email-t-openbsc@tobias.org> References: <1351094030-1325-1-git-send-email-t-openbsc@tobias.org> <1351094030-1325-2-git-send-email-t-openbsc@tobias.org> Message-ID: <20121024162047.21203.qmail@stuge.se> Tobias Engel wrote: > Since it is not possible to bind a socket to a specific interface on > OSX, remove the option to specify the interface when compiled on OSX. Maybe it would be even better to change the tool to bind() to a given local IP address, rather than an interface, to be more like every other software. //Peter From laforge at gnumonks.org Sat Oct 27 08:07:46 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 27 Oct 2012 10:07:46 +0200 Subject: [openbsc PATCH 1/3] Remove interface argument when compiled on OSX In-Reply-To: <20121024162047.21203.qmail@stuge.se> References: <1351094030-1325-1-git-send-email-t-openbsc@tobias.org> <1351094030-1325-2-git-send-email-t-openbsc@tobias.org> <20121024162047.21203.qmail@stuge.se> Message-ID: <20121027080746.GX31205@prithivi.gnumonks.org> Hi Peter, On Wed, Oct 24, 2012 at 06:20:47PM +0200, Peter Stuge wrote: > Maybe it would be even better to change the tool to bind() to a given > local IP address, rather than an interface, to be more like every > other software. I would argue that most people know with more certainty the interface name than the IP address assigned to that interface. Especially in DHCP cases you would always have to check first what's the IP address, then put that into the command. Also think of scripting scenarios, where you definitely don't want to 'sed' the IP address out of ifconfig/ip output before calling ipaccess-config. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From t-openbsc at tobias.org Wed Oct 24 15:53:49 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Wed, 24 Oct 2012 17:53:49 +0200 Subject: [openbsc PATCH 2/3] Remove unused librt dependency In-Reply-To: <1351094030-1325-1-git-send-email-t-openbsc@tobias.org> References: <1351094030-1325-1-git-send-email-t-openbsc@tobias.org> Message-ID: <1351094030-1325-3-git-send-email-t-openbsc@tobias.org> --- openbsc/tests/mgcp/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openbsc/tests/mgcp/Makefile.am b/openbsc/tests/mgcp/Makefile.am index ff67cf8..d99c978 100644 --- a/openbsc/tests/mgcp/Makefile.am +++ b/openbsc/tests/mgcp/Makefile.am @@ -11,4 +11,4 @@ mgcp_test_SOURCES = mgcp_test.c mgcp_test_LDADD = $(top_builddir)/src/libbsc/libbsc.a \ $(top_builddir)/src/libmgcp/libmgcp.a \ $(top_builddir)/src/libcommon/libcommon.a \ - $(LIBOSMOCORE_LIBS) -lrt $(LIBOSMOSCCP_LIBS) $(LIBOSMOVTY_LIBS) + $(LIBOSMOCORE_LIBS) $(LIBOSMOSCCP_LIBS) $(LIBOSMOVTY_LIBS) -- 1.7.10.2 (Apple Git-33) From holger at freyther.de Thu Oct 25 14:56:52 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 25 Oct 2012 16:56:52 +0200 Subject: [openbsc PATCH 2/3] Remove unused librt dependency In-Reply-To: <1351094030-1325-3-git-send-email-t-openbsc@tobias.org> References: <1351094030-1325-1-git-send-email-t-openbsc@tobias.org> <1351094030-1325-3-git-send-email-t-openbsc@tobias.org> Message-ID: <20121025145652.GC9520@xiaoyu.lan> On Wed, Oct 24, 2012 at 05:53:49PM +0200, Tobias Engel wrote: > - $(LIBOSMOCORE_LIBS) -lrt $(LIBOSMOSCCP_LIBS) $(LIBOSMOVTY_LIBS) > + $(LIBOSMOCORE_LIBS) $(LIBOSMOSCCP_LIBS) $(LIBOSMOVTY_LIBS) man clock_gettime. Which library provides this function on OSX? From t-openbsc at tobias.org Thu Oct 25 15:17:00 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Thu, 25 Oct 2012 17:17:00 +0200 Subject: [openbsc PATCH 2/3] Remove unused librt dependency In-Reply-To: <20121025145652.GC9520@xiaoyu.lan> References: <1351094030-1325-1-git-send-email-t-openbsc@tobias.org> <1351094030-1325-3-git-send-email-t-openbsc@tobias.org> <20121025145652.GC9520@xiaoyu.lan> Message-ID: <508957EC.9000403@tobias.org> On 25.10.12 16:56, Holger Hans Peter Freyther wrote: > On Wed, Oct 24, 2012 at 05:53:49PM +0200, Tobias Engel wrote: >> - $(LIBOSMOCORE_LIBS) -lrt $(LIBOSMOSCCP_LIBS) $(LIBOSMOVTY_LIBS) >> + $(LIBOSMOCORE_LIBS) $(LIBOSMOSCCP_LIBS) $(LIBOSMOVTY_LIBS) > > man clock_gettime. I know - but either I am blind or that function is never used in the code. time.h isn't even included: openbsc/openbsc/tests/mgcp $ grep clock * openbsc/openbsc/tests/mgcp $ grep time * openbsc/openbsc/tests/mgcp $ -Tobias From holger at freyther.de Thu Oct 25 16:18:23 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 25 Oct 2012 18:18:23 +0200 Subject: [openbsc PATCH 2/3] Remove unused librt dependency In-Reply-To: <508957EC.9000403@tobias.org> References: <1351094030-1325-1-git-send-email-t-openbsc@tobias.org> <1351094030-1325-3-git-send-email-t-openbsc@tobias.org> <20121025145652.GC9520@xiaoyu.lan> <508957EC.9000403@tobias.org> Message-ID: <20121025161823.GB24111@xiaoyu.lan> On Thu, Oct 25, 2012 at 05:17:00PM +0200, Tobias Engel wrote: > On 25.10.12 16:56, Holger Hans Peter Freyther wrote: > I know - but either I am blind or that function is never used in the > code. time.h isn't even included: > > openbsc/openbsc/tests/mgcp $ grep clock * > openbsc/openbsc/tests/mgcp $ grep time * > openbsc/openbsc/tests/mgcp $ well, two things. 1.) We build libmgcp.a and these archives do not have library deps. This means you would need to grep in src/libmgcp and src/libcommon as well. 2.) I am going to use clock_gettime real soon(tm). You can check the zecke/mgcp-statistics branch where I implement proper RTP packet loss and jitter calculation. thanks holger From t-openbsc at tobias.org Wed Oct 24 15:53:50 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Wed, 24 Oct 2012 17:53:50 +0200 Subject: [openbsc PATCH 3/3] Set byte order defines when compiled on OSX In-Reply-To: <1351094030-1325-1-git-send-email-t-openbsc@tobias.org> References: <1351094030-1325-1-git-send-email-t-openbsc@tobias.org> Message-ID: <1351094030-1325-4-git-send-email-t-openbsc@tobias.org> Byte order defines have a DARWIN prefix on OSX so the values openbsc expects are set from their Darwin counterparts when compiled on OSX. --- openbsc/src/libmgcp/mgcp_network.c | 8 +++++++- openbsc/src/libtrau/rtp_proxy.c | 8 +++++++- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/openbsc/src/libmgcp/mgcp_network.c b/openbsc/src/libmgcp/mgcp_network.c index 848f8cd..8824dc8 100644 --- a/openbsc/src/libmgcp/mgcp_network.c +++ b/openbsc/src/libmgcp/mgcp_network.c @@ -42,7 +42,13 @@ #include #ifndef __BYTE_ORDER -#error "__BYTE_ORDER should be defined by someone" +# ifdef __APPLE__ +# define __BYTE_ORDER __DARWIN_BYTE_ORDER +# define __LITTLE_ENDIAN __DARWIN_LITTLE_ENDIAN +# define __BIG_ENDIAN __DARWIN_BIG_ENDIAN +# else +# error "__BYTE_ORDER should be defined by someone" +# endif #endif /* according to rtp_proxy.c RFC 3550 */ diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index 3d34ac6..f7c5a4f 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -42,7 +42,13 @@ #include #ifndef __BYTE_ORDER -#error "__BYTE_ORDER should be defined by someone" +# ifdef __APPLE__ +# define __BYTE_ORDER __DARWIN_BYTE_ORDER +# define __LITTLE_ENDIAN __DARWIN_LITTLE_ENDIAN +# define __BIG_ENDIAN __DARWIN_BIG_ENDIAN +# else +# error "__BYTE_ORDER should be defined by someone" +# endif #endif static LLIST_HEAD(rtp_sockets); -- 1.7.10.2 (Apple Git-33) From laforge at gnumonks.org Sat Oct 27 08:09:36 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 27 Oct 2012 10:09:36 +0200 Subject: [openbsc PATCH 3/3] Set byte order defines when compiled on OSX In-Reply-To: <1351094030-1325-4-git-send-email-t-openbsc@tobias.org> References: <1351094030-1325-1-git-send-email-t-openbsc@tobias.org> <1351094030-1325-4-git-send-email-t-openbsc@tobias.org> Message-ID: <20121027080935.GZ31205@prithivi.gnumonks.org> On Wed, Oct 24, 2012 at 05:53:50PM +0200, Tobias Engel wrote: > Byte order defines have a DARWIN prefix on OSX so the values openbsc > expects are set from their Darwin counterparts when compiled on OSX. I've only applied this part out of the series, as the others are still under discussion. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Wed Oct 24 18:49:36 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 24 Oct 2012 22:49:36 +0400 Subject: [PATH] Selecting the latest nanoBTS firmware on connect Re: nanoBTS bring up problem Message-ID: Hi all, Here is a patch which selects the latest nanoBTS firmware when it tries to connect to OpenBSC. This fixed the problem with NACKs for us. Sometimes (like in our case) nanoBTS has two firmwares and could boot any of them. Which one to boot is selected by a BSC during the initial OML setup. Originally OpenBSC selected the first firmware available, which gave us random results - sometimes the older firmware was booted, sometimes the newer firmware was loaded. With this patch OpenBSC always selects the latest firmware to boot (using simple string comparison of firmware version strings). In our case this now gives stable results. PS I don't have time to improve this patch if it's too hackish to be checked in, but I hope it will inspire someone to create a better one. On Tue, Oct 23, 2012 at 4:10 PM, Ivan Kluchnikov wrote: > Hi! > > We solved this problem, it seems, that ipaccess-config didn't work > correctly for our nanoBTS. > We set primary OML link IP and port using ipaccess-telnet and nanoBTS bring up. > Now we have working osmo-nitb. > > 2012/10/23 Ivan Kluchnikov : >> Hi all! >> >> We tried to deploy our nanoBTS with osmo-nitb, but unfortunately we >> had no success. >> We have the following logs for ipaccess-find, ipaccess-config, >> osmo-nitb and ipaccess-telnet. >> We would appreciate it, if someone gives us advice. >> What does these logs mean? >> Is it possible, that the problem is in firmware, and we should update it? >> >> ./ipaccess-find >> MAC_Address='00:02:95:00:01:7e' IP_Address='172.44.4.75' >> Unit_ID='1801/0/0' Location_1='' Location_2='BTS_NBT131G' >> Equipment_Version='110_029_13' Software_Version='119a002_v149b18d0' >> Unit_Name='nbts-00-02-95-00-01-7E' Serial_Number='00024616' >> >> ./ipaccess-config -n 0x400/0x400 172.44.4.75 >> <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE >> CHG: OP_STATE=Disabled AVAIL=Not installed(07) >> OML link established using TRX 0 >> setting NV Flags/Mask to 0x0400/0x0400 >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) >> IPACCESS(0xf0): SET NVATTR ACK >> Set the NV Attributes. >> >> ./osmo-nitb --debug=DRLL:DCC:DMM:DRR:DRSL:DNM -c openbsc.cfg >> DB: Database initialized. >> DB: Database prepared. >> <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE >> CHG: OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) SW Activate >> Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and >> Activating >> <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 >> 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 42 12 00 08 31 31 39 61 30 >> 30 32 00 13 00 0a 76 32 30 39 62 32 36 64 30 00 >> <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Not installed(07) >> <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Software >> Activated Report >> <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Off line(03) >> <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART >> <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) SW Activate Request: >> <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating >> <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 >> 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 >> <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) SW Activate >> Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and >> Activating >> <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 >> 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 >> <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: >> OP_STATE=Enabled >> <0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART >> <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) Software Activated Report >> <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Dependency(05) >> <0005> abis_nm.c:1379 Set BTS Attr (bts=0) >> <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART >> <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) SW >> Activate Request: <0005> abis_nm.c:418 Software Activate Request, >> ACKing and Activating >> <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 31 >> 00 13 00 0a 76 32 30 39 62 32 36 64 30 00 42 12 00 08 31 31 39 61 30 >> 30 32 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 >> <0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) SW Activate >> Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and >> Activating >> <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 31 >> 00 13 00 0a 76 32 30 39 62 32 36 64 30 00 42 12 00 08 31 31 39 61 30 >> 30 32 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 >> <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) Software Activated Report >> <0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Dependency(05) >> <0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) SW Activate >> Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and >> Activating >> <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 >> 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 >> <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) SW Activate >> Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and >> Activating >> <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 >> 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 >> <0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) SW Activate >> Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and >> Activating >> <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 >> 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 >> <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: >> OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked >> <0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) OPSTART NACK >> CAUSE=Message cannot be performed >> <0005> bsc_init.c:54 Got a NACK going to drop the OML links. >> >> ./ipaccess-telnet 172.44.4.75 3210 >> 14851:DBG:CLI_SKT:Remote client 172.44.4.4 connected >> 16160:DBG:IP_CHANNEL:Assigning RX Client A >> 16160:DBG:IP_CHAN_RX_A:Attempting connection to 172.44.4.4:3002 >> 20572:DBG:IP_CHANNEL:Assigning RX Client A >> 20572:DBG:IP_CHAN_RX_A:Attempting connection to 172.44.4.4:3002 >> 21007:DBG:OAM_IM:Set SYSTEM LINK to 65.255 >> 21051:DBG:OAM_MOI:Can Activate?=TRUE >> 21051:DBG:OAM_MOI:Sw Activate - activating BH idx=1 >> 21051:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=255) >> 21051:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: BTS:0 flag 3 not >> setting or set! >> 21051:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: GPRS NSE:0 flag >> 3 not setting or set! >> 21063:DBG:OAM_MOI:Can Activate?=TRUE >> 21063:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 >> 21063:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=255) >> 21064:DBG:OAM_MOI:Can Activate?=TRUE >> 21064:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 >> 21064:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=255) >> 21067:DBG:GB_OAM:Received OPEN_REQ for NSE 0. >> 21075:DBG:OAM_IM:Ignored imSetFrameNumber. >> 21075:DBG:OAM_MOI:oid=BTS:0 publisher attributes set >> 21077:DBG:OAM_MOI:Can Activate?=TRUE >> 21078:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 >> 21078:DBG:OAM_MOI:Sw Activate - sending trx boot request to activate TRX idx=1 >> 21078:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=1) >> 21078:DBG:OAM_MOI:Can Activate?=TRUE >> 21078:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 >> 21079:DBG:OAM_MOI:Sw Activate - already activated TRX idx=1 >> 21079:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=1) >> 21079:DBG:OAM_MOI:Can Activate?=TRUE >> 21079:DBG:OAM_MOI:6110:gprs.cell: EVENT 0x000007d4 rxd in STATE initial >> 21079:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 >> 21079:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=1) >> 21079:DBG:OAM_MOI:6112:gprs.cell: EVENT 0x000007cb rxd in STATE >> waitopenresources >> 21080:DBG:OAM_MOI:6124:gprs.cell: EVENT 0x000007cd rxd in STATE >> waitregisterdependencycnf >> 21080:DBG:OAM_MOI:6125:gprs.cell: EVENT 0x000007cd rxd in STATE >> waitregisterdependencycnf >> 21080:DBG:OAM_MOI:6126:gprs.cell: EVENT 0x000007cd rxd in STATE >> waitregisterdependencycnf >> 21081:DBG:OAM_MOI:6127:gprs.cell: EVENT 0x000007cd rxd in STATE >> waitregisterdependencycnf >> 21081:DBG:OAM_MOI:6128:gprs.cell: EVENT 0x000007cd rxd in STATE >> waitregisterdependencycnf >> 21081:DBG:OAM_MOI:6129:gprs.cell: EVENT 0x000007cd rxd in STATE >> waitregisterdependencycnf >> 21081:DBG:OAM_MOI:6130:gprs.cell: EVENT 0x000007cd rxd in STATE >> waitregisterdependencycnf >> 21081:DBG:OAM_MOI:6131:gprs.cell: EVENT 0x000007cd rxd in STATE >> waitregisterdependencycnf >> 21082:DBG:OAM_MOI:6132:gprs.cell: EVENT 0x000007cd rxd in STATE >> waitregisterdependencycnf >> 21082:DBG:OAM_MOI:6133:gprs.cell: EVENT 0x000007cd rxd in STATE >> waitregisterdependencycnf >> 21083:DBG:OAM_MOI:6134:gprs.cell: EVENT 0x000007cd rxd in STATE >> waitregisterdependencycnf >> 21086:DBG:OAM_MOI:Can Activate?=TRUE >> 21086:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 >> 21086:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=1) >> 21087:DBG:OAM_MOI:Can Activate?=TRUE >> 21087:DBG:OAM_MOI:Sw Activate - already activated BH idx=1 >> 21087:DBG:OAM_MOI:Sw Activate - BH(def=1 act=1) TRX(def=1 act=1) >> 21088:DBG:OAM_MOI:6166:gprs.cell: EVENT 0x000007ca rxd in STATE waitopencnf >> 21088:DBG:GB_OAM:Received OPEN_REQ for NSVC 0. >> 21089:DBG:GB_OAM:Received OPEN_REQ for NSVC 1. >> 21089:DBG:TRX_BOOT:Sending Cnf idx=1 token=969 task=2 >> 21098:DBG:TRX_BOOT:Sending Cnf idx=1 token=1031 task=2 >> 21519:DBG:OAM_IM:Clear SYSTEM LINK >> 21523:DBG:OAM_MOI:6426:gprs.cell: EVENT 0x000007c7 rxd in STATE active >> 21523:DBG:OAM_MOI:6426:gprs.cell: EXITING swactivated >> 21527:DBG:OAM_RES:Failed to deregister dependency: token=1024 not >> found (class=1 instance=7) >> 21527:DBG:OAM_RES:Failed to deregister dependency: token=1017 not >> found (class=1 instance=6) >> 21527:DBG:OAM_RES:Failed to deregister dependency: token=1010 not >> found (class=1 instance=5) >> 21527:DBG:OAM_RES:Failed to deregister dependency: token=1003 not >> found (class=1 instance=4) >> 21527:DBG:OAM_RES:Failed to deregister dependency: token=996 not found >> (class=1 instance=3) >> 21527:DBG:OAM_RES:Failed to deregister dependency: token=989 not found >> (class=1 instance=2) >> 21528:DBG:OAM_RES:Failed to deregister dependency: token=982 not found >> (class=1 instance=1) >> 21528:DBG:OAM_RES:Failed to deregister dependency: token=975 not found >> (class=1 instance=0) >> 21528:DBG:OAM_RES:Failed to deregister dependency: token=969 not found >> (class=0 instance=0) >> 21528:DBG:OAM_RES:Failed to deregister dependency: token=1031 not >> found (class=2 instance=0) >> 21528:DBG:OAM_RES:Failed to deregister dependency: token=964 not found >> (class=2 instance=0) >> 21528:DBG:OAM_RES:Failed to deregister dependency: token=964 not found >> (class=1 instance=0) >> 21528:DBG:OAM_RES:Failed to deregister dependency: token=1047 not >> found (class=2 instance=0) >> 21528:DBG:OAM_RES:Failed to deregister dependency: token=1047 not >> found (class=1 instance=0) >> 21608:DBG:DB_EE:Writing 174 bytes of DBX data to block 3 >> 21608:DBG:DB_EE:Re-using existing DBX block >> 21857:DBG:DB_EE:NV block 3 - wrote block to NV, main and backup OK. >> 21857:DBG:DB_EE:EE update complete. >> 21931:DBG:DB_EE:EE update complete. >> 22004:DBG:DB_EE:EE update complete. >> 22078:DBG:DB_EE:EE update complete. >> 22151:DBG:DB_EE:EE update complete. >> 22225:DBG:DB_EE:EE update complete. >> 22298:DBG:DB_EE:EE update complete. >> 22371:DBG:DB_EE:EE update complete. >> >> >> -- >> Regards, >> Ivan Kluchnikov. >> http://fairwaves.ru > > > > -- > Regards, > Ivan Kluchnikov. > http://fairwaves.ru > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: nanobts-sw-selection.patch Type: application/octet-stream Size: 3275 bytes Desc: not available URL: From holger at freyther.de Thu Oct 25 14:59:47 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 25 Oct 2012 16:59:47 +0200 Subject: [PATH] Selecting the latest nanoBTS firmware on connect Re: nanoBTS bring up problem In-Reply-To: References: Message-ID: <20121025145947.GD9520@xiaoyu.lan> On Wed, Oct 24, 2012 at 10:49:36PM +0400, Alexander Chemeris wrote: > PS I don't have time to improve this patch if it's too hackish to be > checked in, but I hope it will inspire someone to create a better one. thanks. I think we should have a testcase for that. Could you provide a hexdump of the SW Description? If it is too much work I should be able to extract it from the pcap file. thanks holger From alexander.chemeris at gmail.com Thu Oct 25 17:14:32 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 25 Oct 2012 21:14:32 +0400 Subject: [PATH] Selecting the latest nanoBTS firmware on connect Re: nanoBTS bring up problem In-Reply-To: <20121025145947.GD9520@xiaoyu.lan> References: <20121025145947.GD9520@xiaoyu.lan> Message-ID: Hi Holger, On Thu, Oct 25, 2012 at 6:59 PM, Holger Hans Peter Freyther < holger at freyther.de> wrote: > On Wed, Oct 24, 2012 at 10:49:36PM +0400, Alexander Chemeris wrote: >> PS I don't have time to improve this patch if it's too hackish to be >> checked in, but I hope it will inspire someone to create a better one. > > thanks. I think we should have a testcase for that. Could you provide > a hexdump of the SW Description? If it is too much work I should be > able to extract it from the pcap file. Three variants, extracted from my previous e-mail about the NACK problem: <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 36 64 30 00 <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 <0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 31 39 61 30 30 31 00 13 00 0a 76 32 30 39 62 32 36 64 30 00 42 12 00 08 31 31 39 61 30 30 32 00 13 00 0a 76 31 34 39 62 31 38 64 30 00 -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at carrierdetect.com Thu Oct 25 17:51:07 2012 From: andrew at carrierdetect.com (Andrew Back) Date: Thu, 25 Oct 2012 18:51:07 +0100 Subject: BTS-MS direct connection. Message-ID: Hello, I'd like to directly cable a handset to a nanoBTS and thought I could: - put attenuators on the nanoBTS TX and RX ports - connect the other side of each attenuator to a resistive splitter/combiner that has 6dB loss - connect the combiner common port to the MS Does this sound sensible and if so what size of attenuators might I want assuming MS and BTS were each set at 6dBm? I've seen figures for receiver sensitivity, but wasn't sure as to a "good" RF level to use with direct cabling! I also have 10/20 dB directional couplers and circulators if they might find use in a better configuration. Regards, Andrew -- Andrew Back http://carrierdetect.com From nikpakar at gmail.com Thu Oct 25 18:01:17 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Thu, 25 Oct 2012 23:31:17 +0530 Subject: BTS-MS direct connection. In-Reply-To: References: Message-ID: Phew ! why do you need to do this at all ? To avoid RF emission ? even using this method you will still leak out enough RF which you can easily use the MS over the air. On Thu, Oct 25, 2012 at 11:21 PM, Andrew Back wrote: > Hello, > > I'd like to directly cable a handset to a nanoBTS and thought I could: > > - put attenuators on the nanoBTS TX and RX ports > - connect the other side of each attenuator to a resistive > splitter/combiner that has 6dB loss > - connect the combiner common port to the MS > > Does this sound sensible and if so what size of attenuators might I > want assuming MS and BTS were each set at 6dBm? I've seen figures for > receiver sensitivity, but wasn't sure as to a "good" RF level to use > with direct cabling! > > I also have 10/20 dB directional couplers and circulators if they > might find use in a better configuration. > > Regards, > > Andrew > > -- > Andrew Back > http://carrierdetect.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at carrierdetect.com Thu Oct 25 18:09:18 2012 From: andrew at carrierdetect.com (Andrew Back) Date: Thu, 25 Oct 2012 19:09:18 +0100 Subject: BTS-MS direct connection. In-Reply-To: References: Message-ID: On 25 October 2012 19:01, Nik Pakar wrote: > Phew ! why do you need to do this at all ? Since the only BTS hardware I currently have access to is 1900MHz and thus cannot be licensed in the UK. > To avoid RF emission ? even using this method you will still leak out enough > RF which you can easily use the MS over the air. I see, but this would almost suggest that you need a development licence just to tune a bench signal generator to a frequency in spectrum such as used by GSM ... Regards, Andrew -- Andrew Back http://carrierdetect.com From nikpakar at gmail.com Thu Oct 25 18:16:35 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Thu, 25 Oct 2012 23:46:35 +0530 Subject: BTS-MS direct connection. In-Reply-To: References: Message-ID: Ok. understand your issue. But trying to do what you suggest wont help that much. I think using maximum attenuation on BTS (3dBm power with 20dB attenuation) and also forcing MS to use lowest power, you will have lab coverage without interfering external world. It will hardly go out if your lab is a concrete or brick building. On Thu, Oct 25, 2012 at 11:39 PM, Andrew Back wrote: > On 25 October 2012 19:01, Nik Pakar wrote: > > Phew ! why do you need to do this at all ? > > Since the only BTS hardware I currently have access to is 1900MHz and > thus cannot be licensed in the UK. > > > To avoid RF emission ? even using this method you will still leak out > enough > > RF which you can easily use the MS over the air. > > I see, but this would almost suggest that you need a development > licence just to tune a bench signal generator to a frequency in > spectrum such as used by GSM ... > > Regards, > > Andrew > > -- > Andrew Back > http://carrierdetect.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Thu Oct 25 18:47:19 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 25 Oct 2012 20:47:19 +0200 Subject: BTS-MS direct connection. In-Reply-To: References: Message-ID: > Does this sound sensible and if so what size of attenuators might I > want assuming MS and BTS were each set at 6dBm? I've seen figures for > receiver sensitivity, but wasn't sure as to a "good" RF level to use > with direct cabling! > > I also have 10/20 dB directional couplers and circulators if they > might find use in a better configuration. Yes it sounds perfectly good. Make sure you connect attenuators as close to the BTS and MS as possible to avoid as much leak as possible. You should target something like - 60 dBm at the RX. So something like 90 dB attenuation or so. Make sure to use semi rigid cable because at that level of attenuation the cable leaks are non negligible :) Cheers, Sylvain From andrew at carrierdetect.com Thu Oct 25 18:57:28 2012 From: andrew at carrierdetect.com (Andrew Back) Date: Thu, 25 Oct 2012 19:57:28 +0100 Subject: BTS-MS direct connection. In-Reply-To: References: Message-ID: On 25 October 2012 19:47, Sylvain Munaut <246tnt at gmail.com> wrote: >> Does this sound sensible and if so what size of attenuators might I >> want assuming MS and BTS were each set at 6dBm? I've seen figures for >> receiver sensitivity, but wasn't sure as to a "good" RF level to use >> with direct cabling! >> >> I also have 10/20 dB directional couplers and circulators if they >> might find use in a better configuration. > > Yes it sounds perfectly good. Make sure you connect attenuators as > close to the BTS and MS as possible to avoid as much leak as possible. That is good to hear. > You should target something like - 60 dBm at the RX. So something like > 90 dB attenuation or so. Wouldn't 90 dB attenuation for -60 dBm at RX suggest a TX power of 30 dBm = 1 watt? Seems high and was thinking of closer 6 dBm at TX. But if I know to aim for -60 dBm at receive ... > Make sure to use semi rigid cable because at > that level of attenuation the cable leaks are non negligible :) Good advice, thanks! Cheers, Andrew -- Andrew Back http://carrierdetect.com From jrees at arbor.net Thu Oct 25 19:16:29 2012 From: jrees at arbor.net (Jim Rees) Date: Thu, 25 Oct 2012 15:16:29 -0400 Subject: BTS-MS direct connection. In-Reply-To: References: Message-ID: <851895A4-AB38-44E5-BF42-E49D11497FBD@arbor.net> My BTS has a min xmit power of -1dbm. I couldn't find specs on max rcv input power for my particular device, but similar devices have specs in the -20 to -25dbm range. My test set is adjustable from -104 to -25. No need to attenuate all the way to -60. But if you can find specs for your receiver, it's better to use them than info from some guy on the Internet. From jrees at arbor.net Thu Oct 25 18:50:50 2012 From: jrees at arbor.net (Jim Rees) Date: Thu, 25 Oct 2012 14:50:50 -0400 Subject: BTS-MS direct connection. In-Reply-To: References: Message-ID: <642DB867-BD75-4567-915E-95C744C5284F@arbor.net> I've done this. My employer likes me to stay legal, so I looked up the FCC rules about unlicensed operation (I'm in the US), did the calculations, and determined that I could in fact keep the leakage below limits, and the input power to the HS and BTS receivers within proper range. I'm using the BTS at minimum power of course. I use a Minicircuits ZAPD-20-S+ power splitter, which has 30db isolation between the two ports, and a single 30db attenuator on the HS side. With my equipment I need a minimum of 24db attenuation between each transmitter and the opposite receiver. I did not check the leakage as I don't have a calibrated field strength meter but according to specs it should be ok. I've got the numbers if you're interested. From baumgrass at hotmail.com Tue Oct 30 09:58:10 2012 From: baumgrass at hotmail.com (=?iso-8859-1?B?QmVybmQgQmF1bWdyYd8=?=) Date: Tue, 30 Oct 2012 10:58:10 +0100 Subject: BS-11 and HFC-E1 for sale Message-ID: Hello, I am thinking about selling my Siemens BS-11 and a compatible HFC-E1 Evaluation Board. If anyone is interested please send me a mail: baumgrass at hotmail.com . Regards, Bernd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From t-openbsc at tobias.org Tue Oct 30 14:45:01 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Tue, 30 Oct 2012 15:45:01 +0100 Subject: [openbsc PATCH v2] Make openbsc also compile/run on OSX Message-ID: <1351608302-43092-1-git-send-email-t-openbsc@tobias.org> I modified the patch for ipaccess-find based on Jim's and Holger's suggestions. Still not sure what to do about the (coming) librt dependency, so no new version of that patch for now. Tobias Tobias Engel (1): Remove iface arg if SO_BINDTODEVICE isn't available openbsc/src/ipaccess/ipaccess-find.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) -- 1.7.10.2 (Apple Git-33) From t-openbsc at tobias.org Tue Oct 30 14:45:02 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Tue, 30 Oct 2012 15:45:02 +0100 Subject: [openbsc PATCH v2] Remove iface arg if SO_BINDTODEVICE isn't available In-Reply-To: <1351608302-43092-1-git-send-email-t-openbsc@tobias.org> References: <1351608302-43092-1-git-send-email-t-openbsc@tobias.org> Message-ID: <1351608302-43092-2-git-send-email-t-openbsc@tobias.org> Remove the commandline option to specify the interface when compiled on a system that doesn't implement SO_BINDTODEVICE. --- openbsc/src/ipaccess/ipaccess-find.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/openbsc/src/ipaccess/ipaccess-find.c b/openbsc/src/ipaccess/ipaccess-find.c index 3f9bf41..2d923fe 100644 --- a/openbsc/src/ipaccess/ipaccess-find.c +++ b/openbsc/src/ipaccess/ipaccess-find.c @@ -31,6 +31,14 @@ #include #include +/* SO_BINDTODEVICE is not implemented on BSD */ +#ifdef SO_BINDTODEVICE +# define SET_SO_BINDTODEVICE(fd, ifname) \ + (setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, ifname, strlen(ifname))) +#else +# define SET_SO_BINDTODEVICE(fd, ifname) (-1) +#endif + static int udp_sock(const char *ifname) { int fd, rc, bc = 1; @@ -41,8 +49,7 @@ static int udp_sock(const char *ifname) return fd; if (ifname) { - rc = setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, ifname, - strlen(ifname)); + rc = SET_SO_BINDTODEVICE(fd, ifname); if (rc < 0) goto err; } @@ -172,12 +179,14 @@ int main(int argc, char **argv) printf("ipaccess-find (C) 2009 by Harald Welte\n"); printf("This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY\n\n"); +#ifdef SO_BINDTODEVICE if (argc < 2) { fprintf(stdout, "you might need to specify the outgoing\n" " network interface, e.g. ``%s eth0''\n", argv[0]); } else { ifname = argv[1]; } +#endif bfd.cb = bfd_cb; bfd.when = BSC_FD_READ | BSC_FD_WRITE; -- 1.7.10.2 (Apple Git-33) From yannm1 at hotmail.com Wed Oct 31 15:43:51 2012 From: yannm1 at hotmail.com (Yann R. Moupinda) Date: Wed, 31 Oct 2012 16:43:51 +0100 Subject: triplets calculation Message-ID: Hi guys, i'm trying to interconnect a WLAN router with my GSM-sysmoBTS and to use the EAP-SIM authentication protocol. For that i installed a Freeradius on an external board that i use as radius server. The Freeradius should use a database file in order to realise the authentication and the idea is that Freeradius should be able to read the hlr.sqlite3 file from my sysmoBTS. I'm not so far to do this part of the work so, i first want to do some tests using the sim card from sysmoBTS (imsi und ki) and the triplets (RAND, Kc and SRES). I want to create a flat file containing this values so the Freeradius will directly use the file to get the triplets. I thought i could get the triplets stored in one of the tables of hlr.sqlite3 (AuthLastTuples) but there is no information on it. From the table AuthKeys i could find some Ki values (e.g X'019B7083FBAFC928421A147DE795217782'). I found that there is an "osmo-auc-gen" program for computing the triplets. By using the Ki from AuthKeys and a self generated RAND (e.g 0123456789ABCDEF0123456789ABCDEF) the program doesn't run and doesn't give the triplets. The used authentication algorithm is the COMP128v1. Has anyone an idea why it doesn't work and why there is no information in the AuthLastTuples table from sysmoBTS ? best regards Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: