From bouchtaoui at gmail.com  Fri Jul  3 09:21:59 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Fri, 03 Jul 2009 11:21:59 +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: <4A4DCDB7.5080809@gmail.com>

Hello guys,

As I am not an experienced GSM engineer I can't fully understand the GSM 
specs.
But I found this in paragraph 4.1.1.2.1 of GSM 04.08:
"NOTE:
Whenever GMM performs a combined GMM procedure, a GPRS MS enters the MM 
state
MM LOCATION UPDATING PENDING in order to prevent the MM to perform a 
location update procedure."

Since we haven't done anything for GPRS support, this might be the 
reason why a location update is not performed with bsc_hack.

Once again, I'm a beginner on this field and still need some more 
readings and learning of GSM and OpenBSC sources.
But I hope I found the part that might lead you to solve the GPRS 
supported mobiles registering issue.

P.S.: Is everybody on holiday...:)




From laforge at gnumonks.org  Sat Jul  4 09:22:51 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 4 Jul 2009 11:22:51 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <4A4DCDB7.5080809@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>
	<1F9AA451-BE3C-448B-BBD3-B73E79711EAD@jcis.net>
	<4A4DCDB7.5080809@gmail.com>
Message-ID: <20090704092251.GF28952@prithivi.gnumonks.org>

On Fri, Jul 03, 2009 at 11:21:59AM +0200, Nordin wrote:

> As I am not an experienced GSM engineer I can't fully understand the GSM  
> specs.
> But I found this in paragraph 4.1.1.2.1 of GSM 04.08:
> "NOTE:
> Whenever GMM performs a combined GMM procedure, a GPRS MS enters the MM  
> state
> MM LOCATION UPDATING PENDING in order to prevent the MM to perform a  
> location update procedure."

I think the way OpenBSC is working (or at leats supposed to work), we don't
permit for any combined GMM procedures but rather tread GSM and GPRS entirely
separate.  I don't remember the terminology, but there are three entirely
different methods on how MM and GMM interact.  They probably reflect the
evolvement of GSM equipment.  The simplest case to move forward for us is
to keep GSM and GPRS entirely separate, i.e. not risking any regressions
due to the inclusion of GPRS support (if at all, at some point).

I strongly believe the problem is related to our SYSTEM INFROMATION headers,
but I currently don't have the time to debug/verify the implementation that I
did for it in some git branch...

> P.S.: Is everybody on holiday...:)

no, working full-time on GSM security 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)



From spaar at mirider.augusta.de  Fri Jul  3 14:27:22 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Fri, 03 Jul 2009 14:27:22 CEST
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
Message-ID: <4a4e154a.mirider@mirider.augusta.de>

Hello Nordin,

On Fri, 03 Jul 2009 11:21:59 +0200, "Nordin" <bouchtaoui at gmail.com> wrote:
> 
> Since we haven't done anything for GPRS support, this might be the 
> reason why a location update is not performed with bsc_hack.

The problem you experience with the nanoBTS 1800 most certainly
comes from an invalid System Information Type 1. It uses the bitmap
type for the channel description which is only valid for GSM900.
So all the phones should try to register with the BS-11 but for
the nanoBTS 1800 phones which strictly confirm to the specification
will ignore it and not try to register (there are some phones which
don't care).

You can try the "system_information" git branch from Harald, it
will most certainly solve the problem.

> P.S.: Is everybody on holiday...:)

I guess the people are just busy...

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



From bouchtaoui at gmail.com  Fri Jul  3 13:20:37 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Fri, 03 Jul 2009 15:20:37 +0200
Subject: Downloading source project
In-Reply-To: <4a4e154a.mirider@mirider.augusta.de>
References: <4a4e154a.mirider@mirider.augusta.de>
Message-ID: <4A4E05A5.6010408@gmail.com>

Hi guys,

A git-beginner's question, I installed git on my Debian, and when trying 
to checkout OpenBSC project as suggested on the website:

"git clone git://bs11-abis.gnumonks.org/openbsc.git"

it somehow hangs at:
"Initialized empty Git repository in /home/nordin/Development/CProjects/openbsc/.git/"

Am I missing a step or is there something wrong with the git-repository or something?





From laforge at gnumonks.org  Sat Jul  4 09:24:29 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 4 Jul 2009 11:24:29 +0200
Subject: Downloading source project
In-Reply-To: <4A4E05A5.6010408@gmail.com>
References: <4a4e154a.mirider@mirider.augusta.de> <4A4E05A5.6010408@gmail.com>
Message-ID: <20090704092429.GG28952@prithivi.gnumonks.org>

On Fri, Jul 03, 2009 at 03:20:37PM +0200, Nordin wrote:
> Hi guys,
>
> A git-beginner's question, I installed git on my Debian, and when trying  
> to checkout OpenBSC project as suggested on the website:
>
> "git clone git://bs11-abis.gnumonks.org/openbsc.git"
>
> it somehow hangs at:
> "Initialized empty Git repository in /home/nordin/Development/CProjects/openbsc/.git/"
>
> Am I missing a step or is there something wrong with the git-repository or
> something?

are you sure port 9418 (tcp) is allowed for outbound connections?

-- 
- 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 Jul  6 07:35:16 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Mon, 06 Jul 2009 09:35:16 +0200
Subject: Downloading source project
In-Reply-To: <20090704092429.GG28952@prithivi.gnumonks.org>
References: <4a4e154a.mirider@mirider.augusta.de> <4A4E05A5.6010408@gmail.com>
	<20090704092429.GG28952@prithivi.gnumonks.org>
Message-ID: <4A51A934.2080004@gmail.com>


> are you sure port 9418 (tcp) is allowed for outbound connections?
>   

Funny, while I was bringing my kids to school in the morning, suddenly 
it came up in my mind that our company's firewall blocks almost all 
ports to the outside world, except port 80 and a few others. I totally 
forgot that, sorry :)

Thank you for remind me anyway.




From zecke at selfish.org  Mon Jul  6 14:15:24 2009
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 6 Jul 2009 16:15:24 +0200
Subject: Downloading source project
In-Reply-To: <4A51A934.2080004@gmail.com>
References: <4a4e154a.mirider@mirider.augusta.de>
	<20090704092429.GG28952@prithivi.gnumonks.org>
	<4A51A934.2080004@gmail.com>
Message-ID: <200907061615.24705.zecke@selfish.org>

On Monday 06 July 2009 09:35:16 Nordin wrote:
> > are you sure port 9418 (tcp) is allowed for outbound connections?
>
> Funny, while I was bringing my kids to school in the morning, suddenly
> it came up in my mind that our company's firewall blocks almost all
> ports to the outside world, except port 80 and a few others. I totally
> forgot that, sorry :)

You can go to repo.or.cz and ask them to clone the OpenBSC git repository and 
then clone using http.

z.



From spaar at mirider.augusta.de  Sat Jul  4 11:41:52 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Sat, 04 Jul 2009 11:41:52 CEST
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
Message-ID: <4a4f4001.mirider@mirider.augusta.de>

Hello Nordin,

On Fri, 03 Jul 2009 14:44:50 +0200, "Nordin" <bouchtaoui at gmail.com> wrote:
> 
> I hope this will at least try to do a LOCATION UPDATE REQUEST.
> But it suprises me that older mobilephones don't care about SI 1 (and 
> maybe more information on the BCCH) and just try to register whatever in 
> the BCCH is.

I have further investigated the problem. Besides the fact that
the channel allocation in SYSTEM INFORMATION 1 is not correct
for GSM 1800, this is probably not the reason for the problem.

Most certainly its just one wrong bit, the GPRS indicator in
the SYSTEM INFORMATION 3 rest octets.

The current setting is

   0x80, 0x00, 0x00, 0x2B

but it should be

   0x80, 0x00, 0x08, 0x2B

What might lead to some confusion is the meaning of "L" and "H" in
the specification of CSN.1. For the rest octets the bit value is
determined by a comparsion (XOR) to the padding byte 0x2B. So the
value 0x08 above actually means "L" for the GPRS indicator, which
means "No GPRS".

Its seem that some phones are really sensible to this setting, some
other GPRS capable phones just don't care and register to the
network even if there is no GPRS.

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



From laforge at gnumonks.org  Sun Jul  5 02:42:20 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 5 Jul 2009 04:42:20 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <4a4f4001.mirider@mirider.augusta.de>
References: <4a4f4001.mirider@mirider.augusta.de>
Message-ID: <20090705024220.GE4379@prithivi.gnumonks.org>

Hi Dieter,

thanks for further looking into this.

On Sat, Jul 04, 2009 at 11:41:52AM +0200, Dieter Spaar wrote:

> I have further investigated the problem. Besides the fact that
> the channel allocation in SYSTEM INFORMATION 1 is not correct
> for GSM 1800, this is probably not the reason for the problem.
> 
> Most certainly its just one wrong bit, the GPRS indicator in
> the SYSTEM INFORMATION 3 rest octets.
> 
> The current setting is
> 
>    0x80, 0x00, 0x00, 0x2B
> 
> but it should be
> 
>    0x80, 0x00, 0x08, 0x2B
> 
> What might lead to some confusion is the meaning of "L" and "H" in
> the specification of CSN.1. For the rest octets the bit value is
> determined by a comparsion (XOR) to the padding byte 0x2B. So the
> value 0x08 above actually means "L" for the GPRS indicator, which
> means "No GPRS".

where did you find this XOR?  I just searched through 04.07 and 04.08 and
didn't find any indication thereof.  Sure, the padding bit sequence ix 0x2b, so
all spare bits have to be padded with that.   But where did you get the XOR
from?

Also, this would mean that if we put explicitly 0x2b into the padding of
our messages, then it would result in all-zero 0x00 on the air, since

0x2b xor 0x2b == 0x00

I'm now looking at an actual abis trace from a production cell with GPRS
enabled, and it has

"0x80, 0x00, 0x80, 0x0b"

as SI3 rest octets.

During early start of the BTS, SI3 rest octets are set to 

"0x80, 0x00, 0x83, 0x2b"

Maybe that helps

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 Jul  6 07:53:08 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Mon, 06 Jul 2009 09:53:08 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <20090705024220.GE4379@prithivi.gnumonks.org>
References: <4a4f4001.mirider@mirider.augusta.de>
	<20090705024220.GE4379@prithivi.gnumonks.org>
Message-ID: <4A51AD64.30305@gmail.com>

Hi guys,

I also figured that out and played with the Rest Octets of SI 3, but 
with no succes.
It's true what you said about the Rest Octets Dieter, and it took me 
some time to figure that out for me Harald.

Wether the result is L or H depends on the result of the tested bit 
XOR'ed with the bit which is part of the value 0x2B. So actually you 
should XOR all octets with 0x2B (but only for those who expect an H or L 
as result). This value is not just a random, it is also specified by the 
CSN.1 standard. It would be much clearer if GSM spec put an example and 
not some abstract description which kills my braincells.

Anyway, I'll try your Rest Octets examples, maybe it helps for me. 
Concerning the SI 1, I modified the Cell Channel Description of the SI 1 
myself, according to the DCS1800 standard, but turns out it didn't work 
for me. I assume SI 1 is hardcoded ofcourse.

Harald Welte schreef:
> Hi Dieter,
>
> thanks for further looking into this.
>
> On Sat, Jul 04, 2009 at 11:41:52AM +0200, Dieter Spaar wrote:
>
>   
>> I have further investigated the problem. Besides the fact that
>> the channel allocation in SYSTEM INFORMATION 1 is not correct
>> for GSM 1800, this is probably not the reason for the problem.
>>
>> Most certainly its just one wrong bit, the GPRS indicator in
>> the SYSTEM INFORMATION 3 rest octets.
>>
>> The current setting is
>>
>>    0x80, 0x00, 0x00, 0x2B
>>
>> but it should be
>>
>>    0x80, 0x00, 0x08, 0x2B
>>
>> What might lead to some confusion is the meaning of "L" and "H" in
>> the specification of CSN.1. For the rest octets the bit value is
>> determined by a comparsion (XOR) to the padding byte 0x2B. So the
>> value 0x08 above actually means "L" for the GPRS indicator, which
>> means "No GPRS".
>>     
>
> where did you find this XOR?  I just searched through 04.07 and 04.08 and
> didn't find any indication thereof.  Sure, the padding bit sequence ix 0x2b, so
> all spare bits have to be padded with that.   But where did you get the XOR
> from?
>
> Also, this would mean that if we put explicitly 0x2b into the padding of
> our messages, then it would result in all-zero 0x00 on the air, since
>
> 0x2b xor 0x2b == 0x00
>
> I'm now looking at an actual abis trace from a production cell with GPRS
> enabled, and it has
>
> "0x80, 0x00, 0x80, 0x0b"
>
> as SI3 rest octets.
>
> During early start of the BTS, SI3 rest octets are set to 
>
> "0x80, 0x00, 0x83, 0x2b"
>
> Maybe that helps
>
> Regards,
>   




From bouchtaoui at gmail.com  Mon Jul  6 10:00:27 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Mon, 06 Jul 2009 12:00:27 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <20090705122827.GC4886@prithivi.gnumonks.org>
References: <4a4f4001.mirider@mirider.augusta.de>
	<20090705024220.GE4379@prithivi.gnumonks.org>
	<7866E4D0-50AD-44E7-AB03-40BD13F2BAEB@jcis.net>
	<20090705122827.GC4886@prithivi.gnumonks.org>
Message-ID: <4A51CB3B.4070701@gmail.com>

I tried the parameters as you suggested for SI 1 as well as SI3, but 
with no success. But I'm still curious if someone else on the list 
registered a PDA-like mobilephone (with GPRS support) to his BTS 
(BS11/nanoBTS1800). If so, I would like to try out his/her SI's settings.

I still don't have the latest version as at the moment our firewall 
doesn't allow to (I ask the networkadmin later for that).




From spaar at mirider.augusta.de  Sun Jul  5 08:40:55 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Sun, 05 Jul 2009 08:40:55 CEST
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
Message-ID: <4a506717.mirider@mirider.augusta.de>

Hello Harald,

On Sun, 5 Jul 2009 04:42:20 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> 
> where did you find this XOR?  I just searched through 04.07 and 04.08 and
> didn't find any indication thereof.  Sure, the padding bit sequence ix 0x2b, so
> all spare bits have to be padded with that.   But where did you get the XOR
> from?

I started to search deeper because I was a bit confused how the Message
Decoding Tool from Joachim Goeller interpreted the rest octets. I looked
at some phone firmware how they do it and found it there. Later I also
found a good explanation at http://csn1.info (they sell a tool which
can be used to generate message parsing source code for various
specifications).

> Also, this would mean that if we put explicitly 0x2b into the padding of
> our messages, then it would result in all-zero 0x00 on the air, since
> 
> 0x2b xor 0x2b == 0x00

The XOR is actually only used for "L" and "H", basically it means that
if a bit at an "L"/"H" position is different from the padding sequence,
its an "H". At least this is how I understand it.

> I'm now looking at an actual abis trace from a production cell with GPRS
> enabled, and it has
> 
> "0x80, 0x00, 0x80, 0x0b"

Here is how I would interpret it according to GSM 04.08, 10.5.2.34:

  Selection Parameter:

   byte 0: 0x80 ^ 0x2B = 0xAB, (bit 7) -> H  (15 bits for parameter follow)

  Power Offset:

   byte 2: 0x80 ^ 0x2B = 0xAB, (bit 7) -> H  ( 2 bits for parameter follow)

  System Information 2ter Indicator:

   byte 2: 0x80 ^ 0x2B = 0xAB, (bit 4) -> L  (has no parameters)

  Early Classmark Sending Control:

   byte 2: 0x80 ^ 0x2B = 0xAB, (bit 3) -> H  (has no parameters)

  Scheduling if and where:

   byte 2: 0x80 ^ 0x2B = 0xAB, (bit 2) -> L

  GPRS Indicator:

   byte 2: 0x80 ^ 0x2B = 0xAB, (bit 1) -> H ( 4 bits for parameter follow)

> During early start of the BTS, SI3 rest octets are set to 
> 
> "0x80, 0x00, 0x83, 0x2b"

The only difference is that at this stage GPRS is not yet set:

  GPRS Indicator:

   byte 2: 0x83 ^ 0x2B = 0xA8, (bit 1) -> L

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



From laforge at gnumonks.org  Sun Jul  5 08:48:52 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 5 Jul 2009 10:48:52 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <4a506717.mirider@mirider.augusta.de>
References: <4a506717.mirider@mirider.augusta.de>
Message-ID: <20090705084852.GF4379@prithivi.gnumonks.org>

Hi Dieter,

On Sun, Jul 05, 2009 at 08:40:55AM +0200, Dieter Spaar wrote:

> I started to search deeper because I was a bit confused how the Message
> Decoding Tool from Joachim Goeller interpreted the rest octets. I looked
> at some phone firmware how they do it and found it there. Later I also
> found a good explanation at http://csn1.info (they sell a tool which
> can be used to generate message parsing source code for various
> specifications).

ok, thanks. I've now started to write some utility functions for encoding
the bits according to this.  When it's finished, it will become part of the
system_information branch.

I'll post to the list again once that is finished.

-- 
- 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  Sun Jul  5 12:15:39 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 5 Jul 2009 14:15:39 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <4a506717.mirider@mirider.augusta.de>
References: <4a506717.mirider@mirider.augusta.de>
Message-ID: <20090705121539.GB4886@prithivi.gnumonks.org>

As a quick work-around, I have replaced all SI3 and SI4 rest octet bytes
with the padding sequence 0x2B.  This should make OpenBSC more friendly towards
GPRS phones.
-- 
- 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 Jul  6 15:38:50 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Mon, 06 Jul 2009 15:38:50 CEST
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
Message-ID: <4a521a8a.mirider@mirider.augusta.de>

Hello Nordin,

On Mon, 06 Jul 2009 12:00:27 +0200, "Nordin" <bouchtaoui at gmail.com> wrote:
>
> I tried the parameters as you suggested for SI 1 as well as SI3, but 
> with no success. But I'm still curious if someone else on the list 
> registered a PDA-like mobilephone (with GPRS support) to his BTS 
> (BS11/nanoBTS1800). If so, I would like to try out his/her SI's settings.
> 

With the modification I have sent I can register a HTC Touch Pro to
the BS11 and the nanoBTS 1800. If GPRS is set in SYSTEM INFORMATION 3,
the phone will not register.

The process is a bit unstable, if the phone is powered on, the
location update works as expected, if I try to register manually,
it sometime fails without actually communication with the BTS.
I don't know the reason for this behaviour yet.

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



From bouchtaoui at gmail.com  Tue Jul  7 12:08:22 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Tue, 07 Jul 2009 14:08:22 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <4a521a8a.mirider@mirider.augusta.de>
References: <4a521a8a.mirider@mirider.augusta.de>
Message-ID: <4A533AB6.4090708@gmail.com>


> With the modification I have sent I can register a HTC Touch Pro to
> the BS11 and the nanoBTS 1800. If GPRS is set in SYSTEM INFORMATION 3,
> the phone will not register.
>
> The process is a bit unstable, if the phone is powered on, the
> location update works as expected, if I try to register manually,
> it sometime fails without actually communication with the BTS.
> I don't know the reason for this behaviour yet.

I have good news now, I'm able to register to our bts manually. What I 
did is download the latest openbsc sources and compiled the whole 
project, that's it. I downloaded the project using git via port 80, I 
posted a mail about that. So I guess the GPRS in the Rest Octets have 
nothing to do, just the SIs were not complete. I'll analyze what went 
wrong with the SIs.

Oooh I forgot to mention that I use HTC Artemis (3030 I guess).




From spaar at mirider.augusta.de  Tue Jul  7 15:35:31 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Tue, 07 Jul 2009 15:35:31 CEST
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
Message-ID: <4a536b43.mirider@mirider.augusta.de>

Hello Nordin,

On Tue, 07 Jul 2009 14:08:22 +0200, "Nordin" <bouchtaoui at gmail.com> wrote:
> 
> I have good news now, I'm able to register to our bts manually. What I 
> did is download the latest openbsc sources and compiled the whole 
> project, that's it. I downloaded the project using git via port 80, I 
> posted a mail about that. So I guess the GPRS in the Rest Octets have 
> nothing to do, just the SIs were not complete. I'll analyze what went 
> wrong with the SIs.

You don't mention which git branch you use, so its probably the
master branch. If you look at the recent changes you will notice
that the SYSTEM INFORMATION 3 and 4 rest octets are now set to the
padding bytes which means they contain no information (which also
means no GPRS). So this is the most important part where you have
to look for differences.

I can confirm that a HTC Touch Pro will not register to the BTS
if the GPRS indication is set, it will register if it is not set.

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



From bouchtaoui at gmail.com  Tue Jul  7 14:31:36 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Tue, 07 Jul 2009 16:31:36 +0200
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
In-Reply-To: <4a536b43.mirider@mirider.augusta.de>
References: <4a536b43.mirider@mirider.augusta.de>
Message-ID: <4A535C48.3050105@gmail.com>


> You don't mention which git branch you use, so its probably the
> master branch.

I guess it is the master branch, but I'm totally new to git, so it must 
be a default thing. Though I'm new to git, I must say I really like it.

> If you look at the recent changes you will notice
> that the SYSTEM INFORMATION 3 and 4 rest octets are now set to the
> padding bytes which means they contain no information (which also
> means no GPRS). So this is the most important part where you have
> to look for differences.
>   

The funny thing is, I really thought I already tested that using these 
settings (putting rest octets to 0x2b). But now I'm not sure anymore. 
Anyway, I hope I can confirm that  before the end of today.

> I can confirm that a HTC Touch Pro will not register to the BTS
> if the GPRS indication is set, it will register if it is not set.
>   

I believe you.
But this means that your HTC needs more relevant GPRS settings before 
deciding to register. So it than searches for altenatives, but since the 
BA list is empty it starts all over again and the whole process repeats, 
which might result in a long procedure before it gives up. This is what 
it might could be the reason, I'm not sure.
Also that the HTC (and maybe other PDA phones) makes a distinction 
between BSS with GPRS support and BTS without GPRS support for its own 
selection behaviour. With GPRS support there is another step before 
registering process, while without GPRS support that step is skipped. 
Nice challenge to figure that out.






From zero-kelvin at gmx.de  Sun Jul 26 19:43:22 2009
From: zero-kelvin at gmx.de (dexter)
Date: Sun, 26 Jul 2009 21:43:22 +0200
Subject: Dummy load / direct wire connection concept
In-Reply-To: <4a536b43.mirider@mirider.augusta.de>
References: <4a536b43.mirider@mirider.augusta.de>
Message-ID: <4A6CB1DA.6000901@gmx.de>

Hi folks,

In order that a rogue GSM-BTS can cause a lot of trouble with the 
regulation offices there is a need for a dummyload solution.

I have 2 ideas in mind:

The first one uses attenuators to set up a direct wired connection:
http://root.runningserver.com/pub/desktop-gsm1.png

The second one uses parasitic coupeling in a shilded box:
http://root.runningserver.com/pub/desktop-gsm2.png

The second solution in my opinion the most save one because the BTS does 
not send directly in its own receiver as well as the MS do not send 
directly into the BTS. But i also think that this solution is too 
crappy, i think there must be a more accurate way.

The first solution fullfilly my demands in accurateness. The impedance 
is 50 Ohms and attenuators ensure that the signal that is transmitted 
between two points are attenuated enough - in theory...

I have no experience in those things, i never connected a sender and a 
receiver directly for measurement proposes. I am afraid to damage BTS 
and/or MS by trying the first solution.

What do you think, what would you do? How do you ensure that you do not 
interfere with the with the official GSM networks? I think sometimes it 
would be very nice to make 100% sure that no HF signals leave the desktop.

PS: One of my inspirations: http://www.comlab.hut.fi/Resources/GSM.html

regards.
Philipp





From bouchtaoui at gmail.com  Mon Jul 27 07:23:12 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Mon, 27 Jul 2009 09:23:12 +0200
Subject: Dummy load / direct wire connection concept
In-Reply-To: <4A6CB1DA.6000901@gmx.de>
References: <4a536b43.mirider@mirider.augusta.de> <4A6CB1DA.6000901@gmx.de>
Message-ID: <4A6D55E0.1040806@gmail.com>

Damn, your lab has serious equipment man!
Wow! I mean, cool! :)


dexter schreef:
> Hi folks,
>
> In order that a rogue GSM-BTS can cause a lot of trouble with the 
> regulation offices there is a need for a dummyload solution.
>
> I have 2 ideas in mind:
>
> The first one uses attenuators to set up a direct wired connection:
> http://root.runningserver.com/pub/desktop-gsm1.png
>
> The second one uses parasitic coupeling in a shilded box:
> http://root.runningserver.com/pub/desktop-gsm2.png
>
> The second solution in my opinion the most save one because the BTS 
> does not send directly in its own receiver as well as the MS do not 
> send directly into the BTS. But i also think that this solution is too 
> crappy, i think there must be a more accurate way.
>
> The first solution fullfilly my demands in accurateness. The impedance 
> is 50 Ohms and attenuators ensure that the signal that is transmitted 
> between two points are attenuated enough - in theory...
>
> I have no experience in those things, i never connected a sender and a 
> receiver directly for measurement proposes. I am afraid to damage BTS 
> and/or MS by trying the first solution.
>
> What do you think, what would you do? How do you ensure that you do 
> not interfere with the with the official GSM networks? I think 
> sometimes it would be very nice to make 100% sure that no HF signals 
> leave the desktop.
>
> PS: One of my inspirations: http://www.comlab.hut.fi/Resources/GSM.html
>
> regards.
> Philipp
>
>
>
>




From zero-kelvin at gmx.de  Wed Jul 29 20:12:08 2009
From: zero-kelvin at gmx.de (dexter)
Date: Wed, 29 Jul 2009 22:12:08 +0200
Subject: Dummy load / direct wire connection concept
In-Reply-To: <4A6D55E0.1040806@gmail.com>
References: <4a536b43.mirider@mirider.augusta.de> <4A6CB1DA.6000901@gmx.de>
	<4A6D55E0.1040806@gmail.com>
Message-ID: <4A70AD18.8070807@gmx.de>

Hi Nordin.
> Damn, your lab has serious equipment man!
> Wow! I mean, cool! :)
I am not from comlab ;-) I am from the CCCB backyard-lab ;-)

regards.
Philipp



From spaar at mirider.augusta.de  Mon Jul 27 09:32:00 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Mon, 27 Jul 2009 09:32:00 CEST
Subject: Dummy load / direct wire connection concept
Message-ID: <4a6d7410.mirider@mirider.augusta.de>

Hello Philipp,

On Sun, 26 Jul 2009 21:43:22 +0200, "dexter" <zero-kelvin at gmx.de> wrote:
> 
> I have no experience in those things, i never connected a sender and a 
> receiver directly for measurement proposes. I am afraid to damage BTS 
> and/or MS by trying the first solution.

If you want to connect the BTS and an MS directly, you have to use
an attenuator to reduce the signal to some "reasonable" level. To
give you some numbers about "reasonable": The maximum RF output level
of two different GSM tester which are intended for direct connection
to an MS are -14 dBm for one of them and -40 dBm for the other. To be
on the safe side I would make sure that the level is below -40 dBm,
this is more than enough for good receiption (poor receiption is around
-100 dBm). If the signal is too strong, you can damage the MS and/or BTS.
Please note that I have not tried to connect a BTS and an MS yet, my
experience comes from the GSM testers only.

One problem I see with this approach is how to handle the separate
RX and TX connectors of the BS-11.

> What do you think, what would you do? How do you ensure that you do not 
> interfere with the with the official GSM networks? I think sometimes it 
> would be very nice to make 100% sure that no HF signals leave the desktop.

I you can't make sure that no RF signal is emitted, you can at least try
to cause as little trouble as possible:

  - use a GSM channel which is not used by an official network, make sure
    that there is at least one free guard channel in between the channel
    you use and the official channels.

  - set the power level of the BTS to its minimum (0.03 Watt for the BS-11)
    and set the NM_ATT_RF_MAXPOWR_R attribute to its maximum (6 for the
    BS-11). For the BS-11 the RF output level should then be around 1 dBm.

  - If you want to further reduce the BTS power, you can put an attenuator
    between antenna and TX output.

  - for the MS make sure that the power class is as low as possible when
    activatig a channel.

  - set the power for RACH access to a low level (in SYSTEM INFORMATION
    TYPE 3 and 4).

  - use an MCC and MNC which is not an official one.

  - only allow a know MS to register on your network.

  - To make sure that normal MSs won't be able to see your network,
    you can set the cell to "barred". However you then need a special
    MS to test, for example the Nokia Network Monitor allows to
    set the MS in a mode which allows to access barred cells. And
    with a special Test SIM it should be possible to access such
    a cell with other phones too (the "cell test" operation mode
    has to be enabled on the SIM).

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



From zero-kelvin at gmx.de  Wed Jul 29 20:08:55 2009
From: zero-kelvin at gmx.de (dexter)
Date: Wed, 29 Jul 2009 22:08:55 +0200
Subject: Dummy load / direct wire connection concept
In-Reply-To: <4a6d7410.mirider@mirider.augusta.de>
References: <4a6d7410.mirider@mirider.augusta.de>
Message-ID: <4A70AC57.2020606@gmx.de>

Hi Dieter.
> If you want to connect the BTS and an MS directly, you have to use
> an attenuator to reduce the signal to some "reasonable" level. To
> give you some numbers about "reasonable": The maximum RF output level
> of two different GSM tester which are intended for direct connection
> to an MS are -14 dBm for one of them and -40 dBm for the other. To be
> on the safe side I would make sure that the level is below -40 dBm,
> this is more than enough for good receiption (poor receiption is around
> -100 dBm). If the signal is too strong, you can damage the MS and/or BTS.
> Please note that I have not tried to connect a BTS and an MS yet, my
> experience comes from the GSM testers only.
>   
Good to know. Maybe this helps to calculate the attenuation rates.
> One problem I see with this approach is how to handle the separate
> RX and TX connectors of the BS-11.
>   
Where is the problem? RX and TX are connected over at least one attenuator.

> I you can't make sure that no RF signal is emitted, you can at least try
> to cause as little trouble as possible:
>   
I know that but i would sleep much better if BTS and MS were connected 
directly by a shielded cable. The network operators will not accept a 
pirate signal even if it causes no harmful effects to the network.

There is another problem that comes in my mind: I don't think that every 
MS will have 50 Ohms impedance on its antenna connection. There might be 
any impedance since an MS is normaly not made for beeing connected to 
external antennas/cabeling ect...

I think i will try the second way first because there is nothing that 
can go wrong. The only risk it that it does not work, but it can not 
damage the BTS or MS.

regards.
Philipp



From spaar at mirider.augusta.de  Tue Jul  7 17:17:15 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Tue, 07 Jul 2009 17:17:15 CEST
Subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
Message-ID: <4a53831b.mirider@mirider.augusta.de>

Hello Nordin,

On Tue, 07 Jul 2009 16:31:36 +0200, "Nordin" <bouchtaoui at gmail.com> wrote:
> 
> But this means that your HTC needs more relevant GPRS settings before 
> deciding to register. So it than searches for altenatives, but since the 
> BA list is empty it starts all over again and the whole process repeats, 
> which might result in a long procedure before it gives up. This is what 
> it might could be the reason, I'm not sure.

If the GPRS Indicator is set, SYSTEM INFORMATION 13 is needed to
describe the GPRS properties. But SYSTEM INFORMATION 13 is not set
yet (not possible for the BS-11 anyway) so the phone won't find it.
Probably some phones don't care about it but some others insist to
find it before going to register.

This is probably one of the many places where there is no rule in
the specification what should be done in such a situation so its
up to the developer of the firmware (the phone could register and
return an error only when GPRS is actually needed for a data
connection). Of course I don't mean that the specification is
incomplete, it just expects that certain things are done "right"
(who would expect that people outside of the mobile phone industry
play with a BTS ;-).

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



From laforge at gnumonks.org  Sat Jul  4 09:19:23 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 4 Jul 2009 11:19:23 +0200
Subject: updated wireshark patches / call for help
In-Reply-To: <200906280307.02081.holger@freyther.de>
References: <20090625190051.GM26626@prithivi.gnumonks.org>
	<200906280307.02081.holger@freyther.de>
Message-ID: <20090704091923.GE28952@prithivi.gnumonks.org>

On Sun, Jun 28, 2009 at 03:07:01AM +0200, Holger Hans Peter Freyther wrote:
> 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 

Ah, thanks, will look at that one.

> 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?

Yes, this would be a different but related issue.

-- 
- 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  Sat Jul  4 09:06:53 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 4 Jul 2009 11:06:53 +0200
Subject: Patch 40 (Re: abnormal channel release)
In-Reply-To: <200906291457.16183.holger@freyther.de>
References: <B16317F2B1592B4492FC414114171CE69FE98D@FLBVEXCH01.versatel.local>
	<200906291457.16183.holger@freyther.de>
Message-ID: <20090704090653.GB28952@prithivi.gnumonks.org>

Hi all
On Mon, Jun 29, 2009 at 02:57:16PM +0200, Holger Hans Peter Freyther wrote:
> 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.

I've applied this as a single commit now.

> 2.) static int rsl_rx_rll_err_ind(struct msgb *msg) 

I've modified it to check for the cause, i.e. only release the channel
in case T200 is expired.  I'm not sure if we need to give up that quickly on
other types of error indications.

> 3.) Explain why 
> 
> +//                     if (msg->lchan->use_count > 0) {
> +//                     }
> 
> is a good change and should be applied?

done, too.

-- 
- 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  Sat Jul  4 08:29:09 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 4 Jul 2009 10:29:09 +0200
Subject: patches again
In-Reply-To: <B16317F2B1592B4492FC414114171CE69FF191@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE69FF191@FLBVEXCH01.versatel.local>
Message-ID: <20090704082909.GA28952@prithivi.gnumonks.org>

On Mon, Jun 29, 2009 at 11:37:51PM +0200, Andreas.Eversberg wrote:

> 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:

Ok, great, thanks for testing.  I've committed this change to git just 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)



From laforge at gnumonks.org  Sat Jul  4 09:12:11 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 4 Jul 2009 11:12:11 +0200
Subject: patch 43 (Re: patches again)
In-Reply-To: <B16317F2B1592B4492FC414114171CE69FE98D@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE69FE98D@FLBVEXCH01.versatel.local>
Message-ID: <20090704091211.GC28952@prithivi.gnumonks.org>

 
> patch 43: this small fix will not check for given subscriber/imsi here.
> this is already done in the next "if"-condition.

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 laforge at gnumonks.org  Thu Jul  2 04:45:48 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 2 Jul 2009 06:45:48 +0200
Subject: Cleanup some parsing in the mncc.c code
In-Reply-To: <200906291727.29186.zecke@selfish.org>
References: <200906291727.29186.zecke@selfish.org>
Message-ID: <20090702044548.GB32676@prithivi.gnumonks.org>

Hi Holger,
On Mon, Jun 29, 2009 at 05:27:28PM +0200, Holger Freyther wrote:
 
> did you have this in mind when mentioning that the parsing of the data derived 
> informations could be driven by a struct?

yes, I had something like this in mind.  It somehow reduces the readability
of the code to those not familiar with this decoding scheme,  but well, it reduces
the number of lines quite significantly on the other side.

Also:

> +	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);

