From msuraev at sysmocom.de  Wed Nov  2 10:21:25 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 2 Nov 2016 11:21:25 +0100
Subject: osmo-bts-trx channel activation
In-Reply-To: <e66b39b3-b65f-9fc5-6c9e-2f2b48ffdaa5@sysmocom.de>
References: <e66b39b3-b65f-9fc5-6c9e-2f2b48ffdaa5@sysmocom.de>
Message-ID: <5e2d1a2f-465d-26e9-ee8d-736083b60478@sysmocom.de>

On a related note - are there some hw/sw limitations in osmo-trx which
might prevent us from using 2 lchans on the same TCH/H timeslot?

See https://projects.osmocom.org/issues/1795 for details.


On 10/17/2016 05:06 PM, Max wrote:
> Hi.
>
> In sysmobts we use ugly hack to auto-activate BCCH/CCCH on TS0 via
> opstart_compl(). How does channel activation looks like for osmo-bts-trx?
>
> On a related note: how do we decide on number of AGCH? In case of
> sysmobts it's communicated to L1 in agch.u8NbrOfAgch via lch_par.  What
> would be equivalent for osmo-bts-trx?
>

-- 
Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/
======================================================================= 
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93 
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B 
* Geschaeftsfuehrer / Managing Director: Harald Welte 



From sami.0jacob0 at gmail.com  Wed Nov  2 12:01:48 2016
From: sami.0jacob0 at gmail.com (sami)
Date: Wed, 2 Nov 2016 14:01:48 +0200
Subject: estimate distance
Message-ID: <10D12978-F290-4BC0-89E3-6C16A6BC75B6@gmail.com>

Hi,

Is there a function in OpenBSC that can help in estimating the diastase of the connected phone ? For example, something that gives the value of the power received by the phone from the BTS and the power received by the BTS from the phone (during paging or active call).

best regards,

From msuraev at sysmocom.de  Wed Nov  2 12:19:00 2016
From: msuraev at sysmocom.de (Max)
Date: Wed, 2 Nov 2016 13:19:00 +0100
Subject: P*CH activation
Message-ID: <190e4770-302f-eb4c-a3eb-40339f79c7f6@sysmocom.de>

HI.

Pardon the cross-posting, I'm not sure where this question really belongs.

I've been trying to wrap my head around how PDTCH/PACCH/PTCCH activation
works. In osmo-bts-sysmo/oml.c there is pdtch_sapis[] which defines what
got to be activated both in DL and UL directions. Right now it's PDTCH
(UL & DL), PTCCH (DL) and PRACH. Note that PACCH (DL) and PTCCH (UL) are
commented out.

Yet I see code dealing with PACCH in osmo-pcu and corresponding log
messages.

So the question is - how does this works? The PACCH seems to be used so
it's somehow activated but apparently not the same way as PDTCH.

-- 
Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/
======================================================================= 
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93 
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B 
* Geschaeftsfuehrer / Managing Director: Harald Welte 



From nhofmeyr at sysmocom.de  Wed Nov  2 12:43:32 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 2 Nov 2016 13:43:32 +0100
Subject: osmo-bts-trx channel activation
In-Reply-To: <5e2d1a2f-465d-26e9-ee8d-736083b60478@sysmocom.de>
References: <e66b39b3-b65f-9fc5-6c9e-2f2b48ffdaa5@sysmocom.de>
 <5e2d1a2f-465d-26e9-ee8d-736083b60478@sysmocom.de>
Message-ID: <20161102124332.GB2576@my.box>

On Wed, Nov 02, 2016 at 11:21:25AM +0100, Max wrote:
> On a related note - are there some hw/sw limitations in osmo-trx which
> might prevent us from using 2 lchans on the same TCH/H timeslot?

Well, the point of TCH/H *is* 2 lchans per timeslot. If this were the case we
might as well disable TCH/H completely and just use TCH/F on osmo-trx.
I'm pretty sure it isn't a HW limitation, expecting a SW bug.

~Neels

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161102/09f5a33a/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Nov  2 13:14:13 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 2 Nov 2016 14:14:13 +0100
Subject: [MERGED] openbsc[master]: gsm0408: Adding log output for 3g
 specific RR messages
References: <gerrit.1476105312408.I41f2242fdf59c3eb4b3f8f7f003c17f7e0df01aa@gerrit.osmocom.org>
Message-ID: <20161102131413.GD2576@my.box>

Possible error in this merged patch, see inline:

On Tue, Nov 01, 2016 at 09:56:24PM +0000, Harald Welte wrote:
> Harald Welte has submitted this change and it was merged.
> 
> Change subject: gsm0408: Adding log output for 3g specific RR messages
> ......................................................................
> 
> 
> gsm0408: Adding log output for 3g specific RR messages
> 
> GSM 04.18, which is the successor of GSM 04.08, describes
> additional RR 3g specific message types. This commit adds
> log output for those messages. The behaviour is not changed
> all affected message types are still forwared to the MSC
> as they were before.
> 
> See also 3GPP TS 04.18, section 10.4, table 10.4.1
> 
> The change requires to update libosmocore as well, see
> also commit f48fdb3a108da0dc23d7af4ac021e98e11f07152 in
> libosmocore.git for details.
> 
> Change-Id: I41f2242fdf59c3eb4b3f8f7f003c17f7e0df01aa
> ---
> M openbsc/src/libbsc/bsc_api.c
> M openbsc/src/libmsc/gsm_04_08.c
> 2 files changed, 11 insertions(+), 7 deletions(-)
> 
> Approvals:
>   Harald Welte: Looks good to me, approved
>   Jenkins Builder: Verified
> 
> 
> 
> diff --git a/openbsc/src/libbsc/bsc_api.c b/openbsc/src/libbsc/bsc_api.c
> index cc12e9f..207e12a 100644
> --- a/openbsc/src/libbsc/bsc_api.c
> +++ b/openbsc/src/libbsc/bsc_api.c
> @@ -34,6 +34,7 @@
>  #include <openbsc/trau_mux.h>
>  
>  #include <osmocom/gsm/protocol/gsm_08_08.h>
> +#include <osmocom/gsm/gsm48.h>
>  
>  #include <osmocom/core/talloc.h>
>  
> @@ -587,11 +588,13 @@
>  	case GSM48_PDISC_RR:
>  		switch (msg_type) {
>  		case GSM48_MT_RR_GPRS_SUSP_REQ:
> -			DEBUGP(DRR, "GRPS SUSPEND REQUEST\n");
> +			DEBUGP(DRR, "%s\n",
> +			       gsm48_rr_msg_name(GSM48_MT_RR_GPRS_SUSP_REQ));
>  			break;
>  		case GSM48_MT_RR_STATUS:
> -			LOGP(DRR, LOGL_NOTICE, "RR STATUS (cause: %s)\n",
> -				rr_cause_name(gh->data[0]));
> +			LOGP(DRR, LOGL_NOTICE, "%s (cause: %s)\n",
> +			     gsm48_rr_msg_name(GSM48_MT_RR_GPRS_SUSP_REQ),

Although this is in case GSM48_MT_RR_STATUS, it logs GSM48_MT_RR_GPRS_SUSP_REQ.
I'd prefer it it logs gsm48_rr_msg_name(msg_type), also in the call above, and
like the patch does below.

> +			     rr_cause_name(gh->data[0]));
>  			break;
>  		case GSM48_MT_RR_MEAS_REP:
>  			/* This shouldn't actually end up here, as RSL treats
> @@ -643,8 +646,9 @@
>  			/* Normally, a MSC should never receive RR
>  			 * messages, but we'd rather forward what we
>  			 * don't know than drop it... */
> -			LOGP(DRR, LOGL_NOTICE, "BSC: Passing unknown 04.08 "
> -			     "RR message type 0x%02x to MSC\n", msg_type);
> +			LOGP(DRR, LOGL_NOTICE,
> +			     "BSC: Passing %s 04.08 RR message to MSC\n",
> +			     gsm48_rr_msg_name(msg_type));
>  			if (api->dtap)
>  				api->dtap(conn, link_id, msg);
>  		}
> diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c
> index a22e3c2..3e362fa 100644
> --- a/openbsc/src/libmsc/gsm_04_08.c
> +++ b/openbsc/src/libmsc/gsm_04_08.c
> @@ -1270,8 +1270,8 @@
>  		rc = gsm48_rx_rr_app_info(conn, msg);
>  		break;
>  	default:
> -		LOGP(DRR, LOGL_NOTICE, "MSC: Unimplemented "
> -			"GSM 04.08 RR msg type 0x%02x\n", gh->msg_type);
> +		LOGP(DRR, LOGL_NOTICE, "MSC: Unimplemented %s GSM 04.08 RR "
> +		     "message\n", gsm48_rr_msg_name(gh->msg_type));
>  		break;
>  	}
>  
> 
> -- 
> To view, visit https://gerrit.osmocom.org/1037
> To unsubscribe, visit https://gerrit.osmocom.org/settings
> 
> Gerrit-MessageType: merged
> Gerrit-Change-Id: I41f2242fdf59c3eb4b3f8f7f003c17f7e0df01aa
> Gerrit-PatchSet: 9
> Gerrit-Project: openbsc
> Gerrit-Branch: master
> Gerrit-Owner: dexter <pmaier at sysmocom.de>
> Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org>
> Gerrit-Reviewer: Jenkins Builder
> Gerrit-Reviewer: Max <msuraev at sysmocom.de>
> Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de>

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161102/4600a767/attachment.bin>

From laforge at gnumonks.org  Wed Nov  2 17:16:38 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 2 Nov 2016 18:16:38 +0100
Subject: [MERGED] openbsc[master]: gsm0408: Adding log output for 3g
 specific RR messages
In-Reply-To: <20161102131413.GD2576@my.box>
References: <gerrit.1476105312408.I41f2242fdf59c3eb4b3f8f7f003c17f7e0df01aa@gerrit.osmocom.org>
 <20161102131413.GD2576@my.box>
Message-ID: <20161102171638.tsbto7i2y7itgod4@nataraja>

Hi Neels,

On Wed, Nov 02, 2016 at 02:14:13PM +0100, Neels Hofmeyr wrote:
> >  		case GSM48_MT_RR_STATUS:
> > -			LOGP(DRR, LOGL_NOTICE, "RR STATUS (cause: %s)\n",
> > -				rr_cause_name(gh->data[0]));
> > +			LOGP(DRR, LOGL_NOTICE, "%s (cause: %s)\n",
> > +			     gsm48_rr_msg_name(GSM48_MT_RR_GPRS_SUSP_REQ),
> 
> Although this is in case GSM48_MT_RR_STATUS, it logs GSM48_MT_RR_GPRS_SUSP_REQ.
> I'd prefer it it logs gsm48_rr_msg_name(msg_type), also in the call above, and
> like the patch does below.

ACK.  Philipp, would be great if you could fix that up.

Thanks,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           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 Nov  2 18:04:30 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 2 Nov 2016 19:04:30 +0100
Subject: P*CH activation
In-Reply-To: <190e4770-302f-eb4c-a3eb-40339f79c7f6@sysmocom.de>
References: <190e4770-302f-eb4c-a3eb-40339f79c7f6@sysmocom.de>
Message-ID: <20161102180430.ljt5djqwobnp65bn@nataraja>

Hi Max,

On Wed, Nov 02, 2016 at 01:19:00PM +0100, Max wrote:
> Pardon the cross-posting, I'm not sure where this question really belongs.

I would say here, as OsmoBTS is discussed on the openbsc list. PCU on
the net-gprs list.

> I've been trying to wrap my head around how PDTCH/PACCH/PTCCH activation
> works. In osmo-bts-sysmo/oml.c there is pdtch_sapis[] which defines what
> got to be activated both in DL and UL directions. Right now it's PDTCH
> (UL & DL), PTCCH (DL) and PRACH. Note that PACCH (DL) and PTCCH (UL) are
> commented out.
> 
> Yet I see code dealing with PACCH in osmo-pcu and corresponding log
> messages.
> 
> So the question is - how does this works? The PACCH seems to be used so
> it's somehow activated but apparently not the same way as PDTCH.

I think the PACCH SAPI is simply not activated in L1 at this point.
Maybe either L1 activates it automatically, or you can still send PACCH
blocks to the L1 despite not having activated it.

the L1 SAPI activation is probably really only "important" for dedicated
channels that get their own sub-multiplex in the TDMA scheme.  Then the
L1 can generate associated PH-RTS.ind to the L2.  Also, it matters for
channels that have different burst types, like the RACH SAPI on an
uplink TCH in case of hand-over, so the L1 will actually enable+perform
RACH burst correlation (which it normally doesn't).

For packet data channels, they're all shared and allocated dynamically
on the PDCH, and therere is no hierarchical TDMA architecture.
Therefore, a PACCH downlink message is simply a CS-1 radio block with
different payload than a PDTCH block. It's completely virtual.

So yes, we should be a good citizen and activate the PACCH SAPI.  It's
probably a bug that simply doesn't show up due to the above reasoning.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From keith at rhizomatica.org  Wed Nov  2 19:07:20 2016
From: keith at rhizomatica.org (Keith Whyte)
Date: Wed, 2 Nov 2016 20:07:20 +0100
Subject: estimate distance
In-Reply-To: <10D12978-F290-4BC0-89E3-6C16A6BC75B6@gmail.com>
References: <10D12978-F290-4BC0-89E3-6C16A6BC75B6@gmail.com>
Message-ID: <b6cfc2de-b5a4-2bda-590f-c1a54ead41b0@rhizomatica.org>

On 02/11/16 13:01, sami wrote:

> Hi,
>
> Is there a function in OpenBSC that can help in estimating the diastase of the connected phone ? For example, something that gives the value of the power received by the phone from the BTS and the power received by the BTS from the phone (during paging or active call).
>
> best regards,
Hi sami. You can see those uplink and downlink power levels with 'show
lchan' in OpenBSC.
For example:

  Measurement Report:
    Flags: 
    L1 MS Power: 33 dBm, Timing Advance: 9
    RXL-FULL-dl:  -86 dBm, RXL-SUB-dl:  -87 dBm RXQ-FULL-dl: 0,
RXQ-SUB-dl: 0
    RXL-FULL-ul:  -87 dBm, RXL-SUB-ul:  -47 dBm RXQ-FULL-ul: 0,
RXQ-SUB-ul: 0

There you will also see "Timing Advance" although I'm not sure how
exactly to interpret that. Maybe somebody else might comment. I'm also
not sure what RXQ is, although I've seen those numbers increase when I
use very low power levels in osmotrx and move the MS away from the USRP,
so I presume it's an indicator of RF errors?
I'll take the opportunity to also ask for clarification on that :)





From sami.0jacob0 at gmail.com  Thu Nov  3 08:11:12 2016
From: sami.0jacob0 at gmail.com (sami)
Date: Thu, 3 Nov 2016 10:11:12 +0200
Subject: estimate distance
In-Reply-To: <b6cfc2de-b5a4-2bda-590f-c1a54ead41b0@rhizomatica.org>
References: <10D12978-F290-4BC0-89E3-6C16A6BC75B6@gmail.com>
 <b6cfc2de-b5a4-2bda-590f-c1a54ead41b0@rhizomatica.org>
Message-ID: <182D3331-356B-44B0-8E6A-8646C6E007B0@gmail.com>

Hi Keith,

Thanks for your help, I will try it !

Best regards,
Sami,

On Nov 2, 2016, at 9:07 PM, Keith Whyte <keith at rhizomatica.org> wrote:

> On 02/11/16 13:01, sami wrote:
> 
>> Hi,
>> 
>> Is there a function in OpenBSC that can help in estimating the diastase of the connected phone ? For example, something that gives the value of the power received by the phone from the BTS and the power received by the BTS from the phone (during paging or active call).
>> 
>> best regards,
> Hi sami. You can see those uplink and downlink power levels with 'show
> lchan' in OpenBSC.
> For example:
> 
>  Measurement Report:
>    Flags: 
>    L1 MS Power: 33 dBm, Timing Advance: 9
>    RXL-FULL-dl:  -86 dBm, RXL-SUB-dl:  -87 dBm RXQ-FULL-dl: 0,
> RXQ-SUB-dl: 0
>    RXL-FULL-ul:  -87 dBm, RXL-SUB-ul:  -47 dBm RXQ-FULL-ul: 0,
> RXQ-SUB-ul: 0
> 
> There you will also see "Timing Advance" although I'm not sure how
> exactly to interpret that. Maybe somebody else might comment. I'm also
> not sure what RXQ is, although I've seen those numbers increase when I
> use very low power levels in osmotrx and move the MS away from the USRP,
> so I presume it's an indicator of RF errors?
> I'll take the opportunity to also ask for clarification on that :)
> 
> 
> 



From msuraev at sysmocom.de  Thu Nov  3 09:14:44 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 3 Nov 2016 10:14:44 +0100
Subject: estimate distance
In-Reply-To: <b6cfc2de-b5a4-2bda-590f-c1a54ead41b0@rhizomatica.org>
References: <10D12978-F290-4BC0-89E3-6C16A6BC75B6@gmail.com>
 <b6cfc2de-b5a4-2bda-590f-c1a54ead41b0@rhizomatica.org>
Message-ID: <45a9dc8e-cf92-b6aa-d7d4-4072e808e7cc@sysmocom.de>

Regarding TA: it's very approximate measure of distance:

1) it's not yet implemented the way it should - see
https://projects.osmocom.org/issues/1545 for example

2) Increase in TA +1 approximately equals to increase of +550 meters
distance between phone and BS (1 bit period = 3.69 usec times speed of
light)

3) There's guard period (8.25 for normal bursts) between transmissions
which allows it not to overlap with next one so even the phone with
incorrect TA might still work with BTS to some extend.


On 11/02/2016 08:07 PM, Keith Whyte wrote:
> On 02/11/16 13:01, sami wrote:
>
>> Hi,
>>
>> Is there a function in OpenBSC that can help in estimating the diastase of the connected phone ? For example, something that gives the value of the power received by the phone from the BTS and the power received by the BTS from the phone (during paging or active call).
>>
>> best regards,
> Hi sami. You can see those uplink and downlink power levels with 'show
> lchan' in OpenBSC.
> For example:
>
>   Measurement Report:
>     Flags: 
>     L1 MS Power: 33 dBm, Timing Advance: 9
>     RXL-FULL-dl:  -86 dBm, RXL-SUB-dl:  -87 dBm RXQ-FULL-dl: 0,
> RXQ-SUB-dl: 0
>     RXL-FULL-ul:  -87 dBm, RXL-SUB-ul:  -47 dBm RXQ-FULL-ul: 0,
> RXQ-SUB-ul: 0
>
> There you will also see "Timing Advance" although I'm not sure how
> exactly to interpret that. Maybe somebody else might comment. I'm also
> not sure what RXQ is, although I've seen those numbers increase when I
> use very low power levels in osmotrx and move the MS away from the USRP,
> so I presume it's an indicator of RF errors?
> I'll take the opportunity to also ask for clarification on that :)
>
>
>

-- 
Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/
======================================================================= 
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93 
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B 
* Geschaeftsfuehrer / Managing Director: Harald Welte 



From keith at rhizomatica.org  Thu Nov  3 13:57:23 2016
From: keith at rhizomatica.org (Keith)
Date: Thu, 3 Nov 2016 14:57:23 +0100
Subject: estimate distance
In-Reply-To: <45a9dc8e-cf92-b6aa-d7d4-4072e808e7cc@sysmocom.de>
References: <10D12978-F290-4BC0-89E3-6C16A6BC75B6@gmail.com>
 <b6cfc2de-b5a4-2bda-590f-c1a54ead41b0@rhizomatica.org>
 <45a9dc8e-cf92-b6aa-d7d4-4072e808e7cc@sysmocom.de>
Message-ID: <791876d7-b306-f813-75bd-d87f95567e84@rhizomatica.org>



On 03/11/2016 10:14, Max wrote:
> Regarding TA: it's very approximate measure of distance:
Thanks Max!
Would you also be able to clarify  RXL-FULL/SUB and the RXQ-FULL/SUB
figures?




From keith at rhizomatica.org  Thu Nov  3 17:45:47 2016
From: keith at rhizomatica.org (Keith)
Date: Thu, 3 Nov 2016 18:45:47 +0100
Subject: estimate distance
In-Reply-To: <791876d7-b306-f813-75bd-d87f95567e84@rhizomatica.org>
References: <10D12978-F290-4BC0-89E3-6C16A6BC75B6@gmail.com>
 <b6cfc2de-b5a4-2bda-590f-c1a54ead41b0@rhizomatica.org>
 <45a9dc8e-cf92-b6aa-d7d4-4072e808e7cc@sysmocom.de>
 <791876d7-b306-f813-75bd-d87f95567e84@rhizomatica.org>
Message-ID: <0fb16b67-4a4a-7261-7afc-3b00d961f93d@rhizomatica.org>


On 03/11/2016 14:57, Keith wrote:
> Would you also be able to clarify  RXL-FULL/SUB and the RXQ-FULL/SUB
> figures?
I looked at the source and did some research, in case anyone (who didn't
know already) is interested,
the L is Level and the Q is Quality.

RXL-SUB is the measurement when DTX (*Discontinuous Transmission)* is
enabled, (abbr. of subset)
RXL-FULL is otherwise i.e when there is voice activity.

That's very much of a tl;dr, but there's plenty of info on it out there.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161103/2673649e/attachment.htm>

From msuraev at sysmocom.de  Fri Nov  4 11:57:07 2016
From: msuraev at sysmocom.de (Max)
Date: Fri, 4 Nov 2016 12:57:07 +0100
Subject: estimate distance
In-Reply-To: <0fb16b67-4a4a-7261-7afc-3b00d961f93d@rhizomatica.org>
References: <10D12978-F290-4BC0-89E3-6C16A6BC75B6@gmail.com>
 <b6cfc2de-b5a4-2bda-590f-c1a54ead41b0@rhizomatica.org>
 <45a9dc8e-cf92-b6aa-d7d4-4072e808e7cc@sysmocom.de>
 <791876d7-b306-f813-75bd-d87f95567e84@rhizomatica.org>
 <0fb16b67-4a4a-7261-7afc-3b00d961f93d@rhizomatica.org>
Message-ID: <00c51cc4-48f7-60cc-dcb8-31a05bd7e5da@sysmocom.de>

Yes, you're right.

RXL (RXLEV) is [0..63] which codes signal level (0 is weakest)
RXQ (RXQUAL) is [0..7] which codes BER (Bit Error Rate) level (0 is least errors)

