From holger at freyther.de  Wed Apr  3 11:12:33 2013
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed, 3 Apr 2013 13:12:33 +0200
Subject: Osmocom Berlin User Group meeting
In-Reply-To: <515750ED.4020007@gmx.de>
References: <502d01a9.mirider@mirider.augusta.de>
	<20120818115942.GV29525@prithivi.gnumonks.org>
	<515750ED.4020007@gmx.de>
Message-ID: <20130403111233.GA17475@xiaoyu.lan>

On Sat, Mar 30, 2013 at 09:54:05PM +0100, dexter wrote:

Hi all,

> 
>     Apr 03, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin

as our conference is starting tomorrow, I will not be able to join
tonight and I think the same applies to LaF0rge. So in case you
still want to attend tonight and do not want to stand in front of
a locked door, please check with someone having a key.

thanks
	holger



From peter at stuge.se  Wed Apr  3 13:50:58 2013
From: peter at stuge.se (Peter Stuge)
Date: Wed, 3 Apr 2013 15:50:58 +0200
Subject: Osmocom Berlin User Group meeting
In-Reply-To: <20130403111233.GA17475@xiaoyu.lan>
References: <502d01a9.mirider@mirider.augusta.de>
	<20120818115942.GV29525@prithivi.gnumonks.org>
	<515750ED.4020007@gmx.de> <20130403111233.GA17475@xiaoyu.lan>
Message-ID: <20130403135058.9829.qmail@stuge.se>

Holger Hans Peter Freyther wrote:
> >     Apr 03, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin
> 
> please check with someone having a key.

I'll be there.


//Peter



From zero-kelvin at gmx.de  Wed Apr  3 15:34:50 2013
From: zero-kelvin at gmx.de (dexter)
Date: Wed, 03 Apr 2013 17:34:50 +0200
Subject: Osmocom Berlin User Group meeting
In-Reply-To: <20130403135058.9829.qmail@stuge.se>
References: <502d01a9.mirider@mirider.augusta.de>
	<20120818115942.GV29525@prithivi.gnumonks.org>
	<515750ED.4020007@gmx.de> <20130403111233.GA17475@xiaoyu.lan>
	<20130403135058.9829.qmail@stuge.se>
Message-ID: <515C4C1A.5080207@gmx.de>

Hi Folks.

I will be there too.

regards.
Philipp



From zero-kelvin at gmx.de  Mon Apr 15 13:51:34 2013
From: zero-kelvin at gmx.de (dexter)
Date: Mon, 15 Apr 2013 15:51:34 +0200
Subject: Osmocom Berlin User Group meeting
In-Reply-To: <20120818115942.GV29525@prithivi.gnumonks.org>
References: <502d01a9.mirider@mirider.augusta.de>
	<20120818115942.GV29525@prithivi.gnumonks.org>
Message-ID: <516C05E6.7060800@gmx.de>

Hi folks.

       This is the announcement for the next Osmocom Berlin meeting.

     Apr 17, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin

There is no formal presentation scheduled for this meeting.

If you are interested to show up, feel free to do so.  There is no
registration required.  The meeting is free as in "free beer", despite
no actual free beer being around.

Regards,
Philipp Maier





From andreas at eversberg.eu  Tue Apr  9 12:14:58 2013
From: andreas at eversberg.eu (jolly)
Date: Tue, 09 Apr 2013 14:14:58 +0200
Subject: Network From Scratch documentation
Message-ID: <51640642.70902@eversberg.eu>

hi,

i just updated the transceiver/osmo-bts/openbsc/lcr documentation:
http://openbsc.osmocom.org/trac/wiki/network_from_scratch
the changes refer to some issues during UmTRX/Osmo-BTS workshop.
especially it describes how to setup/run a network with and without LCR.

regards,

andreas




From alexander.chemeris at gmail.com  Tue Apr  9 12:56:14 2013
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Tue, 9 Apr 2013 16:56:14 +0400
Subject: Network From Scratch documentation
In-Reply-To: <51640642.70902@eversberg.eu>
References: <51640642.70902@eversberg.eu>
Message-ID: <CABmJbFV2+nyewnejjuVfWhBES697LPK9q9gjAusdqSsMimykpw@mail.gmail.com>

Andreas,

On Tue, Apr 9, 2013 at 4:14 PM, jolly <andreas at eversberg.eu> wrote:
> i just updated the transceiver/osmo-bts/openbsc/lcr documentation:
> http://openbsc.osmocom.org/trac/wiki/network_from_scratch
> the changes refer to some issues during UmTRX/Osmo-BTS workshop.
> especially it describes how to setup/run a network with and without LCR.

Looks better now.

One comment I have - Transceiver build instructions are somehow
located in "Running" section and there are no actual instructions
about running a transceiver.

--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru



From peter at stuge.se  Thu Apr 11 04:52:28 2013
From: peter at stuge.se (Peter Stuge)
Date: Thu, 11 Apr 2013 06:52:28 +0200
Subject: Network From Scratch documentation
In-Reply-To: <CABmJbFV2+nyewnejjuVfWhBES697LPK9q9gjAusdqSsMimykpw@mail.gmail.com>
References: <51640642.70902@eversberg.eu>
	<CABmJbFV2+nyewnejjuVfWhBES697LPK9q9gjAusdqSsMimykpw@mail.gmail.com>
Message-ID: <20130411045228.2826.qmail@stuge.se>

Alexander Chemeris wrote:
> One comment I have

Just fix it?


//Peter



From philipp.maier at runningserver.com  Tue Apr  9 20:55:04 2013
From: philipp.maier at runningserver.com (Philipp Fabian Benedikt Maier)
Date: Tue, 09 Apr 2013 22:55:04 +0200
Subject: Question about ms max power parameter.
Message-ID: <51648028.2060807@runningserver.com>

Hi Folks.

I have a simple and straight forward question:

in the openbsc.cfg i find a parameter "ms max power" which is set to 15 
dBm (apporox 30mW) by default.

http://openbsc.osmocom.org/trac/wiki/osmo-nitb_VTY says the following: 
"maximum transmit power (in dBm) to be used by MS in this BTS. This is 
used in the System Information on the BCCH as well as for the MS power 
level at the time a dedicated channel is activated."

My question is how low may i set ms max power level? Is 15dBm already 
the lowest possible minimum or can i set it down to 1dBm if i like?

regards
Philipp






From zero-kelvin at gmx.de  Tue Apr  9 20:57:38 2013
From: zero-kelvin at gmx.de (dexter)
Date: Tue, 09 Apr 2013 22:57:38 +0200
Subject: Question about ms max power parameter.
Message-ID: <516480C2.3060206@gmx.de>

Hi Folks.

I have a simple and straight forward question:

in the openbsc.cfg i find a parameter "ms max power" which is set to 15 
dBm (apporox 30mW) by default.

http://openbsc.osmocom.org/trac/wiki/osmo-nitb_VTY says the following: 
"maximum transmit power (in dBm) to be used by MS in this BTS. This is 
used in the System Information on the BCCH as well as for the MS power 
level at the time a dedicated channel is activated."

My question is how low may i set ms max power level? Is 15dBm already 
the lowest possible minimum or can i set it down to 1dBm if i like?

regards
Philipp






From alexander.huemer at xx.vu  Tue Apr  9 21:54:32 2013
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Tue, 9 Apr 2013 23:54:32 +0200
Subject: Question about ms max power parameter.
In-Reply-To: <516480C2.3060206@gmx.de>
References: <516480C2.3060206@gmx.de>
Message-ID: <20130409215432.GA24141@yade.xx.vu>

Hi,