the parser[] arrays can and should be marked as const, I believe.  Also,
maybe another step of indirection, i.e. have the dd_parser[] structure static
const but global for all IE, and then list in every function which IE's it
expects to parse.

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  Fri Jul 10 17:08:40 2009
From: zecke at selfish.org (Holger Freyther)
Date: Fri, 10 Jul 2009 19:08:40 +0200
Subject: Cleanup some parsing in the mncc.c code
In-Reply-To: <20090702044548.GB32676@prithivi.gnumonks.org>
References: <200906291727.29186.zecke@selfish.org>
	<20090702044548.GB32676@prithivi.gnumonks.org>
Message-ID: <200907101908.41593.zecke@selfish.org>

On Thursday 02 July 2009 06:45:48 Harald Welte wrote:
> Hi Holger,
>
> On Mon, Jun 29, 2009 at 05:27:28PM +0200, Holger Freyther wrote:
> > did you have this in mind when mentioning that the parsing of the data
> > derived informations could be driven by a struct?
>
> yes, I had something like this in mind.  It somehow reduces the readability
> of the code to those not familiar with this decoding scheme,  but well, it
> reduces the number of lines quite significantly on the other side.


A revised patch. I have moved the struct with all known parsers to one place, 
created an enum of known decoders... I think this an improvement over the 
previous patch but we are not there yet.

Things that I think I should do:
	- Maybe nuke the PARSE_FLAG and flag attribute? If we get a response that 
contains an attribute that should not be there our tlvp_parse will have 
already parsed it. Does it hurt to copy the value to the gsm_mncc? In one way 
we would like to be strict, in another it can be nice to see what incorrect 
messages we receive?

        - Kill the enum with the PARSE_ flags, I can use the MNCC ones 
directly..


comments are more than welcome
	z.


From 47f155d62b41df0bcd94c610617d39f9eb678f57 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...

Parse everything that was found during the tlvp_parse and
assign it to members of the gsm_mncc. This would even parse
elements that are not present/part of the specification.
---
 openbsc/src/msc_mncc.c |  304 
++++++++++++++----------------------------------
 1 files changed, 85 insertions(+), 219 deletions(-)

diff --git a/openbsc/src/msc_mncc.c b/openbsc/src/msc_mncc.c
index 90354c0..3dcb6a0 100644
--- a/openbsc/src/msc_mncc.c
+++ b/openbsc/src/msc_mncc.c
@@ -587,6 +587,67 @@ static int encode_more(struct msgb *msg)
 	return 0;
 }
 
+#define DECLARE_DECODER3(IE_NAME, M_NAME, name) \
+	[PARSE_##M_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)
+
+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;
+};
+
+enum {
+	PARSE_CAUSE,
+	PARSE_FACILITY,
+	PARSE_USERUSER,
+	PARSE_SSVERSION,
+	PARSE_KEYPAD,
+	PARSE_BEARER_CAP,
+	PARSE_CALLED,
+	PARSE_CCCAP,
+	PARSE_PROGRESS,
+	PARSE_LAST_ITEM,
+};
+
+#define PARSE_FLAG(flag) (1<<PARSE_##flag)
+
+static const struct dd_parser dd_parsers [PARSE_LAST_ITEM] = {
+	DECLARE_DECODER(CAUSE, cause),
+	DECLARE_DECODER(FACILITY, facility),
+	DECLARE_DECODER3(USER_USER, USERUSER, useruser),
+	DECLARE_DECODER3(SS_VERS, SSVERSION, ssversion),
+	DECLARE_DECODER3(KPD_FACILITY, KEYPAD, keypad),
+	DECLARE_DECODER(BEARER_CAP, bearer_cap),
+	DECLARE_DECODER3(CALLED_BCD, CALLED, called),
+	DECLARE_DECODER3(CC_CAP, CCCAP, cccap),
+	DECLARE_DECODER3(PROGR_IND, PROGRESS, progress),
+};
+
+static void parse_data_derived_information(struct tlv_parsed *tp, struct 
gsm_mncc *rel, int flags)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(dd_parsers); ++i) {
+		if (flags & (1<<i) == (1<<i) && TLVP_PRESENT(tp, 
dd_parsers[i].information_element)) {
+			rel->fields |= dd_parsers[i].mncc_field;
+			dd_parsers[i].decoder(rel + dd_parsers[i].offset,
+					      TLVP_VAL(tp, dd_parsers[i].information_element)-1);
+		}
+	}
+}
+
+
 /* map two ipaccess RTP streams onto each other */
 static int tch_map(struct gsm_lchan *lchan, struct gsm_lchan *remote_lchan)
 {
@@ -1013,48 +1074,16 @@ static int msc_cc_rx_setup(struct gsm_trans *trans, 
struct msgb *msg)
 		strncpy(setup.imsi, trans->subscr->imsi,
 			sizeof(setup.imsi)-1);
 	}
-	/* bearer capability */
-	if (TLVP_PRESENT(&tp, GSM48_IE_BEARER_CAP)) {
-		setup.fields |= MNCC_F_BEARER_CAP;
-		decode_bearer_cap(&setup.bearer_cap,
-				  TLVP_VAL(&tp, GSM48_IE_BEARER_CAP)-1);
-	}
-	/* facility */
-	if (TLVP_PRESENT(&tp, GSM48_IE_FACILITY)) {
-		setup.fields |= MNCC_F_FACILITY;
-		decode_facility(&setup.facility,
-				TLVP_VAL(&tp, GSM48_IE_FACILITY)-1);
-	}
-	/* called party bcd number */
-	if (TLVP_PRESENT(&tp, GSM48_IE_CALLED_BCD)) {
-		setup.fields |= MNCC_F_CALLED;
-		decode_called(&setup.called,
-			      TLVP_VAL(&tp, GSM48_IE_CALLED_BCD)-1);
-	}
-	/* user-user */
-	if (TLVP_PRESENT(&tp, GSM48_IE_USER_USER)) {
-		setup.fields |= MNCC_F_USERUSER;
-		decode_useruser(&setup.useruser,
-				TLVP_VAL(&tp, GSM48_IE_USER_USER)-1);
-	}
-	/* ss-version */
-	if (TLVP_PRESENT(&tp, GSM48_IE_SS_VERS)) {
-		setup.fields |= MNCC_F_SSVERSION;
-		decode_ssversion(&setup.ssversion,
-				 TLVP_VAL(&tp, GSM48_IE_SS_VERS)-1);
-	}
+
+	parse_data_derived_information(&tp, &setup, PARSE_FLAG(BEARER_CAP) | 
PARSE_FLAG(FACILITY) |
+					PARSE_FLAG(CALLED) | PARSE_FLAG(USERUSER) | PARSE_FLAG(SSVERSION) );
+
 	/* CLIR suppression */
 	if (TLVP_PRESENT(&tp, GSM48_IE_CLIR_SUPP))
 		setup.clir.sup = 1;
 	/* CLIR invocation */
 	if (TLVP_PRESENT(&tp, GSM48_IE_CLIR_INVOC))
 		setup.clir.inv = 1;
-	/* cc cap */
-	if (TLVP_PRESENT(&tp, GSM48_IE_CC_CAP)) {
-		setup.fields |= MNCC_F_CCCAP;
-		decode_cccap(&setup.cccap,
-			     TLVP_VAL(&tp, GSM48_IE_CC_CAP)-1);
-	}
 
 	if (is_ipaccess_bts(msg->trx->bts))
 		rsl_ipacc_bind(msg->lchan);
@@ -1171,24 +1200,9 @@ static int msc_cc_rx_call_conf(struct gsm_trans *trans, 
struct msgb *msg)
 	if (TLVP_PRESENT(&tp, GSM48_IE_REPEAT_SEQ))
 		call_conf.repeat = 2;
 #endif
-	/* bearer capability */
-	if (TLVP_PRESENT(&tp, GSM48_IE_BEARER_CAP)) {
-		call_conf.fields |= MNCC_F_BEARER_CAP;
-		decode_bearer_cap(&call_conf.bearer_cap,
-				  TLVP_VAL(&tp, GSM48_IE_BEARER_CAP)-1);
-	}
-	/* cause */
-	if (TLVP_PRESENT(&tp, GSM48_IE_CAUSE)) {
-		call_conf.fields |= MNCC_F_CAUSE;
-		decode_cause(&call_conf.cause,
-			     TLVP_VAL(&tp, GSM48_IE_CAUSE)-1);
-	}
-	/* cc cap */
-	if (TLVP_PRESENT(&tp, GSM48_IE_CC_CAP)) {
-		call_conf.fields |= MNCC_F_CCCAP;
-		decode_cccap(&call_conf.cccap,
-			     TLVP_VAL(&tp, GSM48_IE_CC_CAP)-1);
-	}
+
+	parse_data_derived_information(&tp, &call_conf, PARSE_FLAG(BEARER_CAP) | 
PARSE_FLAG(CAUSE) |
+				       PARSE_FLAG(CCCAP));
 
 	new_cc_state(trans, GSM_CSTATE_MO_TERM_CALL_CONF);
 
@@ -1233,25 +1247,8 @@ static int msc_cc_rx_alerting(struct gsm_trans *trans, 
struct msgb *msg)
 	memset(&alerting, 0, sizeof(struct gsm_mncc));
 	alerting.callref = trans->callref;
 	tlv_parse(&tp, &rsl_att_tlvdef, gh->data, payload_len, 0, 0);
-	/* facility */
-	if (TLVP_PRESENT(&tp, GSM48_IE_FACILITY)) {
-		alerting.fields |= MNCC_F_FACILITY;
-		decode_facility(&alerting.facility,
-				TLVP_VAL(&tp, GSM48_IE_FACILITY)-1);
-	}
-
-	/* progress */
-	if (TLVP_PRESENT(&tp, GSM48_IE_PROGR_IND)) {
-		alerting.fields |= MNCC_F_PROGRESS;
-		decode_progress(&alerting.progress,
-				TLVP_VAL(&tp, GSM48_IE_PROGR_IND)-1);
-	}
-	/* ss-version */
-	if (TLVP_PRESENT(&tp, GSM48_IE_SS_VERS)) {
-		alerting.fields |= MNCC_F_SSVERSION;
-		decode_ssversion(&alerting.ssversion,
-				 TLVP_VAL(&tp, GSM48_IE_SS_VERS)-1);
-	}
+	parse_data_derived_information(&tp, &alerting, PARSE_FLAG(FACILITY) | 
PARSE_FLAG(PROGRESS) |
+				       PARSE_FLAG(SSVERSION));
 
 	new_cc_state(trans, GSM_CSTATE_CALL_RECEIVED);
 
@@ -1353,25 +1350,9 @@ static int msc_cc_rx_connect(struct gsm_trans *trans, 
struct msgb *msg)
 		strncpy(connect.imsi, trans->subscr->imsi,
 			sizeof(connect.imsi)-1);
 	}
-	/* facility */
-	if (TLVP_PRESENT(&tp, GSM48_IE_FACILITY)) {
-		connect.fields |= MNCC_F_FACILITY;
-		decode_facility(&connect.facility,
-				TLVP_VAL(&tp, GSM48_IE_FACILITY)-1);
-	}
-	/* user-user */
-	if (TLVP_PRESENT(&tp, GSM48_IE_USER_USER)) {
-		connect.fields |= MNCC_F_USERUSER;
-		decode_useruser(&connect.useruser,
-				TLVP_VAL(&tp, GSM48_IE_USER_USER)-1);
-	}
-	/* ss-version */
-	if (TLVP_PRESENT(&tp, GSM48_IE_SS_VERS)) {
-		connect.fields |= MNCC_F_SSVERSION;
-		decode_ssversion(&connect.ssversion,
-				 TLVP_VAL(&tp, GSM48_IE_SS_VERS)-1);
-	}
 
+	parse_data_derived_information(&tp, &connect, PARSE_FLAG(FACILITY) | 
PARSE_FLAG(USERUSER) |
+				       PARSE_FLAG(SSVERSION));
 	new_cc_state(trans, GSM_CSTATE_CONNECT_REQUEST);
 
 	return mncc_recvmsg(trans->network, trans, MNCC_SETUP_CNF, &connect);
@@ -1420,31 +1401,8 @@ 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);
-	}
-
+	parse_data_derived_information(&tp, &disc, PARSE_FLAG(CAUSE) | 
PARSE_FLAG(FACILITY) |
+				       PARSE_FLAG(USERUSER) | PARSE_FLAG(SSVERSION));
 	return mncc_recvmsg(trans->network, trans, MNCC_DISC_IND, &disc);
 
 }
@@ -1509,30 +1467,8 @@ 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);
-	}
+	parse_data_derived_information(&tp, &rel, PARSE_FLAG(CAUSE) | 
PARSE_FLAG(FACILITY) |
+				       PARSE_FLAG(USERUSER) | PARSE_FLAG(SSVERSION));
 
 	if (trans->state == GSM_CSTATE_RELEASE_REQ) {
 		/* release collision 5.4.5 */
@@ -1598,30 +1534,8 @@ 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);
-	}
+	parse_data_derived_information(&tp, &rel, PARSE_FLAG(CAUSE) | 
PARSE_FLAG(FACILITY) |
+				      PARSE_FLAG(USERUSER) | PARSE_FLAG(SSVERSION));
 
 	if (trans->callref) {
 		switch (trans->state) {
@@ -1684,19 +1598,7 @@ 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);
-	}
-
+	parse_data_derived_information(&tp, &fac, PARSE_FLAG(FACILITY) | 
PARSE_FLAG(SSVERSION));
 	return mncc_recvmsg(trans->network, trans, MNCC_FACILITY_IND, &fac);
 }
 
@@ -1806,13 +1708,7 @@ static int msc_cc_rx_start_dtmf(struct gsm_trans 
*trans, struct msgb *msg)
 	memset(&dtmf, 0, sizeof(struct gsm_mncc));
 	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);
-	}
-
+	parse_data_derived_information(&tp, &dtmf, PARSE_FLAG(KEYPAD));
 	return mncc_recvmsg(trans->network, trans, MNCC_START_DTMF_IND, &dtmf);
 }
 
@@ -1884,15 +1780,8 @@ 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);
-	}
-
+	parse_data_derived_information(&tp, &modify, PARSE_FLAG(BEARER_CAP));
 	new_cc_state(trans, GSM_CSTATE_MO_ORIG_MODIFY);
-
 	return mncc_recvmsg(trans->network, trans, MNCC_MODIFY_IND, &modify);
 }
 
@@ -1928,15 +1817,8 @@ 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);
-	}
-
+	parse_data_derived_information(&tp, &modify, PARSE_FLAG(BEARER_CAP));
 	new_cc_state(trans, GSM_CSTATE_ACTIVE);
-
 	return mncc_recvmsg(trans->network, trans, MNCC_MODIFY_CNF, &modify);
 }
 
@@ -1970,19 +1852,7 @@ 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);
-	}
-
+	parse_data_derived_information(&tp, &modify, PARSE_FLAG(BEARER_CAP) | 
PARSE_FLAG(CAUSE));
 	new_cc_state(trans, GSM_CSTATE_ACTIVE);
 
 	return mncc_recvmsg(trans->network, trans, MNCC_MODIFY_REJ, &modify);
@@ -2070,12 +1940,8 @@ 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);
-	}
+	parse_data_derived_information(&tp, &user, PARSE_FLAG(USERUSER));
+
 	/* more data */
 	if (TLVP_PRESENT(&tp, GSM48_IE_MORE_DATA))
 		user.more = 1;
-- 
1.6.3.3




From zecke at selfish.org  Fri Jul 10 18:43:34 2009
From: zecke at selfish.org (Holger Freyther)
Date: Fri, 10 Jul 2009 20:43:34 +0200
Subject: Cleanup some parsing in the mncc.c code
In-Reply-To: <200907101908.41593.zecke@selfish.org>
References: <200906291727.29186.zecke@selfish.org>
	<20090702044548.GB32676@prithivi.gnumonks.org>
	<200907101908.41593.zecke@selfish.org>
Message-ID: <200907102043.36044.zecke@selfish.org>

On Friday 10 July 2009 19:08:40 Holger Freyther wrote:
> On Thursday 02 July 2009 06:45:48 Harald Welte wrote:

> Things that I think I should do:
> 	- Maybe nuke the PARSE_FLAG and flag attribute? If we get a response that
> contains an attribute that should not be there our tlvp_parse will have
> already parsed it. Does it hurt to copy the value to the gsm_mncc? In one
> way we would like to be strict, in another it can be nice to see what
> incorrect messages we receive?
>
>         - Kill the enum with the PARSE_ flags, I can use the MNCC ones
> directly..


to reply to myself... i think I have fixed the above and think the patch is 
good enough to be merged? what should I change?


From 6de565798996dfc18de0c2fda98e7365d13fd3bc 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...

Parse everything that was found during the tlvp_parse and
assign it to members of the gsm_mncc. This would even parse
elements that are not present/part of the specification.
---
 openbsc/include/openbsc/mncc.h |   46 +++++--
 openbsc/src/msc_mncc.c         |  294 
++++++++++------------------------------
 2 files changed, 107 insertions(+), 233 deletions(-)

diff --git a/openbsc/include/openbsc/mncc.h b/openbsc/include/openbsc/mncc.h
index 6aa1917..d6df502 100644
--- a/openbsc/include/openbsc/mncc.h
+++ b/openbsc/include/openbsc/mncc.h
@@ -93,20 +93,38 @@ struct gsm_call {
 #define GSM_MAX_SSVERSION	128
 #define GSM_MAX_USERUSER	128
 
-#define	MNCC_F_BEARER_CAP	0x0001
-#define MNCC_F_CALLED		0x0002
-#define MNCC_F_CALLING		0x0004
-#define MNCC_F_REDIRECTING	0x0008
-#define MNCC_F_CONNECTED	0x0010
-#define MNCC_F_CAUSE		0x0020
-#define MNCC_F_USERUSER		0x0040
-#define MNCC_F_PROGRESS		0x0080
-#define MNCC_F_EMERGENCY	0x0100
-#define MNCC_F_FACILITY		0x0200
-#define MNCC_F_SSVERSION	0x0400
-#define MNCC_F_CCCAP		0x0800
-#define MNCC_F_KEYPAD		0x1000
-#define MNCC_F_SIGNAL		0x2000
+enum {
+	_MNCC_E_BEARER_CAP,
+	_MNCC_E_CALLED,
+	_MNCC_E_CALLING,
+	_MNCC_E_REDIRECTING,
+	_MNCC_E_CONNECTED,
+	_MNCC_E_CAUSE,
+	_MNCC_E_USERUSER,
+	_MNCC_E_PROGRESS,
+	_MNCC_E_EMERGENCY,
+	_MNCC_E_FACILITY,
+	_MNCC_E_SSVERSION,
+	_MNCC_E_CCCAP,
+	_MNCC_E_KEYPAD,
+	_MNCC_E_SIGNAL,
+	_MNCC_E_LAST_ITEM,
+};
+
+#define	MNCC_F_BEARER_CAP	(1 << _MNCC_E_BEARER_CAP)
+#define MNCC_F_CALLED		(1 << _MNCC_E_CALLED)
+#define MNCC_F_CALLING		(1 << _MNCC_E_CALLING)
+#define MNCC_F_REDIRECTING	(1 << _MNCC_E_REDIRECTING)
+#define MNCC_F_CONNECTED	(1 << _MNCC_E_CONNECTED)
+#define MNCC_F_CAUSE		(1 << _MNCC_E_CAUSE)
+#define MNCC_F_USERUSER		(1 << _MNCC_E_USERUSER)
+#define MNCC_F_PROGRESS		(1 << _MNCC_E_PROGRESS)
+#define MNCC_F_EMERGENCY	(1 << _MNCC_E_EMERGENCY)
+#define MNCC_F_FACILITY		(1 << _MNCC_E_FACILITY)
+#define MNCC_F_SSVERSION	(1 << _MNCC_E_SSVERSION)
+#define MNCC_F_CCCAP		(1 << _MNCC_E_CCCAP)
+#define MNCC_F_KEYPAD		(1 << _MNCC_E_KEYPAD)
+#define MNCC_F_SIGNAL		(1 << _MNCC_E_SIGNAL)
 
 struct gsm_mncc_bearer_cap {
 	int		transfer;
diff --git a/openbsc/src/msc_mncc.c b/openbsc/src/msc_mncc.c
index 90354c0..41ffcc0 100644
--- a/openbsc/src/msc_mncc.c
+++ b/openbsc/src/msc_mncc.c
@@ -587,6 +587,55 @@ static int encode_more(struct msgb *msg)
 	return 0;
 }
 
+#define DECLARE_DECODER3(IE_NAME, M_NAME, name) \
+	[_MNCC_E_##M_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)
+
+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;
+};
+
+static const struct dd_parser dd_parsers [_MNCC_E_LAST_ITEM] = {
+	DECLARE_DECODER(CAUSE, cause),
+	DECLARE_DECODER(FACILITY, facility),
+	DECLARE_DECODER3(USER_USER, USERUSER, useruser),
+	DECLARE_DECODER3(SS_VERS, SSVERSION, ssversion),
+	DECLARE_DECODER3(KPD_FACILITY, KEYPAD, keypad),
+	DECLARE_DECODER(BEARER_CAP, bearer_cap),
+	DECLARE_DECODER3(CALLED_BCD, CALLED, called),
+	DECLARE_DECODER3(CC_CAP, CCCAP, cccap),
+	DECLARE_DECODER3(PROGR_IND, PROGRESS, progress),
+};
+
+static void parse_data_derived_information(struct tlv_parsed *tp, struct 
gsm_mncc *rel, int flags)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(dd_parsers); ++i) {
+		if ((flags & (1<<i)) == (1<<i) &&
+		     TLVP_PRESENT(tp, dd_parsers[i].information_element) &&
+		     dd_parsers[i].decoder) {
+
+			rel->fields |= dd_parsers[i].mncc_field;
+			dd_parsers[i].decoder(rel + dd_parsers[i].offset,
+					      TLVP_VAL(tp, dd_parsers[i].information_element)-1);
+		}
+	}
+}
+
+
 /* map two ipaccess RTP streams onto each other */
 static int tch_map(struct gsm_lchan *lchan, struct gsm_lchan *remote_lchan)
 {
@@ -1013,48 +1062,17 @@ static int msc_cc_rx_setup(struct gsm_trans *trans, 
struct msgb *msg)
 		strncpy(setup.imsi, trans->subscr->imsi,
 			sizeof(setup.imsi)-1);
 	}
-	/* bearer capability */
-	if (TLVP_PRESENT(&tp, GSM48_IE_BEARER_CAP)) {
-		setup.fields |= MNCC_F_BEARER_CAP;
-		decode_bearer_cap(&setup.bearer_cap,
-				  TLVP_VAL(&tp, GSM48_IE_BEARER_CAP)-1);
-	}
-	/* facility */
-	if (TLVP_PRESENT(&tp, GSM48_IE_FACILITY)) {
-		setup.fields |= MNCC_F_FACILITY;
-		decode_facility(&setup.facility,
-				TLVP_VAL(&tp, GSM48_IE_FACILITY)-1);
-	}
-	/* called party bcd number */
-	if (TLVP_PRESENT(&tp, GSM48_IE_CALLED_BCD)) {
-		setup.fields |= MNCC_F_CALLED;
-		decode_called(&setup.called,
-			      TLVP_VAL(&tp, GSM48_IE_CALLED_BCD)-1);
-	}
-	/* user-user */
-	if (TLVP_PRESENT(&tp, GSM48_IE_USER_USER)) {
-		setup.fields |= MNCC_F_USERUSER;
-		decode_useruser(&setup.useruser,
-				TLVP_VAL(&tp, GSM48_IE_USER_USER)-1);
-	}
-	/* ss-version */
-	if (TLVP_PRESENT(&tp, GSM48_IE_SS_VERS)) {
-		setup.fields |= MNCC_F_SSVERSION;
-		decode_ssversion(&setup.ssversion,
-				 TLVP_VAL(&tp, GSM48_IE_SS_VERS)-1);
-	}
+
+	parse_data_derived_information(&tp, &setup, MNCC_F_BEARER_CAP | 
MNCC_F_FACILITY |
+				       MNCC_F_CALLED | MNCC_F_USERUSER |
+				       MNCC_F_SSVERSION | MNCC_F_CCCAP);
+
 	/* CLIR suppression */
 	if (TLVP_PRESENT(&tp, GSM48_IE_CLIR_SUPP))
 		setup.clir.sup = 1;
 	/* CLIR invocation */
 	if (TLVP_PRESENT(&tp, GSM48_IE_CLIR_INVOC))
 		setup.clir.inv = 1;
-	/* cc cap */
-	if (TLVP_PRESENT(&tp, GSM48_IE_CC_CAP)) {
-		setup.fields |= MNCC_F_CCCAP;
-		decode_cccap(&setup.cccap,
-			     TLVP_VAL(&tp, GSM48_IE_CC_CAP)-1);
-	}
 
 	if (is_ipaccess_bts(msg->trx->bts))
 		rsl_ipacc_bind(msg->lchan);
@@ -1171,24 +1189,9 @@ static int msc_cc_rx_call_conf(struct gsm_trans *trans, 
struct msgb *msg)
 	if (TLVP_PRESENT(&tp, GSM48_IE_REPEAT_SEQ))
 		call_conf.repeat = 2;
 #endif
-	/* bearer capability */
-	if (TLVP_PRESENT(&tp, GSM48_IE_BEARER_CAP)) {
-		call_conf.fields |= MNCC_F_BEARER_CAP;
-		decode_bearer_cap(&call_conf.bearer_cap,
-				  TLVP_VAL(&tp, GSM48_IE_BEARER_CAP)-1);
-	}
-	/* cause */
-	if (TLVP_PRESENT(&tp, GSM48_IE_CAUSE)) {
-		call_conf.fields |= MNCC_F_CAUSE;
-		decode_cause(&call_conf.cause,
-			     TLVP_VAL(&tp, GSM48_IE_CAUSE)-1);
-	}
-	/* cc cap */
-	if (TLVP_PRESENT(&tp, GSM48_IE_CC_CAP)) {
-		call_conf.fields |= MNCC_F_CCCAP;
-		decode_cccap(&call_conf.cccap,
-			     TLVP_VAL(&tp, GSM48_IE_CC_CAP)-1);
-	}
+
+	parse_data_derived_information(&tp, &call_conf, MNCC_F_BEARER_CAP |
+				       MNCC_F_CAUSE | MNCC_F_CCCAP);
 
 	new_cc_state(trans, GSM_CSTATE_MO_TERM_CALL_CONF);
 
@@ -1233,25 +1236,8 @@ static int msc_cc_rx_alerting(struct gsm_trans *trans, 
struct msgb *msg)
 	memset(&alerting, 0, sizeof(struct gsm_mncc));
 	alerting.callref = trans->callref;
 	tlv_parse(&tp, &rsl_att_tlvdef, gh->data, payload_len, 0, 0);
-	/* facility */
-	if (TLVP_PRESENT(&tp, GSM48_IE_FACILITY)) {
-		alerting.fields |= MNCC_F_FACILITY;
-		decode_facility(&alerting.facility,
-				TLVP_VAL(&tp, GSM48_IE_FACILITY)-1);
-	}
-
-	/* progress */
-	if (TLVP_PRESENT(&tp, GSM48_IE_PROGR_IND)) {
-		alerting.fields |= MNCC_F_PROGRESS;
-		decode_progress(&alerting.progress,
-				TLVP_VAL(&tp, GSM48_IE_PROGR_IND)-1);
-	}
-	/* ss-version */
-	if (TLVP_PRESENT(&tp, GSM48_IE_SS_VERS)) {
-		alerting.fields |= MNCC_F_SSVERSION;
-		decode_ssversion(&alerting.ssversion,
-				 TLVP_VAL(&tp, GSM48_IE_SS_VERS)-1);
-	}
+	parse_data_derived_information(&tp, &alerting, MNCC_F_FACILITY |
+				      MNCC_F_PROGRESS | MNCC_F_SSVERSION);
 
 	new_cc_state(trans, GSM_CSTATE_CALL_RECEIVED);
 
@@ -1353,25 +1339,9 @@ static int msc_cc_rx_connect(struct gsm_trans *trans, 
struct msgb *msg)
 		strncpy(connect.imsi, trans->subscr->imsi,
 			sizeof(connect.imsi)-1);
 	}
-	/* facility */
-	if (TLVP_PRESENT(&tp, GSM48_IE_FACILITY)) {
-		connect.fields |= MNCC_F_FACILITY;
-		decode_facility(&connect.facility,
-				TLVP_VAL(&tp, GSM48_IE_FACILITY)-1);
-	}
-	/* user-user */
-	if (TLVP_PRESENT(&tp, GSM48_IE_USER_USER)) {
-		connect.fields |= MNCC_F_USERUSER;
-		decode_useruser(&connect.useruser,
-				TLVP_VAL(&tp, GSM48_IE_USER_USER)-1);
-	}
-	/* ss-version */
-	if (TLVP_PRESENT(&tp, GSM48_IE_SS_VERS)) {
-		connect.fields |= MNCC_F_SSVERSION;
-		decode_ssversion(&connect.ssversion,
-				 TLVP_VAL(&tp, GSM48_IE_SS_VERS)-1);
-	}
 
+	parse_data_derived_information(&tp, &connect, MNCC_F_FACILITY |
+				       MNCC_F_USERUSER | MNCC_F_SSVERSION);
 	new_cc_state(trans, GSM_CSTATE_CONNECT_REQUEST);
 
 	return mncc_recvmsg(trans->network, trans, MNCC_SETUP_CNF, &connect);
@@ -1420,31 +1390,9 @@ 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);
-	}
-
+	parse_data_derived_information(&tp, &disc, MNCC_F_CAUSE |
+				       MNCC_F_FACILITY | MNCC_F_USERUSER |
+				       MNCC_F_SSVERSION);
 	return mncc_recvmsg(trans->network, trans, MNCC_DISC_IND, &disc);
 
 }
@@ -1509,30 +1457,8 @@ 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);
-	}
+	parse_data_derived_information(&tp, &rel, MNCC_F_CAUSE | MNCC_F_FACILITY |
+				       MNCC_F_USERUSER | MNCC_F_SSVERSION);
 
 	if (trans->state == GSM_CSTATE_RELEASE_REQ) {
 		/* release collision 5.4.5 */
@@ -1598,30 +1524,8 @@ 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);
-	}
+	parse_data_derived_information(&tp, &rel, MNCC_F_CAUSE | MNCC_F_FACILITY |
+				       MNCC_F_USERUSER | MNCC_F_SSVERSION);
 
 	if (trans->callref) {
 		switch (trans->state) {
@@ -1684,19 +1588,7 @@ 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);
-	}
-
+	parse_data_derived_information(&tp, &fac, MNCC_F_FACILITY | 
MNCC_F_SSVERSION);
 	return mncc_recvmsg(trans->network, trans, MNCC_FACILITY_IND, &fac);
 }
 
@@ -1806,13 +1698,7 @@ static int msc_cc_rx_start_dtmf(struct gsm_trans 
*trans, struct msgb *msg)
 	memset(&dtmf, 0, sizeof(struct gsm_mncc));
 	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);
-	}
-
+	parse_data_derived_information(&tp, &dtmf, MNCC_F_KEYPAD);
 	return mncc_recvmsg(trans->network, trans, MNCC_START_DTMF_IND, &dtmf);
 }
 
@@ -1884,15 +1770,8 @@ 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);
-	}
-
+	parse_data_derived_information(&tp, &modify, MNCC_F_BEARER_CAP);
 	new_cc_state(trans, GSM_CSTATE_MO_ORIG_MODIFY);
-
 	return mncc_recvmsg(trans->network, trans, MNCC_MODIFY_IND, &modify);
 }
 
@@ -1928,15 +1807,8 @@ 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);
-	}
-
+	parse_data_derived_information(&tp, &modify, MNCC_F_BEARER_CAP);
 	new_cc_state(trans, GSM_CSTATE_ACTIVE);
-
 	return mncc_recvmsg(trans->network, trans, MNCC_MODIFY_CNF, &modify);
 }
 
@@ -1970,19 +1842,7 @@ 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);
-	}
-
+	parse_data_derived_information(&tp, &modify, MNCC_F_BEARER_CAP | 
MNCC_F_CAUSE);
 	new_cc_state(trans, GSM_CSTATE_ACTIVE);
 
 	return mncc_recvmsg(trans->network, trans, MNCC_MODIFY_REJ, &modify);
@@ -2070,12 +1930,8 @@ 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);
-	}
+	parse_data_derived_information(&tp, &user, MNCC_F_USERUSER);
+
 	/* more data */
 	if (TLVP_PRESENT(&tp, GSM48_IE_MORE_DATA))
 		user.more = 1;
-- 
1.6.3.3




From laforge at gnumonks.org  Sat Jul  4 09:18:32 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 4 Jul 2009 11:18:32 +0200
Subject: Patch 39: WAS: Re: patches again
In-Reply-To: <200906291844.15509.zecke@selfish.org>
References: <200906291844.15509.zecke@selfish.org>
Message-ID: <20090704091832.GD28952@prithivi.gnumonks.org>

On Mon, Jun 29, 2009 at 06:44:15PM +0200, Holger Freyther wrote:
> 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?

I have just implemented this part of the patch and committed it.
-- 
- 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  Sun Jul  5 02:08:20 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 5 Jul 2009 04:08:20 +0200
Subject: MEAS REP inverted logic (was Re: AW: patches again)
In-Reply-To: <4a49e018.mirider@mirider.augusta.de>
References: <4a49e018.mirider@mirider.augusta.de>
Message-ID: <20090705020819.GD4379@prithivi.gnumonks.org>

Hi Dieter,

On Tue, Jun 30, 2009 at 09:51:20AM +0200, Dieter Spaar wrote:
 
> 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.

thanks.  Rarther than this, I have changed it in parse_meas_rep, i.e. set
MEAS_REP_F_VALID is set if the bit is 0.

It's not yet in the public git repository yet, but in my local 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 laforge at gnumonks.org  Fri Jul  3 10:57:34 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 3 Jul 2009 12:57:34 +0200
Subject: Abis 12.21 OML plugin for wireshark
Message-ID: <20090703105734.GA32201@prithivi.gnumonks.org>

Hi all!

As some of you might have seen from the various git commit messages, I spent
quite a bit of time to implement a GSM 12.21 (A-bis OML) plugin for wireshark
from scratch.  It's available in our git repository at /wireshark/abis_oml.patch

My main focus has been the parsing of the ip.access vendor-specific extensions
to 12.21, as that part is much harder than just implementing what's written
in TS 12.21 itself.

One of the things that it can now decode is decoding of the 'network listen'
functionality implemented as 12.21 'perform test'.

Using this, you can scan over all ARFCN and report the rx level (good for
determining an unused channel at your current location), or you can actually
decode the BCCH information of all cells in your vicinity.

This is just the wireshark plugin.  I did not write any FOSS code for actually
starting those tests, you still need some non-free software for that.  However,
looking at the pcap file I sent some time ago and at this wireshark plugin,
anyone interested should be able to implement this very quickly, maybe as an
addition to ipaccess-config.

Due to my current lack of access to BS-11 hardware, the plugin was not yet
tested against it.  If anyone can do some testing in this regard, it would
be much appreciated.  Alternatively, if somebody can send me some BS11 pcap
files (maybe just of OpenBSC starting up), I can make sure to fix it.

I'm planning to do some more work regarding cleanup and feature-completeness of
the plugin before submitting it mainline to wireshark.