So RXLEV measures the radio signal quality (how much interference our signal suffered) while RXQUAL measures errors in decoded signal (how much useful info we've managed to extract from signal). Both are estimation of how good is the radio link between MS and BTS using different definition of what "good" is.

And -FULL and -SUB just defines when those measurements are done by MS (in case of DTX there are periods of no transmission so there's nothing to measure).

Overall, this is even worse way to estimate distance than TA - MS standing next to powerful electric motor with lots of of EM leak in the vicinity of BTS will get worse RX* measurements than MS which is far away but in nice clean EM environment.

See 3GPP TS 45.008 for lots of details.

Overall, for getting the distance (as well as actual position) we got
RRLP protocol which I think is the way to go for location data.

On 11/03/2016 06:45 PM, Keith wrote:
>
>
> On 03/11/2016 14:57, Keith wrote:
>> Would you also be able to clarify  RXL-FULL/SUB and the RXQ-FULL/SUB
>> figures?
> I looked at the source and did some research, in case anyone (who
> didn't know already) is interested,
> the L is Level and the Q is Quality.
>
> RXL-SUB is the measurement when DTX (*Discontinuous Transmission)* is
> enabled, (abbr. of subset)
> RXL-FULL is otherwise i.e when there is voice activity.
>
> That's very much of a tl;dr, but there's plenty of info on it out there.
>
>

-- 
Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/
======================================================================= 
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93 
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B 
* Geschaeftsfuehrer / Managing Director: Harald Welte 



From fanx07 at gmail.com  Tue Nov  8 09:54:51 2016
From: fanx07 at gmail.com (Anonim Stefan)
Date: Tue, 8 Nov 2016 11:54:51 +0200
Subject: osmo-nitb + osmo-sip-connector: background noise on peer to peer calls
Message-ID: <CAO7wsJuJ=+=BJuQA9C6XtjvxKLK_qYKueW0oOjFxp=Oi_R2-5w@mail.gmail.com>

Hi,

I am using osmo-nitb + osmo-sip-connector and nanoBTS to establish a per to
peer call. I am using:
osmocom-nitb                    0.15.1.20161024
osmo-sip-connector              1.20161024

While in call, I hear an annoying background noise while not talking. The
noise disappears when someone speaks.

Any idea what might be causing this and how this can be fixed?

Thanks,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161108/8b190737/attachment.htm>

From dhananjay.cse at gmail.com  Tue Nov  8 11:16:51 2016
From: dhananjay.cse at gmail.com (Dhananjay kumar)
Date: Tue, 8 Nov 2016 16:46:51 +0530
Subject: Osmo BTS Multi Carrier activation with 1 TRX
Message-ID: <CAM5ro7vvbZRtEDTsykM6+S754HOWNFO-N-EHyKn8FdT_t+4ASQ@mail.gmail.com>

Hi All,

We are trying to configure Multi carrier [ 2 or more  ARFCN working in
parallel with 1 TRX]  with B200 board.

If anyone has done it ,please share working config file and executing
command for BTS and TRX.
Thanks in advance !

-- 
Thanks & Regards
Dhananjay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161108/1497924e/attachment.htm>

From msuraev at sysmocom.de  Tue Nov  8 11:25:45 2016
From: msuraev at sysmocom.de (Max)
Date: Tue, 8 Nov 2016 12:25:45 +0100
Subject: Osmo BTS Multi Carrier activation with 1 TRX
In-Reply-To: <CAM5ro7vvbZRtEDTsykM6+S754HOWNFO-N-EHyKn8FdT_t+4ASQ@mail.gmail.com>
References: <CAM5ro7vvbZRtEDTsykM6+S754HOWNFO-N-EHyKn8FdT_t+4ASQ@mail.gmail.com>
Message-ID: <21ac0007-04ec-f1b5-0073-e04bfb5ad996@sysmocom.de>

I'm interested in this as well. I've asked couple of times but got no
response so far.

In short, there are 2 way to achieve multi-TRX with osmo-bts-trx (using
B210). One is working for me, other isn't. You can see the details and
current status at

https://projects.osmocom.org/issues/1648 - feel free to contribute your
findings there.


On 11/08/2016 12:16 PM, Dhananjay kumar wrote:
> Hi All,
>
> We are trying to configure Multi carrier [ 2 or more  ARFCN working in
> parallel with 1 TRX]  with B200 board.
>
> If anyone has done it ,please share working config file and executing
> command for BTS and TRX.
> Thanks in advance !
>
> -- 
> Thanks & Regards
> Dhananjay
>
>
>

-- 
Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/
======================================================================= 
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93 
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B 
* Geschaeftsfuehrer / Managing Director: Harald Welte 



From holger at freyther.de  Tue Nov  8 13:05:38 2016
From: holger at freyther.de (Holger Freyther)
Date: Tue, 8 Nov 2016 14:05:38 +0100
Subject: osmo-nitb + osmo-sip-connector: background noise on peer to peer
 calls
In-Reply-To: <CAO7wsJuJ=+=BJuQA9C6XtjvxKLK_qYKueW0oOjFxp=Oi_R2-5w@mail.gmail.com>
References: <CAO7wsJuJ=+=BJuQA9C6XtjvxKLK_qYKueW0oOjFxp=Oi_R2-5w@mail.gmail.com>
Message-ID: <858950FF-5DCB-490C-9A67-B92258F8575C@freyther.de>


> On 08 Nov 2016, at 10:54, Anonim Stefan <fanx07 at gmail.com> wrote:
> 
> Hi,

Hey!


> Any idea what might be causing this and how this can be fixed?

which direction? which audio codec? Can you send us a PCAP with the RTP stream?

cheers
	holger

From fanx07 at gmail.com  Tue Nov  8 16:00:24 2016
From: fanx07 at gmail.com (Anonim Stefan)
Date: Tue, 8 Nov 2016 18:00:24 +0200
Subject: osmo-nitb + osmo-sip-connector: background noise on peer to peer
 calls
In-Reply-To: <858950FF-5DCB-490C-9A67-B92258F8575C@freyther.de>
References: <CAO7wsJuJ=+=BJuQA9C6XtjvxKLK_qYKueW0oOjFxp=Oi_R2-5w@mail.gmail.com>
 <858950FF-5DCB-490C-9A67-B92258F8575C@freyther.de>
Message-ID: <CAO7wsJsgoCZQH4P0w0=DqWo7xYzRPXBd+vjLZ5snvye1OkK=zw@mail.gmail.com>

Hi,

Attached the pcap, with both SIP and RTP; hope it helps. I speak "one" from
one phone and "two" from the other.

In order to capture this I bridged 2 calls together. The first SIP call is
from BSC -> SIP MACHINE and the second SIP call is from SIP MACHINE -> BSC.
The capture has been made on SIP MACHINE.

This is happening also for 1 call scenario.

Thanks,
Stefan



On Tue, Nov 8, 2016 at 3:05 PM, Holger Freyther <holger at freyther.de> wrote:

>
> > On 08 Nov 2016, at 10:54, Anonim Stefan <fanx07 at gmail.com> wrote:
> >
> > Hi,
>
> Hey!
>
>
> > Any idea what might be causing this and how this can be fixed?
>
> which direction? which audio codec? Can you send us a PCAP with the RTP
> stream?
>
> cheers
>         holger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161108/c7e864aa/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bsc.pcap
Type: application/vnd.tcpdump.pcap
Size: 295802 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161108/c7e864aa/attachment.bin>

From abdulghafar1412 at gmail.com  Wed Nov  9 16:08:49 2016
From: abdulghafar1412 at gmail.com (Abdulghafar Shabaneh)
Date: Wed, 9 Nov 2016 16:08:49 +0000
Subject: MS cannot connect; Location Update Request not received by BTS?
In-Reply-To: <CAFeMo5ZiS0iCLtT0Jq2RG-QELsP3DN5UNP=YCYZj6c6zwugywQ@mail.gmail.com>
References: <trinity-9f444231-dce9-4de0-b1b9-94f94cb6a939-1474948050841@3capp-mailcom-lxa08>
 <291300AB-CDFF-4D1A-9797-F14D3F4E3BDA@freyther.de>
 <CAFeMo5ZiS0iCLtT0Jq2RG-QELsP3DN5UNP=YCYZj6c6zwugywQ@mail.gmail.com>
Message-ID: <CAFeMo5bP4z089p3xENoM=AdO14-w8bYu8Lg=-0xH6qvg9X+=Zw@mail.gmail.com>

Hi

I have tried to downgrade to a lot of branches of the osmo-bts, but
unfortunately was unable to catch a good one!, most of them don't build and
install correctly with errors in make or ./configure commands.

 osmo-trx seems to be working fine with the 3.008.004 UHD, it was showing
that Transceiver successfully tuned the down link and up-link frequencies.

I decided to quit with this USRP unless you have a help of which osmo-bts
can be compatible and working with current osmo-nitb for USRPs. Can you
suggest any help?

Thanks
Abdulghafar


On Tue, Sep 27, 2016 at 10:51 PM, Abdulghafar Shabaneh <
abdulghafar1412 at gmail.com> wrote:

> Hi
>
> That's the same that is happening with me since about two weeks, and I was
> unable to solve it. They told me it might be uhd problem, but I installed
> different uhds with the same issue.
>
> osmo-bitb shows the same error like this:
> <0000> chan_alloc.c:342 (bts=0,trx=0,ts=7,pchan=TCH/F) Allocating lchan=0
> as TCH_F
> <0004> abis_rsl.c:1727 (bts=0,trx=0,ts=7,ss=0) Activating ARFCN(60) SS(0)
> lctype TCH_F r=EMERGENCY ra=0xab ta=3
> <0004> abis_rsl.c:536 (bts=0,trx=0,ts=7,pchan=TCH/F) Tx RSL Channel
> Activate with act_type=INITIAL
> <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVATION
> REQUESTED
> <0004> abis_rsl.c:1456 (bts=0,trx=0,ts=7,ss=0) CHANNEL ACTIVATE ACK
> <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state ACTIVATION REQUESTED
> -> ACTIVE
> <0004> abis_rsl.c:806 (bts=0,trx=0,ts=7,ss=0) RF Channel Release CMD due
> error 1
> <0004> abis_rsl.c:718 (bts=0,trx=0,ts=7,ss=0) DEACTivate SACCH CMD
> <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state ACTIVE -> RELEASE DUE
> ERROR
> <0004> abis_rsl.c:863 (bts=0,trx=0,ts=7,ss=0) RF CHANNEL RELEASE ACK
> <0004> abis_rsl.c:767 (bts=0,trx=0,ts=7,ss=0) is back in operation.
>
>
> it once showed this error:
> <0022> control_if.c:286 Failed to parse ip access message: -5
> <0000> chan_alloc.c:355 Failed to allocate SDCCH channel
> <0004> abis_rsl.c:1678 BTS 0 CHAN RQD: no resources for SDCCH 0x10
>
>
> osmo-pcu is not working fine with me, can this help to solve the problem?,
> this is the output for using it with and without sudo.
> pi at raspberrypi:~ $ osmo-pcu -r 1
> No config file: 'osmo-pcu.cfg' Using default config.
> <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS
> <0001> osmobts_sock.cpp:264 Failed to connect to the osmo-bts PCU socket,
> delaying... '/tmp/pcu_bts'
> <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS
> <0001> osmobts_sock.cpp:264 Failed to connect to the osmo-bts PCU socket,
> delaying... '/tmp/pcu_bts'
> ^CSignal 2 received.
> full talloc report on 'Osmo-PCU context' (total      1 bytes in   1 blocks)
> pi at raspberrypi:~ $ sudo osmo-pcu -r 1
> No config file: 'osmo-pcu.cfg' Using default config.
> <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS
> <0001> osmobts_sock.cpp:285 osmo-bts PCU socket has been connected
> <0001> pcu_l1_if.cpp:357 BTS not available
> pi at raspberrypi:~ $
>
> I use USRP2 , I used recently a reference clock of 10 MHz but didn't solve
> the issue, but it is good to know that N210 is with the same error.
>
> Another thing that my network rarely shows on the MS, but the osmo-nitb
> still shows the output every minute or more or when I do a mobile network
> search.
>
> Thanks
> Abdulghafar
>
> On Tue, Sep 27, 2016 at 6:50 PM, Holger Freyther <holger at freyther.de>
> wrote:
>
>>
>> > On 27 Sep 2016, at 05:47, Bruce Smith <brucemate at mail.com> wrote:
>> >
>> > Greetings,
>>
>> Dear Bruce,
>>
>> I have never used osmo-trx/uhd or related with OpenBSC but in terms of
>> figuring out what is broken let's have a look at the different components.
>>
>>
>> > There's a delay of ~10s at the line marked **** where the BTS seems to
>> wait for a location update request from the MS; which never gets received,
>> hence the BTS times out and releases the channel. Using a phone in
>> diagnostic mode, this message appears to be sent correctly, however the BTS
>> never receives/processes it.
>>
>> So OpenBSC/osmo-nitb seems to work correctly. It doesn't "ignore" a
>> message and it is just missing. My hypothesizes that you might have time to
>> explore:
>>
>> a.) osmo-trx not being able to decode the message?
>> b.) The osmo-bts-trx is not "receiving" data from osmo-trx?
>> c.) osmo-bts-trx not getting the LAPDm framing right?
>>
>>
>> >
>> > I've tried using older configuration files (which have worked with
>> older builds), as well as the sample configuration files contained with
>> each of the master branches, but to no differing effect.
>> >
>> > Given the MS can see and attempt to connect to the BTS, I'm assuming
>> the transceiver chain is working correctly... my thoughts are that perhaps
>> I've got some simple configuration set incorrectly somewhere along the way.
>> >
>>
>> > libosmocore (master) - 2016-08-30
>> > libosmo-abis (master) - 2016-09-05
>> > libosmo-netif (master) - 2016-07-07
>> > openggsn (master) - 2016-06-05
>> > libosmo-sccp (master) - 2016-07-07
>> > openbsc (master) - 2016-09-05
>> > osmo-bts (master) - 2016-09-06
>> > osmo-pcu (master) - 2016-09-06
>> > osmo-trx (master) - 2016-08-11
>> > uhd_003.009.002-0
>>
>> Could you downgrade your osmo-trx and osmo-bts to the 12+ months old
>> version? The rest should work just fine and doesn't seem to have the issue.
>> So my bet is either osmo-bts (a year ago you must have used a branch, now
>> the refactored master branch is used) or osmo-trx?
>>
>>
>> holger
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161109/ee4bb0a6/attachment.htm>

From laforge at gnumonks.org  Wed Nov  9 17:35:02 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 09 Nov 2016 18:35:02 +0100
Subject: MS cannot connect; Location Update Request not received by BTS?
In-Reply-To: <CAFeMo5bP4z089p3xENoM=AdO14-w8bYu8Lg=-0xH6qvg9X+=Zw@mail.gmail.com>
References: <trinity-9f444231-dce9-4de0-b1b9-94f94cb6a939-1474948050841@3capp-mailcom-lxa08>
 <291300AB-CDFF-4D1A-9797-F14D3F4E3BDA@freyther.de>
 <CAFeMo5ZiS0iCLtT0Jq2RG-QELsP3DN5UNP=YCYZj6c6zwugywQ@mail.gmail.com>
 <CAFeMo5bP4z089p3xENoM=AdO14-w8bYu8Lg=-0xH6qvg9X+=Zw@mail.gmail.com>
Message-ID: <E2B1E3EF-FE59-43C4-B0EF-1247654C381A@gnumonks.org>

I'm sorry about your lack of positive experience. One problem is that osmo-bts-trx is basically unmaintained for at least 1.5 years as all the original authors and the commercial users seem to have lost interest in supporting it. I find this incredibly sad, but who should do this kind of work and continuous testing/integration, if not the commercial suppliers or users of said SDR hardware?

I'm beginning to think we should remove the code from the master repository until somebody steps up to take care of ongoing maintenance :((
-- 
Sent from a mobile device. Please excuse my brevity.


From keith at rhizomatica.org  Thu Nov 10 16:52:16 2016
From: keith at rhizomatica.org (Keith)
Date: Thu, 10 Nov 2016 17:52:16 +0100
Subject: MS cannot connect; Location Update Request not received by BTS?
In-Reply-To: <CAFeMo5bP4z089p3xENoM=AdO14-w8bYu8Lg=-0xH6qvg9X+=Zw@mail.gmail.com>
References: <trinity-9f444231-dce9-4de0-b1b9-94f94cb6a939-1474948050841@3capp-mailcom-lxa08>
 <291300AB-CDFF-4D1A-9797-F14D3F4E3BDA@freyther.de>
 <CAFeMo5ZiS0iCLtT0Jq2RG-QELsP3DN5UNP=YCYZj6c6zwugywQ@mail.gmail.com>
 <CAFeMo5bP4z089p3xENoM=AdO14-w8bYu8Lg=-0xH6qvg9X+=Zw@mail.gmail.com>
Message-ID: <d9559a90-aba8-5461-904e-7afb3ca0c078@rhizomatica.org>

On 09/11/2016 17:08, Abdulghafar Shabaneh wrote:

> Hi
>
> I decided to quit with this USRP unless you have a help of which osmo-bts
> can be compatible and working with current osmo-nitb for USRPs. Can you
> suggest any help?
Hi!
This doesn't fix what Harald mentions, and I don't know if it may be of
some help, I hope so, so I will describe my setup.

I am keeping my NITB work separated the osmo-trx/bts box, even though it
really makes no difference as I am using static-builds of osmobts-trx
and osmo-trx, that I built with this: git://git.osmocom.org/osmo-bts.git
So, they are the versions that the submodules in that repo point to
there currently.

That, I believe, is for osmo-bts, this release: fairwaves/0.3.0-fw-4
<http://git.osmocom.org/osmo-bts/tag/?h=fairwaves/0.3.0-fw-4>
http://git.osmocom.org/osmo-bts/commit/?h=fairwaves/master&id=b78554342cb2344b13c17bfeaada0509cac5b51c

and for osmo-trx it's at this commit
http://git.osmocom.org/osmo-trx/commit/?id=c312905f43bb120450c33d9a80bc35771d598fc6

Not sure what dependencies you actually have there in the rest of the
osmo stack to build those two (bts/trx), but I can tell you that I have
built that tree and it works fine for the purposes of working and
testing the NITB.

Should you want to work on osmo-bts, you might have an issue. There are
a lot of branches there, I certainly have no idea what's going on.

I am using an N210, and IIRC, I had grave problems with the UHD from the
ettus ubuntu repo, so I cloned from githib and compiled master at the time.
my UHD is reporting UHD_003.010.git-156-g2d68f228
so it was this commit:
https://github.com/EttusResearch/uhd/commit/2d68f228

In case (I really don't think so) it has some impact, all this happens
to be on a stock Ubuntu 12.04.5 LTS,
3.13.0-85-generic #129~precise1-Ubuntu SMP Fri Mar 18 17:38:08 UTC 2016
x86_64

Everything is working "perfectly" ;-)

k.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161110/95a58bdc/attachment.htm>

From keith at rhizomatica.org  Thu Nov 10 17:09:35 2016
From: keith at rhizomatica.org (Keith)
Date: Thu, 10 Nov 2016 18:09:35 +0100
Subject: Errata: Re: MS cannot connect; Location Update Request not received
 by BTS?
In-Reply-To: <d9559a90-aba8-5461-904e-7afb3ca0c078@rhizomatica.org>
References: <trinity-9f444231-dce9-4de0-b1b9-94f94cb6a939-1474948050841@3capp-mailcom-lxa08>
 <291300AB-CDFF-4D1A-9797-F14D3F4E3BDA@freyther.de>
 <CAFeMo5ZiS0iCLtT0Jq2RG-QELsP3DN5UNP=YCYZj6c6zwugywQ@mail.gmail.com>
 <CAFeMo5bP4z089p3xENoM=AdO14-w8bYu8Lg=-0xH6qvg9X+=Zw@mail.gmail.com>
 <d9559a90-aba8-5461-904e-7afb3ca0c078@rhizomatica.org>
Message-ID: <f7a0eb65-08c2-60f9-f9e8-227d8aee044b@rhizomatica.org>

On 10/11/2016 17:52, Keith wrote:
> I am keeping my NITB work separated the osmo-trx/bts box, even though it
> really makes no difference as I am using static-builds of osmobts-trx
> and osmo-trx, that I built with this: git://git.osmocom.org/osmo-bts.git
Sorry, that should read: https://github.com/fairwaves/osmo-combo
> So, they are the versions that the submodules in that repo point to
> there currently.
>



From laforge at gnumonks.org  Fri Nov 11 10:11:00 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 11 Nov 2016 11:11:00 +0100
Subject: Migration of GSUP HLR code
Message-ID: <20161111101100.ac3khd26fg2ycnty@nataraja>

Dear all,

I have just moved the Osmocom GSUP HLR code from the really unrelated
ancient osmo-auc.git repository into its own osmo-hlr.git repository.

The GSUP HLR is a stand-alone HLR for SIM and USIM based subscribers
which exposes the GSUP protocol towards its users.  Currently in
openbsc master, there is OsmoSGSN which supports this protocol.

There is ongoing work to remove the HLR from OsmoNITB and make it access
the GSUP HLR asynchronously.  I originally intended to complete this
in summer this year,but was constantly delayed due to various other
tasks :/

Neels is now coming to the rescue and is in charge of moving this ahead
to get it ready to merge.

The osmo-gsup-hlr is still very simplistic.  It's a single-threaded
architecture and uses only sqlite3 tables as back-end.  It is suitable
for installations of the scale that OsmoNITB was able to handle.  It
also lacks various features like fine-grained control of subscribed
services (like supplementary services).  The most important goal for
osmo-gsup-hlr is to be a replacement for the HLR code we'r removing from
good old OsmoNITB.  It is *not* supposed to be a fully-featured GSM HLR.

One of the advantages of having the GSUP protocol for both CS and PS
side is that there could be other, more scalable/powerful
implementations of the HLR that can just be swapped in.

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Fri Nov 11 11:50:01 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 11 Nov 2016 12:50:01 +0100
Subject: naming contest: gsm_network, gsm_subscriber_connection
Message-ID: <20161111115001.GA4864@my.box>

Hi all,

for a bit of bikeshed fun on the side, I'd like to ask your opinions on a good
name.

The background: we're in the process of separating libmsc from libbsc. Both use
the structs gsm_network and gsm_subscriber_connection, and both of these
structs contain elements that are used only by libbsc or only by libmsc,
besides the elements that are used by both. So at some point I will "split"
both of these in two, to have a BSC and an MSC version thereof.

How should we name them?


struct gsm_network
(note, if there is a common part, that could still be named 'gsm_network')

--> bsc_network / msc_network
    looks familiar but the meaning of the name is lost

--> gsm_bsc / gsm_msc

--> osmo_bsc / osmo_msc
    To me these would be the best and the names are still available, but there
    are header files named like this and the osmo-bsc binary also has a very
    similar name. I think I would go for these anyway.
    +1

--> osmo_gsm_bsc / osmo_gsm_msc
    As alternative, but the gsm is a bit out of place (particularly in the
    light of a UMTS MSC).


struct gsm_subscriber_connection

--> bsc_subscriber_connection / msc_subscriber_connection
    but we could use the opportunity to shorten the name

--> bsc_subscr_conn / msc_subscr_conn
    I like these best; but add osmo?
    +1

--> osmo_bsc_subscr_conn / osmo_msc_subscr_conn
    almost the old length.


Happy shedding, "+1" comments and/or opinions welcome

~Neels

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161111/39104e59/attachment.bin>

From laforge at gnumonks.org  Fri Nov 11 13:58:07 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 11 Nov 2016 14:58:07 +0100
Subject: naming contest: gsm_network, gsm_subscriber_connection
In-Reply-To: <20161111115001.GA4864@my.box>
References: <20161111115001.GA4864@my.box>
Message-ID: <20161111135807.4eh2gqwrodhmkrrb@nataraja>

Hi Neels,

On Fri, Nov 11, 2016 at 12:50:01PM +0100, Neels Hofmeyr wrote:

> struct gsm_network
> (note, if there is a common part, that could still be named 'gsm_network')
> 
> --> bsc_network / msc_network
>     looks familiar but the meaning of the name is lost
> 
> --> gsm_bsc / gsm_msc
> 
> --> osmo_bsc / osmo_msc
>     To me these would be the best and the names are still available, but there
>     are header files named like this and the osmo-bsc binary also has a very
>     similar name. I think I would go for these anyway.
>     +1
> 
> --> osmo_gsm_bsc / osmo_gsm_msc
>     As alternative, but the gsm is a bit out of place (particularly in the
>     light of a UMTS MSC).

In general we shouldn't call structures how we are (or might be) calling
functional elements.  So if it's a msc or bsc instance or context,
postfix it by _inst, _instance, _ctx or _context.

Also, the osmo_ naming prefix makex mostly sense in the conext of
library code to avoid namespace pollution.  I think I actually like it
if application code structures and symbols do not have osmo_ prefixes.

> struct gsm_subscriber_connection
> 
> --> bsc_subscriber_connection / msc_subscriber_connection
>     but we could use the opportunity to shorten the name
> 
> --> bsc_subscr_conn / msc_subscr_conn
>     I like these best; but add osmo?
>     +1

fine with me.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From Mrinal.Mishra at radisys.com  Fri Nov 11 12:51:03 2016
From: Mrinal.Mishra at radisys.com (Mrinal Mishra)
Date: Fri, 11 Nov 2016 12:51:03 +0000
Subject: Dynamic TCH/F_PDCH does not work for CS call 
Message-ID: <BY2PR0801MB14932EC25A45BF2BCA6EB9EAE5BB0@BY2PR0801MB1493.namprd08.prod.outlook.com>

Hello All,

We are testing Dynamic TCH allocation. In the latest BSC ( commit version 87ef68eb33d463d8aad1511a272cbdb779f1ba19) it is observed that CS call is not working with TCH/F_PDCH channel configuration. Please note that if PS call is attempted in TCH/F_PDCH channel then it works fine.

When Dynamic TCH tested with the old BSC commit  version (7bc6986f6babdaf5f2436dae2f603ae5823aa7b4) then CS call worked fine with TCH/F_PDCH channel.

Please let us know if it is known issue.

Thanks and Regards,
Mrinal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161111/cc46d6f6/attachment.htm>

From nhofmeyr at sysmocom.de  Fri Nov 11 17:18:55 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 11 Nov 2016 18:18:55 +0100
Subject: Dynamic TCH/F_PDCH does not work for CS call
In-Reply-To: <BY2PR0801MB14932EC25A45BF2BCA6EB9EAE5BB0@BY2PR0801MB1493.namprd08.prod.outlook.com>
References: <BY2PR0801MB14932EC25A45BF2BCA6EB9EAE5BB0@BY2PR0801MB1493.namprd08.prod.outlook.com>
Message-ID: <20161111171855.GA9130@my.box>

Dear Mrinal,

please be aware that TCH/F_PDCH is a pchan type that is designed for use with
ip.access nanoBTS exclusively. This BTS model understands a non-standard RSL
message to de-/activate PDCH ("PDCH Act"). Some of our other BTS software also
support this pchan kind: sysmoBTS, lc15 and osmo-bts-trx if I remember
correctly, but preferably use the pchan type TCH/F_TCH/H_PDCH in your osmo-bsc
or osmo-nitb config.

When you refer to a PS call, do you mean that GPRS service is used to place a
VoIP call? This is the same as saying that GPRS is functional.