On Tue, Apr 09, 2013 at 10:57:38PM +0200, dexter wrote:
> in the openbsc.cfg i find a parameter "ms max power" which is set to
> 15 dBm (apporox 30mW) by default.
> 
> http://openbsc.osmocom.org/trac/wiki/osmo-nitb_VTY says the
> following: "maximum transmit power (in dBm) to be used by MS in this
> BTS. This is used in the System Information on the BCCH as well as
> for the MS power level at the time a dedicated channel is
> activated."
> 
> My question is how low may i set ms max power level? Is 15dBm
> already the lowest possible minimum or can i set it down to 1dBm if
> i like?

I'd say it's 0..40.

Kind regards,
-Alexander Huemer

[?] http://openbsc.osmocom.org/trac/wiki/osmo-nitb_VTY#msmaxpower0-40
[?] http://cgit.osmocom.org/openbsc/tree/openbsc/src/libbsc/bsc_vty.c#n1934



From alexander.huemer at xx.vu  Tue Apr  9 22:12:10 2013
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Wed, 10 Apr 2013 00:12:10 +0200
Subject: Question about ms max power parameter.
In-Reply-To: <516480C2.3060206@gmx.de>
References: <516480C2.3060206@gmx.de>
Message-ID: <20130409221210.GB24141@yade.xx.vu>

On Tue, Apr 09, 2013 at 10:57:38PM +0200, dexter wrote:
> in the openbsc.cfg i find a parameter "ms max power" which is set to
> 15 dBm (apporox 30mW) by default.
> 
> http://openbsc.osmocom.org/trac/wiki/osmo-nitb_VTY says the
> following: "maximum transmit power (in dBm) to be used by MS in this
> BTS. This is used in the System Information on the BCCH as well as
> for the MS power level at the time a dedicated channel is
> activated."
> 
> My question is how low may i set ms max power level? Is 15dBm
> already the lowest possible minimum or can i set it down to 1dBm if
> i like?

I just looked it up.
GSM 05.05 speaks of values 0..39dBm, although the underlying thing is 
the 'Power control level', MS_TXPWR_MAX_CCH, which has a range of 0..31.  
This is also mentioned in GSM 05.08. I also found [1].

Kind regards,
-Alexander Huemer

[1] http://gsm-optimization.blogspot.com/2012/04/mstxpwrmaxcch.html



From andreas at eversberg.eu  Wed Apr 10 20:20:25 2013
From: andreas at eversberg.eu (Andreas Eversberg)
Date: Wed, 10 Apr 2013 22:20:25 +0200
Subject: Question about ms max power parameter.
In-Reply-To: <516480C2.3060206@gmx.de>
References: <516480C2.3060206@gmx.de>
Message-ID: <5165C989.6010601@eversberg.eu>

dexter wrote:
>
>
> My question is how low may i set ms max power level? Is 15dBm already 
> the lowest possible minimum or can i set it down to 1dBm if i like?
>
hi,

set ms max power to 0 to get 1 milliwatts to start with (rach and 
initial power). set it to 30 to get 1 watts (1800) or 33 to get 2 watts 
(900). during dedicated channel, it is up to the bts to change the power 
level up or down, depending on the uplink level/quality.

regards,

andreas




From risky at mail.ru  Wed Apr 10 21:13:39 2013
From: risky at mail.ru (Sergey V. Efimov)
Date: Thu, 11 Apr 2013 01:13:39 +0400
Subject: Question about ms max power parameter.
In-Reply-To: <5165C989.6010601@eversberg.eu>
References: <516480C2.3060206@gmx.de> <5165C989.6010601@eversberg.eu>
Message-ID: <95C4957C-2771-4A60-93E3-F2A87D78C173@mail.ru>

Hello Andreas,

Does this setting has linear dependence? Or is there something like a calibration table for max_power_red value?

Thanks,
Sergey.

On Apr 11, 2013, at 12:20 AM, Andreas Eversberg wrote:

> dexter wrote:
>> 
>> 
>> My question is how low may i set ms max power level? Is 15dBm already the lowest possible minimum or can i set it down to 1dBm if i like?
>> 
> hi,
> 
> set ms max power to 0 to get 1 milliwatts to start with (rach and initial power). set it to 30 to get 1 watts (1800) or 33 to get 2 watts (900). during dedicated channel, it is up to the bts to change the power level up or down, depending on the uplink level/quality.
> 
> regards,
> 
> andreas
> 
> 
> 




From zero-kelvin at gmx.de  Thu Apr 11 18:57:56 2013
From: zero-kelvin at gmx.de (dexter)
Date: Thu, 11 Apr 2013 20:57:56 +0200
Subject: Question about ms max power parameter.
In-Reply-To: <95C4957C-2771-4A60-93E3-F2A87D78C173@mail.ru>
References: <516480C2.3060206@gmx.de> <5165C989.6010601@eversberg.eu>
	<95C4957C-2771-4A60-93E3-F2A87D78C173@mail.ru>
Message-ID: <516707B4.2020205@gmx.de>

Hi Sergey
> Does this setting has linear dependence? Or is there something like a calibration table for max_power_red value?
I think i can answer this (please correct my if i am wrong). To my 
understanding "nominal power" is the maximum power the BTS is capable to 
transmit. In the case of the nanoBTS it is 23dBm which is about 200mW. 
So the "nominal power" is the calibration value you asked for.

The "max_power_red" value is the setting for the actual output power. In 
my case it has been set to 20dBm. This should result in an output power 
of 23dBm-20dBm=3dBm=ca. 2mW. This is the default setting. I do not know 
if it is the lowest possible setting. I transmit into a dummyload anyway 
which results into a cell radius of approx 1m.

The dBm scale is not linear, just look it up yourself It's easy ;-)

regards.
Philipp



From laforge at gnumonks.org  Thu Apr 11 20:55:21 2013
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 11 Apr 2013 22:55:21 +0200
Subject: Question about ms max power parameter.
In-Reply-To: <95C4957C-2771-4A60-93E3-F2A87D78C173@mail.ru>
References: <516480C2.3060206@gmx.de> <5165C989.6010601@eversberg.eu>
	<95C4957C-2771-4A60-93E3-F2A87D78C173@mail.ru>
Message-ID: <20130411205521.GF32100@prithivi.gnumonks.org>

Dear Sergey,

On Thu, Apr 11, 2013 at 01:13:39AM +0400, Sergey V. Efimov wrote:
> Does this setting has linear dependence? Or is there something like a
> calibration table for max_power_red value?

dB values are never linear, they're logarithmic.  dBm is vs. Power.

The value is the absolute tranmission power of the MS (uplink) in dBm.
It has nothing to do with max_power_red, whcih is about the relative
reduction of downlink transmit power respective to the nominal transmit
power of the BTS in downlink.

The values are all specified in the relevant GSM specs.

-- 
- 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 zero-kelvin at gmx.de  Thu Apr 11 18:41:06 2013
From: zero-kelvin at gmx.de (dexter)
Date: Thu, 11 Apr 2013 20:41:06 +0200
Subject: Question about ms max power parameter.
In-Reply-To: <5165C989.6010601@eversberg.eu>
References: <516480C2.3060206@gmx.de> <5165C989.6010601@eversberg.eu>
Message-ID: <516703C2.3010706@gmx.de>

Hello Andreas,
>
> set ms max power to 0 to get 1 milliwatts to start with (rach and 
> initial power). set it to 30 to get 1 watts (1800) or 33 to get 2 
> watts (900). during dedicated channel, it is up to the bts to change 
> the power level up or down, depending on the uplink level/quality.
>

Thank you very much for your hint. I have set it to 0 dBm now and it 
works fine. I have my phones directly next to the BTS so i think it will 
not raise the power above 1 or 2 mW.

regards.
Philipp




From seuzhaojx at gmail.com  Fri Apr 12 12:59:50 2013
From: seuzhaojx at gmail.com (Jianxiang)
Date: Fri, 12 Apr 2013 20:59:50 +0800
Subject: KINDLY UNSUBSCRIBE ME..
In-Reply-To: <4FF572E4.6000305@cdotb.ernet.in>
References: <4FF572E4.6000305@cdotb.ernet.in>
Message-ID: <51680546.4050807@gmail.com>