However, the Abis-IP plugin should be quite complete and I'll plan to submit
it really soon now.

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 laforge at gnumonks.org  Fri Jul  3 11:19:51 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 3 Jul 2009 13:19:51 +0200
Subject: ipaccess-config: nanoBTS NVRAM flags support
Message-ID: <20090703111951.GB32201@prithivi.gnumonks.org>

Hi!

ipaccess-config can now set the nanoBTS NVRAM flags.  It has the following
syntax:

ipaccess-config <IP-addr> -n flags/mask

so e.g.

> ipaccess-config 1.2.3.4 -n 0x400/0x400

will set bit number 10 in NVRAM, whereas

> ipaccess-config 1.2.3.4 -n 0x000/0x400

will clear that very bit.

A list of known bits that you can set:

0	Static Interface IP configuration
1	Static IP Gateway configuration
8	Secondary OML enable (incoming TCP port 3006)
10	CLI enable (command line interface on serial port)
11	HTTP enable (https server on TCP port 443)
13	SNMP enable

If somebody wants to add a '--help' message to ipaccess-config, patches
are always welcome.

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 bouchtaoui at gmail.com  Tue Jul  7 10:13:31 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Tue, 07 Jul 2009 12:13:31 +0200
Subject: Git repository via HTTP (port 80)
Message-ID: <4A531FCB.5010700@gmail.com>

Hello guys,

I made a repository for the OpenBSC project, see: 
http://repo.or.cz/w/openbsc.git
Now you can update/clone the project from 
http://repo.or.cz/r/openbsc.git, like this:
git clone http://repo.or.cz/r/openbsc.git

It will be updated every hour (mirror mode).

I needed that because our firewall blocks the git port 9418.
Thank you for the tip Holger Freyther :)

If you have any questions, don't hestitate to ask.





From e.cathelinaud at googlemail.com  Thu Jul  9 11:18:05 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Thu, 9 Jul 2009 13:18:05 +0200
Subject: CCCH
Message-ID: <383f8f9a0907090418p7c2851feoe6df38eb80a5d47b@mail.gmail.com>

Hi everybody

I just would like to be sure that the paging is only sent on TS0 with
OpenBSC, that is to say PCH (which is on CCCH) is only sent on TS0.
I read that it could be sent on more time slots (TS2, TS4 and TS6 also) in
the GSM specifications. Is it the case in the soft or you just keep the
normal multiplexage setting (TS0 only for CCCH+BCCH, 1 slot for dedicated
channels and 6 slots for the traffic channels)?

Thanks

Eric Cathelinaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090709/172bff47/attachment.htm>

From zecke at selfish.org  Thu Jul  9 18:58:28 2009
From: zecke at selfish.org (Holger Freyther)
Date: Thu, 9 Jul 2009 20:58:28 +0200
Subject: CCCH
In-Reply-To: <383f8f9a0907090418p7c2851feoe6df38eb80a5d47b@mail.gmail.com>
References: <383f8f9a0907090418p7c2851feoe6df38eb80a5d47b@mail.gmail.com>
Message-ID: <200907092058.29065.zecke@selfish.org>

On Thursday 09 July 2009 13:18:05 Eric Cathelinaud wrote:
> Hi everybody
>
> I just would like to be sure that the paging is only sent on TS0 with
> OpenBSC, that is to say PCH (which is on CCCH) is only sent on TS0.
> I read that it could be sent on more time slots (TS2, TS4 and TS6 also) in
> the GSM specifications. Is it the case in the soft or you just keep the
> normal multiplexage setting (TS0 only for CCCH+BCCH, 1 slot for dedicated
> channels and 6 slots for the traffic channels)?

Hi,

I think it is the case. The reference would be the SYSTEM INFORMATION TYPE 3 
of GSM 04.08, specially the Control Channel Description Information Element 
and the handling of NM_OC_CHANNEL. Both are done in bsc_hack.c.

I might be totally wrong
	z.




From laforge at gnumonks.org  Fri Jul 10 16:56:28 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 10 Jul 2009 18:56:28 +0200
Subject: CCCH
In-Reply-To: <383f8f9a0907090418p7c2851feoe6df38eb80a5d47b@mail.gmail.com>
References: <383f8f9a0907090418p7c2851feoe6df38eb80a5d47b@mail.gmail.com>
Message-ID: <20090710165628.GA11805@prithivi.gnumonks.org>

On Thu, Jul 09, 2009 at 01:18:05PM +0200, Eric Cathelinaud wrote:
> Hi everybody
> 
> I just would like to be sure that the paging is only sent on TS0 with
> OpenBSC, that is to say PCH (which is on CCCH) is only sent on TS0.
> I read that it could be sent on more time slots (TS2, TS4 and TS6 also) in
> the GSM specifications. Is it the case in the soft or you just keep the
> normal multiplexage setting (TS0 only for CCCH+BCCH, 1 slot for dedicated
> channels and 6 slots for the traffic channels)?

we only run one timeslot (TS0) for the CCCH (and thus the PCH).  Using more 
timeslots is only required in really large BTS with many TRX - not a case
we particularly care about 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)



From e.cathelinaud at googlemail.com  Wed Jul 15 09:00:14 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Wed, 15 Jul 2009 11:00:14 +0200
Subject: CCCH
In-Reply-To: <383f8f9a0907150158v5f3097a1x9eb7a7a5952d2d3c@mail.gmail.com>
References: <383f8f9a0907090418p7c2851feoe6df38eb80a5d47b@mail.gmail.com>
	<20090710165628.GA11805@prithivi.gnumonks.org>
	<383f8f9a0907150158v5f3097a1x9eb7a7a5952d2d3c@mail.gmail.com>
Message-ID: <383f8f9a0907150200p46e8cb99h170ca5df44ebd38c@mail.gmail.com>

2009/7/10 Harald Welte <laforge at gnumonks.org>

On Thu, Jul 09, 2009 at 01:18:05PM +0200, Eric Cathelinaud wrote:
> > Hi everybody
> >
> > I just would like to be sure that the paging is only sent on TS0 with
> > OpenBSC, that is to say PCH (which is on CCCH) is only sent on TS0.
> > I read that it could be sent on more time slots (TS2, TS4 and TS6 also)
> in
> > the GSM specifications. Is it the case in the soft or you just keep the
> > normal multiplexage setting (TS0 only for CCCH+BCCH, 1 slot for dedicated
> > channels and 6 slots for the traffic channels)?
>
> we only run one timeslot (TS0) for the CCCH (and thus the PCH).  Using more
> timeslots is only required in really large BTS with many TRX - not a case
> we particularly care about 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)
>


Ok thanks
I was just thinking about performing a recursive paging in order to see how
much time I have until the battery of a mobile phone run out.
Does anyone know if the mobile phone answers at every paging or if it
doesn't "listen" all the time? I think it listens periodically. If anyone
can give me a clue, that would be appreciated.

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

From spaar at mirider.augusta.de  Wed Jul 15 11:29:14 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Wed, 15 Jul 2009 11:29:14 CEST
Subject: CCCH
Message-ID: <4a5dbd8a.mirider@mirider.augusta.de>

Hello Eric,

On Wed, 15 Jul 2009 11:00:14 +0200, "Eric Cathelinaud" <e.cathelinaud at googlemail.com> wrote:
>
> I was just thinking about performing a recursive paging in order to see how
> much time I have until the battery of a mobile phone run out.
> Does anyone know if the mobile phone answers at every paging or if it
> doesn't "listen" all the time? I think it listens periodically. If anyone
> can give me a clue, that would be appreciated.

This is an excerpt from a posting to another mainling list, I just
quote it because I don't want to repeat what I already wrote:

>  - The phone is in "idle" mode (no speech/data traffic)
>    and periodically receives the paging channel (PCH) to
>    find out if its being called. Further the phone measures
>    the signal strength of neighbor cells and every now
>    and then (not that frequent as the above actions)
>    receives the cell information in the broadcast common
>    control channel (BCCH) of the serving cell and of
>    at most six neighbor cells with the strongest signal.

....

>  - The time between receiving the PCH is determined by a
>    parameter of the serving cell (BS_PA_MFRMS, range 2 to 9).
>    Its measured in 51-multiframes until the PCH for the phone
>    repeats (if you want to know the details have a look at
>    the GSM specs  ;-) . The length of a 51-multiframe is
>    235.8 ms, this means the time between receiving the PCH
>    is in the range 471.9 ms to 2122.2 ms. In this time the
>    idle phone most of the time sleeps or receives the BCCH
>    of the serving cell or one of the neighbor cells with
>    the strongest signal (at most six).

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



From e.cathelinaud at googlemail.com  Wed Jul 15 10:56:30 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Wed, 15 Jul 2009 12:56:30 +0200
Subject: CCCH
In-Reply-To: <4a5dbd8a.mirider@mirider.augusta.de>
References: <4a5dbd8a.mirider@mirider.augusta.de>
Message-ID: <383f8f9a0907150356r1a58c6bagbaf65f22cd12c7c0@mail.gmail.com>

2009/7/15 Dieter Spaar <spaar at mirider.augusta.de>

> Hello Eric,
>
> On Wed, 15 Jul 2009 11:00:14 +0200, "Eric Cathelinaud" <
> e.cathelinaud at googlemail.com> wrote:
> >
> > I was just thinking about performing a recursive paging in order to see
> how
> > much time I have until the battery of a mobile phone run out.
> > Does anyone know if the mobile phone answers at every paging or if it
> > doesn't "listen" all the time? I think it listens periodically. If anyone
> > can give me a clue, that would be appreciated.
>
> This is an excerpt from a posting to another mainling list, I just
> quote it because I don't want to repeat what I already wrote:
>
> >  - The phone is in "idle" mode (no speech/data traffic)
> >    and periodically receives the paging channel (PCH) to
> >    find out if its being called. Further the phone measures
> >    the signal strength of neighbor cells and every now
> >    and then (not that frequent as the above actions)
> >    receives the cell information in the broadcast common
> >    control channel (BCCH) of the serving cell and of
> >    at most six neighbor cells with the strongest signal.
>
> ....
>
> >  - The time between receiving the PCH is determined by a
> >    parameter of the serving cell (BS_PA_MFRMS, range 2 to 9).
> >    Its measured in 51-multiframes until the PCH for the phone
> >    repeats (if you want to know the details have a look at
> >    the GSM specs  ;-) . The length of a 51-multiframe is
> >    235.8 ms, this means the time between receiving the PCH
> >    is in the range 471.9 ms to 2122.2 ms. In this time the
> >    idle phone most of the time sleeps or receives the BCCH
> >    of the serving cell or one of the neighbor cells with
> >    the strongest signal (at most six).
>
> Best regards,
>  Dieter
> --
> Dieter Spaar, Germany                           spaar at mirider.augusta.de
>

Thanks a lot for the explanation. It's a pity that the minimum period is 2
multiframes. I wish I could realize a paging on a mobile phone every frame
but it seems to be impossible finally.

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

From e.cathelinaud at googlemail.com  Thu Jul 16 13:44:21 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Thu, 16 Jul 2009 15:44:21 +0200
Subject: CCCH
In-Reply-To: <383f8f9a0907150356r1a58c6bagbaf65f22cd12c7c0@mail.gmail.com>
References: <4a5dbd8a.mirider@mirider.augusta.de>
	<383f8f9a0907150356r1a58c6bagbaf65f22cd12c7c0@mail.gmail.com>
Message-ID: <383f8f9a0907160644q49da4eb7g1f02fa9f968eacfa@mail.gmail.com>

Hi,

Finally I think I find a solution to make the cell phone listening to every
frames of the CCCH.

From zecke at selfish.org  Thu Jul 16 14:10:57 2009
From: zecke at selfish.org (Holger Freyther)
Date: Thu, 16 Jul 2009 16:10:57 +0200
Subject: CCCH
In-Reply-To: <383f8f9a0907160644q49da4eb7g1f02fa9f968eacfa@mail.gmail.com>
References: <4a5dbd8a.mirider@mirider.augusta.de>
	<383f8f9a0907150356r1a58c6bagbaf65f22cd12c7c0@mail.gmail.com>
	<383f8f9a0907160644q49da4eb7g1f02fa9f968eacfa@mail.gmail.com>
Message-ID: <200907161610.58140.zecke@selfish.org>

On Thursday 16 July 2009 15:44:21 Eric Cathelinaud wrote:
> Hi,

> parameter. I saw that the paging group is calculated from the IMSI. And
> then the paging block is calculated. Is it calculated in the BTS or in
> OpenBSC? 

See paging.c in the source code for formatting the paging request (and 
calculating the group)

	z.



From spaar at mirider.augusta.de  Thu Jul 16 16:25:26 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Thu, 16 Jul 2009 16:25:26 CEST
Subject: CCCH
Message-ID: <4a5f5476.mirider@mirider.augusta.de>

Hello Eric,

On Thu, 16 Jul 2009 15:44:21 +0200, "Eric Cathelinaud" <e.cathelinaud at googlemail.com> wrote:
>
> I don't know if the mobile phone will answer everytimes if i try to do a
> paging on it for each successive frame. Or if he will answer the first time
> and ignore the other paging requests after.

Maybe you can explain what you want to achieve, this might help to give
an answere.

I initially thought you want to measure the standby time of the phone,
this is why posted the information about the BS_PA_MFRMS parameter,
it usually determines the standby time (if BS_PA_MFRMS is maximum,
you usually get the longest standby time).

But now it seem you want the phone to react as fast as possible on
a paging request, but maybe I don't understand what you want to do.

Best regards,
  Dieter

PS: The calculation of the paging group is done by OpenBSC and not
by the BTS.
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From spaar at mirider.augusta.de  Fri Jul 17 11:41:16 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Fri, 17 Jul 2009 11:41:16 CEST
Subject: CCCH
Message-ID: <4a60635c.mirider@mirider.augusta.de>

Hello Eric,

On Thu, 16 Jul 2009 17:53:53 +0200, "Eric Cathelinaud" <e.cathelinaud at googlemail.com> wrote:
>
> Yes I would like to make the cell phone answer as fast as possible but
> without the need of a user interaction. So I am trying to get RACH as fast
> as possible and I think the paging function is the most suitable for this. A
> RACH for each frame would be really nice. At least one RACH out of 2 frames,
> then i can have at least 1 RACH per 10 ms.

I don't think you have much influence on setting the paging reorganisation
mode, this is done by the BTS when it detects that something has changed
with paging (the BTS can detect it by looking for changes in the SYSTEM
INFORMATION messages). I did a quick test with a nanoBTS 1800, if for
example BS_PA_MFRMS is changed, the BTS will activate the paging
reorganisation mode while switching the parameter. I can confirm that
with the Nokia Network Monitor, it displays the page mode and indicates
"paging reorganisation" for a short amount of time (about one second).

You can try to constantly switch the SYSTEM INFORMATION data related to
paging, but I don't know if this will help with what you want to do.
Also please note that I have not tried it with the BS-11.

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



From e.cathelinaud at googlemail.com  Fri Jul 17 15:52:17 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Fri, 17 Jul 2009 17:52:17 +0200
Subject: CCCH
In-Reply-To: <4a60635c.mirider@mirider.augusta.de>
References: <4a60635c.mirider@mirider.augusta.de>
Message-ID: <383f8f9a0907170852m2e23ca61gec6a3d5978613a00@mail.gmail.com>

Hi Dieter,

Thanks for the test!
I will make research about this SYSTEM INFORMATION data related to paging
and see if it's possible to modify it every time.

If nothing possible I will try to deal with the 470ms period.
Can you tell me if the mobile will RACH at each paging request or if it can
miss some?
I already saw in OpenBSC that the paging request is sometimes send more than
once for a call so I am not sure. May be it could be something to fixe in
the code? Or the phone sometimes doesn't react as it should?
Normally the RACH is sent 3 time slots after the paging request right?

Thank you

Best regards,
Eric Cathelinaud


2009/7/17 Dieter Spaar <spaar at mirider.augusta.de>

> Hello Eric,
>
> On Thu, 16 Jul 2009 17:53:53 +0200, "Eric Cathelinaud" <
> e.cathelinaud at googlemail.com> wrote:
> >
> > Yes I would like to make the cell phone answer as fast as possible but
> > without the need of a user interaction. So I am trying to get RACH as
> fast
> > as possible and I think the paging function is the most suitable for
> this. A
> > RACH for each frame would be really nice. At least one RACH out of 2
> frames,
> > then i can have at least 1 RACH per 10 ms.
>
> I don't think you have much influence on setting the paging reorganisation
> mode, this is done by the BTS when it detects that something has changed
> with paging (the BTS can detect it by looking for changes in the SYSTEM
> INFORMATION messages). I did a quick test with a nanoBTS 1800, if for
> example BS_PA_MFRMS is changed, the BTS will activate the paging
> reorganisation mode while switching the parameter. I can confirm that
> with the Nokia Network Monitor, it displays the page mode and indicates
> "paging reorganisation" for a short amount of time (about one second).
>
> You can try to constantly switch the SYSTEM INFORMATION data related to
> paging, but I don't know if this will help with what you want to do.
> Also please note that I have not tried it with the BS-11.
>
> Best regard,
>  Dieter
> --
> Dieter Spaar, Germany                           spaar at mirider.augusta.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090717/f8a9fbac/attachment.htm>

From spaar at mirider.augusta.de  Fri Jul 17 19:11:44 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Fri, 17 Jul 2009 19:11:44 CEST
Subject: CCCH
Message-ID: <4a60ccf0.mirider@mirider.augusta.de>

Hello Eric,

On Fri, 17 Jul 2009 17:52:17 +0200, "Eric Cathelinaud" <e.cathelinaud at googlemail.com> wrote:
> 
> If nothing possible I will try to deal with the 470ms period.
> Can you tell me if the mobile will RACH at each paging request or if it can
> miss some?

If the MS receives a paging request for itself and is allowed to access
the network, than it will start the immediate assign procedure (The details
are in GSM 04.08, a good overview with reference to the specification is at
http://en.wikipedia.org/wiki/Um_Interface, many thanks to David Burgess for
writing it down). The MS will not react on further paging request as long as
the immediate assign procedure is running.

> I already saw in OpenBSC that the paging request is sometimes send more than
> once for a call so I am not sure. May be it could be something to fixe in
> the code? Or the phone sometimes doesn't react as it should?

The BSC can't be sure that a single paging request is received by the
MS so it (optionally) has to repeat it (there can be distortions, weak
signal and so on).

> Normally the RACH is sent 3 time slots after the paging request right?

I don't think so, the RACH is always on TS0 of the uplink (at least this
is how I understand it) and the PCH is not necessarily on TS0 (depending
on the configuration). The reaction of the MS surley depends on the
firmware/hardware of the phone and how fast it works, so you don't
have a fixed delay. The MS usually has enough time to react, the
T3113 timer defines how long to wait for a PAGING RESPONSE and than
optionally repeat the paging request (if and how often the paging
request is repeated, is not defined in the specification). I don't
have exact numbers for the T3113 timer because its up to network,
but common values seems to be around 5 seconds.

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



From e.cathelinaud at googlemail.com  Tue Jul 28 12:30:13 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Tue, 28 Jul 2009 14:30:13 +0200
Subject: CCCH
In-Reply-To: <4a60ccf0.mirider@mirider.augusta.de>
References: <4a60ccf0.mirider@mirider.augusta.de>
Message-ID: <383f8f9a0907280530q6975c0aaq6b2e9691addddf4f@mail.gmail.com>

Hello Dieter,

Sorry I am answering quite late on this subject.

>
> If the MS receives a paging request for itself and is allowed to access
> the network, than it will start the immediate assign procedure (The details
> are in GSM 04.08, a good overview with reference to the specification is at
> http://en.wikipedia.org/wiki/Um_Interface, many thanks to David Burgess
> for
> writing it down). The MS will not react on further paging request as long
> as
> the immediate assign procedure is running.
>
> The BSC can't be sure that a single paging request is received by the
> MS so it (optionally) has to repeat it (there can be distortions, weak
> signal and so on).
>
> > Normally the RACH is sent 3 time slots after the paging request right?
>
> I don't think so, the RACH is always on TS0 of the uplink (at least this
> is how I understand it) and the PCH is not necessarily on TS0 (depending
> on the configuration). The reaction of the MS surley depends on the
> firmware/hardware of the phone and how fast it works, so you don't
> have a fixed delay. The MS usually has enough time to react, the
> T3113 timer defines how long to wait for a PAGING RESPONSE and than
> optionally repeat the paging request (if and how often the paging
> request is repeated, is not defined in the specification). I don't
> have exact numbers for the T3113 timer because its up to network,
> but common values seems to be around 5 seconds.


Thanks for the explanations. I can't test it since I have no communication
analyzer to see the communication between the MS & BTS but at least with
wireshark I can see it's more than 500 ms in one of my tests.
For the RACH I found in GSM 05.02 that it can be on TS0,2,4,6 like the PCH.
(Clause 7 Table 3 of 9: Mapping of logical channels onto physical channels)
The RACH is always randomly sent, even at the beginning without any
collision.

Now I am trying to find the window of time during which this random time can
be found.

>  <spaar at mirider.augusta.de>
>

Eric Cathelinaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090728/2427ad00/attachment.htm>

From e.cathelinaud at googlemail.com  Thu Jul  9 14:23:09 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Thu, 9 Jul 2009 16:23:09 +0200
Subject: wireshark, viewing Abis communication
Message-ID: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>

Hi,

I am trying to deal with wireshark to understand what happening in each
function in the code.
It says that the file seems to be corrupted:
"The capture files appears to be damaged or corrupted. (libpcap: LAPD file
has a 15-byte packet, too small to have even a LAPD pseudo-header)"

Is it a problem?

I still can read the Abis communication.
I saw that some rsl packets are malformed. Is it coming from a missing
implementation in the code that need to be fixed?

Thanks

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090709/4e9bb7e7/attachment.htm>

From zecke at selfish.org  Thu Jul  9 18:20:01 2009
From: zecke at selfish.org (Holger Freyther)
Date: Thu, 9 Jul 2009 20:20:01 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
Message-ID: <200907092020.01696.zecke@selfish.org>

On Thursday 09 July 2009 16:23:09 Eric Cathelinaud wrote:
> Hi,
>
> I am trying to deal with wireshark to understand what happening in each
> function in the code.
> It says that the file seems to be corrupted:
> "The capture files appears to be damaged or corrupted. (libpcap: LAPD file
> has a 15-byte packet, too small to have even a LAPD pseudo-header)"

which file is that? anything you recorded? recorded with what?

z.



From e.cathelinaud at googlemail.com  Thu Jul  9 21:02:44 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Thu, 9 Jul 2009 23:02:44 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <200907092020.01696.zecke@selfish.org>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<200907092020.01696.zecke@selfish.org>
Message-ID: <383f8f9a0907091402h7374d714v7bb0e25a0944665b@mail.gmail.com>

hi,

I used the option in the command line : ./bsc_hack -p something.pcap
http://bs11-abis.gnumonks.org/trac/wiki/PacketDump

Then I opened it with wireshark.

Eric Cathelinaud

2009/7/9 Holger Freyther <zecke at selfish.org>

> On Thursday 09 July 2009 16:23:09 Eric Cathelinaud wrote:
> > Hi,
> >
> > I am trying to deal with wireshark to understand what happening in each
> > function in the code.
> > It says that the file seems to be corrupted:
> > "The capture files appears to be damaged or corrupted. (libpcap: LAPD
> file
> > has a 15-byte packet, too small to have even a LAPD pseudo-header)"
>
> which file is that? anything you recorded? recorded with what?
>
> z.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090709/0aa2eacc/attachment.htm>

From zecke at selfish.org  Fri Jul 10 00:49:35 2009
From: zecke at selfish.org (Holger Freyther)
Date: Fri, 10 Jul 2009 02:49:35 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <383f8f9a0907091402h7374d714v7bb0e25a0944665b@mail.gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<200907092020.01696.zecke@selfish.org>
	<383f8f9a0907091402h7374d714v7bb0e25a0944665b@mail.gmail.com>
Message-ID: <200907100249.35566.zecke@selfish.org>

On Thursday 09 July 2009 23:02:44 Eric Cathelinaud wrote:
> hi,
>
> I used the option in the command line : ./bsc_hack -p something.pcap
> http://bs11-abis.gnumonks.org/trac/wiki/PacketDump


leaves only the type of the BTS... which I assume will be nanoBTS... and then 
I will have to tell you that it doesn't work for the nanoBTS and that the 
better alternative is to use harald's work in progress wireshark plugin.

would you find the time to update the PacketDump wiki site?


z.



From e.cathelinaud at googlemail.com  Fri Jul 10 08:11:35 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Fri, 10 Jul 2009 10:11:35 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <200907100249.35566.zecke@selfish.org>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<200907092020.01696.zecke@selfish.org>
	<383f8f9a0907091402h7374d714v7bb0e25a0944665b@mail.gmail.com>
	<200907100249.35566.zecke@selfish.org>
Message-ID: <383f8f9a0907100111x228aa0cbr28d7627b40aef88d@mail.gmail.com>

2009/7/10 Holger Freyther <zecke at selfish.org>

> On Thursday 09 July 2009 23:02:44 Eric Cathelinaud wrote:
> > hi,
> >
> > I used the option in the command line : ./bsc_hack -p something.pcap
> > http://bs11-abis.gnumonks.org/trac/wiki/PacketDump
>
>
> leaves only the type of the BTS... which I assume will be nanoBTS... and
> then
> I will have to tell you that it doesn't work for the nanoBTS and that the
> better alternative is to use harald's work in progress wireshark plugin.
>
> would you find the time to update the PacketDump wiki site?
>

>
> z.
>
>

Yes sure but I am not using a nanoBTS, I am using the bs11.

Eric Cathelinaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090710/566f4fb2/attachment.htm>

From e.cathelinaud at googlemail.com  Fri Jul 10 09:05:32 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Fri, 10 Jul 2009 11:05:32 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <383f8f9a0907100111x228aa0cbr28d7627b40aef88d@mail.gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<200907092020.01696.zecke@selfish.org>
	<383f8f9a0907091402h7374d714v7bb0e25a0944665b@mail.gmail.com>
	<200907100249.35566.zecke@selfish.org>
	<383f8f9a0907100111x228aa0cbr28d7627b40aef88d@mail.gmail.com>
Message-ID: <383f8f9a0907100205u2bd032c1pa44ae0208c8f67fe@mail.gmail.com>

2009/7/10 Eric Cathelinaud <e.cathelinaud at googlemail.com>

> 2009/7/10 Holger Freyther <zecke at selfish.org>
>
> On Thursday 09 July 2009 23:02:44 Eric Cathelinaud wrote:
>> > hi,
>> >
>> > I used the option in the command line : ./bsc_hack -p something.pcap
>> > http://bs11-abis.gnumonks.org/trac/wiki/PacketDump
>>
>>
>> leaves only the type of the BTS... which I assume will be nanoBTS... and
>> then
>> I will have to tell you that it doesn't work for the nanoBTS and that the
>> better alternative is to use harald's work in progress wireshark plugin.
>>
>> would you find the time to update the PacketDump wiki site?
>>
>
>>
>> z.
>>
>>
>
> Yes sure but I am not using a nanoBTS, I am using the bs11.
>
> Eric Cathelinaud
>

Well I have no more problem when opening the pcap files.
I had no problem with the files on the wiki, only with the file i was
generating.
But now it's working fine also, the reboot solved my problem. Dunno what
happened exactly.

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

From e.cathelinaud at googlemail.com  Fri Jul 10 10:29:47 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Fri, 10 Jul 2009 12:29:47 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <383f8f9a0907100205u2bd032c1pa44ae0208c8f67fe@mail.gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<200907092020.01696.zecke@selfish.org>
	<383f8f9a0907091402h7374d714v7bb0e25a0944665b@mail.gmail.com>
	<200907100249.35566.zecke@selfish.org>
	<383f8f9a0907100111x228aa0cbr28d7627b40aef88d@mail.gmail.com>
	<383f8f9a0907100205u2bd032c1pa44ae0208c8f67fe@mail.gmail.com>
Message-ID: <383f8f9a0907100329w8738169tdfacaa5929553b14@mail.gmail.com>

2009/7/10 Eric Cathelinaud <e.cathelinaud at googlemail.com>

> 2009/7/10 Eric Cathelinaud <e.cathelinaud at googlemail.com>
>
> 2009/7/10 Holger Freyther <zecke at selfish.org>
>>
>> On Thursday 09 July 2009 23:02:44 Eric Cathelinaud wrote:
>>> > hi,
>>> >
>>> > I used the option in the command line : ./bsc_hack -p something.pcap
>>> > http://bs11-abis.gnumonks.org/trac/wiki/PacketDump
>>>
>>>
>>> leaves only the type of the BTS... which I assume will be nanoBTS... and
>>> then
>>> I will have to tell you that it doesn't work for the nanoBTS and that the
>>> better alternative is to use harald's work in progress wireshark plugin.
>>>
>>> would you find the time to update the PacketDump wiki site?
>>>
>>
>>>
>>> z.
>>>
>>>
>>
>> Yes sure but I am not using a nanoBTS, I am using the bs11.
>>
>> Eric Cathelinaud
>>
>
> Well I have no more problem when opening the pcap files.
> I had no problem with the files on the wiki, only with the file i was
> generating.
> But now it's working fine also, the reboot solved my problem. Dunno what
> happened exactly.
>
> Eric Cathelinaud


Well i still have sometimes this error message. I have it when I attach a
mobile on the network.
I saw 2 "unknow" packets comes from the Remote Network to the Remote User
during the attach process. Their size are quite small.
I join in attached file a screen of my results.

Eric Cathelinaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090710/d985f74d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unknowPackets.png
Type: image/png
Size: 131282 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090710/d985f74d/attachment.png>

From laforge at gnumonks.org  Fri Jul 10 16:58:20 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 10 Jul 2009 18:58:20 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <383f8f9a0907100329w8738169tdfacaa5929553b14@mail.gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<200907092020.01696.zecke@selfish.org>
	<383f8f9a0907091402h7374d714v7bb0e25a0944665b@mail.gmail.com>
	<200907100249.35566.zecke@selfish.org>
	<383f8f9a0907100111x228aa0cbr28d7627b40aef88d@mail.gmail.com>
	<383f8f9a0907100205u2bd032c1pa44ae0208c8f67fe@mail.gmail.com>
	<383f8f9a0907100329w8738169tdfacaa5929553b14@mail.gmail.com>
Message-ID: <20090710165820.GB11805@prithivi.gnumonks.org>

On Fri, Jul 10, 2009 at 12:29:47PM +0200, Eric Cathelinaud wrote:
> Well i still have sometimes this error message. I have it when I attach a
> mobile on the network.
> I saw 2 "unknow" packets comes from the Remote Network to the Remote User
> during the attach process. Their size are quite small.
> I join in attached file a screen of my results.

it would help if you can put the pcap file (with at least one good and one
'bad' packet) somewhere online or even send it to the list (if its small and you only select a couple of packets, you can attach it).

-- 
- 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 Jul 15 09:06:48 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Wed, 15 Jul 2009 11:06:48 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <20090710165820.GB11805@prithivi.gnumonks.org>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<200907092020.01696.zecke@selfish.org>
	<383f8f9a0907091402h7374d714v7bb0e25a0944665b@mail.gmail.com>
	<200907100249.35566.zecke@selfish.org>
	<383f8f9a0907100111x228aa0cbr28d7627b40aef88d@mail.gmail.com>
	<383f8f9a0907100205u2bd032c1pa44ae0208c8f67fe@mail.gmail.com>
	<383f8f9a0907100329w8738169tdfacaa5929553b14@mail.gmail.com>
	<20090710165820.GB11805@prithivi.gnumonks.org>
Message-ID: <383f8f9a0907150206s15f472e7tbef55a44ad4bdb09@mail.gmail.com>

2009/7/10 Harald Welte <laforge at gnumonks.org>

> On Fri, Jul 10, 2009 at 12:29:47PM +0200, Eric Cathelinaud wrote:
> > Well i still have sometimes this error message. I have it when I attach a
> > mobile on the network.
> > I saw 2 "unknow" packets comes from the Remote Network to the Remote User
> > during the attach process. Their size are quite small.
> > I join in attached file a screen of my results.
>
> it would help if you can put the pcap file (with at least one good and one
> 'bad' packet) somewhere online or even send it to the list (if its small
> and you only select a couple of packets, you can attach it).
>
> --
> - 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)
>


In the attached file there are 5 malformed packets and 2 unknow packets.

Thanks
Eric Cathelinaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090715/b8330db4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: paging12.pcap
Type: application/cap
Size: 7348 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090715/b8330db4/attachment.bin>

From laforge at gnumonks.org  Wed Jul 15 18:46:22 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 15 Jul 2009 20:46:22 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <383f8f9a0907150206s15f472e7tbef55a44ad4bdb09@mail.gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<200907092020.01696.zecke@selfish.org>
	<383f8f9a0907091402h7374d714v7bb0e25a0944665b@mail.gmail.com>
	<200907100249.35566.zecke@selfish.org>
	<383f8f9a0907100111x228aa0cbr28d7627b40aef88d@mail.gmail.com>
	<383f8f9a0907100205u2bd032c1pa44ae0208c8f67fe@mail.gmail.com>
	<383f8f9a0907100329w8738169tdfacaa5929553b14@mail.gmail.com>
	<20090710165820.GB11805@prithivi.gnumonks.org>
	<383f8f9a0907150206s15f472e7tbef55a44ad4bdb09@mail.gmail.com>
Message-ID: <20090715184622.GY11272@prithivi.gnumonks.org>

On Wed, Jul 15, 2009 at 11:06:48AM +0200, Eric Cathelinaud wrote:
> 2009/7/10 Harald Welte <laforge at gnumonks.org>
> 
> > On Fri, Jul 10, 2009 at 12:29:47PM +0200, Eric Cathelinaud wrote:
> > > Well i still have sometimes this error message. I have it when I attach a
> > > mobile on the network.
> > > I saw 2 "unknow" packets comes from the Remote Network to the Remote User
> > > during the attach process. Their size are quite small.
> > > I join in attached file a screen of my results.
> >
> > it would help if you can put the pcap file (with at least one good and one
> > 'bad' packet) somewhere online or even send it to the list (if its small
> > and you only select a couple of packets, you can attach it).
> >
> > --
> > - 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)
> >
> 
> 
> In the attached file there are 5 malformed packets and 2 unknow packets.

just to make it clear: this pcap was generated using bsc_hack's pcap option,
correct?  it seems like sometimes we write truncated packets to that file.

There is a different method, using mISDN's debug tool (see
http://www.misdn.org/index.php/Debugtool).  I think if somebody can confirm
this method works, i.e. use mISDNdebugtool to write a 'dumpfile' and then open
that with wireshark, then we can actually remove the pcap code from OpenBSC
altogether.

Would you mind trying that method and report if you still see broken/unknown
packets?

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 e.cathelinaud at googlemail.com  Wed Jul 15 21:17:40 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Wed, 15 Jul 2009 23:17:40 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <20090715184622.GY11272@prithivi.gnumonks.org>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<200907092020.01696.zecke@selfish.org>
	<383f8f9a0907091402h7374d714v7bb0e25a0944665b@mail.gmail.com>
	<200907100249.35566.zecke@selfish.org>
	<383f8f9a0907100111x228aa0cbr28d7627b40aef88d@mail.gmail.com>
	<383f8f9a0907100205u2bd032c1pa44ae0208c8f67fe@mail.gmail.com>
	<383f8f9a0907100329w8738169tdfacaa5929553b14@mail.gmail.com>
	<20090710165820.GB11805@prithivi.gnumonks.org>
	<383f8f9a0907150206s15f472e7tbef55a44ad4bdb09@mail.gmail.com>
	<20090715184622.GY11272@prithivi.gnumonks.org>