There should be no significant difference in functionality concerning dynamic
timeslots (either kind) between master and commit 7bc6986f6ba, all commits that
"really matter" concerning dyn TS were already present in that revision.

Please verify your statements and/or accompany with log output,
and also try TCH/F_TCH/H_PDCH instead.

If the problem persists, please a) bisect to pinpoint the failing revision and
b) add full log output, preferably with DRSL and DNM logs set to debug level.

I verified that TCH/F_TCH/H_PDCH is functional on sysmobts with all the newest
commits just yesterday.

~Neels


On Fri, Nov 11, 2016 at 12:51:03PM +0000, Mrinal Mishra wrote:
> Hello All,
> 
> We are testing Dynamic TCH allocation. In the latest BSC ( commit version 87ef68eb33d463d8aad1511a272cbdb779f1ba19) it is observed that CS call is not working with TCH/F_PDCH channel configuration. Please note that if PS call is attempted in TCH/F_PDCH channel then it works fine.
> 
> When Dynamic TCH tested with the old BSC commit  version (7bc6986f6babdaf5f2436dae2f603ae5823aa7b4) then CS call worked fine with TCH/F_PDCH channel.
> 
> Please let us know if it is known issue.
> 
> Thanks and Regards,
> Mrinal
> 

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161111/1efdb5cb/attachment.bin>

From nhofmeyr at sysmocom.de  Fri Nov 11 17:22:33 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 11 Nov 2016 18:22:33 +0100
Subject: naming contest: gsm_network, gsm_subscriber_connection
In-Reply-To: <20161111135807.4eh2gqwrodhmkrrb@nataraja>
References: <20161111115001.GA4864@my.box>
 <20161111135807.4eh2gqwrodhmkrrb@nataraja>
Message-ID: <20161111172233.GB9130@my.box>

On Fri, Nov 11, 2016 at 02:58:07PM +0100, Harald Welte wrote:
> In general we shouldn't call structures how we are (or might be) calling
> functional elements.  So if it's a msc or bsc instance or context,
> postfix it by _inst, _instance, _ctx or _context.
> 
> Also, the osmo_ naming prefix makex mostly sense in the conext of
> library code to avoid namespace pollution.  I think I actually like it
> if application code structures and symbols do not have osmo_ prefixes.

> > --> bsc_subscr_conn / msc_subscr_conn
> >     I like these best; but add osmo?
> >     +1
> 
> fine with me.

So for now my finalists are:
  gsm_network --> bsc_ctx / msc_ctx
and
  gsm_subscriber_connection --> bsc_subscr_conn / msc_subscr_conn

Speak now or forever hold your peace...

~N

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161111/1aa58819/attachment.bin>

From nhofmeyr at sysmocom.de  Sat Nov 12 14:38:36 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 12 Nov 2016 15:38:36 +0100
Subject: naming contest: gsm_network, gsm_subscriber_connection
In-Reply-To: <DC79A684-0804-415A-9F72-C36F76953A42@networkradius.com>
References: <20161111115001.GA4864@my.box>
 <DC79A684-0804-415A-9F72-C36F76953A42@networkradius.com>
Message-ID: <20161112143836.GA2086@my.box>

On Fri, Nov 11, 2016 at 05:04:00PM -0500, Arran Cudbard-Bell wrote:
> http://wiki.freeradius.org/contributing/coding-standards

not sure how this is related to this thread... anyway:

the most significant differences from freeradius' style is that Osmocom
apparently still have 1978 and break lines at 80 chars not 120, and we also
prefer a break in 'if (foo && bar) baz();'

We also don't do "Error gotos jump backwards", and apparently also not "Const
on the right".

Apart from that it indeed reads like an Osmocom coding style guide.

I like "Const on the right" :)
That would have helped me realize what exactly const is tied to a lot sooner
than I did.

~N



From nhofmeyr at sysmocom.de  Sun Nov 13 14:08:18 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 13 Nov 2016 15:08:18 +0100
Subject: complete merge of IuCS using --enable-iu switch
Message-ID: <20161113140818.GA1458@my.box>

So far the state of IuCS aka 3G voice is such that we will not merge the branch
to master unless we have a proper A-interface.

But come to think of it, it would technically be possible to split the code not
by git branches, but rather by the --enable-iu configure switch. In that case
openbsc master would contain all IuCS code, and if compiled with --enable-iu,
compile time switches would disable osmo-nitb, enable osmo-cscn and (currently)
destroy 2G due to lack of an A-interface implementation.

The benefit would be simply to not have a separate branch, making for easier 3G
build instructions and possibly reducing rebase merge conflicts; developers
could adjust the 3G code paths along with their 2G patches.

It's just an idea that came to mind... In the end it's just a kind of "fake"
merge, so not sure whether it's worth the effort.

Any thoughts?

~N

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161113/a157ea4c/attachment.bin>

From laforge at gnumonks.org  Sun Nov 13 20:37:38 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 13 Nov 2016 21:37:38 +0100
Subject: The future of c-open-smpp-34 ?
Message-ID: <20161113203738.c6hsclgi2ws5m2zp@nataraja>

Dear Raul,

In 2012 the Osmocom OpenBSC project started to use your libsmpp34 in
order to add SMPP capabilities to our GSM Netwrok In The Box (NITB).

As there was no source code repository (svn, git. ...) of your library
around at the time, we imported the latest version you had released
(1.10) into a git repository at http://git.osmocom.org/libsmpp34/

Ever since we have been chcecking your sourceforge project occasionally
to see if you had made any further releases, in order to re-synchronize
them.  Ther hasn't been any release ever since.

Meanwhile, various (small) improvements have been happening in our git
repository, but those changes are of course not visible to the new user
who is ending up on your sourceforge.net project page.

In order to avoid further confusion to the user, I would like to ask
your input on how we should proceed.

* do you still have plans for this library?
* do you want to run a git repo on sf.net and merge our contributions?
* would you consider designating the git.osmocom.org server as the
  official source code repository, maybe even moving other content from
  sf.net to https://osmocom.org/projects/libsmpp34

I would appreciate if you could at least put a notice on sf.net
indicating that there is a more actively maintained fork of your library
available at the above URLS.

Let me know if there is something we can do to help, or if you have any
other comments.

Thanks,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From Mrinal.Mishra at radisys.com  Mon Nov 14 14:55:30 2016
From: Mrinal.Mishra at radisys.com (Mrinal Mishra)
Date: Mon, 14 Nov 2016 14:55:30 +0000
Subject: Dynamic TCH/F_PDCH does not work for CS call
In-Reply-To: <20161111171855.GA9130@my.box>
References: <BY2PR0801MB14932EC25A45BF2BCA6EB9EAE5BB0@BY2PR0801MB1493.namprd08.prod.outlook.com>
 <20161111171855.GA9130@my.box>
Message-ID: <BY2PR0801MB14936D570D597BBA72C6AA8EE5BC0@BY2PR0801MB1493.namprd08.prod.outlook.com>

> From: Neels Hofmeyr [mailto:nhofmeyr at sysmocom.de]

> I remember correctly, but preferably use the pchan type
> TCH/F_TCH/H_PDCH in your osmo-bsc or osmo-nitb config.

As per the channel configuration defined in the code TCH/F_PDCH is a valid channel configuration and it should work as TCH/F or PDCH channel dynamically.
I tested even with TCH/F_TCH/H_PDCH and it works fine only as TCH/H or PDCH it does not get used as TCH/F.

> When you refer to a PS call, do you mean that GPRS service is used to place a
> VoIP call? This is the same as saying that GPRS is functional.

By PS call I mean GPRS data transfer and yes GPRS is functional.
 
> Please verify your statements and/or accompany with log output, and also
> try TCH/F_TCH/H_PDCH instead.

I have tested TCH/F_TCH/H_PDCH also and it works fine as TCH/H channel. As per the name of the pchan type it can be used as TCH/F or TCH/H or PDCH 
But it does not work as TCH/F. 
Also as I mentioned earlier in TCH/F_PDCH pchan type CS (voice) call does not work.

> If the problem persists, please a) bisect to pinpoint the failing revision and
> b) add full log output, preferably with DRSL and DNM logs set to debug level.

Currently I am busy in other activities. I will bisect and capture the logs once I have some time . Could you please suggest any specific  Unit test case which can be 
executed to compare result.


From nhofmeyr at sysmocom.de  Tue Nov 15 01:42:28 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 15 Nov 2016 02:42:28 +0100
Subject: Dynamic TCH/F_PDCH does not work for CS call
In-Reply-To: <BY2PR0801MB14936D570D597BBA72C6AA8EE5BC0@BY2PR0801MB1493.namprd08.prod.outlook.com>
References: <BY2PR0801MB14932EC25A45BF2BCA6EB9EAE5BB0@BY2PR0801MB1493.namprd08.prod.outlook.com>
 <20161111171855.GA9130@my.box>
 <BY2PR0801MB14936D570D597BBA72C6AA8EE5BC0@BY2PR0801MB1493.namprd08.prod.outlook.com>
Message-ID: <20161115014228.GA21702@my.box>

On Mon, Nov 14, 2016 at 02:55:30PM +0000, Mrinal Mishra wrote:
> As per the channel configuration defined in the code TCH/F_PDCH is a valid
> channel configuration and it should work as TCH/F or PDCH channel
> dynamically.  I tested even with TCH/F_TCH/H_PDCH and it works fine only as
> TCH/H or PDCH it does not get used as TCH/F.

I am glad to hear that TCH/F_TCH/H_PDCH works as TCH/H.
The reason why this pchan type is not used as TCH/F is OS#1778
https://osmocom.org/issues/1778

Fixing OS#1778 is not a top priority at the moment. The perspective that TCH/H
is more efficiently using the available timeslots than TCH/F and the fact that
most MS are capable of TCH/H makes this not very urgent.

Since the ip.access nanoBTS is not capable of TCH/H, it is pretty much the only
hardware where you actually want to use TCH/F_PDCH. Nevertheless, if TCH/F_PDCH
is broken for other BTS models that support it, it should be fixed.

> Also as I mentioned earlier in TCH/F_PDCH pchan type CS (voice) call does not work.

Of course TCH/F_PDCH is a valid channel configuration, which you may use if you
insist on TCH/F -- as long as it is implemented for your BTS model.
There is no unit test available. Testing pchan types involves using a NITB and
actual BTS hardware. At some point, we would like to test this in our
osmo-gsm-tester setup, which still needs a lot of work. See:
https://osmocom.org/projects/cellular-infrastructure/wiki/Roadmap#Build-and-Test-infrastructure

Kindly state which BTS hardware you are using. And I am looking forward to your
logs and/or bisect, if you can spare the time.

As always, let me plug the possibility of directly sponsoring any of above
mentioned issues via sysmocom, to anyone reading this and interested in
quick progress.

~Neels

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161115/301e75c7/attachment.bin>

From alexander.chemeris at gmail.com  Tue Nov 15 03:59:16 2016
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Mon, 14 Nov 2016 19:59:16 -0800
Subject: Dynamic TCH/F_PDCH does not work for CS call
In-Reply-To: <20161115014228.GA21702@my.box>
References: <BY2PR0801MB14932EC25A45BF2BCA6EB9EAE5BB0@BY2PR0801MB1493.namprd08.prod.outlook.com>
 <20161111171855.GA9130@my.box>
 <BY2PR0801MB14936D570D597BBA72C6AA8EE5BC0@BY2PR0801MB1493.namprd08.prod.outlook.com>
 <20161115014228.GA21702@my.box>
Message-ID: <CABmJbFUTF3knwZf+kJ-4AV5godqACgfAjCaqcCZzHKd9G1m=_A@mail.gmail.com>

On Mon, Nov 14, 2016 at 5:42 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> On Mon, Nov 14, 2016 at 02:55:30PM +0000, Mrinal Mishra wrote:
>> As per the channel configuration defined in the code TCH/F_PDCH is a valid
>> channel configuration and it should work as TCH/F or PDCH channel
>> dynamically.  I tested even with TCH/F_TCH/H_PDCH and it works fine only as
>> TCH/H or PDCH it does not get used as TCH/F.
>
> I am glad to hear that TCH/F_TCH/H_PDCH works as TCH/H.
> The reason why this pchan type is not used as TCH/F is OS#1778
> https://osmocom.org/issues/1778
>
> Fixing OS#1778 is not a top priority at the moment. The perspective that TCH/H
> is more efficiently using the available timeslots than TCH/F and the fact that
> most MS are capable of TCH/H makes this not very urgent.

The reason why people use TCH/F is because it offers higher quality than TCH/H.
E.g. if you're using AMR, you can go only up to 7.95 mode in TCH/H
(see https://en.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_codec).
So just saying that TCH/H is "more efficient" is not correct. It's
more efficient in exchange to some loss in quality.

-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co


From nhofmeyr at sysmocom.de  Tue Nov 15 09:32:59 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 15 Nov 2016 10:32:59 +0100
Subject: Dynamic TCH/F_PDCH does not work for CS call
In-Reply-To: <CABmJbFUTF3knwZf+kJ-4AV5godqACgfAjCaqcCZzHKd9G1m=_A@mail.gmail.com>
References: <BY2PR0801MB14932EC25A45BF2BCA6EB9EAE5BB0@BY2PR0801MB1493.namprd08.prod.outlook.com>
 <20161111171855.GA9130@my.box>
 <BY2PR0801MB14936D570D597BBA72C6AA8EE5BC0@BY2PR0801MB1493.namprd08.prod.outlook.com>
 <20161115014228.GA21702@my.box>
 <CABmJbFUTF3knwZf+kJ-4AV5godqACgfAjCaqcCZzHKd9G1m=_A@mail.gmail.com>
Message-ID: <20161115093259.GA1499@ass40.sysmocom.de>

On Mon, Nov 14, 2016 at 07:59:16PM -0800, Alexander Chemeris wrote:
> The reason why people use TCH/F is because it offers higher quality than TCH/H.
> E.g. if you're using AMR, you can go only up to 7.95 mode in TCH/H
> (see https://en.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_codec).
> So just saying that TCH/H is "more efficient" is not correct. It's
> more efficient in exchange to some loss in quality.

IMHO twice the number of timeslots qualifies for saying "more efficiently
using the available timeslots" :)

But thanks for this clarification. My impression so far was that AMR on
TCH/H has fair enough quality that the voice call experience isn't
noticeably different to TCH/F and "everyone is using it anyways"...?

Also how do "people use" TCH/F? Is it a choice the MS user is able to
make? Or is this always a choice on the CN side?

~N

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161115/cd340a59/attachment.bin>

From nhofmeyr at sysmocom.de  Tue Nov 15 10:53:47 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 15 Nov 2016 11:53:47 +0100
Subject: Dynamic TCH/F_PDCH does not work for CS call
In-Reply-To: <20161115093259.GA1499@ass40.sysmocom.de>
References: <BY2PR0801MB14932EC25A45BF2BCA6EB9EAE5BB0@BY2PR0801MB1493.namprd08.prod.outlook.com>
 <20161111171855.GA9130@my.box>
 <BY2PR0801MB14936D570D597BBA72C6AA8EE5BC0@BY2PR0801MB1493.namprd08.prod.outlook.com>
 <20161115014228.GA21702@my.box>
 <CABmJbFUTF3knwZf+kJ-4AV5godqACgfAjCaqcCZzHKd9G1m=_A@mail.gmail.com>
 <20161115093259.GA1499@ass40.sysmocom.de>
Message-ID: <20161115105347.GB1499@ass40.sysmocom.de>

On Tue, Nov 15, 2016 at 10:32:59AM +0100, Neels Hofmeyr wrote:
> IMHO twice the number of timeslots qualifies for saying "more efficiently

I meant twice the number of voice lchans, of course.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161115/08629adb/attachment.bin>

From Mrinal.Mishra at radisys.com  Tue Nov 15 15:01:55 2016
From: Mrinal.Mishra at radisys.com (Mrinal Mishra)
Date: Tue, 15 Nov 2016 15:01:55 +0000
Subject: Dynamic TCH/F_PDCH does not work for CS call
In-Reply-To: <20161115105347.GB1499@ass40.sysmocom.de>
References: <BY2PR0801MB14932EC25A45BF2BCA6EB9EAE5BB0@BY2PR0801MB1493.namprd08.prod.outlook.com>
 <20161111171855.GA9130@my.box>
 <BY2PR0801MB14936D570D597BBA72C6AA8EE5BC0@BY2PR0801MB1493.namprd08.prod.outlook.com>
 <20161115014228.GA21702@my.box>
 <CABmJbFUTF3knwZf+kJ-4AV5godqACgfAjCaqcCZzHKd9G1m=_A@mail.gmail.com>
 <20161115093259.GA1499@ass40.sysmocom.de>
 <20161115105347.GB1499@ass40.sysmocom.de>
Message-ID: <BY2PR0801MB1493B9487BED9DC2DC96B868E5BF0@BY2PR0801MB1493.namprd08.prod.outlook.com>

> From: Neels Hofmeyr [mailto:nhofmeyr at sysmocom.de]
> > IMHO twice the number of timeslots qualifies for saying "more efficiently
> 
> I meant twice the number of voice lchans, of course.
I have tested the CS voice call using 1 TCH/H channel in osmo-bts-trx using USRP B210 board and CS voice call was not successful. 
When I configure 2 TCH/H channel in the TRX then CS  voice call works fine. BSC commit version used  was " 87ef68eb33d463d8aad1511a272cbdb779f1ba19"
As per your explanation 1 TCH/H channel is sufficient for 1  CS  voice call( Mobile originated and Mobile terminated CS call). Please correct me if I am wrong.

Thanks and Regards,
Mrinal


From laforge at gnumonks.org  Tue Nov 15 15:42:22 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 15 Nov 2016 16:42:22 +0100
Subject: Dynamic TCH/F_PDCH does not work for CS call
In-Reply-To: <20161115093259.GA1499@ass40.sysmocom.de>
References: <BY2PR0801MB14932EC25A45BF2BCA6EB9EAE5BB0@BY2PR0801MB1493.namprd08.prod.outlook.com>
 <20161111171855.GA9130@my.box>
 <BY2PR0801MB14936D570D597BBA72C6AA8EE5BC0@BY2PR0801MB1493.namprd08.prod.outlook.com>
 <20161115014228.GA21702@my.box>
 <CABmJbFUTF3knwZf+kJ-4AV5godqACgfAjCaqcCZzHKd9G1m=_A@mail.gmail.com>
 <20161115093259.GA1499@ass40.sysmocom.de>
Message-ID: <20161115154222.eu6c6f4v5h4rf43j@nataraja>

On Tue, Nov 15, 2016 at 10:32:59AM +0100, Neels Hofmeyr wrote:
> But thanks for this clarification. My impression so far was that AMR on
> TCH/H has fair enough quality that the voice call experience isn't
> noticeably different to TCH/F and "everyone is using it anyways"...?

this is true. the concern is primarily about handsets too old to support
AMR, so they would only be able to do HRv1.  And that is really crappy.
So on such handsets, you typically try to fall back to TCH/F.

At least whenever I did traces here in Berlin with German operators, it
was pretty standard that AMR/HR was used at all time [with phones that
support it], irrespective on which Operator.

> Also how do "people use" TCH/F? Is it a choice the MS user is able to
> make? Or is this always a choice on the CN side?

please see the various discussions and tickets on codec selection.

* the MS reports its codec capability
* the BTS has a codec capability
* the BSC and MSC/MGW might have codec capabilities
* there is operator policy involved

so you need to find the common codec sub-set accross all components in
the path, and then take operator policy into consideration, as well as
current channel load in the cell, etc.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From sipos.csaba at kvk.uni-obuda.hu  Wed Nov 16 11:19:45 2016
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Wed, 16 Nov 2016 12:19:45 +0100 (CET)
Subject: Nokia crash during init is fixed
In-Reply-To: <674728593.9364011.1479294985406.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <1898973263.9364698.1479295185136.JavaMail.zimbra@kvk.uni-obuda.hu>

Dear Harald,

Just wanted to confirm that a long outstanding crash is now fixed by your patch:

http://cgit.osmocom.org/libosmocore/commit/?id=f92e44c5399d8914aad58bd2c74005b3640c5a9d

After applying it, the nasty hack I used is not needed anymore, and the BTS-es are coming up just fine, all services are working correctly.

Will update the Nokia Site specific part of the wiki with this new information.

Thanks!

Csaba


From laforge at gnumonks.org  Wed Nov 16 11:51:14 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 16 Nov 2016 12:51:14 +0100
Subject: Nokia crash during init is fixed
In-Reply-To: <1898973263.9364698.1479295185136.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <674728593.9364011.1479294985406.JavaMail.zimbra@kvk.uni-obuda.hu>
 <1898973263.9364698.1479295185136.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <20161116115114.ujjn453gjmldqzy7@nataraja>

Hi Csaba,

On Wed, Nov 16, 2016 at 12:19:45PM +0100, Sipos Csaba wrote:
> Just wanted to confirm that a long outstanding crash is now fixed by your patch:
> http://cgit.osmocom.org/libosmocore/commit/?id=f92e44c5399d8914aad58bd2c74005b3640c5a9d
> After applying it, the nasty hack I used is not needed anymore, and
> the BTS-es are coming up just fine, all services are working
> correctly.

great. thanks for letting me know.

> Will update the Nokia Site specific part of the wiki with this new information.

Also feel free to make sure all known issues are reported in the redmine
issue tracker.  I think for Nokia specific issues, you are one of the
few people I know that regularly use this part of OpenBSC.

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Wed Nov 16 12:26:25 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 16 Nov 2016 13:26:25 +0100
Subject: Dynamic TCH/F_PDCH does not work for CS call
In-Reply-To: <BY2PR0801MB1493B9487BED9DC2DC96B868E5BF0@BY2PR0801MB1493.namprd08.prod.outlook.com>
References: <BY2PR0801MB14932EC25A45BF2BCA6EB9EAE5BB0@BY2PR0801MB1493.namprd08.prod.outlook.com>
 <20161111171855.GA9130@my.box>
 <BY2PR0801MB14936D570D597BBA72C6AA8EE5BC0@BY2PR0801MB1493.namprd08.prod.outlook.com>
 <20161115014228.GA21702@my.box>
 <CABmJbFUTF3knwZf+kJ-4AV5godqACgfAjCaqcCZzHKd9G1m=_A@mail.gmail.com>
 <20161115093259.GA1499@ass40.sysmocom.de>
 <20161115105347.GB1499@ass40.sysmocom.de>
 <BY2PR0801MB1493B9487BED9DC2DC96B868E5BF0@BY2PR0801MB1493.namprd08.prod.outlook.com>
Message-ID: <20161116122625.GC1518@my.box>

On Tue, Nov 15, 2016 at 03:01:55PM +0000, Mrinal Mishra wrote:
> As per your explanation 1 TCH/H channel is sufficient for 1  CS  voice call( Mobile originated and Mobile terminated CS call). Please correct me if I am wrong.

Please be aware of https://osmocom.org/issues/1795
If you have time to investigate and/or fix, that would be highly appreciated.

~Neels

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161116/fee9828c/attachment.bin>

From sipos.csaba at kvk.uni-obuda.hu  Wed Nov 16 12:53:54 2016
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Wed, 16 Nov 2016 13:53:54 +0100 (CET)
Subject: Nokia crash during init is fixed
In-Reply-To: <20161116115114.ujjn453gjmldqzy7@nataraja>
References: <674728593.9364011.1479294985406.JavaMail.zimbra@kvk.uni-obuda.hu>
 <1898973263.9364698.1479295185136.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116115114.ujjn453gjmldqzy7@nataraja>
Message-ID: <1404507143.9404212.1479300834688.JavaMail.zimbra@kvk.uni-obuda.hu>

Dear Harald,

The only outstanding problem is that during SMS sending, the Nokia Site familiy does not seems to send the release confirm, after the SMS is sent, and it generates a T200 timeout.

This problem is very similar to the issue Andreas fixed (the same problem seems to happen with handovers too on Nokia Site):

http://cgit.osmocom.org/openbsc/commit/?id=7d8fa3418ff6c589eba10e562da8b96995e19f7a

Actually if the above patch is enabled (nokia_site no-local-rel-conf 1), this problem is also seems to be "resolved". According to the standard the release confirm must be sent, so this is clearly an erroneous behavior of the Nokia BTSes. Maybe they use some additional/different signalling an their Abis implementation to signal this, but as I dont have any Nokia BSCs lying around, I cannot verify this.

Besides this I have some outstanding patches for Nokia Site specific features, like the RSL timer for UltraSite, and the ability to configure hopping and hopping type. I managed to do RF and baseband hopping on MetroSite, and RF hopping on UltraSite units with it :-) Will try and send it to you soon.

I also needed to register a new user name on osmocom.org. Can you please grant me edit right on the wiki pages? The user name is csaba.sipos My old account does not seems to work since the restructure of the site. Thanks!

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Harald Welte" <laforge at gnumonks.org>
C?mzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
M?solatot kap: "OpenBSC Mailing List" <openbsc at lists.osmocom.org>
Elk?ld?tt ?zenetek: Szerda, 2016. November 16. 12:51:14
T?rgy: Re: Nokia crash during init is fixed

Hi Csaba,

On Wed, Nov 16, 2016 at 12:19:45PM +0100, Sipos Csaba wrote:
> Just wanted to confirm that a long outstanding crash is now fixed by your patch:
> http://cgit.osmocom.org/libosmocore/commit/?id=f92e44c5399d8914aad58bd2c74005b3640c5a9d
> After applying it, the nasty hack I used is not needed anymore, and
> the BTS-es are coming up just fine, all services are working
> correctly.

great. thanks for letting me know.

> Will update the Nokia Site specific part of the wiki with this new information.

Also feel free to make sure all known issues are reported in the redmine
issue tracker.  I think for Nokia specific issues, you are one of the
few people I know that regularly use this part of OpenBSC.

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           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 Nov 16 15:10:58 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 16 Nov 2016 16:10:58 +0100
Subject: Nokia crash during init is fixed
In-Reply-To: <1404507143.9404212.1479300834688.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <674728593.9364011.1479294985406.JavaMail.zimbra@kvk.uni-obuda.hu>
 <1898973263.9364698.1479295185136.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116115114.ujjn453gjmldqzy7@nataraja>
 <1404507143.9404212.1479300834688.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <20161116151058.mm4g75tjool3vue6@nataraja>

Hi Sipos,

On Wed, Nov 16, 2016 at 01:53:54PM +0100, Sipos Csaba wrote:
> The only outstanding problem is that during SMS sending, the Nokia
> Site familiy does not seems to send the release confirm, after the SMS
> is sent, and it generates a T200 timeout.

If there is no issue in redmine yet, please create one.

> This problem is very similar to the issue Andreas fixed (the same problem seems to happen with handovers too on Nokia Site):
> 
> http://cgit.osmocom.org/openbsc/commit/?id=7d8fa3418ff6c589eba10e562da8b96995e19f7a

ideally the release path is centralized in one place in the code so the
fix would apply to all scenarios.  I'm not sure what's different in the
SMS case, but I also have no time to look into this now, sorry.

> Besides this I have some outstanding patches for Nokia Site specific
> features, like the RSL timer for UltraSite, and the ability to
> configure hopping and hopping type. I managed to do RF and baseband
> hopping on MetroSite, and RF hopping on UltraSite units with it :-)
> Will try and send it to you soon.