>




From Max.Suraev at fairwaves.ru  Mon Apr 15 16:35:23 2013
From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=)
Date: Mon, 15 Apr 2013 18:35:23 +0200
Subject: MNCC further reading
Message-ID: <516C2C4B.1090405@fairwaves.ru>

Hello.

Could you advice me where to read more about MNCC protocol?

openbsc/openbsc/include/openbsc/mncc.h references ETSI TS 100 940 which indeed has a
lot of variables like MNCC.RECALL.IND in call control diagrams - but where are the
reference to actual protocol?

I've tried to google but got tons of unrelated junk :(

Pardon if I'm asking smth obvious or already documented. Is there some library which
will let me easily create simple tool which speaks mncc with openbsc (libmsc)?


-- 
best regards,
Max, http://fairwaves.ru



From laforge at gnumonks.org  Mon Apr 15 19:12:13 2013
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 15 Apr 2013 21:12:13 +0200
Subject: MNCC further reading
In-Reply-To: <516C2C4B.1090405@fairwaves.ru>
References: <516C2C4B.1090405@fairwaves.ru>
Message-ID: <20130415191213.GJ11381@prithivi.gnumonks.org>

hi Max,

On Mon, Apr 15, 2013 at 06:35:23PM +0200, ? wrote:

> Could you advice me where to read more about MNCC protocol?

it is not a protocol, but an interface

> openbsc/openbsc/include/openbsc/mncc.h references ETSI TS 100 940 which indeed has a
> lot of variables like MNCC.RECALL.IND in call control diagrams - but where are the
> reference to actual protocol?

there is no protocol.  The Spec only defines a set of primitives and
possibly their parameters, but no encoding or no protocol.  This is
fairly standard for ETSI/3GPP specs that document internal interfaces
between layers of functional elements where no wire-protocol or vendor
inter-operability is required.

-- 
- 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 nicolas.bouliane at nutaq.com  Thu Apr 18 12:25:31 2013
From: nicolas.bouliane at nutaq.com (Nicolas J. Bouliane)
Date: Thu, 18 Apr 2013 08:25:31 -0400
Subject: [PATCH] rsl: fix the unaligned memory access
Message-ID: <516FE63B.1040203@nutaq.com>

the armv5 can do 32bit/16bit reads only from the aligned address
use tlv.h macro to copy data to local variable

Signed-off-by: Nicolas J. Bouliane <nicolas.bouliane at nutaq.com>
---
 src/common/rsl.c |   30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/src/common/rsl.c b/src/common/rsl.c
