From 246tnt at gmail.com Sun Dec 20 00:04:00 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 20 Dec 2009 01:04:00 +0100 Subject: [PATCH 4/4] abis_nm: Fix ACTIVATE SW parameters In-Reply-To: <20091026191842.GP29852@prithivi.gnumonks.org> References: <1256489804-9165-1-git-send-email-246tnt@gmail.com> <1256489804-9165-2-git-send-email-246tnt@gmail.com> <1256489804-9165-3-git-send-email-246tnt@gmail.com> <1256489804-9165-4-git-send-email-246tnt@gmail.com> <20091026191842.GP29852@prithivi.gnumonks.org> Message-ID: <866320f70912191604t1015c8e6x6b6390cfc5ca5b2e@mail.gmail.com> > The previous code only sent the FILE_ID tag data part, > > but according to the GSM 12.21 spec, section 8.3.6, the > > full SW Description 'object' must be sent so that includes > > the NM_ATT_SW_DESCR tag, the whole FILE_ID and the whole > > FILE_VERSION (including tags & length fields). > > Can somebody test this with a BS11? I want to make sure we don't introduce > regressions here. > > Did anyone ever had the opportunity to test this with a BS-11 ? Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Sun Dec 20 13:16:31 2009 From: zecke at selfish.org (Holger Freyther) Date: Sun, 20 Dec 2009 14:16:31 +0100 Subject: Disabling RF for a TRX / Tracking abis NM state In-Reply-To: <200911260144.45262.zecke@selfish.org> References: <20091125194728.GA22160@prithivi.gnumonks.org> <200911260144.45262.zecke@selfish.org> Message-ID: <200912201416.31897.zecke@selfish.org> On Thursday 26 November 2009 01:44:45 Holger Freyther wrote: > On Wednesday 25 November 2009 20:47:28 Harald Welte wrote: > > I would appreciate if you could fix this. > > I will, honestly I was just too lazy to figure out if the state is updated, > how it should be set on startup. I will try to fix it before FOSS.IN. Hi, I did not forget this. Today I was starting to set the nm_state.administrative of the trx and it is working for the _LOCKED start up. For the _UNLOCKED startup we seem to copy a new state to the nm_state which includes changing the administrative back to _LOCKED so the TRX is getting locked during startup. I tried using hardware watchpoints on the memory address in gdb but this made things quite slow (in the Xen instance I was testing). I think I will have something working by tomorrow. regards holger From zecke at selfish.org Mon Dec 21 09:35:20 2009 From: zecke at selfish.org (Holger Freyther) Date: Mon, 21 Dec 2009 10:35:20 +0100 Subject: Disabling RF for a TRX / Tracking abis NM state In-Reply-To: <200912201416.31897.zecke@selfish.org> References: <20091125194728.GA22160@prithivi.gnumonks.org> <200911260144.45262.zecke@selfish.org> <200912201416.31897.zecke@selfish.org> Message-ID: <200912211035.20623.zecke@selfish.org> On Sunday 20 December 2009 14:16:31 Holger Freyther wrote: > I think I will have something working by tomorrow. Using administrative will not make us happy. From what I see in the 12.21 it has two different meanings. In one way it should be controlled by the BSC and in another way it can be used by the BTS to send information (MMI whatever that is...) So when we set the administrative state of the trx to unlocked it will be changed in abis_nm_rx_statechg_rep to whatever we got from the BTS (mostly being locked). One approach would be to never set administrative in abis_nm but then we would lose the state of the BTS... and we would not update it when we get acks.. So I was introducing administrative_bsc and administrative_bts to the nm_state struct and keep the bsc state in the bsc one and the bts field in the bts one. Now I'm kind of struggling with bringing up the BTS (I make it reboot...) Harald do you have an idea of how it should look like? From zecke at selfish.org Mon Dec 21 10:52:08 2009 From: zecke at selfish.org (Holger Freyther) Date: Mon, 21 Dec 2009 11:52:08 +0100 Subject: Disabling RF for a TRX / Tracking abis NM state In-Reply-To: <200912211035.20623.zecke@selfish.org> References: <20091125194728.GA22160@prithivi.gnumonks.org> <200912201416.31897.zecke@selfish.org> <200912211035.20623.zecke@selfish.org> Message-ID: <200912211152.09029.zecke@selfish.org> On Monday 21 December 2009 10:35:20 Holger Freyther wrote: > On Sunday 20 December 2009 14:16:31 Holger Freyther wrote: > > I think I will have something working by tomorrow. > > Harald do you have an idea of how it should look like? > Okay, there is a heisenbug somewhere... (when compiled with -O0..) This is the patch I would like to commit. The biggest change is in the abis_nm_rx_statechg_rep function to not use memcmp or assignment of the structs. The semantic to the administrative state is that it will be assigned if it is 0 (default by the BSC) and ignored once it is set. It will still be updated in the ACK messages... diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h index f3ec9eb..da085fc 100644 --- a/openbsc/include/openbsc/gsm_data.h +++ b/openbsc/include/openbsc/gsm_data.h @@ -273,9 +273,6 @@ struct gsm_bts_trx { } bs11; }; struct gsm_bts_trx_ts ts[TRX_NR_TS]; - - /* NM state */ - int rf_locked; }; enum gsm_bts_type { diff --git a/openbsc/src/abis_nm.c b/openbsc/src/abis_nm.c index e7e3bf0..e7def1a 100644 --- a/openbsc/src/abis_nm.c +++ b/openbsc/src/abis_nm.c @@ -812,12 +812,17 @@ static int abis_nm_rx_statechg_rep(struct msgb *mb) } DEBUGPC(DNM, "\n"); - if (memcmp(&new_state, nm_state, sizeof(new_state))) { + if ((new_state.administrative != 0 && nm_state->administrative == 0) || + new_state.operational != nm_state->operational || + new_state.availability != nm_state->availability) { /* Update the operational state of a given object in our in-memory data * structures and send an event to the higher layer */ void *obj = objclass2obj(bts, foh->obj_class, &foh->obj_inst); rc = nm_state_event(EVT_STATECHG_OPER, foh->obj_class, obj, nm_state, &new_state); - *nm_state = new_state; + nm_state->operational = new_state.operational; + nm_state->availability = new_state.availability; + if (nm_state->administrative == 0) + nm_state->administrative = new_state.administrative; } #if 0 if (op_state == 1) { @@ -2781,7 +2786,7 @@ void gsm_trx_lock_rf(struct gsm_bts_trx *trx, int locked) { int new_state = locked ? NM_STATE_LOCKED : NM_STATE_UNLOCKED; - trx->rf_locked = locked; + trx->nm_state.administrative = new_state; if (!trx->bts || !trx->bts->oml_link) return; diff --git a/openbsc/src/bsc_init.c b/openbsc/src/bsc_init.c index 8450af6..d4e0616 100644 --- a/openbsc/src/bsc_init.c +++ b/openbsc/src/bsc_init.c @@ -429,8 +429,7 @@ static int sw_activ_rep(struct msgb *mb) * This code is here to make sure that on start * a TRX remains locked. */ - int rc_state = trx->rf_locked ? - NM_STATE_LOCKED : NM_STATE_UNLOCKED; + int rc_state = trx->nm_state.administrative; /* Patch ARFCN into radio attribute */ nanobts_attr_radio[5] &= 0xf0; nanobts_attr_radio[5] |= trx->arfcn >> 8; diff --git a/openbsc/src/gsm_data.c b/openbsc/src/gsm_data.c index 94ed91b..62576bd 100644 --- a/openbsc/src/gsm_data.c +++ b/openbsc/src/gsm_data.c @@ -126,6 +126,7 @@ struct gsm_bts_trx *gsm_bts_trx_alloc(struct gsm_bts *bts) trx->bts = bts; trx->nr = bts->num_trx++; + trx->nm_state.administrative = NM_STATE_UNLOCKED; for (k = 0; k < TRX_NR_TS; k++) { struct gsm_bts_trx_ts *ts = &trx->ts[k]; From laforge at gnumonks.org Mon Dec 21 21:10:46 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Dec 2009 22:10:46 +0100 Subject: Disabling RF for a TRX / Tracking abis NM state In-Reply-To: <200912211035.20623.zecke@selfish.org> References: <20091125194728.GA22160@prithivi.gnumonks.org> <200911260144.45262.zecke@selfish.org> <200912201416.31897.zecke@selfish.org> <200912211035.20623.zecke@selfish.org> Message-ID: <20091221211046.GR14330@prithivi.gnumonks.org> On Mon, Dec 21, 2009 at 10:35:20AM +0100, Holger Freyther wrote: > On Sunday 20 December 2009 14:16:31 Holger Freyther wrote: > > > I think I will have something working by tomorrow. > > Using administrative will not make us happy. From what I see in the 12.21 it > has two different meanings. In one way it should be controlled by the BSC and > in another way it can be used by the BTS to send information (MMI whatever > that is...) MMI == man machine interface. > [...] > Harald do you have an idea of how it should look like? I really don't understand the problem, sorry. From laforge at gnumonks.org Wed Dec 2 05:41:38 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 2 Dec 2009 11:11:38 +0530 Subject: system_information branch updates In-Reply-To: <20091130205617.GA10213@prithivi.gnumonks.org> References: <20091130205617.GA10213@prithivi.gnumonks.org> Message-ID: <20091202054138.GB6865@prithivi.gnumonks.org> > Unless there are major objections, I intend to merge this branch ASAP (or > rather do a 'git diff master..system_information' and apply the resulting diff > as one commit to master) JFYI: I've merged (actually: imported the code) it to master yesterday. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From s4dd at losers.yore.ma Wed Dec 2 22:36:53 2009 From: s4dd at losers.yore.ma (s4dd at losers.yore.ma) Date: Wed, 02 Dec 2009 22:36:53 +0000 Subject: Issues on initial setup with BS-11 Message-ID: <4B16EC05.9040403@losers.yore.ma> Hello all, I seem to have fallen at the last hurdle to achieving my first milestone - being able to see an available network from our BS-11/OpenBSC combi on a variety of MEs. Fingers crossed it's something trivial that has been overlooked. I've included some output from bs11_config and bsc_hack below in the hope that someone may spot the issue. Output from bs11_config during bootup: PHASE: 1 Load SMU Intended Abis-link: Down PHASE: 1 Load SMU Intended Abis-link: Down PHASE: 2 Load MBCCU MBCCU0: No Load MBCCU1: No Load Abis-link: Down PHASE: 2 Load MBCCU MBCCU0: Load BTSCAC MBCCU1: No Load Abis-link: Down PHASE: 2 Load MBCCU MBCCU0: Load BTSCAC MBCCU1: Load BTSCAC Abis-link: Down PHASE: 2 Load MBCCU MBCCU0: Load BTSDRX MBCCU1: Load BTSCAC Abis-link: Down PHASE: 2 Load MBCCU MBCCU0: Load BTSDRX MBCCU1: Load BTSDRX Abis-link: Down PHASE: 2 Load MBCCU MBCCU0: Load BTSBBX MBCCU1: Load BTSDRX Abis-link: Down PHASE: 2 Load MBCCU MBCCU0: Load BTSBBX MBCCU1: Load BTSBBX Abis-link: Down PHASE: 2 Load MBCCU MBCCU0: Load BTSBBX MBCCU1: Load BTSBBX Abis-link: Down PHASE: 2 Load MBCCU MBCCU0: Load BTSARC MBCCU1: Load BTSBBX Abis-link: Down PHASE: 2 Load MBCCU MBCCU0: Load BTSARC MBCCU1: Load BTSARC Abis-link: Down PHASE: 2 Load MBCCU MBCCU0: Load MBCCU1: Load BTSARC Abis-link: Down PHASE: 2 Load MBCCU MBCCU0: Load MBCCU1: Load BTSARC Abis-link: Down PHASE: 2 Load MBCCU MBCCU0: Load MBCCU1: Load Abis-link: Down PHASE: 3 Normal MBCCU0: Load MBCCU1: Load Abis-link: Restoring BS11 ATTRIBUTES: SITE MANAGER ATTRIBUTES: E1 Channel: Port=0 Timeslot=1 (Full Slot) TEI: 25 BS11 Line Interface ATTRIBUTES: PLL Mode: E1 Locked BS11 CCLK ATTRIBUTES: BS11 Power Amplifier 0 ATTRIBUTES: TRX Power: 30mW (GSM) LMT LOGOFF: ACK ************************************************************ Output from bs11_config with query: LMT LOGON: ACK PHASE: 3 Normal MBCCU0: Load MBCCU1: Load Abis-link: Up BS11 ATTRIBUTES: SITE MANAGER ATTRIBUTES: E1 Channel: Port=0 Timeslot=1 (Full Slot) TEI: 25 BS11 Line Interface ATTRIBUTES: PLL Mode: Standalone BS11 CCLK ATTRIBUTES: BS11 Power Amplifier 0 ATTRIBUTES: TRX Power: 30mW (GSM) LMT LOGOFF: ACK ************************************************************ bsc_hack startup: 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) 1 device found id: 0 Dprotocols: 00000018 Bprotocols: 0000000e protocol: 4 nrbchan: 30 name: hfc-e1.1 activate bchan activate bchan bootstrapping OML for BTS 0 <0020> abis_nm.c:1724 Set BTS Attr (bts=0) <0020> abis_nm.c:1741 Set TRX Attr (bts=0,trx=0) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=0) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=1) <0020> abis_nm.c:1824 Invalid Channel Combination!!! <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=2) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=2) E1=(0,2,2) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=3) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=3) E1=(0,2,3) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=4) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=4) E1=(0,3,0) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=5) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=5) E1=(0,3,1) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=6) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=6) E1=(0,3,2) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=7) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=7) E1=(0,3,3) bootstrapping RSL for BTS/TRX (0/0) using MCC=1 MNC=1 BSIC=63 TSC=7 <0020> abis_nm.c:606 OC=RACK(a4) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled <0020> abis_nm.c:985 LMT Event LOGON Level=2 Username=FACTORY <0020> abis_nm.c:985 LMT Event LOGOFF Level=2 Username=FACTORY ************************************************************ bsc_hack config used was the vanilla cfg included with the source (openbsc.cfg.1-1). Any help you guys could give is much appreciated! Regards, Paul From laforge at gnumonks.org Thu Dec 3 05:56:00 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 3 Dec 2009 11:26:00 +0530 Subject: Issues on initial setup with BS-11 In-Reply-To: <4B16EC05.9040403@losers.yore.ma> References: <4B16EC05.9040403@losers.yore.ma> Message-ID: <20091203055600.GO6865@prithivi.gnumonks.org> Hi Paul, On Wed, Dec 02, 2009 at 10:36:53PM +0000, s4dd at losers.yore.ma wrote: > <0020> abis_nm.c:1824 Invalid Channel Combination!!! This really sounds wrong. Can you send your openbsc.cfg along? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From s4dd at losers.yore.ma Fri Dec 4 13:53:22 2009 From: s4dd at losers.yore.ma (s4dd at losers.yore.ma) Date: Fri, 04 Dec 2009 13:53:22 +0000 Subject: Issues on initial setup with BS-11 In-Reply-To: <20091203055600.GO6865@prithivi.gnumonks.org> References: <4B16EC05.9040403@losers.yore.ma> <20091203055600.GO6865@prithivi.gnumonks.org> Message-ID: <4B191452.4080300@losers.yore.ma> Hi Harald, >> <0020> abis_nm.c:1824 Invalid Channel Combination!!! >> > > This really sounds wrong. Can you send your openbsc.cfg along? > > After changing the appropriate phys_chan_config of timeslot 1 from its default "SDCCH8" to "TCH/F", we are no longer getting the above warning. However, none of our MEs can see the network. Below is our current openbsc.cfg... if you can think of anything for us to try that would be fantastic! Thanks, Paul **************************************************************** openbsc.cfg: ! ! 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 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 123 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 TCH/F e1 line 0 timeslot 2 sub-slot 1 timeslot 2 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 2 timeslot 3 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 3 timeslot 4 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 0 timeslot 5 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 1 timeslot 6 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 2 timeslot 7 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 3 ************************************************* From laforge at gnumonks.org Sun Dec 6 05:17:39 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 6 Dec 2009 10:47:39 +0530 Subject: Issues on initial setup with BS-11 In-Reply-To: <4B191452.4080300@losers.yore.ma> References: <4B16EC05.9040403@losers.yore.ma> <20091203055600.GO6865@prithivi.gnumonks.org> <4B191452.4080300@losers.yore.ma> Message-ID: <20091206051739.GE26466@prithivi.gnumonks.org> On Fri, Dec 04, 2009 at 01:53:22PM +0000, s4dd at losers.yore.ma wrote: > Hi Harald, > > >><0020> abis_nm.c:1824 Invalid Channel Combination!!! > > > >This really sounds wrong. Can you send your openbsc.cfg along? > > > After changing the appropriate phys_chan_config of timeslot 1 from > its default "SDCCH8" to "TCH/F", we are no longer getting the above > warning. Ok, as it turns out this issue is unrelated. I really don't have any other ideas as of now. Do you have any spectrum analyzer or other receiver that can be used to detect if the BTS is actually transmitting? A USRP would also do... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From spaar at mirider.augusta.de Thu Dec 3 08:26:01 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Thu, 03 Dec 2009 08:26:01 Subject: Issues on initial setup with BS-11 Message-ID: <4b177619.mirider@mirider.augusta.de> Hello Paul, On Wed, 02 Dec 2009 22:36:53 +0000, s4dd at losers.yore.ma wrote: > Any help you guys could give is much appreciated! I think the problem is the "Invalid Channel Combination!!!" error message. Try to change "phys_chan_config" of timeslot 1 from "SDCCH8" to "TCH/F". From my understanding of verify_chan_comb() "SDCCH8" is not allowed on the same TRX that already has "CCCH+SDCCH4" so I wonder why it is set in the config file (this only applies to the BS11). Sorry, I don't have a ready BS11 configuration at hand right now, so I can't test it. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From dburgess at jcis.net Thu Dec 3 09:07:56 2009 From: dburgess at jcis.net (David A. Burgess) Date: Thu, 3 Dec 2009 01:07:56 -0800 Subject: Issues on initial setup with BS-11 In-Reply-To: <4b177619.mirider@mirider.augusta.de> References: <4b177619.mirider@mirider.augusta.de> Message-ID: Dieter - I don't know if that's valid by the spec or not, but it's part of a pretty standard configuration in IMSI-catchers: CCCH+SDCCH4 + 6*SDCCH8 + TCH/F. That maximizes location updating capacity and leaves one TCH/F for other ... mischief. Most of those IMSI-catchers are based on commercial mini/nano-BTS equipment. -- David On Dec 3, 2009, at 8:26 AM, Dieter Spaar wrote: > Hello Paul, > > On Wed, 02 Dec 2009 22:36:53 +0000, s4dd at losers.yore.ma wrote: > >> Any help you guys could give is much appreciated! > > I think the problem is the "Invalid Channel Combination!!!" > error message. Try to change "phys_chan_config" of timeslot > 1 from "SDCCH8" to "TCH/F". From my understanding of > verify_chan_comb() "SDCCH8" is not allowed on the same TRX that > already has "CCCH+SDCCH4" so I wonder why it is set in the > config file (this only applies to the BS11). Sorry, I don't > have a ready BS11 configuration at hand right now, so I can't > test it. > > Best regards, > Dieter > -- > Dieter Spaar, Germany > spaar at mirider.augusta.de David A. Burgess Kestrel Signal Processing, Inc. From laforge at gnumonks.org Fri Dec 4 05:50:58 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 4 Dec 2009 11:20:58 +0530 Subject: Issues on initial setup with BS-11 In-Reply-To: References: <4b177619.mirider@mirider.augusta.de> Message-ID: <20091204055058.GE6865@prithivi.gnumonks.org> On Thu, Dec 03, 2009 at 01:07:56AM -0800, David A. Burgess wrote: > I don't know if that's valid by the spec or not, but it's part of a > pretty standard configuration in IMSI-catchers: CCCH+SDCCH4 + > 6*SDCCH8 + TCH/F. That maximizes location updating capacity and > leaves one TCH/F for other ... mischief. Most of those > IMSI-catchers are based on commercial mini/nano-BTS equipment. Unfortunately that combination is not supported by either the BS-11 nor the ip.access nanoBTS. Maybe they have a special BTS firmware image for the nanoBTS to do that... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bouchtaoui at gmail.com Fri Dec 4 12:06:27 2009 From: bouchtaoui at gmail.com (Nordin) Date: Fri, 04 Dec 2009 13:06:27 +0100 Subject: UMTS In-Reply-To: <20091204055058.GE6865@prithivi.gnumonks.org> References: <4b177619.mirider@mirider.augusta.de> <20091204055058.GE6865@prithivi.gnumonks.org> Message-ID: <4B18FB43.2060809@gmail.com> Are there any plans for OpenBSC supporting 3G? Cause I've heard ip.access also sells nanoBTSs for 3G. From laforge at gnumonks.org Fri Dec 4 18:44:18 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 5 Dec 2009 00:14:18 +0530 Subject: UMTS In-Reply-To: <4B18FB43.2060809@gmail.com> References: <4b177619.mirider@mirider.augusta.de> <20091204055058.GE6865@prithivi.gnumonks.org> <4B18FB43.2060809@gmail.com> Message-ID: <20091204184418.GE3653@prithivi.gnumonks.org> On Fri, Dec 04, 2009 at 01:06:27PM +0100, Nordin wrote: > Are there any plans for OpenBSC supporting 3G? Cause I've heard > ip.access also sells nanoBTSs for 3G. yes, they have 3G devices, but I suspect they are even more expensive. I have not yet seen one. Dieter and me have been playing with different 3G hardware that is available cheaper, but we had to postpone any future work on it due to the fact that the RANAP protocol is ASN.1 in PER aligned encoding and there are no open source tools for C that support this. In fact, the only tools for that encoding that we could find were for Erlang. So until somebody implements some tools for that encoding, it's unlikely that we will be able to continue. I think for Dieter, Holger and myself currently other topics like GPRS support and working on a MS-side stack have higher preference. However, if somebody had useable asn.1 tools for PER unaligned, to be used in C language, I'm more than happy to work on 3G support. It's not all that different from GSM anyway, just many things were renamed ;) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dburgess at jcis.net Fri Dec 4 23:12:14 2009 From: dburgess at jcis.net (David A. Burgess) Date: Fri, 4 Dec 2009 15:12:14 -0800 Subject: Issues on initial setup with BS-11 In-Reply-To: <20091204055058.GE6865@prithivi.gnumonks.org> References: <4b177619.mirider@mirider.augusta.de> <20091204055058.GE6865@prithivi.gnumonks.org> Message-ID: Interesting observation on the nanoBTS because I have definitely seen it used that way. I am fairly certain that the CellXion DX/GX systems, marketed by Datong and at the heart of the MMI v. CellXion lawsuit, were based on the IP Access nanoBTS. Even if I'm wrong on that particular model, I am sure that I have seen IP Access equipment used in that configuration. That was a few years ago, though. Is it possible that IP Access changed their firmware at some point to make IMSI-catching more difficult? On Dec 3, 2009, at 9:50 PM, Harald Welte wrote: > On Thu, Dec 03, 2009 at 01:07:56AM -0800, David A. Burgess wrote: > >> I don't know if that's valid by the spec or not, but it's part of a >> pretty standard configuration in IMSI-catchers: CCCH+SDCCH4 + >> 6*SDCCH8 + TCH/F. That maximizes location updating capacity and >> leaves one TCH/F for other ... mischief. Most of those >> IMSI-catchers are based on commercial mini/nano-BTS equipment. > > Unfortunately that combination is not supported by either the BS-11 > nor the > ip.access nanoBTS. Maybe they have a special BTS firmware image > for the > nanoBTS to do that... > > -- > - Harald Welte http:// > laforge.gnumonks.org/ > ====================================================================== > ====== > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 > 175-7 Ch. A6) David A. Burgess Kestrel Signal Processing, Inc. From s4dd at losers.yore.ma Thu Dec 3 09:26:48 2009 From: s4dd at losers.yore.ma (s4dd at losers.yore.ma) Date: Thu, 03 Dec 2009 09:26:48 +0000 Subject: Issues on initial setup with BS-11 In-Reply-To: <4b177619.mirider@mirider.augusta.de> References: <4b177619.mirider@mirider.augusta.de> Message-ID: <4B178458.9060803@losers.yore.ma> Hello Dieter, > I think the problem is the "Invalid Channel Combination!!!" > error message. Try to change "phys_chan_config" of timeslot > 1 from "SDCCH8" to "TCH/F". From my understanding of > verify_chan_comb() "SDCCH8" is not allowed on the same TRX that > already has "CCCH+SDCCH4" so I wonder why it is set in the > config file (this only applies to the BS11). Sorry, I don't > have a ready BS11 configuration at hand right now, so I can't > test it. > I'll give this a go and response ASAP! -Paul From paul at dolan.ie Thu Dec 3 17:51:45 2009 From: paul at dolan.ie (Paul Dolan) Date: Thu, 03 Dec 2009 17:51:45 +0000 Subject: Issues on initial setup with BS-11 In-Reply-To: <4B178458.9060803@losers.yore.ma> References: <4b177619.mirider@mirider.augusta.de> <4B178458.9060803@losers.yore.ma> Message-ID: <4B17FAB1.2060000@dolan.ie> Hello again gents, >> I think the problem is the "Invalid Channel Combination!!!" >> error message. Try to change "phys_chan_config" of timeslot >> 1 from "SDCCH8" to "TCH/F". From my understanding of >> verify_chan_comb() "SDCCH8" is not allowed on the same TRX that >> already has "CCCH+SDCCH4" so I wonder why it is set in the >> config file (this only applies to the BS11). Sorry, I don't >> have a ready BS11 configuration at hand right now, so I can't >> test it. >> > I'll give this a go and response ASAP! > > -Paul > So, having changed the appropriate line in the default config the "Invalid Channel" error is not generated, however still no joy on viewing the mobile network from an ME. Here is the latest output from bsc_hack and the openbsc.cfg being used: bsc_hack output: 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) 1 device found id: 0 Dprotocols: 00000018 Bprotocols: 0000000e protocol: 4 nrbchan: 30 name: hfc-e1.1 activate bchan activate bchan bootstrapping OML for BTS 0 <0020> abis_nm.c:1724 Set BTS Attr (bts=0) <0020> abis_nm.c:1741 Set TRX Attr (bts=0,trx=0) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=0) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=1) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=1) E1=(0,2,1) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=2) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=2) E1=(0,2,2) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=3) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=3) E1=(0,2,3) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=4) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=4) E1=(0,3,0) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=5) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=5) E1=(0,3,1) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=6) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=6) E1=(0,3,2) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=7) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=7) E1=(0,3,3) <0020> abis_nm.c:606 OC=SITE MANAGER(00) INST=(ff,ff,ff) Software Activated Report <0020> abis_nm.c:985 LMT Event LOGON Level=2 Username=FACTORY bootstrapping RSL for BTS/TRX (0/0) using MCC=1 MNC=1 BSIC=63 TSC=7 <0020> abis_nm.c:985 LMT Event LOGOFF Level=2 Username=FACTORY **************************************************************** openbsc.cfg: ! ! 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 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 123 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 TCH/F e1 line 0 timeslot 2 sub-slot 1 timeslot 2 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 2 timeslot 3 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 3 timeslot 4 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 0 timeslot 5 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 1 timeslot 6 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 2 timeslot 7 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 3 ************************************************* Any other ideas/things to try/etc. would be greatly appreciated! -Paul From s4dd at losers.yore.ma Thu Dec 3 21:55:04 2009 From: s4dd at losers.yore.ma (s4dd at losers.yore.ma) Date: Thu, 03 Dec 2009 21:55:04 +0000 Subject: Issues on initial setup with BS-11 In-Reply-To: <4B178458.9060803@losers.yore.ma> References: <4b177619.mirider@mirider.augusta.de> <4B178458.9060803@losers.yore.ma> Message-ID: <4B1833B8.8070608@losers.yore.ma> Hello again gents, >> I think the problem is the "Invalid Channel Combination!!!" >> error message. Try to change "phys_chan_config" of timeslot >> 1 from "SDCCH8" to "TCH/F". From my understanding of >> verify_chan_comb() "SDCCH8" is not allowed on the same TRX that >> already has "CCCH+SDCCH4" so I wonder why it is set in the >> config file (this only applies to the BS11). Sorry, I don't >> have a ready BS11 configuration at hand right now, so I can't >> test it. >> > I'll give this a go and response ASAP! > > -Paul > So, having changed the appropriate line in the default config the "Invalid Channel" error is not generated, however still no joy on viewing the mobile network from an ME. Here is the latest output from bsc_hack and the openbsc.cfg being used: bsc_hack output: 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) 1 device found id: 0 Dprotocols: 00000018 Bprotocols: 0000000e protocol: 4 nrbchan: 30 name: hfc-e1.1 activate bchan activate bchan bootstrapping OML for BTS 0 <0020> abis_nm.c:1724 Set BTS Attr (bts=0) <0020> abis_nm.c:1741 Set TRX Attr (bts=0,trx=0) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=0) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=1) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=1) E1=(0,2,1) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=2) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=2) E1=(0,2,2) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=3) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=3) E1=(0,2,3) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=4) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=4) E1=(0,3,0) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=5) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=5) E1=(0,3,1) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=6) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=6) E1=(0,3,2) <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=7) <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=7) E1=(0,3,3) <0020> abis_nm.c:606 OC=SITE MANAGER(00) INST=(ff,ff,ff) Software Activated Report <0020> abis_nm.c:985 LMT Event LOGON Level=2 Username=FACTORY bootstrapping RSL for BTS/TRX (0/0) using MCC=1 MNC=1 BSIC=63 TSC=7 <0020> abis_nm.c:985 LMT Event LOGOFF Level=2 Username=FACTORY **************************************************************** openbsc.cfg: ! ! 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 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 123 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 TCH/F e1 line 0 timeslot 2 sub-slot 1 timeslot 2 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 2 timeslot 3 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 3 timeslot 4 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 0 timeslot 5 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 1 timeslot 6 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 2 timeslot 7 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 3 ************************************************* Any other ideas/things to try/etc. would be greatly appreciated! -Paul From laforge at gnumonks.org Sun Dec 6 05:19:34 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 6 Dec 2009 10:49:34 +0530 Subject: Issues on initial setup with BS-11 In-Reply-To: <4B1833B8.8070608@losers.yore.ma> References: <4b177619.mirider@mirider.augusta.de> <4B178458.9060803@losers.yore.ma> <4B1833B8.8070608@losers.yore.ma> Message-ID: <20091206051934.GF26466@prithivi.gnumonks.org> On Thu, Dec 03, 2009 at 09:55:04PM +0000, s4dd at losers.yore.ma wrote: > bootstrapping OML for BTS 0 > <0020> abis_nm.c:1724 Set BTS Attr (bts=0) > <0020> abis_nm.c:1741 Set TRX Attr (bts=0,trx=0) > <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=0) > <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=1) > <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=1) E1=(0,2,1) > <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=2) > <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=2) E1=(0,2,2) > <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=3) > <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=3) E1=(0,2,3) > <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=4) > <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=4) E1=(0,3,0) > <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=5) > <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=5) E1=(0,3,1) > <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=6) > <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=6) E1=(0,3,2) > <0020> abis_nm.c:1821 Set Chan Attr (bts=0,trx=0,ts=7) > <0020> abis_nm.c:1704 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=7) E1=(0,3,3) > <0020> abis_nm.c:606 OC=SITE MANAGER(00) INST=(ff,ff,ff) Software > Activated Report > <0020> abis_nm.c:985 LMT Event LOGON Level=2 Username=FACTORY > bootstrapping RSL for BTS/TRX (0/0) using MCC=1 MNC=1 BSIC=63 TSC=7 > <0020> abis_nm.c:985 LMT Event LOGOFF Level=2 Username=FACTORY This means you never get to the "bootstrapping RSL" point. The organization and maintenance layer seems to work fine in both ways (the REPORT is from the BTS, the other messages are sent from OpenBSC). However, the RSL link does not seem to come up... you could experiment with generating a pcap file from openbsc and send that along with your bug report. -- - 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 Dec 6 07:05:35 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 6 Dec 2009 12:35:35 +0530 Subject: Issues on initial setup with BS-11 In-Reply-To: <20091206051934.GF26466@prithivi.gnumonks.org> References: <4b177619.mirider@mirider.augusta.de> <4B178458.9060803@losers.yore.ma> <4B1833B8.8070608@losers.yore.ma> <20091206051934.GF26466@prithivi.gnumonks.org> Message-ID: <20091206070535.GI26466@prithivi.gnumonks.org> On Sun, Dec 06, 2009 at 10:49:34AM +0530, Harald Welte wrote: > > <0020> abis_nm.c:985 LMT Event LOGON Level=2 Username=FACTORY > > bootstrapping RSL for BTS/TRX (0/0) using MCC=1 MNC=1 BSIC=63 TSC=7 > > <0020> abis_nm.c:985 LMT Event LOGOFF Level=2 Username=FACTORY > > This means you never get to the "bootstrapping RSL" point. The organization > and maintenance layer seems to work fine in both ways (the REPORT is from the > BTS, the other messages are sent from OpenBSC). However, the RSL link > does not seem to come up... you could experiment with generating a pcap file > from openbsc and send that along with your bug report. Erm, I must have been too tired to see the line in your log. Forget my comment, it actually gets to the "bootstrapping RSL". -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From spaar at mirider.augusta.de Thu Dec 3 10:46:39 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Thu, 03 Dec 2009 10:46:39 Subject: Issues on initial setup with BS-11 Message-ID: <4b17970f.mirider@mirider.augusta.de> Hello David, On Thu, 3 Dec 2009 01:07:56 -0800, "David A. Burgess" wrote: > > I don't know if that's valid by the spec or not, but it's part of a > pretty standard configuration in IMSI-catchers: CCCH+SDCCH4 + > 6*SDCCH8 + TCH/F. That maximizes location updating capacity and > leaves one TCH/F for other ... mischief. Most of those IMSI-catchers > are based on commercial mini/nano-BTS equipment. Thanks for this input. I think this a limitation of the BS11 only, I have read that there are some limitations related to the SDCCH/8 of the BS11: - only one SDCCH/8 per TRX - not allowed together with SDCCH/4 on BCCH-TRX Maybe the BS11 does not have enough processing power to handle it ? Of course it could be that the documentation is wrong and it would work, I have not yet tried it. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From spaar at mirider.augusta.de Sun Dec 6 08:23:37 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Sun, 06 Dec 2009 08:23:37 Subject: Issues on initial setup with BS-11 Message-ID: <4b1b6a09.mirider@mirider.augusta.de> Hello Paul, On Thu, 03 Dec 2009 17:51:45 +0000, "Paul Dolan" wrote: > > Any other ideas/things to try/etc. would be greatly appreciated! Can you check the "PLL set" and "PLL work" values with bs11_config ? If the BS-11 is locked to the E1 clock, it could be that the clock of the BS-11 is too far away from the correct value so that a phone will only find the official networks but not the one of the BS-11. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From jmenon86 at gmail.com Fri Dec 4 11:40:00 2009 From: jmenon86 at gmail.com (Jai Menon) Date: Fri, 4 Dec 2009 17:10:00 +0530 Subject: ip.access BTS IML dissector for wireshark Message-ID: <20091204114000.GA13093@outrax.event.foss.in> Hi, Attached is a direct port of the IML dissector code from the ip.access code to wireshark SVN head with a few changes to make it work with the current API. This was done as part of Harald's GSM workout during FOSS.IN and he suggested I post it to this list. I haven't really tested this code since I dont have access to IML traces, but assuming the original code worked, this one should too. Hope this is possibly useful to someone :) -- Jai Menon -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa_iml.patch Type: text/x-patch Size: 25163 bytes Desc: not available URL: From laforge at gnumonks.org Sun Dec 6 06:59:40 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 6 Dec 2009 12:29:40 +0530 Subject: ip.access BTS IML dissector for wireshark In-Reply-To: <20091204114000.GA13093@outrax.event.foss.in> References: <20091204114000.GA13093@outrax.event.foss.in> Message-ID: <20091206065940.GH26466@prithivi.gnumonks.org> Dear Jai, thanks for your work. On Fri, Dec 04, 2009 at 05:10:00PM +0530, Jai Menon wrote: > Attached is a direct port of the IML dissector code from the ip.access > code to wireshark SVN head with a few changes to make it work with the > current API. This was done as part of Harald's GSM workout during > FOSS.IN and he suggested I post it to this list. I haven't really > tested this code since I dont have access to IML traces, but assuming > the original code worked, this one should too. Great. Anyone who has two nanoBTS can set up a multi-TRX BTS and trace the IML protocol between those two BTS. This pcap should be possible to decode using this dissector. Before we can submit this mainline, we need to clean up packet-gsm.h though. ip.access has one header file (packet-gsm.h) where they define many aspects of various different GSM protocols. This is not really how things are done in upstream wireshark. Thus, we need to remove everything that is not IML related, like > +#define GSM0408_HEADER_LEN 2 > +#define GSM0808_HEADER_LEN 1 > +#define IPA_HEADER_LEN 3 > +#define IPA_UDP_HEADER_LEN 4 04.08, 08.08, IPA: All not relevant for IML > +#define MAX_DATA_STR 5 > + > +/* defines for the Signalling over IP streams */ > +#define OML_STREAM 255 > +#define CTRL_STREAM 254 > +#define SCCP_STREAM 253 > +#define SPIRIT_STREAM 253 > +#define BSC_MGMT_STREAM 251 > +#define BSC_SUBAGENT_STREAM 250 > +#define SIGTRAN_STREAM 249 > +#define FRIP_STREAM 248 > +#define GNAT_STREAM 247 > +#define IML_STREAM 129 > +#define RSL_STREAM_MAX 32 > +/* defines for the fixed TCP/UDP port numbers */ > +#define TCP_PORT_IPA_OML 3002 > +#define TCP_PORT_IPA_RSL 3003 > +#define TCP_PORT_IPA_2NDOML 3006 > +#define TCP_PORT_IPA_HW_MON 3007 > +#define TCP_PORT_IPA_FRIP 3008 > +#define TCP_PORT_IPA_SPIRIT 3008 > +#define TCP_PORT_IPA_GNAT 3009 > +#define TCP_PORT_IPA_BSCMGMT 3010 > +#define TCP_PORT_IPA_A_IF 3011 > +#define TCP_PORT_IPA_SITE_IML 3013 > +#define TCP_PORT_IPA_BTS_IML 3014 > +#define UDP_PORT_IPA 3006 > + those are all IPA related, I think. so they can be removed. > +/* defines for the GSMSTAT interface */ > +#define GSMSTAT_INTERFACE_NULL -1 > +#define GSMSTAT_INTERFACE_A 0 > +#define GSMSTAT_INTERFACE_A_BIS 1 > +#define GSMSTAT_INTERFACE_GB 2 > +#define GSMSTAT_INTERFACE_MAX 2 /* until we add GB! */ > + > +#define GSMSTAT_PROTO_NULL -1 > +#define GSMSTAT_PROTO_GSM0408 1 > +#define GSMSTAT_PROTO_GSM0808 2 > +#define GSMSTAT_PROTO_GSM0858 3 > +#define GSMSTAT_PROTO_GSM0818 4 > +#define GSMSTAT_PROTO_GSM1221 5 > + > +#define GSMSTAT_PD_NULL -1 gsmstat can also be removed. > +/* 04.08 Protocol Discriminator values */ > +#define GSM0408_PD_VGCS 0x0 > +#define GSM0408_PD_VBS 0x1 > +#define GSM0408_PD_PDSS1 0x2 > +#define GSM0408_PD_CC 0x3 > +#define GSM0408_PD_PDSS2 0x4 > +#define GSM0408_PD_MM 0x5 > +#define GSM0408_PD_RR 0x6 > +#define GSM0408_PD_GMM 0x8 > +#define GSM0408_PD_SMS 0x9 > +#define GSM0408_PD_SM 0xa > +#define GSM0408_PD_SS 0xb > +#define GSM0408_PD_LS 0xc as the comment implies, this is all 04.08 and we don't need it in IML > +/* RTP Paylod types in use for A-bis */ > +#define RTP_PAYLOAD_GSM_FR 0 > +#define RTP_PAYLOAD_GSM_EFR 1 > +#define RTP_PAYLOAD_GSM_AMR 2 > +#define RTP_PAYLOAD_GSM_CSD 3 > +#define RTP_PAYLOAD_GSM_NANO_GSM_MUX 4 etc. I could now continue for the whole file, but I think you get what I mean :) Would you be able to clean this further up and do another round of patch submission? Thanks again for your help. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jmenon86 at gmail.com Mon Dec 7 18:41:05 2009 From: jmenon86 at gmail.com (Jai Menon) Date: Tue, 8 Dec 2009 00:11:05 +0530 Subject: ip.access BTS IML dissector for wireshark In-Reply-To: <20091206065940.GH26466@prithivi.gnumonks.org> References: <20091204114000.GA13093@outrax.event.foss.in> <20091206065940.GH26466@prithivi.gnumonks.org> Message-ID: <20091207184105.GA24665@outrax> Hi Harald, On Sun, Dec 06, 2009 at 12:29:40PM +0530, Harald Welte wrote: > Dear Jai, > > thanks for your work. > > On Fri, Dec 04, 2009 at 05:10:00PM +0530, Jai Menon wrote: > > > Attached is a direct port of the IML dissector code from the ip.access > > code to wireshark SVN head with a few changes to make it work with the > > current API. This was done as part of Harald's GSM workout during > > FOSS.IN and he suggested I post it to this list. I haven't really > > tested this code since I dont have access to IML traces, but assuming > > the original code worked, this one should too. > > Great. Anyone who has two nanoBTS can set up a multi-TRX BTS and > trace the IML protocol between those two BTS. This pcap should be possible > to decode using this dissector. Also, if someone could upload/post the resulting pcap, that would be useful for local testing. > Before we can submit this mainline, we need to clean up packet-gsm.h though. > > ip.access has one header file (packet-gsm.h) where they define many aspects of > various different GSM protocols. This is not really how things are done > in upstream wireshark. > > Thus, we need to remove everything that is not IML related, like [...] > etc. I could now continue for the whole file, but I think you > get what I mean :) Indeed :) the first attempt was quite naive as in I wanted to just get it to build cleanly with the new API. > Would you be able to clean this further up and do another round of patch > submission? Thanks again for your help. Sure thing. Before I go ahead and do that, I wanted to know whats the preferred approach here. The packet-gsm_ipa dissector code, for example, doesn't #include any additional headers. Should the iml code be modified so that all typedefs like ie_def_t are present in the one source file? Or should the packet-gsm.h header be trimmed down to contain only what the iml code requires? If it is cleaned up to remove unused stuff, should the name then be changed to packet-gsm_iml.h or something similar? Thanks for the comments. -- Jai Menon From womax at gmx.ch Fri Dec 4 13:20:44 2009 From: womax at gmx.ch (WoMax) Date: Fri, 4 Dec 2009 14:20:44 +0100 Subject: UMTS Message-ID: <0A62D3CA3B94437B81314FC7253373EA@HAL2008> If there is a solution for UMTS (W-CDMA) coming, we don't need the expensive nanoBTS anymore. BTW I've still one for sale ... see at http://umts.zerber.us There are cheap W-CDMA BTS's out there, like Netgear DVG834GH, AT&T 3G Microcell, Alcatel-Lucent 9365 or the Vodafone Access Gateway you can buy in England for just 160 GBP each. All the femtocell's I know have built in GPS for timebase and security reason, so there is a lot to do for our purpose ... I guess the future is W-CDMA and I hope there will be openUMTS available soon ;-) Regards from Switzerland From laforge at gnumonks.org Tue Dec 22 13:04:44 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 22 Dec 2009 14:04:44 +0100 Subject: UMTS In-Reply-To: <0A62D3CA3B94437B81314FC7253373EA@HAL2008> References: <0A62D3CA3B94437B81314FC7253373EA@HAL2008> Message-ID: <20091222130444.GD14330@prithivi.gnumonks.org> Hi WoMax, On Fri, Dec 04, 2009 at 02:20:44PM +0100, WoMax wrote: > If there is a solution for UMTS (W-CDMA) coming, we don't need the expensive > nanoBTS anymore. Yes and no. UMTS Node-B's and Home-Node-B are 3G only, i.e. will not work with the > 66% of all the phones that are actively in use even in developed countries. > BTW I've still one for sale ... see at http://umts.zerber.us I would like to kindly ask you to refrain from further advertising your product sales on this mailing list. I think people will easily find your messages in the archives. And no, I have no commercial motivation. BS-11 are sold out, and I think even for those I've never really actively made advertisements on this list. > There are cheap W-CDMA BTS's out there, like Netgear DVG834GH, AT&T 3G > Microcell, Alcatel-Lucent 9365 or the Vodafone Access Gateway you can buy in > England for just 160 GBP each. We're very well aware about this. Dieter, myself and others have been playing around with them a bit. Biggest issue is that there is no standard protocol like A-bis, and every vendor seems to have its own proprietary hacks. There actually is a IuH standard protocol, but that doesn't seem to be used much [yet?]. > All the femtocell's I know have built in GPS for timebase and security > reason, so there is a lot to do for our purpose ... At least one in the list that you have indicated above does not have GPS but rather a GSM modem for that purpsoe. Also, the security is implemented in the core network (HMB gateway or beyond), not in the femtocells themselves. > I guess the future is W-CDMA and I hope there will be openUMTS available > soon ;-) I'm not so sure. The capacity of those units is typically also very limited, as well as the transmit power... it always depends on the application. The biggest challenge for working with 3G is ASN.1 PER, as I have indicated in my blog. The only open source asn.1 tool that support all the required language features, as well as PER aligned and unaligned encoding is asn1ct, part of the Erlang distribution. And while Erlang might be a great programming language, it is exotic and not many people know how to program it. So unless somebody will implement the RNC + MSC functionality in Erlang, or write useful asn.1 tools for C and adapt OpenBSC, I don't see much progress in the Open Soruce 3G protocols area... 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 anandrm at gmail.com Sat Dec 5 09:35:18 2009 From: anandrm at gmail.com (Anand Raj Manickam) Date: Sat, 5 Dec 2009 15:05:18 +0530 Subject: packet_gsm-ipa update patch Message-ID: <4d5b51f60912050135m34891a9fm8905f32c0f51bd14@mail.gmail.com> Hi , Please find the patch for packet_gsm-ipa.c attached . This patch updates few fields. Thanks, Anand -------------- next part -------------- A non-text attachment was scrubbed... Name: gsm_ipa.patch Type: text/x-patch Size: 3547 bytes Desc: not available URL: From laforge at gnumonks.org Sun Dec 6 07:07:48 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 6 Dec 2009 12:37:48 +0530 Subject: packet_gsm-ipa update patch In-Reply-To: <4d5b51f60912050135m34891a9fm8905f32c0f51bd14@mail.gmail.com> References: <4d5b51f60912050135m34891a9fm8905f32c0f51bd14@mail.gmail.com> Message-ID: <20091206070748.GJ26466@prithivi.gnumonks.org> On Sat, Dec 05, 2009 at 03:05:18PM +0530, Anand Raj Manickam wrote: > Hi , > Please find the patch for packet_gsm-ipa.c attached . thanks. I'm looking forward to the follow-up patches for further completing packet-gsm_ipa! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From stefreak at stefreak.de Sat Dec 5 11:58:34 2009 From: stefreak at stefreak.de (Steffen 'stefreak' Neubauer) Date: Sat, 5 Dec 2009 12:58:34 +0100 Subject: [PATCH] bugfix: additional functionality indicator only appears in TP_VPF_ENHANCED Message-ID: <20091205125834.476b821c@stefreak.de> The patch is attached ("bugfix"). You can simply merge the stefreak/trivia branch (but there is one more change in it, see the second patch attached. abis_nm.c was executable, that's a really trivial change). Greetings, Steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: bugfix Type: application/octet-stream Size: 471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: trivial Type: application/octet-stream Size: 91 bytes Desc: not available URL: From laforge at gnumonks.org Sun Dec 6 06:54:26 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 6 Dec 2009 12:24:26 +0530 Subject: [PATCH] bugfix: additional functionality indicator only appears in TP_VPF_ENHANCED In-Reply-To: <20091205125834.476b821c@stefreak.de> References: <20091205125834.476b821c@stefreak.de> Message-ID: <20091206065426.GG26466@prithivi.gnumonks.org> On Sat, Dec 05, 2009 at 12:58:34PM +0100, Steffen 'stefreak' Neubauer wrote: > The patch is attached ("bugfix"). > > You can simply merge the stefreak/trivia branch (but there is one more > change in it, see the second patch attached. abis_nm.c was > executable, that's a really trivial change). both applied. thanks. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From stefreak at stefreak.de Sun Dec 6 13:20:00 2009 From: stefreak at stefreak.de (Steffen 'stefreak' Neubauer) Date: Sun, 6 Dec 2009 14:20:00 +0100 Subject: [PATCH] bugfix: additional functionality indicator only appears in TP_VPF_ENHANCED In-Reply-To: <20091206065426.GG26466@prithivi.gnumonks.org> References: <20091205125834.476b821c@stefreak.de> <20091206065426.GG26466@prithivi.gnumonks.org> Message-ID: <20091206142000.0f5f0380@stefreak.de> On Sun, 6 Dec 2009 12:24:26 +0530 Harald Welte wrote: > both applied. thanks. The bugfix isn't applied yet. Why don't you simply merge the branch? Greetings, Steffen From Axel at Walsleben.info Tue Dec 8 14:02:16 2009 From: Axel at Walsleben.info (Axel Walsleben) Date: Tue, 08 Dec 2009 15:02:16 +0100 Subject: nanoBTS 900 Message-ID: <4B1E5C68.8050702@Walsleben.info> Hi List, i am searching for a used or new nanoBTS. Best would be an 900Mhz Model, but i take 'everything' i can get. I tried the Haralds Contact, but from there i didn't get any response. It seems that they are not willing to sell anything. :( Regards Axel From fabrice.poundeu at smail.inf.fh-bonn-rhein-sieg.de Wed Dec 9 13:58:22 2009 From: fabrice.poundeu at smail.inf.fh-bonn-rhein-sieg.de (Fabrice Ismael Poundeu Tchouatieu) Date: Wed, 09 Dec 2009 14:58:22 +0100 Subject: somes problems running OpenBSC with nanoBTS (1800) Message-ID: <20091209145822.dj4fhl8no0scgkko@www4.inf.fh-bonn-rhein-sieg.de> Hye everyone, i'm trying to build a small GSM Network using OpenBSC and nanoBTS. After the start of bsc_hack, when i try to scanned the network with my mobile station, i do find the right network. But when i try to register into this network, i'm not coming through. It's the first time that i'm trying to used OpenBSC and i do not exactly known how it works. below, a part of the output coming out after the start of bsc_hack: <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS. DB: Failed to find the Subscriber. '0' '262##########' DB: Failed to find the Subscriber. '0' '262##########' DB: New Subscriber: ID 28, IMSI 262########## DB: Allocated extension 43234 for IMSI 262##########. <0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 DATA INDICATION <0004> gsm_04_08.c:948 IDENTITY RESPONSE: mi_type=0x02 MI(35#############) DB: New Equipment: ID 124, IMEI 35############# DB: New EquipmentWatch: ID 124, IMSI 262##########, IMEI 35############# DB: Sync Equipment IMEI=35#############, classmark1=30 <0010> abis_rsl.c:1273 Activating ARFCN(514) TS(0) SS(1) lctype SDCCH chan_nr=0x28 r=LOCATION_UPDATE ra=0x10 <0010> abis_rsl.c:1088 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 CHANNEL ACTIVATE ACK <0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 sapi=0 ESTABLISH INDICATION <0004> gsm_04_08.c:1402 LOCATION UPDATING REQUEST: mi_type=0x04 MI(23########) type=NORMAL <0002> gsm_04_08.c:293 lchan (bts=0,trx=0,ts=0,ch=1) increases usage to: 1 <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS. DB: Found Subscriber: ID 28, IMSI 262############, NAME '', TMSI 42########, EXTEN '43234', LAC 0, AUTH 0 DBI: The requested variable type does not match what libdbi thinks it should be libdbi: dbi_result_get_int_idx: field `classmark1` is not integer type <0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 DATA INDICATION <0004> gsm_04_08.c:948 IDENTITY RESPONSE: mi_type=0x02 MI(35#############) DB: Updated EquipmentWatch: ID 124, IMSI 262############, IMEI 35############# DB: Sync Equipment IMEI=35#############, classmark1=30, classmark2=13 25 , classmark3=13 25 <0010> abis_rsl.c:1273 Activating ARFCN(514) TS(0) SS(1) lctype SDCCH chan_nr=0x28 r=LOCATION_UPDATE ra=0x06 <0010> abis_rsl.c:1088 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 CHANNEL ACTIVATE ACK <0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 sapi=0 ESTABLISH INDICATION <0004> gsm_04_08.c:1402 LOCATION UPDATING REQUEST: mi_type=0x01 MI(262############) type=NORMAL <0002> gsm_04_08.c:293 lchan (bts=0,trx=0,ts=0,ch=1) increases usage to: 1 can someone please explains me if those outputs (about the Subscriber ID '28') are OK? Best regards; -- Fabrice Ismael Poundeu Tchouatieu ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From mailinglists at hellercom.de Wed Dec 9 14:54:27 2009 From: mailinglists at hellercom.de (Bjoern Heller) Date: Wed, 9 Dec 2009 15:54:27 +0100 Subject: somes problems running OpenBSC with nanoBTS (1800) In-Reply-To: <20091209145822.dj4fhl8no0scgkko@www4.inf.fh-bonn-rhein-sieg.de> References: <20091209145822.dj4fhl8no0scgkko@www4.inf.fh-bonn-rhein-sieg.de> Message-ID: <21D809AB-A9AE-41FB-AA08-F19AF59195C2@hellercom.de> Hi, You need to open registration. telnet localhost 4242 and then enable configure terminal network auth policy accept-all regards tec Am 09.12.2009 um 14:58 schrieb Fabrice Ismael Poundeu Tchouatieu: > Hye everyone, > > i'm trying to build a small GSM Network using OpenBSC and nanoBTS. After the start of bsc_hack, when i try to scanned the network with my mobile station, i do find the right network. But when i try to register into this network, i'm not coming through. It's the first time that i'm trying to used OpenBSC and i do not exactly known how it works. > > below, a part of the output coming out after the start of bsc_hack: > > <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS. > DB: Failed to find the Subscriber. '0' '262##########' > DB: Failed to find the Subscriber. '0' '262##########' > DB: New Subscriber: ID 28, IMSI 262########## > DB: Allocated extension 43234 for IMSI 262##########. > <0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 DATA INDICATION > <0004> gsm_04_08.c:948 IDENTITY RESPONSE: mi_type=0x02 MI(35#############) > DB: New Equipment: ID 124, IMEI 35############# > DB: New EquipmentWatch: ID 124, IMSI 262##########, IMEI 35############# > DB: Sync Equipment IMEI=35#############, classmark1=30 > <0010> abis_rsl.c:1273 Activating ARFCN(514) TS(0) SS(1) lctype SDCCH chan_nr=0x28 r=LOCATION_UPDATE ra=0x10 > <0010> abis_rsl.c:1088 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 CHANNEL ACTIVATE ACK > <0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 sapi=0 ESTABLISH INDICATION > <0004> gsm_04_08.c:1402 LOCATION UPDATING REQUEST: mi_type=0x04 MI(23########) type=NORMAL <0002> gsm_04_08.c:293 lchan (bts=0,trx=0,ts=0,ch=1) increases usage to: 1 > > > <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS. > DB: Found Subscriber: ID 28, IMSI 262############, NAME '', TMSI 42########, EXTEN '43234', LAC 0, AUTH 0 > DBI: The requested variable type does not match what libdbi thinks it should be > libdbi: dbi_result_get_int_idx: field `classmark1` is not integer type > <0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 DATA INDICATION > <0004> gsm_04_08.c:948 IDENTITY RESPONSE: mi_type=0x02 MI(35#############) > DB: Updated EquipmentWatch: ID 124, IMSI 262############, IMEI 35############# > DB: Sync Equipment IMEI=35#############, classmark1=30, classmark2=13 25 , classmark3=13 25 > <0010> abis_rsl.c:1273 Activating ARFCN(514) TS(0) SS(1) lctype SDCCH chan_nr=0x28 r=LOCATION_UPDATE ra=0x06 > <0010> abis_rsl.c:1088 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 CHANNEL ACTIVATE ACK > <0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 sapi=0 ESTABLISH INDICATION > <0004> gsm_04_08.c:1402 LOCATION UPDATING REQUEST: mi_type=0x01 MI(262############) type=NORMAL <0002> gsm_04_08.c:293 lchan (bts=0,trx=0,ts=0,ch=1) increases usage to: 1 > > can someone please explains me if those outputs (about the Subscriber ID '28') are OK? > > Best regards; > > -- > Fabrice Ismael Poundeu Tchouatieu > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bj?rn Heller Jabber: tec at jabber.hellercom.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Dec 9 15:02:00 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 9 Dec 2009 16:02:00 +0100 Subject: somes problems running OpenBSC with nanoBTS (1800) In-Reply-To: <20091209145822.dj4fhl8no0scgkko@www4.inf.fh-bonn-rhein-sieg.de> References: <20091209145822.dj4fhl8no0scgkko@www4.inf.fh-bonn-rhein-sieg.de> Message-ID: <20091209150200.GY4292@prithivi.gnumonks.org> On Wed, Dec 09, 2009 at 02:58:22PM +0100, Fabrice Ismael Poundeu Tchouatieu wrote: > i'm trying to build a small GSM Network using OpenBSC and nanoBTS. > After the start of bsc_hack, when i try to scanned the network with > my mobile station, i do find the right network. But when i try to > register into this network, i'm not coming through. It's the first > time that i'm trying to used OpenBSC and i do not exactly known how > it works. Everything seems to work fine. You simply did not authorize your subscriber[s] to join the network yet. This is what we do using the 'authorized' field in the 'subscriber' SQL table. Once a subscriber is authorized, it should get permission to join the 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 fabrice.poundeu at smail.inf.fh-bonn-rhein-sieg.de Wed Dec 9 15:49:22 2009 From: fabrice.poundeu at smail.inf.fh-bonn-rhein-sieg.de (Fabrice Ismael Poundeu Tchouatieu) Date: Wed, 09 Dec 2009 16:49:22 +0100 Subject: somes problems running OpenBSC with nanoBTS (1800) In-Reply-To: <20091209150200.GY4292@prithivi.gnumonks.org> References: <20091209145822.dj4fhl8no0scgkko@www4.inf.fh-bonn-rhein-sieg.de> <20091209150200.GY4292@prithivi.gnumonks.org> Message-ID: <20091209164922.9d0nf4pe888sgk88@www4.inf.fh-bonn-rhein-sieg.de> Quoting Harald Welte : > On Wed, Dec 09, 2009 at 02:58:22PM +0100, Fabrice Ismael Poundeu > Tchouatieu wrote: > >> i'm trying to build a small GSM Network using OpenBSC and nanoBTS. >> After the start of bsc_hack, when i try to scanned the network with >> my mobile station, i do find the right network. But when i try to >> register into this network, i'm not coming through. It's the first >> time that i'm trying to used OpenBSC and i do not exactly known how >> it works. > > Everything seems to work fine. You simply did not authorize your > subscriber[s] > to join the network yet. This is what we do using the 'authorized' field in > the 'subscriber' SQL table. > > Once a subscriber is authorized, it should get permission to join > the network. > > Regards, > Harald > -- --> Thanks That was exactly the problem. -- Fabrice Ismael Poundeu Tchouatieu ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From bouchtaoui at gmail.com Wed Dec 9 15:02:03 2009 From: bouchtaoui at gmail.com (Nordin) Date: Wed, 09 Dec 2009 16:02:03 +0100 Subject: somes problems running OpenBSC with nanoBTS (1800) In-Reply-To: <20091209145822.dj4fhl8no0scgkko@www4.inf.fh-bonn-rhein-sieg.de> References: <20091209145822.dj4fhl8no0scgkko@www4.inf.fh-bonn-rhein-sieg.de> Message-ID: <4B1FBBEB.9030802@gmail.com> Fabrice Ismael Poundeu Tchouatieu schreef: > Hye everyone, > > i'm trying to build a small GSM Network using OpenBSC and nanoBTS. > After the start of bsc_hack, when i try to scanned the network with my > mobile station, i do find the right network. But when i try to > register into this network, i'm not coming through. It's the first > time that i'm trying to used OpenBSC and i do not exactly known how it > works. You need to modify the config-file. Put under network the following: auth policy accept-all This will accept all MSs that want to register. From laforge at gnumonks.org Sat Dec 12 12:38:52 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 12 Dec 2009 13:38:52 +0100 Subject: somes problems running OpenBSC with nanoBTS (1800) In-Reply-To: <4B1FBBEB.9030802@gmail.com> References: <20091209145822.dj4fhl8no0scgkko@www4.inf.fh-bonn-rhein-sieg.de> <4B1FBBEB.9030802@gmail.com> Message-ID: <20091212123852.GQ5474@prithivi.gnumonks.org> On Wed, Dec 09, 2009 at 04:02:03PM +0100, Nordin wrote: > Fabrice Ismael Poundeu Tchouatieu schreef: > >Hye everyone, > > > >i'm trying to build a small GSM Network using OpenBSC and nanoBTS. > >After the start of bsc_hack, when i try to scanned the network > >with my mobile station, i do find the right network. But when i > >try to register into this network, i'm not coming through. It's > >the first time that i'm trying to used OpenBSC and i do not > >exactly known how it works. > > You need to modify the config-file. Put under network the following: > auth policy accept-all > > This will accept all MSs that want to register. Which is a very DANGEROUS mode of operation, as chances are high it will accept some phone that has lost signal or is on international roaming! So even if you have legal permission to operate your own gsm network (such as a test license), an accept-all BTS will likely interfere with commercial GSM networks in your vicinity and you will end up selectively denying service to people. This is punishable under criminal law in probably any country that I've ever heard of! So pleaes use extreme caution and never run an accept-all network on a non-barred cell outside a faraday cage. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dburgess at jcis.net Sat Dec 12 19:26:08 2009 From: dburgess at jcis.net (David A. Burgess) Date: Sat, 12 Dec 2009 11:26:08 -0800 Subject: somes problems running OpenBSC with nanoBTS (1800) In-Reply-To: <20091212123852.GQ5474@prithivi.gnumonks.org> References: <20091209145822.dj4fhl8no0scgkko@www4.inf.fh-bonn-rhein-sieg.de> <4B1FBBEB.9030802@gmail.com> <20091212123852.GQ5474@prithivi.gnumonks.org> Message-ID: Harald - I agree with your comments in the strongest terms. DO NOT DO THIS UNLESS YOU ARE ABSOLUTELY SURE OF ITS EFFECT ON THE LOCAL CELLULAR ENVIRONMENT. Even if you do not directly interfere with the carrier's spectrum, you can still interfere with their service. Remember that you are interacting with the cellular carrier, indirectly, every time you exchange phones with them. -- David On Dec 12, 2009, at 4:38 AM, Harald Welte wrote: > On Wed, Dec 09, 2009 at 04:02:03PM +0100, Nordin wrote: >> Fabrice Ismael Poundeu Tchouatieu schreef: >>> Hye everyone, >>> >>> i'm trying to build a small GSM Network using OpenBSC and nanoBTS. >>> After the start of bsc_hack, when i try to scanned the network >>> with my mobile station, i do find the right network. But when i >>> try to register into this network, i'm not coming through. It's >>> the first time that i'm trying to used OpenBSC and i do not >>> exactly known how it works. >> >> You need to modify the config-file. Put under network the following: >> auth policy accept-all >> >> This will accept all MSs that want to register. > > Which is a very DANGEROUS mode of operation, as chances are high it > will accept > some phone that has lost signal or is on international roaming! So > even if you > have legal permission to operate your own gsm network (such as a > test license), > an accept-all BTS will likely interfere with commercial GSM > networks in your > vicinity and you will end up selectively denying service to people. > > This is punishable under criminal law in probably any country that > I've ever > heard of! > > So pleaes use extreme caution and never run an accept-all network on a > non-barred cell outside a faraday cage. > > -- > - Harald Welte http:// > laforge.gnumonks.org/ > ====================================================================== > ====== > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 > 175-7 Ch. A6) David A. Burgess Kestrel Signal Processing, Inc. From laforge at gnumonks.org Sun Dec 13 08:07:41 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 13 Dec 2009 09:07:41 +0100 Subject: somes problems running OpenBSC with nanoBTS (1800) In-Reply-To: References: <20091209145822.dj4fhl8no0scgkko@www4.inf.fh-bonn-rhein-sieg.de> <4B1FBBEB.9030802@gmail.com> <20091212123852.GQ5474@prithivi.gnumonks.org> Message-ID: <20091213080741.GV5474@prithivi.gnumonks.org> David, On Sat, Dec 12, 2009 at 11:26:08AM -0800, David A. Burgess wrote: > I agree with your comments in the strongest terms. DO NOT DO THIS > UNLESS YOU ARE ABSOLUTELY SURE OF ITS EFFECT ON THE LOCAL CELLULAR > ENVIRONMENT. Thinking more about it, I've added a warning message to bsc_hack at startup if you run it in this mode. -- - 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 Dec 14 16:39:04 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 14 Dec 2009 17:39:04 +0100 Subject: Update on GSM network at 26C3 Message-ID: <20091214163904.GA12643@prithivi.gnumonks.org> Dear All, as you will know, we have applied for an experimental GSM license for the 26C3 (http://events.ccc.de/congress/2009/). Last week, the license was granted. However, only two ARFCN's have been granted (I applied for 8). As it turns out, this was a communication problem. Today they have acknowledged a third ARFCN. So we can have at least one single-TRX BTS on each floor. On wednesday they will determine whether we can have more than three, or if we'll have to live with three ARFCN only. If we get 6, it will be one dual-TRX BTS for each floor. If we get even more, the surplus ones can be used for random experiments. TODO items before 26C3 (for the next couple of days): * finish handover implementation (critical) * do some more testing with LCR integration (Andreas did it, but I also want to have more hands-on experience with it) * introduce log levels and/or per-subscriber tracing functionality to "see the signal among all the noise" while debugging problems in an otherwise busy network * ensure SMS implementation is more robust than at HAR * log all measurement reports to database for later analysis of handover performance. We could also get them from pcap files, so not strictly neccessary. Optional: * finish AMR-halfrate implementation, as this will increase our capacity. This includes dynamically selecting the codec that is used for each call. I don't think we'll manage finishing this, especially with the LCR integration. Standalone might be possible - but that is useless for 26C3 -- - 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 Mon Dec 14 22:18:16 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 14 Dec 2009 23:18:16 +0100 Subject: Update on GSM network at 26C3 In-Reply-To: <20091214163904.GA12643@prithivi.gnumonks.org> References: <20091214163904.GA12643@prithivi.gnumonks.org> Message-ID: <866320f70912141418q22202895taf5256eeccf756ce@mail.gmail.com> Hi, TODO items before 26C3 (for the next couple of days): > * finish handover implementation (critical) > * do some more testing with LCR integration (Andreas did it, but I also > want > to have more hands-on experience with it) > * introduce log levels and/or per-subscriber tracing functionality to > "see the signal among all the noise" while debugging problems in an > otherwise > busy network > * ensure SMS implementation is more robust than at HAR > * log all measurement reports to database for later analysis of handover > performance. We could also get them from pcap files, so not strictly > neccessary. > > Optional: > * finish AMR-halfrate implementation, as this will increase our capacity. > This includes dynamically selecting the codec that is used for each call. > I don't think we'll manage finishing this, especially with the LCR > integration. Standalone might be possible - but that is useless for 26C3 > Are you planning on finishing up all those points by yourself or could you use some help on some of theses ? (It wouldn't be very efficient to have several people working on the very same feature independently). I'll be in vacation in a few days till 26c3 and I was planning on working more seriously on GSM projects. I can definitely do some handhover testing once it's implemented. I was also planning on finishing my chan_openbsc for asterisk, the RRLP work I started and have a look at encryption but if some other things would be more useful, I can take a crack at them. Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Dec 16 08:45:36 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 16 Dec 2009 09:45:36 +0100 Subject: Update on GSM network at 26C3 In-Reply-To: <866320f70912141418q22202895taf5256eeccf756ce@mail.gmail.com> References: <20091214163904.GA12643@prithivi.gnumonks.org> <866320f70912141418q22202895taf5256eeccf756ce@mail.gmail.com> Message-ID: <20091216084536.GC20725@prithivi.gnumonks.org> On Mon, Dec 14, 2009 at 11:18:16PM +0100, Sylvain Munaut wrote: > Hi, > > TODO items before 26C3 (for the next couple of days): > > * finish handover implementation (critical) > > * do some more testing with LCR integration (Andreas did it, but I also > > want > > to have more hands-on experience with it) > > * introduce log levels and/or per-subscriber tracing functionality to > > "see the signal among all the noise" while debugging problems in an > > otherwise > > busy network > > * ensure SMS implementation is more robust than at HAR > > * log all measurement reports to database for later analysis of handover > > performance. We could also get them from pcap files, so not strictly > > neccessary. > > > > Optional: > > * finish AMR-halfrate implementation, as this will increase our capacity. > > This includes dynamically selecting the codec that is used for each call. > > I don't think we'll manage finishing this, especially with the LCR > > integration. Standalone might be possible - but that is useless for 26C3 > > Are you planning on finishing up all those points by yourself or could you > use some help on some of theses ? (It wouldn't be very efficient to have > several people working on the very same feature independently). well, as it seems zecke is already doing a lot of work with regard to logging/tracing. Not sure if he can finish that all by himself. If yes, it would be great to simply use his work. If you are interested, you could work on the SMS implementation. Somehow we have a number of known bugs: * inconsistent/incompatible/incorrect handling of transaction ID's * interleaved 04.11 CP-DATA transfers if a phone sends a multi-part message or multiple SMS at the same time. If you do this right now, we will use one full cycle of channel request -> immediate assignment -> establish indication -> cm service request -> cm service ack and then the full CP and RP transfers for each part of the message. However, the phones use the MMS (more messages to send) and overlapped / interleaved CP-DATA transfers in order to do all of this in one go, in one RR connection. We need to support this. I think the handover I'll have to do by myself, and theoretically it should all be finished in my codebase, will spend the full day today testing and finishing it. 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 246tnt at gmail.com Thu Dec 17 22:03:35 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 17 Dec 2009 23:03:35 +0100 Subject: Update on GSM network at 26C3 In-Reply-To: <20091216084536.GC20725@prithivi.gnumonks.org> References: <20091214163904.GA12643@prithivi.gnumonks.org> <866320f70912141418q22202895taf5256eeccf756ce@mail.gmail.com> <20091216084536.GC20725@prithivi.gnumonks.org> Message-ID: <866320f70912171403w6c3b24d9we90acd67aec5ef49@mail.gmail.com> Hi, If you are interested, you could work on the SMS implementation. Somehow > we have a number of known bugs: > * inconsistent/incompatible/incorrect handling of transaction ID's > * interleaved 04.11 CP-DATA transfers if a phone sends a multi-part > message or multiple SMS at the same time. If you do this right now, > we will use one full cycle of channel request -> immediate assignment > -> establish indication -> cm service request -> cm service ack and > then the full CP and RP transfers for each part of the message. However, > the phones use the MMS (more messages to send) and overlapped / > interleaved > CP-DATA transfers in order to do all of this in one go, in one RR > connection. > We need to support this. > Ok, after sending a couple of big messages I see what you mean. I don't get multiple RR connections but I get multiple CM service requests one after another in a single RR connection. Looking into it ... Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Tue Dec 15 03:40:29 2009 From: zecke at selfish.org (Holger Freyther) Date: Tue, 15 Dec 2009 04:40:29 +0100 Subject: Update on GSM network at 26C3 In-Reply-To: <20091214163904.GA12643@prithivi.gnumonks.org> References: <20091214163904.GA12643@prithivi.gnumonks.org> Message-ID: <200912150440.29330.zecke@selfish.org> On Monday 14 December 2009 17:39:04 Harald Welte wrote: > * introduce log levels and/or per-subscriber tracing functionality to > "see the signal among all the noise" while debugging problems in an > otherwise busy network please see the debug branch. it has the capability of logging everything to a vty. I could easily implement a hardcode filter for subscriber imsi/tmsi and will ping you once I did it (I try to do it today). z. From zecke at selfish.org Tue Dec 15 05:03:40 2009 From: zecke at selfish.org (Holger Freyther) Date: Tue, 15 Dec 2009 06:03:40 +0100 Subject: Update on GSM network at 26C3 In-Reply-To: <200912150440.29330.zecke@selfish.org> References: <20091214163904.GA12643@prithivi.gnumonks.org> <200912150440.29330.zecke@selfish.org> Message-ID: <200912150603.40696.zecke@selfish.org> On Tuesday 15 December 2009 04:40:29 Holger Freyther wrote: > On Monday 14 December 2009 17:39:04 Harald Welte wrote: > > * introduce log levels and/or per-subscriber tracing functionality to > > "see the signal among all the noise" while debugging problems in an > > otherwise busy network > > please see the debug branch. it has the capability of logging everything to > a vty. I could easily implement a hardcode filter for subscriber imsi/tmsi > and will ping you once I did it (I try to do it today). I have pushed two more changes to the holger/new-debug-arch branch. Now in vty it is possible to do: tamarin> logging enable tamarin> logging filter imsi IMSI tamarin> logging filter all 1 (to output every message via VTY) I will have to test with my GSM network once I have setup everything again.. I'm plagued by a cold or such... slowing me a bit down. z. From alexander.chemeris at gmail.com Tue Dec 15 20:53:38 2009 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 15 Dec 2009 23:53:38 +0300 Subject: Update on GSM network at 26C3 In-Reply-To: <20091214163904.GA12643@prithivi.gnumonks.org> References: <20091214163904.GA12643@prithivi.gnumonks.org> Message-ID: <3d032e5d0912151253q42fbacb2m442b44ea264f7339@mail.gmail.com> Hi Harald, On Mon, Dec 14, 2009 at 19:39, Harald Welte wrote: > as you will know, we have applied for an experimental GSM license for the > 26C3 (http://events.ccc.de/congress/2009/). > > Last week, the license was granted. ?However, only two ARFCN's have been > granted (I applied for 8). ?As it turns out, this was a communication problem. > > Today they have acknowledged a third ARFCN. ?So we can have at least one > single-TRX BTS on each floor. ?On wednesday they will determine whether > we can have more than three, or if we'll have to live with three ARFCN only. > > If we get 6, it will be one dual-TRX BTS for each floor. ?If we get even more, > the surplus ones can be used for random experiments. Does it means that we won't be able to do OpenBTS experiments there? We planned to test new USSD code in OpenBTS and it will be a shame to cancel this plans. -- Regards, Alexander Chemeris. From laforge at gnumonks.org Tue Dec 15 23:14:47 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 16 Dec 2009 00:14:47 +0100 Subject: Update on GSM network at 26C3 In-Reply-To: <3d032e5d0912151253q42fbacb2m442b44ea264f7339@mail.gmail.com> References: <20091214163904.GA12643@prithivi.gnumonks.org> <3d032e5d0912151253q42fbacb2m442b44ea264f7339@mail.gmail.com> Message-ID: <20091215231447.GB20725@prithivi.gnumonks.org> On Tue, Dec 15, 2009 at 11:53:38PM +0300, Alexander Chemeris wrote: > Hi Harald, > > On Mon, Dec 14, 2009 at 19:39, Harald Welte wrote: > > as you will know, we have applied for an experimental GSM license for the > > 26C3 (http://events.ccc.de/congress/2009/). > > > > Last week, the license was granted. ?However, only two ARFCN's have been > > granted (I applied for 8). ?As it turns out, this was a communication problem. > > > > Today they have acknowledged a third ARFCN. ?So we can have at least one > > single-TRX BTS on each floor. ?On wednesday they will determine whether > > we can have more than three, or if we'll have to live with three ARFCN only. > > > > If we get 6, it will be one dual-TRX BTS for each floor. ?If we get even more, > > the surplus ones can be used for random experiments. > > Does it means that we won't be able to do OpenBTS experiments there? > We planned to test new USSD code in OpenBTS and it will be a shame to > cancel this plans. Dear Alexander, I do not remember having seen any specific request from you applying for an ARFCN for OpenBTS experiments. Like in any country of the world, you need a test license in Germany to operate equipment in the GSM band. If you did and I missed that, I apologize. As you can see from my e-mail, we likely don't even have enough ARFCNs for operating the actual GSM network at 26C3 - not to talk about runing any more experimental stuff for doing actual development. The priorities for me have been very clear: First the actual GSM network, then any experiments. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Wed Dec 16 21:28:30 2009 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 17 Dec 2009 00:28:30 +0300 Subject: Update on GSM network at 26C3 In-Reply-To: <20091215231447.GB20725@prithivi.gnumonks.org> References: <20091214163904.GA12643@prithivi.gnumonks.org> <3d032e5d0912151253q42fbacb2m442b44ea264f7339@mail.gmail.com> <20091215231447.GB20725@prithivi.gnumonks.org> Message-ID: <3d032e5d0912161328v48945d5ftfc5db5244b49f4ea@mail.gmail.com> Hi Harald, On Wed, Dec 16, 2009 at 02:14, Harald Welte wrote: > I do not remember having seen any specific request from you applying for an > ARFCN for OpenBTS experiments. ?Like in any country of the world, you need > a test license in Germany to operate equipment in the GSM band. ?If you did and > I missed that, I apologize. Sorry, I was not clear enough. I wrote that we want to have OpenBTS working and assumed that you include that in your ARFCN request.That's my bad, I should have been more clear. I wouldn't tell for the whole world. ;) Someone wrote, that in Holland (IIRC) you can run low-power GSM in low part of 1800 without any restrictions. And in many countries no one just care if you run something low-power in clear ARFCN. > As you can see from my e-mail, we likely don't even have enough ARFCNs for > operating the actual GSM network at 26C3 - not to talk about runing any more > experimental stuff for doing actual development. > > > The priorities for me have been very clear: ?First the actual GSM network, then > any experiments. That's clear. -- Regards, Alexander Chemeris. From Andreas.Eversberg at versatel.de Wed Dec 16 10:15:49 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Wed, 16 Dec 2009 11:15:49 +0100 Subject: AW: Update on GSM network at 26C3 Message-ID: > Does it means that we won't be able to do OpenBTS experiments there? > We planned to test new USSD code in OpenBTS and it will be a shame to > cancel this plans. i think, if you don't transmit "too loud", i.e ranges lower than a few meters, no one would care. i use a leaky dummy load for testing. From alexander.chemeris at gmail.com Wed Dec 16 10:40:40 2009 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 16 Dec 2009 13:40:40 +0300 Subject: Update on GSM network at 26C3 In-Reply-To: References: Message-ID: <3d032e5d0912160240l4be56aacl55036dae1ffa58d6@mail.gmail.com> Hi, On Wed, Dec 16, 2009 at 13:15, Andreas.Eversberg wrote: >> Does it means that we won't be able to do OpenBTS experiments there? >> We planned to test new USSD code in OpenBTS and it will be a shame to >> cancel this plans. > > i think, if you don't transmit "too loud", i.e ranges lower than a few > meters, no one would care. i use a leaky dummy load for testing. I hope so too. Just don't want to make trouble for anyone, especially while I'm not in my home country. -- Regards, Alexander Chemeris. From laforge at gnumonks.org Wed Dec 16 12:15:40 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 16 Dec 2009 13:15:40 +0100 Subject: Update on GSM network at 26C3 In-Reply-To: <20091214163904.GA12643@prithivi.gnumonks.org> References: <20091214163904.GA12643@prithivi.gnumonks.org> Message-ID: <20091216121540.GK16689@prithivi.gnumonks.org> Hi all, one more update: On Mon, Dec 14, 2009 at 05:39:04PM +0100, Harald Welte wrote: > as you will know, we have applied for an experimental GSM license for the > 26C3 (http://events.ccc.de/congress/2009/). > > Last week, the license was granted. However, only two ARFCN's have been > granted (I applied for 8). As it turns out, this was a communication problem. > > Today they have acknowledged a third ARFCN. So we can have at least one > single-TRX BTS on each floor. On wednesday they will determine whether > we can have more than three, or if we'll have to live with three ARFCN only. Today they have acknowledged a total of 5 ARFCN's in GSM1800 for the 26C3. All of them are for indoor use only, with 200mW maximum transmit power. 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 Dec 16 23:38:21 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 17 Dec 2009 00:38:21 +0100 Subject: First successful handover Message-ID: <20091216233821.GQ16689@prithivi.gnumonks.org> Hi! I've just committed the current state of the handover code to git. What is working so far: * receiving + parsing the measurement reports from both MS and BTS * performing the actual handover process, i.e. allocating / activating the new logical channel on the new BTS, waiting for the ACK, sending handover command to the MS, waiting for HO complete, HO fail or timeout, ... * a minimalistic handover decision making. without any averaging: If we have a cell that's >= 3dB better than the current one, try a handover. What's missing: * switching the actual traffic channel contents (i.e. re-configuring the RTP streams in the ip.access case, or reconfiguring the TRAU mux in E1 case) * better handover algorithm implementation including averaging I'm on a business trip tomorrow, but the code is already seeming to work quite fine, and it looks like: <0400> abis_rsl.c:980 MEASUREMENT RESULT NR=13 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 10dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-61dBm RXL-SUB-dl=-56dBm RXQ-FULL-dl=6 RXQ-SUB-dl=4 NUM_NEIGH=1 <0400> abis_rsl.c:1010 ARFCN=868 BSIC=63 => -70 dBm <80000> handover_decision.c:61 process meas res: No better cell <0400> abis_rsl.c:980 MEASUREMENT RESULT NR=14 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 10dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-87dBm RXL-SUB-dl=-83dBm RXQ-FULL-dl=6 RXQ-SUB-dl=4 NUM_NEIGH=1 <0400> abis_rsl.c:1010 ARFCN=868 BSIC=63 => -69 dBm <80000> handover_decision.c:61 process meas res: Cell on ARFCN 868 is better, starting handover <80000> handover_logic.c:92 (old_lchan on BTS 0, new BTS 1): <0010> abis_rsl.c:1107 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a CHANNEL ACTIVATE ACK <80000> handover_logic.c:151 handover activate ack, send HO Command <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 2 pd 06) Sending 0x2b to MS. <0010> abis_rsl.c:1107 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a <0010> abis_rsl.c:1082 HANDOVER DETECT access delay = 0 <0010> abis_rsl.c:1107 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a <0010> abis_rsl.c:1082 HANDOVER DETECT access delay = 0 <0001> abis_rsl.c:1396 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a sapi=0 ESTABLISH INDICATION <0001> abis_rsl.c:1396 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a sapi=0 DATA INDICATION <0008> gsm_04_08.c:1595 HANDOVER COMPLETE cause = Normal event <0002> handover_logic.c:203 lchan (bts=0,trx=0,ts=2,ch=0) decreases usage to: 0 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 Thu Dec 17 16:48:35 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 17 Dec 2009 17:48:35 +0100 Subject: LCR / RTP interface Message-ID: <20091217164835.GD26952@prithivi.gnumonks.org> Hi Andreas + List, I have now studied the new "RTP capable" lcr integration in detail. My sincere apologies once again for the long delay that this has been taking me. I really like the interface (like its predecessor). The major restriction at the moment seems to be its limitation to support only GSM Version 1 Full Rate. After doing some testing with the current 'lcr_rtp' branch in git, as well as the attempt to integrate handover support with the lcr/mncc interface, I am considering to add support for other codec types, too. GSM EFR (only exists in full-rate) is interesting for everyone, as almost all phones support it, and it renders significantly higher quality. GSM V1 halfrate is important for BS-11 users who want increased capacity, since this BTS does not support AMR-halfrate. GSM V1 full-rate is important for ip.access, since it is the only half-rate codec it supports, and thus the only way to increase capacity for this BTS. GSM AMR full-rate is probably of the least interest, but still nice to have. For the 26C3, I would love to run in a EFR-fullrate and AMR-halfrate configuration, depending on the phone's capabilities. 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 roch at on-waves.com Thu Dec 17 16:57:32 2009 From: roch at on-waves.com (Roch-Alexandre Nomine) Date: Thu, 17 Dec 2009 17:57:32 +0100 Subject: LCR / RTP interface In-Reply-To: <20091217164835.GD26952@prithivi.gnumonks.org> References: <20091217164835.GD26952@prithivi.gnumonks.org> Message-ID: <4B2A62FC.4070301@on-waves.com> Hi Harald, I might be wrong but I think that ip.access only supports AMR for half-rate channels. Regards Roch. Roch-Alexandre NOMIN? CTO On-Waves ehf ?rm?li 25, IS-108 Reykjav?k, ICELAND Tel: +354 864 9431 Harald Welte a ?crit : > Hi Andreas + List, > > I have now studied the new "RTP capable" lcr integration in detail. My > sincere apologies once again for the long delay that this has been taking > me. > > I really like the interface (like its predecessor). The major restriction > at the moment seems to be its limitation to support only GSM Version 1 > Full Rate. > > After doing some testing with the current 'lcr_rtp' branch in git, as well > as the attempt to integrate handover support with the lcr/mncc interface, > I am considering to add support for other codec types, too. > > GSM EFR (only exists in full-rate) is interesting for everyone, as almost > all phones support it, and it renders significantly higher quality. > > GSM V1 halfrate is important for BS-11 users who want increased capacity, since > this BTS does not support AMR-halfrate. > > GSM V1 full-rate is important for ip.access, since it is the only half-rate > codec it supports, and thus the only way to increase capacity for this BTS. > > GSM AMR full-rate is probably of the least interest, but still nice to have. > > For the 26C3, I would love to run in a EFR-fullrate and AMR-halfrate > configuration, depending on the phone's capabilities. > > Regards, > Harald > From laforge at gnumonks.org Thu Dec 17 17:31:39 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 17 Dec 2009 18:31:39 +0100 Subject: LCR / RTP interface In-Reply-To: <4B2A62FC.4070301@on-waves.com> References: <20091217164835.GD26952@prithivi.gnumonks.org> <4B2A62FC.4070301@on-waves.com> Message-ID: <20091217173139.GH26952@prithivi.gnumonks.org> Hi Roch, On Thu, Dec 17, 2009 at 05:57:32PM +0100, Roch-Alexandre Nomine wrote: > I might be wrong but I think that ip.access only supports AMR for > half-rate channels. thanks for that information. As indicated, it is more like a nice-to-have than something that is needed. -- - 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 Thu Dec 17 21:04:27 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 17 Dec 2009 22:04:27 +0100 Subject: new debug / logging architecture Message-ID: <20091217210427.GJ26952@prithivi.gnumonks.org> Hi Holger, I'm happy with the new architecture. During testing I made a couple of bug fixes, which I applied to the new 'new-debug-arch' branch in the root directory of the git branch namespace. (i.e. not prefixed with holger/). It would be great if you could finish this work so we can benefit of it before the congress. I'll probably merge some initial parts already now (at least the new macro definitions) to start using log levels in the actual code - even if it doesn't get used yet. 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 Tue Dec 22 12:59:37 2009 From: zecke at selfish.org (Holger Freyther) Date: Tue, 22 Dec 2009 13:59:37 +0100 Subject: new debug / logging architecture In-Reply-To: <20091217210427.GJ26952@prithivi.gnumonks.org> References: <20091217210427.GJ26952@prithivi.gnumonks.org> Message-ID: <200912221359.37628.zecke@selfish.org> On Thursday 17 December 2009 22:04:27 Harald Welte wrote: > Hi Holger, > > I'm happy with the new architecture. During testing I made a couple of bug > fixes, which I applied to the new 'new-debug-arch' branch in the root > directory of the git branch namespace. (i.e. not prefixed with holger/). > > It would be great if you could finish this work so we can benefit of it > before the congress. > > I'll probably merge some initial parts already now (at least the new macro > definitions) to start using log levels in the actual code - even if it > doesn't get used yet. I have added what I think were missing features. Two things are missing, one is more heavy testing and the other is considering method renaming. What I have added during the day: - Be able to set a global loglevel (ala setloglevel of syslog) - Set print timestamp, use color per debug target - Filter the debug_mask per target - Remove the debug mask and replace it with an array struct debug_category that contains the loglevel and enabled state. - The -d argument on bsc_hack (and via vty) can now handle CategoryName1:CategoryName,OptionalLogLevel... The ',' and ':' are a bit backwards due compabilitiy... - It is possible to set the category enabled state and the log level via VTY. - I have verified that the loglevel and enabled state is working so please review it once again, and then I think it would be great to merge it before the 26c3. regards holger From 246tnt at gmail.com Thu Dec 17 21:44:05 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 17 Dec 2009 22:44:05 +0100 Subject: The need of RTP payload type IE in CRCX and MDCX Message-ID: <866320f70912171344p602409a3p89dc0836d2af99ce@mail.gmail.com> Hi, I have a nanobts unit 139 with a software that somehow only accepts GSM FR (and not EFR), unless I also send the RTP payload type IE ( RSL_IE_IPAC_RTP_PAYLOAD ) in the CRCX and MDCX messages. (and only the "RTP payload type" IE, the "RTP payload type 2" has no effect I can see). From laforge at gnumonks.org Sat Dec 19 17:40:15 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 19 Dec 2009 18:40:15 +0100 Subject: The need of RTP payload type IE in CRCX and MDCX In-Reply-To: <866320f70912171344p602409a3p89dc0836d2af99ce@mail.gmail.com> References: <866320f70912171344p602409a3p89dc0836d2af99ce@mail.gmail.com> Message-ID: <20091219174014.GE14330@prithivi.gnumonks.org> On Thu, Dec 17, 2009 at 10:44:05PM +0100, Sylvain Munaut wrote: > Hi, > > I have a nanobts unit 139 with a software that somehow only accepts GSM FR > (and not EFR), unless I also send the RTP payload type IE ( > RSL_IE_IPAC_RTP_PAYLOAD ) in the CRCX and MDCX messages. (and only the "RTP > payload type" IE, the "RTP payload type 2" has no effect I can see). thanks for pointing this out. Now the question is, would that affect the later models? Do you have any later models to test? If later models / versions don't mind the RTP Payload (non-type-2), we can jusy simply always use that. > From the ip.access dissector, I think it's just a mapping between the RTP > 'type' used and the corresponding codec. we can use any random number as we control both the BTS and the RTP proxy on our side. > For GSM FR the RFC specifies PT=3 but for HR/EFR/AMR, they are dynamic and > must be chosed in the 96-127 range. > AFAIK, we could just use a static mapping in openbsc or load that from the > config. Does anyone sees a downside to that ? static mapping is fine with me, patches welcome. -- - 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 Sun Dec 20 21:09:22 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 20 Dec 2009 22:09:22 +0100 Subject: The need of RTP payload type IE in CRCX and MDCX In-Reply-To: <20091219174014.GE14330@prithivi.gnumonks.org> References: <866320f70912171344p602409a3p89dc0836d2af99ce@mail.gmail.com> <20091219174014.GE14330@prithivi.gnumonks.org> Message-ID: <866320f70912201309n2fa3ba63h80fe65adb7602605@mail.gmail.com> > > I have a nanobts unit 139 with a software that somehow only accepts GSM > FR > > (and not EFR), unless I also send the RTP payload type IE ( > > RSL_IE_IPAC_RTP_PAYLOAD ) in the CRCX and MDCX messages. (and only the > "RTP > > payload type" IE, the "RTP payload type 2" has no effect I can see). > > thanks for pointing this out. Now the question is, would that affect the > later > models? Do you have any later models to test? If later models / versions > don't mind the RTP Payload (non-type-2), we can jusy simply always use > that. > I tested with a later version othe 139 software and including the RTP payload type IE works fine. I don't have any other units (EDGE ones) so I can't test. But I just posted the patch so someone could test ... > > > For GSM FR the RFC specifies PT=3 but for HR/EFR/AMR, they are dynamic > and > > must be chosed in the 96-127 range. > > AFAIK, we could just use a static mapping in openbsc or load that from > the > > config. Does anyone sees a downside to that ? > > static mapping is fine with me, patches welcome. > Patch sent on the ML. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From khh at viptel.dk Fri Dec 18 08:46:49 2009 From: khh at viptel.dk (Viptel ApS - Kasper H. Hansen) Date: Fri, 18 Dec 2009 09:46:49 +0100 Subject: payable freelance consulting on openbsc ? Message-ID: Is there anyone well knowing about the signaling part in openbsc project there might be interested in the solving of a few specific tasks against payment? the results will be posted in the openbsc project also. Please contact me. Med venlig hilsen / Best regards Kasper Hessellund Hansen Denmark -------------- next part -------------- An HTML attachment was scrubbed... URL: From khh at viptel.dk Fri Dec 18 08:58:23 2009 From: khh at viptel.dk (Viptel ApS - Kasper H. Hansen) Date: Fri, 18 Dec 2009 09:58:23 +0100 Subject: payable freelance consulting on openbsc ? Message-ID: Is there anyone well knowing about the signaling part in openbsc project there might be interested in the solving of a few specific tasks against payment? the results will be posted in the openbsc project also. Please contact me. Med venlig hilsen / Best regards Kasper Hessellund Hansen Denmark Khh at viptel.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Fri Dec 18 17:28:05 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 18 Dec 2009 18:28:05 +0100 Subject: [PATCH 0/7] Preliminary fixes Message-ID: <1261157292-22288-1-git-send-email-246tnt@gmail.com> Here's a small series with some minor fixes I found when looking at multiple SMS in a single RR connection. For the MO case, it actually now works as described in the spec in the no-error case. But what can happen is that after the second CM SERVICE REQUEST, we may never receive the last CP-ACK of the previous transaction (and thus leak a transaction). The spec says than when receiving a CP-DATA after a CM SERVICE REQUEST we should consider we also implicitely received the last CP-ACK of the previous transaction ... that's not implemented yet. For the MT case, it currently makes several RR connection which is quite bad ... to be fixed. Sylvain From 246tnt at gmail.com Fri Dec 18 17:28:06 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 18 Dec 2009 18:28:06 +0100 Subject: [PATCH 1/7] [bsc_init] Send OPSTART if SITE_MANAGER reports off-line In-Reply-To: <1261157292-22288-1-git-send-email-246tnt@gmail.com> References: <1261157292-22288-1-git-send-email-246tnt@gmail.com> Message-ID: <1261157292-22288-2-git-send-email-246tnt@gmail.com> From: Sylvain Munaut The exact sequence the states the BTS goes through is slightly different for one of the nanoBTS 139 I have and it needs this to start. Signed-off-by: Sylvain Munaut --- openbsc/src/bsc_init.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/openbsc/src/bsc_init.c b/openbsc/src/bsc_init.c index ce3d0b4..b72624a 100644 --- a/openbsc/src/bsc_init.c +++ b/openbsc/src/bsc_init.c @@ -356,8 +356,10 @@ int nm_state_event(enum nm_evt evt, u_int8_t obj_class, void *obj, switch (obj_class) { case NM_OC_SITE_MANAGER: bts = container_of(obj, struct gsm_bts, site_mgr); - if (new_state->operational == 2 && - new_state->availability == NM_AVSTATE_OK) + if ((new_state->operational == 2 && + new_state->availability == NM_AVSTATE_OK) || + (new_state->operational == 1 && + new_state->availability == NM_AVSTATE_OFF_LINE)) abis_nm_opstart(bts, obj_class, 0xff, 0xff, 0xff); break; case NM_OC_BTS: -- 1.6.5.1 From 246tnt at gmail.com Fri Dec 18 17:28:07 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 18 Dec 2009 18:28:07 +0100 Subject: [PATCH 2/7] [gsm_04_11] Fix typos in debug message / comments In-Reply-To: <1261157292-22288-2-git-send-email-246tnt@gmail.com> References: <1261157292-22288-1-git-send-email-246tnt@gmail.com> <1261157292-22288-2-git-send-email-246tnt@gmail.com> Message-ID: <1261157292-22288-3-git-send-email-246tnt@gmail.com> From: Sylvain Munaut Signed-off-by: Sylvain Munaut --- openbsc/src/gsm_04_11.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/openbsc/src/gsm_04_11.c b/openbsc/src/gsm_04_11.c index 4930e5c..d256f7e 100644 --- a/openbsc/src/gsm_04_11.c +++ b/openbsc/src/gsm_04_11.c @@ -173,7 +173,7 @@ static int gsm411_cp_sendmsg(struct msgb *msg, struct gsm_trans *trans, DEBUGP(DSMS, "TX: CP-ACK "); break; case GSM411_MT_CP_ERROR: - DEBUGP(DSMS, "TX: CP-ACK "); + DEBUGP(DSMS, "TX: CP-ERROR "); break; } @@ -958,7 +958,7 @@ int gsm0411_rcv_sms(struct msgb *msg, u_int8_t link_id) bsc_del_timer(&trans->sms.cp_timer); if (!trans->sms.is_mt) { - /* FIXME: we have sont one CP-DATA, which was now + /* FIXME: we have sent one CP-DATA, which was now * acknowledged. Check if we want to transfer more, * i.e. multi-part message */ trans->sms.cp_state = GSM411_CPS_IDLE; -- 1.6.5.1 From 246tnt at gmail.com Fri Dec 18 17:28:08 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 18 Dec 2009 18:28:08 +0100 Subject: [PATCH 3/7] [gsm_04_11] Fix transaction_id displayed in debug message In-Reply-To: <1261157292-22288-3-git-send-email-246tnt@gmail.com> References: <1261157292-22288-1-git-send-email-246tnt@gmail.com> <1261157292-22288-2-git-send-email-246tnt@gmail.com> <1261157292-22288-3-git-send-email-246tnt@gmail.com> Message-ID: <1261157292-22288-4-git-send-email-246tnt@gmail.com> From: Sylvain Munaut In SMS debug messages, we always display the transaction ID as if we were 'sending' the message. Signed-off-by: Sylvain Munaut --- openbsc/src/gsm_04_11.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/openbsc/src/gsm_04_11.c b/openbsc/src/gsm_04_11.c index d256f7e..84139e2 100644 --- a/openbsc/src/gsm_04_11.c +++ b/openbsc/src/gsm_04_11.c @@ -906,7 +906,7 @@ int gsm0411_rcv_sms(struct msgb *msg, u_int8_t link_id) return -EIO; /* FIXME: send some error message */ - DEBUGP(DSMS, "trans_id=%x ", gh->proto_discr >> 4); + DEBUGP(DSMS, "trans_id=%x ", transaction_id); trans = trans_find_by_id(lchan->subscr, GSM48_PDISC_SMS, transaction_id); if (!trans) { -- 1.6.5.1 From 246tnt at gmail.com Fri Dec 18 17:28:09 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 18 Dec 2009 18:28:09 +0100 Subject: [PATCH 4/7] [gsm_04_11] Use 'new' rather than 'unknown' when starting transaction In-Reply-To: <1261157292-22288-4-git-send-email-246tnt@gmail.com> References: <1261157292-22288-1-git-send-email-246tnt@gmail.com> <1261157292-22288-2-git-send-email-246tnt@gmail.com> <1261157292-22288-3-git-send-email-246tnt@gmail.com> <1261157292-22288-4-git-send-email-246tnt@gmail.com> Message-ID: <1261157292-22288-5-git-send-email-246tnt@gmail.com> From: Sylvain Munaut 'unknown' has a negative connotation for a case that's totally normal so refer to it as 'new' so it doesn't sound like a problem. Signed-off-by: Sylvain Munaut --- openbsc/src/gsm_04_11.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/openbsc/src/gsm_04_11.c b/openbsc/src/gsm_04_11.c index 84139e2..31fcabf 100644 --- a/openbsc/src/gsm_04_11.c +++ b/openbsc/src/gsm_04_11.c @@ -910,7 +910,7 @@ int gsm0411_rcv_sms(struct msgb *msg, u_int8_t link_id) trans = trans_find_by_id(lchan->subscr, GSM48_PDISC_SMS, transaction_id); if (!trans) { - DEBUGPC(DSMS, "(unknown) "); + DEBUGPC(DSMS, "(new) "); trans = trans_alloc(lchan->subscr, GSM48_PDISC_SMS, transaction_id, new_callref++); if (!trans) { -- 1.6.5.1 From 246tnt at gmail.com Fri Dec 18 17:28:10 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 18 Dec 2009 18:28:10 +0100 Subject: [PATCH 5/7] [gsm_04_08] Fix subscr ref leak for multi CM SERV REQ In-Reply-To: <1261157292-22288-5-git-send-email-246tnt@gmail.com> References: <1261157292-22288-1-git-send-email-246tnt@gmail.com> <1261157292-22288-2-git-send-email-246tnt@gmail.com> <1261157292-22288-3-git-send-email-246tnt@gmail.com> <1261157292-22288-4-git-send-email-246tnt@gmail.com> <1261157292-22288-5-git-send-email-246tnt@gmail.com> Message-ID: <1261157292-22288-6-git-send-email-246tnt@gmail.com> From: Sylvain Munaut Multiple CM SERVICE REQUEST can happen on a single RR connection, in this case, since the subscr reference is tracked through lchan->subscr and will only be put'd once on lchan_free, we need to make sure we don't get several reference .... Signed-off-by: Sylvain Munaut --- openbsc/src/gsm_04_08.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/openbsc/src/gsm_04_08.c b/openbsc/src/gsm_04_08.c index 5fea6bf..f87b335 100644 --- a/openbsc/src/gsm_04_08.c +++ b/openbsc/src/gsm_04_08.c @@ -1343,7 +1343,9 @@ static int gsm48_rx_mm_serv_req(struct msgb *msg) if (!msg->lchan->subscr) msg->lchan->subscr = subscr; - else if (msg->lchan->subscr != subscr) { + else if (msg->lchan->subscr == subscr) + subscr_put(subscr); /* lchan already has a ref, don't need another one */ + else { DEBUGP(DMM, "<- CM Channel already owned by someone else?\n"); subscr_put(subscr); } -- 1.6.5.1 From 246tnt at gmail.com Fri Dec 18 17:28:11 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 18 Dec 2009 18:28:11 +0100 Subject: [PATCH 6/7] [transaction] Never allocate transaction ID 7 In-Reply-To: <1261157292-22288-6-git-send-email-246tnt@gmail.com> References: <1261157292-22288-1-git-send-email-246tnt@gmail.com> <1261157292-22288-2-git-send-email-246tnt@gmail.com> <1261157292-22288-3-git-send-email-246tnt@gmail.com> <1261157292-22288-4-git-send-email-246tnt@gmail.com> <1261157292-22288-5-git-send-email-246tnt@gmail.com> <1261157292-22288-6-git-send-email-246tnt@gmail.com> Message-ID: <1261157292-22288-7-git-send-email-246tnt@gmail.com> From: Sylvain Munaut According to GSM 04.07 11.2.3.1.3 , TID 7 is "reserved for future extensions". Signed-off-by: Sylvain Munaut --- openbsc/src/transaction.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/openbsc/src/transaction.c b/openbsc/src/transaction.c index 9f1bbf3..1d58333 100644 --- a/openbsc/src/transaction.c +++ b/openbsc/src/transaction.c @@ -133,7 +133,7 @@ int trans_assign_trans_id(struct gsm_subscriber *subscr, used_tid_bitmask |= (1 << trans->transaction_id); } - for (i = 0; i <= 7; i++) { + for (i = 0; i < 7; i++) { if ((used_tid_bitmask & (1 << (i | ti_flag))) == 0) return i | ti_flag; } -- 1.6.5.1 From 246tnt at gmail.com Fri Dec 18 17:28:12 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 18 Dec 2009 18:28:12 +0100 Subject: [PATCH 7/7] [gsm_04_11] Replace hardcoded transaction_id by real allocation In-Reply-To: <1261157292-22288-7-git-send-email-246tnt@gmail.com> References: <1261157292-22288-1-git-send-email-246tnt@gmail.com> <1261157292-22288-2-git-send-email-246tnt@gmail.com> <1261157292-22288-3-git-send-email-246tnt@gmail.com> <1261157292-22288-4-git-send-email-246tnt@gmail.com> <1261157292-22288-5-git-send-email-246tnt@gmail.com> <1261157292-22288-6-git-send-email-246tnt@gmail.com> <1261157292-22288-7-git-send-email-246tnt@gmail.com> Message-ID: <1261157292-22288-8-git-send-email-246tnt@gmail.com> From: Sylvain Munaut Signed-off-by: Sylvain Munaut --- openbsc/src/gsm_04_11.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/openbsc/src/gsm_04_11.c b/openbsc/src/gsm_04_11.c index 31fcabf..9e85f9b 100644 --- a/openbsc/src/gsm_04_11.c +++ b/openbsc/src/gsm_04_11.c @@ -1005,7 +1005,11 @@ int gsm411_send_sms_lchan(struct gsm_lchan *lchan, struct gsm_sms *sms) u_int8_t transaction_id; int rc; - transaction_id = 4; /* FIXME: we always use 4 for now */ + transaction_id = trans_assign_trans_id(lchan->subscr, GSM48_PDISC_SMS, 0); + if (transaction_id == -1) { + DEBUGP(DSMS, "No available transaction ids\n"); + return -EBUSY; + } msg->lchan = lchan; -- 1.6.5.1 From laforge at gnumonks.org Tue Dec 22 12:46:30 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 22 Dec 2009 13:46:30 +0100 Subject: [PATCH 7/7] [gsm_04_11] Replace hardcoded transaction_id by real allocation In-Reply-To: <1261157292-22288-8-git-send-email-246tnt@gmail.com> References: <1261157292-22288-1-git-send-email-246tnt@gmail.com> <1261157292-22288-2-git-send-email-246tnt@gmail.com> <1261157292-22288-3-git-send-email-246tnt@gmail.com> <1261157292-22288-4-git-send-email-246tnt@gmail.com> <1261157292-22288-5-git-send-email-246tnt@gmail.com> <1261157292-22288-6-git-send-email-246tnt@gmail.com> <1261157292-22288-7-git-send-email-246tnt@gmail.com> <1261157292-22288-8-git-send-email-246tnt@gmail.com> Message-ID: <20091222124630.GB14330@prithivi.gnumonks.org> thanks, applied. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zecke at selfish.org Sat Dec 19 02:28:06 2009 From: zecke at selfish.org (Holger Freyther) Date: Sat, 19 Dec 2009 03:28:06 +0100 Subject: [PATCH 0/7] Preliminary fixes In-Reply-To: <1261157292-22288-1-git-send-email-246tnt@gmail.com> References: <1261157292-22288-1-git-send-email-246tnt@gmail.com> Message-ID: <200912190328.09086.zecke@selfish.org> On Friday 18 December 2009 18:28:05 Sylvain Munaut wrote: > Here's a small series with some minor fixes I found when looking at > multiple SMS in a single RR connection. > > For the MO case, it actually now works as described in the spec in the > no-error case. But what can happen is that after the second > CM SERVICE REQUEST, we may never receive the last CP-ACK of the previous > transaction (and thus leak a transaction). The spec says than when > receiving a CP-DATA after a CM SERVICE REQUEST we should consider we also > implicitely received the last CP-ACK of the previous transaction ... > that's not implemented yet. > > For the MT case, it currently makes several RR connection which is quite > bad ... to be fixed. Great, I have applied 2-6, for 1 and 7 I would like to let Harald review it (they seem fine but I can't judge the impacts). z. From 246tnt at gmail.com Sun Dec 20 12:42:16 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 20 Dec 2009 13:42:16 +0100 Subject: [PATCH 1/2] [signal] Differentiate paging success from expiration in SS_PAGING Message-ID: <1261312937-32339-1-git-send-email-246tnt@gmail.com> From: Sylvain Munaut This is useful information to know and actually fixes a segfault in rllp.c where lchan is accessed even tough it could be NULL in case of failure. Signed-off-by: Sylvain Munaut --- openbsc/include/openbsc/signal.h | 3 ++- openbsc/src/gsm_04_08_utils.c | 2 +- openbsc/src/paging.c | 2 +- openbsc/src/rrlp.c | 4 +++- 4 files changed, 7 insertions(+), 4 deletions(-) diff --git a/openbsc/include/openbsc/signal.h b/openbsc/include/openbsc/signal.h index 8c815f8..3680d56 100644 --- a/openbsc/include/openbsc/signal.h +++ b/openbsc/include/openbsc/signal.h @@ -45,7 +45,8 @@ enum signal_subsystems { /* SS_PAGING signals */ enum signal_paging { - S_PAGING_COMPLETED, + S_PAGING_SUCCEEDED, + S_PAGING_EXPIRED, }; /* SS_SMS signals */ diff --git a/openbsc/src/gsm_04_08_utils.c b/openbsc/src/gsm_04_08_utils.c index e96a1ca..2183743 100644 --- a/openbsc/src/gsm_04_08_utils.c +++ b/openbsc/src/gsm_04_08_utils.c @@ -488,7 +488,7 @@ int gsm48_handle_paging_resp(struct msgb *msg, struct gsm_subscriber *subscr) sig_data.bts = msg->lchan->ts->trx->bts; sig_data.lchan = msg->lchan; - dispatch_signal(SS_PAGING, S_PAGING_COMPLETED, &sig_data); + dispatch_signal(SS_PAGING, S_PAGING_SUCCEEDED, &sig_data); /* Stop paging on the bts we received the paging response */ paging_request_stop(msg->trx->bts, subscr, msg->lchan); diff --git a/openbsc/src/paging.c b/openbsc/src/paging.c index b273419..6cd4d05 100644 --- a/openbsc/src/paging.c +++ b/openbsc/src/paging.c @@ -212,7 +212,7 @@ static void paging_T3113_expired(void *data) cbfn = req->cbfn; paging_remove_request(&req->bts->paging, req); - dispatch_signal(SS_PAGING, S_PAGING_COMPLETED, &sig_data); + dispatch_signal(SS_PAGING, S_PAGING_EXPIRED, &sig_data); if (cbfn) cbfn(GSM_HOOK_RR_PAGING, GSM_PAGING_EXPIRED, NULL, NULL, cbfn_param); diff --git a/openbsc/src/rrlp.c b/openbsc/src/rrlp.c index 60ce750..3504451 100644 --- a/openbsc/src/rrlp.c +++ b/openbsc/src/rrlp.c @@ -89,10 +89,12 @@ static int paging_sig_cb(unsigned int subsys, unsigned int signal, struct paging_signal_data *psig_data = signal_data; switch (signal) { - case S_PAGING_COMPLETED: + case S_PAGING_SUCCEEDED: /* A subscriber has attached. */ send_rrlp_req(psig_data->lchan); break; + case S_PAGING_EXPIRED: + break; } return 0; } -- 1.6.5.1 From 246tnt at gmail.com Sun Dec 20 12:42:17 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 20 Dec 2009 13:42:17 +0100 Subject: [PATCH 2/2] [db] Fix queries for unsent SMS In-Reply-To: <1261312937-32339-1-git-send-email-246tnt@gmail.com> References: <1261312937-32339-1-git-send-email-246tnt@gmail.com> Message-ID: <1261312937-32339-2-git-send-email-246tnt@gmail.com> From: Sylvain Munaut - Need to use sms.id for the ORDER BY since 'subscriber' also has 'id' - Need to add the join clause between 'SMS' and 'subscriber' - Add a LIMIT 1 (probably no impact for the db size we're dealing with here, but with large DB and mysql/postgresql this can help the planner) - (fix a wrong comment in passing ...) Signed-off-by: Sylvain Munaut --- openbsc/src/db.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/openbsc/src/db.c b/openbsc/src/db.c index 5dfefb5..ebfe923 100644 --- a/openbsc/src/db.c +++ b/openbsc/src/db.c @@ -769,8 +769,9 @@ struct gsm_sms *db_sms_get_unsent(struct gsm_network *net, int min_id) result = dbi_conn_queryf(conn, "SELECT * FROM SMS,Subscriber " "WHERE sms.id >= %llu AND sms.sent is NULL " + "AND sms.receiver_id = subscriber.id " "AND subscriber.lac > 0 " - "ORDER BY id", + "ORDER BY sms.id LIMIT 1", min_id); if (!result) return NULL; @@ -787,7 +788,7 @@ struct gsm_sms *db_sms_get_unsent(struct gsm_network *net, int min_id) return sms; } -/* retrieve the next unsent SMS with ID >= min_id */ +/* retrieve the next unsent SMS for a given subscriber */ struct gsm_sms *db_sms_get_unsent_for_subscr(struct gsm_subscriber *subscr) { dbi_result result; @@ -796,8 +797,9 @@ struct gsm_sms *db_sms_get_unsent_for_subscr(struct gsm_subscriber *subscr) result = dbi_conn_queryf(conn, "SELECT * FROM SMS,Subscriber " "WHERE sms.receiver_id = %llu AND sms.sent is NULL " + "AND sms.receiver_id = subscriber.id " "AND subscriber.lac > 0 " - "ORDER BY id", + "ORDER BY sms.id LIMIT 1", subscr->id); if (!result) return NULL; -- 1.6.5.1 From laforge at gnumonks.org Mon Dec 21 00:10:53 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Dec 2009 01:10:53 +0100 Subject: [PATCH 2/2] [db] Fix queries for unsent SMS In-Reply-To: <1261312937-32339-2-git-send-email-246tnt@gmail.com> References: <1261312937-32339-1-git-send-email-246tnt@gmail.com> <1261312937-32339-2-git-send-email-246tnt@gmail.com> Message-ID: <20091221001053.GK14330@prithivi.gnumonks.org> Thanks, applied. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Andreas.Eversberg at versatel.de Sun Dec 20 16:42:39 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Sun, 20 Dec 2009 17:42:39 +0100 Subject: fix of lcr_rtp and systeminfo Message-ID: hi, here are two patches (attached): the lcr_rtp.fix will make the current lcr_rtp branch compile. also it works with LCR. the systeminfo.fix contains a pointer fix and a question why there is a value cleared again. (don't apply it, just apply the line with the pointer fix) regards, andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rtp_4.fix Type: application/octet-stream Size: 1872 bytes Desc: rtp_4.fix URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: systeminfo.fix Type: application/octet-stream Size: 668 bytes Desc: systeminfo.fix URL: From 246tnt at gmail.com Sun Dec 20 17:16:44 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 20 Dec 2009 18:16:44 +0100 Subject: [PATCH 1/3] chan_alloc: Delete T3101 on lchan_free as well Message-ID: <1261329406-3058-1-git-send-email-246tnt@gmail.com> From: Sylvain Munaut If a RF channel is assigned but no response is ever heard from the phone, we will receive a CONNECTION FAIL from the BTS, triggering a RF release freeing the channel. Then sometime later, T3101 will expire as well and free the channel again ... Signed-off-by: Sylvain Munaut --- openbsc/src/chan_alloc.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/openbsc/src/chan_alloc.c b/openbsc/src/chan_alloc.c index 786e8b1..a23192a 100644 --- a/openbsc/src/chan_alloc.c +++ b/openbsc/src/chan_alloc.c @@ -251,6 +251,7 @@ void lchan_free(struct gsm_lchan *lchan) /* stop the timer */ bsc_del_timer(&lchan->release_timer); + bsc_del_timer(&lchan->T3101); /* clear cached measuement reports */ lchan->meas_rep_idx = 0; -- 1.6.5.1 From 246tnt at gmail.com Sun Dec 20 17:16:45 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 20 Dec 2009 18:16:45 +0100 Subject: [PATCH 2/3] net: Allow config of RACH control parameters tx-integer & max retrans In-Reply-To: <1261329406-3058-1-git-send-email-246tnt@gmail.com> References: <1261329406-3058-1-git-send-email-246tnt@gmail.com> Message-ID: <1261329406-3058-2-git-send-email-246tnt@gmail.com> From: Sylvain Munaut Tweaking theses can be useful especially tx-integer that influence both the spread of rach attemps and the delay between two attemps. Looking up GSM 04.08 3.3.1.1.2 & 10.5.2.29 can help determine good values. The default are choosed with a wide spacing between attemps (tx integer = 9 -> T=12 & S=217 (non-combined CCCH/SDCCH) or 115 (for combined CCCH/SDCCH)). This alleviates the problem of responding to several RACH attempts by a same MS, allocating several RF channels when only 1 is needed. Signed-off-by: Sylvain Munaut --- openbsc/include/openbsc/gsm_data.h | 4 ++++ openbsc/include/openbsc/gsm_utils.h | 7 +++++++ openbsc/src/bsc_init.c | 4 ++-- openbsc/src/gsm_data.c | 2 ++ openbsc/src/vty_interface.c | 24 ++++++++++++++++++++++++ 5 files changed, 39 insertions(+), 2 deletions(-) diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h index f4e4d21..bc1dbe6 100644 --- a/openbsc/include/openbsc/gsm_data.h +++ b/openbsc/include/openbsc/gsm_data.h @@ -451,6 +451,10 @@ struct gsm_network { enum gsm48_reject_value reject_cause; int a5_encryption; int neci; + struct { + int tx_integer; + int max_retrans; + } rach; int send_mm_info; struct { int active; diff --git a/openbsc/include/openbsc/gsm_utils.h b/openbsc/include/openbsc/gsm_utils.h index 5809221..80fe12f 100644 --- a/openbsc/include/openbsc/gsm_utils.h +++ b/openbsc/include/openbsc/gsm_utils.h @@ -37,5 +37,12 @@ int ms_pwr_dbm(enum gsm_band band, u_int8_t lvl); int rxlev2dbm(u_int8_t rxlev); u_int8_t dbm2rxlev(int dbm); +/* According to GSM 04.08 Chapter 10.5.2.29 */ +static inline int rach_max_retrans_val2raw(int val) { return (val >> 1) & 3; } +static inline int rach_max_retrans_raw2val(int raw) { + const int tbl[4] = { 1, 2, 4, 7 }; + return tbl[raw & 3]; +} + void generate_backtrace(); #endif diff --git a/openbsc/src/bsc_init.c b/openbsc/src/bsc_init.c index ae6f163..0e6e3dc 100644 --- a/openbsc/src/bsc_init.c +++ b/openbsc/src/bsc_init.c @@ -823,8 +823,8 @@ static int bootstrap_bts(struct gsm_bts *bts) /* some defaults for our system information */ bts->si_common.rach_control.re = 1; /* no re-establishment */ - bts->si_common.rach_control.tx_integer = 5; /* 8 slots spread */ - bts->si_common.rach_control.max_trans = 3; /* 7 retransmissions */ + bts->si_common.rach_control.tx_integer = bts->network->rach.tx_integer; + bts->si_common.rach_control.max_trans = bts->network->rach.max_retrans; bts->si_common.rach_control.t2 = 4; /* no emergency calls */ bts->si_common.cell_options.radio_link_timeout = 2; /* 12 */ diff --git a/openbsc/src/gsm_data.c b/openbsc/src/gsm_data.c index 94ed91b..a4a4fb7 100644 --- a/openbsc/src/gsm_data.c +++ b/openbsc/src/gsm_data.c @@ -206,6 +206,8 @@ struct gsm_network *gsm_network_init(u_int16_t country_code, u_int16_t network_c net->country_code = country_code; net->network_code = network_code; net->num_bts = 0; + net->rach.max_retrans = 3; /* 7 retransmissions */ + net->rach.tx_integer = 9; /* 12 slots spread - 217/115 slots delay */ net->T3101 = GSM_T3101_DEFAULT; net->T3113 = GSM_T3113_DEFAULT; /* FIXME: initialize all other timers! */ diff --git a/openbsc/src/vty_interface.c b/openbsc/src/vty_interface.c index 20df909..9dc7253 100644 --- a/openbsc/src/vty_interface.c +++ b/openbsc/src/vty_interface.c @@ -91,6 +91,10 @@ static void net_dump_vty(struct vty *vty, struct gsm_network *net) VTY_NEWLINE); vty_out(vty, " NECI (TCH/H): %u%s", net->neci, VTY_NEWLINE); + vty_out(vty, " RACH TX-Integer: %u%s", net->rach.tx_integer, + VTY_NEWLINE); + vty_out(vty, " RACH Max retransmissions: %u%s", rach_max_retrans_raw2val(net->rach.max_retrans), + VTY_NEWLINE); vty_out(vty, " RRLP Mode: %s%s", rrlp_mode_name(net->rrlp.mode), VTY_NEWLINE); vty_out(vty, " MM Info: %s%s", net->send_mm_info ? "On" : "Off", @@ -295,6 +299,8 @@ static int config_write_net(struct vty *vty) gsmnet->reject_cause, VTY_NEWLINE); vty_out(vty, " encryption a5 %u%s", gsmnet->a5_encryption, VTY_NEWLINE); vty_out(vty, " neci %u%s", gsmnet->neci, VTY_NEWLINE); + vty_out(vty, " rach tx integer %u%s", gsmnet->rach.tx_integer, VTY_NEWLINE); + vty_out(vty, " rach max retransmission %u%s", rach_max_retrans_raw2val(gsmnet->rach.max_retrans), VTY_NEWLINE); vty_out(vty, " rrlp mode %s%s", rrlp_mode_name(gsmnet->rrlp.mode), VTY_NEWLINE); vty_out(vty, " mm info %u%s", gsmnet->send_mm_info, VTY_NEWLINE); @@ -848,6 +854,24 @@ DEFUN(cfg_net_neci, return CMD_SUCCESS; } +DEFUN(cfg_net_rach_tx_integer, + cfg_net_rach_tx_integer_cmd, + "rach tx integer <0-15>", + "Set the raw tx integer value in RACH Control parameters IE") +{ + gsmnet->rach.tx_integer = atoi(argv[0]) & 0xf; + return CMD_SUCCESS; +} + +DEFUN(cfg_net_rach_max_retransmission, + cfg_net_rach_max_retransmission_cmd, + "rach max retransmission (1|2|4|7)", + "Set the maximum number of RACH burst retransmissions") +{ + gsmnet->rach.max_retrans = rach_max_retrans_val2raw(atoi(argv[0])); + return CMD_SUCCESS; +} + DEFUN(cfg_net_rrlp_mode, cfg_net_rrlp_mode_cmd, "rrlp mode (none|ms-based|ms-preferred|ass-preferred)", "Set the Radio Resource Location Protocol Mode") -- 1.6.5.1 From 246tnt at gmail.com Sun Dec 20 17:16:46 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 20 Dec 2009 18:16:46 +0100 Subject: [PATCH 3/3] Implement a better sending of pending SMS In-Reply-To: <1261329406-3058-2-git-send-email-246tnt@gmail.com> References: <1261329406-3058-1-git-send-email-246tnt@gmail.com> <1261329406-3058-2-git-send-email-246tnt@gmail.com> Message-ID: <1261329406-3058-3-git-send-email-246tnt@gmail.com> From: Sylvain Munaut The previous implementation had some shortcomings: - If the MIN ID given was not the exact id of the first unsent SMS, it would try to submit the same sms several time until id++ finally made id go to the next one. - If a subscriber had several SMS pending it would try to submit them individually (only to get rejected because a paging for that subscriber was already in progress) Signed-off-by: Sylvain Munaut --- openbsc/src/db.c | 27 +++++++++++++++++++++++++++ openbsc/src/vty_interface_layer3.c | 17 +++++++---------- 2 files changed, 34 insertions(+), 10 deletions(-) diff --git a/openbsc/src/db.c b/openbsc/src/db.c index ebfe923..b796350 100644 --- a/openbsc/src/db.c +++ b/openbsc/src/db.c @@ -788,6 +788,33 @@ struct gsm_sms *db_sms_get_unsent(struct gsm_network *net, int min_id) return sms; } +struct gsm_sms *db_sms_get_unsent_by_subscr(struct gsm_network *net, int min_subscr_id) +{ + dbi_result result; + struct gsm_sms *sms; + + result = dbi_conn_queryf(conn, + "SELECT * FROM SMS,Subscriber " + "WHERE sms.receiver_id >= %llu AND sms.sent is NULL " + "AND sms.receiver_id = subscriber.id " + "AND subscriber.lac > 0 " + "ORDER BY sms.receiver_id, id LIMIT 1", + min_subscr_id); + if (!result) + return NULL; + + if (!dbi_result_next_row(result)) { + dbi_result_free(result); + return NULL; + } + + sms = sms_from_result(net, result); + + dbi_result_free(result); + + return sms; +} + /* retrieve the next unsent SMS for a given subscriber */ struct gsm_sms *db_sms_get_unsent_for_subscr(struct gsm_subscriber *subscr) { diff --git a/openbsc/src/vty_interface_layer3.c b/openbsc/src/vty_interface_layer3.c index 4cc08c2..70e8445 100644 --- a/openbsc/src/vty_interface_layer3.c +++ b/openbsc/src/vty_interface_layer3.c @@ -143,23 +143,20 @@ DEFUN(show_subscr_cache, DEFUN(sms_send_pend, sms_send_pend_cmd, - "sms send pending MIN_ID", - "Send all pending SMS starting from MIN_ID") + "sms send pending", + "Send all pending SMS") { struct gsm_sms *sms; - int id = atoi(argv[0]); + int id = 0; while (1) { - sms = db_sms_get_unsent(gsmnet, id++); + sms = db_sms_get_unsent_by_subscr(gsmnet, id); if (!sms) - return CMD_WARNING; - - if (!sms->receiver) { - sms_free(sms); - continue; - } + break; gsm411_send_sms_subscr(sms->receiver, sms); + + id = sms->receiver->id + 1; } return CMD_SUCCESS; -- 1.6.5.1 From laforge at gnumonks.org Tue Dec 22 12:44:45 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 22 Dec 2009 13:44:45 +0100 Subject: [PATCH 3/3] Implement a better sending of pending SMS In-Reply-To: <1261329406-3058-3-git-send-email-246tnt@gmail.com> References: <1261329406-3058-1-git-send-email-246tnt@gmail.com> <1261329406-3058-2-git-send-email-246tnt@gmail.com> <1261329406-3058-3-git-send-email-246tnt@gmail.com> Message-ID: <20091222124445.GA14330@prithivi.gnumonks.org> thanks, applied. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Dec 21 00:14:33 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Dec 2009 01:14:33 +0100 Subject: [PATCH 2/3] net: Allow config of RACH control parameters tx-integer & max retrans In-Reply-To: <1261329406-3058-2-git-send-email-246tnt@gmail.com> References: <1261329406-3058-1-git-send-email-246tnt@gmail.com> <1261329406-3058-2-git-send-email-246tnt@gmail.com> Message-ID: <20091221001433.GM14330@prithivi.gnumonks.org> Hi Sylvain, > Tweaking theses can be useful especially tx-integer that influence > both the spread of rach attemps and the delay between two attemps. I like the idea of making this configurable, and yes our defaults are probably not all that great. However, I think those parameters are inherently an attribute of the BTS, not the network. So if you don't mind, please re-submit with adding the same data to the struct gsm_bts rather the struct gsm_network (and of course also move the vty parameters to the bts section). -- - 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 Dec 21 00:12:00 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Dec 2009 01:12:00 +0100 Subject: [PATCH 1/3] chan_alloc: Delete T3101 on lchan_free as well In-Reply-To: <1261329406-3058-1-git-send-email-246tnt@gmail.com> References: <1261329406-3058-1-git-send-email-246tnt@gmail.com> Message-ID: <20091221001200.GL14330@prithivi.gnumonks.org> On Sun, Dec 20, 2009 at 06:16:44PM +0100, Sylvain Munaut wrote: > If a RF channel is assigned but no response is ever heard from > the phone, we will receive a CONNECTION FAIL from the BTS, > triggering a RF release freeing the channel. Then sometime later, > T3101 will expire as well and free the channel again ... Thanks, applied. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Sun Dec 20 21:06:51 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 20 Dec 2009 22:06:51 +0100 Subject: [PATCH] ipaccess: Send RTP Payload IE for CRCX & MDCX Message-ID: <1261343211-4996-1-git-send-email-246tnt@gmail.com> From: Sylvain Munaut For GSM V1 FR, the payload type is fixed to 3 in the RFC. But for the other codecs, the payload type is dynamically assigned between 96 and 127. Here, we use a static mapping internal to OpenBSC. This patch is needed to make a rather old 139 unit (with sw version 120a002_v149b42d0) work with something else than FR codec. I also tested this patch on a newer 139 (with sw version 120a352_v267b22d0) to make sure it didn't add a regression. More testing with newer EDGE units should be done by whoever has some of theses. Signed-off-by: Sylvain Munaut --- openbsc/include/openbsc/gsm_data.h | 1 + openbsc/include/openbsc/rtp_proxy.h | 6 ++++ openbsc/src/abis_rsl.c | 53 ++++++++++++++++++++++++++++++++-- openbsc/src/rtp_proxy.c | 3 -- 4 files changed, 56 insertions(+), 7 deletions(-) diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h index bc1dbe6..16d6d94 100644 --- a/openbsc/include/openbsc/gsm_data.h +++ b/openbsc/include/openbsc/gsm_data.h @@ -204,6 +204,7 @@ struct gsm_lchan { u_int16_t bound_port; u_int16_t connect_port; u_int16_t conn_id; + u_int8_t rtp_payload; u_int8_t rtp_payload2; u_int8_t speech_mode; struct rtp_socket *rtp_socket; diff --git a/openbsc/include/openbsc/rtp_proxy.h b/openbsc/include/openbsc/rtp_proxy.h index a3e4596..07cf5a2 100644 --- a/openbsc/include/openbsc/rtp_proxy.h +++ b/openbsc/include/openbsc/rtp_proxy.h @@ -28,6 +28,12 @@ #include #include +#define RTP_PT_GSM_FULL 3 +#define RTP_PT_GSM_HALF 96 +#define RTP_PT_GSM_EFR 97 +#define RTP_PT_AMR_FULL 98 +#define RTP_PT_AMR_HALF 99 + enum rtp_rx_action { RTP_NONE, RTP_PROXY, diff --git a/openbsc/src/abis_rsl.c b/openbsc/src/abis_rsl.c index 2d55806..f4c42b8 100644 --- a/openbsc/src/abis_rsl.c +++ b/openbsc/src/abis_rsl.c @@ -39,6 +39,7 @@ #include #include #include +#include #define RSL_ALLOC_SIZE 1024 #define RSL_ALLOC_HEADROOM 128 @@ -1496,6 +1497,44 @@ static u_int8_t ipa_smod_s_for_lchan(struct gsm_lchan *lchan) return 0; } +static u_int8_t ipa_rtp_pt_for_lchan(struct gsm_lchan *lchan) +{ + switch (lchan->tch_mode) { + case GSM48_CMODE_SPEECH_V1: + switch (lchan->type) { + case GSM_LCHAN_TCH_F: + return RTP_PT_GSM_FULL; + case GSM_LCHAN_TCH_H: + return RTP_PT_GSM_HALF; + default: + break; + } + case GSM48_CMODE_SPEECH_EFR: + switch (lchan->type) { + case GSM_LCHAN_TCH_F: + return RTP_PT_GSM_EFR; + /* there's no half-rate EFR */ + default: + break; + } + case GSM48_CMODE_SPEECH_AMR: + switch (lchan->type) { + case GSM_LCHAN_TCH_F: + return RTP_PT_AMR_FULL; + case GSM_LCHAN_TCH_H: + return RTP_PT_AMR_HALF; + default: + break; + } + default: + break; + } + LOGP(DRSL, LOGL_ERROR, "Cannot determine ip.access rtp payload type for " + "tch_mode == 0x%02x\n & lchan_type == %d", + lchan->tch_mode, lchan->type); + return 0; +} + /* ip.access specific RSL extensions */ static void ipac_parse_rtp(struct gsm_lchan *lchan, struct tlv_parsed *tv) { @@ -1562,11 +1601,14 @@ int rsl_ipacc_crcx(struct gsm_lchan *lchan) /* 0x1- == receive-only, 0x-1 == EFR codec */ lchan->abis_ip.speech_mode = 0x10 | ipa_smod_s_for_lchan(lchan); + lchan->abis_ip.rtp_payload = ipa_rtp_pt_for_lchan(lchan); msgb_tv_put(msg, RSL_IE_IPAC_SPEECH_MODE, lchan->abis_ip.speech_mode); + msgb_tv_put(msg, RSL_IE_IPAC_RTP_PAYLOAD, lchan->abis_ip.rtp_payload); DEBUGP(DRSL, "channel=%s chan_nr=0x%02x IPAC_BIND " - "speech_mode=0x%02x\n", gsm_ts_name(lchan->ts), - dh->chan_nr, lchan->abis_ip.speech_mode); + "RTP_PAYLOAD=%d speech_mode=0x%02x\n", + gsm_ts_name(lchan->ts), dh->chan_nr, + lchan->abis_ip.rtp_payload, lchan->abis_ip.speech_mode); msg->trx = lchan->ts->trx; @@ -1593,12 +1635,14 @@ int rsl_ipacc_mdcx(struct gsm_lchan *lchan, u_int32_t ip, u_int16_t port, /* 0x0- == both directions, 0x-1 == EFR codec */ lchan->abis_ip.speech_mode = 0x00 | ipa_smod_s_for_lchan(lchan); + lchan->abis_ip.rtp_payload = ipa_rtp_pt_for_lchan(lchan); ia.s_addr = htonl(ip); DEBUGP(DRSL, "channel=%s chan_nr=0x%02x IPAC_MDCX " - "IP=%s PORT=%d RTP_PAYLOAD2=%d CONN_ID=%d speech_mode=0x%02x\n", + "IP=%s PORT=%d RTP_PAYLOAD=%d RTP_PAYLOAD2=%d CONN_ID=%d speech_mode=0x%02x\n", gsm_ts_name(lchan->ts), dh->chan_nr, inet_ntoa(ia), port, - rtp_payload2, lchan->abis_ip.conn_id, lchan->abis_ip.speech_mode); + lchan->abis_ip.rtp_payload, rtp_payload2, + lchan->abis_ip.conn_id, lchan->abis_ip.speech_mode); msgb_tv16_put(msg, RSL_IE_IPAC_CONN_ID, lchan->abis_ip.conn_id); msgb_v_put(msg, RSL_IE_IPAC_REMOTE_IP); @@ -1606,6 +1650,7 @@ int rsl_ipacc_mdcx(struct gsm_lchan *lchan, u_int32_t ip, u_int16_t port, *att_ip = ia.s_addr; msgb_tv16_put(msg, RSL_IE_IPAC_REMOTE_PORT, port); msgb_tv_put(msg, RSL_IE_IPAC_SPEECH_MODE, lchan->abis_ip.speech_mode); + msgb_tv_put(msg, RSL_IE_IPAC_RTP_PAYLOAD, lchan->abis_ip.rtp_payload); if (rtp_payload2) msgb_tv_put(msg, RSL_IE_IPAC_RTP_PAYLOAD2, rtp_payload2); diff --git a/openbsc/src/rtp_proxy.c b/openbsc/src/rtp_proxy.c index 5513497..6896755 100644 --- a/openbsc/src/rtp_proxy.c +++ b/openbsc/src/rtp_proxy.c @@ -81,9 +81,6 @@ struct rtp_x_hdr { #define RTP_VERSION 2 -#define RTP_PT_GSM_FULL 3 -#define RTP_PT_GSM_EFR 97 - /* decode an rtp frame and create a new buffer with payload */ static int rtp_decode(struct msgb *msg, u_int32_t callref, struct msgb **data) { -- 1.6.5.1 From Andreas.Eversberg at versatel.de Sun Dec 20 21:15:16 2009 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Sun, 20 Dec 2009 22:15:16 +0100 Subject: fix on trau frame check Message-ID: minor fix for master branch. (self explaining) LCR works with the main branch also. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: trau.fix Type: application/octet-stream Size: 558 bytes Desc: trau.fix URL: From laforge at gnumonks.org Mon Dec 21 00:19:11 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Dec 2009 01:19:11 +0100 Subject: fix on trau frame check In-Reply-To: References: Message-ID: <20091221001911.GN14330@prithivi.gnumonks.org> Dear Andreas, On Sun, Dec 20, 2009 at 10:15:16PM +0100, Andreas.Eversberg wrote: > minor fix for master branch. (self explaining) thanks, applying it right now. > LCR works with the main branch also. thanks for testing. this is good news! -- - 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 Dec 21 00:07:28 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Dec 2009 01:07:28 +0100 Subject: OpenBSC status report / Handover Message-ID: <20091221000728.GJ14330@prithivi.gnumonks.org> Hi! Just a "quick" status report about the progress I've made with the code over the last three days, and what is now in 'master': 1) handover is not only working on a signalling level, but also fully working with actual voice traffic This turned out to be a major headache, since we don't [yet?] have a proper RTP media gateway and so far decided to simply relay the RTP frames rather than doing proper processing. In case of handover though, the RTP source changes (different SSRC / timestamp / sequence) - plus we also get some dropped frames and have to ensure that we don't hide that fact from the receiver. In order to make it work, I added a new "MNCC RTP Proxy" mode, which is automatically selected if you a) enable the RTP Proxy mode with "-P" on the command line, and b) enable handover using the 'handover 1' command on the VTY The Handover decision (handover_decision.c) is currently still based on a single MEASUREMENT REPORT, i.e. way too volatile. This was intended for testing, where we need as many handovers as possible. I've meanwhile written a lot of additional code to implement proper measurement averaging and neighbor cell selection. This is not committed yet, but will be committed by tomorrow. 2) Support for MNCC (lcr) with RTP based BTS is in 'master' There's no need for any old branches or patches for this anymore 3) Support for EFR frames with RTP based BTS in MNCC 4) No half-rate support at 26C3. The integration with lcr is likely too much work, and I think we should try not to implement even more features that have not yet received lots of testing 5) fixing tons of compiler warnings all over the code 6) fix segfault in RRLP in case of unsuccessful paging (sorry sylvain, I fixed this independently before seeing your patch, but I actually prefer your solution, will look at it tomorrow) 7) correct System Information Type 5 and 6 on ip.access The two BTS types implement the RSL SACCH FILLing slightly different, resulting in broken neighbor cell lists on ip.access systems. Any testing of current master that you can do is very much appreciated, let's hope we can catch more bugs before we go live at 26C3. 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 Mon Dec 21 16:10:30 2009 From: zecke at selfish.org (Holger Freyther) Date: Mon, 21 Dec 2009 17:10:30 +0100 Subject: [PATCH] Possible BS11 fixes.. Message-ID: <200912211710.30477.zecke@selfish.org> Hi Harlad, does this make sense to you? openbsc/src/abis_nm.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/openbsc/src/abis_nm.c b/openbsc/src/abis_nm.c index bb7248b..dce1c35 100644 --- a/openbsc/src/abis_nm.c +++ b/openbsc/src/abis_nm.c @@ -653,13 +653,13 @@ objclass2nmstate(struct gsm_bts *bts, u_int8_t obj_class, nm_state = &bts->bs11.cclk.nm_state; break; case BS11_OBJ_BBSIG: - if (obj_inst->ts_nr > bts->num_trx) + if (obj_inst->trx_nr >= bts->num_trx) return NULL; trx = gsm_bts_trx_num(bts, obj_inst->trx_nr); nm_state = &trx->bs11.bbsig.nm_state; break; case BS11_OBJ_PA: - if (obj_inst->ts_nr > bts->num_trx) + if (obj_inst->trx_nr >= bts->num_trx) return NULL; trx = gsm_bts_trx_num(bts, obj_inst->trx_nr); nm_state = &trx->bs11.pa.nm_state; -- 1.6.3.3 From laforge at gnumonks.org Mon Dec 21 21:13:30 2009 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Dec 2009 22:13:30 +0100 Subject: [PATCH] Possible BS11 fixes.. In-Reply-To: <200912211710.30477.zecke@selfish.org> References: <200912211710.30477.zecke@selfish.org> Message-ID: <20091221211330.GT14330@prithivi.gnumonks.org> On Mon, Dec 21, 2009 at 05:10:30PM +0100, Holger Freyther wrote: > Hi Harlad, > > does this make sense to you? not sure. The Siemens vendor specific attributes don't really follow the standard 12.21 conventions and somethimes seem to use arbitrary object intance fields for whatever they seem fit. I think this needs careful analysis of actual protocol traces before any modifiations. -- - 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 Tue Dec 22 02:16:14 2009 From: zecke at selfish.org (Holger Freyther) Date: Tue, 22 Dec 2009 03:16:14 +0100 Subject: [PATCH] Possible BS11 fixes.. In-Reply-To: <20091221211330.GT14330@prithivi.gnumonks.org> References: <200912211710.30477.zecke@selfish.org> <20091221211330.GT14330@prithivi.gnumonks.org> Message-ID: <200912220316.14382.zecke@selfish.org> On Monday 21 December 2009 22:13:30 Harald Welte wrote: > On Mon, Dec 21, 2009 at 05:10:30PM +0100, Holger Freyther wrote: > > Hi Harlad, > > > > does this make sense to you? > > not sure. The Siemens vendor specific attributes don't really follow the > standard 12.21 conventions and somethimes seem to use arbitrary object > intance fields for whatever they seem fit. I think this needs careful > analysis of actual protocol traces before any modifiations. I agree but the usage is not consistent. It is using ts_nr to compare to max_trx and then uses trx_nr to access things. But we share the same thought that this needs careful consideration and testing. z. From 246tnt at gmail.com Mon Dec 21 23:41:47 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 22 Dec 2009 00:41:47 +0100 Subject: [PATCH] bts: Allow config of RACH control parameters tx-integer & max retrans Message-ID: <1261438907-12488-1-git-send-email-246tnt@gmail.com> From: Sylvain Munaut Tweaking theses can be useful especially tx-integer that influence both the spread of rach attemps and the delay between two attemps. Looking up GSM 04.08 3.3.1.1.2 & 10.5.2.29 can help determine good values. The default are choosed with a wide spacing between attemps (tx integer = 9 -> T=12 & S=217 (non-combined CCCH/SDCCH) or 115 (for combined CCCH/SDCCH)). This alleviates the problem of responding to several RACH attempts by a same MS, allocating several RF channels when only 1 is needed. Signed-off-by: Sylvain Munaut --- openbsc/include/openbsc/gsm_utils.h | 7 +++++++ openbsc/src/bsc_init.c | 5 ----- openbsc/src/gsm_data.c | 4 ++++ openbsc/src/vty_interface.c | 32 ++++++++++++++++++++++++++++++++ 4 files changed, 43 insertions(+), 5 deletions(-) diff --git a/openbsc/include/openbsc/gsm_utils.h b/openbsc/include/openbsc/gsm_utils.h index 5809221..56a4120 100644 --- a/openbsc/include/openbsc/gsm_utils.h +++ b/openbsc/include/openbsc/gsm_utils.h @@ -37,5 +37,12 @@ int ms_pwr_dbm(enum gsm_band band, u_int8_t lvl); int rxlev2dbm(u_int8_t rxlev); u_int8_t dbm2rxlev(int dbm); +/* According to GSM 04.08 Chapter 10.5.2.29 */ +static inline int rach_max_trans_val2raw(int val) { return (val >> 1) & 3; } +static inline int rach_max_trans_raw2val(int raw) { + const int tbl[4] = { 1, 2, 4, 7 }; + return tbl[raw & 3]; +} + void generate_backtrace(); #endif diff --git a/openbsc/src/bsc_init.c b/openbsc/src/bsc_init.c index 547aaa9..c6d891c 100644 --- a/openbsc/src/bsc_init.c +++ b/openbsc/src/bsc_init.c @@ -825,11 +825,6 @@ static int bootstrap_bts(struct gsm_bts *bts) /* T3212 is set from vty/config */ /* some defaults for our system information */ - bts->si_common.rach_control.re = 1; /* no re-establishment */ - bts->si_common.rach_control.tx_integer = 5; /* 8 slots spread */ - bts->si_common.rach_control.max_trans = 3; /* 7 retransmissions */ - bts->si_common.rach_control.t2 = 4; /* no emergency calls */ - bts->si_common.cell_options.radio_link_timeout = 2; /* 12 */ bts->si_common.cell_options.dtx = 2; /* MS shall not use upplink DTX */ bts->si_common.cell_options.pwrc = 0; /* PWRC not set */ diff --git a/openbsc/src/gsm_data.c b/openbsc/src/gsm_data.c index 12f439b..d6ebd92 100644 --- a/openbsc/src/gsm_data.c +++ b/openbsc/src/gsm_data.c @@ -175,6 +175,10 @@ struct gsm_bts *gsm_bts_alloc(struct gsm_network *net, enum gsm_bts_type type, bts->si_common.cell_alloc.data = bts->si_common.data.cell_alloc; bts->si_common.cell_alloc.data_len = sizeof(bts->si_common.data.cell_alloc); + bts->si_common.rach_control.re = 1; /* no re-establishment */ + bts->si_common.rach_control.tx_integer = 9; /* 12 slots spread - 217/115 slots delay */ + bts->si_common.rach_control.max_trans = 3; /* 7 retransmissions */ + bts->si_common.rach_control.t2 = 4; /* no emergency calls */ for (i = 0; i < ARRAY_SIZE(bts->gprs.nsvc); i++) { bts->gprs.nsvc[i].bts = bts; diff --git a/openbsc/src/vty_interface.c b/openbsc/src/vty_interface.c index b13dc5f..5e42e6b 100644 --- a/openbsc/src/vty_interface.c +++ b/openbsc/src/vty_interface.c @@ -140,6 +140,11 @@ static void bts_dump_vty(struct vty *vty, struct gsm_bts *bts) VTY_NEWLINE); vty_out(vty, "Cell Reselection Hysteresis: %u dBm%s", bts->si_common.cell_sel_par.cell_resel_hyst*2, VTY_NEWLINE); + vty_out(vty, "RACH TX-Integer: %u%s", bts->si_common.rach_control.tx_integer, + VTY_NEWLINE); + vty_out(vty, "RACH Max transmissions: %u%s", + rach_max_trans_raw2val(bts->si_common.rach_control.max_trans), + VTY_NEWLINE); if (bts->si_common.rach_control.cell_bar) vty_out(vty, " CELL IS BARRED%s", VTY_NEWLINE); if (is_ipaccess_bts(bts)) @@ -258,6 +263,11 @@ static void config_write_bts_single(struct vty *vty, struct gsm_bts *bts) vty_out(vty, " channel allocator %s%s", bts->chan_alloc_reverse ? "descending" : "ascending", VTY_NEWLINE); + vty_out(vty, " rach tx integer %u%s", + bts->si_common.rach_control.tx_integer, VTY_NEWLINE); + vty_out(vty, " rach max transmission %u%s", + rach_max_trans_raw2val(bts->si_common.rach_control.max_trans), + VTY_NEWLINE); if (bts->si_common.rach_control.cell_bar) vty_out(vty, " cell barred 1%s", VTY_NEWLINE); if (is_ipaccess_bts(bts)) { @@ -1196,6 +1206,26 @@ DEFUN(cfg_bts_challoc, cfg_bts_challoc_cmd, return CMD_SUCCESS; } +DEFUN(cfg_bts_rach_tx_integer, + cfg_bts_rach_tx_integer_cmd, + "rach tx integer <0-15>", + "Set the raw tx integer value in RACH Control parameters IE") +{ + struct gsm_bts *bts = vty->index; + bts->si_common.rach_control.tx_integer = atoi(argv[0]) & 0xf; + return CMD_SUCCESS; +} + +DEFUN(cfg_bts_rach_max_trans, + cfg_bts_rach_max_trans_cmd, + "rach max transmission (1|2|4|7)", + "Set the maximum number of RACH burst transmissions") +{ + struct gsm_bts *bts = vty->index; + bts->si_common.rach_control.max_trans = rach_max_trans_val2raw(atoi(argv[0])); + return CMD_SUCCESS; +} + DEFUN(cfg_bts_cell_barred, cfg_bts_cell_barred_cmd, "cell barred (0|1)", "Should this cell be barred from access?") @@ -1482,6 +1512,8 @@ int bsc_vty_init(struct gsm_network *net) install_element(BTS_NODE, &cfg_bts_oml_e1_cmd); install_element(BTS_NODE, &cfg_bts_oml_e1_tei_cmd); install_element(BTS_NODE, &cfg_bts_challoc_cmd); + install_element(BTS_NODE, &cfg_bts_rach_tx_integer_cmd); + install_element(BTS_NODE, &cfg_bts_rach_max_trans_cmd); install_element(BTS_NODE, &cfg_bts_cell_barred_cmd); install_element(BTS_NODE, &cfg_bts_ms_max_power_cmd); install_element(BTS_NODE, &cfg_bts_per_loc_upd_cmd); -- 1.6.5.1 From laforge at gnumonks.org Tue Dec 22 12:24:39 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 22 Dec 2009 13:24:39 +0100 Subject: [PATCH] bts: Allow config of RACH control parameters tx-integer & max retrans In-Reply-To: <1261438907-12488-1-git-send-email-246tnt@gmail.com> References: <1261438907-12488-1-git-send-email-246tnt@gmail.com> Message-ID: <20091222122439.GY14330@prithivi.gnumonks.org> thanks, applying now. -- - 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 Tue Dec 22 20:02:46 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 22 Dec 2009 21:02:46 +0100 Subject: RRLP / ephemeris data Message-ID: <20091222200246.GK14330@prithivi.gnumonks.org> Dear Daniel and Jan, you have been working very closely with and on the u-blox GPS receiver during your work on the Openmoko GTA02. As far as I know, it is possible to obtain the ephemeris data from a u-blox receiver. I would like to see some code that obtains and converts that ephemeris data into the format described by the RRLP protocol specification. I know this involves asn.1 PER ugliness, but this can all be done well outside the OpenBSC codebase. What I'll propose is to simply use some pattern matching to determine the RRLP request for assistance data, and if such a request exists, open some file in the filesystem and send the contents binary as-is to the phone in response. Any responses from the phone are already stored in the database anyway. In case any of you are interested in working on something to generate the required ephemeris data and have time before or even at the 26C3, you can simply give me the resulting binary file, I can drop it into the OpenBSC directory and we'll see what happens. If this doesn't happen right now, it doesn't matter all that much, as the 26C3 is an indoor event and I don't think we'll be getting that many GPS fixes in such an environment anyway. But eventually, for the next outdoor test, and to do some more RRLP security research, the ephemeris data formatter would be really great! 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 246tnt at gmail.com Tue Dec 22 20:20:15 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 22 Dec 2009 21:20:15 +0100 Subject: RRLP / ephemeris data In-Reply-To: <20091222200246.GK14330@prithivi.gnumonks.org> References: <20091222200246.GK14330@prithivi.gnumonks.org> Message-ID: <866320f70912221220l12fe28b6x300fe1339ae56647@mail.gmail.com> Just FYI, I have code that generates the ephemeris data in the good format for RRLP message from a u-blox receiver. I sent it to dieter, just need to plug it into openbsc. On Tue, Dec 22, 2009 at 9:02 PM, Harald Welte wrote: > Dear Daniel and Jan, > > you have been working very closely with and on the u-blox GPS receiver > during your work on the Openmoko GTA02. > > As far as I know, it is possible to obtain the ephemeris data from a u-blox > receiver. > > I would like to see some code that obtains and converts that ephemeris data > into the format described by the RRLP protocol specification. I know this > involves asn.1 PER ugliness, but this can all be done well outside the > OpenBSC > codebase. > > What I'll propose is to simply use some pattern matching to determine the > RRLP > request for assistance data, and if such a request exists, open some file > in > the filesystem and send the contents binary as-is to the phone in response. > > Any responses from the phone are already stored in the database anyway. > > In case any of you are interested in working on something to generate the > required ephemeris data and have time before or even at the 26C3, you can > simply give me the resulting binary file, I can drop it into the OpenBSC > directory and we'll see what happens. > > If this doesn't happen right now, it doesn't matter all that much, as the > 26C3 > is an indoor event and I don't think we'll be getting that many GPS fixes > in such an environment anyway. But eventually, for the next outdoor test, > and to do some more RRLP security research, the ephemeris data formatter > would be really great! > > Cheers, > Harald > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Tue Dec 22 20:23:23 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 22 Dec 2009 21:23:23 +0100 Subject: RRLP / ephemeris data In-Reply-To: <866320f70912221220l12fe28b6x300fe1339ae56647@mail.gmail.com> References: <20091222200246.GK14330@prithivi.gnumonks.org> <866320f70912221220l12fe28b6x300fe1339ae56647@mail.gmail.com> Message-ID: <866320f70912221223h11f1a99ej85542c2585bb1acc@mail.gmail.com> Damn, I forgot the link : http://www.246tnt.com/files/rrlp-20091101.tar.bz2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Dec 22 20:55:42 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 22 Dec 2009 21:55:42 +0100 Subject: RRLP / ephemeris data In-Reply-To: <866320f70912221220l12fe28b6x300fe1339ae56647@mail.gmail.com> References: <20091222200246.GK14330@prithivi.gnumonks.org> <866320f70912221220l12fe28b6x300fe1339ae56647@mail.gmail.com> Message-ID: <20091222205541.GN14330@prithivi.gnumonks.org> On Tue, Dec 22, 2009 at 09:20:15PM +0100, Sylvain Munaut wrote: > Just FYI, I have code that generates the ephemeris data in the good format > for RRLP message from a u-blox receiver. > I sent it to dieter, just need to plug it into openbsc. That's great! I remember hearing/reading that you've been working on it, but never realised that this work was actually completed. Thanks a lot. I've imported it into the openbsc.git repository, hope you don't mind. -- - 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 Wed Dec 23 01:30:34 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 23 Dec 2009 02:30:34 +0100 Subject: RRLP / ephemeris data In-Reply-To: <20091222205541.GN14330@prithivi.gnumonks.org> References: <20091222200246.GK14330@prithivi.gnumonks.org> <866320f70912221220l12fe28b6x300fe1339ae56647@mail.gmail.com> <20091222205541.GN14330@prithivi.gnumonks.org> Message-ID: <866320f70912221730g4436a9b6v44908ff870df0778@mail.gmail.com> On Tue, Dec 22, 2009 at 9:55 PM, Harald Welte wrote: > On Tue, Dec 22, 2009 at 09:20:15PM +0100, Sylvain Munaut wrote: > > Just FYI, I have code that generates the ephemeris data in the good > format > > for RRLP message from a u-blox receiver. > > I sent it to dieter, just need to plug it into openbsc. > > That's great! > > I remember hearing/reading that you've been working on it, but never > realised that this work was actually completed. Thanks a lot. > The main.c is currently a test stub, reading from a file, printing on stdout, but fixing that into something usable for 26c3 shouldn't be long. I'm working on SMS and ciphering right now but at worse I could write something up in the plane or the day just before. The plan was to have a daemon running that would essentially play the role of the LCS, mapping a tcp session to a RRLP session. This way I could have re-used the same code for both openbsc/openbts. It also misses the Reference Position decoding/encoding (currently my home GPS coordinates are hardcoded :), I'll have to fix that. BTW, when do you setup the network ? I should be in Berlin the 26th late afternoon if you need help setup/pre-testing. > I've imported it into the openbsc.git repository, hope you don't mind. > Not at all, that's what it was written for :) Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Dec 23 09:36:28 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 23 Dec 2009 10:36:28 +0100 Subject: RRLP / ephemeris data In-Reply-To: <866320f70912221730g4436a9b6v44908ff870df0778@mail.gmail.com> References: <20091222200246.GK14330@prithivi.gnumonks.org> <866320f70912221220l12fe28b6x300fe1339ae56647@mail.gmail.com> <20091222205541.GN14330@prithivi.gnumonks.org> <866320f70912221730g4436a9b6v44908ff870df0778@mail.gmail.com> Message-ID: <20091223093628.GR14330@prithivi.gnumonks.org> Hi Sylvain, On Wed, Dec 23, 2009 at 02:30:34AM +0100, Sylvain Munaut wrote: > The main.c is currently a test stub, reading from a file, printing on > stdout, but fixing that into something usable for 26c3 shouldn't be long. > I'm working on SMS and ciphering right now but at worse I could write > something up in the plane or the day just before. > Don't bother with encryption (at least not for the 26C3)... > The plan was to have a daemon running that would essentially play the role > of the LCS, mapping a tcp session to a RRLP session. This way I could have > re-used the same code for both openbsc/openbts. Mh, that would be possible, too. I thought reading from a file is even simpler, but handing all data off to a TCP socket is certainly also not much more difficult. The biggest task is the APDU fragmentation/reassembly that needs to be done. At the moment I have no idea how flow control would be implemented for this, as we have a very fat TCP pipe to the LCS but a very narrow SDCCH on the other end. And the narrow pipe terminates at the BTS, while the TCP socket terminates at the BSC. We have no clue when the BTS's per-channel buffers will overrun, all we might get is a generic indication that the A-bis interface is overloaded (and that's too late). How big is the ephemeris data from your experience? > It also misses the Reference Position decoding/encoding (currently my home > GPS coordinates are hardcoded :), I'll have to fix that. That's quick to fix. > BTW, when do you setup the network ? I should be in Berlin the 26th late > afternoon if you need help setup/pre-testing. We'll set it up in the 25th and 26th morning, so by late afternoon everything should already be running (though the license only allows us to switch it on on the 27th). -- - 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 Wed Dec 23 10:34:51 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 23 Dec 2009 11:34:51 +0100 Subject: RRLP / ephemeris data In-Reply-To: <20091223093628.GR14330@prithivi.gnumonks.org> References: <20091222200246.GK14330@prithivi.gnumonks.org> <866320f70912221220l12fe28b6x300fe1339ae56647@mail.gmail.com> <20091222205541.GN14330@prithivi.gnumonks.org> <866320f70912221730g4436a9b6v44908ff870df0778@mail.gmail.com> <20091223093628.GR14330@prithivi.gnumonks.org> Message-ID: <866320f70912230234k698f8b00u146ebd80b8d0cf00@mail.gmail.com> > > The main.c is currently a test stub, reading from a file, printing on > > stdout, but fixing that into something usable for 26c3 shouldn't be long. > > I'm working on SMS and ciphering right now but at worse I could write > > something up in the plane or the day just before. > > > > Don't bother with encryption (at least not for the 26C3)... > I know it's not much use for events since you need a known Ki which most people don't have that. But looking at it yesterday, it seemed pretty straightforward to implement and if the user doesn't have a Ki in the HLR, that code path would not be executed at all ... Basically for : - LOCATION UPDATE REQUEST - PAGING RESPONSE - CM SERVICE REQUEST You need : - Test if key_seq is the last known key_seq, - If yes you can just re-use the last Kc and send cipher mode command - If no, need to do an auth request, then send cipher mode command - On cipher mode complete, just pursue the task you were asked to do (loc update or paging. for cm service ack, the cipher mode command means implicit ack). The biggest task is the APDU fragmentation/reassembly that needs to be done. > At the moment I have no idea how flow control would be implemented for > this, > as we have a very fat TCP pipe to the LCS but a very narrow SDCCH on the > other > end. And the narrow pipe terminates at the BTS, while the TCP socket > terminates at the BSC. We have no clue when the BTS's per-channel buffers > will overrun, all we might get is a generic indication that the A-bis > interface > is overloaded (and that's too late). > Application PDU do have a fragmentation mechanism but you can't use it. The spec says : """ The RRLP maximum PDU size is 242 octets. If the amount of data that needs to be sent is larger than RRLP maximum PDU size, the RRLP pseudo-segmentation shall be used. The RRLP pseudo-segmentation is the use of several RRLP components (one in each RRLP message) to deliver a large amount of information. For SMLC to MS messages, the Assistance Data component is the one that is sent several times in order to deliver the information. For MS to SMLC messages, the Measure Position Response component may be sent twice in order to deliver the information. Legacy MS and SMLC (3GPP Rel-4 or older) may send RRLP components that are larger than the RRLP maximum PDU size. In this case lower level segmentation will be used. """ However, in my experience, low level segmentation (as described in gsm 04.08 3.4.21.2.2) just isn't accepted by the handsets I have. So we have to use pseudo segmentation where we send multiple complete RRLP messages. > How big is the ephemeris data from your experience? > Around 12 APDU of 200 bytes in average. (for ref location + ref time + full almanach + ephemeris for 12 SVs). Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From spaar at mirider.augusta.de Wed Dec 23 14:45:27 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Wed, 23 Dec 2009 14:45:27 Subject: RRLP / ephemeris data Message-ID: <4b322d07.mirider@mirider.augusta.de> Hello Sylvain, I finally found the time to play with the RRLP encoding of the GPS assistance data, sorry for the long delay. When comparing the encoded PDUs with the data from an evaluation version of a commercial ASN1 too, I found several problems which seem to come from a bug in the ASN1 unaligned PER encoder of ASN1C. I can also confirm this problem by simply trying to decode the generated PDUs with the ASN1 decoder from ASN1C, it shows the same error as the commercial tool. I think I have found the bug and a fix for it, however I have not yet confirmed that it really works with a phone, I currently just check the PDUs. I will try to test it with a phone, if anyone is currently playing with RRLP, I can of course send the bug fix (I am just not yet 100% sure with it). Just in case, I use ASN1C from the SourceForge subversion repository. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From 246tnt at gmail.com Sun Dec 27 10:08:15 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 27 Dec 2009 11:08:15 +0100 Subject: RRLP / ephemeris data In-Reply-To: <4b322d07.mirider@mirider.augusta.de> References: <4b322d07.mirider@mirider.augusta.de> Message-ID: <866320f70912270208q49dae698y3aba4e3cd540d6b6@mail.gmail.com> Hi, I think I have found the bug and a fix for it, however I have not > yet confirmed that it really works with a phone, I currently just check > the PDUs. I will try to test it with a phone, if anyone is currently > playing with RRLP, I can of course send the bug fix (I am just not yet > 100% sure with it). > Yes, I'd definitly be interested in that bug fix :) > Just in case, I use ASN1C from the SourceForge subversion repository. > me as well. Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Dec 22 20:10:57 2009 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 22 Dec 2009 21:10:57 +0100 Subject: statistics tools for OpenBSC Message-ID: <20091222201057.GL14330@prithivi.gnumonks.org> Hi all! I've just added some code to OpenBSC which keeps counters for various events, such as the number of channel requests, how often we were out of channels, the number of delivered/submitted sms, paging statistics, etc. Those counters are available through the VTY for evaluation at runtime. There is now a "Counters" table in our database schema. It stores those counters in a generic way. The counters are stored to the database every minute. Each counter is identified by a string like "net.sms.delivered" The counters increment all the time, until OpenBSC terminates, when they will re-start from zero. I did not want to make the counters persistent (i.e. load them from the database) as it would cofuse users of the VTY. What's still missing now is some kind of script that uses those counters to generate something like nice charts. Given the way how the counters are stored in the database, it should be relatively easy to write a fairly generic tool that does not need any modification even if we add new counters. What I'm thinking is something like specifying the specific counters one is interested in at the command line, maybe also providing a start and end time. The graphs should then generally show the increments of the counters between two counter stores in the database. So if e.g. one minute ago the number of delivered SMS was '10', and now it is '15, then the actual value plotted in the graph should only be '5'. The only "difficulty" is to handle restarts of OpenBSC... but that's quite easy. All counters are monotonically incrementing, i.e. whenever you see a smaller counter, you can safely assume that openbsc was restarted and that we simply continue with the next diff, ignoring the negative one. If anyone is interested in working in such a tool (preferrably in python or perl, using their respective sqlite3 bindings), it would be greatly appreciated. However, please do coordinate on this mailing list... your time is too precious to be wasted by code duplication. Thanks in advance, 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 Dec 24 00:11:46 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 24 Dec 2009 01:11:46 +0100 Subject: statistics tools for OpenBSC In-Reply-To: <20091222201057.GL14330@prithivi.gnumonks.org> References: <20091222201057.GL14330@prithivi.gnumonks.org> Message-ID: <866320f70912231611j614b38cetd916a0e12cf3e47b@mail.gmail.com> Is someone already working on this ? It should be pretty straightforward to pipe this into a RRD database (rrdtool) and from there, do pretty much any graph you want ... It will handle wrap around / reset to 0 / differential all by itself. I'll have a look at this tomorrow if nobody manifests itself as already working on it. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Dec 24 08:27:49 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 24 Dec 2009 09:27:49 +0100 Subject: statistics tools for OpenBSC In-Reply-To: <866320f70912231611j614b38cetd916a0e12cf3e47b@mail.gmail.com> References: <20091222201057.GL14330@prithivi.gnumonks.org> <866320f70912231611j614b38cetd916a0e12cf3e47b@mail.gmail.com> Message-ID: <20091224082749.GE14330@prithivi.gnumonks.org> On Thu, Dec 24, 2009 at 01:11:46AM +0100, Sylvain Munaut wrote: > Is someone already working on this ? not that I'm aware of. > It should be pretty straightforward to pipe this into a RRD database > (rrdtool) and from there, do pretty much any graph you want ... > It will handle wrap around / reset to 0 / differential all by itself. great idea. > I'll have a look at this tomorrow if nobody manifests itself as already > working on it. thanks. But please, SMS stuff has higher priority. You can still work on the rrdtool integration after you've arrived at the event.. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From datacop at wireloss.net Fri Dec 25 00:41:06 2009 From: datacop at wireloss.net (Clemens Hopfer) Date: Fri, 25 Dec 2009 01:41:06 +0100 Subject: statistics tools for OpenBSC In-Reply-To: <20091224082749.GE14330@prithivi.gnumonks.org> References: <20091222201057.GL14330@prithivi.gnumonks.org> <866320f70912231611j614b38cetd916a0e12cf3e47b@mail.gmail.com> <20091224082749.GE14330@prithivi.gnumonks.org> Message-ID: <200912250141.06224.datacop@wireloss.net> Hi, I also thought about RRD, I'm writing on a small python script that gets the new values from the db (since the last update of the target rrd file) and updates the rrd file. At the moment it only supports one data source for a single rrd file, but I'll add commandline options for the file and counter name. I think this is the easiest solution, adding a new counter is just creating a new rrd file and adding a cronjob. It would be great if someone could post some sample data to do some tests. cu, Clemens Am Donnerstag 24 Dezember 2009 09:27:49 schrieb Harald Welte: > On Thu, Dec 24, 2009 at 01:11:46AM +0100, Sylvain Munaut wrote: > > Is someone already working on this ? > > not that I'm aware of. > > > It should be pretty straightforward to pipe this into a RRD database > > (rrdtool) and from there, do pretty much any graph you want ... > > It will handle wrap around / reset to 0 / differential all by itself. > > great idea. > > > I'll have a look at this tomorrow if nobody manifests itself as already > > working on it. > > thanks. But please, SMS stuff has higher priority. You can still work on > the rrdtool integration after you've arrived at the event.. > From laforge at gnumonks.org Fri Dec 25 02:07:34 2009 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 25 Dec 2009 03:07:34 +0100 Subject: statistics tools for OpenBSC In-Reply-To: <200912250141.06224.datacop@wireloss.net> References: <20091222201057.GL14330@prithivi.gnumonks.org> <866320f70912231611j614b38cetd916a0e12cf3e47b@mail.gmail.com> <20091224082749.GE14330@prithivi.gnumonks.org> <200912250141.06224.datacop@wireloss.net> Message-ID: <20091225020734.GL14330@prithivi.gnumonks.org> Hi Clemens, On Fri, Dec 25, 2009 at 01:41:06AM +0100, Clemens Hopfer wrote: > At the moment it only supports one data source for a single rrd file, but I'll > add commandline options for the file and counter name. > I think this is the easiest solution, adding a new counter is just creating a > new rrd file and adding a cronjob. well, it's also easy to generate a list of the counters from the sql database by using something like "select unique(name) from counters" and then iterate over that list... > It would be great if someone could post some sample data to do some tests. I cannot send you the full hlr.sqlite3 of my test machine, sorry. but I've attached the output of 'sqlite3 -csv hlr.sqlite3 "select * from counters;"'. The counter values are very low as I've been playing around with few phones and few events, but it should give you a feeling for it. btw: Will you be at 26C3? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: hlr-counters.csv.gz Type: application/octet-stream Size: 52212 bytes Desc: not available URL: From datacop at wireloss.net Fri Dec 25 02:56:37 2009 From: datacop at wireloss.net (Clemens Hopfer) Date: Fri, 25 Dec 2009 03:56:37 +0100 Subject: statistics tools for OpenBSC In-Reply-To: <20091225020734.GL14330@prithivi.gnumonks.org> References: <20091222201057.GL14330@prithivi.gnumonks.org> <200912250141.06224.datacop@wireloss.net> <20091225020734.GL14330@prithivi.gnumonks.org> Message-ID: <200912250356.37805.datacop@wireloss.net> Am Freitag 25 Dezember 2009 03:07:34 schrieb Harald Welte: > Hi Clemens, > > On Fri, Dec 25, 2009 at 01:41:06AM +0100, Clemens Hopfer wrote: > > At the moment it only supports one data source for a single rrd file, but > > I'll add commandline options for the file and counter name. > > I think this is the easiest solution, adding a new counter is just > > creating a new rrd file and adding a cronjob. > > well, it's also easy to generate a list of the counters from the sql > database by using something like "select unique(name) from counters" and > then iterate over that list... hmm, I'm not very familiar with rrdtool, but afaics there is no direct option in rrdtool to add a data source after creating a rrd file. However the Perl RRD bindings actually got a function to do that and there are several suggestions to dump the rrd file to xml, change that file and recreate the rrd file but I'm not sure if this is a really good idea... That's one reason (apart from simplicity) why i only used one data source for now. It would be also possible to use a dedicated directory and create RRDs of new counters on-the-fly. I'll have a look at the Perl api, although I don't like Perl that much... ;-) > > It would be great if someone could post some sample data to do some > > tests. > > I cannot send you the full hlr.sqlite3 of my test machine, sorry. but I've > attached the output of 'sqlite3 -csv hlr.sqlite3 "select * from > counters;"'. The counter values are very low as I've been playing around > with few phones and few events, but it should give you a feeling for it. thanks, that's everything I wanted :-) > btw: Will you be at 26C3? yep, I'll arrive at Saturday afternoon. From datacop at wireloss.net Fri Dec 25 03:45:06 2009 From: datacop at wireloss.net (Clemens Hopfer) Date: Fri, 25 Dec 2009 04:45:06 +0100 Subject: statistics tools for OpenBSC In-Reply-To: <200912250356.37805.datacop@wireloss.net> References: <20091222201057.GL14330@prithivi.gnumonks.org> <20091225020734.GL14330@prithivi.gnumonks.org> <200912250356.37805.datacop@wireloss.net> Message-ID: <200912250445.06799.datacop@wireloss.net> Am Freitag 25 Dezember 2009 03:56:37 schrieb Clemens Hopfer: > [..] > hmm, I'm not very familiar with rrdtool, but afaics there is no direct > option in rrdtool to add a data source after creating a rrd file. > However the Perl RRD bindings actually got a function to do that and there > are several suggestions to dump the rrd file to xml, change that file and > recreate the rrd file but I'm not sure if this is a really good idea... ok, the perl api is also just dumping the whole rrd file to xml, changing it and recreating the rrd file. The xml file seems to be about the factor 10 bigger than the rrd file, i expected 100 or more. I'll have a deeper look into the xml structure tomorrow. Clemens From datacop at wireloss.net Sat Dec 26 01:07:12 2009 From: datacop at wireloss.net (Clemens Hopfer) Date: Sat, 26 Dec 2009 02:07:12 +0100 Subject: statistics tools for OpenBSC In-Reply-To: <20091225020734.GL14330@prithivi.gnumonks.org> References: <20091222201057.GL14330@prithivi.gnumonks.org> <200912250141.06224.datacop@wireloss.net> <20091225020734.GL14330@prithivi.gnumonks.org> Message-ID: <200912260207.12480.datacop@wireloss.net> Hi, there is one problem with the sqlite db: Afaik sqlite3 doesn't really know about datatypes apart from the standard types (like integer, text etc..) and uses a dynamic type system. So the query for inserting a new counter value to the database does not insert the timestamp as unix time as expected but as string ( db.c:1037 datetime('now') ). Something like strftime('%s','now') would make much more sense, rrd also uses unix time for updating rrd files. Am Freitag 25 Dezember 2009 03:07:34 schrieb Harald Welte: > Hi Clemens, > > On Fri, Dec 25, 2009 at 01:41:06AM +0100, Clemens Hopfer wrote: > > At the moment it only supports one data source for a single rrd file, but > > I'll add commandline options for the file and counter name. > > I think this is the easiest solution, adding a new counter is just > > creating a new rrd file and adding a cronjob. > > well, it's also easy to generate a list of the counters from the sql > database by using something like "select unique(name) from counters" and > then iterate over that list... > > > It would be great if someone could post some sample data to do some > > tests. > > I cannot send you the full hlr.sqlite3 of my test machine, sorry. but I've > attached the output of 'sqlite3 -csv hlr.sqlite3 "select * from > counters;"'. The counter values are very low as I've been playing around > with few phones and few events, but it should give you a feeling for it. > > btw: Will you be at 26C3? > From womax at gmx.ch Wed Dec 23 02:18:48 2009 From: womax at gmx.ch (WoMax) Date: Wed, 23 Dec 2009 03:18:48 +0100 Subject: ciphering on nanoBTS Message-ID: Beware! Ciphering on nanoBTS is depending on the installed software. If you have a model 139/140 and the software is 120a... the A5/1 and A5/2 encryption is available; 120b... is A5/2 only and 120c... there is no encryption available. When you have a model 108/110 the software should start with 119 and with model 165 it starts with 168. From 246tnt at gmail.com Wed Dec 23 15:08:20 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 23 Dec 2009 16:08:20 +0100 Subject: ciphering on nanoBTS In-Reply-To: References: Message-ID: <866320f70912230708mde80119rba0ed49478e847ed@mail.gmail.com> > Ciphering on nanoBTS is depending on the installed software. > > If you have a model 139/140 and the software is 120a... the A5/1 and A5/2 > encryption is available; > > 120b... is A5/2 only and > 120c... there is no encryption available. > > When you have a model 108/110 the software should start with 119 and with > model 165 it starts with 168. > > Interesting. I've updated the Wiki with this. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Wed Dec 23 23:46:51 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 24 Dec 2009 00:46:51 +0100 Subject: Encryption support, please test :) Message-ID: <866320f70912231546x21ee370ak7a578aaaf0bd7e94@mail.gmail.com> Hi everyone, I've just pushed a branch sylvain/encryption on the OpenBSC git that contains my current patches to support encryption. Even if you don't have programmable SIMs, test it still works :) If a subscriber doesn't have a Ki set in the HLR or encryption isn't enabled in the config, the executed code path should be the exact same as before. It uses COMP128 as a3/a8 so you can use common programmable SIMs. Currently a secure channel is established for - LOCATION UPDATEs - CM SERVICE REQUEST. Support for PAGING RESPONSE is a little trickier and I haven't looked deeply into it. To enable : - Either recreate your HLR sqlite3, or update it like this (do a backup before hand !) : bash# sqlite3 hlr.sqlite3 sqlite> ALTER TABLE Subscriber ADD COLUMN ki BLOB; sqlite> UPDATE Meta SET value = '3' WHERE key='revision'; - Add a "a5 encryption 1" line to your openbsc.cfg to enable encryption using A5/1 - Set the Ki of the subscriber. Using the vty interface is the simplest : bash# telnet 127.0.0.1 4242 openbsc> enable openbsc# conf t openbsc# subscriber YOURIMSI openbsc# ki 0123456789abcdef0123456789abcdef Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From womax at gmx.ch Wed Dec 23 23:58:25 2009 From: womax at gmx.ch (WoMax) Date: Thu, 24 Dec 2009 00:58:25 +0100 Subject: christmas present Message-ID: <50BDA3A07EDB4CF0995EE419A73D4C11@HAL2008> As a christmas present a friend of mine showed me some nanoBTS documents, I can't make copies but I remember some details I will post here ... LED status codes: red/steady: sw error, power-on fails orange/slow flash: ethernet disconnected red/fast blink: dongle attached, factory reset done red-green/fast flash: unit not configured orange/fast flash: code loading in progress orange/slow blink: TRX is waiting for OML orange/steady: self test in progress green/fast flash: OML established, NWL test running green-orange/slow blink: calibrating in progress green/slow flash: no radio carrier transmitted green/steady: operational state TIB pinout: Output-connector - pin 1-spare/fpga 2-spare/fpga 3-26mhz - 4-26mhz + 5-sync out + 6-sync out - 7-ppc serial out 8-ppc serial in 9-fpga serial out 10-gnd Input-connector - pin 1-10mhz in - 2-10mhz in + 3-26mhz in - 4-26mhz in + 5-sync in + 6-sync in - 7-frame sync 8-nc 9-reset 10-gnd A merry christmas, WoMax From laforge at gnumonks.org Thu Dec 24 14:18:37 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 24 Dec 2009 15:18:37 +0100 Subject: About the ipaccess-proxy Message-ID: <20091224141837.GK14330@prithivi.gnumonks.org> Hi all, I've committed a new program called ipaccess-proxy to openbsc git. It is - like the name implies - a proxy for the ip.access A-bis over IP protocol. Why would you want to do that? 1) to keep the BCCH live while you restart OpenBSC. This keeps the phones nice and happy on the network while you test/deploy new code 2) to inject packets into the A-bis stream, e.g. from a packet generation tool like scapy. ipaccess-proxy creates udp ports to do this. More documentation after the 26C3. -- - 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 Dec 24 16:08:41 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 24 Dec 2009 17:08:41 +0100 Subject: SMS status Message-ID: <866320f70912240808v7fb273d2la384d2074710202d@mail.gmail.com> Hi, Here's a little report on the SMS status: First, the good news is that in practice everything works fine with the handsets I tested. There are a few issues left to address but they don't seem to cause any operational troubles so far : * In MO transfers, the channel should be closed after the reception of CP-ACK, _unless_ a CM SERVICE REQUEST was sent just before on the channel. Currently the channel is just not closed AFAICT and it times out some time afterwards. * Double RF Channel Release : Here's the log of the end of a typical SMS transfer (MO in this case but MT has a similar problem) : <0000> abis_rsl.c:1408 (bts=0,trx=0,ts=1) SAPI=3 DATA INDICATION <0007> gsm_04_11.c:918 trans_id=c RX SMS CP-ACK [ pause ] <0000> abis_rsl.c:1408 (bts=0,trx=0,ts=1) SAPI=0 RELEASE INDICATION <0004> abis_rsl.c:742 (bts=0,trx=0,ts=1) RF Channel Release CMD <0004> abis_rsl.c:1138 (bts=0,trx=0,ts=1) RF CHANNEL RELEASE ACK <0000> abis_rsl.c:1408 (bts=0,trx=0,ts=1) SAPI=3 RELEASE INDICATION <0004> abis_rsl.c:742 (bts=0,trx=0,ts=1) RF Channel Release CMD <0004> abis_rsl.c:1138 (bts=0,trx=0,ts=1) RF CHANNEL RELEASE ACK As you see, when we receive a RELEASE INDICATION in abis_rsl_rx_rll, we call rsl_rf_chan_release directly. But we'll receive RELEASE INDICATION for both SAPI 0 & 3 and so we'll call it twice which is bad. I tried releasing channel _only_ if all SAPI are unused but the resulting effect was not what I expected : <0000> abis_rsl.c:1418 (bts=0,trx=0,ts=1) SAPI=3 DATA INDICATION <0007> gsm_04_11.c:927 trans_id=b RX SMS CP-ACK [ pause ] <0000> abis_rsl.c:1418 (bts=0,trx=0,ts=1) SAPI=0 RELEASE INDICATION [ pause ] <0004> abis_rsl.c:1137 (bts=0,trx=0,ts=1) <0004> abis_rsl.c:967 CONNECTION FAIL: RELEASINGCAUSE=0x01(Radio Link Failure) <0004> abis_rsl.c:975 <0004> abis_rsl.c:742 (bts=0,trx=0,ts=1) RF Channel Release CMD <0004> abis_rsl.c:1148 (bts=0,trx=0,ts=1) RF CHANNEL RELEASE ACK <0013> gsm_subscriber_base.c:subscr 35414 usage decreased usage to: 0 <0000> abis_rsl.c:1418 (bts=0,trx=0,ts=1) SAPI=3 RELEASE INDICATION <0004> abis_rsl.c:742 (bts=0,trx=0,ts=1) RF Channel Release CMD <0004> abis_rsl.c:1148 (bts=0,trx=0,ts=1) RF CHANNEL RELEASE ACK I need to read the spec and see what happens on a commercial network to understand better what should be done because I'm obviously missing something ... Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Fri Dec 25 04:34:48 2009 From: zecke at selfish.org (Holger Freyther) Date: Fri, 25 Dec 2009 05:34:48 +0100 Subject: SMS status In-Reply-To: <866320f70912240808v7fb273d2la384d2074710202d@mail.gmail.com> References: <866320f70912240808v7fb273d2la384d2074710202d@mail.gmail.com> Message-ID: <200912250534.50221.zecke@selfish.org> On Thursday 24 December 2009 17:08:41 Sylvain Munaut wrote: > Hi, > > Here's a little report on the SMS status: > * In MO transfers, the channel should be closed after the reception of > CP-ACK, _unless_ a CM SERVICE REQUEST was sent just before on the channel. > Currently the channel is just not closed AFAICT and it times out some time > afterwards. This will be all better next year... > * Double RF Channel Release : Here's the log of the end of a typical SMS > transfer (MO in this case but MT has a similar problem) : Interesting. Your approach seemed to be fine. The RF Channel Release contains the SAPI that was released. So we should release SAPI=0 and SAPI=3 when we get this command. The question is who should release SAPI=3 in the MT case (where OpenBSC will establish this)? So we should only free the radio resource and set the chan mode to NONE if all SAPIs has been released. > I need to read the spec and see what happens on a commercial network to > understand better what should be done because I'm obviously missing > something ... maybe I can help later this year. But in a real network the MSC is most likely to just say drop your radio resources and then all SAPIs will be deallocated and the channel will be closed. regards holger From laforge at gnumonks.org Fri Dec 25 23:40:05 2009 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 26 Dec 2009 00:40:05 +0100 Subject: URGENT: range 1024/512/256 encoding of neighbor cell list required Message-ID: <20091225234005.GA17265@prithivi.gnumonks.org> Hi! We've just finished most of the build-up of the GSM network at 26C3, and I've noticed that the ARFCN's that we've been allocated are further than 111 apart, i.e. we cannot use the 'variable bitmap' format that OpenBSC implements so far. If anyone understands (and/or has time to implement) the specification in GSM TS 04.08 10.5.2.13.3 / 10.5.2.13.4 / 10.5.2.13.5, or even the full algorithm as specified in "Annex J: Algorithm to encode frequency list information elements", I would be extremely grateful. Off to bed, will be yet another long day tomorrow. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From spaar at mirider.augusta.de Sat Dec 26 09:37:20 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Sat, 26 Dec 2009 09:37:20 Subject: URGENT: range 1024/512/256 encoding of neighbor cell list required Message-ID: <4b35d950.mirider@mirider.augusta.de> Hello Harald, On Sat, 26 Dec 2009 00:40:05 +0100, "Harald Welte" wrote: > > If anyone understands (and/or has time to implement) the specification > in GSM TS 04.08 10.5.2.13.3 / 10.5.2.13.4 / 10.5.2.13.5, or even the full > algorithm as specified in "Annex J: Algorithm to encode frequency list > information elements", I would be extremely grateful. Sorry, no time to code the algorithm, however here is a handcrafted list: 0x83, 0x64, 0x5C, 0x00, 0xFF, 0x3F, 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, It contains ARFCN 536, 540, 868, 870 und 871, I have not yet checked it with a phone. I guess its OK to use it for all five BTS units, T-Mobile also includes the main BCCH ARFCN in the neighbor cell list, at least here in my area, so this should work for us too. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From spaar at mirider.augusta.de Sat Dec 26 11:45:46 2009 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Sat, 26 Dec 2009 11:45:46 Subject: URGENT: range 1024/512/256 encoding of neighbor cell list required Message-ID: <4b35f76a.mirider@mirider.augusta.de> Hello Harald, On Sat, 26 Dec 2009 09:37:20 , "Dieter Spaar" wrote: > > Sorry, no time to code the algorithm, however here is a handcrafted > list: > > 0x83, 0x64, 0x5C, 0x00, 0xFF, 0x3F, 0xC0, 0x00, > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > > It contains ARFCN 536, 540, 868, 870 und 871, I have not yet checked it > with a phone. I verified with two different phones that the list is correct. However Wireshark does not properly decode this format, it tells you that the ARFCNs are 448 and 868 (DTAP decoder). Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From daniel at totalueberwachung.de Sun Dec 27 00:28:38 2009 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Sun, 27 Dec 2009 01:28:38 +0100 Subject: [PATCH 1/1] Add a GURU import script for 26C3 Message-ID: <9542a8bfdab89578ed96a944f4e1235019485b3f.1261873599.git.daniel@totalueberwachung.de> Use it like this: ./26c3-guru-import.py hlr.sqlite3 This script will check if the imXi is an IMSI and authorize the subscriber. If it isn't it checks whether it's an IMEI that has an IMSI associated with it and authorize the first IMSI that was seen with that particular IMEI. It will not touch subscribers that are already authorized. --- openbsc/tools/26c3-guru-import.py | 90 +++++++++++++++++++++++++++++++++++++ 1 files changed, 90 insertions(+), 0 deletions(-) create mode 100755 openbsc/tools/26c3-guru-import.py diff --git a/openbsc/tools/26c3-guru-import.py b/openbsc/tools/26c3-guru-import.py new file mode 100755 index 0000000..99a982b --- /dev/null +++ b/openbsc/tools/26c3-guru-import.py @@ -0,0 +1,90 @@ +#!/usr/bin/python2.6 + +# Based loosely on hlrsync.py from Jan L??bbe +# (C) 2009 Daniel Willmann +# All Rights Reserved +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License along +# with this program; if not, write to the Free Software Foundation, Inc., +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + +from __future__ import with_statement + +import urllib +from pysqlite2 import dbapi2 as sqlite3 +import sys + +hlr = sqlite3.connect(sys.argv[1]) +web = urllib.urlopen(sys.argv[2]).read() + +# switch to autocommit +hlr.isolation_level = None + +hlr.row_factory = sqlite3.Row + +web = web.split("\n") + +# Remove last empty newline +# List of extension - imei/imsi tuples from GURU2 +web_tuple = [ (int(i.split(" ")[0]), int(i.split(" ")[1])) for i in web if len(i) > 0 ] + +for x in web_tuple: + exten = x[0] + imxi = x[1] + + # Enforce numering plan of 26c3 + if exten < 9100 or exten > 9999: + continue + + # Test if it is an IMSI and hasn't yet been authorized + subscr = hlr.execute(""" + SELECT * FROM Subscriber WHERE imsi=="%015u" and authorized==0 + """ % (imxi) ).fetchall() + + # Not an IMSI + if len(subscr) == 0: + equip = hlr.execute(""" + SELECT * FROM Equipment WHERE imei="%015u" + """ % (imxi) ).fetchall(); + #print equip + + if len(equip) == 0: + continue + + subscrid = hlr.execute(""" + SELECT * FROM EquipmentWatch WHERE equipment_id=%015u ORDER BY created LIMIT 1 + """ % (int(equip[0]['id'])) ).fetchall(); + + #print subscrid + + if len(subscrid) == 0: + continue + + subscr = hlr.execute(""" + SELECT * FROM Subscriber WHERE id==%u and authorized==0 + """ % subscrid[0]['subscriber_id']).fetchall(); + + if len(subscr) == 0: + continue + + subscr = subscr[0] + # Now we have an unauthorized subscriber for the imXi + print exten, imxi + print subscr + + # Strip leading 9 from extension and authorize subscriber + hlr.execute("""UPDATE Subscriber SET authorized = 1,extension="%s" \ + WHERE id = %u + """ % (str(exten)[1:], subscr['id']) ); + +hlr.close() -- 1.6.5.2 From 246tnt at gmail.com Sun Dec 27 09:38:04 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 27 Dec 2009 10:38:04 +0100 Subject: pySim: Utility to program SIMs Message-ID: <866320f70912270138p33cac75crf884326e7aa73769@mail.gmail.com> I' ve just added a tool to deal with SIMs more easily (especially when you want to program tens of them ... :) You can check it out at git://bs11-abis.gnumonks.org/pysim.git The currently supported models are : - Super Sim 12-in-1 (the format described in the OpenBSC Wiki) - Magic SIM (2010 model) - 'fake' Magic SIM (some counterfeits ?) Note that I have some marked 'SuperSIM' that need the 'Fake Magic SIM protocol'. In any case, just try 'auto' first and it'll try to autodetect. If you have a card for which that doesn't work, contact me please (or debug and fix it yourself :) I tested it with the 3 models I have here and it worked fine (tested IMSI, PLMN_Sel & Ki). (with the 2010 magic sim model, the ICCID isn't programmed but that has no impact ... and it's not programmed with the official software either ...) Here's the README for reference : This utility allows to : * Program customizable SIMs. Two modes are possible: - one where you specify every parameter manually : ./pySim.py -n 26C3 -c 49 -x 262 -y 42 -i -s - one where they are generated from some minimal set : ./pySim.py -n 26C3 -c 49 -x 262 -y 42 -z -j With and , the soft will generate 'predictable' IMSI and ICCID, so make sure you choose them so as not to conflict with anyone. (for eg. your name as and 0 1 2 ... for ). You also need to enter some parameters to select the device : -t TYPE : type of card (supersim, magicsim, fakemagicsim or try 'auto') -d DEV : Serial port device (default /dev/ttyUSB0) -b BAUD : Baudrate (default 9600) * Interact with SIMs from a python interactive shell (ipython for eg :) import pySim sl = pySim.SerialSimLink(device='/dev/ttyUSB0', baudrate=9600) print sl.read_binary(['3f00', '7f20', '6f07']) # Print IMSI print sl.run_gsm('00112233445566778899aabbccddeeff') # Run A3/A8 ---------------- Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Wed Dec 30 09:33:42 2009 From: zecke at selfish.org (Holger Freyther) Date: Wed, 30 Dec 2009 10:33:42 +0100 Subject: Work on ipaccess-config and software load Message-ID: <200912301033.42741.zecke@selfish.org> Hi All, in the last couple of days I have implemented Software Loading for the nanoBTS. Use this at your own risk but it is working here(tm). Software Load is implemented as of the GSM 12.21 with some quirks and extra messages compared to the BS11. - BS11 got the length of the "length" wrong and it should have been a short. ipaccess got this right so I needed to change that part - For the nanoBTS in the SW Load Init and Load End message one needs to add the SW_DESCR IE but without a length. 12.21 would probably require the length but this is omitted. The other part is that the file id must be set to "id\0" and the version to "version\ 0" or at least was set like this in the example trace I had. - Strings must be written with the '\0' in it. - After the Software Load End ACK one needs to send a special SET NVATTR to set the software as default. The message must contain the ID and Version of two firmware parts. I'm not sure which funtional part they relate to but they have the "more more magic" ids of 0x1000 and 0x2001. I have changed ipaccess-config to exit after the software load, or setting the primary OML IP by handling the ACK and carrying a state. One can also chain "-r" and the above two so the primary action will be executed first and then the reset will be issue and with a reset ack/nack the app will exit. With doing the above it becomes aware that we should change ipaccess-config a lot, all the options you could enable should generate an operation and we should put these into a queue and then execute them one after another and exit once all of them are done but this will be a bigger project as we need some more cooperation with abis_nm.c. Is anyone volunteering to fix the structure of this small application helper? regards holger From 246tnt at gmail.com Wed Dec 30 09:59:05 2009 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 30 Dec 2009 10:59:05 +0100 Subject: Work on ipaccess-config and software load In-Reply-To: <200912301033.42741.zecke@selfish.org> References: <200912301033.42741.zecke@selfish.org> Message-ID: <866320f70912300159u24cd0de3xf9447eb3d3432e5c@mail.gmail.com> > - For the nanoBTS in the SW Load Init and Load End message one needs > to add the SW_DESCR IE but without a length. 12.21 would probably > require the length but this is omitted. The other part is that the > file id must be set to "id\0" and the version to "version\ 0" or > at > least was set like this in the example trace I had. > - Strings must be written with the '\0' in it. > - Actually the SW_DESCR IE doesn't have a length. It's defined in 12.21 - 9.4.62 as having a File ID IE followed by a File Version IE and since both have length, they don't use a length for SW_DESCR. - And for the \0 things, I thing the file id and file version can be just any binary blob and they just choose to use zero terminated strings ... So they just match 12.21 closely AFAICS :) The data sent currently in sw activate packets is wrong btw ... there is a patch in my pending branch fixing that but apparently needs to be validated against a BS-11 to be sure it still works with it :p Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Wed Dec 30 10:12:10 2009 From: zecke at selfish.org (Holger Freyther) Date: Wed, 30 Dec 2009 11:12:10 +0100 Subject: Work on ipaccess-config and software load In-Reply-To: <866320f70912300159u24cd0de3xf9447eb3d3432e5c@mail.gmail.com> References: <200912301033.42741.zecke@selfish.org> <866320f70912300159u24cd0de3xf9447eb3d3432e5c@mail.gmail.com> Message-ID: <200912301112.10458.zecke@selfish.org> On Wednesday 30 December 2009 10:59:05 Sylvain Munaut wrote: > > - For the nanoBTS in the SW Load Init and Load End message one > > needs to add the SW_DESCR IE but without a length. 12.21 would probably > > require the length but this is omitted. The other part is that the file > > id must be set to "id\0" and the version to "version\ 0" or at > > least was set like this in the example trace I had. > > - Strings must be written with the '\0' in it. > > - Actually the SW_DESCR IE doesn't have a length. It's defined in 12.21 - > 9.4.62 as having a File ID IE followed by a File Version IE and since both > have length, they don't use a length for SW_DESCR. Argh, I was looking at 9.4.61 and saw a length (off by one)... okay this is one more thing we can fix in the wireshark OML plugin now. > - And for the \0 things, I thing the file id and file version can be just > any binary blob and they just choose to use zero terminated strings ... Yes, maybe the nanoBTS will take any id and version... in the trace they were using the "id\0" and "version\0" string though. > So they just match 12.21 closely AFAICS :) agreed From laforge at gnumonks.org Wed Dec 30 13:44:01 2009 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 30 Dec 2009 14:44:01 +0100 Subject: REQUEST: Letter of Support for OpenBSC Message-ID: <20091230134401.GD11704@prithivi.gnumonks.org> Dear List, some entities in the GSM Industry seem to have started to discredit our efforts for an Open Source implementation of GSM protocols. In order to prove them wrong and demonstrate the usefulness of OpenBSC, I would like to ask everyone who uses OpenBSC in a commercial or educational context (companies, universities, schools) to show their support by writing a letter of support. This is a way how you can contribute back to the OpenBSC project, even without writing any code. Simply put a couple of sentences on your letterhead where you explain that you use OpenBSC, and if or how you think it is a useful tool for your research and/or development. I will collect those letters and forward them to those who try to discredit us, and if that is not sufficient, put the letters on the project homepage and take that dispute somewhat more public. I'm looking forward to your letter. Thanks for your support! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zero-kelvin at gmx.de Wed Dec 30 09:40:49 2009 From: zero-kelvin at gmx.de (dexter) Date: Wed, 30 Dec 2009 10:40:49 +0100 Subject: REQUEST: Letter of Support for OpenBSC In-Reply-To: <20091230134401.GD11704@prithivi.gnumonks.org> References: <20091230134401.GD11704@prithivi.gnumonks.org> Message-ID: <4B3B2021.6090501@gmx.de> Hi Harald. That is something i recently discoverd when i tryed to talk to one of my lecturers who works for a big BSS Equipment manufacturer. I asked him if he know Harald Welte. "Who is Harald Welte" came back. As I started to explain about openBSC he said something like "This is not what we want, we want to sell our stuff!" regards, Philipp From zecke at selfish.org Wed Dec 30 10:13:56 2009 From: zecke at selfish.org (Holger Freyther) Date: Wed, 30 Dec 2009 11:13:56 +0100 Subject: REQUEST: Letter of Support for OpenBSC In-Reply-To: <4B3B2021.6090501@gmx.de> References: <20091230134401.GD11704@prithivi.gnumonks.org> <4B3B2021.6090501@gmx.de> Message-ID: <200912301113.56812.zecke@selfish.org> On Wednesday 30 December 2009 10:40:49 dexter wrote: > Hi Harald. > > That is something i recently discoverd when i tryed to talk to one of my > lecturers who works for a big BSS Equipment manufacturer. > > I asked him if he know Harald Welte. "Who is Harald Welte" came back. As > I started to explain about openBSC he said something like "This is not > what we want, we want to sell our stuff!" Hehe, this sounds like a conflict of interest. So his loyality is with the company he is working for (there is nothing wrong with that). z. From ich at henrik-hansen.de Wed Dec 30 16:40:13 2009 From: ich at henrik-hansen.de (ich at henrik-hansen.de) Date: Wed, 30 Dec 2009 16:40:13 +0000 Subject: Hello my name is ... Message-ID: Hi first i wan't to intoduce myself, i m henrik and am from germany. my english isn't good as is should be but i hope everyone can understand me. :) I'm searching for a Siemens BS-11 GSM1800. Why? Im the technical operator of the biggest summer-camp in lower saxony / germany of youth-fire-fighters. I know hard to understand. :D My plan is it, to operate a GSM zell on our camp next year. some background informations: -2000 youth member at the camp-ground. -up to 200 tecnical supporters. -300 youth supporters. more informations about the event 2009: http://www.zeltlager-2009.de/ The Mainorganisators of the camp know about this idea, and are willing to get a short-time licence for the event. The first contact to the "Bundesnetzagentur" is already done. What can i give the openBSC community? A place to test / benchmark OpenBSC. Also i'm a c / php developer and maybe i can help develope some external features for openBSC. Greetings from cold old Germany Henrik From laforge at gnumonks.org Thu Dec 31 10:18:34 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 31 Dec 2009 11:18:34 +0100 Subject: OpenBSC / GSM network at camp site In-Reply-To: References: Message-ID: <20091231101834.GO11704@prithivi.gnumonks.org> Hi Henrik, first of all, thanks for your introduction and thanks for your interest in OpenBSC. Let me just raise some general thoughts about operating your own GSM network at such a camp site: 1) whenever those teenagers register to your local network, they will no longer be reachable from the public network, i.e. their parents or other friends cannot call them on their regular phone 2) when you operate that network as an official services for those youth groups, think of liability aspects. As opposed to the HAR 2009 or 26C3, you will not deal with technical people who understand what they're doing, but you're dealing with innocent "normal" people. People who e.g. expect emergency calls to work reliably - something that OpenBSC clearly cannot offer at this time. 3) Also, I am not sure if you are already providing a telecommunication service to the public at that point. There are regulations regarding data safety, privacy but also lawful intercept and data retention that need to be considered. Operating an actual network for people who just want to use it (as opposed to people who want to test and research GSM technology) is really a different case. So my question would be: What is your reason for wanting to operate a GSM network at that camp? * Is there no real GSM network coverage on that camp? * Or do you want to provide free calls / sms for your camp attendees? (do you want your youngsters to spend even more time with their phones than usually?) * Or are you simply interested in doing it because it's cool? ;) > I'm searching for a Siemens BS-11 GSM1800. I only know of one unit, owned by somebody in Austria, and the last time I knew that unit was even broken. What you can find more often are ip.access nanoBTS for GSM 1800. Those units have 200mW output power, which is the same power level than what we used at HAR2009 - though in a completely different frequency band with different signal propagation erties. > The Mainorganisators of the camp know about this idea, and are willing to > get a short-time licence for the event. The first contact to the > "Bundesnetzagentur" is already done. I think the regulatory license is the smallest problem - if at all. 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 ich at henrik-hansen.de Thu Dec 31 12:44:28 2009 From: ich at henrik-hansen.de (ich at henrik-hansen.de) Date: Thu, 31 Dec 2009 12:44:28 +0000 Subject: OpenBSC / GSM network at camp site In-Reply-To: <20091231101834.GO11704@prithivi.gnumonks.org> References: <20091231101834.GO11704@prithivi.gnumonks.org> Message-ID: <5191f22fd38e6bbe47f1d6e587e02487@85.25.59.155> > 1) whenever those teenagers register to your local network, they will no > longer > be reachable from the public network, i.e. their parents or other > friends > cannot call them on their regular phone I'm aware of this, and i forget to tell that the gsm net will be limited to the organisators and the youth advisor. > People who e.g. expect emergency calls to work reliably - something that OpenBSC > clearly cannot offer at this time. The fact of emergency call's are not the problem, on camp site we got the so called TEL and a DRK Station, both are official branches of the emergency control stations. So if someone calls 112 with need for a doctor, he will get one :) > 3) Also, I am not sure if you are already providing a telecommunication > service > to the public at that point. There are regulations regarding data > safety, > privacy but also lawful intercept and data retention that need to be > considered. Operating an actual network for people who just want to > use it > (as opposed to people who want to test and research GSM technology) is > really a different case. In 2009 we use a huge number of 2m Radio's. These Radio's are normaly used by the German Firefighters. And are Devices taken from fire engines. > * Or do you want to provide free calls / sms for your camp attendees? > (do you want your youngsters to spend even more time with their phones > than usually?) The main reason providing a own gsm network, is that in 2009 my mobile phone bill breaks the 200? milestone. If we talking about the financial site, there are up to 120 people doing organisation stuff the hole day. Those People normaly use on of the radio's to communicate with each other. When the person i wanna talk to isn't reachable trough his radio, i call him. Thats why i think that a own GSM Network is a realy good idea for this event. > * Or are you simply interested in doing it because it's cool? ;) Jap, this is truely also a reason :) > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch.> A6) Funny signature. :) Thanks for all kind of response. Henrik. From nobody_su at chaostreff.ch Thu Dec 31 17:57:50 2009 From: nobody_su at chaostreff.ch (Miguel Elias) Date: Thu, 31 Dec 2009 18:57:50 +0100 Subject: OpenBSC / GSM network at camp site In-Reply-To: <5191f22fd38e6bbe47f1d6e587e02487@85.25.59.155> References: <20091231101834.GO11704@prithivi.gnumonks.org> <5191f22fd38e6bbe47f1d6e587e02487@85.25.59.155> Message-ID: <4B3CE61E.9050504@chaostreff.ch> Hi Henrik, I think what you need is a local radio repeater. Which does allow you to expand your reception area. Depending were the camp will be, a local ham radio (funk amateure) club could be able to help you, at least to finde the right equipment for your event. That would allow you to use the 2m commercial radios and save money in the same time. regards miguel From zecke at selfish.org Thu Dec 31 05:12:31 2009 From: zecke at selfish.org (Holger Freyther) Date: Thu, 31 Dec 2009 06:12:31 +0100 Subject: Stack corruption from set_system_infos Message-ID: <200912310612.32158.zecke@selfish.org> Hi Harald, I have a stack corruption due the above method and here is my analysis of the problem... set_system_infos is having a u_int8_t array with 23 bytes on the stack and is asking to generate system infos into this array... Now what happens is: 1.) some system information types structs are already bigger than the 23 bytes... 2.) this does not take the rest octets into account.. I would like to fix it like this: 1.) Turn bitvec_spare_padding to return void 2.) In the rest_octets_siX method return the bit_vec.data_len 3.) Change the generate_siX to return the sizeof the struct + return value of the rest_octets_siX instead of the fixed MACBLOCK_LEN (23) 4.) always use this rc value instead of the size of the buffer... (due to 1. of the above we set truncated values as well) do you have a better idea? would you just increase the buffer size? z. From laforge at gnumonks.org Thu Dec 31 10:23:00 2009 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 31 Dec 2009 11:23:00 +0100 Subject: Stack corruption from set_system_infos In-Reply-To: <200912310612.32158.zecke@selfish.org> References: <200912310612.32158.zecke@selfish.org> Message-ID: <20091231102300.GP11704@prithivi.gnumonks.org> Hi Zecke, On Thu, Dec 31, 2009 at 06:12:31AM +0100, Holger Freyther wrote: > I have a stack corruption due the above method and here is my analysis of the > problem... thanks for your analysis. > set_system_infos is having a u_int8_t array with 23 bytes on the stack and is > asking to generate system infos into this array... > > Now what happens is: > 1.) some system information types structs are already bigger > than the 23 bytes... why are they? How can that be? How can a SI message be larger than the physical limitation of the MAC-Block? This sounds like the root cause of the problem to me. > I would like to fix it like this: > 1.) Turn bitvec_spare_padding to return void makes sense. after all, the caller already specifies the number of bits up to which he wants the data to be padded. > 2.) In the rest_octets_siX method return the bit_vec.data_len makes also sense to me. > 3.) Change the generate_siX to return the sizeof the struct > + return value of the rest_octets_siX instead of the fixed > MACBLOCK_LEN (23) > 4.) always use this rc value instead of the size of the buffer... > (due to 1. of the above we set truncated values as well) also fine with me. > do you have a better idea? would you just increase the buffer size? as indicated above, the root cause might well be something else. Nevertheless, your suggested improvements are valid and correct. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)