It might make sense to keep those patches in a branch on
git.osmocom.org, even if you think they're not yet ready to merge. Just
in case somebody else needs/wants them.

> I also needed to register a new user name on osmocom.org. Can you
> please grant me edit right on the wiki pages? The user name is
> csaba.sipos My old account does not seems to work since the
> restructure of the site. Thanks!

done.  Is there an old account that should be deactivated now? What was
the old user name?

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From sipos.csaba at kvk.uni-obuda.hu  Wed Nov 16 15:20:30 2016
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Wed, 16 Nov 2016 16:20:30 +0100 (CET)
Subject: Nokia crash during init is fixed
In-Reply-To: <20161116151058.mm4g75tjool3vue6@nataraja>
References: <674728593.9364011.1479294985406.JavaMail.zimbra@kvk.uni-obuda.hu>
 <1898973263.9364698.1479295185136.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116115114.ujjn453gjmldqzy7@nataraja>
 <1404507143.9404212.1479300834688.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116151058.mm4g75tjool3vue6@nataraja>
Message-ID: <115638735.9432487.1479309630317.JavaMail.zimbra@kvk.uni-obuda.hu>

Hi Harald,

The old user name is "csaba" you can deactivate it.

The rest, I can understand it. With Andreas fix, there is no apparent errors anymore, so I consider it done, until I got a Nokia BSC :-).

I did some LAPD PCAP traces, my only question is should I be able to see the higher layer messages like call control, or mobility management inside? Maybe I need to manually tell Wireshark what to decode? Our students are measuring this setup and it would be lovely to add some protocol tracing to the task.

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Harald Welte" <laforge at gnumonks.org>
C?mzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
M?solatot kap: "OpenBSC Mailing List" <openbsc at lists.osmocom.org>
Elk?ld?tt ?zenetek: Szerda, 2016. November 16. 16:10:58
T?rgy: Re: Nokia crash during init is fixed

Hi Sipos,

On Wed, Nov 16, 2016 at 01:53:54PM +0100, Sipos Csaba wrote:
> The only outstanding problem is that during SMS sending, the Nokia
> Site familiy does not seems to send the release confirm, after the SMS
> is sent, and it generates a T200 timeout.

If there is no issue in redmine yet, please create one.

> This problem is very similar to the issue Andreas fixed (the same problem seems to happen with handovers too on Nokia Site):
> 
> http://cgit.osmocom.org/openbsc/commit/?id=7d8fa3418ff6c589eba10e562da8b96995e19f7a

ideally the release path is centralized in one place in the code so the
fix would apply to all scenarios.  I'm not sure what's different in the
SMS case, but I also have no time to look into this now, sorry.

> Besides this I have some outstanding patches for Nokia Site specific
> features, like the RSL timer for UltraSite, and the ability to
> configure hopping and hopping type. I managed to do RF and baseband
> hopping on MetroSite, and RF hopping on UltraSite units with it :-)
> Will try and send it to you soon.

It might make sense to keep those patches in a branch on
git.osmocom.org, even if you think they're not yet ready to merge. Just
in case somebody else needs/wants them.

> I also needed to register a new user name on osmocom.org. Can you
> please grant me edit right on the wiki pages? The user name is
> csaba.sipos My old account does not seems to work since the
> restructure of the site. Thanks!

done.  Is there an old account that should be deactivated now? What was
the old user name?

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From holger at freyther.de  Wed Nov 16 15:33:31 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 16 Nov 2016 16:33:31 +0100
Subject: Nokia crash during init is fixed
In-Reply-To: <20161116151058.mm4g75tjool3vue6@nataraja>
References: <674728593.9364011.1479294985406.JavaMail.zimbra@kvk.uni-obuda.hu>
 <1898973263.9364698.1479295185136.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116115114.ujjn453gjmldqzy7@nataraja>
 <1404507143.9404212.1479300834688.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116151058.mm4g75tjool3vue6@nataraja>
Message-ID: <FEC9D932-C866-42C3-B471-4101EBFC4B91@freyther.de>


> On 16 Nov 2016, at 16:10, Harald Welte <laforge at gnumonks.org> wrote:
> 
> 
> ideally the release path is centralized in one place in the code so the
> fix would apply to all scenarios.  I'm not sure what's different in the
> SMS case, but I also have no time to look into this now, sorry.

we make a local-end release of SAPI=3 and deactivate the SACCH. Maybe this is Sipos is referring to.


holger

From laforge at gnumonks.org  Wed Nov 16 15:36:23 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 16 Nov 2016 16:36:23 +0100
Subject: wireshark LAPD tracing (was Re: Nokia crash during init is fixed)
In-Reply-To: <20161116153329.sip4dzedomzxvmbf@nataraja>
References: <674728593.9364011.1479294985406.JavaMail.zimbra@kvk.uni-obuda.hu>
 <1898973263.9364698.1479295185136.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116115114.ujjn453gjmldqzy7@nataraja>
 <1404507143.9404212.1479300834688.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116151058.mm4g75tjool3vue6@nataraja>
 <115638735.9432487.1479309630317.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116153329.sip4dzedomzxvmbf@nataraja>
Message-ID: <20161116153623.sh25yhee3tgiwdpi@nataraja>

Hi Sipos,

On Wed, Nov 16, 2016 at 04:33:29PM +0100, Harald Welte wrote:

> It would be great if you and/or your students could add that kind of
> inforation to the openbsc wiki, 

actually it is documented at
https://osmocom.org/projects/openbsc/wiki/PacketDump

However, I think it might also be useful to have a chapter on protocol
tracing in the OpenBSC manual

> maybe even with some sample pcap files of Nokia BTS startup, or even
> general stuff like LU, SMS, etc.  procedures.

that would still be useful, in case you had some time and/or resources
for that. 

-- 
- Harald Welte <laforge at gnumonks.org>           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 Nov 16 15:33:29 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 16 Nov 2016 16:33:29 +0100
Subject: wireshark LAPD tracing (was Re: Nokia crash during init is fixed)
In-Reply-To: <115638735.9432487.1479309630317.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <674728593.9364011.1479294985406.JavaMail.zimbra@kvk.uni-obuda.hu>
 <1898973263.9364698.1479295185136.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116115114.ujjn453gjmldqzy7@nataraja>
 <1404507143.9404212.1479300834688.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116151058.mm4g75tjool3vue6@nataraja>
 <115638735.9432487.1479309630317.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <20161116153329.sip4dzedomzxvmbf@nataraja>

Hi Sipos,

On Wed, Nov 16, 2016 at 04:20:30PM +0100, Sipos Csaba wrote:
> I did some LAPD PCAP traces, my only question is should I be able to
> see the higher layer messages like call control, or mobility
> management inside? Maybe I need to manually tell Wireshark what to
> decode? Our students are measuring this setup and it would be lovely
> to add some protocol tracing to the task.

You need to use the "Use GSM SAPI values" setting of the LAPD protocol
prrference in Wireshark.  Without that, wireshark is expecting ISDN
(Q.931) messages on top of LAPD.

It would be great if you and/or your students could add that kind of
inforation to the openbsc wiki, maybe even with some sample pcap files
of Nokia BTS startup, or even general stuff like LU, SMS, etc.
procedures.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From sipos.csaba at kvk.uni-obuda.hu  Wed Nov 16 16:26:27 2016
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Wed, 16 Nov 2016 17:26:27 +0100 (CET)
Subject: wireshark LAPD tracing (was Re: Nokia crash during init is fixed)
In-Reply-To: <20161116153623.sh25yhee3tgiwdpi@nataraja>
References: <674728593.9364011.1479294985406.JavaMail.zimbra@kvk.uni-obuda.hu>
 <1898973263.9364698.1479295185136.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116115114.ujjn453gjmldqzy7@nataraja>
 <1404507143.9404212.1479300834688.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116151058.mm4g75tjool3vue6@nataraja>
 <115638735.9432487.1479309630317.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116153329.sip4dzedomzxvmbf@nataraja>
 <20161116153623.sh25yhee3tgiwdpi@nataraja>
Message-ID: <1229743580.9442828.1479313587736.JavaMail.zimbra@kvk.uni-obuda.hu>

Dear Harald,

Thanks for highlighting that. First I will clear up the Nokia Wiki, tomorrow I will try to do some traces of basic procedures (initial attach, detach, LU, MO call, MT call, SMS), and try to create wiki for it.

This will signifficantly improve the value of the lab exercise.

We finally have the 2g BTS measurement license for our R&S CMW 500, so we can do proper validation of the DL signals for both Nokia and Osmo-trx too. We also have a basic license for 3G UE meas, so we can do analysis on 3G femtos as well. Will contact you in private for that.

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Harald Welte" <laforge at gnumonks.org>
C?mzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
M?solatot kap: "OpenBSC Mailing List" <openbsc at lists.osmocom.org>
Elk?ld?tt ?zenetek: Szerda, 2016. November 16. 16:36:23
T?rgy: Re: wireshark LAPD tracing (was Re: Nokia crash during init is fixed)

Hi Sipos,

On Wed, Nov 16, 2016 at 04:33:29PM +0100, Harald Welte wrote:

> It would be great if you and/or your students could add that kind of
> inforation to the openbsc wiki, 

actually it is documented at
https://osmocom.org/projects/openbsc/wiki/PacketDump

However, I think it might also be useful to have a chapter on protocol
tracing in the OpenBSC manual

> maybe even with some sample pcap files of Nokia BTS startup, or even
> general stuff like LU, SMS, etc.  procedures.

that would still be useful, in case you had some time and/or resources
for that. 

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From a.cudbardb at networkradius.com  Fri Nov 11 22:04:00 2016
From: a.cudbardb at networkradius.com (Arran Cudbard-Bell)
Date: Fri, 11 Nov 2016 17:04:00 -0500
Subject: naming contest: gsm_network, gsm_subscriber_connection
In-Reply-To: <20161111115001.GA4864@my.box>
References: <20161111115001.GA4864@my.box>
Message-ID: <DC79A684-0804-415A-9F72-C36F76953A42@networkradius.com>


> On 11 Nov 2016, at 06:50, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> Hi all,
> 
> for a bit of bikeshed fun on the side, I'd like to ask your opinions on a good
> name.
> 
> The background: we're in the process of separating libmsc from libbsc. Both use
> the structs gsm_network and gsm_subscriber_connection, and both of these
> structs contain elements that are used only by libbsc or only by libmsc,
> besides the elements that are used by both. So at some point I will "split"
> both of these in two, to have a BSC and an MSC version thereof.
> 
> How should we name them?
> 
> 
> struct gsm_network
> (note, if there is a common part, that could still be named 'gsm_network')
> 
> --> bsc_network / msc_network
>    looks familiar but the meaning of the name is lost
> 
> --> gsm_bsc / gsm_msc
> 
> --> osmo_bsc / osmo_msc
>    To me these would be the best and the names are still available, but there
>    are header files named like this and the osmo-bsc binary also has a very
>    similar name. I think I would go for these anyway.
>    +1
> 
> --> osmo_gsm_bsc / osmo_gsm_msc
>    As alternative, but the gsm is a bit out of place (particularly in the
>    light of a UMTS MSC).
> 
> 
> struct gsm_subscriber_connection
> 
> --> bsc_subscriber_connection / msc_subscriber_connection
>    but we could use the opportunity to shorten the name
> 
> --> bsc_subscr_conn / msc_subscr_conn
>    I like these best; but add osmo?
>    +1
> 
> --> osmo_bsc_subscr_conn / osmo_msc_subscr_conn
>    almost the old length.
> 
> 
> Happy shedding, "+1" comments and/or opinions welcome


http://wiki.freeradius.org/contributing/coding-standards

Seems pretty similar to what we do.


Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4976 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161111/a7c966ce/attachment.bin>

From dhananjay.cse at gmail.com  Sun Nov 20 13:36:08 2016
From: dhananjay.cse at gmail.com (Dhananjay kumar)
Date: Sun, 20 Nov 2016 19:06:08 +0530
Subject: B210 - 2 chain Configuration issue
Message-ID: <CAM5ro7sskXyGB_+_cpJ4647VNF06Q-QmYs1O-G0bbv4PDootNQ@mail.gmail.com>

Hi,

We are configuring B210 with OSMO-NITB ,OSMO-BTS and OSMO-TRX for 2 chain
configuartion.

BSC Configuation :

bts 0
 trx 0
   rf_locked 0
   arfcn 51
   nominal power 0
   max_power_red 0
   rsl e1 tei 0
    timeslot 0
     phys_chan_config CCCH+SDCCH4
     hopping enabled 0
    timeslot 1
     phys_chan_config PDCH
    timeslot 2
     phys_chan_config PDCH
    timeslot 3
     phys_chan_config PDCH
    timeslot 4
     phys_chan_config PDCH
    timeslot 5
     phys_chan_config PDCH
    timeslot 6
     phys_chan_config TCH/F
    timeslot 7
     phys_chan_config TCH/F
  trx 1
   rf_locked 0
   arfcn 55
   nominal power 0
   max_power_red 0
   rsl e1 tei 0
    timeslot 0
     phys_chan_config CCCH+SDCCH4
    timeslot 1
     phys_chan_config PDCH
    timeslot 2
     phys_chan_config PDCH
    timeslot 3
     phys_chan_config PDCH
    timeslot 4
     phys_chan_config PDCH
    timeslot 5
     phys_chan_config PDCH
    timeslot 6
     phys_chan_config TCH/F
    timeslot 7
     phys_chan_config TCH/F



BTS config  :

trx 0
  phy 0 instance 0
 trx 1
  phy 0 instance 1

*Issue description :*


On TRX 0 all 8 eight brust is seen on simulator , but on TRX1 only 1 brust
is coming up.
when channel is swiped with " - s" [osmo-trx -fc 2 -s ] issue reversed to
TRX0.

Please refer attached screen shot for frame brust.
 we need to both TRX working with identical power level. let me know if
anyone has faced this issue and have solution for this.

BR
Dhananjay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161120/c836d37f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: B210-TRX0.jpg
Type: image/jpeg
Size: 215576 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161120/c836d37f/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: B210-TRX1.jpg
Type: image/jpeg
Size: 234678 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161120/c836d37f/attachment-0001.jpg>

From kristian.martens at ng4t.com  Mon Nov 21 21:19:45 2016
From: kristian.martens at ng4t.com (Kristian Martens)
Date: Mon, 21 Nov 2016 22:19:45 +0100
Subject: Roadmap for OpenBSC
In-Reply-To: <58336157.10309@freenet.de>
References: <58336157.10309@freenet.de>
Message-ID: <583364F1.5080503@ng4t.com>

All,

I have seen that it is planned to implement the full AoIP stack for a
standalone OpenBSC. Do have any idea by when this feature could be ready
to use?

Best regards,
Kris


From laforge at gnumonks.org  Mon Nov 21 23:05:19 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 22 Nov 2016 00:05:19 +0100
Subject: Roadmap for OpenBSC
In-Reply-To: <583364F1.5080503@ng4t.com>
References: <58336157.10309@freenet.de>
 <583364F1.5080503@ng4t.com>
Message-ID: <20161121230519.t5lsdxmvie3shl4l@nataraja>

Hi Kristian,

On Mon, Nov 21, 2016 at 10:19:45PM +0100, Kristian Martens wrote:
> I have seen that it is planned to implement the full AoIP stack for a
> standalone OpenBSC. Do have any idea by when this feature could be ready
> to use?

There are some ideas and abstract plans at this point, yes.  Primarily
right now we are analyzing the steps that need to be taken once/if
somebody decides to commit the required resources to actually
implementing it.  Resources could come either in form of developer
contributions by interetsed parties, or in terms of funding.

So if you have certain requirements or even some idas about how to
achieve 3GPP AoIP compatibility in the OpenBSC code base, by all menas
let us know and discuss it here and/or in the redmine.

I'm sorry I have to say this, but I'm increasingly frustrated by people
(particularly from commercial entities) asking about features, support,
stability, roadmap and the like - but at the same time most of those
companies/entities have no history whatsoever of contributing to the
OpenBSC and related projects.

Please do not take this personally or directed towards your organization
in any way,  I'm just expressing my general dissatisfaction with what I
see as a very "consumer - producer" related attitude by numerous people
who contact us on-list or by private mail.

Free / Open Source Software needs to be developed and maintained like
any other software, and that effort must be shared by at least most
significant benficiaries in some way.  Yet, we currently see something
like 80% of commits comming from a very small group of people at
sysmocom.  This is not healthy for any FOSS project.

We need more contributions from a variety of entities and individuals.
Once upon a time there was a time when there were more diverse
developers / contributors to OpenBSC than now.

Sorry once again for hijacking your request in this way.  I'm trying to
speak to the general audience on this list (and beyond).  Thanks for
your understanding.

So to get back to your original question in temsof 'when it could b
ready'?  Open Source projects are almost always too late in the market.
They start because somebody has a need that he cannot address otherwise.

So it is not investment by a large corporation based on market
prediction trying to build a product at the time the market is expected
to exist.

Rather, it is perpetual catching-up, based on whenever a sufficient
number of developers/contributors commit what is required to get it
done.

So to be honest, I have no idea if and when it will be
implemented.  However, you can be part of the people that define that
time :)

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From kristian.martens at ng4t.com  Tue Nov 22 21:04:31 2016
From: kristian.martens at ng4t.com (Kristian Martens)
Date: Tue, 22 Nov 2016 22:04:31 +0100
Subject: Channel types not accepted for voice call
In-Reply-To: <583364F1.5080503@ng4t.com>
References: <58336157.10309@freenet.de> <583364F1.5080503@ng4t.com>
Message-ID: <5834B2DF.9050304@ng4t.com>

When receiving BSSAP Assignment Request message, the BSC is rejecting
the request with (cause "No radio resources available"). In the log file
a printout states "No supported audio type found" even though most
commonly used channel types are available in the message. How do I need
to configure the BSC to accept certain channel types?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bssap_failure_call_setup2.pcapng
Type: application/octet-stream
Size: 3192 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161122/cd46dbc1/attachment.obj>

From laforge at gnumonks.org  Tue Nov 22 23:55:14 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 23 Nov 2016 00:55:14 +0100
Subject: Channel types not accepted for voice call
In-Reply-To: <5834B2DF.9050304@ng4t.com>
References: <58336157.10309@freenet.de> <583364F1.5080503@ng4t.com>
 <5834B2DF.9050304@ng4t.com>
Message-ID: <20161122235514.73ik47pvuqvfaisw@nataraja>

Hi Kristian,

On Tue, Nov 22, 2016 at 10:04:31PM +0100, Kristian Martens wrote:
> When receiving BSSAP Assignment Request message, the BSC is rejecting
> the request with (cause "No radio resources available"). In the log file
> a printout states "No supported audio type found" even though most
> commonly used channel types are available in the message. How do I need
> to configure the BSC to accept certain channel types?

Please see the "codec-list" vty command, as implemented at
http://git.osmocom.org/openbsc/tree/openbsc/src/osmo-bsc/osmo_bsc_vty.c#n313

something like 'codec-list fr' would create a supported codec list
consisting only of the GSM full-rate version 1 codec.

I hope this helps.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From z.tamosevicius at limemicro.com  Wed Nov 23 07:06:29 2016
From: z.tamosevicius at limemicro.com (z.tamosevicius at limemicro.com)
Date: Wed, 23 Nov 2016 09:06:29 +0200 (EET)
Subject: Osmo-trx Git Access and New Branch Request
In-Reply-To: <CADj1OPDL5T0_O-ZEutCr0wzXNMDut9dJwj_T=9M8WW70Epi3Jg@mail.gmail.com>
References: <CADj1OPBYpDQ5bo1KfezVdMPXU3zzxS+BRu5iCP+TLU=irTyzag@mail.gmail.com> 
 <C74D932B-B14B-40CB-B0FD-BE781CB1A4AE@freyther.de> 
 <CADj1OPBZZ_U8VkmWTE_hSLWCTvAO6C7u-p5=-FVgJyoUGusQBw@mail.gmail.com> 
 <CADj1OPD9HYUVPTzreeEspBt21cTz0L4Nv8_DA6hFZ2gJqShteA@mail.gmail.com> 
 <1479387334.238322260@apps.rackspace.com> 
 <CADj1OPDL5T0_O-ZEutCr0wzXNMDut9dJwj_T=9M8WW70Epi3Jg@mail.gmail.com>
Message-ID: <1479884789.114713573@apps.rackspace.com>

Hello,

  My name is Zydrunas Tamosevicius. I work for Lime on Myriad-RF and would like to ask to have a new "myriadrf" branch set up and access in osmo-trx git repository. We want to be able to work on adding support for Myriad-RF hardware.
  The intention is to have these changes merged into master after we get it working on our branch. Is there any guidelines we have to follow?

  Thank you in advance!

--
Best regards,
Zydrunas Tamosevicius
Senior IC Design Engineer (Digital)
Lime Microsystems
z.tamosevicius at limemicro.com



From rajasekar at vestel.co.in  Wed Nov 23 13:16:09 2016
From: rajasekar at vestel.co.in (Rajasekar R)
Date: Wed, 23 Nov 2016 18:46:09 +0530
Subject: Unable to find Ki value using Pysim Error -Reg
Message-ID: <CAEwq8P+26_ZrV2WbWOWFf49xo_xyFLoAxmKaroqLfezrK6yWyg@mail.gmail.com>

Dear Team,

           I am trying to find out KI Value of Anristu MT8820C Test SIm
Card using Pysim Software.

          I am using Identiv uTrust 2900 R Smart Card Reader and Identiv
SCR35xx USB Smart Card Reader.

          When I put  *./pySim-read.py -p 0 *in the terminal it shows the
following error

*.*
         Please help me to proceed further.
[image: Inline image 1]

Thanks and Regards....
Rajasekar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161123/2853cf37/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 68895 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161123/2853cf37/attachment.png>

From nhofmeyr at sysmocom.de  Wed Nov 23 14:05:28 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 23 Nov 2016 15:05:28 +0100
Subject: Unable to find Ki value using Pysim Error -Reg
In-Reply-To: <CAEwq8P+26_ZrV2WbWOWFf49xo_xyFLoAxmKaroqLfezrK6yWyg@mail.gmail.com>
References: <CAEwq8P+26_ZrV2WbWOWFf49xo_xyFLoAxmKaroqLfezrK6yWyg@mail.gmail.com>
Message-ID: <20161123140528.GA1800@my.box>

Dear Rajasekar,

please do not send actual screen shot images to this mailing list. Instead,
paste the actual text *as text* into your email body.

About your error, try to use the second-last revision of pysim,
e.g. 'git co master^' (the caret '^' goes back one revision).