index 9a50a33..5a1b867 100644
--- a/src/common/rsl.c
+++ b/src/common/rsl.c
@@ -1089,7 +1089,6 @@ static int rsl_tx_ipac_XXcx_ack(struct gsm_lchan *lchan, int inc_pt2,
 {
     struct msgb *msg;
     uint8_t chan_nr = gsm_lchan2chan_nr(lchan);
-    uint32_t *att_ip;
     const char *name;
     struct in_addr ia;
 
@@ -1116,8 +1115,7 @@ static int rsl_tx_ipac_XXcx_ack(struct gsm_lchan *lchan, int inc_pt2,
 
     /* locally bound IP */
     msgb_v_put(msg, RSL_IE_IPAC_LOCAL_IP);
-    att_ip = (uint32_t *) msgb_put(msg, sizeof(uint32_t));
-    *att_ip = htonl(lchan->abis_ip.bound_ip);
+    msgb_put_u32(msg, lchan->abis_ip.bound_ip);
 
     /* locally bound port */
     msgb_tv16_put(msg, RSL_IE_IPAC_LOCAL_PORT,
@@ -1199,11 +1197,9 @@ static int tx_ipac_XXcx_nack(struct gsm_lchan *lchan, uint8_t cause,
         return -ENOMEM;
 
     if (inc_ipport) {
-        uint32_t *att_ip;
         /* remote IP */
         msgb_v_put(msg, RSL_IE_IPAC_REMOTE_IP);
-        att_ip = (uint32_t *) msgb_put(msg, sizeof(uint32_t));
-        *att_ip = htonl(lchan->abis_ip.connect_ip);
+        msgb_put_u32(msg, lchan->abis_ip.connect_ip);
 
         /* remote port */
         msgb_tv16_put(msg, RSL_IE_IPAC_REMOTE_PORT,
@@ -1248,8 +1244,8 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
     struct gsm_lchan *lchan = msg->lchan;
     struct gsm_bts_role_bts *btsb = bts_role_bts(msg->lchan->ts->trx->bts);
     const uint8_t *payload_type, *speech_mode, *payload_type2;
-    const uint32_t *connect_ip;
-    const uint16_t *connect_port;
+    uint32_t connect_ip = 0;
+    uint16_t connect_port = 0;
     int rc, inc_ip_port = 0, port;
     char *name;
 
@@ -1267,8 +1263,14 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
     speech_mode = TLVP_VAL(&tp, RSL_IE_IPAC_SPEECH_MODE);
     payload_type = TLVP_VAL(&tp, RSL_IE_IPAC_RTP_PAYLOAD);
     payload_type2 = TLVP_VAL(&tp, RSL_IE_IPAC_RTP_PAYLOAD2);
-    connect_ip = (uint32_t *) TLVP_VAL(&tp, RSL_IE_IPAC_REMOTE_IP);
-    connect_port = (uint16_t *) TLVP_VAL(&tp, RSL_IE_IPAC_REMOTE_PORT);
+
+    if (TLVP_PRESENT(&tp, RSL_IE_IPAC_REMOTE_IP)) {
+        connect_ip = tlvp_val32_unal(&tp, RSL_IE_IPAC_REMOTE_IP);
+    }
+
+    if (TLVP_PRESENT(&tp, RSL_IE_IPAC_REMOTE_PORT)) {
+        connect_port = tlvp_val16_unal(&tp, RSL_IE_IPAC_REMOTE_PORT);
+    }
 
     if (dch->c.msg_type == RSL_MT_IPAC_CRCX && connect_ip && connect_port)
         inc_ip_port = 1;
@@ -1350,14 +1352,14 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
 
         /* Special rule: If connect_ip == 0.0.0.0, use RSL IP
          * address */
-        if (*connect_ip == 0) {
+        if (connect_ip == 0) {
             struct ipabis_link *link =
                 lchan->ts->trx->rsl_link;
             ia.s_addr = htonl(link->ip);
         } else
-            ia.s_addr = *connect_ip;
+            ia.s_addr = connect_ip;
         rc = osmo_rtp_socket_connect(lchan->abis_ip.rtp_socket,
-                         inet_ntoa(ia), ntohs(*connect_port));
+                         inet_ntoa(ia), ntohs(connect_port));
         if (rc < 0) {
             LOGP(DRSL, LOGL_ERROR,
                  "%s Failed to connect RTP/RTCP sockets\n",
@@ -1370,7 +1372,7 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
         }
         /* save IP address and port number */
         lchan->abis_ip.connect_ip = ntohl(ia.s_addr);
-        lchan->abis_ip.connect_port = ntohs(*connect_port);
+        lchan->abis_ip.connect_port = ntohs(connect_port);
 
     } else {
         /* FIXME: discard all codec frames */
-- 
1.7.10.4




From laforge at gnumonks.org  Thu Apr 18 14:27:56 2013
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 18 Apr 2013 16:27:56 +0200
Subject: [PATCH] rsl: fix the unaligned memory access
In-Reply-To: <516FE63B.1040203@nutaq.com>
References: <516FE63B.1040203@nutaq.com>
Message-ID: <20130418142756.GB9621@prithivi.gnumonks.org>

Hi Nicolas,

thanks for your patch.

On Thu, Apr 18, 2013 at 08:25:31AM -0400, Nicolas J. Bouliane wrote:
> -    connect_ip = (uint32_t *) TLVP_VAL(&tp, RSL_IE_IPAC_REMOTE_IP);
> -    connect_port = (uint16_t *) TLVP_VAL(&tp, RSL_IE_IPAC_REMOTE_PORT);
> +
> +    if (TLVP_PRESENT(&tp, RSL_IE_IPAC_REMOTE_IP)) {
> +        connect_ip = tlvp_val32_unal(&tp, RSL_IE_IPAC_REMOTE_IP);
> +    }
> +
> +    if (TLVP_PRESENT(&tp, RSL_IE_IPAC_REMOTE_PORT)) {
> +        connect_port = tlvp_val16_unal(&tp, RSL_IE_IPAC_REMOTE_PORT);
> +    }

Several comments for that:

1) we unconditionally assume that the IEs are present in the original
   code.  This is most likely due to the fact that they are specified to
   be there.  If they don't exist, we fail miserably.  With your new
   code, we still fail in strange ways.  Best would be to print a
   LOGL_WARN or ERROR message about missing information elements.

2) kernel coding style (which we use universally in our projects) says:
   If there's only a single statement after an if statement, we don't
   use curly braces.

I'd appreciate if you could submit a new patch (replacing the original
patch, not an incremental one) to that regard.  Thanks.

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 nicolas.bouliane at nutaq.com  Thu Apr 18 16:01:38 2013
From: nicolas.bouliane at nutaq.com (Nicolas J. Bouliane)
Date: Thu, 18 Apr 2013 12:01:38 -0400
Subject: [PATCH] rsl: fix the unaligned memory access
In-Reply-To: <20130418142756.GB9621@prithivi.gnumonks.org>
References: <516FE63B.1040203@nutaq.com>
	<20130418142756.GB9621@prithivi.gnumonks.org>
Message-ID: <517018E2.50509@nutaq.com>


the armv5 can do 32bit/16bit reads only from the aligned address
use tlv.h macro to copy data to local variable

Signed-off-by: Nicolas J. Bouliane <nicolas.bouliane at nutaq.com>
---
 src/common/rsl.c |   30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/src/common/rsl.c b/src/common/rsl.c
index 9a50a33..f3657a7 100644
--- a/src/common/rsl.c
+++ b/src/common/rsl.c
@@ -1089,7 +1089,6 @@ static int rsl_tx_ipac_XXcx_ack(struct gsm_lchan *lchan, int inc_pt2,
 {
     struct msgb *msg;
     uint8_t chan_nr = gsm_lchan2chan_nr(lchan);
-    uint32_t *att_ip;
     const char *name;
     struct in_addr ia;
 
@@ -1116,8 +1115,7 @@ static int rsl_tx_ipac_XXcx_ack(struct gsm_lchan *lchan, int inc_pt2,
 
     /* locally bound IP */
     msgb_v_put(msg, RSL_IE_IPAC_LOCAL_IP);
-    att_ip = (uint32_t *) msgb_put(msg, sizeof(uint32_t));
-    *att_ip = htonl(lchan->abis_ip.bound_ip);
+    msgb_put_u32(msg, lchan->abis_ip.bound_ip);
 
     /* locally bound port */
     msgb_tv16_put(msg, RSL_IE_IPAC_LOCAL_PORT,
@@ -1199,11 +1197,9 @@ static int tx_ipac_XXcx_nack(struct gsm_lchan *lchan, uint8_t cause,
         return -ENOMEM;
 
     if (inc_ipport) {
-        uint32_t *att_ip;
         /* remote IP */
         msgb_v_put(msg, RSL_IE_IPAC_REMOTE_IP);
-        att_ip = (uint32_t *) msgb_put(msg, sizeof(uint32_t));
-        *att_ip = htonl(lchan->abis_ip.connect_ip);
+        msgb_put_u32(msg, lchan->abis_ip.connect_ip);
 
         /* remote port */
         msgb_tv16_put(msg, RSL_IE_IPAC_REMOTE_PORT,
@@ -1248,8 +1244,8 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
     struct gsm_lchan *lchan = msg->lchan;
     struct gsm_bts_role_bts *btsb = bts_role_bts(msg->lchan->ts->trx->bts);
     const uint8_t *payload_type, *speech_mode, *payload_type2;
-    const uint32_t *connect_ip;
-    const uint16_t *connect_port;
+    uint32_t connect_ip = 0;
+    uint16_t connect_port = 0;
     int rc, inc_ip_port = 0, port;
     char *name;
 
@@ -1267,8 +1263,14 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
     speech_mode = TLVP_VAL(&tp, RSL_IE_IPAC_SPEECH_MODE);
     payload_type = TLVP_VAL(&tp, RSL_IE_IPAC_RTP_PAYLOAD);
     payload_type2 = TLVP_VAL(&tp, RSL_IE_IPAC_RTP_PAYLOAD2);
-    connect_ip = (uint32_t *) TLVP_VAL(&tp, RSL_IE_IPAC_REMOTE_IP);
-    connect_port = (uint16_t *) TLVP_VAL(&tp, RSL_IE_IPAC_REMOTE_PORT);
+
+    if (TLVP_PRESENT(&tp, RSL_IE_IPAC_REMOTE_IP))
+        connect_ip = tlvp_val32_unal(&tp, RSL_IE_IPAC_REMOTE_IP);
+    else LOGP(DRSL, LOGL_NOTICE, "CRCX does not specify a remote IP\n");
+
+    if (TLVP_PRESENT(&tp, RSL_IE_IPAC_REMOTE_PORT))
+        connect_port = tlvp_val16_unal(&tp, RSL_IE_IPAC_REMOTE_PORT);
+    else LOGP(DRSL, LOGL_NOTICE, "CRCX does not specify a remote port\n");
 
     if (dch->c.msg_type == RSL_MT_IPAC_CRCX && connect_ip && connect_port)
         inc_ip_port = 1;
@@ -1350,14 +1352,14 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
 
         /* Special rule: If connect_ip == 0.0.0.0, use RSL IP
          * address */
-        if (*connect_ip == 0) {
+        if (connect_ip == 0) {
             struct ipabis_link *link =
                 lchan->ts->trx->rsl_link;
             ia.s_addr = htonl(link->ip);
         } else
-            ia.s_addr = *connect_ip;
+            ia.s_addr = connect_ip;
         rc = osmo_rtp_socket_connect(lchan->abis_ip.rtp_socket,
-                         inet_ntoa(ia), ntohs(*connect_port));
+                         inet_ntoa(ia), ntohs(connect_port));
         if (rc < 0) {
             LOGP(DRSL, LOGL_ERROR,
                  "%s Failed to connect RTP/RTCP sockets\n",
@@ -1370,7 +1372,7 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
         }
         /* save IP address and port number */
         lchan->abis_ip.connect_ip = ntohl(ia.s_addr);
-        lchan->abis_ip.connect_port = ntohs(*connect_port);
+        lchan->abis_ip.connect_port = ntohs(connect_port);
 
     } else {
         /* FIXME: discard all codec frames */
-- 
1.7.10.4




From nicolas.bouliane at nutaq.com  Thu Apr 18 16:18:16 2013
From: nicolas.bouliane at nutaq.com (Nicolas J. Bouliane)
Date: Thu, 18 Apr 2013 12:18:16 -0400
Subject: [PATCH] rsl: fix the unaligned memory access
In-Reply-To: <20130418142756.GB9621@prithivi.gnumonks.org>
References: <516FE63B.1040203@nutaq.com>
	<20130418142756.GB9621@prithivi.gnumonks.org>
Message-ID: <51701CC8.8070602@nutaq.com>


the armv5 can do 32bit/16bit reads only from the aligned address
use tlv.h macro to copy data to local variable

Signed-off-by: Nicolas J. Bouliane <nicolas.bouliane at nutaq.com>
---
 src/common/rsl.c |   32 ++++++++++++++++++--------------
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/src/common/rsl.c b/src/common/rsl.c
index 9a50a33..4f28cb2 100644
--- a/src/common/rsl.c
+++ b/src/common/rsl.c
@@ -1089,7 +1089,6 @@ static int rsl_tx_ipac_XXcx_ack(struct gsm_lchan *lchan, int inc_pt2,
 {
     struct msgb *msg;
     uint8_t chan_nr = gsm_lchan2chan_nr(lchan);
-    uint32_t *att_ip;
     const char *name;
     struct in_addr ia;
 
@@ -1116,8 +1115,7 @@ static int rsl_tx_ipac_XXcx_ack(struct gsm_lchan *lchan, int inc_pt2,
 
     /* locally bound IP */
     msgb_v_put(msg, RSL_IE_IPAC_LOCAL_IP);
-    att_ip = (uint32_t *) msgb_put(msg, sizeof(uint32_t));
-    *att_ip = htonl(lchan->abis_ip.bound_ip);
+    msgb_put_u32(msg, lchan->abis_ip.bound_ip);
 
     /* locally bound port */
     msgb_tv16_put(msg, RSL_IE_IPAC_LOCAL_PORT,
@@ -1199,11 +1197,9 @@ static int tx_ipac_XXcx_nack(struct gsm_lchan *lchan, uint8_t cause,
         return -ENOMEM;
 
     if (inc_ipport) {
-        uint32_t *att_ip;
         /* remote IP */
         msgb_v_put(msg, RSL_IE_IPAC_REMOTE_IP);
-        att_ip = (uint32_t *) msgb_put(msg, sizeof(uint32_t));
-        *att_ip = htonl(lchan->abis_ip.connect_ip);
+        msgb_put_u32(msg, lchan->abis_ip.connect_ip);
 
         /* remote port */
         msgb_tv16_put(msg, RSL_IE_IPAC_REMOTE_PORT,
@@ -1248,8 +1244,8 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
     struct gsm_lchan *lchan = msg->lchan;
     struct gsm_bts_role_bts *btsb = bts_role_bts(msg->lchan->ts->trx->bts);
     const uint8_t *payload_type, *speech_mode, *payload_type2;
-    const uint32_t *connect_ip;
-    const uint16_t *connect_port;
+    uint32_t connect_ip = 0;
+    uint16_t connect_port = 0;
     int rc, inc_ip_port = 0, port;
     char *name;
 
@@ -1267,8 +1263,16 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
     speech_mode = TLVP_VAL(&tp, RSL_IE_IPAC_SPEECH_MODE);
     payload_type = TLVP_VAL(&tp, RSL_IE_IPAC_RTP_PAYLOAD);
     payload_type2 = TLVP_VAL(&tp, RSL_IE_IPAC_RTP_PAYLOAD2);
-    connect_ip = (uint32_t *) TLVP_VAL(&tp, RSL_IE_IPAC_REMOTE_IP);
-    connect_port = (uint16_t *) TLVP_VAL(&tp, RSL_IE_IPAC_REMOTE_PORT);
+
+    if (TLVP_PRESENT(&tp, RSL_IE_IPAC_REMOTE_IP))
+        connect_ip = tlvp_val32_unal(&tp, RSL_IE_IPAC_REMOTE_IP);
+    else
+        LOGP(DRSL, LOGL_NOTICE, "CRCX does not specify a remote IP\n");
+
+    if (TLVP_PRESENT(&tp, RSL_IE_IPAC_REMOTE_PORT))
+        connect_port = tlvp_val16_unal(&tp, RSL_IE_IPAC_REMOTE_PORT);
+    else
+        LOGP(DRSL, LOGL_NOTICE, "CRCX does not specify a remote port\n");
 
     if (dch->c.msg_type == RSL_MT_IPAC_CRCX && connect_ip && connect_port)
         inc_ip_port = 1;
@@ -1350,14 +1354,14 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
 
         /* Special rule: If connect_ip == 0.0.0.0, use RSL IP
          * address */
-        if (*connect_ip == 0) {
+        if (connect_ip == 0) {
             struct ipabis_link *link =
                 lchan->ts->trx->rsl_link;
             ia.s_addr = htonl(link->ip);
         } else
-            ia.s_addr = *connect_ip;
+            ia.s_addr = connect_ip;
         rc = osmo_rtp_socket_connect(lchan->abis_ip.rtp_socket,
-                         inet_ntoa(ia), ntohs(*connect_port));
+                         inet_ntoa(ia), ntohs(connect_port));
         if (rc < 0) {
             LOGP(DRSL, LOGL_ERROR,
                  "%s Failed to connect RTP/RTCP sockets\n",
@@ -1370,7 +1374,7 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
         }
         /* save IP address and port number */
         lchan->abis_ip.connect_ip = ntohl(ia.s_addr);
-        lchan->abis_ip.connect_port = ntohs(*connect_port);
+        lchan->abis_ip.connect_port = ntohs(connect_port);
 
     } else {
         /* FIXME: discard all codec frames */
-- 
1.7.10.4





From laforge at gnumonks.org  Sun Apr 21 15:41:22 2013
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 21 Apr 2013 17:41:22 +0200
Subject: [PATCH] rsl: fix the unaligned memory access
In-Reply-To: <51701CC8.8070602@nutaq.com>
References: <516FE63B.1040203@nutaq.com>
	<20130418142756.GB9621@prithivi.gnumonks.org>
	<51701CC8.8070602@nutaq.com>
Message-ID: <20130421154122.GD7790@prithivi.gnumonks.org>

Dear Nicolas,

I'm not sure what you're doing or where exactly your patch got broken,
but both "git am" as well as a manual "patch -p1" completely fail:

patching file src/common/rsl.c
Hunk #1 FAILED at 1089.
Hunk #2 FAILED at 1116.
Hunk #3 FAILED at 1199.
Hunk #4 FAILED at 1248.
Hunk #5 FAILED at 1267.
Hunk #6 FAILED at 1350.
Hunk #7 FAILED at 1370.
7 out of 7 hunks FAILED -- saving rejects to file src/common/rsl.c.rej

To me it seems like your file contains four spaces instead of tab
indentation that we use.  I suggest sending mails by "git send-email" or
buy git format-patch + attaching them to your mail.

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 holger at freyther.de  Sun Apr 21 19:23:16 2013
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 21 Apr 2013 21:23:16 +0200
Subject: [PATCH] rsl: fix the unaligned memory access
In-Reply-To: <20130421154122.GD7790@prithivi.gnumonks.org>
References: <516FE63B.1040203@nutaq.com>
	<20130418142756.GB9621@prithivi.gnumonks.org>
	<51701CC8.8070602@nutaq.com>
	<20130421154122.GD7790@prithivi.gnumonks.org>
Message-ID: <20130421192316.GE29706@xiaoyu.lan>

On Sun, Apr 21, 2013 at 05:41:22PM +0200, Harald Welte wrote:

Yes,

we already had this on IRC. thunderbird is replacing tabs with spaces.
Maybe we should have a procmail file that rejects inline patches sent
by thunderbird. :}


> To me it seems like your file contains four spaces instead of tab
> indentation that we use.  I suggest sending mails by "git send-email" or
> buy git format-patch + attaching them to your mail.




From nicolas.bouliane at nutaq.com  Mon Apr 22 11:45:13 2013
From: nicolas.bouliane at nutaq.com (Nicolas J. Bouliane)
Date: Mon, 22 Apr 2013 07:45:13 -0400
Subject: [PATCH] rsl: fix the unaligned memory access
In-Reply-To: <20130421154122.GD7790@prithivi.gnumonks.org>
References: <20130421154122.GD7790@prithivi.gnumonks.org>
Message-ID: <1366631113-5621-1-git-send-email-nicolas.bouliane@nutaq.com>

From: "Nicolas J. Bouliane" <nicolas.bouliane at nutaq.com>

the armv5 can do 32bit/16bit reads only from the aligned address
use tlv.h macro to copy data to local variable

Signed-off-by: Nicolas J. Bouliane <nicolas.bouliane at nutaq.com>
---
 src/common/rsl.c |   32 ++++++++++++++++++--------------
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/src/common/rsl.c b/src/common/rsl.c
index 9a50a33..4f28cb2 100644
--- a/src/common/rsl.c
+++ b/src/common/rsl.c
@@ -1089,7 +1089,6 @@ static int rsl_tx_ipac_XXcx_ack(struct gsm_lchan *lchan, int inc_pt2,
 {
 	struct msgb *msg;
 	uint8_t chan_nr = gsm_lchan2chan_nr(lchan);
-	uint32_t *att_ip;
 	const char *name;
 	struct in_addr ia;
 
@@ -1116,8 +1115,7 @@ static int rsl_tx_ipac_XXcx_ack(struct gsm_lchan *lchan, int inc_pt2,
 
 	/* locally bound IP */
 	msgb_v_put(msg, RSL_IE_IPAC_LOCAL_IP);
-	att_ip = (uint32_t *) msgb_put(msg, sizeof(uint32_t));
-	*att_ip = htonl(lchan->abis_ip.bound_ip);
+	msgb_put_u32(msg, lchan->abis_ip.bound_ip);
 
 	/* locally bound port */
 	msgb_tv16_put(msg, RSL_IE_IPAC_LOCAL_PORT,
@@ -1199,11 +1197,9 @@ static int tx_ipac_XXcx_nack(struct gsm_lchan *lchan, uint8_t cause,
 		return -ENOMEM;
 
 	if (inc_ipport) {
-		uint32_t *att_ip;
 		/* remote IP */
 		msgb_v_put(msg, RSL_IE_IPAC_REMOTE_IP);
-		att_ip = (uint32_t *) msgb_put(msg, sizeof(uint32_t));
-		*att_ip = htonl(lchan->abis_ip.connect_ip);
+		msgb_put_u32(msg, lchan->abis_ip.connect_ip);
 
 		/* remote port */
 		msgb_tv16_put(msg, RSL_IE_IPAC_REMOTE_PORT,
@@ -1248,8 +1244,8 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
 	struct gsm_lchan *lchan = msg->lchan;
 	struct gsm_bts_role_bts *btsb = bts_role_bts(msg->lchan->ts->trx->bts);
 	const uint8_t *payload_type, *speech_mode, *payload_type2;
-	const uint32_t *connect_ip;
-	const uint16_t *connect_port;
+	uint32_t connect_ip = 0;
+	uint16_t connect_port = 0;
 	int rc, inc_ip_port = 0, port;
 	char *name;
 
@@ -1267,8 +1263,16 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
 	speech_mode = TLVP_VAL(&tp, RSL_IE_IPAC_SPEECH_MODE);
 	payload_type = TLVP_VAL(&tp, RSL_IE_IPAC_RTP_PAYLOAD);
 	payload_type2 = TLVP_VAL(&tp, RSL_IE_IPAC_RTP_PAYLOAD2);
-	connect_ip = (uint32_t *) TLVP_VAL(&tp, RSL_IE_IPAC_REMOTE_IP);
-	connect_port = (uint16_t *) TLVP_VAL(&tp, RSL_IE_IPAC_REMOTE_PORT);
+
+	if (TLVP_PRESENT(&tp, RSL_IE_IPAC_REMOTE_IP))
+		connect_ip = tlvp_val32_unal(&tp, RSL_IE_IPAC_REMOTE_IP);
+	else
+		LOGP(DRSL, LOGL_NOTICE, "CRCX does not specify a remote IP\n");
+
+	if (TLVP_PRESENT(&tp, RSL_IE_IPAC_REMOTE_PORT))
+		connect_port = tlvp_val16_unal(&tp, RSL_IE_IPAC_REMOTE_PORT);
+	else
+		LOGP(DRSL, LOGL_NOTICE, "CRCX does not specify a remote port\n");
 
 	if (dch->c.msg_type == RSL_MT_IPAC_CRCX && connect_ip && connect_port)
 		inc_ip_port = 1;
@@ -1350,14 +1354,14 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
 
 		/* Special rule: If connect_ip == 0.0.0.0, use RSL IP
 		 * address */
-		if (*connect_ip == 0) {
+		if (connect_ip == 0) {
 			struct ipabis_link *link =
 				lchan->ts->trx->rsl_link;
 			ia.s_addr = htonl(link->ip);
 		} else
-			ia.s_addr = *connect_ip;
+			ia.s_addr = connect_ip;
 		rc = osmo_rtp_socket_connect(lchan->abis_ip.rtp_socket,
-					     inet_ntoa(ia), ntohs(*connect_port));
+					     inet_ntoa(ia), ntohs(connect_port));
 		if (rc < 0) {
 			LOGP(DRSL, LOGL_ERROR,
 			     "%s Failed to connect RTP/RTCP sockets\n",
@@ -1370,7 +1374,7 @@ static int rsl_rx_ipac_XXcx(struct msgb *msg)
 		}
 		/* save IP address and port number */
 		lchan->abis_ip.connect_ip = ntohl(ia.s_addr);
-		lchan->abis_ip.connect_port = ntohs(*connect_port);
+		lchan->abis_ip.connect_port = ntohs(connect_port);
 
 	} else {
 		/* FIXME: discard all codec frames */
-- 
1.7.10.4




From nicolas.bouliane at nutaq.com  Thu Apr 18 14:46:13 2013
From: nicolas.bouliane at nutaq.com (Nicolas J. Bouliane)
Date: Thu, 18 Apr 2013 10:46:13 -0400
Subject: [PATCH] osmo-bts: fix linking order in Makefile.am
Message-ID: <51700735.60909@nutaq.com>


On some system (e.g. ubuntu) libosmovty must precede libosmocore
otherwise we get undefined reference errors while linking.

Signed-off-by: Nicolas J. Bouliane <nicolas.bouliane at nutaq.com>
---
 src/osmo-bts-sysmo/Makefile.am |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/osmo-bts-sysmo/Makefile.am b/src/osmo-bts-sysmo/Makefile.am
index 80a23d3..1064acf 100644
--- a/src/osmo-bts-sysmo/Makefile.am
+++ b/src/osmo-bts-sysmo/Makefile.am
@@ -1,6 +1,6 @@
 INCLUDES = $(all_includes) -I$(top_srcdir)/include -I$(OPENBSC_INCDIR)
 AM_CFLAGS = -Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(LIBOSMOTRAU_CFLAGS)
-LDADD = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) $(LIBOSMOVTY_LIBS) $(LIBOSMOTRAU_LIBS) -lortp
+LDADD = $(LIBOSMOVTY_LIBS) $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) $(LIBOSMOTRAU_LIBS) -lortp
 
 EXTRA_DIST = misc/sysmobts_mgr.h misc/sysmobts_misc.h misc/sysmobts_par.h \
     misc/sysmobts_eeprom.h femtobts.h hw_misc.h l1_fwd.h l1_if.h \
-- 
1.7.10.4




From tyruskam at gmail.com  Fri Apr 19 10:01:21 2013
From: tyruskam at gmail.com (ty)
Date: Fri, 19 Apr 2013 13:01:21 +0300
Subject: No subject
Message-ID: <CAO-q7J7-D0u_7_98YhQhmhxARkXAeb7i0iw9wLnsDG=+Xm0CyQ@mail.gmail.com>


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

From tyruskam at gmail.com  Fri Apr 19 10:22:25 2013
From: tyruskam at gmail.com (ty)
Date: Fri, 19 Apr 2013 13:22:25 +0300
Subject: Latest OpenBSC repo regression
Message-ID: <CAO-q7J7qN6T3WwprZ65JDtbUZKt0eCKFu-YGCqhKmV1gOtGt+w@mail.gmail.com>

Hi folks
I pulled the latest repo of OpenBsc but upon compilation, it breaks while
running 'make'
Everything else compiled fine, libosmocore and libosmo-abis. I'm running
this on Ubuntu 12.04 LTS.

Here is the make error.

make[3]: Entering directory `/home/tyrus/openbsc/openbsc/src/libcommon'
  CC     common_vty.o
In file included from common_vty.c:30:0:
../../include/openbsc/bsc_nat.h:35:37: fatal error:
osmocom/sccp/sccp_types.h: No such file or directory
compilation terminated.
make[3]: *** [common_vty.o] Error 1
make[3]: Leaving directory `/home/tyrus/openbsc/openbsc/src/libcommon'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/tyrus/openbsc/openbsc/src'
make[1]: *** [all-recursive] Error 1

After fiddling around I couldnt find the sccp dir with its contents so when
i checked the git diff I found it was in this tree
http://git.zerfleddert.de/cgi-bin/gitweb.cgi/bs11/commitdiff/e9359db5803baef9a66bb007a0fa719c2d2bb475?hp=7638af95fd08213aef4adb3c6399975fe3621855

However when i manually created the files and dirs, it was just a
nightmare. Anyone with pointers how to fix this, ill really appreciate


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

From holger at freyther.de  Sun Apr 21 19:21:33 2013
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 21 Apr 2013 21:21:33 +0200
Subject: Latest OpenBSC repo regression
In-Reply-To: <CAO-q7J7qN6T3WwprZ65JDtbUZKt0eCKFu-YGCqhKmV1gOtGt+w@mail.gmail.com>
References: <CAO-q7J7qN6T3WwprZ65JDtbUZKt0eCKFu-YGCqhKmV1gOtGt+w@mail.gmail.com>
Message-ID: <20130421192133.GD29706@xiaoyu.lan>

On Fri, Apr 19, 2013 at 01:22:25PM +0300, ty wrote:
> Hi folks
> I pulled the latest repo of OpenBsc but upon compilation, it breaks while
> running 'make'

well, the users of the SCCP library are disabled by default. When you upgrade
OpenBSC after a couple of years you should use autoreconf --install --force
and re-generate the configure script.





From holger at freyther.de  Mon Apr 22 07:16:07 2013
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Mon, 22 Apr 2013 09:16:07 +0200
Subject: Latest OpenBSC repo regression
In-Reply-To: <CAO-q7J7qN6T3WwprZ65JDtbUZKt0eCKFu-YGCqhKmV1gOtGt+w@mail.gmail.com>
References: <CAO-q7J7qN6T3WwprZ65JDtbUZKt0eCKFu-YGCqhKmV1gOtGt+w@mail.gmail.com>
Message-ID: <20130422071607.GJ29706@xiaoyu.lan>

On Fri, Apr 19, 2013 at 01:22:25PM +0300, ty wrote:
> Hi folks

Hi again,


due the little context (e.g the head of config.log to see how one has
configured OpenBSC, some output of git reflog to see what was the old
HEAD) given in this email I didn't notice the problem when reading the
make output.

> make[3]: Entering directory `/home/tyrus/openbsc/openbsc/src/libcommon'
>   CC     common_vty.o
> In file included from common_vty.c:30:0:
> ../../include/openbsc/bsc_nat.h:35:37: fatal error:
> osmocom/sccp/sccp_types.h: No such file or directory
> compilation terminated.

bsc_nat.h is including sccp_types.h and it started doing it in
git revision 462b7d7158937b51fbb833ea3066e01fe8322f37. I have
moved the new struct into a new header file and common_vty.c should
compile without the SCCP header installed.

holger



From alexander.chemeris at gmail.com  Sat Apr 20 20:33:58 2013
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Sun, 21 Apr 2013 00:33:58 +0400
Subject: [ANNOUNCE] UmTRX sales start on the Hardware Freedom Day
Message-ID: <CABmJbFWUtZRD8zcG5yfQJmAOwqgZ4NrYXMcJWHG5QA=e4kSeXg@mail.gmail.com>

Dear all,

(I'm sorry for cross-posting to several mailing lists, but it really
belongs to all of them. Please respond only to a mailing list you're
subscribed to.)

UmTRX sales start
===============

It's the Hardware Freedom Day and we're starting sales of UmTRX to
celebrate it! Now you could order it directly from Fairwaves web-shop
[1],

UmTRX is a completely open-source hardware SDR transceiver designed
for professional/industrial applications. We designed it for use with
OpenBTS software [2], but it also works well with OsmoBTS/OpenBSC [3].

UmTRX uses a UHD [4] with only minor changes to interact with a host
and thus works well with GnuRadio and other applications based on UHD.

1. http://shop.fairwaves.ru/
2. https://code.google.com/p/umtrx/wiki/RunningOpenBTS
3. http://openbsc.osmocom.org/trac/wiki/OsmoBTS
4. https://github.com/fairwaves/UHD-Fairwaves

Technical details
==============

UmTRX is an SDR transceiver inspired by USRP N series. If you worked
with USRP N you will find it familiar, but there are significant
differences which are described below as well.

 * Single board with an integrated RF part.
 * Optimized for industrial use and high MTBF.
 * 1GbE Ethernet connectivity to a computer.
 * Two full-duplex RF channels (side "A" and "B" in UHD).
 * Single chip transceivers LMS6002D are used for AD/DA and RF
processing (300MHz to 3.8GHz)
 * Stable reference clocks:
   - 26MHz TCXO (integer multiple of GSM sample rate) with 100ppb
frequency stability.
   - DAC for TCXO frequency fine tuning.
   - Integrated GPS module for automatic TCXO frequency stabilization.
   - External clock source is possible.
 * Thermal sensors for temperature based calibration.
 * 100mW @ 900MHz, 50mW @ 1800MHz RF output power.
 * 8-28V DC input power supply.
 * Spartan 6 LX75 FPGA.

PS Big thank you to Lime Microsystems for their excellent support of
open-source users! Check out their chips if you're planning to develop
and SDR system.

GSM specific info
==============

UmTRX was designed to be easy to use to use with OpenBTS and OsmoBTS.
So far it's the easiest way to get them up and running in your lab.

 * Quad-band support without any changes
 * 100-200m coverage (with an external duplexer and a small omni antenna).
 * >2km coverage with an external 2W GSM repeater and a patch antenna
 * Two independent TRXs (*).
 * Single-ARFCN and Multi-ARFCN support.

(*) OpenBTS doesn't support the second channel on UmTRX yet. We're
working to implement this and plan to release this soon.

I also want to say thank you to our beta testers who received earlier
versions of UmTRX. Some of them even blogged about their experience :)
http://blog.shimaore.net/2013/03/umtrx.html
http://genesysguru.com/blog/blog/2013/03/23/umtrx-is-alive-again/

UmTRX package contents
========================

 * UmTRXv2.1, flashed and ready to use.
 * Power supply, 12V/30W - http://www.phihong.com/assets/pdf/PSAC30U.pdf
 * U.FL-to-SMA-F pigtail cables.
 * Two small GSM antennas - one for Tx and one for Rx.
 * An active GPS antenna.
 * Thermal pads.

Note 1: The power supply comes without a 220V power cord. Make sure to
prepare one before you receive the UmTRX to be able to power it on
immediately. ;)

Note 2: You'll need a heatsink or a fan to prevent UmTRX from
overheating during long continuous operation. We provide thermal pads,
but you have to find a heatsink by yourself. HDD heatsinks are good
options, because UmTRX has almost the same size as an HDD.

--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru



From alexd at afterthoughtsoftware.com  Fri Apr 26 19:46:00 2013
From: alexd at afterthoughtsoftware.com (Alex Duller)
Date: Fri, 26 Apr 2013 20:46:00 +0100
Subject: [PATCH (for jolly/testing)] Fixed seg fault when using sysmobts and
	added sysmo enum to tch_frame_down
Message-ID: <1367005560-5270-1-git-send-email-alexd@afterthoughtsoftware.com>

---
 openbsc/src/libbsc/bts_ipaccess_nanobts.c |    6 +++---
 openbsc/src/libbsc/bts_sysmobts.c         |    4 ++++
 openbsc/src/libmsc/gsm_04_08.c            |    1 +
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/openbsc/src/libbsc/bts_ipaccess_nanobts.c b/openbsc/src/libbsc/bts_ipaccess_nanobts.c
index 16f6a6b..c20d240 100644
--- a/openbsc/src/libbsc/bts_ipaccess_nanobts.c
+++ b/openbsc/src/libbsc/bts_ipaccess_nanobts.c
@@ -280,7 +280,7 @@ static int nm_statechg_event(int evt, struct nm_statechg_signal_data *nsd)
 	struct gsm_bts_trx_ts *ts;
 	struct gsm_bts_gprs_nsvc *nsvc;
 
-	if (nsd->bts->type != GSM_BTS_TYPE_NANOBTS)
+	if (!is_ipaccess_bts(nsd->bts))
 		return 0;
 
 	/* This event-driven BTS setup is currently only required on nanoBTS */
@@ -400,7 +400,7 @@ static int sw_activ_rep(struct msgb *mb)
 	if (!trx)
 		return -EINVAL;
 
-	if (trx->bts->type != GSM_BTS_TYPE_NANOBTS)
+	if (!is_ipaccess_bts(trx->bts))
 		return 0;
 
 	switch (foh->obj_class) {
@@ -460,7 +460,7 @@ int bts_ipa_nm_sig_cb(unsigned int subsys, unsigned int signal,
 	return 0;
 }
 
-static struct gsm_network *ipaccess_gsmnet;
+struct gsm_network *ipaccess_gsmnet;
 
 static int bts_model_nanobts_start(struct gsm_network *net)
 {
diff --git a/openbsc/src/libbsc/bts_sysmobts.c b/openbsc/src/libbsc/bts_sysmobts.c
index 9479206..0f0b6eb 100644
--- a/openbsc/src/libbsc/bts_sysmobts.c
+++ b/openbsc/src/libbsc/bts_sysmobts.c
@@ -45,6 +45,8 @@ extern struct gsm_bts_model bts_model_nanobts;
 
 static struct gsm_bts_model model_sysmobts;
 
+extern struct gsm_network *ipaccess_gsmnet;
+
 static int bts_model_sysmobts_start(struct gsm_network *net)
 {
 	model_sysmobts.features.data = &model_sysmobts._features_data[0];
@@ -56,6 +58,8 @@ static int bts_model_sysmobts_start(struct gsm_network *net)
 
 	osmo_signal_register_handler(SS_NM, bts_ipa_nm_sig_cb, NULL);
 
+	ipaccess_gsmnet = net;
+
 	return 0;
 }
 
diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c
index e560653..30be610 100644
--- a/openbsc/src/libmsc/gsm_04_08.c
+++ b/openbsc/src/libmsc/gsm_04_08.c
@@ -1774,6 +1774,7 @@ int tch_frame_down(struct gsm_network *net, uint32_t callref, struct gsm_data_fr
 	}
 	bts = trans->conn->lchan->ts->trx->bts;
 	switch (bts->type) {
+	case GSM_BTS_TYPE_OSMO_SYSMO:
 	case GSM_BTS_TYPE_NANOBTS:
 		if (!trans->conn->lchan->abis_ip.rtp_socket) {
 			DEBUGP(DMNCC, "TCH frame to lchan without RTP connection\n");
-- 
1.7.9.5




From andreas at eversberg.eu  Sat Apr 27 11:23:48 2013
From: andreas at eversberg.eu (jolly)
Date: Sat, 27 Apr 2013 13:23:48 +0200
Subject: [PATCH (for jolly/testing)] Fixed seg fault when using sysmobts
	and	added sysmo enum to tch_frame_down
In-Reply-To: <1367005560-5270-1-git-send-email-alexd@afterthoughtsoftware.com>
References: <1367005560-5270-1-git-send-email-alexd@afterthoughtsoftware.com>
Message-ID: <517BB544.4070907@eversberg.eu>

hi alex,

i just pushed it to jolly/testing branch. it would be interesting to
have this in master branch soon, since using sysmo-bts by setting
ipaccess type would result in slot configuration restrictions, which
sysmo-bts does not have.

best regards,

andreas




From holger at freyther.de  Sat Apr 27 13:03:01 2013
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sat, 27 Apr 2013 15:03:01 +0200
Subject: [PATCH (for jolly/testing)] Fixed seg fault when using sysmobts
	and	added sysmo enum to tch_frame_down
In-Reply-To: <517BB544.4070907@eversberg.eu>
References: <1367005560-5270-1-git-send-email-alexd@afterthoughtsoftware.com>
	<517BB544.4070907@eversberg.eu>
Message-ID: <20130427130301.GA10666@xiaoyu.lan>

On Sat, Apr 27, 2013 at 01:23:48PM +0200, jolly wrote:
> hi alex,
> 
> i just pushed it to jolly/testing branch. it would be interesting to
> have this in master branch soon, since using sysmo-bts by setting
> ipaccess type would result in slot configuration restrictions, which
> sysmo-bts does not have.

I will integrate zecke/features/sysmobts to master soon. It fixes the
crash, initialisation and operating an nanoBTS/sysmoBTS network. The
tch_frame change only applies to your branch though.

holger

PS: thanks alex for sharing your patch



From dchardware at gmail.com  Tue Apr 30 21:20:37 2013
From: dchardware at gmail.com (Sipos Csaba)
Date: Tue, 30 Apr 2013 23:20:37 +0200
Subject: Nokia InSite GPRS
Message-ID: <542853694.20130430232037@freemail.hu>

Hi,

We have two Nokia Insite BTSs and now we are configuring it to work
with OpenBSC.

But after we installed all the necessary parts (OpenGGSN, OpenSGSN,
OpenBSC) we got the following message:

"This BTS type does not support gprs"

I just wanted to ask that maybe we did something wrong, or the GPRS
support for Nokia InSite is not ready yet?

If the support is not ready yet maybe there is some alfa or beta stage
version that we can try?

Nokia Insite family supports GRPS CS-1 and CS-2 according to the
specification.

Thanks in advance!

Csaba






From 246tnt at gmail.com  Tue Apr 30 22:02:49 2013
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 1 May 2013 00:02:49 +0200
Subject: Nokia InSite GPRS
In-Reply-To: <542853694.20130430232037@freemail.hu>
References: <542853694.20130430232037@freemail.hu>
Message-ID: <CAHL+j09q9Lub86t0KA9_07+E_Z_=tcO=SWE+V6ymZTzPxjJjWg@mail.gmail.com>

Hi,

> I just wanted to ask that maybe we did something wrong, or the GPRS
> support for Nokia InSite is not ready yet?

It's not ready, no one even looked at it much AFAIK.

Those BTS don't have a built-in PCU so you need to implement that.
There is a PCU being worked on, but targeted at openbts/osmo-bts (i.e.
IP based bts), it can prbably be used as a base to support GPRS on the
in-site but it's still a bunch of non-trivial dev-work.


> If the support is not ready yet maybe there is some alfa or beta stage
> version that we can try?

Nope, not that I know.
And I don't even think anyone is working on it.


Cheers,

    Sylvain