From laforge at gnumonks.org  Tue Apr  3 16:03:48 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 3 Apr 2012 18:03:48 +0200
Subject: April 11, 7pm / Re: Regular Osmocom meeting in Berlin?
In-Reply-To: <20120330100042.GP27922@prithivi.gnumonks.org>
References: <20120329152016.GN19456@prithivi.gnumonks.org>
	<20120330074236.GA4863@nybble.binarybase.org>
	<20120330100042.GP27922@prithivi.gnumonks.org>
Message-ID: <20120403160348.GA11263@prithivi.gnumonks.org>

To quote myself...

On Fri, Mar 30, 2012 at 12:00:42PM +0200, Harald Welte wrote:
> > I would probably be in favor of Wednesday
> 
> Great, then we have already three people in favor of Wednesday (which
> would also work out fine for me).

I've now inquired with CCC Berlin, people there seem to be fine with a
bi-weekly meeting on wednesday.  I told them that one CCCB member would
be present at every meeting.  This would likely be me (unless I'm
travelling) so we have to see that somebody else (dexter, prom, roh,
zecke, ...) can fulfill that role during other meetings.

The first meeting thus will be next wednesday, April 11.  I suggest we
meet at 7pm.  A more official announcement will follow.

-- 
- 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 ajlennon at dynamicdevices.co.uk  Wed Apr  4 10:49:36 2012
From: ajlennon at dynamicdevices.co.uk (Alex J Lennon)
Date: Wed, 04 Apr 2012 11:49:36 +0100
Subject: Buying a nanoBTS
In-Reply-To: <BF1C18A5-8C8F-4B98-A419-652A21079B04@googlemail.com>
References: <BF1C18A5-8C8F-4B98-A419-652A21079B04@googlemail.com>
Message-ID: <4F7C2740.6050407@dynamicdevices.co.uk>

Hi Patrick,

They come up on eBay now and again. You might want to keep an eye on there.

I paid around ?150. I'm not sure if that's good or bad...

Best Regards,

Alex

On 04/04/2012 10:22, Patrick Klapper wrote:
> Hello,
>
> I am interested in buying a nanoBTS.
> The sales department of ip.access told me, that they only sell their products to mobile operators.
>
> Where can I buy an ip.access nanoBTS (GSM1800) and what's its price?
>
> Regards
>
> Patrick




From refikthesis at googlemail.com  Wed Apr  4 14:40:36 2012
From: refikthesis at googlemail.com (Refik Hadzialic)
Date: Wed, 4 Apr 2012 16:40:36 +0200
Subject: Question regarding timeouts and RRLP
Message-ID: <CALTLFGneq04TgAMUonHM+bLqv2C1u=3Vn0a1jFFOeg7QPoaFSA@mail.gmail.com>

Dear group members,

(I would like to apologize if you got this message for the second
time, but last time I sent it to the wrong mail address and I am not
sure if the gnumonks mailing list is synchronized with this one,
osmocom, I am sorry if you get this mail for the second time!)

I would like to ask you a question regarding the timeouts and
initiating/allocating an SDCCH channel for a subscriber inside of the
GSM network. I am trying to modify some parts of OpenBSC
(/openbsc/src/libmsc/rrlp.c) and to implement the MS-based RRLP in
OpenBSC (to send assistance data in form of almanac, ephemeris, BTS
geolocation data and GPS reference time to the MS).

At the moment I use the silent sms to start an RRLP request (send RRLP
request + assistance data and then send the silent sms). But if it
takes too long to send the assistance data OpenBSC starts from the
beginning (send rrlp request + assistance data + sms again). I think
this is because OpenBSC waits for an ack from the MS for the silent
sms (which has not been sent) and therefore it's a timeout issue. As a
quick hack I have modified parts of the code and got the RRLP to work
(sent successfully these data and I got a position from the MS).

Just for the curious one, I commented out three lines just before the
return, in /openbsc/src/libmsc/gsm_04_11.c in the function,
gsm411_rx_rp_ack, the following lines:

//else
//gsm411_release_conn(trans->conn);

/* free the transaction here */
//trans_free(trans);


and I changed one timer value from 10 to 100, in
/openbsc/src/libbsc/bsc_rll.c in the function, rll_establish to:

osmo_timer_schedule(&rllr->timer, 100, 0);.


As I know what I did was wrong (since changing the timers and not
releasing the channel properly influences the whole system) but I just
did it for the purpose of testing and to see do I send correct data
and does the RRLP work at all.

I hope you can give me some hints and guides how to allocate a channel
for around 130 seconds and to send the RRLP assistance data within
that channel without doing the above tricks. Once everything works
properly I will provide the RRLP code.

Best regards,
Refik Hadzialic



From alexander.huemer at xx.vu  Wed Apr  4 16:26:33 2012
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Wed, 4 Apr 2012 18:26:33 +0200
Subject: Question regarding timeouts and RRLP
In-Reply-To: <CALTLFGneq04TgAMUonHM+bLqv2C1u=3Vn0a1jFFOeg7QPoaFSA@mail.gmail.com>
References: <CALTLFGneq04TgAMUonHM+bLqv2C1u=3Vn0a1jFFOeg7QPoaFSA@mail.gmail.com>
Message-ID: <20120404162633.GA32577@de.xx.vu>

Hi Refik,

On Wed, Apr 04, 2012 at 04:40:36PM +0200, Refik Hadzialic wrote:
> (I would like to apologize if you got this message for the second
> time, but last time I sent it to the wrong mail address and I am not
> sure if the gnumonks mailing list is synchronized with this one,
> osmocom, I am sorry if you get this mail for the second time!)

That's very easy to check.
http://lists.osmocom.org/pipermail/openbsc/2012-March/003727.html

Kind regards,
-Alexander Huemer



From holger at freyther.de  Wed Apr  4 16:38:19 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed, 04 Apr 2012 18:38:19 +0200
Subject: Question regarding timeouts and RRLP
In-Reply-To: <CALTLFGneq04TgAMUonHM+bLqv2C1u=3Vn0a1jFFOeg7QPoaFSA@mail.gmail.com>
References: <CALTLFGneq04TgAMUonHM+bLqv2C1u=3Vn0a1jFFOeg7QPoaFSA@mail.gmail.com>
Message-ID: <4F7C78FB.103@freyther.de>

On 04/04/2012 04:40 PM, Refik Hadzialic wrote:
> Dear group members,

Hi Refik,

osmo-nitb (libmsc/) keeps a channel open by "reference" counting. This
counting is implemented by the 'transaction' or 'operations'. See
gsm_subscriber_connection for 'operation' pointers.

So what roughly happens is:
1.) A channel is opened, a dummy operation is created to not immediately close
the channel
2.) Whoever feels responsible creates an operation/transaction..
3.) When a transaction is done msc_release_connection is called..
4.) when all transactions and operations are completed the channel will be
released.

You would probably want to add a new operation



From refikthesis at googlemail.com  Sun Apr  8 12:53:19 2012
From: refikthesis at googlemail.com (Refik Hadzialic)
Date: Sun, 8 Apr 2012 14:53:19 +0200
Subject: Question regarding timeouts and RRLP
In-Reply-To: <4F7C78FB.103@freyther.de>
References: <CALTLFGneq04TgAMUonHM+bLqv2C1u=3Vn0a1jFFOeg7QPoaFSA@mail.gmail.com>
	<4F7C78FB.103@freyther.de>
Message-ID: <CALTLFGmx272d4SqKsfK9b2ex=eU_GuP7QP6ioths3wPdviXNBA@mail.gmail.com>

Hi Alexander & Holger,

thank you for the link, I will bookmark it, and sorry for the same message.

Thank you for the help Holger, I will look at it this week, I might
have then a few more questions.

Best regards,
Refik