The last revision seems to break pysim for some sim card types, which is a
known error but hasn't been fixed yet.

~N


-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161123/dd512fd5/attachment.bin>

From kristian.martens at ng4t.com  Wed Nov 23 17:04:48 2016
From: kristian.martens at ng4t.com (Kristian Martens)
Date: Wed, 23 Nov 2016 18:04:48 +0100
Subject: Channel types not accepted for voice call
In-Reply-To: <20161122235514.73ik47pvuqvfaisw@nataraja>
References: <58336157.10309@freenet.de> <583364F1.5080503@ng4t.com>
 <5834B2DF.9050304@ng4t.com> <20161122235514.73ik47pvuqvfaisw@nataraja>
Message-ID: <5835CC30.8020102@ng4t.com>

Hi Harald,

thank you for the prompt answer helping a lot.

Regards,
Kristian

Am 23.11.2016 um 00:55 schrieb Harald Welte:
> Hi Kristian,
>
> On Tue, Nov 22, 2016 at 10:04:31PM +0100, Kristian Martens wrote:
>> When receiving BSSAP Assignment Request message, the BSC is rejecting
>> the request with (cause "No radio resources available"). In the log file
>> a printout states "No supported audio type found" even though most
>> commonly used channel types are available in the message. How do I need
>> to configure the BSC to accept certain channel types?
> Please see the "codec-list" vty command, as implemented at
> http://git.osmocom.org/openbsc/tree/openbsc/src/osmo-bsc/osmo_bsc_vty.c#n313
>
> something like 'codec-list fr' would create a supported codec list
> consisting only of the GSM full-rate version 1 codec.
>
> I hope this helps.
>
> Regards,
> 	Harald

-- 
*Kristian Martens*
Software Engineer

Mobile: +49 160 1024262
Office: +49 30 65218529
/
ng4T GmbH
Siemensdamm 50
13629 Berlin
Germany

www.ng4t.com <http://www.ng4t.com>

/
Berlin-Charlottenburg, HRB 123546
Gesch?ftsf?hrer Dr. Andreas Kallmann



From kristian.martens at ng4t.com  Wed Nov 23 17:13:51 2016
From: kristian.martens at ng4t.com (Kristian Martens)
Date: Wed, 23 Nov 2016 18:13:51 +0100
Subject: MGCP support
Message-ID: <5835CE4F.6010005@ng4t.com>

All,

Does there exist a document describing to which port the callagent (MSC)
has to connect to, how and where the CIC to RTP IP/port mapping table is
defined etc?

Regards,
Kristian

-- 
*Kristian Martens*
Software Engineer

Mobile: +49 160 1024262
Office: +49 30 65218529
/
ng4T GmbH
Siemensdamm 50
13629 Berlin
Germany

www.ng4t.com <http://www.ng4t.com>

/
Berlin-Charlottenburg, HRB 123546
Gesch?ftsf?hrer Dr. Andreas Kallmann

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161123/3fd2fbe8/attachment.htm>

From holger at freyther.de  Wed Nov 23 17:24:22 2016
From: holger at freyther.de (Holger Freyther)
Date: Wed, 23 Nov 2016 18:24:22 +0100
Subject: MGCP support
In-Reply-To: <5835CE4F.6010005@ng4t.com>
References: <5835CE4F.6010005@ng4t.com>
Message-ID: <2233EEF9-A831-4818-A75E-1AFB6C2893D2@freyther.de>


> On 23 Nov 2016, at 18:13, Kristian Martens <kristian.martens at ng4t.com> wrote:
> 
> All,
> 
> Does there exist a document describing to which port the callagent (MSC) has to connect to, how and where the CIC to RTP IP/port mapping table is defined etc?

VTY reference: http://ftp.osmocom.org/docs/latest/osmomgcp-vty-reference.pdf

osmo-bsc and osmo-bsc_mgcp share a secret of the portbase. E.g. have a look at rtp_calculate_port. I think the osmo-bsc VTY option is ip.access rtp-port.

does it clear things up?

	holger

From laforge at gnumonks.org  Thu Nov 24 00:21:04 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 24 Nov 2016 01:21:04 +0100
Subject: Osmo-trx Git Access and New Branch Request
In-Reply-To: <1479884789.114713573@apps.rackspace.com>
References: <CADj1OPBYpDQ5bo1KfezVdMPXU3zzxS+BRu5iCP+TLU=irTyzag@mail.gmail.com>
 <C74D932B-B14B-40CB-B0FD-BE781CB1A4AE@freyther.de>
 <CADj1OPBZZ_U8VkmWTE_hSLWCTvAO6C7u-p5=-FVgJyoUGusQBw@mail.gmail.com>
 <CADj1OPD9HYUVPTzreeEspBt21cTz0L4Nv8_DA6hFZ2gJqShteA@mail.gmail.com>
 <1479387334.238322260@apps.rackspace.com>
 <CADj1OPDL5T0_O-ZEutCr0wzXNMDut9dJwj_T=9M8WW70Epi3Jg@mail.gmail.com>
 <1479884789.114713573@apps.rackspace.com>
Message-ID: <20161124002104.ljtuyk42ziim4yre@nataraja>

Hi Zydrunas,

On Wed, Nov 23, 2016 at 09:06:29AM +0200, z.tamosevicius at limemicro.com wrote:
>   My name is Zydrunas Tamosevicius. I work for Lime on Myriad-RF and

thanks for introducing yourself.

>   would like to ask to have a new "myriadrf" branch set up and access
>   in osmo-trx git repository. We want to be able to work on adding
>   support for Myriad-RF hardware.

Please note that since 2016, many osmocom projects have switched to
using gerrit. osmo-trx is using this, too.

>  The intention is to have these changes merged into master after we
>  get it working on our branch. Is there any guidelines we have to
>  follow?

