From tillusbazillus at gmx.net Wed Apr 14 15:23:17 2010 From: tillusbazillus at gmx.net (till) Date: Wed, 14 Apr 2010 17:23:17 +0200 Subject: BS-11 multidrop problem In-Reply-To: References: Message-ID: <1271258597.6917.13.camel@core2> Hi, i am still trying to get hose two BS-11 to run. The hfcmulti driver is now configured with dmask and bmask (just had the wrong version, thx to Andreas). But there are still no OML and RSL-connections to the second BS-11 initialized. And i found no possibility to put bport1 into multidrop. I appreciate any help :) ! "The problem is now solved. It seems that we need to create the BPORT1 object on BTS-A, and configure both BPORT0 and BPORT1 into multi-drop mode. Thanks to Dieter for his help with that." Greets Till Some outputs: ____BS-11_A____________________________________________ (create bport1 and put bport0 into multidrop) ./bs11_config query bs11_config (C) 2009 by Harald Welte and Dieter Spaar This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY LMT LOGON: ACK PHASE: 3 Normal MBCCU0: Load MBCCU1: No Load Abis-link: Restoring BS11 ATTRIBUTES: BS-11 ESN PCB Serial Number: 001127 BS-11 ESN Hardware Code Number: 135-2044/03.03 BS-11 ESN Firmware Code Number: 135-2044/03.03 PLL Set Value=1026, Work Value=1026 SITE MANAGER ATTRIBUTES: E1 Channel: Port=0 Timeslot=1 (Full Slot) TEI: 25 BS11 Line Interface ATTRIBUTES: PLL Mode: Standalone BS11 CCLK ATTRIBUTES: CCLK Accuracy: Medium (0) BS11 Power Amplifier 0 ATTRIBUTES: TRX Power: 30mW (GSM) LMT LOGOFF: ACK ____BS-11_B____________________________________________ ./bs11_config query bs11_config (C) 2009 by Harald Welte and Dieter Spaar This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY LMT LOGON: ACK PHASE: 3 Normal MBCCU0: Load MBCCU1: Unknown Abis-link: Restoring BS11 ATTRIBUTES: BS-11 ESN PCB Serial Number: 000432 BS-11 ESN Hardware Code Number: 135-2044/02.07 BS-11 ESN Firmware Code Number: 135-2044/02.07 PLL Set Value=942, Work Value=942 SITE MANAGER ATTRIBUTES: E1 Channel: Port=1 Timeslot=17 (Full Slot) TEI: 26 BS11 Line Interface ATTRIBUTES: PLL Mode: Standalone BS11 CCLK ATTRIBUTES: CCLK Accuracy: Medium (0) BS11 Power Amplifier 0 ATTRIBUTES: TRX Power: 30mW (GSM) LMT LOGOFF: ACK ____MISDN____________________________________________ debian:/home/till/openbsc/openbsc/src# misdn_info Found 2 ports Port 0 'hfc-e1.1-1': TE/NT-mode PRI E1 (for phone lines & E1 devices) 14 B-channels: 2-15 B-protocols: RAW HDLC X75slp L2:DSP L2:DSPHDLC -------- Port 1 'hfc-e1.1-2': TE/NT-mode PRI E1 (for phone lines & E1 devices) 14 B-channels: 18-31 B-protocols: RAW HDLC X75slp L2:DSP L2:DSPHDLC ____DEBUG____________________________________________ debian:/home/till/openbsc/openbsc/src# ./bsc_hack DB: Database initialized. DB: Database prepared. e1_reconfig_bts(0) e1_reconfig_ts(0,0,0) e1_reconfig_ts(0,0,1) e1_reconfig_ts(0,0,2) e1_reconfig_ts(0,0,3) e1_reconfig_ts(0,0,4) e1_reconfig_ts(0,0,5) e1_reconfig_ts(0,0,6) e1_reconfig_ts(0,0,7) 2 devices found id: 0 Dprotocols: 00000018 Bprotocols: 0000006e protocol: 0 nrbchan: 14 name: hfc-e1.1-1 e1_reconfig_bts(1) e1_reconfig_ts(1,0,0) e1_reconfig_ts(1,0,1) e1_reconfig_ts(1,0,2) e1_reconfig_ts(1,0,3) e1_reconfig_ts(1,0,4) e1_reconfig_ts(1,0,5) e1_reconfig_ts(1,0,6) e1_reconfig_ts(1,0,7) 2 devices found id: 1 Dprotocols: 00000018 Bprotocols: 0000006e protocol: 0 nrbchan: 14 name: hfc-e1.1-2 activate bchan bootstrapping OML for BTS 0 <0020> abis_nm.c:1644 Set BTS Attr (bts=0) <0020> abis_nm.c:1661 Set TRX Attr (bts=0,trx=0) <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=0) <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=1) <0020> abis_nm.c:1744 Invalid Channel Combination!!! <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=2) <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=3) <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=4) <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=5) <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=6) <0020> abis_nm.c:1741 Set Chan Attr (bts=0,trx=0,ts=7) <0020> abis_nm.c:805 OC=SITE MANAGER(00) INST=(ff,ff,ff) Software Activated Report bootstrapping RSL for BTS/TRX (0/0) using MCC=1 MNC=1 BSIC=63 TSC=7 <0020> abis_nm.c:805 OC=BPORT(a9) INST=(01,ff,ff) Failure Event Report Severity=major failure <0020> abis_nm.c:805 OC=BPORT(a9) INST=(01,ff,ff) STATE CHG: ____Config____________________________________________ ! ! OpenBSC configuration saved from vty ! ! password foo ! line vty no login ! network network country code 1 mobile network code 1 short name OpenBSC long name OpenBSC bts 0 type bs11 band GSM900 cell_identity 1 location_area_code 1 training_sequence_code 7 base_station_id_code 63 oml e1 line 0 timeslot 1 sub-slot full oml e1 tei 25 trx 0 arfcn 101 max_power_red 6 rsl e1 line 0 timeslot 1 sub-slot full rsl e1 tei 1 timeslot 0 phys_chan_config CCCH+SDCCH4 e1 line 0 timeslot 1 sub-slot full timeslot 1 phys_chan_config SDCCH8 e1 line 0 timeslot 2 sub-slot 1 bts 1 type bs11 band GSM900 location_area_code 2 training_sequence_code 7 base_station_id_code 62 oml e1 line 1 timeslot 17 sub-slot full oml e1 tei 26 trx 0 arfcn 122 max_power_red 0 rsl e1 line 1 timeslot 17 sub-slot full rsl e1 tei 2 timeslot 0 phys_chan_config CCCH+SDCCH4 e1 line 1 timeslot 17 sub-slot full timeslot 1 phys_chan_config SDCCH8 e1 line 1 timeslot 18 sub-slot 1 timeslot 2 phys_chan_config TCH/F e1 line 1 timeslot 18 sub-slot 2 > BS-11 multidrop problem (till) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 20 Mar 2010 01:47:53 +0100 > From: till > Subject: BS-11 multidrop problem > To: openbsc at lists.gnumonks.org > Message-ID: <1269046073.8017.13.camel at core2> > Content-Type: text/plain > > Hi, > > i want to operate two BS-11 via one E1-card. And i did it almost like > here: > http://lists.gnumonks.org/pipermail/openbsc/2009-August/000733.html > But i dont know how to configure the bport1 object for multidrop and how > to use the hfcmulti module to get two interfaces (for lcr i compiled > misdn_l1loop but i think this isnt the right here ;)). So atm i am not > able to communicate with the second BS11 :/. Any idea? > > Thx & Greets Till From laforge at gnumonks.org Thu Apr 15 06:22:30 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 15 Apr 2010 08:22:30 +0200 Subject: BS-11 multidrop problem In-Reply-To: <1271258597.6917.13.camel@core2> References: <1271258597.6917.13.camel@core2> Message-ID: <20100415062230.GI7381@prithivi.gnumonks.org> Hi till, On Wed, Apr 14, 2010 at 05:23:17PM +0200, till wrote: > i am still trying to get hose two BS-11 to run. The hfcmulti driver is > now configured with dmask and bmask (just had the wrong version, thx to > Andreas). But there are still no OML and RSL-connections to the second > BS-11 initialized. > > And i found no possibility to put bport1 into multidrop. I appreciate > any help :) ! why not simply modify the bs11_config.c source code to either add a new option or to patch the existing code? this is really all I can afford right now. it is a best-effort community-run project, and the last time i've had two bs-11 in a multidrop config was at HAR2009. > abis_nm_bs11_set_bport_line_cfg(g_bts, 0, BS11_LINE_CFG_MULTIDROP); sets bport 0 to multidrop.. all that needs to be done is to call this function with '1' instead of '0' -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zecke at selfish.org Mon Apr 5 13:33:44 2010 From: zecke at selfish.org (Holger Freyther) Date: Mon, 5 Apr 2010 15:33:44 +0200 Subject: Can't start nanoBTS properly. In-Reply-To: <4BB21F2D.9020708@gmail.com> References: <4BB21F2D.9020708@gmail.com> Message-ID: <201004051533.44954.zecke@selfish.org> On Tuesday 30 March 2010 17:56:29 Nordin wrote: > > It stops there and nanoBTS keeps blinking green light. > When running an older version (without libosmocore), it works well. > Is this a familiar behaviour, any idea? Okay, I'm seeing the same on a rugby sized nanoBTS and I should have some time this week to address it. From bouchtaoui at gmail.com Tue Apr 6 08:18:53 2010 From: bouchtaoui at gmail.com (Nordin) Date: Tue, 06 Apr 2010 10:18:53 +0200 Subject: Can't start nanoBTS properly. In-Reply-To: <201004051533.44954.zecke@selfish.org> References: <4BB21F2D.9020708@gmail.com> <201004051533.44954.zecke@selfish.org> Message-ID: <4BBAEE6D.6030004@gmail.com> Hi Holger and friends, I also want to say that at this period I can't help developing on the OpenBSC as I just don't have the time for it (just have a new born son a few months ago). All I can do is do some testing for you and inform the list if I encounter abnormal behavior. On 5-4-2010 15:33, Holger Freyther wrote: > On Tuesday 30 March 2010 17:56:29 Nordin wrote: > > >> It stops there and nanoBTS keeps blinking green light. >> When running an older version (without libosmocore), it works well. >> Is this a familiar behaviour, any idea? >> > Okay, I'm seeing the same on a rugby sized nanoBTS and I should have some time > this week to address it. > > > > From mailman-bounces at lists.gnumonks.org Mon Apr 5 07:00:01 2010 From: mailman-bounces at lists.gnumonks.org (mailman-bounces at lists.gnumonks.org) Date: Mon, 05 Apr 2010 09:00:01 +0200 Subject: OpenBSC unsubscribe notification Message-ID: sebastian.holter at wavelight.com has been removed from OpenBSC. From f.koliqi at gmail.com Mon Apr 5 14:37:31 2010 From: f.koliqi at gmail.com (Fadil Berisha) Date: Mon, 5 Apr 2010 10:37:31 -0400 Subject: openbsc with softBTS Message-ID: I am doing some experimenting with openbsc with software emulation of ipaccess. At this early stage, I am communicating with openbsc with hard coded messages. Here is what getting as response from openbsc: ./bsc_hack --debug=DNM:DRSL DB: Database initialized. DB: Database prepared. <0005> bsc_init.c:626 bootstrapping OML for BTS 0 <0005> abis_nm.c:583 OC=BASEBAND TRANSCEIVER(04) INST=(00,ff,ff) SW Activate Request: ACKing and Activating <0005> abis_nm.c:934 Found SW config: 42 12 00 05 01 02 03 04 05 13 00 05 05 04 03 02 01 <0005> abis_nm.c:1482 state 4, NM MT 0x0e <0005> abis_nm.c:1581 Activate Software DONE! <0005> abis_nm.c:583 OC=BASEBAND TRANSCEIVER(04) INST=(00,ff,ff) Software Activated Report <0005> abis_nm.c:583 OC=BTS(01) INST=(00,ff,ff) IPACCESS(0xe1): RSL CONNECT ACK PORT=3003 Openbsc responding properly on PING from softBTS in both links for OML and RSL. Looks like OML and RSL connection are established, but, here is problem. To get RSL CONNECT ACK PORT=3003, I send OML message NM_MT_IPACC_RSL_CONNECT_ACK before recieving request NM_MT_IPACC_RSL_CONNECT from openbsc. My question is, how to get in stage when openbsc is ready to send NM_MT_IPACC_RSL_CONNECT. What expecting openbsc to get from ipaccess before sending NM_MT_IPACC_RSL_CONNECT? Thank you Fadil Berisha -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Mon Apr 5 22:17:10 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 6 Apr 2010 00:17:10 +0200 Subject: openbsc with softBTS In-Reply-To: References: Message-ID: <201004060017.10782.zecke@selfish.org> On Monday 05 April 2010 16:37:31 Fadil Berisha wrote: > To get RSL CONNECT ACK PORT=3003, I send OML message > NM_MT_IPACC_RSL_CONNECT_ACK before recieving request > NM_MT_IPACC_RSL_CONNECT from openbsc. > My question is, how to get in stage when openbsc is ready to send > NM_MT_IPACC_RSL_CONNECT. What expecting openbsc to get from ipaccess > before sending NM_MT_IPACC_RSL_CONNECT? I think you want to look into src/bsc_init.c for our init sequence and on which states we trigger the RSL connect message. From f.koliqi at gmail.com Tue Apr 6 05:06:03 2010 From: f.koliqi at gmail.com (Fadil Berisha) Date: Tue, 6 Apr 2010 01:06:03 -0400 Subject: openbsc with softBTS In-Reply-To: References: <201004060017.10782.zecke@selfish.org> Message-ID: Thank you Holger. Info was there, proper SW Activate Report message solved problem. Fadil On Mon, Apr 5, 2010 at 6:17 PM, Holger Freyther wrote: > On Monday 05 April 2010 16:37:31 Fadil Berisha wrote: > > > To get RSL CONNECT ACK PORT=3003, I send OML message > > NM_MT_IPACC_RSL_CONNECT_ACK before recieving request > > NM_MT_IPACC_RSL_CONNECT from openbsc. > > My question is, how to get in stage when openbsc is ready to send > > NM_MT_IPACC_RSL_CONNECT. What expecting openbsc to get from ipaccess > > before sending NM_MT_IPACC_RSL_CONNECT? > > I think you want to look into src/bsc_init.c for our init sequence and on > which states we trigger the RSL connect message. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Apr 7 05:47:11 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Apr 2010 07:47:11 +0200 Subject: openbsc with softBTS In-Reply-To: References: Message-ID: <20100407054711.GI20583@prithivi.gnumonks.org> Hi Fadil, On Mon, Apr 05, 2010 at 10:37:31AM -0400, Fadil Berisha wrote: > I am doing some experimenting with openbsc with software emulation of > ipaccess. This is great news! Are you going to release this as Free / Open Source Software ? I think even in an early stage, it might be very interesting to have a look at it. If you'd like, I can set up a git repository for you. I once started with creating an Abis/IP BTS-side implementation for OpenBTS, but never had the time to continue it. There might be quite some code sharing possibilities. I'll try to port my OpenBTS Abis/IP code against current OpenBTS and release it soon. Regarding your actual technical problem: Holger has already responded to it, so I won't add anything else... Cheers, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From f.koliqi at gmail.com Thu Apr 8 00:20:13 2010 From: f.koliqi at gmail.com (Fadil Berisha) Date: Wed, 7 Apr 2010 20:20:13 -0400 Subject: openbsc with softBTS In-Reply-To: <20100407054711.GI20583@prithivi.gnumonks.org> References: <20100407054711.GI20583@prithivi.gnumonks.org> Message-ID: Hi Harald This is great news! Are you going to release this as Free / Open Source > Software ? > This project is based on openBSC and would be Free/Open Source. Let me comment a few points for this project: 1. Abis side Create software for BTS which will use same Abis/IP software what is already developed to communicate with ipaccess. OpenBSC will operate this BTS as ipaccess, using same cfg files etc. 2. Um side Use or adapt as much as we can software already developed in current project OsmocomBB (LAPDm, etc). 3. Core New module. Following programing techniques and approach as in openBSC will allow more people to be involved. 4. Hardware Hardware independent. Kernel driver for each hardware solution. There might be quite some code sharing possibilities. > I'll try to port my OpenBTS Abis/IP code against current OpenBTS and > release it soon. > That would be great. Would be good to have more hardware options for openBSC also will help to prepare better some initial code for repository. Fadil -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eversberg at versatel.de Wed Apr 7 10:10:45 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Wed, 7 Apr 2010 12:10:45 +0200 Subject: AW: openbsc with softBTS Message-ID: > I'll try to port my OpenBTS Abis/IP code against current OpenBTS and > release it soon. hi harald, i hope i undertood it right. does that mean that OpenBTS will be able to connect to a BSC like OpenBSC? that would be extreemly interesting when using USRP as BTS with other than GSM-P (900) and DCS 1800/1900 band. andreas From fabrice.poundeu at smail.inf.fh-bonn-rhein-sieg.de Wed Apr 7 14:21:32 2010 From: fabrice.poundeu at smail.inf.fh-bonn-rhein-sieg.de (Fabrice Ismael Poundeu Tchouatieu) Date: Wed, 07 Apr 2010 16:21:32 +0200 Subject: connecting two nanoBTS-GSM-Cells Message-ID: <20100407162132.h98zinuiowkoccs8@www4.inf.fh-bonn-rhein-sieg.de> Hallo everyone, i'm trying to connect two nanoBTS-GSM-Cells together to simulate two different GSM Subscriber networks. I have tried to make it using lcr and asterisk but they were some difficulties using mISDNv2. Certainly some of you have made such a connection before. I just want to known if someone can tell me the best way to make such a connection and which components are necessary for that? -- Fabrice Ismael Poundeu Tchouatieu ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From laforge at gnumonks.org Sat Apr 10 09:48:51 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 10 Apr 2010 11:48:51 +0200 Subject: connecting two nanoBTS-GSM-Cells In-Reply-To: <20100407162132.h98zinuiowkoccs8@www4.inf.fh-bonn-rhein-sieg.de> References: <20100407162132.h98zinuiowkoccs8@www4.inf.fh-bonn-rhein-sieg.de> Message-ID: <20100410094851.GE14576@prithivi.gnumonks.org> > i'm trying to connect two nanoBTS-GSM-Cells together to simulate two > different GSM Subscriber networks. I have tried to make it using lcr > and asterisk but they were some difficulties using mISDNv2. > Certainly some of you have made such a connection before. I just > want to known if someone can tell me the best way to make such a > connection and which components are necessary for that? Just to make sure there is no misunderstanding: If you want to simulate two different networks, you should not connect your nanoBTS's! Connecting nanoBTS's with each otehr is only needed for a multi-TRX setup of a single BTS. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From fabrice.poundeu at smail.inf.fh-bonn-rhein-sieg.de Mon Apr 12 08:59:56 2010 From: fabrice.poundeu at smail.inf.fh-bonn-rhein-sieg.de (Fabrice Ismael Poundeu Tchouatieu) Date: Mon, 12 Apr 2010 10:59:56 +0200 Subject: connecting two nanoBTS-GSM-Cells In-Reply-To: <20100410094851.GE14576@prithivi.gnumonks.org> References: <20100407162132.h98zinuiowkoccs8@www4.inf.fh-bonn-rhein-sieg.de> <20100410094851.GE14576@prithivi.gnumonks.org> Message-ID: <20100412105956.zlls4usts04ggscc@www4.inf.fh-bonn-rhein-sieg.de> Hye Harald, thanks for your answer! I don't want to connect them directly (multi-TRX), but over the network. Zitat von Harald Welte : >> i'm trying to connect two nanoBTS-GSM-Cells together to simulate two >> different GSM Subscriber networks. I have tried to make it using lcr >> and asterisk but they were some difficulties using mISDNv2. >> Certainly some of you have made such a connection before. I just >> want to known if someone can tell me the best way to make such a >> connection and which components are necessary for that? > > Just to make sure there is no misunderstanding: > If you want to simulate two different networks, you should not connect > your nanoBTS's! Connecting nanoBTS's with each otehr is only needed for > a multi-TRX setup of a single BTS. > > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -- Fabrice Ismael Poundeu Tchouatieu ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From stuart at bluewave.im Fri Apr 9 16:03:57 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Fri, 9 Apr 2010 17:03:57 +0100 Subject: Another Compile Error Message-ID: <4B69F0BF-7423-4E2B-ACD2-C397B2916BA8@bluewave.im> Hi guys, I am trying to get openBSC to compile on Ubuntu 2.6.31 but I get the following error when I run make: Making all in src make[2]: Entering directory `/home/stuart/openbsc/openbsc/src' CCLD bsc_hack libmsc.a(gsm_04_08.o): In function `mm_rx_id_resp': /home/stuart/openbsc/openbsc/src/gsm_04_08.c:259: undefined reference to `gsm48_mi_to_string' libmsc.a(gsm_04_08.o): In function `mm_rx_loc_upd_req': /home/stuart/openbsc/openbsc/src/gsm_04_08.c:345: undefined reference to `gsm48_mi_to_string' libmsc.a(gsm_04_08.o): In function `gsm48_rx_mm_imsi_detach_ind': /home/stuart/openbsc/openbsc/src/gsm_04_08.c:685: undefined reference to `gsm48_mi_to_string' libmsc.a(gsm_04_08.o): In function `gsm48_rx_mm_serv_req': /home/stuart/openbsc/openbsc/src/gsm_04_08.c:642: undefined reference to `gsm48_mi_to_string' libbsc.a(gsm_04_08_utils.o): In function `gsm48_paging_extract_mi': /home/stuart/openbsc/openbsc/src/gsm_04_08_utils.c:262: undefined reference to `gsm48_mi_to_string' collect2: ld returned 1 exit status make[2]: *** [bsc_hack] Error 1 make[2]: Leaving directory `/home/stuart/openbsc/openbsc/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/stuart/openbsc/openbsc' make: *** [all] Error 2 Any ideas? Thanks, Stuart From zecke at selfish.org Fri Apr 9 16:33:17 2010 From: zecke at selfish.org (Holger Freyther) Date: Fri, 9 Apr 2010 18:33:17 +0200 Subject: Another Compile Error In-Reply-To: <4B69F0BF-7423-4E2B-ACD2-C397B2916BA8@bluewave.im> References: <4B69F0BF-7423-4E2B-ACD2-C397B2916BA8@bluewave.im> Message-ID: <201004091833.18085.zecke@selfish.org> On Friday 09 April 2010 18:03:57 Stuart Baggs wrote: > Hi guys, I am trying to get openBSC to compile on Ubuntu 2.6.31 but I get > the following error when I run make: Well, strictly speaking it is a linker error. You should tell us which version of libosmocore you have installed and which git revision you attempt to build. z. From stuart at bluewave.im Fri Apr 9 16:59:54 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Fri, 9 Apr 2010 17:59:54 +0100 Subject: Another Compile Error In-Reply-To: <201004091833.18085.zecke@selfish.org> References: <4B69F0BF-7423-4E2B-ACD2-C397B2916BA8@bluewave.im> <201004091833.18085.zecke@selfish.org> Message-ID: <96AD9DDE-AF17-487B-8093-726771CF90B1@bluewave.im> I'm not sure (how can I tell)? I did a git pull in the root directory of both packages however. Thanks for your help, its really appreciated.ou are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. On 9 Apr 2010, at 17:33, Holger Freyther wrote: > On Friday 09 April 2010 18:03:57 Stuart Baggs wrote: >> Hi guys, I am trying to get openBSC to compile on Ubuntu 2.6.31 but I get >> the following error when I run make: > > Well, strictly speaking it is a linker error. You should tell us which version > of libosmocore you have installed and which git revision you attempt to build. > > z. > > > From zecke at selfish.org Fri Apr 9 18:14:43 2010 From: zecke at selfish.org (Holger Freyther) Date: Fri, 9 Apr 2010 20:14:43 +0200 Subject: Another Compile Error In-Reply-To: <96AD9DDE-AF17-487B-8093-726771CF90B1@bluewave.im> References: <4B69F0BF-7423-4E2B-ACD2-C397B2916BA8@bluewave.im> <201004091833.18085.zecke@selfish.org> <96AD9DDE-AF17-487B-8093-726771CF90B1@bluewave.im> Message-ID: <201004092014.44011.zecke@selfish.org> On Friday 09 April 2010 18:59:54 Stuart Baggs wrote: > I'm not sure (how can I tell)? I did a git pull in the root directory of > both packages however. Thanks for your help, its really appreciated.ou are > notified that disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly prohibited I assume you only half way removed your corporate email footer? Checking version of libosmocore: $ pkg-config --modversion libosmocore 0.1.3 Checking git version: git log --pretty=oneline | head -1 07d838a3bf866692f15d6d3bbc17e91451ace216 ... From stuart at bluewave.im Fri Apr 9 18:29:55 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Fri, 9 Apr 2010 19:29:55 +0100 Subject: Another Compile Error Message-ID: <556CE437-8DC8-4DD1-9FE7-76C215BD9138@bluewave.im> Im not sure what I did but it eventually compiled no problem. From 246tnt at gmail.com Sat Apr 10 09:48:00 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 10 Apr 2010 11:48:00 +0200 Subject: Another Compile Error In-Reply-To: <556CE437-8DC8-4DD1-9FE7-76C215BD9138@bluewave.im> References: <556CE437-8DC8-4DD1-9FE7-76C215BD9138@bluewave.im> Message-ID: On Fri, Apr 9, 2010 at 8:29 PM, Stuart Baggs wrote: > Im not sure what I did but it eventually compiled no problem. The libosmocore that's included with git-submodule inside the openbsc.git isn't at a proper version. You need to take a separate recent checkout of both git and then it will work. It can get confusing because it you checkout openbsc.git and libosmocore.git, you get this structure : base/openbsc -> The openbsc git base/openbsc/openbsc -> The openbsc source base/openbsc/libosmocore -> The bad libosmocore (only work on release tags I guess) base/libosmocore -> The libosmocore git that will work. Sylvain From stuart at bluewave.im Fri Apr 9 18:26:05 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Fri, 9 Apr 2010 19:26:05 +0100 Subject: NanoBTS Problem Message-ID: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> Hi, I have a nanobts config file: ! OpenBSC configuration saved from vty ! password foo ! line vty no login ! network network country code 1 mobile network code 1 short name SomeNet long name SomeNet timer t3101 10 timer t3113 60 auth policy closed bts 0 type nanobts ip.access unit_id 0 0 band GSM1800 location_area_code 1 training_sequence_code 7 base_station_id_code 63 ms max power 40 trx 0 rf_locked 0 arfcn 514 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 bsc_hack reports: DB: Database initialized. DB: Database prepared. <000d> input/ipaccess.c:535 accept()ed new OML link from 192.168.1.85 <0005> bsc_init.c:735 bootstrapping OML for BTS 0 The light on the nanoBTS flashes green but does not go solid green / or start transmitting a signal. Any ideas? Thanks, Stuart From zecke at selfish.org Fri Apr 9 18:30:04 2010 From: zecke at selfish.org (Holger Freyther) Date: Fri, 9 Apr 2010 20:30:04 +0200 Subject: NanoBTS Problem In-Reply-To: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> Message-ID: <201004092030.04976.zecke@selfish.org> On Friday 09 April 2010 20:26:05 Stuart Baggs wrote: > DB: Database initialized. > DB: Database prepared. > <000d> input/ipaccess.c:535 accept()ed new OML link from 192.168.1.85 > <0005> bsc_init.c:735 bootstrapping OML for BTS 0 > > The light on the nanoBTS flashes green but does not go solid green / or > start transmitting a signal. > > Any ideas? Yes, you have a rugby sized BTS, you didn't check the mailing list archives prior to posting and you didn't include relevant information. :) Please look at the mail from Nordin that was sent on Tuesday and see if you suffer from the same problem? The thread also contains the information we are looking for. From stuart at bluewave.im Fri Apr 9 18:34:54 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Fri, 9 Apr 2010 19:34:54 +0100 Subject: NanoBTS Problem In-Reply-To: <201004092030.04976.zecke@selfish.org> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004092030.04976.zecke@selfish.org> Message-ID: Hi, whoops missed that one! Yes its a rugby sized GSM/GPRS bts. Looked through the posts not sure what information has been requested but if you let me know I can give the group all the info. Thanks On 9 Apr 2010, at 19:30, Holger Freyther wrote: > On Friday 09 April 2010 20:26:05 Stuart Baggs wrote: > >> DB: Database initialized. >> DB: Database prepared. >> <000d> input/ipaccess.c:535 accept()ed new OML link from 192.168.1.85 >> <0005> bsc_init.c:735 bootstrapping OML for BTS 0 >> >> The light on the nanoBTS flashes green but does not go solid green / or >> start transmitting a signal. >> >> Any ideas? > > Yes, > > you have a rugby sized BTS, you didn't check the mailing list archives prior > to posting and you didn't include relevant information. :) > > Please look at the mail from Nordin that was sent on Tuesday and see if you > suffer from the same problem? The thread also contains the information we are > looking for. > > From zecke at selfish.org Fri Apr 9 18:43:52 2010 From: zecke at selfish.org (Holger Freyther) Date: Fri, 9 Apr 2010 20:43:52 +0200 Subject: NanoBTS Problem In-Reply-To: References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004092030.04976.zecke@selfish.org> Message-ID: <201004092043.52439.zecke@selfish.org> On Friday 09 April 2010 20:34:54 Stuart Baggs wrote: > Hi, whoops missed that one! Yes its a rugby sized GSM/GPRS bts. Looked > through the posts not sure what information has been requested but if you > let me know I can give the group all the info. A recent commit, e.g. we speculate it might have been the merge of the first bits of the GPRS conf branch, broke support for the rugby sized nanoBTS. What we would need would be a pcap file of a working startup and one of a non- working startup. The other bit would be to use the power of git bisect to figure out the commit that actually broke it. From stuart at bluewave.im Fri Apr 9 18:48:17 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Fri, 9 Apr 2010 19:48:17 +0100 Subject: NanoBTS Problem In-Reply-To: <201004092043.52439.zecke@selfish.org> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004092030.04976.zecke@selfish.org> <201004092043.52439.zecke@selfish.org> Message-ID: OK, I will do this for the group. Could you let me know how to downgrade my openBSC to a version which supports the rugby nanoBTS? Would I also need to downgrade libosmocore? Thanks for your help. On 9 Apr 2010, at 19:43, Holger Freyther wrote: > On Friday 09 April 2010 20:34:54 Stuart Baggs wrote: >> Hi, whoops missed that one! Yes its a rugby sized GSM/GPRS bts. Looked >> through the posts not sure what information has been requested but if you >> let me know I can give the group all the info. > > > > A recent commit, e.g. we speculate it might have been the merge of the first > bits of the GPRS conf branch, broke support for the rugby sized nanoBTS. What > we would need would be a pcap file of a working startup and one of a non- > working startup. The other bit would be to use the power of git bisect to > figure out the commit that actually broke it. > > > From zecke at selfish.org Fri Apr 9 19:18:39 2010 From: zecke at selfish.org (Holger Freyther) Date: Fri, 9 Apr 2010 21:18:39 +0200 Subject: NanoBTS Problem In-Reply-To: References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004092043.52439.zecke@selfish.org> Message-ID: <201004092118.39714.zecke@selfish.org> On Friday 09 April 2010 20:48:17 Stuart Baggs wrote: > OK, I will do this for the group. Could you let me know how to downgrade my > openBSC to a version which supports the rugby nanoBTS? Would I also need > to downgrade libosmocore? Yes, you would need to downgrade libosmocore too. Well I think the best way would be to search for a small git tutorial. When I would have the time to track it down I would do.. $ git bisect start -- openbsc/ $ git bisect bad HEAD $ git bisect good 0.9.0 $ cd openbsc/; make (and if I have link errors or such I would downgrade libosmocore too... I would downgrade by checking out the releases). From 246tnt at gmail.com Fri Apr 9 20:53:44 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 9 Apr 2010 22:53:44 +0200 Subject: NanoBTS Problem In-Reply-To: <201004092118.39714.zecke@selfish.org> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004092043.52439.zecke@selfish.org> <201004092118.39714.zecke@selfish.org> Message-ID: That's weird because I was running the GPRS branch on a rugby sized nanoBTS. It initially didn't work because of the NM_ATT_IPACC_RLC_CFG_3 attribute but this one is now commented out. Note that some nanoBTS require fixes that are only in my pending branch ... (but that's a pre-lisbosmocore branch, I haven't rebased it yet). I don't have the setup ready to test right now, but I'll give it a shot tomorrow ... Sylvain From zecke at selfish.org Fri Apr 9 21:02:46 2010 From: zecke at selfish.org (Holger Freyther) Date: Fri, 9 Apr 2010 23:02:46 +0200 Subject: NanoBTS Problem In-Reply-To: References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004092118.39714.zecke@selfish.org> Message-ID: <201004092302.46469.zecke@selfish.org> On Friday 09 April 2010 22:53:44 Sylvain Munaut wrote: > That's weird because I was running the GPRS branch on a rugby sized > nanoBTS. It initially didn't work because of the NM_ATT_IPACC_RLC_CFG_3 > attribute but this one is now commented out. > > Note that some nanoBTS require fixes that are only in my pending > branch ... (but that's a pre-lisbosmocore branch, I haven't rebased it > yet). Do you need some help to merge patches of your branch? From 246tnt at gmail.com Fri Apr 9 21:16:02 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 9 Apr 2010 23:16:02 +0200 Subject: NanoBTS Problem In-Reply-To: <201004092302.46469.zecke@selfish.org> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004092118.39714.zecke@selfish.org> <201004092302.46469.zecke@selfish.org> Message-ID: >> That's weird because I was running the GPRS branch on a rugby sized >> nanoBTS. It initially didn't work because of the NM_ATT_IPACC_RLC_CFG_3 >> attribute but this one is now commented out. >> >> Note that some nanoBTS require fixes that are only in my pending >> branch ... (but that's a pre-lisbosmocore branch, I haven't rebased it >> yet). > > Do you need some help to merge patches of your branch? They rebased automatically quite fine. I didn't push the rebased version yet because I didn't get a chance to test it yet. I think Harald wanted to see if they didn't affect proper operation on the EDGE units and BS-11. Since I don't have any of those, I can't test myself. Sylvain From stuart at bluewave.im Sat Apr 10 01:59:57 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sat, 10 Apr 2010 02:59:57 +0100 Subject: NanoBTS Problem In-Reply-To: References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004092118.39714.zecke@selfish.org> <201004092302.46469.zecke@selfish.org> Message-ID: Still wont get past the green flashing light on 0.9.0 :s On 9 Apr 2010, at 22:16, Sylvain Munaut wrote: >>> That's weird because I was running the GPRS branch on a rugby sized >>> nanoBTS. It initially didn't work because of the NM_ATT_IPACC_RLC_CFG_3 >>> attribute but this one is now commented out. >>> >>> Note that some nanoBTS require fixes that are only in my pending >>> branch ... (but that's a pre-lisbosmocore branch, I haven't rebased it >>> yet). >> >> Do you need some help to merge patches of your branch? > > They rebased automatically quite fine. I didn't push the rebased > version yet because I didn't get a chance to test it yet. > > I think Harald wanted to see if they didn't affect proper operation on > the EDGE units and BS-11. Since I don't have any of those, I can't > test myself. > > Sylvain > > From laforge at gnumonks.org Sat Apr 10 09:51:51 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 10 Apr 2010 11:51:51 +0200 Subject: NanoBTS Problem In-Reply-To: References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004092118.39714.zecke@selfish.org> <201004092302.46469.zecke@selfish.org> Message-ID: <20100410095151.GF14576@prithivi.gnumonks.org> On Sat, Apr 10, 2010 at 02:59:57AM +0100, Stuart Baggs wrote: > Still wont get past the green flashing light on 0.9.0 :s please create a pcap file of the full BTS boot with tcpdump or wireshark, also please post a debug log file of openbsc (start bsc_hack with -d DINP:DNM:DRSL,0:0:0) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From stuart at bluewave.im Sat Apr 10 10:09:42 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sat, 10 Apr 2010 11:09:42 +0100 Subject: NanoBTS Problem In-Reply-To: <20100410095151.GF14576@prithivi.gnumonks.org> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004092118.39714.zecke@selfish.org> <201004092302.46469.zecke@selfish.org> <20100410095151.GF14576@prithivi.gnumonks.org> Message-ID: <75848494-408F-4515-9808-AD5D1D65D6F4@bluewave.im> Hi guys, ok first things first. Here if the debug log of openbsc startup: root at gateway:~/openbsc/openbsc/src# ./bsc_hack -d DINP:DNM:DRSL,0:0:0 DB: Database initialized. DB: Database prepared. <000d> input/ipaccess.c:535 accept()ed new OML link from 192.168.1.85 <000d> input/ipaccess.c:235 Identified BTS 0/0/0 <0005> bsc_init.c:735 bootstrapping OML for BTS 0 <0005> abis_nm.c:519 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:519 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:519 OC=GPRS NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:519 OC=GPRS CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:519 OC=SITE MANAGER(00) INST=(ff,ff,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:519 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:519 OC=SITE MANAGER(00) INST=(ff,ff,ff) Sending OPSTART <0005> abis_nm.c:519 OC=SITE MANAGER(00) INST=(ff,ff,ff) Software Activated Report <0005> abis_nm.c:519 OC=BTS(01) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:519 OC=GPRS NSE(f0) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:519 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1753 Set BTS Attr (bts=0) <0005> abis_nm.c:519 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART <0005> abis_nm.c:519 OC=BTS(01) INST=(00,ff,ff) Software Activated Report <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:519 OC=GPRS NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:519 OC=GPRS NSE(f0) INST=(00,ff,ff) Software Activated Report <0005> abis_nm.c:519 OC=GPRS CELL(f1) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,01,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:519 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:519 OC=GPRS CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:519 OC=GPRS CELL(f1) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,01,ff) Software Activated Report <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:2824 ip.access RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=0) <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=1) <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=2) <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,02) Sending OPSTART <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=3) <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,03) Sending OPSTART <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=4) <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,04) Sending OPSTART <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=5) <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,05) Sending OPSTART <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=6) <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,06) Sending OPSTART <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=7) <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,07) Sending OPSTART <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xe1): RSL CONNECT ACK IP=192.168.1.50 PORT=3003 STREAM=0x00 <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,00) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,00) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,01) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,01) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,02) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,02) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,03) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,03) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,04) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,04) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,05) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,05) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,06) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,06) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,07) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,07) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,00) Software Activated Report <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,01) Software Activated Report <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,02) Software Activated Report <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,03) Software Activated Report <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,04) Software Activated Report <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,05) Software Activated Report <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,06) Software Activated Report <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,07) Software Activated Report <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:1770 Set TRX Attr (bts=0,trx=0) <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) Sending OPSTART On 10 Apr 2010, at 10:51, Harald Welte wrote: > On Sat, Apr 10, 2010 at 02:59:57AM +0100, Stuart Baggs wrote: >> Still wont get past the green flashing light on 0.9.0 :s > > please create a pcap file of the full BTS boot with tcpdump or > wireshark, also please post a debug log file of openbsc (start bsc_hack > with -d DINP:DNM:DRSL,0:0:0) > > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > From stuart at bluewave.im Sat Apr 10 10:13:07 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sat, 10 Apr 2010 11:13:07 +0100 Subject: NanoBTS Problem In-Reply-To: <75848494-408F-4515-9808-AD5D1D65D6F4@bluewave.im> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004092118.39714.zecke@selfish.org> <201004092302.46469.zecke@selfish.org> <20100410095151.GF14576@prithivi.gnumonks.org> <75848494-408F-4515-9808-AD5D1D65D6F4@bluewave.im> Message-ID: <4BD25081-B7D4-47D1-A552-470F261AF636@bluewave.im> root at gateway:~/openbsc/openbsc/src# tcpdump port 3002 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:11:21.797321 IP 192.168.1.85.52667 > 192.168.1.50.3002: Flags [S], seq 409659731, win 16000, options [mss 1460], length 0 11:11:21.797361 IP 192.168.1.50.3002 > 192.168.1.85.52667: Flags [R.], seq 0, ack 409659732, win 0, length 0 11:11:41.779406 IP 192.168.1.85.56146 > 192.168.1.50.3002: Flags [S], seq 2599547005, win 16000, options [mss 1460], length 0 11:11:41.779451 IP 192.168.1.50.3002 > 192.168.1.85.56146: Flags [R.], seq 0, ack 2599547006, win 0, length 0 11:11:58.442678 IP 192.168.1.85.7245 > 192.168.1.50.3002: Flags [S], seq 2917588595, win 16000, options [mss 1460], length 0 11:11:58.442699 IP 192.168.1.50.3002 > 192.168.1.85.7245: Flags [R.], seq 0, ack 2917588596, win 0, length 0 11:12:22.500586 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [S], seq 1562623206, win 16000, options [mss 1460], length 0 11:12:22.500633 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [S.], seq 2967578324, ack 1562623207, win 5840, options [mss 1460], length 0 11:12:22.501011 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], ack 1, win 16000, length 0 11:12:22.501352 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 1:21, ack 1, win 5840, length 20 11:12:22.502339 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 1:5, ack 21, win 15980, length 4 11:12:22.502360 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 5, win 5840, length 0 11:12:22.502441 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 21:25, ack 5, win 5840, length 4 11:12:22.504934 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 5:131, ack 25, win 15996, length 126 11:12:22.543240 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 131, win 5840, length 0 11:12:22.543776 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [P.], seq 131:449, ack 25, win 16000, length 318 11:12:22.543786 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 449, win 6432, length 0 11:12:24.509645 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 449:598, ack 25, win 16000, length 149 11:12:24.509669 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 598, win 7504, length 0 11:12:24.509937 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 25:174, ack 598, win 7504, length 149 11:12:24.701164 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], ack 174, win 16000, length 0 11:12:24.701173 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 174:194, ack 598, win 7504, length 20 11:12:24.708748 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 598:610, ack 194, win 16000, length 12 11:12:24.747239 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 610, win 7504, length 0 11:12:24.747864 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [P.], seq 610:941, ack 194, win 16000, length 331 11:12:24.747873 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 941, win 8576, length 0 11:12:24.747964 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 194:206, ack 941, win 8576, length 12 11:12:24.752873 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 941:953, ack 206, win 16000, length 12 11:12:24.752881 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 206:544, ack 953, win 8576, length 338 11:12:24.771674 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 953:965, ack 544, win 16000, length 12 11:12:24.811238 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 965, win 8576, length 0 11:12:24.811952 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [P.], seq 965:1840, ack 544, win 16000, length 875 11:12:24.811961 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 1840, win 10500, length 0 11:12:24.812034 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 544:612, ack 1840, win 10500, length 68 11:12:24.819174 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 1840:1911, ack 612, win 16000, length 71 11:12:24.819184 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 612:1533, ack 1911, win 10500, length 921 11:12:24.888002 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 1911:1925, ack 1533, win 16000, length 14 11:12:24.927238 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 1925, win 10500, length 0 11:12:24.927849 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [P.], seq 1925:2119, ack 1533, win 16000, length 194 11:12:24.927857 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 2119, win 12250, length 0 11:12:24.954213 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2119:2137, ack 1533, win 16000, length 18 11:12:24.954260 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 2137, win 12250, length 0 11:12:24.955859 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2137:2153, ack 1533, win 16000, length 16 11:12:24.955907 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 2153, win 12250, length 0 11:12:24.955948 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 1533:1547, ack 2153, win 12250, length 14 11:12:24.958282 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2153:2171, ack 1547, win 16000, length 18 11:12:24.958292 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 1547:1590, ack 2171, win 12250, length 43 11:12:24.961987 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2171:2189, ack 1590, win 16000, length 18 11:12:24.961996 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 1590:1632, ack 2189, win 12250, length 42 11:12:24.966291 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2189:2207, ack 1632, win 16000, length 18 11:12:24.966301 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 1632:1674, ack 2207, win 12250, length 42 11:12:24.970734 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2207:2225, ack 1674, win 16000, length 18 11:12:24.970743 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 1674:1716, ack 2225, win 12250, length 42 11:12:24.975263 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2225:2243, ack 1716, win 16000, length 18 11:12:24.975275 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 1716:1758, ack 2243, win 12250, length 42 11:12:24.979554 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2243:2261, ack 1758, win 16000, length 18 11:12:24.979564 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 1758:1800, ack 2261, win 12250, length 42 11:12:24.983848 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2261:2279, ack 1800, win 16000, length 18 11:12:24.983858 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 1800:1842, ack 2279, win 12250, length 42 11:12:24.987368 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2279:2297, ack 1842, win 16000, length 18 11:12:24.987378 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 1842:1884, ack 2297, win 12250, length 42 11:12:25.021388 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2297:2311, ack 1884, win 16000, length 14 11:12:25.021398 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 1884:1926, ack 2311, win 12250, length 42 11:12:25.025685 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2311:2331, ack 1926, win 16000, length 20 11:12:25.063239 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 2331, win 12250, length 0 11:12:25.063852 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [P.], seq 2331:2811, ack 1926, win 16000, length 480 11:12:25.063861 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 2811, win 14000, length 0 11:12:25.064378 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2811:2827, ack 1926, win 16000, length 16 11:12:25.064418 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 2827, win 14000, length 0 11:12:25.067884 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2827:2843, ack 1926, win 16000, length 16 11:12:25.067931 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 2843, win 14000, length 0 11:12:25.071663 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2843:2859, ack 1926, win 16000, length 16 11:12:25.071711 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 2859, win 14000, length 0 11:12:25.074964 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2859:2875, ack 1926, win 16000, length 16 11:12:25.075005 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 2875, win 14000, length 0 11:12:25.088318 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2875:2893, ack 1926, win 16000, length 18 11:12:25.088366 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 2893, win 14000, length 0 11:12:25.089840 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2893:2909, ack 1926, win 16000, length 16 11:12:25.089881 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 2909, win 14000, length 0 11:12:25.089917 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 1926:1945, ack 2909, win 14000, length 19 11:12:25.129885 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2909:2928, ack 1945, win 16000, length 19 11:12:25.129895 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 1945:1971, ack 2928, win 14000, length 26 11:12:25.150016 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2928:2942, ack 1971, win 16000, length 14 11:12:25.187238 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 2942, win 14000, length 0 11:12:25.187693 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [P.], seq 2942:2973, ack 1971, win 16000, length 31 11:12:25.187737 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 2973, win 14000, length 0 11:12:25.187756 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 1971:1983, ack 2973, win 14000, length 12 11:12:25.190336 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2973:2985, ack 1983, win 16000, length 12 11:12:25.227238 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 2985, win 14000, length 0 11:12:45.196404 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], seq 2985:2989, ack 1983, win 16000, length 4 11:12:45.196458 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [.], ack 2989, win 14000, length 0 11:12:45.196624 IP 192.168.1.50.3002 > 192.168.1.85.3661: Flags [P.], seq 1983:1987, ack 2989, win 14000, length 4 11:12:45.395830 IP 192.168.1.85.3661 > 192.168.1.50.3002: Flags [.], ack 1987, win 16000, length 0 On 10 Apr 2010, at 11:09, Stuart Baggs wrote: > Hi guys, ok first things first. Here if the debug log of openbsc startup: > > root at gateway:~/openbsc/openbsc/src# ./bsc_hack -d DINP:DNM:DRSL,0:0:0 > DB: Database initialized. > DB: Database prepared. > <000d> input/ipaccess.c:535 accept()ed new OML link from 192.168.1.85 > <000d> input/ipaccess.c:235 Identified BTS 0/0/0 > <0005> bsc_init.c:735 bootstrapping OML for BTS 0 > <0005> abis_nm.c:519 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:519 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:519 OC=GPRS NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:519 OC=GPRS CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:519 OC=SITE MANAGER(00) INST=(ff,ff,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:519 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:519 OC=SITE MANAGER(00) INST=(ff,ff,ff) Sending OPSTART > <0005> abis_nm.c:519 OC=SITE MANAGER(00) INST=(ff,ff,ff) Software Activated Report > <0005> abis_nm.c:519 OC=BTS(01) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:519 OC=GPRS NSE(f0) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:519 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1753 Set BTS Attr (bts=0) > <0005> abis_nm.c:519 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART > <0005> abis_nm.c:519 OC=BTS(01) INST=(00,ff,ff) Software Activated Report > <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:519 OC=GPRS NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:519 OC=GPRS NSE(f0) INST=(00,ff,ff) Software Activated Report > <0005> abis_nm.c:519 OC=GPRS CELL(f1) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,01,ff) SW Activate Request: <0005> abis_nm.c:839 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:854 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:519 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:519 OC=GPRS CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:519 OC=GPRS CELL(f1) INST=(00,00,ff) Software Activated Report > <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,00,ff) Software Activated Report > <0005> abis_nm.c:519 OC=GPRS NSVC(f2) INST=(00,01,ff) Software Activated Report > <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report > <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Sending OPSTART > <0005> abis_nm.c:2824 ip.access RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=0) > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=1) > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=2) > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,02) Sending OPSTART > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=3) > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,03) Sending OPSTART > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=4) > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,04) Sending OPSTART > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=5) > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,05) Sending OPSTART > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=6) > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,06) Sending OPSTART > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1928 Set Chan Attr (bts=0,trx=0,ts=7) > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,07) Sending OPSTART > <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xe1): RSL CONNECT ACK IP=192.168.1.50 PORT=3003 STREAM=0x00 > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,00) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,00) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,01) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,01) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,02) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,02) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,03) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,03) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,04) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,04) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,05) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,05) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,06) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,06) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,07) SET CHANNEL ATTRIBUTE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,07) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,00) Software Activated Report > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,01) Software Activated Report > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,02) Software Activated Report > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,03) Software Activated Report > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,04) Software Activated Report > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,05) Software Activated Report > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,06) Software Activated Report > <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,07) Software Activated Report > <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) Software Activated Report > <0005> abis_nm.c:1770 Set TRX Attr (bts=0,trx=0) > <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) Sending OPSTART > <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) ADM=Unlocked > <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) Sending OPSTART > > > On 10 Apr 2010, at 10:51, Harald Welte wrote: > >> On Sat, Apr 10, 2010 at 02:59:57AM +0100, Stuart Baggs wrote: >>> Still wont get past the green flashing light on 0.9.0 :s >> >> please create a pcap file of the full BTS boot with tcpdump or >> wireshark, also please post a debug log file of openbsc (start bsc_hack >> with -d DINP:DNM:DRSL,0:0:0) >> >> -- >> - Harald Welte http://laforge.gnumonks.org/ >> ============================================================================ >> "Privacy in residential applications is a desirable marketing option." >> (ETSI EN 300 175-7 Ch. A6) >> >> > > > From laforge at gnumonks.org Sat Apr 10 10:49:29 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 10 Apr 2010 12:49:29 +0200 Subject: NanoBTS Problem In-Reply-To: <75848494-408F-4515-9808-AD5D1D65D6F4@bluewave.im> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004092118.39714.zecke@selfish.org> <201004092302.46469.zecke@selfish.org> <20100410095151.GF14576@prithivi.gnumonks.org> <75848494-408F-4515-9808-AD5D1D65D6F4@bluewave.im> Message-ID: <20100410104929.GI14576@prithivi.gnumonks.org> I can reproduce your problem on a GSM900 nanoBTS, but I don't really have any idea why that happens. Using ipaccess-telnet and using moi::states to look at the debug console of the nanoBTS, I can see: ----- MOI States ----- [ Site] (Null:255), Enabled, [ BTS:0] (Unlocked), Disabled, [ BBTRX:0-0] (Unlocked), Disabled, > [ Channel:0-0-0] (Locked), Disabled, > [ Channel:0-0-1] (Locked), Disabled, > [ Channel:0-0-2] (Locked), Disabled, > [ Channel:0-0-3] (Locked), Disabled, > [ Channel:0-0-4] (Locked), Disabled, > [ Channel:0-0-5] (Locked), Disabled, > [ Channel:0-0-6] (Locked), Disabled, > [ Channel:0-0-7] (Locked), Disabled, > [ Carrier:0-0] (Unlocked), Disabled, > [ GPRS NSE:0] (Locked), Disabled, [ GPRS Cell:0-0] (Unlocked), Disabled, > [ GPRS NSVC:0-0] (Locked), Disabled, > [ GPRS NSVC:0-1] (Locked), Disabled, > The problem is the radio carrier. It is Disabled, without having any dependency on other objects. Sending OPSTART even twice does not change its state. If the Radio Carrier would get into Enabled state, the Channels would all get rid of their Dependency problem. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From stuart at bluewave.im Sat Apr 10 11:02:17 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sat, 10 Apr 2010 12:02:17 +0100 Subject: NanoBTS Problem In-Reply-To: <20100410104929.GI14576@prithivi.gnumonks.org> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004092118.39714.zecke@selfish.org> <201004092302.46469.zecke@selfish.org> <20100410095151.GF14576@prithivi.gnumonks.org> <75848494-408F-4515-9808-AD5D1D65D6F4@bluewave.im> <20100410104929.GI14576@prithivi.gnumonks.org> Message-ID: I would like to know how to downgrade my openbsc to get this BTS online (just for testing). I tried to use the git commands from Holger, but no luck so far. $ git bisect start -- openbsc/ $ git bisect bad HEAD $ git bisect good 0.9.0 $ cd openbsc/; make (and if I have link errors or such I would downgrade libosmocore too... I would downgrade by checking out the releases). Is there anyway I can get this BTS setup and working in the short term? Thanks, Stuart On 10 Apr 2010, at 11:49, Harald Welte wrote: > I can reproduce your problem on a GSM900 nanoBTS, but I don't really > have any idea why that happens. > > Using ipaccess-telnet and using moi::states to look at the debug console > of the nanoBTS, I can see: > > ----- MOI States ----- > [ Site] (Null:255), Enabled, > [ BTS:0] (Unlocked), Disabled, > [ BBTRX:0-0] (Unlocked), Disabled, > > [ Channel:0-0-0] (Locked), Disabled, > > [ Channel:0-0-1] (Locked), Disabled, > > [ Channel:0-0-2] (Locked), Disabled, > > [ Channel:0-0-3] (Locked), Disabled, > > [ Channel:0-0-4] (Locked), Disabled, > > [ Channel:0-0-5] (Locked), Disabled, > > [ Channel:0-0-6] (Locked), Disabled, > > [ Channel:0-0-7] (Locked), Disabled, > > [ Carrier:0-0] (Unlocked), Disabled, > > [ GPRS NSE:0] (Locked), Disabled, > [ GPRS Cell:0-0] (Unlocked), Disabled, > > [ GPRS NSVC:0-0] (Locked), Disabled, > > [ GPRS NSVC:0-1] (Locked), Disabled, > > > The problem is the radio carrier. It is Disabled, without having any > dependency on other objects. Sending OPSTART even twice does not change > its state. > > If the Radio Carrier would get into Enabled state, the Channels would > all get rid of their Dependency problem. > > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > From zecke at selfish.org Sat Apr 10 11:26:45 2010 From: zecke at selfish.org (Holger Freyther) Date: Sat, 10 Apr 2010 13:26:45 +0200 Subject: NanoBTS Problem In-Reply-To: References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <20100410104929.GI14576@prithivi.gnumonks.org> Message-ID: <201004101326.46731.zecke@selfish.org> On Saturday 10 April 2010 13:02:17 Stuart Baggs wrote: > I would like to know how to downgrade my openbsc to get this BTS online > (just for testing). I tried to use the git commands from Holger, but no > luck so far. > > $ git bisect start -- openbsc/ > $ git bisect bad HEAD > $ git bisect good 0.9.0 > > $ cd openbsc/; make (and if I have link errors or such I would downgrade > libosmocore too... I would downgrade by checking out the releases). > > Is there anyway I can get this BTS setup and working in the short term? Well, I'm a bit confused. You mentioned that 0.9.0 is not working and now you mention you don't know how to checkout a given version of git? The original message I wrote had two parts: 1.) Consult a git tutorial of your choice 2.) If you want to debug this, use git bisect (you copied this bit). Let us assume you want to reset your current branch to an older version you can use the git reset (man git-reset) utility. $ git reset --hard TAG|HASH TAG can be a tag, e.g. 0.9.0 HASH can be a sha1 hash of a git commit.. but the above is no replacement for consulting a git tutorial, and of course if you got back to an older release you might need to install an older version of libosmocore as well. From stuart at bluewave.im Sat Apr 10 11:34:39 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sat, 10 Apr 2010 12:34:39 +0100 Subject: NanoBTS Problem In-Reply-To: <201004101326.46731.zecke@selfish.org> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <20100410104929.GI14576@prithivi.gnumonks.org> <201004101326.46731.zecke@selfish.org> Message-ID: <7E58E718-A434-43B5-BE35-BAD7818DB2FB@bluewave.im> Ok I entered git reset --hard 0.9.0 but when I issue a fresh "git pull" I get this error: root at gateway:~/openbsc# git pull You are not currently on a branch, so I cannot use any 'branch..merge' in your configuration file. Please specify which branch you want to merge on the command line and try again (e.g. 'git pull '). See git-pull(1) for details. Is there a tar.gz file of the 0.9.0 version of openbts? I am really keen to get involved in the project but I simply cannot understand how GIT works and no mattter how many tutorials I read it is still clear as mud. I really would appreciate some instructions on how to get a fresh version of OpenBSC to work with my rugby sized nanoBTS. Thanks for your help. On 10 Apr 2010, at 12:26, Holger Freyther wrote: > git reset --hard From zecke at selfish.org Sat Apr 10 13:09:42 2010 From: zecke at selfish.org (Holger Freyther) Date: Sat, 10 Apr 2010 15:09:42 +0200 Subject: GIT support was: Re: NanoBTS Problem In-Reply-To: <7E58E718-A434-43B5-BE35-BAD7818DB2FB@bluewave.im> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004101326.46731.zecke@selfish.org> <7E58E718-A434-43B5-BE35-BAD7818DB2FB@bluewave.im> Message-ID: <201004101509.43450.zecke@selfish.org> On Saturday 10 April 2010 13:34:39 Stuart Baggs wrote: > Ok I entered git reset --hard 0.9.0 but when I issue a fresh "git pull" I > get this error: > > root at gateway:~/openbsc# git pull > You are not currently on a branch, so I cannot use any > 'branch..merge' in your configuration file. > Please specify which branch you want to merge on the command > line and try again (e.g. 'git pull '). > See git-pull(1) for details. > > Is there a tar.gz file of the 0.9.0 version of openbts? I am really keen to > get involved in the project but I simply cannot understand how GIT works > and no mattter how many tutorials I read it is still clear as mud. Hi Stuart, git can be hard to understand at first but with a basic cheat sheet and just using a handful commands you should be just fine. What most likely happened for you is you typed some of the bisect commands I wrote without actually knowing what they will do and what you will have to do. What git bisect does is it go away from your default branch to a unnamed temporary branch to jump in the history... Now when you type "git pull" it is first fetching objects from the default remote (origin) and then tries to merge with the remote branch that you are tracking... The problem is you are currently not on a branch (as the command tells you) and so it refuses to merge. All you want to type is "git bisect reset" to go back to before you started the bisect. which brings you back to the master branch.. From stuart at bluewave.im Sat Apr 10 13:13:44 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sat, 10 Apr 2010 14:13:44 +0100 Subject: GIT support was: Re: NanoBTS Problem In-Reply-To: <201004101509.43450.zecke@selfish.org> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004101326.46731.zecke@selfish.org> <7E58E718-A434-43B5-BE35-BAD7818DB2FB@bluewave.im> <201004101509.43450.zecke@selfish.org> Message-ID: <1A5D091A-F6AC-4B93-9249-87C53A7A9D21@bluewave.im> Thank you for all your help. I have managed to get OML sync now from a nanoBTS and the network is up. The problem now is that even though I have added my IMSI to the sqlite3 DB, it still give an auth REJECT. Not sure what database name openBSC used by default (or if sqlite even supports multiple databases). Does anyone know how I can get ths to auth based on the entries I have put into sqlite. Thanks, Stuart On 10 Apr 2010, at 14:09, Holger Freyther wrote: > On Saturday 10 April 2010 13:34:39 Stuart Baggs wrote: >> Ok I entered git reset --hard 0.9.0 but when I issue a fresh "git pull" I >> get this error: >> >> root at gateway:~/openbsc# git pull >> You are not currently on a branch, so I cannot use any >> 'branch..merge' in your configuration file. >> Please specify which branch you want to merge on the command >> line and try again (e.g. 'git pull '). >> See git-pull(1) for details. >> >> Is there a tar.gz file of the 0.9.0 version of openbts? I am really keen to >> get involved in the project but I simply cannot understand how GIT works >> and no mattter how many tutorials I read it is still clear as mud. > > Hi Stuart, > > git can be hard to understand at first but with a basic cheat sheet and just > using a handful commands you should be just fine. > > What most likely happened for you is you typed some of the bisect commands I > wrote without actually knowing what they will do and what you will have to do. > What git bisect does is it go away from your default branch to a unnamed > temporary branch to jump in the history... > > Now when you type "git pull" it is first fetching objects from the default > remote (origin) and then tries to merge with the remote branch that you are > tracking... The problem is you are currently not on a branch (as the command > tells you) and so it refuses to merge. > > All you want to type is "git bisect reset" to go back to before you started > the bisect. which brings you back to the master branch.. > > > From zecke at selfish.org Sat Apr 10 13:24:11 2010 From: zecke at selfish.org (Holger Freyther) Date: Sat, 10 Apr 2010 15:24:11 +0200 Subject: GIT support was: Re: NanoBTS Problem Message-ID: <201004101524.12307.zecke@selfish.org> On Saturday 10 April 2010 15:13:44 you wrote: > Thank you for all your help. I have managed to get OML sync now from a > nanoBTS and the network is up. The problem now is that even though I have > added my IMSI to the sqlite3 DB, it still give an auth REJECT. > > Not sure what database name openBSC used by default (or if sqlite even > supports multiple databases). Does anyone know how I can get ths to auth > based on the entries I have put into sqlite. http://openbsc.gnumonks.org/trac/wiki/BscHack From stuart at bluewave.im Sat Apr 10 13:46:42 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sat, 10 Apr 2010 14:46:42 +0100 Subject: GIT support was: Re: NanoBTS Problem In-Reply-To: <201004101524.12307.zecke@selfish.org> References: <201004101524.12307.zecke@selfish.org> Message-ID: The problem seems to be that openBSC is not adding data to the database hlr.sqlite. It doesnt matter how many AUTh REJECTs I trigger, my details are not logged into the Equipment or Subscriber tables. When I add the info manually via the CLI tool sqlite the data says it has been inserted but then a SELECT * shows now results. hlr.sqlite has a CHMOD of 0777. Thanks, s On 10 Apr 2010, at 14:24, Holger Freyther wrote: > On Saturday 10 April 2010 15:13:44 you wrote: >> Thank you for all your help. I have managed to get OML sync now from a >> nanoBTS and the network is up. The problem now is that even though I have >> added my IMSI to the sqlite3 DB, it still give an auth REJECT. >> >> Not sure what database name openBSC used by default (or if sqlite even >> supports multiple databases). Does anyone know how I can get ths to auth >> based on the entries I have put into sqlite. > > http://openbsc.gnumonks.org/trac/wiki/BscHack > > > From stuart at bluewave.im Sat Apr 10 11:45:23 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sat, 10 Apr 2010 12:45:23 +0100 Subject: NanoBTS Problem In-Reply-To: <201004101326.46731.zecke@selfish.org> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <20100410104929.GI14576@prithivi.gnumonks.org> <201004101326.46731.zecke@selfish.org> Message-ID: Hi guys, is there a list somwhere which matches versions of openbsc with the required version of libosmocore? Thanks, Stuart On 10 Apr 2010, at 12:26, Holger Freyther wrote: > On Saturday 10 April 2010 13:02:17 Stuart Baggs wrote: >> I would like to know how to downgrade my openbsc to get this BTS online >> (just for testing). I tried to use the git commands from Holger, but no >> luck so far. >> >> $ git bisect start -- openbsc/ >> $ git bisect bad HEAD >> $ git bisect good 0.9.0 >> >> $ cd openbsc/; make (and if I have link errors or such I would downgrade >> libosmocore too... I would downgrade by checking out the releases). >> >> Is there anyway I can get this BTS setup and working in the short term? > > Well, > I'm a bit confused. You mentioned that 0.9.0 is not working and now you > mention you don't know how to checkout a given version of git? The original > message I wrote had two parts: > > 1.) Consult a git tutorial of your choice > 2.) If you want to debug this, use git bisect (you copied this bit). > > > Let us assume you want to reset your current branch to an older version you > can use the git reset (man git-reset) utility. > > $ git reset --hard TAG|HASH > > TAG can be a tag, e.g. 0.9.0 > HASH can be a sha1 hash of a git commit.. > > but the above is no replacement for consulting a git tutorial, and of course > if you got back to an older release you might need to install an older version > of libosmocore as well. > > > > > From 246tnt at gmail.com Sat Apr 10 21:24:11 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 10 Apr 2010 23:24:11 +0200 Subject: NanoBTS Problem In-Reply-To: References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <20100410104929.GI14576@prithivi.gnumonks.org> <201004101326.46731.zecke@selfish.org> Message-ID: Reverting commit f5284ae1cf8babc1567b33f469e20a66a73fcd9e --- ipa: Reduce the throttling of the IPA msges This code used to be a sleep, it was changed to be a timer by Andreas but this timer does not seem to have any use. When doing the sw load this timer is increasing the upload time dramatically, reduce it to make it work faster. --- fixes the problem for me. Sylvain From zecke at selfish.org Sat Apr 10 21:40:08 2010 From: zecke at selfish.org (Holger Freyther) Date: Sat, 10 Apr 2010 23:40:08 +0200 Subject: NanoBTS Problem In-Reply-To: References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> Message-ID: <201004102340.08950.zecke@selfish.org> On Saturday 10 April 2010 23:24:11 Sylvain Munaut wrote: > Reverting commit f5284ae1cf8babc1567b33f469e20a66a73fcd9e Okay, feel free to push it to the repository. I will make it configurable as I want to have a way lower timeout for the software load. z. From 246tnt at gmail.com Sat Apr 10 21:47:05 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 10 Apr 2010 23:47:05 +0200 Subject: NanoBTS Problem In-Reply-To: <201004102340.08950.zecke@selfish.org> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004102340.08950.zecke@selfish.org> Message-ID: >> Reverting commit f5284ae1cf8babc1567b33f469e20a66a73fcd9e > > Okay, feel free to push it to the repository. I will make it configurable as I > want to have a way lower timeout for the software load. I was hoping someone would know _why_ this has _any_ impact at all ... From zecke at selfish.org Sat Apr 10 23:18:35 2010 From: zecke at selfish.org (Holger Freyther) Date: Sun, 11 Apr 2010 01:18:35 +0200 Subject: NanoBTS Problem In-Reply-To: References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004102340.08950.zecke@selfish.org> Message-ID: <201004110118.35226.zecke@selfish.org> On Saturday 10 April 2010 23:47:05 Sylvain Munaut wrote: > >> Reverting commit f5284ae1cf8babc1567b33f469e20a66a73fcd9e > > > > Okay, feel free to push it to the repository. I will make it configurable > > as I want to have a way lower timeout for the software load. > > I was hoping someone would know _why_ this has _any_ impact at all ... Some timing problem. In older versions we used a usleep, then Andreas switched it to a timer and then I reduced the timeout to have a faster firmware loading... we can probably only speculate why we need to wait a bit more... or maybe we are hiding a bug in our bootstrap where we would need to wait for an ack before we can continue.. From laforge at gnumonks.org Sun Apr 11 05:43:26 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 11 Apr 2010 07:43:26 +0200 Subject: NanoBTS Problem In-Reply-To: References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <20100410104929.GI14576@prithivi.gnumonks.org> <201004101326.46731.zecke@selfish.org> Message-ID: <20100411054326.GH3284@prithivi.gnumonks.org> Hi Sylvain, thanks for debugging this. On Sat, Apr 10, 2010 at 11:24:11PM +0200, Sylvain Munaut wrote: > Reverting commit f5284ae1cf8babc1567b33f469e20a66a73fcd9e > > --- > ipa: Reduce the throttling of the IPA msges > > This code used to be a sleep, it was changed to be a timer by Andreas > but this timer does not seem to have any use. When doing the sw load > this timer is increasing the upload time dramatically, reduce it to > make it work faster. > --- > > fixes the problem for me. That makes complete sense. In fact, the reason why that throttling was in place ('does not seem to have any use') was exactly to make the initialization work at all. Initially I was working with a GSM900 unit, and the initialization never worked without those sleeps. This probably means that we're still doing something wrong with regard to the object state transitions. I never really understood why 12.21 has to be so horribly complex with all those objects and their dependencies, as well as administrative, operational and a third stage. It sounds like a stupid exercise in object oriented data model serving nothing but the purpose of advertising the perceived marvels of object orientation :( I for my part think reverting the patch is the way to go, until somebody has debugged this issue. Is that ok with you, zecke? 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 zecke at selfish.org Sun Apr 11 07:46:45 2010 From: zecke at selfish.org (Holger Freyther) Date: Sun, 11 Apr 2010 09:46:45 +0200 Subject: NanoBTS Problem In-Reply-To: <20100411054326.GH3284@prithivi.gnumonks.org> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <20100411054326.GH3284@prithivi.gnumonks.org> Message-ID: <201004110946.45287.zecke@selfish.org> On Sunday 11 April 2010 07:43:26 Harald Welte wrote: > I for my part think reverting the patch is the way to go, until somebody > has debugged this issue. Is that ok with you, zecke? Yeah, I already mentioned that I'm perfectly fine with that. I have a GSM900 nanoBTS at home and I will figure out what is going on on this one and will attempt to land such a patch again without breaking the GSM900 this time. holger From stuart at bluewave.im Sun Apr 11 11:04:44 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sun, 11 Apr 2010 12:04:44 +0100 Subject: OpenBSC code questions In-Reply-To: <20100411054326.GH3284@prithivi.gnumonks.org> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <20100410104929.GI14576@prithivi.gnumonks.org> <201004101326.46731.zecke@selfish.org> <20100411054326.GH3284@prithivi.gnumonks.org> Message-ID: <66286C36-71C6-4ED9-B38F-AFA403075D95@bluewave.im> I am also getting problems with SMS buffering until the handset restarts or the bsc_hack program restarts. No segmentation faults though. I am running 0.9.0 with DSC1800 nanoBTS GPRS (Rugby Ball). From 246tnt at gmail.com Sun Apr 11 11:48:37 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 11 Apr 2010 13:48:37 +0200 Subject: OpenBSC code questions In-Reply-To: <66286C36-71C6-4ED9-B38F-AFA403075D95@bluewave.im> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <20100410104929.GI14576@prithivi.gnumonks.org> <201004101326.46731.zecke@selfish.org> <20100411054326.GH3284@prithivi.gnumonks.org> <66286C36-71C6-4ED9-B38F-AFA403075D95@bluewave.im> Message-ID: sms are distributed only on location updates or when forced in the telnet CLI. On Sun, Apr 11, 2010 at 1:04 PM, Stuart Baggs wrote: > I am also getting problems with SMS buffering until the handset restarts or the bsc_hack program restarts. No segmentation faults though. I am running 0.9.0 with DSC1800 nanoBTS GPRS (Rugby Ball). > From meierk at informatik.uni-freiburg.de Tue Apr 13 10:46:51 2010 From: meierk at informatik.uni-freiburg.de (Konrad Meier) Date: Tue, 13 Apr 2010 12:46:51 +0200 Subject: NanoBTS Problem In-Reply-To: References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004092118.39714.zecke@selfish.org> <201004092302.46469.zecke@selfish.org> Message-ID: <4BC44B9B.5000003@informatik.uni-freiburg.de> Sylvain Munaut schrieb: >>> That's weird because I was running the GPRS branch on a rugby sized >>> nanoBTS. It initially didn't work because of the NM_ATT_IPACC_RLC_CFG_3 >>> attribute but this one is now commented out. >>> >>> Note that some nanoBTS require fixes that are only in my pending >>> branch ... (but that's a pre-lisbosmocore branch, I haven't rebased it >>> yet). >> Do you need some help to merge patches of your branch? > > They rebased automatically quite fine. I didn't push the rebased > version yet because I didn't get a chance to test it yet. > > I think Harald wanted to see if they didn't affect proper operation on > the EDGE units and BS-11. Since I don't have any of those, I can't > test myself. I now can confirm that the sylvain/pending branch works with the following BTS: nanoBTS 139 (DCS1800 rugby sized) nanoBTS 165AU (DCS1800 EDGE version) BS11 > > Sylvain > From zecke at selfish.org Tue Apr 13 10:49:10 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 13 Apr 2010 12:49:10 +0200 Subject: NanoBTS Problem In-Reply-To: <4BC44B9B.5000003@informatik.uni-freiburg.de> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <4BC44B9B.5000003@informatik.uni-freiburg.de> Message-ID: <201004131249.10782.zecke@selfish.org> On Tuesday 13 April 2010 12:46:51 Konrad Meier wrote: > I now can confirm that the sylvain/pending branch works with the > following BTS: > > nanoBTS 139 (DCS1800 rugby sized) > nanoBTS 165AU (DCS1800 EDGE version) > BS11 I can add a DCS900 nanoBTS EDGE to the mix. I think Sylvain should land his branch. > > > Sylvain From zecke at selfish.org Sat Apr 10 13:50:17 2010 From: zecke at selfish.org (Holger Freyther) Date: Sat, 10 Apr 2010 15:50:17 +0200 Subject: GIT support was: Re: NanoBTS Problem In-Reply-To: <1622017E-E16F-406B-9FD9-821D2B0938C0@bluewave.im> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004101520.15153.zecke@selfish.org> <1622017E-E16F-406B-9FD9-821D2B0938C0@bluewave.im> Message-ID: <201004101550.17723.zecke@selfish.org> On Saturday 10 April 2010 15:27:21 Stuart Baggs wrote: > Hi, yep I followed those instructions but even with a restart of bsc_hack > it still ignores the DB contents. Well, it is unlikely that it ignores the content. It is more likely that you are not using the database you think you are using. type bsc_hack and find the option to specify the path to the database, do a ls -la /proc/`pidof bsc_gack/fd to see which database was opened. From stuart at bluewave.im Sat Apr 10 13:52:49 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sat, 10 Apr 2010 14:52:49 +0100 Subject: GIT support was: Re: NanoBTS Problem In-Reply-To: <201004101550.17723.zecke@selfish.org> References: <0CB086B3-FDFC-435D-AA0A-B09E6BA8D487@bluewave.im> <201004101520.15153.zecke@selfish.org> <1622017E-E16F-406B-9FD9-821D2B0938C0@bluewave.im> <201004101550.17723.zecke@selfish.org> Message-ID: All fixed, problem was extension of .sqlite instead of .sqlite3. Thanks every for your help. On 10 Apr 2010, at 14:50, Holger Freyther wrote: > On Saturday 10 April 2010 15:27:21 Stuart Baggs wrote: >> Hi, yep I followed those instructions but even with a restart of bsc_hack >> it still ignores the DB contents. > > Well, it is unlikely that it ignores the content. It is more likely that you > are not using the database you think you are using. > > type bsc_hack and find the option to specify the path to the database, do a ls > -la /proc/`pidof bsc_gack/fd to see which database was opened. > > > From womax at gmx.ch Sat Apr 10 11:10:51 2010 From: womax at gmx.ch (WoMax) Date: Sat, 10 Apr 2010 13:10:51 +0200 Subject: nanoBTS LED status indicators Message-ID: ... see here what your nanoBTS is trying to tell you :-) http://umts.zerber.us From stuart at bluewave.im Sat Apr 10 11:39:32 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sat, 10 Apr 2010 12:39:32 +0100 Subject: nanoBTS LED status indicators In-Reply-To: References: Message-ID: Thanks a million for that link! On 10 Apr 2010, at 12:10, WoMax wrote: > ... see here what your nanoBTS is trying to tell you :-) > > http://umts.zerber.us > > > > > From stuart at bluewave.im Sat Apr 10 16:18:48 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sat, 10 Apr 2010 17:18:48 +0100 Subject: One Way Audio nano-bts Message-ID: <9910631F-FEDF-4CDC-A224-1BBEE067B866@bluewave.im> Hi guys, any idea why I am getting one-way audio between mobiles on the same bts? I have tried it with both proxy RTP on and off. Not sure what is going on? Thanks s From zecke at selfish.org Sat Apr 10 16:29:56 2010 From: zecke at selfish.org (Holger Freyther) Date: Sat, 10 Apr 2010 18:29:56 +0200 Subject: One Way Audio nano-bts In-Reply-To: <9910631F-FEDF-4CDC-A224-1BBEE067B866@bluewave.im> References: <9910631F-FEDF-4CDC-A224-1BBEE067B866@bluewave.im> Message-ID: <201004101829.57170.zecke@selfish.org> On Saturday 10 April 2010 18:18:48 Stuart Baggs wrote: > Hi guys, any idea why I am getting one-way audio between mobiles on the > same bts? I have tried it with both proxy RTP on and off. Not sure what is > going on? Hi Stuart, please be more verbose and more precise. What does one way mean? Record a packet dump and look if audio packets go in both ways? Is the rtp payload the proper one? How does the output look like? If you have old firmware on your nanoBTS you might need an extra patch. One thread started on the 25th of February. z. From stuart at bluewave.im Sun Apr 11 11:20:56 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sun, 11 Apr 2010 12:20:56 +0100 Subject: One Way Audio nano-bts In-Reply-To: <201004101829.57170.zecke@selfish.org> References: <9910631F-FEDF-4CDC-A224-1BBEE067B866@bluewave.im> <201004101829.57170.zecke@selfish.org> Message-ID: <96E0AB97-941D-4829-A334-C459C6F32CE3@bluewave.im> The calling subscriber can hear the called party but the called party cannot hear the calling party. The firmware onboard is almost certainly old (it shows a build date of 2006 on the HTTP interface). I will look into doing the packet dumps for you but if there is a setting I have missed please let me know. On 10 Apr 2010, at 17:29, Holger Freyther wrote: > On Saturday 10 April 2010 18:18:48 Stuart Baggs wrote: >> Hi guys, any idea why I am getting one-way audio between mobiles on the >> same bts? I have tried it with both proxy RTP on and off. Not sure what is >> going on? > > > Hi Stuart, > > please be more verbose and more precise. What does one way mean? Record a > packet dump and look if audio packets go in both ways? Is the rtp payload the > proper one? How does the output look like? If you have old firmware on your > nanoBTS you might need an extra patch. One thread started on the 25th of > February. > > z. > > > > From 246tnt at gmail.com Sun Apr 11 11:49:31 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 11 Apr 2010 13:49:31 +0200 Subject: One Way Audio nano-bts In-Reply-To: <96E0AB97-941D-4829-A334-C459C6F32CE3@bluewave.im> References: <9910631F-FEDF-4CDC-A224-1BBEE067B866@bluewave.im> <201004101829.57170.zecke@selfish.org> <96E0AB97-941D-4829-A334-C459C6F32CE3@bluewave.im> Message-ID: On Sun, Apr 11, 2010 at 1:20 PM, Stuart Baggs wrote: > The calling subscriber can hear the called party but the called party cannot hear the calling party. The firmware onboard is almost certainly old (it shows a build date of 2006 on the HTTP interface). Can you explain how you got the HTTP interface ? From stuart at bluewave.im Sun Apr 11 11:51:38 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sun, 11 Apr 2010 12:51:38 +0100 Subject: One Way Audio nano-bts In-Reply-To: References: <9910631F-FEDF-4CDC-A224-1BBEE067B866@bluewave.im> <201004101829.57170.zecke@selfish.org> <96E0AB97-941D-4829-A334-C459C6F32CE3@bluewave.im> Message-ID: <0C8E575C-9FA4-49A8-A892-9B859109A714@bluewave.im> Yes, I have a copy of the ip.access nanoBTS installer software for windows. You simply enable it in the NVRAM settings. On 11 Apr 2010, at 12:49, Sylvain Munaut wrote: > On Sun, Apr 11, 2010 at 1:20 PM, Stuart Baggs wrote: >> The calling subscriber can hear the called party but the called party cannot hear the calling party. The firmware onboard is almost certainly old (it shows a build date of 2006 on the HTTP interface). > > Can you explain how you got the HTTP interface ? > From 246tnt at gmail.com Sun Apr 11 11:55:30 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 11 Apr 2010 13:55:30 +0200 Subject: One Way Audio nano-bts In-Reply-To: <0C8E575C-9FA4-49A8-A892-9B859109A714@bluewave.im> References: <9910631F-FEDF-4CDC-A224-1BBEE067B866@bluewave.im> <201004101829.57170.zecke@selfish.org> <96E0AB97-941D-4829-A334-C459C6F32CE3@bluewave.im> <0C8E575C-9FA4-49A8-A892-9B859109A714@bluewave.im> Message-ID: On Sun, Apr 11, 2010 at 1:51 PM, Stuart Baggs wrote: > Yes, I have a copy of the ip.access nanoBTS installer software for windows. You simply enable it in the NVRAM settings. I enabled it but it apperently needs a client HTTP SSL certificate. Can you set it as well with the intaller software ? For you issue: * what's you sw version exactly ? * if you reverse the role of caller / callee, does it reverse who can hear who ? (to know if it's a direction problem or a handset problem) Sylvain From stuart at bluewave.im Sun Apr 11 11:59:40 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sun, 11 Apr 2010 12:59:40 +0100 Subject: One Way Audio nano-bts In-Reply-To: References: <9910631F-FEDF-4CDC-A224-1BBEE067B866@bluewave.im> <201004101829.57170.zecke@selfish.org> <96E0AB97-941D-4829-A334-C459C6F32CE3@bluewave.im> <0C8E575C-9FA4-49A8-A892-9B859109A714@bluewave.im> Message-ID: No SSL cert required here, just type the nanoBTS ip into your browser over standard HTTP. Brings up a link to two pages showing NVRAM settings. Yes, if you reverse roles of the handsets it stays the same i.e. the called party can never here the caller. Stuart On 11 Apr 2010, at 12:55, Sylvain Munaut wrote: > On Sun, Apr 11, 2010 at 1:51 PM, Stuart Baggs wrote: >> Yes, I have a copy of the ip.access nanoBTS installer software for windows. You simply enable it in the NVRAM settings. > > I enabled it but it apperently needs a client HTTP SSL certificate. > Can you set it as well with the intaller software ? > > For you issue: > * what's you sw version exactly ? > * if you reverse the role of caller / callee, does it reverse who can > hear who ? (to know if it's a direction problem or a handset problem) > > Sylvain > From 246tnt at gmail.com Sun Apr 11 12:06:56 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 11 Apr 2010 14:06:56 +0200 Subject: One Way Audio nano-bts In-Reply-To: References: <9910631F-FEDF-4CDC-A224-1BBEE067B866@bluewave.im> <201004101829.57170.zecke@selfish.org> <96E0AB97-941D-4829-A334-C459C6F32CE3@bluewave.im> <0C8E575C-9FA4-49A8-A892-9B859109A714@bluewave.im> Message-ID: On Sun, Apr 11, 2010 at 1:59 PM, Stuart Baggs wrote: > No SSL cert required here, just type the nanoBTS ip into your browser over standard HTTP. Brings up a link to two pages showing NVRAM settings. mmm, can you post them (screenshots or something ?) Maybe there is a flag to disable that security ... > Yes, if you reverse roles of the handsets it stays the same i.e. the called party can never here the caller. Post a full debug log on pastbin.ca or similar. bsc_hack -d DINP:DNM:DRSL:DRR:DMM:DCC:DRLL:DMNCC:DSMS:DPAG,0:0:0 Sylvain From stuart at bluewave.im Sun Apr 11 12:19:22 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sun, 11 Apr 2010 13:19:22 +0100 Subject: One Way Audio nano-bts In-Reply-To: References: <9910631F-FEDF-4CDC-A224-1BBEE067B866@bluewave.im> <201004101829.57170.zecke@selfish.org> <96E0AB97-941D-4829-A334-C459C6F32CE3@bluewave.im> <0C8E575C-9FA4-49A8-A892-9B859109A714@bluewave.im> Message-ID: <0ED16228-CB7C-409B-9A10-92AB741F3EAA@bluewave.im> Hi Sylvain Debug log is here: root at gateway:~/openbsc/openbsc/src# bsc_hack -d DINP:DNM:DRSL:DRR:DMM:DCC:DRLL:DMNCC:DSMS:DPAG,0:0:0 DB: Database initialized. DB: Database prepared. <000d> input/ipaccess.c:515 accept()ed new OML link from 192.168.1.85 <000d> input/ipaccess.c:232 Identified BTS 0/0/0 <0005> bsc_init.c:735 bootstrapping OML for BTS 0 <0005> abis_nm.c:545 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:545 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:545 OC=GPRS NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:545 OC=GPRS CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:545 OC=SITE MANAGER(00) INST=(ff,ff,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:545 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:545 OC=SITE MANAGER(00) INST=(ff,ff,ff) Sending OPSTART <0005> abis_nm.c:545 OC=SITE MANAGER(00) INST=(ff,ff,ff) Software Activated Report <0005> abis_nm.c:545 OC=BTS(01) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:545 OC=GPRS NSE(f0) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:545 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1783 Set BTS Attr (bts=0) <0005> abis_nm.c:545 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART <0005> abis_nm.c:545 OC=BTS(01) INST=(00,ff,ff) Software Activated Report <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:545 OC=GPRS NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:545 OC=GPRS NSE(f0) INST=(00,ff,ff) Software Activated Report <0005> abis_nm.c:545 OC=GPRS CELL(f1) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,01,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 <0005> abis_nm.c:545 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:2854 ip.access RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=0) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=1) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=2) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,02) Sending OPSTART <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=3) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,03) Sending OPSTART <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=4) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,04) Sending OPSTART <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=5) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,05) Sending OPSTART <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=6) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,06) Sending OPSTART <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=7) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,07) Sending OPSTART <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,00) Software Activated Report <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,01) Software Activated Report <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,02) Software Activated Report <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,03) Software Activated Report <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,04) Software Activated Report <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,05) Software Activated Report <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,06) Software Activated Report <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,07) Software Activated Report <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:1800 Set TRX Attr (bts=0,trx=0) <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:545 OC=GPRS CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:545 OC=GPRS CELL(f1) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,01,ff) Software Activated Report <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xe1): RSL CONNECT ACK IP=192.168.1.50 PORT=3003 STREAM=0x00 <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) Sending OPSTART <000d> input/ipaccess.c:573 accept()ed new RSL link from 192.168.1.85 <000d> input/ipaccess.c:232 Identified BTS 0/0/0 <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Failure Event Report Type=communication failure Severity=failure ceased <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:545 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0004> bsc_init.c:896 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 870 using MCC=234 MNC=18 LAC=1 CID=0 BSIC=63 TSC=7 <0003> bsc_init.c:798 SI 1: 55 06 19 8f b3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e5 04 00 2b <0003> bsc_init.c:798 SI 2: 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00 <0003> bsc_init.c:798 SI 3: 49 06 1b 00 00 32 f4 81 00 01 41 03 00 22 5d 00 e5 04 00 3b 2b 2b 2b <0003> bsc_init.c:798 SI 4: 31 06 1c 32 f4 81 00 01 5d 00 e5 04 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0003> bsc_init.c:815 SI 5: 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <0003> bsc_init.c:822 SI 6: 2d 06 1e 00 00 32 f4 81 00 01 22 ff <0004> abis_rsl.c:1157 (bts=0,trx=0,ts=2,ss=0) Activating ARFCN(870) SS(0) lctype TCH/F r=OTHER ra=0xeb <0004> abis_rsl.c:963 (bts=0,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 ESTABLISH INDICATION <0002> gsm_04_08.c:613 <- CM SERVICE REQUEST serv_type=0x08 mi_type=0x04 M(1758515149) <0002> gsm_04_08.c:564 -> CM SERVICE ACK <0001> gsm_04_08_utils.c:76 (bts 0 trx 0 ts 2 pd 05) Sending 0x21 to MS. <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0003> gsm_04_08.c:823 CLASSMARK CHANGE CM2(len=3) CM3(len=4) <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0002> ussd.c:57 Unhandled USSD *101*234*18*353645019793200*000 <0001> gsm_04_08_utils.c:76 (bts 0 trx 0 ts 2 pd 8b) Sending 0x2a to MS. <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0002> gsm_04_08.c:613 <- CM SERVICE REQUEST serv_type=0x01 mi_type=0x04 M(1758515149) <0002> gsm_04_08.c:564 -> CM SERVICE ACK <0001> gsm_04_08_utils.c:76 (bts 0 trx 0 ts 2 pd 05) Sending 0x21 to MS. <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 2 ti 8 sub 4444) Received 'SETUP' from MS in state 0 (NULL) <0001> gsm_04_08.c:2822 Unknown transaction ID 8, creating new trans. <0001> transaction.c:69 subscr=0x883fae8, subscr->net=0x87daf20 <0001> gsm_04_08.c:1011 new state NULL -> INITIATED <0001> gsm_04_08.c:1511 Subscriber 234180000035836 (4444) sends SETUP to 6666 <0001> gsm_04_08.c:1071 (bts 0 trx 0 ts 2 ti 8 sub 4444) Sending 'MNCC_SETUP_IND' to MNCC. <0006> mncc.c:386 (call 80000001) Call created. <0006> mncc.c:395 (call 80000001) Received message MNCC_SETUP_IND <0006> mncc.c:176 (call 80000001) Creating new remote instance 1. <0006> mncc.c:186 (call 80000001) Modify channel mode. <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 2 ti 08 sub 4444) Received 'MNCC_LCHAN_MODIFY' from MNCC in state 1 (INITIATED) <0003> gsm_04_08_utils.c:465 -> CHANNEL MODE MODIFY mode=0x21 <0001> gsm_04_08_utils.c:76 (bts 0 trx 0 ts 2 pd 06) Sending 0x10 to MS. <0006> mncc.c:192 (call 80000001) Accepting call. <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 2 ti 08 sub 4444) Received 'MNCC_CALL_PROC_REQ' from MNCC in state 1 (INITIATED) <0001> gsm_04_08.c:1011 new state INITIATED -> MO_CALL_PROC <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 2 ti 80) Sending 'CALL_PROC' to MS. <0006> mncc.c:199 (call 80000001) Forwarding SETUP to remote. <0001> transaction.c:69 subscr=0x88424e8, subscr->net=0x87daf20 <0008> paging.c:235 Start paging of subscriber 16 on bts 0. <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0003> gsm_04_08_utils.c:515 CHANNEL MODE MODIFY ACK <0004> abis_rsl.c:1433 (bts=0,trx=0,ts=2,ss=0) IPAC_BIND speech_mode=0x11 <0004> abis_rsl.c:988 (bts=0,trx=0,ts=2,ss=0) CHANNEL MODE MODIFY ACK <0004> abis_rsl.c:1610 (bts=0,trx=0,ts=2,ss=0) IPAC_CRCX_ACK LOCAL_IP=192.168.1.85 LOCAL_PORT=4016 CON_ID=24 RTP_PAYLOAD2=0x6f <0008> paging.c:94 Going to send paging commands: imsi: '234180000035787' tmsi: '0x465a6689' <0004> abis_rsl.c:1157 (bts=0,trx=0,ts=3,ss=0) Activating ARFCN(870) SS(0) lctype TCH/F r=PAGING ra=0x2c <0004> abis_rsl.c:963 (bts=0,trx=0,ts=3,ss=0) CHANNEL ACTIVATE ACK <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=3,ss=0) SAPI=0 ESTABLISH INDICATION <0003> gsm_04_08.c:787 PAGING RESPONSE: mi_type=0x04 MI(1180329609) <0003> gsm_04_08.c:805 <- Channel was requested by 234180000035787 <0008> paging.c:299 Stop paging on bts 0, calling cbfn. <0001> gsm_04_08.c:1153 Paging subscr 6666 succeeded! <0001> gsm_04_08.c:1434 starting timer T303 with 30 seconds <0001> gsm_04_08.c:1011 new state NULL -> CALL_PRESENT <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 3 ti 00) Sending 'SETUP' to MS. <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=3,ss=0) SAPI=0 DATA INDICATION <0003> gsm_04_08.c:823 CLASSMARK CHANGE CM2(len=3) CM3(len=7) <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=3,ss=0) SAPI=0 DATA INDICATION <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 3 ti 0 sub 6666) Received 'CALL_CONF' from MS in state 6 (CALL_PRESENT) <0001> gsm_04_08.c:1052 stopping pending timer T303 <0001> gsm_04_08.c:1434 starting timer T310 with 180 seconds <0001> gsm_04_08.c:1011 new state CALL_PRESENT -> MO_TERM_CALL_CONF <0001> gsm_04_08.c:1071 (bts 0 trx 0 ts 3 ti 0 sub 6666) Sending 'MNCC_CALL_CONF_IND' to MNCC. <0006> mncc.c:395 (call 1) Received message MNCC_CALL_CONF_IND <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 3 ti 00 sub 6666) Received 'MNCC_LCHAN_MODIFY' from MNCC in state 9 (MO_TERM_CALL_CONF) <0003> gsm_04_08_utils.c:465 -> CHANNEL MODE MODIFY mode=0x21 <0001> gsm_04_08_utils.c:76 (bts 0 trx 0 ts 3 pd 06) Sending 0x10 to MS. <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=3,ss=0) SAPI=0 DATA INDICATION <0003> gsm_04_08_utils.c:515 CHANNEL MODE MODIFY ACK <0004> abis_rsl.c:1433 (bts=0,trx=0,ts=3,ss=0) IPAC_BIND speech_mode=0x11 <0004> abis_rsl.c:988 (bts=0,trx=0,ts=3,ss=0) CHANNEL MODE MODIFY ACK <0004> abis_rsl.c:1610 (bts=0,trx=0,ts=3,ss=0) IPAC_CRCX_ACK LOCAL_IP=192.168.1.85 LOCAL_PORT=4018 CON_ID=25 RTP_PAYLOAD2=0x70 <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=3,ss=0) SAPI=0 DATA INDICATION <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 3 ti 0 sub 6666) Received 'ALERTING' from MS in state 9 (MO_TERM_CALL_CONF) <0001> gsm_04_08.c:1052 stopping pending timer T310 <0001> gsm_04_08.c:1434 starting timer T301 with 180 seconds <0001> gsm_04_08.c:1011 new state MO_TERM_CALL_CONF -> CALL_RECEIVED <0001> gsm_04_08.c:1071 (bts 0 trx 0 ts 3 ti 0 sub 6666) Sending 'MNCC_ALERT_IND' to MNCC. <0006> mncc.c:395 (call 1) Received message MNCC_ALERT_IND <0006> mncc.c:217 (call 1) Forwarding ALERT to remote. <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 2 ti 08 sub 4444) Received 'MNCC_ALERT_REQ' from MNCC in state 3 (MO_CALL_PROC) <0001> gsm_04_08.c:1011 new state MO_CALL_PROC -> CALL_DELIVERED <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 2 ti 80) Sending 'ALERTING' to MS. <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=3,ss=0) SAPI=0 DATA INDICATION <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 3 ti 0 sub 6666) Received 'CONNECT' from MS in state 7 (CALL_RECEIVED) <0001> gsm_04_08.c:1052 stopping pending timer T301 <0001> gsm_04_08.c:1011 new state CALL_RECEIVED -> CONNECT_REQUEST <0001> gsm_04_08.c:1071 (bts 0 trx 0 ts 3 ti 0 sub 6666) Sending 'MNCC_SETUP_CNF' to MNCC. <0006> mncc.c:395 (call 1) Received message MNCC_SETUP_CNF <0006> mncc.c:245 (call 1) Acknowledge SETUP. <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 3 ti 00 sub 6666) Received 'MNCC_SETUP_COMPL_REQ' from MNCC in state 8 (CONNECT_REQUEST) <0001> gsm_04_08.c:1011 new state CONNECT_REQUEST -> ACTIVE <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 3 ti 00) Sending 'CONNECT_ACK' to MS. <0006> mncc.c:252 (call 1) Sending CONNECT to remote. <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 2 ti 08 sub 4444) Received 'MNCC_SETUP_RSP' from MNCC in state 4 (CALL_DELIVERED) <0001> gsm_04_08.c:1434 starting timer T313 with 30 seconds <0001> gsm_04_08.c:1011 new state CALL_DELIVERED -> CONNECT_IND <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 2 ti 80) Sending 'CONNECT' to MS. <0006> mncc.c:258 (call 1) Bridging with remote. <0001> gsm_04_08.c:1222 Setting up TCH map between (bts=0,trx=0,ts=3) and (bts=0,trx=0,ts=2) <0004> abis_rsl.c:1464 (bts=0,trx=0,ts=3,ss=0) IPAC_MDCX IP=192.168.1.85 PORT=4016 RTP_PAYLOAD2=111 CONN_ID=25 speech_mode=0x01 <0004> abis_rsl.c:1464 (bts=0,trx=0,ts=2,ss=0) IPAC_MDCX IP=192.168.1.85 PORT=4018 RTP_PAYLOAD2=111 CONN_ID=24 speech_mode=0x01 <0004> abis_rsl.c:1620 (bts=0,trx=0,ts=3,ss=0) IPAC_MDCX_ACK CON_ID=25 <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 2 ti 8 sub 4444) Received 'CONNECT_ACK' from MS in state 28 (CONNECT_IND) <0001> gsm_04_08.c:1052 stopping pending timer T313 <0001> gsm_04_08.c:1011 new state CONNECT_IND -> ACTIVE <0001> gsm_04_08.c:1071 (bts 0 trx 0 ts 2 ti 8 sub 4444) Sending 'MNCC_SETUP_COMPL_IND' to MNCC. <0006> mncc.c:395 (call 80000001) Received message MNCC_SETUP_COMPL_IND <0004> abis_rsl.c:1620 (bts=0,trx=0,ts=2,ss=0) IPAC_MDCX_ACK CON_ID=24 <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 2 ti 8 sub 4444) Received 'DISCONNECT' from MS in state 10 (ACTIVE) <0001> gsm_04_08.c:1011 new state ACTIVE -> DISCONNECT_IND <0001> gsm_04_08.c:1071 (bts 0 trx 0 ts 2 ti 8 sub 4444) Sending 'MNCC_DISC_IND' to MNCC. <0006> mncc.c:395 (call 80000001) Received message MNCC_DISC_IND <0006> mncc.c:288 (call 80000001) Releasing call with cause 16 <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 2 ti 08 sub 4444) Received 'MNCC_REL_REQ' from MNCC in state 12 (DISCONNECT_IND) <0001> gsm_04_08.c:1434 starting timer T308 with 10 seconds <0001> gsm_04_08.c:1011 new state DISCONNECT_IND -> RELEASE_REQ <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 2 ti 80) Sending 'RELEASE' to MS. <0006> mncc.c:297 (call 1) Disconnecting remote with cause 16 <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 3 ti 00 sub 6666) Received 'MNCC_DISC_REQ' from MNCC in state 10 (ACTIVE) <0001> gsm_04_08.c:1434 starting timer T306 with 30 seconds <0001> gsm_04_08.c:1011 new state ACTIVE -> DISCONNECT_IND <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 3 ti 00) Sending 'DISCONNECT' to MS. <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 2 ti 8 sub 4444) Received 'RELEASE_COMPL' from MS in state 19 (RELEASE_REQ) <0001> gsm_04_08.c:1052 stopping pending timer T308 <0001> gsm_04_08.c:1011 new state RELEASE_REQ -> NULL <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=3,ss=0) SAPI=0 DATA INDICATION <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 3 ti 0 sub 6666) Received 'RELEASE' from MS in state 12 (DISCONNECT_IND) <0001> gsm_04_08.c:1052 stopping pending timer T306 <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 3 ti 00) Sending 'RELEASE_COMPL' to MS. <0001> gsm_04_08.c:1071 (bts 0 trx 0 ts 3 ti 0 sub 6666) Sending 'MNCC_REL_IND' to MNCC. <0001> gsm_04_08.c:1011 new state DISCONNECT_IND -> NULL <0006> mncc.c:395 (call 1) Received message MNCC_REL_IND <0006> mncc.c:312 (call 1) Releasing remote with cause 0 <0001> gsm_04_08.c:2610 (bts - trx - ts - ti -- sub ) Received 'MNCC_REL_REQ' from MNCC with unknown callref -2147483647 <0001> gsm_04_08.c:1079 (bts - trx - ts - ti -- sub -) Sending 'MNCC_REL_IND' to MNCC. <0006> mncc.c:111 (call 1) Call removed. <0006> mncc.c:395 (call 80000001) Received message MNCC_REL_IND <0006> mncc.c:111 (call 80000001) Call removed. Screen shots are here: http://www.bluewave.im/images/ipaccess/bts-installer.jpg http://www.bluewave.im/images/ipaccess/bts-http1.jpg Thanks Stuart On 11 Apr 2010, at 13:06, Sylvain Munaut wrote: > On Sun, Apr 11, 2010 at 1:59 PM, Stuart Baggs wrote: >> No SSL cert required here, just type the nanoBTS ip into your browser over standard HTTP. Brings up a link to two pages showing NVRAM settings. > > mmm, can you post them (screenshots or something ?) > Maybe there is a flag to disable that security ... > > >> Yes, if you reverse roles of the handsets it stays the same i.e. the called party can never here the caller. > > Post a full debug log on pastbin.ca or similar. > > bsc_hack -d DINP:DNM:DRSL:DRR:DMM:DCC:DRLL:DMNCC:DSMS:DPAG,0:0:0 > > Sylvain > From stuart at bluewave.im Tue Apr 13 09:02:09 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Tue, 13 Apr 2010 10:02:09 +0100 Subject: One Way Audio nano-bts In-Reply-To: <0ED16228-CB7C-409B-9A10-92AB741F3EAA@bluewave.im> References: <9910631F-FEDF-4CDC-A224-1BBEE067B866@bluewave.im> <201004101829.57170.zecke@selfish.org> <96E0AB97-941D-4829-A334-C459C6F32CE3@bluewave.im> <0C8E575C-9FA4-49A8-A892-9B859109A714@bluewave.im> <0ED16228-CB7C-409B-9A10-92AB741F3EAA@bluewave.im> Message-ID: Problem was resolved by using sylvain/pending. Also nanoBTS does OML sync with this branch. Thanks guys Stuart On 11 Apr 2010, at 13:19, Stuart Baggs wrote: > Hi Sylvain > > Debug log is here: > > root at gateway:~/openbsc/openbsc/src# bsc_hack -d DINP:DNM:DRSL:DRR:DMM:DCC:DRLL:DMNCC:DSMS:DPAG,0:0:0 > DB: Database initialized. > DB: Database prepared. > <000d> input/ipaccess.c:515 accept()ed new OML link from 192.168.1.85 > <000d> input/ipaccess.c:232 Identified BTS 0/0/0 > <0005> bsc_init.c:735 bootstrapping OML for BTS 0 > <0005> abis_nm.c:545 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) > <0005> abis_nm.c:545 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:545 OC=GPRS NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:545 OC=GPRS CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked > <0005> abis_nm.c:545 OC=SITE MANAGER(00) INST=(ff,ff,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:545 OC=SITE MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:545 OC=SITE MANAGER(00) INST=(ff,ff,ff) Sending OPSTART > <0005> abis_nm.c:545 OC=SITE MANAGER(00) INST=(ff,ff,ff) Software Activated Report > <0005> abis_nm.c:545 OC=BTS(01) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:545 OC=GPRS NSE(f0) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:545 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1783 Set BTS Attr (bts=0) > <0005> abis_nm.c:545 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART > <0005> abis_nm.c:545 OC=BTS(01) INST=(00,ff,ff) Software Activated Report > <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:545 OC=GPRS NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:545 OC=GPRS NSE(f0) INST=(00,ff,ff) Software Activated Report > <0005> abis_nm.c:545 OC=GPRS CELL(f1) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,01,ff) SW Activate Request: <0005> abis_nm.c:865 Software Activate Request, ACKing and Activating > <0005> abis_nm.c:880 Found SW config: 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 30 39 62 32 34 64 30 00 > <0005> abis_nm.c:545 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report > <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Sending OPSTART > <0005> abis_nm.c:2854 ip.access RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=0) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=1) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=2) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,02) Sending OPSTART > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=3) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,03) Sending OPSTART > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=4) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,04) Sending OPSTART > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=5) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,05) Sending OPSTART > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=6) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,06) Sending OPSTART > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1958 Set Chan Attr (bts=0,trx=0,ts=7) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,07) Sending OPSTART > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,00) Software Activated Report > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,01) Software Activated Report > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,02) Software Activated Report > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,03) Software Activated Report > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,04) Software Activated Report > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,05) Software Activated Report > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,06) Software Activated Report > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,07) Software Activated Report > <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) Software Activated Report > <0005> abis_nm.c:1800 Set TRX Attr (bts=0,trx=0) > <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) Sending OPSTART > <0005> abis_nm.c:545 OC=GPRS CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:545 OC=GPRS CELL(f1) INST=(00,00,ff) Software Activated Report > <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,00,ff) Software Activated Report > <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:545 OC=GPRS NSVC(f2) INST=(00,01,ff) Software Activated Report > <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xe1): RSL CONNECT ACK IP=192.168.1.50 PORT=3003 STREAM=0x00 > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked > <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) ADM=Unlocked > <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) Sending OPSTART > <000d> input/ipaccess.c:573 accept()ed new RSL link from 192.168.1.85 > <000d> input/ipaccess.c:232 Identified BTS 0/0/0 > <0005> abis_nm.c:545 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Failure Event Report Type=communication failure Severity=failure ceased > <0005> abis_nm.c:545 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:545 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:545 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0004> bsc_init.c:896 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 870 using MCC=234 MNC=18 LAC=1 CID=0 BSIC=63 TSC=7 > <0003> bsc_init.c:798 SI 1: 55 06 19 8f b3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e5 04 00 2b > <0003> bsc_init.c:798 SI 2: 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00 > <0003> bsc_init.c:798 SI 3: 49 06 1b 00 00 32 f4 81 00 01 41 03 00 22 5d 00 e5 04 00 3b 2b 2b 2b > <0003> bsc_init.c:798 SI 4: 31 06 1c 32 f4 81 00 01 5d 00 e5 04 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b > <0003> bsc_init.c:815 SI 5: 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > <0003> bsc_init.c:822 SI 6: 2d 06 1e 00 00 32 f4 81 00 01 22 ff > <0004> abis_rsl.c:1157 (bts=0,trx=0,ts=2,ss=0) Activating ARFCN(870) SS(0) lctype TCH/F r=OTHER ra=0xeb > <0004> abis_rsl.c:963 (bts=0,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 ESTABLISH INDICATION > <0002> gsm_04_08.c:613 <- CM SERVICE REQUEST serv_type=0x08 mi_type=0x04 M(1758515149) > <0002> gsm_04_08.c:564 -> CM SERVICE ACK > <0001> gsm_04_08_utils.c:76 (bts 0 trx 0 ts 2 pd 05) Sending 0x21 to MS. > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION > <0003> gsm_04_08.c:823 CLASSMARK CHANGE CM2(len=3) CM3(len=4) > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION > <0002> ussd.c:57 Unhandled USSD *101*234*18*353645019793200*000 > <0001> gsm_04_08_utils.c:76 (bts 0 trx 0 ts 2 pd 8b) Sending 0x2a to MS. > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION > <0002> gsm_04_08.c:613 <- CM SERVICE REQUEST serv_type=0x01 mi_type=0x04 M(1758515149) > <0002> gsm_04_08.c:564 -> CM SERVICE ACK > <0001> gsm_04_08_utils.c:76 (bts 0 trx 0 ts 2 pd 05) Sending 0x21 to MS. > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION > <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 2 ti 8 sub 4444) Received 'SETUP' from MS in state 0 (NULL) > <0001> gsm_04_08.c:2822 Unknown transaction ID 8, creating new trans. > <0001> transaction.c:69 subscr=0x883fae8, subscr->net=0x87daf20 > <0001> gsm_04_08.c:1011 new state NULL -> INITIATED > <0001> gsm_04_08.c:1511 Subscriber 234180000035836 (4444) sends SETUP to 6666 > <0001> gsm_04_08.c:1071 (bts 0 trx 0 ts 2 ti 8 sub 4444) Sending 'MNCC_SETUP_IND' to MNCC. > <0006> mncc.c:386 (call 80000001) Call created. > <0006> mncc.c:395 (call 80000001) Received message MNCC_SETUP_IND > <0006> mncc.c:176 (call 80000001) Creating new remote instance 1. > <0006> mncc.c:186 (call 80000001) Modify channel mode. > <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 2 ti 08 sub 4444) Received 'MNCC_LCHAN_MODIFY' from MNCC in state 1 (INITIATED) > <0003> gsm_04_08_utils.c:465 -> CHANNEL MODE MODIFY mode=0x21 > <0001> gsm_04_08_utils.c:76 (bts 0 trx 0 ts 2 pd 06) Sending 0x10 to MS. > <0006> mncc.c:192 (call 80000001) Accepting call. > <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 2 ti 08 sub 4444) Received 'MNCC_CALL_PROC_REQ' from MNCC in state 1 (INITIATED) > <0001> gsm_04_08.c:1011 new state INITIATED -> MO_CALL_PROC > <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 2 ti 80) Sending 'CALL_PROC' to MS. > <0006> mncc.c:199 (call 80000001) Forwarding SETUP to remote. > <0001> transaction.c:69 subscr=0x88424e8, subscr->net=0x87daf20 > <0008> paging.c:235 Start paging of subscriber 16 on bts 0. > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION > <0003> gsm_04_08_utils.c:515 CHANNEL MODE MODIFY ACK > <0004> abis_rsl.c:1433 (bts=0,trx=0,ts=2,ss=0) IPAC_BIND speech_mode=0x11 > <0004> abis_rsl.c:988 (bts=0,trx=0,ts=2,ss=0) CHANNEL MODE MODIFY ACK > <0004> abis_rsl.c:1610 (bts=0,trx=0,ts=2,ss=0) IPAC_CRCX_ACK LOCAL_IP=192.168.1.85 LOCAL_PORT=4016 CON_ID=24 RTP_PAYLOAD2=0x6f > <0008> paging.c:94 Going to send paging commands: imsi: '234180000035787' tmsi: '0x465a6689' > <0004> abis_rsl.c:1157 (bts=0,trx=0,ts=3,ss=0) Activating ARFCN(870) SS(0) lctype TCH/F r=PAGING ra=0x2c > <0004> abis_rsl.c:963 (bts=0,trx=0,ts=3,ss=0) CHANNEL ACTIVATE ACK > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=3,ss=0) SAPI=0 ESTABLISH INDICATION > <0003> gsm_04_08.c:787 PAGING RESPONSE: mi_type=0x04 MI(1180329609) > <0003> gsm_04_08.c:805 <- Channel was requested by 234180000035787 > <0008> paging.c:299 Stop paging on bts 0, calling cbfn. > <0001> gsm_04_08.c:1153 Paging subscr 6666 succeeded! > <0001> gsm_04_08.c:1434 starting timer T303 with 30 seconds > <0001> gsm_04_08.c:1011 new state NULL -> CALL_PRESENT > <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 3 ti 00) Sending 'SETUP' to MS. > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=3,ss=0) SAPI=0 DATA INDICATION > <0003> gsm_04_08.c:823 CLASSMARK CHANGE CM2(len=3) CM3(len=7) > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=3,ss=0) SAPI=0 DATA INDICATION > <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 3 ti 0 sub 6666) Received 'CALL_CONF' from MS in state 6 (CALL_PRESENT) > <0001> gsm_04_08.c:1052 stopping pending timer T303 > <0001> gsm_04_08.c:1434 starting timer T310 with 180 seconds > <0001> gsm_04_08.c:1011 new state CALL_PRESENT -> MO_TERM_CALL_CONF > <0001> gsm_04_08.c:1071 (bts 0 trx 0 ts 3 ti 0 sub 6666) Sending 'MNCC_CALL_CONF_IND' to MNCC. > <0006> mncc.c:395 (call 1) Received message MNCC_CALL_CONF_IND > <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 3 ti 00 sub 6666) Received 'MNCC_LCHAN_MODIFY' from MNCC in state 9 (MO_TERM_CALL_CONF) > <0003> gsm_04_08_utils.c:465 -> CHANNEL MODE MODIFY mode=0x21 > <0001> gsm_04_08_utils.c:76 (bts 0 trx 0 ts 3 pd 06) Sending 0x10 to MS. > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=3,ss=0) SAPI=0 DATA INDICATION > <0003> gsm_04_08_utils.c:515 CHANNEL MODE MODIFY ACK > <0004> abis_rsl.c:1433 (bts=0,trx=0,ts=3,ss=0) IPAC_BIND speech_mode=0x11 > <0004> abis_rsl.c:988 (bts=0,trx=0,ts=3,ss=0) CHANNEL MODE MODIFY ACK > <0004> abis_rsl.c:1610 (bts=0,trx=0,ts=3,ss=0) IPAC_CRCX_ACK LOCAL_IP=192.168.1.85 LOCAL_PORT=4018 CON_ID=25 RTP_PAYLOAD2=0x70 > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=3,ss=0) SAPI=0 DATA INDICATION > <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 3 ti 0 sub 6666) Received 'ALERTING' from MS in state 9 (MO_TERM_CALL_CONF) > <0001> gsm_04_08.c:1052 stopping pending timer T310 > <0001> gsm_04_08.c:1434 starting timer T301 with 180 seconds > <0001> gsm_04_08.c:1011 new state MO_TERM_CALL_CONF -> CALL_RECEIVED > <0001> gsm_04_08.c:1071 (bts 0 trx 0 ts 3 ti 0 sub 6666) Sending 'MNCC_ALERT_IND' to MNCC. > <0006> mncc.c:395 (call 1) Received message MNCC_ALERT_IND > <0006> mncc.c:217 (call 1) Forwarding ALERT to remote. > <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 2 ti 08 sub 4444) Received 'MNCC_ALERT_REQ' from MNCC in state 3 (MO_CALL_PROC) > <0001> gsm_04_08.c:1011 new state MO_CALL_PROC -> CALL_DELIVERED > <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 2 ti 80) Sending 'ALERTING' to MS. > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=3,ss=0) SAPI=0 DATA INDICATION > <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 3 ti 0 sub 6666) Received 'CONNECT' from MS in state 7 (CALL_RECEIVED) > <0001> gsm_04_08.c:1052 stopping pending timer T301 > <0001> gsm_04_08.c:1011 new state CALL_RECEIVED -> CONNECT_REQUEST > <0001> gsm_04_08.c:1071 (bts 0 trx 0 ts 3 ti 0 sub 6666) Sending 'MNCC_SETUP_CNF' to MNCC. > <0006> mncc.c:395 (call 1) Received message MNCC_SETUP_CNF > <0006> mncc.c:245 (call 1) Acknowledge SETUP. > <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 3 ti 00 sub 6666) Received 'MNCC_SETUP_COMPL_REQ' from MNCC in state 8 (CONNECT_REQUEST) > <0001> gsm_04_08.c:1011 new state CONNECT_REQUEST -> ACTIVE > <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 3 ti 00) Sending 'CONNECT_ACK' to MS. > <0006> mncc.c:252 (call 1) Sending CONNECT to remote. > <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 2 ti 08 sub 4444) Received 'MNCC_SETUP_RSP' from MNCC in state 4 (CALL_DELIVERED) > <0001> gsm_04_08.c:1434 starting timer T313 with 30 seconds > <0001> gsm_04_08.c:1011 new state CALL_DELIVERED -> CONNECT_IND > <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 2 ti 80) Sending 'CONNECT' to MS. > <0006> mncc.c:258 (call 1) Bridging with remote. > <0001> gsm_04_08.c:1222 Setting up TCH map between (bts=0,trx=0,ts=3) and (bts=0,trx=0,ts=2) > <0004> abis_rsl.c:1464 (bts=0,trx=0,ts=3,ss=0) IPAC_MDCX IP=192.168.1.85 PORT=4016 RTP_PAYLOAD2=111 CONN_ID=25 speech_mode=0x01 > <0004> abis_rsl.c:1464 (bts=0,trx=0,ts=2,ss=0) IPAC_MDCX IP=192.168.1.85 PORT=4018 RTP_PAYLOAD2=111 CONN_ID=24 speech_mode=0x01 > <0004> abis_rsl.c:1620 (bts=0,trx=0,ts=3,ss=0) IPAC_MDCX_ACK CON_ID=25 > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION > <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 2 ti 8 sub 4444) Received 'CONNECT_ACK' from MS in state 28 (CONNECT_IND) > <0001> gsm_04_08.c:1052 stopping pending timer T313 > <0001> gsm_04_08.c:1011 new state CONNECT_IND -> ACTIVE > <0001> gsm_04_08.c:1071 (bts 0 trx 0 ts 2 ti 8 sub 4444) Sending 'MNCC_SETUP_COMPL_IND' to MNCC. > <0006> mncc.c:395 (call 80000001) Received message MNCC_SETUP_COMPL_IND > <0004> abis_rsl.c:1620 (bts=0,trx=0,ts=2,ss=0) IPAC_MDCX_ACK CON_ID=24 > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION > <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 2 ti 8 sub 4444) Received 'DISCONNECT' from MS in state 10 (ACTIVE) > <0001> gsm_04_08.c:1011 new state ACTIVE -> DISCONNECT_IND > <0001> gsm_04_08.c:1071 (bts 0 trx 0 ts 2 ti 8 sub 4444) Sending 'MNCC_DISC_IND' to MNCC. > <0006> mncc.c:395 (call 80000001) Received message MNCC_DISC_IND > <0006> mncc.c:288 (call 80000001) Releasing call with cause 16 > <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 2 ti 08 sub 4444) Received 'MNCC_REL_REQ' from MNCC in state 12 (DISCONNECT_IND) > <0001> gsm_04_08.c:1434 starting timer T308 with 10 seconds > <0001> gsm_04_08.c:1011 new state DISCONNECT_IND -> RELEASE_REQ > <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 2 ti 80) Sending 'RELEASE' to MS. > <0006> mncc.c:297 (call 1) Disconnecting remote with cause 16 > <0001> gsm_04_08.c:2723 (bts 0 trx 0 ts 3 ti 00 sub 6666) Received 'MNCC_DISC_REQ' from MNCC in state 10 (ACTIVE) > <0001> gsm_04_08.c:1434 starting timer T306 with 30 seconds > <0001> gsm_04_08.c:1011 new state ACTIVE -> DISCONNECT_IND > <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 3 ti 00) Sending 'DISCONNECT' to MS. > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION > <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 2 ti 8 sub 4444) Received 'RELEASE_COMPL' from MS in state 19 (RELEASE_REQ) > <0001> gsm_04_08.c:1052 stopping pending timer T308 > <0001> gsm_04_08.c:1011 new state RELEASE_REQ -> NULL > <0000> abis_rsl.c:1262 (bts=0,trx=0,ts=3,ss=0) SAPI=0 DATA INDICATION > <0001> gsm_04_08.c:2817 (bts 0 trx 0 ts 3 ti 0 sub 6666) Received 'RELEASE' from MS in state 12 (DISCONNECT_IND) > <0001> gsm_04_08.c:1052 stopping pending timer T306 > <0001> gsm_04_08_utils.c:71 (bts 0 trx 0 ts 3 ti 00) Sending 'RELEASE_COMPL' to MS. > <0001> gsm_04_08.c:1071 (bts 0 trx 0 ts 3 ti 0 sub 6666) Sending 'MNCC_REL_IND' to MNCC. > <0001> gsm_04_08.c:1011 new state DISCONNECT_IND -> NULL > <0006> mncc.c:395 (call 1) Received message MNCC_REL_IND > <0006> mncc.c:312 (call 1) Releasing remote with cause 0 > <0001> gsm_04_08.c:2610 (bts - trx - ts - ti -- sub ) Received 'MNCC_REL_REQ' from MNCC with unknown callref -2147483647 > <0001> gsm_04_08.c:1079 (bts - trx - ts - ti -- sub -) Sending 'MNCC_REL_IND' to MNCC. > <0006> mncc.c:111 (call 1) Call removed. > <0006> mncc.c:395 (call 80000001) Received message MNCC_REL_IND > <0006> mncc.c:111 (call 80000001) Call removed. > > Screen shots are here: http://www.bluewave.im/images/ipaccess/bts-installer.jpg http://www.bluewave.im/images/ipaccess/bts-http1.jpg > > Thanks Stuart > > On 11 Apr 2010, at 13:06, Sylvain Munaut wrote: > >> On Sun, Apr 11, 2010 at 1:59 PM, Stuart Baggs wrote: >>> No SSL cert required here, just type the nanoBTS ip into your browser over standard HTTP. Brings up a link to two pages showing NVRAM settings. >> >> mmm, can you post them (screenshots or something ?) >> Maybe there is a flag to disable that security ... >> >> >>> Yes, if you reverse roles of the handsets it stays the same i.e. the called party can never here the caller. >> >> Post a full debug log on pastbin.ca or similar. >> >> bsc_hack -d DINP:DNM:DRSL:DRR:DMM:DCC:DRLL:DMNCC:DSMS:DPAG,0:0:0 >> >> Sylvain >> > > > From stuart at bluewave.im Sun Apr 11 12:01:54 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sun, 11 Apr 2010 13:01:54 +0100 Subject: One Way Audio nano-bts In-Reply-To: References: <9910631F-FEDF-4CDC-A224-1BBEE067B866@bluewave.im> <201004101829.57170.zecke@selfish.org> <96E0AB97-941D-4829-A334-C459C6F32CE3@bluewave.im> <0C8E575C-9FA4-49A8-A892-9B859109A714@bluewave.im> Message-ID: <9AAAD98A-581F-4BE5-8B35-1BE2061C70EA@bluewave.im> Also on the SMS front I get this error: <0007> gsm_04_11.c:784 234180000035836: RX SMS RP-ERROR, cause 1:22 ((MT) Memory Exceeded) One mobile is an iPhone with unlimited handset SMS memory (well 16GB anyway) and the other has 2 texts stored on the entire phone. Stuart On 11 Apr 2010, at 12:55, Sylvain Munaut wrote: > On Sun, Apr 11, 2010 at 1:51 PM, Stuart Baggs wrote: >> Yes, I have a copy of the ip.access nanoBTS installer software for windows. You simply enable it in the NVRAM settings. > > I enabled it but it apperently needs a client HTTP SSL certificate. > Can you set it as well with the intaller software ? > > For you issue: > * what's you sw version exactly ? > * if you reverse the role of caller / callee, does it reverse who can > hear who ? (to know if it's a direction problem or a handset problem) > > Sylvain > > From stuart at bluewave.im Sun Apr 11 18:19:08 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sun, 11 Apr 2010 19:19:08 +0100 Subject: Command Line SMS Message-ID: <4125A384-B66E-4ACE-8183-904942D398E1@bluewave.im> Hi, I am struggling to understand the syntax of the command line SMS tool. I have tried subscriber 4444 EXTEN sms send .LINE subscriber 4444 sms send .LINE subscriber 4444 sms send test sms But im getting unknown command. Can someone please let me know the correct syntax. Thanks From zecke at selfish.org Sun Apr 11 19:51:44 2010 From: zecke at selfish.org (Holger Freyther) Date: Sun, 11 Apr 2010 21:51:44 +0200 Subject: Command Line SMS In-Reply-To: <4125A384-B66E-4ACE-8183-904942D398E1@bluewave.im> References: <4125A384-B66E-4ACE-8183-904942D398E1@bluewave.im> Message-ID: <201004112151.44965.zecke@selfish.org> On Sunday 11 April 2010 20:19:08 Stuart Baggs wrote: > Hi, I am struggling to understand the syntax of the command line SMS tool. > > I have tried > > subscriber 4444 EXTEN sms send .LINE > subscriber 4444 sms send .LINE > subscriber 4444 sms send test sms > > But im getting unknown command. Can someone please let me know the correct > syntax. Thanks Hi again, I have changed http://openbsc.gnumonks.org/trac/wiki/bsc_hack_VTY to have a list of some useful comments. It would be nice if you could extend the wiki with other commands you have found. z. From stuart at bluewave.im Sun Apr 11 19:56:30 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sun, 11 Apr 2010 20:56:30 +0100 Subject: Command Line SMS In-Reply-To: <201004112151.44965.zecke@selfish.org> References: <4125A384-B66E-4ACE-8183-904942D398E1@bluewave.im> <201004112151.44965.zecke@selfish.org> Message-ID: Thanks, that worked a treat! On 11 Apr 2010, at 20:51, Holger Freyther wrote: > On Sunday 11 April 2010 20:19:08 Stuart Baggs wrote: >> Hi, I am struggling to understand the syntax of the command line SMS tool. >> >> I have tried >> >> subscriber 4444 EXTEN sms send .LINE >> subscriber 4444 sms send .LINE >> subscriber 4444 sms send test sms >> >> But im getting unknown command. Can someone please let me know the correct >> syntax. Thanks > > Hi again, > > I have changed http://openbsc.gnumonks.org/trac/wiki/bsc_hack_VTY to have a > list of some useful comments. It would be nice if you could extend the wiki > with other commands you have found. > > z. > > From stuart at bluewave.im Mon Apr 12 17:44:27 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Mon, 12 Apr 2010 18:44:27 +0100 Subject: Pending Branch Message-ID: Hi guys, I am trying to find the sylvain/pending branch of OpenBSC but I can only find: 0.9.0 on-waves/0.1 on-waves/0.2 on-waves/0.3 on-waves/0.3.1 on-waves/0.3.2 on-waves/0.3.3 on-waves/0.3.4 on-waves/0.3.91 on-waves/0.3.92 on-waves/0.3.93 on-waves/0.3.94 on-waves/0.3.95 on-waves/0.3.96 Does anyone have the list to the git repository that has the pending branches? Thanks Stuart From zecke at selfish.org Tue Apr 13 05:06:47 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 13 Apr 2010 07:06:47 +0200 Subject: Pending Branch In-Reply-To: References: Message-ID: <201004130706.47944.zecke@selfish.org> On Monday 12 April 2010 19:44:27 Stuart Baggs wrote: > Hi guys, I am trying to find the sylvain/pending branch of OpenBSC but I > can only find: My usual hint on verbosity applies here again. Which command did you use to determine the branches available to you? From stuart at bluewave.im Tue Apr 13 08:15:00 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Tue, 13 Apr 2010 09:15:00 +0100 Subject: Pending Branch In-Reply-To: <201004130706.47944.zecke@selfish.org> References: <201004130706.47944.zecke@selfish.org> Message-ID: Using git branch shows only master and git tag shows: 0.9.0 on-waves/0.1 on-waves/0.2 on-waves/0.3 on-waves/0.3.1 on-waves/0.3.2 on-waves/0.3.3 on-waves/0.3.4 on-waves/0.3.91 on-waves/0.3.92 on-waves/0.3.93 on-waves/0.3.94 on-waves/0.3.95 on-waves/0.3.96 On 13 Apr 2010, at 06:06, Holger Freyther wrote: > On Monday 12 April 2010 19:44:27 Stuart Baggs wrote: >> Hi guys, I am trying to find the sylvain/pending branch of OpenBSC but I >> can only find: > > My usual hint on verbosity applies here again. Which command did you use to > determine the branches available to you? > > > From zecke at selfish.org Tue Apr 13 08:37:17 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 13 Apr 2010 10:37:17 +0200 Subject: Pending Branch In-Reply-To: References: <201004130706.47944.zecke@selfish.org> Message-ID: <201004131037.17828.zecke@selfish.org> On Tuesday 13 April 2010 10:15:00 Stuart Baggs wrote: > Using git branch shows only master and git tag shows: Did you consider typing git branch --help? By default git branch only shows local branches (created by yourself), if you want to see more, you will have to ask to see more. From amed.et at hotmail.com Tue Apr 13 15:52:36 2010 From: amed.et at hotmail.com (amed et) Date: Tue, 13 Apr 2010 15:52:36 +0000 Subject: still searching for a Siemens BTS BS11 device Message-ID: Hello readers, I am still searching for the cheaper hardware openbsc in supporting --> which is the Siemens BTS Bs 11 Can any body give me a hint where to find such great piece of hardware ? I am very interested in testing this project. since its exactly what i study at the university :), I couldnt really find anything in google regarding sellers. I am just interested in one device. So any info's or adresse's will be just great. Thanks folks amed _________________________________________________________________ http://redirect.gimas.net/?n=M1004xNoSpam2_WW Angst vor Spam? Hotmail sch?tzt Sie mit modernster Technologie! -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Apr 13 22:49:46 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 14 Apr 2010 00:49:46 +0200 Subject: Introductory text on typical GSM phone hardware Message-ID: <20100413224946.GJ28773@prithivi.gnumonks.org> Hi! While working on OsmocomBB, I wrote a small introductory text explaining how current GSM phone hardware actually looks like (and works). You can download it from http://laforge.gnumonks.org/papers/gsm_phone-anatomy-v0.2.pdf Hope this is useful for one or the other person here on this list... 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 laforge at gnumonks.org Wed Apr 14 21:48:22 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 14 Apr 2010 23:48:22 +0200 Subject: Proposed OpenBSC application interface Message-ID: <20100414214822.GE7381@prithivi.gnumonks.org> Hi! Collin Mulliner, Tobias Engel and myself have been meeting yesterday to discuss a generic application interface for OpenBSC. They are both doing security analysis and want to achieve a clean way how an external application can get access to a more or less transparent communication channel to the phone. The purpose of this is to be able to send intentionally malformed packets to the mobile phone GSM stack at various different levels within the stack. As of now, they have both hacked some custom code into openbsc that gets them half way where they want to be - but not quite all the way. The requirements can be summarized as follows: 1) Ability to establish a SDCCH or TCH channel by paging the phone As of now, the 'silent call' feature from the VTY already does this. 2) Ability to send arbitrary layer3 protocol messages to the phone Adding this is relatively easy (use rsl_sendmsg on the lchan from the silent call) 3) Ability to receive responses from the phone, as well as error conditions such as 'readio link failure'. We don't have a solution for this yet, and we also have no clean way to identify what might be a response from the phone to the external app, and what might be a message from the phone to the normal network code in OpenBSC 4) Ability to selectively disable partial protocol handling in OpenBSC. Let's say you want to play with the mobile phone call control implementation. In this case, you want to make sure all CC related messages go from/to the external program and not from the regular OpenBSC network code. So what I've been thinking of as a solution to the problem: * store a bypass_flags bitmask related to the subscriber structure, where we indicate values such as BYPASS_RR, BYPASS_MM, BYPASS_CC, BYPASS_SAPI3. * if we process an incoming message from the MS in gsm0408_rcvmsg(), we check if a bypass flag matching the message is found. If yes, forward the message to the external program * if we want to send a message from our own protocol stack to the MS, we check if a bypass flag matching the message is found. If yes, we drop the message that we were about to send. * any messages received from the application will be forwarded to the MS The application interface protocol will likely have a close resemblance to RSL RLL. We need to exchange the following primitives with the application, like: * ESTABLISH REQUEST -- app requests a channel be established to MS (by IMSI) * ESTABLISH CONFIRM -- network confirms a channel has been established * ESTABLISH INDICATION -- network tells app connection was made by MS * [UNIT] DATA REQUEST -- app requests data to be sent to MS * [UNIT] DATA INDICATION -- network indicates data was received from MS * ERROR INDICATION -- network tells app something went wrong * RELEASE REQUEST -- app asks network to release channel * RELEASE CONFIRM -- net tells app that channel was released (as rqd) * RELEASE INDICATION -- net tells app that channel was released (by MS) The channel_number of RSL (indicating on-air timeslot) doesn't make much sense in this context, of course. The link_identifier on the other hand is great as it allows the app to indicate SDCCH/FACCH or SACCH as well as the SAPI. The actual RSL-like protocol would be encapsulated by UDP and available on a socket of the MSC. 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 zecke at selfish.org Thu Apr 15 00:53:02 2010 From: zecke at selfish.org (Holger Freyther) Date: Thu, 15 Apr 2010 02:53:02 +0200 Subject: Proposed OpenBSC application interface In-Reply-To: <20100414214822.GE7381@prithivi.gnumonks.org> References: <20100414214822.GE7381@prithivi.gnumonks.org> Message-ID: <201004150253.03162.zecke@selfish.org> On Wednesday 14 April 2010 23:48:22 Harald Welte wrote: > Hi! > > Collin Mulliner, Tobias Engel and myself have been meeting yesterday to > discuss a generic application interface for OpenBSC. very nice. > > They are both doing security analysis and want to achieve a clean way > how an external application can get access to a more or less transparent > communication channel to the phone. > > The purpose of this is to be able to send intentionally malformed > packets to the mobile phone GSM stack at various different levels within > the stack. Let me answer to your question from the bottom. If our only goal is to send malformed packets to the MS I think this interface is way too low level and for now all requirements can be handled by basic GSM08.08 messages. > 1) Ability to establish a SDCCH or TCH channel by paging the phone > As of now, the 'silent call' feature from the VTY already does this. GSM08.08 Paging Request which will be answered with a GSM08.08 Complete Layer3 Information (a new connection) > > 2) Ability to send arbitrary layer3 protocol messages to the phone > Adding this is relatively easy (use rsl_sendmsg on the lchan from the > silent call) GSM08.08 DTAP > > 3) Ability to receive responses from the phone, as well as error > conditions such as 'readio link failure'. We don't have a solution > for this yet, and we also have no clean way to identify what might > be a response from the phone to the external app, and what might > be a message from the phone to the normal network code in OpenBSC GSM08.08 DTAP and GSM08.08 Cleanup Request (Error Cause Radio Link Failure) > So what I've been thinking of as a solution to the problem: > > * store a bypass_flags bitmask related to the subscriber structure, > where we indicate values such as BYPASS_RR, BYPASS_MM, BYPASS_CC, > BYPASS_SAPI3. That sounds easy so far. We could easily extend it to MSG type in the future. From laforge at gnumonks.org Thu Apr 15 13:24:47 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 15 Apr 2010 15:24:47 +0200 Subject: Proposed OpenBSC application interface In-Reply-To: <201004150253.03162.zecke@selfish.org> References: <20100414214822.GE7381@prithivi.gnumonks.org> <201004150253.03162.zecke@selfish.org> Message-ID: <20100415132447.GG18200@prithivi.gnumonks.org> Hi Zecke, On Thu, Apr 15, 2010 at 02:53:02AM +0200, Holger Freyther wrote: > > They are both doing security analysis and want to achieve a clean way > > how an external application can get access to a more or less transparent > > communication channel to the phone. > > > > The purpose of this is to be able to send intentionally malformed > > packets to the mobile phone GSM stack at various different levels within > > the stack. > > Let me answer to your question from the bottom. If our only goal is to send > malformed packets to the MS I think this interface is way too low level and > for now all requirements can be handled by basic GSM08.08 messages. what do you mean by 'low level'? Their intent really is to send arbitrary L3 messages in L2, even on strange SAPIs or on an unexpected logical channel (SACCH vs. SDCCH). > > 1) Ability to establish a SDCCH or TCH channel by paging the phone > > As of now, the 'silent call' feature from the VTY already does this. > > GSM08.08 Paging Request which will be answered with a GSM08.08 Complete Layer3 > Information (a new connection) true. > > 2) Ability to send arbitrary layer3 protocol messages to the phone > > Adding this is relatively easy (use rsl_sendmsg on the lchan from the > > silent call) > > GSM08.08 DTAP true. > > 3) Ability to receive responses from the phone, as well as error > > conditions such as 'readio link failure'. We don't have a solution > > for this yet, and we also have no clean way to identify what might > > be a response from the phone to the external app, and what might > > be a message from the phone to the normal network code in OpenBSC > > GSM08.08 DTAP and GSM08.08 Cleanup Request (Error Cause Radio Link Failure) true. However, the MSC talks GSM 08.08 to the BSC. So are you proposing of having a 08.08 interface between APP and MSC, or to have a BSC with multiple 08.08 interfaces? After all, in almost all the use cases we still want the regular MSC around for things like location updating, authentication, etc. The other question then is: Why 08.08? Wouldn't the logical consequence be to implement actual MAP (like the E interface between MSC and MSC in a real gsm network)? 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 zecke at selfish.org Thu Apr 15 13:43:18 2010 From: zecke at selfish.org (Holger Freyther) Date: Thu, 15 Apr 2010 15:43:18 +0200 Subject: Proposed OpenBSC application interface In-Reply-To: <20100415132447.GG18200@prithivi.gnumonks.org> References: <20100414214822.GE7381@prithivi.gnumonks.org> <201004150253.03162.zecke@selfish.org> <20100415132447.GG18200@prithivi.gnumonks.org> Message-ID: <201004151543.19300.zecke@selfish.org> On Thursday 15 April 2010 15:24:47 Harald Welte wrote: Mahlzeit LaF0rge, > > Let me answer to your question from the bottom. If our only goal is to > > send malformed packets to the MS I think this interface is way too low > > level and for now all requirements can be handled by basic GSM08.08 > > messages. > > what do you mean by 'low level'? Their intent really is to send > arbitrary L3 messages in L2, even on strange SAPIs or on an unexpected > logical channel (SACCH vs. SDCCH). When looking at your proposed RSL like messages I was able (at least I thought/think so) to map it 1:1 to GSM0808 primitives and then had the feeling to implement most of GSM0808 at a lower level. > However, the MSC talks GSM 08.08 to the BSC. So are you proposing of > having a 08.08 interface between APP and MSC, or to have a BSC with > multiple 08.08 interfaces? After all, in almost all the use cases we > still want the regular MSC around for things like location updating, > authentication, etc. I had a bypass on the MSC in mind. E.g. one would send a PAGING REQUEST messages to the MSC, it would be forwarded to the BSC, then we would get a Complete Layer3 Information with the CM Service Request and then we could decide that for the type of XYZ, we want to hand out this communication to another app (okay, I made the CM Service Request up and didn't have that in mind today morning). > > The other question then is: Why 08.08? Wouldn't the logical consequence > be to implement actual MAP (like the E interface between MSC and MSC in > a real gsm network)? Good point, I have no idea about the protocol and the way it is working. My reason to propose GSM0808 as interface was twofold. We do have code to create and parse messages right now, and I think we can handle the use cases you have described with it (including using a custom link id and requesting weird channels) which would lead to a fast result for one of the primary use cases of OpenBSC (enable research). regards holger From laforge at gnumonks.org Sat Apr 17 10:23:43 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 17 Apr 2010 12:23:43 +0200 Subject: Proposed OpenBSC application interface In-Reply-To: <201004151543.19300.zecke@selfish.org> References: <20100414214822.GE7381@prithivi.gnumonks.org> <201004150253.03162.zecke@selfish.org> <20100415132447.GG18200@prithivi.gnumonks.org> <201004151543.19300.zecke@selfish.org> Message-ID: <20100417102343.GW18200@prithivi.gnumonks.org> On Thu, Apr 15, 2010 at 03:43:18PM +0200, Holger Freyther wrote: > > what do you mean by 'low level'? Their intent really is to send > > arbitrary L3 messages in L2, even on strange SAPIs or on an unexpected > > logical channel (SACCH vs. SDCCH). > > When looking at your proposed RSL like messages I was able (at least I > thought/think so) to map it 1:1 to GSM0808 primitives and then had the feeling > to implement most of GSM0808 at a lower level. I agree it's a lower level in the network hierarchy, but not really a lower level in the protocol stack... both interfaces facilitate the establishment and communication via layer2. It might be the case that since paging / response is included in 08.08, we have a little bit less extra (non-standard) work than with the RSL approach. > I had a bypass on the MSC in mind. E.g. one would send a PAGING REQUEST > messages to the MSC, it would be forwarded to the BSC, then we would get a > Complete Layer3 Information with the CM Service Request and then we could > decide that for the type of XYZ, we want to hand out this communication to > another app (okay, I made the CM Service Request up and didn't have that in > mind today morning). What I'm wondering about is: Do we really get the full power/control if we want it? Isn't the RR always handled in the BSC with no way around and only MM/CC/SMS/SS forwarded to the MSC on 08.08? > > The other question then is: Why 08.08? Wouldn't the logical consequence > > be to implement actual MAP (like the E interface between MSC and MSC in > > a real gsm network)? > > Good point, I have no idea about the protocol and the way it is working. I've done a careful peek at 09.01 and 09.02. While it might be flexible enough to do what we want, implementing MAP only partially is more than an entire project in itself. So I'd rather not open pandora's box as of now. Which leaves us with the RSL or the 08.08 based approach. I'm still undecided :/ -- - 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 Sat Apr 17 18:00:45 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 18 Apr 2010 02:00:45 +0800 Subject: Proposed OpenBSC application interface In-Reply-To: <20100417102343.GW18200@prithivi.gnumonks.org> References: <20100414214822.GE7381@prithivi.gnumonks.org> <201004150253.03162.zecke@selfish.org> <20100415132447.GG18200@prithivi.gnumonks.org> <201004151543.19300.zecke@selfish.org> <20100417102343.GW18200@prithivi.gnumonks.org> Message-ID: <4BC9F74D.9020700@freyther.de> On 04/17/2010 06:23 PM, Harald Welte wrote: > What I'm wondering about is: Do we really get the full power/control if > we want it? Isn't the RR always handled in the BSC with no way around > and only MM/CC/SMS/SS forwarded to the MSC on 08.08? No, we do not have the full power. There is one thing we can not do with the 08.08 approach unless we add something non standard. Right now we would not be able to submit on a SAPI that was not established yet. It might be more easy to add IEs for custom behavior than implementing everything. > Which leaves us with the RSL or the 08.08 based approach. I'm still > undecided :/ You know it is your call. :) PS: First mail with thunderbird, I hope it is not HTML... From admin at manateeshome.com Sat Apr 17 14:45:59 2010 From: admin at manateeshome.com (Seungju Kim) Date: Sat, 17 Apr 2010 23:45:59 +0900 Subject: Does anybody sell BTSs? Message-ID: Hello I am interested in buying a BS-11 or nanoBTS for testing.. I tried contacting ip.access but they demand a spectrum license...:( Does anybody have some for sale? Sent from my iPhone From zero-kelvin at gmx.de Sat Apr 17 18:14:30 2010 From: zero-kelvin at gmx.de (dexter) Date: Sat, 17 Apr 2010 20:14:30 +0200 Subject: Does anybody sell BTSs? In-Reply-To: References: Message-ID: <4BC9FA86.6040508@gmx.de> Hello Seungju Kim. > I tried contacting ip.access but they demand a spectrum license...:( Is this really a problem? What is if one has a test licence? Or do they sell only to people who can prove that they are an operator? Regards. Philipp From amed.et at hotmail.com Sat Apr 17 20:08:02 2010 From: amed.et at hotmail.com (amed et) Date: Sat, 17 Apr 2010 20:08:02 +0000 Subject: Does anybody sell BTSs? In-Reply-To: References: Message-ID: Hello, I have been searching for the BS11 for a long time, but unfortunately i didnt find any some body selling these bs11. > From: admin at manateeshome.com > To: openbsc at lists.gnumonks.org > Subject: Does anybody sell BTSs? > Date: Sat, 17 Apr 2010 23:45:59 +0900 > > Hello > I am interested in buying a BS-11 or nanoBTS for testing.. > I tried contacting ip.access but they demand a spectrum license...:( > > Does anybody have some for sale? > > Sent from my iPhone > _________________________________________________________________ http://redirect.gimas.net/?n=M1004xSkyDrive2_WW Ihre Daten brauchen Platz? SkyDrive gibt Ihnen 25 GB - gratis! -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at bluewave.im Sat Apr 17 20:39:34 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sat, 17 Apr 2010 21:39:34 +0100 Subject: Does anybody sell BTSs? In-Reply-To: References: Message-ID: Hi, I have a quantity of nanoBTS 169's available for ?2000 each. All are 1800 MHz. Thanks, Stuart On 17 Apr 2010, at 21:08, amed et wrote: > Hello, > I have been searching for the BS11 for a long time, but unfortunately i didnt find any some body selling these bs11. > > > > From: admin at manateeshome.com > > To: openbsc at lists.gnumonks.org > > Subject: Does anybody sell BTSs? > > Date: Sat, 17 Apr 2010 23:45:59 +0900 > > > > Hello > > I am interested in buying a BS-11 or nanoBTS for testing.. > > I tried contacting ip.access but they demand a spectrum license...:( > > > > Does anybody have some for sale? > > > > Sent from my iPhone > > > > Ihre Daten brauchen Platz? SkyDrive gibt Ihnen 25 GB - gratis! -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Apr 18 07:05:21 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 18 Apr 2010 09:05:21 +0200 Subject: Does anybody sell BTSs? In-Reply-To: References: Message-ID: <20100418070520.GH18200@prithivi.gnumonks.org> Hi Amed, On Sat, Apr 17, 2010 at 08:08:02PM +0000, amed et wrote: > I have been searching for the BS11 for a long time, but unfortunately i didnt > find any some body selling these bs11. There were about 70 units as leftover stock two yers ago. They have been sold over the course of a year to interested people who were observing the OpenBSC project. I am afraid they're all sold and you are too late now. However, any other Siemens BTS model should be supported fairly easily, as their protocol is supposed to be identical. So if you can get your hands on an old Siemens BTS that was in carrier use - go ahead! Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From stuart at bluewave.im Sun Apr 18 02:58:04 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sun, 18 Apr 2010 03:58:04 +0100 Subject: SMS Alpha Originator Message-ID: Hi guys I have been looking through the SMS functionality of openBSC and I can see that the HLR / SMS database uses an sender_id (a secondary key of the Subscriber database). Is it possible to send SMS messages with an alpha originator i.e. from a string of text up to 11 characters? I also noticed that using the telnet interface, the command to send a SMS does not leave a trace in the sql database. Thanks, Stuart From laforge at gnumonks.org Sun Apr 18 07:08:15 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 18 Apr 2010 09:08:15 +0200 Subject: SMS Alpha Originator In-Reply-To: References: Message-ID: <20100418070815.GI18200@prithivi.gnumonks.org> Hi Stuart, On Sun, Apr 18, 2010 at 03:58:04AM +0100, Stuart Baggs wrote: > I have been looking through the SMS functionality of openBSC and I can see > that the HLR / SMS database uses an sender_id (a secondary key of the > Subscriber database). Is it possible to send SMS messages with an alpha > originator i.e. from a string of text up to 11 characters? no, not yet. > I also noticed that using the telnet interface, the command to send a SMS > does not leave a trace in the sql database. that is indeed true and is intentional. If you want to send through the database, you can use an external program to add the SMS to the database. The whole SMS support is simply a prove-of-concept as of now. At some point we need to move it into its own SMSC application program and have a proper interface in the MSC part of OpenBSC. You're welcome to help with that implementation :) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From admin at manateeshome.com Sun Apr 18 09:40:16 2010 From: admin at manateeshome.com (Seungju Kim) Date: Sun, 18 Apr 2010 18:40:16 +0900 Subject: Ericsson RBS Message-ID: <74171030-DD07-4B4C-A1F2-09C00BE72AD2@manateeshome.com> I found some ericsson rbs's on eBay, they were being sold at much cheaper price than nanobts.. Will it be supported? Sent from my iPhone From laforge at gnumonks.org Sun Apr 18 13:08:00 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 18 Apr 2010 15:08:00 +0200 Subject: Ericsson RBS In-Reply-To: <74171030-DD07-4B4C-A1F2-09C00BE72AD2@manateeshome.com> References: <74171030-DD07-4B4C-A1F2-09C00BE72AD2@manateeshome.com> Message-ID: <20100418130800.GV18200@prithivi.gnumonks.org> On Sun, Apr 18, 2010 at 06:40:16PM +0900, Seungju Kim wrote: > I found some ericsson rbs's on eBay, they were being sold at much > cheaper price than nanobts.. Will it be supported? unfortunately those are not a complete RBS unit, but only one part (the transceiver unit). We've had that unit mentioned earlier on the list, see http://lists.gnumonks.org/pipermail/openbsc/2009-August/000734.html As you can see from the doucmentation, the units sold on eBay are only the RRU (Remote Radio Unit) but not the IXU (Interface and switching unit) The RRU is the actual radio transceiver, but the IXU is what terminates the E1/T1 A-bis link. Both units are connected over a undocumented/proprietary interface called Y-Link. So you would have to get your hands on a matching RBS 2380 IXU. Also, you need the OMT (a windows PC based software for configuration), or serial traces of that software so you can reimplement its features. Last, but not least, we have zero documentation nor any protocol traces as examples on Ericsson's A-bis dialect. I suppose we could get most features working fairly quickly, but that is just a wild guess. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From admin at manateeshome.com Sun Apr 18 09:55:12 2010 From: admin at manateeshome.com (Seungju Kim) Date: Sun, 18 Apr 2010 18:55:12 +0900 Subject: Basics Message-ID: <72D603EC-1589-4A5E-BA82-7AF744992CAF@manateeshome.com> What is the prerequisites to run a experimental gsm network? -a computer -a BTS ..and what is needed? Sent from my iPhone From laforge at gnumonks.org Sun Apr 18 12:58:36 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 18 Apr 2010 14:58:36 +0200 Subject: Basics In-Reply-To: <72D603EC-1589-4A5E-BA82-7AF744992CAF@manateeshome.com> References: <72D603EC-1589-4A5E-BA82-7AF744992CAF@manateeshome.com> Message-ID: <20100418125836.GU18200@prithivi.gnumonks.org> On Sun, Apr 18, 2010 at 06:55:12PM +0900, Seungju Kim wrote: > What is the prerequisites to run a experimental gsm network? > -a computer > -a BTS ... that speaks an A-bis dialcet supported by OpenBSC > ..and what is needed? The OpenBSC software. Depending on the BTS model, you of course also need the proper interface (E1, T1, ...) in your computer, cables, antenna, power supply (traditional telco BTS are 48V). -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sun Apr 18 20:57:09 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 18 Apr 2010 22:57:09 +0200 Subject: Experimental nanoBTS EDGE support Message-ID: <20100418205709.GC18200@prithivi.gnumonks.org> Hi! I've been working on a set of patches to enable configuring the nanoBTS to not only support GPRS but also EDGE. After some testing, I've merged them into the master branch. In order to enable EDGE, you need to use 'gprs mode egprs'. Also, you still need an external SGSN or use the gprs-sgsn branch (which has been rebased). Your phones should then show 'E' instead of 'G'. I haven't actually benchmarked the transfer speed, i.e. if it really is giving the expected performance improvement. 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 stuart at bluewave.im Sun Apr 18 21:00:37 2010 From: stuart at bluewave.im (Stuart Baggs) Date: Sun, 18 Apr 2010 22:00:37 +0100 Subject: Experimental nanoBTS EDGE support In-Reply-To: <20100418205709.GC18200@prithivi.gnumonks.org> References: <20100418205709.GC18200@prithivi.gnumonks.org> Message-ID: <2F40B161-1631-47E6-9641-2BD07CCB7A05@bluewave.im> Hi Do you know of any opensource SGSN's or are they all third party commercial offeringS? Thanks Stuart On 18 Apr 2010, at 21:57, Harald Welte wrote: > Hi! > > I've been working on a set of patches to enable configuring the nanoBTS > to not only support GPRS but also EDGE. After some testing, I've merged > them into the master branch. > > In order to enable EDGE, you need to use 'gprs mode egprs'. > > Also, you still need an external SGSN or use the gprs-sgsn branch (which has > been rebased). Your phones should then show 'E' instead of 'G'. > > I haven't actually benchmarked the transfer speed, i.e. if it really is giving > the expected performance improvement. > > 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 laforge at gnumonks.org Mon Apr 19 07:08:42 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 19 Apr 2010 09:08:42 +0200 Subject: Experimental nanoBTS EDGE support In-Reply-To: <2F40B161-1631-47E6-9641-2BD07CCB7A05@bluewave.im> References: <20100418205709.GC18200@prithivi.gnumonks.org> <2F40B161-1631-47E6-9641-2BD07CCB7A05@bluewave.im> Message-ID: <20100419070842.GE18200@prithivi.gnumonks.org> On Sun, Apr 18, 2010 at 10:00:37PM +0100, Stuart Baggs wrote: > Hi > > Do you know of any opensource SGSN's or are they all third party commercial > offeringS? I am quite sure there are no FOSS implementations. That's why I've started my own in the gprs-sgsn branch. But that still only supports the signalling plane and no data plane. If you wait 1-2 more months, I'm sure it will be finished at some point soon. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zecke at selfish.org Mon Apr 19 04:37:12 2010 From: zecke at selfish.org (Holger Freyther) Date: Mon, 19 Apr 2010 12:37:12 +0800 Subject: Changes to the paging subsystem Message-ID: <4BCBDDF8.1060703@selfish.org> Hi all, I will implement the following changes on the on-waves/bsc-master branch and if no one is screaming move them over to master shortly afterwards. Right now I'm experiencing the following problem. When enabling the RF on the BTS hordes of MS come to the network for Location Updating Requests and the SDCCHs are close to 100% loaded, now I want to send a SMS to every new Subscriber welcoming it (ideally one would do it during the LU but... well... it does not). To deliver the SMS we need to page the SMS and currently we are paging 20 MSs during 2 seconds. The first problem is that the nanoBTS can not handle this load for a long time, it is sending CPU Overload and as of GSM 08.58 we should handle it by throttling the transfer but well that is not implemented. The other problem is with the 20 paging requests every two seconds I'm creating a RACH DoS for my BTS to a point that I think (didn't bother to do the easy math, and I don't have the spec here right now) we have two MS picking the same random number. At least the symptom is that even if we assign a channel, it gets closed down with a RF Failure. So here is my problem: - Remove the notion of paging slots... the nanoBTS is not even sending the load indication anyway. - Look at free channels (ignoring the requested channel at first... something we need to fix later) and have a config switch like.. only page if the cell is like 50% loaded or such. I will figure out the details while doing the changes. The other reason to write this mail is, I think it is pretty interesting to see how our experiments from the congress look different to what I was seeing due way more paging going on. regards holger From spaar at mirider.augusta.de Mon Apr 19 08:14:25 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Mon, 19 Apr 2010 08:14:25 CEST Subject: Changes to the paging subsystem Message-ID: <4bcc10e1.mirider@mirider.augusta.de> Hello Holger, On Mon, 19 Apr 2010 12:37:12 +0800, "Holger Freyther" wrote: > > The other problem is with the 20 paging requests every two seconds I'm > creating a RACH DoS for my BTS to a point that I think (didn't bother to > do the easy math, and I don't have the spec here right now) we have two > MS picking the same random number. At least the symptom is that even if > we assign a channel, it gets closed down with a RF Failure. I wonder how frequently it happens with 20 MS that a RACH is sent on the same frame and with the same random number. There are at least 16 possible random numbers for the "Answere to Paging" Channel Request and there are 27 frames in the MF to chooses from (in the "Combined Configuration"). Do you use the same phones for testing and does the RF Failure happen frequently (this probably would mean a bad random number generator in this phone firmware) ? Also I would expect that two RACH burst will disturb each other, at least in a testing environment where all the MS have the same distance to the BTS and send with the same power. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From dburgess at jcis.net Mon Apr 19 13:40:21 2010 From: dburgess at jcis.net (David A. Burgess) Date: Mon, 19 Apr 2010 06:40:21 -0700 Subject: Changes to the paging subsystem In-Reply-To: <4bcc10e1.mirider@mirider.augusta.de> References: <4bcc10e1.mirider@mirider.augusta.de> Message-ID: <4C2A596D-E1F5-4094-BBBE-375927B76EAD@jcis.net> Even if two MS collide with the same random number at the same time, and one RACH burst overpowers the other enough to be detected and decoded, the L2 contention resolution procedure will usually prevent a complete failure, at lease for one of the MS. On Apr 18, 2010, at 11:14 PM, Dieter Spaar wrote: > Hello Holger, > > On Mon, 19 Apr 2010 12:37:12 +0800, "Holger Freyther" > wrote: >> >> The other problem is with the 20 paging requests every two seconds >> I'm >> creating a RACH DoS for my BTS to a point that I think (didn't >> bother to >> do the easy math, and I don't have the spec here right now) we >> have two >> MS picking the same random number. At least the symptom is that >> even if >> we assign a channel, it gets closed down with a RF Failure. > > I wonder how frequently it happens with 20 MS that a RACH is sent > on the > same frame and with the same random number. There are at least 16 > possible > random numbers for the "Answere to Paging" Channel Request and > there are > 27 frames in the MF to chooses from (in the "Combined Configuration"). > Do you use the same phones for testing and does the RF Failure happen > frequently (this probably would mean a bad random number generator in > this phone firmware) ? Also I would expect that two RACH burst will > disturb each other, at least in a testing environment where all the > MS have the same distance to the BTS and send with the same power. > > Best regards, > Dieter > -- > Dieter Spaar, Germany > spaar at mirider.augusta.de David A. Burgess Kestrel Signal Processing, Inc. From zecke at selfish.org Tue Apr 20 02:42:34 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 20 Apr 2010 10:42:34 +0800 Subject: Changes to the paging subsystem In-Reply-To: <4C2A596D-E1F5-4094-BBBE-375927B76EAD@jcis.net> References: <4bcc10e1.mirider@mirider.augusta.de> <4C2A596D-E1F5-4094-BBBE-375927B76EAD@jcis.net> Message-ID: <4BCD149A.40908@selfish.org> On 04/19/2010 09:40 PM, David A. Burgess wrote: > Even if two MS collide with the same random number at the same time, and > one RACH burst overpowers the other enough to be detected and decoded, > the L2 contention resolution procedure will usually prevent a complete > failure, at lease for one of the MS. >>> The other problem is with the 20 paging requests every two seconds I'm >>> creating a RACH DoS for my BTS to a point that I think (didn't bother to >>> do the easy math, and I don't have the spec here right now) we have two >>> MS picking the same random number. At least the symptom is that even if >>> we assign a channel, it gets closed down with a RF Failure. >> >> I wonder how frequently it happens with 20 MS that a RACH is sent on the >> same frame and with the same random number. There are at least 16 >> possible Hi David, Dieter, you are both right and this was wishful thinking on my side. I'm able to reproduce the problem locally and the root cause seems to be among the lines Harald has pointed out in a previous mail. My test setup is to always have 200 pending paging requests (so we will mostly constantly page) and then try to place a call from a MS. What happens is that the IMMEDIATE ASSIGNMENT does not make it to the phone fast enough and the same MS is sending another RA and we assign another channel. The root causes consist of various issues: - Our delay in src/input/ipaccess.c does not help, removing it is breaking the rugby sized BTS though.. - Our paging layer sends the paging command in bursts... we should have an even distribution of them. - We have some NM attributes to play with. I am going to poke this some more. From zecke at selfish.org Mon Apr 26 08:16:45 2010 From: zecke at selfish.org (Holger Freyther) Date: Mon, 26 Apr 2010 16:16:45 +0800 Subject: Changes to the paging subsystem In-Reply-To: <4BCD149A.40908@selfish.org> References: <4bcc10e1.mirider@mirider.augusta.de> <4C2A596D-E1F5-4094-BBBE-375927B76EAD@jcis.net> <4BCD149A.40908@selfish.org> Message-ID: <4BD54BED.5020206@selfish.org> On 04/20/2010 10:42 AM, Holger Freyther wrote: > > The root causes consist of various issues: > - Our delay in src/input/ipaccess.c does not help, removing it > is breaking the rugby sized BTS though.. > - Our paging layer sends the paging command in bursts... we > should have an even distribution of them. > - We have some NM attributes to play with. > Hi, I have the following changes in my branch: 1.) instead of sending n paging requests in a big bulk, send one every couple of milliseconds. Even if the CCCH Overload warning should be fine, in my experiments the nanoBTS didn't really like it. The delay in milliseconds was tested like this. I was having 200 pending paging requests and I was making the delay big enough to not run into messages from the nanoBTS about dropped paging requests. I think that change is okay to land and should not interfere with anything. 2.) the other one is to not send a paging request when there are no free channels for that given type. This is configurable and off by default. I think this is meeting LaF0rge's requirements about such a change. From laforge at gnumonks.org Mon Apr 19 07:27:20 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 19 Apr 2010 09:27:20 +0200 Subject: Changes to the paging subsystem In-Reply-To: <4BCBDDF8.1060703@selfish.org> References: <4BCBDDF8.1060703@selfish.org> Message-ID: <20100419072720.GF18200@prithivi.gnumonks.org> Hi Zecke, On Mon, Apr 19, 2010 at 12:37:12PM +0800, Holger Freyther wrote: > I will implement the following changes on the on-waves/bsc-master branch > and if no one is screaming move them over to master shortly afterwards. I think they might be a bit controversial - at least in part :/ > Right now I'm experiencing the following problem. When enabling the RF > on the BTS hordes of MS come to the network for Location Updating > Requests and the SDCCHs are close to 100% loaded, What I would recommend is to slowly ramp up the power. This is how IMSI catchers avoid that problem. You start with the lowest transmit power of the BTS and then increase only once your load at that transmit level is low enough. I have no idea how we could easily increase the power of the nanoBTS _while_ it is operating. Setting the MAX_POWER_RED attribute is done via OML and I'm almost certain (worth checking) that the transceiver needs to be locked to change it. > now I want to send a SMS to every new Subscriber welcoming it (ideally one > would do it during the LU but... well... it does not). It does not what? It doesn't work? You cannot establish SAPI3 on the channel that's open after location updating accept? That's weird. I think we did this at HAR and it worked fine. The only thing that doesn't work is sending an SMS before you have sent the LOC UPD ACCEPT. Or are you referring that your proprietary MSC doesn't do that ;) > The first problem is that the nanoBTS can not handle this load for a > long time, it is sending CPU Overload and as of GSM 08.58 we should > handle it by throttling the transfer but well that is not implemented. I hate the nanoBTS for giving such indifferent error messages... and we might sooner or later reconsider implementing the throttling after all. > The other problem is with the 20 paging requests every two seconds I'm > creating a RACH DoS for my BTS to a point that I think (didn't bother to > do the easy math, and I don't have the spec here right now) we have two > MS picking the same random number. At least the symptom is that even if > we assign a channel, it gets closed down with a RF Failure. Maybe the RACH retransmission time and count are set too small? Maybe somehow we are too slow in responding to the request (remember that stupid usleep in the ipaccess input plugin? maybe it can be disabled after the BTS OML startup) The BTS has something like 200 RACH slots a second... so sending 20 requests on the downlink is certainly no problem. Even if two MS are accessing the same channel, it should not result in a readio link failure. Both will tune to the assigned channel and send the first packet (SABME with PAGING RESPONSE as L3). The BTS will echo back the received packet (one of them should have survived). One phone will see its own message echoed back (good). The other phone will see a different message (bad) and thus locally close the channel. However, in your specific setup, the two phones might be received with exactly the same (high) signal level, so there might be too many errors at the BTS to still be able to decode the first message. > So here is my problem: > - Remove the notion of paging slots... the nanoBTS is not > even sending the load indication anyway. yes, but other BTS do (like BS-11, and hopefully many others that we will eventually support. We already have a static const structure representing a BTS type, so we can simply add this as a flag to that data structure. > - Look at free channels (ignoring the requested channel at > first... something we need to fix later) and have a config > switch like.. only page if the cell is like 50% loaded or > such. I will figure out the details while doing the changes. As long as that is an option, I have no problems at all. > The other reason to write this mail is, I think it is pretty interesting > to see how our experiments from the congress look different to what I > was seeing due way more paging going on. apparently yes... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zecke at selfish.org Mon Apr 19 07:45:10 2010 From: zecke at selfish.org (Holger Freyther) Date: Mon, 19 Apr 2010 15:45:10 +0800 Subject: Changes to the paging subsystem In-Reply-To: <20100419072720.GF18200@prithivi.gnumonks.org> References: <4BCBDDF8.1060703@selfish.org> <20100419072720.GF18200@prithivi.gnumonks.org> Message-ID: <4BCC0A06.1090801@selfish.org> On 04/19/2010 03:27 PM, Harald Welte wrote: > Hi Zecke, > > On Mon, Apr 19, 2010 at 12:37:12PM +0800, Holger Freyther wrote: > >> I will implement the following changes on the on-waves/bsc-master branch >> and if no one is screaming move them over to master shortly afterwards. > > I think they might be a bit controversial - at least in part :/ No problem, I will solve my problem first and then we can see how controversial things are looking. > >> Right now I'm experiencing the following problem. When enabling the RF >> on the BTS hordes of MS come to the network for Location Updating >> Requests and the SDCCHs are close to 100% loaded, > > What I would recommend is to slowly ramp up the power. This is how IMSI > catchers avoid that problem. You start with the lowest transmit power of the > BTS and then increase only once your load at that transmit level is low enough. > > I have no idea how we could easily increase the power of the nanoBTS _while_ it > is operating. Setting the MAX_POWER_RED attribute is done via OML and I'm > almost certain (worth checking) that the transceiver needs to be locked to > change it. I didn't know that. I can give it a try and then see what is going on. It might take a day or two until I have the time to try it. > >> now I want to send a SMS to every new Subscriber welcoming it (ideally one >> would do it during the LU but... well... it does not). > Or are you referring that your proprietary MSC doesn't do that ;) Exactly, or actually... thanks to the closed "market" the module sending the welcome SMS and the MSC have little in common... I would be very interested in a paid study of loss generated by proprietary software... In that case we have to use more power on the network and mobile side for the extra paging and such... :) > >> The first problem is that the nanoBTS can not handle this load for a >> long time, it is sending CPU Overload and as of GSM 08.58 we should >> handle it by throttling the transfer but well that is not implemented. > > I hate the nanoBTS for giving such indifferent error messages... and we might > sooner or later reconsider implementing the throttling after all. Do you happen to know if it is generating messages for the RACH load? I have seen some parsing inside the abis_rsl.c for it, but I can not remember to have seen such a message in the traces. > >> The other problem is with the 20 paging requests every two seconds I'm >> creating a RACH DoS for my BTS to a point that I think (didn't bother to >> do the easy math, and I don't have the spec here right now) we have two >> MS picking the same random number. At least the symptom is that even if >> we assign a channel, it gets closed down with a RF Failure. > > Maybe the RACH retransmission time and count are set too small? > > Maybe somehow we are too slow in responding to the request (remember that > stupid usleep in the ipaccess input plugin? maybe it can be disabled after > the BTS OML startup) Two very good points, we can test one of them easily, while the other is... well we have burned our hands twice, it is time for the third time and with some time we might see what we are doing wrong in regard to the order of messages. > > The BTS has something like 200 RACH slots a second... so sending 20 requests on > the downlink is certainly no problem. Yeah, thanks to the TDMA excercise on OsmocomBB, I assumed that we can easily send that many requests (we can page like 5-8 MS during a 51 multiframe). But just by looking at the symptoms. I do see CPU overload messages and at some point the OML connection drops, and everything is better when I do not send the paging requests (it also means I don't attempt MT-SMS). >> So here is my problem: >> - Remove the notion of paging slots... the nanoBTS is not >> even sending the load indication anyway. > > yes, but other BTS do (like BS-11, and hopefully many others that we will > eventually support. We already have a static const structure representing > a BTS type, so we can simply add this as a flag to that data structure. okay. > >> - Look at free channels (ignoring the requested channel at >> first... something we need to fix later) and have a config >> switch like.. only page if the cell is like 50% loaded or >> such. I will figure out the details while doing the changes. > > As long as that is an option, I have no problems at all. I will see if that cures my problem and then work on a revised version for master. From dburgess at jcis.net Mon Apr 19 13:39:08 2010 From: dburgess at jcis.net (David A. Burgess) Date: Mon, 19 Apr 2010 06:39:08 -0700 Subject: Changes to the paging subsystem In-Reply-To: <20100419072720.GF18200@prithivi.gnumonks.org> References: <4BCBDDF8.1060703@selfish.org> <20100419072720.GF18200@prithivi.gnumonks.org> Message-ID: <8A68DEAD-B1BD-40B6-BE58-C601A963EF32@jcis.net> We do with with OpenBTS, too and it works fine. If there's a problem, it's in your local implementation, not in the spec. On Apr 19, 2010, at 12:27 AM, Harald Welte wrote: > >> now I want to send a SMS to every new Subscriber welcoming it >> (ideally one >> would do it during the LU but... well... it does not). > > It does not what? It doesn't work? You cannot establish SAPI3 on > the channel > that's open after location updating accept? That's weird. I think > we did this > at HAR and it worked fine. The only thing that doesn't work is > sending an SMS > before you have sent the LOC UPD ACCEPT. > David A. Burgess Kestrel Signal Processing, Inc. From spaar at mirider.augusta.de Tue Apr 20 08:17:39 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Tue, 20 Apr 2010 08:17:39 CEST Subject: Changes to the paging subsystem Message-ID: <4bcd6323.mirider@mirider.augusta.de> Hello Holger, On Tue, 20 Apr 2010 10:42:34 +0800, "Holger Freyther" wrote: > > What happens is that the IMMEDIATE ASSIGNMENT does not make it to the > phone fast enough and the same MS is sending another RA and we assign > another channel. > > The root causes consist of various issues: > - Our delay in src/input/ipaccess.c does not help, removing it > is breaking the rugby sized BTS though.. > - Our paging layer sends the paging command in bursts... we > should have an even distribution of them. > - We have some NM attributes to play with. > > I am going to poke this some more. I sometimes had the same problem in the past even with a single MS. If you want to play with the parameters which control sending the RACH burst, you can try the configuration commands "rach tx integer" for the number of slots used to spread retransmission or "rach max transmission" for the number of retransmitted burst. Of course in a perfect world OpenBSC should work with all possible configurations. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From laforge at gnumonks.org Tue Apr 20 09:32:36 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 20 Apr 2010 11:32:36 +0200 Subject: Who would attend a developer room / meeting at FrOSCon ? Message-ID: <20100420093236.GT18200@prithivi.gnumonks.org> Hi! I've been offered a 'developer room' at FrOSCon 2010 (http://www.froscon.de/) which will be at FH Bonn-Rhein-Sieg (http://www.fh-brs.de/) in Sankt Augustin from August 21/22 this year. Before sending a response, I would like to inquire whom of you would actually have any intention of visiting this conference and spending time in the developer room to work on OpenBSC or OsmocomBB ? I think the idea is great to meet some of you guys [again], not only at the annual CCC congress in winter. But there is little point for me to go there if there is no interest from the wider project community. Please provide your feedback ASAP. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From fabrice.poundeu at smail.inf.fh-bonn-rhein-sieg.de Thu Apr 22 11:55:32 2010 From: fabrice.poundeu at smail.inf.fh-bonn-rhein-sieg.de (Fabrice Ismael Poundeu Tchouatieu) Date: Thu, 22 Apr 2010 13:55:32 +0200 Subject: AW: running lcr with openbsc and nanoBTS In-Reply-To: References: Message-ID: <20100422135532.mboha5d9ckw0cos0@www4.inf.fh-bonn-rhein-sieg.de> Quoting "Andreas.Eversberg" : hye andreas, > output of "misdn_info" Found 2 ports Port 0 'mISDN_l1loop.1': TE/NT-mode PRI E1 (for phone lines & E1 devices) 30 B-channels: 1-15 17-31 B-protocols: RAW HDLC X75slp -------- Port 1 'mISDN_l1loop.2': TE/NT-mode PRI E1 (for phone lines & E1 devices) 30 B-channels: 1-15 17-31 B-protocols: RAW HDLC X75slp > /usr/local/lcr/interface.conf # The MSN numbers will equal the subscriber number. [GSM] gsm nt layer1hold no layer2hold no tones yes earlyb no channel-in free channel-out any nodtmf # Hint: Enter "lcr interface" for quick help on interface options. # Add your interfaces here: [Ext] extern portnum 0 [Int] extension msn 200,201,202,203 portnum 1 nt > /usr/local/lcr/openbsc.cfg (or whatever your config file name is > defined in gsm.conf) ! ! OpenBSC configuration saved from vty ! password foo ! line vty no login ! network network country code 1 mobile network code 1 short name OpenBSC long name OpenBSC timer t3101 10 timer t3113 60 bts 0 type nanobts ip.access unit_id 1801 0 band GSM1800 location_area_code 1 training_sequence_code 7 base_station_id_code 63 trx 0 arfcn 514 max_power_red 20 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/H timeslot 7 phys_chan_config TCH/H and here is the content of the /usr/local/lcr/gsm.conf # LCR GSM options ################# # Enable debugging of OpenBSC library. # Refer to OpenBSC project for debugging options. # By default, debugging is turned off. #debug DRLL:DCC:DMM:DRR:DRSL:DNM:DSMS:DMNCC:DMNSMS:DPAG:DMUX:DMEAS # Two Loopback interfaces for audio transfer between OpenBSC and mISDN. # The first interface must provide B-channelis for each call mobile call. # The seond interface links them to LCR. # Use 30 B-channels unless you need more due to many TRXs. # -> Load with: "modprobe mISDN_l1loop pri=1 nchannel=30" # By default "mISDN_l1loop.1" and "mISDN_l1loop.2" is used. #interface-bsc mISDN_l1loop.1 #interface-lcr mISDN_l1loop.2 # Give openbsc.cnf config file # It will be located at /usr/local/lcr by default. config /opt/openbsc/src/openbsc.cfg # Give database of Home Location Register (HLR) # HLR stores all subscribers. It will be used to grant access to the network. # It is an Sqlite3 database. Refer to OpenBSC project for handling. # The database is located at /usr/local/lcr by default. hlr /opt/openbsc/src/hlr.sqlite # To keep layer 2 connection to BS11 when quitting, use this option. # It is only usefull for developing. TRX will stay on. # Also changes in frequency, mcc, mnc, lac while keeping layer 2 will cause # malefunction of BSC. # Warning: Keeping layer 2 link may prevent emergency calls. (See below) #keep-l2 # Shutdown on emergency calls: # This option will prevent a shutdown if an emergency call is received. In # case of an emergency, a mobile phone may log onto you GSM network and may # use it to set up an emergency call. # The received emergency call will have 'emergency' as dialed number. But this # number can't be dialed on PSTN networks without chaning. # If you disable shutdown, be sure to provide routing of emergency calls to # emergency facility. If you can't do that, don't touch it! #no-emergency-shutdown # Write BTS-Link traffic to PCAP file. #pcapfile pcap > > it seems that you hook twice on some interface. are you using > asterisk also (in conjunction with chan_lcr)? yes i'm using it also > > regards, > > andreas > > p.s. please discuss this in the mailing list (see > openbsc.gnumonks.org), so other users may have the same problems in > the future. there are not many installations with LCR and openbsc. > > > > > -----Urspr?ngliche Nachricht----- > Von: Fabrice Ismael Poundeu Tchouatieu > [mailto:fabrice.poundeu at smail.inf.fh-bonn-rhein-sieg.de] > Gesendet: Mittwoch, 21. April 2010 14:14 > An: Andreas.Eversberg > Betreff: running lcr with openbsc and nanoBTS > > Quoting "Andreas.Eversberg" : > > hye Andreas, > > i'm trying to get lcr working with openbsc and nanoBTS. To be able to > come through this i have some questions: > > First when i start lcr i have the following following error-informations: > > ** LCR Version 1.7 > > DB: Database initialized. > DB: Database prepared. > ERROR Port 1 already in use by LCR. You can't use a NT port multiple times. > LCR 1.7 started, waiting for calls... > ERROR (in main() line 447) LCR was stalling 2.25 seconds > > but lcr seems to work actually. Is that the normal way it works or it > there something wrong? I have nothing else running on LCR. > > When i then try to set a call, lcr break out with the following information: > > layer3_thread read socket error No space left on device > > I don't known how many space is needed therefore, or in which folder > or directory this space should be available. But the drive is quite > empty. there is so much space available on it! > > Also can you send me an example of a working dialplan and sip.conf to > enable the routing of gsm calls?? > > thanks and best regards!! > > -- > Fabrice Ismael Poundeu Tchouatieu > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > -- Fabrice Ismael Poundeu Tchouatieu ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From Andreas.Eversberg at versatel.de Fri Apr 23 13:10:47 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Fri, 23 Apr 2010 15:10:47 +0200 Subject: AW: AW: running lcr with openbsc and nanoBTS Message-ID: >> output of "misdn_info" >Found 2 ports > Port 0 'mISDN_l1loop.1': TE/NT-mode PRI E1 (for phone lines & E1 devices) > 30 B-channels: 1-15 17-31 > B-protocols: RAW HDLC X75slp > -------- > Port 1 'mISDN_l1loop.2': TE/NT-mode PRI E1 (for phone lines & E1 devices) > 30 B-channels: 1-15 17-31 > B-protocols: RAW HDLC X75slp hi fabrice, the mISDN_l1loop interfaces are used to bring audio channels from the BTS into the kernel (mISDN driver). there they can be connected to other ISDN ports or used by chan_lcr (asterisk channel driver). both interfaces are used by the [GSM] interface. (see gsm.conf) there are two interfaces: one is for the BTS side and the other for the chan_lcr (asterisk) side. since you have no physical interface, i assume that you want to use asterisk in combination with chan_lcr. but you also have [Int] and [Ext] interfaces defined. you may only use them if you actually have physical interfaces. what happens here: the given port numbers 0 and 1 match you virtual l1loop interfaces, which are already in use for [GSM] interface. unless you don't have physical cards, remove them. (interface.conf) now you may route all call from the GSM interface (or any interface to the chan_lcr: see routing.conf [main] : remote application=asterisk and from asterisk to lcr: Dial(LCR/GSM/[/]) try a test first: [main] : test prefix=5 and you should hear music... regards, andreas p.s. i think we may require a howto. also i think i must put some 'working' packages together at one point to download. sometimes api changes a bit, so always latest packets may not work together. From fabrice.poundeu at smail.inf.fh-bonn-rhein-sieg.de Thu Apr 29 07:00:51 2010 From: fabrice.poundeu at smail.inf.fh-bonn-rhein-sieg.de (Fabrice Ismael Poundeu Tchouatieu) Date: Thu, 29 Apr 2010 09:00:51 +0200 Subject: AW: AW: running lcr with openbsc and nanoBTS In-Reply-To: References: Message-ID: <20100429090051.2so8yzl5wwc0gkcs@www4.inf.fh-bonn-rhein-sieg.de> Hye Andreas, thanks for the help. That was exactly my problem and you help me solve it. regards; Fabrice Quoting "Andreas.Eversberg" : >>> output of "misdn_info" >> Found 2 ports >> Port 0 'mISDN_l1loop.1': TE/NT-mode PRI E1 (for phone lines & E1 > devices) >> 30 B-channels: 1-15 17-31 >> B-protocols: RAW HDLC X75slp >> -------- >> Port 1 'mISDN_l1loop.2': TE/NT-mode PRI E1 (for phone lines & E1 > devices) >> 30 B-channels: 1-15 17-31 >> B-protocols: RAW HDLC X75slp > > hi fabrice, > > the mISDN_l1loop interfaces are used to bring audio channels from the > BTS into the kernel (mISDN driver). there they can be connected to other > ISDN ports or used by chan_lcr (asterisk channel driver). both > interfaces are used by the [GSM] interface. (see gsm.conf) there are two > interfaces: one is for the BTS side and the other for the chan_lcr > (asterisk) side. > > since you have no physical interface, i assume that you want to use > asterisk in combination with chan_lcr. but you also have [Int] and [Ext] > interfaces defined. you may only use them if you actually have physical > interfaces. what happens here: the given port numbers 0 and 1 match you > virtual l1loop interfaces, which are already in use for [GSM] interface. > unless you don't have physical cards, remove them. (interface.conf) > > now you may route all call from the GSM interface (or any interface to > the chan_lcr: > > see routing.conf > > [main] > : remote application=asterisk > > and from asterisk to lcr: > > Dial(LCR/GSM/[/]) > > > try a test first: > > [main] > : test prefix=5 > > and you should hear music... > > regards, > > andreas > > p.s. i think we may require a howto. also i think i must put some > 'working' packages together at one point to download. sometimes api > changes a bit, so always latest packets may not work together. > > > > > > > -- Fabrice Ismael Poundeu Tchouatieu ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From zecke at selfish.org Mon Apr 26 08:26:07 2010 From: zecke at selfish.org (Holger Freyther) Date: Mon, 26 Apr 2010 16:26:07 +0800 Subject: FYI: Difference between on-waves/bsc-master Message-ID: <4BD54E1F.6000805@selfish.org> Hi all, this is just a small head ups on the current differences between the on-waves/bsc-master branch and HEAD. New apps: 1.) bsc_msc_ip is the OpenBSC BSC that is speaking the A interface 2.) bsc_nat is a NAT/Multiplexer for BSCs and MGCP. One reason for it is easy nat penetration. I will look into git filter branch to merge the NAT into master as there is nothing that is preventing it, for the bsc_msc_ip I need to continue some merging. Changes: *) RF Failure handling. When a RF Channel fails, I switch it over to a failure state, then ignore all SAPIs releases... and then set it back to operational state. *) RF bring down in SAPI order. So at first I will bring down SAPI=3, then send SACH deactivate, then SAPI=0, then send the RF Channel release. This is done as the nanoBTS likes to send a SAPI release indication after the RF Channel Release ACK. *) channel release reason, when closing a lchan one can set the release reason. This is used on early assignment when closing down the old signalling channel. *) and of course the much talked about removal of ref counts from the lchan. From laforge at gnumonks.org Thu Apr 29 21:26:34 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 29 Apr 2010 23:26:34 +0200 Subject: Inter-layer state / references / control buffer Message-ID: <20100429212634.GM20018@prithivi.gnumonks.org> Hi! I'm getting to a point where we need to associate more and more state and/or references with every individual msgb. In the circuit switched BSC case, every message (msgb) is associated with a logical channel (lchan) through which it is sent. However, in the packet switched case, this is not the case. Rather, a msgb is received on a particular NS-VC, inside a particular BSSGP-VC, inside a LLC session, etc. When we pass a msgb through the protocol layers and back, we somehow need to identify where to send the response to. Once we actually reach the 04.08/04.11 layer, things become a bit less difficult. In the end, all messages are at least somehow associated with a 'subscriber'. If a message passes from the UDP socket into the NS protocol and into BSSGP, we need to know the BSVCI and NSVCI if we want to send a response back. One option would be to pass those values as explicit function call arguments, which is partially what my current code is doing. But the more layers we traverse, the longer the function arguments get. Furthermore, there are parts of our protocol (04.08 and 04.11 particularly) that can either be transported on top of 08.58 (RSL) or LLC/BSSGP/NS. Those upper layers shouldn't really care what the underlying transport looks like. One possible option is to somehow identify the NS-VC and BSSGP-VC by putting an identifier or pointer into a 'struct msgb' member. This would require libosmocore changes every time we add some bits here or there. Another option is to introduce something similar to the skb->cb in the linux kernel: A 'control buffer' area of unspecified content provide by the core networking code as part of every sk_buff, which gets type-casted to the IPCB or TCB-CB when the msgb enters the respective protocol layer. The advantage is that we could have one msgb structure definition with the typecasting functions/macros being part of the application (e.g. openbsc) The problem with this is: Its scope is limited to whatever is the current layer of the protocol stack. The IPCB is overwritten with the TCBCB once the message enters TCP. In our case, we would actually want to have the associated data to persist even while the msgb passes from one layer into another. This would mean that there is a more-or-less static structure containing all the various identifiers, which is then typecasted to the control buffer. While this might not be ideal, it definitely keeps the details hidden away from libosmocore, which is good. Any comments are welcome, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Thu Apr 29 22:19:33 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 30 Apr 2010 00:19:33 +0200 Subject: Inter-layer state / references / control buffer In-Reply-To: <20100429212634.GM20018@prithivi.gnumonks.org> References: <20100429212634.GM20018@prithivi.gnumonks.org> Message-ID: Hi Harald, > In our case, we would actually want to have the associated data to persist > even while the msgb passes from one layer into another. ?This would mean > that there is a more-or-less static structure containing all the various > identifiers, which is then typecasted to the control buffer. > > While this might not be ideal, it definitely keeps the details hidden > away from libosmocore, which is good. FWIW, I think it's a good idea. When I had a first look at the gprs branch a few months ago, all those new fields required in msgb definitely were something I wasn't thrilled to see. As I see it, it might not be perfect but : - It does the job - It's a whole lot better than the current situation - It's simple to understand One question that pops to mind is : - Would allocation / freeing of those be handled by msgb routines ? I would think so since that'd avoid error and I don't see any loss of 'genericity' in doing that, but just asking. Also, would you include the various header pointer in this cb struct or splitted ? Personaly, I'd still see them splitted but more something like "uint8_t *h[8];" and let the application define its own macros msgb_ns_hdr(), msgb_rsl_hdr(), msgb_gmm_hdr() that map to the unique 'h' pointer rather than things like union { unsigned char *smsh; unsigned char *llch; unsigned char *l4h; }; This way the msgb wouldn't show even any 'gsm' aspect and would just be a generic message buffer ... Cheers, Sylvain From laforge at gnumonks.org Fri Apr 30 20:39:27 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 30 Apr 2010 22:39:27 +0200 Subject: Inter-layer state / references / control buffer In-Reply-To: References: <20100429212634.GM20018@prithivi.gnumonks.org> Message-ID: <20100430203927.GB20018@prithivi.gnumonks.org> Hi Sylvain, On Fri, Apr 30, 2010 at 12:19:33AM +0200, Sylvain Munaut wrote: > > While this might not be ideal, it definitely keeps the details hidden > > away from libosmocore, which is good. > > FWIW, I think it's a good idea. When I had a first look at the gprs > branch a few months ago, all those new fields required in msgb > definitely were something I wasn't thrilled to see. I also didn't find them particularly exciting. > As I see it, it might not be perfect but : > - It does the job > - It's a whole lot better than the current situation > - It's simple to understand > > One question that pops to mind is : > - Would allocation / freeing of those be handled by msgb routines ? I > would think so since that'd avoid error and I don't see any loss of > 'genericity' in doing that, but just asking. As you can see from the current code in libosmocore, there is no separate allocation but simply a small data array in the msgb itself, just like the sk_buff.cb member. > Also, would you include the various header pointer in this cb struct > or splitted ? > > Personaly, I'd still see them splitted but more something like > "uint8_t *h[8];" and let the application define its own > macros msgb_ns_hdr(), msgb_rsl_hdr(), msgb_gmm_hdr() that map to the > unique 'h' pointer rather than things like > > union { > unsigned char *smsh; > unsigned char *llch; > unsigned char *l4h; > }; Yes, I agree with that, too. We can do a gradual migration, i.e. first introduce the accessor macros (while still pointing to the named msgb members) fields) and later removing those named msgb members. Using accessor macros would also remove the need for those stupid typecasts all over the code (like "struct gsm48_hdr *gh = (struct gsm48_hdr *) msgb->l3h;"). It would simply be "struct gsm48_hdr *gh = msgb_gsm48hdr(msg);" instead. Due to time constraints I will not be working on this and rather work on completing gprs functionality. However, if somebody submits patches, I'm happy to merge them. Another stupidity that I also dislike about the current gsm_04_08_gprs.c code is that it uses a different header (msgb->gmmh, now msgb_gmmh(msg)) than the gsm_04_08.c code (msg->l3h). The reason for this is that the layer stacking in GPRS is deeper than in the GSM case. I plan to rework it in a way that all 04.08 code (gsm or gprs) uses msgb_gsm48h(msg) whihc resolves to msg->l3h; The additional layers introduced by NS/BSSGP/LLC stacking will be hidden in the cb[]. This way we can have code that works on any gsm48 msgb without knowing if its on GSM or GPRS. This will become important e.g. for SMS later. > This way the msgb wouldn't show even any 'gsm' aspect and would just > be a generic message buffer ... yes, that is definitely one of the goals... Cheers, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)