On Wed, Apr 4, 2012 at 6:38 PM, Holger Hans Peter Freyther
<holger at freyther.de> wrote:
> On 04/04/2012 04:40 PM, Refik Hadzialic wrote:
>> Dear group members,
>
> Hi Refik,
>
> osmo-nitb (libmsc/) keeps a channel open by "reference" counting. This
> counting is implemented by the 'transaction' or 'operations'. See
> gsm_subscriber_connection for 'operation' pointers.
>
> So what roughly happens is:
> 1.) A channel is opened, a dummy operation is created to not immediately close
> the channel
> 2.) Whoever feels responsible creates an operation/transaction..
> 3.) When a transaction is done msc_release_connection is called..
> 4.) when all transactions and operations are completed the channel will be
> released.
>
> You would probably want to add a new operation
>



From holger at freyther.de  Sun Apr  8 14:19:17 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 08 Apr 2012 16:19:17 +0200
Subject: Question regarding timeouts and RRLP
In-Reply-To: <CALTLFGmx272d4SqKsfK9b2ex=eU_GuP7QP6ioths3wPdviXNBA@mail.gmail.com>
References: <CALTLFGneq04TgAMUonHM+bLqv2C1u=3Vn0a1jFFOeg7QPoaFSA@mail.gmail.com>
	<4F7C78FB.103@freyther.de>
	<CALTLFGmx272d4SqKsfK9b2ex=eU_GuP7QP6ioths3wPdviXNBA@mail.gmail.com>
Message-ID: <4F819E65.8090706@freyther.de>

On 04/08/2012 02:53 PM, Refik Hadzialic wrote:
> Hi Alexander & Holger,
> 
> thank you for the link, I will bookmark it, and sorry for the same message.
> 
> Thank you for the help Holger, I will look at it this week, I might
> have then a few more questions.

Hi,