Please familiarize yourself with the gerrit code reciew tool, with 
the coding standards
(https://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards)
and the wiki page on how we use Gerrit and how to create an account in
it to submit patches:
https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit

The coding style probably doesn't really apply much for osmo-trx, as it
is not a "native" osmocom project but inherited as a fork of the OpenBTS
transceiver code.  So it's best to simply follow the style of the
surrounding code of the file you're woring in.

Please note I'm not involved in osmo-trx development, Tom and
Alexander are the people running the osmo-trx project.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From sipos.csaba at kvk.uni-obuda.hu  Thu Nov 24 09:53:59 2016
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Thu, 24 Nov 2016 10:53:59 +0100 (CET)
Subject: wireshark LAPD tracing (was Re: Nokia crash during init is fixed)
In-Reply-To: <20161116153623.sh25yhee3tgiwdpi@nataraja>
References: <674728593.9364011.1479294985406.JavaMail.zimbra@kvk.uni-obuda.hu>
 <1898973263.9364698.1479295185136.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116115114.ujjn453gjmldqzy7@nataraja>
 <1404507143.9404212.1479300834688.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116151058.mm4g75tjool3vue6@nataraja>
 <115638735.9432487.1479309630317.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116153329.sip4dzedomzxvmbf@nataraja>
 <20161116153623.sh25yhee3tgiwdpi@nataraja>
Message-ID: <1238900409.10606586.1479981239322.JavaMail.zimbra@kvk.uni-obuda.hu>

Dear Harald,

I have the traces so I will try to put the protocol trace wiki together.

I think for now I will expand the "PacketDump" part, and when it has a meaningful length/content, we can move it to a separate wiki page.

What I have in mind is to create some sort comparison like image/visualization, where the OpenBSC log and the corresponding Pcap trace can be seen side by side, so complete procedures (like call setup, SMS, lau and such) can be observed, and to put some explanation what actually happens (where it is not obvious).

Does this suits you?

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Harald Welte" <laforge at gnumonks.org>
C?mzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
M?solatot kap: "OpenBSC Mailing List" <openbsc at lists.osmocom.org>
Elk?ld?tt ?zenetek: Szerda, 2016. November 16. 16:36:23
T?rgy: Re: wireshark LAPD tracing (was Re: Nokia crash during init is fixed)

Hi Sipos,

On Wed, Nov 16, 2016 at 04:33:29PM +0100, Harald Welte wrote:

> It would be great if you and/or your students could add that kind of
> inforation to the openbsc wiki, 

actually it is documented at
https://osmocom.org/projects/openbsc/wiki/PacketDump

However, I think it might also be useful to have a chapter on protocol
tracing in the OpenBSC manual

> maybe even with some sample pcap files of Nokia BTS startup, or even
> general stuff like LU, SMS, etc.  procedures.

that would still be useful, in case you had some time and/or resources
for that. 

-- 
- Harald Welte <laforge at gnumonks.org>           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 Nov 24 20:38:00 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 24 Nov 2016 21:38:00 +0100
Subject: wireshark LAPD tracing (was Re: Nokia crash during init is fixed)
In-Reply-To: <1238900409.10606586.1479981239322.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <674728593.9364011.1479294985406.JavaMail.zimbra@kvk.uni-obuda.hu>
 <1898973263.9364698.1479295185136.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116115114.ujjn453gjmldqzy7@nataraja>
 <1404507143.9404212.1479300834688.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116151058.mm4g75tjool3vue6@nataraja>
 <115638735.9432487.1479309630317.JavaMail.zimbra@kvk.uni-obuda.hu>
 <20161116153329.sip4dzedomzxvmbf@nataraja>
 <20161116153623.sh25yhee3tgiwdpi@nataraja>
 <1238900409.10606586.1479981239322.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <20161124203800.z725hxq2h3tuizo6@nataraja>

Hi Sipos,

On Thu, Nov 24, 2016 at 10:53:59AM +0100, Sipos Csaba wrote:
> I have the traces so I will try to put the protocol trace wiki together.

great, thanks,

> I think for now I will expand the "PacketDump" part, and when it has a
> meaningful length/content, we can move it to a separate wiki page.

sure.

> What I have in mind is to create some sort comparison like
> image/visualization, where the OpenBSC log and the corresponding Pcap
> trace can be seen side by side, so complete procedures (like call
> setup, SMS, lau and such) can be observed, and to put some explanation
> what actually happens (where it is not obvious).

that sounds complicated, but I'm definitely curious to see what yo might
end up doing.

What we had contemplated for many years is to create a "log target" for
libosmocore logging which generates a GSMTAP packet that just contains
logging text. If OpenBSC sends those GSMTAP messages interspersed with
the Abis protocol messages, you could have both the text log and the GSM
protocol messages in one application (wireshark).  Unfortunately, nobody
has yet implemente it.  Maybe that might also be something to look into
for a student project?  It's a small libosmocore extension and an
equally small wireshark extension.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Fri Nov 25 12:03:11 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 25 Nov 2016 13:03:11 +0100
Subject: New Defects reported by Coverity Scan for Osmocom
In-Reply-To: <58374704eb3f3_75e77b531818b2@ss1435.mail>
References: <58374704eb3f3_75e77b531818b2@ss1435.mail>
Message-ID: <20161125120311.GA12444@my.box>

On Thu, Nov 24, 2016 at 12:01:08PM -0800, scan-admin at coverity.com wrote:
> ________________________________________________________________________________________________________
> *** CID 149097:  Null pointer dereferences  (FORWARD_NULL)
> /source-Osmocom/openbsc/openbsc/src/gprs/gprs_sndcp_comp.c: 67 in gprs_sndcp_comp_create()
> 61     		       comp_field->rfc2507_params->nsapi,
> 62     		       sizeof(comp_entity->nsapi));
> 63     	} else if (comp_field->rohc_params) {
> 64     		comp_entity->nsapi_len = comp_field->rohc_params->nsapi_len;
> 65     		memcpy(comp_entity->nsapi, comp_field->rohc_params->nsapi,
> 66     		       sizeof(comp_entity->nsapi));
> >>>     CID 149097:  Null pointer dereferences  (FORWARD_NULL)
> >>>     Comparing "comp_field->v42bis_params" to null implies that "comp_field->v42bis_params" might be null.


The point of this complaint:

- gprs_sndcp_comp.c:67 implies that v42bis_params might be NULL
- on line 104 we call gprs_sndcp_dcomp_init()
- then this function (gprs_sndcp_dcomp.c near 88) dereferences
  comp_field->v42bis_params without checking for NULL (instead relies on
  comp_entity->algo == V42BIS)

I think I'd add an OSMO_ASSERT(comp_field->v42bis_params) in
gprs_sndcp_dcomp_init(). pmaier?

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161125/1ebdbfe4/attachment.bin>

From pmaier at sysmocom.de  Fri Nov 25 14:42:02 2016
From: pmaier at sysmocom.de (Philipp Maier)
Date: Fri, 25 Nov 2016 15:42:02 +0100
Subject: New Defects reported by Coverity Scan for Osmocom
In-Reply-To: <20161125120311.GA12444@my.box>
References: <58374704eb3f3_75e77b531818b2@ss1435.mail>
 <20161125120311.GA12444@my.box>
Message-ID: <58384DBA.2010503@sysmocom.de>

Hallo Neels,

> The point of this complaint:
>
> - gprs_sndcp_comp.c:67 implies that v42bis_params might be NULL
> - on line 104 we call gprs_sndcp_dcomp_init()
> - then this function (gprs_sndcp_dcomp.c near 88) dereferences
>    comp_field->v42bis_params without checking for NULL (instead relies on
>    comp_entity->algo == V42BIS)
>
> I think I'd add an OSMO_ASSERT(comp_field->v42bis_params) in
> gprs_sndcp_dcomp_init(). pmaier?

I am ok with that, but I think this CID is a false alarm anyway. I have 
now added OSMO_ASSERT()s for both gprs_sndcp_dcomp_init() and 
gprs_sndcp_pcomp_init().

See also: https://gerrit.osmocom.org/1279

regards,
Philipp

-- 
Philipp Maier <pmaier at sysmocom.de>              http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte



From nhofmeyr at sysmocom.de  Sat Nov 26 15:04:29 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 26 Nov 2016 16:04:29 +0100
Subject: question on USSD messages
Message-ID: <20161126150429.GA20125@my.box>

Hi all,

I'm looking at USSD message generation in openbsc, and would like to move a
bit of msg generation to libosmocore.

However, in libosmocore's gsm0480.c I already find an implementation that seems
to do the same, yet with some differences I'm not sure how to deal with.

The function originally in openbsc:
  gsm0480_send_releaseComplete()

On the iu branch, I've moved the msg generation to
  gsm0480_gen_releaseComplete()
This should rather go to libosmocore.

There I already find
  gsm0480_create_ussd_resp()

The openbsc variants are rather shorter. Is it incomplete/incorrect?? Is the
libosmocore gsm0480_create_ussd_resp() just bloat for this case??

For convenience, let me paste the code:

openbsc's Release Complete, very lean:

    struct msgb *gsm0480_gen_releaseComplete(void)
    {
            struct msgb *msg;
    
            msg = gsm48_msgb_alloc_name("GSM 04.08 USSD REL COMPL");
            if (!msg)
                    return NULL;
    
            gsm0480_l3hdr_push(msg, GSM48_PDISC_NC_SS,
                               GSM0480_MTYPE_RELEASE_COMPLETE);
            return msg;
    }

Note that the above does not set a direction flag nor trans_id in the
proto_discr, like libosmocore's gsm0480_create_ussd_resp() does; neither do I
understand the purpose of all the constant "code/id" TLs and wrapping:

    struct msgb *gsm0480_create_ussd_resp(uint8_t invoke_id, uint8_t trans_id, const char *text)
    {
            struct msgb *msg;
            uint8_t *ptr8;
            int response_len;
    
            msg = msgb_alloc_headroom(1024, 128, "GSM 04.80");
            if (!msg)
                    return NULL;
    
            /* First put the payload text into the message */
            ptr8 = msgb_put(msg, 0);
            gsm_7bit_encode_n_ussd(ptr8, msgb_tailroom(msg), text, &response_len);
            msgb_put(msg, response_len);
    
            /* Then wrap it as an Octet String */
            msgb_wrap_with_TL(msg, ASN1_OCTET_STRING_TAG);
    
            /* Pre-pend the DCS octet string */
            msgb_push_TLV1(msg, ASN1_OCTET_STRING_TAG, 0x0F);
    
            /* Then wrap these as a Sequence */
            msgb_wrap_with_TL(msg, GSM_0480_SEQUENCE_TAG);
    
            /* Pre-pend the operation code */
            msgb_push_TLV1(msg, GSM0480_OPERATION_CODE,
                            GSM0480_OP_CODE_PROCESS_USS_REQ);
    
            /* Wrap the operation code and IA5 string as a sequence */
            msgb_wrap_with_TL(msg, GSM_0480_SEQUENCE_TAG);
    
            /* Pre-pend the invoke ID */
            msgb_push_TLV1(msg, GSM0480_COMPIDTAG_INVOKE_ID, invoke_id);
    
            /* Wrap this up as a Return Result component */
            msgb_wrap_with_TL(msg, GSM0480_CTYPE_RETURN_RESULT);
    
            /* Wrap the component in a Facility message */
            msgb_wrap_with_TL(msg, GSM0480_IE_FACILITY);
    
            /* And finally pre-pend the L3 header */
            gsm0480_l3hdr_push(msg,
                               GSM48_PDISC_NC_SS | trans_id
                               | (1<<7) /* TI direction = 1 */,
                               GSM0480_MTYPE_RELEASE_COMPLETE);
            return msg;
    }

Thanks for any insights!

~N


-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161126/e8d9168b/attachment.bin>

From cleb at defcon-3.net  Sun Nov 27 08:01:29 2016
From: cleb at defcon-3.net (Caleb Pal)
Date: Sun, 27 Nov 2016 00:01:29 -0800
Subject: RBS 2308 Protocol Error
In-Reply-To: <777b8857-b645-196a-4336-8f5e9ff6c809@defcon-3.net>
References: <777b8857-b645-196a-4336-8f5e9ff6c809@defcon-3.net>
Message-ID: <4e156107-a454-be80-52cf-ffd007f7c5de@defcon-3.net>

Good Evening,

With the recent commits for the OM2000 protocol, I figured it was time
to dust off the RBS2308 and see what would happen. I am using the latest
version of DAHDI, with a TE122P T1 card. All osmocom software was pulled
yesterday and installed successfully on a machine running Debian Stable.

When OpenBSC starts, all appears normal with regards to bringing the BTS
up until the timeslots for the first TRX are being configured. When the
timeslots are configured, a protocol error is given for each. If I
change trx0/ts0 from the default of CCCH+SDCCH4 to CCCH, that timeslot
is successfully brought up, and the BTS transmits. Other configurations
(TCH/F, TCH/F, PDCH, SDCCH8, TCH/F_TCH/H_PDCH) on timeslots 1-7 give the
same protocol error.

I have attached my openbsc.cfg, the output from the OpenBSC console, a
pcap of the failed startup, and my DAHDI configuration. If they do not
come through the list server, they are also available at:
http://cleb.org/RBS/

Thanks,

Caleb


-------------- next part --------------
!
! OpenBSC (0.9.11.308-62d46) configuration saved from vty
!!
password foo
!
line vty
 no login
!
network
 network country code 262
 mobile network code 42
 short name OpenBSC
 long name OpenBSC
 auth policy closed
 location updating reject cause 13
 encryption a5 0
 neci 0
 paging any use tch 0
 rrlp mode none
 mm info 0
 handover 0
 handover window rxlev averaging 10
 handover window rxqual averaging 1
 handover window rxlev neighbor averaging 10
 handover power budget interval 6
 handover power budget hysteresis 3
 handover maximum distance 9999
 timer t3101 10
 timer t3103 0
 timer t3105 0
 timer t3107 0
 timer t3109 4
 timer t3111 0
 timer t3113 60
 timer t3115 0
 timer t3117 0
 timer t3119 0
 timer t3122 0
 timer t3141 0
 subscriber-keep-in-ram 0
 bts 0
  type rbs2000
  band GSM1900
  cell_identity 0
  location_area_code 1
  training_sequence_code 7
  base_station_id_code 63
  ms max power 15
  cell reselection hysteresis 4
  rxlev access min 0
  channel allocator descending
  rach tx integer 9
  rach max transmission 7
  oml e1 line 0 timeslot 1 sub-slot full
  oml e1 tei 62
  neighbor-list mode automatic
  gprs mode none
  is-connection-list add 4 512 12
  is-connection-list add 16 524 12
  is-connection-list add 28 536 12
  is-connection-list add 40 548 12
  trx 0
   rf_locked 0
   arfcn 512
   nominal power 24
   max_power_red 12
   rsl e1 line 0 timeslot 1 sub-slot full
   rsl e1 tei 0
   timeslot 0
    phys_chan_config CCCH+SDCCH4
    hopping enabled 0
    e1 line 0 timeslot 1 sub-slot full
   timeslot 1
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 2 sub-slot 1
   timeslot 2
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 2 sub-slot 2
   timeslot 3
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 2 sub-slot 3
   timeslot 4
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 3 sub-slot 0
   timeslot 5
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 3 sub-slot 1
   timeslot 6
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 3 sub-slot 2
   timeslot 7
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 3 sub-slot 3
  trx 1
   rf_locked 0
   arfcn 514
   nominal power 24
   max_power_red 12
   rsl e1 line 0 timeslot 4 sub-slot full
   rsl e1 tei 1
   timeslot 0
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 5 sub-slot 0
   timeslot 1
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 5 sub-slot 1
   timeslot 2
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 5 sub-slot 2
   timeslot 3
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 5 sub-slot 3
   timeslot 4
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 6 sub-slot 0
   timeslot 5
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 6 sub-slot 1
   timeslot 6
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 6 sub-slot 2
   timeslot 7
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 6 sub-slot 3
  trx 2
   rf_locked 0
   arfcn 516
   nominal power 24
   max_power_red 12
   rsl e1 line 0 timeslot 7 sub-slot full
   rsl e1 tei 2
   timeslot 0
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 8 sub-slot 0
   timeslot 1
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 8 sub-slot 1
   timeslot 2
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 8 sub-slot 2
   timeslot 3
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 8 sub-slot 3
   timeslot 4
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 9 sub-slot 0
   timeslot 5
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 9 sub-slot 1
   timeslot 6
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 9 sub-slot 2
   timeslot 7
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 9 sub-slot 3
  trx 3
   rf_locked 0
   arfcn 518 
   nominal power 24
   max_power_red 12
   rsl e1 line 0 timeslot 10 sub-slot full
   rsl e1 tei 3
   timeslot 0
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 11 sub-slot 0
   timeslot 1
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 11 sub-slot 1
   timeslot 2
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 11 sub-slot 2
   timeslot 3
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 11 sub-slot 3
   timeslot 4
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 12 sub-slot 0
   timeslot 5
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 12 sub-slot 1
   timeslot 6
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 12 sub-slot 2
   timeslot 7
    phys_chan_config TCH/F
    hopping enabled 0
    e1 line 0 timeslot 12 sub-slot 3

e1_input
 e1_line 0 driver dahdi
-------------- next part --------------
root at bsc:~# osmo-nitb -P -C -c /etc/openbsc/openbsc.cfg -l /etc/openbsc/hlr-905.db --debug=DRLL:DCC:DMM:DRR:DRSL:DNM -p /root/rbs2308.pcap
DB: Database initialized.
DB: Database prepared.
<0005> bts_ericsson_rbs2000.c:36 bootstrapping OML for BTS 0
<0005> fsm.c:192 OM2000-BTS(0)[0x946ef20]{INIT}: Allocated
<0005> fsm.c:371 OM2000-BTS(0)[0x946ef20]{INIT}: Received Event START
<0005> fsm.c:328 OM2000-BTS(0)[0x946ef20]{INIT}: state_chg to WAIT-CF
<0005> fsm.c:192 OM2000-MO(0-CF/00/ff/00)[0x9483550]{INIT}: Allocated
<0005> abis_om2000.c:63 OM2000-MO(0-CF/00/ff/00)[0x9483550]{INIT}: is child of OM2000-BTS(0)[0x946ef20]
<0005> fsm.c:371 OM2000-MO(0-CF/00/ff/00)[0x9483550]{INIT}: Received Event START
<0005> fsm.c:328 OM2000-MO(0-CF/00/ff/00)[0x9483550]{INIT}: state_chg to WAIT-START-ACCEPT
<0005> abis_om2000.c:1017 Tx MO=CF/00/ff/00 Start Request
<0005> abis_om2000.c:2613 Rx MO=CF/00/ff/00 Fault Report (80 80 00 3a 00 42 0a 00 ff 00 23 02 00 00 00 00 00 24 00 00 00 00 00 00 25 00 00 00 00 00 00 14 00 00 15 00 00 34 00 00 00 00 00 00 2c 00 2a 00 26 00 00 00 00 00 00 50 00 00 00 00 00 00 )
<0005> abis_om2000.c:2439 Rx MO=CF/00/ff/00 Fault Report, MO State: RESET
<0005> abis_om2000.c:2488 Rx MO=CF/00/ff/00 Fault Report: Internal Fault Map Class 1A (1)
<0005> abis_om2000.c:1017 Tx MO=CF/00/ff/00 Fault Report ACK
<0005> abis_om2000.c:2613 Rx MO=CF/00/ff/00 Start Request Accept (80 80 00 06 00 86 0a 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-CF/00/ff/00)[0x9483550]{WAIT-START-ACCEPT}: Received Event RX-RESET-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0-CF/00/ff/00)[0x9483550]{WAIT-START-ACCEPT}: state_chg to WAIT-START-RES
<0005> abis_om2000.c:2613 Rx MO=CF/00/ff/00 Negotiation Request (80 80 00 25 01 06 0a 00 ff 00 90 1d 02 02 00 47 31 32 52 30 37 47 31 32 52 30 38 02 01 47 30 31 52 31 30 47 30 31 52 31 31 )
<0005> abis_om2000.c:2372       IWD Type 0 Gen G12 Rev R07
<0005> abis_om2000.c:2372       IWD Type 0 Gen G12 Rev R08
<0005> abis_om2000.c:2372       IWD Type 1 Gen G01 Rev R10
<0005> abis_om2000.c:2372       IWD Type 1 Gen G01 Rev R11
<0005> abis_om2000.c:2326 Tx MO=CF/00/ff/00 Negotiation Request ACK
<0005> abis_om2000.c:2613 Rx MO=CF/00/ff/00 Start Result (80 80 00 25 00 8a 0a 00 ff 00 2c 01 48 00 40 45 52 41 47 30 34 52 30 38 56 30 31 43 01 6e 44 01 ff 45 03 ff eb 03 46 01 ff )
<0005> abis_om2000.c:2439 Rx MO=CF/00/ff/00 Start Result, MO State: STARTED
<0005> abis_om2000.c:1017 Tx MO=CF/00/ff/00 Start Result ACK
<0005> fsm.c:371 OM2000-MO(0-CF/00/ff/00)[0x9483550]{WAIT-START-RES}: Received Event RX-START-RESULT
<0005> fsm.c:328 OM2000-MO(0-CF/00/ff/00)[0x9483550]{WAIT-START-RES}: state_chg to WAIT-OPINFO-ACCEPT
<0005> abis_om2000.c:1074 Tx MO=CF/00/ff/00 Operational Information
<0005> abis_om2000.c:2613 Rx MO=CF/00/ff/00 Fault Report (80 80 00 3a 00 42 0a 00 ff 00 23 00 00 00 00 00 00 24 00 00 00 00 00 00 25 00 00 00 00 00 00 14 00 00 15 00 00 34 00 00 00 00 00 00 2c 01 2a 00 26 00 00 00 00 00 00 50 00 00 00 00 00 00 )
<0005> abis_om2000.c:2439 Rx MO=CF/00/ff/00 Fault Report, MO State: STARTED
<0005> abis_om2000.c:2575 Rx MO=CF/00/ff/00 Fault Report: All faults ceased!
<0005> abis_om2000.c:1017 Tx MO=CF/00/ff/00 Fault Report ACK
<0005> abis_om2000.c:2613 Rx MO=CF/00/ff/00 Operational Information Accept (80 80 00 06 00 76 0a 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-CF/00/ff/00)[0x9483550]{WAIT-OPINFO-ACCEPT}: Received Event RX-OPINFO-ACCEPT
<0005> fsm.c:328 OM2000-MO(0-CF/00/ff/00)[0x9483550]{WAIT-OPINFO-ACCEPT}: state_chg to DONE
<0005> fsm.c:411 OM2000-MO(0-CF/00/ff/00)[0x9483550]{DONE}: Terminating (cause = 2)
<0005> fsm.c:426 OM2000-MO(0-CF/00/ff/00)[0x9483550]{DONE}: Release
<0005> fsm.c:236 OM2000-MO(0-CF/00/ff/00)[0x9483550]{DONE}: Deallocated
<0005> fsm.c:371 OM2000-BTS(0)[0x946ef20]{WAIT-CF}: Received Event CF-DONE
<0005> fsm.c:328 OM2000-BTS(0)[0x946ef20]{WAIT-CF}: state_chg to WAIT-IS
<0005> fsm.c:192 OM2000-MO(0-IS/00/ff/00)[0x946b260]{INIT}: Allocated
<0005> abis_om2000.c:63 OM2000-MO(0-IS/00/ff/00)[0x946b260]{INIT}: is child of OM2000-BTS(0)[0x946ef20]
<0005> fsm.c:371 OM2000-MO(0-IS/00/ff/00)[0x946b260]{INIT}: Received Event START
<0005> fsm.c:328 OM2000-MO(0-IS/00/ff/00)[0x946b260]{INIT}: state_chg to WAIT-CONN-COMPL
<0005> abis_om2000.c:1017 Tx MO=IS/00/ff/00 Connect Command
<0005> abis_om2000.c:2613 Rx MO=IS/00/ff/00 Connect Complete (80 80 00 06 00 1e 05 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-CONN-COMPL}: Received Event RX-CONN-COMPL
<0005> fsm.c:328 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-CONN-COMPL}: state_chg to WAIT-RES-COMPL
<0005> abis_om2000.c:1017 Tx MO=IS/00/ff/00 Reset Command
<0005> abis_om2000.c:2613 Rx MO=IS/00/ff/00 Reset Complete (80 80 00 06 00 7a 05 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-RES-COMPL}: Received Event RX-RESET-COMPL
<0005> fsm.c:328 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-RES-COMPL}: state_chg to WAIT-START-ACCEPT
<0005> abis_om2000.c:1017 Tx MO=IS/00/ff/00 Start Request
<0005> abis_om2000.c:2613 Rx MO=IS/00/ff/00 Start Request Accept (80 80 00 06 00 86 05 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-START-ACCEPT}: Received Event RX-RESET-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-START-ACCEPT}: state_chg to WAIT-START-RES
<0005> abis_om2000.c:2613 Rx MO=IS/00/ff/00 Start Result (80 80 00 08 00 8a 05 00 ff 00 2c 03 )
<0005> abis_om2000.c:2439 Rx MO=IS/00/ff/00 Start Result, MO State: DISABLED
<0005> abis_om2000.c:1017 Tx MO=IS/00/ff/00 Start Result ACK
<0005> fsm.c:371 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-START-RES}: Received Event RX-START-RESULT
<0005> fsm.c:328 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-START-RES}: state_chg to WAIT-CFG-ACCEPT
<0005> abis_om2000.c:1131 Tx MO=IS/00/ff/00 IS Configuration Request
<0005> abis_om2000.c:2613 Rx MO=IS/00/ff/00 IS Configuration Request Accept (80 80 00 06 00 62 05 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-CFG-ACCEPT}: Received Event RX-CFG-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-CFG-ACCEPT}: state_chg to WAIT-CFG-RES
<0005> abis_om2000.c:2613 Rx MO=IS/00/ff/00 IS Configuration Result (80 80 00 08 00 66 05 00 ff 00 00 00 )
<0005> abis_om2000.c:1017 Tx MO=IS/00/ff/00 IS Configuration Result ACK
<0005> fsm.c:371 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-CFG-RES}: Received Event RX-CFG-RESULT
<0005> fsm.c:328 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-CFG-RES}: state_chg to WAIT-ENABLE-ACCEPT
<0005> abis_om2000.c:1017 Tx MO=IS/00/ff/00 Enable Request
<0005> abis_om2000.c:2613 Rx MO=CF/00/ff/00 Calendar Time Request (80 80 00 06 00 12 0a 00 ff 00 )
<0005> bts_ericsson_rbs2000.c:49 bootstrapping OML for TRX 0/0
<0005> bts_ericsson_rbs2000.c:49 bootstrapping OML for TRX 0/1
<0005> bts_ericsson_rbs2000.c:49 bootstrapping OML for TRX 0/2
<0005> bts_ericsson_rbs2000.c:49 bootstrapping OML for TRX 0/3
<0005> abis_om2000.c:2613 Rx MO=TRXC/00/ff/00 Fault Report (80 80 00 36 00 42 01 00 ff 00 23 02 00 00 00 00 00 24 00 00 00 00 00 00 25 00 00 00 00 00 00 14 00 00 15 00 00 34 00 00 00 00 00 00 2c 00 2a 00 9c 00 00 00 00 9d 00 00 00 00 )
<0005> abis_om2000.c:2439 Rx MO=TRXC/00/ff/00 Fault Report, MO State: RESET
<0005> abis_om2000.c:2488 Rx MO=TRXC/00/ff/00 Fault Report: Internal Fault Map Class 1A (1)
<0005> abis_om2000.c:1017 Tx MO=TRXC/00/ff/00 Fault Report ACK
<0005> abis_om2000.c:2613 Rx MO=TRXC/00/ff/02 Fault Report (80 80 00 36 00 42 01 00 ff 02 23 02 00 00 00 00 00 24 00 00 00 00 00 00 25 00 00 00 00 00 00 14 00 00 15 00 00 34 00 00 00 00 00 00 2c 00 2a 00 9c 00 00 00 00 9d 00 00 00 00 )
<0005> abis_om2000.c:2439 Rx MO=TRXC/00/ff/02 Fault Report, MO State: RESET
<0005> abis_om2000.c:2488 Rx MO=TRXC/00/ff/02 Fault Report: Internal Fault Map Class 1A (1)
<0005> abis_om2000.c:1017 Tx MO=TRXC/00/ff/02 Fault Report ACK
<0005> abis_om2000.c:2613 Rx MO=TRXC/00/ff/01 Fault Report (80 80 00 36 00 42 01 00 ff 01 23 02 00 00 00 00 00 24 00 00 00 00 00 00 25 00 00 00 00 00 00 14 00 00 15 00 00 34 00 00 00 00 00 00 2c 00 2a 00 9c 00 00 00 00 9d 00 00 00 00 )
<0005> abis_om2000.c:2439 Rx MO=TRXC/00/ff/01 Fault Report, MO State: RESET
<0005> abis_om2000.c:2488 Rx MO=TRXC/00/ff/01 Fault Report: Internal Fault Map Class 1A (1)
<0005> abis_om2000.c:1017 Tx MO=TRXC/00/ff/01 Fault Report ACK
<0005> abis_om2000.c:2613 Rx MO=TRXC/00/ff/03 Fault Report (80 80 00 36 00 42 01 00 ff 03 23 02 00 00 00 00 00 24 00 00 00 00 00 00 25 00 00 00 00 00 00 14 00 00 15 00 00 34 00 00 00 00 00 00 2c 00 2a 00 9c 00 00 00 00 9d 00 00 00 00 )
<0005> abis_om2000.c:2439 Rx MO=TRXC/00/ff/03 Fault Report, MO State: RESET
<0005> abis_om2000.c:2488 Rx MO=TRXC/00/ff/03 Fault Report: Internal Fault Map Class 1A (1)
<0005> abis_om2000.c:1017 Tx MO=TRXC/00/ff/03 Fault Report ACK
<0005> abis_om2000.c:2613 Rx MO=TRXC/00/ff/00 Fault Report (80 80 00 36 00 42 01 00 ff 00 23 00 00 00 00 00 00 24 00 00 00 00 00 00 25 00 00 00 00 00 00 14 00 00 15 00 00 34 00 00 00 00 00 00 2c 00 2a 00 9c 00 00 00 00 9d 00 00 00 00 )
<0005> abis_om2000.c:2439 Rx MO=TRXC/00/ff/00 Fault Report, MO State: RESET
<0005> abis_om2000.c:2575 Rx MO=TRXC/00/ff/00 Fault Report: All faults ceased!
<0005> abis_om2000.c:1017 Tx MO=TRXC/00/ff/00 Fault Report ACK
<0005> abis_om2000.c:2613 Rx MO=TRXC/00/ff/01 Fault Report (80 80 00 36 00 42 01 00 ff 01 23 00 00 00 00 00 00 24 00 00 00 00 00 00 25 00 00 00 00 00 00 14 00 00 15 00 00 34 00 00 00 00 00 00 2c 00 2a 00 9c 00 00 00 00 9d 00 00 00 00 )
<0005> abis_om2000.c:2439 Rx MO=TRXC/00/ff/01 Fault Report, MO State: RESET
<0005> abis_om2000.c:2575 Rx MO=TRXC/00/ff/01 Fault Report: All faults ceased!
<0005> abis_om2000.c:1017 Tx MO=TRXC/00/ff/01 Fault Report ACK
<0005> abis_om2000.c:2613 Rx MO=TRXC/00/ff/02 Fault Report (80 80 00 36 00 42 01 00 ff 02 23 00 00 00 00 00 00 24 00 00 00 00 00 00 25 00 00 00 00 00 00 14 00 00 15 00 00 34 00 00 00 00 00 00 2c 00 2a 00 9c 00 00 00 00 9d 00 00 00 00 )
<0005> abis_om2000.c:2439 Rx MO=TRXC/00/ff/02 Fault Report, MO State: RESET
<0005> abis_om2000.c:2575 Rx MO=TRXC/00/ff/02 Fault Report: All faults ceased!
<0005> abis_om2000.c:1017 Tx MO=TRXC/00/ff/02 Fault Report ACK
<0005> abis_om2000.c:2613 Rx MO=TRXC/00/ff/03 Fault Report (80 80 00 36 00 42 01 00 ff 03 23 00 00 00 00 00 00 24 00 00 00 00 00 00 25 00 00 00 00 00 00 14 00 00 15 00 00 34 00 00 00 00 00 00 2c 00 2a 00 9c 00 00 00 00 9d 00 00 00 00 )
<0005> abis_om2000.c:2439 Rx MO=TRXC/00/ff/03 Fault Report, MO State: RESET
<0005> abis_om2000.c:2575 Rx MO=TRXC/00/ff/03 Fault Report: All faults ceased!
<0005> abis_om2000.c:1017 Tx MO=TRXC/00/ff/03 Fault Report ACK
<0005> abis_om2000.c:2613 Rx MO=IS/00/ff/00 Enable Request Accept (80 80 00 06 00 36 05 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-ENABLE-ACCEPT}: Received Event RX-ENABLE-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-ENABLE-ACCEPT}: state_chg to WAIT-ENABLE-RES
<0005> abis_om2000.c:2613 Rx MO=IS/00/ff/00 Enable Result (80 80 00 08 00 3a 05 00 ff 00 2c 02 )
<0005> abis_om2000.c:2439 Rx MO=IS/00/ff/00 Enable Result, MO State: ENABLED
<0005> abis_om2000.c:1017 Tx MO=IS/00/ff/00 Enable Result ACK
<0005> fsm.c:371 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-ENABLE-RES}: Received Event RX-ENABLE-RESULT
<0005> fsm.c:328 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-ENABLE-RES}: state_chg to WAIT-OPINFO-ACCEPT
<0005> abis_om2000.c:1074 Tx MO=IS/00/ff/00 Operational Information
<0005> abis_om2000.c:2613 Rx MO=IS/00/ff/00 Operational Information Accept (80 80 00 06 00 76 05 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-OPINFO-ACCEPT}: Received Event RX-OPINFO-ACCEPT
<0005> fsm.c:328 OM2000-MO(0-IS/00/ff/00)[0x946b260]{WAIT-OPINFO-ACCEPT}: state_chg to DONE
<0005> fsm.c:411 OM2000-MO(0-IS/00/ff/00)[0x946b260]{DONE}: Terminating (cause = 2)
<0005> fsm.c:426 OM2000-MO(0-IS/00/ff/00)[0x946b260]{DONE}: Release
<0005> fsm.c:236 OM2000-MO(0-IS/00/ff/00)[0x946b260]{DONE}: Deallocated
<0005> fsm.c:371 OM2000-BTS(0)[0x946ef20]{WAIT-IS}: Received Event IS-DONE
<0005> fsm.c:328 OM2000-BTS(0)[0x946ef20]{WAIT-IS}: state_chg to WAIT-CON
<0005> fsm.c:192 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{INIT}: Allocated
<0005> abis_om2000.c:63 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{INIT}: is child of OM2000-BTS(0)[0x946ef20]
<0005> fsm.c:371 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{INIT}: Received Event START
<0005> fsm.c:328 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{INIT}: state_chg to WAIT-CONN-COMPL
<0005> abis_om2000.c:1017 Tx MO=CON/00/ff/00 Connect Command
<0004> bsc_init.c:287 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 512 using MCC=262 MNC=42 LAC=1 CID=0 BSIC=63
<0003> system_information.c:525 Serving cell: 512 514 516 518
<0003> bsc_init.c:104 SI1: 55 06 19 8f 00 2a 00 00 00 00 00 00 00 00 00 00 00 00 00 e5 04 00 6b
<0003> bsc_init.c:104 SI2: 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00
<0003> bsc_init.c:104 SI3: 49 06 1b 00 00 62 f2 24 00 01 49 03 05 27 47 00 e5 04 00 39 2b 2b 2b
<0003> bsc_init.c:104 SI4: 31 06 1c 62 f2 24 00 01 47 00 e5 04 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
<0003> bsc_init.c:104 SI5: 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b 2b
<0003> bsc_init.c:104 SI6: 06 1e 00 00 62 f2 24 00 01 27 ff 3b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
<0004> bsc_init.c:287 bootstrapping RSL for BTS/TRX (0/1) on ARFCN 514 using MCC=262 MNC=42 LAC=1 CID=0 BSIC=63
<0003> bsc_init.c:104 SI5: 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b 2b
<0003> bsc_init.c:104 SI6: 06 1e 00 00 62 f2 24 00 01 27 ff 3b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
<0004> bsc_init.c:287 bootstrapping RSL for BTS/TRX (0/2) on ARFCN 516 using MCC=262 MNC=42 LAC=1 CID=0 BSIC=63
<0003> bsc_init.c:104 SI5: 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b 2b
<0003> bsc_init.c:104 SI6: 06 1e 00 00 62 f2 24 00 01 27 ff 3b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
<0004> bsc_init.c:287 bootstrapping RSL for BTS/TRX (0/3) on ARFCN 518 using MCC=262 MNC=42 LAC=1 CID=0 BSIC=63
<0003> bsc_init.c:104 SI5: 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b 2b
<0003> bsc_init.c:104 SI6: 06 1e 00 00 62 f2 24 00 01 27 ff 3b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
<0005> abis_om2000.c:2613 Rx MO=CON/00/ff/00 Connect Complete (80 80 00 06 00 1e 06 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{WAIT-CONN-COMPL}: Received Event RX-CONN-COMPL
<0005> fsm.c:328 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{WAIT-CONN-COMPL}: state_chg to WAIT-RES-COMPL
<0005> abis_om2000.c:1017 Tx MO=CON/00/ff/00 Reset Command
<0005> abis_om2000.c:2613 Rx MO=CON/00/ff/00 Reset Complete (80 80 00 06 00 7a 06 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{WAIT-RES-COMPL}: Received Event RX-RESET-COMPL
<0005> fsm.c:328 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{WAIT-RES-COMPL}: state_chg to WAIT-START-ACCEPT
<0005> abis_om2000.c:1017 Tx MO=CON/00/ff/00 Start Request
<0004> abis_rsl.c:1597 (bts=0,trx=0) ERROR REPORT CAUSE=0x62(Message Sequence Error)
<0004> abis_rsl.c:1597 (bts=0,trx=0) ERROR REPORT CAUSE=0x62(Message Sequence Error)
<0004> abis_rsl.c:1597 (bts=0,trx=0) ERROR REPORT CAUSE=0x62(Message Sequence Error)
<0004> abis_rsl.c:1597 (bts=0,trx=0) ERROR REPORT CAUSE=0x62(Message Sequence Error)
<0005> abis_om2000.c:2613 Rx MO=CON/00/ff/00 Start Request Accept (80 80 00 06 00 86 06 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{WAIT-START-ACCEPT}: Received Event RX-RESET-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{WAIT-START-ACCEPT}: state_chg to WAIT-START-RES
<0005> abis_om2000.c:2613 Rx MO=CON/00/ff/00 Start Result (80 80 00 08 00 8a 06 00 ff 00 2c 03 )
<0005> abis_om2000.c:2439 Rx MO=CON/00/ff/00 Start Result, MO State: DISABLED
<0005> abis_om2000.c:1017 Tx MO=CON/00/ff/00 Start Result ACK
<0005> fsm.c:371 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{WAIT-START-RES}: Received Event RX-START-RESULT
<0005> fsm.c:328 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{WAIT-START-RES}: state_chg to WAIT-CFG-ACCEPT
<0005> fsm.c:141 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{WAIT-CFG-ACCEPT}: Timeout of T0
<0005> fsm.c:328 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{WAIT-CFG-ACCEPT}: state_chg to ERROR
<0005> fsm.c:411 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{ERROR}: Terminating (cause = 2)
<0005> fsm.c:426 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{ERROR}: Release
<0005> fsm.c:236 OM2000-MO(0-CON/00/ff/00)[0x946ac08]{ERROR}: Deallocated
<0005> fsm.c:371 OM2000-BTS(0)[0x946ef20]{WAIT-CON}: Received Event CON-DONE
<0005> fsm.c:328 OM2000-BTS(0)[0x946ef20]{WAIT-CON}: state_chg to WAIT-TF
<0005> fsm.c:192 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{INIT}: Allocated
<0005> abis_om2000.c:63 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{INIT}: is child of OM2000-BTS(0)[0x946ef20]
<0005> fsm.c:371 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{INIT}: Received Event START
<0005> fsm.c:328 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{INIT}: state_chg to WAIT-CONN-COMPL
<0005> abis_om2000.c:1017 Tx MO=TF/00/ff/00 Connect Command
<0005> abis_om2000.c:2613 Rx MO=TF/00/ff/00 Connect Complete (80 80 00 06 00 1e 04 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-CONN-COMPL}: Received Event RX-CONN-COMPL
<0005> fsm.c:328 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-CONN-COMPL}: state_chg to WAIT-RES-COMPL
<0005> abis_om2000.c:1017 Tx MO=TF/00/ff/00 Reset Command
<0005> abis_om2000.c:2613 Rx MO=TF/00/ff/00 Reset Complete (80 80 00 06 00 7a 04 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-RES-COMPL}: Received Event RX-RESET-COMPL
<0005> fsm.c:328 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-RES-COMPL}: state_chg to WAIT-START-ACCEPT
<0005> abis_om2000.c:1017 Tx MO=TF/00/ff/00 Start Request
<0005> abis_om2000.c:2613 Rx MO=TF/00/ff/00 Start Request Accept (80 80 00 06 00 86 04 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-START-ACCEPT}: Received Event RX-RESET-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-START-ACCEPT}: state_chg to WAIT-START-RES
<0005> abis_om2000.c:2613 Rx MO=TF/00/ff/00 Start Result (80 80 00 08 00 8a 04 00 ff 00 2c 03 )
<0005> abis_om2000.c:2439 Rx MO=TF/00/ff/00 Start Result, MO State: DISABLED
<0005> abis_om2000.c:1017 Tx MO=TF/00/ff/00 Start Result ACK
<0005> fsm.c:371 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-START-RES}: Received Event RX-START-RESULT
<0005> fsm.c:328 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-START-RES}: state_chg to WAIT-CFG-ACCEPT
<0005> abis_om2000.c:1269 Tx MO=TF/00/ff/00 TF Configuration Request
<0005> abis_om2000.c:2613 Rx MO=TF/00/ff/00 TF Configuration Request Accept (80 80 00 06 00 a2 04 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-CFG-ACCEPT}: Received Event RX-CFG-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-CFG-ACCEPT}: state_chg to WAIT-CFG-RES
<0005> abis_om2000.c:2613 Rx MO=TF/00/ff/00 TF Configuration Result (80 80 00 08 00 a6 04 00 ff 00 00 00 )
<0005> abis_om2000.c:1017 Tx MO=TF/00/ff/00 TF Configuration Result ACK
<0005> fsm.c:371 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-CFG-RES}: Received Event RX-CFG-RESULT
<0005> fsm.c:328 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-CFG-RES}: state_chg to WAIT-ENABLE-ACCEPT
<0005> abis_om2000.c:1017 Tx MO=TF/00/ff/00 Enable Request
<0005> abis_om2000.c:2613 Rx MO=TF/00/ff/00 Enable Request Accept (80 80 00 06 00 36 04 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-ENABLE-ACCEPT}: Received Event RX-ENABLE-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-ENABLE-ACCEPT}: state_chg to WAIT-ENABLE-RES
<0005> abis_om2000.c:2613 Rx MO=TF/00/ff/00 Enable Result (80 80 00 08 00 3a 04 00 ff 00 2c 02 )
<0005> abis_om2000.c:2439 Rx MO=TF/00/ff/00 Enable Result, MO State: ENABLED
<0005> abis_om2000.c:1017 Tx MO=TF/00/ff/00 Enable Result ACK
<0005> fsm.c:371 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-ENABLE-RES}: Received Event RX-ENABLE-RESULT
<0005> fsm.c:328 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-ENABLE-RES}: state_chg to WAIT-OPINFO-ACCEPT
<0005> abis_om2000.c:1074 Tx MO=TF/00/ff/00 Operational Information
<0005> abis_om2000.c:2613 Rx MO=TF/00/ff/00 Operational Information Accept (80 80 00 06 00 76 04 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-OPINFO-ACCEPT}: Received Event RX-OPINFO-ACCEPT
<0005> fsm.c:328 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{WAIT-OPINFO-ACCEPT}: state_chg to DONE
<0005> fsm.c:411 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{DONE}: Terminating (cause = 2)
<0005> fsm.c:426 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{DONE}: Release
<0005> fsm.c:236 OM2000-MO(0-TF/00/ff/00)[0x946ac08]{DONE}: Deallocated
<0005> fsm.c:371 OM2000-BTS(0)[0x946ef20]{WAIT-TF}: Received Event TF-DONE
<0005> fsm.c:328 OM2000-BTS(0)[0x946ef20]{WAIT-TF}: state_chg to WAIT-TRX
<0005> fsm.c:192 OM2000-TRX(0/0)[0x946b260]{INIT}: Allocated
<0005> abis_om2000.c:63 OM2000-TRX(0/0)[0x946b260]{INIT}: is child of OM2000-BTS(0)[0x946ef20]
<0005> fsm.c:371 OM2000-TRX(0/0)[0x946b260]{INIT}: Received Event START
<0005> fsm.c:328 OM2000-TRX(0/0)[0x946b260]{INIT}: state_chg to WAIT-TRXC
<0005> fsm.c:192 OM2000-MO(0/0-TRXC/00/ff/00)[0x946ac08]{INIT}: Allocated
<0005> abis_om2000.c:63 OM2000-MO(0/0-TRXC/00/ff/00)[0x946ac08]{INIT}: is child of OM2000-TRX(0/0)[0x946b260]
<0005> fsm.c:371 OM2000-MO(0/0-TRXC/00/ff/00)[0x946ac08]{INIT}: Received Event START
<0005> fsm.c:328 OM2000-MO(0/0-TRXC/00/ff/00)[0x946ac08]{INIT}: state_chg to WAIT-RES-COMPL
<0005> abis_om2000.c:1017 Tx MO=TRXC/00/ff/00 Reset Command
<0005> abis_om2000.c:2613 Rx MO=TRXC/00/ff/00 Reset Complete (80 80 00 06 00 7a 01 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0/0-TRXC/00/ff/00)[0x946ac08]{WAIT-RES-COMPL}: Received Event RX-RESET-COMPL
<0005> fsm.c:328 OM2000-MO(0/0-TRXC/00/ff/00)[0x946ac08]{WAIT-RES-COMPL}: state_chg to WAIT-START-ACCEPT
<0005> abis_om2000.c:1017 Tx MO=TRXC/00/ff/00 Start Request
<0005> abis_om2000.c:2613 Rx MO=TRXC/00/ff/00 Start Request Accept (80 80 00 06 00 86 01 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0/0-TRXC/00/ff/00)[0x946ac08]{WAIT-START-ACCEPT}: Received Event RX-RESET-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0/0-TRXC/00/ff/00)[0x946ac08]{WAIT-START-ACCEPT}: state_chg to WAIT-START-RES
<0005> abis_om2000.c:2613 Rx MO=TRXC/00/ff/00 Start Result (80 80 00 25 00 8a 01 00 ff 00 2c 01 48 00 40 45 52 41 47 30 34 52 30 38 56 30 31 43 01 5e 44 01 ff 45 03 ff eb 03 46 01 ff )
<0005> abis_om2000.c:2439 Rx MO=TRXC/00/ff/00 Start Result, MO State: STARTED
<0005> abis_om2000.c:1017 Tx MO=TRXC/00/ff/00 Start Result ACK
<0005> fsm.c:371 OM2000-MO(0/0-TRXC/00/ff/00)[0x946ac08]{WAIT-START-RES}: Received Event RX-START-RESULT
<0005> fsm.c:328 OM2000-MO(0/0-TRXC/00/ff/00)[0x946ac08]{WAIT-START-RES}: state_chg to WAIT-OPINFO-ACCEPT
<0005> abis_om2000.c:1074 Tx MO=TRXC/00/ff/00 Operational Information
<0005> abis_om2000.c:2613 Rx MO=TRXC/00/ff/00 Operational Information Accept (80 80 00 06 00 76 01 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0/0-TRXC/00/ff/00)[0x946ac08]{WAIT-OPINFO-ACCEPT}: Received Event RX-OPINFO-ACCEPT
<0005> fsm.c:328 OM2000-MO(0/0-TRXC/00/ff/00)[0x946ac08]{WAIT-OPINFO-ACCEPT}: state_chg to DONE
<0005> fsm.c:411 OM2000-MO(0/0-TRXC/00/ff/00)[0x946ac08]{DONE}: Terminating (cause = 2)
<0005> fsm.c:426 OM2000-MO(0/0-TRXC/00/ff/00)[0x946ac08]{DONE}: Release
<0005> fsm.c:236 OM2000-MO(0/0-TRXC/00/ff/00)[0x946ac08]{DONE}: Deallocated
<0005> fsm.c:371 OM2000-TRX(0/0)[0x946b260]{WAIT-TRXC}: Received Event TRXC-DONE
<0005> fsm.c:328 OM2000-TRX(0/0)[0x946b260]{WAIT-TRXC}: state_chg to WAIT-TX
<0005> fsm.c:192 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{INIT}: Allocated
<0005> abis_om2000.c:63 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{INIT}: is child of OM2000-TRX(0/0)[0x946b260]
<0005> fsm.c:371 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{INIT}: Received Event START
<0005> fsm.c:328 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{INIT}: state_chg to WAIT-CONN-COMPL
<0005> abis_om2000.c:1017 Tx MO=TX/00/ff/00 Connect Command
<0005> abis_om2000.c:2613 Rx MO=TX/00/ff/00 Connect Complete (80 80 00 06 00 1e 0b 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{WAIT-CONN-COMPL}: Received Event RX-CONN-COMPL
<0005> fsm.c:328 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{WAIT-CONN-COMPL}: state_chg to WAIT-RES-COMPL
<0005> abis_om2000.c:1017 Tx MO=TX/00/ff/00 Reset Command
<0005> abis_om2000.c:2613 Rx MO=TX/00/ff/00 Reset Complete (80 80 00 06 00 7a 0b 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{WAIT-RES-COMPL}: Received Event RX-RESET-COMPL
<0005> fsm.c:328 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{WAIT-RES-COMPL}: state_chg to WAIT-START-ACCEPT
<0005> abis_om2000.c:1017 Tx MO=TX/00/ff/00 Start Request
<0005> abis_om2000.c:2613 Rx MO=TX/00/ff/00 Start Request Accept (80 80 00 06 00 86 0b 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{WAIT-START-ACCEPT}: Received Event RX-RESET-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{WAIT-START-ACCEPT}: state_chg to WAIT-START-RES
<0005> abis_om2000.c:2613 Rx MO=TX/00/ff/00 Start Result (80 80 00 08 00 8a 0b 00 ff 00 2c 03 )
<0005> abis_om2000.c:2439 Rx MO=TX/00/ff/00 Start Result, MO State: DISABLED
<0005> abis_om2000.c:1017 Tx MO=TX/00/ff/00 Start Result ACK
<0005> fsm.c:371 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{WAIT-START-RES}: Received Event RX-START-RESULT
<0005> fsm.c:328 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{WAIT-START-RES}: state_chg to WAIT-CFG-ACCEPT
<0005> abis_om2000.c:2613 Rx MO=TX/00/ff/00 TX Configuration Request Accept (80 80 00 06 00 b2 0b 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{WAIT-CFG-ACCEPT}: Received Event RX-CFG-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{WAIT-CFG-ACCEPT}: state_chg to WAIT-CFG-RES
<0005> abis_om2000.c:2613 Rx MO=TX/00/ff/00 TX Configuration Result (80 80 00 0c 00 b6 0b 00 ff 00 00 03 7f 00 2f 00 )
<0005> abis_om2000.c:1017 Tx MO=TX/00/ff/00 TX Configuration Result ACK
<0005> fsm.c:371 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{WAIT-CFG-RES}: Received Event RX-CFG-RESULT
<0005> fsm.c:328 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{WAIT-CFG-RES}: state_chg to ERROR
<0005> fsm.c:411 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{ERROR}: Terminating (cause = 2)
<0005> fsm.c:426 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{ERROR}: Release
<0005> fsm.c:236 OM2000-MO(0/0-TX/00/ff/00)[0x946ac08]{ERROR}: Deallocated
<0005> fsm.c:371 OM2000-TRX(0/0)[0x946b260]{WAIT-TX}: Received Event TX-DONE
<0005> fsm.c:328 OM2000-TRX(0/0)[0x946b260]{WAIT-TX}: state_chg to WAIT-RX
<0005> fsm.c:192 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{INIT}: Allocated
<0005> abis_om2000.c:63 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{INIT}: is child of OM2000-TRX(0/0)[0x946b260]
<0005> fsm.c:371 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{INIT}: Received Event START
<0005> fsm.c:328 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{INIT}: state_chg to WAIT-CONN-COMPL
<0005> abis_om2000.c:1017 Tx MO=RX/00/ff/00 Connect Command
<0005> abis_om2000.c:2613 Rx MO=RX/00/ff/00 Connect Complete (80 80 00 06 00 1e 0c 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-CONN-COMPL}: Received Event RX-CONN-COMPL
<0005> fsm.c:328 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-CONN-COMPL}: state_chg to WAIT-RES-COMPL
<0005> abis_om2000.c:1017 Tx MO=RX/00/ff/00 Reset Command
<0005> abis_om2000.c:2613 Rx MO=RX/00/ff/00 Reset Complete (80 80 00 06 00 7a 0c 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-RES-COMPL}: Received Event RX-RESET-COMPL
<0005> fsm.c:328 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-RES-COMPL}: state_chg to WAIT-START-ACCEPT
<0005> abis_om2000.c:1017 Tx MO=RX/00/ff/00 Start Request
<0005> abis_om2000.c:2613 Rx MO=RX/00/ff/00 Start Request Accept (80 80 00 06 00 86 0c 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-START-ACCEPT}: Received Event RX-RESET-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-START-ACCEPT}: state_chg to WAIT-START-RES
<0005> abis_om2000.c:2613 Rx MO=RX/00/ff/00 Start Result (80 80 00 08 00 8a 0c 00 ff 00 2c 03 )
<0005> abis_om2000.c:2439 Rx MO=RX/00/ff/00 Start Result, MO State: DISABLED
<0005> abis_om2000.c:1017 Tx MO=RX/00/ff/00 Start Result ACK
<0005> fsm.c:371 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-START-RES}: Received Event RX-START-RESULT
<0005> fsm.c:328 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-START-RES}: state_chg to WAIT-CFG-ACCEPT
<0005> abis_om2000.c:2613 Rx MO=RX/00/ff/00 RX Configuration Request Accept (80 80 00 06 00 7e 0c 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-CFG-ACCEPT}: Received Event RX-CFG-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-CFG-ACCEPT}: state_chg to WAIT-CFG-RES
<0005> abis_om2000.c:2613 Rx MO=RX/00/ff/00 RX Configuration Result (80 80 00 08 00 82 0c 00 ff 00 00 00 )
<0005> abis_om2000.c:1017 Tx MO=RX/00/ff/00 RX Configuration Result ACK
<0005> fsm.c:371 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-CFG-RES}: Received Event RX-CFG-RESULT
<0005> fsm.c:328 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-CFG-RES}: state_chg to WAIT-ENABLE-ACCEPT
<0005> abis_om2000.c:1017 Tx MO=RX/00/ff/00 Enable Request
<0005> abis_om2000.c:2613 Rx MO=RX/00/ff/00 Enable Request Accept (80 80 00 06 00 36 0c 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-ENABLE-ACCEPT}: Received Event RX-ENABLE-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-ENABLE-ACCEPT}: state_chg to WAIT-ENABLE-RES
<0005> abis_om2000.c:2613 Rx MO=RX/00/ff/00 Enable Result (80 80 00 08 00 3a 0c 00 ff 00 2c 02 )
<0005> abis_om2000.c:2439 Rx MO=RX/00/ff/00 Enable Result, MO State: ENABLED
<0005> abis_om2000.c:1017 Tx MO=RX/00/ff/00 Enable Result ACK
<0005> fsm.c:371 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-ENABLE-RES}: Received Event RX-ENABLE-RESULT
<0005> fsm.c:328 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-ENABLE-RES}: state_chg to WAIT-OPINFO-ACCEPT
<0005> abis_om2000.c:1074 Tx MO=RX/00/ff/00 Operational Information
<0005> abis_om2000.c:2613 Rx MO=RX/00/ff/00 Operational Information Accept (80 80 00 06 00 76 0c 00 ff 00 )
<0005> fsm.c:371 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-OPINFO-ACCEPT}: Received Event RX-OPINFO-ACCEPT
<0005> fsm.c:328 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{WAIT-OPINFO-ACCEPT}: state_chg to DONE
<0005> fsm.c:411 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{DONE}: Terminating (cause = 2)
<0005> fsm.c:426 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{DONE}: Release
<0005> fsm.c:236 OM2000-MO(0/0-RX/00/ff/00)[0x946ac08]{DONE}: Deallocated
<0005> fsm.c:371 OM2000-TRX(0/0)[0x946b260]{WAIT-RX}: Received Event RX-DONE
<0005> fsm.c:328 OM2000-TRX(0/0)[0x946b260]{WAIT-RX}: state_chg to WAIT-TS
<0005> fsm.c:192 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{INIT}: Allocated
<0005> abis_om2000.c:63 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{INIT}: is child of OM2000-TRX(0/0)[0x946b260]
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{INIT}: Received Event START
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{INIT}: state_chg to WAIT-CONN-COMPL
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/00 Connect Command
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/00 Connect Complete (80 80 00 06 00 1e 03 00 00 00 )
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{WAIT-CONN-COMPL}: Received Event RX-CONN-COMPL
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{WAIT-CONN-COMPL}: state_chg to WAIT-RES-COMPL
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/00 Reset Command
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/00 Reset Complete (80 80 00 06 00 7a 03 00 00 00 )
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{WAIT-RES-COMPL}: Received Event RX-RESET-COMPL
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{WAIT-RES-COMPL}: state_chg to WAIT-START-ACCEPT
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/00 Start Request
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/00 Start Request Accept (80 80 00 06 00 86 03 00 00 00 )
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{WAIT-START-ACCEPT}: Received Event RX-RESET-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{WAIT-START-ACCEPT}: state_chg to WAIT-START-RES
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/00 Start Result (80 80 00 08 00 8a 03 00 00 00 2c 03 )
<0005> abis_om2000.c:2439 Rx MO=TS/00/00/00 Start Result, MO State: DISABLED
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/00 Start Result ACK
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{WAIT-START-RES}: Received Event RX-START-RESULT
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{WAIT-START-RES}: state_chg to WAIT-CFG-ACCEPT
<0005> abis_om2000.c:1432 Tx MO=TS/00/00/00 TS Configuration Request
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/00 TS Configuration Request Reject (80 80 00 0a 00 ab 03 00 00 00 32 00 35 06 )
<0005> abis_om2000.c:2412 Rx MO=TS/00/00/00 TS Configuration Request Reject, Reason 0x00, Result Protocol error
<0005> fsm.c:141 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{WAIT-CFG-ACCEPT}: Timeout of T0
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{WAIT-CFG-ACCEPT}: state_chg to ERROR
<0005> fsm.c:411 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{ERROR}: Terminating (cause = 2)
<0005> fsm.c:426 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{ERROR}: Release
<0005> fsm.c:236 OM2000-MO(0/0-TS/00/00/00)[0x946ac08]{ERROR}: Deallocated
<0005> fsm.c:371 OM2000-TRX(0/0)[0x946b260]{WAIT-TS}: Received Event TS-DONE
<0005> fsm.c:192 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{INIT}: Allocated
<0005> abis_om2000.c:63 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{INIT}: is child of OM2000-TRX(0/0)[0x946b260]
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{INIT}: Received Event START
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{INIT}: state_chg to WAIT-CONN-COMPL
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/01 Connect Command
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/01 Connect Complete (80 80 00 06 00 1e 03 00 00 01 )
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{WAIT-CONN-COMPL}: Received Event RX-CONN-COMPL
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{WAIT-CONN-COMPL}: state_chg to WAIT-RES-COMPL
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/01 Reset Command
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/01 Reset Complete (80 80 00 06 00 7a 03 00 00 01 )
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{WAIT-RES-COMPL}: Received Event RX-RESET-COMPL
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{WAIT-RES-COMPL}: state_chg to WAIT-START-ACCEPT
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/01 Start Request
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/01 Start Request Accept (80 80 00 06 00 86 03 00 00 01 )
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{WAIT-START-ACCEPT}: Received Event RX-RESET-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{WAIT-START-ACCEPT}: state_chg to WAIT-START-RES
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/01 Start Result (80 80 00 08 00 8a 03 00 00 01 2c 03 )
<0005> abis_om2000.c:2439 Rx MO=TS/00/00/01 Start Result, MO State: DISABLED
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/01 Start Result ACK
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{WAIT-START-RES}: Received Event RX-START-RESULT
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{WAIT-START-RES}: state_chg to WAIT-CFG-ACCEPT
<0005> abis_om2000.c:1432 Tx MO=TS/00/00/01 TS Configuration Request
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/01 TS Configuration Request Reject (80 80 00 0a 00 ab 03 00 00 01 32 00 35 06 )
<0005> abis_om2000.c:2412 Rx MO=TS/00/00/01 TS Configuration Request Reject, Reason 0x00, Result Protocol error
<0005> fsm.c:141 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{WAIT-CFG-ACCEPT}: Timeout of T0
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{WAIT-CFG-ACCEPT}: state_chg to ERROR
<0005> fsm.c:411 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{ERROR}: Terminating (cause = 2)
<0005> fsm.c:426 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{ERROR}: Release
<0005> fsm.c:236 OM2000-MO(0/0-TS/00/00/01)[0x946ac08]{ERROR}: Deallocated
<0005> fsm.c:371 OM2000-TRX(0/0)[0x946b260]{WAIT-TS}: Received Event TS-DONE
<0005> fsm.c:192 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{INIT}: Allocated
<0005> abis_om2000.c:63 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{INIT}: is child of OM2000-TRX(0/0)[0x946b260]
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{INIT}: Received Event START
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{INIT}: state_chg to WAIT-CONN-COMPL
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/02 Connect Command
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/02 Connect Complete (80 80 00 06 00 1e 03 00 00 02 )
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{WAIT-CONN-COMPL}: Received Event RX-CONN-COMPL
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{WAIT-CONN-COMPL}: state_chg to WAIT-RES-COMPL
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/02 Reset Command
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/02 Reset Complete (80 80 00 06 00 7a 03 00 00 02 )
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{WAIT-RES-COMPL}: Received Event RX-RESET-COMPL
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{WAIT-RES-COMPL}: state_chg to WAIT-START-ACCEPT
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/02 Start Request
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/02 Start Request Accept (80 80 00 06 00 86 03 00 00 02 )
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{WAIT-START-ACCEPT}: Received Event RX-RESET-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{WAIT-START-ACCEPT}: state_chg to WAIT-START-RES
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/02 Start Result (80 80 00 08 00 8a 03 00 00 02 2c 03 )
<0005> abis_om2000.c:2439 Rx MO=TS/00/00/02 Start Result, MO State: DISABLED
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/02 Start Result ACK
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{WAIT-START-RES}: Received Event RX-START-RESULT
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{WAIT-START-RES}: state_chg to WAIT-CFG-ACCEPT
<0005> abis_om2000.c:1432 Tx MO=TS/00/00/02 TS Configuration Request
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/02 TS Configuration Request Reject (80 80 00 0a 00 ab 03 00 00 02 32 00 35 06 )
<0005> abis_om2000.c:2412 Rx MO=TS/00/00/02 TS Configuration Request Reject, Reason 0x00, Result Protocol error
<0005> fsm.c:141 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{WAIT-CFG-ACCEPT}: Timeout of T0
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{WAIT-CFG-ACCEPT}: state_chg to ERROR
<0005> fsm.c:411 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{ERROR}: Terminating (cause = 2)
<0005> fsm.c:426 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{ERROR}: Release
<0005> fsm.c:236 OM2000-MO(0/0-TS/00/00/02)[0x946ac08]{ERROR}: Deallocated
<0005> fsm.c:371 OM2000-TRX(0/0)[0x946b260]{WAIT-TS}: Received Event TS-DONE
<0005> fsm.c:192 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{INIT}: Allocated
<0005> abis_om2000.c:63 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{INIT}: is child of OM2000-TRX(0/0)[0x946b260]
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{INIT}: Received Event START
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{INIT}: state_chg to WAIT-CONN-COMPL
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/03 Connect Command
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/03 Connect Complete (80 80 00 06 00 1e 03 00 00 03 )
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{WAIT-CONN-COMPL}: Received Event RX-CONN-COMPL
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{WAIT-CONN-COMPL}: state_chg to WAIT-RES-COMPL
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/03 Reset Command
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/03 Reset Complete (80 80 00 06 00 7a 03 00 00 03 )
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{WAIT-RES-COMPL}: Received Event RX-RESET-COMPL
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{WAIT-RES-COMPL}: state_chg to WAIT-START-ACCEPT
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/03 Start Request
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/03 Start Request Accept (80 80 00 06 00 86 03 00 00 03 )
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{WAIT-START-ACCEPT}: Received Event RX-RESET-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{WAIT-START-ACCEPT}: state_chg to WAIT-START-RES
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/03 Start Result (80 80 00 08 00 8a 03 00 00 03 2c 03 )
<0005> abis_om2000.c:2439 Rx MO=TS/00/00/03 Start Result, MO State: DISABLED
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/03 Start Result ACK
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{WAIT-START-RES}: Received Event RX-START-RESULT
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{WAIT-START-RES}: state_chg to WAIT-CFG-ACCEPT
<0005> abis_om2000.c:1432 Tx MO=TS/00/00/03 TS Configuration Request
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/03 TS Configuration Request Reject (80 80 00 0a 00 ab 03 00 00 03 32 00 35 06 )
<0005> abis_om2000.c:2412 Rx MO=TS/00/00/03 TS Configuration Request Reject, Reason 0x00, Result Protocol error
<0005> fsm.c:141 OM2000-BTS(0)[0x946ef20]{WAIT-TRX}: Timeout of T0
<0005> fsm.c:328 OM2000-BTS(0)[0x946ef20]{WAIT-TRX}: state_chg to ERROR
<0005> fsm.c:141 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{WAIT-CFG-ACCEPT}: Timeout of T0
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{WAIT-CFG-ACCEPT}: state_chg to ERROR
<0005> fsm.c:411 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{ERROR}: Terminating (cause = 2)
<0005> fsm.c:426 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{ERROR}: Release
<0005> fsm.c:236 OM2000-MO(0/0-TS/00/00/03)[0x946ac08]{ERROR}: Deallocated
<0005> fsm.c:371 OM2000-TRX(0/0)[0x946b260]{WAIT-TS}: Received Event TS-DONE
<0005> fsm.c:192 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{INIT}: Allocated
<0005> abis_om2000.c:63 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{INIT}: is child of OM2000-TRX(0/0)[0x946b260]
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{INIT}: Received Event START
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{INIT}: state_chg to WAIT-CONN-COMPL
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/04 Connect Command
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/04 Connect Complete (80 80 00 06 00 1e 03 00 00 04 )
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{WAIT-CONN-COMPL}: Received Event RX-CONN-COMPL
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{WAIT-CONN-COMPL}: state_chg to WAIT-RES-COMPL
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/04 Reset Command
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/04 Reset Complete (80 80 00 06 00 7a 03 00 00 04 )
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{WAIT-RES-COMPL}: Received Event RX-RESET-COMPL
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{WAIT-RES-COMPL}: state_chg to WAIT-START-ACCEPT
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/04 Start Request
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/04 Start Request Accept (80 80 00 06 00 86 03 00 00 04 )
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{WAIT-START-ACCEPT}: Received Event RX-RESET-REQ-ACCEPT
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{WAIT-START-ACCEPT}: state_chg to WAIT-START-RES
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/04 Start Result (80 80 00 08 00 8a 03 00 00 04 2c 03 )
<0005> abis_om2000.c:2439 Rx MO=TS/00/00/04 Start Result, MO State: DISABLED
<0005> abis_om2000.c:1017 Tx MO=TS/00/00/04 Start Result ACK
<0005> fsm.c:371 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{WAIT-START-RES}: Received Event RX-START-RESULT
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{WAIT-START-RES}: state_chg to WAIT-CFG-ACCEPT
<0005> abis_om2000.c:1432 Tx MO=TS/00/00/04 TS Configuration Request
<0005> abis_om2000.c:2613 Rx MO=TS/00/00/04 TS Configuration Request Reject (80 80 00 0a 00 ab 03 00 00 04 32 00 35 06 )
<0005> abis_om2000.c:2412 Rx MO=TS/00/00/04 TS Configuration Request Reject, Reason 0x00, Result Protocol error
<0005> fsm.c:141 OM2000-TRX(0/0)[0x946b260]{WAIT-TS}: Timeout of T0
<0005> fsm.c:328 OM2000-TRX(0/0)[0x946b260]{WAIT-TS}: state_chg to ERROR
<0005> fsm.c:141 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{WAIT-CFG-ACCEPT}: Timeout of T0
<0005> fsm.c:328 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{WAIT-CFG-ACCEPT}: state_chg to ERROR
<0005> fsm.c:411 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{ERROR}: Terminating (cause = 2)
<0005> fsm.c:426 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{ERROR}: Release
<0005> fsm.c:236 OM2000-MO(0/0-TS/00/00/04)[0x946ac08]{ERROR}: Deallocated
<0005> fsm.c:371 OM2000-TRX(0/0)[0x946b260]{ERROR}: Received Event TS-DONE
<0005> fsm.c:382 OM2000-TRX(0/0)[0x946b260](ERROR): Event TS-DONE not permitted
^Csignal 2 received
<0005> bsc_init.c:91 shutting down OML for BTS 0
root at bsc:~#
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rbs2308.pcap
Type: application/octet-stream
Size: 33619 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161127/b18dfcfb/attachment.obj>
-------------- next part --------------
#
# DAHDI Configuration File
#
# Span Configuration
# 
# span=<span num>,<timing source>,<line build out (LBO)>,<framing>,<coding>[,yellow]
#
# framing:: 
#   one of 'd4' or 'esf' for T1 or 'cas' or 'ccs' for E1. Use 'ccs' for BRI.
#  'd4' could be referred to as 'sf' or 'superframe'
#
# coding:: 
#   one of 'ami' or 'b8zs' for T1 or 'ami' or 'hdb3' for E1. Use 'ami' for
#   BRI.
#
# T1 to Ericsson RBS
span=1,0,0,esf,b8zs
bchan=2,3,5,6,8,9, 11-24
dchan=1,4,7,10
#
#
# unused:: 
#   No signalling is performed, each channel in the list remains idle
# clear::
#   Channel(s) are bundled into a single span.  No conversion or
#   signalling is performed, and raw data is available on the master.
# bchan:: 
#   Like 'clear' except all channels are treated individually and
#   are not bundled.  'inclear' is an alias for this.
# rawhdlc::
#   The DAHDI driver performs HDLC encoding and decoding on the 
#   bundle, and the resulting data is communicated via the master
#   device.
# dchan::
#   The DAHDI driver performs HDLC encoding and decoding on the
#   bundle and also performs incoming and outgoing FCS insertion
#   and verification.  'fcshdlc' is an alias for this. 
# hardhdlc::
#   The hardware driver performs HDLC encoding and decoding on the
#   bundle and also performs incoming and outgoing FCS insertion
#   and verification.  Is subject to limitations and support of underlying
#   hardware. BRI spans serviced by the wcb4xxp driver must use hardhdlc
#   channels for the signalling channels. 
# nethdlc::
#   The DAHDI driver bundles the channels together into an
#   hdlc network device, which in turn can be configured with
#   sethdlc (available separately). In 2.6.x kernels you can also optionally
#   pass the name for the network interface after the channel list.
#   Syntax:
#   
#
loadzone = us
defaultzone=us
#