Message-ID: <383f8f9a0907151417i751af2bte66a12d242b4aebc@mail.gmail.com>

2009/7/15 Harald Welte <laforge at gnumonks.org>

>  On Wed, Jul 15, 2009 at 11:06:48AM +0200, Eric Cathelinaud wrote:
> > 2009/7/10 Harald Welte <laforge at gnumonks.org>
> >
> > > On Fri, Jul 10, 2009 at 12:29:47PM +0200, Eric Cathelinaud wrote:
> > > > Well i still have sometimes this error message. I have it when I
> attach a
> > > > mobile on the network.
> > > > I saw 2 "unknow" packets comes from the Remote Network to the Remote
> User
> > > > during the attach process. Their size are quite small.
> > > > I join in attached file a screen of my results.
> > >
> > > it would help if you can put the pcap file (with at least one good and
> one
> > > 'bad' packet) somewhere online or even send it to the list (if its
> small
> > > and you only select a couple of packets, you can attach it).
> > >
> > > --
> > > - 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)
> > >
> >
> >
> > In the attached file there are 5 malformed packets and 2 unknow packets.
>
> just to make it clear: this pcap was generated using bsc_hack's pcap
> option,
> correct?  it seems like sometimes we write truncated packets to that file.
>
> There is a different method, using mISDN's debug tool (see
> http://www.misdn.org/index.php/Debugtool).  I think if somebody can
> confirm
> this method works, i.e. use mISDNdebugtool to write a 'dumpfile' and then
> open
> that with wireshark, then we can actually remove the pcap code from OpenBSC
> altogether.
>
> Would you mind trying that method and report if you still see
> broken/unknown
> packets?
>
> 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)
>


 Ok i will try it and tell u ;-)

Thanks

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

From e.cathelinaud at googlemail.com  Wed Jul 15 21:18:43 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Wed, 15 Jul 2009 23:18:43 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <383f8f9a0907151417i751af2bte66a12d242b4aebc@mail.gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<383f8f9a0907091402h7374d714v7bb0e25a0944665b@mail.gmail.com>
	<200907100249.35566.zecke@selfish.org>
	<383f8f9a0907100111x228aa0cbr28d7627b40aef88d@mail.gmail.com>
	<383f8f9a0907100205u2bd032c1pa44ae0208c8f67fe@mail.gmail.com>
	<383f8f9a0907100329w8738169tdfacaa5929553b14@mail.gmail.com>
	<20090710165820.GB11805@prithivi.gnumonks.org>
	<383f8f9a0907150206s15f472e7tbef55a44ad4bdb09@mail.gmail.com>
	<20090715184622.GY11272@prithivi.gnumonks.org>
	<383f8f9a0907151417i751af2bte66a12d242b4aebc@mail.gmail.com>
Message-ID: <383f8f9a0907151418k1773f0faid0d45eef270fd4b4@mail.gmail.com>

2009/7/15 Eric Cathelinaud <e.cathelinaud at googlemail.com>

> 2009/7/15 Harald Welte <laforge at gnumonks.org>
>
>>  On Wed, Jul 15, 2009 at 11:06:48AM +0200, Eric Cathelinaud wrote:
>> > 2009/7/10 Harald Welte <laforge at gnumonks.org>
>> >
>> > > On Fri, Jul 10, 2009 at 12:29:47PM +0200, Eric Cathelinaud wrote:
>> > > > Well i still have sometimes this error message. I have it when I
>> attach a
>> > > > mobile on the network.
>> > > > I saw 2 "unknow" packets comes from the Remote Network to the Remote
>> User
>> > > > during the attach process. Their size are quite small.
>> > > > I join in attached file a screen of my results.
>> > >
>> > > it would help if you can put the pcap file (with at least one good and
>> one
>> > > 'bad' packet) somewhere online or even send it to the list (if its
>> small
>> > > and you only select a couple of packets, you can attach it).
>> > >
>> > > --
>> > > - 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)
>> > >
>> >
>> >
>> > In the attached file there are 5 malformed packets and 2 unknow packets.
>>
>> just to make it clear: this pcap was generated using bsc_hack's pcap
>> option,
>> correct?  it seems like sometimes we write truncated packets to that file.
>>
>> There is a different method, using mISDN's debug tool (see
>> http://www.misdn.org/index.php/Debugtool).  I think if somebody can
>> confirm
>> this method works, i.e. use mISDNdebugtool to write a 'dumpfile' and then
>> open
>> that with wireshark, then we can actually remove the pcap code from
>> OpenBSC
>> altogether.
>>
>> Would you mind trying that method and report if you still see
>> broken/unknown
>> packets?
>>
>> 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)
>>
>
>
>  Ok i will try it and tell u ;-)
>
> Thanks
>
> Eric Cathelinaud
>

And yes the pcap file was coming from bsc_hack's pcap option
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090715/1df7e7b0/attachment.htm>

From e.cathelinaud at googlemail.com  Fri Jul 17 15:59:30 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Fri, 17 Jul 2009 17:59:30 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <383f8f9a0907151418k1773f0faid0d45eef270fd4b4@mail.gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<200907100249.35566.zecke@selfish.org>
	<383f8f9a0907100111x228aa0cbr28d7627b40aef88d@mail.gmail.com>
	<383f8f9a0907100205u2bd032c1pa44ae0208c8f67fe@mail.gmail.com>
	<383f8f9a0907100329w8738169tdfacaa5929553b14@mail.gmail.com>
	<20090710165820.GB11805@prithivi.gnumonks.org>
	<383f8f9a0907150206s15f472e7tbef55a44ad4bdb09@mail.gmail.com>
	<20090715184622.GY11272@prithivi.gnumonks.org>
	<383f8f9a0907151417i751af2bte66a12d242b4aebc@mail.gmail.com>
	<383f8f9a0907151418k1773f0faid0d45eef270fd4b4@mail.gmail.com>
Message-ID: <383f8f9a0907170859m5a6fe58ag28a9bfd4c30da633@mail.gmail.com>

2009/7/15 Eric Cathelinaud <e.cathelinaud at googlemail.com>

> 2009/7/15 Eric Cathelinaud <e.cathelinaud at googlemail.com>
>
>  2009/7/15 Harald Welte <laforge at gnumonks.org>
>>
>>>  On Wed, Jul 15, 2009 at 11:06:48AM +0200, Eric Cathelinaud wrote:
>>> > 2009/7/10 Harald Welte <laforge at gnumonks.org>
>>> >
>>> > > On Fri, Jul 10, 2009 at 12:29:47PM +0200, Eric Cathelinaud wrote:
>>> > > > Well i still have sometimes this error message. I have it when I
>>> attach a
>>> > > > mobile on the network.
>>> > > > I saw 2 "unknow" packets comes from the Remote Network to the
>>> Remote User
>>> > > > during the attach process. Their size are quite small.
>>> > > > I join in attached file a screen of my results.
>>> > >
>>> > > it would help if you can put the pcap file (with at least one good
>>> and one
>>> > > 'bad' packet) somewhere online or even send it to the list (if its
>>> small
>>> > > and you only select a couple of packets, you can attach it).
>>> > >
>>> > > --
>>> > > - 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)
>>> > >
>>> >
>>> >
>>> > In the attached file there are 5 malformed packets and 2 unknow
>>> packets.
>>>
>>> just to make it clear: this pcap was generated using bsc_hack's pcap
>>> option,
>>> correct?  it seems like sometimes we write truncated packets to that
>>> file.
>>>
>>> There is a different method, using mISDN's debug tool (see
>>> http://www.misdn.org/index.php/Debugtool).  I think if somebody can
>>> confirm
>>> this method works, i.e. use mISDNdebugtool to write a 'dumpfile' and then
>>> open
>>> that with wireshark, then we can actually remove the pcap code from
>>> OpenBSC
>>> altogether.
>>>
>>> Would you mind trying that method and report if you still see
>>> broken/unknown
>>> packets?
>>>
>>> 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)
>>>
>>
>>
>>  Ok i will try it and tell u ;-)
>>
>> Thanks
>>
>> Eric Cathelinaud
>>
>
> And yes the pcap file was coming from bsc_hack's pcap option



Hi,

I encounter problems using the debugtool from misdn.
I tried to follow the setup :
Setup

   1. Install the latest mISDN and mISDNuser. On how to obtain the sources,
   see GIT <http://www.misdn.org/index.php/GIT>.
   2. Configure the mISDN kernel modules. On how to do that, see
   Installing_mISDN <http://www.misdn.org/index.php/Installing_mISDN> and
   Configuring_mISDN <http://www.misdn.org/index.php/Configuring_mISDN>.
   3. Add the following line to you /etc/mISDN.conf:
   <module>mISDN_debugtool</module>
   4. Load the mISDN kernel modules via: mISDN start
   5. Enable the debugging facility (this is done automagically by
   mISDNdebugtool if started with no -n parameter): echo 1 >
   /sys/class/mISDN-debugtool/enabled
   6. Validate your setup by running the mISDNdebugtool user space program
   to capture all packets transmitted by the mISDNdebugtool kernel module and
   log them to stdout: mISDNdebugtool -v


But on step 3, I don't see the file mISDN.conf in /etc/
I can find it in the git but not complete like I can see on this link :
http://www.misdn.org/index.php/Configuring_mISDN
I only have the <mISDNconf> ... </mISDNconf> section.

In addition, I can t use any command from mISDN like mISDN start, mISDN scan
and so on.
In my kernel, I put mISDN as modular and I need to load them at each reboot
as follow to enable dslot=1 :
rmmod mISDN_core hfcmulti
modprobe mISDN_core
modprobe hfcmulti dslot=1


I still tried to compile the mISDN-debugtool.
But in /sys/class i have only a repertory for mISDN and nothing for
mISDN-debugtool. The file enabled doesn't exist too. But i think it's just a
file with a "1" inside. So i created it.

Now when i launch mISDNdebugtool -v it works but doesn't capture anything
and even doesn't create any file.
I think I have a problem since I didn't start the module mISDN_debugtool via
mISDN.conf. (step 3 & 4)

Thanks

Eric Cathelinaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090717/590efd03/attachment.htm>

From bouchtaoui at gmail.com  Mon Jul 27 12:11:56 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Mon, 27 Jul 2009 14:11:56 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <383f8f9a0907150206s15f472e7tbef55a44ad4bdb09@mail.gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>	<200907092020.01696.zecke@selfish.org>	<383f8f9a0907091402h7374d714v7bb0e25a0944665b@mail.gmail.com>	<200907100249.35566.zecke@selfish.org>	<383f8f9a0907100111x228aa0cbr28d7627b40aef88d@mail.gmail.com>	<383f8f9a0907100205u2bd032c1pa44ae0208c8f67fe@mail.gmail.com>	<383f8f9a0907100329w8738169tdfacaa5929553b14@mail.gmail.com>	<20090710165820.GB11805@prithivi.gnumonks.org>
	<383f8f9a0907150206s15f472e7tbef55a44ad4bdb09@mail.gmail.com>
Message-ID: <4A6D998C.5030109@gmail.com>

Hello guys,

I captured some data traffic between nanobts and openbsc with tcpdump 
and opened the pcap file in Wireshark under windows, as I don't have GUI 
on my Linux box (just a commandline shell). But unfortunately I can't 
get the data parsed in Abis mesaages.

I downloaded the latest developer's Wireshark 1.1.3, with no result. I 
know it's easy asking for an Abis-parser, but I thought there was a 
patch for it.

Thank you.



From zecke at selfish.org  Mon Jul 27 10:31:24 2009
From: zecke at selfish.org (Holger Freyther)
Date: Mon, 27 Jul 2009 12:31:24 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <4A6D998C.5030109@gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<383f8f9a0907150206s15f472e7tbef55a44ad4bdb09@mail.gmail.com>
	<4A6D998C.5030109@gmail.com>
Message-ID: <200907271231.25835.zecke@selfish.org>

On Monday 27 July 2009 14:11:56 Nordin wrote:
> Hello guys,
>
> I captured some data traffic between nanobts and openbsc with tcpdump
> and opened the pcap file in Wireshark under windows, as I don't have GUI
> on my Linux box (just a commandline shell). But unfortunately I can't
> get the data parsed in Abis mesaages.
>
> I downloaded the latest developer's Wireshark 1.1.3, with no result. I
> know it's easy asking for an Abis-parser, but I thought there was a
> patch for it.

Get the latest svn version. Compile it. Use tshark in case you don't have a 
GUI....

z.



From bouchtaoui at gmail.com  Mon Jul 27 12:56:32 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Mon, 27 Jul 2009 14:56:32 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <200907271231.25835.zecke@selfish.org>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>	<383f8f9a0907150206s15f472e7tbef55a44ad4bdb09@mail.gmail.com>	<4A6D998C.5030109@gmail.com>
	<200907271231.25835.zecke@selfish.org>
Message-ID: <4A6DA400.6080801@gmail.com>

Thanks,

But I'll check if Eric gets a complete view first.


Holger Freyther schreef:
> On Monday 27 July 2009 14:11:56 Nordin wrote:
>   
>> Hello guys,
>>
>> I captured some data traffic between nanobts and openbsc with tcpdump
>> and opened the pcap file in Wireshark under windows, as I don't have GUI
>> on my Linux box (just a commandline shell). But unfortunately I can't
>> get the data parsed in Abis mesaages.
>>
>> I downloaded the latest developer's Wireshark 1.1.3, with no result. I
>> know it's easy asking for an Abis-parser, but I thought there was a
>> patch for it.
>>     
>
> Get the latest svn version. Compile it. Use tshark in case you don't have a 
> GUI....
>
> z.
>
>
>   




From e.cathelinaud at googlemail.com  Mon Jul 27 12:33:56 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Mon, 27 Jul 2009 14:33:56 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <4A6D998C.5030109@gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<200907092020.01696.zecke@selfish.org>
	<383f8f9a0907091402h7374d714v7bb0e25a0944665b@mail.gmail.com>
	<200907100249.35566.zecke@selfish.org>
	<383f8f9a0907100111x228aa0cbr28d7627b40aef88d@mail.gmail.com>
	<383f8f9a0907100205u2bd032c1pa44ae0208c8f67fe@mail.gmail.com>
	<383f8f9a0907100329w8738169tdfacaa5929553b14@mail.gmail.com>
	<20090710165820.GB11805@prithivi.gnumonks.org>
	<383f8f9a0907150206s15f472e7tbef55a44ad4bdb09@mail.gmail.com>
	<4A6D998C.5030109@gmail.com>
Message-ID: <383f8f9a0907270533n3696859cj94e3d0d67356fc1e@mail.gmail.com>

Hi Nordin,

Do you think it's coming from Wireshark?
If you can send the pcap file, I can check with wireshark 1.0.8 on debian
and let you know. It works fine for me.

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090727/257e6d45/attachment.htm>

From bouchtaoui at gmail.com  Mon Jul 27 12:54:11 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Mon, 27 Jul 2009 14:54:11 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <383f8f9a0907270533n3696859cj94e3d0d67356fc1e@mail.gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>	
	<200907092020.01696.zecke@selfish.org>	
	<383f8f9a0907091402h7374d714v7bb0e25a0944665b@mail.gmail.com>	
	<200907100249.35566.zecke@selfish.org>	
	<383f8f9a0907100111x228aa0cbr28d7627b40aef88d@mail.gmail.com>	
	<383f8f9a0907100205u2bd032c1pa44ae0208c8f67fe@mail.gmail.com>	
	<383f8f9a0907100329w8738169tdfacaa5929553b14@mail.gmail.com>	
	<20090710165820.GB11805@prithivi.gnumonks.org>	
	<383f8f9a0907150206s15f472e7tbef55a44ad4bdb09@mail.gmail.com>	
	<4A6D998C.5030109@gmail.com>
	<383f8f9a0907270533n3696859cj94e3d0d67356fc1e@mail.gmail.com>
Message-ID: <4A6DA373.6030405@gmail.com>

Hi Eric,

This is what I get:
http://picasaweb.google.com/Bouchtaoui/ComputerScienceAndTelecommunication#5363121985533076994


Eric Cathelinaud schreef:
> Hi Nordin,
>
> Do you think it's coming from Wireshark?
> If you can send the pcap file, I can check with wireshark 1.0.8 on debian
> and let you know. It works fine for me.
>
> Eric
>
>   




From bouchtaoui at gmail.com  Wed Jul 29 15:31:03 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Wed, 29 Jul 2009 17:31:03 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <383f8f9a0907270624j48bbb9b5hf0159adf11a27d26@mail.gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>	
	<383f8f9a0907100205u2bd032c1pa44ae0208c8f67fe@mail.gmail.com>	
	<383f8f9a0907100329w8738169tdfacaa5929553b14@mail.gmail.com>	
	<20090710165820.GB11805@prithivi.gnumonks.org>	
	<383f8f9a0907150206s15f472e7tbef55a44ad4bdb09@mail.gmail.com>	
	<4A6D998C.5030109@gmail.com>	
	<383f8f9a0907270533n3696859cj94e3d0d67356fc1e@mail.gmail.com>	
	<4A6DA177.6040206@gmail.com>	
	<383f8f9a0907270612q35a945cdv6a79151ebbda065e@mail.gmail.com>	
	<4A6DAA30.1010803@gmail.com>
	<383f8f9a0907270624j48bbb9b5hf0159adf11a27d26@mail.gmail.com>
Message-ID: <4A706B37.9050603@gmail.com>

Hello Harald,

Should the plugin you added for Wireshark decode almost all messages or 
not? Cause on the OML layer a lot of OML messages are not decoded, is 
this behaviour normal?

I now try to follow the communication flow, but can't seem to understand 
the multiple  OML messages. It starts with 0x00, than a datalen and than 
protocol (0xFF) and than it starts with 0x80, 0x80,.... But I can't find 
0x80 (messagetype) in OpenBSC source. I've checked ipaccess.h and 
ipaccess.c, but nothing...maybe I lokked at the wrong place.




From laforge at gnumonks.org  Wed Jul 29 16:02:41 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 29 Jul 2009 18:02:41 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <4A706B37.9050603@gmail.com>
References: <383f8f9a0907100329w8738169tdfacaa5929553b14@mail.gmail.com>
	<20090710165820.GB11805@prithivi.gnumonks.org>
	<383f8f9a0907150206s15f472e7tbef55a44ad4bdb09@mail.gmail.com>
	<4A6D998C.5030109@gmail.com>
	<383f8f9a0907270533n3696859cj94e3d0d67356fc1e@mail.gmail.com>
	<4A6DA177.6040206@gmail.com>
	<383f8f9a0907270612q35a945cdv6a79151ebbda065e@mail.gmail.com>
	<4A6DAA30.1010803@gmail.com>
	<383f8f9a0907270624j48bbb9b5hf0159adf11a27d26@mail.gmail.com>
	<4A706B37.9050603@gmail.com>
Message-ID: <20090729160241.GT1434@prithivi.gnumonks.org>

On Wed, Jul 29, 2009 at 05:31:03PM +0200, Nordin wrote:
> Hello Harald,
> 
> Should the plugin you added for Wireshark decode almost all messages
> or not? Cause on the OML layer a lot of OML messages are not
> decoded, is this behaviour normal?

there is a oml decoder plugin, I've posted it to this list, it is in our git
tree and it is mentioned in the wiki, so it should be pretty easy to find.

> I now try to follow the communication flow, but can't seem to
> understand the multiple  OML messages. It starts with 0x00, than a
> datalen and than protocol (0xFF) and than it starts with 0x80,
> 0x80,.... But I can't find 0x80 (messagetype) in OpenBSC source.
> I've checked ipaccess.h and ipaccess.c, but nothing...maybe I lokked
> at the wrong place.

oml is implemented in abis_nm.c

-- 
- 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 Jul 29 20:43:55 2009
From: bouchtaoui at gmail.com (Nordin Bouchtaoui)
Date: Wed, 29 Jul 2009 22:43:55 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <20090729160241.GT1434@prithivi.gnumonks.org>
References: <383f8f9a0907100329w8738169tdfacaa5929553b14@mail.gmail.com>
	<383f8f9a0907150206s15f472e7tbef55a44ad4bdb09@mail.gmail.com>
	<4A6D998C.5030109@gmail.com>
	<383f8f9a0907270533n3696859cj94e3d0d67356fc1e@mail.gmail.com>
	<4A6DA177.6040206@gmail.com>
	<383f8f9a0907270612q35a945cdv6a79151ebbda065e@mail.gmail.com>
	<4A6DAA30.1010803@gmail.com>
	<383f8f9a0907270624j48bbb9b5hf0159adf11a27d26@mail.gmail.com>
	<4A706B37.9050603@gmail.com>
	<20090729160241.GT1434@prithivi.gnumonks.org>
Message-ID: <8aedb85a0907291343h352f778dkdd6c43d6813c40fb@mail.gmail.com>

Sorry Harald,

Should read the info on the wiki better. And also the debugging output
reveals some info. Anyway thanks.



2009/7/29 Harald Welte <laforge at gnumonks.org>

> On Wed, Jul 29, 2009 at 05:31:03PM +0200, Nordin wrote:
> > Hello Harald,
> >
> > Should the plugin you added for Wireshark decode almost all messages
> > or not? Cause on the OML layer a lot of OML messages are not
> > decoded, is this behaviour normal?
>
> there is a oml decoder plugin, I've posted it to this list, it is in our
> git
> tree and it is mentioned in the wiki, so it should be pretty easy to find.
>
> > I now try to follow the communication flow, but can't seem to
> > understand the multiple  OML messages. It starts with 0x00, than a
> > datalen and than protocol (0xFF) and than it starts with 0x80,
> > 0x80,.... But I can't find 0x80 (messagetype) in OpenBSC source.
> > I've checked ipaccess.h and ipaccess.c, but nothing...maybe I lokked
> > at the wrong place.
>
> oml is implemented in abis_nm.c
>
> --
> - 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/20090729/52bc537c/attachment.htm>

From zecke at selfish.org  Thu Jul 30 00:50:10 2009
From: zecke at selfish.org (Holger Freyther)
Date: Thu, 30 Jul 2009 02:50:10 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <4A706B37.9050603@gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<383f8f9a0907270624j48bbb9b5hf0159adf11a27d26@mail.gmail.com>
	<4A706B37.9050603@gmail.com>
Message-ID: <200907300250.10730.zecke@selfish.org>

On Wednesday 29 July 2009 17:31:03 Nordin wrote:
> Hello Harald,
>
> Should the plugin you added for Wireshark decode almost all messages or
> not? Cause on the OML layer a lot of OML messages are not decoded, is
> this behaviour normal?


Feel free to upload your pcap file somewhere so we can take a look.



From bouchtaoui at gmail.com  Thu Jul 30 08:55:49 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Thu, 30 Jul 2009 10:55:49 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <200907300250.10730.zecke@selfish.org>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>	<383f8f9a0907270624j48bbb9b5hf0159adf11a27d26@mail.gmail.com>	<4A706B37.9050603@gmail.com>
	<200907300250.10730.zecke@selfish.org>
Message-ID: <4A716015.4060908@gmail.com>

Hi Holger,

Thnx for your offer, there is nothing to look at it than just an 
initialization process on the OML layer.
It decodes some OML messages but not all, the RSL messages are decoded 
well I think, can't completely confirm that.

For me it's important to follow the procedure of the nanobts up and 
running before handling RSL messages.
Harald posted me some traces for scanning neighbouring cells, which I 
think is important to fill the BA List.
But according to Harald these were ip.access specific messages, so how 
am I suppose to interpret that? I mean which bytes indicates a 
neighbouring cell, or how am I suppose to understand the meaning of 
certain bytes i.e. dBm level of a certain neigbouring cell and which 
ARFCN? It's like reading a piece of Frenche text without having a 
dictionarry (well, I understand a little bit french :-) ).

I don't know how you, Harald and others interpretted the messages during 
reverse-engineering. Cause I assume you don't have any technical 
documents about ip.access specific messages, except the GSM specs and 
some own experience?

Kind regards,

Nordin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abis2.pcap
Type: application/octet-stream
Size: 21147 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090730/65ff43b2/attachment.obj>

From laforge at gnumonks.org  Thu Jul 30 21:10:03 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 30 Jul 2009 23:10:03 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <4A716015.4060908@gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<383f8f9a0907270624j48bbb9b5hf0159adf11a27d26@mail.gmail.com>
	<4A706B37.9050603@gmail.com> <200907300250.10730.zecke@selfish.org>
	<4A716015.4060908@gmail.com>
Message-ID: <20090730211003.GH24787@prithivi.gnumonks.org>

On Thu, Jul 30, 2009 at 10:55:49AM +0200, Nordin wrote:
> Hi Holger,
> 
> Thnx for your offer, there is nothing to look at it than just an
> initialization process on the OML layer.
> It decodes some OML messages but not all, 

Can you please indicate which OML messages (packet number in your pcap) are not
decoded well?  It looks quite fine for me here.  Also, I think it should
be pretty straight forward to look at the 12.21 spec and extend the
packet-gsm_abis_oml.c code in wireshark.  We need more people working on this
than just me ;)

> Harald posted me some traces for scanning neighbouring cells, which
> I think is important to fill the BA List.

Why would you need that?  If you run your own network, then you know the
neighbouring cells at the BSC and you can fill it from there.

If you want to operate a rouge BTS for security research or in imsi-catcher
style applications, then you probably don't want to fill neighbor cell
information in the syste info messages, since that would tell the phones
how to easily get away from your rogue cell (which you typically don't want)

> But according to Harald these were ip.access specific messages, so
> how am I suppose to interpret that? I mean which bytes indicates a
> neighbouring cell, or how am I suppose to understand the meaning of
> certain bytes i.e. dBm level of a certain neigbouring cell and which
> ARFCN? It's like reading a piece of Frenche text without having a
> dictionarry (well, I understand a little bit french :-) ).

Yes, that's exactly it.  That's how the samba developers first implemented the
SMB protocol of windows filesharing, and that's how we write OpenBSC and
wireshark code for nanoBTS.

Also, the abis-oml.patch already includes support for parsing the test result
messages of a nanoBTS.  See dissect_ipacc_test_rep() as well as
ipacc_tr_ie_chan_usage and ipacc_tr_ie_bcch() in the attached patch.

> I don't know how you, Harald and others interpretted the messages
> during reverse-engineering. Cause I assume you don't have any
> technical documents about ip.access specific messages, except the
> GSM specs and some own experience?

No, we don't have other documentatio.  Just our common sense :)

-- 
- 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 Jul 31 08:30:05 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Fri, 31 Jul 2009 10:30:05 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <20090730211003.GH24787@prithivi.gnumonks.org>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<383f8f9a0907270624j48bbb9b5hf0159adf11a27d26@mail.gmail.com>
	<4A706B37.9050603@gmail.com> <200907300250.10730.zecke@selfish.org>
	<4A716015.4060908@gmail.com>
	<20090730211003.GH24787@prithivi.gnumonks.org>
Message-ID: <4A72AB8D.8020601@gmail.com>


> Can you please indicate which OML messages (packet number in your pcap) are not
> decoded well?

I think all OML messages. The ipaccess-specific and RSL are decoded well.
But I run Wireshark under windows, so I guess it's not provided with 
your latest patches.

> Also, I think it should be pretty straight forward to look at the 12.21 spec and extend the
> packet-gsm_abis_oml.c code in wireshark.  We need more people working on this
> than just me ;)
>   

Yes, it is straightforward. I really do my best to get some time free to 
extend the decodings for Wireshark and I really like to cooperate to 
help the project.

> Why would you need that?  If you run your own network, then you know the
> neighbouring cells at the BSC and you can fill it from there.
>   

Well, if you reject a MS, it will be left with an empty BA list, so I 
guess it starts scanning all over again for a BTS to register. But if 
the MS has a BA list, it can, after it is rejected, reselect for antoher 
bts/arfcn. So in this way, I can accept my own MS and reject others, 
without disturbing the others. And I can play with my MS and see how our 
bsc behaves and, who knows, find a security leak?

> If you want to operate a rouge BTS for security research or in imsi-catcher
> style applications, then you probably don't want to fill neighbor cell
> information in the syste info messages, since that would tell the phones
> how to easily get away from your rogue cell (which you typically don't want)
>   

For me it's more important to learn understanding the GSM technique, how 
to read a documentation, how to program in Linux, how to develope with a 
community, how to use git, how to analyze data packets using Wireshark 
and tcpdump, how to create a project with Autotools, etc... :)
I'm undergoing a transformation from Windows developer to Linux 
developer. I'm like Jetfire from Transformer II, leaving the Decepticons 
for becoming an Autobot :p

> Yes, that's exactly it.  That's how the samba developers first implemented the
> SMB protocol of windows filesharing, and that's how we write OpenBSC and
> wireshark code for nanoBTS.
>   

So, you guys like challenges :)

> Also, the abis-oml.patch already includes support for parsing the test result
> messages of a nanoBTS.  See dissect_ipacc_test_rep() as well as
> ipacc_tr_ie_chan_usage and ipacc_tr_ie_bcch() in the attached patch.
>   

My Linux is just command-line for now, so I run Wireshark GUI in windows.

> No, we don't have other documentatio.  Just our common sense :)
>   

And a bit of sense of humor... :)






From bouchtaoui at gmail.com  Fri Jul 31 13:23:53 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Fri, 31 Jul 2009 15:23:53 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <4A72AB8D.8020601@gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<383f8f9a0907270624j48bbb9b5hf0159adf11a27d26@mail.gmail.com>
	<4A706B37.9050603@gmail.com> <200907300250.10730.zecke@selfish.org>
	<4A716015.4060908@gmail.com>
	<20090730211003.GH24787@prithivi.gnumonks.org>
	<4A72AB8D.8020601@gmail.com>
Message-ID: <4A72F069.7060506@gmail.com>

Hi guys,

In GSM 12.21 there is a mistype. In par. 8.8.1 State Changed Event 
Report, it says Length of Availability Status is >= 2, but actually it's 
 >=4. Cause if you look at part. 9.4.7, you have 1 octet for Attr. Id. 
(T), 2 octets of Length (L) and Avail. State (V), which could contain 
one or more octets.

I found this fault when I was analyzing pcap with Wireshark and gsm 
spec. 12.21.




From laforge at gnumonks.org  Fri Jul 31 20:19:04 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 31 Jul 2009 22:19:04 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <4A72AB8D.8020601@gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<383f8f9a0907270624j48bbb9b5hf0159adf11a27d26@mail.gmail.com>
	<4A706B37.9050603@gmail.com> <200907300250.10730.zecke@selfish.org>
	<4A716015.4060908@gmail.com>
	<20090730211003.GH24787@prithivi.gnumonks.org>
	<4A72AB8D.8020601@gmail.com>
Message-ID: <20090731201904.GA4216@prithivi.gnumonks.org>

Hi Nordin.
On Fri, Jul 31, 2009 at 10:30:05AM +0200, Nordin wrote:
 
> >Can you please indicate which OML messages (packet number in your pcap) are not
> >decoded well?
> 
> I think all OML messages. The ipaccess-specific and RSL are decoded well.
> But I run Wireshark under windows, so I guess it's not provided with
> your latest patches.

if you patched and compiled it yourself, then it is 'provided' with my patches.
If you do something else, then please be very clear in your e-mails, as I
really don't want to spend time trying to figure out what kind of problems
there are with decoding your packets - when in fact there are none.  There are
more efficient ways how I can spend my time.  No offence taken, but please keep
this in mind for the future.

> Yes, it is straightforward. I really do my best to get some time
> free to extend the decodings for Wireshark and I really like to
> cooperate to help the project.
> 
> >Why would you need that?  If you run your own network, then you know the
> >neighbouring cells at the BSC and you can fill it from there.
> 
> Well, if you reject a MS, it will be left with an empty BA list, so
> I guess it starts scanning all over again for a BTS to register. But
> if the MS has a BA list, it can, after it is rejected, reselect for
> antoher bts/arfcn. So in this way, I can accept my own MS and reject
> others, without disturbing the others. And I can play with my MS and
> see how our bsc behaves and, who knows, find a security leak?

please note that this would mean that you yourself are using the same MCC/MNC
of an existing commercial network.  I can only state my utmost concern about
this.  Do not interfere with actual GSM networks without the permission/knowledge
of that very operator!  In most countries interference with public
telecommunications services is quite significant offence.

> >If you want to operate a rouge BTS for security research or in imsi-catcher
> >style applications, then you probably don't want to fill neighbor cell
> >information in the syste info messages, since that would tell the phones
> >how to easily get away from your rogue cell (which you typically don't want)
> 
> For me it's more important to learn understanding the GSM technique,
> how to read a documentation, how to program in Linux, how to
> develope with a community, how to use git, how to analyze data
> packets using Wireshark and tcpdump, how to create a project with
> Autotools, etc... :)

> I'm undergoing a transformation from Windows developer to Linux
> developer. I'm like Jetfire from Transformer II, leaving the
> Decepticons for becoming an Autobot :p

you don't really need all of that, at least with the nanoBTS:  Dieter is
running OpenBSC happily on Windows.  Still, the open source experience /
learning curve remains - it's just no longer related to Linux itself.

> >Yes, that's exactly it.  That's how the samba developers first implemented the
> >SMB protocol of windows filesharing, and that's how we write OpenBSC and
> >wireshark code for nanoBTS.
> 
> So, you guys like challenges :)

I would love to have documentation.  But as we can see by those examples, it
is not a strict requirements.  By implementing it anyway, even without public
documentation we basicall say: Your security by obscurity or "keep the
competition away by obscurity" kind of model does not work. Next time you might
disclose the documentation right from the beginning.

> >Also, the abis-oml.patch already includes support for parsing the test result
> >messages of a nanoBTS.  See dissect_ipacc_test_rep() as well as
> >ipacc_tr_ie_chan_usage and ipacc_tr_ie_bcch() in the attached patch.
> 
> My Linux is just command-line for now, so I run Wireshark GUI in windows.

Even on Windows you can take wireshark sources, patch them and compile them!

-- 
- 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 Jul 31 14:43:29 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Fri, 31 Jul 2009 16:43:29 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <20090730211003.GH24787@prithivi.gnumonks.org>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<383f8f9a0907270624j48bbb9b5hf0159adf11a27d26@mail.gmail.com>
	<4A706B37.9050603@gmail.com> <200907300250.10730.zecke@selfish.org>
	<4A716015.4060908@gmail.com>
	<20090730211003.GH24787@prithivi.gnumonks.org>
Message-ID: <4A730311.1050208@gmail.com>

Hi Harald,

You once posted a pcap of a "Network Listen" process of the ip.access 
nanoBTS, I think.
If I anlyze the traffic, I can't find any messages leading to "Network 
Listen" activities.
According to the nanobts product spec. "Network Listen" is an ip.access 
specific message, so when looking at 0xfe (ipaccess) I only see the 
Ping/Pong messages.

In GSM 12.21 I couldn't find something about scanning or listening for 
other ARFCNs. But it's possible I haven't read the spec well or didn't 
understand completely.

Any idea's?