technical questions are more than welcome. Feel encouraged to update the wiki
or submit a patch for the doc/*.txt files.

holger




From refikthesis at googlemail.com  Mon Apr 23 16:26:51 2012
From: refikthesis at googlemail.com (Refik Hadzialic)
Date: Mon, 23 Apr 2012 18:26:51 +0200
Subject: Question regarding timeouts and RRLP
In-Reply-To: <4F819E65.8090706@freyther.de>
References: <CALTLFGneq04TgAMUonHM+bLqv2C1u=3Vn0a1jFFOeg7QPoaFSA@mail.gmail.com>
	<4F7C78FB.103@freyther.de>
	<CALTLFGmx272d4SqKsfK9b2ex=eU_GuP7QP6ioths3wPdviXNBA@mail.gmail.com>
	<4F819E65.8090706@freyther.de>
Message-ID: <CALTLFGmE8vAFf2A+LO-DN2znKCxODUbgTTo+bUmyd3bAExH80g@mail.gmail.com>

Hi Holger,

I did what you suggested (at least I think I did), I recreated the
silent call with different variable names in gsm_subscriber_connection
and I added the release checks in msc_release_connection in
libmsc/osmo_msc.c for the RRLP transaction, thank you for guiding me!
However, I have one more question regarding the connection, it gets
always disconnected after some time.

When I create the connection e.q. by typing in the terminal
"subscriber id 1 silent-call start sdcch", and my request is being
sent out (RRLP request) in the function:

static int paging_cb_silent in libmsc/silent_call.c in "case
GSM_PAGING_SUCCEEDED:", between the following two lines:

"osmo_signal_dispatch(SS_SCALL, S_SCALL_SUCCESS, &sigdata);" and
"break;" (between these two lines I send the request out).

If the cell phone has the GPS coordinates cached, it returns them
back, if not it tries to get a fix, but no matter in which of the two
states it is, it disconnects me after 30 seconds after executing the
above command in the telnet window.

I get the following output after 22-23 seconds:
<0000> abis_rsl.c:1517 (bts=0,trx=0,ts=0,ss=0) SAPI=0 RELEASE INDICATION
<0004> abis_rsl.c:1478 rsl_handle_release

and then a few seconds later (around 5-8 seconds):
<0004> abis_rsl.c:891 (bts=0,trx=0,ts=0,ss=0) CONNECTION FAIL:
RELEASING CAUSE=0x01(Radio Link Failure)
<0004> abis_rsl.c:621 (bts=0,trx=0,ts=0,ss=0) RF Channel Release CMD due error 1
<0004> abis_rsl.c:658 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK
<0000> chan_alloc.c:303 Freeing lchan with state RELEASE DUE ERROR -
setting to NONE

and it doesn't enter the function: void msc_release_connection in
libmsc/osmo_msc.c since I output a comment in the log file when it is
in there!

Do you have an idea, what I might be doing wrong? I get the same
behavior even if I comment out the RRLP request sending (so just
normal silent call).

Once I finish and get it to work, I will make a wiki page so it can
help other users.

Best regards,
Refik Hadzialic


On Sun, Apr 8, 2012 at 4:19 PM, Holger Hans Peter Freyther
<holger at freyther.de> wrote:
> On 04/08/2012 02:53 PM, Refik Hadzialic wrote:
>> Hi Alexander & Holger,
>>
>> thank you for the link, I will bookmark it, and sorry for the same message.
>>
>> Thank you for the help Holger, I will look at it this week, I might
>> have then a few more questions.
>
> Hi,
>
> technical questions are more than welcome. Feel encouraged to update the wiki
> or submit a patch for the doc/*.txt files.
>
> holger
>
>



From laforge at gnumonks.org  Mon Apr  9 13:16:37 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 9 Apr 2012 15:16:37 +0200
Subject: Sagem OT-290 trace phone / GSMTAP integration
Message-ID: <20120409131637.GE7895@prithivi.gnumonks.org>

Hi all!

Thanks to a generous donor, we have received a couple of OT-290 trace
phones.  These are commercial products intended for taking L2/L3 air
interface traces.  If you've read any of the fabulous GSM papers by
Prof. Dr.-Ing. Joachim Goeller:  The OT-phones is what he used to
generate all his traces.

The majority of what those phones can do is now also possible with
OsmocomBB.

However, OT-290 support GPRS tracing/testing - for CS-1 throguh CS-4.

I would be willing to give away one of the two remaining OT-290 (for
free) to anyone who would in return commit to developing a GSMTAP
interface for it.

The message format on the serial UART between phone and PC is documented
(PDF documentation by Sagem included with the phones).  So based on this
documentation and an OT-290 phone, it should be possible to write a
small command-line program that receives the GSM/GPRS messages from the
OT-290 and sends them via GSMTAP into wireshark.

The result would then be similar to what
http://cgit.osmocom.org/cgit/dct3-gsmtap/ is for DCT-3 phones.

If you're interested, please respond to this message.  Please don't
apply for the phone if you are not able to find the required time and
interest for actually doing the GSMTAP integration.

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 tophut at gmail.com  Sat Apr 21 17:28:53 2012
From: tophut at gmail.com (John)
Date: Sat, 21 Apr 2012 12:28:53 -0500
Subject: Issue with GPRS for nanoBTS: no SGSN IP sent to nanoBTS ...
Message-ID: <CAAUcBR=LEWUHff1WOrusuHqi6uTtnf1k5i_1eKEsE_keCw1vfQ@mail.gmail.com>

Hi,

I have an ipaccess nanobts model 165AU.  I have followed the instructions
for GPRS on the OpenBSC with a fresh install of Ubuntu 11.10:

http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS

By adding the IMSIs for two GPRS capable handsets to the database and
assigning extensions, the phones will attach and I can make calls between
the handsets.

However, there seems to be no functionality related to GPRS.  A couple of
of different iPhones in GPRS field test mode won't pick up GPRS-related
parameters in "filed test mode", such as they won't see different values I
try for T3192 timer or DRC Timer Max. Note that I see changes I try for
these parameters (T3192 and DRC Timer Max) sent to the nanobts from the
wireshark packet captures.  These same iPhones can make phone calls through
the nanoBTS/OpenBSC.

Probably, the most significant underlying issue is that I don't see the
SGSN IP address ever sent to the nanoBTS anywhere in the Wireshark packet
capture.  It's clearly set in my configuration line "gprs nsvc 0 remote ip
192.168.XXX.YYY", and again I'm using an exact copy of the instructions
linked above.  So, GPRS clearly won't work without the nanoBTS "knowing"
the SGSN.  I do see the link between SGSN and GGSN, and the SGSN/GGSN
both "up", but no traffic of course between the nanoBTS and SGSN.

Note that I also did some searching and I saw one posting where the
configuration line "gprs mode gprs" should be "gprs mode egprs", but that
didn't make any difference.  Does anyone have suggestions of what might be
wrong or what I should look at?

Thanks, John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120421/d6e5206f/attachment.htm>

From laforge at gnumonks.org  Mon Apr 23 19:22:07 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 23 Apr 2012 21:22:07 +0200
Subject: Issue with GPRS for nanoBTS: no SGSN IP sent to nanoBTS ...
In-Reply-To: <CAAUcBR=LEWUHff1WOrusuHqi6uTtnf1k5i_1eKEsE_keCw1vfQ@mail.gmail.com>
References: <CAAUcBR=LEWUHff1WOrusuHqi6uTtnf1k5i_1eKEsE_keCw1vfQ@mail.gmail.com>
Message-ID: <20120423192206.GK4592@prithivi.gnumonks.org>

Hi John,

On Sat, Apr 21, 2012 at 12:28:53PM -0500, John wrote:
> Note that I also did some searching and I saw one posting where the
> configuration line "gprs mode gprs" should be "gprs mode egprs", but that
> didn't make any difference.  Does anyone have suggestions of what might be
> wrong or what I should look at?

I would be helpful if you could make available a pcap file of the
communication between BTS and OpenBSC from the point where the OML tcp
connection is established up to the point whre you see the RSL link
coming up.

-- 
- 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 tophut at gmail.com  Tue Apr 24 02:49:15 2012
From: tophut at gmail.com (John)
Date: Mon, 23 Apr 2012 21:49:15 -0500
Subject: Issue with GPRS for nanoBTS: no SGSN IP sent to nanoBTS ...
In-Reply-To: <20120423192206.GK4592@prithivi.gnumonks.org>
References: <CAAUcBR=LEWUHff1WOrusuHqi6uTtnf1k5i_1eKEsE_keCw1vfQ@mail.gmail.com>
	<20120423192206.GK4592@prithivi.gnumonks.org>
Message-ID: <CAAUcBRkpO7604ZQkmPdNo1huVwZWdj27pmsuWgVxDmCrDA=HWw@mail.gmail.com>

Hi,

OK, the SGSN is running and listening/communicating on port 23000 as
specified in the config files.  I was confused because (1) I couldn't find
the IP address passed to the BTS on the Wireshark packet captures (maybe
the IP is sent as binary or not regular text), and (2), it now seems clear
the iPhone 3GS won't transmit/support GPRS even though it shows some GPRS
data in the GPRS field test modes.  Thus, with the iPhone 3GS, there was no
BTS->SGSN traffic to view (even though it has a GPRS test mode).

We are now testing with a GPRS capable phone, the LG GR500.  We can see
some initial GPRS data, but nothing more than the following.  The messages
represent what is shown upon power up of the phone, and no following GPRS
messages are sent by the phone when trying to access IP:

Here is BTS/SGSN startup:

<0011> gprs_ns.c:169 NSVCI=65534 Creating NS-VC

<0011> gprs_ns.c:169 NSVCI=65535 Creating NS-VC

<0011> gprs_ns.c:804 Creating NS-VC for BSS at 192.168.253.10:23000

<0011> gprs_ns.c:677 NSEI=65535 Rx NS RESET (NSVCI=0, cause=O&M
intervention)

<0011> gprs_ns.c:536 NSEI=101 Tx NS RESET ACK (NSVCI=101)

<0011> gprs_ns.c:863 NSEI=101 Rx NS UNBLOCK

<0012> gprs_bssgp.c:247 BSSGP BVCI=0 Rx RESET cause=Transmission capacity
modified

<0012> gprs_bssgp.c:247 BSSGP BVCI=2 Rx RESET cause=O&M intervention

<0012> gprs_bssgp.c:270 Cell 1-1-1-0 CI 0 on BVCI 2

<0012> gprs_bssgp.c:323 BSSGP BVCI=2 Rx BVC-UNBLOCK

<0012> gprs_bssgp.c:463 BSSGP BVCI=2 Rx Flow Control BVC


Here is the phone powering up:

<0012> gprs_bssgp.c:347 BSSGP TLLI=0x78fd6033 Rx UPLINK-UNITDATA

<0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x35b15fCMD=UI DATA

<0013> gprs_llc.c:742 LLC RX: unknown TLLI 0x78fd6033, creating LLME on the
fly

2nd try:

<0012> gprs_bssgp.c:347 BSSGP TLLI=0x7d3b6971 Rx UPLINK-UNITDATA

<0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x35b15fCMD=UI DATA

<0013> gprs_llc.c:742 LLC RX: unknown TLLI 0x7d3b6971, creating LLME on the
fly

I saw a note on the message board from about a year ago about handling the
unknown TLLI with a patch, but the code for gprs_llc.c has been updated
quite a bit since then.

We will try to look into it more and report back any findings, but any
pointers would be appreciated.

John



On Mon, Apr 23, 2012 at 2:22 PM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi John,
>
> On Sat, Apr 21, 2012 at 12:28:53PM -0500, John wrote:
> > Note that I also did some searching and I saw one posting where the
> > configuration line "gprs mode gprs" should be "gprs mode egprs", but that
> > didn't make any difference.  Does anyone have suggestions of what might
> be
> > wrong or what I should look at?
>
> I would be helpful if you could make available a pcap file of the
> communication between BTS and OpenBSC from the point where the OML tcp
> connection is established up to the point whre you see the RSL link
> coming up.
>
> --
> - 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/20120423/21fc6920/attachment.htm>

From peter at stuge.se  Tue Apr 24 03:13:25 2012
From: peter at stuge.se (Peter Stuge)
Date: Tue, 24 Apr 2012 05:13:25 +0200
Subject: Issue with GPRS for nanoBTS: no SGSN IP sent to nanoBTS ...
In-Reply-To: <CAAUcBRkpO7604ZQkmPdNo1huVwZWdj27pmsuWgVxDmCrDA=HWw@mail.gmail.com>
References: <CAAUcBR=LEWUHff1WOrusuHqi6uTtnf1k5i_1eKEsE_keCw1vfQ@mail.gmail.com>
	<20120423192206.GK4592@prithivi.gnumonks.org>
	<CAAUcBRkpO7604ZQkmPdNo1huVwZWdj27pmsuWgVxDmCrDA=HWw@mail.gmail.com>
Message-ID: <20120424031325.1750.qmail@stuge.se>

Hi John,

John wrote:
> On Mon, Apr 23, 2012 at 2:22 PM, Harald Welte <laforge at gnumonks.org> wrote:
> 
> > I would be helpful if you could make available a pcap file of the
> > communication between BTS and OpenBSC from the point where the OML
> > tcp connection is established up to the point whre you see the RSL
> > link coming up.
> 
> Here is BTS/SGSN startup:
> 
> <0011> gprs_ns.c:169 NSVCI=65534 Creating NS-VC

Please send the pcap file as requested. It includes significant
detail which is not shown in console messages. You can use tcpdump
to create the file from the command line, or even wireshark.


//Peter



From cr3 at cr3.us  Tue Apr 24 14:54:22 2012
From: cr3 at cr3.us (Chris Rankine)
Date: Tue, 24 Apr 2012 10:54:22 -0400
Subject: Issue with GPRS for nanoBTS: no SGSN IP sent to nanoBTS ...
In-Reply-To: <20120424031325.1750.qmail@stuge.se>
References: <CAAUcBR=LEWUHff1WOrusuHqi6uTtnf1k5i_1eKEsE_keCw1vfQ@mail.gmail.com>
	<20120423192206.GK4592@prithivi.gnumonks.org>
	<CAAUcBRkpO7604ZQkmPdNo1huVwZWdj27pmsuWgVxDmCrDA=HWw@mail.gmail.com>
	<20120424031325.1750.qmail@stuge.se>
Message-ID: <CAHutDux4xgLJXO3jM0mS_z67_ivhMoCyYjzTxKYLKbYJcBbLEQ@mail.gmail.com>

I have come across a similar problem with a 178U.  Attached is the pcap
file.  .190 is BSC/NITB, .188 is sgsn, .195 is BTS.

Chris Rankine

On Mon, Apr 23, 2012 at 11:13 PM, Peter Stuge <peter at stuge.se> wrote:

> Hi John,
>
> John wrote:
> > On Mon, Apr 23, 2012 at 2:22 PM, Harald Welte <laforge at gnumonks.org>
> wrote:
> >
> > > I would be helpful if you could make available a pcap file of the
> > > communication between BTS and OpenBSC from the point where the OML
> > > tcp connection is established up to the point whre you see the RSL
> > > link coming up.
> >
> > Here is BTS/SGSN startup:
> >
> > <0011> gprs_ns.c:169 NSVCI=65534 Creating NS-VC
>
> Please send the pcap file as requested. It includes significant
> detail which is not shown in console messages. You can use tcpdump
> to create the file from the command line, or even wireshark.
>
>
> //Peter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120424/ad82c51d/attachment.htm>
-------------- next part --------------
root at gsm-2012:/root/openbsc/openbsc/src/osmo-nitb# ./osmo-nitb --debug=DRLL:DCC:DMM:DRR:DRSL:DNM
<0005> bsc_init.c:419
WARNING: You are running an 'accept-all' network on a BTS that is not barred.  This configuration is likely to interfere with production GSM networks and should only be used in a RF shielded environment such as a faraday cage!

DB: Database initialized.
DB: Database prepared.
<0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07)
<0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 37 36 62 31 37 64 30 00
<0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART
<0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Software Activated Report
<0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00
<0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1379 Set BTS Attr (bts=0)
<0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART
<0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) Software Activated Report
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 31 00 13 00 0a 76 32 30 39 62 32 33 64 30 00 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 37 36 62 31 37 64 30 00 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 31 00 13 00 0a 76 32 30 39 62 32 33 64 30 00 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 37 36 62 31 37 64 30 00 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) Sending OPSTART
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) Software Activated Report
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00
<0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) Software Activated Report
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) Software Activated Report
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) Software Activated Report
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) IPACCESS(0xf6): SET ATTR ACK
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) IPACCESS(0xf6): SET ATTR ACK
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:2479 ip.access RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=0)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=1)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=2)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=3)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=4)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=5)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=6)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=7)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) Software Activated Report
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) Software Activated Report
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) Software Activated Report
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) Software Activated Report
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) Software Activated Report
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) Software Activated Report
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) Software Activated Report
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) Software Activated Report
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) IPACCESS(0xf6): SET ATTR ACK
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) ADM=Unlocked
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) Software Activated Report
<0005> abis_nm.c:1396 Set TRX Attr (bts=0,trx=0)
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xe1): RSL CONNECT ACK IP=192.168.21.190 PORT=3003 STREAM=0x00
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) ADM=Unlocked
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Failure Event Report Type=communication failure Severity=failure ceased Probable cause= 03 03 24
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0004> bsc_init.c:281 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 123 using MCC=1 MNC=1 LAC=1 CID=0 BSIC=63 TSC=7
<0003> system_information.c:247 Serving cell: 123
<0003> bsc_init.c:104 SI1: 55 06 19 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e5 04 00 2b
<0003> bsc_init.c:104 SI2: 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00
<0003> bsc_init.c:104 SI3: 49 06 1b 00 00 00 f1 10 00 01 49 03 00 27 4e 00 e5 04 00 3c 2b 2b 2b
<0003> bsc_init.c:104 SI4: 31 06 1c 00 f1 10 00 01 4e 00 e5 04 00 01 2b 2b 2b 2b 2b 2b 2b 2b 2b
<0003> bsc_init.c:104 SI5: 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b
<0003> bsc_init.c:104 SI6: 2d 06 1e 00 00 00 f1 10 00 01 27 ff 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
<0003> bsc_init.c:104 SI13: 01 06 00 90 00 18 67 6f c9 ea 84 10 ab 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
^Csignal 2 received
<0005> bsc_init.c:91 shutting down OML for BTS 0
root at gsm-2012:/root/openbsc/openbsc/src/osmo-nitb# ./osmo-nitb --debug=DRLL:DCC:DMM:DRR:DRSL:DNM
<0005> bsc_init.c:419
WARNING: You are running an 'accept-all' network on a BTS that is not barred.  This configuration is likely to interfere with production GSM networks and should only be used in a RF shielded environment such as a faraday cage!

DB: Database initialized.
DB: Database prepared.
<0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07)
<0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked
<0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00 42 12 00 08 31 32 30 61 30 30 32 00 13 00 0a 76 32 37 36 62 31 37 64 30 00
<0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART
<0005> abis_nm.c:419 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Software Activated Report
<0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00
<0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1379 Set BTS Attr (bts=0)
<0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART
<0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) Software Activated Report
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 31 00 13 00 0a 76 32 30 39 62 32 33 64 30 00 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 37 36 62 31 37 64 30 00 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 31 00 13 00 0a 76 32 30 39 62 32 33 64 30 00 42 12 00 08 31 32 30 61 30 30 31 00 13 00 0a 76 32 37 36 62 31 37 64 30 00 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) Sending OPSTART
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) Software Activated Report
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) SW Activate Request: <0005> abis_nm.c:418 Software Activate Request, ACKing and Activating
<0005> abis_nm.c:439 Found SW config: 42 12 00 08 31 32 30 63 30 30 32 00 13 00 0a 76 32 30 39 62 32 33 64 30 00
<0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) Software Activated Report
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) Software Activated Report
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,01,ff) Software Activated Report
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) IPACCESS(0xf6): SET ATTR ACK
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) IPACCESS(0xf6): SET ATTR ACK
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:2479 ip.access RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=0)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=1)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=2)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=3)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=4)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=5)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=6)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1553 Set Chan Attr (bts=0,trx=0,ts=7)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) Sending OPSTART
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) Software Activated Report
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) Software Activated Report
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) Software Activated Report
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) Software Activated Report
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) Software Activated Report
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) Software Activated Report
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) Software Activated Report
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) Software Activated Report
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) IPACCESS(0xf6): SET ATTR ACK
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) ADM=Unlocked
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) Software Activated Report
<0005> abis_nm.c:1396 Set TRX Attr (bts=0,trx=0)
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:419 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xe1): RSL CONNECT ACK IP=192.168.21.190 PORT=3003 STREAM=0x00
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) ADM=Unlocked
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) ADM=Unlocked
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:419 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Failure Event Report Type=communication failure Severity=failure ceased Probable cause= 03 03 24
<0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:419 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0004> bsc_init.c:281 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 123 using MCC=1 MNC=1 LAC=1 CID=0 BSIC=63 TSC=7
<0003> system_information.c:247 Serving cell: 123
<0003> bsc_init.c:104 SI1: 55 06 19 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e5 04 00 2b
<0003> bsc_init.c:104 SI2: 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00
<0003> bsc_init.c:104 SI3: 49 06 1b 00 00 00 f1 10 00 01 49 03 00 27 4e 00 e5 04 00 3c 2b 2b 2b
<0003> bsc_init.c:104 SI4: 31 06 1c 00 f1 10 00 01 4e 00 e5 04 00 01 2b 2b 2b 2b 2b 2b 2b 2b 2b
<0003> bsc_init.c:104 SI5: 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b
<0003> bsc_init.c:104 SI6: 2d 06 1e 00 00 00 f1 10 00 01 27 ff 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
<0003> bsc_init.c:104 SI13: 01 06 00 90 00 18 67 6f c9 ea 84 10 ab 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tcpdump(1).pcap
Type: application/octet-stream
Size: 29615 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120424/ad82c51d/attachment.obj>

From laforge at gnumonks.org  Mon Apr 23 20:54:51 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 23 Apr 2012 22:54:51 +0200
Subject: April 25, 7pm / Regular Osmocom meeting in Berlin?
Message-ID: <20120423205451.GS4592@prithivi.gnumonks.org>

Hi all!

This is the announcement for the 2nd incarnation of our bi-weekly
Osmocom Berlin meeting.

	April 25, 7pm @ CCC Berlin, Marienstr. 11, 10113 Berlin

The schedule is as follows:

19:00	Introduction into the TETRA base station located @ CCCB 

	For quite some time, there is a full TETRA base station located
	in the Berlin CCC, consisting of two base radios (BR), a site
	controller (TSC), an auto-tuning cavity combiner and other
	equipment.  The talk will introduce the architecture of the
	system and the current status of getting it running.

20:00	Presenting the CC32RS512 / towards an Osmocom Card OS

	The CC32RS512 is a flash-based smart card controller to which
	the documentation is available without NDA.  This means that we
	finally are able to implement a Smart Card OS (COS) as free
	software.

20:30	Informal discussions


If you are interested to show up, feel free to do so.  There is no
registration required.  If the initial part is not interesting to you,
feel free to join us later at 20:30.  The meeting is free as in "free
beer", despite no actual free beer being around ;)

Regards,
	Harald

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



From tophut at gmail.com  Tue Apr 24 19:20:52 2012
From: tophut at gmail.com (John)
Date: Tue, 24 Apr 2012 14:20:52 -0500
Subject: PCAP and CFG Files for NanoBTS with GPRS "unknown TLLI" issue ...
Message-ID: <CAAUcBRkW8YR6MRGQnz7YzSP3-oqiVL==RvMwGcQ-LSPw22a7Sg@mail.gmail.com>

Peter Suge wrote:

>Please send the pcap file as requested. It includes significant
>detail which is not shown in console messages. You can use tcpdump
>to create the file from the command line, or even wireshark.

Here is the pcap:

https://docs.google.com/open?id=0B1aXbMU98OahcWp3cVRRWEJBeHc

The phone cannot communicate any GPRS data after the message in packet
480 (sent upon power up), which is also when the console shows a
message like this below (not actual message from attached pcap):

<0012> gprs_bssgp.c:347 BSSGPTLLI=0x7d3b6971 Rx UPLINK-UNITDATA

<0013> gprs_llc.c:478 LLC SAPI=1C   FCS=0x35b15fCMD=UI DATA

<0013> gprs_llc.c:742 LLC RX:unknown TLLI 0x7d3b6971, creating LLME on the fly

Others on this mailing list asked for the config files.  Here is the
nanobts config, which follows the example on the instructions in the
wiki for GPRS, with the main differences being allowing all devices to
attach and I set the IP addresses.  Also, I put the PDCH in the last
two timeslots.

https://docs.google.com/file/d/0B1aXbMU98OahcGFFWkRIcE54NDQ

Here is the SGSN config:

https://docs.google.com/open?id=0B1aXbMU98OaheVFqdUhYZWkwQzg

There are some strange things in the BCCH configuration in packet #240
of the pcap that don't match configuration files.  For example, I have
set cell reselection hysteresis as shown in the openbsc.cfg to 4, but
the BCCH configuration packet #240 has the value of 2.

Let me know if you see anything, and I appreciate your feedback.

John



From carcellelist at free.fr  Thu Apr 26 06:23:20 2012
From: carcellelist at free.fr (carcelle)
Date: Thu, 26 Apr 2012 08:23:20 +0200
Subject: sgsn/ggsn bitrate tests and reflexions
Message-ID: <20120426062320.GD4918@massoud>

Hi dear osmocom folks,

I have been doing some bitrate throughput tests from different MS (i.e. phones
models) connected to a working osmo-nitb/sgsn/ggsn configuration (with a nanoBTS
DCS1800) and i get 15kbits/s maximum (tcp/udp transfer) with the gprs subnet nat-ed to a 100baseT
lan connected to a 2Mbits/s dsl line

The channel configuration is as follow in the osmo-nitb configuration file : 


<file /etc/osmocom/bsc.conf>
(...)
   nominal power 23
   max_power_red 0
   rsl e1 tei 0
    timeslot 0
     phys_chan_config CCCH+SDCCH4
!     hopping enabled 0
    timeslot 1
     phys_chan_config TCH/F
!     hopping enabled 0
    timeslot 2
     phys_chan_config TCH/F
!     hopping enabled 0
    timeslot 3
     phys_chan_config TCH/F
!     hopping enabled 0
    timeslot 4
     phys_chan_config TCH/F
!     hopping enabled 0
    timeslot 5
     phys_chan_config TCH/F
!     hopping enabled 0
    timeslot 6
     phys_chan_config TCH/F
!     hopping enabled 0
    timeslot 7
     phys_chan_config PDCH

</file>

Should i change the channel configuration to get more bitrate ? 
Should add more cells (bts?) to add more channels ?

my best, cheers.

Xavier.



From laforge at gnumonks.org  Thu Apr 26 06:56:08 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 26 Apr 2012 08:56:08 +0200
Subject: sgsn/ggsn bitrate tests and reflexions
In-Reply-To: <20120426062320.GD4918@massoud>
References: <20120426062320.GD4918@massoud>
Message-ID: <20120426065608.GL14519@prithivi.gnumonks.org>

On Thu, Apr 26, 2012 at 08:23:20AM +0200, carcelle wrote:
> Should i change the channel configuration to get more bitrate ? 

you can increase the bitrate by adding more PDCH on other timeslots.
You will lose those for voice, though.  The nanoBTS is capable of
dynamic TCH/F + PDCH switching, but we don't support that in OpenBSC
yet.

> Should add more cells (bts?) to add more channels ?

More BTSs (stand-alone) is not improving capacity, but you can increase
coverage by putting them at different locations.

If you stack BTSs (multi-TRX), you can e.g. run the firs TRX with 7*PDCH
and run the second TRX with TCH.  This way you have maximum GPRS/EDGE
bitrate, plus full set of voice channels.

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



From carcellelist at free.fr  Thu Apr 26 10:22:16 2012
From: carcellelist at free.fr (carcelle)
Date: Thu, 26 Apr 2012 12:22:16 +0200
Subject: sgsn/ggsn bitrate tests and reflexions
In-Reply-To: <20120426065608.GL14519@prithivi.gnumonks.org>
References: <20120426062320.GD4918@massoud>
	<20120426065608.GL14519@prithivi.gnumonks.org>
Message-ID: <20120426102216.GE4918@massoud>

Hi Harald,

thanks for your reply

On Thu, Apr 26, 2012 at 08:56:08AM +0200, Harald Welte wrote:
> On Thu, Apr 26, 2012 at 08:23:20AM +0200, carcelle wrote:
> > Should i change the channel configuration to get more bitrate ? 
> 
> you can increase the bitrate by adding more PDCH on other timeslots.
> You will lose those for voice, though.  The nanoBTS is capable of
> dynamic TCH/F + PDCH switching, but we don't support that in OpenBSC
> yet.

ok understand, TCH/F + PDCH repartitions based on your
how could i calcultate the theorical layer2/ip troughput available for one PDCH
and correlate it to the troughput measured from the MS to an external IP ?
 
> > Should add more cells (bts?) to add more channels ?
> 
> More BTSs (stand-alone) is not improving capacity, but you can increase
> coverage by putting them at different locations.
> 
> If you stack BTSs (multi-TRX), you can e.g. run the firs TRX with 7*PDCH
> and run the second TRX with TCH.  This way you have maximum GPRS/EDGE
> bitrate, plus full set of voice channels.

Excellent, i will work in this direction and let you know.

My best regards,

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



From laforge at gnumonks.org  Thu Apr 26 11:19:16 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 26 Apr 2012 13:19:16 +0200
Subject: sgsn/ggsn bitrate tests and reflexions
In-Reply-To: <20120426102216.GE4918@massoud>
References: <20120426062320.GD4918@massoud>
	<20120426065608.GL14519@prithivi.gnumonks.org>
	<20120426102216.GE4918@massoud>
Message-ID: <20120426111916.GO14519@prithivi.gnumonks.org>

Hi Xavier,

On Thu, Apr 26, 2012 at 12:22:16PM +0200, carcelle wrote:

> > you can increase the bitrate by adding more PDCH on other timeslots.
> > You will lose those for voice, though.  The nanoBTS is capable of
> > dynamic TCH/F + PDCH switching, but we don't support that in OpenBSC
> > yet.
> 
> ok understand, TCH/F + PDCH repartitions based on your
> how could i calcultate the theorical layer2/ip troughput available for one PDCH
> and correlate it to the troughput measured from the MS to an external IP ?

you can see the raw bitrates for different EDGE coding modes (PDCH
coding scheme will vary depending on RF layer performance):
https://en.wikipedia.org/wiki/Enhanced_Data_Rates_for_GSM_Evolution
so it's 8.8 kbit/second / slot to 59 kbit/second /slot

For pure GPRS it's 8 kbit/second / slot to 20 kbit/second / slot


From laforge at gnumonks.org  Thu Apr 26 17:21:32 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 26 Apr 2012 19:21:32 +0200
Subject: Developer room @ FrOSCon 2012 ?
Message-ID: <20120426172132.GH15595@prithivi.gnumonks.org>

Hi all,

I have received the following invitation from the FrOSCon team.

Please let me know if anyone is already intending to attend the
conference, or would be interested in getting together thre in a
devroom.

I'm personally not so sure since we already had the OsmoDevCon earlier
this year... but then, late August is almost half a year later ;)

------------

Hello OpenBSC Team,

we would like to invite you to take part in the seventh Free and Open
Source Software Conference (FrOSCon 2012).

FrOSCon is a two-day conference on Free Software and Open Source,
which takes place on August 25th/26th, 2012 at the University of
Applied Sciences Bonn-Rhein-Sieg, in St. Augustin near Bonn, Germany.

Main part of the conference is a comprehensive range of talks and
workshops. Furthermore, there is a large exhibition area, where
projects have the opportunity to present themselves and get in touch
with users and other developers. Moreover, we offer a few rooms for
Free Software projects to organize developer meetings or to present
their own program.

We would be pleased if your project would like to contribute to this
year's FrOSCon and thus support the communication and exchange within
the Open Source and Free Software community. Depending on the kind of
your participation, there is different information available to you.

To sign up for a booth, please visit
https://callforexhibitors.froscon.org and register your project.
Please feel free to contact us for any questions at
exhibitors at froscon.org <mailto:exhibitors at froscon.org>. The
registration for booths will be open until May 23rd.

If your project wants to sign up for a developer room, please write a
proposal to projects at froscon.org <mailto:projects at froscon.org>. The
proposal should contain a short summary (1-2 paragraphs) of what you
plan to do and which special requirements you have. Since the demand
for developer rooms usually exceeds the number of rooms we can offer,
we will choose the projects which look the most promising to us based
on the submitted proposals. If you have questions concerning the
developer rooms, feel free to contact projects at froscon.org
<mailto:projects at froscon.org>. The deadline for the submission of
developer room proposals is April 30th.

Additionally our Call for Papers already started, we are looking
forward to your submissions of talks and workshops. You can register
via http://cfp.froscon.org/. For further information concerning the
Call for Papers take a look at
http://www.froscon.de/en/program/call-for-papers/. The Call for Papers
will end on May 23rd, too.

We hope to meet you at FrOSCon in St. Augustin.

Kind regards,
The FrOSCon Team

-----------
-- 
- 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 Apr 26 19:31:42 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 26 Apr 2012 21:31:42 +0200
Subject: LAPDm / RSL EST IND
Message-ID: <20120426193142.GB10786@prithivi.gnumonks.org>

Hi jolly,

I'm seeing some strange behavior on the BTS side LAPDm code:

When we get a SABM on SAPI=3 from the phone, this gets translated into
an RSL_RLL_EST_IND.  However, as there commonly is no l3 payload in a
SAPI=3 SABM, the L3_INFO IE should not be present in that message.

Instead of a RLL_EST_IND without L3_INFO IE, we get a L3_INFO IE that
consists only of 1 byte tag and 2 byte length, but not payload.  The
Length value seems non-deterministic, i.e. like uninitialized memory.

I've tried to resolve this, and I suspect it is somehow related to the
DUMMY msgb that the lapd code allocates (why is it doing that?) in
send_dl_simple().

The code path should be:

lapd_rx_u()
  if (length == 0) send_dl_simple()
    send_rslms_dlsap()
      here we check for (!dp->oph.msg), but since there is a dummy msgb,
      we probably run into the send_rslms_rll_l3() case instead of
      send_rll_simple().

What do you think is the best way to resolve this?

Thanks,
	Harald

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



From andreas at eversberg.eu  Sat Apr 28 18:18:23 2012
From: andreas at eversberg.eu (Andreas Eversberg)
Date: Sat, 28 Apr 2012 20:18:23 +0200
Subject: LAPDm / RSL EST IND
In-Reply-To: <20120426193142.GB10786@prithivi.gnumonks.org>
References: <20120426193142.GB10786@prithivi.gnumonks.org>
Message-ID: <4F9C346F.2040703@eversberg.eu>

Harald Welte wrote:
> if (length == 0) send_dl_simple()
somehow i remember that there was a problem with that, but i am not 
sure. we should check, if it would impact on osmocombb (lapdm+rr) and 
lapd (for abis) of libosmocore.



From andreas at eversberg.eu  Sun Apr 29 07:18:02 2012
From: andreas at eversberg.eu (jolly)
Date: Sun, 29 Apr 2012 09:18:02 +0200
Subject: LAPDm / RSL EST IND
In-Reply-To: <20120426193142.GB10786@prithivi.gnumonks.org>
References: <20120426193142.GB10786@prithivi.gnumonks.org>
Message-ID: <4F9CEB2A.8000201@eversberg.eu>

Harald Welte wrote:
> The code path should be:
>
> lapd_rx_u()
>   if (length == 0) send_dl_simple()
>     send_rslms_dlsap()
>       here we check for (!dp->oph.msg), but since there is a dummy msgb,
>       we probably run into the send_rslms_rll_l3() case instead of
>       send_rll_simple().
>
> What do you think is the best way to resolve this?
>   
hi harald,

i think we should remove the msgb at send_dl_simple(). i looked at the
code that handles received lapd messages:

at osmocombb (gsm48_rr.c) the layer 2 message is received at
gsm48_rcv_rll(). only DL_EST_REQ with SAPI 3 is handled here, but
without msgb, so i see no impact.

at e1_input.c the layer 2 message is received at e1inp_dlsap_up(). there
it is expected that only DL_DATA and DL_UNIT_DATA carries a msgb, so i
see no impact.

but i see a little problem: at e1inp_dlsap_up(): dp->oph.msg gets freed,
even if not set. even if msgb_free() does check for NULL pointers, we
should check there.

at least we should try openbsc and osmocombb/mobile and sysmo-bts to see
if there is any problem. i could check osmocombb and openbsc.

regards,

andreas






From frank at vid.nl  Mon Apr 30 13:32:35 2012
From: frank at vid.nl (VID - Frank Maas)
Date: Mon, 30 Apr 2012 15:32:35 +0200
Subject: [SHOWCASE] OpenBSC used during Queensday (NL)
Message-ID: <CAE_7HfuFo64z03va3Xp7oygg-hsCsEHCkUBSxzc2hRzzTAHzpA@mail.gmail.com>

Goodafternoon,

This is just a quick email to let you know that we are currently (as in:
today) using OpenBSC to offer a GPRS service to some equipment during
Queensday. For those of you that do not know this: Queensday is a Dutch
festivity where the birthday of the Queen is celebrated. It attracts a mass
of people and under that condition no (normal) mobile network will stay
operational. Since we have some equipment running, we decided to try out
creating our own mobile network. For this we installed several ip.access
nanoBTSes and use OpenBSC as central software.

Unfortunately this is not a complete success. Although we tested it and
those tests gave us confidence, we now experience a lot of connection
losses. Several nanoBTS'es bootstrap quite regularly, and almost all
connected devices are unreachable after several minutes (some later than
others). Only restarting OmniBSC quite often seems to bring back some life.
Up until now I have been unable to find out why things are wrong.

While preparing for this use of OpenBSC I came accross some things that
might be worthwhile to share with you. I'll do that in separate messages,
so contents does not get clobbered. Please allow me to thank you all for
the great work you have done in this set of software. I hope some of my
experiences will help you pushing this forward.

Kind regards,
Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120430/0bb1c85b/attachment.htm>

From peter at stuge.se  Mon Apr 30 14:12:01 2012
From: peter at stuge.se (Peter Stuge)
Date: Mon, 30 Apr 2012 16:12:01 +0200
Subject: [SHOWCASE] OpenBSC used during Queensday (NL)
In-Reply-To: <CAE_7HfuFo64z03va3Xp7oygg-hsCsEHCkUBSxzc2hRzzTAHzpA@mail.gmail.com>
References: <CAE_7HfuFo64z03va3Xp7oygg-hsCsEHCkUBSxzc2hRzzTAHzpA@mail.gmail.com>
Message-ID: <20120430141201.25868.qmail@stuge.se>

Hi Frank,

VID - Frank Maas wrote:
> Unfortunately this is not a complete success.

Thanks for testing! You are brave to go live with GPRS! :)


> Several nanoBTS'es bootstrap quite regularly,

I believe this is due to a problem with the nanoBTS itself. If you're
able to (also) put some pressure on ip.access I think that would be
awesome. If they hear from enough customers maybe they will work
harder on a firmware upgrade.


> and almost all connected devices are unreachable after several
> minutes (some later than others). Only restarting OmniBSC quite
> often seems to bring back some life.
> Up until now I have been unable to find out why things are wrong.

It would of course be very valuable to find out what it is that is
actually fixed when you restart OpenBSC. If you still have the
network running for some time maybe you can save pcap files with the
traffic between nanoBTSes and OpenBSC, which could be analyzed post
mortem.

Best would be to have a pcap which starts with OpenBSC being started,
and captures for these several minutes including the OpenBSC re-start
as well as the devices becoming reachable again.

Since the error happens in "only" a few minutes hopefully this
capture does not have to get too big to handle.


> While preparing for this use of OpenBSC I came accross some things that
> might be worthwhile to share with you. I'll do that in separate messages,

Thank you very much for your feedback!


//Peter



From laforge at gnumonks.org  Mon Apr 30 14:46:26 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 30 Apr 2012 16:46:26 +0200
Subject: [SHOWCASE] OpenBSC used during Queensday (NL)
In-Reply-To: <CAE_7HfuFo64z03va3Xp7oygg-hsCsEHCkUBSxzc2hRzzTAHzpA@mail.gmail.com>
References: <CAE_7HfuFo64z03va3Xp7oygg-hsCsEHCkUBSxzc2hRzzTAHzpA@mail.gmail.com>
Message-ID: <20120430144626.GB15890@prithivi.gnumonks.org>

Hi Frank,

thanks for your report.

On Mon, Apr 30, 2012 at 03:32:35PM +0200, VID - Frank Maas wrote:
> This is just a quick email to let you know that we are currently (as in:
> today) using OpenBSC to offer a GPRS service to some equipment during
> Queensday. 

GPRS related problems are to be expected.

GPRS with the nanoBTS is unfortunately problematic, especially if you
have lots of devices that are trying to use the network.  We have seen
many installaitons where tha nanoBTSs crash somewhere deep down in their
firmware.

If you look at the OML error reports after they have rebooted (using
wireshark), you will notice that they have something like linked list
corruption in their memory management, or errors related to the TLB.

So whether we (osmo-sgsn) are doing something wrong or not, it should
definitely not corrupt the BTS internal memory managment state :(

Some of our users have tried dozens of different firmware versions, to
no avail.

This is why we have never operated GPRS at our installations at the CCC
Congresses or Camps.

Regards,
	Harald

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



From frank at vid.nl  Mon Apr 30 13:37:47 2012
From: frank at vid.nl (VID - Frank Maas)
Date: Mon, 30 Apr 2012 15:37:47 +0200
Subject: OpenBSC (GPRS) on VMWare/ESXi 4: UDP problem
Message-ID: <CAE_7Hft230cRHWm6jCVfqQW2pHoPjAjxse95miNQZ1piUcE4Qg@mail.gmail.com>

Please be aware of a problem in ESXi in which the checksum of UDP packets
is wrongly calculated. This will cause the UDP traffic from the SGSN to the
BTS'es (vice versa) to fail. It can take quite a while to figure this out
(well... to be honest all it takes is a good look at the extended tcpdump
output, but hey).

If you experience problems setting up GPRS (symptom: NSVC remains ALIVE
BLOCKED), try this command:

ethtool --offload eth0 rx off tx off gso off

(with eth0 the correct interface, or better: for all interfaces).

This works under CentOS (tested) and Debian/Ubuntu (read about it).

HTH/F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120430/192cf3b4/attachment.htm>

From maas.frank at gmail.com  Mon Apr 30 14:26:03 2012
From: maas.frank at gmail.com (Frank Maas)
Date: Mon, 30 Apr 2012 16:26:03 +0200
Subject: gprs_llc.c: foreign TLLI is stored, but not searched
Message-ID: <CAE_7Hftr9hnLzB5E-UfToRBAmat2h+5j0SPbnL8vFiiqFm2NnA@mail.gmail.com>

I might be horribly wrong, but there is something I did not grasp in
gprs_llc.c. So I altered it, but since I am not sure I share it here...

Function 'gprs_llc_tx_ui' uses function 'lle_by_tlli_sapi' to retrieve an
lle based on a tlli/sapi combination. To do the lookup, the supplied tlli
is 'localized' (tlli_foreign2local). If this does not result in a succesful
find, function 'llme_alloc' is used to "create an LLME on the fly". However
'llme_alloc' does not localize the tlli. So every next search for the lle
fails.

For this I created this patch:

--- openbsc/openbsc/src/gprs/gprs_llc.c 2012-04-30 15:42:58.958823325 +0200
+++ ../openbsc/openbsc/openbsc/src/gprs/gprs_llc.c      2012-04-30
10:54:11.291836887 +0200
@@ -157,7 +160,8 @@
  if (!llme)
   return NULL;

- llme->tlli = tlli;
+ llme->tlli = tlli_foreign2local(tlli);
  llme->old_tlli = 0xffffffff;
  llme->state = GPRS_LLMS_UNASSIGNED;



This seems to have solved the problem (unable to get an IP link
operational), but I am not sure if this was the correct way to handle this,
so please feel free to comment.

HTH/F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120430/3afd202a/attachment.htm>

From holger at freyther.de  Mon Apr 30 14:51:16 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Mon, 30 Apr 2012 16:51:16 +0200
Subject: gprs_llc.c: foreign TLLI is stored, but not searched
In-Reply-To: <CAE_7Hftr9hnLzB5E-UfToRBAmat2h+5j0SPbnL8vFiiqFm2NnA@mail.gmail.com>
References: <CAE_7Hftr9hnLzB5E-UfToRBAmat2h+5j0SPbnL8vFiiqFm2NnA@mail.gmail.com>
Message-ID: <4F9EA6E4.3020003@freyther.de>

On 04/30/2012 04:26 PM, Frank Maas wrote:

Hi,

> I might be horribly wrong, but there is something I did not grasp in
> gprs_llc.c. So I altered it, but since I am not sure I share it here...

> - llme->tlli = tlli;
> + llme->tlli = tlli_foreign2local(tlli);
>   llme->old_tlli = 0xffffffff;
>   llme->state = GPRS_LLMS_UNASSIGNED;

I think I once carried a similar patch in one of the branches. The way we
wanted to avoid this issue is that whoever transmits needs to select the
llme/lle. I think my code set old_tlli to the foreign or such but I dropped it
(and can't remember why it wasn't needed anymore).

This will not be the last issue you will experience with GPRS. Both the
nanoBTSs implementation and our SGSN are not very stable. Some of the known
GPRS issues include:

	- http://openbsc.osmocom.org/trac/ticket/55 (crash)
	- http://openbsc.osmocom.org/trac/ticket/44 (correctness)
	- http://openbsc.osmocom.org/trac/ticket/43 (leak)

There is also the 'santos' branch of someone that forked our code and has done
a bit of bugfixing.



From frank at vid.nl  Mon Apr 30 15:05:52 2012
From: frank at vid.nl (VID - Frank Maas)
Date: Mon, 30 Apr 2012 17:05:52 +0200
Subject: gprs_llc.c: foreign TLLI is stored, but not searched
Message-ID: <CAE_7HftQ5hTtEX=BZvXdOk=G=Gjd_zbBJoPLvf9tJaJEkH1F3Q@mail.gmail.com>

Holger wrote:
> wanted to avoid this issue is that whoever transmits needs to select the
> llme/lle. I think my code set old_tlli to the foreign or such but I dropped it
> (and can't remember why it wasn't needed anymore).

Been there, tried that. It wasn't so much that is wasn't needed, but elsewhere
in the code old_tlli (and especially the fact if it is 0xffffffff or
not) is used to (re)set
some stuff.

> This will not be the last issue you will experience with GPRS. Both the
> nanoBTSs implementation and our SGSN are not very stable.

Well... only 7 hours of Qday to go ;-)

> Some of the known GPRS issues include:
>
>	- http://openbsc.osmocom.org/trac/ticket/55 (crash)

I solved that one

>	- http://openbsc.osmocom.org/trac/ticket/44 (correctness)
>	- http://openbsc.osmocom.org/trac/ticket/43 (leak)

Will check these.

> There is also the 'santos' branch of someone that forked our code and has
> done a bit of bugfixing.

Ah ok. I'll look into that. Might be of use during the last couple of hours

HTH/F



From holger at freyther.de  Mon Apr 30 15:12:57 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Mon, 30 Apr 2012 17:12:57 +0200
Subject: gprs_llc.c: foreign TLLI is stored, but not searched
In-Reply-To: <CAE_7HftQ5hTtEX=BZvXdOk=G=Gjd_zbBJoPLvf9tJaJEkH1F3Q@mail.gmail.com>
References: <CAE_7HftQ5hTtEX=BZvXdOk=G=Gjd_zbBJoPLvf9tJaJEkH1F3Q@mail.gmail.com>
Message-ID: <4F9EABF9.9010705@freyther.de>

On 04/30/2012 05:05 PM, VID - Frank Maas wrote:

>> 	- http://openbsc.osmocom.org/trac/ticket/55 (crash)
> 
> I solved that one

how? the patch i carry is having a special return value when the stuff has not
been deleted...



From maas.frank at gmail.com  Mon Apr 30 15:44:58 2012
From: maas.frank at gmail.com (Frank Maas)
Date: Mon, 30 Apr 2012 17:44:58 +0200
Subject: gprs_llc.c: foreign TLLI is stored, but not searched
In-Reply-To: <4F9EABF9.9010705@freyther.de>
References: <CAE_7HftQ5hTtEX=BZvXdOk=G=Gjd_zbBJoPLvf9tJaJEkH1F3Q@mail.gmail.com>
	<4F9EABF9.9010705@freyther.de>
Message-ID: <CAE_7Hfu+8KKwF17L3PB6oDh6y5x=LtyN8PtN34fSfZRGzFeLTg@mail.gmail.com>

On Mon, Apr 30, 2012 at 5:12 PM, Holger Hans Peter Freyther
<holger at freyther.de> wrote:
> On 04/30/2012 05:05 PM, VID - Frank Maas wrote:
>
>>> ? ? ?- http://openbsc.osmocom.org/trac/ticket/55 (crash)
>>
>> I solved that one
>
> how? the patch i carry is having a special return value when the stuff has not
> been deleted...

I addressed it in a separate thread. And I should have said "I hope
that I have solved that one for my specific purpose"...

HTH/F



From holger at freyther.de  Mon Apr 30 15:15:29 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Mon, 30 Apr 2012 17:15:29 +0200
Subject: gprs_llc.c: foreign TLLI is stored, but not searched
In-Reply-To: <CAE_7HftQ5hTtEX=BZvXdOk=G=Gjd_zbBJoPLvf9tJaJEkH1F3Q@mail.gmail.com>
References: <CAE_7HftQ5hTtEX=BZvXdOk=G=Gjd_zbBJoPLvf9tJaJEkH1F3Q@mail.gmail.com>
Message-ID: <4F9EAC91.5030207@freyther.de>

On 04/30/2012 05:05 PM, VID - Frank Maas wrote:

> 
> Well... only 7 hours of Qday to go ;-)
> 

good luck and happy hacking.



From maas.frank at gmail.com  Mon Apr 30 15:37:48 2012
From: maas.frank at gmail.com (Frank Maas)
Date: Mon, 30 Apr 2012 17:37:48 +0200
Subject: Possible solution to ticket #55
Message-ID: <CAE_7HfuP8fBTgN1Joj1149yX+OCFC6ong58mS6_c5j_JeaXgHw@mail.gmail.com>

As reported in ticket #55 SGSN can crash due to double free-ing. You
can replace 'can' by 'will' in that last phrase. I had a sift through
the code and tried to solve this by removing the free in gprs_ns.c.
Whenever the calling function created the msgb-struct, I have made the
function free it after its use. If the function got the msgb from a
calling function, there will not be a free (hoping that will be done
on the higher level).

HTH/F
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ticket55.patch
Type: application/octet-stream
Size: 15346 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120430/46993aaa/attachment.obj>