From lxhmingjun at 163.com  Sun Nov 27 08:04:10 2016
From: lxhmingjun at 163.com (=?GBK?B?uqvD9779?=)
Date: Sun, 27 Nov 2016 16:04:10 +0800 (CST)
Subject: Any one who can help me ,can't find a branch or tag which may
 compile success.!! thank u.
Message-ID: <349c324.2828.158a4d01805.Coremail.lxhmingjun@163.com>

hello everyone ,first thanks for yours look at this email ...


i work under ubuntu 14.04 and with the doc of http://osmocom.org/projects/openbsc/wiki/Building_OpenBSC


now  i only can do make install and success with git version of on-waves/0.3 ?openbsc? and success found the executable file 


drwxr-xr-x  2 root root    4096 11? 27 15:42 ./
drwxr-xr-x 11 root root    4096 11? 13 21:46 ../
-rwxr-xr-x  1 root root  551571 11? 27 15:42 bs11_config*
-rwxr-xr-x  1 root root 1877782 11? 27 15:42 bsc_hack*
-rwxr-xr-x  1 root root  528464 11? 27 15:42 bsc_mgcp*
-rwxr-xr-x  1 root root 1547559 11? 27 15:42 bsc_msc_ip*
-rwxr-xr-x  1 root root  967960 11? 27 15:42 bsc_nat*
-rwxr-xr-x  1 root root 1359089 11? 27 15:42 ipaccess-config*
-rwxr-xr-x  1 root root   37451 11? 27 15:42 ipaccess-find*
-rwxr-xr-x  1 root root   25066 11? 27 15:42 isdnsync*




