From zecke at selfish.org  Tue Jun  2 02:04:54 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 2 Jun 2009 04:04:54 +0200
Subject: Mac OS X - include file patch
In-Reply-To: <4A152659.6010105@ibp.de>
References: <B16317F2B1592B4492FC414114171CE64D237F@FLBVEXCH01.versatel.local>
	<20090521073403.GJ4021@prithivi.gnumonks.org>
	<4A152659.6010105@ibp.de>
Message-ID: <200906020404.54868.zecke@selfish.org>

On Thursday 21 May 2009 12:00:57 Lars Immisch wrote:

> Compiles on OS X and Linux and reenables crypt.

Patch looked good, sorry for the delay on applying it.

	z.




From laforge at gnumonks.org  Tue Jun  2 12:52:15 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 2 Jun 2009 14:52:15 +0200
Subject: patch: 8_paging
In-Reply-To: <B16317F2B1592B4492FC414114171CE659534B@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE659534B@FLBVEXCH01.versatel.local>
Message-ID: <20090602125215.GC9823@prithivi.gnumonks.org>

Dear Andreas,

I've been offline for a number of days, so please excuse my delay in applying
the second half of your patches.  I'll carefully review them durin the next
week or so and hopefully merge everything before June 6.

Regards,

-- 
- 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 bouchtaoui at gmail.com  Mon Jun 22 13:42:08 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Mon, 22 Jun 2009 15:42:08 +0200
Subject: Trying to understanding the source
In-Reply-To: <20090526185009.GB4024@prithivi.gnumonks.org>
References: <4A1C085D.50402@gmail.com>
	<20090526185009.GB4024@prithivi.gnumonks.org>
Message-ID: <4A3F8A30.1080900@gmail.com>

Hi guys,

I added SI 13 structure to "support" GPRS, just to test my PDA-phone out.
What I did after defining SI 13 struct is just this bsc_hack.c:

static const struct bcch_info bcch_infos[] = {
        {
                .type = RSL_SYSTEM_INFO_1,
                .len = sizeof(si1),
                .data = si1,
        }, {
                .type = RSL_SYSTEM_INFO_2,
                .len = sizeof(si2),
                .data = si2,
        }, {
                .type = RSL_SYSTEM_INFO_3,
                .len = sizeof(si3),
                .data = si3,
        }, {
                .type = RSL_SYSTEM_INFO_4,
                .len = sizeof(si4),
                .data = si4,
        },
        /* our SI 13 struct object for faking GPRS */
        {
                .type = RSL_SYSTEM_INFO_13,
                .len = sizeof(si13),
                .data = si13,
        },
};

I assumed that this is the way to put SI 13 in the BCCH.
Should that be enough, or am I thinking too easy?
It might be a silly question, but I'm studying 4, 5 things at once, 
which freaks me out sometimes.





From bouchtaoui at gmail.com  Fri Jun  5 12:35:39 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Fri, 05 Jun 2009 14:35:39 +0200
Subject: Trying to understanding the source
Message-ID: <4A29111B.7030604@gmail.com>

Hi guys,

I'm a bit ashamed to ask, but I'll ask anyway, could someone help me 
explaining the OpenBSC source?

make_sock():
I didn't know it's possible to call select() on a read signal to finally 
call the accept() for the socket_fd. Logically seen, socket_fd receives 
something (in this case a new connection), so it works. I just thought 
select() is only used for reading/writing data (or an except) on file 
descriptors.

Why is OpenBSC written to work synchronously and not multihtreaded? If 
somewhere in the chain hangs (by a bug), telnet for example won't 
respond, right? What is the idea behind this concept? Is it a popular 
concept in the Linux world (so I can be familiar with)?

Which other functions does timer.c has besides returning a timevalue for 
the select() call (nearest_timer) time-out. I mean what more other 
purposes has timer.c Cause I don't really understand why timer_values 
also be put in a doubly linked list...

That's all for now, I might ask some more questions, but after some 
studying :s

Thank you.

P.S: I do have experience in C/C++ programming....in Bill Gates 
environment. I know.....I'm sorry.





From laforge at gnumonks.org  Fri Jun  5 13:21:00 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 5 Jun 2009 15:21:00 +0200
Subject: Trying to understanding the source
In-Reply-To: <4A29111B.7030604@gmail.com>
References: <4A29111B.7030604@gmail.com>
Message-ID: <20090605132100.GQ4421@prithivi.gnumonks.org>

On Fri, Jun 05, 2009 at 02:35:39PM +0200, Nordin wrote:
> Hi guys,
>
> I'm a bit ashamed to ask, but I'll ask anyway, could someone help me  
> explaining the OpenBSC source?
>
> make_sock():
> I didn't know it's possible to call select() on a read signal to finally  
> call the accept() for the socket_fd. Logically seen, socket_fd receives  
> something (in this case a new connection), so it works. I just thought  
> select() is only used for reading/writing data (or an except) on file  
> descriptors.

This is normal operation for asynchronous select() based network daemons.

> Why is OpenBSC written to work synchronously and not multihtreaded? If  
> somewhere in the chain hangs (by a bug), telnet for example won't  
> respond, right? What is the idea behind this concept? 

The idea is to avoid the significant increase in complexity making all data
structures and the code architecture thread safe, avoid race conditions,
etc.

Threads just horribly complicate things, and typically they're not really
needed.

As indicated, I'm perfectly fine with putting the actual voice data processing
and TRAU muxing into a separate process.  But more than that would be simply
over-engineering.  We're not trying to build a commercial grade BSC with
hundreds of BTS and [tens of] thousands of handsets roaming back and forth
between them.

We want to build something simple for protocol and security experiments,
which will likely only see deployment in small setups.

So we stick to KISS (Keep It Simple / Stupid)

> Is it a popular  concept in the Linux world (so I can be familiar with)?

Yes, I think it is fairly popular in the unix network daemon world.

> Which other functions does timer.c has besides returning a timevalue for  
> the select() call (nearest_timer) time-out. I mean what more other  
> purposes has timer.c Cause I don't really understand why timer_values  
> also be put in a doubly linked list...

it manages a list of timers, and determines the timeout to the shortest
current timer.  once a timer expires, it calls the per-timer specific callback
functoin.

Regards,
-- 
- 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 lars at ibp.de  Fri Jun  5 21:45:02 2009
From: lars at ibp.de (Lars Immisch)
Date: Fri, 05 Jun 2009 23:45:02 +0200
Subject: Trying to understanding the source
In-Reply-To: <4A29111B.7030604@gmail.com>
References: <4A29111B.7030604@gmail.com>
Message-ID: <4A2991DE.2040909@ibp.de>

Naordin,

> I'm a bit ashamed to ask, but I'll ask anyway, could someone help me 
> explaining the OpenBSC source?
> 
> make_sock():
> I didn't know it's possible to call select() on a read signal to finally 
> call the accept() for the socket_fd. Logically seen, socket_fd receives 
> something (in this case a new connection), so it works. I just thought 
> select() is only used for reading/writing data (or an except) on file 
> descriptors.
> 
> Why is OpenBSC written to work synchronously and not multihtreaded? If 
> somewhere in the chain hangs (by a bug), telnet for example won't 
> respond, right? What is the idea behind this concept? Is it a popular 
> concept in the Linux world (so I can be familiar with)?

This is called the Reactor pattern and it is not at all restricted to 
Linux. It's not synchronous, it's synchronous event dispatching.

This style of programming was popularized with the ACE Framework by 
Douglas Schmidt and a fairly well-known modern-day example is Twisted 
(Python): http://twistedmatrix.com/trac/.

Another - simpler - example is libevent: 
http://www.monkey.org/~provos/libevent/.

Here is a short overview on Wikipedia: 
http://en.wikipedia.org/wiki/Reactor_pattern

- Lars



From bouchtaoui at gmail.com  Mon Jun  8 11:19:15 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Mon, 08 Jun 2009 13:19:15 +0200
Subject: Trying to understanding the source
In-Reply-To: <4A2991DE.2040909@ibp.de>
References: <4A29111B.7030604@gmail.com> <4A2991DE.2040909@ibp.de>
Message-ID: <4A2CF3B3.7010206@gmail.com>

Hi Lars,

Thank you for your explanation and your valuable links.
I really appreciate it.

Greetings,

Nordin.


Lars Immisch schreef:
> Naordin,
>
>> I'm a bit ashamed to ask, but I'll ask anyway, could someone help me 
>> explaining the OpenBSC source?
>>
>> make_sock():
>> I didn't know it's possible to call select() on a read signal to 
>> finally call the accept() for the socket_fd. Logically seen, 
>> socket_fd receives something (in this case a new connection), so it 
>> works. I just thought select() is only used for reading/writing data 
>> (or an except) on file descriptors.
>>
>> Why is OpenBSC written to work synchronously and not multihtreaded? 
>> If somewhere in the chain hangs (by a bug), telnet for example won't 
>> respond, right? What is the idea behind this concept? Is it a popular 
>> concept in the Linux world (so I can be familiar with)?
>
> This is called the Reactor pattern and it is not at all restricted to 
> Linux. It's not synchronous, it's synchronous event dispatching.
>
> This style of programming was popularized with the ACE Framework by 
> Douglas Schmidt and a fairly well-known modern-day example is Twisted 
> (Python): http://twistedmatrix.com/trac/.
>
> Another - simpler - example is libevent: 
> http://www.monkey.org/~provos/libevent/.
>
> Here is a short overview on Wikipedia: 
> http://en.wikipedia.org/wiki/Reactor_pattern
>
> - Lars
>




From laforge at gnumonks.org  Wed Jun  3 13:29:01 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 3 Jun 2009 15:29:01 +0200
Subject: Possible to control the radio strength of a nanoBTS?
In-Reply-To: <4A1E6941.4060005@gmail.com>
References: <4A1E6941.4060005@gmail.com>
Message-ID: <20090603132901.GY9823@prithivi.gnumonks.org>

On Thu, May 28, 2009 at 12:36:49PM +0200, Nordin wrote:
> Hello guys,
>
> While I'm still busy with understanding the OpenBSC sourcecodes and GSM  
> protocols, I wonder if it's possible to control the nanoBTS's  
> transmissionpower. If some additional code is needed, I'd like to give a  
> try with some hints or directions to look at.

Unfortunately we don't know this, as we don't have the ip.access protocol
documentation.  As far as I know, there is no standard command for altering
power levels.

You might be able to control the _initial_ BS power by setting some
TRX or BTS attributes related to that.  But it is my understanding that after the
initial power level, the BS will adjust the power itself on every dedicated
channel.

-- 
- 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 bouchtaoui at gmail.com  Wed Jun  3 15:48:12 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Wed, 03 Jun 2009 17:48:12 +0200
Subject: Possible to control the radio strength of a nanoBTS?
In-Reply-To: <20090603132901.GY9823@prithivi.gnumonks.org>
References: <4A1E6941.4060005@gmail.com>
	<20090603132901.GY9823@prithivi.gnumonks.org>
Message-ID: <4A269B3C.4040002@gmail.com>

Thanks for your response Harald,

Well I read in the mailinglist with the title: BS-11 runs, but no 
Network on my Mobile, date: Thu Apr 2 18:03:24 CEST 2009
about modifying the TRX power for the BS-11, so I could try that too for 
the ip.acces?

Isn't it a bad idea to add abis_nm_bs11_set_trx_power(&bts->trx[0], 
BS11_TRX_POWER_GSM_250mW); in the bootstrap sequence? It won't harm if 
one tries right?



Harald Welte schreef:
> On Thu, May 28, 2009 at 12:36:49PM +0200, Nordin wrote:
>   
>> Hello guys,
>>
>> While I'm still busy with understanding the OpenBSC sourcecodes and GSM  
>> protocols, I wonder if it's possible to control the nanoBTS's  
>> transmissionpower. If some additional code is needed, I'd like to give a  
>> try with some hints or directions to look at.
>>     
>
> Unfortunately we don't know this, as we don't have the ip.access protocol
> documentation.  As far as I know, there is no standard command for altering
> power levels.
>
> You might be able to control the _initial_ BS power by setting some
> TRX or BTS attributes related to that.  But it is my understanding that after the
> initial power level, the BS will adjust the power itself on every dedicated
> channel.
>
>   




From roch at on-waves.com  Wed Jun  3 17:28:19 2009
From: roch at on-waves.com (Roch)
Date: Wed, 03 Jun 2009 17:28:19 +0000
Subject: Possible to control the radio strength of a nanoBTS?
In-Reply-To: <4A269B3C.4040002@gmail.com>
References: <4A1E6941.4060005@gmail.com>	<20090603132901.GY9823@prithivi.gnumonks.org>
	<4A269B3C.4040002@gmail.com>
Message-ID: <4A26B2B3.2050507@on-waves.com>

Hi,

I tried it a few weeks ago, you don't need to do anything to have the 
ip.access BTS transmit.
You don't actually control the output power of the BTS but the 
attenuation of the signal (from 0 to 12 2dB step).

Regards

Roch.

Nordin wrote:
> Thanks for your response Harald,
> 
> Well I read in the mailinglist with the title: BS-11 runs, but no 
> Network on my Mobile, date: Thu Apr 2 18:03:24 CEST 2009
> about modifying the TRX power for the BS-11, so I could try that too for 
> the ip.acces?
> 
> Isn't it a bad idea to add abis_nm_bs11_set_trx_power(&bts->trx[0], 
> BS11_TRX_POWER_GSM_250mW); in the bootstrap sequence? It won't harm if 
> one tries right?
> 
> 
> 
> Harald Welte schreef:
>> On Thu, May 28, 2009 at 12:36:49PM +0200, Nordin wrote:
>>  
>>> Hello guys,
>>>
>>> While I'm still busy with understanding the OpenBSC sourcecodes and 
>>> GSM  protocols, I wonder if it's possible to control the nanoBTS's  
>>> transmissionpower. If some additional code is needed, I'd like to 
>>> give a  try with some hints or directions to look at.
>>>     
>>
>> Unfortunately we don't know this, as we don't have the ip.access protocol
>> documentation.  As far as I know, there is no standard command for 
>> altering
>> power levels.
>>
>> You might be able to control the _initial_ BS power by setting some
>> TRX or BTS attributes related to that.  But it is my understanding 
>> that after the
>> initial power level, the BS will adjust the power itself on every 
>> dedicated
>> channel.
>>
>>   
> 
> 

-- 
Roch-Alexandre Nomin?
CTO
On-Waves ehf
Armuli 25, IS-108, Reykjavik, Iceland
Tel: +354 864 9431



From laforge at gnumonks.org  Wed Jun  3 19:00:23 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 3 Jun 2009 21:00:23 +0200
Subject: Possible to control the radio strength of a nanoBTS?
In-Reply-To: <4A269B3C.4040002@gmail.com>
References: <4A1E6941.4060005@gmail.com>
	<20090603132901.GY9823@prithivi.gnumonks.org>
	<4A269B3C.4040002@gmail.com>
Message-ID: <20090603190023.GG9823@prithivi.gnumonks.org>

On Wed, Jun 03, 2009 at 05:48:12PM +0200, Nordin wrote:
> Thanks for your response Harald,
>
> Well I read in the mailinglist with the title: BS-11 runs, but no  
> Network on my Mobile, date: Thu Apr 2 18:03:24 CEST 2009
> about modifying the TRX power for the BS-11, so I could try that too for  
> the ip.acces?
>
> Isn't it a bad idea to add abis_nm_bs11_set_trx_power(&bts->trx[0],  
> BS11_TRX_POWER_GSM_250mW); in the bootstrap sequence? It won't harm if  
> one tries right?

go ahead and try, but I would bet on just about anything that it does not work.
Those are vendor-specific proprietary extensions of 12.21.  Values defined by
Siemens have no significance whatsoever for ip.access

-- 
- 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 bouchtaoui at gmail.com  Wed Jun  3 20:40:18 2009
From: bouchtaoui at gmail.com (Nordin Bouchtaoui)
Date: Wed, 3 Jun 2009 22:40:18 +0200
Subject: Possible to control the radio strength of a nanoBTS?
In-Reply-To: <20090603190023.GG9823@prithivi.gnumonks.org>
References: <4A1E6941.4060005@gmail.com>
	<20090603132901.GY9823@prithivi.gnumonks.org>
	<4A269B3C.4040002@gmail.com>
	<20090603190023.GG9823@prithivi.gnumonks.org>
Message-ID: <8aedb85a0906031340k52de870ahbcade07c0a27d8e1@mail.gmail.com>

Well I guess you're right. I modified the source as suggested and tried it
out. But there was no difference.

The reason I want to boost up its transmitpower, is because I wanted to test
the handover. If our nanoBTS acts like a commercial provider I just see one
MS trying to register to our nanoBTS. This is because it's just a meter away
from our bts, while my mobile (an HTC Artemis) doesn't register to our bts
with a distance of less than 10 m.
Even when I switch off and on, while I'm just a meter away of our bts, my
mobile somehow keeps registering to the real provider (I tested by simply
calling someone).

Another interesting thing is, if I simulate a total different provider,
which doesn't exist here, I can easely find our bts, with manual search.
Also the MS seems to have its own database of all the country codes,
networkcodes and its belonging providernames. I thought the BSC sends these
information to the MS and the MS checks it with SIM data. (But that;s
off-topic).

Greetings.

2009/6/3 Harald Welte <laforge at gnumonks.org>

> On Wed, Jun 03, 2009 at 05:48:12PM +0200, Nordin wrote:
> > Thanks for your response Harald,
> >
> > Well I read in the mailinglist with the title: BS-11 runs, but no
> > Network on my Mobile, date: Thu Apr 2 18:03:24 CEST 2009
> > about modifying the TRX power for the BS-11, so I could try that too for
> > the ip.acces?
> >
> > Isn't it a bad idea to add abis_nm_bs11_set_trx_power(&bts->trx[0],
> > BS11_TRX_POWER_GSM_250mW); in the bootstrap sequence? It won't harm if
> > one tries right?
>
> go ahead and try, but I would bet on just about anything that it does not
> work.
> Those are vendor-specific proprietary extensions of 12.21.  Values defined
> by
> Siemens have no significance whatsoever for ip.access
>
> --
> - 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090603/caabd706/attachment.htm>

From laforge at gnumonks.org  Wed Jun  3 21:24:50 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 3 Jun 2009 23:24:50 +0200
Subject: Possible to control the radio strength of a nanoBTS?
In-Reply-To: <8aedb85a0906031340k52de870ahbcade07c0a27d8e1@mail.gmail.com>
References: <4A1E6941.4060005@gmail.com>
	<20090603132901.GY9823@prithivi.gnumonks.org>
	<4A269B3C.4040002@gmail.com>
	<20090603190023.GG9823@prithivi.gnumonks.org>
	<8aedb85a0906031340k52de870ahbcade07c0a27d8e1@mail.gmail.com>
Message-ID: <20090603212450.GJ9823@prithivi.gnumonks.org>

On Wed, Jun 03, 2009 at 10:40:18PM +0200, Nordin Bouchtaoui wrote:
> Well I guess you're right. I modified the source as suggested and tried it
> out. But there was no difference.
> 
> The reason I want to boost up its transmitpower, is because I wanted to test
> the handover. 

There is certainly no way to 'boost' the power from the nanoBTS, since it
is specified to something like 250mW max output power.  The BS-11 has 3W
max output.

> Even when I switch off and on, while I'm just a meter away of our bts, my
> mobile somehow keeps registering to the real provider (I tested by simply
> calling someone).

That's quite obvious if you understand the details of the cell selection
algorithm.  If you've been registered to an actual cell of the operator before,
then that ARFCN/LAC is stored on the SIM card even when you shut off the phone.

So the phone will first try to register to that cell again before scanning the
entire band.

> Another interesting thing is, if I simulate a total different provider,
> which doesn't exist here, I can easely find our bts, with manual search.

of course.

> Also the MS seems to have its own database of all the country codes,
> networkcodes and its belonging providernames. I thought the BSC sends these
> information to the MS and the MS checks it with SIM data. (But that;s
> off-topic).

The BTS only sends numeric ID's in the BCCH.  Only _after_ you register, the
BTS (well, actually the BSC) sends a MM INFO message with the string-name of
the network.

So yes, typically the translation of mcc/mnc happens in a table on the SIM
card, and if that fails in a table that is included at compile time into the
GSM firmware of the handset.

-- 
- 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090603/35d1b7e8/attachment.bin>

From bouchtaoui at gmail.com  Thu Jun  4 09:40:05 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Thu, 04 Jun 2009 11:40:05 +0200
Subject: Possible to control the radio strength of a nanoBTS?
In-Reply-To: <20090603212450.GJ9823@prithivi.gnumonks.org>
References: <4A1E6941.4060005@gmail.com>
	<20090603132901.GY9823@prithivi.gnumonks.org>
	<4A269B3C.4040002@gmail.com>
	<20090603190023.GG9823@prithivi.gnumonks.org>
	<8aedb85a0906031340k52de870ahbcade07c0a27d8e1@mail.gmail.com>
	<20090603212450.GJ9823@prithivi.gnumonks.org>
Message-ID: <4A279675.5030602@gmail.com>


> That's quite obvious if you understand the details of the cell selection
> algorithm.  If you've been registered to an actual cell of the operator before,
> then that ARFCN/LAC is stored on the SIM card even when you shut off the phone.
>
> So the phone will first try to register to that cell again before scanning the
> entire band.
>
>   
Ahaa, that's an important detail I have missed!
Thank you ;-)




From roch at on-waves.com  Thu Jun  4 10:27:44 2009
From: roch at on-waves.com (Roch)
Date: Thu, 04 Jun 2009 10:27:44 +0000
Subject: Possible to control the radio strength of a nanoBTS?
In-Reply-To: <4A279675.5030602@gmail.com>
References: <4A1E6941.4060005@gmail.com>	<20090603132901.GY9823@prithivi.gnumonks.org>	<4A269B3C.4040002@gmail.com>	<20090603190023.GG9823@prithivi.gnumonks.org>	<8aedb85a0906031340k52de870ahbcade07c0a27d8e1@mail.gmail.com>	<20090603212450.GJ9823@prithivi.gnumonks.org>
	<4A279675.5030602@gmail.com>
Message-ID: <4A27A1A0.7060603@on-waves.com>

Hi,

Another thing: if your mobile phone is set to auto it will always 
register on its home network (if available) even if the signal of your 
basestation is far stronger.

Roch.

Nordin wrote:
> 
>> That's quite obvious if you understand the details of the cell selection
>> algorithm.  If you've been registered to an actual cell of the 
>> operator before,
>> then that ARFCN/LAC is stored on the SIM card even when you shut off 
>> the phone.
>>
>> So the phone will first try to register to that cell again before 
>> scanning the
>> entire band.
>>
>>   
> Ahaa, that's an important detail I have missed!
> Thank you ;-)
> 
> 

-- 
Roch-Alexandre Nomin?
CTO
On-Waves ehf
Armuli 25, IS-108, Reykjavik, Iceland
Tel: +354 864 9431



From bouchtaoui at gmail.com  Thu Jun  4 10:45:36 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Thu, 04 Jun 2009 12:45:36 +0200
Subject: Possible to control the radio strength of a nanoBTS?
In-Reply-To: <4A27A1A0.7060603@on-waves.com>
References: <4A1E6941.4060005@gmail.com>	<20090603132901.GY9823@prithivi.gnumonks.org>	<4A269B3C.4040002@gmail.com>	<20090603190023.GG9823@prithivi.gnumonks.org>	<8aedb85a0906031340k52de870ahbcade07c0a27d8e1@mail.gmail.com>	<20090603212450.GJ9823@prithivi.gnumonks.org>
	<4A279675.5030602@gmail.com> <4A27A1A0.7060603@on-waves.com>
Message-ID: <4A27A5D0.7050802@gmail.com>

Hi Roch,

>
> Another thing: if your mobile phone is set to auto it will always 
> register on its home network (if available) even if the signal of your 
> basestation is far stronger.
>

Can you specify home network?
Cause according to Harald and Dieter, a MS saves the latest ARFCN, LAC, 
TMSI and some other parameters in the SIM in a so called Elementary 
Files (yes, time to time I do my homework :p ). And since a mobilephone 
is suppose to be mobile, than "home network" makes no sense to me. But 
maybe I missed a chapter about how GSM works.





From roch at on-waves.com  Thu Jun  4 10:54:14 2009
From: roch at on-waves.com (Roch)
Date: Thu, 04 Jun 2009 10:54:14 +0000
Subject: Possible to control the radio strength of a nanoBTS?
In-Reply-To: <4A27A5D0.7050802@gmail.com>
References: <4A1E6941.4060005@gmail.com>	<20090603132901.GY9823@prithivi.gnumonks.org>	<4A269B3C.4040002@gmail.com>	<20090603190023.GG9823@prithivi.gnumonks.org>	<8aedb85a0906031340k52de870ahbcade07c0a27d8e1@mail.gmail.com>	<20090603212450.GJ9823@prithivi.gnumonks.org>
	<4A279675.5030602@gmail.com> <4A27A1A0.7060603@on-waves.com>
	<4A27A5D0.7050802@gmail.com>
Message-ID: <4A27A7D6.3050506@on-waves.com>

Hi Nordin,

The Sim card contains the MCC/MNC of your home network (along with a 
list of preferred and banned networks).

Roch.

Nordin wrote:
> Hi Roch,
> 
>>
>> Another thing: if your mobile phone is set to auto it will always 
>> register on its home network (if available) even if the signal of your 
>> basestation is far stronger.
>>
> 
> Can you specify home network?
> Cause according to Harald and Dieter, a MS saves the latest ARFCN, LAC, 
> TMSI and some other parameters in the SIM in a so called Elementary 
> Files (yes, time to time I do my homework :p ). And since a mobilephone 
> is suppose to be mobile, than "home network" makes no sense to me. But 
> maybe I missed a chapter about how GSM works.
> 
> 

-- 
Roch-Alexandre Nomin?
CTO
On-Waves ehf
Armuli 25, IS-108, Reykjavik, Iceland
Tel: +354 864 9431



From laforge at gnumonks.org  Thu Jun  4 12:14:33 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 4 Jun 2009 14:14:33 +0200
Subject: Possible to control the radio strength of a nanoBTS?
In-Reply-To: <4A27A5D0.7050802@gmail.com>
References: <4A1E6941.4060005@gmail.com>
	<20090603132901.GY9823@prithivi.gnumonks.org>
	<4A269B3C.4040002@gmail.com>
	<20090603190023.GG9823@prithivi.gnumonks.org>
	<8aedb85a0906031340k52de870ahbcade07c0a27d8e1@mail.gmail.com>
	<20090603212450.GJ9823@prithivi.gnumonks.org>
	<4A279675.5030602@gmail.com> <4A27A1A0.7060603@on-waves.com>
	<4A27A5D0.7050802@gmail.com>
Message-ID: <20090604121433.GR9823@prithivi.gnumonks.org>

On Thu, Jun 04, 2009 at 12:45:36PM +0200, Nordin wrote:
> Hi Roch,
>
>>
>> Another thing: if your mobile phone is set to auto it will always  
>> register on its home network (if available) even if the signal of your  
>> basestation is far stronger.
>>
>
> Can you specify home network?

the network that has issued the sim card.  technically: the network with
the MCC and MNC of the IMSI of th SIM.

-- 
- 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090604/2b84215d/attachment.bin>

From bouchtaoui at gmail.com  Thu Jun  4 12:49:21 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Thu, 04 Jun 2009 14:49:21 +0200
Subject: Possible to control the radio strength of a nanoBTS?
In-Reply-To: <20090604121433.GR9823@prithivi.gnumonks.org>
References: <4A1E6941.4060005@gmail.com>
	<20090603132901.GY9823@prithivi.gnumonks.org>
	<4A269B3C.4040002@gmail.com>
	<20090603190023.GG9823@prithivi.gnumonks.org>
	<8aedb85a0906031340k52de870ahbcade07c0a27d8e1@mail.gmail.com>
	<20090603212450.GJ9823@prithivi.gnumonks.org>
	<4A279675.5030602@gmail.com> <4A27A1A0.7060603@on-waves.com>
	<4A27A5D0.7050802@gmail.com>
	<20090604121433.GR9823@prithivi.gnumonks.org>
Message-ID: <4A27C2D1.6010508@gmail.com>

Harald Welte schreef:
> On Thu, Jun 04, 2009 at 12:45:36PM +0200, Nordin wrote:
>   
>> Hi Roch,
>>
>>     
>>> Another thing: if your mobile phone is set to auto it will always  
>>> register on its home network (if available) even if the signal of your  
>>> basestation is far stronger.
>>>
>>>       
>> Can you specify home network?
>>     
>
> the network that has issued the sim card.  technically: the network with
> the MCC and MNC of the IMSI of th SIM.
>
>   
Yes, that's obvious.
But if my BTS has the same ARFCN, besides the MCC and the MNC,  as the 
mobile has tuned to, than it's possible that the mobile tries to 
register to my BTS.
That's why I think our gsm-module (gsm for our servers) automatically 
tries to register to my BTS. A nice detail, after 4 times, the 
gsm-module stops trying to register to our BTS. I guess, that's an 
algorithm (maybe vendor-specific), to search for other available 
channels (ARFCNs).





From laforge at gnumonks.org  Thu Jun  4 15:18:02 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 4 Jun 2009 17:18:02 +0200
Subject: Possible to control the radio strength of a nanoBTS?
In-Reply-To: <4A27C2D1.6010508@gmail.com>
References: <20090603132901.GY9823@prithivi.gnumonks.org>
	<4A269B3C.4040002@gmail.com>
	<20090603190023.GG9823@prithivi.gnumonks.org>
	<8aedb85a0906031340k52de870ahbcade07c0a27d8e1@mail.gmail.com>
	<20090603212450.GJ9823@prithivi.gnumonks.org>
	<4A279675.5030602@gmail.com> <4A27A1A0.7060603@on-waves.com>
	<4A27A5D0.7050802@gmail.com>
	<20090604121433.GR9823@prithivi.gnumonks.org>
	<4A27C2D1.6010508@gmail.com>
Message-ID: <20090604151802.GU9823@prithivi.gnumonks.org>

On Thu, Jun 04, 2009 at 02:49:21PM +0200, Nordin wrote:
> Harald Welte schreef:
>> On Thu, Jun 04, 2009 at 12:45:36PM +0200, Nordin wrote:
>>   
>>> Hi Roch,
>>>
>>>     
>>>> Another thing: if your mobile phone is set to auto it will always   
>>>> register on its home network (if available) even if the signal of 
>>>> your  basestation is far stronger.
>>>>
>>>>       
>>> Can you specify home network?
>>>     
>>
>> the network that has issued the sim card.  technically: the network with
>> the MCC and MNC of the IMSI of th SIM.
>>
>>   
> Yes, that's obvious.
> But if my BTS has the same ARFCN, besides the MCC and the MNC,  as the  
> mobile has tuned to, than it's possible that the mobile tries to  
> register to my BTS.

Also don't forget to make sure the BSIC and possibly even TSC is the same.

> That's why I think our gsm-module (gsm for our servers) automatically  
> tries to register to my BTS. A nice detail, after 4 times, the  
> gsm-module stops trying to register to our BTS. I guess, that's an  
> algorithm (maybe vendor-specific), to search for other available  
> channels (ARFCNs).

it's very clearly specified in the GSM specs into every possible detail.  I
don't remember which one, though.

-- 
- 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 Juha.Tuomala at iki.fi  Thu Jun  4 13:33:07 2009
From: Juha.Tuomala at iki.fi (Juha Tuomala)
Date: Thu, 4 Jun 2009 16:33:07 +0300
Subject: Possible to control the radio strength of a nanoBTS?
In-Reply-To: <4A27A5D0.7050802@gmail.com>
References: <4A1E6941.4060005@gmail.com> <4A27A1A0.7060603@on-waves.com>
	<4A27A5D0.7050802@gmail.com>
Message-ID: <200906041633.07746.Juha.Tuomala@iki.fi>




On Thursday 04 June 2009 13:45:36 Nordin wrote:
> Can you specify home network?
> Cause according to Harald and Dieter, a MS saves the latest ARFCN, LAC, 
> TMSI and some other parameters in the SIM in a so called Elementary 
> Files (yes, time to time I do my homework :p ). And since a mobilephone 
> is suppose to be mobile, than "home network" makes no sense to me. But 
> maybe I missed a chapter about how GSM works.

Yes, this would be intresting. If you could hack your sim 
preferred ROAMing list and the home network, then it would
always pick your own BTS when you're close it?

I'm afraid that sounds bit too good to be possible.


Tuju

-- 
Better to have one, and not need it, than to need one and not have it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090604/5f245c7a/attachment.htm>

From benny at benny.de  Thu Jun  4 17:01:17 2009
From: benny at benny.de (Benjamin Hagemann)
Date: Thu, 4 Jun 2009 19:01:17 +0200
Subject: own sim? - was: Re: Possible to control the radio strength of a
	nanoBTS?
In-Reply-To: <200906041633.07746.Juha.Tuomala@iki.fi>
References: <4A1E6941.4060005@gmail.com> <4A27A1A0.7060603@on-waves.com>
	<4A27A5D0.7050802@gmail.com>
	<200906041633.07746.Juha.Tuomala@iki.fi>
Message-ID: <20090604170117.GP12204@benny.de>

hello,

* Juha Tuomala <Juha.Tuomala at iki.fi> [2009-06-04 15:34]:
> On Thursday 04 June 2009 13:45:36 Nordin wrote:
> > Can you specify home network?
> > Cause according to Harald and Dieter, a MS saves the latest ARFCN, LAC, 
> > TMSI and some other parameters in the SIM in a so called Elementary 
> > Files (yes, time to time I do my homework :p ). And since a mobilephone 
> > is suppose to be mobile, than "home network" makes no sense to me. But 
> > maybe I missed a chapter about how GSM works.
> 
> Yes, this would be intresting. If you could hack your sim 
> preferred ROAMing list and the home network, then it would
> always pick your own BTS when you're close it?
> 
> I'm afraid that sounds bit too good to be possible.

would it make sense to programm own SIM cards?
I found eq this shop: http://www.sim-max.biz/store/catalog.php
and I'm sure, there are more shops with blanko SIMs and programmer hw.

Sure it is more easy when a T-D1, Vodafone or other official SIM could
join a openbsc cell, but so we could make an other part of GSM for
ourselves - the SIM.

-- 
Mit freundlichen Gr??en,

	Benjamin Hagemann

instant messaging : jabber  benny at benny.de
crypto-public-key : gpg     0xFC505AB0
internettelephonie: sip     benny at benny.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090604/d161df83/attachment.bin>

From bouchtaoui at gmail.com  Mon Jun 15 10:49:48 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Mon, 15 Jun 2009 12:49:48 +0200
Subject: Possible to control the radio strength of a nanoBTS?
In-Reply-To: <200906041633.07746.Juha.Tuomala@iki.fi>
References: <4A1E6941.4060005@gmail.com>
	<4A27A1A0.7060603@on-waves.com>	<4A27A5D0.7050802@gmail.com>
	<200906041633.07746.Juha.Tuomala@iki.fi>
Message-ID: <4A36274C.30207@gmail.com>

Hello guys,

Antoher interesting thing I found, is when trying to force the mobile to 
register to the nanoBTS by simulating a commecrial provider, the classic 
mobilephones like a Nokia 6230, 6310i or a Siemens MC 60 do register to 
the nanoBTS. But PocketPCs like the HTCs (artemis, Diamond Touch, 
Qtek9090 and others of the same factory) just loses its signal or 
refuses to change bts.

I haven't tested more mobilephones yet, but it's a bit strange that 
untill now it's succesful with normal mobilephones, but not with PDAs 
with integrated gsm module. Maybe the PDAs also checks for the 
availability of GPRS before registering to the BTS?
I don't know if that kind of information is provided in the Broadcast 
channel (BCCH). I'll check it out.

regards,

Nordin.






From spaar at mirider.augusta.de  Thu Jun  4 09:32:12 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Thu, 04 Jun 2009 09:32:12 CEST
Subject: Possible to control the radio strength of a nanoBTS?
Message-ID: <4a27949c.mirider@mirider.augusta.de>

Hello Harald,

On Wed, 3 Jun 2009 23:24:50 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> 
> The BS-11 has 3W max output.

I think we have 2 Watt maximum, 3 Watt is the maximum for the 1800/1900
variant of the BS-11.

> That's quite obvious if you understand the details of the cell selection
> algorithm.  If you've been registered to an actual cell of the operator
> before, then that ARFCN/LAC is stored on the SIM card even when you shut
> off the phone.

Let me add a few more detail (I sent this to the list a while ago).
There are two EFs (Elementary Files) on the SIM which contain this
information:

  - EF_BCCH contains the cell allocation information from
    "SYSTEM INFORMATION 2".

  - EF_LOCI contains the TMSI, Location Update Timer, LAI and the
    status of the location update.

If those EFs are set to the correct values used by the test cell, the
phone will immediately look for the test cell when powered on and also
consider to be "registered" if no "IMSI Attach" is required.

> So yes, typically the translation of mcc/mnc happens in a table on the SIM
> card, and if that fails in a table that is included at compile time into the
> GSM firmware of the handset.

It seems that the mapping of MCC/MNC to names on the SIM was introduced
with GSM 31.102 (USIM for UMTS), GSM 11.11 did not have it. So it depends
on the SIM if it has this mapping. I looked at some phone firmware, in
this special case the mapping is done by looking at the SIM first (if it 
is an USIM), than at an optional table in the phone filesystem and finally
at the table in the firmware.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From spaar at mirider.augusta.de  Mon Jun 15 13:14:57 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Mon, 15 Jun 2009 13:14:57 CEST
Subject: Possible to control the radio strength of a nanoBTS?
Message-ID: <4a364951.mirider@mirider.augusta.de>

Hello Nordin,

On Mon, 15 Jun 2009 12:49:48 +0200, "Nordin" <bouchtaoui at gmail.com> wrote:
>
> I don't know if that kind of information is provided in the Broadcast 
> channel (BCCH). I'll check it out.

GPRS is indicated through the SYSTEM INFORMATION on the BCCH. bsc_hack
doese not (yet) indicate it.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From Andreas.Eversberg at versatel.de  Mon Jun  1 17:33:43 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 1 Jun 2009 19:33:43 +0200
Subject: patch 12 14, 15, 16
Message-ID: <B16317F2B1592B4492FC414114171CE66A9027@FLBVEXCH01.versatel.local>

The patch 14 and 16 have been updated. They are not applied yet.
 
Patches 12 and 15 are obsolete.
 
Patch 14 will fix DMM debugging. now MM debugging is shown, if given by
debug option, not only by default debugging. the color of DNM debugging
changes to cyan as it is supposed to be.

Patch 16 will store the current LAC in the HLC when the subscriber
successfully attaches. If the subscriber detaches, the LAC will be set
to 0.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/309b1056/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 14_DMM.patch
Type: application/octet-stream
Size: 607 bytes
Desc: 14_DMM.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/309b1056/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 16_subscr_lac.patch
Type: application/octet-stream
Size: 1533 bytes
Desc: 16_subscr_lac.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/309b1056/attachment-0001.obj>

From zecke at selfish.org  Tue Jun  2 00:30:20 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 2 Jun 2009 02:30:20 +0200
Subject: patch 12 14, 15, 16
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A9027@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A9027@FLBVEXCH01.versatel.local>
Message-ID: <200906020230.20915.zecke@selfish.org>

On Monday 01 June 2009 19:33:43 Andreas.Eversberg wrote:

> Patch 16 will store the current LAC in the HLC when the subscriber
> successfully attaches. If the subscriber detaches, the LAC will be set
> to 0.

I'm not sure what happens to IMSI ATTACHED/DETACHED when doing handover, so 
far the detach path was written in a way that even a sequence like:
	new BTS ATTACHED
	old  BTS DETACHED

would work. I don't know if this will be sequence in real life, but as a 
defensive programmer this sounded reasonable. I will change your patch 16 to 
move that into the if from a couple of lines earlier. if this was a stupid 
idea please provide another patch and highlight were my assumptions were 
wrong.

z.




From zecke at selfish.org  Tue Jun  2 00:34:35 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 2 Jun 2009 02:34:35 +0200
Subject: patch 12 14, 15, 16
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A9027@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A9027@FLBVEXCH01.versatel.local>
Message-ID: <200906020234.36011.zecke@selfish.org>

On Monday 01 June 2009 19:33:43 Andreas.Eversberg wrote:

> Patch 16 will store the current LAC in the HLC when the subscriber
> successfully attaches. If the subscriber detaches, the LAC will be set
> to 0.

And I was too fast. I have one more question. Could you please explain the 
extra call to:
	subscr_update(lchan->subscr, bts, GSM_SUBSCRIBER_UPDATE_ATTACHED);

My thoughts are:
	- How will this be unbalanced (DETACHED)
	- So far the ATTACHED/DETACHED is from the IMSI ATTACHED/DETACHED 
          specification and the above change is loosening "attachment" to 
          something like "last seen". Is this on purpose? Have you thought 
          about this? Do I miss anything?

z.



From Andreas.Eversberg at versatel.de  Tue Jun  2 11:46:22 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 2 Jun 2009 13:46:22 +0200
Subject: AW: patch 12 14, 15, 16
Message-ID: <B16317F2B1592B4492FC414114171CE66A9582@FLBVEXCH01.versatel.local>

 

-----Urspr?ngliche Nachricht-----
Von: openbsc-bounces at lists.gnumonks.org [mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von Holger Freyther
>And I was too fast. I have one more question. Could you please explain the 
>extra call to:
>	subscr_update(lchan->subscr, bts, GSM_SUBSCRIBER_UPDATE_ATTACHED);

i don't know why, but i will check that tonight too.



From Andreas.Eversberg at versatel.de  Wed Jun  3 08:00:39 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Wed, 3 Jun 2009 10:00:39 +0200
Subject: AW: patch 12 14, 15, 16
Message-ID: <B16317F2B1592B4492FC414114171CE66A9A75@FLBVEXCH01.versatel.local>

 

this call makes no sense. maybe i forgot it during testing and debugging.
 

-----Urspr?ngliche Nachricht-----
Von: openbsc-bounces at lists.gnumonks.org [mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von Holger Freyther
>And I was too fast. I have one more question. Could you please explain the 
>extra call to:
>	subscr_update(lchan->subscr, bts, GSM_SUBSCRIBER_UPDATE_ATTACHED);

i don't know why, but i will check that tonight too.




From Andreas.Eversberg at versatel.de  Mon Jun  1 17:33:43 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 1 Jun 2009 19:33:43 +0200
Subject: patch 17: subscr usage
Message-ID: <B16317F2B1592B4492FC414114171CE66A9028@FLBVEXCH01.versatel.local>

This patch will fix subscriber usage counting and adds debugging
whenever usage is increased or decreased.
It may happen, that the subscriber count will not be 0 after releasing
of a call. (This problem is solved with the application patch (27),
which will replace static call transaction by a dynamic transaction
list, and use subscriber for each transaction created.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/21a7b8f8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 17_subscr_usage.patch
Type: application/octet-stream
Size: 1878 bytes
Desc: 17_subscr_usage.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/21a7b8f8/attachment.obj>

From zecke at selfish.org  Tue Jun  2 00:46:03 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 2 Jun 2009 02:46:03 +0200
Subject: patch 17: subscr usage
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A9028@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A9028@FLBVEXCH01.versatel.local>
Message-ID: <200906020246.04258.zecke@selfish.org>

On Monday 01 June 2009 19:33:43 Andreas.Eversberg wrote:
> This patch will fix subscriber usage counting and adds debugging
> whenever usage is increased or decreased.
> It may happen, that the subscriber count will not be 0 after releasing
> of a call. (This problem is solved with the application patch (27),
> which will replace static call transaction by a dynamic transaction
> list, and use subscriber for each transaction created.)

applied, thanks.

z.



From Andreas.Eversberg at versatel.de  Mon Jun  1 17:33:43 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 1 Jun 2009 19:33:43 +0200
Subject: patch 20: autogen
Message-ID: <B16317F2B1592B4492FC414114171CE66A9029@FLBVEXCH01.versatel.local>

Adding "autogen.sh". It generates files like "configure".
 
Question: Do we need this? Without it, I cannot compile OpenBSC.
 
(Patch 18 and 19 do not exist.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/6a21456b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20_autogen.patch
Type: application/octet-stream
Size: 285 bytes
Desc: 20_autogen.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/6a21456b/attachment.obj>

From zecke at selfish.org  Mon Jun  1 23:51:43 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 2 Jun 2009 01:51:43 +0200
Subject: patch 20: autogen
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A9029@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A9029@FLBVEXCH01.versatel.local>
Message-ID: <200906020151.43963.zecke@selfish.org>

On Monday 01 June 2009 19:33:43 Andreas.Eversberg wrote:
> Adding "autogen.sh". It generates files like "configure".
>
> Question: Do we need this? Without it, I cannot compile OpenBSC.

Why is invoking autoreconf not enough?

z.



From Andreas.Eversberg at versatel.de  Tue Jun  2 07:01:09 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 2 Jun 2009 09:01:09 +0200
Subject: AW: patch 20: autogen
Message-ID: <B16317F2B1592B4492FC414114171CE66A9101@FLBVEXCH01.versatel.local>

i don't know what autoreconf is.

root at fuckup:~/gsm/openbsc.orig# autoreconf
configure.in: required file `./install-sh' not found
configure.in: required file `./mkinstalldirs' not found
configure.in: required file `./missing' not found
src/Makefile.am: required file `./depcomp' not found
autoreconf: automake failed with exit status: 1
root at fuckup:~/gsm/openbsc.orig#

maybe i need to update autoconf...
 

>> Adding "autogen.sh". It generates files like "configure".
>>
>> Question: Do we need this? Without it, I cannot compile OpenBSC.
>
>Why is invoking autoreconf not enough?
>
>z.




From zecke at selfish.org  Tue Jun  2 12:00:22 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 2 Jun 2009 14:00:22 +0200
Subject: patch 20: autogen
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A9101@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A9101@FLBVEXCH01.versatel.local>
Message-ID: <200906021400.23221.zecke@selfish.org>

On Tuesday 02 June 2009 09:01:09 Andreas.Eversberg wrote:
> i don't know what autoreconf is.

just run autoreconf --install. The benefit of this over a hand written 
autogen.sh is that you can easily change autoconf and automake versions by 
environment variables...

z.



From Andreas.Eversberg at versatel.de  Mon Jun  1 17:33:44 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 1 Jun 2009 19:33:44 +0200
Subject: patch 23: db fix
Message-ID: <B16317F2B1592B4492FC414114171CE66A902C@FLBVEXCH01.versatel.local>

Fixes the subscriber id type defintion from "long unsigned int" to "long
long unsigned int". Without, printf with '%llu' caused a crash.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/4673be0e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 23_db_fix.patch
Type: application/octet-stream
Size: 487 bytes
Desc: 23_db_fix.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/4673be0e/attachment.obj>

From Andreas.Eversberg at versatel.de  Mon Jun  1 17:33:44 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 1 Jun 2009 19:33:44 +0200
Subject: patch 24: output
Message-ID: <B16317F2B1592B4492FC414114171CE66A902D@FLBVEXCH01.versatel.local>

Some debug outputs now correctly use end-of-line characters.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/c925d99c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 24_output.patch
Type: application/octet-stream
Size: 3676 bytes
Desc: 24_output.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/c925d99c/attachment.obj>

From zecke at selfish.org  Tue Jun  2 01:19:43 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 2 Jun 2009 03:19:43 +0200
Subject: patch 24: output
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A902D@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A902D@FLBVEXCH01.versatel.local>
Message-ID: <200906020319.43765.zecke@selfish.org>

On Monday 01 June 2009 19:33:44 Andreas.Eversberg wrote:
> Some debug outputs now correctly use end-of-line characters.

Mostly applied:

the moving of subscr = subcr_get_by_tmsi didn't match the description and I 
wonder what is the reasoning behind it. For the other debug statements, for 
some new ones I added more than the "\n" but with the below ones I don't see
what value they add. The mi_type is printed a couple of line earlier and a 
simple log that the line of the case was hit didn't look useful to me. Do you 
agree/disagree?

thanks for the patch and looking forward for your comments

	z.


diff --git a/src/gsm_04_08.c b/src/gsm_04_08.c
index d585aae..9a2a00a 100644
--- a/src/gsm_04_08.c
+++ b/src/gsm_04_08.c
@@ -797,9 +797,9 @@ static int gsm48_rx_mm_serv_req(struct msgb *msg)
        }
 
        mi_to_string(mi_string, sizeof(mi_string), mi, mi_len);
-       subscr = subscr_get_by_tmsi(mi_string);
        DEBUGPC(DMM, "serv_type=0x%02x mi_type=0x%02x M(%s)\n",
                req->cm_service_type, mi_type, mi_string);
+       subscr = subscr_get_by_tmsi(mi_string);
 
        /* FIXME: if we don't know the TMSI, inquire abit IMSI and allocate 
new TMSI */
        if (!subscr)
@@ -831,9 +831,11 @@ static int gsm48_rx_mm_imsi_detach_ind(struct msgb *msg)
 
        switch (mi_type) {
        case GSM_MI_TYPE_TMSI:
+               DEBUGPC(DMM, "\n");
                subscr = subscr_get_by_tmsi(mi_string);
                break;
        case GSM_MI_TYPE_IMSI:
+               DEBUGPC(DMM, "\n");
                subscr = subscr_get_by_imsi(mi_string);
                break;
        case GSM_MI_TYPE_IMEI:




From Andreas.Eversberg at versatel.de  Wed Jun  3 07:41:13 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Wed, 3 Jun 2009 09:41:13 +0200
Subject: AW: patch 24: output
Message-ID: <B16317F2B1592B4492FC414114171CE66A9A25@FLBVEXCH01.versatel.local>

the reason for moving "subscr_get_by_tmsi" behind the "DEBUGPC" function is to finish the debug line (using end-of-line) before calling the "subscr_get_by_tmsi" function. the "subscr_get_by_tmsi" function may also do debug output (currently uses printf). without changing it, the debug gets distorted.

-----Urspr?ngliche Nachricht-----
Von: openbsc-bounces at lists.gnumonks.org [mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von Holger Freyther

diff --git a/src/gsm_04_08.c b/src/gsm_04_08.c
index d585aae..9a2a00a 100644
--- a/src/gsm_04_08.c
+++ b/src/gsm_04_08.c
@@ -797,9 +797,9 @@ static int gsm48_rx_mm_serv_req(struct msgb *msg)
        }
 
        mi_to_string(mi_string, sizeof(mi_string), mi, mi_len);
-       subscr = subscr_get_by_tmsi(mi_string);
        DEBUGPC(DMM, "serv_type=0x%02x mi_type=0x%02x M(%s)\n",
                req->cm_service_type, mi_type, mi_string);
+       subscr = subscr_get_by_tmsi(mi_string);
 
        /* FIXME: if we don't know the TMSI, inquire abit IMSI and allocate 
new TMSI */
        if (!subscr)
@@ -831,9 +831,11 @@ static int gsm48_rx_mm_imsi_detach_ind(struct msgb *msg)
 
        switch (mi_type) {
        case GSM_MI_TYPE_TMSI:
+               DEBUGPC(DMM, "\n");
                subscr = subscr_get_by_tmsi(mi_string);
                break;
        case GSM_MI_TYPE_IMSI:
+               DEBUGPC(DMM, "\n");
                subscr = subscr_get_by_imsi(mi_string);
                break;
        case GSM_MI_TYPE_IMEI:





From zecke at selfish.org  Thu Jun  4 13:59:40 2009
From: zecke at selfish.org (Holger Freyther)
Date: Thu, 4 Jun 2009 15:59:40 +0200
Subject: patch 24: output
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A9A25@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A9A25@FLBVEXCH01.versatel.local>
Message-ID: <200906041559.40677.zecke@selfish.org>

On Wednesday 03 June 2009 09:41:13 Andreas.Eversberg wrote:
> the reason for moving "subscr_get_by_tmsi" behind the "DEBUGPC" function is
> to finish the debug line (using end-of-line) before calling the
> "subscr_get_by_tmsi" function. the "subscr_get_by_tmsi" function may also
> do debug output (currently uses printf). without changing it, the debug
> gets distorted.

Applied, I assume you agree that omitting the other two "empty" DEBUGPC is 
good enough as well?



From Andreas.Eversberg at versatel.de  Fri Jun  5 08:29:19 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Fri, 5 Jun 2009 10:29:19 +0200
Subject: AW: patch 24: output
Message-ID: <B16317F2B1592B4492FC414114171CE672753A@FLBVEXCH01.versatel.local>

the two "empty" DEBUGPC do terminate the line ("\n"). never mind, if i find some more distorted debug output during test in the future, i will post them here. 


-----Urspr?ngliche Nachricht-----
Von: openbsc-bounces at lists.gnumonks.org [mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von Holger Freyther
Gesendet: Donnerstag, 4. Juni 2009 16:00
An: openbsc at lists.gnumonks.org
Betreff: Re: patch 24: output

On Wednesday 03 June 2009 09:41:13 Andreas.Eversberg wrote:
> the reason for moving "subscr_get_by_tmsi" behind the "DEBUGPC" function is
> to finish the debug line (using end-of-line) before calling the
> "subscr_get_by_tmsi" function. the "subscr_get_by_tmsi" function may also
> do debug output (currently uses printf). without changing it, the debug
> gets distorted.

Applied, I assume you agree that omitting the other two "empty" DEBUGPC is 
good enough as well?




From Andreas.Eversberg at versatel.de  Mon Jun  1 17:33:44 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 1 Jun 2009 19:33:44 +0200
Subject: patch 22: lchan_use
Message-ID: <B16317F2B1592B4492FC414114171CE66A902B@FLBVEXCH01.versatel.local>

This patch will fix usage counting of logical channel. Also it adds
usage counter debugging.
 
The use counter is increased on loaction update request. The counter is
not decreased when location update responds (mm_rx_id_resp()), but if
subscriber is authorized, it will be decreased on
release_loc_update_req(). If lchan closes, the location update is also
released (release_loc_update_req()), also if the location update times
out.
 
In case of a channel connection failure with cause 0x18, the logical
channel is not released if usage counter of lchan is not 0.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/fdd71465/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 22_lchan_use.patch
Type: application/octet-stream
Size: 4423 bytes
Desc: 22_lchan_use.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/fdd71465/attachment.obj>

From zecke at selfish.org  Tue Jun  2 01:01:52 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 2 Jun 2009 03:01:52 +0200
Subject: patch 22: lchan_use
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A902B@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A902B@FLBVEXCH01.versatel.local>
Message-ID: <200906020301.53113.zecke@selfish.org>

On Monday 01 June 2009 19:33:44 Andreas.Eversberg wrote:
> This patch will fix usage counting of logical channel. Also it adds
> usage counter debugging.
>
> The use counter is increased on loaction update request. The counter is
> not decreased when location update responds (mm_rx_id_resp()), but if
> subscriber is authorized, it will be decreased on
> release_loc_update_req(). If lchan closes, the location update is also
> released (release_loc_update_req()), also if the location update times
> out.

I don't like this part. First of all when making release_loc_update_req 
"public" it should be properly prefixed, but I don't think chan_alloc.c should 
know/care about gsm_04_08.c at all. Also tying the timeout of the Location 
Update with the autorelease of the channel does not seem appropriate.

I would very much prefer if this logic can stay within gsm_04_08.c and we fix 
the usage count issue there.

For me it looks like:
	- We get a reference when creating the loc_update_request
	- We start a timer
	- We put the reference when destroying the loc update request...

	- So we might just remove the extra put/use for the waiting for IMSI/IMEI
          and fix the "leak" like this?


what do you think?


	z.



From Andreas.Eversberg at versatel.de  Tue Jun  2 15:04:33 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 2 Jun 2009 17:04:33 +0200
Subject: AW: patch 22: lchan_use
Message-ID: <B16317F2B1592B4492FC414114171CE66A9842@FLBVEXCH01.versatel.local>

lchan_free() is called when RSL released the logical channel. all ressources that 'uses' the channel, must be released. i aggree with you, that it makes no sense to consider everything that 'uses' the logical channel. to fix this, i have an idea and need some response before implementing.

problems:
 - what instance uses the logical channel?
 - how do we release them, if the channel is closed?
 - how do we change the channel (handover/SDCCH->TCH ...)? (is this required?)

one possible solution:

every logical channel gets a list of 'users'. these users have nodes in this list. users can be i.e.: an active call, a call on hold, an SMS transaction, a location update....

each node has a pointer to the lchan. the 'user' can access the logical channel via node.

each node has a destructor function pointer. during lchan_free(), the destructor of each node is called. the 'user' will remove the node. with that, the chan_alloc does not need to know how to free 'users'

if we want to change the logical channel, we just unlink the nodes from the old channel and attach them to the new channel.

each node has:
- "struct llist_head" to link to previous and next node
- pointer to the logical channel (lchan)
- pointer to the destructor for the node owner. (the 'user')
- void pointer to the owner's private structure.

user 'uses' a channel:
- it calls the lchan_use() function with the logical channel, the destructor, and private structure pointer
- the node is created and linked to the logical channel
- the pointers within that node are set

user 'drops' a channel:
- it calls the lchan_put() function with the pointer to the node.
- the node is unlinked from lchan and destroyed

lchan closes:
- for each node of a logical channel, the destructor is created.
- within this destructor, the 'user' must remove all relations to that channel, remove the node, and set the node pointer to NULL.


user can refers to it's channel:
struct gsm_lchan *lchan = private->lchan_node->lchan;


what do you think?



-----Urspr?ngliche Nachricht-----
Von: openbsc-bounces at lists.gnumonks.org [mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von Holger Freyther
Gesendet: Dienstag, 2. Juni 2009 03:02
An: openbsc at lists.gnumonks.org
Betreff: Re: patch 22: lchan_use


I don't like this part. First of all when making release_loc_update_req 
"public" it should be properly prefixed, but I don't think chan_alloc.c should 
know/care about gsm_04_08.c at all. Also tying the timeout of the Location 
Update with the autorelease of the channel does not seem appropriate.

I would very much prefer if this logic can stay within gsm_04_08.c and we fix 
the usage count issue there.

For me it looks like:
	- We get a reference when creating the loc_update_request
	- We start a timer
	- We put the reference when destroying the loc update request...

	- So we might just remove the extra put/use for the waiting for IMSI/IMEI
          and fix the "leak" like this?


what do you think?


	z.




From zecke at selfish.org  Tue Jun  2 22:33:06 2009
From: zecke at selfish.org (Holger Freyther)
Date: Wed, 3 Jun 2009 00:33:06 +0200
Subject: patch 22: lchan_use
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A9842@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A9842@FLBVEXCH01.versatel.local>
Message-ID: <200906030033.09050.zecke@selfish.org>

On Tuesday 02 June 2009 17:04:33 Andreas.Eversberg wrote:
> lchan_free() is called when RSL released the logical channel. all
> ressources that 'uses' the channel, must be released. i aggree with you,
> that it makes no sense to consider everything that 'uses' the logical
> channel. to fix this, i have an idea and need some response before
> implementing.
>
> problems:
>  - what instance uses the logical channel?
>  - how do we release them, if the channel is closed?
>  - how do we change the channel (handover/SDCCH->TCH ...)? (is this
> required?)
>

>
> what do you think?

Let me tell you what I intended for the lchan and what I see is missing.

Normal operation:
  Basic:
	- lchan is a logical channel
	- we use refcount, when refcount drops zero we will release it
	  (arbitrary timeout to delay it)

 Logical Operations:
         - On top of this we have a logical operation/transaction...
         - E.g. Location Updating Request....
         - It has a specified timeout of 20 seconds T3210 (okay that
	   is cheating as this timer is from the mobile station)
         - During this operation we send a couple of commands, want
           the IMSI, IMEISV, etc. and ultimately want to end in a
           CM SERVICE REQUEST (oops... another bug in our code)
         - But we might not get every command answered, so manipulating
           the refcount for IMSI, IMEISV, etc. might result in leaks..
         - This is where the logical operation comes into place to "hold" the
           ref throughout the operation and put_lchan once it is done (either
           by timeout, failure or success)

         On the specific bug you see, I think removing use_lchan/put_lchan for
         the separate IMSI/IMEISV should fix your leak, and should be safe as
         the creation of the logical operation is getting the lock.


Failure Case:
     - We get a RSL_MT_RF_CHAN_REL_ACK with refcount != 0
     - so the channel got closed under our back...
     - The question is how to do error recovery in general in OpenBSC

     - Your proposal is to have a list of users in each lchan to run 
       "destructors".


     - I think something as easy as our callback system can be used. Just
       broadcast an UNEXPECTED LCHAN RELEASE event and let the client
       code figure out what resources to release.



So I think with "users" we already have them in the sense of logical operation 
that can be embedded into the lchan. So far I would opt for pointers in the 
lchan structure, we can make that a llist once we have too many of them.

But I wouldn't want to mix that with the "error" case, normally the 
"destructors" of an user are ran when the operation is completed and 
afterwards the reference gets dropped. The only case this does not happen is 
the unexpected release of a channel.

what do you think?



From Andreas.Eversberg at versatel.de  Mon Jun  1 17:33:44 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 1 Jun 2009 19:33:44 +0200
Subject: patch 25: e1link
Message-ID: <B16317F2B1592B4492FC414114171CE66A902E@FLBVEXCH01.versatel.local>

During bootstrap of BS11, the e1links are initialized. This must also be
done when BS11 is already bootstrapped (when restarting OpenBSC). It is
required to correctly multiplex the audio traffic between channels.
Without it, all time slots refer to card 0, slot 0, subslot 0, which
causes crashes when handling TRAU frames..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/fcc3685e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 25_e1link.patch
Type: application/octet-stream
Size: 3049 bytes
Desc: 25_e1link.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/fcc3685e/attachment.obj>

From zecke at selfish.org  Tue Jun  2 01:22:32 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 2 Jun 2009 03:22:32 +0200
Subject: patch 25: e1link
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A902E@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A902E@FLBVEXCH01.versatel.local>
Message-ID: <200906020322.32605.zecke@selfish.org>

On Monday 01 June 2009 19:33:44 Andreas.Eversberg wrote:
> During bootstrap of BS11, the e1links are initialized. This must also be
> done when BS11 is already bootstrapped (when restarting OpenBSC). It is
> required to correctly multiplex the audio traffic between channels.
> Without it, all time slots refer to card 0, slot 0, subslot 0, which
> causes crashes when handling TRAU frames..

applied thanks.

	z.



From Andreas.Eversberg at versatel.de  Mon Jun  1 17:33:44 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 1 Jun 2009 19:33:44 +0200
Subject: patch 21: libcrypt
Message-ID: <B16317F2B1592B4492FC414114171CE66A902A@FLBVEXCH01.versatel.local>

Libcrypt must be linked to use "crypt()" function.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/4ead8e83/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 21_libcrypt.patch
Type: application/octet-stream
Size: 815 bytes
Desc: 21_libcrypt.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/4ead8e83/attachment.obj>

From zecke at selfish.org  Mon Jun  1 23:56:32 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 2 Jun 2009 01:56:32 +0200
Subject: patch 21: libcrypt
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A902A@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A902A@FLBVEXCH01.versatel.local>
Message-ID: <200906020156.33789.zecke@selfish.org>

On Monday 01 June 2009 19:33:44 Andreas.Eversberg wrote:
> Libcrypt must be linked to use "crypt()" function.

Did you see the "Mac OS X" thread? Maybe you could come up with a patch like 
posted by Lars, or could just ack it?

z.



From Andreas.Eversberg at versatel.de  Mon Jun  1 17:33:45 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 1 Jun 2009 19:33:45 +0200
Subject: patch 27: application
Message-ID: <B16317F2B1592B4492FC414114171CE66A9030@FLBVEXCH01.versatel.local>

This patch replaces the application patch 12.
 
Because the application was not checked in yet, I will not document the
bugs I fixed in it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/b470a6e9/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 27_application.patch
Type: application/octet-stream
Size: 115513 bytes
Desc: 27_application.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/b470a6e9/attachment.obj>

From zecke at selfish.org  Tue Jun  2 01:25:44 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 2 Jun 2009 03:25:44 +0200
Subject: patch 27: application
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A9030@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A9030@FLBVEXCH01.versatel.local>
Message-ID: <200906020325.44519.zecke@selfish.org>

On Monday 01 June 2009 19:33:45 Andreas.Eversberg wrote:
> This patch replaces the application patch 12.
>
> Because the application was not checked in yet, I will not document the
> bugs I fixed in it.

Puh, that is big and I need a small break from the previous patches, I will 
try hard to find some time this week to take a look.

thanks for your work
	z.



From Andreas.Eversberg at versatel.de  Mon Jun  1 17:33:45 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 1 Jun 2009 19:33:45 +0200
Subject: patch 26: releasel2
Message-ID: <B16317F2B1592B4492FC414114171CE66A902F@FLBVEXCH01.versatel.local>

Tells mISDN not to release layer 2 on closing socket, when not
requested. If mISDN was told to release layer 2 once, it will continue
to release layer 2 on every shutdown of OpenBSC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/b1d16fd5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 26_releasel2.patch
Type: application/octet-stream
Size: 598 bytes
Desc: 26_releasel2.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090601/b1d16fd5/attachment.obj>

From zecke at selfish.org  Tue Jun  2 01:25:01 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 2 Jun 2009 03:25:01 +0200
Subject: patch 26: releasel2
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A902F@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A902F@FLBVEXCH01.versatel.local>
Message-ID: <200906020325.02064.zecke@selfish.org>

On Monday 01 June 2009 19:33:45 Andreas.Eversberg wrote:
> Tells mISDN not to release layer 2 on closing socket, when not
> requested. If mISDN was told to release layer 2 once, it will continue
> to release layer 2 on every shutdown of OpenBSC.

applied, thanks

	z.



From Andreas.Eversberg at versatel.de  Mon Jun  1 18:09:56 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 1 Jun 2009 20:09:56 +0200
Subject: layer 1 debugging
Message-ID: <B16317F2B1592B4492FC414114171CE66A9032@FLBVEXCH01.versatel.local>

hi,
 
i added layer 1 state change (and initial state) reporting to mISDN
kernel driver. this is usefull to resolve E1 connection problem.
 
1. download the latest mISDN driver from www.mISDN.org using git:
 
 git-clone git://git.misdn.org/git/mISDN.git/

change to socket branch:
 
 cd mISDN
./checkout-branch.sh socket
 
compile and install as usual
 
 make force # remove kernel mISDN includes
 make
 make install
 
load mISDN as usual.
 
 
2. run bsc_hack using debug option: --debug=DMI
 
Allowing everyone?
DB: Database initialized.
DB: Database prepared.
1 devices found
        id:             0
        Dprotocols:     00000018
        Bprotocols:     0000006e
        protocol:       4
        nrbchan:        30
        name:           hfc-e1.1
activate bchan
activate bchan
Mon Jun  1 18:51:43 2009 <1000> input/misdn.c:124 alen =6, dev(9)
channel(0) sapi(63) tei(127)
Mon Jun  1 18:51:43 2009 <1000> input/misdn.c:127 <= len = 12, prim(0x8)
id(0x7f3f): DL_INFORMATION_IND
Mon Jun  1 18:51:43 2009 <1000> input/misdn.c:134 DL_INFORMATION_IND:
use channel(0) sapi(63) tei(127) for now
mISDN message for unknown sign_link
Mon Jun  1 18:51:43 2009 <1000> input/misdn.c:124 alen =6, dev(9)
channel(0) sapi(63) tei(127)
Mon Jun  1 18:51:43 2009 <1000> input/misdn.c:127 <= len = 8,
prim(0x102) id(0x7f3f): PH_ACTIVATE_IND
Mon Jun  1 18:51:43 2009 <1000> input/misdn.c:161 PH_ACTIVATE_IND:
channel(0) sapi(63) tei(127)
 
in this case we see "PH_ACTIVATE_IND", because BS11 is connected and
sending a signal.
 
 
3. check your card: (most common type)
 
close to the plug there are two jumpers. the are used to select between
1,2,4,5 and 1,2,3,6 pin selection. be sure they are to the left for
standard 1,2,4,5 pinning.
 
take an rj45 plug and connect pin 1 with 4 and 2 with 5. start bsc_hack
and plug it into your card. you should see "PH_ACTIVATE_IND" when you
plug it. your card is working.
 
if nothing works, check your termination switches. refer to the card's
manual. the must be set to 120 ohms, if the termination jumpers on your
BS11 are pulled out. without termination, the card might not work.
 
 
4. check your BS11
 
remove the plug and connect the cable to the BS11: one pair (pin 1 and
2) to Y01 and one pair (pin 4 and 5) to Y02. after bootup ob BS11 you
will see "PH_ACTIVATE_IND" if you connect both paris in the correct
order. you must connect both pairs because BS11 will only send a signal,
if it receives a signal. pin 1 can be wapped with pin 2, pin 4 with pin
5 also. the E1 interface does not care about that.
 
 
5. check data link connection:
 
you have already received the management process via
"DL_INFORMATION_IND" on sapi 63 tei 127. if BS11 software load is
running, you will receive additional data links from BS11:
 
- sapi 62 tei 25
- sapi 0 tei 25
- sapi 0 tei 1
 
these are three datalinks. each one is created and sends us
"DL_INFORMATION_IND" on creation, "DL_ESTABLISH_IND" on activation and
"DL_DATA_IND" when receiving data on that link.
 
 
hope that helps.
 
andreas
 
 
 


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

From laforge at gnumonks.org  Wed Jun  3 13:31:41 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 3 Jun 2009 15:31:41 +0200
Subject: layer 1 debugging
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A9032@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A9032@FLBVEXCH01.versatel.local>
Message-ID: <20090603133141.GZ9823@prithivi.gnumonks.org>

thanks a lot, andreas.  

I hope this helps people debugging their physical connection, cable pin-outs,
etc.

Will that patch for the mISDN kernel driver be pushed for mainline (2.6.31)?

It might also help if we had a patch against 2.6.29 that people can apply,
rather than building from the mISDN git tree.

-- 
- 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 e.cathelinaud at googlemail.com  Tue Jun  9 10:56:25 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Tue, 9 Jun 2009 12:56:25 +0200
Subject: layer 1 debugging
In-Reply-To: <20090603133141.GZ9823@prithivi.gnumonks.org>
References: <B16317F2B1592B4492FC414114171CE66A9032@FLBVEXCH01.versatel.local>
	<20090603133141.GZ9823@prithivi.gnumonks.org>
Message-ID: <383f8f9a0906090356p53642994oa589b59bc341c288@mail.gmail.com>

Thanks a lot for this layer 1 debugging tutorial. It helped me a lot since i
was thinking I did something wrong with mISDN. I checked the step 3 and find
out that my ISDN card was working fine.
Then I tried to invert my twinax plugs and it worked. I think there is a
mistake in the wiki.
It's written in http://bs11-abis.gnumonks.org/trac/wiki/BS11_Configuration :
- left Y01 PCM in (from BSC): RJ45 pin 4,5
- Y02 PCM out (to BSC): RJ45 pin 1,2

but for me it works with :
Y01 PCM : RJ45 pin 1,2 (orange / white orange for a straight cable)
Y02 PCM : RJ45 pin 4,5 (blue / white blue for a straight cable)


I can now see the network on my mobile phone thanks a lot.

Best regards
Eric Cathelinaud

2009/6/3 Harald Welte <laforge at gnumonks.org>

> thanks a lot, andreas.
>
> I hope this helps people debugging their physical connection, cable
> pin-outs,
> etc.
>
> Will that patch for the mISDN kernel driver be pushed for mainline
> (2.6.31)?
>
> It might also help if we had a patch against 2.6.29 that people can apply,
> rather than building from the mISDN git tree.
>
> --
> - 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)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090609/c94e5e1c/attachment.htm>

From laforge at gnumonks.org  Tue Jun  9 18:07:53 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 10 Jun 2009 02:07:53 +0800
Subject: layer 1 debugging
In-Reply-To: <383f8f9a0906090356p53642994oa589b59bc341c288@mail.gmail.com>
References: <B16317F2B1592B4492FC414114171CE66A9032@FLBVEXCH01.versatel.local>
	<20090603133141.GZ9823@prithivi.gnumonks.org>
	<383f8f9a0906090356p53642994oa589b59bc341c288@mail.gmail.com>
Message-ID: <20090609180753.GG5304@prithivi.gnumonks.org>

Hi Eric,
 
On Tue, Jun 09, 2009 at 12:56:25PM +0200, Eric Cathelinaud wrote:
> Thanks a lot for this layer 1 debugging tutorial. It helped me a lot since i
> was thinking I did something wrong with mISDN. I checked the step 3 and find
> out that my ISDN card was working fine.
> Then I tried to invert my twinax plugs and it worked. I think there is a
> mistake in the wiki.
> It's written in http://bs11-abis.gnumonks.org/trac/wiki/BS11_Configuration :
> - left Y01 PCM in (from BSC): RJ45 pin 4,5
> - Y02 PCM out (to BSC): RJ45 pin 1,2
> 
> but for me it works with :
> Y01 PCM : RJ45 pin 1,2 (orange / white orange for a straight cable)
> Y02 PCM : RJ45 pin 4,5 (blue / white blue for a straight cable)

I think that depends on the jumper configuration of your E1 card.  Did you
really put the jumpers in "NT Mode" configuration?

> I can now see the network on my mobile phone thanks a lot.

great!
-- 
- 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 e.cathelinaud at googlemail.com  Tue Jun  9 20:51:08 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Tue, 9 Jun 2009 22:51:08 +0200
Subject: layer 1 debugging
In-Reply-To: <20090609180753.GG5304@prithivi.gnumonks.org>
References: <B16317F2B1592B4492FC414114171CE66A9032@FLBVEXCH01.versatel.local>
	<20090603133141.GZ9823@prithivi.gnumonks.org>
	<383f8f9a0906090356p53642994oa589b59bc341c288@mail.gmail.com>
	<20090609180753.GG5304@prithivi.gnumonks.org>
Message-ID: <383f8f9a0906091351x6643e669i1e0720df808ac162@mail.gmail.com>

2009/6/9 Harald Welte <laforge at gnumonks.org>

> Hi Eric,
>
> On Tue, Jun 09, 2009 at 12:56:25PM +0200, Eric Cathelinaud wrote:
> > Thanks a lot for this layer 1 debugging tutorial. It helped me a lot
> since i
> > was thinking I did something wrong with mISDN. I checked the step 3 and
> find
> > out that my ISDN card was working fine.
> > Then I tried to invert my twinax plugs and it worked. I think there is a
> > mistake in the wiki.
> > It's written in
> http://bs11-abis.gnumonks.org/trac/wiki/BS11_Configuration :
> > - left Y01 PCM in (from BSC): RJ45 pin 4,5
> > - Y02 PCM out (to BSC): RJ45 pin 1,2
> >
> > but for me it works with :
> > Y01 PCM : RJ45 pin 1,2 (orange / white orange for a straight cable)
> > Y02 PCM : RJ45 pin 4,5 (blue / white blue for a straight cable)
>
> I think that depends on the jumper configuration of your E1 card.  Did you
> really put the jumpers in "NT Mode" configuration?



Yes I put NT Mode following the jumper plan (short pins on the right). My
card is a Beronet BN1E1. I will try to short pins on the left and let you
know if working as in wiki.

>
>
> > I can now see the network on my mobile phone thanks a lot.
>
> great!
> --
>  - 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090609/59753390/attachment.htm>

From e.cathelinaud at googlemail.com  Wed Jun 10 08:40:30 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Wed, 10 Jun 2009 10:40:30 +0200
Subject: layer 1 debugging
In-Reply-To: <383f8f9a0906091351x6643e669i1e0720df808ac162@mail.gmail.com>
References: <B16317F2B1592B4492FC414114171CE66A9032@FLBVEXCH01.versatel.local>
	<20090603133141.GZ9823@prithivi.gnumonks.org>
	<383f8f9a0906090356p53642994oa589b59bc341c288@mail.gmail.com>
	<20090609180753.GG5304@prithivi.gnumonks.org>
	<383f8f9a0906091351x6643e669i1e0720df808ac162@mail.gmail.com>
Message-ID: <383f8f9a0906100140l1c93313cm9ea4b03321e1e64d@mail.gmail.com>

I tried to short the left and to invert the twinax plug (thus pluging them
as in the wiki) and it works too. Then it could be a mistake in the jumper
plan of BN1E1 cause they say that the left is "TE" and not "NT".
Anyone else dealing with a BN1E1 card to confirm?

Eric Cathelinaud


2009/6/9, Eric Cathelinaud <e.cathelinaud at googlemail.com>:
>
> 2009/6/9 Harald Welte <laforge at gnumonks.org>
>
>> Hi Eric,
>>
>> On Tue, Jun 09, 2009 at 12:56:25PM +0200, Eric Cathelinaud wrote:
>> > Thanks a lot for this layer 1 debugging tutorial. It helped me a lot
>> since i
>> > was thinking I did something wrong with mISDN. I checked the step 3 and
>> find
>> > out that my ISDN card was working fine.
>> > Then I tried to invert my twinax plugs and it worked. I think there is a
>> > mistake in the wiki.
>> > It's written in
>> http://bs11-abis.gnumonks.org/trac/wiki/BS11_Configuration :
>> > - left Y01 PCM in (from BSC): RJ45 pin 4,5
>> > - Y02 PCM out (to BSC): RJ45 pin 1,2
>> >
>> > but for me it works with :
>> > Y01 PCM : RJ45 pin 1,2 (orange / white orange for a straight cable)
>> > Y02 PCM : RJ45 pin 4,5 (blue / white blue for a straight cable)
>>
>>
>> I think that depends on the jumper configuration of your E1 card.  Did you
>> really put the jumpers in "NT Mode" configuration?
>
>
>
> Yes I put NT Mode following the jumper plan (short pins on the right). My
> card is a Beronet BN1E1. I will try to short pins on the left and let you
> know if working as in wiki.
>
>>
>>
>> > I can now see the network on my mobile phone thanks a lot.
>>
>>
>> great!
>> --
>>  - 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)
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090610/c0663d2f/attachment.htm>

From Andreas.Eversberg at versatel.de  Wed Jun 10 09:03:29 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Wed, 10 Jun 2009 11:03:29 +0200
Subject: AW: layer 1 debugging
Message-ID: <B16317F2B1592B4492FC414114171CE67DEE52@FLBVEXCH01.versatel.local>

BN1E1 seems to have different layouts over the time.
 
i always jumper the cards to TE, so i use a crosslink cable for NT to
TE.
 

________________________________

Von: openbsc-bounces at lists.gnumonks.org
[mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von Eric
Cathelinaud
Gesendet: Mittwoch, 10. Juni 2009 10:41
An: Harald Welte
Cc: openbsc at lists.gnumonks.org
Betreff: Re: layer 1 debugging


I tried to short the left and to invert the twinax plug (thus pluging
them as in the wiki) and it works too. Then it could be a mistake in the
jumper plan of BN1E1 cause they say that the left is "TE" and not "NT".
Anyone else dealing with a BN1E1 card to confirm?
 
Eric Cathelinaud

 
2009/6/9, Eric Cathelinaud <e.cathelinaud at googlemail.com>: 

	2009/6/9 Harald Welte <laforge at gnumonks.org>
	

		Hi Eric,
		

		On Tue, Jun 09, 2009 at 12:56:25PM +0200, Eric
Cathelinaud wrote:
		> Thanks a lot for this layer 1 debugging tutorial. It
helped me a lot since i
		> was thinking I did something wrong with mISDN. I
checked the step 3 and find
		> out that my ISDN card was working fine.
		> Then I tried to invert my twinax plugs and it worked.
I think there is a
		> mistake in the wiki.
		> It's written in
http://bs11-abis.gnumonks.org/trac/wiki/BS11_Configuration :
		> - left Y01 PCM in (from BSC): RJ45 pin 4,5
		> - Y02 PCM out (to BSC): RJ45 pin 1,2
		>
		> but for me it works with :
		> Y01 PCM : RJ45 pin 1,2 (orange / white orange for a
straight cable)
		> Y02 PCM : RJ45 pin 4,5 (blue / white blue for a
straight cable)
		
		 
		I think that depends on the jumper configuration of your
E1 card.  Did you
		really put the jumpers in "NT Mode" configuration?

	 
	 
	Yes I put NT Mode following the jumper plan (short pins on the
right). My card is a Beronet BN1E1. I will try to short pins on the left
and let you know if working as in wiki.
	

		
		

		> I can now see the network on my mobile phone thanks a
lot.
		
		 
		great!
		--
		
		- 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)
		 



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

From mailinglists at hellercom.de  Tue Jun  2 21:44:29 2009
From: mailinglists at hellercom.de (Bjoern Heller)
Date: Tue, 2 Jun 2009 23:44:29 +0200
Subject: How to sync to HFC-S s0 clock?
Message-ID: <851D57F9-9C0D-499A-8A32-E2FC6B70909D@hellercom.de>

Hello,

I want to sync the e1 card with a HFC-s card, which is attached to my
ISDN line.
How do I have to interconnect the two cards?

Best regards
Bj?rn

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Bj?rn Heller
Jabber: tec at jabber.hellercom.de

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

From Andreas.Eversberg at versatel.de  Wed Jun  3 08:58:33 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Wed, 3 Jun 2009 10:58:33 +0200
Subject: AW: How to sync to HFC-S s0 clock?
Message-ID: <B16317F2B1592B4492FC414114171CE66A9B64@FLBVEXCH01.versatel.local>

>Hello,
>
> I want to sync the e1 card with a HFC-s card, which is attached to my
> ISDN line.
> How do I have to interconnect the two cards? 
>
> Best regards
> Bj?rn



 
hi,
 
you need to find pin 118 of the E1 controller on the pcm bus (connector). this signal provides or receives the clock (4096khz) also find pin 119. it provides or receives frame sync (8khz).
 
connect them to the clock pin 54 and frame sync pin 55 of the HFC-S PCI ISDN controller. maybe choose a resistor of 1kohm to protect cards, if both card send output signals.
 
load mISDN driver module as "clock slave":
 
modprobe hfcmulti port=0x200 debug=0x40000
 
watch the kernel messages for clock selection process.
 
without clock connected, the hfcmulti module will fail. test that to see if the card trys to receive external clock. before you can use the clock from HFC-S, you must load hfcpci module. note that your E1 card is now card number 1 and not 0.
 
then you need to connect the HFC-S card to you isdn line. your card must activate interface. therefor a telephony application is required. but before, you need to see if your E1 card syncs to your HFC-S card. if your clock sync works, i will write a small application to set your isdn card into PTP mode (for durable link activation).
 
regards,
 
andreas
 



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

From Andreas.Eversberg at versatel.de  Wed Jun  3 07:59:11 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Wed, 3 Jun 2009 09:59:11 +0200
Subject: WG: patch 12 14, 15, 16
Message-ID: <B16317F2B1592B4492FC414114171CE66A9A70@FLBVEXCH01.versatel.local>

 
-----Urspr?ngliche Nachricht-----
Von: openbsc-bounces at lists.gnumonks.org [mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von Holger Freyther
>I'm not sure what happens to IMSI ATTACHED/DETACHED when doing handover, so 
>far the detach path was written in a way that even a sequence like:
>	new BTS ATTACHED
>	old  BTS DETACHED

hi holger,

here is what happens:

BTS(new LAC) ATTACH -> DB = new LAC
BTS(old LAC) DETACH -> DB = 0

the mobile attaches to the new LAC, so the database stores the new LAC number. next, the mobile detaches from the old LAC and the database stores 0 for 'not attached'. the database now holds a wrong value.

to solve this, we may only allow detach, if the mobile is not already attached to a different location area:

if (DB == old LAC) then  DB = 0  else  ignore!

so the mobile can only detach from a BTS with the location it is currently attached.


i checked the code yesterday. i saw that the subscriber is associated to a LAC and a bts when attaching. when detaching, the association to the bts is removed, if not already attached to a different one.

is this correct? as far as i know, the attached subscriber is associated to a LAC only. it may silently change the BTS without location update, if the MCC/MNC/LAC is equal on this BTS. when we page a mobile, we must do it on all BTS of that location area, as far as i know. (see patch 27) if the mobile requests a channel, it chooses one of the BTS. i think we must remove the "current_bts" pointer from the subscriber structure.



andreas



From zecke at selfish.org  Wed Jun  3 08:39:35 2009
From: zecke at selfish.org (Holger Freyther)
Date: Wed, 3 Jun 2009 10:39:35 +0200
Subject: WG: patch 12 14, 15, 16
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A9A70@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A9A70@FLBVEXCH01.versatel.local>
Message-ID: <200906031039.36063.zecke@selfish.org>

On Wednesday 03 June 2009 09:59:11 Andreas.Eversberg wrote:
> -----Urspr?ngliche Nachricht-----
> Von: openbsc-bounces at lists.gnumonks.org
> [mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von Holger Freyther
>
> >I'm not sure what happens to IMSI ATTACHED/DETACHED when doing handover,
> > so far the detach path was written in a way that even a sequence like:
> > new BTS ATTACHED
> >	old  BTS DETACHED
>
> hi holger,
>
> here is what happens:
>
> BTS(new LAC) ATTACH -> DB = new LAC
> BTS(old LAC) DETACH -> DB = 0

okay, so my assumption was correct.


> to solve this, we may only allow detach, if the mobile is not already
> attached to a different location area:
>
> if (DB == old LAC) then  DB = 0  else  ignore!

okay, the same approach as with the bts pointer (unless I fucked up in the 
code)


> is this correct? as far as i know, the attached subscriber is associated to
> a LAC only. it may silently change the BTS without location update,

You are right. It is wrong. I assumed that BTS <-> LAC map 1:1 but that is not 
the case. Could you prepare a change to gsm_subscriber to store the LAC + CELL 
ID and remove the struct gsm_bts pointer or would you be willing to test one? 
Maybe even carry out the change in the db.c to store/restore the that 
information (e.g. check my "VLR" patches as this is what we are building).


For the future we would have something like this:
  1.) Call +123323
  2.) Find the gsm_subscriber and load it from the db
  3.) Check the VLR where we currently think it is
       struct gsm_bts* bts = bts_resolve(subscr->lac, subscr->cell_id);
       and then page...

z.



From Andreas.Eversberg at versatel.de  Thu Jun  4 08:27:28 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Thu, 4 Jun 2009 10:27:28 +0200
Subject: AW: WG: patch 12 14, 15, 16
Message-ID: <B16317F2B1592B4492FC414114171CE6726BD8@FLBVEXCH01.versatel.local>



>> is this correct? as far as i know, the attached subscriber is
associated to
>> a LAC only. it may silently change the BTS without location update,
>
>You are right. It is wrong. I assumed that BTS <-> LAC map 1:1 but that
is not 
>the case. Could you prepare a change to gsm_subscriber to store the LAC
+ CELL 
>ID and remove the struct gsm_bts pointer or would you be willing to
test one? 
>Maybe even carry out the change in the db.c to store/restore the that 
>information (e.g. check my "VLR" patches as this is what we are
building).

i can test this. i will remove bts pointer and only check lac when
detaching. when paging, i will loop all bts and add a paging request to
all bts with that pointer. if the paging responds, we receive the lchan
and then stop paging requests to other bts' (if any). if we receive
resonse, we ignore them, if we already received an lchan. (error case
when two mobiles share same imsi or other error cases).

what about the "VLR" patch? where is it? why do you need a VLR? (HLR??)

>For the future we would have something like this:
>  1.) Call +123323
>  2.) Find the gsm_subscriber and load it from the db
>  3.) Check the VLR where we currently think it is
>       struct gsm_bts* bts = bts_resolve(subscr->lac, subscr->cell_id);
>       and then page...
>
>z.

check out the patch 27 (application). there is a loop when start paging.
it already loops all bts with the LAC. there is an error in that: the
current_bts pointer is changed for every paging request. this would be
removed, if the bts pointer is removed. also the stopping of parallel
paging requests (same subscriber, different bts) is not realized.

if you aggree with that, i will implement it this weekend.




From zecke at selfish.org  Thu Jun  4 14:09:19 2009
From: zecke at selfish.org (Holger Freyther)
Date: Thu, 4 Jun 2009 16:09:19 +0200
Subject: WG: patch 12 14, 15, 16
In-Reply-To: <B16317F2B1592B4492FC414114171CE6726BD8@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE6726BD8@FLBVEXCH01.versatel.local>
Message-ID: <200906041609.20045.zecke@selfish.org>

On Thursday 04 June 2009 10:27:28 Andreas.Eversberg wrote:

> check out the patch 27 (application). there is a loop when start paging.
> it already loops all bts with the LAC.

To be honest the patch 27 is so big that this is not easy to spot. The feature 
of searching the right bts(es) and trying to page there would be good enough 
for a patch on its own. :)

Let me use this opportunity to leave my two cents (again). I understand a big 
patch happens naturally but it would be great if you could attempt to split 
things up into smaller pieces (patches up to 27 were a great progress). 
Smaller patches are more easily judged which means they end up in the 
repository faster which will make everyone involved happy.

but we are certainly on a good way, so please keep up with your good work and 
I will try to merge patches as fast as possible.


thanks a lot
	z.



From zecke at selfish.org  Thu Jun  4 14:37:50 2009
From: zecke at selfish.org (Holger Freyther)
Date: Thu, 4 Jun 2009 16:37:50 +0200
Subject: WG: patch 12 14, 15, 16
In-Reply-To: <B16317F2B1592B4492FC414114171CE6726BD8@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE6726BD8@FLBVEXCH01.versatel.local>
Message-ID: <200906041637.50812.zecke@selfish.org>

On Thursday 04 June 2009 10:27:28 Andreas.Eversberg wrote:

> i can test this. i will remove bts pointer and only check lac when
> detaching. when paging, i will loop all bts and add a paging request to
> all bts with that pointer. if the paging responds, we receive the lchan
> and then stop paging requests to other bts' (if any). if we receive
> resonse, we ignore them, if we already received an lchan. (error case
> when two mobiles share same imsi or other error cases).
>
> what about the "VLR" patch? where is it? why do you need a VLR? (HLR??)
>

Please see the mail "[PATCH 0/3] Channel requests/Management in 
gsm_subscriber" from 2009-04-19 21:20 and "[RFC] Patches for better channel 
management". The bottom line of the patches are to make the "paging" layer 
more internal and request a lchan for a given subscriber (finding the right 
bts, checking if we have capacity, checking if the MS has capacity, properly 
queuing things). I will rediff this over the weekend as well.

z.




From laforge at gnumonks.org  Fri Jun  5 14:53:47 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 5 Jun 2009 16:53:47 +0200
Subject: WG: patch 12 14, 15, 16
In-Reply-To: <B16317F2B1592B4492FC414114171CE66A9A70@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE66A9A70@FLBVEXCH01.versatel.local>
Message-ID: <20090605145347.GV4421@prithivi.gnumonks.org>

On Wed, Jun 03, 2009 at 09:59:11AM +0200, Andreas.Eversberg wrote:
>  
> -----Urspr?ngliche Nachricht-----
> Von: openbsc-bounces at lists.gnumonks.org [mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von Holger Freyther
> >I'm not sure what happens to IMSI ATTACHED/DETACHED when doing handover, so 
> >far the detach path was written in a way that even a sequence like:
> >	new BTS ATTACHED
> >	old  BTS DETACHED
> 
> hi holger,
> 
> here is what happens:
> 
> BTS(new LAC) ATTACH -> DB = new LAC
> BTS(old LAC) DETACH -> DB = 0

are you familiar enough with the protocol to make this kind of statement?  I
wouldn't be sure.  But if you say that switching LAC with IMSI Attach/Detach
enabled works this way, ok.

The reason I'm asking is that the phone would have to first go to a different
ARFCN, sync to it and send some message, and then go back to the old one.  This
sounds really strange to me.  What if you're in a fast moving vehicle and can no
longer go back to the old cell/LAC?

I would assume that an attach in a new LAC would implicitly be treated as a
detach in the old cell, without any explicit IMSI DETACH message.

Wikipedia is certainly not the definitive anwer, but as you can see
at http://en.wikipedia.org/wiki/IMSI_attach it claims that ATTACH is only
performed at the initial switch-on.  Later on, it does a regular Location
Update.

The 04.08 chyapter 4.4.3 says:

=====
The IMSI attach procedure is invoked if the detach/attach procedures are
required by the network and an IMSI is activated in a mobile station (i.e.
activation of a mobile station with plug-in SIM, insertion of a card in a
card-operated mobile station etc.) within coverage area from the network or a
mobile station with an IMSI activated outside the coverage area enters the
coverage area. The IMSI attach procedure is used only if the update status is
UPDATED and if the stored Location Area Identification is the same as the one
which is actually broadcasted on the BCCH of the current serving cell.
Otherwise a normal location updating procedure (see sub-clause 4.4.1) is
invoked independently of the ATT flag indication.
=====

So we will certainly get a Loaction Update both on initial phone power-up, as
well as when we switch from one LAC to another.  We don't really care if it's
a IMSI ATTACH type or other type Location Update.

The IMSI DETACH (section 4.3.4) doesn't say anything about changing location
area.  it is only sent once the SIM is deactivated/removed or the phone
switched off.

> to solve this, we may only allow detach, if the mobile is not already
> attached to a different location area:
> 
> if (DB == old LAC) then  DB = 0  else  ignore!
> 
> so the mobile can only detach from a BTS with the location it is currently
> attached.

I don't think we need this, see above.

But what I'm thinking right now is whether we have a DoS here, if somebody
spoofs tons of IMSI DETACH messages.  But well, not our primary concern right
now.  As soon as authentication and ciphering is used, it's not that much of
an issue anymore anyway.

> is this correct? as far as i know, the attached subscriber is associated to a
> LAC only. it may silently change the BTS without location update, if the
> MCC/MNC/LAC is equal on this BTS. when we page a mobile, we must do it on all
> BTS of that location area, as far as i know. (see patch 27) if the mobile
> requests a channel, it chooses one of the BTS. i think we must remove the
> "current_bts" pointer from the subscriber structure.

Yes.  The 'current_bts' pointer goes back to a time where at least I (and
presumably Holger, too) did not yet fully understand the option of a LAC
consisting of multiple BTS.

So yes, I think it should be removed.  What we'd rather need is a pointer
to the current RR (or MM?) connection, if any.  So if we have some MT call or
other service request, we look up the subscriber and can either use an existing
RR/MM connection, or if that one doesn't exist, we fall back to paging of all
BTS in the LAC.

The RR/MM connection is represented by what we call "lchan" right now.

-- 
- 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090605/9ff15277/attachment.bin>

From zecke at selfish.org  Fri Jun  5 13:30:23 2009
From: zecke at selfish.org (Holger Freyther)
Date: Fri, 5 Jun 2009 15:30:23 +0200
Subject: WG: patch 12 14, 15, 16
In-Reply-To: <20090605145347.GV4421@prithivi.gnumonks.org>
References: <B16317F2B1592B4492FC414114171CE66A9A70@FLBVEXCH01.versatel.local>
	<20090605145347.GV4421@prithivi.gnumonks.org>
Message-ID: <200906051530.23422.zecke@selfish.org>

On Friday 05 June 2009 16:53:47 Harald Welte wrote:

> Wikipedia is certainly not the definitive anwer, but as you can see
> at http://en.wikipedia.org/wiki/IMSI_attach it claims that ATTACH is only
> performed at the initial switch-on.  Later on, it does a regular Location
> Update.

Right, the spec agrees here (I stumbled across this today) and we need to fix 
the code. It is written in 04.08 Section 4.4.3 (IMSI Attach)

"The IMSI attach procedure is used only if the update status is UPDATED and if
the stored Location Area Identification is the same as the one which is 
actually broadcasted on the BCCH of the current
serving cell. Otherwise a normal location updating procedure (see sub-clause 
4.4.1) is invoked independently of the ATT flag indication."

So I don't fully understand this yet, but it is a strong indication that 
wikipedia is right...


greetings
	z.






From laforge at gnumonks.org  Fri Jun  5 20:37:49 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 5 Jun 2009 22:37:49 +0200
Subject: WG: patch 12 14, 15, 16
In-Reply-To: <200906051530.23422.zecke@selfish.org>
References: <B16317F2B1592B4492FC414114171CE66A9A70@FLBVEXCH01.versatel.local>
	<20090605145347.GV4421@prithivi.gnumonks.org>
	<200906051530.23422.zecke@selfish.org>
Message-ID: <20090605203749.GZ4421@prithivi.gnumonks.org>

On Fri, Jun 05, 2009 at 03:30:23PM +0200, Holger Freyther wrote:
> On Friday 05 June 2009 16:53:47 Harald Welte wrote:
> 
> > Wikipedia is certainly not the definitive anwer, but as you can see
> > at http://en.wikipedia.org/wiki/IMSI_attach it claims that ATTACH is only
> > performed at the initial switch-on.  Later on, it does a regular Location
> > Update.
> 
> Right, the spec agrees here (I stumbled across this today) and we need to fix 
> the code. It is written in 04.08 Section 4.4.3 (IMSI Attach)
> 
> "The IMSI attach procedure is used only if the update status is UPDATED and if
> the stored Location Area Identification is the same as the one which is 
> actually broadcasted on the BCCH of the current
> serving cell. Otherwise a normal location updating procedure (see sub-clause 
> 4.4.1) is invoked independently of the ATT flag indication."
> 
> So I don't fully understand this yet, but it is a strong indication that 
> wikipedia is right...

'update status' is the status as stored in the SIM.   UPDATED means that the
last Location Update was successful, and the SIM contains a valid LAI.

So IMSI ATTACH is only used if the SIM card is activated in the same LA that it
was last active in.

If the SIM was registered to a different network or LA, or actually failed to
register to a network (unsuccessful location update), then the status is NOT
UPDATED and thus IMSI ATTACH should not be performed, but rather a regular
Location Update

So IMSI ATTACH/DETACH really is about a SIM(IMSI) being activated/deactivated
in a given LA.  activation/deactivation typically is switching the phone on
or off.

While moving between location areas [at least in the same network] there should
be no IMSI ATTACH, as per the spec.

-- 
- 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090605/925772e0/attachment.bin>

From laforge at gnumonks.org  Sat Jun  6 08:03:38 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 6 Jun 2009 10:03:38 +0200
Subject: WG: patch 12 14, 15, 16
In-Reply-To: <20090605203749.GZ4421@prithivi.gnumonks.org>
References: <B16317F2B1592B4492FC414114171CE66A9A70@FLBVEXCH01.versatel.local>
	<20090605145347.GV4421@prithivi.gnumonks.org>
	<200906051530.23422.zecke@selfish.org>
	<20090605203749.GZ4421@prithivi.gnumonks.org>
Message-ID: <20090606080338.GF4421@prithivi.gnumonks.org>

On Fri, Jun 05, 2009 at 10:37:49PM +0200, Harald Welte wrote:

> So IMSI ATTACH/DETACH really is about a SIM(IMSI) being activated/deactivated
> in a given LA.  activation/deactivation typically is switching the phone on
> or off.

In other words: IMSI ATTACH/DETACH is only used in addition to regular Location
Update, and it is used in situations where a MS on a network with ATT=0 would
not perform any signalling with the network at all.

-- 
- 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 spaar at mirider.augusta.de  Sat Jun  6 10:41:00 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Sat, 06 Jun 2009 10:41:00 CEST
Subject: WG: patch 12 14, 15, 16
Message-ID: <4a2a47bc.mirider@mirider.augusta.de>

Hello Harald,

On Sat, 6 Jun 2009 10:03:38 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> 
> In other words: IMSI ATTACH/DETACH is only used in addition to regular Location
> Update, and it is used in situations where a MS on a network with ATT=0 would
> not perform any signalling with the network at all.

I have read at some places that the idea of IMSI ATTACH/DETACH is to
save resources of the network, if its is know that an MS is off (IMSI
DETACH was sent) there is no need to allocate resources for paging the
MS. IMSI ATTACH is the reverse, it tells the network that the phone is
back again. Its up to the operator to use this feature. I am not sure
if this is the real motivation, but it makes sense for me.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From laforge at gnumonks.org  Sat Jun  6 09:45:23 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 6 Jun 2009 11:45:23 +0200
Subject: imsi attach/detach (was Re: WG: patch 12 14, 15, 16)
In-Reply-To: <4a2a47bc.mirider@mirider.augusta.de>
References: <4a2a47bc.mirider@mirider.augusta.de>
Message-ID: <20090606094523.GG4421@prithivi.gnumonks.org>

On Sat, Jun 06, 2009 at 10:41:00AM +0200, Dieter Spaar wrote:
> Hello Harald,
> 
> On Sat, 6 Jun 2009 10:03:38 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> > 
> > In other words: IMSI ATTACH/DETACH is only used in addition to regular Location
> > Update, and it is used in situations where a MS on a network with ATT=0 would
> > not perform any signalling with the network at all.
> 
> I have read at some places that the idea of IMSI ATTACH/DETACH is to
> save resources of the network, if its is know that an MS is off (IMSI
> DETACH was sent) there is no need to allocate resources for paging the
> MS. IMSI ATTACH is the reverse, it tells the network that the phone is
> back again. Its up to the operator to use this feature. I am not sure
> if this is the real motivation, but it makes sense for me.

yes, that's what I've figured, too.  You rather don't want to page a MS that
the user has intentionally switched off to save paging slots on the PCH...

-- 
- 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 bouchtaoui at gmail.com  Thu Jun  4 09:39:06 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Thu, 04 Jun 2009 11:39:06 +0200
Subject: Some very handy telecom call flow pdfs
Message-ID: <4A27963A.9020004@gmail.com>

I found some good call-flow schematics according to GSM protocol with 
some explanation included.
Check out this link: http://www.eventhelix.com/RealtimeMantra/Telecom/
It has some valuable and clear information how parts of GSM work.
I hope you like it, at least I do :)




From zecke at selfish.org  Fri Jun  5 02:15:09 2009
From: zecke at selfish.org (Holger Freyther)
Date: Fri, 5 Jun 2009 04:15:09 +0200
Subject: [PATCH 0/3] lchan/location updating request robustnes
Message-ID: <200906050415.10024.zecke@selfish.org>

Hey,

in patch22 Andreas pointed out that we might have unbalanced ref count in the 
location updating request path(s) and these patches try to fix some possible 
reliable issues, handle spoofing to a certain degree and recover from error 
(abnormal channel close).


 include/openbsc/signal.h |   10 ++++++++++
 src/chan_alloc.c         |    4 +++-
 src/gsm_04_08.c          |   32 ++++++++++++++++++++++++--------
 3 files changed, 37 insertions(+), 9 deletions(-)




From zecke at selfish.org  Fri Jun  5 02:16:30 2009
From: zecke at selfish.org (Holger Freyther)
Date: Fri, 5 Jun 2009 04:16:30 +0200
Subject: [PATCH 1/3]  Remove use_lchan and put_lchan from location updating
In-Reply-To: <200906050415.10024.zecke@selfish.org>
References: <200906050415.10024.zecke@selfish.org>
Message-ID: <200906050416.31287.zecke@selfish.org>

Andreas Eversberg is suspecting that some of these messages
are not balanced and we are seeing a leak here. The general location
updating request is guarded by the "location updating request" object
inside the lchan that will keep the channel open for at least five
seconds to get all the information we need.
---
 src/gsm_04_08.c |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/src/gsm_04_08.c b/src/gsm_04_08.c
index fd47d8b..a91ef7a 100644
--- a/src/gsm_04_08.c
+++ b/src/gsm_04_08.c
@@ -481,11 +481,6 @@ static int mm_rx_id_resp(struct msgb *msg)
 	DEBUGP(DMM, "IDENTITY RESPONSE: mi_type=0x%02x MI(%s)\n",
 		mi_type, mi_string);
 
-	/*
-	 * Rogue messages could trick us but so is life
-	 */
-	put_lchan(lchan);
-
 	switch (mi_type) {
 	case GSM_MI_TYPE_IMSI:
 		if (!lchan->subscr)
@@ -573,7 +568,6 @@ static int mm_rx_loc_upd_req(struct msgb *msg)
 	switch (mi_type) {
 	case GSM_MI_TYPE_IMSI:
 		/* we always want the IMEI, too */
-		use_lchan(lchan);
 		rc = mm_tx_identity_req(lchan, GSM_MI_TYPE_IMEI);
 		lchan->loc_operation->waiting_for_imei = 1;
 
@@ -582,7 +576,6 @@ static int mm_rx_loc_upd_req(struct msgb *msg)
 		break;
 	case GSM_MI_TYPE_TMSI:
 		/* we always want the IMEI, too */
-		use_lchan(lchan);
 		rc = mm_tx_identity_req(lchan, GSM_MI_TYPE_IMEI);
 		lchan->loc_operation->waiting_for_imei = 1;
 
@@ -590,7 +583,6 @@ static int mm_rx_loc_upd_req(struct msgb *msg)
 		subscr = subscr_get_by_tmsi(mi_string);
 		if (!subscr) {
 			/* send IDENTITY REQUEST message to get IMSI */
-			use_lchan(lchan);
 			rc = mm_tx_identity_req(lchan, GSM_MI_TYPE_IMSI);
 			lchan->loc_operation->waiting_for_imsi = 1;
 		}
-- 
1.6.3.1






From zecke at selfish.org  Fri Jun  5 02:17:21 2009
From: zecke at selfish.org (Holger Freyther)
Date: Fri, 5 Jun 2009 04:17:21 +0200
Subject: [PATCH 2/3] gsm_04_08.c: Some spoofing protection against two location
In-Reply-To: <200906050415.10024.zecke@selfish.org>
References: <200906050415.10024.zecke@selfish.org>
Message-ID: <200906050417.22295.zecke@selfish.org>

Do not allow two location updating requests at the same time on the
same lchan. Such an event is certainly spoofed and can confuse the
internal logic of the application. Prevent that.
---
 src/gsm_04_08.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/src/gsm_04_08.c b/src/gsm_04_08.c
index a91ef7a..18371b5 100644
--- a/src/gsm_04_08.c
+++ b/src/gsm_04_08.c
@@ -563,6 +563,12 @@ static int mm_rx_loc_upd_req(struct msgb *msg)
 	DEBUGP(DMM, "LUPDREQ: mi_type=0x%02x MI(%s) type=%s\n", mi_type, mi_string,
 		lupd_name(lu->type));
 
+	/* two location updating request on the same lchan... *spoof* */
+	if (lchan->loc_operation) {
+		gsm0408_loc_upd_rej(lchan, GSM48_REJECT_PROTOCOL_ERROR);
+		return 0;
+	}
+
 	allocate_loc_updating_req(lchan);
 
 	switch (mi_type) {
-- 
1.6.3.1





From zecke at selfish.org  Fri Jun  5 02:18:49 2009
From: zecke at selfish.org (Holger Freyther)
Date: Fri, 5 Jun 2009 04:18:49 +0200
Subject: [PATCH 3/3] lchan: Handle the abnormal case of channel getting closed
In-Reply-To: <200906050415.10024.zecke@selfish.org>
References: <200906050415.10024.zecke@selfish.org>
Message-ID: <200906050418.49741.zecke@selfish.org>

The abnormal case is that lchan_free ist getting called due
a RSL_MT_CHAN_REL_ACK in the RSL but the refcount of this
channel is not zero. This means that some "logical operation"
is still going on that needs to be cancelled.
Instead of always queuing up all operations in the
struct lchan use the signal framework to inform higher layers
about this abnormal case.

In gsm_04_08.c a signal handler is installed and in the
abnormal case the location updating request operation is
freed.
---
 include/openbsc/signal.h |   10 ++++++++++
 src/chan_alloc.c         |    4 +++-
 src/gsm_04_08.c          |   18 ++++++++++++++++++
 3 files changed, 31 insertions(+), 1 deletions(-)

diff --git a/include/openbsc/signal.h b/include/openbsc/signal.h
index c2cf46a..ca16296 100644
--- a/include/openbsc/signal.h
+++ b/include/openbsc/signal.h
@@ -37,6 +37,7 @@ enum signal_subsystems {
 	SS_SMS,
 	SS_ABISIP,
 	SS_NM,
+	SS_LCHAN,
 };
 
 /* SS_PAGING signals */
@@ -55,6 +56,15 @@ enum signal_nm {
 	S_NM_FAIL_REP,		/* GSM 12.21 failure event report */
 };
 
+/* SS_LCHAN signals */
+enum signal_lchan {
+	/*
+	 * The lchan got freed with refcount != 0 and error
+	 * recovery needs to happen right now.
+	 */
+	S_LCHAN_UNEXPECTED_RELEASE,
+};
+
 typedef int signal_cbfn(unsigned int subsys, unsigned int signal,
 			void *handler_data, void *signal_data);
 
diff --git a/src/chan_alloc.c b/src/chan_alloc.c
index fa07273..77a4f57 100644
--- a/src/chan_alloc.c
+++ b/src/chan_alloc.c
@@ -31,6 +31,7 @@
 #include <openbsc/abis_nm.h>
 #include <openbsc/abis_rsl.h>
 #include <openbsc/debug.h>
+#include <openbsc/signal.h>
 
 static void auto_release_channel(void *_lchan);
 
@@ -193,8 +194,9 @@ void lchan_free(struct gsm_lchan *lchan)
 		lchan->subscr = 0;
 	}
 
-	/* We might kill an active channel... FIXME: call cancellations */
+	/* We might kill an active channel... */
 	if (lchan->use_count != 0) {
+		dispatch_signal(SS_LCHAN, S_LCHAN_UNEXPECTED_RELEASE, lchan);
 		lchan->use_count = 0;
 	}
 
diff --git a/src/gsm_04_08.c b/src/gsm_04_08.c
index 18371b5..3dfa780 100644
--- a/src/gsm_04_08.c
+++ b/src/gsm_04_08.c
@@ -182,6 +182,24 @@ static void allocate_loc_updating_req(struct gsm_lchan 
*lchan)
 	memset(lchan->loc_operation, 0, sizeof(*lchan->loc_operation));
 }
 
+static int gsm0408_handle_lchan_signal(unsigned int subsys, unsigned int 
signal,
+					void *handler_data, void *signal_data)
+{
+	if (subsys != SS_LCHAN || signal != S_LCHAN_UNEXPECTED_RELEASE)
+		return 0;
+
+	/* give up on the loc_operation in case of error */
+	struct gsm_lchan *lchan = (struct gsm_lchan *)handler_data;
+	release_loc_updating_req(lchan);
+
+	return 0;
+}
+
+static __attribute__((constructor)) void on_load_0408(void)
+{
+	register_signal_handler(SS_LCHAN, gsm0408_handle_lchan_signal, NULL);
+}
+
 static void to_bcd(u_int8_t *bcd, u_int16_t val)
 {
 	bcd[2] = val % 10;
-- 
1.6.3.1





From Andreas.Eversberg at versatel.de  Fri Jun  5 08:30:21 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Fri, 5 Jun 2009 10:30:21 +0200
Subject: AW: [PATCH 3/3] lchan: Handle the abnormal case of channel getting
	closed
Message-ID: <B16317F2B1592B4492FC414114171CE672753E@FLBVEXCH01.versatel.local>

ok, i understand now. the location update is a subinstance of lchan, so you "signal" an error to gsm_04_08.c to release all instances related to lchan.

i will test that and modify the patch 27 (application) this weekend, so the signal handler also releases the transactions of that lchan ("transactions" will replace the "call" process). i must upgrade patch 27, because it depends on earlier patches. 

-----Urspr?ngliche Nachricht-----
Von: openbsc-bounces at lists.gnumonks.org [mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von Holger Freyther
Gesendet: Freitag, 5. Juni 2009 04:19
An: openbsc at lists.gnumonks.org
Betreff: [PATCH 3/3] lchan: Handle the abnormal case of channel getting closed

The abnormal case is that lchan_free ist getting called due
a RSL_MT_CHAN_REL_ACK in the RSL but the refcount of this
channel is not zero. This means that some "logical operation"
is still going on that needs to be cancelled.
Instead of always queuing up all operations in the
struct lchan use the signal framework to inform higher layers
about this abnormal case.

In gsm_04_08.c a signal handler is installed and in the
abnormal case the location updating request operation is
freed.
---
 include/openbsc/signal.h |   10 ++++++++++
 src/chan_alloc.c         |    4 +++-
 src/gsm_04_08.c          |   18 ++++++++++++++++++
 3 files changed, 31 insertions(+), 1 deletions(-)

diff --git a/include/openbsc/signal.h b/include/openbsc/signal.h
index c2cf46a..ca16296 100644
--- a/include/openbsc/signal.h
+++ b/include/openbsc/signal.h
@@ -37,6 +37,7 @@ enum signal_subsystems {
 	SS_SMS,
 	SS_ABISIP,
 	SS_NM,
+	SS_LCHAN,
 };
 
 /* SS_PAGING signals */
@@ -55,6 +56,15 @@ enum signal_nm {
 	S_NM_FAIL_REP,		/* GSM 12.21 failure event report */
 };
 
+/* SS_LCHAN signals */
+enum signal_lchan {
+	/*
+	 * The lchan got freed with refcount != 0 and error
+	 * recovery needs to happen right now.
+	 */
+	S_LCHAN_UNEXPECTED_RELEASE,
+};
+
 typedef int signal_cbfn(unsigned int subsys, unsigned int signal,
 			void *handler_data, void *signal_data);
 
diff --git a/src/chan_alloc.c b/src/chan_alloc.c
index fa07273..77a4f57 100644
--- a/src/chan_alloc.c
+++ b/src/chan_alloc.c
@@ -31,6 +31,7 @@
 #include <openbsc/abis_nm.h>
 #include <openbsc/abis_rsl.h>
 #include <openbsc/debug.h>
+#include <openbsc/signal.h>
 
 static void auto_release_channel(void *_lchan);
 
@@ -193,8 +194,9 @@ void lchan_free(struct gsm_lchan *lchan)
 		lchan->subscr = 0;
 	}
 
-	/* We might kill an active channel... FIXME: call cancellations */
+	/* We might kill an active channel... */
 	if (lchan->use_count != 0) {
+		dispatch_signal(SS_LCHAN, S_LCHAN_UNEXPECTED_RELEASE, lchan);
 		lchan->use_count = 0;
 	}
 
diff --git a/src/gsm_04_08.c b/src/gsm_04_08.c
index 18371b5..3dfa780 100644
--- a/src/gsm_04_08.c
+++ b/src/gsm_04_08.c
@@ -182,6 +182,24 @@ static void allocate_loc_updating_req(struct gsm_lchan 
*lchan)
 	memset(lchan->loc_operation, 0, sizeof(*lchan->loc_operation));
 }
 
+static int gsm0408_handle_lchan_signal(unsigned int subsys, unsigned int 
signal,
+					void *handler_data, void *signal_data)
+{
+	if (subsys != SS_LCHAN || signal != S_LCHAN_UNEXPECTED_RELEASE)
+		return 0;
+
+	/* give up on the loc_operation in case of error */
+	struct gsm_lchan *lchan = (struct gsm_lchan *)handler_data;
+	release_loc_updating_req(lchan);
+
+	return 0;
+}
+
+static __attribute__((constructor)) void on_load_0408(void)
+{
+	register_signal_handler(SS_LCHAN, gsm0408_handle_lchan_signal, NULL);
+}
+
 static void to_bcd(u_int8_t *bcd, u_int16_t val)
 {
 	bcd[2] = val % 10;
-- 
1.6.3.1






From zecke at selfish.org  Sat Jun  6 12:49:10 2009
From: zecke at selfish.org (Holger Freyther)
Date: Sat, 6 Jun 2009 14:49:10 +0200
Subject: [PATCH 0/3] Updated Channel Allocation Code
Message-ID: <200906061449.11326.zecke@selfish.org>

Hey,

I posted some of these patches some time ago and started to rebase them now. 
The main idea is to make the "paging" layer more internal and only request to 
open a channel (of a specific type) to a certain subscriber.

The internal handling would find the right bts in the lac ("new" requirement 
and not yet implemented), will make sure that we assign as many as possible 
channels to the subscriber but will not lose any request (act as a queue).

I would like to merge the first two patches as I think they are moving in the 
right direction and are unlikely to break anything and plan to test the third 
patch later this week (if I get access to a BTS).

So if you will see a regression in call handling, shout at me..

         z.



 include/openbsc/gsm_data.h       |    2 
 include/openbsc/gsm_subscriber.h |    9 ++
 src/bsc_hack.c                   |    1 
 src/gsm_04_08.c                  |    6 -
 src/gsm_subscriber.c             |  139 
++++++++++++++++++++++++++++++++++++++-
 5 files changed, 153 insertions(+), 4 deletions(-)




From zecke at selfish.org  Sat Jun  6 12:49:55 2009
From: zecke at selfish.org (Holger Freyther)
Date: Sat, 6 Jun 2009 14:49:55 +0200
Subject: [PATCH 1/3] Proposal for a "channel request" interface...
In-Reply-To: <200906061449.11326.zecke@selfish.org>
References: <200906061449.11326.zecke@selfish.org>
Message-ID: <200906061449.55396.zecke@selfish.org>

From 6cec523f3c48a6b0d253a9c7405bb6797b044e68 Mon Sep 17 00:00:00 2001
From: Holger Freyther <ich at tamarin.(none)>
Date: Tue, 31 Mar 2009 04:35:19 +0200
Subject: [PATCH 1/3] Proposal for a "channel request" interface...

Reuqests for a subscriber a stored within the gsm_subscriber
datastructure and it will keep track how many channels are
allocated for this user and of which type to decide on policy...

e.g. attempt to submit SMS during a phone call and not doing
paging but a simple (immediate) assignment of the channel...
---
 include/openbsc/gsm_subscriber.h |    8 ++++++++
 src/bsc_hack.c                   |    1 +
 src/gsm_04_08.c                  |    6 +++---
 src/gsm_subscriber.c             |   26 ++++++++++++++++++++++++++
 4 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/include/openbsc/gsm_subscriber.h 
b/include/openbsc/gsm_subscriber.h
index 99148b5..abe1fd7 100644
--- a/include/openbsc/gsm_subscriber.h
+++ b/include/openbsc/gsm_subscriber.h
@@ -23,6 +23,9 @@ struct gsm_subscriber {
 	/* for internal management */
 	int use_count;
 	struct llist_head entry;
+
+	/* pending requests */
+	struct llist_head requests;
 };
 
 enum gsm_subscriber_field {
@@ -43,6 +46,11 @@ struct gsm_subscriber *subscr_get_by_imsi(const char 
*imsi);
 struct gsm_subscriber *subscr_get_by_extension(const char *ext);
 int subscr_update(struct gsm_subscriber *s, struct gsm_bts *bts, int reason);
 void subscr_put_channel(struct gsm_lchan *lchan);
+void subscr_get_channel(struct gsm_subscriber *subscr,
+                        struct gsm_bts *bts, int type,
+		        gsm_cbfn *cbfn, void *data);
+
+void subscr_init(struct gsm_network *network);
 
 /* internal */
 struct gsm_subscriber *subscr_alloc(void);
diff --git a/src/bsc_hack.c b/src/bsc_hack.c
index 188ccf6..7821044 100644
--- a/src/bsc_hack.c
+++ b/src/bsc_hack.c
@@ -983,6 +983,7 @@ static int bootstrap_network(void)
 	printf("DB: Database prepared.\n");
 
 	telnet_init(gsmnet, 4242);
+	subscr_init(gsmnet);
 
 	register_signal_handler(SS_NM, nm_sig_cb, NULL);
 
diff --git a/src/gsm_04_08.c b/src/gsm_04_08.c
index 83f38dd..040efff 100644
--- a/src/gsm_04_08.c
+++ b/src/gsm_04_08.c
@@ -1203,10 +1203,10 @@ static int gsm48_cc_rx_setup(struct msgb *msg)
 	call->called_subscr = called_subscr;
 
 	/* start paging of the receiving end of the call */
-	/* FIXME: we're assuming that the receiver is at the same BTS
-	 * than we are, which is obviously a wrong assumption in multi-BTS
+	/* FIXME: we're assuming that the receiver is at the same BSC
+	 * than we are, which is obviously a wrong assumption in multi BSC
 	 * case */
-	paging_request(msg->trx->bts, called_subscr, RSL_CHANNEED_TCH_F,
+	subscr_get_channel(called_subscr, msg->trx->bts, RSL_CHANNEED_TCH_F,
 			setup_trig_pag_evt, call);
 
 	/* send a CALL PROCEEDING message to the MO */
diff --git a/src/gsm_subscriber.c b/src/gsm_subscriber.c
index 3f608ec..19de6dc 100644
--- a/src/gsm_subscriber.c
+++ b/src/gsm_subscriber.c
@@ -27,11 +27,13 @@
 #include <string.h>
 
 #include <openbsc/gsm_subscriber.h>
+#include <openbsc/paging.h>
 #include <openbsc/debug.h>
 #include <openbsc/db.h>
 
 
 LLIST_HEAD(active_subscribers);
+struct gsm_network *gsmnet = NULL;
 
 struct gsm_subscriber *subscr_alloc(void)
 {
@@ -45,6 +47,8 @@ struct gsm_subscriber *subscr_alloc(void)
 	llist_add_tail(&s->entry, &active_subscribers);
 	s->use_count = 1;
 
+	INIT_LLIST_HEAD(&s->requests);
+
 	return s;
 }
 
@@ -131,6 +135,23 @@ struct gsm_subscriber *subscr_put(struct gsm_subscriber 
*subscr)
 	return NULL;
 }
 
+void subscr_get_channel(struct gsm_subscriber *subscr,
+			struct gsm_bts *default_bts, int type,
+			gsm_cbfn *cbfn, void *data)
+{
+	/* FIXME: Find the right BTS... */
+	struct gsm_bts *bts;
+	if (default_bts)
+		bts = default_bts;
+	else
+		bts = gsm_bts_by_lac(gsmnet, subscr->lac, NULL);
+
+	if (!bts)
+		return;
+
+	paging_request(bts, subscr, type, cbfn, data);
+}
+
 void subscr_put_channel(struct gsm_lchan *lchan)
 {
 	/*
@@ -141,3 +162,8 @@ void subscr_put_channel(struct gsm_lchan *lchan)
 	 */
 	put_lchan(lchan);
 }
+
+void subscr_init(struct gsm_network *net)
+{
+    gsmnet = net;
+}
-- 
1.6.3.1





From zecke at selfish.org  Sat Jun  6 12:50:21 2009
From: zecke at selfish.org (Holger Freyther)
Date: Sat, 6 Jun 2009 14:50:21 +0200
Subject: [PATCH 2/3] [paging] Immediately fail if we don't have something like
In-Reply-To: <200906061449.11326.zecke@selfish.org>
References: <200906061449.11326.zecke@selfish.org>
Message-ID: <200906061450.22235.zecke@selfish.org>

From 6f3d3f1b8ea8ef1e54367a0c8963c7c358addfb8 Mon Sep 17 00:00:00 2001
From: Holger Freyther <ich at tamarin.(none)>
Date: Sun, 5 Apr 2009 14:36:33 +0200
Subject: [PATCH 2/3] [paging] Immediately fail if we don't have something like 
a VLR

If we don't know where to search for a GSM subscriber then
do not try to page it at all. Introduce an enum value for this
and call the callback from within the get_channel request.
---
 include/openbsc/gsm_data.h |    1 +
 src/gsm_subscriber.c       |    8 +++++++-
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/include/openbsc/gsm_data.h b/include/openbsc/gsm_data.h
index e85adf8..297d505 100644
--- a/include/openbsc/gsm_data.h
+++ b/include/openbsc/gsm_data.h
@@ -25,6 +25,7 @@ enum gsm_hooks {
 enum gsm_paging_event {
 	GSM_PAGING_SUCCEEDED,
 	GSM_PAGING_EXPIRED,
+	GSM_PAGING_VLR_UNKNOWN,
 };
 
 struct msgb;
diff --git a/src/gsm_subscriber.c b/src/gsm_subscriber.c
index 19de6dc..d9e7116 100644
--- a/src/gsm_subscriber.c
+++ b/src/gsm_subscriber.c
@@ -147,9 +147,15 @@ void subscr_get_channel(struct gsm_subscriber *subscr,
 		bts = gsm_bts_by_lac(gsmnet, subscr->lac, NULL);
 
 	if (!bts)
-		return;
+		goto error;
 
 	paging_request(bts, subscr, type, cbfn, data);
+	return;
+
+error:
+	if (!cbfn)
+		return;
+	cbfn(GSM_HOOK_RR_PAGING, GSM_PAGING_VLR_UNKNOWN, NULL, NULL, data);
 }
 
 void subscr_put_channel(struct gsm_lchan *lchan)
-- 
1.6.3.1





From zecke at selfish.org  Sat Jun  6 12:51:01 2009
From: zecke at selfish.org (Holger Freyther)
Date: Sat, 6 Jun 2009 14:51:01 +0200
Subject: [PATCH 3/3] [channel] Handle and dispatch paging requests in
	gsm_subscriber
In-Reply-To: <200906061449.11326.zecke@selfish.org>
References: <200906061449.11326.zecke@selfish.org>
Message-ID: <200906061451.01810.zecke@selfish.org>

From d1e5ef15114ee6071597d4338500c553d9959c87 Mon Sep 17 00:00:00 2001
From: Holger Freyther <ich at tamarin.(none)>
Date: Sat, 18 Apr 2009 13:48:55 +0200
Subject: [PATCH 3/3] [channel] Handle and dispatch paging requests in 
gsm_subscriber

Implement subscr_get_channel to a degree that a pending SMS
Submit and a phone call should work.
---
 include/openbsc/gsm_data.h       |    1 +
 include/openbsc/gsm_subscriber.h |    1 +
 src/gsm_subscriber.c             |  113 ++++++++++++++++++++++++++++++++++++-
 3 files changed, 111 insertions(+), 4 deletions(-)

diff --git a/include/openbsc/gsm_data.h b/include/openbsc/gsm_data.h
index 297d505..9a13b4b 100644
--- a/include/openbsc/gsm_data.h
+++ b/include/openbsc/gsm_data.h
@@ -26,6 +26,7 @@ enum gsm_paging_event {
 	GSM_PAGING_SUCCEEDED,
 	GSM_PAGING_EXPIRED,
 	GSM_PAGING_VLR_UNKNOWN,
+	GSM_PAGING_OOM,
 };
 
 struct msgb;
diff --git a/include/openbsc/gsm_subscriber.h 
b/include/openbsc/gsm_subscriber.h
index abe1fd7..d5c2a90 100644
--- a/include/openbsc/gsm_subscriber.h
+++ b/include/openbsc/gsm_subscriber.h
@@ -25,6 +25,7 @@ struct gsm_subscriber {
 	struct llist_head entry;
 
 	/* pending requests */
+	int in_callback;
 	struct llist_head requests;
 };
 
diff --git a/src/gsm_subscriber.c b/src/gsm_subscriber.c
index d9e7116..200ac8f 100644
--- a/src/gsm_subscriber.c
+++ b/src/gsm_subscriber.c
@@ -25,16 +25,78 @@
 #include <stdlib.h>
 #include <stdio.h>
 #include <string.h>
+#include <assert.h>
 
 #include <openbsc/gsm_subscriber.h>
 #include <openbsc/paging.h>
 #include <openbsc/debug.h>
+#include <openbsc/paging.h>
 #include <openbsc/db.h>
 
-
 LLIST_HEAD(active_subscribers);
 struct gsm_network *gsmnet = NULL;
 
+/*
+ * Struct for pending channel requests. This is managed in the
+ * llist_head requests of each subscriber. The reference counting
+ * should work in such a way that a subscriber with a pending request
+ * remains in memory.
+ */
+struct subscr_request {
+	struct llist_head entry;
+
+	/* back reference */
+	struct gsm_subscriber *subscr;
+
+	/* the requested channel type */
+	int channel_type;
+
+	/* the bts we have decided to use */
+	struct gsm_bts *bts;
+
+	/* the callback data */
+	gsm_cbfn *cbfn;
+	void *data;
+};
+
+/*
+ * We got the channel assigned and can now hand this channel
+ * over to one of our callbacks.
+ */
+static int subscr_paging_cb(unsigned int hooknum, unsigned int event,
+			     struct msgb *msg, void *data, void *param)
+{
+	struct subscr_request *request;
+	struct gsm_subscriber *subscr = (struct gsm_subscriber *)data;
+
+	assert(!llist_empty(&subscr->requests));
+
+	/*
+	 * FIXME: What to do with paging requests coming during
+	 * this callback? We must be sure to not start paging when
+	 * we have an active connection to a subscriber and to make
+	 * the subscr_put_channel work as required...
+	 */
+	request = (struct subscr_request *)subscr->requests.next;
+	llist_del(&request->entry);
+	subscr->in_callback = 1;
+	request->cbfn(hooknum, event, msg, request->data, param);
+	subscr->in_callback = 0;
+
+	free(request);
+	return 0;
+}
+
+static void subscr_send_paging_request(struct gsm_subscriber *subscr)
+{
+	struct subscr_request *request;
+	assert(!llist_empty(&subscr->requests));
+
+	request = (struct subscr_request *)subscr->requests.next;
+	paging_request(request->bts, subscr, request->channel_type,
+		       subscr_paging_cb, subscr);
+}
+
 struct gsm_subscriber *subscr_alloc(void)
 {
 	struct gsm_subscriber *s;
@@ -139,8 +201,10 @@ void subscr_get_channel(struct gsm_subscriber *subscr,
 			struct gsm_bts *default_bts, int type,
 			gsm_cbfn *cbfn, void *data)
 {
-	/* FIXME: Find the right BTS... */
+	struct subscr_request *request;
 	struct gsm_bts *bts;
+
+	/* FIXME: Find the right BTS... */
 	if (default_bts)
 		bts = default_bts;
 	else
@@ -149,8 +213,34 @@ void subscr_get_channel(struct gsm_subscriber *subscr,
 	if (!bts)
 		goto error;
 
-	paging_request(bts, subscr, type, cbfn, data);
-	return;
+	request = (struct subscr_request *)malloc(sizeof(*request));
+	if (!request) {
+		if (cbfn)
+			cbfn(GSM_HOOK_RR_PAGING, GSM_PAGING_OOM,
+				NULL, NULL, data);
+		return;
+	}
+
+	memset(request, 0, sizeof(*request));
+	request->bts = bts;
+	request->subscr = subscr;
+	request->channel_type = type;
+	request->cbfn = cbfn;
+	request->data = data;
+
+	/*
+	 * FIXME: We might be able to assign more than one
+	 * channel, e.g. voice and SMS submit at the same
+	 * time.
+	 */
+	if (!subscr->in_callback && llist_empty(&subscr->requests)) {
+		/* add to the list, send a request */
+		llist_add_tail(&request->entry, &subscr->requests);
+		subscr_send_paging_request(subscr);
+	} else {
+		/* this will be picked up later */
+		llist_add_tail(&request->entry, &subscr->requests);
+	}
 
 error:
 	if (!cbfn)
@@ -166,7 +256,22 @@ void subscr_put_channel(struct gsm_lchan *lchan)
 	 * of the lchan after having asked the next requestee to handle
 	 * the channel.
 	 */
+	/*
+	 * FIXME: is the lchan is of a different type we could still
+	 * issue an immediate assignment for another channel and then
+	 * close this one.
+	 */
+	/*
+	 * Currently we will drop the last ref of the lchan which
+	 * will result in a channel release on RSL and we will start
+	 * the paging. This should work most of the time as the MS
+	 * will listen to the paging requests before we timeout
+	 */
+
 	put_lchan(lchan);
+
+	if (lchan->subscr && !llist_empty(&lchan->subscr->requests))
+	    subscr_send_paging_request(lchan->subscr);
 }
 
 void subscr_init(struct gsm_network *net)
-- 
1.6.3.1





From spaar at mirider.augusta.de  Sat Jun  6 16:26:55 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Sat, 06 Jun 2009 16:26:55 CEST
Subject: Some notes about BS-11 clock calibration
Message-ID: <4a2a98d0.mirider@mirider.augusta.de>

Hello,

I did a few tests with the BS-11 clock. I wanted to
find out how accurate the clock of the BS-11 is and how
the calibration value influences the clock. This is only
about one BS-11, but I guess the others are similar.

To control the BS-11 clock I used a slightly modified HFC-E1
card, instead of the 32.768 MHz oscillator of the card an
external signal from an accurate and stable clock source is 
used.

The BS-11 "PLL Mode" is set to "Locked" so that it locks to the
E1 clock. I am observing the PLL "Work Value" which is the actual
value used by the PLL. I also measured the RF frequency of the BS-11.

  HFC-E1 clock is 32.768 MHz:             PLL Work Value is 1024
  HFC-E1 clock is 32.768 MHz + 0.1 ppm:   PLL Work Value is  941
  HFC-E1 clock is 32.768 MHz - 0.1 ppm:   PLL Work Value is 1116

So a lower PLL calibration value means a higher frequency.

Another observation is that the actual RF frequency is following the
E1 clock slowly. For example if the E1 clock is changed by 0.1 ppm,
the RF frequency is slowly changing until after several minutes it
has also changed by 0.1 ppm. The PLL "Working Value" is following
even slower, it takes nearly an hour until is has settled to a
stable value.

The clock of the BS-11 is very stable, if set to "Stand Alone"
the RF frequency is not changing very much, its much less than
the required 0.05 ppm from the GSM specification for a BTS.

Another interesting thing is that the factory PLL calibration of
this BS-11 is 1016, very close to 1024 of the measured value.

What does that all mean ? 

If you want to calibrate the clock of your BS-11 by using a HFC-E1 
card which is synchronized from a stable and accurate clock (Andreas 
explained how this can be done with a second ISDN card) I would 
recommend to do the following:

  - let the BS-11 warm up for at least one hour

  - set the "PLL Mode" to "Locked" with bs11_config

  - start bsc_hack and let it run for an hour so that the PLL can
    adjust to the E1 clock and the PLL "Work Value" settles (you
    can use bs11_config to watch the value).

  - set the "PLL Mode" to "Stand Alone" with bs11_config, this
    makes sure that the PLL "Work Value" will no longer change and
    is used next time, even if the HFC-E1 clock is no longer 
    synchronized. The BS-11 oscillator should be stable enough so 
    that there is no need for continuous synchronisation with an 
    external reference.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From laforge at gnumonks.org  Mon Jun  8 08:28:54 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 8 Jun 2009 16:28:54 +0800
Subject: Some notes about BS-11 clock calibration
In-Reply-To: <4a2a98d0.mirider@mirider.augusta.de>
References: <4a2a98d0.mirider@mirider.augusta.de>
Message-ID: <20090608082854.GL4106@prithivi.gnumonks.org>

Dieter,

you are my hero.

The various clock related issues that people have been describing already gave
me a lot of headache.  With the method you described in your mail we now have a
documented way how to make sure the BS-11 runs on the 'right' frequency.

Thanks!
-- 
- 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 spaar at mirider.augusta.de  Mon Jun  8 13:35:06 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Mon, 08 Jun 2009 13:35:06 CEST
Subject: Some notes about BS-11 clock calibration
Message-ID: <4a2d138a.mirider@mirider.augusta.de>

Hello Harald,

On Mon, 8 Jun 2009 16:28:54 +0800, "Harald Welte" <laforge at gnumonks.org> wrote:
> 
> The various clock related issues that people have been describing already gave
> me a lot of headache.  With the method you described in your mail we now have a
> documented way how to make sure the BS-11 runs on the 'right' frequency.

Thank you, I hope that together with the description and tool from
Andreas it will help to solve any issues related to the BS-11 clock.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From Andreas.Eversberg at versatel.de  Mon Jun  8 09:45:03 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 8 Jun 2009 11:45:03 +0200
Subject: No subject
Message-ID: <B16317F2B1592B4492FC414114171CE6768461@FLBVEXCH01.versatel.local>

hi,
 
this small tool is used to enable layer 1 and 2 on a given isdn card.
the card can be used to retrieve clock signal from a network. layer 2
(PTP) is required to keep layer 1 without interruption. this tool works
on e1 and s0 cards. to use the clock signal with other cards,
interconnection with a clock-slave-card is required.
 
this tool is GPL v2. the import to the subversion server on
bs11-abis.gnumonks.org is welcome.
 
a documentation with card interconnection howto does not exist, but if
someone really successfully connects two cards (HFC-S PCI and HFC-E1),
we can write one from these experiences.
 
regards,
 
andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090608/59018480/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: isdnsync_v1.tar.gz
Type: application/x-gzip
Size: 5384 bytes
Desc: isdnsync_v1.tar.gz
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090608/59018480/attachment.bin>

From zecke at selfish.org  Mon Jun  8 09:55:55 2009
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 8 Jun 2009 11:55:55 +0200
Subject: isdnsync
In-Reply-To: <B16317F2B1592B4492FC414114171CE6768461@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE6768461@FLBVEXCH01.versatel.local>
Message-ID: <200906081155.56025.zecke@selfish.org>

On Monday 08 June 2009 11:45:03 Andreas.Eversberg wrote:
> hi,
>
> this small tool is used to enable layer 1 and 2 on a given isdn card.
> the card can be used to retrieve clock signal from a network. layer 2
> (PTP) is required to keep layer 1 without interruption. this tool works
> on e1 and s0 cards. to use the clock signal with other cards,
> interconnection with a clock-slave-card is required.
>
> this tool is GPL v2. the import to the subversion server on
> bs11-abis.gnumonks.org is welcome.
>
> a documentation with card interconnection howto does not exist, but if
> someone really successfully connects two cards (HFC-S PCI and HFC-E1),
> we can write one from these experiences.

Cool, two small questions. Do you mind if I add a "g" to your name in the 
isdnsync.c, or did I always misspell your name? The second one is if the 
OpenBSC svn is to be preferred over misdn-utils?

z.



From Andreas.Eversberg at versatel.de  Mon Jun  8 10:05:09 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 8 Jun 2009 12:05:09 +0200
Subject: AW: isdnsync
Message-ID: <B16317F2B1592B4492FC414114171CE67684B1@FLBVEXCH01.versatel.local>

the "g" is missing. maybe i lost the "g" while copying.
 
i prefer OpenBSC svn because the tool is currently usefull for OpenBSC only. 
 
-----Urspr?ngliche Nachricht-----
Von: openbsc-bounces at lists.gnumonks.org [mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von Holger Freyther
Gesendet: Montag, 8. Juni 2009 11:56
An: openbsc at lists.gnumonks.org
Betreff: Re: isdnsync
 
Cool, two small questions. Do you mind if I add a "g" to your name in the 
isdnsync.c, or did I always misspell your name? The second one is if the 
OpenBSC svn is to be preferred over misdn-utils?
 
z.




From zecke at selfish.org  Mon Jun  8 11:52:42 2009
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 8 Jun 2009 13:52:42 +0200
Subject: isdnsync
In-Reply-To: <B16317F2B1592B4492FC414114171CE67684B1@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE67684B1@FLBVEXCH01.versatel.local>
Message-ID: <200906081352.43264.zecke@selfish.org>

On Monday 08 June 2009 12:05:09 Andreas.Eversberg wrote:
> the "g" is missing. maybe i lost the "g" while copying.
>
> i prefer OpenBSC svn because the tool is currently usefull for OpenBSC
> only.

thanks. i put it into the svn.

z.



From Andreas.Eversberg at versatel.de  Tue Jun  9 07:46:23 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 9 Jun 2009 09:46:23 +0200
Subject: patch 28: wrieshark pcap logging
Message-ID: <B16317F2B1592B4492FC414114171CE67DE3EA@FLBVEXCH01.versatel.local>

This patch fixes the PCAP logging. If frames are received from E1
interface, an 8 byte mISDN header (MISDN_HEADER_LEN) is in front of the
RSL packet. When frames are transmitted to the E1 interface, the
pcap_write_packet function will get a message buffer without the mISDN
header in front of the RSL packet. The pcap file was tested and the
output is correct.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 28_wireshark.patch
Type: application/octet-stream
Size: 1164 bytes
Desc: 28_wireshark.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090609/697f7ca6/attachment.obj>

From zecke at selfish.org  Tue Jun  9 06:35:31 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 9 Jun 2009 08:35:31 +0200
Subject: patch 28: wrieshark pcap logging
In-Reply-To: <B16317F2B1592B4492FC414114171CE67DE3EA@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE67DE3EA@FLBVEXCH01.versatel.local>
Message-ID: <200906090835.32118.zecke@selfish.org>

On Tuesday 09 June 2009 09:46:23 Andreas.Eversberg wrote:
> This patch fixes the PCAP logging. If frames are received from E1
> interface, an 8 byte mISDN header (MISDN_HEADER_LEN) is in front of the
> RSL packet. When frames are transmitted to the E1 interface, the
> pcap_write_packet function will get a message buffer without the mISDN
> header in front of the RSL packet. The pcap file was tested and the
> output is correct.

Cool, you are right about the misdn.c case. in the ip-access case it is 
different. It looks like we should use msg->l2h instead of msg->data in the 
write_pcap_output. Could you attempt doing that with msg->l2h, e.g. add the 
mISDNheader in the msgb struct and set it in misdn.c and use it in the 
write_pcap_output?

	z.



From zecke at selfish.org  Wed Jun 10 13:06:34 2009
From: zecke at selfish.org (Holger Freyther)
Date: Wed, 10 Jun 2009 15:06:34 +0200
Subject: patch 28: wrieshark pcap logging
In-Reply-To: <B16317F2B1592B4492FC414114171CE67DE3EA@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE67DE3EA@FLBVEXCH01.versatel.local>
Message-ID: <200906101506.34961.zecke@selfish.org>

On Tuesday 09 June 2009 09:46:23 Andreas.Eversberg wrote:
> This patch fixes the PCAP logging. If frames are received from E1
> interface, an 8 byte mISDN header (MISDN_HEADER_LEN) is in front of the
> RSL packet. When frames are transmitted to the E1 interface, the
> pcap_write_packet function will get a message buffer without the mISDN
> header in front of the RSL packet. The pcap file was tested and the
> output is correct.

I just pushed this change. The ipaccess.c didn't use the method used to 
dispatch the data to NM or RSL so was already broken in regard to write
down incoming packets and you patch didn't break it anymore.

My original comment still holds true that this code should use msgb_l2 and 
msgb_l2len instead of msgb->data and we should fix that in a follow on commit.

z.



From Andreas.Eversberg at versatel.de  Tue Jun  9 07:49:31 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 9 Jun 2009 09:49:31 +0200
Subject: patch 31: fixed option for db selection
Message-ID: <B16317F2B1592B4492FC414114171CE67DE3FB@FLBVEXCH01.versatel.local>



the database select option "-l" did not work:

-		c = getopt_long(argc, argv, "hc:n:d:sar:p:f:t:C:RL:",
+		c = getopt_long(argc, argv, "hc:n:d:sar:p:f:t:C:RL:l:",

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 31_bsc_hack_db.patch
Type: application/octet-stream
Size: 423 bytes
Desc: 31_bsc_hack_db.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090609/871f05c1/attachment.obj>

From Andreas.Eversberg at versatel.de  Tue Jun  9 07:55:28 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 9 Jun 2009 09:55:28 +0200
Subject: patch 32: subscr_update() missing.
Message-ID: <B16317F2B1592B4492FC414114171CE67DE41E@FLBVEXCH01.versatel.local>


If location update is requested, but subscriber is not yet authorised
within mm_rx_loc_upd_req() function, the subscr_update() is not called,
because subscriber information is not complete.
During mm_rx_id_resp() the subscriber informations is may be complete,
so authorize subscriber succeeds and database must be updated.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 32_subscr_update.patch
Type: application/octet-stream
Size: 554 bytes
Desc: 32_subscr_update.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090609/100d22c6/attachment.obj>

From zecke at selfish.org  Tue Jun  9 06:09:11 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 9 Jun 2009 08:09:11 +0200
Subject: patch 32: subscr_update() missing.
In-Reply-To: <B16317F2B1592B4492FC414114171CE67DE41E@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE67DE41E@FLBVEXCH01.versatel.local>
Message-ID: <200906090809.11628.zecke@selfish.org>

On Tuesday 09 June 2009 09:55:28 Andreas.Eversberg wrote:
> If location update is requested, but subscriber is not yet authorised
> within mm_rx_loc_upd_req() function, the subscr_update() is not called,
> because subscriber information is not complete.
> During mm_rx_id_resp() the subscriber informations is may be complete,
> so authorize subscriber succeeds and database must be updated.

Right, but why allocate the tmsi afterwards? It doesn't matter right now but I  
changed the order to match the other call site... at least the code 
duplication is not consistent.

thanks!

z.



From Andreas.Eversberg at versatel.de  Tue Jun  9 08:14:31 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 9 Jun 2009 10:14:31 +0200
Subject: patch: 30
Message-ID: <B16317F2B1592B4492FC414114171CE67DE477@FLBVEXCH01.versatel.local>

my subsequent patches are dependant on the patches by holger from may 5th. for personal testing and for information, i packed them together. i tested them and they work well.
 
 

 

Mit freundlichen Gr??en,

                                                                  .-.
                                                                 /'v'\
                                                                (/   \)
------------------------------------------------------------------"-"-
                                                                  |_|
i.A. Andreas Eversberg
Administrator
Betrieb und Entst?rung

Versatel Nord GmbH

Nordstr. 2
D-24937 Flensburg

Fon: +49-461-9099749 | Fax: +49-461-909960749
andreas.eversberg at versatel.de@versatel.de | www.versatel.de

Sitz der Gesellschaft: Flensburg, Registergericht: Flensburg, HRB 3395 FL
Gesch?ftsf?hrer: Soeren Wendler, Dr. Hai Cheng, Dr. Max Padberg, Peter Schindler, Joachim Bellinghoven 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090609/0a59e6df/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 30_holger0-3.patch
Type: application/octet-stream
Size: 4172 bytes
Desc: 30_holger0-3.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090609/0a59e6df/attachment.obj>

From zecke at selfish.org  Tue Jun  9 06:49:19 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 9 Jun 2009 08:49:19 +0200
Subject: patch: 30
In-Reply-To: <B16317F2B1592B4492FC414114171CE67DE477@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE67DE477@FLBVEXCH01.versatel.local>
Message-ID: <200906090849.19326.zecke@selfish.org>

On Tuesday 09 June 2009 10:14:31 Andreas.Eversberg wrote:
> my subsequent patches are dependant on the patches by holger from may 5th.
> for personal testing and for information, i packed them together. i tested
> them and they work well.

Cool. I will take this as an ack to land them... There is one change you made 
and it looks like this one:

 
@@ -941,7 +956,6 @@
        if (!subscr) {
                DEBUGP(DRR, "<- Can't find any subscriber for this ID\n");
                /* FIXME: request id? close channel? */
-               return -EINVAL;
        }
        DEBUGP(DRR, "<- Channel was requested by %s\n",
                subscr->name ? subscr->name : subscr->imsi);

We have two cases in there that will return -EINVAL. Maybe we should replace 
both with an error signal?

	z.



From Andreas.Eversberg at versatel.de  Tue Jun  9 08:18:09 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 9 Jun 2009 10:18:09 +0200
Subject: patch 33: db fix
Message-ID: <B16317F2B1592B4492FC414114171CE67DE485@FLBVEXCH01.versatel.local>

during attachment, the "tmsi" field of the subscriber may be an empty
string, so the string must be quoted in the sql request, or the sql
request fails due to incorrect syntax.

also i added "extension" field to debug output.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 33_db_fix.patch
Type: application/octet-stream
Size: 933 bytes
Desc: 33_db_fix.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090609/8bef7e24/attachment.obj>

From Andreas.Eversberg at versatel.de  Tue Jun  9 08:45:04 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 9 Jun 2009 10:45:04 +0200
Subject: patch 34: paging lac
Message-ID: <B16317F2B1592B4492FC414114171CE67DE500@FLBVEXCH01.versatel.local>

this patch will use the gsm_bts_by_lac() function to start paging of all
bts' with the same lac.
when paging is successfull, the paging_request_stop() function is called
with the current lchan, so the callback function will be called. for all
other bts', the paging_request_stop() function is called without lchan,
so the paging is stopped, but the callback function is not called.

this ensures that only one paging result is received when paging
multiple BTS.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 34_paging_lac.patch
Type: application/octet-stream
Size: 2630 bytes
Desc: 34_paging_lac.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090609/70c065b3/attachment.obj>

From zecke at selfish.org  Tue Jun  9 06:56:11 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 9 Jun 2009 08:56:11 +0200
Subject: patch 34: paging lac
In-Reply-To: <B16317F2B1592B4492FC414114171CE67DE500@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE67DE500@FLBVEXCH01.versatel.local>
Message-ID: <200906090856.11548.zecke@selfish.org>

On Tuesday 09 June 2009 10:45:04 Andreas.Eversberg wrote:
> this patch will use the gsm_bts_by_lac() function to start paging of all
> bts' with the same lac.
> when paging is successfull, the paging_request_stop() function is called
> with the current lchan, so the callback function will be called. for all
> other bts', the paging_request_stop() function is called without lchan,
> so the paging is stopped, but the callback function is not called.
>
> this ensures that only one paging result is received when paging
> multiple BTS.


great! Reading the diff it is kind of funny we are currently sending _SUCCEED 
from paging_stop...

z.



From zecke at selfish.org  Wed Jun 10 01:03:50 2009
From: zecke at selfish.org (Holger Freyther)
Date: Wed, 10 Jun 2009 03:03:50 +0200
Subject: patch 34: paging lac
In-Reply-To: <B16317F2B1592B4492FC414114171CE67DE500@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE67DE500@FLBVEXCH01.versatel.local>
Message-ID: <200906100303.51090.zecke@selfish.org>

On Tuesday 09 June 2009 10:45:04 Andreas.Eversberg wrote:
> this patch will use the gsm_bts_by_lac() function to start paging of all
> bts' with the same lac.
> when paging is successfull, the paging_request_stop() function is called
> with the current lchan, so the callback function will be called. for all
> other bts', the paging_request_stop() function is called without lchan,
> so the paging is stopped, but the callback function is not called.
>
> this ensures that only one paging result is received when paging
> multiple BTS.

Thanks, I have merged this patch and have done two follow up changes (one to 
use called_subscr->lac) and then moved the loops into paging.c to allow 
changing the strategy in the future..

z.



From laforge at gnumonks.org  Wed Jun 10 03:49:02 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 10 Jun 2009 11:49:02 +0800
Subject: patch 34: paging lac
In-Reply-To: <200906100303.51090.zecke@selfish.org>
References: <B16317F2B1592B4492FC414114171CE67DE500@FLBVEXCH01.versatel.local>
	<200906100303.51090.zecke@selfish.org>
Message-ID: <20090610034902.GE19211@prithivi.gnumonks.org>

On Wed, Jun 10, 2009 at 03:03:50AM +0200, Holger Freyther wrote:

> Thanks, I have merged this patch and have done two follow up changes (one to 
> use called_subscr->lac) and then moved the loops into paging.c to allow 
> changing the strategy in the future..

ok, we need to merge that into the git tree now, sorry for the confusion :(

I wanted to migrate to git for more than a month and simply didn't have the
time, last night i stayed up until 4am to finally get it done.  sorry for not
announcing this before.

regards,
-- 
- 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 zecke at selfish.org  Wed Jun 10 04:10:27 2009
From: zecke at selfish.org (Holger Freyther)
Date: Wed, 10 Jun 2009 06:10:27 +0200
Subject: patch 34: paging lac
In-Reply-To: <20090610034902.GE19211@prithivi.gnumonks.org>
References: <B16317F2B1592B4492FC414114171CE67DE500@FLBVEXCH01.versatel.local>
	<200906100303.51090.zecke@selfish.org>
	<20090610034902.GE19211@prithivi.gnumonks.org>
Message-ID: <200906100610.28211.zecke@selfish.org>

On Wednesday 10 June 2009 05:49:02 Harald Welte wrote:
> On Wed, Jun 10, 2009 at 03:03:50AM +0200, Holger Freyther wrote:
> > Thanks, I have merged this patch and have done two follow up changes (one
> > to use called_subscr->lac) and then moved the loops into paging.c to
> > allow changing the strategy in the future..
>
> ok, we need to merge that into the git tree now, sorry for the confusion :(

no problem, I can just rebase....



From laforge at gnumonks.org  Wed Jun 10 03:43:01 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 10 Jun 2009 11:43:01 +0800
Subject: patch 34: paging lac
In-Reply-To: <B16317F2B1592B4492FC414114171CE67DE500@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE67DE500@FLBVEXCH01.versatel.local>
Message-ID: <20090610034301.GD19211@prithivi.gnumonks.org>

applied to the master branch of git://bs11-abis.gnumonks.org/openbsc.git

(I've converted from svn to git last night, sorry for the inconvenience)

-- 
- 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 charles at thewybles.com  Wed Jun 10 17:30:39 2009
From: charles at thewybles.com (Charles Wyble)
Date: Wed, 10 Jun 2009 10:30:39 -0700
Subject: patch 34: paging lac
In-Reply-To: <20090610034301.GD19211@prithivi.gnumonks.org>
References: <B16317F2B1592B4492FC414114171CE67DE500@FLBVEXCH01.versatel.local>
	<20090610034301.GD19211@prithivi.gnumonks.org>
Message-ID: <4A2FEDBF.6080201@thewybles.com>

Congrats! Git is so much better!. :)

Harald Welte wrote:
> applied to the master branch of git://bs11-abis.gnumonks.org/openbsc.git
> 
> (I've converted from svn to git last night, sorry for the inconvenience)
> 



From Andreas.Eversberg at versatel.de  Tue Jun  9 08:47:58 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 9 Jun 2009 10:47:58 +0200
Subject: patch 35: information element transcoding
Message-ID: <B16317F2B1592B4492FC414114171CE67DE50E@FLBVEXCH01.versatel.local>

this patch will do the transcoding of information elements. this patch
adds new functions to be used for the application interface patch, and
is basis for the application patch (currently patch 36). when applying
the patch, the compiler gives warnings, because the "static" functions
will not be used. (yet)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 35_ie_transcoding.patch
Type: application/octet-stream
Size: 15211 bytes
Desc: 35_ie_transcoding.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090609/859bfb61/attachment.obj>

From laforge at gnumonks.org  Wed Jun 10 04:06:30 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 10 Jun 2009 12:06:30 +0800
Subject: patch 35: information element transcoding
In-Reply-To: <B16317F2B1592B4492FC414114171CE67DE50E@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE67DE50E@FLBVEXCH01.versatel.local>
Message-ID: <20090610040630.GF19211@prithivi.gnumonks.org>

On Tue, Jun 09, 2009 at 10:47:58AM +0200, Andreas.Eversberg wrote:
> this patch will do the transcoding of information elements. this patch
> adds new functions to be used for the application interface patch, and
> is basis for the application patch (currently patch 36). when applying
> the patch, the compiler gives warnings, because the "static" functions
> will not be used. (yet)

All of those functions (as well as quite a bit of other code in your patches)
changes the function return value assumptions.  OpenBSC uses the kernel style
for return values, i.e. '0' on success and negative values on failure.
positive value might indicate a count, if there is something like a return
count given the context of the function.

Also, a number of your functions always return the same value (1).  If
that is not supposed to be changed (because some error checking might still
be missing), I recommend converting them to void.  However, there might also
be incentive to keep all encode_* and decode_* functions have a return value,
making it easier to write code because you know you need to check return
values all the time...

I'm re-working the patch right now
-- 
- 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090610/72437776/attachment.bin>

From Andreas.Eversberg at versatel.de  Tue Jun  9 08:56:08 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 9 Jun 2009 10:56:08 +0200
Subject: patch 37: assigning traffic channel
Message-ID: <B16317F2B1592B4492FC414114171CE67DE538@FLBVEXCH01.versatel.local>

hi,

i have a phone that requests a SDCCH channel after it is paged. (even if
paging request required a TCH Full channel.)
in this case, i assign a GSM_LCHAN_TCF_F channel except for location
update. (see patch)

in the second part of this patch, i check if the current channel is a
traffic channel. if not, we can't use it on calls BSS->MS. this happens
if a call is received after location update, but before the channel is
released. this second part depends on the application patch (36).

andreas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 37_tch_f.patch
Type: application/octet-stream
Size: 1390 bytes
Desc: 37_tch_f.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090609/53ef1065/attachment.obj>

From zecke at selfish.org  Tue Jun  9 07:08:48 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 9 Jun 2009 09:08:48 +0200
Subject: patch 37: assigning traffic channel
In-Reply-To: <B16317F2B1592B4492FC414114171CE67DE538@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE67DE538@FLBVEXCH01.versatel.local>
Message-ID: <200906090908.48495.zecke@selfish.org>

On Tuesday 09 June 2009 10:56:08 Andreas.Eversberg wrote:
> hi,
>
> i have a phone that requests a SDCCH channel after it is paged. (even if
> paging request required a TCH Full channel.)
> in this case, i assign a GSM_LCHAN_TCF_F channel except for location
> update. (see patch)
>
> in the second part of this patch, i check if the current channel is a
> traffic channel. if not, we can't use it on calls BSS->MS. this happens
> if a call is received after location update, but before the channel is
> released. this second part depends on the application patch (36).

Hey andreas,

you might make this[1] more useful and add your handset to this table (or 
actually create it).

z.

[1] http://bs11-abis.gnumonks.org/trac/wiki/HandsetBugs



From Andreas.Eversberg at versatel.de  Tue Jun  9 09:00:00 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 9 Jun 2009 11:00:00 +0200
Subject: patch 36: application interface
Message-ID: <B16317F2B1592B4492FC414114171CE67DE553@FLBVEXCH01.versatel.local>

 <<36_application.patch>> again the application patch based on the
current OpenBSC source and the other patches i posted.

i cannot split this patch, because all the parts depend on each other.
the only thing i can do, i can splitt them into their functional parts.
the libbsc will not work without applying all parts then.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 36_application.patch
Type: application/octet-stream
Size: 107150 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090609/0e650f03/attachment.obj>

From laforge at gnumonks.org  Fri Jun 12 13:11:28 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 12 Jun 2009 21:11:28 +0800
Subject: patch 36: application interface
In-Reply-To: <B16317F2B1592B4492FC414114171CE67DE553@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE67DE553@FLBVEXCH01.versatel.local>
Message-ID: <20090612131128.GL30843@prithivi.gnumonks.org>

Dear Andreas,

I have finally found some time to review the MNCC patches in detail.

There were quite a bit of details that I wanted to change, mostly about
the code and data structure.  The logic and the idea of the interface is
still the same.

You can have a look at my code in the 'mncc-harald' branch of the new
git tree.  It's probably easiest if you look at the new mncc.h file.  Instead
of a flat list of fields, I decided for a bit more structure.  This results
in a situation where most of the ancode_foo() and decode_foo() functions
now only take a pointer to a sub-structure, rather than a long list of
arguments.  I think this is much better to understand - and also reduces
the number of lines that are either long or have to be broken in many more lines,
resulting in less code visibility on one screen page.

Furthermore, I've introduced some additional functions like mncc_set_cause()
for constantly repeated sequences of code.

Changing mncc.h obviously breaks interoperability with your lcr, and I'm
honestly sorry about that.  I'm not planning any intentional data structure
changes any time soon.

I've tested the standalone bsc_hack of the mncc-harald branch for quite some time
on a nanobts1800, it works fine.

I have some more thoughts on improving MNCC, but those changes would only
affect the implementation, not the interface.  I don't like the many explicit
lists of "if (TLVP_PRESENT(&tp, ...)) decode_something" sequences.  If we had something like a table of

========
struct parser_def {
	u_int8_t	tlv_tag;
	u_int32_t	field_flag;
	unsigned int	member_offset;
	(int)		(decode_function)(void *, u_int8_t *lv);
};

struct parser_def parser_defs[] = {
	{ GSM48_IE_SS_VERS, MNCC_F_SSVERSION,
	  offset_of(ssversion_info, struct gsm_mncc),
	  &decode_ssversion },
	...
};
========

then we could do something like have a for-loop and then only one statement
like this:
========
	struct parser_def *pd;

	if (TLVP_PRESENT(&tp, pd->tlv_tag)) {
		connect.fields |= pd->field_tag;
		pd->decode_function(&connect + pd->member_offset,
				    TLVP_VAL(&tp, pd->tlv_tag)-1);
	}
========

It would replace a lot of explicit open-coded code (38 incarnations!) with a
more data-driven model.

Regards,
-- 
- 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 Andreas.Eversberg at versatel.de  Tue Jun  9 09:09:17 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 9 Jun 2009 11:09:17 +0200
Subject: inofficioal test
Message-ID: <B16317F2B1592B4492FC414114171CE67DE580@FLBVEXCH01.versatel.local>

hi,
 
i uploaded an inofficial test version of openbsc with all my patches
applied. (not the latest, but working well). you will find it here:
http://www.linux-call-router.de/download/lcr-1.5/
<http://www.linux-call-router.de/download/lcr-1.5/>   all ressources get
freed, no hanging logical channels or subscriber instances in any test
case i found.
 
also linux-call-router, an alternative application to bsc_hack, the gsm
speech codec and mISDN kernel drivers are available there.
 
a howto is in progress.
 
regards,
 
andreas
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090609/57683b51/attachment.htm>

From zecke at selfish.org  Tue Jun  9 07:58:20 2009
From: zecke at selfish.org (Holger Freyther)
Date: Tue, 9 Jun 2009 09:58:20 +0200
Subject: inofficioal test
In-Reply-To: <B16317F2B1592B4492FC414114171CE67DE580@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE67DE580@FLBVEXCH01.versatel.local>
Message-ID: <200906090958.21312.zecke@selfish.org>

On Tuesday 09 June 2009 11:09:17 Andreas.Eversberg wrote:
> hi,
>
> i uploaded an inofficial test version of openbsc with all my patches
> applied. (not the latest, but working well). you will find it here:
> http://www.linux-call-router.de/download/lcr-1.5/
> <http://www.linux-call-router.de/download/lcr-1.5/>   all ressources get
> freed, no hanging logical channels or subscriber instances in any test
> case i found.
>
> also linux-call-router, an alternative application to bsc_hack, the gsm
> speech codec and mISDN kernel drivers are available there.
>
> a howto is in progress.

congrats!



From zecke at selfish.org  Wed Jun 10 14:51:47 2009
From: zecke at selfish.org (Holger Freyther)
Date: Wed, 10 Jun 2009 16:51:47 +0200
Subject: Ideas regarding BSC/MSC split up
Message-ID: <200906101651.48269.zecke@selfish.org>

Hey Guys,

some of us started to look into the various 08.0x specs and even SCCP (not me 
yet) and I think our common goal is to go towards a more "normal" BSS/MSC and 
in the same way keeping the spirit of bsc_hack to allow to run a whole network 
with one executable.

A rough split up of BSC vs. MSC would be:

BSC has the secret of:
	- init hardware, bcch, oml/rsl setup
	- paging
	- channel allocation/management

MSC has most of the policies:
	- HLR/VLR and who to allow into the network
	- call handling etc...

To keep this short ('m quite tired at the moment) my goal/approach is to 
create a libmsc.a and move the db.c, gsm_subscriber.c and on the way to move 
policy out of gsm_04_08.c to the libmsc.a. bsc and msc would communicate with 
an API that resembles the DTAP, BSSMAP interface. The MNCC use case Andreas 
and Harald are working on should remain supported, same as the bsc_hack.c. The 
goal of having an interface like DTAP and BSSMAP is to allow implementing the 
A-Interface.

I will start this work in a branch called holger/msc and will seek for 
feedback once I have something that is worthwhile to share.

good night
	z.



From laforge at gnumonks.org  Wed Jun 10 18:34:50 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 11 Jun 2009 02:34:50 +0800
Subject: Ideas regarding BSC/MSC split up
In-Reply-To: <200906101651.48269.zecke@selfish.org>
References: <200906101651.48269.zecke@selfish.org>
Message-ID: <20090610183450.GK4131@prithivi.gnumonks.org>

Hi Holger!

On Wed, Jun 10, 2009 at 04:51:47PM +0200, Holger Freyther wrote:
 
> some of us started to look into the various 08.0x specs and even SCCP (not me 
> yet) and I think our common goal is to go towards a more "normal" BSS/MSC and 
> in the same way keeping the spirit of bsc_hack to allow to run a whole network 
> with one executable.

exactly.

> To keep this short ('m quite tired at the moment) my goal/approach is to 
> create a libmsc.a and move the db.c, gsm_subscriber.c and on the way to move 
> policy out of gsm_04_08.c to the libmsc.a. bsc and msc would communicate with 
> an API that resembles the DTAP, BSSMAP interface. The MNCC use case Andreas 
> and Harald are working on should remain supported, same as the bsc_hack.c. 

yes.  Basically the split you are introducing is below the MNCC and the
bsc_hack application cases.   They both use [parts of] MSC and BSC functionality,
i.e. can be implemented on top of the libmsc + libbsc combination that you're
aiming for.

> I will start this work in a branch called holger/msc and will seek for 
> feedback once I have something that is worthwhile to share.

great. good luck!

-- 
- 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090611/3d1baadf/attachment.bin>

From zecke at selfish.org  Fri Jun 12 15:36:32 2009
From: zecke at selfish.org (Holger Freyther)
Date: Fri, 12 Jun 2009 17:36:32 +0200
Subject: Ideas regarding BSC/MSC split up
In-Reply-To: <200906101651.48269.zecke@selfish.org>
References: <200906101651.48269.zecke@selfish.org>
Message-ID: <200906121736.32873.zecke@selfish.org>

On Wednesday 10 June 2009 16:51:47 Holger Freyther wrote:

> I will start this work in a branch called holger/msc and will seek for
> feedback once I have something that is worthwhile to share.

Just a quick status update on the above named branch. First of all it exists 
now and has the first bits of the abstraction...

The problems:
	- We use gsm_subscriber and the db in places were we should not
          (find_by_tmsi, find_by_imsi...)
	- We do channel management in layer3 code were we should not
          (lchan_put, lchan_auto_release)

What was done so far:
	- Create libmsc.a
	- Move db.c, telnet_interface.c there initially
	- Move functionality of gsm_subscriber.c that uses a DB to the MSC
        - Move high level part of paging response to MSC (the BSC part
          needs to be that way but is a violation of the spec...)
       - Move location updating request handling to msc_loc.c


What needs to be done:
	- Move CC and SMS part to the MSC layer (I wait for harald to finish the
          mncc stuff first to avoid a big merge catastrophe)
	- Change paging to be internal to the BSC. When to stop/retire a paging
          request? In one way the BSC is not supposed to look at the PAGING 
	  RESPONSE (see 08.08), but I could not find a "stop" paging... so we will
	  have to tell the paging layer somehow to stop... without doing it too early
          (that is what currently happens...)

The interface:
       - BSC to MSC passes struct msgb* from gsm_04_08.c via a gsm layer3
         callback that is stored in the gsm_network
	- MSC to BSC work by sending a struct msgb* using the existing send
	 msg function.

please take a look and scream if you think it goes in the wrong direction...

z.



From e.cathelinaud at googlemail.com  Thu Jun 11 17:19:40 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Thu, 11 Jun 2009 19:19:40 +0200
Subject: Question: Allow Mobile Attach
Message-ID: <383f8f9a0906111019r9f34dbeu1406cd736265738b@mail.gmail.com>

Hi!

I am trying to understand the code to make several tests.
If I understand, the default setting is to refuse any phone trying to
connect the network?
I would like to change this in the code to accept everyone.
I saw in bsc_hack the Control Channel Description which seems to deal with
this. Am I wrong?

static u_int8_t si3[] = {
    /* header */0x49, 0x06, 0x1B,
    /* cell */0x00, 0x01,
    /* lai  */0x00, 0xF1, 0x10, 0x00, 0x01,
    /* desc */0x01, 0x03, 0x00,                    //Control Channel
Description
    /* option*/0x28,
    /* selection*/0x62, 0x00,
    /* rach */0xD5, 0x00, 0x00,
    /* reset*/0x80, 0x00, 0x00, 0x2B
};

Which value shall I put to accept everyone?


Thanks!

Best regards
Eric Cathelinaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090611/b3cab096/attachment.htm>

From zecke at selfish.org  Fri Jun 12 02:07:01 2009
From: zecke at selfish.org (Holger Freyther)
Date: Fri, 12 Jun 2009 04:07:01 +0200
Subject: Question: Allow Mobile Attach
In-Reply-To: <383f8f9a0906111019r9f34dbeu1406cd736265738b@mail.gmail.com>
References: <383f8f9a0906111019r9f34dbeu1406cd736265738b@mail.gmail.com>
Message-ID: <200906120407.01436.zecke@selfish.org>

On Thursday 11 June 2009 19:19:40 Eric Cathelinaud wrote:
> Hi!
>
> I am trying to understand the code to make several tests.
> If I understand, the default setting is to refuse any phone trying to
> connect the network?
> I would like to change this in the code to accept everyone.
> I saw in bsc_hack the Control Channel Description which seems to deal with
> this. Am I wrong?

Accept everyone? as in location updating request? There should be a command 
line option for it. The thing that is missing to make this really useful is 
that no one in the network got an "extension" assigned so calling, SMS, etc. 
is not useful...

z.



From dburgess at jcis.net  Fri Jun 12 04:06:36 2009
From: dburgess at jcis.net (David A. Burgess)
Date: Thu, 11 Jun 2009 21:06:36 -0700
Subject: Question: Allow Mobile Attach
In-Reply-To: <200906120407.01436.zecke@selfish.org>
References: <383f8f9a0906111019r9f34dbeu1406cd736265738b@mail.gmail.com>
	<200906120407.01436.zecke@selfish.org>
Message-ID: <F8A193FE-081D-4AB9-A282-39C754B6CE5E@jcis.net>

Yes.  This is very useful feature in some legitimate applications,  
like handset testing and disaster relief.  It also makes it very easy  
to accidentally block cellular service for random subscribers in your  
test area if you forget that it is turned on.  If you put a feature  
like this on you system, you might also consider delivering a test  
message to the newly attached subscriber telling them what has  
happened.  Otherwise the system too easily lends itself to abuse.

-- David


On Jun 11, 2009, at 7:07 PM, Holger Freyther wrote:

> On Thursday 11 June 2009 19:19:40 Eric Cathelinaud wrote:
>> Hi!
>>
>> I am trying to understand the code to make several tests.
>> If I understand, the default setting is to refuse any phone trying to
>> connect the network?
>> I would like to change this in the code to accept everyone.
>> I saw in bsc_hack the Control Channel Description which seems to  
>> deal with
>> this. Am I wrong?
>
> Accept everyone? as in location updating request? There should be a  
> command
> line option for it. The thing that is missing to make this really  
> useful is
> that no one in the network got an "extension" assigned so calling,  
> SMS, etc.
> is not useful...
>
> z.


David A. Burgess
Kestrel Signal Processing, Inc.







From zecke at selfish.org  Fri Jun 12 04:31:55 2009
From: zecke at selfish.org (Holger Freyther)
Date: Fri, 12 Jun 2009 06:31:55 +0200
Subject: Question: Allow Mobile Attach
In-Reply-To: <F8A193FE-081D-4AB9-A282-39C754B6CE5E@jcis.net>
References: <383f8f9a0906111019r9f34dbeu1406cd736265738b@mail.gmail.com>
	<200906120407.01436.zecke@selfish.org>
	<F8A193FE-081D-4AB9-A282-39C754B6CE5E@jcis.net>
Message-ID: <200906120631.56302.zecke@selfish.org>

On Friday 12 June 2009 06:06:36 David A. Burgess wrote:
> Yes.  This is very useful feature in some legitimate applications,
> like handset testing and disaster relief.  It also makes it very easy
> to accidentally block cellular service for random subscribers in your
> test area if you forget that it is turned on.  If you put a feature
> like this on you system, you might also consider delivering a test
> message to the newly attached subscriber telling them what has
> happened.  Otherwise the system too easily lends itself to abuse.


Good idea, we added this switch as sort of hack for the 25c3 to send 
invitations. So what we could do would be let the "unauthorized" user in, 
assign an extension from a pool, send the user a SMS with his number.

thanks for the hint
	z.



From smith_fabian at yahoo.com  Sat Jun 13 17:24:29 2009
From: smith_fabian at yahoo.com (FABIAN SMITH)
Date: Sat, 13 Jun 2009 10:24:29 -0700 (PDT)
Subject: Open bsc + trixbox
Message-ID: <41431.77189.qm@web36103.mail.mud.yahoo.com>

Will openbsc work with trixbox or other pbx's ?



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

From laforge at gnumonks.org  Sun Jun 14 02:28:09 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 14 Jun 2009 10:28:09 +0800
Subject: Open bsc + trixbox
In-Reply-To: <41431.77189.qm@web36103.mail.mud.yahoo.com>
References: <41431.77189.qm@web36103.mail.mud.yahoo.com>
Message-ID: <20090614022809.GH2854@prithivi.gnumonks.org>

On Sat, Jun 13, 2009 at 10:24:29AM -0700, FABIAN SMITH wrote:
> Will openbsc work with trixbox or other pbx's ?

This is a community project, and it lives by contributions.  So if somebody
(maybe even you) will write support for it and contribute it back to us,
OpenBSC will work with it :)

So far, only a specific branch of the development is able to work with lcr,
see the various posts by Andreas Eversberg.

The main focus of the core developers so far is on the GSM protocol side,
not so much on the 'integrating with every PBX system out there' side.
-- 
- 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 Andreas.Eversberg at versatel.de  Sun Jun 14 12:26:53 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Sun, 14 Jun 2009 14:26:53 +0200
Subject: AW: Open bsc + trixbox
Message-ID: <B16317F2B1592B4492FC414114171CE6817D9D@FLBVEXCH01.versatel.local>

hi fabian,
 
trixbox uses asterisk. asterisk is supported by linux-call-router
(integrated channel driver). linux-call-router is supports a modified
version of openbsc. (see last post) so you can use trixbox with openbsc.
 
regards,
 
andreas
 

________________________________

Von: openbsc-bounces at lists.gnumonks.org
[mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von FABIAN SMITH
Gesendet: Samstag, 13. Juni 2009 19:24
An: openbsc at lists.gnumonks.org
Betreff: Open bsc + trixbox


Will openbsc work with trixbox or other pbx's ?
	

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

From Andreas.Eversberg at versatel.de  Sun Jun 14 12:20:39 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Sun, 14 Jun 2009 14:20:39 +0200
Subject: fixes for mncc-harald branch
Message-ID: <B16317F2B1592B4492FC414114171CE6871F1F@FLBVEXCH01.versatel.local>

hi,
 
finally i ported linux-call-router to new mncc api. this is quite easy,
because only data types changed. i don't care about change of mncc api
from time to time, because openbsc does not have that much applications
yet. i think that trau frames don't have anything todo with mncc api and
should be use own interface in the future (hopefully with ipaccess).
 
i tested openbsc with linux-call-router. everything worked fine after
adding some fixes. now, the mncc-harald includes every work i made,
except the installation of library and include files.
 
fix 1: i use this workarround to allow my mobile to get a traffic
channel. the mobile reqests a sdcch channel, but currently openbsc is
not able to switch channel. (this should be possible in the future for
handover.) also it checks if there is actually a traffic channel
currently in use, when making a call.
 
fix 2: not actually a fix: adding imsi to gsm_mncc_number allows to
notify application about calling/connected imsi. also it is possible to
dial a subscriber with no extension assigned, just by using imsi. maybe
it is wiser to put imsi string into gsm_mncc, because it is only used
only once in a message.
 
fix 3: while detaching, we don't hold a ressource (we don't call
lchan_use), so we don't need to "lchan_put".
 
fix 4: the given cause value and location parameters are used in
mncc_release_ind function, rather than hardcoded. the plain cause
numbers are replaced by the definitions from header file.
 
additionally i uploaded a new inofficial version of openbsc and
linux-call-router at www.linux-call-router.de. 
 
andreas
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090614/6597eaaf/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_4.patch
Type: application/octet-stream
Size: 4439 bytes
Desc: fix_4.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090614/6597eaaf/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_1.patch
Type: application/octet-stream
Size: 1690 bytes
Desc: fix_1.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090614/6597eaaf/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_2.patch
Type: application/octet-stream
Size: 2337 bytes
Desc: fix_2.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090614/6597eaaf/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_3.patch
Type: application/octet-stream
Size: 573 bytes
Desc: fix_3.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090614/6597eaaf/attachment-0003.obj>

From laforge at gnumonks.org  Sun Jun 14 14:14:01 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 14 Jun 2009 22:14:01 +0800
Subject: fixes for mncc-harald branch
In-Reply-To: <B16317F2B1592B4492FC414114171CE6871F1F@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE6871F1F@FLBVEXCH01.versatel.local>
Message-ID: <20090614141401.GS2854@prithivi.gnumonks.org>

Hi Andreas,

On Sun, Jun 14, 2009 at 02:20:39PM +0200, Andreas.Eversberg wrote:
  
> finally i ported linux-call-router to new mncc api. this is quite easy,
> because only data types changed. 

thanks!

> i don't care about change of mncc api from time to time, because openbsc does
> not have that much applications yet. 

thanks, that's good to hear.  We should probably introduce an API version
number somewhere to make it fail gracefully if something changes [but still
compiles/links].

> i think that trau frames don't have anything todo with mncc api and
> should be use own interface in the future (hopefully with ipaccess).

ipaccess is very different from traditional TRAU frames.  To be honest, I have
not yet fully reverse engineered the RTP payload that it sends.  Initially I
assumed that it would just send the raw GSM FR/EFR/AMR data, but unfortunately
that seems not the case, as the RTP payload is too short for that.

Right now I didn't worry about it, since when we switch calls between a nanoBTS
and another nanoBTS (or the same nanoBTS), we can instruct the BTS' to send the
RTP/RTCP streams directly to each other.

In the mid-term we probably need to come up with a dedicated media gateway.
That could and should be a totally separate program, but able to bind to E1
timeslots and receive/multiplex TRAU frames, as well as receive and
interpret/switch the RTP payload as used by the nanoBTS.

If anyone wants to look further into this, I'm happy to record some PCAP files
with some example RTP/RTCP dumps.  If you want, even combined with the
TCP connection to the BSC, so you have a correct timeline and know what the BSC
told the BTS when, and how the BTS reacted to that.

> i tested openbsc with linux-call-router. everything worked fine after
> adding some fixes. now, the mncc-harald includes every work i made,
> except the installation of library and include files.

ok, thanks.  I think I'll merge mncc-harald into the master branch within
the next couple of days.

> fix 1: i use this workarround to allow my mobile to get a traffic
> channel. the mobile reqests a sdcch channel, but currently openbsc is
> not able to switch channel. (this should be possible in the future for
> handover.) also it checks if there is actually a traffic channel
> currently in use, when making a call.

I'll look at this in more detail.  I'm not sure if I want to merge your
hack.  I had some old patches for early / very early and OCASU assignment,
making it a configurable feature.

Based on my experience testing with various phones, we _might_ actually need
something like a blacklist based on the IMEI, where we make sure to use
a certain assignment method based on the particular phone model.

I think in reality nobody does the early or very early assignment, since
it needs more network resources even if the call cannot be established -
which is probably quite often the case.  I don't have any statistics, but
if it's 30-50% of all initiaded calls, it's definitely worth optimizing for it.

> fix 2: not actually a fix: adding imsi to gsm_mncc_number allows to
> notify application about calling/connected imsi. also it is possible to
> dial a subscriber with no extension assigned, just by using imsi. maybe
> it is wiser to put imsi string into gsm_mncc, because it is only used
> only once in a message.

yes, can you please provide a patch that adds it to gsm_mncc, rather than gsm_mncc_number?

> fix 3: while detaching, we don't hold a ressource (we don't call
> lchan_use), so we don't need to "lchan_put".
>
> fix 4: the given cause value and location parameters are used in
> mncc_release_ind function, rather than hardcoded. the plain cause
> numbers are replaced by the definitions from header file.

I've applied those two to my tree, will push it in the next minutes.

Cheers from Taipei Airport,
-- 
- 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 Andreas.Eversberg at versatel.de  Sun Jun 14 21:23:54 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Sun, 14 Jun 2009 23:23:54 +0200
Subject: AW: fixes for mncc-harald branch
Message-ID: <B16317F2B1592B4492FC414114171CE6817DC1@FLBVEXCH01.versatel.local>

 
> If anyone wants to look further into this, I'm happy to record some
PCAP files with some example RTP/RTCP dumps.  If you want, even combined
with the TCP connection to the BSC, so you have a correct timeline and
know what the BSC told the BTS when, and how the BTS reacted to that.

i would like to see some of this payload, but without any BSC traffic.
when i see in the future, i see that a bts directly forwards rtp data to
remote sip phone or media gateway or other bts. therefore it must be a
standard. i think it is gsm audio coded.




From laforge at gnumonks.org  Tue Jun 16 23:16:23 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 17 Jun 2009 01:16:23 +0200
Subject: nanoBTS RTP payload format
In-Reply-To: <B16317F2B1592B4492FC414114171CE6817DC1@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE6817DC1@FLBVEXCH01.versatel.local>
Message-ID: <20090616231623.GI4993@prithivi.gnumonks.org>

Hi Andreas,

On Sun, Jun 14, 2009 at 11:23:54PM +0200, Andreas.Eversberg wrote:

> > If anyone wants to look further into this, I'm happy to record some
> > PCAP files with some example RTP/RTCP dumps.  If you want, even combined
> > with the TCP connection to the BSC, so you have a correct timeline and
> > know what the BSC told the BTS when, and how the BTS reacted to that.
> 
> i would like to see some of this payload, but without any BSC traffic.
> when i see in the future, i see that a bts directly forwards rtp data to
> remote sip phone or media gateway or other bts. therefore it must be a
> standard. i think it is gsm audio coded.

After I have digged a bit further, it seems like the FR and EFR RTP payload
is conformant with section 4.5.8 and 4.5.9 of RFC3551.  Therefore, no mystery
is expected here.

I'm currently too busy (travelling in about 6 hours and still have way
too much work to consider any sleep tonight) to do some RTP captures, but
at least RFC3551 should give you some indication, in case you want to start
writing some code or anything in this area.

Cheers,
-- 
- 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 Jun 15 21:23:28 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 15 Jun 2009 23:23:28 +0200
Subject: fixes for mncc-harald branch
In-Reply-To: <B16317F2B1592B4492FC414114171CE688A4EF@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE688A4EF@FLBVEXCH01.versatel.local>
Message-ID: <20090615212328.GG30342@prithivi.gnumonks.org>

On Mon, Jun 15, 2009 at 08:38:55PM +0200, Andreas.Eversberg wrote:
>  
> > yes, can you please provide a patch that adds it to gsm_mncc, rather
> than gsm_mncc_number?
> 
> here it is...

thanks, applied.

-- 
- 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 Andreas.Eversberg at versatel.de  Mon Jun 15 18:41:00 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 15 Jun 2009 20:41:00 +0200
Subject: WG: fixes for mncc-harald branch
Message-ID: <B16317F2B1592B4492FC414114171CE688A4F0@FLBVEXCH01.versatel.local>

 

> yes, can you please provide a patch that adds it to gsm_mncc, rather
than gsm_mncc_number?

here it is...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_5.patch
Type: application/octet-stream
Size: 2294 bytes
Desc: fix_5.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090615/de973457/attachment.obj>

From Andreas.Eversberg at versatel.de  Mon Jun 15 18:46:29 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 15 Jun 2009 20:46:29 +0200
Subject: change my email
Message-ID: <B16317F2B1592B4492FC414114171CE688A4F5@FLBVEXCH01.versatel.local>

harald,
 
could you please change my email within the source code?
 
my email is "a  ndr ea s aet ever sber g dot eu". (remove spaces) this
works much better, even after versatel era :-].
 
regards,
 
andreas
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090615/eb52f7a2/attachment.htm>

From bouchtaoui at gmail.com  Tue Jun 16 13:10:12 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Tue, 16 Jun 2009 15:10:12 +0200
Subject: nanoBTS Listen mode
Message-ID: <4A3799B4.6050304@gmail.com>

Hello guys,

I was reading the nanoBTS product description and found support for 
"Network Listen" feature to monitor and decode GSM base stations. Is 
that an ip.access specific protocol? If so, does anyone has the ability 
to revers engineer this particular function. That would be really great!

I would like to scan other ARFCNs for neighbourcells and fill the 
information in SI 2, 3 or 4,  don't remeber which one.
Thank you.




From laforge at gnumonks.org  Tue Jun 16 23:11:54 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 17 Jun 2009 01:11:54 +0200
Subject: nanoBTS Listen mode
In-Reply-To: <4A3799B4.6050304@gmail.com>
References: <4A3799B4.6050304@gmail.com>
Message-ID: <20090616231154.GG4993@prithivi.gnumonks.org>

On Tue, Jun 16, 2009 at 03:10:12PM +0200, Nordin wrote:
> Hello guys,
>
> I was reading the nanoBTS product description and found support for  
> "Network Listen" feature to monitor and decode GSM base stations. Is  
> that an ip.access specific protocol? If so, does anyone has the ability  
> to revers engineer this particular function. That would be really great!

The network listen feature is implemented by means of GSM 12.21 "EXECUTE TEST"
methods.  So the activation/initiation of the network listen mode follows
the framework as set forth by 12.21, but the actual parameters as well
as the test results are vendor-specific attributes.

As far as I have noted, if you put the BTS in this mode it ceases to work
as normal BTS, so you cannot do that while you're actually using it
productively.

I've attached a pcap protocol trace of some old recorded network listen action.
Maybe this helps you to discover and document the 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nanobts_listen_bcchinfo_channelusage.pcap
Type: application/cap
Size: 49211 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090617/b0724e92/attachment.bin>

From bouchtaoui at gmail.com  Wed Jun 17 07:47:56 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Wed, 17 Jun 2009 09:47:56 +0200
Subject: nanoBTS Listen mode
In-Reply-To: <20090616231154.GG4993@prithivi.gnumonks.org>
References: <4A3799B4.6050304@gmail.com>
	<20090616231154.GG4993@prithivi.gnumonks.org>
Message-ID: <4A389FAC.7020708@gmail.com>

Thank you for the trace Harald.

Harald Welte schreef:
> On Tue, Jun 16, 2009 at 03:10:12PM +0200, Nordin wrote:
>   
>
> As far as I have noted, if you put the BTS in this mode it ceases to work
> as normal BTS, so you cannot do that while you're actually using it
> productively.
>
>   
It's not a problem to me, as long as I can scan the neighbourcells, I'm 
satisfied.
I'll work on this part...




From Andreas.Eversberg at versatel.de  Tue Jun 16 13:35:13 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 16 Jun 2009 15:35:13 +0200
Subject: measurement report
Message-ID: <B16317F2B1592B4492FC414114171CE68C390F@FLBVEXCH01.versatel.local>

hi,
 
i like to check out the measturement report feature of GSM. the A-bis
protocol shows measurement report indications, but i can't see any
request to turn it on. on the BCCH it is turned on, as far as i can see
in the bsc_hack.c. what do i miss? (neighbor cell frequencies?)
 
also i like to get continuous informations about timing advance. any
idea on how to retrieve these informations?
 
regards,
 
andreas
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090616/e53adb64/attachment.htm>

From spaar at mirider.augusta.de  Tue Jun 16 17:22:55 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Tue, 16 Jun 2009 17:22:55 CEST
Subject: measurement report
Message-ID: <4a37d4ef.mirider@mirider.augusta.de>

Hello Andreas,

On Tue, 16 Jun 2009 15:35:13 +0200, "Andreas.Eversberg" <Andreas.Eversberg at versatel.de> wrote:
>
> i like to check out the measturement report feature of GSM. the A-bis
> protocol shows measurement report indications, but i can't see any
> request to turn it on. on the BCCH it is turned on, as far as i can see
> in the bsc_hack.c. what do i miss? (neighbor cell frequencies?)

You need an active connection between the BTS and the MS to get the
measurement reports. The BTS will send its own results together with
the data received from the MS. If the cell has neighbor cells the
MS will also report their data (right now bsc_hack does not configure
any neighbor cells).

I am not sure if you will get the measurement reports for an active
connection by default or if they have to be turned on with a "Start
Measurement" command over OML.

> also i like to get continuous informations about timing advance. any
> idea on how to retrieve these informations?

TA is included in the measurement report from the BTS. Please be aware
that a value other than 0 means that you are more than about 550 meter
away with the MS from the BTS so you cover a rather large area with
your BTS ;-)

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From laforge at gnumonks.org  Tue Jun 16 23:12:51 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 17 Jun 2009 01:12:51 +0200
Subject: measurement report
In-Reply-To: <4a37d4ef.mirider@mirider.augusta.de>
References: <4a37d4ef.mirider@mirider.augusta.de>
Message-ID: <20090616231251.GH4993@prithivi.gnumonks.org>

On Tue, Jun 16, 2009 at 05:22:55PM +0200, Dieter Spaar wrote:

> > i like to check out the measturement report feature of GSM. the A-bis
> > protocol shows measurement report indications, but i can't see any
> > request to turn it on. on the BCCH it is turned on, as far as i can see
> > in the bsc_hack.c. what do i miss? (neighbor cell frequencies?)
> 
> You need an active connection between the BTS and the MS to get the
> measurement reports. The BTS will send its own results together with
> the data received from the MS. If the cell has neighbor cells the
> MS will also report their data (right now bsc_hack does not configure
> any neighbor cells).

ACK!

> I am not sure if you will get the measurement reports for an active
> connection by default or if they have to be turned on with a "Start
> Measurement" command over OML.

it's part of the BTS or TRX attributes that are set from the BSC.

-- 
- 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 spaar at mirider.augusta.de  Tue Jun 16 18:28:53 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Tue, 16 Jun 2009 18:28:53 CEST
Subject: measurement report
Message-ID: <4a37e466.mirider@mirider.augusta.de>

On Tue, 16 Jun 2009 17:22:55 CEST, "Dieter Spaar" <spaar at mirider.augusta.de> wrote:
> 
> I am not sure if you will get the measurement reports for an active
> connection by default or if they have to be turned on with a "Start
> Measurement" command over OML.

Please forget about the "Start Measurement" OML message, they have been
introduced with newer versions of GSM 12.21 and are most certainly not
available with the BS-11 (and probably intended for other things).

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From Andreas.Eversberg at versatel.de  Wed Jun 17 14:38:13 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Wed, 17 Jun 2009 16:38:13 +0200
Subject: AW: measurement report
Message-ID: <B16317F2B1592B4492FC414114171CE68C43CB@FLBVEXCH01.versatel.local>

 
>> I am not sure if you will get the measurement reports for an active
>> connection by default or if they have to be turned on with a "Start
>> Measurement" command over OML.
>
>it's part of the BTS or TRX attributes that are set from the BSC.


		NM_ATT_BS11_RADIO_MEAS_REP, 0x01, 0x01,

measurement report is enabled in msg_6[], but no report messages during
call or setup. this TRX-config seems to tell the mobile to send reports.
what do i need to tell the BTS to forward the reports to BSC? 




From laforge at gnumonks.org  Thu Jun 18 15:25:11 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 18 Jun 2009 17:25:11 +0200
Subject: measurement report
In-Reply-To: <B16317F2B1592B4492FC414114171CE68C43CB@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE68C43CB@FLBVEXCH01.versatel.local>
Message-ID: <20090618152511.GE7692@prithivi.gnumonks.org>

On Wed, Jun 17, 2009 at 04:38:13PM +0200, Andreas.Eversberg wrote:
>  
> >> I am not sure if you will get the measurement reports for an active
> >> connection by default or if they have to be turned on with a "Start
> >> Measurement" command over OML.
> >
> >it's part of the BTS or TRX attributes that are set from the BSC.
> 
> 
> 		NM_ATT_BS11_RADIO_MEAS_REP, 0x01, 0x01,
> 
> measurement report is enabled in msg_6[], but no report messages during
> call or setup. this TRX-config seems to tell the mobile to send reports.
> what do i need to tell the BTS to forward the reports to BSC? 

I see them all the time.  That's really weird.  I didn't test with BS-11
for a long time, but I distinctively remember having seen them at some time
in the past.

I'm not much in Berlin during the next 5-6 weeks, so it's unlikely that I'll be
working on the BS-11 for quite some time, sorry.

-- 
- 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090618/1b601ee2/attachment.bin>

From laforge at gnumonks.org  Thu Jun 18 15:23:47 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 18 Jun 2009 17:23:47 +0200
Subject: measurement report
In-Reply-To: <B16317F2B1592B4492FC414114171CE68C390F@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE68C390F@FLBVEXCH01.versatel.local>
Message-ID: <20090618152347.GD7692@prithivi.gnumonks.org>

On Tue, Jun 16, 2009 at 03:35:13PM +0200, Andreas.Eversberg wrote:
> hi,
>  
> i like to check out the measturement report feature of GSM. the A-bis
> protocol shows measurement report indications, but i can't see any
> request to turn it on. on the BCCH it is turned on, as far as i can see
> in the bsc_hack.c. what do i miss? (neighbor cell frequencies?)

actual measurement reports are sent all the time, as we turn them on by BTS/TRX
configuration attributes.  I can observe them very clearly as soon as any
dedicated channel between MS and BTS is established.

We do not get any information about neighbor cells from the MS, since the BCCH
of our BTS does not send information about known neighbor cells.  Only if we
put some ARFCN's in there, the MS will actually scan for the CCCH of those and
report the corresponding measurement values.

-- 
- 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 bouchtaoui at gmail.com  Tue Jun 16 15:13:13 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Tue, 16 Jun 2009 17:13:13 +0200
Subject: Understanding the GSM specs
Message-ID: <4A37B689.7010906@gmail.com>

Hello friends,

I want to modify the SYSTEM INFORMATION data, but I have some 
difficulties to understand the GSM spec.
It's about the GSM 04.08 part 10.5.2.34, I don't know how to interpet 
table 10.5.72 (and other similar tables).

According to paragraph 9.1.35 table 9.32 (GSM 04.08) SI3 rest octetets 
has a length of 4 bytes, but according to par. 10.5.2.34 we're dealing 
with a type 5 IE and thus with length of 5 bytes. That's odd to me, but 
hey, the world is full of surprises :)

Anyway, the problem is I don't know how to interpret table 10.5.72 (of 
GSM 04.08). I mean, for example, element CBQ (Cell Bar Qualify) is at 
bit 1. Bit 1 of what, which octet? What is L | H? Can someone explain it 
to me, so I can experiment with SI messages?

Thank you!




From bouchtaoui at gmail.com  Thu Jun 18 16:12:38 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Thu, 18 Jun 2009 18:12:38 +0200
Subject: Understanding the GSM specs
In-Reply-To: <4A37B689.7010906@gmail.com>
References: <4A37B689.7010906@gmail.com>
Message-ID: <4A3A6776.9020406@gmail.com>

Well guys,

If someone can help me with how to fill in the Rest Octets, I'll send 
you a postcard from my city to thank you :)
What I found out is that it uses CSN.1 notation, but the description is 
hard to follow, I began to see words floating around the screen.

<SI3RestOctet>::=<Optionalselectionparameters>
            <OptionalPoweroffset>
            <SystemInformation2terIndicator>
            <EarlyClassmarkSendingControl>
            <Schedulingifandwhere>
            {L|H<GPRSIndicator>}
            <sparepadding>:

    <OptionalSelectionParameters>::=   L |H <SelectionParameters>;

    <SelectionParameters>::=
            <CBQ:bit(1)>
            <CELL_RESELECT_OFFSET:bit(6)>
            <TEMPORARY_OFFSET:bit(3)>
            <PENALTY_TIME:bit(5)>;

    <OptionalPowerOffset>::=        L |H 
<PowerOffset:bit(2)>;<SystemInformation2terIndicator>::=
        L|H;

    <EarlyClassmarkSendingControl>::= L|H;

    <Schedulingifandwhere>::= L|H <WHERE:bit(3)>;

    <GPRSIndicator>::=        <RACOLOUR :bit(3)>
                                            < SI13POSITION :bit>;

So, now I want to enable GPRS support by do something with 
GPRSIndicator. This is how I thought to do that:
L|H -> 1
next -> RACOLOUR -> 000
next -> SI13POSITION -> 0
So we get -> 1 000 0

Next step is to do something with padding but than I'm lost. I don't 
have good documentations on how to use CSN.1 for GSM network.




From dburgess at jcis.net  Thu Jun 18 16:59:14 2009
From: dburgess at jcis.net (David A. Burgess)
Date: Thu, 18 Jun 2009 09:59:14 -0700
Subject: Understanding the GSM specs
In-Reply-To: <4A3A6776.9020406@gmail.com>
References: <4A37B689.7010906@gmail.com> <4A3A6776.9020406@gmail.com>
Message-ID: <C167BCCB-8FC3-4965-8834-903669E3B5D0@jcis.net>

Nordin -

You will probably find GSM 04.07 Appendix B of some use here.   
Specifically, for a description of the padding sequence and the  
meaning of "H" and "L" see GSM 04.07 B.1.2.2.

-- David



On Jun 18, 2009, at 9:12 AM, Nordin wrote:

> Well guys,
>
> If someone can help me with how to fill in the Rest Octets, I'll  
> send you a postcard from my city to thank you :)
> What I found out is that it uses CSN.1 notation, but the  
> description is hard to follow, I began to see words floating around  
> the screen.
>
> <SI3RestOctet>::=<Optionalselectionparameters>
>            <OptionalPoweroffset>
>            <SystemInformation2terIndicator>
>            <EarlyClassmarkSendingControl>
>            <Schedulingifandwhere>
>            {L|H<GPRSIndicator>}
>            <sparepadding>:
>
>    <OptionalSelectionParameters>::=   L |H <SelectionParameters>;
>
>    <SelectionParameters>::=
>            <CBQ:bit(1)>
>            <CELL_RESELECT_OFFSET:bit(6)>
>            <TEMPORARY_OFFSET:bit(3)>
>            <PENALTY_TIME:bit(5)>;
>
>    <OptionalPowerOffset>::=        L |H <PowerOffset:bit(2) 
> >;<SystemInformation2terIndicator>::=
>        L|H;
>
>    <EarlyClassmarkSendingControl>::= L|H;
>
>    <Schedulingifandwhere>::= L|H <WHERE:bit(3)>;
>
>    <GPRSIndicator>::=        <RACOLOUR :bit(3)>
>                                            < SI13POSITION :bit>;
>
> So, now I want to enable GPRS support by do something with  
> GPRSIndicator. This is how I thought to do that:
> L|H -> 1
> next -> RACOLOUR -> 000
> next -> SI13POSITION -> 0
> So we get -> 1 000 0
>
> Next step is to do something with padding but than I'm lost. I  
> don't have good documentations on how to use CSN.1 for GSM network.
>


David A. Burgess
Kestrel Signal Processing, Inc.







From bouchtaoui at gmail.com  Thu Jun 18 20:10:12 2009
From: bouchtaoui at gmail.com (Nordin Bouchtaoui)
Date: Thu, 18 Jun 2009 22:10:12 +0200
Subject: Understanding the GSM specs
In-Reply-To: <C167BCCB-8FC3-4965-8834-903669E3B5D0@jcis.net>
References: <4A37B689.7010906@gmail.com> <4A3A6776.9020406@gmail.com>
	<C167BCCB-8FC3-4965-8834-903669E3B5D0@jcis.net>
Message-ID: <8aedb85a0906181310o1063ba6fl647cacf5c67d69f0@mail.gmail.com>

>
> You will probably find GSM 04.07 Appendix B of some use here.
>  Specifically, for a description of the padding sequence and the meaning of
> "H" and "L" see GSM 04.07 B.1.2.2.
>

I already read that part, but it's so abstract, so just understand a little
bit of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090618/8e69438b/attachment.htm>

From laforge at gnumonks.org  Thu Jun 18 18:18:36 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 18 Jun 2009 20:18:36 +0200
Subject: Understanding the GSM specs
In-Reply-To: <4A3A6776.9020406@gmail.com>
References: <4A37B689.7010906@gmail.com> <4A3A6776.9020406@gmail.com>
Message-ID: <20090618181836.GT7692@prithivi.gnumonks.org>

On Thu, Jun 18, 2009 at 06:12:38PM +0200, Nordin wrote:
> Well guys,
>
> If someone can help me with how to fill in the Rest Octets, I'll send  
> you a postcard from my city to thank you :)

What I personally imagine might help is to look at the BSSMAP dissector in
wireshark.  It typically contains quite easily readable C-code for the
actual packet parsing.
-- 
- 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 bouchtaoui at gmail.com  Thu Jun 18 20:15:43 2009
From: bouchtaoui at gmail.com (Nordin Bouchtaoui)
Date: Thu, 18 Jun 2009 22:15:43 +0200
Subject: Understanding the GSM specs
In-Reply-To: <20090618181836.GT7692@prithivi.gnumonks.org>
References: <4A37B689.7010906@gmail.com> <4A3A6776.9020406@gmail.com>
	<20090618181836.GT7692@prithivi.gnumonks.org>
Message-ID: <8aedb85a0906181315r170fb961j9d9420fdc3a43f3c@mail.gmail.com>

>
> What I personally imagine might help is to look at the BSSMAP dissector in
> wireshark.  It typically contains quite easily readable C-code for the
> actual packet parsing.
>

Ok, I'll look at it this weekend. I haven't used wireshark a lot, but this
is the right time to learn to work with it. Also to analyze your trace you
post me about listening to neigbourcells with nanobts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090618/cdbfdf06/attachment.htm>

From spaar at mirider.augusta.de  Wed Jun 17 17:22:12 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Wed, 17 Jun 2009 17:22:12 CEST
Subject: AW: measurement report
Message-ID: <4a392644.mirider@mirider.augusta.de>

Hello Andreas,

On Wed, 17 Jun 2009 16:38:13 +0200, "Andreas.Eversberg" <Andreas.Eversberg at versatel.de> wrote:
> 
> 		NM_ATT_BS11_RADIO_MEAS_REP, 0x01, 0x01,
> 
> measurement report is enabled in msg_6[], but no report messages during
> call or setup. this TRX-config seems to tell the mobile to send reports.
> what do i need to tell the BTS to forward the reports to BSC?
> 

A quick idea without having verified it: You can try to
decrease NM_ATT_BS11_RADIO_MEAS_GRAN which is currently set
to 254 (0xFE). The unit seems to be "SACCH multiframes" which
is about 470 ms. If this attribute and its value means that a
report should only be sent about every 120 seconds, it would take
quite some time to see the report. However I am not 100% if this
attribute really has this meaning.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From spaar at mirider.augusta.de  Thu Jun 18 18:41:15 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Thu, 18 Jun 2009 18:41:15 CEST
Subject: AW: measurement report
Message-ID: <4a3a8a4b.mirider@mirider.augusta.de>

On Wed, 17 Jun 2009 17:22:12 CEST, "Dieter Spaar" <spaar at mirider.augusta.de> wrote:
> 
> A quick idea without having verified it: You can try to
> decrease NM_ATT_BS11_RADIO_MEAS_GRAN which is currently set
> to 254 (0xFE). The unit seems to be "SACCH multiframes" which
> is about 470 ms. If this attribute and its value means that a
> report should only be sent about every 120 seconds, it would take
> quite some time to see the report. However I am not 100% if this
> attribute really has this meaning.

I verified it, decreasing NM_ATT_BS11_RADIO_MEAS_GRAN to a
smaller value (I used 5 which means about 2.4 seconds)
will show the measurement results as expected. The default
setting of 254 is just too large so that you normally won't
notice them during testing.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From laforge at gnumonks.org  Thu Jun 18 18:21:54 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 18 Jun 2009 20:21:54 +0200
Subject: request for contributio (was Re: AW: measurement report)
In-Reply-To: <4a3a8a4b.mirider@mirider.augusta.de>
References: <4a3a8a4b.mirider@mirider.augusta.de>
Message-ID: <20090618182154.GU7692@prithivi.gnumonks.org>

On Thu, Jun 18, 2009 at 06:41:15PM +0200, Dieter Spaar wrote:

> > A quick idea without having verified it: You can try to
> > decrease NM_ATT_BS11_RADIO_MEAS_GRAN which is currently set
> > to 254 (0xFE). The unit seems to be "SACCH multiframes" which
> > is about 470 ms. If this attribute and its value means that a
> > report should only be sent about every 120 seconds, it would take
> > quite some time to see the report. However I am not 100% if this
> > attribute really has this meaning.
> 
> I verified it, decreasing NM_ATT_BS11_RADIO_MEAS_GRAN to a
> smaller value (I used 5 which means about 2.4 seconds)
> will show the measurement results as expected. The default
> setting of 254 is just too large so that you normally won't
> notice them during testing.

Which brings us to a TODO list item:

All the parameters that both BS-11 and nanoBTS currently initialize from their
own array of attributes should be shared.

I think many of those parameters should simply be part of 'struct gsm_bts' and
configurable from the vty interface.  So rather than puttign them in a static
array, actually have code that 
1) can set it from telnet and write it in the gsm_bts struct
2) can read it from gsm_bts struct send the SET ATTRIBUTE message to the BTS.

Maybe somebody on this list who wants to contribute can take care of this
kind of work.  It would mean Holger and myself can continue to work on the
more complex issues... Any help in this area would be appreciated a lot.

-- 
- 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 Jun 18 21:32:55 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 18 Jun 2009 23:32:55 +0200
Subject: Summary of GSM RF Power control
Message-ID: <20090618213255.GV7692@prithivi.gnumonks.org>

Hi!

In order to minimize any potential interference with other GSM networks, I
think we should try to improve our current power control.  I have so far
seen the various power control related attributes and parameters in the 12.21,
08.58 and 04.08 specs, but I might not yet have the full picture.

So I've done some reading up and am sharing my experience here now:

1) BS power control: controls the power of the downlink (BTS->MS)

12.21 has a 'power class' attribute, defined as binary representation of a
05.05 power class.  However, 05.05 power classes also come alphanumeric (M1 ..
M3, P1) and thus cannot be mapped 1:1.  Also, this attribute is marked as
read-only - thus not important for this discussion.  It can only be used
by the BSC to get some rough idea about the TRX power range.

12.21 also specifies a 'RF max power reduction' value in 9.4.47.  This element
can be sent as part of 'SET RADIO CARRIER ATTRIBUTE'.  The value in this IE is
the 'Pn' value of 08.58.  The Scale is 2dB steps, and the maximum value is 255,
so there can be a maximum value of 512dB.

08.58 defines Pn as the 'nominal power level', i.e. the level that is not yet
reduced by dynamic power control.

Please also note that the first TRX (the TRX carrying the TS0 i.e. the CCCH)
is only allowed to transmit at a fixed power level.

So if my calculations are correct, we can do the following calculation:

* BS-11 TRX power set to 30mW. 30mW equals roughly 15dBm
* Pn can be set to anywhere between 0 (30mW) and 512dB less, i.e.
  literally nothing.  A 'rf max power reduction' level of 7 (14dB)
  should reduce our _maximum_ BS power output to about 1dBm, i.e. 1.2mW

I'm creating the following table (with tabs, so use fixed-width fonts)

Power class	Pn_val=0 (0Db)
BS-11 30mW	15dBm	
BS-11 80mW	19dBm
BS-11 250mW	24dBm
BS-11 2W	33dBm

08.58 furthermore contains a 'BS power' attribute, chapter 9.3.4.  This is
used for initial channel activation, but also can be used in a later message to
alter the current power level of a particular channel (BS POWER CONTROL
message).  The attribute contains the number of 2dB steps that are to be
subtracted from the Pn nominal power, up to Pn-30dB.

There also is a "fast power control" (FPC) bit that can be set to enable
or unset to disable FPC.  As far as I understand, FPC is only available to
circuit-switched-data TCH's in ECSD (enhanced circuit switched data) mode.  The
idea that power control happens every 20ms, rather than every 480ms (SACCH)

There are also "BS Power Parameters" (9.3.32) which describe the parameters
and limits for the dynamic power control algorithm.  However, no algorithm
is standardized and thus the parameters are manufacturer/network dependent.


2) MS power control: controls the power of the uplink (MS->BTS)

08.58 9.3.13 specifies the initial power level as indicated in the CHANNEL
ACTIVATION message.  It can also be changed for an active channel by a MS POWER
CONTROL message.

Analoguous to the BS power, there also are 'MS Power Parameters' (9.3.31)

The algorithm for MS power control (also defining the example ms power
parameters) can be found in GSM 05.08 10.2.1.

What I can summarize is:

a) The Tx power of the MS is typically controlled by the MS_TXPWR_REQUEST field
   of the L1 header of the data sent by the BTS on the corresponding channel.
   The content of the field is a 'ms power level' in nominal 2dB steps, as
   defined in 05.08 and even more specifically in Section 4.1.1 of 05.05.

   Interestingly, the tables in 05.05 don't contain relative values in dB,
   but absolute values in dBm.  If the MS is asked to transmit at a power level
   it doesn't support, it has to use the closest level it supports.

   For GSM900, the range is 5dBm (3.2mW) to 39dBm (close to 10W)
   For GSM1800, the range is 0dBm (1mW) to 36dBm (4W)

b) When accessing the RACH and before the MS has received any such L1 headers,
   it shall use the value broadcasted in the MS_TXPWR_MAX_CCH field of the BCCH.

c) The BTS will employ some non-specified algorithm to configure the MS to
   use the minimum neccessary power to still be received by the BTS.  This
   is actually an optional feature in the spec, but I have clearly heard this
   in the speakers of my monitor with both the BS-11 and the nanoBTS:  The initial
   bursts are loud, and then the follow-up bursts are becoming less and less loud.

d) The L1 header IE that we get as part of every MEASUREMENT REPORT contains
   the absolute power level in dBm that the MS used to transfer this frame.
   We can thus use this information to verify that our assumptions about the
   power control have actually worked.


If we use the knowledge of the behavior as described above, we can also deduct:

* the BS-11 is configured to a NM_ATT_RF_MAXPOWR_R of 0, i.e. it will transmit
  with the power level that is configured by LMT / ipaccess_config.  By default
  this is set to 30mW 

* the nanoBTS 900 has 20dBm (1800 is 23dBm) TRX output power.  bsc_hack is 
  configured to a NM_ATT_RF_MAXPOWR_R of 12, i.e. 24dB.  This means we are
  transmitting with a mere -4dBm (398uW) or -1dBm (794uW) which would be _really_
  low.  So either the nanoBTS are not following specs, or we're really transmitting
  something that would barely be possible to receive.  Or my calculations are
  wrong ;)

I don't actually have any RF measurement equipment around, but it could be useful
if somebody who has can do some experimentation based on the information I have
provided in this message.

-- 
- 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 Jun 18 21:58:48 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 18 Jun 2009 23:58:48 +0200
Subject: Summary of GSM RF Power control
In-Reply-To: <20090618213255.GV7692@prithivi.gnumonks.org>
References: <20090618213255.GV7692@prithivi.gnumonks.org>
Message-ID: <20090618215848.GW7692@prithivi.gnumonks.org>

On Thu, Jun 18, 2009 at 11:32:55PM +0200, Harald Welte wrote:
> If we use the knowledge of the behavior as described above, we can also deduct:
> 
> * the BS-11 is configured to a NM_ATT_RF_MAXPOWR_R of 0, i.e. it will transmit
>   with the power level that is configured by LMT / ipaccess_config.  By default
>   this is set to 30mW 
> 
> * the nanoBTS 900 has 20dBm (1800 is 23dBm) TRX output power.  bsc_hack is 
>   configured to a NM_ATT_RF_MAXPOWR_R of 12, i.e. 24dB.  This means we are
>   transmitting with a mere -4dBm (398uW) or -1dBm (794uW) which would be _really_
>   low.  So either the nanoBTS are not following specs, or we're really
>   transmitting something that would barely be possible to receive.  Or my
>   calculations are wrong ;)

I've now also realised that every CHANNEL ACTIVATE message contains a BS power
and MS power IE with 0x0f as value, i.e. another 30dB decrease in initial power
levels.  This really makes me suspicious...  at levels that low, everything
should never be working.  Probably the MS and BTS cannot operate below a
certain level, and thus they choose whatever is the minimum level they support.

But that would again disagree with my 'speaker sound level decreases after
initial burst and settles on a low level'  observation.

So I think there is a lot of experimentation to do for somebody with a somewhat
accurate spectrum analyzer or similar equipment.

-- 
- 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090618/153520a8/attachment.bin>

From laforge at gnumonks.org  Thu Jun 18 22:05:47 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 19 Jun 2009 00:05:47 +0200
Subject: Summary of GSM RF Power control
In-Reply-To: <20090618215848.GW7692@prithivi.gnumonks.org>
References: <20090618213255.GV7692@prithivi.gnumonks.org>
	<20090618215848.GW7692@prithivi.gnumonks.org>
Message-ID: <20090618220547.GX7692@prithivi.gnumonks.org>

On Thu, Jun 18, 2009 at 11:58:48PM +0200, Harald Welte wrote:
> On Thu, Jun 18, 2009 at 11:32:55PM +0200, Harald Welte wrote:
> > If we use the knowledge of the behavior as described above, we can also deduct:
> > 
> > * the BS-11 is configured to a NM_ATT_RF_MAXPOWR_R of 0, i.e. it will transmit
> >   with the power level that is configured by LMT / ipaccess_config.  By default
> >   this is set to 30mW 
> > 
> > * the nanoBTS 900 has 20dBm (1800 is 23dBm) TRX output power.  bsc_hack is 
> >   configured to a NM_ATT_RF_MAXPOWR_R of 12, i.e. 24dB.  This means we are
> >   transmitting with a mere -4dBm (398uW) or -1dBm (794uW) which would be _really_
> >   low.  So either the nanoBTS are not following specs, or we're really
> >   transmitting something that would barely be possible to receive.  Or my
> >   calculations are wrong ;)
> 
> I've now also realised that every CHANNEL ACTIVATE message contains a BS power
> and MS power IE with 0x0f as value, i.e. another 30dB decrease in initial power
> levels.  This really makes me suspicious...  at levels that low, everything
> should never be working.  Probably the MS and BTS cannot operate below a
> certain level, and thus they choose whatever is the minimum level they support.

For the BTS I'm still puzzled.  For the MS, a power level of 0xf (15) means:
13dBm (19mW) output power in GSM900 and 0dBm (1mW) in GSM1800 - which would
probably work well unless there's actual uplink interference on the respective
channel.

-- 
- 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  Fri Jun 19 07:13:36 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 19 Jun 2009 09:13:36 +0200
Subject: Summary of GSM RF Power control
In-Reply-To: <20090618220547.GX7692@prithivi.gnumonks.org>
References: <20090618213255.GV7692@prithivi.gnumonks.org>
	<20090618215848.GW7692@prithivi.gnumonks.org>
	<20090618220547.GX7692@prithivi.gnumonks.org>
Message-ID: <20090619071335.GC7692@prithivi.gnumonks.org>

On Fri, Jun 19, 2009 at 12:05:47AM +0200, Harald Welte wrote:
> On Thu, Jun 18, 2009 at 11:58:48PM +0200, Harald Welte wrote:
> > On Thu, Jun 18, 2009 at 11:32:55PM +0200, Harald Welte wrote:
> > > If we use the knowledge of the behavior as described above, we can also deduct:
> > > 
> > > * the BS-11 is configured to a NM_ATT_RF_MAXPOWR_R of 0, i.e. it will transmit
> > >   with the power level that is configured by LMT / ipaccess_config.  By default
> > >   this is set to 30mW 
> > > 
> > > * the nanoBTS 900 has 20dBm (1800 is 23dBm) TRX output power.  bsc_hack is 
> > >   configured to a NM_ATT_RF_MAXPOWR_R of 12, i.e. 24dB.  This means we are
> > >   transmitting with a mere -4dBm (398uW) or -1dBm (794uW) which would be _really_
> > >   low.  So either the nanoBTS are not following specs, or we're really
> > >   transmitting something that would barely be possible to receive.  Or my
> > >   calculations are wrong ;)
> > 
> > I've now also realised that every CHANNEL ACTIVATE message contains a BS power
> > and MS power IE with 0x0f as value, i.e. another 30dB decrease in initial power
> > levels.  This really makes me suspicious...  at levels that low, everything
> > should never be working.  Probably the MS and BTS cannot operate below a
> > certain level, and thus they choose whatever is the minimum level they support.
> 
> For the BTS I'm still puzzled.  For the MS, a power level of 0xf (15) means:
> 13dBm (19mW) output power in GSM900 and 0dBm (1mW) in GSM1800 - which would
> probably work well unless there's actual uplink interference on the respective
> channel.

However, what contradicts this is:

The BCCH never gets 'activated', i.e. we just set the 12.21 CHANNEL ATTRIBUTEs
and don't call a 08.58 'ACTIVATE CHANNEL'.    12.21 CHANNEL ATTRIBUTEs don't
allow us to set any power level.  Thus the TS0 should currently be instructed
to transmit at the maximum TRX power.

Since the TRX that carries TS0 cannot employ any power control but has to
operate at constant power, the BTS will have to use the highest power of any
TS on that TRX.
 
What we could try is to send a 'BS POWER CONTROL' 08.58 message containing a
'BS POWER' IE for TS0 and see if that further reduces the TRX power.  I think
especially on the nanoBTS this is desirable, since it's nominal output can not
be reduced to 30mW like we can do for the BS-11 with lmt or bs11_config.

Cheers,
-- 
- 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 Jun 18 22:22:22 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 19 Jun 2009 00:22:22 +0200
Subject: Summary of GSM RF Power control
In-Reply-To: <20090618213255.GV7692@prithivi.gnumonks.org>
References: <20090618213255.GV7692@prithivi.gnumonks.org>
Message-ID: <20090618222221.GY7692@prithivi.gnumonks.org>


On Thu, Jun 18, 2009 at 11:32:55PM +0200, Harald Welte wrote:

> 12.21 also specifies a 'RF max power reduction' value in 9.4.47.  This element
> can be sent as part of 'SET RADIO CARRIER ATTRIBUTE'.  The value in this IE is
> the 'Pn' value of 08.58.  The Scale is 2dB steps, and the maximum value is 255,
> so there can be a maximum value of 512dB.
> 
> 08.58 defines Pn as the 'nominal power level', i.e. the level that is not yet
> reduced by dynamic power control.

As I've now figured, the 'RF max power reduction' element seems to be marked as
read-only, i.e. the BSC is not allowed to change it.  This means that I was
probably reading the specs the wrong way earlier.

It's also weird that all the A-bis traces that I've seen actually try to set
that attribute (without any error message).

So if it was read-only, it might well be that this is only indicating the
'maximum possible power reduction', i.e. the limit you can specify for the 'BS
power level' IE in the CHANNEL ACTIVATION or other messages.

If we once again combine this with our knowledge, i.e.

> BS-11 30mW	15dBm	
> BS-11 80mW	19dBm
> BS-11 250mW	24dBm
> BS-11 2W	33dBm
> nanoBTS 900	20dBm
> nanoBTS 1800	23dBm

And we set the BS power level in channel activation as 0xf (i.e. -30dB),then
we get something like -15dBm for BS-11/30mW and -10/-7dBm for the nanoBTS.
That would still be _very_ low.

05.05 Chapter 4.1.2 tells us that a BTS has to support at least six levels of
2dB each power reduction, i.e. -12dB is the minimum it has to support.

-- 
- 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 spaar at mirider.augusta.de  Fri Jun 19 10:55:16 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Fri, 19 Jun 2009 10:55:16 CEST
Subject: Summary of GSM RF Power control
Message-ID: <4a3b6e94.mirider@mirider.augusta.de>

Hello Harald,

On Fri, 19 Jun 2009 00:22:22 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> 
> If we once again combine this with our knowledge, i.e.
> 
> > BS-11 30mW	15dBm=09
> > BS-11 80mW	19dBm
> > BS-11 250mW	24dBm
> > BS-11 2W	33dBm
> > nanoBTS 900	20dBm
> > nanoBTS 1800	23dBm
> 
> And we set the BS power level in channel activation as 0xf (i.e. -30dB),then
> we get something like -15dBm for BS-11/30mW and -10/-7dBm for the nanoBTS.
> That would still be _very_ low.

A few numbers from a measurement:

  nanoBTS 1800, ARCN 840, no voice/data traffic:

  NM_ATT_RF_MAXPOWR_R    RF output

    0                    20   dBm
    1                    18   dBm
    2                    16   dBm
    4                    12   dBm
    8                     4.4 dBm
    9                     2.0 dBm
   10                     0.4 dBm
   11                    -1.6 dBm
   12                    -3.6 dBm

The power measurement of my equippment is not calibrated and the
cable I used is not one of the best, so it could cause 3 dB
loss. However one can see the tendency. Values larger than 12
for NM_ATT_RF_MAXPOWR_R are not supported, they result in an
error.

I will see if I find some time for measurements with the BS-11.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From spaar at mirider.augusta.de  Fri Jun 19 19:21:05 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Fri, 19 Jun 2009 19:21:05 CEST
Subject: Summary of GSM RF Power control
Message-ID: <4a3be521.mirider@mirider.augusta.de>

On Fri, 19 Jun 2009 10:55:16 CEST, "Dieter Spaar" <spaar at mirider.augusta.de> wrote:
> 
> I will see if I find some time for measurements with the BS-11.

And here are the measurment results for the BS-11 for each of the
four power classes:

BS-11, ARFCN 123

  BTS Power: 0.03 Watt
  NM_ATT_RF_MAXPOWR_R    RF output

    0                    12   dBm
    1                     9.7 dBm
    2                     7.8 dBm
    4                     4.7 dBm
    6                     0.9 dBm

  BTS Power: 0.08 Watt
  NM_ATT_RF_MAXPOWR_R    RF output

    0                    17   dBm
    1                    15   dBm
    2                    13   dBm
    4                     8.7 dBm
    6                     5.5 dBm

  BTS Power: 0.25 Watt
  NM_ATT_RF_MAXPOWR_R    RF output

    0                    22   dBm
    1                    20   dBm
    2                    18   dBm
    4                    14   dBm
    6                     9.9 dBm

  BTS Power: 2 Watt
  NM_ATT_RF_MAXPOWR_R    RF output

    0                    32   dBm
    1                    30   dBm
    2                    27   dBm
    4                    23   dBm
    6                    19   dBm

Values larger than 6 for NM_ATT_RF_MAXPOWR_R are not supported.
There is most certainly an error in the range of 2 to 3 dB coming
from the low-quality cable and some adaptor connectors to connect
the BTS to the measurement equipment.

I did also play with the power control of the BS-11. As far as I
am aware the BTS power control is not enbabled per default in
bsc_hack, the measurement results from the BTS confirm that. If
I enable the BTS power control I can at least see that the BTS
changes the MS power. I have not verified on the phone if the
power is really changed, but the RX level of the BTS seem to
indicate that it works.

There are a lot of parameters to play with so if anyone is
interested, just reduce NM_ATT_BS11_RADIO_MEAS_GRAN (lets
say to 2) so that you see frequent measurement results and
watch what is going on.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From laforge at gnumonks.org  Sat Jun 20 08:02:17 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 20 Jun 2009 10:02:17 +0200
Subject: BS-11 power measurement results
In-Reply-To: <4a3be521.mirider@mirider.augusta.de>
References: <4a3be521.mirider@mirider.augusta.de>
Message-ID: <20090620080217.GI4664@prithivi.gnumonks.org>

On Fri, Jun 19, 2009 at 07:21:05PM +0200, Dieter Spaar wrote:
>
> And here are the measurment results for the BS-11 for each of the
> four power classes:

thanks so much.

I have extended the table by the theoretical value (i.e. nominal power
converted to dBm minus (NM_ATT_RF_MAXPOWR_R * 2dB steps-size)):

> BS-11, ARFCN 123
> 
>   BTS Power: 0.03 Watt
>   NM_ATT_RF_MAXPOWR_R    RF output	Theoretical
> 
>     0                    12   dBm	15 dBm
>     1                     9.7 dBm	13 dBm
>     2                     7.8 dBm	12 dBm
>     4                     4.7 dBm	 7 dBm
>     6                     0.9 dBm	 3 dBm
> 
>   BTS Power: 0.08 Watt
>   NM_ATT_RF_MAXPOWR_R    RF output
> 
>     0                    17   dBm	19 dBm
>     1                    15   dBm	17 dBm
>     2                    13   dBm	15 dBm
>     4                     8.7 dBm	11 dBm
>     6                     5.5 dBm	 7 dBm
> 
>   BTS Power: 0.25 Watt
>   NM_ATT_RF_MAXPOWR_R    RF output
> 
>     0                    22   dBm	24 dBm
>     1                    20   dBm	22 dBm
>     2                    18   dBm	20 dBm
>     4                    14   dBm	16 dBm
>     6                     9.9 dBm	12 dBm
> 
>   BTS Power: 2 Watt
>   NM_ATT_RF_MAXPOWR_R    RF output
> 
>     0                    32   dBm	33 dBm
>     1                    30   dBm	31 dBm
>     2                    27   dBm	29 dBm
>     4                    23   dBm	25 dBm
>     6                    19   dBm	21 dBm
> 
> Values larger than 6 for NM_ATT_RF_MAXPOWR_R are not supported.

Do you get an error message (SET ATTRIBUTE NACK) if you try to set it?

According to the spec, 6 steps of 2dB is the minimum a BTS has to support.

The indication in 12.21 that NM_ATT_RF_MAXPOWR_R is read-only is thus
likely only an error in the documentation.

> There is most certainly an error in the range of 2 to 3 dB coming
> from the low-quality cable and some adaptor connectors to connect
> the BTS to the measurement equipment.

sure.  Also, the BTS is 12 years old...

> I did also play with the power control of the BS-11. As far as I
> am aware the BTS power control is not enbabled per default in
> bsc_hack, the measurement results from the BTS confirm that. If
> I enable the BTS power control I can at least see that the BTS
> changes the MS power. I have not verified on the phone if the
> power is really changed, but the RX level of the BTS seem to
> indicate that it works.

BTS power control should be 'BS power control', i.e. the dynamic
adjustment of downlink power.  The respective details are quite
vendor specific, as it is an optional feature (and one that is not
to be used on C0 anyway).

MS power control (the dynamic adjustment of MS power) should be used even now,
otherwise I would not understand my observation of the phone bursts becoming
much lesss loud in the speakers after the initial few very loud bursts.

> There are a lot of parameters to play with so if anyone is
> interested, just reduce NM_ATT_BS11_RADIO_MEAS_GRAN (lets
> say to 2) so that you see frequent measurement results and
> watch what is going on.

Yes, thanks.

What would be more interesting to me than dynamic BS power control is:
How do the 'BS POWER' IE's in the ACTIVATE CHANNEL and 'BS POWER CONTROL'
messages affect the BS transmit power.

Some things to confirm:

1) whatever we use as BS POWER value in ACTIVATE CHANNEL on a TCH/SDCCH8
   on the C0 does not make any changes to the acutal TX power

2) if we activate a channel on the second TRX, do we see the BTS power
   adjusted according to BS POWER in ACTIVATE CHANNEL ?

3) if we use a BS POWER CONTROL message on the CCCH on C0 of an otherwise idle
   BTS, do we see a power change on the TRX ?

I've just written some code for OpenBSC to implement those commands, I'll
commit it later.
-- 
- 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 spaar at mirider.augusta.de  Sat Jun 20 11:23:31 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Sat, 20 Jun 2009 11:23:31 CEST
Subject: BS-11 power measurement results
Message-ID: <4a3cc6b3.mirider@mirider.augusta.de>

Hello Harald,

On Sat, 20 Jun 2009 10:02:17 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> 
> Do you get an error message (SET ATTRIBUTE NACK) if you try to set it?

I have not looked at the response, but LMT says "unrecognized value"
or something like that if I query the TRX attributes. The BS-11 seems
to use "6" if something larger than 6 is sent. The nanoBTS 1800 however
does not start if an invalid value for NM_ATT_RF_MAXPOWR_R is sent,
the green LED is just blinking.

> According to the spec, 6 steps of 2dB is the minimum a BTS has to support.

Yes, and looking at the test report of the BS-11 seems to indicate that
there are 15 steps possible for dynamic adjustment (probably used only
if BTS power control is enabled).

> sure.  Also, the BTS is 12 years old...

I think the power of the BS-11 is still rather accurate, someone
else (you know him) with much better measurment equippment has
confired a while ago that the maximum power of the BS-11 is very
accurate. Anyway, 3 dB more or less is not really a problem for
our purpose.

> MS power control (the dynamic adjustment of MS power) should be used even now,
> otherwise I would not understand my observation of the phone bursts becoming
> much lesss loud in the speakers after the initial few very loud bursts.

I can only report the results of a short test. According to LMT, the
MS power control is currently disabled when bsc_hack is used (at least
the version I use). If I enable it and additionally enable the whole
power control of the BS-11, I can see that the MS power is changed.
I guess the same is true for the BS power.

> What would be more interesting to me than dynamic BS power control is:
> How do the 'BS POWER' IE's in the ACTIVATE CHANNEL and 'BS POWER CONTROL'
> messages affect the BS transmit power.
> 
> Some things to confirm:
> 
> 1) whatever we use as BS POWER value in ACTIVATE CHANNEL on a TCH/SDCCH8
>    on the C0 does not make any changes to the acutal TX power

Difficult to measure for me with the current setup (ARFCN of the
traffic channel is the same as the BCCH channel). To find out if the
BS power of the traffic channel is modified, I have to switch to a
different ARFCN for traffic.

> 2) if we activate a channel on the second TRX, do we see the BTS power
>    adjusted according to BS POWER in ACTIVATE CHANNEL ?

Does bsc_hack already support the second TRX ?

> 3) if we use a BS POWER CONTROL message on the CCCH on C0 of an otherwise idle
>    BTS, do we see a power change on the TRX ?

I can only measure it if I switch the ARFCN to a different channel than
used by the BCCH. I don't think the BTS will modify the BCCH power.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From laforge at gnumonks.org  Sat Jun 20 23:05:27 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 21 Jun 2009 01:05:27 +0200
Subject: BS-11 power measurement results
In-Reply-To: <4a3cc6b3.mirider@mirider.augusta.de>
References: <4a3cc6b3.mirider@mirider.augusta.de>
Message-ID: <20090620230527.GR4664@prithivi.gnumonks.org>

Hi Dieter,

On Sat, Jun 20, 2009 at 11:23:31AM +0200, Dieter Spaar wrote:

> On Sat, 20 Jun 2009 10:02:17 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> > 
> > Do you get an error message (SET ATTRIBUTE NACK) if you try to set it?
> 
> I have not looked at the response, but LMT says "unrecognized value"
> or something like that if I query the TRX attributes. The BS-11 seems
> to use "6" if something larger than 6 is sent. 

which I think is logical and might actually be demanded by the spec.

> The nanoBTS 1800 however does not start if an invalid value for
> NM_ATT_RF_MAXPOWR_R is sent, the green LED is just blinking.

ok.  I suppose it sends an ATTRIBUTE NACK and thus doens't perform the
state transitions required to activate the TRX.

> Yes, and looking at the test report of the BS-11 seems to indicate that
> there are 15 steps possible for dynamic adjustment (probably used only
> if BTS power control is enabled).

ok.

> > MS power control (the dynamic adjustment of MS power) should be used even
> > now, otherwise I would not understand my observation of the phone bursts
> > becoming much lesss loud in the speakers after the initial few very loud
> > bursts.
> 
> I can only report the results of a short test. According to LMT, the
> MS power control is currently disabled when bsc_hack is used (at least
> the version I use). If I enable it and additionally enable the whole
> power control of the BS-11, I can see that the MS power is changed.
> I guess the same is true for the BS power.

mh. I see.  Seems like there is some more research required here.  With
the recent "L1 Info" IE decoding that I committed, we should always see
the actual RF power in dBm used by the MS during reception of measurement
results.

> > 1) whatever we use as BS POWER value in ACTIVATE CHANNEL on a TCH/SDCCH8
> >    on the C0 does not make any changes to the acutal TX power
> 
> Difficult to measure for me with the current setup (ARFCN of the
> traffic channel is the same as the BCCH channel). To find out if the
> BS power of the traffic channel is modified, I have to switch to a
> different ARFCN for traffic.

No, this is actually the inverse test:  MAke sure the power does _not_ change
if TCH and BCCH are on the same TRX and we send different BS POWER values
for the TCH CHANNEL ACTIVATE.  Right now we send a value of 15 (!).

> > 2) if we activate a channel on the second TRX, do we see the BTS power
> >    adjusted according to BS POWER in ACTIVATE CHANNEL ?
> 
> Does bsc_hack already support the second TRX ?

I've once manually hacked it into it and was using it for a test.  But there's
no real integrated/automatic support yet, no. Sorry.  I think the latter will
be much easier once we have changed to a full vty-based configuration, since
we suddenly need to deal with different ARFCN's and command line arguments
are just not really a good idea to put all this information into.

> > 3) if we use a BS POWER CONTROL message on the CCCH on C0 of an otherwise idle
> >    BTS, do we see a power change on the TRX ?
> 
> I can only measure it if I switch the ARFCN to a different channel than
> used by the BCCH. I don't think the BTS will modify the BCCH power.

CCCH is the channel that contains the BCCH.  So I'm actually asking for
what you "don't think", i.e. an attempt to alter the BS POWRE on the TRX
that carries the BCCH.

As far as I read the specs, there should be no technical reason why it should
not respond to this request.  Whether or not it implements it this way, we don't
know.

-- 
- 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 spaar at mirider.augusta.de  Sun Jun 21 19:55:20 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Sun, 21 Jun 2009 19:55:20 CEST
Subject: BS-11 power measurement results
Message-ID: <4a3e9028.mirider@mirider.augusta.de>

Hello Harald,

On Sun, 21 Jun 2009 01:05:27 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> 
> mh. I see.  Seems like there is some more research required here.  With
> the recent "L1 Info" IE decoding that I committed, we should always see
> the actual RF power in dBm used by the MS during reception of measurement
> results.

The MS power can easily be observed with the Network Monitor of the
Nokia phones, the updated frequency of the display is fast enough.
I can for example see that the MS POWER of the ACTIVATE CHANNEL
command is set (as expected of course).

> No, this is actually the inverse test:  MAke sure the power does _not_ change
> if TCH and BCCH are on the same TRX and we send different BS POWER values
> for the TCH CHANNEL ACTIVATE.  Right now we send a value of 15 (!).

The BS power of the BCCH does not change. From my understanding, this
is the expected behaviour because the BCCH frequency is the reference
of the cell for all such things as cell re-selection or handover. I
think (without being 100% sure) that this even affects all other
timeslots of the BCCH TRX because if a phone measures the signal
strength of a neighbor cell, it does not neccessarily measure on TS0
(not sure how it is acually done, RSSI average over a certain amount
of time ?)

I cannot confirm with a measurement that the TCH power is not changed
because I cannot measure it if TCH and BCCH use the same frequency.

BTW, what does the MS measure and report in the measurment report if
there is an acctive connection, is it the strength of the TCH or the
BCCH ?

> CCCH is the channel that contains the BCCH.  So I'm actually asking for
> what you "don't think", i.e. an attempt to alter the BS POWRE on the TRX
> that carries the BCCH.

As I said, I don't see a change. But as long as it is not 100% sure what
I or the phone measures (BCCH or TCH) there is still a chance that the
TCH is adjusted, although I don't expect it (not that it isn't possible,
I have read that on a TRX which does not carry the BCCH, a different
power level on every timeslot is allowed).

One other observation: I tried to use a different ARFCN for the TCH
on the BS-11 using only one TRX. This does not seem to work, although
I can see with LMT the ARFCN set for all the TCH timeslots and can
also see that the phone switches to the other ARFCN, there is no RF
activity of the BS on this ARFCN. All the commands to activate the
channel are acknowledged and use the other ARFCN, no errors. The
only strange thing is the ARFCN list of the TRX, I have added the
other ARFCN but LMT displays "0" for all additional ARFCNs in the
list, only the first has a different value.

Maybe I am doing something wrong or this is just the expected
behaviour, a TRX which carries the BCCH cannot use a different
ARFCN for the TCH (but this would also mean that no hopping is
allowed).

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From e.cathelinaud at googlemail.com  Mon Jun 22 13:22:50 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Mon, 22 Jun 2009 15:22:50 +0200
Subject: Setting BS11 output power
Message-ID: <383f8f9a0906220622m3bc84da3u53762124cd2006ee@mail.gmail.com>

Hi,

I was following your mails about your results for the ouput power but I
don't understand how you change it. I was checking the code  but I didn't
find how to change TX0 output power.

I tried to change the line :
abis_nm_bs11_set_trx_power(&bts->trx[0], BS11_TRX_POWER_GSM_30mW);
with
abis_nm_bs11_set_trx_power(&bts->trx[0], BS11_TRX_POWER_GSM_250mW);
in the "create_objects" fonction but I don't know how the fonction is
loaded, I don't know how the bs11 enter the state
"BS11_STATE_WAIT_MIN_CFG_2"

case BS11_STATE_WAIT_MIN_CFG_2:
        bs11cfg_state = STATE_SWLOAD;
        rc = create_objects(g_bts);
        break;


If anyone can help me

Thanks a lot

Eric Cathelinaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090622/3300303d/attachment.htm>

From laforge at gnumonks.org  Tue Jun 23 16:36:49 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 23 Jun 2009 18:36:49 +0200
Subject: Setting BS11 output power
In-Reply-To: <383f8f9a0906220622m3bc84da3u53762124cd2006ee@mail.gmail.com>
References: <383f8f9a0906220622m3bc84da3u53762124cd2006ee@mail.gmail.com>
Message-ID: <20090623163649.GG26945@prithivi.gnumonks.org>

On Mon, Jun 22, 2009 at 03:22:50PM +0200, Eric Cathelinaud wrote:
> Hi,
> 
> I was following your mails about your results for the ouput power but I
> don't understand how you change it. I was checking the code  but I didn't
> find how to change TX0 output power.
> 
> I tried to change the line :
> abis_nm_bs11_set_trx_power(&bts->trx[0], BS11_TRX_POWER_GSM_30mW);
> with
> abis_nm_bs11_set_trx_power(&bts->trx[0], BS11_TRX_POWER_GSM_250mW);
> in the "create_objects" fonction but I don't know how the fonction is
> loaded, I don't know how the bs11 enter the state
> "BS11_STATE_WAIT_MIN_CFG_2"

you have to manually change the state into MAINTENANCE (by calling disconnect)
and then call abis_nm_bs11_set_trx_power()

-- 
- 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 e.cathelinaud at googlemail.com  Wed Jun 24 10:15:39 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Wed, 24 Jun 2009 12:15:39 +0200
Subject: Setting BS11 output power
In-Reply-To: <20090623163649.GG26945@prithivi.gnumonks.org>
References: <383f8f9a0906220622m3bc84da3u53762124cd2006ee@mail.gmail.com>
	<20090623163649.GG26945@prithivi.gnumonks.org>
Message-ID: <383f8f9a0906240315ub967013u7ef942792e3f5db1@mail.gmail.com>

Working fine thanks

Eric Cathelinaud

2009/6/23 Harald Welte <laforge at gnumonks.org>

> On Mon, Jun 22, 2009 at 03:22:50PM +0200, Eric Cathelinaud wrote:
> > Hi,
> >
> > I was following your mails about your results for the ouput power but I
> > don't understand how you change it. I was checking the code  but I didn't
> > find how to change TX0 output power.
> >
> > I tried to change the line :
> > abis_nm_bs11_set_trx_power(&bts->trx[0], BS11_TRX_POWER_GSM_30mW);
> > with
> > abis_nm_bs11_set_trx_power(&bts->trx[0], BS11_TRX_POWER_GSM_250mW);
> > in the "create_objects" fonction but I don't know how the fonction is
> > loaded, I don't know how the bs11 enter the state
> > "BS11_STATE_WAIT_MIN_CFG_2"
>
> you have to manually change the state into MAINTENANCE (by calling
> disconnect)
> and then call abis_nm_bs11_set_trx_power()
>
> --
> - 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090624/8d2ef79f/attachment.htm>

From Andreas.Eversberg at versatel.de  Mon Jun 22 17:40:17 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 22 Jun 2009 19:40:17 +0200
Subject: location update problem
Message-ID: <B16317F2B1592B4492FC414114171CE696FE35@FLBVEXCH01.versatel.local>

hi,
 
i got a leak of channel ressource. (currently i cannot look at the
source code.)
 
ignore the first 3 lines, they are just part of testing/debugging code i
use.
 
after location update fails. "DB: Failed to find the Subscriber...", get
an "ERROR INDICATION" with cause 1. it seems that the mobile just stops
sending on the channel. the channel ressource hold by location update
process is not freed. the last messages show that.
 
i will look on this the next days and report if i found something. if
you have any idea, please tell me. the way to test any change/fix is
quite complicated. the bug only occurrs when many phones are available
and when they move from a different network to my network (built in a
car, moving arround.)
 
andreas
 
 
<8000> chan_alloc.c:164 looking for free signalling subchannel on CCCH
<8000> chan_alloc.c:168 requesting SDCCH* channel
<8000> chan_alloc.c:135 free lchan (1) found on trx 0 ts 1
<0010> abis_rsl.c:894 Activating ARFCN(123) TS(1) SS(1) lctype SDCCH
chan_nr=0x49 r=LOCATION_UPDATE ra=0x15
<0010> abis_rsl.c:744 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 CHANNEL
ACTIVATE ACK
<0001> abis_rsl.c:988 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 ESTABLISH
INDICATION
<0004> gsm_04_08.c:1528 LOCATION UPDATING REQUEST
<0004> gsm_04_08.c:1200 LUPDREQ: mi_type=0x04 MI(1293316309) type=NORMAL
<0002> gsm_04_08.c:347 lchan (bts=0,trx=0,ts=1,ch=1) increases usage to:
1
<0004> gsm_04_08.c:1226
<0002> gsm_04_08.c:990 (bts 0 trx 0 ts 1 pd 05) Sending 0x18 to MS.
DB: Failed to find the Subscriber. '1' '1293316309'
<0002> gsm_04_08.c:990 (bts 0 trx 0 ts 1 pd 05) Sending 0x18 to MS.
<0008> gsm_04_08.c:1250 <- Can't find any subscriber for this ID
<0001> abis_rsl.c:988 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 DATA
INDICATION
<0008> gsm_04_08.c:1634 CLASSMARK CHANGE CM2(len=3) CM3(len=4)
<0001> abis_rsl.c:988 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 ERROR
INDICATION cause=0x01
<0001> chan_alloc.c:256 Recycling the channel with: 0 (0)
<0010> abis_rsl.c:530 Channel Release CMD channel=(bts=0,trx=0,ts=1)
chan_nr=0x41
<0010> abis_rsl.c:744 channel=(bts=0,trx=0,ts=1) chan_nr=0x41 RF CHANNEL
RELEASE ACK
<8000> chan_alloc.c:203 freeing logical channel on trx 0, ts 1
<0010> abis_rsl.c:744 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 CONNECTION
FAIL: CAUSE: 18 01 49 Cause 0x18 IGNORING, lchan in use! (1 times)
<0010> abis_rsl.c:744 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 CONNECTION
FAIL: CAUSE: 18 01 49 Cause 0x18 IGNORING, lchan in use! (1 times)
<0010> abis_rsl.c:744 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 CONNECTION
FAIL: CAUSE: 18 01 49 Cause 0x18 IGNORING, lchan in use! (1 times)
<0010> abis_rsl.c:744 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 CONNECTION
FAIL: CAUSE: 18 01 49 Cause 0x18 IGNORING, lchan in use! (1 times)

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

From spaar at mirider.augusta.de  Tue Jun 23 08:36:16 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Tue, 23 Jun 2009 08:36:16 CEST
Subject: location update problem
Message-ID: <4a409400.mirider@mirider.augusta.de>

Hello Andreas,

On Mon, 22 Jun 2009 19:40:17 +0200, "Andreas.Eversberg" <Andreas.Eversberg at versatel.de> wrote:
>
> after location update fails. "DB: Failed to find the Subscriber...", get
> an "ERROR INDICATION" with cause 1. it seems that the mobile just stops
> sending on the channel. the channel ressource hold by location update
> process is not freed. the last messages show that.
>
> i will look on this the next days and report if i found something. if
> you have any idea, please tell me. the way to test any change/fix is
> quite complicated. the bug only occurrs when many phones are available
> and when they move from a different network to my network (built in a
> car, moving arround.)

Just a wild guess: Could it be a reception problem ? If you have set
the BS-11 to a high power level, many phones will see it. Currently the
BS-11 advises the phones to use a very low power level when activating
a channel. So the BS-11 might receive the phone with a low signal
strength and the receiption is just too bad (although the phones will
receive the BS-11 quite well). The measurement reports should indicate
if this is the problem.

Out of interest, do you also have a PC with an E1 card in the car or
do you use a laptop with an USB (or PCMIA) to E1 interface ?

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From Andreas.Eversberg at versatel.de  Tue Jun 23 08:12:38 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 23 Jun 2009 10:12:38 +0200
Subject: AW: location update problem
Message-ID: <B16317F2B1592B4492FC414114171CE69700B5@FLBVEXCH01.versatel.local>

hi,

how can i advice the phone to use the "full" power level according to the power class of the bs11? what parameter and what value is required?

currently we have "kieler woche", an event with up to 3.000.000 visitors over one week.

for the "mobile base station" i use a standard PC with E1/S0 card, a BS11, a laptop, an ISDN phone, and an UPS with 4 * 200Ah batteries.

andreas




-----Urspr?ngliche Nachricht-----
Von: Dieter Spaar [mailto:spaar at mirider.augusta.de] 
Gesendet: Dienstag, 23. Juni 2009 10:36
An: Andreas.Eversberg
Cc: openbsc at lists.gnumonks.org
Betreff: Re: location update problem

Hello Andreas,

On Mon, 22 Jun 2009 19:40:17 +0200, "Andreas.Eversberg" <Andreas.Eversberg at versatel.de> wrote:
>
> after location update fails. "DB: Failed to find the Subscriber...", get
> an "ERROR INDICATION" with cause 1. it seems that the mobile just stops
> sending on the channel. the channel ressource hold by location update
> process is not freed. the last messages show that.
>
> i will look on this the next days and report if i found something. if
> you have any idea, please tell me. the way to test any change/fix is
> quite complicated. the bug only occurrs when many phones are available
> and when they move from a different network to my network (built in a
> car, moving arround.)

Just a wild guess: Could it be a reception problem ? If you have set
the BS-11 to a high power level, many phones will see it. Currently the
BS-11 advises the phones to use a very low power level when activating
a channel. So the BS-11 might receive the phone with a low signal
strength and the receiption is just too bad (although the phones will
receive the BS-11 quite well). The measurement reports should indicate
if this is the problem.

Out of interest, do you also have a PC with an E1 card in the car or
do you use a laptop with an USB (or PCMIA) to E1 interface ?

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de





From laforge at gnumonks.org  Tue Jun 23 16:41:52 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 23 Jun 2009 18:41:52 +0200
Subject: location update problem
In-Reply-To: <B16317F2B1592B4492FC414114171CE69700B5@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE69700B5@FLBVEXCH01.versatel.local>
Message-ID: <20090623164152.GH26945@prithivi.gnumonks.org>

On Tue, Jun 23, 2009 at 10:12:38AM +0200, Andreas.Eversberg wrote:
 
> how can i advice the phone to use the "full" power level according to the
> power class of the bs11? what parameter and what value is required?

Check
* the 'MS POWER' attribute in the ACTIVATE CHANNEL
* the cell selection parameters in SYSTEM INFORMATION TYPE 4 (max tx power for CCH)

-- 
- 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 Andreas.Eversberg at versatel.de  Tue Jun 23 18:29:33 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 23 Jun 2009 20:29:33 +0200
Subject: AW: location update problem
Message-ID: <B16317F2B1592B4492FC414114171CE6970687@FLBVEXCH01.versatel.local>

harald,

i checked the msg_4 array. i found the power info in the description,
but i cannot see where the values are in the array. also i don't really
know the maximum power value for BS11 (GSM 900). is 0db maximum? is it
relative to the BS power class?

> Check
> * the 'MS POWER' attribute in the ACTIVATE CHANNEL
> * the cell selection parameters in SYSTEM INFORMATION TYPE 4 (max tx
power for CCH)

anyway, i found the bug about holding the location update process. i
fixed it, but before i supply a patch, i will check if this really works
when the link fails during location update again.

regards,

andreas



From laforge at gnumonks.org  Wed Jun 24 04:58:49 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 24 Jun 2009 06:58:49 +0200
Subject: location update problem
In-Reply-To: <B16317F2B1592B4492FC414114171CE6970687@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE6970687@FLBVEXCH01.versatel.local>
Message-ID: <20090624045849.GE24414@prithivi.gnumonks.org>

On Tue, Jun 23, 2009 at 08:29:33PM +0200, Andreas.Eversberg wrote:
> harald,
> 
> i checked the msg_4 array. i found the power info in the description,
> but i cannot see where the values are in the array. 

The SI is highly bit-packed information, you will need to read the specs in
order to understand and parse it.  I don't have any more convenient
information, I have to do the same whenever I want to change something.

We could certainly need some code to pack/unpack the information from a more
conveninet C structure into the actual on-air format.

> also i don't really know the maximum power value for BS11 (GSM 900). is 0db
> maximum? is it relative to the BS power class?

The "MS Power" IE is independent of the BS power or BS power class.  It is an
absolute value in dBm as specificed in GSM05.05 and the definition/mapping
between power IE values and dBm is specified in tables of GSM 05.05.

I have committed some unused code for this translation to dBm in http://bs11-abis.gnumonks.org/trac/changeset/fcd2445d05e24c20310790ef0041c8cbe6e6546d - search for
ms_pwr_ctl_lvl() which you can call with the desired dbm level (i.e. 50 which is higher than any phone can transmit) and it will return with the highest possible
value for the BS power IE.  If the phone then supports less than that, it will
in turn use the maximum it has.

For the BS11 in GSM900, the maximum seems to encode to '0'.

> anyway, i found the bug about holding the location update process. i
> fixed it, but before i supply a patch, i will check if this really works
> when the link fails during location update again.

good news!

-- 
- 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 waqas.farooq at gmail.com  Tue Jun 23 08:24:38 2009
From: waqas.farooq at gmail.com (Waqas Farooq)
Date: Tue, 23 Jun 2009 14:24:38 +0600
Subject: Which Pico cells are supported
Message-ID: <fa3175800906230124o6e2c3997nafe16b1c23402ef1@mail.gmail.com>

Hi All,

Can somebody please let me know which Pico cells can be interfaced with Open
BSC? Any help or pointers will be be much appreciated.

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

From bouchtaoui at gmail.com  Tue Jun 23 08:53:22 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Tue, 23 Jun 2009 10:53:22 +0200
Subject: Which Pico cells are supported
In-Reply-To: <fa3175800906230124o6e2c3997nafe16b1c23402ef1@mail.gmail.com>
References: <fa3175800906230124o6e2c3997nafe16b1c23402ef1@mail.gmail.com>
Message-ID: <4A409802.6010709@gmail.com>

The nanoBTS from ip.access should work,
at least it works for me. I use the nanoBTS 139, which works on the 1800 
MHz band.


Waqas Farooq schreef:
> Hi All,
>
> Can somebody please let me know which Pico cells can be interfaced with Open
> BSC? Any help or pointers will be be much appreciated.
>
> Thanks,
>
>   




From waqas.farooq at gmail.com  Wed Jun 24 12:52:54 2009
From: waqas.farooq at gmail.com (Waqas Farooq)
Date: Wed, 24 Jun 2009 18:52:54 +0600
Subject: Which Pico cells are supported
In-Reply-To: <4A409802.6010709@gmail.com>
References: <fa3175800906230124o6e2c3997nafe16b1c23402ef1@mail.gmail.com>
	<4A409802.6010709@gmail.com>
Message-ID: <fa3175800906240552k2b9a83e6kbdb2b6e8a372779d@mail.gmail.com>

Hi Nordin,

Can you please let me know where can I purchase these picocells? These are
not available on Website, eBay or Amazon.

Actually I need to setup a small cellular network for research purposes by
which I can connect one cell phone from one room to another in another room
using a picocell and OpenBSC. Can somebody please help me out in this
regard? Which hardware I will be needing for such purposes apart from a
picocell and where can I purchase them?

Thanks,
Waqas

On Tue, Jun 23, 2009 at 2:53 PM, Nordin <bouchtaoui at gmail.com> wrote:

> The nanoBTS from ip.access should work,
> at least it works for me. I use the nanoBTS 139, which works on the 1800
> MHz band.
>
>
> Waqas Farooq schreef:
>
>  Hi All,
>>
>> Can somebody please let me know which Pico cells can be interfaced with
>> Open
>> BSC? Any help or pointers will be be much appreciated.
>>
>> Thanks,
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090624/21743134/attachment.htm>

From bouchtaoui at gmail.com  Wed Jun 24 13:18:28 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Wed, 24 Jun 2009 15:18:28 +0200
Subject: Which Pico cells are supported
In-Reply-To: <fa3175800906240552k2b9a83e6kbdb2b6e8a372779d@mail.gmail.com>
References: <fa3175800906230124o6e2c3997nafe16b1c23402ef1@mail.gmail.com>	
	<4A409802.6010709@gmail.com>
	<fa3175800906240552k2b9a83e6kbdb2b6e8a372779d@mail.gmail.com>
Message-ID: <4A4227A4.2000907@gmail.com>

Waqas Farooq schreef:
> Can you please let me know where can I purchase these picocells? These are
> not available on Website, eBay or Amazon.
>   

Check this link: http://www.ipaccess.com
I'm working with this one: 
http://www.ipaccess.com/picocells/nanoBTS_picocells.php
Check pdf file: 
http://www.tellumat.com/communications/wireless-solutions/brochures/Nano_BTS_datasheet.pdf

We borrowed it from T-Mobile via a contactperson, but without software, 
so OpenBSC is my hero :)

> Actually I need to setup a small cellular network for research purposes by
> which I can connect one cell phone from one room to another in another room
> using a picocell and OpenBSC. Can somebody please help me out in this
> regard? Which hardware I will be needing for such purposes apart from a
> picocell and where can I purchase them?
>   

I think Harald can help you with that, you can also buy E1 card via 
Harald with some discount.
Maybe he can arrange a nanoBTS for you.

Personally I don't have experience in buying expensive devices, just a 
few microcontrollerkits and a embedded softwarekit.





From bouchtaoui at gmail.com  Tue Jun 23 09:50:30 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Tue, 23 Jun 2009 11:50:30 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support?
Message-ID: <4A40A566.5030205@gmail.com>

Hello guys,

Has anybody registered a PDA phone of 2.5G/3G type to the BS11 bts 
succesfully?
Cause I'm still struggling with it for my nanoBTS (1800 Mhz).

Thank you.




From squ at tent.at  Tue Jun 23 10:29:40 2009
From: squ at tent.at (=?ISO-8859-1?Q?Kai_M=FCnz?=)
Date: Tue, 23 Jun 2009 12:29:40 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <4A40A566.5030205@gmail.com>
References: <4A40A566.5030205@gmail.com>
Message-ID: <4A40AE94.8050601@tent.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Nordin wrote:
> Has anybody registered a PDA phone of 2.5G/3G type to the BS11 bts
> succesfully?

I've tested my BS11 with a certain number of phones. Most phones
work, but there are some picky ones:

Siemens S3com		works
Siemens S10D		works, sometime
Siemens C35		works
Siemens S35		works
Ericsson R290		works, picky about the SIM (problem has 				nothing
to do about the BS11)
SonyEricsson K600i*	works, a little picky sometimes
SonyEricsson T610	almost never works, in fact it registered 				only
once (but worked then)
Nokia 6610i		works
Nokia E90*		works
Nokia 810 Carphone	works
Motorola V3x*		works mostly (sometimes the signal strength 			
changes regularly)

Phones marked with an * are 3G-capable.

All phones were tested using China Mobile M-Zone SIMs (460-02) and a
BS11 on channel 23, broadcasting network 460-02.

(these SIM are available from
http://www.dealextreme.com/details.dx/sku.16159 for $3.94 per 10pc,
including shipping, to reduce problems with SIM trying to register
with its home networks here)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iJwEAQECAAYFAkpArpAACgkQAFwr480vHf0mjAQAhrxFafYOccl9KPHgMgBqMSxE
5IZ8ucxZPvR8luD6M9KfwidO+4oWZVAgyfDBYmPNaVF7fS8gbfx0ip5UoOFJQwaO
vD2AwHNB5io5EaoiVaAcYsJNo88SGtOYvkOhCw1cDn7B/IJqnwC0MK9KyVuMAWQb
GBpLlBKLXFJ54AqGE/Y=
=S700
-----END PGP SIGNATURE-----



From bouchtaoui at gmail.com  Tue Jun 23 21:06:30 2009
From: bouchtaoui at gmail.com (Nordin Bouchtaoui)
Date: Tue, 23 Jun 2009 23:06:30 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <4A40AE94.8050601@tent.at>
References: <4A40A566.5030205@gmail.com> <4A40AE94.8050601@tent.at>
Message-ID: <8aedb85a0906231406y3e0ee10nbe10f19b2d441be8@mail.gmail.com>

Thanks Kai,

I even manually tried to register with my HTC Artemis to our nanoBTS using a
T-Mobile sim but it failed. I'll do some more tests and hopefully with more
results...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090623/c5bf899f/attachment.htm>

From laforge at gnumonks.org  Wed Jun 24 04:59:52 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 24 Jun 2009 06:59:52 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <8aedb85a0906231406y3e0ee10nbe10f19b2d441be8@mail.gmail.com>
References: <4A40A566.5030205@gmail.com> <4A40AE94.8050601@tent.at>
	<8aedb85a0906231406y3e0ee10nbe10f19b2d441be8@mail.gmail.com>
Message-ID: <20090624045952.GF24414@prithivi.gnumonks.org>

On Tue, Jun 23, 2009 at 11:06:30PM +0200, Nordin Bouchtaoui wrote:
> Thanks Kai,
> 
> I even manually tried to register with my HTC Artemis to our nanoBTS using a
> T-Mobile sim but it failed. I'll do some more tests and hopefully with more
> results...

if you can provide us with the detailed log of OpenBSC while you attempt to do
that location update (and preferrably just this one, no other phones
simultaneously), it could enable us to help you.

-- 
- 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 bouchtaoui at gmail.com  Wed Jun 24 13:04:01 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Wed, 24 Jun 2009 15:04:01 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <20090624045952.GF24414@prithivi.gnumonks.org>
References: <4A40A566.5030205@gmail.com>
	<4A40AE94.8050601@tent.at>	<8aedb85a0906231406y3e0ee10nbe10f19b2d441be8@mail.gmail.com>
	<20090624045952.GF24414@prithivi.gnumonks.org>
Message-ID: <4A422441.3000808@gmail.com>

I did the following command:
 ./bsc_hack -t nanobts1800 -c 204 -n 16 -f 866 -L 11 -d -p dump1.pcap

But when I open this pcap file in Wireshark, I get the following message:

The capture file appears to be damaged or corrupt.
(libpcap: LAPD file has a 15-byte packet, too small to have even a LAPD 
pseudo-header).
/This is in WinXP environment./

The filesize keeps at 4 kB and doesn't want to grow, does anyone 
recognises this?

When I manually select our nanoBTS with my HTC pda-phone, it just can't 
register and keeps unconnected to the GSM network, which also shows the 
no-gsm-network symbol (a cross near the antenna symbol) on the display. 
Sometimes it comes with a message "Can't register on the selected 
network. Choose another network or disconnect the data connection and 
try again." The latter part is interesting, what does it mean with 
"disconnect the data connection"? I checked how to turn off GRPS, but up 
to now, I don't know how to configure that. I tried everything.

The debug info of bsc_hack doesn't show any requests from my pda-phone, 
so it doesn't attempt to do a request of whatever type. That's why I 
think my pda-phone is somehow strugling with interpetting the BCCH 
channel concerning the GPRS part. Or there must be another reason. I 
took a gsm-trace from the web and modified SI 3 and SI 4 Rest Octets, 
such that it mimics GPRS support. But the problem is, the pcap file the 
bsc_hack produces, is damaged as I said before. Once again, the debug 
shows nothing when trying to register to our nanoBTS manually.

By the way, I used a T-Mobile sim-card on my pda-phone. The same 
sim-card in a Nokia 6310i registers fine on our nanoBTS.

If you need more information, just ask please. I'll do everything I can.

Thank you.



From zecke at selfish.org  Wed Jun 24 14:09:49 2009
From: zecke at selfish.org (Holger Freyther)
Date: Wed, 24 Jun 2009 16:09:49 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <4A422441.3000808@gmail.com>
References: <4A40A566.5030205@gmail.com>
	<20090624045952.GF24414@prithivi.gnumonks.org>
	<4A422441.3000808@gmail.com>
Message-ID: <200906241609.49605.zecke@selfish.org>

On Wednesday 24 June 2009 15:04:01 Nordin wrote:
> I did the following command:
>  ./bsc_hack -t nanobts1800 -c 204 -n 16 -f 866 -L 11 -d -p dump1.pcap

Yes... pcap for nanobts is broken in at least two ways... For one direction
of the package (from BTS to BSC) the input layer is not used and the message 
is sent directly to the abis_rsl... For the other direction we are currently 
not adding any mISDN header... Please see the "patch 28: wrieshark pcap 
logging" thread for a hint what to do with the current pcap dumping code to 
make it work for the nanobts as well...

z.



From bouchtaoui at gmail.com  Wed Jun 24 14:27:30 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Wed, 24 Jun 2009 16:27:30 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <200906241609.49605.zecke@selfish.org>
References: <4A40A566.5030205@gmail.com>	<20090624045952.GF24414@prithivi.gnumonks.org>	<4A422441.3000808@gmail.com>
	<200906241609.49605.zecke@selfish.org>
Message-ID: <4A4237D2.9050906@gmail.com>

Ok thanks Holger,

It just takes much more time for me to realize that as a "beginner" in 
GNU/Linux environment, but this is the best opportunity to become an 
experienced Linux user :)
At the moment I'm trying to get traces with TShark.

But Holger, do you also have registering issues with pda-phones, like 
the HTC or maybe even the iPhone?
Regards,

Nordin.




From zecke at selfish.org  Wed Jun 24 14:33:38 2009
From: zecke at selfish.org (Holger Freyther)
Date: Wed, 24 Jun 2009 16:33:38 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <4A4237D2.9050906@gmail.com>
References: <4A40A566.5030205@gmail.com> <200906241609.49605.zecke@selfish.org>
	<4A4237D2.9050906@gmail.com>
Message-ID: <200906241633.39476.zecke@selfish.org>

On Wednesday 24 June 2009 16:27:30 Nordin wrote:
> Ok thanks Holger,
>
> It just takes much more time for me to realize that as a "beginner" in
> GNU/Linux environment, but this is the best opportunity to become an
> experienced Linux user.

Yes, the code is not that difficult to understand. Mostly only two files and 
three methods...and you could start with a gross hack and then clean it up?


> But Holger, do you also have registering issues with pda-phones, like
> the HTC or maybe even the iPhone?

I remember we had some problems with the PDA phones at the 25C3, I currently 
have no physical access to any BTS and can't do tests.

z.



From bouchtaoui at gmail.com  Wed Jun 24 14:52:23 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Wed, 24 Jun 2009 16:52:23 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <200906241633.39476.zecke@selfish.org>
References: <4A40A566.5030205@gmail.com>
	<200906241609.49605.zecke@selfish.org>	<4A4237D2.9050906@gmail.com>
	<200906241633.39476.zecke@selfish.org>
Message-ID: <4A423DA7.6060209@gmail.com>


> Yes, the code is not that difficult to understand. Mostly only two files and 
> three methods...and you could start with a gross hack and then clean it up?
>
>   
If it is, I'll give it a try soon ;-)




From dburgess at jcis.net  Wed Jun 24 15:25:54 2009
From: dburgess at jcis.net (David A. Burgess)
Date: Wed, 24 Jun 2009 08:25:54 -0700
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <200906241633.39476.zecke@selfish.org>
References: <4A40A566.5030205@gmail.com> <200906241609.49605.zecke@selfish.org>
	<4A4237D2.9050906@gmail.com> <200906241633.39476.zecke@selfish.org>
Message-ID: <ED11F1C9-983F-40FE-9950-C8A5FBF309CC@jcis.net>

Holger -

[OpenBTS - I'm cross posting this from OpenBSC.]

A problem we had with a lot of PDA phones in OpenBTS was that they  
would attempt to register or access CM services by TMSI, even when  
our system had a different MCC/MNC/LAC and even when we had not yet  
assigned a TMSI.  I first saw this with a Palm Treo 650 but have seen  
it with other PDA phones since then.  I suspect a lot of them are  
using the same broken GSM chipset that does not follow the standard's  
TMSI invalidation rules.  I don't know what you do for TMSI  
resolution in OpenBSC, but if you don't handle this case correctly  
you will have problems with these handsets.

-- David


On Jun 24, 2009, at 7:33 AM, Holger Freyther wrote:

>
>
>> But Holger, do you also have registering issues with pda-phones, like
>> the HTC or maybe even the iPhone?
>
> I remember we had some problems with the PDA phones at the 25C3, I  
> currently
> have no physical access to any BTS and can't do tests.
>
> z.


David A. Burgess
Kestrel Signal Processing, Inc.







From bouchtaoui at gmail.com  Wed Jun 24 15:50:47 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Wed, 24 Jun 2009 17:50:47 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <ED11F1C9-983F-40FE-9950-C8A5FBF309CC@jcis.net>
References: <4A40A566.5030205@gmail.com>
	<200906241609.49605.zecke@selfish.org>	<4A4237D2.9050906@gmail.com>
	<200906241633.39476.zecke@selfish.org>
	<ED11F1C9-983F-40FE-9950-C8A5FBF309CC@jcis.net>
Message-ID: <4A424B57.70501@gmail.com>

Thanks for your post David,

Well that sounds strange, this means that if I turn off my pda phone in 
Holland and turn it on in France, my pda phone won't register because of 
non-standard TMSI issue? I doubt about that.

The case is, I don't even see any transaction between OpenBSC and the 
PDA phone from the debugging of bsc_hack. I have the feeling that the 
PDA phone don't even do any request based on System Informations 
provided by the BCCH of the bsc_hack.

As far as I know, we don't do TMSI resolution. We kind of like saying 
"hey PDA, I don't want the TMSI, just give me your IMSI instead" and so 
the PDA "should" drop the TMSI as it's TEMPRORAY MSI anyway. If that's 
how it works.

c u later...


David A. Burgess schreef:
> Holger -
>
> [OpenBTS - I'm cross posting this from OpenBSC.]
>
> A problem we had with a lot of PDA phones in OpenBTS was that they 
> would attempt to register or access CM services by TMSI, even when our 
> system had a different MCC/MNC/LAC and even when we had not yet 
> assigned a TMSI.  I first saw this with a Palm Treo 650 but have seen 
> it with other PDA phones since then.  I suspect a lot of them are 
> using the same broken GSM chipset that does not follow the standard's 
> TMSI invalidation rules.  I don't know what you do for TMSI resolution 
> in OpenBSC, but if you don't handle this case correctly you will have 
> problems with these handsets.
>
> -- David
>
>
> On Jun 24, 2009, at 7:33 AM, Holger Freyther wrote:
>
>>
>>
>>> But Holger, do you also have registering issues with pda-phones, like
>>> the HTC or maybe even the iPhone?
>>
>> I remember we had some problems with the PDA phones at the 25C3, I 
>> currently
>> have no physical access to any BTS and can't do tests.
>>
>> z.
>
>
> David A. Burgess
> Kestrel Signal Processing, Inc.
>
>
>
>
>
>




From dburgess at jcis.net  Wed Jun 24 16:18:31 2009
From: dburgess at jcis.net (David A. Burgess)
Date: Wed, 24 Jun 2009 09:18:31 -0700
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <4A424B57.70501@gmail.com>
References: <4A40A566.5030205@gmail.com>
	<200906241609.49605.zecke@selfish.org>	<4A4237D2.9050906@gmail.com>
	<200906241633.39476.zecke@selfish.org>
	<ED11F1C9-983F-40FE-9950-C8A5FBF309CC@jcis.net>
	<4A424B57.70501@gmail.com>
Message-ID: <901F344F-4FAF-46B0-9746-EAC73C0AC205@jcis.net>


On Jun 24, 2009, at 8:50 AM, Nordin wrote:

> Thanks for your post David,
>
> Well that sounds strange, this means that if I turn off my pda  
> phone in Holland and turn it on in France, my pda phone won't  
> register because of non-standard TMSI issue? I doubt about that.

No.  It means the PDA might first try to register with that Dutch  
TMSI and then the network will need to explicitly request the IMSI.   
It's not supposed to use that Dutch TMSI in France, but it might try  
if there's a bug in its GSM stack.

> The case is, I don't even see any transaction between OpenBSC and  
> the PDA phone from the debugging of bsc_hack. I have the feeling  
> that the PDA phone don't even do any request based on System  
> Informations provided by the BCCH of the bsc_hack.

Ah.  Sorry.  You are probably correct then.  There's something about  
the BCCH that the phone doesn't like.

> As far as I know, we don't do TMSI resolution. We kind of like  
> saying "hey PDA, I don't want the TMSI, just give me your IMSI  
> instead" and so the PDA "should" drop the TMSI as it's TEMPRORAY  
> MSI anyway. If that's how it works.

That's part of what I mean by TMSI resolution: if you can't recognize  
or support the TMSI, turn around and request the IMSI.  The problem,  
sometimes, is that some phones don't drop the TMSI.  They insist on  
using it, even when it should have been invalidated.  The only way we  
could get the Treo 650 to stop sending us AT&T's old TMSI was to  
assign it one of our own.

>
> c u later...

Not if I c u first... ;-)

-- David

>



From bouchtaoui at gmail.com  Thu Jun 25 07:46:28 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Thu, 25 Jun 2009 09:46:28 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <901F344F-4FAF-46B0-9746-EAC73C0AC205@jcis.net>
References: <4A40A566.5030205@gmail.com>
	<200906241609.49605.zecke@selfish.org>	<4A4237D2.9050906@gmail.com>
	<200906241633.39476.zecke@selfish.org>
	<ED11F1C9-983F-40FE-9950-C8A5FBF309CC@jcis.net>
	<4A424B57.70501@gmail.com>
	<901F344F-4FAF-46B0-9746-EAC73C0AC205@jcis.net>
Message-ID: <4A432B54.7090007@gmail.com>


> No.  It means the PDA might first try to register with that Dutch TMSI 
> and then the network will need to explicitly request the IMSI.  It's 
> not supposed to use that Dutch TMSI in France, but it might try if 
> there's a bug in its GSM stack.

Well I'm sorry, but I'm still not convinced about that. Cause that would 
be a major bug, which won't be accepted by the biggest user group for 
PDA phones (like business men, or presidents like Obama).

> Ah.  Sorry.  You are probably correct then.  There's something about 
> the BCCH that the phone doesn't like.

That's I think is most likely the case.

> That's part of what I mean by TMSI resolution: if you can't recognize 
> or support the TMSI, turn around and request the IMSI.

Yeah, that is what OpenBSC does, I think. But Harald, Holger, Dieter and 
others know more about it.

>   The problem, sometimes, is that some phones don't drop the TMSI.  
> They insist on using it, even when it should have been invalidated. 

In that case, I would see some negotiations from the debug bsc_hack, 
which there is not. So my assumption is still some missing information 
in the BCCH channel. Cause once again, trying to register to my BTS 
manually failed and I don't see any attempt to do just a simple Radio 
Resource request. The latter one I can't confirm that for 100 %, because 
it's possible the debug doesn't show all of that.

> The only way we could get the Treo 650 to stop sending us AT&T's old 
> TMSI was to assign it one of our own.

Well, at least the Treo talked to you.

>>
>> c u later...
>
> Not if I c u first... ;-)
uhhhh....c u soon? :)




From e.cathelinaud at googlemail.com  Thu Jun 25 08:32:56 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Thu, 25 Jun 2009 10:32:56 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <4A432B54.7090007@gmail.com>
References: <4A40A566.5030205@gmail.com> <200906241609.49605.zecke@selfish.org>
	<4A4237D2.9050906@gmail.com> <200906241633.39476.zecke@selfish.org>
	<ED11F1C9-983F-40FE-9950-C8A5FBF309CC@jcis.net>
	<4A424B57.70501@gmail.com>
	<901F344F-4FAF-46B0-9746-EAC73C0AC205@jcis.net>
	<4A432B54.7090007@gmail.com>
Message-ID: <383f8f9a0906250132y71cea247tad6103db6ba15602@mail.gmail.com>

Did anyone try a Samsung mobile phone?
I tried 3 different kind of Samsung and none of them can attach to the
network (but they can see it with manual research).
Problems with :
Samsung U600
Samsung PlayerAddict I900
Samsung E840

Working fine with Nokia and Ericsson mobile phones

Eric Cathelinaud


2009/6/25 Nordin <bouchtaoui at gmail.com>

>
>  No.  It means the PDA might first try to register with that Dutch TMSI and
>> then the network will need to explicitly request the IMSI.  It's not
>> supposed to use that Dutch TMSI in France, but it might try if there's a bug
>> in its GSM stack.
>>
>
> Well I'm sorry, but I'm still not convinced about that. Cause that would be
> a major bug, which won't be accepted by the biggest user group for PDA
> phones (like business men, or presidents like Obama).
>
>  Ah.  Sorry.  You are probably correct then.  There's something about the
>> BCCH that the phone doesn't like.
>>
>
> That's I think is most likely the case.
>
>  That's part of what I mean by TMSI resolution: if you can't recognize or
>> support the TMSI, turn around and request the IMSI.
>>
>
> Yeah, that is what OpenBSC does, I think. But Harald, Holger, Dieter and
> others know more about it.
>
>   The problem, sometimes, is that some phones don't drop the TMSI.  They
>> insist on using it, even when it should have been invalidated.
>>
>
> In that case, I would see some negotiations from the debug bsc_hack, which
> there is not. So my assumption is still some missing information in the BCCH
> channel. Cause once again, trying to register to my BTS manually failed and
> I don't see any attempt to do just a simple Radio Resource request. The
> latter one I can't confirm that for 100 %, because it's possible the debug
> doesn't show all of that.
>
>  The only way we could get the Treo 650 to stop sending us AT&T's old TMSI
>> was to assign it one of our own.
>>
>
> Well, at least the Treo talked to you.
>
>
>>> c u later...
>>>
>>
>> Not if I c u first... ;-)
>>
> uhhhh....c u soon? :)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090625/30f59f29/attachment.htm>

From dburgess at jcis.net  Thu Jun 25 14:54:19 2009
From: dburgess at jcis.net (David A. Burgess)
Date: Thu, 25 Jun 2009 07:54:19 -0700
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <4A432B54.7090007@gmail.com>
References: <4A40A566.5030205@gmail.com>
	<200906241609.49605.zecke@selfish.org>	<4A4237D2.9050906@gmail.com>
	<200906241633.39476.zecke@selfish.org>
	<ED11F1C9-983F-40FE-9950-C8A5FBF309CC@jcis.net>
	<4A424B57.70501@gmail.com>
	<901F344F-4FAF-46B0-9746-EAC73C0AC205@jcis.net>
	<4A432B54.7090007@gmail.com>
Message-ID: <1F9AA451-BE3C-448B-BBD3-B73E79711EAD@jcis.net>


On Jun 25, 2009, at 12:46 AM, Nordin wrote:

>
>> No.  It means the PDA might first try to register with that Dutch  
>> TMSI and then the network will need to explicitly request the  
>> IMSI.  It's not supposed to use that Dutch TMSI in France, but it  
>> might try if there's a bug in its GSM stack.
>
> Well I'm sorry, but I'm still not convinced about that. Cause that  
> would be a major bug, which won't be accepted by the biggest user  
> group for PDA phones (like business men, or presidents like Obama).

I agree that it is a major bug and a security risk for high-profile  
users, but it is real.  The users might reject it if they knew, but  
most have no way of knowing, unless, of course, someone publishes a  
report on it and to my knowledge nobody has.  (OK, except for Obama.   
You can bet someone competent has done an analysis of his PDA.)

>
>> Ah.  Sorry.  You are probably correct then.  There's something  
>> about the BCCH that the phone doesn't like.
>
> That's I think is most likely the case.

It would be great if someone with an OpenBTS system could turn on  
debugging messages and capture the raw bits from our system  
information messages 1-4 and send them to you for you to try in your  
OpenBSC build.  I'd do it myself but I am traveling a lot lately and  
don't have the equipment with me.

I looked at the BCCH messages in OpenBSC yesterday, but could not  
identify the problem.  I don't know how OpenBSC handles the "rest  
octets" at the ends of these messages, but it is important that these  
be properly padded with the GSM filler pattern if you are not coding  
anything there.  This is especially important for high-feature phones  
that might actually be looking for GPRS parameters.  It is also  
important to present the BCCH messages in the correct sequence and  
with the timing given in GSM 05.02 6.3.1.3, but I suspect your BTS  
takes care of that for you.

>
>> That's part of what I mean by TMSI resolution: if you can't  
>> recognize or support the TMSI, turn around and request the IMSI.
>
> Yeah, that is what OpenBSC does, I think. But Harald, Holger,  
> Dieter and others know more about it.
>
>>   The problem, sometimes, is that some phones don't drop the  
>> TMSI.  They insist on using it, even when it should have been  
>> invalidated.
>
> In that case, I would see some negotiations from the debug  
> bsc_hack, which there is not. So my assumption is still some  
> missing information in the BCCH channel. Cause once again, trying  
> to register to my BTS manually failed and I don't see any attempt  
> to do just a simple Radio Resource request. The latter one I can't  
> confirm that for 100 %, because it's possible the debug doesn't  
> show all of that.

I agree with your analysis.  If the handset actually sees the  
network, then you do not have a frequency offset problem.  Therefore,  
if you do not see channel requests coming from the phone via the BTS  
the most likely explanation is that the phone has found some  
inconsistency in the BCCH.

>
>> The only way we could get the Treo 650 to stop sending us AT&T's  
>> old TMSI was to assign it one of our own.
>
> Well, at least the Treo talked to you.
>
>>>
>>> c u later...
>>
>> Not if I c u first... ;-)
> uhhhh....c u soon? :)

Sorry.  It's joking response: If I see you coming, I will hide.  Just  
a joke, though.

>

-- David

David A. Burgess
Kestrel Signal Processing, Inc.







From bouchtaoui at gmail.com  Fri Jun 26 09:15:08 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Fri, 26 Jun 2009 11:15:08 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <1F9AA451-BE3C-448B-BBD3-B73E79711EAD@jcis.net>
References: <4A40A566.5030205@gmail.com>
	<200906241609.49605.zecke@selfish.org>	<4A4237D2.9050906@gmail.com>
	<200906241633.39476.zecke@selfish.org>
	<ED11F1C9-983F-40FE-9950-C8A5FBF309CC@jcis.net>
	<4A424B57.70501@gmail.com>
	<901F344F-4FAF-46B0-9746-EAC73C0AC205@jcis.net>
	<4A432B54.7090007@gmail.com>
	<1F9AA451-BE3C-448B-BBD3-B73E79711EAD@jcis.net>
Message-ID: <4A44919C.40104@gmail.com>


> It would be great if someone with an OpenBTS system could turn on 
> debugging messages and capture the raw bits from our system 
> information messages 1-4 and send them to you for you to try in your 
> OpenBSC build.

Well, I already did that by using some traces I found in 
http://wiki.thc.org/. There I copied some values for GPRS support and 
changed that in OpenBSC source. Also added the missing SI 13 to the 
source, which contains some more info about the GPRS, but without success.

> I looked at the BCCH messages in OpenBSC yesterday, but could not 
> identify the problem.  I don't know how OpenBSC handles the "rest 
> octets" at the ends of these messages, but it is important that these 
> be properly padded with the GSM filler pattern if you are not coding 
> anything there.  This is especially important for high-feature phones 
> that might actually be looking for GPRS parameters.  It is also 
> important to present the BCCH messages in the correct sequence and 
> with the timing given in GSM 05.02 6.3.1.3, but I suspect your BTS 
> takes care of that for you.

In OpenBSC (I have older version, didn't do any updates yet) There are 
SI 1 to 4 that are filled and the Rest Octets (in SI 3 and SI 4) are 
filled with 0x2B, which the MS should ignore and thus it also indicates 
no GPRS support.

> I agree with your analysis.  If the handset actually sees the network, 
> then you do not have a frequency offset problem.  Therefore, if you do 
> not see channel requests coming from the phone via the BTS the most 
> likely explanation is that the phone has found some inconsistency in 
> the BCCH.

Exactly, that's my assumption too. But as my collegue once said 
"Assumption is the mother of all f at ck" from a movie scene of Steven 
Seagal's film Under Siege 2. The fact is, it should/must work with BTSs 
without GPRS, so I think some important basic information on the BCCH is 
not complete and thus maybe corrupt in a certain way.  Cause the same 
problem also occurs with the BS11 BTS according to other guys in the 
list.  So I'll concentrate more on the BCCH and try to understand it 
carefully.

> Sorry.  It's joking response: If I see you coming, I will hide.  Just 
> a joke, though.

No need for appolagize, I like jokes too :p It's funny we laugh about 
jokes. Actually, we should always laugh and laugh harder when we hear a 
joke. The world would be so beautiful than.

Greetings,

Laughing Nordin.




From laforge at gnumonks.org  Wed Jun 24 15:28:31 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 24 Jun 2009 17:28:31 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <4A422441.3000808@gmail.com>
References: <4A40A566.5030205@gmail.com> <4A40AE94.8050601@tent.at>
	<8aedb85a0906231406y3e0ee10nbe10f19b2d441be8@mail.gmail.com>
	<20090624045952.GF24414@prithivi.gnumonks.org>
	<4A422441.3000808@gmail.com>
Message-ID: <20090624152831.GH24414@prithivi.gnumonks.org>

On Wed, Jun 24, 2009 at 03:04:01PM +0200, Nordin wrote:
> I did the following command:
> ./bsc_hack -t nanobts1800 -c 204 -n 16 -f 866 -L 11 -d -p dump1.pcap
>
> But when I open this pcap file in Wireshark, I get the following message:

you should not use PCAP mode with nanoBTS.  in the case of nanoBTS, it is easy
to start tcpdump or wireshark to capture the IP traffic off the ethernet
interface.

pcap mode of OpenBSC is intended for BS-11 connected to traditional E1
lines.
-- 
- 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 spaar at mirider.augusta.de  Tue Jun 23 13:17:47 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Tue, 23 Jun 2009 13:17:47 CEST
Subject: AW: location update problem
Message-ID: <4a40d5fb.mirider@mirider.augusta.de>

Hello Andreas,

On Tue, 23 Jun 2009 10:12:38 +0200, "Andreas.Eversberg" <Andreas.Eversberg at versatel.de> wrote:
> 
> how can i advice the phone to use the "full" power level according to
> the power class of the bs11? what parameter and what value is required?

Currently the BS power is set in rsl_rx_chan_rqd() (file abis_rsl.c),
its the "lchan->ms_power" assignment. Currently the value 0x0F (13 dBm)
is used (I am not sure if this is still true for the latest version of
OpenBSC). If you set this value to 0, the MS will use the maximum
power (usually only 5 is supported for GSM900, 2 Watt). I did only
a few tests, but I could see that my phone uses the modified value.

You can of course also look at the measurement report and check the
used values.

> currently we have "kieler woche", an event with up to 3.000.000 visitors
> over one week.
> 
> for the "mobile base station" i use a standard PC with E1/S0 card, a
> BS11, a laptop, an ISDN phone, and an UPS with 4 * 200Ah batteries.

Cool, do you have some pictures of the setup ? :-)

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From Andreas.Eversberg at versatel.de  Tue Jun 23 11:30:17 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Tue, 23 Jun 2009 13:30:17 +0200
Subject: AW: AW: location update problem
Message-ID: <B16317F2B1592B4492FC414114171CE697034C@FLBVEXCH01.versatel.local>

picture!

> Cool, do you have some pictures of the setup ? :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mbs.JPG
Type: image/jpeg
Size: 136686 bytes
Desc: mbs.JPG
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090623/3125b3ea/attachment.jpe>

From squ at tent.at  Tue Jun 23 12:19:20 2009
From: squ at tent.at (=?ISO-8859-15?Q?Kai_M=FCnz?=)
Date: Tue, 23 Jun 2009 14:19:20 +0200
Subject: AW: location update problem
In-Reply-To: <4a40d5fb.mirider@mirider.augusta.de>
References: <4a40d5fb.mirider@mirider.augusta.de>
Message-ID: <4A40C848.5040401@tent.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> for the "mobile base station" i use a standard PC with E1/S0 card, a
>> BS11, a laptop, an ISDN phone, and an UPS with 4 * 200Ah batteries.

There is an even lighter setup possible.

I'm using an old IBM Thinkpad R50p with a Thinkpad DockII (Ebay, 30Eur)

http://www.bildschirmtext.org/thinkpad-e1.jpg

Just connect the BTS and play %)

Regards,
Kai
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iJwEAQECAAYFAkpAyEMACgkQAFwr480vHf0c9QQArGmlGlxtBrbNHW2LDFdU7IqG
x5S2SWv6I26cBnJjIKiLLSUAV0gr4Fh4XNjZohpACv8jeV6dIj+KWjFv18fTnADy
g+6FmCw8t++nS7i7DOJUaE1ZkZTK5sov48T0TaJeshFcGkEYojrTpnaLSKZOR+rb
j8ouhy1EMpdS+gh2EDI=
=38j5
-----END PGP SIGNATURE-----



From spaar at mirider.augusta.de  Tue Jun 23 15:45:49 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Tue, 23 Jun 2009 15:45:49 CEST
Subject: AW: location update problem
Message-ID: <4a40f8ad.mirider@mirider.augusta.de>

Hallo Kai,

On Tue, 23 Jun 2009 14:19:20 +0200, "=?ISO-8859-15?Q?Kai_M=FCnz?=" <squ at tent.at> wrote:
> 
> There is an even lighter setup possible.
> 
> I'm using an old IBM Thinkpad R50p with a Thinkpad DockII (Ebay, 30Eur)
> 
> http://www.bildschirmtext.org/thinkpad-e1.jpg
> 
> Just connect the BTS and play %)

Nice, and it even has DECT connnectivity (looks like a COM-ON-AIR card
in the background :-)

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From spaar at mirider.augusta.de  Tue Jun 23 15:17:22 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Tue, 23 Jun 2009 15:17:22 CEST
Subject: AW: AW: location update problem
Message-ID: <4a40f202.mirider@mirider.augusta.de>

Hello Andreas,

On Tue, 23 Jun 2009 13:30:17 +0200, "Andreas.Eversberg" <Andreas.Eversberg at versatel.de> wrote:
> 
> picture!

Even more cool :-). I expected a bigger car, maybe a van, to but all
the stuff inside. Really nice GSM war-driving setup ;-)

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From spaar at mirider.augusta.de  Wed Jun 24 09:12:30 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Wed, 24 Jun 2009 09:12:30 CEST
Subject: BS/MS power summary
Message-ID: <4a41edfe.mirider@mirider.augusta.de>

Hello,

I try to give a short summary of the MS and BS power settings.
It is not intended to replace the GSM specs, it just contains
the important things for the current BS-11 configuration.

MS power:

  - The MS power is usually specified as an absolute value,
    a lower value means higher power. Some values for GSM 900 
    (GSM 1800 has a different encoding):

        15 ->  13 dBm (0.02 W)
        10 ->  23 dBm (0.2  W)
         5 ->  33 dBm (2    W)

         
  - The power used to access the RACH before any channel is active, 
    is defined by a Cell Selection parameter in SYSTEM INFORMATION 
    TYPE 3 and 4. 

    Remark: bsc_hack currently uses "2" which should be increased
    (lower power) to avoid interference with the public networks.
    
    
  - When the BTS activates a channel, it sets the MS power. 
    bsc_hack currently sets it to 15 which should be OK for testing
    (see rsl_rx_chan_rqd() in abis_rsl.c).
     
    
  - Dynamic power control of the MS power by the BTS is currently 
    not enabled.
    
  
BS power:
  
  - For the BS-11 the PA power can be configured to 0.03W, 0.08W,
    0.25W or 2W (b11_config can be used for this purpose).
    
    
  - The attribute NM_ATT_RF_MAXPOWR_R of each TRX of the BS-11 
    can be set to a value from 0 (0dB) to 6 (12dB) to reduce
    the power in steps of 2dB (see bsc_hack.c).
      
    
  - for the TRX which carries the BCCH, there is no dynamic 
    BS power control possible. In the meantime I have read
    at several places that the BCCH TRX has to use a fixed power
    and additionally cannot use a different ARFCN for example
    for the TCH (which also means that no hopping is possible). 
    To use hopping or dynamic BS power control, the second TRX 
    has to be used and configured in a way that it does not carry
    a BCCH.
  
    
Best regard,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From Andreas.Eversberg at versatel.de  Thu Jun 25 09:16:58 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Thu, 25 Jun 2009 11:16:58 +0200
Subject: AW: BS/MS power summary
Message-ID: <B16317F2B1592B4492FC414114171CE69B432F@FLBVEXCH01.versatel.local>

dieter,

thanx for the detailed description. i will try this out this weekend. i
will use a 900mhz radio receiver to check out the change in signal
strength. i cannot get any measurement reports yet. the change of
NM_ATT_BS11_RADIO_MEAS_GRAN value did not get me any measurement report
as before.

regards,

andreas



From spaar at mirider.augusta.de  Thu Jun 25 11:47:54 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Thu, 25 Jun 2009 11:47:54 CEST
Subject: AW: BS/MS power summary
Message-ID: <4a4363ea.mirider@mirider.augusta.de>

Hello Andreas,

On Thu, 25 Jun 2009 11:16:58 +0200, "Andreas.Eversberg" <Andreas.Eversberg at versatel.de> wrote:
> 
> thanx for the detailed description. i will try this out this weekend. i
> will use a 900mhz radio receiver to check out the change in signal
> strength. i cannot get any measurement reports yet. the change of
> NM_ATT_BS11_RADIO_MEAS_GRAN value did not get me any measurement report
> as before.

Strange that you don't see the measurement reports.

Here are the two attributes I use for the TRX attributes
and they result in lots of reports when a channel is active
(at least for a speech channel, for a location update there
might be only one report because the connection is not active
that long):

  NM_ATT_BS11_RADIO_MEAS_GRAN, 0x01, 0x05,
  NM_ATT_BS11_RADIO_MEAS_REP, 0x01, 0x01,

I think I also tried it already with 0x02 to get a report
every second.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From Andreas.Eversberg at versatel.de  Fri Jun 26 08:38:54 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Fri, 26 Jun 2009 10:38:54 +0200
Subject: AW: AW: BS/MS power summary
Message-ID: <B16317F2B1592B4492FC414114171CE69B4A4C@FLBVEXCH01.versatel.local>

hi,

i tested the suggested values:

>  NM_ATT_BS11_RADIO_MEAS_GRAN, 0x01, 0x05,
>  NM_ATT_BS11_RADIO_MEAS_REP, 0x01, 0x01,

no measurement reports during calls, never seen one before. maybe i have
the wrong firmware load? i also get errors after starting bsc-hack on
the lmt. i will try to load a different firmware this weekend.

regards,

andreas







From laforge at gnumonks.org  Thu Jun 25 19:00:51 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 25 Jun 2009 21:00:51 +0200
Subject: updated wireshark patches / call for help
Message-ID: <20090625190051.GM26626@prithivi.gnumonks.org>

Hi!

I've just committed some recent improvements of the Abis dissection of
wireshark to git.

There's some initial work on a 12.21 OML decoder in
epan/dissectors/packet-abis_oml.c.  It will happily decode the common FOM
header and tell you the name of the message as well as list all attributes
in it.  It does not yet understand details on how to parse all the various
attributes.  If anyone wants to make himself familiar with this part of
GSM, get a copy of 12.21, look at OpenBSC or protocol traces and add
more of that attribute parsing code!

The A-bis/IP dissector has only been improved slightly.

If you apply abisip.patch and abis_oml.patch to current wireshark svn,
you will be able to decode 94-99% of what you see in any capture between
OpenBSC and a nanoBTS.

I currently don't have access to a BS-11, so I cannot test the wireshark
code with it.  In case somebody wants to send me some pcap files of BS-11
traces, either by using the openbsc pcap option or by tracing it through mISDN,
I'm more than happy to make sure that it works on thos traces, too.

Testing as well as contributed patches are also always welcome!

Thanks,
-- 
- 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 Jun 28 01:07:01 2009
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 28 Jun 2009 03:07:01 +0200
Subject: updated wireshark patches / call for help
In-Reply-To: <20090625190051.GM26626@prithivi.gnumonks.org>
References: <20090625190051.GM26626@prithivi.gnumonks.org>
Message-ID: <200906280307.02081.holger@freyther.de>

On Thursday 25 June 2009 21:00:51 Harald Welte wrote:
> I currently don't have access to a BS-11, so I cannot test the wireshark
> code with it.  In case somebody wants to send me some pcap files of BS-11
> traces, either by using the openbsc pcap option or by tracing it through
> mISDN, I'm more than happy to make sure that it works on thos traces, too.

There is a simple/older trace in our wiki and the other question is if you 
know if someone confirmed that one can directly trace through mISDN? If that is 
the case we can nuke the pcap code from OpenBSC?

holger



From laforge at gnumonks.org  Thu Jun 25 19:16:59 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 25 Jun 2009 21:16:59 +0200
Subject: Some initial investigation on GPRS support
Message-ID: <20090625191659.GN26626@prithivi.gnumonks.org>

Hi!

I've started to analyze GPRS and was actually even starting to write some code
for it, but then have given up for the time being - it's much more work than
anticipated.

Given the long todo list of OpenBSC right now, I think I'll have put aside GPRS
for some time :(

Based on looking at protocol traces, I have figured out the nanoBTS GPRS/EDGE
implementation roughly looks as follows:

* make sure we allow the BTS to activate the GPRS software components
  in abis_nm / OML activation!
* BTS will use a UDP connection on port 23000 for the GPRS related frames.
  The GSM specs will consider this type of connection between the PCU (part
  of the nanoBTS) and the SGSN.  The establishment/configuration of the
  UDP port number and SGSN ip address has not yet been identified.  Probably
  similar to how the RSL link is activated via OML.

  The protocol stack looks like:

  IP : UDP : NSIP : BSSGP : LLC : higher-layer

  IP and UDP you should know and/or not care about ;)
  NSIP is a IP-enabled version of NS as specified in TS 08.16
  BSSGP is specified in TS 08.18
  LLC is as specified in TS 04.64

  the higher-layer depends on the SAPI value of the LLC and can be
  * GMM (GPRS Mobility Management as specified in 04.08)
  * User Data (actual IP packets, e.g.)
  * SMS

So what is weird about this is that the GPRS MM is actually part of 04.08, but
it is not terminated at the BSC but rather at the SGSN.  Also, the deep stack
comprised of many headers is really weird.  Furthermore, it seems that a lot
of the packet scheduling and timeslot allocation is happening inside the
nanoBTS - very unlike the GSM side of things.

I have not yet managed to figure out how to allocate/dedicate resources to
GPRS.. after all, the BTS needs to know how many timeslots it can use for it,
etc.

If anyone wants to dig deeper, you're most welcome to do so.  A list of
relevant specs:

01.61 GPRS cipher algorithm requirements
03.60 Overall GRPS logical architecture (above RL and MAC)
03.64 GPRS radio interface
04.60 RLC/MAC on PDCH
04.64 MS-SGSN LLC spec (on top of RLC/MAC)
04.65 SGSN SNDCP
08.14 BSS SGSN Gb Layer 1
08.16 BSS SGSN Gb Layer 2
08.18 BSS SGSN BSS GPRS protocol
09.95 Interworking between modified PLMN supporting legacy GPRS and GPRS mobiles
22.060 GPRS Service Spec
23.060 GPRS Radio Service Spec
29.016 SGSN - VLR Interface Gs network interface spec
29.018 SGSN - VLR Interface Gs layer3 interface spec
29.060 GPRS Tunneling (GTP) over Gn and Gp

Happy hacking,
-- 
- 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 bouchtaoui at gmail.com  Fri Jun 26 08:41:06 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Fri, 26 Jun 2009 10:41:06 +0200
Subject: Some initial investigation on GPRS support
In-Reply-To: <20090625191659.GN26626@prithivi.gnumonks.org>
References: <20090625191659.GN26626@prithivi.gnumonks.org>
Message-ID: <4A4489A2.1040800@gmail.com>

Hi Harald,

I would love to contribute as much as I can, but as a father of two kids 
and as a husband it's really hard to have some time free. So my 
contribution is very minimal, sorry for that.
All I can do is doing some tests, try to modify parameters in the source 
and give feedback about the result. And ofcourse learn as much as 
possible :) Anyway, I'll do everything I can to help you.

Offtopic: Today I'm a bit sad, because Michael Jackson died.

Thank you.


Harald Welte schreef:
> Hi!
>
> I've started to analyze GPRS and was actually even starting to write some code
> for it, but then have given up for the time being - it's much more work than
> anticipated.
>
> Given the long todo list of OpenBSC right now, I think I'll have put aside GPRS
> for some time :(
>
> Based on looking at protocol traces, I have figured out the nanoBTS GPRS/EDGE
> implementation roughly looks as follows:
>
> * make sure we allow the BTS to activate the GPRS software components
>   in abis_nm / OML activation!
> * BTS will use a UDP connection on port 23000 for the GPRS related frames.
>   The GSM specs will consider this type of connection between the PCU (part
>   of the nanoBTS) and the SGSN.  The establishment/configuration of the
>   UDP port number and SGSN ip address has not yet been identified.  Probably
>   similar to how the RSL link is activated via OML.
>
>   The protocol stack looks like:
>
>   IP : UDP : NSIP : BSSGP : LLC : higher-layer
>
>   IP and UDP you should know and/or not care about ;)
>   NSIP is a IP-enabled version of NS as specified in TS 08.16
>   BSSGP is specified in TS 08.18
>   LLC is as specified in TS 04.64
>
>   the higher-layer depends on the SAPI value of the LLC and can be
>   * GMM (GPRS Mobility Management as specified in 04.08)
>   * User Data (actual IP packets, e.g.)
>   * SMS
>
> So what is weird about this is that the GPRS MM is actually part of 04.08, but
> it is not terminated at the BSC but rather at the SGSN.  Also, the deep stack
> comprised of many headers is really weird.  Furthermore, it seems that a lot
> of the packet scheduling and timeslot allocation is happening inside the
> nanoBTS - very unlike the GSM side of things.
>
> I have not yet managed to figure out how to allocate/dedicate resources to
> GPRS.. after all, the BTS needs to know how many timeslots it can use for it,
> etc.
>
> If anyone wants to dig deeper, you're most welcome to do so.  A list of
> relevant specs:
>
> 01.61 GPRS cipher algorithm requirements
> 03.60 Overall GRPS logical architecture (above RL and MAC)
> 03.64 GPRS radio interface
> 04.60 RLC/MAC on PDCH
> 04.64 MS-SGSN LLC spec (on top of RLC/MAC)
> 04.65 SGSN SNDCP
> 08.14 BSS SGSN Gb Layer 1
> 08.16 BSS SGSN Gb Layer 2
> 08.18 BSS SGSN BSS GPRS protocol
> 09.95 Interworking between modified PLMN supporting legacy GPRS and GPRS mobiles
> 22.060 GPRS Service Spec
> 23.060 GPRS Radio Service Spec
> 29.016 SGSN - VLR Interface Gs network interface spec
> 29.018 SGSN - VLR Interface Gs layer3 interface spec
> 29.060 GPRS Tunneling (GTP) over Gn and Gp
>
> Happy hacking,
>   




From spaar at mirider.augusta.de  Fri Jun 26 10:59:24 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Fri, 26 Jun 2009 10:59:24 CEST
Subject: AW: AW: BS/MS power summary
Message-ID: <4a44aa0c.mirider@mirider.augusta.de>

Hello Andreas,

On Fri, 26 Jun 2009 10:38:54 +0200, "Andreas.Eversberg" <Andreas.Eversberg at versatel.de> wrote:
> 
> i tested the suggested values:
> 
> >  NM_ATT_BS11_RADIO_MEAS_GRAN, 0x01, 0x05,
> >  NM_ATT_BS11_RADIO_MEAS_REP, 0x01, 0x01,
> 
> no measurement reports during calls, never seen one before. maybe i have
> the wrong firmware load? i also get errors after starting bsc-hack on
> the lmt. i will try to load a different firmware this weekend.

This is what I use:

  Safety Load: HS010876.SWL
  SW Load:     HS011106.SWL

Just one other thing, I am watching the measurement reports in custom
E1 traces. I guess this should not care and bsc_hack will show them
too.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From Andreas.Eversberg at versatel.de  Sun Jun 28 16:47:31 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Sun, 28 Jun 2009 18:47:31 +0200
Subject: patches again
Message-ID: <B16317F2B1592B4492FC414114171CE69FE98D@FLBVEXCH01.versatel.local>

hi,
 
i did some heavy tests this weekend with many mobile stations at once.
with these patches all ressources (channels / subscribers) were released
cleanly. even when mobile stations request more than 4 channels at a
time (the current SDCCH4 is full), there is no ressource getting stuck
anymore.
 
patch 39: the location update process did not work, if mobile station
uses tmsi when comming from a different network. in this case the
reject-timer must also be started, and we wait for imsi identity
response. in case we can't find the subscriber or if we have an
unimplemented location update, we release location update process and
send a reject.
 
patch 40: in case of a channel breakdown, the signal handler for
releasing lchan is called. the wrong pointer was used as lchan. (see
last hunk) also we don't need to check use counter of lchan, if we
receive an "cause 22 error". the lchan gets released anyway, if use
counter becomes 0. (see first hunk). also i think we can force channel
release when we receive an error indication. this can easily be tested:
remove the battery during active call, then send a message to the mobile
station (hang up on the remote). the message cannot be delivered, so the
BTS send us an error indication, the channels and the call process gets
released.
 
patch 41: the pointer "tall_bsc_ctx" belongs to the gsm_data.c file, not
to include file.
 
patch 42: again my traffic channel patch. the mobile requests a channel.
in case of a location update, we deliver the requested channel type. if
we receive a channel request for other reasons, i force a TCH_F channel.
this is requied, because we cannot change (modify) the channel right
now. also i check if we have a TCH_F channel when we want to make a call
to the mobile. if so, the channel is used, if not, paging is stated as
if we would have no channel. so it is possible to call a mobile during
location update, when it holds not a TCH_F channel.
 
patch 43: this small fix will not check for given subscriber/imsi here.
this is already done in the next "if"-condition.
 
patch 38: still i use this little hacked install patch to install
library and include files, so other applications like LCR can use
openbsc without refering to the openbsc source directory. i use that
install-hook, because i don't know much about autoconf. maybe there is a
better way to do that.
 
anyway i don't get any measurement reports at all. i tried two BTS' and
used the firmware as described in the wiki.
 
regards,
 
andreas
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090628/805847e5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 43_imsi_fix.patch
Type: application/octet-stream
Size: 547 bytes
Desc: 43_imsi_fix.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090628/805847e5/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 38_install.patch
Type: application/octet-stream
Size: 2485 bytes
Desc: 38_install.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090628/805847e5/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 39_loc_update.patch
Type: application/octet-stream
Size: 1170 bytes
Desc: 39_loc_update.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090628/805847e5/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 40_lchan_release.patch
Type: application/octet-stream
Size: 1340 bytes
Desc: 40_lchan_release.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090628/805847e5/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 41_tall_bsc_ctx.patch
Type: application/octet-stream
Size: 1188 bytes
Desc: 41_tall_bsc_ctx.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090628/805847e5/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 42_tch_f.patch
Type: application/octet-stream
Size: 1074 bytes
Desc: 42_tch_f.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090628/805847e5/attachment-0005.obj>

From laforge at gnumonks.org  Sun Jun 28 21:23:01 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 28 Jun 2009 23:23:01 +0200
Subject: patches again
In-Reply-To: <B16317F2B1592B4492FC414114171CE69FE98D@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE69FE98D@FLBVEXCH01.versatel.local>
Message-ID: <20090628212301.GM8467@prithivi.gnumonks.org>

Dear Andreas,

I'll try to review your patches ASAP, but due to my current workload I think I
might not find time before the weekend...

> anyway i don't get any measurement reports at all. i tried two BTS' and
> used the firmware as described in the wiki.

I'm once again travelling and won't be in Berlin (with my BS-11) for at least
another month, so I cannot do any tests by myself.  I only have a nanoBTS  
1800 with me here in Hamburg.

However, since Dieter has been seeing the measurement reports, I would hope he
is able to verify wether it works for him with the current git version of
OpenBSC, or what kind of changes he needs to make it work.  Sorry :(

Cheers,
-- 
- 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  Mon Jun 29 12:41:52 2009
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Mon, 29 Jun 2009 14:41:52 +0200
Subject: patches again
In-Reply-To: <B16317F2B1592B4492FC414114171CE69FE98D@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE69FE98D@FLBVEXCH01.versatel.local>
Message-ID: <200906291441.53480.holger@freyther.de>

On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 38: still i use this little hacked install patch to install
> library and include files, so other applications like LCR can use
> openbsc without refering to the openbsc source directory. i use that
> install-hook, because i don't know much about autoconf. maybe there is a
> better way to do that.

There is. Currently all the libraries are noinst libraries.. I did sent a 
patch to the mailinglist you could attempt to extent and make ready?

	z.



From holger at freyther.de  Mon Jun 29 12:54:30 2009
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Mon, 29 Jun 2009 14:54:30 +0200
Subject: Patch 39: WAS: Re: patches again
In-Reply-To: <B16317F2B1592B4492FC414114171CE69FE98D@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE69FE98D@FLBVEXCH01.versatel.local>
Message-ID: <200906291454.30130.holger@freyther.de>

On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 39: the location update process did not work, if mobile station
> uses tmsi when comming from a different network. in this case the
> reject-timer must also be started, and we wait for imsi identity
> response. in case we can't find the subscriber or if we have an
> unimplemented location update, we release location update process and
> send a reject.

Sorry, to me it seems the patch is doing something else...

1.) 
        if (!subscr) {
                DEBUGPC(DRR, "<- Can't find any subscriber for this ID\n");
                /* FIXME: request id? close channel? */
+               release_loc_updating_req(lchan);
+               gsm0408_loc_upd_rej(lchan, reject_cause);
                return -EINVAL;
        }

I think we can just move the schedule_reject from two lines below the if to 
the top. What do you think?


2.) The patch changes the policy from delayed reject (to not make the MS come 
back immediately) to a direct one. What is the reasoning?




From holger at freyther.de  Mon Jun 29 12:57:16 2009
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Mon, 29 Jun 2009 14:57:16 +0200
Subject: abnormal channel release WAS: Re: patches again
In-Reply-To: <B16317F2B1592B4492FC414114171CE69FE98D@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE69FE98D@FLBVEXCH01.versatel.local>
Message-ID: <200906291457.16183.holger@freyther.de>

On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 40: in case of a channel breakdown, the signal handler for
> releasing lchan is called. the wrong pointer was used as lchan. (see
> last hunk) also we don't need to check use counter of lchan, if we
> receive an "cause 22 error". the lchan gets released anyway, if use
> counter becomes 0. (see first hunk). also i think we can force channel
> release when we receive an error indication. this can easily be tested:
> remove the battery during active call, then send a message to the mobile
> station (hang up on the remote). the message cannot be delivered, so the
> BTS send us an error indication, the channels and the call process gets
> released.


Okay. As stupid as it might sound please split that into three patches.

1.) Fixing my stupidity in gsm0408_handle_lchan_signal!!! sorry for making you 
suffer from it and thanks for fixing it.

2.) static int rsl_rx_rll_err_ind(struct msgb *msg) 

3.) Explain why 

+//                     if (msg->lchan->use_count > 0) {
+//                     }

is a good change and should be applied?


thanks



From holger at freyther.de  Mon Jun 29 12:58:16 2009
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Mon, 29 Jun 2009 14:58:16 +0200
Subject: move tall_bsc_ctx WAS: Re: patches again
In-Reply-To: <B16317F2B1592B4492FC414114171CE69FE98D@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE69FE98D@FLBVEXCH01.versatel.local>
Message-ID: <200906291458.16866.holger@freyther.de>

On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 41: the pointer "tall_bsc_ctx" belongs to the gsm_data.c file, not
> to include file.

seems sensible.




From spaar at mirider.augusta.de  Mon Jun 29 15:24:37 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Mon, 29 Jun 2009 15:24:37 CEST
Subject: patches again
Message-ID: <4a48dcb5.mirider@mirider.augusta.de>

Hello Harald,

On Sun, 28 Jun 2009 23:23:01 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> 
> However, since Dieter has been seeing the measurement reports, I would hope he
> is able to verify wether it works for him with the current git version of
> OpenBSC, or what kind of changes he needs to make it work.  Sorry :(

I tested it with the git version from yesterday. The TRX0 is
configured properly, I can see that the attributes are set as
they should. I can also see the measurement reports in my custom
traces (I set NM_ATT_BS11_RADIO_MEAS_GRAN to 0x05).

I don't use mISDN on Linux (I use Cygwin on Windows with my custom
driver). However I had to adjust my custom driver to see the
measurement reports in bsc_hack. The reason is that the measurement
reports are sent as LAPD UI-Frames and not as LAPD I-Frames and I did
not yet take care of UI-Frames. Maybe there is a similar problem with
mISDN and UI-Frames.

One other thing is that decoding the measurement report might not
yet work properly, bsc_hack says that the reports are invalid but
for the MA10 Analyzer they are fine.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From laforge at gnumonks.org  Mon Jun 29 16:12:02 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 29 Jun 2009 18:12:02 +0200
Subject: patches again
In-Reply-To: <4a48dcb5.mirider@mirider.augusta.de>
References: <4a48dcb5.mirider@mirider.augusta.de>
Message-ID: <20090629161202.GP8467@prithivi.gnumonks.org>

On Mon, Jun 29, 2009 at 03:24:37PM +0200, Dieter Spaar wrote:
> Hello Harald,
> 
> On Sun, 28 Jun 2009 23:23:01 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> > 
> > However, since Dieter has been seeing the measurement reports, I would hope he
> > is able to verify wether it works for him with the current git version of
> > OpenBSC, or what kind of changes he needs to make it work.  Sorry :(
> 
> I tested it with the git version from yesterday. The TRX0 is
> configured properly, I can see that the attributes are set as
> they should. I can also see the measurement reports in my custom
> traces (I set NM_ATT_BS11_RADIO_MEAS_GRAN to 0x05).
> 
> I don't use mISDN on Linux (I use Cygwin on Windows with my custom
> driver). However I had to adjust my custom driver to see the
> measurement reports in bsc_hack. The reason is that the measurement
> reports are sent as LAPD UI-Frames and not as LAPD I-Frames and I did
> not yet take care of UI-Frames. Maybe there is a similar problem with
> mISDN and UI-Frames.

Thanks!

UI frames should be reported to userspace as DL_UNITDATA_IND rather than
DL_DATA_IND.  openbsc/input/misdn.c currently doesn't support DL_UNITDATA_IND
in the switch statement of handle_ts1_read.  That sounds like the most likely
cause.

-- 
- 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 zecke at selfish.org  Mon Jun 29 16:44:31 2009
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 29 Jun 2009 18:44:31 +0200
Subject: patches again
Message-ID: <200906291844.32480.zecke@selfish.org>

On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 38: still i use this little hacked install patch to install
> library and include files, so other applications like LCR can use
> openbsc without refering to the openbsc source directory. i use that
> install-hook, because i don't know much about autoconf. maybe there is a
> better way to do that.

There is. Currently all the libraries are noinst libraries.. I did sent a 
patch to the mailinglist you could attempt to extent and make ready?

	z.



From Andreas.Eversberg at versatel.de  Mon Jun 29 21:37:51 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 29 Jun 2009 23:37:51 +0200
Subject: AW: patches again
Message-ID: <B16317F2B1592B4492FC414114171CE69FF191@FLBVEXCH01.versatel.local>

> UI frames should be reported to userspace as DL_UNITDATA_IND rather
than DL_DATA_IND.  openbsc/input/misdn.c currently doesn't support
DL_UNITDATA_IND in the switch statement of handle_ts1_read.  That sounds
like the most likely cause.


hi harald,

this was the problem. finally got the measurement reports (--debug
....:DMEAS). you just need to add to misdn.c:

		case DL_UNITDATA_IND:

and everything is fine.

regards,

andreas





From holger at freyther.de  Mon Jun 29 14:51:28 2009
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Mon, 29 Jun 2009 16:51:28 +0200
Subject: MSC split out progress
Message-ID: <200906291651.28253.holger@freyther.de>

Hey,

just a small head up. I rebased the holger/msc branch and also moved the mncc 
bits into the libmsc. I'm currently in Essen and should be able to test these 
patches tomorrow.

One thing that keeps me from pushing (after having tested) is the following 
observation. For going from layer3 to layer4 we currently have a queue, for my 
patches when going from layer2 to layer3 I have a direct callback. Should I 
change that to use the same queuing approach?

holger



From zecke at selfish.org  Mon Jun 29 15:27:28 2009
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 29 Jun 2009 17:27:28 +0200
Subject: Cleanup some parsing in the mncc.c code
Message-ID: <200906291727.29186.zecke@selfish.org>

Hey Harald,

did you have this in mind when mentioning that the parsing of the data derived 
informations could be driven by a struct?

z.


From 594cf586dedaecfc5e755a6d0fc9ac69dc513e91 Mon Sep 17 00:00:00 2001
From: Holger Hans Peter Freyther <zecke at selfish.org>
Date: Mon, 29 Jun 2009 17:21:37 +0200
Subject: [PATCH] Generic data derived informations parsing...

Declare what elements to parse in a struct and then trigger
the generic parsing routine.
---
 openbsc/src/msc_mncc.c |  211 ++++++++++++++++++++---------------------------
 1 files changed, 90 insertions(+), 121 deletions(-)

diff --git a/openbsc/src/msc_mncc.c b/openbsc/src/msc_mncc.c
index b54e184..5329fa1 100644
--- a/openbsc/src/msc_mncc.c
+++ b/openbsc/src/msc_mncc.c
@@ -112,6 +112,39 @@ static const char *cc_state_names[] = {
 	"illegal state 31",
 };
 
+typedef int (*dd_decoder)(void* data, const u_int8_t *lv);
+
+struct dd_parser {
+	int information_element;
+	int mncc_field;
+	int offset;
+	dd_decoder decoder;
+};
+
+#define DECLARE_DECODER3(IE_NAME, M_NAME, name) \
+	{ .information_element = GSM48_IE_##IE_NAME, \
+	  .mncc_field = MNCC_F_##M_NAME, \
+	  .offset = offsetof(struct gsm_mncc, name), \
+	  .decoder = (dd_decoder)decode_##name, \
+	}
+
+
+#define DECLARE_DECODER(NAME, name) \
+	    DECLARE_DECODER3(NAME, NAME, name)
+
+static void parse_data_derived_information(struct dd_parser *parser, const 
int length,
+					   struct tlv_parsed *tp, struct gsm_mncc *rel)
+{
+	int i;
+
+	for (i = 0; i < length; ++i) {
+		if (TLVP_PRESENT(tp, parser[i].information_element)) {
+			rel->fields |= parser[i].mncc_field;
+			parser[i].decoder(rel + parser[i].offset,
+					  TLVP_VAL(tp, parser[i].information_element)-1);
+		}
+	}
+}
 
 static int mncc_handle_lchan_signal(unsigned int subsys, unsigned int signal,
 				    void *handler_data, void *signal_data)
@@ -1420,31 +1453,15 @@ static int msc_cc_rx_disconnect(struct gsm_trans 
*trans, struct msgb *msg)
 	memset(&disc, 0, sizeof(struct gsm_mncc));
 	disc.callref = trans->callref;
 	tlv_parse(&tp, &rsl_att_tlvdef, gh->data, payload_len, GSM48_IE_CAUSE, 0);
-	/* cause */
-	if (TLVP_PRESENT(&tp, GSM48_IE_CAUSE)) {
-		disc.fields |= MNCC_F_CAUSE;
-		decode_cause(&disc.cause,
-			     TLVP_VAL(&tp, GSM48_IE_CAUSE)-1);
-	}
-	/* facility */
-	if (TLVP_PRESENT(&tp, GSM48_IE_FACILITY)) {
-		disc.fields |= MNCC_F_FACILITY;
-		decode_facility(&disc.facility,
-				TLVP_VAL(&tp, GSM48_IE_FACILITY)-1);
-	}
-	/* user-user */
-	if (TLVP_PRESENT(&tp, GSM48_IE_USER_USER)) {
-		disc.fields |= MNCC_F_USERUSER;
-		decode_useruser(&disc.useruser,
-				TLVP_VAL(&tp, GSM48_IE_USER_USER)-1);
-	}
-	/* ss-version */
-	if (TLVP_PRESENT(&tp, GSM48_IE_SS_VERS)) {
-		disc.fields |= MNCC_F_SSVERSION;
-		decode_ssversion(&disc.ssversion,
-				 TLVP_VAL(&tp, GSM48_IE_SS_VERS)-1);
-	}
 
+	static struct dd_parser parser[] = {
+		DECLARE_DECODER(CAUSE, cause),
+		DECLARE_DECODER(FACILITY, facility),
+		DECLARE_DECODER3(USER_USER, USERUSER, useruser),
+		DECLARE_DECODER3(SS_VERS, SSVERSION, ssversion),
+	};
+
+	parse_data_derived_information(&parser[0], ARRAY_SIZE(parser), &tp, &disc);
 	return mncc_recvmsg(trans->network, trans, MNCC_DISC_IND, &disc);
 
 }
@@ -1509,30 +1526,15 @@ static int msc_cc_rx_release(struct gsm_trans *trans, 
struct msgb *msg)
 	memset(&rel, 0, sizeof(struct gsm_mncc));
 	rel.callref = trans->callref;
 	tlv_parse(&tp, &rsl_att_tlvdef, gh->data, payload_len, 0, 0);
-	/* cause */
-	if (TLVP_PRESENT(&tp, GSM48_IE_CAUSE)) {
-		rel.fields |= MNCC_F_CAUSE;
-		decode_cause(&rel.cause,
-			     TLVP_VAL(&tp, GSM48_IE_CAUSE)-1);
-	}
-	/* facility */
-	if (TLVP_PRESENT(&tp, GSM48_IE_FACILITY)) {
-		rel.fields |= MNCC_F_FACILITY;
-		decode_facility(&rel.facility,
-				TLVP_VAL(&tp, GSM48_IE_FACILITY)-1);
-	}
-	/* user-user */
-	if (TLVP_PRESENT(&tp, GSM48_IE_USER_USER)) {
-		rel.fields |= MNCC_F_USERUSER;
-		decode_useruser(&rel.useruser,
-				TLVP_VAL(&tp, GSM48_IE_USER_USER)-1);
-	}
-	/* ss-version */
-	if (TLVP_PRESENT(&tp, GSM48_IE_SS_VERS)) {
-		rel.fields |= MNCC_F_SSVERSION;
-		decode_ssversion(&rel.ssversion,
-				 TLVP_VAL(&tp, GSM48_IE_SS_VERS)-1);
-	}
+
+	static struct dd_parser parser[] = {
+		DECLARE_DECODER(CAUSE, cause),
+		DECLARE_DECODER(FACILITY, facility),
+		DECLARE_DECODER3(USER_USER, USERUSER, useruser),
+		DECLARE_DECODER3(SS_VERS, SSVERSION, ssversion),
+	};
+
+	parse_data_derived_information(&parser[0], ARRAY_SIZE(parser), &tp, &rel);
 
 	if (trans->state == GSM_CSTATE_RELEASE_REQ) {
 		/* release collision 5.4.5 */
@@ -1598,30 +1600,15 @@ static int msc_cc_rx_release_compl(struct gsm_trans 
*trans, struct msgb *msg)
 	memset(&rel, 0, sizeof(struct gsm_mncc));
 	rel.callref = trans->callref;
 	tlv_parse(&tp, &rsl_att_tlvdef, gh->data, payload_len, 0, 0);
-	/* cause */
-	if (TLVP_PRESENT(&tp, GSM48_IE_CAUSE)) {
-		rel.fields |= MNCC_F_CAUSE;
-		decode_cause(&rel.cause,
-			     TLVP_VAL(&tp, GSM48_IE_CAUSE)-1);
-	}
-	/* facility */
-	if (TLVP_PRESENT(&tp, GSM48_IE_FACILITY)) {
-		rel.fields |= MNCC_F_FACILITY;
-		decode_facility(&rel.facility,
-				TLVP_VAL(&tp, GSM48_IE_FACILITY)-1);
-	}
-	/* user-user */
-	if (TLVP_PRESENT(&tp, GSM48_IE_USER_USER)) {
-		rel.fields |= MNCC_F_USERUSER;
-		decode_useruser(&rel.useruser,
-				TLVP_VAL(&tp, GSM48_IE_USER_USER)-1);
-	}
-	/* ss-version */
-	if (TLVP_PRESENT(&tp, GSM48_IE_SS_VERS)) {
-		rel.fields |= MNCC_F_SSVERSION;
-		decode_ssversion(&rel.ssversion,
-				 TLVP_VAL(&tp, GSM48_IE_SS_VERS)-1);
-	}
+
+	static struct dd_parser parser[] = {
+		DECLARE_DECODER(CAUSE, cause),
+		DECLARE_DECODER(FACILITY, facility),
+		DECLARE_DECODER3(USER_USER, USERUSER, useruser),
+		DECLARE_DECODER3(SS_VERS, SSVERSION, ssversion),
+	};
+
+	parse_data_derived_information(&parser[0], ARRAY_SIZE(parser), &tp, &rel);
 
 	if (trans->callref) {
 		switch (trans->state) {
@@ -1684,19 +1671,13 @@ static int msc_cc_rx_facility(struct gsm_trans *trans, 
struct msgb *msg)
 	memset(&fac, 0, sizeof(struct gsm_mncc));
 	fac.callref = trans->callref;
 	tlv_parse(&tp, &rsl_att_tlvdef, gh->data, payload_len, GSM48_IE_FACILITY, 
0);
-	/* facility */
-	if (TLVP_PRESENT(&tp, GSM48_IE_FACILITY)) {
-		fac.fields |= MNCC_F_FACILITY;
-		decode_facility(&fac.facility,
-				TLVP_VAL(&tp, GSM48_IE_FACILITY)-1);
-	}
-	/* ss-version */
-	if (TLVP_PRESENT(&tp, GSM48_IE_SS_VERS)) {
-		fac.fields |= MNCC_F_SSVERSION;
-		decode_ssversion(&fac.ssversion,
-				 TLVP_VAL(&tp, GSM48_IE_SS_VERS)-1);
-	}
 
+	static struct dd_parser parser[] = {
+		DECLARE_DECODER(FACILITY, facility),
+		DECLARE_DECODER3(SS_VERS, SSVERSION, ssversion),
+	};
+
+	parse_data_derived_information(&parser[0], ARRAY_SIZE(parser), &tp, &fac);
 	return mncc_recvmsg(trans->network, trans, MNCC_FACILITY_IND, &fac);
 }
 
@@ -1807,12 +1788,11 @@ static int msc_cc_rx_start_dtmf(struct gsm_trans 
*trans, struct msgb *msg)
 	dtmf.callref = trans->callref;
 	tlv_parse(&tp, &rsl_att_tlvdef, gh->data, payload_len, 0, 0);
 	/* keypad facility */
-	if (TLVP_PRESENT(&tp, GSM48_IE_KPD_FACILITY)) {
-		dtmf.fields |= MNCC_F_KEYPAD;
-		decode_keypad(&dtmf.keypad,
-			      TLVP_VAL(&tp, GSM48_IE_KPD_FACILITY)-1);
-	}
+	static struct dd_parser parser[] = {
+		DECLARE_DECODER3(KPD_FACILITY, KEYPAD, keypad),
+	};
 
+	parse_data_derived_information(&parser[0], ARRAY_SIZE(parser), &tp, &dtmf);
 	return mncc_recvmsg(trans->network, trans, MNCC_START_DTMF_IND, &dtmf);
 }
 
@@ -1884,15 +1864,12 @@ static int msc_cc_rx_modify(struct gsm_trans *trans, 
struct msgb *msg)
 	memset(&modify, 0, sizeof(struct gsm_mncc));
 	modify.callref = trans->callref;
 	tlv_parse(&tp, &rsl_att_tlvdef, gh->data, payload_len, GSM48_IE_BEARER_CAP, 
0);
-	/* bearer capability */
-	if (TLVP_PRESENT(&tp, GSM48_IE_BEARER_CAP)) {
-		modify.fields |= MNCC_F_BEARER_CAP;
-		decode_bearer_cap(&modify.bearer_cap,
-				  TLVP_VAL(&tp, GSM48_IE_BEARER_CAP)-1);
-	}
+	static struct dd_parser parser[] = {
+		DECLARE_DECODER(BEARER_CAP, bearer_cap),
+	};
 
+	parse_data_derived_information(&parser[0], ARRAY_SIZE(parser), &tp, 
&modify);
 	new_cc_state(trans, GSM_CSTATE_MO_ORIG_MODIFY);
-
 	return mncc_recvmsg(trans->network, trans, MNCC_MODIFY_IND, &modify);
 }
 
@@ -1928,15 +1905,12 @@ static int msc_cc_rx_modify_complete(struct gsm_trans 
*trans, struct msgb *msg)
 	memset(&modify, 0, sizeof(struct gsm_mncc));
 	modify.callref = trans->callref;
 	tlv_parse(&tp, &rsl_att_tlvdef, gh->data, payload_len, GSM48_IE_BEARER_CAP, 
0);
-	/* bearer capability */
-	if (TLVP_PRESENT(&tp, GSM48_IE_BEARER_CAP)) {
-		modify.fields |= MNCC_F_BEARER_CAP;
-		decode_bearer_cap(&modify.bearer_cap,
-				  TLVP_VAL(&tp, GSM48_IE_BEARER_CAP)-1);
-	}
+	static struct dd_parser parser[] = {
+		DECLARE_DECODER(BEARER_CAP, bearer_cap),
+	};
 
+	parse_data_derived_information(&parser[0], ARRAY_SIZE(parser), &tp, 
&modify);
 	new_cc_state(trans, GSM_CSTATE_ACTIVE);
-
 	return mncc_recvmsg(trans->network, trans, MNCC_MODIFY_CNF, &modify);
 }
 
@@ -1970,19 +1944,13 @@ static int msc_cc_rx_modify_reject(struct gsm_trans 
*trans, struct msgb *msg)
 	memset(&modify, 0, sizeof(struct gsm_mncc));
 	modify.callref = trans->callref;
 	tlv_parse(&tp, &rsl_att_tlvdef, gh->data, payload_len, GSM48_IE_BEARER_CAP, 
GSM48_IE_CAUSE);
-	/* bearer capability */
-	if (TLVP_PRESENT(&tp, GSM48_IE_BEARER_CAP)) {
-		modify.fields |= GSM48_IE_BEARER_CAP;
-		decode_bearer_cap(&modify.bearer_cap,
-				  TLVP_VAL(&tp, GSM48_IE_BEARER_CAP)-1);
-	}
-	/* cause */
-	if (TLVP_PRESENT(&tp, GSM48_IE_CAUSE)) {
-		modify.fields |= MNCC_F_CAUSE;
-		decode_cause(&modify.cause,
-			     TLVP_VAL(&tp, GSM48_IE_CAUSE)-1);
-	}
 
+
+	static struct dd_parser parser[] = {
+		DECLARE_DECODER(BEARER_CAP, bearer_cap),
+		DECLARE_DECODER(CAUSE, cause),
+	};
+	parse_data_derived_information(&parser[0], ARRAY_SIZE(parser), &tp, 
&modify);
 	new_cc_state(trans, GSM_CSTATE_ACTIVE);
 
 	return mncc_recvmsg(trans->network, trans, MNCC_MODIFY_REJ, &modify);
@@ -2070,12 +2038,13 @@ static int msc_cc_rx_userinfo(struct gsm_trans *trans, 
struct msgb *msg)
 	memset(&user, 0, sizeof(struct gsm_mncc));
 	user.callref = trans->callref;
 	tlv_parse(&tp, &rsl_att_tlvdef, gh->data, payload_len, GSM48_IE_USER_USER, 
0);
-	/* user-user */
-	if (TLVP_PRESENT(&tp, GSM48_IE_USER_USER)) {
-		user.fields |= MNCC_F_USERUSER;
-		decode_useruser(&user.useruser,
-				TLVP_VAL(&tp, GSM48_IE_USER_USER)-1);
-	}
+
+	static struct dd_parser parser[] = {
+		DECLARE_DECODER3(USER_USER, USERUSER, useruser),
+	};
+
+	parse_data_derived_information(&parser[0], ARRAY_SIZE(parser), &tp, &user);
+
 	/* more data */
 	if (TLVP_PRESENT(&tp, GSM48_IE_MORE_DATA))
 		user.more = 1;
-- 
1.6.3.1




From zecke at selfish.org  Mon Jun 29 16:43:42 2009
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 29 Jun 2009 18:43:42 +0200
Subject: abnormal channel release WAS: Re: patches again
Message-ID: <200906291843.43402.zecke@selfish.org>

On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 40: in case of a channel breakdown, the signal handler for
> releasing lchan is called. the wrong pointer was used as lchan. (see
> last hunk) also we don't need to check use counter of lchan, if we
> receive an "cause 22 error". the lchan gets released anyway, if use
> counter becomes 0. (see first hunk). also i think we can force channel
> release when we receive an error indication. this can easily be tested:
> remove the battery during active call, then send a message to the mobile
> station (hang up on the remote). the message cannot be delivered, so the
> BTS send us an error indication, the channels and the call process gets
> released.


Okay. As stupid as it might sound please split that into three patches.

1.) Fixing my stupidity in gsm0408_handle_lchan_signal!!! sorry for making you 
suffer from it and thanks for fixing it.

2.) static int rsl_rx_rll_err_ind(struct msgb *msg) 

3.) Explain why 

+//                     if (msg->lchan->use_count > 0) {
+//                     }

is a good change and should be applied?


thanks



From Andreas.Eversberg at versatel.de  Mon Jun 29 19:48:40 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 29 Jun 2009 21:48:40 +0200
Subject: AW: abnormal channel release WAS: Re: patches again
Message-ID: <B16317F2B1592B4492FC414114171CE69FF18B@FLBVEXCH01.versatel.local>

hi holger,

i can do that soon. part 3 just removes the if-condition. i missed to
remove it after testing. i will fix it in the forthcomming splitted
patches.

regards,

andreas
 

> Okay. As stupid as it might sound please split that into three
patches.

> 1.) Fixing my stupidity in gsm0408_handle_lchan_signal!!! sorry for
making you suffer from it and thanks for fixing it.

> 2.) static int rsl_rx_rll_err_ind(struct msgb *msg) 

> 3.) Explain why 

> +//                     if (msg->lchan->use_count > 0) {
> +//                     }

> is a good change and should be applied?




From zecke at selfish.org  Mon Jun 29 16:43:55 2009
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 29 Jun 2009 18:43:55 +0200
Subject: move tall_bsc_ctx WAS: Re: patches again
Message-ID: <200906291843.56085.zecke@selfish.org>

On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 41: the pointer "tall_bsc_ctx" belongs to the gsm_data.c file, not
> to include file.

seems sensible.




From zecke at selfish.org  Mon Jun 29 16:44:06 2009
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 29 Jun 2009 18:44:06 +0200
Subject: MSC split out progress
Message-ID: <200906291844.07203.zecke@selfish.org>

Hey,

just a small head up. I rebased the holger/msc branch and also moved the mncc 
bits into the libmsc. I'm currently in Essen and should be able to test these 
patches tomorrow.

One thing that keeps me from pushing (after having tested) is the following 
observation. For going from layer3 to layer4 we currently have a queue, for my 
patches when going from layer2 to layer3 I have a direct callback. Should I 
change that to use the same queuing approach?

holger



From Andreas.Eversberg at versatel.de  Mon Jun 29 20:46:08 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 29 Jun 2009 22:46:08 +0200
Subject: AW: MSC split out progress
Message-ID: <B16317F2B1592B4492FC414114171CE69FF18E@FLBVEXCH01.versatel.local>


> One thing that keeps me from pushing (after having tested) is the
following observation. For going from layer3 to layer4 we currently have
a queue, for my patches when going from layer2 to layer3 I have a direct
callback. Should I change that to use the same queuing approach?

hi holger,

for me it is very hard to explain, but i will try...

- bsc = lower layer (signalling)
- msc = upper layer (application)

actually we need a queue in only one direction, if we link two finite
state machines. (or in our case link two instances of transactions using
mncc.c).

during an bsc-event, when a message from bsc is sent to msc, the bsc
might do some processing right after sending the message. without a
queue, the msc could reply directly to that message (with a function
call to msc) which may change the state machine of bsc, while bsc is
still processing the first event... (race condition)

an up-queue from bsc to msc will fix that problem. msc will only process
messages, if bsc has finished it's processing of events.

in case of a message from msc to bsc, we also don't have that problem,
even without a queue. if msc sends a message directly down to bsc (using
a function call), an eventually direct reply is queued in the up-queue,
so msc can finish processing the first event before processing the
message in the up-queue.

it does not matter if the queue is for messages from bsc to msc, or from
msc to bsc, but at least we need one queue.

it may happen that a message is dequeued, but the call instance is
already gone. in this case the other layer (bsc or msc) should ignore
it. this is why the call reference is used instead of a memory pointer.
also it must be unique all the (run-)time.


regards,

andreas 





From zecke at selfish.org  Mon Jun 29 16:44:15 2009
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 29 Jun 2009 18:44:15 +0200
Subject: Patch 39: WAS: Re: patches again
Message-ID: <200906291844.15509.zecke@selfish.org>

On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 39: the location update process did not work, if mobile station
> uses tmsi when comming from a different network. in this case the
> reject-timer must also be started, and we wait for imsi identity
> response. in case we can't find the subscriber or if we have an
> unimplemented location update, we release location update process and
> send a reject.

Sorry, to me it seems the patch is doing something else...

1.) 
        if (!subscr) {
                DEBUGPC(DRR, "<- Can't find any subscriber for this ID\n");
                /* FIXME: request id? close channel? */
+               release_loc_updating_req(lchan);
+               gsm0408_loc_upd_rej(lchan, reject_cause);
                return -EINVAL;
        }

I think we can just move the schedule_reject from two lines below the if to 
the top. What do you think?


2.) The patch changes the policy from delayed reject (to not make the MS come 
back immediately) to a direct one. What is the reasoning?




From Andreas.Eversberg at versatel.de  Mon Jun 29 20:47:06 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 29 Jun 2009 22:47:06 +0200
Subject: AW: Patch 39: WAS: Re: patches again
Message-ID: <B16317F2B1592B4492FC414114171CE69FF18D@FLBVEXCH01.versatel.local>

 

> I think we can just move the schedule_reject from two lines below the
if to the top. What do you think?


> 2.) The patch changes the policy from delayed reject (to not make the
MS come 
> back immediately) to a direct one. What is the reasoning?


hi holger,

1. just move it to the top.

2. you are right. only we need to restart the timer and exit, on
location update with TMSI. also i was concerned about loosing link to
mobile. in this case we get a timeout, so only the first 3 lines make
sense. anyway i will test it and see if i missed to explain an
importaint reason.

regards,

andreas



From Andreas.Eversberg at versatel.de  Mon Jun 29 19:42:20 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 29 Jun 2009 21:42:20 +0200
Subject: WG: patches again
Message-ID: <B16317F2B1592B4492FC414114171CE69FF18A@FLBVEXCH01.versatel.local>

> I don't use mISDN on Linux (I use Cygwin on Windows with my custom
driver). However I had to adjust my custom driver to see the measurement
reports in bsc_hack. The reason is that the measurement reports are sent
as LAPD UI-Frames and not as LAPD I-Frames and I did not yet take care
of UI-Frames. Maybe there is a similar problem with mISDN and UI-Frames.


hi dieter,

this is indeed a good thing to check. i can enable frame debugging on
hfc-e1, so i can see every frame in hex. also i can sniff frames using
an mISDN userland tool. with that i can see if there are any frames. if
so i will check why the driver does not report UI frames in this case,
and fix it..

regards,

andreas 







From spaar at mirider.augusta.de  Tue Jun 30 09:51:20 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Tue, 30 Jun 2009 09:51:20 CEST
Subject: AW: patches again
Message-ID: <4a49e018.mirider@mirider.augusta.de>

Hello Andreas,

On Mon, 29 Jun 2009 23:37:51 +0200, "Andreas.Eversberg" <Andreas.Eversberg at versatel.de> wrote:
>
> this was the problem. finally got the measurement reports (--debug
> ....:DMEAS). you just need to add to misdn.c:
> 
> 		case DL_UNITDATA_IND:
> 
> and everything is fine.

Great, so this is solved.

I noticed one minor problem, its the meaning of the MEAS-VALID
flag. The spec says that "0" means "valid" and "1" is "not valid".

So

  if (!(meas_rep.flags & MEAS_REP_F_VALID))

should be changed or the parsing of the measurement result where this
flag is set.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de