From laforge at gnumonks.org  Fri Jul 31 20:39:51 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 31 Jul 2009 22:39:51 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <4A730311.1050208@gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<383f8f9a0907270624j48bbb9b5hf0159adf11a27d26@mail.gmail.com>
	<4A706B37.9050603@gmail.com> <200907300250.10730.zecke@selfish.org>
	<4A716015.4060908@gmail.com>
	<20090730211003.GH24787@prithivi.gnumonks.org>
	<4A730311.1050208@gmail.com>
Message-ID: <20090731203951.GC4216@prithivi.gnumonks.org>

On Fri, Jul 31, 2009 at 04:43:29PM +0200, Nordin wrote:
> Hi Harald,
> 
> You once posted a pcap of a "Network Listen" process of the
> ip.access nanoBTS, I think.
> If I anlyze the traffic, I can't find any messages leading to
> "Network Listen" activities.
> According to the nanobts product spec. "Network Listen" is an
> ip.access specific message, so when looking at 0xfe (ipaccess) I
> only see the Ping/Pong messages.

you are misreading the product spec.  network listen is implemented as 'perform
test' and 'test report', well within 12.21.  the 12.21 spec just doesn't tell
you what the test numbers are, and how the result data is formatted.

-- 
- 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 Jul 30 11:00:46 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Thu, 30 Jul 2009 13:00:46 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <200907300250.10730.zecke@selfish.org>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>	<383f8f9a0907270624j48bbb9b5hf0159adf11a27d26@mail.gmail.com>	<4A706B37.9050603@gmail.com>
	<200907300250.10730.zecke@selfish.org>
Message-ID: <4A717D5E.5050200@gmail.com>

Hi,

according to the wiki for the nanobts:

    * 0x00 RSL messages as per GSM 08.58
    * 0xfe ip.access specific messages
    * 0xff OML messages as per GSM 12.21

I assume this is the so called SAPI?
Cause I read some Abis articles that for RSL and OML is resp. 0 and 62.
I just want to be sure there are some value differences.
thank you.


Holger Freyther schreef:
> On Wednesday 29 July 2009 17:31:03 Nordin wrote:
>   
>> Hello Harald,
>>
>> Should the plugin you added for Wireshark decode almost all messages or
>> not? Cause on the OML layer a lot of OML messages are not decoded, is
>> this behaviour normal?
>>     
>
>
> Feel free to upload your pcap file somewhere so we can take a look.
>
>
>   




From laforge at gnumonks.org  Thu Jul 30 21:03:05 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 30 Jul 2009 23:03:05 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <4A717D5E.5050200@gmail.com>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<383f8f9a0907270624j48bbb9b5hf0159adf11a27d26@mail.gmail.com>
	<4A706B37.9050603@gmail.com> <200907300250.10730.zecke@selfish.org>
	<4A717D5E.5050200@gmail.com>
Message-ID: <20090730210305.GG24787@prithivi.gnumonks.org>

On Thu, Jul 30, 2009 at 01:00:46PM +0200, Nordin wrote:
> Hi,
> 
> according to the wiki for the nanobts:
> 
>    * 0x00 RSL messages as per GSM 08.58
>    * 0xfe ip.access specific messages
>    * 0xff OML messages as per GSM 12.21
> 
> I assume this is the so called SAPI?

no. SAPI only exists in E1 based A-bis.

> Cause I read some Abis articles that for RSL and OML is resp. 0 and 62.
> I just want to be sure there are some value differences.

A-bis over E1 is what the BS-11 uses.  ip.access has their own proprietary
protocol stacking and A-bis dialect.  There is no public documentation about
it, apart from what we deducted from protocol traces and implemented in OpenBSC
/ wireshark and put into the OpenBSC wiki.

In any case, the Layer 2 (Q.921 on E1, with TEI and SAPI) is completely 
uninteresting.  All you should care about is layer 3 (12.21 OML and 08.58 RSL).

Whatever is below is the transport layer and does not actually have any actual impact on the GSM netwokr

-- 
- 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 Jul 31 07:57:58 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Fri, 31 Jul 2009 09:57:58 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <20090730210305.GG24787@prithivi.gnumonks.org>
References: <383f8f9a0907090723te634c39gdcef0d44abdeb81f@mail.gmail.com>
	<383f8f9a0907270624j48bbb9b5hf0159adf11a27d26@mail.gmail.com>
	<4A706B37.9050603@gmail.com> <200907300250.10730.zecke@selfish.org>
	<4A717D5E.5050200@gmail.com>
	<20090730210305.GG24787@prithivi.gnumonks.org>
Message-ID: <4A72A406.1040302@gmail.com>


> no. SAPI only exists in E1 based A-bis.
>   

Pfff, I was going crazy...

> A-bis over E1 is what the BS-11 uses.  ip.access has their own proprietary
> protocol stacking and A-bis dialect.  There is no public documentation about
> it, apart from what we deducted from protocol traces and implemented in OpenBSC
> / wireshark and put into the OpenBSC wiki.
>   

Damn, did you had a lot of cola and chips? :p

> In any case, the Layer 2 (Q.921 on E1, with TEI and SAPI) is completely 
> uninteresting.  All you should care about is layer 3 (12.21 OML and 08.58 RSL).
>   

Yeah, I kind of figured that out now.




From spaar at mirider.augusta.de  Mon Jul 27 14:56:16 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Mon, 27 Jul 2009 14:56:16 CEST
Subject: wireshark, viewing Abis communication
Message-ID: <4a6dc010.mirider@mirider.augusta.de>

Hello Nordin,

On Mon, 27 Jul 2009 14:11:56 +0200, "Nordin" <bouchtaoui at gmail.com> wrote:
> 
> I downloaded the latest developer's Wireshark 1.1.3, with no result. I 
> know it's easy asking for an Abis-parser, but I thought there was a 
> patch for it.

If you take one of the latest daily automated Wireshark builds it
will work, even on Windows. No need to compile the sources if
you don't want to. I use "1.3.0-SVN-29061" and it contains Harald's
patch for the nanoBTS.

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



From bouchtaoui at gmail.com  Mon Jul 27 13:10:26 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Mon, 27 Jul 2009 15:10:26 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <4a6dc010.mirider@mirider.augusta.de>
References: <4a6dc010.mirider@mirider.augusta.de>
Message-ID: <4A6DA742.6070004@gmail.com>


> If you take one of the latest daily automated Wireshark builds it
> will work, even on Windows. No need to compile the sources if
> you don't want to. I use "1.3.0-SVN-29061" and it contains Harald's
> patch for the nanoBTS.
>   

I thought I already had the latest version, wrong. I am now downloading 
the latest version, I hope this will solve my problem. Thank  you!




From bouchtaoui at gmail.com  Mon Jul 27 13:21:06 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Mon, 27 Jul 2009 15:21:06 +0200
Subject: wireshark, viewing Abis communication
In-Reply-To: <4a6dc010.mirider@mirider.augusta.de>
References: <4a6dc010.mirider@mirider.augusta.de>
Message-ID: <4A6DA9C2.8000509@gmail.com>

Problems solved! The latest version Wireshark (1.3.0 29201) did the trick.
It's cool, Harald did a nice job man, hahaha.
Thanks guys.


Dieter Spaar schreef:
> Hello Nordin,
>
> On Mon, 27 Jul 2009 14:11:56 +0200, "Nordin" <bouchtaoui at gmail.com> wrote:
>   
>> I downloaded the latest developer's Wireshark 1.1.3, with no result. I 
>> know it's easy asking for an Abis-parser, but I thought there was a 
>> patch for it.
>>     
>
> If you take one of the latest daily automated Wireshark builds it
> will work, even on Windows. No need to compile the sources if
> you don't want to. I use "1.3.0-SVN-29061" and it contains Harald's
> patch for the nanoBTS.
>
> Best regards,
>   Dieter
>   




From laforge at gnumonks.org  Fri Jul 10 21:17:56 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 10 Jul 2009 23:17:56 +0200
Subject: ip.access Abis-over-IP dissector now part of wireshark
Message-ID: <20090710211756.GN11805@prithivi.gnumonks.org>

Hi!

JFYI: My dissector for the Abis-IP adaption layer of ip.access has been merged
into wireshark (as of svn revision 29059).

-- 
- 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 Jul 11 20:03:30 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Sat, 11 Jul 2009 20:03:30 CEST
Subject: Authentication and Encryption
Message-ID: <4a58f012.mirider@mirider.augusta.de>

Hello,

I did a few tests with Authentication and Encryption. Its just
a quick hack and nothing which can be integrated into OpenBSC
in a clean way but the process was rather straightforward:

  - For my tests I used the location update request.

  - I sent the AUTHENTICATION REQUEST to the MS.

  - When I received the AUTHENTICATION RESPONSE from the MS, I
    compared SRES with the expected value. If the expected value
    was received, I send the ENCRYPTION COMMAND with Kc to the
    BTS. If the wrong SRES was received, I send an AUTHENTICATION
    REJECT to the MS.

  - The BTS will now send the CIPHERING MODE COMMAND to
    the MS and activate encryption.

  - The CIPHERING MODE COMPLETE command from the MS will already
    be received encrypted.

I have not recorded the RF traffic to check if encryption is really
enabled. But the Nokia Netmonitor indicated encryption, additionally
if I send the wrong Kc in the ENCRYPTION COMMAND, the location update
does not complete.

I have not tested speech traffic yet, but it most certainly works the
same way.

One thing which might be interesting is how to get SRES and Kc because
the A3/A8 algorithm on the SIM is usually not known. There are a few ways
how to do it:

  - one could record a few results from a SIM and only send RAND values
    where the pre-recorded results are known.

  - the SIM communication could be intercepted (for example with a
    device like the "Turbo Lite" from www.bladox.com) and if the APDU for
    authentication is sent, one can run its own A3/A8 algorithm instead of
    the one from the card.

  - if one has a SIM with the broken and known COMP128, its possible
    to find Ki so that the authentication response from the card can
    be calculated.

  - Test SIMs (for GSM Test Equipment) have implemented a know
    A3/A8 algorithm (XOR) and so the authentication response can
    be calculated.

  - One can buy one of those SIM clone cards (they are called Super-SIM
    Magic-SIM, 16in1 SIM or similar). They are of not much use for official
    networks because only a few (if any) providers use COMP128 any more
    and this is the algorithm those card implement (and expect it to be in
    the card which should be cloned). You can buy such SIM cards rather cheap
    (around 5 Euro). They usually come with a software (Windows) which allows
    to set the IMSI and Ki for COMP128. So you have a card with a know
    A3/A8 algorithm (COMP128) and a know Ki.

I used one of those SIM clone cards for my experiments, the SIM worked
fine in an older Nokia 3310 (at least for this test). I don't know how
well it will work in other phones but for this rathe low price its
probably worth a try.

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



From laforge at gnumonks.org  Sun Jul 12 14:02:11 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 12 Jul 2009 16:02:11 +0200
Subject: Authentication and Encryption
In-Reply-To: <4a58f012.mirider@mirider.augusta.de>
References: <4a58f012.mirider@mirider.augusta.de>
Message-ID: <20090712140211.GT11805@prithivi.gnumonks.org>

Hi Dieter,

On Sat, Jul 11, 2009 at 08:03:30PM +0200, Dieter Spaar wrote:
 
> I did a few tests with Authentication and Encryption. Its just
> a quick hack and nothing which can be integrated into OpenBSC
> in a clean way but the process was rather straightforward:

Thanks a lot for your investigation.  Are you planning to take it beyond the
hack and do a clean implementation that we can merge at some point?

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 spaar at mirider.augusta.de  Sun Jul 12 16:50:48 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Sun, 12 Jul 2009 16:50:48 CEST
Subject: Authentication and Encryption
Message-ID: <4a5a1468.mirider@mirider.augusta.de>

Hello Harald,

On Sun, 12 Jul 2009 16:02:11 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> 
> Thanks a lot for your investigation.  Are you planning to take it beyond the
> hack and do a clean implementation that we can merge at some point?

To implement it in a clean way in my opinion requires some discussion
about how to do it so that it fits into the architecture:

  - When do the authentication, most certainly during the first
    Loacation Update, but when else ?

  - Where to store the subscriber Ki for authentication and the
    information about which algorithm is used ? Also store for each
    subscriber if authentication and/or encryption should to be used.

  - Where to cache Kc, its not necessary to authenticate every time when
    encryption for a channel is turned on. Kc from a previous
    authentication can be used several times.

  - Where to turn on encryption, every time a channel is allocated ?

Those are just a few thoughts. I guess discussion about the details
probably takes longer than if you or Holger implement it during your
ongoing work on OpenBSC. Currently you both are the main people working
on OpenBSC at several places of the implementation and a clean integration
of authentication and encryption affects a lot of those places too. I am
reluctant to interfere here, not because of the time it takes (its not
that much) but because any changes should fit to what you plan to
do. If anyone want to see the technical details, I can provide them,
its rather simple and straightforward.

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



From laforge at gnumonks.org  Sun Jul 12 16:21:08 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 12 Jul 2009 18:21:08 +0200
Subject: Authentication and Encryption
In-Reply-To: <4a5a1468.mirider@mirider.augusta.de>
References: <4a5a1468.mirider@mirider.augusta.de>
Message-ID: <20090712162107.GU11805@prithivi.gnumonks.org>

Hi Dieter,

On Sun, Jul 12, 2009 at 04:50:48PM +0200, Dieter Spaar wrote:
> To implement it in a clean way in my opinion requires some discussion
> about how to do it so that it fits into the architecture:
> 
>   - When do the authentication, most certainly during the first
>     Loacation Update, but when else ?

I think first location update (until imsi detach) is fine for now. It
can always be extended later on.

What's probably more important is to enable the encryption (CIPHERING MODE
COMMAND) for every radio channel that we establish for that MS.

The entire auth+crypto should be enabled/disabled by a global switch, in
case somebody wants to typically have it, but disable it temporarily
in order to be able to obtain plaintext Um interface traces.

>   - Where to store the subscriber Ki for authentication and the
>     information about which algorithm is used ? Also store for each
>     subscriber if authentication and/or encryption should to be used.

yes, each subscriber needs the following information:
* which auth algorithm to use (none,xor,comp128v1)
* which crypto algorithm to use (a5/0,1,2)
* the secret data (Ki) for that particular algorithm
* the currently-allocated Kc

I would simply also store all that it in the sqlite database.

It makes sense to put all this authentication related information into
a separate table, indexed and referenced by the subscriber ID.  The rationale
is that later (when using real SQL databases) we might want to have different
permissions on the regular subscriber data than on the authentication data.

>   - Where to cache Kc, its not necessary to authenticate every time when
>     encryption for a channel is turned on. Kc from a previous
>     authentication can be used several times.

yes.  I think a typical value in production networks is: something like 4 calls
/ sms and then re-authenticate.  The Kc should be cached in the sqlite
database, too.

>   - Where to turn on encryption, every time a channel is allocated ?

yes, of course only if the subscriber database indicates that this subscriber
is to use encryption.

> Those are just a few thoughts. I guess discussion about the details
> probably takes longer than if you or Holger implement it during your
> ongoing work on OpenBSC. 

I'm not so sure about that.  I'm very busy and have a long todo list, so I'm
always happy to see somebody else taking care of relatively self-contained
features...

> Currently you both are the main people working on OpenBSC at several places
> of the implementation and a clean integration of authentication and
> encryption affects a lot of those places too. I am reluctant to interfere
> here, not because of the time it takes (its not that much) but because any
> changes should fit to what you plan to do. If anyone want to see the
> technical details, I can provide them, its rather simple and straightforward.

Mh. If Holger thinks it is causing interference with his work, I think we
should probably delay encryption/authentication until the BSC/MSC functional
split has been matured and merged in the code.

As for myself, I'm doing a lot of GSM related work right now, but it's not
actually extending OpenBSC that much, more reverse engineering some more bits
about the ip.access protocol extensions, writing wireshark code, as well as
work on a A-bis proxy (between BTS and BSC), allowing for OML and RSL packet
injection into the live connection, as well as a scapy plugin for
crafting/fuzzing 04.08, RSL and OML packets.  Using that infrastructure it
should be possible to do a lot of things such as
* fuzzing packets sent to the MS (MS software stability)
* fuzzing packets sent to the BTS (BTS software stability)
* fuzzing packets sent to BSC/MSC (network software stability)

Among other things, this can also be used to generate test cases for OpenBSC
and to work on OpenBSC protocol parsing stability, too.

The only part of OpenBSC that I plan to work on during the next weeks is
the SMS implementation and system information generation.  And if I find more
time after that, GPRS.

None of that should clash with support for encryption/authentication.
-- 
- 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 mailman-bounces at lists.gnumonks.org  Tue Jul 14 07:00:02 2009
From: mailman-bounces at lists.gnumonks.org (mailman-bounces at lists.gnumonks.org)
Date: Tue, 14 Jul 2009 09:00:02 +0200
Subject: OpenBSC unsubscribe notification
Message-ID: <mailman.1.1247554802.8342.openbsc@lists.gnumonks.org>

pylon at koeln.ccc.de has been removed from OpenBSC.



From laforge at gnumonks.org  Fri Jul 17 18:06:01 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 17 Jul 2009 20:06:01 +0200
Subject: mISDNdebugtool status
Message-ID: <20090717180601.GR31421@sunbeam.hmw-consulting.de>

Hi Andreas,

since youre experience with mISDN is much better than mine,

can you comment on the status of mISDNdebugtool?  As it seems, Eric is having
some problems using it.  Also, in current mISDNuser.git (socket branch),
it doesn't compile since mISDNdebugtool.h is missing.

What we're trying to do is to generate pcap files that we can throw at wireshark.

Thanks in advance,
-- 
- Harald Welte <laforge at gnumonks.org>          	        http://gnumonks.org/
============================================================================
We all know Linux is great...it does infinite loops in 5 seconds. -- Linus
-------------- next part --------------
An embedded message was scrubbed...
From: Eric Cathelinaud <e.cathelinaud at googlemail.com>
Subject: Re: wireshark, viewing Abis communication
Date: Fri, 17 Jul 2009 17:59:30 +0200
Size: 14987
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090717/9b6c6be0/attachment.eml>

From Andreas.Eversberg at versatel.de  Wed Jul 22 08:13:32 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Wed, 22 Jul 2009 10:13:32 +0200
Subject: AW: mISDNdebugtool status
Message-ID: <B16317F2B1592B4492FC414114171CE6D64F3C@FLBVEXCH01.versatel.local>

> can you comment on the status of mISDNdebugtool?  As it seems, Eric is
having
> some problems using it.  Also, in current mISDNuser.git (socket
branch),
> it doesn't compile since mISDNdebugtool.h is missing.

hi,

sorry for the late answer.

i don't exactly know what this was for. i think it was used to debug the
driver itself. to actually log frames from isdn interface and write a
pcap file you need misdn_log.

for logging first card use "misdn_log" or "misdn_log -c0". for writing
pcap file use "misdn_log -c0 -w <file>"
this connects to given isdn interface and shows transmitted data also.
it must be started AFTER the application or it will set the mode to
TE-mode. so first run bsc_hack, then start misdn_log.

andreas





From e.cathelinaud at googlemail.com  Thu Jul 23 09:35:33 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Thu, 23 Jul 2009 11:35:33 +0200
Subject: mISDNdebugtool status
In-Reply-To: <B16317F2B1592B4492FC414114171CE6D64F3C@FLBVEXCH01.versatel.local>
References: <AcoHCUaFsOyYdHLfQKqbZnaZ9xogYwDl94SQ>
	<B16317F2B1592B4492FC414114171CE6D64F3C@FLBVEXCH01.versatel.local>
Message-ID: <383f8f9a0907230235y1038e400raab52ff0c7be9577@mail.gmail.com>

Hi!

Working fine thanks. But there is something I don't understand : the source
is always the user and the destination always the network.

I would like to ask another question. I can see on which time slot the burst
is sent but i can't see the frame and the multiframe number. Is it available
somewhere?

Thanks

Eric

2009/7/22 Andreas.Eversberg <Andreas.Eversberg at versatel.de>

> > can you comment on the status of mISDNdebugtool?  As it seems, Eric is
> having
> > some problems using it.  Also, in current mISDNuser.git (socket
> branch),
> > it doesn't compile since mISDNdebugtool.h is missing.
>
> hi,
>
> sorry for the late answer.
>
> i don't exactly know what this was for. i think it was used to debug the
> driver itself. to actually log frames from isdn interface and write a
> pcap file you need misdn_log.
>
> for logging first card use "misdn_log" or "misdn_log -c0". for writing
> pcap file use "misdn_log -c0 -w <file>"
> this connects to given isdn interface and shows transmitted data also.
> it must be started AFTER the application or it will set the mode to
> TE-mode. so first run bsc_hack, then start misdn_log.
>
> andreas
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090723/ba0dd550/attachment.htm>

From spaar at mirider.augusta.de  Thu Jul 23 14:00:36 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Thu, 23 Jul 2009 14:00:36 CEST
Subject: mISDNdebugtool status
Message-ID: <4a686d04.mirider@mirider.augusta.de>

Hello Eric,

On Thu, 23 Jul 2009 11:35:33 +0200, "Eric Cathelinaud" <e.cathelinaud at googlemail.com> wrote:
> 
> I would like to ask another question. I can see on which time slot the burst
> is sent but i can't see the frame and the multiframe number. Is it available
> somewhere?

Not in the Abis communication, its the BTS which cares about frames
but not the BSC. For the nanoBTS it is most certainly possible to get
debug traces from the debug port (but probably not on Abis) which
contain the frame number, but I am not aware that the same is possible
for the BS-11.

If you are interested in this low-level Layer 1 stuff, you might have
a look at OpenBTS, you can adjust nearly everything or trace at a really
low level.

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



From e.cathelinaud at googlemail.com  Thu Jul 23 18:48:42 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Thu, 23 Jul 2009 20:48:42 +0200
Subject: mISDNdebugtool status
In-Reply-To: <4a686d04.mirider@mirider.augusta.de>
References: <4a686d04.mirider@mirider.augusta.de>
Message-ID: <383f8f9a0907231148g791dca3mde6037ee9158936d@mail.gmail.com>

Oh nice
thanks for the information

Best regards
Eric Cathelinaud

2009/7/23 Dieter Spaar <spaar at mirider.augusta.de>

> Hello Eric,
>
> On Thu, 23 Jul 2009 11:35:33 +0200, "Eric Cathelinaud" <
> e.cathelinaud at googlemail.com> wrote:
> >
> > I would like to ask another question. I can see on which time slot the
> burst
> > is sent but i can't see the frame and the multiframe number. Is it
> available
> > somewhere?
>
> Not in the Abis communication, its the BTS which cares about frames
> but not the BSC. For the nanoBTS it is most certainly possible to get
> debug traces from the debug port (but probably not on Abis) which
> contain the frame number, but I am not aware that the same is possible
> for the BS-11.
>
> If you are interested in this low-level Layer 1 stuff, you might have
> a look at OpenBTS, you can adjust nearly everything or trace at a really
> low level.
>
> Best regards,
>  Dieter
> --
> Dieter Spaar, Germany                           spaar at mirider.augusta.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090723/701da556/attachment.htm>

From e.cathelinaud at googlemail.com  Fri Jul 24 15:26:31 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Fri, 24 Jul 2009 17:26:31 +0200
Subject: mISDNdebugtool status
In-Reply-To: <383f8f9a0907231148g791dca3mde6037ee9158936d@mail.gmail.com>
References: <4a686d04.mirider@mirider.augusta.de>
	<383f8f9a0907231148g791dca3mde6037ee9158936d@mail.gmail.com>
Message-ID: <383f8f9a0907240826n2cbe0f2bif4e4d7e42ef780ce@mail.gmail.com>

Hi,

I saw something wierd using misdn_log to see the Abis communication : even
if i don't call or send SMS I can see a periodic paging and a periodic RACH
answer.
The period of the paging is 2.6 seconds.
The RACH appears 16 or 17 ms after the paging.
In attached file the capture (open with wireshark) :
1. a call Mobile1(Nokia6310i)-->2(Ericsson)
2. a SMS Mobile 1-->2
3. a call Mobile 2-->1
4. a SMS Mobile 2-->1
Between these 4 operations we can see lot of paging and RACH with no
interruption.

Does anyone understand this?

Btw the SMS doesn't work for me. It is transmitted towards the BTS but not
fowarded from the BTS to the 2nd mobile.

Eric Cathelinaud

2009/7/23 Eric Cathelinaud <e.cathelinaud at googlemail.com>

> Oh nice
> thanks for the information
>
> Best regards
> Eric Cathelinaud
>
> 2009/7/23 Dieter Spaar <spaar at mirider.augusta.de>
>
> Hello Eric,
>>
>> On Thu, 23 Jul 2009 11:35:33 +0200, "Eric Cathelinaud" <
>> e.cathelinaud at googlemail.com> wrote:
>> >
>> > I would like to ask another question. I can see on which time slot the
>> burst
>> > is sent but i can't see the frame and the multiframe number. Is it
>> available
>> > somewhere?
>>
>> Not in the Abis communication, its the BTS which cares about frames
>> but not the BSC. For the nanoBTS it is most certainly possible to get
>> debug traces from the debug port (but probably not on Abis) which
>> contain the frame number, but I am not aware that the same is possible
>> for the BS-11.
>>
>> If you are interested in this low-level Layer 1 stuff, you might have
>> a look at OpenBTS, you can adjust nearly everything or trace at a really
>> low level.
>>
>> Best regards,
>>  Dieter
>> --
>> Dieter Spaar, Germany                           spaar at mirider.augusta.de
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090724/7b37f17c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: misdnlog01
Type: application/octet-stream
Size: 17418 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090724/7b37f17c/attachment.obj>

From laforge at gnumonks.org  Sun Jul 26 08:37:57 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 26 Jul 2009 10:37:57 +0200
Subject: mISDNdebugtool status
In-Reply-To: <383f8f9a0907240826n2cbe0f2bif4e4d7e42ef780ce@mail.gmail.com>
References: <4a686d04.mirider@mirider.augusta.de>
	<383f8f9a0907231148g791dca3mde6037ee9158936d@mail.gmail.com>
	<383f8f9a0907240826n2cbe0f2bif4e4d7e42ef780ce@mail.gmail.com>
Message-ID: <20090726083757.GH7204@prithivi.gnumonks.org>

On Fri, Jul 24, 2009 at 05:26:31PM +0200, Eric Cathelinaud wrote:

> I saw something wierd using misdn_log to see the Abis communication : even
> if i don't call or send SMS I can see a periodic paging and a periodic RACH
> answer.

> Does anyone understand this?

you are seeing those paging commands only on the A-bis interface but not
on the log output of OpenBSC?

> Btw the SMS doesn't work for me. It is transmitted towards the BTS but not
> fowarded from the BTS to the 2nd mobile.

No surprise here. the latter code is not implemented yet ;)  Working on it.

-- 
- 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  Sun Jul 26 21:08:04 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Sun, 26 Jul 2009 23:08:04 +0200
Subject: mISDNdebugtool status
In-Reply-To: <20090726083757.GH7204@prithivi.gnumonks.org>
References: <4a686d04.mirider@mirider.augusta.de>
	<383f8f9a0907231148g791dca3mde6037ee9158936d@mail.gmail.com>
	<383f8f9a0907240826n2cbe0f2bif4e4d7e42ef780ce@mail.gmail.com>
	<20090726083757.GH7204@prithivi.gnumonks.org>
Message-ID: <383f8f9a0907261408u6bc542d2wca015dc8d869ea4a@mail.gmail.com>

>
> > I saw something wierd using misdn_log to see the Abis communication :
> even
> > if i don't call or send SMS I can see a periodic paging and a periodic
> RACH
> > answer.
>
> > Does anyone understand this?
>
> you are seeing those paging commands only on the A-bis interface but not
> on the log output of OpenBSC?
>

Well I didn't use the log of OpenBSC in the same time but normally there is
no periodic paging like this with the log of OpenBSC. I will try it again
tomorrow and compare with the log of OpenBSC.

>
> > Btw the SMS doesn't work for me. It is transmitted towards the BTS but
> not
> > fowarded from the BTS to the 2nd mobile.
>
> No surprise here. the latter code is not implemented yet ;)  Working on it.


oh ok ;)

>
>

Eric Cathelinaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090726/9d84c509/attachment.htm>

From e.cathelinaud at googlemail.com  Mon Jul 27 08:40:34 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Mon, 27 Jul 2009 10:40:34 +0200
Subject: mISDNdebugtool status
In-Reply-To: <383f8f9a0907261408u6bc542d2wca015dc8d869ea4a@mail.gmail.com>
References: <4a686d04.mirider@mirider.augusta.de>
	<383f8f9a0907231148g791dca3mde6037ee9158936d@mail.gmail.com>
	<383f8f9a0907240826n2cbe0f2bif4e4d7e42ef780ce@mail.gmail.com>
	<20090726083757.GH7204@prithivi.gnumonks.org>
	<383f8f9a0907261408u6bc542d2wca015dc8d869ea4a@mail.gmail.com>
Message-ID: <383f8f9a0907270140j53e09148p4c5a0e536b2d9576@mail.gmail.com>

well I didn't pay attention to this for the log of OpenBSC but it's the same
yes. I still don't understand what are these 2 packets. Could it be the
information for paging loaded each 2,5 seconds in only one packet? I mean :
even if we have no paging request these packets should be sent?
And every RACH information regrouped in one packet is also transmitted
towards the BSC periodically?

Thanks

Eric Cathelinaud

2009/7/26 Eric Cathelinaud <e.cathelinaud at googlemail.com>

>  > I saw something wierd using misdn_log to see the Abis communication :
>> even
>> > if i don't call or send SMS I can see a periodic paging and a periodic
>> RACH
>> > answer.
>>
>> > Does anyone understand this?
>>
>> you are seeing those paging commands only on the A-bis interface but not
>> on the log output of OpenBSC?
>>
>
> Well I didn't use the log of OpenBSC in the same time but normally there is
> no periodic paging like this with the log of OpenBSC. I will try it again
> tomorrow and compare with the log of OpenBSC.
>
>>
>> > Btw the SMS doesn't work for me. It is transmitted towards the BTS but
>> not
>> > fowarded from the BTS to the 2nd mobile.
>>
>> No surprise here. the latter code is not implemented yet ;)  Working on
>> it.
>
>
> oh ok ;)
>
>>
>>
>
> Eric Cathelinaud
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090727/9a93e3cd/attachment.htm>

From e.cathelinaud at googlemail.com  Mon Jul 27 22:34:59 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Tue, 28 Jul 2009 00:34:59 +0200
Subject: mISDNdebugtool status
In-Reply-To: <383f8f9a0907270140j53e09148p4c5a0e536b2d9576@mail.gmail.com>
References: <4a686d04.mirider@mirider.augusta.de>
	<383f8f9a0907231148g791dca3mde6037ee9158936d@mail.gmail.com>
	<383f8f9a0907240826n2cbe0f2bif4e4d7e42ef780ce@mail.gmail.com>
	<20090726083757.GH7204@prithivi.gnumonks.org>
	<383f8f9a0907261408u6bc542d2wca015dc8d869ea4a@mail.gmail.com>
	<383f8f9a0907270140j53e09148p4c5a0e536b2d9576@mail.gmail.com>
Message-ID: <383f8f9a0907271534j2473a2a6x739e37e39d95d94d@mail.gmail.com>

Hi,

I still have one question about the log. We can see only messages going from
BTS to BSC but not the ones in the other way. Why?
This is the case with the log from mISDN tool and I think it's almost the
same with bsc_hack option but I need to check (I think with bsc_hack option
there are some messages in the other way too but a lot of them are missing
like during a call procedure for example).

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

From laforge at gnumonks.org  Tue Jul 28 05:53:38 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 28 Jul 2009 07:53:38 +0200
Subject: mISDNdebugtool status
In-Reply-To: <383f8f9a0907271534j2473a2a6x739e37e39d95d94d@mail.gmail.com>
References: <4a686d04.mirider@mirider.augusta.de>
	<383f8f9a0907231148g791dca3mde6037ee9158936d@mail.gmail.com>
	<383f8f9a0907240826n2cbe0f2bif4e4d7e42ef780ce@mail.gmail.com>
	<20090726083757.GH7204@prithivi.gnumonks.org>
	<383f8f9a0907261408u6bc542d2wca015dc8d869ea4a@mail.gmail.com>
	<383f8f9a0907270140j53e09148p4c5a0e536b2d9576@mail.gmail.com>
	<383f8f9a0907271534j2473a2a6x739e37e39d95d94d@mail.gmail.com>
Message-ID: <20090728055338.GA1434@prithivi.gnumonks.org>

On Tue, Jul 28, 2009 at 12:34:59AM +0200, Eric Cathelinaud wrote:
> Hi,
> 
> I still have one question about the log. We can see only messages going from
> BTS to BSC but not the ones in the other way. Why?

I would give you answers if I had them.  As I indicated before on this list,
I'm almost constantly travelling and rarely have access to a BS-11, so I
cannot test/verify any of your findings.  I did some casual checking of
misdn_log last time, and it _seemed_ to work fine.
-- 
- 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 Jul 28 09:18:05 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Tue, 28 Jul 2009 11:18:05 +0200
Subject: mISDNdebugtool status
In-Reply-To: <20090728055338.GA1434@prithivi.gnumonks.org>
References: <4a686d04.mirider@mirider.augusta.de>
	<383f8f9a0907231148g791dca3mde6037ee9158936d@mail.gmail.com>
	<383f8f9a0907240826n2cbe0f2bif4e4d7e42ef780ce@mail.gmail.com>
	<20090726083757.GH7204@prithivi.gnumonks.org>
	<383f8f9a0907261408u6bc542d2wca015dc8d869ea4a@mail.gmail.com>
	<383f8f9a0907270140j53e09148p4c5a0e536b2d9576@mail.gmail.com>
	<383f8f9a0907271534j2473a2a6x739e37e39d95d94d@mail.gmail.com>
	<20090728055338.GA1434@prithivi.gnumonks.org>
Message-ID: <383f8f9a0907280218g6de3c2cei236f4c9b1abdf521@mail.gmail.com>

Hello,

I give you a screenshot in attached file. May be Andreas know why.
This screenshot shows a terminated call procedure.
We should have :
BTS --> BSC : CHANNEL REQUIRED
BSC --> BTS : CHANNEL ACTIVATION
BTS --> BSC : CHANNEL ACTIVATION ACK
BSC --> BTS : IMMEDIATE ASSIGNMENT COMMAND
and so on

And on the misdn log we only have :
BTS --> BSC : CHANNEL REQUIRED
BTS --> BSC : CHANNEL ACTIVATION ACK
and so on

I can't see any message from BSC to BTS.
But I can see : "S, func=RR, N(R)=23" from LAPD format
I didn't find what it is exactly.

Thanks

Eric Cathelinaud


2009/7/28 Harald Welte <laforge at gnumonks.org>

> On Tue, Jul 28, 2009 at 12:34:59AM +0200, Eric Cathelinaud wrote:
> > Hi,
> >
> > I still have one question about the log. We can see only messages going
> from
> > BTS to BSC but not the ones in the other way. Why?
>
> I would give you answers if I had them.  As I indicated before on this
> list,
> I'm almost constantly travelling and rarely have access to a BS-11, so I
> cannot test/verify any of your findings.  I did some casual checking of
> misdn_log last time, and it _seemed_ to work fine.
> --
> - 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/20090728/2efd29cc/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: misdnLog.png
Type: image/png
Size: 133932 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090728/2efd29cc/attachment.png>