but as the README under openbsc this version don't work well with ip based BTS

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161127/dc618312/attachment.htm>

From laforge at gnumonks.org  Sun Nov 27 09:23:59 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 27 Nov 2016 10:23:59 +0100
Subject: Any one who can help me ,can't find a branch or tag which may
 compile success.!! thank u.
In-Reply-To: <349c324.2828.158a4d01805.Coremail.lxhmingjun@163.com>
References: <349c324.2828.158a4d01805.Coremail.lxhmingjun@163.com>
Message-ID: <20161127092359.hz6ofj6mrsjnirep@nataraja>

Hi!

On Sun, Nov 27, 2016 at 04:04:10PM +0800, ??? wrote:
> hello everyone ,first thanks for yours look at this email ...[face58]

Please explain in detail what is your use case / application.  What kind
of BTSs do you want to use, etc.

> i work under ubuntu 14.04 and with the doc of http://osmocom.org/projects/
> openbsc/wiki/Building_OpenBSC
> 
> now  i only can do make install and success with git version of on-waves/0.3 ?
> openbsc? and success found the executable file 

Why are you trying to build an old version?  The latest master should
generally be the version to use.

Also, why are you building from source and not just using the nightly
debian packages?  If you just want to use the software and not
develop/modify it, using the nightly package feed is easiest.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           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 Nov 28 07:37:33 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 28 Nov 2016 08:37:33 +0100
Subject: Any one who can help me ,can't find a branch or tag which
 may compile success.!! thank u.
In-Reply-To: <3da81733.763.158a83472b3.Coremail.lxhmingjun@163.com>
References: <349c324.2828.158a4d01805.Coremail.lxhmingjun@163.com>
 <20161127092359.hz6ofj6mrsjnirep@nataraja>
 <3da81733.763.158a83472b3.Coremail.lxhmingjun@163.com>
Message-ID: <20161128073733.yi77xkjtspn3xgch@nataraja>

pleaes always make sure you send your responses to the mailing list,
never by private mail to individual developer s only

On Mon, Nov 28, 2016 at 07:52:39AM +0800, ??? wrote:
> when i use  the newest version of git tag 3G_2016_09 for compile I got lots of
> make error(???`) so switch to the old version 

if you want anyone to help you, you need to include the exact error
messages (copy+paste) in your message to the mailing list.

> Anad another question is where may I found the nightly package,and download the *.deb file

It is really very simple. Go to osmocom.org and search for 'nigthly'.
Then you will find the link to
http://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds

-- 
- Harald Welte <laforge at gnumonks.org>           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 Nov 28 07:45:29 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 28 Nov 2016 08:45:29 +0100
Subject: osmo-trx debian nightly builds fail due to uhd requirement
Message-ID: <20161128074529.7o2lp74dbt4lomwv@nataraja>

Dear all,

as osmo-trx has recently introduced a dependency on a super-recent
version of UHD (as opposed to what regular stable distributions ship),
the nightly debian builds are broken for both Debian 8.0 and Ubuntu
14.04:
https://build.opensuse.org/package/show/network:osmocom:nightly/osmo-trx

I would like to ask the osmo-trx folks to consider
a) adding the uhd version dependencly to the debian rules
b) submitting a suitable uhd package version that can be build in the
   osmoco nightly OBS repository

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Mon Nov 28 12:32:36 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 28 Nov 2016 13:32:36 +0100
Subject: confused by libosmo-netif
Message-ID: <20161128123236.GA2050@my.box>

By random, I looked at an fd leak complained about by coverity in
osmo_stream_srv_fd_cb() and came up with https://gerrit.osmocom.org/1320

Now I wanted to at least run it once to make sure I didn't break anything, but
I'm unsure in figuring out how it is used.

There are two Iu related callers: osmo-iuh's hnbgw.c and libosmo-sccp's sua.c.

And I find libosmo-netif/src/channel/abis/ipa_stream_server.c, called in
libosmo-netif/src/channel.c by osmo_chan_init() and osmo_chan_create(). But it
seems no-one is ever calling these, except for examples in libosmo-netif.

Am I right to conclude that there's some 2G / Abis / ip.access related code in
libosmo-netif but we're not actually using it in openbsc, and that the only
"real" osmo_stream_srv_* callers are 3G/Iu related?

~N

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161128/52df4870/attachment.bin>

From laforge at gnumonks.org  Mon Nov 28 19:31:12 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 28 Nov 2016 20:31:12 +0100
Subject: confused by libosmo-netif
In-Reply-To: <20161128123236.GA2050@my.box>
References: <20161128123236.GA2050@my.box>
Message-ID: <20161128193112.p74eoguied5ok2w3@nataraja>

Hi Neels,

On Mon, Nov 28, 2016 at 01:32:36PM +0100, Neels Hofmeyr wrote:

> Am I right to conclude that there's some 2G / Abis / ip.access related code in
> libosmo-netif but we're not actually using it in openbsc, and that the only
> "real" osmo_stream_srv_* callers are 3G/Iu related?

Yes, at least likely. The history is as follows:

* we implemented openbsc with classic Abis over LAPD/E1
* we added IPA Abis/IP to it
* that code went into libosmo-abis
* Pablo was tasked with the OSMUX implementation for a more efficient
  transport protocol
* Pablo wrote libosmo-netif as a sort of unification layer on top of IP
  and OSMUX
* We started to use osmux in osmo-bsc (and bsc-nat?) for the A interface
* We kept using libosmo-netif only for OSMUX but never migrated the
  other code over to it

It might not be an exact historical record, but I guess you'd have to
ask Pablo for more details

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From tom at tsou.cc  Tue Nov 29 05:32:41 2016
From: tom at tsou.cc (Tom Tsou)
Date: Mon, 28 Nov 2016 21:32:41 -0800
Subject: osmo-trx debian nightly builds fail due to uhd requirement
In-Reply-To: <20161128074529.7o2lp74dbt4lomwv@nataraja>
References: <20161128074529.7o2lp74dbt4lomwv@nataraja>
Message-ID: <CAATyM+ZRjBV3CkvY9eaBetRSGm+uXzGP9SMv-+mYPK6tmTY+Lw@mail.gmail.com>

Hi Harald,

On Sun, Nov 27, 2016 at 11:45 PM, Harald Welte <laforge at gnumonks.org> wrote:
> as osmo-trx has recently introduced a dependency on a super-recent
> version of UHD (as opposed to what regular stable distributions ship),
> the nightly debian builds are broken for both Debian 8.0 and Ubuntu
> 14.04:
> https://build.opensuse.org/package/show/network:osmocom:nightly/osmo-trx

I bumped the UHD version dependency to 3.9.x because older versions of
UHD are no longer maintained and osmo-trx was already dependent on
3.9.x for certain functionality (mainly multi-trx and improved
timing). Build-time version checks were also causing user confusion.

I understand the unwanted effects and dislike the idea of forcing
users to move to more recent versions, however, Ettus Research does
not recommend building against the shipping 3.5 and 3.7 UHD versions
in Ubuntu 14.04 and Debian 8.0 respectively.

> b) submitting a suitable uhd package version that can be build in the
>    osmoco nightly OBS repository

Recommended UHD versions are found in Debian 8.0 Backports and Ubuntu
14.04 Ettus Research PPA.

  https://packages.debian.org/jessie-backports/libuhd-dev
  https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd-3.9.lts

  -TT


From laforge at gnumonks.org  Tue Nov 29 11:46:19 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 29 Nov 2016 12:46:19 +0100
Subject: osmo-trx debian nightly builds fail due to uhd requirement
In-Reply-To: <CAATyM+ZRjBV3CkvY9eaBetRSGm+uXzGP9SMv-+mYPK6tmTY+Lw@mail.gmail.com>
References: <20161128074529.7o2lp74dbt4lomwv@nataraja>
 <CAATyM+ZRjBV3CkvY9eaBetRSGm+uXzGP9SMv-+mYPK6tmTY+Lw@mail.gmail.com>
Message-ID: <20161129114619.rvyjvjwbobdaugtu@nataraja>

Hi Tom,

On Mon, Nov 28, 2016 at 09:32:41PM -0800, Tom Tsou wrote:
> Hi Harald,
> 
> On Sun, Nov 27, 2016 at 11:45 PM, Harald Welte <laforge at gnumonks.org> wrote:
> > as osmo-trx has recently introduced a dependency on a super-recent
> > version of UHD (as opposed to what regular stable distributions ship),
> > the nightly debian builds are broken for both Debian 8.0 and Ubuntu
> > 14.04:
> > https://build.opensuse.org/package/show/network:osmocom:nightly/osmo-trx
> 
> I bumped the UHD version dependency to 3.9.x because older versions of
> UHD are no longer maintained and osmo-trx was already dependent on
> 3.9.x for certain functionality (mainly multi-trx and improved
> timing). Build-time version checks were also causing user confusion.

It is sad that Ettus depreicates those versions that are shipped by the
major stable distributions.  This means that anyone basing their
projects or products on stable versions of those major distributions /
OS vendors will run into trouble.  I consider that quite questionable,
but it is of course not my call and there's nothing we can do about it.

> I understand the unwanted effects and dislike the idea of forcing
> users to move to more recent versions, however, Ettus Research does
> not recommend building against the shipping 3.5 and 3.7 UHD versions
> in Ubuntu 14.04 and Debian 8.0 respectively.

That's Ettus' decision.  However, when you introduce a dependency into
osmo-trx which breaks our official nightly package builds, I would argue
it is also your responsibility to resolved that in some way, or at least
to provide a solution to that problem :)

> Recommended UHD versions are found in Debian 8.0 Backports and Ubuntu
> 14.04 Ettus Research PPA.
> 
>   https://packages.debian.org/jessie-backports/libuhd-dev
>   https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd-3.9.lts

Do you know how to add that dependency on external binary package repos
to OBS?  Or do we have to re-build the soruce packages as part of the
OBS build?  Would you be taking care of this if we provide you with the
respective privileges on the osmocom OBS build?

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From rp.labs at gmx.ch  Tue Nov 29 19:43:58 2016
From: rp.labs at gmx.ch (Labs)
Date: Tue, 29 Nov 2016 20:43:58 +0100
Subject: RBS 2308 Protocol Error
In-Reply-To: <4e156107-a454-be80-52cf-ffd007f7c5de@defcon-3.net>
References: <777b8857-b645-196a-4336-8f5e9ff6c809@defcon-3.net>
 <4e156107-a454-be80-52cf-ffd007f7c5de@defcon-3.net>
Message-ID: <015be423-883f-be92-59d9-341354c90435@gmx.ch>

Hello Caleb,


On 11/27/16 9:01 AM, Caleb Pal wrote:
> Good Evening,
>
> With the recent commits for the OM2000 protocol, I figured it was time
> to dust off the RBS2308 and see what would happen. I am using the latest
> version of DAHDI, with a TE122P T1 card. All osmocom software was pulled
> yesterday and installed successfully on a machine running Debian Stable.
Maybe you want to try to switch you DAHDI config from T1 to E1 first
since you use the BSC config with E1.
T1 uses 24 channels and E1 uses 32 channels.

Second thing is that from what I saw on the wiki and on the Harald's
blog posts the Ericsson RBS units never worked fully and there is still
work to be done. Would be helpful if you have some traces on Abis from a
real Ericsson BSC to see what is going on there.

Regards,
R.



From nhofmeyr at sysmocom.de  Tue Nov 29 20:56:18 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 29 Nov 2016 21:56:18 +0100
Subject: osmo-trx debian nightly builds fail due to uhd requirement
In-Reply-To: <CAATyM+ZRjBV3CkvY9eaBetRSGm+uXzGP9SMv-+mYPK6tmTY+Lw@mail.gmail.com>
References: <20161128074529.7o2lp74dbt4lomwv@nataraja>
 <CAATyM+ZRjBV3CkvY9eaBetRSGm+uXzGP9SMv-+mYPK6tmTY+Lw@mail.gmail.com>
Message-ID: <20161129205618.GB1911@my.box>

On Mon, Nov 28, 2016 at 09:32:41PM -0800, Tom Tsou wrote:
>   https://packages.debian.org/jessie-backports/libuhd-dev

For the record, using jessie-backports I successfully installed a recent UHD on
a Debian-jessie based build server and built osmo-trx master.

Helpful: https://backports.debian.org/Instructions/
In short:
Add to /etc/apt/sources.list:
  deb http://ftp.de.debian.org/debian jessie-backports main
Then:
  apt-get update
  apt-get -t jessie-backports install libuhd-dev

It would of course be even nicer if UHD 3.9 were in the "normal" jessie
packages, but this is the next most convenient way.

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161129/fdfc19f6/attachment.bin>

From tom at tsou.cc  Tue Nov 29 23:08:00 2016
From: tom at tsou.cc (Tom Tsou)
Date: Tue, 29 Nov 2016 15:08:00 -0800
Subject: osmo-trx debian nightly builds fail due to uhd requirement
In-Reply-To: <20161129114619.rvyjvjwbobdaugtu@nataraja>
References: <20161128074529.7o2lp74dbt4lomwv@nataraja>
 <CAATyM+ZRjBV3CkvY9eaBetRSGm+uXzGP9SMv-+mYPK6tmTY+Lw@mail.gmail.com>
 <20161129114619.rvyjvjwbobdaugtu@nataraja>
Message-ID: <CAATyM+bgv_cNvJJzwgLPnM4CN6NP--4-Opkmc4P8_3Lj3KCkAQ@mail.gmail.com>

On Tue, Nov 29, 2016 at 3:46 AM, Harald Welte <laforge at gnumonks.org> wrote:
> That's Ettus' decision.  However, when you introduce a dependency into
> osmo-trx which breaks our official nightly package builds, I would argue
> it is also your responsibility to resolved that in some way, or at least
> to provide a solution to that problem :)

Yes, I accept responsibility for underestimating the downstream
effects of the version change on stable package builds. I do believe
increasing the UHD version requirement is the best choice for users
given the stated direction of Ettus version support.

>> Recommended UHD versions are found in Debian 8.0 Backports and Ubuntu
>> 14.04 Ettus Research PPA.
>>
>>   https://packages.debian.org/jessie-backports/libuhd-dev
>>   https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd-3.9.lts
>
> Do you know how to add that dependency on external binary package repos
> to OBS?  Or do we have to re-build the soruce packages as part of the
> OBS build?  Would you be taking care of this if we provide you with the
> respective privileges on the osmocom OBS build?

Adding the backports repository should be sufficient for Debain
builds. I'm not familiar with the details of the OBS. Given access,
though, I can figure out the dependency settings if there is nobody
else is in a better position to do so.

  -TT


From nhofmeyr at sysmocom.de  Tue Nov 29 23:27:31 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 30 Nov 2016 00:27:31 +0100
Subject: osmo-trx debian nightly builds fail due to uhd requirement
In-Reply-To: <CAATyM+bgv_cNvJJzwgLPnM4CN6NP--4-Opkmc4P8_3Lj3KCkAQ@mail.gmail.com>
References: <20161128074529.7o2lp74dbt4lomwv@nataraja>
 <CAATyM+ZRjBV3CkvY9eaBetRSGm+uXzGP9SMv-+mYPK6tmTY+Lw@mail.gmail.com>
 <20161129114619.rvyjvjwbobdaugtu@nataraja>
 <CAATyM+bgv_cNvJJzwgLPnM4CN6NP--4-Opkmc4P8_3Lj3KCkAQ@mail.gmail.com>
Message-ID: <20161129232731.GE1911@my.box>

On Tue, Nov 29, 2016 at 03:08:00PM -0800, Tom Tsou wrote:
> Adding the backports repository should be sufficient for Debain
> builds. I'm not familiar with the details of the OBS. Given access,
> though, I can figure out the dependency settings if there is nobody
> else is in a better position to do so.

Well, I would do it, but it's all new to me and I have a pile of tasks this
high, way beyond late... so personally, I would highly appreciate if I could
pass it on to you.

The first step would be to create an account on https://build.opensuse.org/ and
communicate your user name to Holger, so that you can be added to the
osmocom-nightly project. From there on, Holger would be your guide, I assume.

Thanks!

~N

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161130/ee4f6e01/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Nov 30 00:51:25 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 30 Nov 2016 01:51:25 +0100
Subject: osmo-trx debian nightly builds fail due to uhd requirement
In-Reply-To: <20161129232731.GE1911@my.box>
References: <20161128074529.7o2lp74dbt4lomwv@nataraja>
 <CAATyM+ZRjBV3CkvY9eaBetRSGm+uXzGP9SMv-+mYPK6tmTY+Lw@mail.gmail.com>
 <20161129114619.rvyjvjwbobdaugtu@nataraja>
 <CAATyM+bgv_cNvJJzwgLPnM4CN6NP--4-Opkmc4P8_3Lj3KCkAQ@mail.gmail.com>
 <20161129232731.GE1911@my.box>
Message-ID: <20161130005124.GF1911@my.box>

On Wed, Nov 30, 2016 at 12:27:31AM +0100, Neels Hofmeyr wrote:
> The first step would be to create an account on https://build.opensuse.org/ and

loosely related: https://gerrit.osmocom.org/1348
"debian: fix: add pcuif_proto.h to osmo-pcu.install"

should fix the osmocom-nightly failure for osmo-pcu.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161130/00d1f022/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Nov 30 03:14:19 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 30 Nov 2016 04:14:19 +0100
Subject: TbfTest fails sanitizer build, please take a look @tbf-folks
Message-ID: <20161130031419.GA9871@my.box>

Dear authors of Tbf,

can you make sense of this build failure?
https://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/373/console

It shows that the expected stderr output of the TbfTest deviates,
and the test exits prematurely.

interesting output:

+tbf_dl.cpp:766:65: runtime error: load of value 32767, which is not a valid value for type 'egprs_puncturing_values'

-- got ack for BSN=1258
-- got ack for BSN=1259
-- got ack for BSN=1260
+- got NACK for BSN=1258
+- got NACK for BSN=1259
+- got NACK for BSN=1260

To help reproducing it, find below the jenkins script that runs this sanitizer
build.

Thanks for any patches that could fix our sanitizer build!

~Neels



#!/bin/sh

set -ex

export BUILDDIR=$PWD/build/
export PKG_CONFIG_PATH=$BUILDDIR/lib/pkgconfig
export LD_LIBRARY_PATH=$BUILDDIR/lib/
export PATH="$PATH:$HOME/osmo-ci/scripts"

build() {
        RET=$PWD
	git clone git://git.osmocom.org/$1 source/$1
	cd source/$1
        git checkout -b build-branch origin/$2
        cd $3
	autoreconf --install --force
	./configure --prefix=$BUILDDIR $4
	make check CFLAGS+="-fsanitize=address -fsanitize=undefined" CXXFLAGS+="-fsanitize=address -fsanitize=undefined" ASAN_OPTIONS="detect_leaks=0" UBSAN_OPTIONS="print_stacktrace=1:halt_on_error=1" \
      || cat-testlogs.sh
	make install CFLAGS+="-fsanitize=address -fsanitize=undefined" CXXFLAGS+="-fsanitize=address -fsanitize=undefined"
	cd $RET
}

rm -rf $BUILDDIR
rm -rf source
mkdir -p source
mkdir -p $BUILDDIR/include/sysmocom/femtobts

git clone git://git.sysmocom.de/sysmo-bts/layer1-api.git source/layer1-api/
cp source/layer1-api/include/* $BUILDDIR/include/sysmocom/femtobts/

build libosmocore $LIBOSMOCORE_BRANCH ./
build libosmo-abis $LIBOSMOABIS_BRANCH ./
build libosmo-netif $LIBOSMONETIF_BRANCH ./
build libosmo-sccp $LIBOSMOSCCP_BRANCH ./
# gcc ice's
#build libsmpp34 $LIBSMPP_BRANCH
build openggsn $OPENGGSN_BRANCH ./
build openbsc $OPENBSC_BRANCH ./openbsc "--enable-nat --enable-osmo-bsc --enable-vty-tests --enable-external-tests"
build osmo-pcu $OSMOPCU_BRANCH ./ "--enable-sysmocom-dsp --enable-vty-tests"
build osmo-bts $OSMOBTS_BRANCH ./ "--enable-sysmocom-bts --enable-trx"


-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161130/eaacae3b/attachment.bin>