From zero-kelvin at gmx.de  Mon Jul 20 16:39:47 2009
From: zero-kelvin at gmx.de (dexter)
Date: Mon, 20 Jul 2009 18:39:47 +0200
Subject: Spectrum analysis shows strange carrier
Message-ID: <4A649DD3.8080403@gmx.de>

Hi folks.

We have a Toy-Spectrum-Analyser here, so i have measured the output of 
our BS-11 when initalized with -f 123

http://www.root.runningserver.com/pub/openbsc_spektralanalyse.png

Why are there 2 carriers emitted by the BTS?

I thought that openBSC uses only one TRX. I have verfied that the 
carrier must be emitted by the BTS. If i stop the BTS the carrier 
vanishes and the T-Mobile carrier comes through (much weaker, of cause)

I have no explaination for this effect, can anyone give me a hint?

regards
Philipp



From mailinglists at hellercom.de  Mon Jul 20 17:39:01 2009
From: mailinglists at hellercom.de (Bjoern Heller)
Date: Mon, 20 Jul 2009 19:39:01 +0200
Subject: Spectrum analysis shows strange carrier
In-Reply-To: <4A649DD3.8080403@gmx.de>
References: <4A649DD3.8080403@gmx.de>
Message-ID: <ABC3CC54-CE84-4D2F-BB54-6B4A6FA0E90E@hellercom.de>

Es gibt zwei Tr?gerfrequenzen, eine von der BS zur MS (Downlink) und  
eine f?r die andere Richtung (Uplink).

Gru?

Am 20.07.2009 um 18:39 schrieb dexter:

> Hi folks.
>
> We have a Toy-Spectrum-Analyser here, so i have measured the output  
> of our BS-11 when initalized with -f 123
>
> http://www.root.runningserver.com/pub/openbsc_spektralanalyse.png
>
> Why are there 2 carriers emitted by the BTS?
>
> I thought that openBSC uses only one TRX. I have verfied that the  
> carrier must be emitted by the BTS. If i stop the BTS the carrier  
> vanishes and the T-Mobile carrier comes through (much weaker, of  
> cause)
>
> I have no explaination for this effect, can anyone give me a hint?
>
> regards
> Philipp
>

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

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

From spaar at mirider.augusta.de  Mon Jul 20 20:19:16 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Mon, 20 Jul 2009 20:19:16 CEST
Subject: Spectrum analysis shows strange carrier
Message-ID: <4a64d144.mirider@mirider.augusta.de>

Hello Philipp,

On Mon, 20 Jul 2009 18:39:47 +0200, "dexter" <zero-kelvin at gmx.de> wrote:
> 
> We have a Toy-Spectrum-Analyser here, so i have measured the output of 
> our BS-11 when initalized with -f 123
> 
> http://www.root.runningserver.com/pub/openbsc_spektralanalyse.png
> 

Not sure what you are measuring on peak one and two, but channel 123
should be 959.6 MHz, this is most certainly the third peak. There might
be small signals (e.g. from the oscillator of the BS-11) on other
frequencies, but they should be much smaller than the main signal.

I don't know what the specification for a BTS allows as level for
emitting on other frequencies, so I can't give you any numbers how
strong those other signals can be.

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



From philipp.maier at runningserver.com  Mon Jul 20 18:49:22 2009
From: philipp.maier at runningserver.com (Philipp Fabian Benedikt Maier)
Date: Mon, 20 Jul 2009 20:49:22 +0200
Subject: Spectrum analysis shows strange carrier
In-Reply-To: <4a64d144.mirider@mirider.augusta.de>
References: <4a64d144.mirider@mirider.augusta.de>
Message-ID: <4A64BC32.7050609@runningserver.com>

Hello Dieter,

> There might
> be small signals (e.g. from the oscillator of the BS-11) on other
> frequencies, but they should be much smaller than the main signal.
>   
I think that is the most plausible explaination. The antenna of the
spectrum analyser was positioned very close to the BS11. That might be a
reason why unwanted Signal comes out so strong.

besides: An expert told me that the grounding in our laboratory is not
so good at all. That also might weak the shilding.

Thanks!

regards.
Philipp




From e.cathelinaud at googlemail.com  Mon Jul 20 19:49:57 2009
From: e.cathelinaud at googlemail.com (Eric Cathelinaud)
Date: Mon, 20 Jul 2009 21:49:57 +0200
Subject: Spectrum analysis shows strange carrier
In-Reply-To: <4a64d144.mirider@mirider.augusta.de>
References: <4a64d144.mirider@mirider.augusta.de>
Message-ID: <383f8f9a0907201249u17246d5egf4faa9fb8ab54826@mail.gmail.com>

ok there are only downlink signals there since it s more than 935MHz.
If I understand one of the pike 1&2 vanishes when you stop the BTS and the
other one stays? Or is it the 3rd pike at 959.6 MHz who vanishes?
I am not sure but I think you said the pike 1 disapeared and the pike 2
(weaker) staid... right? and the 3rd pike?
The pike at 959.6 MHz corresponding to n = 123 is coming from the Tx0 for
sure as Dieter said.

Can you say what you can see when you load the bs11 with bs11_config query?
And which power did u setup? 30mW (default)?

Best regards,
Eric


2009/7/20 Dieter Spaar <spaar at mirider.augusta.de>

> Hello Philipp,
>
> On Mon, 20 Jul 2009 18:39:47 +0200, "dexter" <zero-kelvin at gmx.de> wrote:
> >
> > We have a Toy-Spectrum-Analyser here, so i have measured the output of
> > our BS-11 when initalized with -f 123
> >
> > http://www.root.runningserver.com/pub/openbsc_spektralanalyse.png
> >
>
> Not sure what you are measuring on peak one and two, but channel 123
> should be 959.6 MHz, this is most certainly the third peak. There might
> be small signals (e.g. from the oscillator of the BS-11) on other
> frequencies, but they should be much smaller than the main signal.
>
> I don't know what the specification for a BTS allows as level for
> emitting on other frequencies, so I can't give you any numbers how
> strong those other signals can be.
>
> Best regards,
>  Dieter
> --
> Dieter Spaar, Germany                           spaar at mirider.augusta.de
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090720/b0a87112/attachment.htm>

From spaar at mirider.augusta.de  Mon Jul 20 21:48:31 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Mon, 20 Jul 2009 21:48:31 CEST
Subject: Spectrum analysis shows strange carrier
Message-ID: <4a64e62f.mirider@mirider.augusta.de>

Hello Philipp,

On Mon, 20 Jul 2009 20:19:16 CEST, "Dieter Spaar" <spaar at mirider.augusta.de> wrote:
>
> Not sure what you are measuring on peak one and two, but channel 123
> should be 959.6 MHz, this is most certainly the third peak. There might
> be small signals (e.g. from the oscillator of the BS-11) on other
> frequencies, but they should be much smaller than the main signal.

In the meantime I did check with my spectrum analyzer. There is
indeed a signal coming from the BS-11, even if nothing else is
connected to the BS-11 (no serial connection, no E1). The signal
starts to be emitted after the firmware download is complete.

I could measure the signal at 942.4 MHz, the level is about -42 dBm
(cable connection from the spectrum analyzer to TRX0, low-quality
cable). The signal strength does not depend on the power amplifier
setting, I wonder where it comes from (some internal oscillator
working at that frequency ?). The signal is not very strong, so
it should not cause major trouble (besides disturbing a weak
signal which might be there from an "official" source if you
are close to the BS-11).

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



From zero-kelvin at gmx.de  Tue Jul 21 09:53:03 2009
From: zero-kelvin at gmx.de (dexter)
Date: Tue, 21 Jul 2009 11:53:03 +0200
Subject: Spectrum analysis shows strange carrier
In-Reply-To: <4a64e62f.mirider@mirider.augusta.de>
References: <4a64e62f.mirider@mirider.augusta.de>
Message-ID: <4A658FFF.2060104@gmx.de>

Hello Dieter.
> In the meantime I did check with my spectrum analyzer. There is
> indeed a signal coming from the BS-11, even if nothing else is
> connected to the BS-11 (no serial connection, no E1). The signal
> starts to be emitted after the firmware download is complete.
>
> I could measure the signal at 942.4 MHz, the level is about -42 dBm
> (cable connection from the spectrum analyzer to TRX0, low-quality
> cable). The signal strength does not depend on the power amplifier
> setting, I wonder where it comes from (some internal oscillator
> working at that frequency ?). The signal is not very strong, so
> it should not cause major trouble (besides disturbing a weak
> signal which might be there from an "official" source if you
> are close to the BS-11).
>   
I think i can confirm that. This was measured during the BS11 startup:

http://root.runningserver.com/pub/startup-phase.png

For me the case is closed, think this behaviour is just normal.

regards,
Philipp




From laforge at gnumonks.org  Wed Jul 22 10:28:55 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 22 Jul 2009 12:28:55 +0200
Subject: Looking for 32.768MHz OCXO for BS-11 calibration
Message-ID: <20090722102855.GM14751@prithivi.gnumonks.org>

Hi!

So for everyone who has problems with BS-11 clock accuracy,
what would be the theoretical straight-forward way to solve the
problem, is to replace the 32.768MHz crystal oscillator on the E1
card with a OCXO of the same frequency.

So what we're looking for is an OCXO with +/- 0.05ppm or higher stability for
3.3V power supply.  Unfortunately I was not able to find one at that
frequency, even digikey doesn't have one.

If anyone can find a source for a OCXO in the abovementioned
parameter range (and small quantities), I think quite a number of people would
be interested in buying one and connecting it to their E1 boards.  Any help
is much appreciated.

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 Michael.Gernoth at informatik.uni-erlangen.de  Thu Jul 23 08:36:44 2009
From: Michael.Gernoth at informatik.uni-erlangen.de (Michael Gernoth)
Date: Thu, 23 Jul 2009 10:36:44 +0200
Subject: Looking for 32.768MHz OCXO for BS-11 calibration
In-Reply-To: <20090722102855.GM14751@prithivi.gnumonks.org>
References: <20090722102855.GM14751@prithivi.gnumonks.org>
Message-ID: <20090723083644.GA63766@informatik.uni-erlangen.de>

Hi,

On Wed, Jul 22, 2009 at 12:28:55PM +0200, Harald Welte wrote:
> If anyone can find a source for a OCXO in the abovementioned
> parameter range (and small quantities), I think quite a number of people would
> be interested in buying one and connecting it to their E1 boards.  Any help
> is much appreciated.

After having given up on the same task, I decided to try Andreas'
isdnsync using my ISDN line. I synchronized the clock of the BS-11
by connecting it to a cheap HFC-S PCI card and connecting that to
the ISDN network.

I just connected C4IO and F0IO, added type=0x00800 to the hfcmulti
parameters, ran isdnsync and started bsc_hack. I could then watch the
oscillator frequency getting slowly adjusted to the ISDN line with
bs11_config (the value changed from somewhere around 1840 to 1035).
It took about an hour for the work value to stablilize.

Now all available mobiles can see and join the network and are also able
to find and join the official networks again.

I've uploaded a (bad) picture of the modified card here:
http://www4.cs.fau.de/~gernoth/IMG_8005.JPG
The attached cable can be directly plugged in to one of
the PCM connectors on the E1 board (PIN 9 and 11).

Regards,
  Michael

-- 
Michael Gernoth                            Department of Computer Science IV 
Martensstrasse 1  D-91058 Erlangen Germany  University of Erlangen-Nuremberg
	      http://www4.informatik.uni-erlangen.de/~gernoth/



From laforge at gnumonks.org  Thu Jul 23 16:09:57 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 23 Jul 2009 18:09:57 +0200
Subject: Looking for 32.768MHz OCXO for BS-11 calibration
In-Reply-To: <20090723083644.GA63766@informatik.uni-erlangen.de>
References: <20090722102855.GM14751@prithivi.gnumonks.org>
	<20090723083644.GA63766@informatik.uni-erlangen.de>
Message-ID: <20090723160957.GI7204@prithivi.gnumonks.org>

On Thu, Jul 23, 2009 at 10:36:44AM +0200, Michael Gernoth wrote:

> I just connected C4IO and F0IO, added type=0x00800 to the hfcmulti
> parameters, ran isdnsync and started bsc_hack. I could then watch the
> oscillator frequency getting slowly adjusted to the ISDN line with
> bs11_config (the value changed from somewhere around 1840 to 1035).
> It took about an hour for the work value to stablilize.

Ok, thanks.  It seems I'll have to do the same thing and pre-calibrate
the BS-11 units that we'll be taking to HAR2009, as we certainly won't
have any actual ISDN lines there...

-- 
- 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 Michael.Gernoth at informatik.uni-erlangen.de  Fri Jul 24 11:10:26 2009
From: Michael.Gernoth at informatik.uni-erlangen.de (Michael Gernoth)
Date: Fri, 24 Jul 2009 13:10:26 +0200
Subject: Looking for 32.768MHz OCXO for BS-11 calibration
In-Reply-To: <20090723160957.GI7204@prithivi.gnumonks.org>
References: <20090722102855.GM14751@prithivi.gnumonks.org>
	<20090723083644.GA63766@informatik.uni-erlangen.de>
	<20090723160957.GI7204@prithivi.gnumonks.org>
Message-ID: <20090724111026.GB65294@informatik.uni-erlangen.de>

Hi,

On Thu, Jul 23, 2009 at 06:09:57PM +0200, Harald Welte wrote:
> Ok, thanks.  It seems I'll have to do the same thing and pre-calibrate
> the BS-11 units that we'll be taking to HAR2009, as we certainly won't
> have any actual ISDN lines there...

One pre-calibrated unit should be enough, as you should be able to use the
clock generated by one BS-11 as PCM master clock for another HFC card
with a second unit attached.

Regards,
  Michael

-- 
Michael Gernoth                            Department of Computer Science IV 
Martensstrasse 1  D-91058 Erlangen Germany  University of Erlangen-Nuremberg
	      http://www4.informatik.uni-erlangen.de/~gernoth/



From laforge at gnumonks.org  Fri Jul 24 18:09:08 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 24 Jul 2009 20:09:08 +0200
Subject: Looking for 32.768MHz OCXO for BS-11 calibration
In-Reply-To: <20090724111026.GB65294@informatik.uni-erlangen.de>
References: <20090722102855.GM14751@prithivi.gnumonks.org>
	<20090723083644.GA63766@informatik.uni-erlangen.de>
	<20090723160957.GI7204@prithivi.gnumonks.org>
	<20090724111026.GB65294@informatik.uni-erlangen.de>
Message-ID: <20090724180908.GS7204@prithivi.gnumonks.org>

On Fri, Jul 24, 2009 at 01:10:26PM +0200, Michael Gernoth wrote:
> Hi,
> 
> On Thu, Jul 23, 2009 at 06:09:57PM +0200, Harald Welte wrote:
> > Ok, thanks.  It seems I'll have to do the same thing and pre-calibrate
> > the BS-11 units that we'll be taking to HAR2009, as we certainly won't
> > have any actual ISDN lines there...
> 
> One pre-calibrated unit should be enough, as you should be able to use the
> clock generated by one BS-11 as PCM master clock for another HFC card
> with a second unit attached.

I'm planning to use only one E1 card.  Yes, theoretically that should still
work with only one calibrated unit, but I'd rather not take my chances.

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



From laforge at gnumonks.org  Wed Jul 22 15:38:48 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 22 Jul 2009 17:38:48 +0200
Subject: GSM license approval for HAR2009
Message-ID: <20090722153847.GH18204@prithivi.gnumonks.org>

Hi!

For those who are planning to attend HAR2009 (http://har2009.org/): 

We have just received regulatory approval for four ARFCN in the GSM900 band
during HAR2009.  The Power on each ARFCN for BTS and MS is restricted to 100mW.

There are also some GSM1800 ARFCN's that we can use with up to 200mW, though
I don't yet know their values and how many.

I have created a wiki page at https://wiki.har2009.org/page/GSM
for further coordination of GSM related activities at HAR2009.

It would be great to know which other OpenBSC users/hackers will be present
at the event.  As there are multiple things that I'm planning to do at HAR2009,
I would be happy about any help that I might get from you guys.

Basically there will be

* A 'stable' GSM network with BS-11 and OpenBSC for people to test
  their phone interoperability with OpenBSC by making/receiving calls and
  SMS.  

* A nanoBTS1800 for use by OpenBSC hackers only to test/fix OpenBSC stuff
  before putting it on the BS-11 'stable' network

* work on airprobe.

Especially for the 'stable' network, there is a lot of help required, among
others:
* physical setup of the BS-11
* registration of mobile phones into the network. It would probably be good
  to have a setup where people can plug their SIM into a SIM card reader
  (or phone that can read the IMSI).  We can then create the SQL entry with
  their IMSI and extension.
* making sure the network runs and OpenBSC / hfcmulti gets restarted in case
  something hangs.

Please just respond to this mail if you want to help in any way.

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 dburgess at jcis.net  Wed Jul 22 16:22:57 2009
From: dburgess at jcis.net (David A. Burgess)
Date: Wed, 22 Jul 2009 09:22:57 -0700
Subject: GSM license approval for HAR2009
In-Reply-To: <20090722153847.GH18204@prithivi.gnumonks.org>
References: <20090722153847.GH18204@prithivi.gnumonks.org>
Message-ID: <335598CD-E454-4EEF-94CB-8F5A316DE399@jcis.net>

Harald -

Congratulations on the license.

One thing we plan do at Burning Man is run an auto-provisioning  
system via SMS, using the BTS itself as a SIM reader.  When a handset  
first tries to register, we will accept the location updating attempt  
and then send a text message saying "If you want experimental  
service, please reply with your telephone number."  The reply to the  
text message then goes into a function that creates a new entry in  
the provisioning database based on the originating IMSI and the  
content of the message.  Then we will respond with something like  
"Thanks for joining our test.  This is an experimental network.  WE  
DO NOT SUPPORT EMERGENCY CALLS.  To quit the test, reply to this  
message."  In the US, at least, the part about emergency calls is  
really important.

I realize you don't have a lot of time left to get ready for HAR,  
though.  This may or may not be a simple hack, depending on the state  
of your SMS software.  But if it works, it will be a lot faster than  
provisioning phone by hand.

-- David


On Jul 22, 2009, at 8:38 AM, Harald Welte wrote:

> Hi!
>
> For those who are planning to attend HAR2009 (http://har2009.org/):
>
> We have just received regulatory approval for four ARFCN in the  
> GSM900 band
> during HAR2009.  The Power on each ARFCN for BTS and MS is  
> restricted to 100mW.
>
> There are also some GSM1800 ARFCN's that we can use with up to  
> 200mW, though
> I don't yet know their values and how many.
>
> I have created a wiki page at https://wiki.har2009.org/page/GSM
> for further coordination of GSM related activities at HAR2009.
>
> It would be great to know which other OpenBSC users/hackers will be  
> present
> at the event.  As there are multiple things that I'm planning to do  
> at HAR2009,
> I would be happy about any help that I might get from you guys.
>
> Basically there will be
>
> * A 'stable' GSM network with BS-11 and OpenBSC for people to test
>   their phone interoperability with OpenBSC by making/receiving  
> calls and
>   SMS.
>
> * A nanoBTS1800 for use by OpenBSC hackers only to test/fix OpenBSC  
> stuff
>   before putting it on the BS-11 'stable' network
>
> * work on airprobe.
>
> Especially for the 'stable' network, there is a lot of help  
> required, among
> others:
> * physical setup of the BS-11
> * registration of mobile phones into the network. It would probably  
> be good
>   to have a setup where people can plug their SIM into a SIM card  
> reader
>   (or phone that can read the IMSI).  We can then create the SQL  
> entry with
>   their IMSI and extension.
> * making sure the network runs and OpenBSC / hfcmulti gets  
> restarted in case
>   something hangs.
>
> Please just respond to this mail if you want to help in any way.
>
> 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)


David A. Burgess
Kestrel Signal Processing, Inc.







From laforge at gnumonks.org  Wed Jul 22 16:38:11 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 22 Jul 2009 18:38:11 +0200
Subject: GSM license approval for HAR2009
In-Reply-To: <335598CD-E454-4EEF-94CB-8F5A316DE399@jcis.net>
References: <20090722153847.GH18204@prithivi.gnumonks.org>
	<335598CD-E454-4EEF-94CB-8F5A316DE399@jcis.net>
Message-ID: <20090722163811.GK18204@prithivi.gnumonks.org>

Hi David,

On Wed, Jul 22, 2009 at 09:22:57AM -0700, David A. Burgess wrote:
> One thing we plan do at Burning Man is run an auto-provisioning system 
> via SMS, using the BTS itself as a SIM reader.  When a handset first 
> tries to register, we will accept the location updating attempt and then 
> send a text message saying "If you want experimental service, please 
> reply with your telephone number."  The reply to the text message then 
> goes into a function that creates a new entry in the provisioning 
> database based on the originating IMSI and the content of the message.  
> Then we will respond with something like "Thanks for joining our test.  
> This is an experimental network.  WE DO NOT SUPPORT EMERGENCY CALLS.  To 
> quit the test, reply to this message."  In the US, at least, the part 
> about emergency calls is really important.
>
> I realize you don't have a lot of time left to get ready for HAR,  
> though.  This may or may not be a simple hack, depending on the state of 
> your SMS software.  But if it works, it will be a lot faster than  
> provisioning phone by hand.

Yes, I was thinking about something similar, but more restrictive:

* let an unknown imsi perform location update
* send a SMS that this is a test network, include IMSI plus some
  authentication token in the SMS
* send a authentication request to the phone
* reject the authentication irrespective of the response

This way the phone cannot stay on our network until somebody has gone to a web
browser and entered imsi + auth code from that SMS.  Still it's not foolproof,
since anyone with airprobe could just get that imsi + auth code off the air
and authenticate for somebody else :(

Oh, and of course, only do that entire procedure onec for every given IMSI,
so next time the location update request is rejected without any SMS,
unless the auth code has been entered on the web site.

I'm not sure if I can manage to implement this, but it would be the
solution I would hope for.  On the other hand, having to manually enter people
keeps the number of users smaller and more controllable.  If there's one
volunteer who can take care of that, it should be fine.
 
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 stefan at datenfreihafen.org  Wed Jul 22 17:11:12 2009
From: stefan at datenfreihafen.org (Stefan Schmidt)
Date: Wed, 22 Jul 2009 19:11:12 +0200
Subject: GSM license approval for HAR2009
In-Reply-To: <20090722163811.GK18204@prithivi.gnumonks.org>
References: <20090722153847.GH18204@prithivi.gnumonks.org>
	<335598CD-E454-4EEF-94CB-8F5A316DE399@jcis.net>
	<20090722163811.GK18204@prithivi.gnumonks.org>
Message-ID: <20090722171112.GC5337@dodger.lab.datenfreihafen.org>

Hello.

On Wed, 2009-07-22 at 18:38, Harald Welte wrote:
> 
> I'm not sure if I can manage to implement this, but it would be the
> solution I would hope for.  On the other hand, having to manually enter people
> keeps the number of users smaller and more controllable.  If there's one
> volunteer who can take care of that, it should be fine.

Hmm, judging from the rush at the POC on other conferences/camps at the first
day I would think we would need at least 3-4 people at the first day. Especially
if you have in mind that it is a new "feature" of such an event and people may
carry a GSM handset with them but no extra DECT. For the later days 1 or 2
people at the desk should be ok.

regards
Stefan Schmidt



From laforge at gnumonks.org  Wed Jul 22 21:49:00 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 22 Jul 2009 23:49:00 +0200
Subject: GSM license approval for HAR2009
In-Reply-To: <20090722171112.GC5337@dodger.lab.datenfreihafen.org>
References: <20090722153847.GH18204@prithivi.gnumonks.org>
	<335598CD-E454-4EEF-94CB-8F5A316DE399@jcis.net>
	<20090722163811.GK18204@prithivi.gnumonks.org>
	<20090722171112.GC5337@dodger.lab.datenfreihafen.org>
Message-ID: <20090722214900.GH20307@prithivi.gnumonks.org>

Hi Stefan,

On Wed, Jul 22, 2009 at 07:11:12PM +0200, Stefan Schmidt wrote:
 
> On Wed, 2009-07-22 at 18:38, Harald Welte wrote:
> > 
> > I'm not sure if I can manage to implement this, but it would be the
> > solution I would hope for.  On the other hand, having to manually enter people
> > keeps the number of users smaller and more controllable.  If there's one
> > volunteer who can take care of that, it should be fine.
> 
> Hmm, judging from the rush at the POC on other conferences/camps at the first
> day I would think we would need at least 3-4 people at the first day. Especially
> if you have in mind that it is a new "feature" of such an event and people may
> carry a GSM handset with them but no extra DECT. For the later days 1 or 2
> people at the desk should be ok.

I think we should advertise/communicate the GSM network as a more experimental
feature.

Even with two BTS at two TRX (exercising all our four ARFCN), the total call
capacity is not more than 13 simultanesous MS-to-MS calls (since each call
requires two timeslots).  Yes we could do half-rate, but we have no software
support for that so far.

Sure, we can take a different approach and just let everyone in and see how
many segfaults of OpenBSC we can fix under that kind of load :)

But I think a 'slow start' would definitely help, where we don't allow too many
people onto the network.

Of course we could also allow people to register their IMSI themselves on a
web-based interface, but then have something like a global counter of currently
attached MS in OpenBSC and then simply refuse further people on the network.

So a manual registration process has the following pro's:
* the number of authorized ms on the network is limited
* the number of authorized ms is growing at a slow speed
* we have some personal interaction with the respective people and maybe
  can actually ask them to do a MO and MT call during registration, marking
  this handset model (IMEI) as 'known working' or file a bug report.

An automatic registration process obviously has the following pro's:
* we can get virtually everyone onto the network
* we do not need to spend time with registering people.

I'm a bit undecided, but think for HAR2009 we should probably go for a manual
process first.  Only after things have proven reliable in that scale, we can
plan for something bigger next time (26C3).  If everything works fine on the
first day of HAR2009, then we could also switch from manual to the automatic
process, at least if the software already exists.

If the process is still manual but the web-based UI already exists, we can
also see if we can find some random HAR volunteers to do the actual
registration procedure.

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 stefan at datenfreihafen.org  Wed Jul 22 16:32:28 2009
From: stefan at datenfreihafen.org (Stefan Schmidt)
Date: Wed, 22 Jul 2009 18:32:28 +0200
Subject: GSM license approval for HAR2009
In-Reply-To: <20090722153847.GH18204@prithivi.gnumonks.org>
References: <20090722153847.GH18204@prithivi.gnumonks.org>
Message-ID: <20090722163228.GA5337@dodger.lab.datenfreihafen.org>

Hello.

On Wed, 2009-07-22 at 17:38, Harald Welte wrote:
> 
> We have just received regulatory approval for four ARFCN in the GSM900 band
> during HAR2009.  The Power on each ARFCN for BTS and MS is restricted to 100mW.
> 
> There are also some GSM1800 ARFCN's that we can use with up to 200mW, though
> I don't yet know their values and how many.

Great news. It worked out finally.

> It would be great to know which other OpenBSC users/hackers will be present
> at the event.  As there are multiple things that I'm planning to do at HAR2009,
> I would be happy about any help that I might get from you guys.

Daniel, Jan and me will also be there. We already have our cards so the problem
with sold out cards did not catch us. I can only speak for myself, but I would
bet Jan and Daniel are thinking along the same lines, we would be happy to help
out.

> Basically there will be
> 
> * A 'stable' GSM network with BS-11 and OpenBSC for people to test
>   their phone interoperability with OpenBSC by making/receiving calls and
>   SMS.

Great. Covering the whole event with an official GSM network should give us a
lot of fun. :)

> * A nanoBTS1800 for use by OpenBSC hackers only to test/fix OpenBSC stuff
>   before putting it on the BS-11 'stable' network
> 
> * work on airprobe.
> 
> Especially for the 'stable' network, there is a lot of help required, among
> others:
> * physical setup of the BS-11

When do you plan to do this? We haven't settled for final dates yet, but planned
to be around from 12. - 17. Daniel and I should be able to be there earlier. I
would think it would make sense to get the physical infrastructure in place
before most of the people arrive. 10. - 11. for physical software setup sounds
like a good idea to me. That should give us enough time to have it running
stable from 12. to 16.

What about tents, tables, chairs, etc? Is this something we get from the orga or
should organise ourself? I may be able to arrange a big tent plus some tables
and banks. Taking into account that I would need to ask and we have the
transportation proplem I would prefer equipment already at the destination.

> * registration of mobile phones into the network. It would probably be good
>   to have a setup where people can plug their SIM into a SIM card reader
>   (or phone that can read the IMSI).  We can then create the SQL entry with
>   their IMSI and extension.

Maybe some pre-registration over a website which feeds the IMSI into the db and
assigns a number? It would help to spread the load of register 3000 IMSIs during
the event. :) On the other hand it would drain time now. Anyway, I volunteer to
help out dealing with people at the event.

Hmm, another idea pops up into my mind right now. Any chance we can get a big
bunch of pre paid SIMs without money on the account? If we would get some 100s
of them we could prepare them in advance and just hand out to the people.

> * making sure the network runs and OpenBSC / hfcmulti gets restarted in case
>   something hangs.

Should be the job for the same people running the GOC (GSM Operating Center) ;)

I've seen on the wiki side that you will bring two BS-11 for the stable network.
Do you think that are enough, or should Daniel bring his one as well. (Not that
I could stop him putting _everything_ into the car for the event.)

regards
Stefan Schmidt



From laforge at gnumonks.org  Wed Jul 22 21:58:58 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 22 Jul 2009 23:58:58 +0200
Subject: GSM license approval for HAR2009
In-Reply-To: <20090722163228.GA5337@dodger.lab.datenfreihafen.org>
References: <20090722153847.GH18204@prithivi.gnumonks.org>
	<20090722163228.GA5337@dodger.lab.datenfreihafen.org>
Message-ID: <20090722215858.GI20307@prithivi.gnumonks.org>

Hi Stefan!

On Wed, Jul 22, 2009 at 06:32:28PM +0200, Stefan Schmidt wrote:
 
> > It would be great to know which other OpenBSC users/hackers will be present
> > at the event.  As there are multiple things that I'm planning to do at HAR2009,
> > I would be happy about any help that I might get from you guys.
> 
> Daniel, Jan and me will also be there. We already have our cards so the problem
> with sold out cards did not catch us. I can only speak for myself, but I would
> bet Jan and Daniel are thinking along the same lines, we would be happy to help
> out.

Ok, great!

> > Basically there will be
> > 
> > * A 'stable' GSM network with BS-11 and OpenBSC for people to test
> >   their phone interoperability with OpenBSC by making/receiving calls and
> >   SMS.
> 
> Great. Covering the whole event with an official GSM network should give us a
> lot of fun. :)

well, I basically want to avoid the impression that this is a phone network for
reliable use for everyone.  The software will not run stable enough, and I
suspect many interoperability reasons.  Also, our capacity is too small for the
number of people at the event.

"stable" means that this is not where we should test each and every of our
committ's, but rather run something that we expect to behave as sane/stable
as possible.

> > Especially for the 'stable' network, there is a lot of help required, among
> > others:
> > * physical setup of the BS-11
> 
> When do you plan to do this? We haven't settled for final dates yet, but planned
> to be around from 12. - 17. Daniel and I should be able to be there earlier. I
> would think it would make sense to get the physical infrastructure in place
> before most of the people arrive. 10. - 11. for physical software setup sounds
> like a good idea to me. That should give us enough time to have it running
> stable from 12. to 16.

I don't really know yet.  I'll ask the HAR guys how early we can start to put
up our equipment.

> What about tents, tables, chairs, etc? Is this something we get from the orga
> or should organise ourself? I may be able to arrange a big tent plus some
> tables and banks. Taking into account that I would need to ask and we have
> the transportation proplem I would prefer equipment already at the
> destination.

Don't count on any equipment being there for us.  I'll bring my own personal
tent (well, it is a tent intended for 5 people AFAIR), but that's it.

If we start to ask for support from HAR, I think this will in turn raise the
expectations that we actually provide a stable operational service for them -
something that I think we simply cannot provide yet.

> > * registration of mobile phones into the network. It would probably be good
> >   to have a setup where people can plug their SIM into a SIM card reader
> >   (or phone that can read the IMSI).  We can then create the SQL entry with
> >   their IMSI and extension.
> 
> Maybe some pre-registration over a website which feeds the IMSI into the db and
> assigns a number? It would help to spread the load of register 3000 IMSIs during
> the event. :) On the other hand it would drain time now. Anyway, I volunteer to
> help out dealing with people at the event.
> 
> Hmm, another idea pops up into my mind right now. Any chance we can get a big
> bunch of pre paid SIMs without money on the account? If we would get some 100s
> of them we could prepare them in advance and just hand out to the people.

well, those SIM's would have to be sold, and that would mean dealing with cash,
dealing with change, etc. - not very practical IMHO.  Also, if we sell something,
that again leads to the conclusion that people should get something in return.

It might also raise the wrong impression to the regulatory authority if we actually
charge money for anything.

> > * making sure the network runs and OpenBSC / hfcmulti gets restarted in case
> >   something hangs.
> 
> Should be the job for the same people running the GOC (GSM Operating Center) ;)
 
heh.  well, we can have a simple script that respawns the two (in the right
order) if bsc_hack dies.  We should have 'ulimit -c unlimited' and store all
the core files for later debugging.  Also, the pcap files have to be rotated
away at every bsc_hack restart.

We also need to ensure that we save the bsc_hack binary that corresponds to the
respective core versions.  Maybe actually the entire corresponding source tree
for gdb.

That would be a task for our pre-HAR TODO list (I'll start one soon).

> I've seen on the wiki side that you will bring two BS-11 for the stable network.
> Do you think that are enough, or should Daniel bring his one as well. (Not that
> I could stop him putting _everything_ into the car for the event.)

Well, I think it is always good to have another unit, and if only as spare part
in case one breaks or magicall disappears.  Apart from that, it might also help
for testing BS-11 specific code on something that is not the production network.

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 stefan at datenfreihafen.org  Thu Jul 23 16:47:59 2009
From: stefan at datenfreihafen.org (Stefan Schmidt)
Date: Thu, 23 Jul 2009 18:47:59 +0200
Subject: GSM license approval for HAR2009
In-Reply-To: <20090722215858.GI20307@prithivi.gnumonks.org>
References: <20090722153847.GH18204@prithivi.gnumonks.org>
	<20090722163228.GA5337@dodger.lab.datenfreihafen.org>
	<20090722215858.GI20307@prithivi.gnumonks.org>
Message-ID: <20090723164759.GC21010@excalibur.local>

Hello.

On Wed, 2009-07-22 at 23:58, Harald Welte wrote:
> 
> On Wed, Jul 22, 2009 at 06:32:28PM +0200, Stefan Schmidt wrote:
> 
> > > Basically there will be
> > > 
> > > * A 'stable' GSM network with BS-11 and OpenBSC for people to test
> > >   their phone interoperability with OpenBSC by making/receiving calls and
> > >   SMS.
> > 
> > Great. Covering the whole event with an official GSM network should give us a
> > lot of fun. :)
> 
> well, I basically want to avoid the impression that this is a phone network for
> reliable use for everyone.  The software will not run stable enough, and I
> suspect many interoperability reasons.  Also, our capacity is too small for the
> number of people at the event.

OK, so it should be announced more as an field test to help us getting in touch
with problematic handsets and other issues. Fine with me. We just need to make
sure communicating people this.

> > When do you plan to do this? We haven't settled for final dates yet, but planned
> > to be around from 12. - 17. Daniel and I should be able to be there earlier. I
> > would think it would make sense to get the physical infrastructure in place
> > before most of the people arrive. 10. - 11. for physical software setup sounds
> > like a good idea to me. That should give us enough time to have it running
> > stable from 12. to 16.
> 
> I don't really know yet.  I'll ask the HAR guys how early we can start to put
> up our equipment.

OK.

> > What about tents, tables, chairs, etc? Is this something we get from the orga
> > or should organise ourself? I may be able to arrange a big tent plus some
> > tables and banks. Taking into account that I would need to ask and we have
> > the transportation proplem I would prefer equipment already at the
> > destination.
> 
> Don't count on any equipment being there for us.  I'll bring my own personal
> tent (well, it is a tent intended for 5 people AFAIR), but that's it.
> 
> If we start to ask for support from HAR, I think this will in turn raise the
> expectations that we actually provide a stable operational service for them -
> something that I think we simply cannot provide yet.

Hmm, ok. Do you remember the tent we had at the last CCC camp? I may be able to
get that one again. Also some tables and banks. That should give us enough place
for the GOC equipment and space to hack. Will call soem people over the next
days and see if I can get it again. What worries me a bit is the transportation.
We brought the same set even to WTH four years ago, but we had two fully packed
cars. Well, we will figure something out. I'll let you know.

> > Maybe some pre-registration over a website which feeds the IMSI into the db and
> > assigns a number? It would help to spread the load of register 3000 IMSIs during
> > the event. :) On the other hand it would drain time now. Anyway, I volunteer to
> > help out dealing with people at the event.
> > 
> > Hmm, another idea pops up into my mind right now. Any chance we can get a big
> > bunch of pre paid SIMs without money on the account? If we would get some 100s
> > of them we could prepare them in advance and just hand out to the people.
> 
> well, those SIM's would have to be sold, and that would mean dealing with cash,
> dealing with change, etc. - not very practical IMHO.  Also, if we sell something,
> that again leads to the conclusion that people should get something in return.
> 
> It might also raise the wrong impression to the regulatory authority if we actually
> charge money for anything.

I was thinking along the loines to hand out the SIMs for free. Was just an idea
to offload some of the registration work from the actual event. I think we can
strike that idea. Giving the information that we don't what do cover all people
and announce it as a field test in combination with maybe implemented SMS token
register it does not make much sense anymore. :)

> > > * making sure the network runs and OpenBSC / hfcmulti gets restarted in case
> > >   something hangs.
> > 
> > Should be the job for the same people running the GOC (GSM Operating Center) ;)
>  
> heh.  well, we can have a simple script that respawns the two (in the right
> order) if bsc_hack dies.  We should have 'ulimit -c unlimited' and store all
> the core files for later debugging.  Also, the pcap files have to be rotated
> away at every bsc_hack restart.
> 
> We also need to ensure that we save the bsc_hack binary that corresponds to the
> respective core versions.  Maybe actually the entire corresponding source tree
> for gdb.
> 
> That would be a task for our pre-HAR TODO list (I'll start one soon).

I have to deal with an exam until 30.07. Afterwards I may be able to help out in
the preparations.

> > I've seen on the wiki side that you will bring two BS-11 for the stable network.
> > Do you think that are enough, or should Daniel bring his one as well. (Not that
> > I could stop him putting _everything_ into the car for the event.)
> 
> Well, I think it is always good to have another unit, and if only as spare part
> in case one breaks or magicall disappears.  Apart from that, it might also help
> for testing BS-11 specific code on something that is not the production network.

Just talked to him (we will reply in more details I guess). He will bring his
BS-11. And another big item to transport on the list. ;)

regards
Stefan Schmidt



From stefan at datenfreihafen.org  Tue Jul 28 12:18:06 2009
From: stefan at datenfreihafen.org (Stefan Schmidt)
Date: Tue, 28 Jul 2009 14:18:06 +0200
Subject: GSM license approval for HAR2009
In-Reply-To: <20090723164759.GC21010@excalibur.local>
References: <20090722153847.GH18204@prithivi.gnumonks.org>
	<20090722163228.GA5337@dodger.lab.datenfreihafen.org>
	<20090722215858.GI20307@prithivi.gnumonks.org>
	<20090723164759.GC21010@excalibur.local>
Message-ID: <20090728121806.GA9184@excalibur.local>

Hello.

On Thu, 2009-07-23 at 18:47, Stefan Schmidt wrote:
>
> Hmm, ok. Do you remember the tent we had at the last CCC camp? I may be able to
> get that one again. Also some tables and banks.

I reserved the tent plus 3 tables and banks from 11.8 - to 18.8 now. The tent is
an SG30, means to cover an area of 30 square meter. Should we inform the HAR
orga about the size and a preferred place?

regards
Stefan Schmidt



From laforge at gnumonks.org  Tue Jul 28 17:20:36 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 28 Jul 2009 19:20:36 +0200
Subject: GSM license approval for HAR2009
In-Reply-To: <20090728121806.GA9184@excalibur.local>
References: <20090722153847.GH18204@prithivi.gnumonks.org>
	<20090722163228.GA5337@dodger.lab.datenfreihafen.org>
	<20090722215858.GI20307@prithivi.gnumonks.org>
	<20090723164759.GC21010@excalibur.local>
	<20090728121806.GA9184@excalibur.local>
Message-ID: <20090728172036.GL1434@prithivi.gnumonks.org>

On Tue, Jul 28, 2009 at 02:18:06PM +0200, Stefan Schmidt wrote:
> Hello.
> 
> On Thu, 2009-07-23 at 18:47, Stefan Schmidt wrote:
> >
> > Hmm, ok. Do you remember the tent we had at the last CCC camp? I may be able to
> > get that one again. Also some tables and banks.
> 
> I reserved the tent plus 3 tables and banks from 11.8 - to 18.8 now. The tent is
> an SG30, means to cover an area of 30 square meter. 

Awesome.  Thanks a lot!

> Should we inform the HAR orga about the size and a preferred place?

I've sent a separate (private) mail to the organizers, asking them to contact
you on how to proceed.

-- 
- 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  Wed Jul 22 19:10:51 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Wed, 22 Jul 2009 19:10:51 CEST
Subject: GSM license approval for HAR2009
Message-ID: <4a67643b.mirider@mirider.augusta.de>

Hello Stefan,

On Wed, 22 Jul 2009 18:32:28 +0200, "Stefan Schmidt" <stefan at datenfreihafen.org> wrote:
> 
> Hmm, another idea pops up into my mind right now. Any chance we can get a big
> bunch of pre paid SIMs without money on the account? If we would get some 100s
> of them we could prepare them in advance and just hand out to the people.

Kai Muenz mentioned it on the list already, there are GSM SIMs available
at http://www.dealextreme.com/details.dx/sku.16159. 10 pieces cost $US 3.94
including shipping. If you don't mind about a Chinese SIM Toolkit Menu which
you can't read and also don't mind to remove a little bit of glue from
some of the SIMs, they are fine for this purpose.

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



From stefan at datenfreihafen.org  Wed Jul 22 17:36:16 2009
From: stefan at datenfreihafen.org (Stefan Schmidt)
Date: Wed, 22 Jul 2009 19:36:16 +0200
Subject: GSM license approval for HAR2009
In-Reply-To: <4a67643b.mirider@mirider.augusta.de>
References: <4a67643b.mirider@mirider.augusta.de>
Message-ID: <20090722173616.GD5337@dodger.lab.datenfreihafen.org>

Hello.

On Wed, 2009-07-22 at 19:10, Dieter Spaar wrote:
> 
> On Wed, 22 Jul 2009 18:32:28 +0200, "Stefan Schmidt" <stefan at datenfreihafen.org> wrote:
> > 
> > Hmm, another idea pops up into my mind right now. Any chance we can get a big
> > bunch of pre paid SIMs without money on the account? If we would get some 100s
> > of them we could prepare them in advance and just hand out to the people.
> 
> Kai Muenz mentioned it on the list already, there are GSM SIMs available
> at http://www.dealextreme.com/details.dx/sku.16159. 10 pieces cost $US 3.94
> including shipping. If you don't mind about a Chinese SIM Toolkit Menu which
> you can't read and also don't mind to remove a little bit of glue from
> some of the SIMs, they are fine for this purpose.

Hmm, if we would calculate with 200 cards we would have ~80 USD costs for them.
Maybe not the baddest thing. Let's wait to what conclusion we come here before
going ahead. A technical solution that let the user handle the registration on
it's own is still my favorit. Sadly we can't estimate how many subscribers we
will get. :)

regards
Stefan Schmidt



From spaar at mirider.augusta.de  Wed Jul 22 19:58:00 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Wed, 22 Jul 2009 19:58:00 CEST
Subject: GSM license approval for HAR2009
Message-ID: <4a676f48.mirider@mirider.augusta.de>

Hello Stefan,

On Wed, 22 Jul 2009 19:36:16 +0200, "Stefan Schmidt" <stefan at datenfreihafen.org> wrote:
> 
> Hmm, if we would calculate with 200 cards we would have ~80 USD costs for them.
> Maybe not the baddest thing. Let's wait to what conclusion we come here before
> going ahead. A technical solution that let the user handle the registration on
> it's own is still my favorit. Sadly we can't estimate how many subscribers we
> will get. :)

I don't know if you get a better price if you buy such a large amount of
the SIM cards, but I would ask.

One advantage of handing out SIM cards: You can play with authentication
and encryption if you want to. The A3/A8 algorithm in the SIM cards seems
to be different from COMP128-V1 (at least with the SIM I tested) so you
cannot retrieve Ki. However you could run the authentication in advance
and record a few challenge-reponse pairs and use them later.

And if you take one Euro as deposit for the SIM, you might get them
back or don't care if not.

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



From spaar at mirider.augusta.de  Thu Jul 23 08:43:26 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Thu, 23 Jul 2009 08:43:26 CEST
Subject: GSM license approval for HAR2009
Message-ID: <4a6822ae.mirider@mirider.augusta.de>

Hello Harald,

On Wed, 22 Jul 2009 23:49:00 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> 
> Even with two BTS at two TRX (exercising all our four ARFCN), the total call
> capacity is not more than 13 simultanesous MS-to-MS calls (since each call
> requires two timeslots).  Yes we could do half-rate, but we have no software
> support for that so far.

You have the adjacent channels 121 to 124 for GSM 900 ? As far as I am
aware, adjacent channels will disturb each other. From what I know,
real networks usually have one free guard channel in between. So at
least the configuration of using adjacent channels should be checked
in advance (but you don't know how well different phones behave).

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



From laforge at gnumonks.org  Thu Jul 23 07:40:34 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 23 Jul 2009 09:40:34 +0200
Subject: GSM license approval for HAR2009
In-Reply-To: <4a6822ae.mirider@mirider.augusta.de>
References: <4a6822ae.mirider@mirider.augusta.de>
Message-ID: <20090723074034.GC21731@prithivi.gnumonks.org>

On Thu, Jul 23, 2009 at 08:43:26AM +0200, Dieter Spaar wrote:
> Hello Harald,
> 
> On Wed, 22 Jul 2009 23:49:00 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> > 
> > Even with two BTS at two TRX (exercising all our four ARFCN), the total call
> > capacity is not more than 13 simultanesous MS-to-MS calls (since each call
> > requires two timeslots).  Yes we could do half-rate, but we have no software
> > support for that so far.
> 
> You have the adjacent channels 121 to 124 for GSM 900 ? As far as I am
> aware, adjacent channels will disturb each other. From what I know,
> real networks usually have one free guard channel in between. So at
> least the configuration of using adjacent channels should be checked
> in advance (but you don't know how well different phones behave).

yes, we should check that in advance.  Also, if we have two BTS at different
geographic locations, we might very well have 121 + 123 for one, and 122 + 124
for the other one.

For testing it is probably sufficient to use two adjacend channels on two TRX's
of one BTS.

-- 
- 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 Jul 23 09:43:38 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Thu, 23 Jul 2009 11:43:38 +0200
Subject: GSM license approval for HAR2009
In-Reply-To: <20090723074034.GC21731@prithivi.gnumonks.org>
References: <4a6822ae.mirider@mirider.augusta.de>
	<20090723074034.GC21731@prithivi.gnumonks.org>
Message-ID: <4A6830CA.8070406@gmail.com>

Well congratulation,

Too bad for me the tickets are sold out. Cause this is a great 
opportunity to meet you guys there and help you.
It would be nice if such an event could be posted in the list before, so 
we can react quickly.
Anyway, I hope you'll have a lot of fun there :)




From codec at muc.ccc.de  Tue Jul 28 18:24:20 2009
From: codec at muc.ccc.de (codec)
Date: Tue, 28 Jul 2009 20:24:20 +0200
Subject: GSM license approval for HAR2009
In-Reply-To: <20090722153847.GH18204@prithivi.gnumonks.org>
References: <20090722153847.GH18204@prithivi.gnumonks.org>
Message-ID: <20090728202420.1902b989@dilbert>

Hi,

do you need another BS11? We could bring the one from MuCCC (including
a server with an E1 card).

cheers, codec.



From laforge at gnumonks.org  Wed Jul 29 08:40:14 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 29 Jul 2009 10:40:14 +0200
Subject: GSM license approval for HAR2009
In-Reply-To: <20090728202420.1902b989@dilbert>
References: <20090722153847.GH18204@prithivi.gnumonks.org>
	<20090728202420.1902b989@dilbert>
Message-ID: <20090729084014.GD1434@prithivi.gnumonks.org>

Hi Codec,

On Tue, Jul 28, 2009 at 08:24:20PM +0200, codec wrote:
 
> do you need another BS11? We could bring the one from MuCCC (including
> a server with an E1 card).

Thanks, we don't need it.  I still have plenty of them, but we cannot use
many due to our restrictions on 4 ARFCN's.

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 laforge at gnumonks.org  Wed Jul 22 22:26:14 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 23 Jul 2009 00:26:14 +0200
Subject: HAR2009 TODO list
Message-ID: <20090722222614.GJ20307@prithivi.gnumonks.org>

Hi again,

I'm currently in the train, so forgive me posting the initial TODO list
to the mailing list rather than the wiki.

I'll put it in the wiki soon.  If you want to take on of the items, just let
me know!

What I think we have to do before HAR is as follows:

== Actual code ==

=== absolutely required ===

* finish and test the SMS implementation [Harald]
* make sure we enable MS power control and impose a global limit of
  100mW for the uplink (MS->BSC) direction by means of the MS POWER IE's
  and the BCCH information.  That sounds like something for Dieter to
  figure out, especially since he has measurement equipment ;)
* test dual-BTS-on-single-E1-card config [Harald]
** up to now, we have only tested with two nanoBTS, not BS-11 !
* test dual-TRX operation of BS-11 on OpenBSC [Stefan/Daniel, can you do that?]
** channel allocator can be tweaked to give 2nd TRX a preference for debugging

[I'll add those to trac, since they are really important]

=== optional ===

* implement a 'provisioning mode' to OpenBSC that 
** acccepts every new IMSI the first time we see it
** sends a SMS with a auth token to that mobile
** disconnects that mobile immediately
* implement a web site / cgi script
** once user enters correct tuple of ISMI + auth code, we
*** assign him a number (user cannot choose, we assign)
*** set authorized=1 in the sql table
* implement a web site bug tracker for user bug reports
** the should include detailed information about the phone model,
   his phone number and the exact timestamp, so we can match it in
   the pcap's
* add more introspection code for the VTY interface to explore the run-time
  data structures in OpenBSC
* implement different TCH assignment schemes (early / very early / OCASU)
* do we really want a SDCCH/8 or is SDCCH/4 for each BTS sufficient?
* some more testing with two BTS
* in case we call a user who is currently offline/busy, generate SMS
  about missed call and store it in the SMS table
* web interface ideas
** SMS gateway where people can send SMS from the web site
*** SMS spam function for us in case we want to inform users about something
** simplistic phone book
* enhance vty interface with administrative functions such as
** ability to close arbitrary channels (i.e. terminate a call)
** ability to kick-ban a user out of the network
*** set authorized=0
*** perform authentication procedure with reject at its end
* make sure we store all the 'this phone was registerd before to MCC/MNC/LAC'
  from the LOC UPD REQ data
* make sure we really store the classmark1/2/3 together with IMEI in SQL table

== Things to bring to the event ==

* spectrum analyzer [from CCCB]
* stable OCXO reference to calibrate BS-11 internal clock
** this could be done before the event, but Harald has no precision clock source
* trace mobiles / monitor mode mobiles (if anyone has some)
* some poles to which we can mount the BS-11 ?

== Misc ==

* draft 'usage terms & conditions' to be put on the registration web site
  and the HAR2009 wiki, indicating
** all signalling and traffic data will be stored for R&D purpose
** we do not employ authentication and/or encryption
** we do not provide any service guarantee
** this is for evaluation+testing only
** no handover/roaming and/or external calls
** no warranty for any damage to MS, SIM, ...
** IMSI/IMEI information will not be disclosed by us, but people can sniff it

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 laforge at gnumonks.org  Thu Jul 23 07:39:10 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 23 Jul 2009 09:39:10 +0200
Subject: HAR2009 TODO list
In-Reply-To: <20090722222614.GJ20307@prithivi.gnumonks.org>
References: <20090722222614.GJ20307@prithivi.gnumonks.org>
Message-ID: <20090723073910.GB21731@prithivi.gnumonks.org>

On Thu, Jul 23, 2009 at 12:26:14AM +0200, Harald Welte wrote:
> Hi again,
> 
> I'm currently in the train, so forgive me posting the initial TODO list
> to the mailing list rather than the wiki.

this is now at http://bs11-abis.gnumonks.org/trac/wiki/HAR2009

-- 
- 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  Fri Jul 24 08:04:19 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Fri, 24 Jul 2009 10:04:19 +0200
Subject: AW: HAR2009 TODO list
Message-ID: <B16317F2B1592B4492FC414114171CE6DB901A@FLBVEXCH01.versatel.local>

 
>On Thu, Jul 23, 2009 at 12:26:14AM +0200, Harald Welte wrote:
>> Hi again,
>> 
>> I'm currently in the train, so forgive me posting the initial TODO
list
>> to the mailing list rather than the wiki.
>
>this is now at http://bs11-abis.gnumonks.org/trac/wiki/HAR2009


Check out Eventphone. They run DECT network. Why not linking to their
network? I am not at HAR, but I can help setting it up. An extra E1 card
is required to link to Eventphone's machine...

http://www.eventphone.de/guru/?language=de



From laforge at gnumonks.org  Sun Jul 26 08:42:45 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 26 Jul 2009 10:42:45 +0200
Subject: HAR2009 TODO list
In-Reply-To: <B16317F2B1592B4492FC414114171CE6DB901A@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE6DB901A@FLBVEXCH01.versatel.local>
Message-ID: <20090726084245.GI7204@prithivi.gnumonks.org>

Hi Andreas,

On Fri, Jul 24, 2009 at 10:04:19AM +0200, Andreas.Eversberg wrote:
  
> >On Thu, Jul 23, 2009 at 12:26:14AM +0200, Harald Welte wrote:
> >> Hi again,
> >> 
> >> I'm currently in the train, so forgive me posting the initial TODO
> list
> >> to the mailing list rather than the wiki.
> >
> >this is now at http://bs11-abis.gnumonks.org/trac/wiki/HAR2009
> 
> 
> Check out Eventphone. They run DECT network. Why not linking to their
> network? I am not at HAR, but I can help setting it up. An extra E1 card
> is required to link to Eventphone's machine...

Yes, I'm very aware of the PoC / Eventphone and I know the people doing it
personally for years.

To me, I think this is one step too big for the current installation.

First of all, a link to DECT would increase the usability and thus drastically
increase the demand for something that is intended to be an OpenBSC
interop/testing network, and cannot yet be a public service - for capacity 
reasons and because I don't trust OpenBSC that much yet.

Secondly, routing to DECT will probably still be permissible within the license
we have, but routing to land line would effectively make us a telco and that is
definitely not possible.  Sure, such filtering could be implemented at the Poc.

Also, I think we have plenty of problems to debug and fix when OpenBSC suddenly
faces this kind of load.  No need to further increae the complexity.

If everything works fine at HAR, we can do the bigger/better version at 26C3,
at least if we can somehow find more than the 2-3 nanoBTS1800 that we currently
have - at least for a couple of days.

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  Mon Jul 27 08:02:42 2009
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 27 Jul 2009 10:02:42 +0200
Subject: AW: HAR2009 TODO list
Message-ID: <B16317F2B1592B4492FC414114171CE6DB96E4@FLBVEXCH01.versatel.local>

 
> If everything works fine at HAR, we can do the bigger/better version
at 26C3,
> at least if we can somehow find more than the 2-3 nanoBTS1800 that we
currently
> have - at least for a couple of days.

hi harald,

i am looking forward to be at 26C3. i doubt that we can get a frequency
for a test network on the 900 band, because all frequencies are assigned
to GSM operators. therefore only nanoBTS1800 can be run legaly with a
test license of "bundesnetzagentur". currently the application interface
does not support audio streams of the nanoBTS, so other networks
(ISDN/DECT/SIP) cannot be connected yet. i would like to finish audio
processing for nanoBTS. can you provide me with some pcap files? a short
complete call (few seconds) of one rtp session (including setup, some
spoken words, and termination) would help. also the call must be made
with full rate codec, so i can test the playload on the GSM codec i
have. (not the enhanced full rate codec)

regards,

andreas



From laforge at gnumonks.org  Mon Jul 27 17:59:01 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 27 Jul 2009 19:59:01 +0200
Subject: HAR2009 TODO list
In-Reply-To: <B16317F2B1592B4492FC414114171CE6DB96E4@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE6DB96E4@FLBVEXCH01.versatel.local>
Message-ID: <20090727175901.GM22498@prithivi.gnumonks.org>

On Mon, Jul 27, 2009 at 10:02:42AM +0200, Andreas.Eversberg wrote:

> i am looking forward to be at 26C3. i doubt that we can get a frequency
> for a test network on the 900 band, because all frequencies are assigned
> to GSM operators. therefore only nanoBTS1800 can be run legaly with a
> test license of "bundesnetzagentur". 

There is still the option of finding a GSM900 operator to allow us to use
some of their ARFCN's - but given that the 26C3 happens at Alexanderplatz
in central berlin, I think they cannot do that without actually disabling
some of their own TRX's in that region, i.e. without severe impact to their
own network - which they will never do.  Nonetheless, we can ask.

I think we might be able to use holger + dieter + my nanoBTS 1800 at 26C3,
maybe something like one on each floor. 

> currently the application interface does not support audio streams of the
> nanoBTS, so other networks (ISDN/DECT/SIP) cannot be connected yet. 

yes, I'm aware of that.

> i would like to finish audio processing for nanoBTS. can you provide me with
> some pcap files? a short complete call (few seconds) of one rtp session
> (including setup, some spoken words, and termination) would help. 

I will prepare this for you, no problem.  I have the equipment with me and will
probably send another mail later tonight.

> also the call must be made with full rate codec, so i can test the playload
> on the GSM codec i have. (not the enhanced full rate codec)

of course.

One thing that comes into my mind is that the entire TRAU frame handling (and
nanoBTS RTP media handling) should be moved into its own 'media gateway'
process.  It would be great if you feel like doing this conversion, too.

I think once the split is implemented, the MNCC interface to the media gateway
process will inevitably be more general (i.e. less E1 specific).  Adding
MNCC/application support for the nanoBTS would probably be easy at that point.

Running OpenBSC with BS-11 and nanoBTS at the same time should also be
possible at that point, since the media gateway would already be able to do
input and output of both TRAU frames and RTP.

-- 
- 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  Tue Jul 28 17:18:52 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 28 Jul 2009 19:18:52 +0200
Subject: application TCH support for nanoBTS
In-Reply-To: <20090727175901.GM22498@prithivi.gnumonks.org>
References: <B16317F2B1592B4492FC414114171CE6DB96E4@FLBVEXCH01.versatel.local>
	<20090727175901.GM22498@prithivi.gnumonks.org>
Message-ID: <20090728171852.GK1434@prithivi.gnumonks.org>

Hi Andreas,

On Mon, Jul 27, 2009 at 07:59:01PM +0200, Harald Welte wrote:

> > i would like to finish audio processing for nanoBTS. can you provide me with
> > some pcap files? a short complete call (few seconds) of one rtp session
> > (including setup, some spoken words, and termination) would help. 
> 
> I will prepare this for you, no problem.  I have the equipment with me and will
> probably send another mail later tonight.

In fact, it was much more difficult than expected.  Since I only have one
nanoBTS available right now, all RTP sessions usually originate and terminate
on the device itelf and you never see the RTP streams.

So I've had to add RTP/RTCP proxy functionality to OpenBSC first.  Now even calls
between two MS on the same BTS can be routed via the RTP/RTCP proxy (by using
the new "-P" option of bsc_hack).

Using this mode, I have created a pcap file with OML+RSL bringup, followed by
one call between two MS (extn. 1005 calls 1003) where all RTP/RTCP packets are
visible.  The call uses EFR, since that is hardcoded in many places all over
OpenBSC at the moment.

The pcap file is available from
http://bs11-abis.gnumonks.org/trac/attachment/wiki/nanoBTS/ipaccess-startup-mo_to_mo_call-proxy.pcap

The call content is an inquiry about the subway schedule between a male and a
female speaker.

Using the rtp_proxy code as a reference, it should be relatively easy to
take those RTP packets and stuff them in TRAU frames (or vice versa), or
passt their content upwards to an application.

Also, we still want to see the TRAU and RTP code move into a separate process.
I've tried to prepare by ths, impementing all RTP related functions in
gsm_04_08 rather than abis_rsl.

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 spaar at mirider.augusta.de  Tue Jul 28 20:58:46 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Tue, 28 Jul 2009 20:58:46 CEST
Subject: application TCH support for nanoBTS
Message-ID: <4a6f6686.mirider@mirider.augusta.de>

Hello Harald,

On Tue, 28 Jul 2009 19:18:52 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> 
> Using this mode, I have created a pcap file with OML+RSL bringup, followed by
> one call between two MS (extn. 1005 calls 1003) where all RTP/RTCP packets are
> visible.  The call uses EFR, since that is hardcoded in many places all over
> OpenBSC at the moment.
> 
> The pcap file is available from
> http://bs11-abis.gnumonks.org/trac/attachment/wiki/nanoBTS/ipaccess-startup-mo_to_mo_call-proxy.pcap

I just took a quick look at the dump with Wireshark, its possible to
safe the raw RTP payload from within Wireshark and it looks OK (31-byte
EFR packages starting with 0xC in the high nibble). However I have
no ready-made EFR decoder available so I can't decode the speech.

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



From spaar at mirider.augusta.de  Wed Jul 29 12:26:47 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Wed, 29 Jul 2009 12:26:47 CEST
Subject: application TCH support for nanoBTS
Message-ID: <4a704007.mirider@mirider.augusta.de>

Hello Harald,

On Tue, 28 Jul 2009 20:58:46 CEST, "Dieter Spaar" <spaar at mirider.augusta.de> wrote:
> 
> I just took a quick look at the dump with Wireshark, its possible to
> safe the raw RTP payload from within Wireshark and it looks OK (31-byte
> EFR packages starting with 0xC in the high nibble). However I have
> no ready-made EFR decoder available so I can't decode the speech.

I did play a little bit with the EFR reference implementation from
GSM 06.35. Its possible to convert the data and I can understand a few
words (a "Yes" at the beginning and a "Bye" at the end). However it seems
that several RTP packages are missing, also the RTP Analysis Tool of
Wireshark says so (according to it more than 80% is missing). Anyway,
basically EFR decoding seems to work as expected.

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



From codec at muc.ccc.de  Tue Jul 28 18:49:46 2009
From: codec at muc.ccc.de (codec)
Date: Tue, 28 Jul 2009 20:49:46 +0200
Subject: HAR2009 TODO list
In-Reply-To: <B16317F2B1592B4492FC414114171CE6DB96E4@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE6DB96E4@FLBVEXCH01.versatel.local>
Message-ID: <20090728204946.1e71eb54@dilbert>

hi,

On Mon, 27 Jul 2009 10:02:42 +0200
"Andreas.Eversberg" <Andreas.Eversberg at versatel.de> wrote:
> i am looking forward to be at 26C3. i doubt that we can get a
> frequency for a test network on the 900 band, because all frequencies
> are assigned to GSM operators. therefore only nanoBTS1800 can be run
> legaly with a test license of "bundesnetzagentur". currently the
> application interface does not support audio streams of the nanoBTS,
> so other networks (ISDN/DECT/SIP) cannot be connected yet. i would
> like to finish audio processing for nanoBTS. can you provide me with
> some pcap files? a short complete call (few seconds) of one rtp
> session (including setup, some spoken words, and termination) would
> help. also the call must be made with full rate codec, so i can test
> the playload on the GSM codec i have. (not the enhanced full rate
> codec)

i've been talking to the bundesnetzagentur about test frequencies and
temporary event frequencies for the SIGINT in cologne. i've actually
made it through the whole bureaucratic process, but they had to reject
us, because we applied to late (guess it takes >2 weeks, we applied 5
days before the event ;).

they didn't sound like there's no way we can get a frequency. but they
told me that we are NOT allowed to connect our network to the normal
telephone network (e.g. via eventphone).

so, i might talk to the bundesnetzagentur about 26c3 if you want.

cheers, codec



From laforge at gnumonks.org  Wed Jul 29 08:43:23 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 29 Jul 2009 10:43:23 +0200
Subject: Bundesnetzagentur / 26C3 (Re: HAR2009 TODO list)
In-Reply-To: <20090728204946.1e71eb54@dilbert>
References: <B16317F2B1592B4492FC414114171CE6DB96E4@FLBVEXCH01.versatel.local>
	<20090728204946.1e71eb54@dilbert>
Message-ID: <20090729084323.GE1434@prithivi.gnumonks.org>

On Tue, Jul 28, 2009 at 08:49:46PM +0200, codec wrote:
> i've been talking to the bundesnetzagentur about test frequencies and
> temporary event frequencies for the SIGINT in cologne. i've actually
> made it through the whole bureaucratic process, but they had to reject
> us, because we applied to late (guess it takes >2 weeks, we applied 5
> days before the event ;).

Well, the question is whether or not there is any GSM900 spectrum left that
they can actually assign to you.  I have spoken with the respective person
at the Bundesnetzagentur, and at least for Berlin he indicated that there
is absolutely no such free ARFCN that they could assign to me for a test
license.

Instead, he argued we should obtain permission from one of the licensees (i.e.
GSM operators) and then show that permission to the Bundesnetzagentur.

> they didn't sound like there's no way we can get a frequency. but they
> told me that we are NOT allowed to connect our network to the normal
> telephone network (e.g. via eventphone).

yes, that is obvious.

> so, i might talk to the bundesnetzagentur about 26c3 if you want.

Sure, feel free to do it.  Talking/asking never hurst.  But I think GSM900
is not going to work out.  Which leaves us with GSM1800, which in turn means no
BS-11.
 
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 daniel at totalueberwachung.de  Thu Jul 30 01:34:58 2009
From: daniel at totalueberwachung.de (Daniel Willmann)
Date: Thu, 30 Jul 2009 03:34:58 +0200
Subject: HAR2009 TODO list
In-Reply-To: <20090722222614.GJ20307@prithivi.gnumonks.org>
References: <20090722222614.GJ20307@prithivi.gnumonks.org>
Message-ID: <20090730033458.6c45c6a8@adrastea.totalueberwachung.de>

Hi,

On Thu, 23 Jul 2009 00:26:14 +0200
Harald Welte <laforge at gnumonks.org> wrote:

> === absolutely required ===
> 
> * test dual-TRX operation of BS-11 on OpenBSC [Stefan/Daniel, can you
> do that?] 
> ** channel allocator can be tweaked to give 2nd TRX a
> preference for debugging

yeah, I can test that. What do you want me to do exactly? See if I can
register to OpenBSC via both TRX?

Regards,
Daniel Willmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090730/430b1ecb/attachment.bin>

From raza_hamdani at hotmail.com  Thu Jul 23 11:47:03 2009
From: raza_hamdani at hotmail.com (raza shah)
Date: Thu, 23 Jul 2009 17:47:03 +0600
Subject: new to OpenBSC
Message-ID: <SNT113-W236568971D8286B669BBFDFE180@phx.gbl>


Hi everyone,                 I am new to OpenBSC and I think the best way to contribute to it is to get to know the source code first. I would appreciate any help regarding how to begin understanding the source code. And what are the main features of the code? What is the best approach to start learning OpenBSC. And is there any good material on OpenBSC.?
Thanks.
_________________________________________________________________
Share your memories online with anyone you want.
http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090723/f5f211f8/attachment.htm>

From zecke at selfish.org  Thu Jul 23 12:11:37 2009
From: zecke at selfish.org (Holger Freyther)
Date: Thu, 23 Jul 2009 14:11:37 +0200
Subject: new to OpenBSC
In-Reply-To: <SNT113-W236568971D8286B669BBFDFE180@phx.gbl>
References: <SNT113-W236568971D8286B669BBFDFE180@phx.gbl>
Message-ID: <200907231411.38719.zecke@selfish.org>

On Thursday 23 July 2009 13:47:03 raza shah wrote:
> Hi everyone,                 I am new to OpenBSC and I think the best way
> to contribute to it is to get to know the source code first. I would
> appreciate any help regarding how to begin understanding the source code.
> And what are the main features of the code? What is the best approach to
> start learning OpenBSC. And is there any good material on OpenBSC.? Thanks.

Welcome,

we attempt to implement the BSC interface. You can take a look at the GSM 
08.02 specification to see the functional split of the BSC and MSC. The main 
functionality of BSC is probably reliable channel management. In the absence 
of another MSC we also have some layer3 and layer4 implementation in the code.

- At the bottom we have the input (either mISDN or ipaccess)
- This goes to rsl and oml management
- On top of that we have gsm_04_08.c
- And then SMS and Call handling...

kind regards
	holger





From bouchtaoui at gmail.com  Thu Jul 23 12:12:24 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Thu, 23 Jul 2009 14:12:24 +0200
Subject: new to OpenBSC
In-Reply-To: <SNT113-W236568971D8286B669BBFDFE180@phx.gbl>
References: <SNT113-W236568971D8286B669BBFDFE180@phx.gbl>
Message-ID: <4A6853A8.50406@gmail.com>

I guess the best thing to do is read bsc_hack.c and follow the path 
which starts in the main() function.
After you've done that, you can ask questions for parts you don't 
understand. But I think it's also important to read some GSM articles to 
follow the source. Cause there are a lot of acronyms used.
Hopefully the more experienced guys have some time to clarify you some.


raza shah schreef:
> Hi everyone,                 I am new to OpenBSC and I think the best way to contribute to it is to get to know the source code first. I would appreciate any help regarding how to begin understanding the source code. And what are the main features of the code? What is the best approach to start learning OpenBSC. And is there any good material on OpenBSC.?
> Thanks.
> _________________________________________________________________
> Share your memories online with anyone you want.
> http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1
>   




From laforge at gnumonks.org  Thu Jul 23 16:55:55 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 23 Jul 2009 18:55:55 +0200
Subject: Some changes to the gsm_transaction data model
Message-ID: <20090723165555.GK7204@prithivi.gnumonks.org>

Hi!

For finishing proper SMS support, I need supoprt for transactions. Similar
to Call Control, SMS can also have a number of different transactions
active of any time.

Before my changes, the transactions were tied to call control, which is
obviously not good if that code is to be reused from SMS.

Also, the transaction was linked to the gsm_network as well as the gsm_lchan.
I think both are somehow wrong.

Why are they not a property of the network?  Because a transaction always
belongs to a 'MM entity' (gsm spec language), or a gsm_subscriber in openbsc
terminology.  That subscriber then is part of a gsm_network.

And why are they not part of a gsm_lchan?  Because a transaction can be
initiated on one lchan and then move to another lchan, e.g. in case a SMS is
sent just before a call is made, where we start on an SDCCH and might continue
on a SACCH.  I will keep the lchan pointer in the meaning of 'current lchan
through which we transmit messages to the remote MM entity'.

Tying the transaction to the subscriber neatly addresses both of those
issues.

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 raza_hamdani at hotmail.com  Mon Jul 27 10:34:19 2009
From: raza_hamdani at hotmail.com (raza shah)
Date: Mon, 27 Jul 2009 16:34:19 +0600
Subject: Just starting!!
Message-ID: <SNT113-W265515CE706B72F60F263DFE140@phx.gbl>


Hi folks,            I hope this finds you all in the best of health. As a start, I have read some basic GSM articles and went through bsc_hack.c.  Few questions are bugging me and I would appreciate some info regarding them:
(1) With which type(s) of BTS does OpenBSC work?
(2) What is OML NM?
(3) What is the best way to follow the path in the code in case of a call?
Thanks.
_________________________________________________________________
Show them the way! Add maps and directions to your party invites. 
http://www.microsoft.com/windows/windowslive/products/events.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090727/78a527b8/attachment.htm>

From bouchtaoui at gmail.com  Mon Jul 27 11:01:50 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Mon, 27 Jul 2009 13:01:50 +0200
Subject: Just starting!!
In-Reply-To: <SNT113-W265515CE706B72F60F263DFE140@phx.gbl>
References: <SNT113-W265515CE706B72F60F263DFE140@phx.gbl>
Message-ID: <4A6D891E.1000605@gmail.com>


> (1) With which type(s) of BTS does OpenBSC work?
>   

Check the in bsc_hack.c : handle_options(), it will finally leads you to 
gsm_bts_type() in gsm_data.c and there you can find the struct 
bts_types. For now it supports nanobts900/1800 and bs11.

> (2) What is OML NM?
>   

OML stands for Organization and Maintenance Layer, it has a broad 
meaning, but in this case it's for configuring the BTS. Actually it's 
more for managing and configuring the network. Maybe other guys can give 
better explenation about OML NM.

> (3) What is the best way to follow the path in the code in case of a call?
>   

Well, you should know that the whole communication is based on select(). 
All socket connection and traffic is based on select(). When select is 
called, it blocks untill a certain amount of time or an event occurs on 
one of the provided file-descriptors. It than searches in a list 
(Linux-doublylinked-list) which FD caused an event and than the 
appropriate function will be called to handle it further 
(callback-function). In case of a call you might look at rsl layer.




From laforge at gnumonks.org  Mon Jul 27 17:51:18 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 27 Jul 2009 19:51:18 +0200
Subject: Just starting!!
In-Reply-To: <4A6D891E.1000605@gmail.com>
References: <SNT113-W265515CE706B72F60F263DFE140@phx.gbl>
	<4A6D891E.1000605@gmail.com>
Message-ID: <20090727175117.GL22498@prithivi.gnumonks.org>

On Mon, Jul 27, 2009 at 01:01:50PM +0200, Nordin wrote:
> >(2) What is OML NM?
> 
> OML stands for Organization and Maintenance Layer, it has a broad
> meaning, but in this case it's for configuring the BTS. Actually
> it's more for managing and configuring the network. Maybe other guys
> can give better explenation about OML NM.

NM == Network Management.  In OpenBSC  you can safely assume OML == NM.
 

-- 
- 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  Tue Jul 28 18:40:20 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 28 Jul 2009 20:40:20 +0200
Subject: ip.access RTP setup details
Message-ID: <20090728184020.GQ1434@prithivi.gnumonks.org>

Hi!

While writing the RTP proxy, I've been playing with the ip.access RTP related
code for quite a bit.  This is as far as I have understood it so far:

Setting up a voice call (for one MS)
 * sending IPACCESS_BIND via RSL, specifying
  * the GSM channel number IE
  * the IP speech mode IE, indicating
   * 0x1- : uni-directional, rx-only
   * 0x-1 : EFR (0: FR, 2: AMR)
 * receiving IPACCESS_BIND_ACK via RSL, specifying
  * the GSM channel number IE
  * the ip.access connection identifier
  * the locally-bound UDP port for RTP
  * the locally-bound IP address for RTP
  * optionally: the RTP payload type 
 * sending IPACCESS_CONNECT via RSL, specifying
  * the GSM channel number IE
  * the ip.access connection identifier (from BIND_ACK)
  * the remote UDP port number for RTP
  * the remote IP address for RTP
  * the IP speech mode IE, indicating
   * 0x0-: bi-directional
   * 0x-1: EFR (0: FR, 2: AMR)
  * optionally: the RTP payload type, if BIND_CAK specified it

Misc observations:
* if BIND is called with IP speech mode IE 0x10 (uni-directional FR), then no
  RTP payload type is returned in BIND_ACK.  Instead, the standard type for GSM
  06.10 (0x03) is used in the packets.
* I'm not sure which RTP payload type (and IP speech mode) is which, i.e. if
  the payload type of BIND/BIND_ACK specifies "expect this payload type for
  incoming packets" or "use this payload type for all RTP packets originated by
  this 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 dakota.courtois at labsone.net  Wed Jul 29 03:28:18 2009
From: dakota.courtois at labsone.net (Dakota C)
Date: Tue, 28 Jul 2009 23:28:18 -0400
Subject: UMA a possibility in the future?
Message-ID: <58990b1d0907282028mcfa9315q3909b3f1560e2850@mail.gmail.com>

Hi, I'm a long time lurker into this project and I've wondered something for
a bit of time.Knowing that we can use an ip.access nanoBTS to work on
OpenBSC, why not adapt OpenBSC for UMA (unlicensed mobile access)
standards?
I know over here in the US we currently use UMA with T-Mobile over WiFi to
communicate back to the T-Mobile servers and eventually off to the GSM and
regular ol' networks.

http://www.umatechnology.org/specifications/index.htm is the UMA
specification, and to my knowledge T-Mobile US's @Home service uses the
1.0.3 protocol revision.

To me it seems like it'd be trivial to make a derived copy of OpenBSC with
UMA support up and running, but I'd like some other thoughts into this
matter. I'm not a programmer by any means here, so if this is impossible,
well, then so be it.

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

From laforge at gnumonks.org  Fri Jul 31 20:58:46 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 31 Jul 2009 22:58:46 +0200
Subject: UMA a possibility in the future?
In-Reply-To: <58990b1d0907282028mcfa9315q3909b3f1560e2850@mail.gmail.com>
References: <58990b1d0907282028mcfa9315q3909b3f1560e2850@mail.gmail.com>
Message-ID: <20090731205846.GF4216@prithivi.gnumonks.org>

Hi Dakota.

> Hi, I'm a long time lurker into this project and I've wondered something for
> a bit of time.Knowing that we can use an ip.access nanoBTS to work on
> OpenBSC, why not adapt OpenBSC for UMA (unlicensed mobile access)
> standards?

That could very well be an option.  I have not looked into UMA as I only
know it as a buzzword.

> To me it seems like it'd be trivial to make a derived copy of OpenBSC with
> UMA support up and running, but I'd like some other thoughts into this
> matter. I'm not a programmer by any means here, so if this is impossible,
> well, then so be it.

Please don't take this the wrong way, but: In Open Source projects, features
typically get added because somebody has a need and actually implements
them :)

For myself, I don't have such a need and I think there are many much more
important GSM feature that OpenBSC needs, i.e. stable SMS support, independent
media gateway process, GPRS support, intra/inter-BSC handover, BSC/MSC
functional split, A-interface, A3/A5/A8 support, ...  so it's not like we're
going to run out of ideas what we could do anytime soon.

Also, for most people involved with OpenBSC, it is one of many projects they are
involved in - so the amount of time we can and want to spend on it is limited.  

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 bouchtaoui at gmail.com  Wed Jul 29 09:51:59 2009
From: bouchtaoui at gmail.com (Nordin)
Date: Wed, 29 Jul 2009 11:51:59 +0200
Subject: TDMA frame, Time slot and speech data transfer confusion.
Message-ID: <4A701BBF.60702@gmail.com>

Hi guys,

I read Goller's documentation "About the GSM-Dm-Channels", but I'm a bit 
confused about something.
I understand that one TDMA frame has a period of 4.615 ms and consists 
of 8 Time slots, each of a period of 576.9 us. When a MS registers to 
the BTS, it gets one Time-slot, but how is speech transfered? Normally 
the Fs (samplefrequency) is 8 KHz, this means every 128 us one byte 
sample. If I have one timeslot of let's say 577 us , than there is a gap 
of 7 other timeslots, which makes a 4 ms gap. Also the speech data is 
compressed. How is that damn speech data multiplexed with other MSs and 
finally received on the other side as 8 bit samplevalue at a rate of 128 
us (8 KHz).

It gets fuzzy to me, cause I wrote a microcontroller project which, 
among other things, samples audio and than transfered to a GSM module. 
This is done at 8 KHz samplerate, so how is that done when I have only 
one TimeSlot of 577 us every 4 ms period?
I can't find a good link about how several MSs on one ARFCN can send and 
receive speech data.

Thank you.



From jsemail at gmx.de  Wed Jul 29 11:00:03 2009
From: jsemail at gmx.de (Johannes Schmitz)
Date: Wed, 29 Jul 2009 13:00:03 +0200
Subject: TDMA frame, Time slot and speech data transfer confusion.
In-Reply-To: <4A701BBF.60702@gmail.com>
References: <4A701BBF.60702@gmail.com>
Message-ID: <1248865203.6171.24.camel@chilli>

> I understand that one TDMA frame has a period of 4.615 ms and consists 
> of 8 Time slots, each of a period of 576.9 us. When a MS registers to 
> the BTS, it gets one Time-slot, but how is speech transfered? Normally 
> the Fs (samplefrequency) is 8 KHz, this means every 128 us one byte 
> sample. If I have one timeslot of let's say 577 us , than there is a gap 
> of 7 other timeslots, which makes a 4 ms gap. Also the speech data is 
> compressed. How is that damn speech data multiplexed with other MSs and 
> finally received on the other side as 8 bit samplevalue at a rate of 128 
> us (8 KHz).

I am not sure if this is what you want to know but I suggest you have to
take a look at GSM fullrate and halfrate speech codecs. I am currently
doing the speech processing lecture in here in Aachen so you might have
a look at the following books: "Digital Speech Transmisson" by Peter
Vary and Rainer Martin and "Wireless Communications Second Edition" by
Theodore S. Rappaport. Or you read it from the standard...
You will find that speech is not transmitted by sending just the 8kHz
samples. There is a complex prediction filter structure. In principle
the filter coefficients and the error are send and the receiver does a
reconstruction of the signal.
Additionally everything is quantized heavily to achieve the low
datarates.
If you use fullrate, every 8th timeslot is given to you, if you use
halfrate you get every 16th timeslot. You also need to now about
multiplexing of the logical GSM channels. Sometimes a timeslot is used
to send signaling or control information instead of speech data. The
Speechcodec is able to hide this missing data so you will not notice
that while talking.

regards, Johannes




From spaar at mirider.augusta.de  Wed Jul 29 13:07:25 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Wed, 29 Jul 2009 13:07:25 CEST
Subject: TDMA frame, Time slot and speech data transfer confusion.
Message-ID: <4a70498e.mirider@mirider.augusta.de>

Hello Nordin,

On Wed, 29 Jul 2009 11:51:59 +0200, "Nordin" <bouchtaoui at gmail.com> wrote:
>
> I can't find a good link about how several MSs on one ARFCN can send and 
> receive speech data.

Have a look at the following, the first is a general introduction with
good references to the GSM specification, the second is about speech
coding:

 http://en.wikipedia.org/wiki/Um_Interface

 http://www.gsmfordummies.com/encoding/encoding.shtml

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



From laforge at gnumonks.org  Wed Jul 29 10:33:59 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 29 Jul 2009 12:33:59 +0200
Subject: ip.access RTP capture using Version 1 (FR) codec
Message-ID: <20090729103359.GI1434@prithivi.gnumonks.org>

Hi!

Using git version 58ca5b7ae70365c1285b2ea0cb3c3370a8f108a9 of openbsc,
plus the patch from the attachment, I was able to do a V1 (FR) call,
not only EFR.

The FR pcap file is attached to this mail. I'll also put it to the nanoBTS wiki
page, like the EFR capture before.  I hope this helps you to decode the voice
samples.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openbsc-mncc-fr.patch
Type: text/x-diff
Size: 858 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090729/07839d1d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipaccess-startup-mo_to_mo_call-proxy-FR.pcap
Type: application/cap
Size: 103358 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090729/07839d1d/attachment-0001.bin>

From spaar at mirider.augusta.de  Wed Jul 29 14:03:10 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Wed, 29 Jul 2009 14:03:10 CEST
Subject: ip.access RTP capture using Version 1 (FR) codec
Message-ID: <4a70569e.mirider@mirider.augusta.de>

Hello Harald,

On Wed, 29 Jul 2009 12:33:59 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> 
> The FR pcap file is attached to this mail. I'll also put it to the nanoBTS wiki
> page, like the EFR capture before.  I hope this helps you to decode the voice
> samples.

Decoding with Toast would work fine but there is the same problem, lots
of missing packets. If I look at the capture timestamps, there seem to
miss about 0.8 seconds of data at regular intervals (the first disruption
is at packet number 681, the next at 710, 742, ...). These are also the
positions where the Wireshark RTP analysis complains about wrong sequence
numbers.

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



From laforge at gnumonks.org  Wed Jul 29 12:43:12 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 29 Jul 2009 14:43:12 +0200
Subject: ip.access RTP capture using Version 1 (FR) codec
In-Reply-To: <4a70569e.mirider@mirider.augusta.de>
References: <4a70569e.mirider@mirider.augusta.de>
Message-ID: <20090729124312.GM1434@prithivi.gnumonks.org>

Hi Dieter,

On Wed, Jul 29, 2009 at 02:03:10PM +0200, Dieter Spaar wrote:
 
> On Wed, 29 Jul 2009 12:33:59 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> > 
> > The FR pcap file is attached to this mail. I'll also put it to the nanoBTS wiki
> > page, like the EFR capture before.  I hope this helps you to decode the voice
> > samples.
> 
> Decoding with Toast would work fine but there is the same problem, lots
> of missing packets. If I look at the capture timestamps, there seem to
> miss about 0.8 seconds of data at regular intervals (the first disruption
> is at packet number 681, the next at 710, 742, ...). These are also the
> positions where the Wireshark RTP analysis complains about wrong sequence
> numbers.

That's really weird.  I almost think there must be something wrong on my
machine while capturing those packets.  At least while making the call I did
not notice strange interruptions - but I may have missed that.

If you're interested, you can certainly try for yourself with your nanoBTS...

In any case, openbsc seems to be able to deal quite fine with FR and EFR calls
in TCH/F timeslots now.

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 spaar at mirider.augusta.de  Wed Jul 29 15:15:47 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Wed, 29 Jul 2009 15:15:47 CEST
Subject: ip.access RTP capture using Version 1 (FR) codec
Message-ID: <4a7067a3.mirider@mirider.augusta.de>

Hello Harald,

On Wed, 29 Jul 2009 14:43:12 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> 
> If you're interested, you can certainly try for yourself with your nanoBTS...
> 

You are joking, right ? How should it work on my Windows machine if it
does not work on Linux ;-) ?

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



From laforge at gnumonks.org  Wed Jul 29 13:48:32 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 29 Jul 2009 15:48:32 +0200
Subject: ip.access RTP capture using Version 1 (FR) codec
In-Reply-To: <4a7067a3.mirider@mirider.augusta.de>
References: <4a7067a3.mirider@mirider.augusta.de>
Message-ID: <20090729134832.GO1434@prithivi.gnumonks.org>

On Wed, Jul 29, 2009 at 03:15:47PM +0200, Dieter Spaar wrote:
 
> On Wed, 29 Jul 2009 14:43:12 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> > 
> > If you're interested, you can certainly try for yourself with your nanoBTS...
> 
> You are joking, right ? How should it work on my Windows machine if it
> does not work on Linux ;-) ?

I'm telling you, OpenBSC's RTP proxy works fine.   I've just made another call
and there are no drop-outs of .8 seconds or anything like that.

As all it uses is the sockets API, i.e. the very same calls that the
input/ipaccess.c module already uses, I think it should be very easy to make it
build using the posix compatibility of cygwin.

Somehow the pcap is missing packets, but I think that's an
independent/different problem.

-- 
- 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 Jul 29 13:53:41 2009
From: zecke at selfish.org (Holger Freyther)
Date: Wed, 29 Jul 2009 15:53:41 +0200
Subject: ip.access RTP capture using Version 1 (FR) codec
In-Reply-To: <20090729134832.GO1434@prithivi.gnumonks.org>
References: <4a7067a3.mirider@mirider.augusta.de>
	<20090729134832.GO1434@prithivi.gnumonks.org>
Message-ID: <200907291553.41418.zecke@selfish.org>

On Wednesday 29 July 2009 15:48:32 Harald Welte wrote:
> On Wed, Jul 29, 2009 at 03:15:47PM +0200, Dieter Spaar wrote:
> > On Wed, 29 Jul 2009 14:43:12 +0200, "Harald Welte" <laforge at gnumonks.org> 
wrote:
> > > If you're interested, you can certainly try for yourself with your
> > > nanoBTS...
> >
> > You are joking, right ? How should it work on my Windows machine if it
> > does not work on Linux ;-) ?
>
> I'm telling you, OpenBSC's RTP proxy works fine.   I've just made another
> call and there are no drop-outs of .8 seconds or anything like that.
>
> As all it uses is the sockets API, i.e. the very same calls that the
> input/ipaccess.c module already uses, I think it should be very easy to
> make it build using the posix compatibility of cygwin.
>
> Somehow the pcap is missing packets, but I think that's an
> independent/different problem.

And it is unlikely that the BTS is doing both, sending out packets and routing 
on the BTS? What happens if you skip packets on RTP proxy? does it start 
skipping? okay, another stupid question :}

	z.



From spaar at mirider.augusta.de  Wed Jul 29 16:06:12 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Wed, 29 Jul 2009 16:06:12 CEST
Subject: ip.access RTP capture using Version 1 (FR) codec
Message-ID: <4a707374.mirider@mirider.augusta.de>

Hello Harald,

On Wed, 29 Jul 2009 15:48:32 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> 
> I'm telling you, OpenBSC's RTP proxy works fine.   I've just made another call
> and there are no drop-outs of .8 seconds or anything like that.

I am sure that the proxy is working, I never doubt that. I guess for some
reason Wireshark is just missing the data. I was joking about Windows
versus Linux performance, but maybe this was not clear enough.

> As all it uses is the sockets API, i.e. the very same calls that the
> input/ipaccess.c module already uses, I think it should be very easy to make it
> build using the posix compatibility of cygwin.

I tried it in the meantime. No problem at all. The git version works
as expected and Wireshark does not miss any packets here, each call
is about 30 seconds. I tried it with EFR and FR, Wireshark can
save the RTP payload, for EFR I had to convert the data first so
that they fit to the GSM 06.35 reference implementation (they use
a strange format which stores every bit into two bytes). For FR,
Toast can convert the payload immediately. Tested on Windows XP
and cygwin, Wireshark and bsc_hack running on the same machine.

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



From laforge at gnumonks.org  Wed Jul 29 14:55:23 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 29 Jul 2009 16:55:23 +0200
Subject: ip.access RTP capture using Version 1 (FR) codec
In-Reply-To: <4a707374.mirider@mirider.augusta.de>
References: <4a707374.mirider@mirider.augusta.de>
Message-ID: <20090729145523.GQ1434@prithivi.gnumonks.org>

Hi Dieter,

On Wed, Jul 29, 2009 at 04:06:12PM +0200, Dieter Spaar wrote:

> I am sure that the proxy is working, I never doubt that. I guess for some
> reason Wireshark is just missing the data. I was joking about Windows
> versus Linux performance, but maybe this was not clear enough.

Ah, now I understand ;)

> > As all it uses is the sockets API, i.e. the very same calls that the
> > input/ipaccess.c module already uses, I think it should be very easy to make it
> > build using the posix compatibility of cygwin.
> 
> I tried it in the meantime. No problem at all. The git version works
> as expected and Wireshark does not miss any packets here, each call
> is about 30 seconds. 

Great!  can you please provide one FR and one EFR pcap file for Andreas
Eversberg?   It's probably best to replace the two corrupted files that I've
attached to the nanoBTS wiki-page.  You do have a wiki account, I assume.

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  Wed Jul 29 17:38:40 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Wed, 29 Jul 2009 17:38:40 CEST
Subject: ip.access RTP capture using Version 1 (FR) codec
Message-ID: <4a708920.mirider@mirider.augusta.de>

Hello Harald,

On Wed, 29 Jul 2009 16:55:23 +0200, "Harald Welte" <laforge at gnumonks.org> wrote:
> 
> Great!  can you please provide one FR and one EFR pcap file for Andreas
> Eversberg?   It's probably best to replace the two corrupted files that I've
> attached to the nanoBTS wiki-page.

I am not sure if my two FR and EFR cpatures are good examples for the
Wiki, the call is from one person only (me) counting numbers and saying
"Hello Test" or similar things and you hear the voice on both channels
because the two phones are close to each other. Of course they are
good enough as an example for implementing the RTP media feature. So
let me know if I shall provide them to Andreas only (Andreas, shall
I send them to you as email, they are about 240 KByte as ZIP file ?).

> You do have a wiki account, I assume.

I don't think so, at least I have not yet requested an account.

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



From laforge at gnumonks.org  Wed Jul 29 14:50:06 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 29 Jul 2009 16:50:06 +0200
Subject: OpenBSC should now have full support for BS-11 with two TRX
Message-ID: <20090729145006.GP1434@prithivi.gnumonks.org>

Hi!

Please note:
===========================
commit d46299da00f923b24043aa37fa2bae17ffcc1ff7

    make channel allocator policy multi-TRX aware
    
    For now, we assume that TRX1 (and higher) all have a TCH/F configuration
    on all of their timeslots

commit 67b4c30a9de972d199830bba5535e934bd47ac0f

    complete TRX1 support for BS11
    
    * remove old HAVE_TRX1 definition, replace it with '-1' commandline argument
    * make sure we actually configure the OML TRX attributes with a different
      ARFCN than TRX0
    * make sure we configure timeslot 0 of TRX1 also in TCH/F mode
    
    This code is untested, but if you have a dual-trx BS-11, and the second TRX
    is activated, you should be able to run bsc_hack with the -1 option to enable
    and use the second trx.  It works like this:
    * TRX1 shares E1 timeslot 0 for signalling
    * TRX1 RSL link uses TEI2 (TRX0 uses 1)
    * TRX1 on ARFCN+2, i.e. if you have TRX0 on 122, TRX1 will be 124
===========================

I'm very happy if somebody wans to test this.  First of all, it is important
to see if there are any error messages during OML and RSL brigup, and if
the TEI2 link is actually established from mISDN.

If you want to actually use the second TRX, you will either have to make sure
all TCH/H on TRX0 are used (establish sufficient simultaneous calls), or
hack chan_alloc.c to give a preference to TRX1, or to do round-robin or
whatever :)

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 spaar at mirider.augusta.de  Wed Jul 29 19:43:29 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Wed, 29 Jul 2009 19:43:29 CEST
Subject: How to attack mobile networks with an iPhone (according to Apple)
Message-ID: <4a70a662.mirider@mirider.augusta.de>

Hello,

not sure if you already noticed this statement from Apple:

  http://www.wired.com/threatlevel/2009/07/jailbreak/

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



From dburgess at jcis.net  Wed Jul 29 18:02:15 2009
From: dburgess at jcis.net (David A. Burgess)
Date: Wed, 29 Jul 2009 11:02:15 -0700
Subject: How to attack mobile networks with an iPhone (according to Apple)
In-Reply-To: <4a70a662.mirider@mirider.augusta.de>
References: <4a70a662.mirider@mirider.augusta.de>
Message-ID: <AFB2510D-7F3D-4738-9BBB-D8E43DE311F7@jcis.net>


So you can jailbreak an iPhone and get direct access to L3 to run a  
DOS?  That would be very interesting if it were true, but I suspect  
it's just horseshit put in there to deceive the court, which isn't  
hard to do in technology cases.


On Jul 29, 2009, at 10:43 AM, Dieter Spaar wrote:

> Hello,
>
> not sure if you already noticed this statement from Apple:
>
>   http://www.wired.com/threatlevel/2009/07/jailbreak/
>
> Best regards,
>   Dieter
> -- 
> Dieter Spaar, Germany                            
> spaar at mirider.augusta.de


David A. Burgess
Kestrel Signal Processing, Inc.







From charles at thewybles.com  Wed Jul 29 18:10:50 2009
From: charles at thewybles.com (Charles Wyble)
Date: Wed, 29 Jul 2009 11:10:50 -0700
Subject: How to attack mobile networks with an iPhone (according to Apple)
In-Reply-To: <AFB2510D-7F3D-4738-9BBB-D8E43DE311F7@jcis.net>
References: <4a70a662.mirider@mirider.augusta.de>
	<AFB2510D-7F3D-4738-9BBB-D8E43DE311F7@jcis.net>
Message-ID: <4A7090AA.8090703@thewybles.com>

Oh of course it is.

Anyone serious about hacking the GSM network , with any skills wouldn't 
use an iPhone (which is tied back to a credit card/name/address) You 
would use a USRP, or at the very least a G1 dev version.

Full and complete control over all aspects of the traffic.

*rolls eyes*

Apple is lame. They make good products (i'm typing this on a MacBook Pro 
and have an ipod touch 2nd gen next to me). However they have some 
clueless people out there.



David A. Burgess wrote:
> 
> So you can jailbreak an iPhone and get direct access to L3 to run a 
> DOS?  That would be very interesting if it were true, but I suspect it's 
> just horseshit put in there to deceive the court, which isn't hard to do 
> in technology cases.
> 
> 
> On Jul 29, 2009, at 10:43 AM, Dieter Spaar wrote:
> 
>> Hello,
>>
>> not sure if you already noticed this statement from Apple:
>>
>>   http://www.wired.com/threatlevel/2009/07/jailbreak/
>>
>> Best regards,
>>   Dieter
>> -- 
>> Dieter Spaar, Germany                           spaar at mirider.augusta.de
> 
> 
> David A. Burgess
> Kestrel Signal Processing, Inc.
> 
> 
> 
> 
> 



From spaar at mirider.augusta.de  Wed Jul 29 20:25:52 2009
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Wed, 29 Jul 2009 20:25:52 CEST
Subject: How to attack mobile networks with an iPhone (according to Apple)
Message-ID: <4a70b050.mirider@mirider.augusta.de>

Hello David,

On Wed, 29 Jul 2009 11:02:15 -0700, "David A. Burgess" <dburgess at jcis.net> wrote:
> 
> So you can jailbreak an iPhone and get direct access to L3 to run a  
> DOS?  That would be very interesting if it were true, but I suspect  
> it's just horseshit put in there to deceive the court, which isn't  
> hard to do in technology cases.

I don't think its that easy (if it would be, why not modify the TSM30
instead which should be much easier). I just found it very interesting
that Apple uses it as an argument. Of course such arguments are also bad
for opening the phone GSM stack to a larger group of people (if this ever
happens) or developing an open source GSM phone stack which could be
used for anything else than research.

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



From bouchtaoui at gmail.com  Wed Jul 29 19:58:09 2009
From: bouchtaoui at gmail.com (Nordin Bouchtaoui)
Date: Wed, 29 Jul 2009 21:58:09 +0200
Subject: How to attack mobile networks with an iPhone (according to Apple)
In-Reply-To: <4a70b050.mirider@mirider.augusta.de>
References: <4a70b050.mirider@mirider.augusta.de>
Message-ID: <8aedb85a0907291258w2aeca077t40d62cd50977205e@mail.gmail.com>

I don't trust this, I think this a way to control the mass. If "hackers"
could hack the towers, than the regulators come with a new law to get more
control of people in sake of "national security".

Make people afraid and you can control them...
But that's my opinion.


2009/7/29 Dieter Spaar <spaar at mirider.augusta.de>

> Hello David,
>
> On Wed, 29 Jul 2009 11:02:15 -0700, "David A. Burgess" <dburgess at jcis.net>
> wrote:
> >
> > So you can jailbreak an iPhone and get direct access to L3 to run a
> > DOS?  That would be very interesting if it were true, but I suspect
> > it's just horseshit put in there to deceive the court, which isn't
> > hard to do in technology cases.
>
> I don't think its that easy (if it would be, why not modify the TSM30
> instead which should be much easier). I just found it very interesting
> that Apple uses it as an argument. Of course such arguments are also bad
> for opening the phone GSM stack to a larger group of people (if this ever
> happens) or developing an open source GSM phone stack which could be
> used for anything else than research.
>
> Best regards,
>  Dieter
> --
> Dieter Spaar, Germany                           spaar at mirider.augusta.de
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090729/67a0f542/attachment.htm>

From laforge at gnumonks.org  Thu Jul 30 21:16:38 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 30 Jul 2009 23:16:38 +0200
Subject: How to attack mobile networks with an iPhone (according to Apple)
In-Reply-To: <8aedb85a0907291258w2aeca077t40d62cd50977205e@mail.gmail.com>
References: <4a70b050.mirider@mirider.augusta.de>
	<8aedb85a0907291258w2aeca077t40d62cd50977205e@mail.gmail.com>
Message-ID: <20090730211638.GK24787@prithivi.gnumonks.org>

On Wed, Jul 29, 2009 at 09:58:09PM +0200, Nordin Bouchtaoui wrote:
> I don't trust this, I think this a way to control the mass. If "hackers"
> could hack the towers, than the regulators come with a new law to get more
> control of people in sake of "national security".

yes, this is very likely.  This is why it is very important how we communicate
our work and its result to the public.   I actually wnat to build an
operational GSM network and an operational GSM mobile phone from open source
components.  We can show that our work is constructive, that we actually
have useful results.  Doing nothing else but implementing open specifications
in open source software.  And among other things, this can be used for security
research and to make more engineers familiar with practical aspects of GSM
protocols.

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 jsemail at gmx.de  Thu Jul 30 21:47:33 2009
From: jsemail at gmx.de (Johannes Schmitz)
Date: Thu, 30 Jul 2009 23:47:33 +0200
Subject: How to attack mobile networks with an iPhone (according to Apple)
In-Reply-To: <20090730211638.GK24787@prithivi.gnumonks.org>
References: <4a70b050.mirider@mirider.augusta.de>
	<8aedb85a0907291258w2aeca077t40d62cd50977205e@mail.gmail.com>
	<20090730211638.GK24787@prithivi.gnumonks.org>
Message-ID: <1248990453.20067.18.camel@chilli>

Am Donnerstag, den 30.07.2009, 23:16 +0200 schrieb Harald Welte:
> yes, this is very likely.  This is why it is very important how we communicate
> our work and its result to the public.   I actually wnat to build an
> operational GSM network and an operational GSM mobile phone from open source
> components.  We can show that our work is constructive, that we actually
> have useful results.  Doing nothing else but implementing open specifications
> in open source software.  And among other things, this can be used for security
> research and to make more engineers familiar with practical aspects of GSM
> protocols.

But as a matter of fact the GSM standard itself has security
vulnerabilities. So are we gonna demonstrate this? For example do you
plan to show that false Basestation attacks are possible within a 1000
Euro cost range or something like that?
I think we must be careful with such things and everybody should be
aware of the fact that openbsc could be abused for criminal purpose. 
I see this project as a chance to sensitize the general public of GSM
security problems and send a message towards industry.

Johannes




From laforge at gnumonks.org  Fri Jul 31 04:38:57 2009
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 31 Jul 2009 06:38:57 +0200
Subject: GSM [in]security Apple)
In-Reply-To: <1248990453.20067.18.camel@chilli>
References: <4a70b050.mirider@mirider.augusta.de>
	<8aedb85a0907291258w2aeca077t40d62cd50977205e@mail.gmail.com>
	<20090730211638.GK24787@prithivi.gnumonks.org>
	<1248990453.20067.18.camel@chilli>
Message-ID: <20090731043857.GS24787@prithivi.gnumonks.org>

Hi Johannes,

On Thu, Jul 30, 2009 at 11:47:33PM +0200, Johannes Schmitz wrote:
> Am Donnerstag, den 30.07.2009, 23:16 +0200 schrieb Harald Welte:
> > yes, this is very likely.  This is why it is very important how we communicate
> > our work and its result to the public.   I actually wnat to build an
> > operational GSM network and an operational GSM mobile phone from open source
> > components.  We can show that our work is constructive, that we actually
> > have useful results.  Doing nothing else but implementing open specifications
> > in open source software.  And among other things, this can be used for security
> > research and to make more engineers familiar with practical aspects of GSM
> > protocols.
> 
> But as a matter of fact the GSM standard itself has security
> vulnerabilities. So are we gonna demonstrate this? For example do you
> plan to show that false Basestation attacks are possible within a 1000
> Euro cost range or something like that?

Of course.  We have already shown that e.g. at 25C3 last year.  Interestingly
no press coverage at all, not even heise.de.  I guess they were all busy writing
about the DECT related security issues.

> I think we must be careful with such things and everybody should be
> aware of the fact that openbsc could be abused for criminal purpose. 

of course.  But is it our fault that the GSM spec was written with almost
no security in mind?  Is it our fault that the industry didn'd do anything
to fix those problems for 20 years, despite the problems being very obvious?

The argument 'xyz can be used for criminal purpose' is true for about anything.
You can use a hammer to drive nails into walls, but you can also kill somebody.

You can use a TCP/IP stack to browse the web and send mail, or you can use it
to attack other computers over the network.

You can thus also use a GSM protocol stack for the very same features.

The internet also had things like telnet for remote logins, befor security
evolved and ssh was created.  And even today, most e-mail is transferred
unauthenticated and unencrypted.  People are more aware of it than the
problems in the GSM world.

Real criminals like organized crime have always had the budget to fund the
development of technology that they used for fraud.  We're creating more
awareness in the general technology community (and in the end the public)
about problems that already exist for decades, without any of our doing.

Plus: You can already buy a BTS + GSM network simulator for a five-digit
USD sum, even without OpenBSC.  It's commercial off-the-shelf equipment,
after all.

> I see this project as a chance to sensitize the general public of GSM
> security problems and send a message towards industry.

that's what I've always had in mind with most of the security projects that
I've been [even remotely] involved, e.g. OpenPCD and OpenPICC as tools for
practical RFID security analysis, deDECTed.org, ...

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)