From mihal.grznar at gmail.com  Thu Jun  5 09:52:44 2014
From: mihal.grznar at gmail.com (=?UTF-8?Q?Michal_Grzn=C3=A1r?=)
Date: Thu, 5 Jun 2014 11:52:44 +0200
Subject: OsmoSGSN [PATCH], Network Service
In-Reply-To: <CA+W2XBungi8EX+uOsm52yNB334hHgJCHYjnTBxZRJvpe0jjfyQ@mail.gmail.com>
References: <CA+W2XBs2zon9z87RujfC7QDapXHcp95SEk1k5xukh7FSFnS91w@mail.gmail.com>
	<20140517115033.GC14533@nataraja>
	<CA+W2XBuGwG3Tg1E4Y9cdGXe2kftyzRJUwrVBiBS0yVEP5PgCOQ@mail.gmail.com>
	<20140523111650.GE21550@xiaoyu.lan>
	<CA+W2XBungi8EX+uOsm52yNB334hHgJCHYjnTBxZRJvpe0jjfyQ@mail.gmail.com>
Message-ID: <CA+W2XBsMNncSkS-23QdL6-NOp=CW6zjej4q7gXJoRX72U3w49g@mail.gmail.com>

So it is the communication between osmoSGSN and sim-bss (Attach procedure).
The problem comes in attach accept/complete. OsmoSGSN sends message attach
accept with currenr TLLI = 0x78000001 and with new allocated P-TMSI =
0x475b916b. Sim-bss answeres with message attach complete with new tlli
made/generated im osmoSGSN from new P-TMSI...and as I said and as 3GPP
24.008 spec. says new TLLI = new allocated P-TMSI = 0x475b916b. And there
comes the problem that it is not LOCAL TLLI. So the point of the problem is
that new P-TMSI/TLLI is not generated correctly and could be said osmoSGSN
rejects what it generated and that is the problem. If it helps, I connects
osmo-SGSN_vty output.

Regards Michal


2014-05-28 14:38 GMT+02:00 Michal Grzn?r <mihal.grznar at gmail.com>:

> Hi, it wasn?t handly written diffs but here I send diff made by using git
> diff. And the problem you can see in packets with number 27-40 (especially
> see in number 30 you see there the old tlli and newly generated P-TMSI in
> message attach accept and in number 31 there is new TLLI which is the same
> as generated P-TMSI in previous message) and that is the problem I needed
> to solve, that the new TLLI was not LOCAL.
>
> regards Michal
>
>
> 2014-05-23 13:16 GMT+02:00 Holger Hans Peter Freyther <holger at freyther.de>
> :
>
> On Fri, May 23, 2014 at 11:44:40AM +0200, Michal Grzn?r wrote:
>>
>> Hi,
>>
>> > And the problem was as I said in Imsi attach procedure new TLLI == new
>> > allocated P-tmsi, and there was a problem that the function
>>  gprs_tmsi2tlli()
>> > function there was not called and so I had to mask the upper bits in
>> > function where the p-tmsi is allocated, there is also a pcap trace where
>> > you can see it.
>>
>> Could you please elaborate of what/were (e.g. packet numbers) we
>> can see "it" and what it should be instead? And please use "git diff"
>> or preferable "git commit" and git format-patch. The "diff" you include
>> is hand-written and sadly not usable because of this.
>>
>> And as written by Harald before. The place you patch is not correct.
>> The method you patch should generate a unique P-TMSI. It might should
>> mask some of the higher bits. But you need to look at the callers of
>> this function if the tlli is not updated.
>>
>> e.g. in src/gprs/gprs_gmm.c you will see something like this:
>>
>>         ctx->p_tmsi = sgsn_alloc_ptmsi();
>> #endif
>>
>>         /* Even if there is no P-TMSI allocated, the MS will switch from
>>          * foreign TLLI to local TLLI */
>>         ctx->tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL);
>>
>>         /* Inform LLC layer about new TLLI but keep old active */
>>         gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new,
>>                           GPRS_ALGO_GEA0, NULL);
>>
>> So this call to gprs_tmsi2tlli will make sure that 0xc0000000 will
>> be set. In fact I see two calls to sgsn_alloc_ptmsi and both of them
>> do the above and assign the new tlli to the context. So please could
>> you try to explain what you are trying to solve?
>>
>> holger
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140605/06b6f946/attachment.htm>
-------------- next part --------------
<0010> gprs_ns.c:1226 Rx NS ALIVE
<0010> gprs_ns.c:479 NSEI=65534 Tx NS ALIVE_ACK (NSVCI=12345)
<0010> gprs_ns.c:505 NSEI=65534 Starting timer in mode tns-test (40 seconds)
<0010> gprs_ns.c:1226 Rx NS ALIVE
<0010> gprs_ns.c:479 NSEI=65534 Tx NS ALIVE_ACK (NSVCI=12345)
<0010> gprs_ns.c:505 NSEI=65534 Starting timer in mode tns-test (40 seconds)
<0011> gprs_bssgp.c:249 BSSGP BVCI=0 Rx RESET cause=Processor overload
<0011> gprs_bssgp.c:249 BSSGP BVCI=2 Rx RESET cause=Processor overload
<0011> gprs_bssgp.c:272 Cell 208-2-11-1 CI 1 on BVCI 2
<0011> gprs_bssgp.c:249 BSSGP BVCI=3 Rx RESET cause=Processor overload
<0011> gprs_bssgp.c:272 Cell 208-2-11-2 CI 2 on BVCI 3
<0011> gprs_bssgp.c:249 BSSGP BVCI=4 Rx RESET cause=Processor overload
<0011> gprs_bssgp.c:272 Cell 208-2-11-3 CI 3 on BVCI 4
<0011> gprs_bssgp.c:249 BSSGP BVCI=5 Rx RESET cause=Processor overload
<0011> gprs_bssgp.c:272 Cell 208-2-11-4 CI 4 on BVCI 5
<0011> gprs_bssgp.c:753 BSSGP BVCI=2 Rx Flow Control BVC
<0011> gprs_bssgp.c:790 BSS instructs us to MS default bucket leak rate != 0, restarting DL GPRS!
<0011> gprs_bssgp.c:753 BSSGP BVCI=3 Rx Flow Control BVC
<0011> gprs_bssgp.c:790 BSS instructs us to MS default bucket leak rate != 0, restarting DL GPRS!
<0011> gprs_bssgp.c:753 BSSGP BVCI=4 Rx Flow Control BVC
<0011> gprs_bssgp.c:790 BSS instructs us to MS default bucket leak rate != 0, restarting DL GPRS!
<0011> gprs_bssgp.c:753 BSSGP BVCI=5 Rx Flow Control BVC
<0011> gprs_bssgp.c:790 BSS instructs us to MS default bucket leak rate != 0, restarting DL GPRS!
<0010> gprs_ns.c:523 NSEI=65534 Timer expired in mode tns-test (40 seconds)
<0010> gprs_ns.c:466 NSEI=65534 Tx NS ALIVE (NSVCI=12345)
<0010> gprs_ns.c:505 NSEI=65534 Starting timer in mode tns-alive (10 seconds)
<0010> gprs_ns.c:505 NSEI=65534 Starting timer in mode tns-test (40 seconds)
<0011> gprs_bssgp.c:376 BSSGP TLLI=0x78000001 Rx UPLINK-UNITDATA
<0012> gprs_llc.c:562 LLC SAPI=1 C   FCS=0xbbe727CMD=UI DATA 
<0012> gprs_llc.c:826 tlli je random!!!
<0012> gprs_llc.c:256 LLC RX: unknown TLLI 0x78000001, creating LLME on the fly
<0002> gprs_gmm.c:640 -> GMM ATTACH REQUEST MI(231010000000000) type="GPRS attach" <0012> gprs_gmm.c:752 gprs_gmm.c: Alokujeme nove p-tmsi!!!!
<0012> gprs_sgsn.c:369 sgsn_alloc_ptmsi: Alokovali sme taketo p-tmsi 0x475b916b 

<0002> gprs_gmm.c:444 <- GPRS IDENTITY REQUEST: mi_type=02
<0011> gprs_bssgp.c:376 BSSGP TLLI=0x78000001 Rx UPLINK-UNITDATA
<0012> gprs_llc.c:562 LLC SAPI=1 C   FCS=0xae6b48CMD=UI DATA 
<0012> gprs_llc.c:826 tlli je random!!!
<0002> gprs_gmm.c:582 -> GMM IDENTITY RESPONSE: mi_type=0x02 MI(123456789012310) 
<0002> gprs_gmm.c:352 <- GPRS ATTACH ACCEPT (new P-TMSI=0x475b916b)
<0011> gprs_bssgp.c:376 BSSGP TLLI=0x475b916b Rx UPLINK-UNITDATA
<0012> gprs_llc.c:562 LLC SAPI=1 C   FCS=0xbcd739CMD=UI DATA 
<0012> gprs_llc.c:832 tlli je reserved!!!
<0012> gprs_llc.c:256 LLC RX: unknown TLLI 0x475b916b, creating LLME on the fly
<0002> gprs_gmm.c:1030 Cannot handle GMM for unknown MM CTX
<0002> gprs_gmm.c:277 <- GPRS MM STATUS (cause: MS identity cannot be derived by the network)
<0011> gprs_bssgp.c:376 BSSGP TLLI=0x475b916b Rx UPLINK-UNITDATA
<0012> gprs_llc.c:562 LLC SAPI=1 R   FCS=0x42e56dCMD=XID DATA 
<0012> gprs_llc.c:832 tlli je reserved!!!
<0002> gprs_gmm.c:1574 Unknown GSM 04.08 discriminator 0x01
<0002> gprs_gmm.c:352 <- GPRS ATTACH ACCEPT (new P-TMSI=0x475b916b)
<0002> gprs_gmm.c:352 <- GPRS ATTACH ACCEPT (new P-TMSI=0x475b916b)
<0010> gprs_ns.c:523 NSEI=65534 Timer expired in mode tns-test (40 seconds)
<0010> gprs_ns.c:466 NSEI=65534 Tx NS ALIVE (NSVCI=12345)
<0010> gprs_ns.c:505 NSEI=65534 Starting timer in mode tns-alive (10 seconds)
<0010> gprs_ns.c:505 NSEI=65534 Starting timer in mode tns-test (40 seconds)
<0002> gprs_gmm.c:352 <- GPRS ATTACH ACCEPT (new P-TMSI=0x475b916b)
<0002> gprs_gmm.c:352 <- GPRS ATTACH ACCEPT (new P-TMSI=0x475b916b)
<0002> gprs_gmm.c:1104 T3350 expired >= 5 times
<0010> gprs_ns.c:523 NSEI=65534 Timer expired in mode tns-test (40 seconds)
<0010> gprs_ns.c:466 NSEI=65534 Tx NS ALIVE (NSVCI=12345)
<0010> gprs_ns.c:505 NSEI=65534 Starting timer in mode tns-alive (10 seconds)
<0010> gprs_ns.c:505 NSEI=65534 Starting timer in mode tns-test (40 seconds)
<0010> gprs_ns.c:523 NSEI=65534 Timer expired in mode tns-test (40 seconds)
<0010> gprs_ns.c:466 NSEI=65534 Tx NS ALIVE (NSVCI=12345)
<0010> gprs_ns.c:505 NSEI=65534 Starting timer in mode tns-alive (10 seconds)
<0010> gprs_ns.c:505 NSEI=65534 Starting timer in mode tns-test (40 seconds)
<0010> gprs_ns.c:523 NSEI=65534 Timer expired in mode tns-test (40 seconds)
<0010> gprs_ns.c:466 NSEI=65534 Tx NS ALIVE (NSVCI=12345)
<0010> gprs_ns.c:505 NSEI=65534 Starting timer in mode tns-alive (10 seconds)
<0010> gprs_ns.c:505 NSEI=65534 Starting timer in mode tns-test (40 seconds)

From holger at freyther.de  Wed Jun  4 15:58:36 2014
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed, 4 Jun 2014 17:58:36 +0200
Subject: [PATCH 1/2] write_queue: Avoid possible use-after-free if fd is
	read-/writable
In-Reply-To: <b3f5691ae4dc33d9481275e3fbcc34aeef06ea34.1400677699.git.daniel@totalueberwachung.de>
References: <b3f5691ae4dc33d9481275e3fbcc34aeef06ea34.1400677699.git.daniel@totalueberwachung.de>
Message-ID: <20140604155836.GA5644@xiaoyu.lan>

On Wed, May 21, 2014 at 03:08:18PM +0200, Daniel Willmann wrote:

>  	return 0;
> +err_badfd:
> +	return rc;

hi, why do you want to change the return value here? Why is the
return 0 not good enough here?



From dwillmann at sysmocom.de  Tue Jun 10 08:03:11 2014
From: dwillmann at sysmocom.de (Daniel Willmann)
Date: Tue, 10 Jun 2014 10:03:11 +0200
Subject: [PATCH 1/2] write_queue: Avoid possible use-after-free if fd is
	read-/writable
In-Reply-To: <20140604155836.GA5644@xiaoyu.lan>
References: <b3f5691ae4dc33d9481275e3fbcc34aeef06ea34.1400677699.git.daniel@totalueberwachung.de>
	<20140604155836.GA5644@xiaoyu.lan>
Message-ID: <20140610080311.GB24020@adrastea.totalueberwachung.de>

On Wed, 2014-06-04 at 17:58, Holger Hans Peter Freyther wrote:
> On Wed, May 21, 2014 at 03:08:18PM +0200, Daniel Willmann wrote:
> 
> >  	return 0;
> > +err_badfd:
> > +	return rc;
> 
> hi, why do you want to change the return value here? Why is the
> return 0 not good enough here?

You're right, it would be. In fact, the return value of this callback is
not checked in osmo_select_main() at all (and there doesn't seem to be
any use for it in that place either). I'll update the patch to return 0
in both cases.


Regards,
Daniel

-- 
- Daniel Willmann <dwillmann at sysmocom.de>       http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte



From daniel at totalueberwachung.de  Tue Jun 10 08:02:24 2014
From: daniel at totalueberwachung.de (Daniel Willmann)
Date: Tue, 10 Jun 2014 10:02:24 +0200
Subject: [PATCH v2 1/1] write_queue: Avoid possible use-after-free if fd is
	read-/writable
In-Reply-To: <b3f5691ae4dc33d9481275e3fbcc34aeef06ea34.1400677699.git.daniel@totalueberwachung.de>
References: <b3f5691ae4dc33d9481275e3fbcc34aeef06ea34.1400677699.git.daniel@totalueberwachung.de>
Message-ID: <aa989a94b42e06a7e2bbf1761a7049b9e3db508e.1402387344.git.daniel@totalueberwachung.de>

From: Daniel Willmann <dwillmann at sysmocom.de>

If the FD is both readable and writable and the read callback closes the
connection (and frees the surrounding structure) we shouldn't call the
write callback (or check anything else in the read fd).

With this patch callback functions can return -EBADFD if they don't want
the FD to be handled any more.
---
 src/write_queue.c | 27 ++++++++++++++++++++++-----
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/src/write_queue.c b/src/write_queue.c
index cef40f8..dcc0469 100644
--- a/src/write_queue.c
+++ b/src/write_queue.c
@@ -21,8 +21,15 @@
  *
  */
 
+#include <errno.h>
 #include <osmocom/core/write_queue.h>
 
+#define HANDLE_BAD_FD(rc, label) \
+	do { \
+		if (rc == -EBADFD) \
+			goto label; \
+	} while (0);
+
 /*! \addtogroup write_queue
  *  @{
  */
@@ -39,14 +46,19 @@
 int osmo_wqueue_bfd_cb(struct osmo_fd *fd, unsigned int what)
 {
 	struct osmo_wqueue *queue;
+	int rc;
 
 	queue = container_of(fd, struct osmo_wqueue, bfd);
 
-	if (what & BSC_FD_READ)
-		queue->read_cb(fd);
+	if (what & BSC_FD_READ) {
+		rc = queue->read_cb(fd);
+		HANDLE_BAD_FD(rc, err_badfd);
+	}
 
-	if (what & BSC_FD_EXCEPT)
-		queue->except_cb(fd);
+	if (what & BSC_FD_EXCEPT) {
+		rc = queue->except_cb(fd);
+		HANDLE_BAD_FD(rc, err_badfd);
+	}
 
 	if (what & BSC_FD_WRITE) {
 		struct msgb *msg;
@@ -58,16 +70,21 @@ int osmo_wqueue_bfd_cb(struct osmo_fd *fd, unsigned int what)
 			--queue->current_length;
 
 			msg = msgb_dequeue(&queue->msg_queue);
-			queue->write_cb(fd, msg);
+			rc = queue->write_cb(fd, msg);
 			msgb_free(msg);
 
+			HANDLE_BAD_FD(rc, err_badfd);
+
 			if (!llist_empty(&queue->msg_queue))
 				fd->when |= BSC_FD_WRITE;
 		}
 	}
 
+err_badfd:
+	/* Return value is not checked in osmo_select_main() */
 	return 0;
 }
+#undef HANDLE_BAD_FD
 
 /*! \brief Initialize a \ref osmo_wqueue structure
  *  \param[in] queue Write queue to operate on
-- 
1.8.4.2




From pablo at gnumonks.org  Tue Jun 10 08:27:52 2014
From: pablo at gnumonks.org (Pablo Neira Ayuso)
Date: Tue, 10 Jun 2014 10:27:52 +0200
Subject: [PATCH v2 1/1] write_queue: Avoid possible use-after-free if fd
	is read-/writable
In-Reply-To: <aa989a94b42e06a7e2bbf1761a7049b9e3db508e.1402387344.git.daniel@totalueberwachung.de>
References: <b3f5691ae4dc33d9481275e3fbcc34aeef06ea34.1400677699.git.daniel@totalueberwachung.de>
	<aa989a94b42e06a7e2bbf1761a7049b9e3db508e.1402387344.git.daniel@totalueberwachung.de>
Message-ID: <20140610082752.GA3558@localhost>

On Tue, Jun 10, 2014 at 10:02:24AM +0200, Daniel Willmann wrote:
> From: Daniel Willmann <dwillmann at sysmocom.de>
> 
> If the FD is both readable and writable and the read callback closes the
> connection (and frees the surrounding structure) we shouldn't call the
> write callback (or check anything else in the read fd).
> 
> With this patch callback functions can return -EBADFD if they don't want
> the FD to be handled any more.
> ---
>  src/write_queue.c | 27 ++++++++++++++++++++++-----
>  1 file changed, 22 insertions(+), 5 deletions(-)
> 
> diff --git a/src/write_queue.c b/src/write_queue.c
> index cef40f8..dcc0469 100644
> --- a/src/write_queue.c
> +++ b/src/write_queue.c
> @@ -21,8 +21,15 @@
>   *
>   */
>  
> +#include <errno.h>
>  #include <osmocom/core/write_queue.h>
>  
> +#define HANDLE_BAD_FD(rc, label) \
> +	do { \
> +		if (rc == -EBADFD) \
> +			goto label; \
> +	} while (0);

Do we really get anything good with this macro? This checking is only
required in three places in this patch.



From holger at freyther.de  Thu Jun 12 10:19:49 2014
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Thu, 12 Jun 2014 12:19:49 +0200
Subject: [PATCH v2 1/1] write_queue: Avoid possible use-after-free if fd
	is read-/writable
In-Reply-To: <20140610082752.GA3558@localhost>
References: <b3f5691ae4dc33d9481275e3fbcc34aeef06ea34.1400677699.git.daniel@totalueberwachung.de>
	<aa989a94b42e06a7e2bbf1761a7049b9e3db508e.1402387344.git.daniel@totalueberwachung.de>
	<20140610082752.GA3558@localhost>
Message-ID: <20140612101949.GA27802@xiaoyu.lan>

On Tue, Jun 10, 2014 at 10:27:52AM +0200, Pablo Neira Ayuso wrote:

> > +#define HANDLE_BAD_FD(rc, label) \
> > +	do { \
> > +		if (rc == -EBADFD) \
> > +			goto label; \
> > +	} while (0);
> 
> Do we really get anything good with this macro? This checking is only
> required in three places in this patch.

What is the argument against having this macro? readability?



From holger at freyther.de  Sun Jun 22 08:59:36 2014
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 22 Jun 2014 10:59:36 +0200
Subject: trau_decode_fr memory corruption. Fix requested
In-Reply-To: <20140528145811.GA6793@xiaoyu.lan>
References: <20140528145811.GA6793@xiaoyu.lan>
Message-ID: <20140622085936.GB19928@xiaoyu.lan>

On Wed, May 28, 2014 at 04:58:11PM +0200, Holger Hans Peter Freyther wrote:
> Dear Andreas, Harald,

Good Morning,

> I don't really know much about the bit order of TRAU frames but
> the trau_test.c is causing an out of bounds access to the gsm_fr_map.

can one of you please provide a fix for this issue.


thanks
	holger




From laforge at gnumonks.org  Mon Jun 23 07:50:48 2014
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 23 Jun 2014 09:50:48 +0200
Subject: trau_decode_fr memory corruption. Fix requested
In-Reply-To: <20140528145811.GA6793@xiaoyu.lan>
References: <20140528145811.GA6793@xiaoyu.lan>
Message-ID: <20140623075048.GC5903@nataraja>

Hi Holger,

On Wed, May 28, 2014 at 04:58:11PM +0200, Holger Hans Peter Freyther wrote:
> I don't really know much about the bit order of TRAU frames but
> the trau_test.c is causing an out of bounds access to the gsm_fr_map.

It is the last iteration of the loop, where i==259 and o==260.  It is
read out-of-bounds but the content is never used.  So yes, it is an
out-of-bounds access, but one that's unlikely to cause any problems
[unless the end of the 'gsm_fr_map' is the edge of the address space]

The only way I can think to avoid it is by putting additional
conditionals in the code, which might have performance implications:

Fixed in git:



From laforge at gnumonks.org  Mon Jun 23 07:48:07 2014
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 23 Jun 2014 09:48:07 +0200
Subject: [PATCH 1/2] trau_mux.c: Prevent out-of-bounds read in
 trau_encode_fr()
Message-ID: <mailman.118.1641744192.42898.openbsc@lists.osmocom.org>

found by -fsanitize=address the last iteration of the loop, where i ==
259 and o == 260.  It is read out-of-bounds but the content is never
used.
---
 openbsc/src/libtrau/trau_mux.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/openbsc/src/libtrau/trau_mux.c b/openbsc/src/libtrau/trau_mux.c
index fd1895f..4f159e4 100644
--- a/openbsc/src/libtrau/trau_mux.c
+++ b/openbsc/src/libtrau/trau_mux.c
@@ -436,6 +436,9 @@ void trau_encode_fr(struct decoded_trau_frame *tf,
 	o = 0; /* offset output bits */
 	while (i < 260) {
 		tf->d_bits[k+o] = (data[j/8] >> (7-(j%8))) & 1;
+		/* to avoid out-of-bounds access in gsm_fr_map[++l] */
+		if (i == 259)
+			break;
 		if (--k < 0) {
 			o += gsm_fr_map[l];
 			k = gsm_fr_map[++l]-1;
-- 
2.0.0

-- 
- 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 jerlbeck at sysmocom.de  Mon Jun  2 08:48:59 2014
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Mon,  2 Jun 2014 10:48:59 +0200
Subject: [PATCH 1/3] gprs/test: Use valid MCC/MNC for BVC RESET
Message-ID: <1401698941-10318-1-git-send-email-jerlbeck@sysmocom.de>

The code currently uses an encoded sequence of (hex) 10 20 30 40 50
60 as RAI, for which no bijective mapping to the set of
representations MCC-MNC-LAC-RAC exists.

This patch changes the hard-coded RAI to 11 22 33 40 50 60 which maps
to 112-332-16464-96 (and vice-versa).

Sponsored-by: On-Waves ehf
---
 openbsc/tests/gbproxy/gbproxy_test.c  |    4 +-
 openbsc/tests/gbproxy/gbproxy_test.ok |  216 ++++++++++++++++-----------------
 2 files changed, 110 insertions(+), 110 deletions(-)

diff --git a/openbsc/tests/gbproxy/gbproxy_test.c b/openbsc/tests/gbproxy/gbproxy_test.c
index d32ac83..ea07a77 100644
--- a/openbsc/tests/gbproxy/gbproxy_test.c
+++ b/openbsc/tests/gbproxy/gbproxy_test.c
@@ -142,8 +142,8 @@ static void send_bssgp_reset(struct gprs_ns_inst *nsi, struct sockaddr_in *src_a
 	 * BSSGP RESET */
 	unsigned char msg[22] = {
 		0x22, 0x04, 0x82, 0x4a,
-		0x2e, 0x07, 0x81, 0x08, 0x08, 0x88, 0x10, 0x20,
-		0x30, 0x40, 0x50, 0x60, 0x10, 0x00
+		0x2e, 0x07, 0x81, 0x08, 0x08, 0x88, 0x11, 0x22,
+		0x33, 0x40, 0x50, 0x60, 0x10, 0x00
 	};
 
 	msg[3] = bvci / 256;
diff --git a/openbsc/tests/gbproxy/gbproxy_test.ok b/openbsc/tests/gbproxy/gbproxy_test.ok
index 0942ca3..e677ec0 100644
--- a/openbsc/tests/gbproxy/gbproxy_test.ok
+++ b/openbsc/tests/gbproxy/gbproxy_test.ok
@@ -82,16 +82,16 @@ result (ALIVE_ACK) = 0
 Setup BSSGP: remote 0x01020304:1111, BVCI 0x1002(4098)
 
 PROCESSING BVC_RESET from 0x01020304:1111
-00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 CALLBACK, event 0, msg length 22, bvci 0x0000
-22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22
-22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 MESSAGE to SGSN at 0x05060708:32000, msg length 26
-00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 result (BVC_RESET) = 26
 
@@ -101,7 +101,7 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
 PROCESSING BVC_RESET_ACK from 0x05060708:32000
 00 00 00 00 23 04 82 10 02 
 
@@ -159,16 +159,16 @@ result (ALIVE_ACK) = 0
 Setup BSSGP: remote 0x01020304:2222, BVCI 0x2002(8194)
 
 PROCESSING BVC_RESET from 0x01020304:2222
-00 00 00 00 22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 CALLBACK, event 0, msg length 22, bvci 0x0000
-22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22
-22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 MESSAGE to SGSN at 0x05060708:32000, msg length 26
-00 00 00 00 22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 result (BVC_RESET) = 26
 
@@ -179,8 +179,8 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
 PROCESSING BVC_RESET_ACK from 0x05060708:32000
 00 00 00 00 23 04 82 20 02 
 
@@ -242,8 +242,8 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
 --- Move BSS 2 to former BSS 1 port ---
 
 Setup NS-VC: remote 0x01020304:1111, NSVCI 0x2001(8193), NSEI 0x2000(8192)
@@ -291,8 +291,8 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
 --- Move BSS 1 to current BSS 2 port ---
 
 Setup NS-VC: remote 0x01020304:1111, NSVCI 0x2001(8193), NSEI 0x2000(8192)
@@ -340,8 +340,8 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
 --- Move BSS 2 to new port ---
 
 Setup NS-VC: remote 0x01020304:4444, NSVCI 0x2001(8193), NSEI 0x2000(8192)
@@ -389,8 +389,8 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
 --- Move BSS 2 to former BSS 1 port ---
 
 Setup NS-VC: remote 0x01020304:3333, NSVCI 0x2001(8193), NSEI 0x2000(8192)
@@ -441,8 +441,8 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
 --- Move BSS 1 to original BSS 1 port ---
 
 Setup NS-VC: remote 0x01020304:1111, NSVCI 0x1001(4097), NSEI 0x1000(4096)
@@ -491,23 +491,23 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
 --- Reset BSS 1 with a new BVCI ---
 
 Setup BSSGP: remote 0x01020304:1111, BVCI 0x1012(4114)
 
 PROCESSING BVC_RESET from 0x01020304:1111
-00 00 00 00 22 04 82 10 12 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 12 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 CALLBACK, event 0, msg length 22, bvci 0x0000
-22 04 82 10 12 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 12 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22
-22 04 82 10 12 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 12 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 MESSAGE to SGSN at 0x05060708:32000, msg length 26
-00 00 00 00 22 04 82 10 12 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 12 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 result (BVC_RESET) = 26
 
@@ -519,9 +519,9 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 4096, BVCI 4114, not blocked, RAC 10-32-16464-96
-  NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 4096, BVCI 4114, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
 PROCESSING BVC_RESET_ACK from 0x05060708:32000
 00 00 00 00 23 04 82 10 12 
 
@@ -541,16 +541,16 @@ result (BVC_RESET_ACK) = 9
 Setup BSSGP: remote 0x01020304:1111, BVCI 0x1002(4098)
 
 PROCESSING BVC_RESET from 0x01020304:1111
-00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 CALLBACK, event 0, msg length 22, bvci 0x0000
-22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22
-22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 MESSAGE to SGSN at 0x05060708:32000, msg length 26
-00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 result (BVC_RESET) = 26
 
@@ -562,9 +562,9 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 4096, BVCI 4114, not blocked, RAC 10-32-16464-96
-  NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 4096, BVCI 4114, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
 PROCESSING BVC_RESET_ACK from 0x05060708:32000
 00 00 00 00 23 04 82 10 02 
 
@@ -584,16 +584,16 @@ result (BVC_RESET_ACK) = 9
 Setup BSSGP: remote 0x01020304:1111, BVCI 0x1002(4098)
 
 PROCESSING BVC_RESET from 0x01020304:1111
-00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 CALLBACK, event 0, msg length 22, bvci 0x0000
-22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22
-22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 MESSAGE to SGSN at 0x05060708:32000, msg length 26
-00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 result (BVC_RESET) = 26
 
@@ -605,9 +605,9 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 4096, BVCI 4114, not blocked, RAC 10-32-16464-96
-  NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 4096, BVCI 4114, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
 PROCESSING BVC_RESET_ACK from 0x05060708:32000
 00 00 00 00 23 04 82 10 02 
 
@@ -723,16 +723,16 @@ result (UNITDATA) = 4
 Setup BSSGP: remote 0x01020304:3333, BVCI 0x1002(4098)
 
 PROCESSING BVC_RESET from 0x01020304:3333
-00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 CALLBACK, event 0, msg length 22, bvci 0x0000
-22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22
-22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 MESSAGE to SGSN at 0x05060708:32000, msg length 26
-00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 result (BVC_RESET) = 26
 
@@ -744,10 +744,10 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 4096, BVCI 4114, not blocked, RAC 10-32-16464-96
-  NSEI 8192, BVCI 8194, not blocked, RAC 10-32-16464-96
+  NSEI 4096, BVCI 4114, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 1
-  NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 1
 Gbproxy global:
 PROCESSING BVC_RESET_ACK from 0x05060708:32000
@@ -904,16 +904,16 @@ Current NS-VCIs:
 Setup BSSGP: remote 0x01020304:1111, BVCI 0x1002(4098)
 
 PROCESSING BVC_RESET from 0x01020304:1111
-00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 CALLBACK, event 0, msg length 22, bvci 0x0000
-22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22
-22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 MESSAGE to SGSN at 0x05060708:32000, msg length 26
-00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 result (BVC_RESET) = 26
 
@@ -932,22 +932,22 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9
 result (BVC_RESET_ACK) = 9
 
 Peers:
-  NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
 --- Setup BVCI 2 ---
 
 Setup BSSGP: remote 0x01020304:1111, BVCI 0x2002(8194)
 
 PROCESSING BVC_RESET from 0x01020304:1111
-00 00 00 00 22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 CALLBACK, event 0, msg length 22, bvci 0x0000
-22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22
-22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 MESSAGE to SGSN at 0x05060708:32000, msg length 26
-00 00 00 00 22 04 82 20 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 20 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 result (BVC_RESET) = 26
 
@@ -966,8 +966,8 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9
 result (BVC_RESET_ACK) = 9
 
 Peers:
-  NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
 --- Send message from BSS 1 to SGSN and back, BVCI 1 ---
 
 PROCESSING UNITDATA from 0x01020304:1111
@@ -1079,16 +1079,16 @@ Current NS-VCIs:
 Setup BSSGP: remote 0x01020304:1111, BVCI 0x1002(4098)
 
 PROCESSING BVC_RESET from 0x01020304:1111
-00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 CALLBACK, event 0, msg length 22, bvci 0x0000
-22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22
-22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 MESSAGE to SGSN at 0x05060708:32000, msg length 26
-00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 result (BVC_RESET) = 26
 
@@ -1107,24 +1107,24 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9
 result (BVC_RESET_ACK) = 9
 
 Peers:
-  NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96
-  NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 1
 --- Setup BVCI 3 ---
 
 Setup BSSGP: remote 0x01020304:1111, BVCI 0x3002(12290)
 
 PROCESSING BVC_RESET from 0x01020304:1111
-00 00 00 00 22 04 82 30 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 30 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 CALLBACK, event 0, msg length 22, bvci 0x0000
-22 04 82 30 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 30 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22
-22 04 82 30 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 30 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 MESSAGE to SGSN at 0x05060708:32000, msg length 26
-00 00 00 00 22 04 82 30 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 30 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 result (BVC_RESET) = 26
 
@@ -1143,9 +1143,9 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9
 result (BVC_RESET_ACK) = 9
 
 Peers:
-  NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96
-  NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 1
 --- Send message from BSS 1 to SGSN and back, BVCI 1 ---
 
@@ -1194,10 +1194,10 @@ MESSAGE to SGSN at 0x05060708:32000, msg length 4
 result (UNITDATA) = 4
 
 Peers:
-  NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 1
-  NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 1
 PROCESSING UNITDATA from 0x05060708:32000
 00 00 20 02 
@@ -1211,11 +1211,11 @@ NS UNITDATA MESSAGE to BSS, BVCI 0x2002, msg length 0
 result (UNITDATA) = -22
 
 Peers:
-  NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 1
     NS Transmission error           : 1
-  NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 1
 --- Send message from BSS 1 to SGSN and back, BVCI 3 ---
 
@@ -1302,16 +1302,16 @@ Current NS-VCIs:
 Setup BSSGP: remote 0x01020304:1111, BVCI 0x1002(4098)
 
 PROCESSING BVC_RESET from 0x01020304:1111
-00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 CALLBACK, event 0, msg length 22, bvci 0x0000
-22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22
-22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 MESSAGE to SGSN at 0x05060708:32000, msg length 26
-00 00 00 00 22 04 82 10 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 10 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 result (BVC_RESET) = 26
 
@@ -1330,27 +1330,27 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9
 result (BVC_RESET_ACK) = 9
 
 Peers:
-  NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 1
     NS Transmission error           : 1
-  NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 1
 --- Setup BVCI 4 ---
 
 Setup BSSGP: remote 0x01020304:1111, BVCI 0x4002(16386)
 
 PROCESSING BVC_RESET from 0x01020304:1111
-00 00 00 00 22 04 82 40 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 40 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 CALLBACK, event 0, msg length 22, bvci 0x0000
-22 04 82 40 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 40 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 22
-22 04 82 40 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+22 04 82 40 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 MESSAGE to SGSN at 0x05060708:32000, msg length 26
-00 00 00 00 22 04 82 40 02 07 81 08 08 88 10 20 30 40 50 60 10 00 00 00 00 00 
+00 00 00 00 22 04 82 40 02 07 81 08 08 88 11 22 33 40 50 60 10 00 00 00 00 00 
 
 result (BVC_RESET) = 26
 
@@ -1369,12 +1369,12 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9
 result (BVC_RESET_ACK) = 9
 
 Peers:
-  NSEI 8192, BVCI 16386, not blocked, RAC 10-32-16464-96
-  NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 16386, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 1
     NS Transmission error           : 1
-  NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 1
 --- Send message from BSS 1 to SGSN and back, BVCI 1 ---
 
@@ -1423,12 +1423,12 @@ MESSAGE to SGSN at 0x05060708:32000, msg length 4
 result (UNITDATA) = 4
 
 Peers:
-  NSEI 8192, BVCI 16386, not blocked, RAC 10-32-16464-96
-  NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 16386, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 2
     NS Transmission error           : 1
-  NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 1
 PROCESSING UNITDATA from 0x05060708:32000
 00 00 20 02 
@@ -1442,12 +1442,12 @@ NS UNITDATA MESSAGE to BSS, BVCI 0x2002, msg length 0
 result (UNITDATA) = -22
 
 Peers:
-  NSEI 8192, BVCI 16386, not blocked, RAC 10-32-16464-96
-  NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 16386, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 2
     NS Transmission error           : 2
-  NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 1
 --- Send message from BSS 1 to SGSN and back, BVCI 3 ---
 
@@ -1511,12 +1511,12 @@ result (UNITDATA) = 4
 
 Gbproxy global:
 Peers:
-  NSEI 8192, BVCI 16386, not blocked, RAC 10-32-16464-96
-  NSEI 8192, BVCI 12290, not blocked, RAC 10-32-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 16386, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 2
     NS Transmission error           : 2
-  NSEI 8192, BVCI 4098, not blocked, RAC 10-32-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
     NSEI mismatch                   : 1
 ===== GbProxy test END
 
-- 
1.7.9.5




From jerlbeck at sysmocom.de  Mon Jun  2 08:49:00 2014
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Mon,  2 Jun 2014 10:49:00 +0200
Subject: [PATCH 2/3] gprs: Use area terms LAI/RAI as defined in GSM 03.03
In-Reply-To: <1401698941-10318-1-git-send-email-jerlbeck@sysmocom.de>
References: <1401698941-10318-1-git-send-email-jerlbeck@sysmocom.de>
Message-ID: <1401698941-10318-2-git-send-email-jerlbeck@sysmocom.de>

Currently the terms 'Routing area code' (RAC) and 'Location area
code' (LAC) are used in several places where 'Routing area
identification' (RAI) or 'Location area identification' (LAI) are
meant in fact.

This patch replaces RAC/LAC by RAI/LAI and 'code' by 'identification'
at these places.

Note that RAI := MCC MNC LAC RAC, and RAC := MCC MNC LAC (see GSM
03.03, sections 4.1 and 4.2).

Sponsored-by: On-Waves ehf
---
 openbsc/src/gprs/gb_proxy.c           |   54 +++++++--------
 openbsc/tests/gbproxy/gbproxy_test.ok |  120 ++++++++++++++++-----------------
 2 files changed, 87 insertions(+), 87 deletions(-)

diff --git a/openbsc/src/gprs/gb_proxy.c b/openbsc/src/gprs/gb_proxy.c
index 3c41529..4799344 100644
--- a/openbsc/src/gprs/gb_proxy.c
+++ b/openbsc/src/gprs/gb_proxy.c
@@ -45,8 +45,8 @@
 
 enum gbprox_global_ctr {
 	GBPROX_GLOB_CTR_INV_BVCI,
-	GBPROX_GLOB_CTR_INV_LAC,
-	GBPROX_GLOB_CTR_INV_RAC,
+	GBPROX_GLOB_CTR_INV_LAI,
+	GBPROX_GLOB_CTR_INV_RAI,
 	GBPROX_GLOB_CTR_INV_NSEI,
 	GBPROX_GLOB_CTR_PROTO_ERR_BSS,
 	GBPROX_GLOB_CTR_PROTO_ERR_SGSN,
@@ -59,8 +59,8 @@ enum gbprox_global_ctr {
 
 static const struct rate_ctr_desc global_ctr_description[] = {
 	{ "inv-bvci",	    "Invalid BVC Identifier          " },
-	{ "inv-lac",	    "Invalid Location Area Code      " },
-	{ "inv-rac",	    "Invalid Routing Area Code       " },
+	{ "inv-lai",	    "Invalid Location Area Identifier" },
+	{ "inv-rai",	    "Invalid Routing Area Identifier " },
 	{ "inv-nsei",	    "No BVC established for NSEI     " },
 	{ "proto-err.bss",  "BSSGP protocol error      (BSS )" },
 	{ "proto-err.sgsn", "BSSGP protocol error      (SGSN)" },
@@ -154,8 +154,8 @@ static struct gbprox_peer *peer_by_nsei(uint16_t nsei)
 	return NULL;
 }
 
-/* look-up a peer by its Routeing Area Code (RAC) */
-static struct gbprox_peer *peer_by_rac(const uint8_t *ra)
+/* look-up a peer by its Routeing Area Identification (RAI) */
+static struct gbprox_peer *peer_by_rai(const uint8_t *ra)
 {
 	struct gbprox_peer *peer;
 	llist_for_each_entry(peer, &gbprox_bts_peers, list) {
@@ -165,8 +165,8 @@ static struct gbprox_peer *peer_by_rac(const uint8_t *ra)
 	return NULL;
 }
 
-/* look-up a peer by its Location Area Code (LAC) */
-static struct gbprox_peer *peer_by_lac(const uint8_t *la)
+/* look-up a peer by its Location Area Identification (LAI) */
+static struct gbprox_peer *peer_by_lai(const uint8_t *la)
 {
 	struct gbprox_peer *peer;
 	llist_for_each_entry(peer, &gbprox_bts_peers, list) {
@@ -389,11 +389,11 @@ static int gbprox_rx_sig_from_bss(struct msgb *msg, uint16_t nsei,
 	switch (pdu_type) {
 	case BSSGP_PDUT_SUSPEND:
 	case BSSGP_PDUT_RESUME:
-		/* We implement RAC snooping during SUSPEND/RESUME, since
-		 * it establishes a relationsip between BVCI/peer and the
-		 * routeing area code.  The snooped information is then
-		 * used for routing the {SUSPEND,RESUME}_[N]ACK back to
-		 * the correct BSSGP */
+		/* We implement RAI snooping during SUSPEND/RESUME, since it
+		 * establishes a relationsip between BVCI/peer and the routeing
+		 * area identification.  The snooped information is then used
+		 * for routing the {SUSPEND,RESUME}_[N]ACK back to the correct
+		 * BSSGP */
 		if (!TLVP_PRESENT(&tp, BSSGP_IE_ROUTEING_AREA))
 			goto err_mand_ie;
 		from_peer = peer_by_nsei(nsei);
@@ -403,7 +403,7 @@ static int gbprox_rx_sig_from_bss(struct msgb *msg, uint16_t nsei,
 			sizeof(from_peer->ra));
 		gsm48_parse_ra(&raid, from_peer->ra);
 		LOGP(DGPRS, LOGL_INFO, "NSEI=%u BSSGP SUSPEND/RESUME "
-			"RAC snooping: RAC %u-%u-%u-%u behind BVCI=%u\n",
+			"RAI snooping: RAI %u-%u-%u-%u behind BVCI=%u\n",
 			nsei, raid.mcc, raid.mnc, raid.lac,
 			raid.rac , from_peer->bvci);
 		/* FIXME: This only supports one BSS per RA */
@@ -485,15 +485,15 @@ static int gbprox_rx_paging(struct msgb *msg, struct tlv_parsed *tp,
 			bvci);
 		errctr = GBPROX_GLOB_CTR_OTHER_ERR;
 	} else if (TLVP_PRESENT(tp, BSSGP_IE_ROUTEING_AREA)) {
-		peer = peer_by_rac(TLVP_VAL(tp, BSSGP_IE_ROUTEING_AREA));
-		LOGPC(DGPRS, LOGL_INFO, "routing by RAC to peer BVCI=%u\n",
+		peer = peer_by_rai(TLVP_VAL(tp, BSSGP_IE_ROUTEING_AREA));
+		LOGPC(DGPRS, LOGL_INFO, "routing by RAI to peer BVCI=%u\n",
 			peer ? peer->bvci : -1);
-		errctr = GBPROX_GLOB_CTR_INV_RAC;
+		errctr = GBPROX_GLOB_CTR_INV_RAI;
 	} else if (TLVP_PRESENT(tp, BSSGP_IE_LOCATION_AREA)) {
-		peer = peer_by_lac(TLVP_VAL(tp, BSSGP_IE_LOCATION_AREA));
-		LOGPC(DGPRS, LOGL_INFO, "routing by LAC to peer BVCI=%u\n",
+		peer = peer_by_lai(TLVP_VAL(tp, BSSGP_IE_LOCATION_AREA));
+		LOGPC(DGPRS, LOGL_INFO, "routing by LAI to peer BVCI=%u\n",
 			peer ? peer->bvci : -1);
-		errctr = GBPROX_GLOB_CTR_INV_LAC;
+		errctr = GBPROX_GLOB_CTR_INV_LAI;
 	} else
 		LOGPC(DGPRS, LOGL_INFO, "\n");
 
@@ -590,7 +590,7 @@ static int gbprox_rx_sig_from_sgsn(struct msgb *msg, uint32_t nsei,
 		break;
 	case BSSGP_PDUT_PAGING_PS:
 	case BSSGP_PDUT_PAGING_CS:
-		/* process the paging request (LAC/RAC lookup) */
+		/* process the paging request (LAI/RAI lookup) */
 		rc = gbprox_rx_paging(msg, &tp, nsei, ns_bvci);
 		break;
 	case BSSGP_PDUT_STATUS:
@@ -616,10 +616,10 @@ static int gbprox_rx_sig_from_sgsn(struct msgb *msg, uint32_t nsei,
 	case BSSGP_PDUT_SUSPEND_NACK:
 	case BSSGP_PDUT_RESUME_ACK:
 	case BSSGP_PDUT_RESUME_NACK:
-		/* RAC IE is mandatory */
+		/* RAI IE is mandatory */
 		if (!TLVP_PRESENT(&tp, BSSGP_IE_ROUTEING_AREA))
 			goto err_mand_ie;
-		peer = peer_by_rac(TLVP_VAL(&tp, BSSGP_IE_ROUTEING_AREA));
+		peer = peer_by_rai(TLVP_VAL(&tp, BSSGP_IE_ROUTEING_AREA));
 		if (!peer)
 			goto err_no_peer;
 		rc = gbprox_relay2peer(msg, peer, ns_bvci);
@@ -666,9 +666,9 @@ err_mand_ie:
 		     ctr[GBPROX_GLOB_CTR_PROTO_ERR_SGSN]);
 	return bssgp_tx_status(BSSGP_CAUSE_MISSING_MAND_IE, NULL, msg);
 err_no_peer:
-	LOGP(DGPRS, LOGL_ERROR, "NSEI=%u(SGSN) cannot find peer based on RAC\n",
+	LOGP(DGPRS, LOGL_ERROR, "NSEI=%u(SGSN) cannot find peer based on RAI\n",
 		nsei);
-	rate_ctr_inc(&get_global_ctrg()-> ctr[GBPROX_GLOB_CTR_INV_RAC]);
+	rate_ctr_inc(&get_global_ctrg()-> ctr[GBPROX_GLOB_CTR_INV_RAI]);
 	return bssgp_tx_status(BSSGP_CAUSE_UNKNOWN_BVCI, NULL, msg);
 }
 
@@ -853,7 +853,7 @@ int gbprox_dump_peers(FILE *stream, int indent, int verbose)
 		gsm48_parse_ra(&raid, peer->ra);
 
 		rc = fprintf(stream, "%*s  NSEI %u, BVCI %u, %sblocked, "
-			     "RAC %u-%u-%u-%u\n",
+			     "RAI %u-%u-%u-%u\n",
 			     indent, "",
 			     peer->nsei, peer->bvci,
 			     peer->blocked ? "" : "not ",
@@ -921,7 +921,7 @@ static void gbprox_vty_print_peer(struct vty *vty, struct gbprox_peer *peer)
 	gsm48_parse_ra(&raid, peer->ra);
 
 	vty_out(vty, "NSEI %5u, PTP-BVCI %5u, "
-		"RAC %u-%u-%u-%u",
+		"RAI %u-%u-%u-%u",
 		peer->nsei, peer->bvci,
 		raid.mcc, raid.mnc, raid.lac, raid.rac);
 	if (peer->blocked)
diff --git a/openbsc/tests/gbproxy/gbproxy_test.ok b/openbsc/tests/gbproxy/gbproxy_test.ok
index e677ec0..3b25922 100644
--- a/openbsc/tests/gbproxy/gbproxy_test.ok
+++ b/openbsc/tests/gbproxy/gbproxy_test.ok
@@ -101,7 +101,7 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAI 112-332-16464-96
 PROCESSING BVC_RESET_ACK from 0x05060708:32000
 00 00 00 00 23 04 82 10 02 
 
@@ -179,8 +179,8 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAI 112-332-16464-96
 PROCESSING BVC_RESET_ACK from 0x05060708:32000
 00 00 00 00 23 04 82 20 02 
 
@@ -242,8 +242,8 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAI 112-332-16464-96
 --- Move BSS 2 to former BSS 1 port ---
 
 Setup NS-VC: remote 0x01020304:1111, NSVCI 0x2001(8193), NSEI 0x2000(8192)
@@ -291,8 +291,8 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAI 112-332-16464-96
 --- Move BSS 1 to current BSS 2 port ---
 
 Setup NS-VC: remote 0x01020304:1111, NSVCI 0x2001(8193), NSEI 0x2000(8192)
@@ -340,8 +340,8 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAI 112-332-16464-96
 --- Move BSS 2 to new port ---
 
 Setup NS-VC: remote 0x01020304:4444, NSVCI 0x2001(8193), NSEI 0x2000(8192)
@@ -389,8 +389,8 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAI 112-332-16464-96
 --- Move BSS 2 to former BSS 1 port ---
 
 Setup NS-VC: remote 0x01020304:3333, NSVCI 0x2001(8193), NSEI 0x2000(8192)
@@ -441,8 +441,8 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAI 112-332-16464-96
 --- Move BSS 1 to original BSS 1 port ---
 
 Setup NS-VC: remote 0x01020304:1111, NSVCI 0x1001(4097), NSEI 0x1000(4096)
@@ -491,8 +491,8 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAI 112-332-16464-96
 --- Reset BSS 1 with a new BVCI ---
 
 Setup BSSGP: remote 0x01020304:1111, BVCI 0x1012(4114)
@@ -519,9 +519,9 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 4096, BVCI 4114, not blocked, RAC 112-332-16464-96
-  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4114, not blocked, RAI 112-332-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAI 112-332-16464-96
 PROCESSING BVC_RESET_ACK from 0x05060708:32000
 00 00 00 00 23 04 82 10 12 
 
@@ -562,9 +562,9 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 4096, BVCI 4114, not blocked, RAC 112-332-16464-96
-  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4114, not blocked, RAI 112-332-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAI 112-332-16464-96
 PROCESSING BVC_RESET_ACK from 0x05060708:32000
 00 00 00 00 23 04 82 10 02 
 
@@ -605,9 +605,9 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 4096, BVCI 4114, not blocked, RAC 112-332-16464-96
-  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4114, not blocked, RAI 112-332-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAI 112-332-16464-96
 PROCESSING BVC_RESET_ACK from 0x05060708:32000
 00 00 00 00 23 04 82 10 02 
 
@@ -744,10 +744,10 @@ Current NS-VCIs:
          NS-VC Block count         : 1
 
 Peers:
-  NSEI 4096, BVCI 4114, not blocked, RAC 112-332-16464-96
-  NSEI 8192, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4114, not blocked, RAI 112-332-16464-96
+  NSEI 8192, BVCI 8194, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 1
-  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 1
 Gbproxy global:
 PROCESSING BVC_RESET_ACK from 0x05060708:32000
@@ -932,7 +932,7 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9
 result (BVC_RESET_ACK) = 9
 
 Peers:
-  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAI 112-332-16464-96
 --- Setup BVCI 2 ---
 
 Setup BSSGP: remote 0x01020304:1111, BVCI 0x2002(8194)
@@ -966,8 +966,8 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9
 result (BVC_RESET_ACK) = 9
 
 Peers:
-  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 4098, not blocked, RAI 112-332-16464-96
 --- Send message from BSS 1 to SGSN and back, BVCI 1 ---
 
 PROCESSING UNITDATA from 0x01020304:1111
@@ -1107,8 +1107,8 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9
 result (BVC_RESET_ACK) = 9
 
 Peers:
-  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
-  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAI 112-332-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 1
 --- Setup BVCI 3 ---
 
@@ -1143,9 +1143,9 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9
 result (BVC_RESET_ACK) = 9
 
 Peers:
-  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
-  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAI 112-332-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 1
 --- Send message from BSS 1 to SGSN and back, BVCI 1 ---
 
@@ -1194,10 +1194,10 @@ MESSAGE to SGSN at 0x05060708:32000, msg length 4
 result (UNITDATA) = 4
 
 Peers:
-  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 1
-  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 1
 PROCESSING UNITDATA from 0x05060708:32000
 00 00 20 02 
@@ -1211,11 +1211,11 @@ NS UNITDATA MESSAGE to BSS, BVCI 0x2002, msg length 0
 result (UNITDATA) = -22
 
 Peers:
-  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 1
     NS Transmission error           : 1
-  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 1
 --- Send message from BSS 1 to SGSN and back, BVCI 3 ---
 
@@ -1330,11 +1330,11 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9
 result (BVC_RESET_ACK) = 9
 
 Peers:
-  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 1
     NS Transmission error           : 1
-  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 1
 --- Setup BVCI 4 ---
 
@@ -1369,12 +1369,12 @@ MESSAGE to BSS at 0x01020304:1111, msg length 9
 result (BVC_RESET_ACK) = 9
 
 Peers:
-  NSEI 8192, BVCI 16386, not blocked, RAC 112-332-16464-96
-  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 16386, not blocked, RAI 112-332-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 1
     NS Transmission error           : 1
-  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 1
 --- Send message from BSS 1 to SGSN and back, BVCI 1 ---
 
@@ -1423,12 +1423,12 @@ MESSAGE to SGSN at 0x05060708:32000, msg length 4
 result (UNITDATA) = 4
 
 Peers:
-  NSEI 8192, BVCI 16386, not blocked, RAC 112-332-16464-96
-  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 16386, not blocked, RAI 112-332-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 2
     NS Transmission error           : 1
-  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 1
 PROCESSING UNITDATA from 0x05060708:32000
 00 00 20 02 
@@ -1442,12 +1442,12 @@ NS UNITDATA MESSAGE to BSS, BVCI 0x2002, msg length 0
 result (UNITDATA) = -22
 
 Peers:
-  NSEI 8192, BVCI 16386, not blocked, RAC 112-332-16464-96
-  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 16386, not blocked, RAI 112-332-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 2
     NS Transmission error           : 2
-  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 1
 --- Send message from BSS 1 to SGSN and back, BVCI 3 ---
 
@@ -1511,12 +1511,12 @@ result (UNITDATA) = 4
 
 Gbproxy global:
 Peers:
-  NSEI 8192, BVCI 16386, not blocked, RAC 112-332-16464-96
-  NSEI 8192, BVCI 12290, not blocked, RAC 112-332-16464-96
-  NSEI 4096, BVCI 8194, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 16386, not blocked, RAI 112-332-16464-96
+  NSEI 8192, BVCI 12290, not blocked, RAI 112-332-16464-96
+  NSEI 4096, BVCI 8194, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 2
     NS Transmission error           : 2
-  NSEI 8192, BVCI 4098, not blocked, RAC 112-332-16464-96
+  NSEI 8192, BVCI 4098, not blocked, RAI 112-332-16464-96
     NSEI mismatch                   : 1
 ===== GbProxy test END
 
-- 
1.7.9.5




From holger at freyther.de  Wed Jun  4 14:28:11 2014
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed, 4 Jun 2014 16:28:11 +0200
Subject: [PATCH 2/3] gprs: Use area terms LAI/RAI as defined in GSM 03.03
In-Reply-To: <1401698941-10318-2-git-send-email-jerlbeck@sysmocom.de>
References: <1401698941-10318-1-git-send-email-jerlbeck@sysmocom.de>
	<1401698941-10318-2-git-send-email-jerlbeck@sysmocom.de>
Message-ID: <20140604142811.GA21904@xiaoyu.lan>

On Mon, Jun 02, 2014 at 10:49:00AM +0200, Jacob Erlbeck wrote:

> Note that RAI := MCC MNC LAC RAC, and RAC := MCC MNC LAC (see GSM

		\            /		^^^^
		    LAI        RAC      LAI ??

> +	{ "inv-rai",	    "Invalid Routing Area Identifier " },
> +/* look-up a peer by its Routeing Area Identification (RAI) */

The spec you mention is using "routing". Please be consistent. Given
the question about s,RAC,LAI, I am waiting for your feedback.

holger





From jerlbeck at sysmocom.de  Thu Jun  5 08:23:06 2014
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Thu, 05 Jun 2014 10:23:06 +0200
Subject: [PATCH 2/3] gprs: Use area terms LAI/RAI as defined in GSM 03.03
In-Reply-To: <20140604142811.GA21904@xiaoyu.lan>
References: <1401698941-10318-1-git-send-email-jerlbeck@sysmocom.de>
	<1401698941-10318-2-git-send-email-jerlbeck@sysmocom.de>
	<20140604142811.GA21904@xiaoyu.lan>
Message-ID: <539028EA.2020002@sysmocom.de>

On 04.06.2014 16:28, Holger Hans Peter Freyther wrote:
> On Mon, Jun 02, 2014 at 10:49:00AM +0200, Jacob Erlbeck wrote:
> 
>> Note that RAI := MCC MNC LAC RAC, and RAC := MCC MNC LAC (see GSM
> 
> 		\            /		^^^^
> 		    LAI        RAC      LAI ??

Oops, that was a typo of mine. Of course it's LAI := MCC MNC LAC.

> 
>> +	{ "inv-rai",	    "Invalid Routing Area Identifier " },
>> +/* look-up a peer by its Routeing Area Identification (RAI) */
> 
> The spec you mention is using "routing". Please be consistent. 

Unfortunately the specs themselves are not consistent with respect to
this, GSM 08.18 is using the British variant. Thus the identifier in
gsm_08_18.h also use the ROUTEING variant.

The C file already was mixing the British and the American English
variants. This commit didn't add any 'rout(e)ing' term, it focused on
the 'code' issue.

While I agree that we should strive for consistency, I'd rather put it
into a specific commit when we've settled on which variant shall be taken.

Jacob

> Given
> the question about s,RAC,LAI, I am waiting for your feedback.
> 
> holger
> 
> 


-- 
- Jacob Erlbeck <jerlbeck at sysmocom.de>       http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte



From jerlbeck at sysmocom.de  Mon Jun  2 08:49:01 2014
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Mon,  2 Jun 2014 10:49:01 +0200
Subject: [PATCH 3/3] gprs: Separate LLC parsing from LLC state handling
In-Reply-To: <1401698941-10318-1-git-send-email-jerlbeck@sysmocom.de>
References: <1401698941-10318-1-git-send-email-jerlbeck@sysmocom.de>
Message-ID: <1401698941-10318-3-git-send-email-jerlbeck@sysmocom.de>

Currently LLC parsing is part of gprs_llc.c which needs large parts
of the SGSN code parsing to fulfill its link dependencies.

This patch moves the functions that just do plain parsing, dumping,
and FCS computation to a different file to avoid these dependencies
if LLC stateful processing is not needed. It also exposes
struct gprs_llc_hdr_parsed and enum gprs_llc_cmd publically.

Sponsored-by: On-Waves ehf
---
 openbsc/include/openbsc/gprs_llc.h |   41 ++++++
 openbsc/src/gprs/Makefile.am       |    2 +-
 openbsc/src/gprs/gprs_llc.c        |  236 ----------------------------------
 openbsc/src/gprs/gprs_llc_parse.c  |  243 ++++++++++++++++++++++++++++++++++++
 4 files changed, 285 insertions(+), 237 deletions(-)
 create mode 100644 openbsc/src/gprs/gprs_llc_parse.c

diff --git a/openbsc/include/openbsc/gprs_llc.h b/openbsc/include/openbsc/gprs_llc.h
index 4be7b1f..854b968 100644
--- a/openbsc/include/openbsc/gprs_llc.h
+++ b/openbsc/include/openbsc/gprs_llc.h
@@ -165,6 +165,39 @@ struct gprs_llc_llme {
 
 extern struct llist_head gprs_llc_llmes;
 
+/* LLC low level types */
+
+enum gprs_llc_cmd {
+	GPRS_LLC_NULL,
+	GPRS_LLC_RR,
+	GPRS_LLC_ACK,
+	GPRS_LLC_RNR,
+	GPRS_LLC_SACK,
+	GPRS_LLC_DM,
+	GPRS_LLC_DISC,
+	GPRS_LLC_UA,
+	GPRS_LLC_SABM,
+	GPRS_LLC_FRMR,
+	GPRS_LLC_XID,
+	GPRS_LLC_UI,
+};
+
+struct gprs_llc_hdr_parsed {
+	uint8_t sapi;
+	uint8_t is_cmd:1,
+		 ack_req:1,
+		 is_encrypted:1;
+	uint32_t seq_rx;
+	uint32_t seq_tx;
+	uint32_t fcs;
+	uint32_t fcs_calc;
+	uint8_t *data;
+	uint16_t data_len;
+	uint16_t crc_length;
+	enum gprs_llc_cmd cmd;
+};
+
+
 /* BSSGP-UL-UNITDATA.ind */
 int gprs_llc_rcvmsg(struct msgb *msg, struct tlv_parsed *tv);
 
@@ -199,4 +232,12 @@ static inline int gprs_llc_is_retransmit(uint16_t nu, uint16_t vur)
 	return 0 < delta && delta < 32;
 }
 
+/* LLC low level functions */
+
+/* parse a GPRS LLC header, also check for invalid frames */
+int gprs_llc_hdr_parse(struct gprs_llc_hdr_parsed *ghp,
+		       uint8_t *llc_hdr, int len);
+void gprs_llc_hdr_dump(struct gprs_llc_hdr_parsed *gph);
+int gprs_llc_fcs(uint8_t *data, unsigned int len);
+
 #endif
diff --git a/openbsc/src/gprs/Makefile.am b/openbsc/src/gprs/Makefile.am
index 90c376c..049d41d 100644
--- a/openbsc/src/gprs/Makefile.am
+++ b/openbsc/src/gprs/Makefile.am
@@ -19,7 +19,7 @@ osmo_gbproxy_LDADD = 	$(top_builddir)/src/libcommon/libcommon.a \
 
 osmo_sgsn_SOURCES =	gprs_gmm.c gprs_sgsn.c gprs_sndcp.c gprs_sndcp_vty.c \
 			sgsn_main.c sgsn_vty.c sgsn_libgtp.c \
-			gprs_llc.c gprs_llc_vty.c crc24.c \
+			gprs_llc.c gprs_llc_parse.c gprs_llc_vty.c crc24.c \
 			sgsn_ctrl.c
 osmo_sgsn_LDADD = 	\
 			$(top_builddir)/src/libctrl/libctrl.a \
diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c
index 1e40dcb..70fe9dd 100644
--- a/openbsc/src/gprs/gprs_llc.c
+++ b/openbsc/src/gprs/gprs_llc.c
@@ -36,52 +36,6 @@
 #include <openbsc/crc24.h>
 #include <openbsc/sgsn.h>
 
-enum gprs_llc_cmd {
-	GPRS_LLC_NULL,
-	GPRS_LLC_RR,
-	GPRS_LLC_ACK,
-	GPRS_LLC_RNR,
-	GPRS_LLC_SACK,
-	GPRS_LLC_DM,
-	GPRS_LLC_DISC,
-	GPRS_LLC_UA,
-	GPRS_LLC_SABM,
-	GPRS_LLC_FRMR,
-	GPRS_LLC_XID,
-	GPRS_LLC_UI,
-};
-
-static const struct value_string llc_cmd_strs[] = {
-	{ GPRS_LLC_NULL,	"NULL" },
-	{ GPRS_LLC_RR,		"RR" },
-	{ GPRS_LLC_ACK,		"ACK" },
-	{ GPRS_LLC_RNR,		"RNR" },
-	{ GPRS_LLC_SACK,	"SACK" },
-	{ GPRS_LLC_DM,		"DM" },
-	{ GPRS_LLC_DISC,	"DISC" },
-	{ GPRS_LLC_UA,		"UA" },
-	{ GPRS_LLC_SABM,	"SABM" },
-	{ GPRS_LLC_FRMR,	"FRMR" },
-	{ GPRS_LLC_XID,		"XID" },
-	{ GPRS_LLC_UI,		"UI" },
-	{ 0, NULL }
-};
-
-struct gprs_llc_hdr_parsed {
-	uint8_t sapi;
-	uint8_t is_cmd:1,
-		 ack_req:1,
-		 is_encrypted:1;
-	uint32_t seq_rx;
-	uint32_t seq_tx;
-	uint32_t fcs;
-	uint32_t fcs_calc;
-	uint8_t *data;
-	uint16_t data_len;
-	uint16_t crc_length;
-	enum gprs_llc_cmd cmd;
-};
-
 static struct gprs_llc_llme *llme_alloc(uint32_t tlli);
 
 /* If the TLLI is foreign, return its local version */
@@ -292,22 +246,6 @@ static void llme_free(struct gprs_llc_llme *llme)
 	talloc_free(llme);
 }
 
-#define LLC_ALLOC_SIZE 16384
-#define UI_HDR_LEN	3
-#define N202		4
-#define CRC24_LENGTH	3
-
-static int gprs_llc_fcs(uint8_t *data, unsigned int len)
-{
-	uint32_t fcs_calc;
-
-	fcs_calc = crc24_calc(INIT_CRC24, data, len);
-	fcs_calc = ~fcs_calc;
-	fcs_calc &= 0xffffff;
-
-	return fcs_calc;
-}
-
 #if 0
 /* FIXME: Unused code... */
 static void t200_expired(void *data)
@@ -550,20 +488,6 @@ static void rx_llc_xid(struct gprs_llc_lle *lle,
 	}
 }
 
-static void gprs_llc_hdr_dump(struct gprs_llc_hdr_parsed *gph)
-{
-	DEBUGP(DLLC, "LLC SAPI=%u %c %c FCS=0x%06x",
-		gph->sapi, gph->is_cmd ? 'C' : 'R', gph->ack_req ? 'A' : ' ',
-		gph->fcs);
-
-	if (gph->cmd)
-		DEBUGPC(DLLC, "CMD=%s ", get_value_string(llc_cmd_strs, gph->cmd));
-
-	if (gph->data)
-		DEBUGPC(DLLC, "DATA ");
-
-	DEBUGPC(DLLC, "\n");
-}
 static int gprs_llc_hdr_rx(struct gprs_llc_hdr_parsed *gph,
 			   struct gprs_llc_lle *lle)
 {
@@ -634,166 +558,6 @@ static int gprs_llc_hdr_rx(struct gprs_llc_hdr_parsed *gph,
 	return 0;
 }
 
-/* parse a GPRS LLC header, also check for invalid frames */
-static int gprs_llc_hdr_parse(struct gprs_llc_hdr_parsed *ghp,
-			      uint8_t *llc_hdr, int len)
-{
-	uint8_t *ctrl = llc_hdr+1;
-
-	if (len <= CRC24_LENGTH)
-		return -EIO;
-
-	ghp->crc_length = len - CRC24_LENGTH;
-
-	ghp->ack_req = 0;
-
-	/* Section 5.5: FCS */
-	ghp->fcs = *(llc_hdr + len - 3);
-	ghp->fcs |= *(llc_hdr + len - 2) << 8;
-	ghp->fcs |= *(llc_hdr + len - 1) << 16;
-
-	/* Section 6.2.1: invalid PD field */
-	if (llc_hdr[0] & 0x80)
-		return -EIO;
-
-	/* This only works for the MS->SGSN direction */
-	if (llc_hdr[0] & 0x40)
-		ghp->is_cmd = 0;
-	else
-		ghp->is_cmd = 1;
-
-	ghp->sapi = llc_hdr[0] & 0xf;
-
-	/* Section 6.2.3: check for reserved SAPI */
-	switch (ghp->sapi) {
-	case 0:
-	case 4:
-	case 6:
-	case 0xa:
-	case 0xc:
-	case 0xd:
-	case 0xf:
-		return -EINVAL;
-	}
-
-	if ((ctrl[0] & 0x80) == 0) {
-		/* I (Information transfer + Supervisory) format */
-		uint8_t k;
-
-		ghp->data = ctrl + 3;
-
-		if (ctrl[0] & 0x40)
-			ghp->ack_req = 1;
-
-		ghp->seq_tx  = (ctrl[0] & 0x1f) << 4;
-		ghp->seq_tx |= (ctrl[1] >> 4);
-
-		ghp->seq_rx  = (ctrl[1] & 0x7) << 6;
-		ghp->seq_rx |= (ctrl[2] >> 2);
-
-		switch (ctrl[2] & 0x03) {
-		case 0:
-			ghp->cmd = GPRS_LLC_RR;
-			break;
-		case 1:
-			ghp->cmd = GPRS_LLC_ACK;
-			break;
-		case 2:
-			ghp->cmd = GPRS_LLC_RNR;
-			break;
-		case 3:
-			ghp->cmd = GPRS_LLC_SACK;
-			k = ctrl[3] & 0x1f;
-			ghp->data += 1 + k;
-			break;
-		}
-		ghp->data_len = (llc_hdr + len - 3) - ghp->data;
-	} else if ((ctrl[0] & 0xc0) == 0x80) {
-		/* S (Supervisory) format */
-		ghp->data = NULL;
-		ghp->data_len = 0;
-
-		if (ctrl[0] & 0x20)
-			ghp->ack_req = 1;
-		ghp->seq_rx  = (ctrl[0] & 0x7) << 6;
-		ghp->seq_rx |= (ctrl[1] >> 2);
-
-		switch (ctrl[1] & 0x03) {
-		case 0:
-			ghp->cmd = GPRS_LLC_RR;
-			break;
-		case 1:
-			ghp->cmd = GPRS_LLC_ACK;
-			break;
-		case 2:
-			ghp->cmd = GPRS_LLC_RNR;
-			break;
-		case 3:
-			ghp->cmd = GPRS_LLC_SACK;
-			break;
-		}
-	} else if ((ctrl[0] & 0xe0) == 0xc0) {
-		/* UI (Unconfirmed Inforamtion) format */
-		ghp->cmd = GPRS_LLC_UI;
-		ghp->data = ctrl + 2;
-		ghp->data_len = (llc_hdr + len - 3) - ghp->data;
-
-		ghp->seq_tx  = (ctrl[0] & 0x7) << 6;
-		ghp->seq_tx |= (ctrl[1] >> 2);
-		if (ctrl[1] & 0x02) {
-			ghp->is_encrypted = 1;
-			/* FIXME: encryption */
-		}
-		if (ctrl[1] & 0x01) {
-			/* FCS over hdr + all inf fields */
-		} else {
-			/* FCS over hdr + N202 octets (4) */
-			if (ghp->crc_length > UI_HDR_LEN + N202)
-				ghp->crc_length = UI_HDR_LEN + N202;
-		}
-	} else {
-		/* U (Unnumbered) format: 1 1 1 P/F M4 M3 M2 M1 */
-		ghp->data = NULL;
-		ghp->data_len = 0;
-
-		switch (ctrl[0] & 0xf) {
-		case GPRS_LLC_U_NULL_CMD:
-			ghp->cmd = GPRS_LLC_NULL;
-			break;
-		case GPRS_LLC_U_DM_RESP:
-			ghp->cmd = GPRS_LLC_DM;
-			break;
-		case GPRS_LLC_U_DISC_CMD:
-			ghp->cmd = GPRS_LLC_DISC;
-			break;
-		case GPRS_LLC_U_UA_RESP:
-			ghp->cmd = GPRS_LLC_UA;
-			break;
-		case GPRS_LLC_U_SABM_CMD:
-			ghp->cmd = GPRS_LLC_SABM;
-			break;
-		case GPRS_LLC_U_FRMR_RESP:
-			ghp->cmd = GPRS_LLC_FRMR;
-			break;
-		case GPRS_LLC_U_XID:
-			ghp->cmd = GPRS_LLC_XID;
-			ghp->data = ctrl + 1;
-			ghp->data_len = (llc_hdr + len - 3) - ghp->data;
-			break;
-		default:
-			return -EIO;
-		}
-	}
-
-	/* FIXME: parse sack frame */
-	if (ghp->cmd == GPRS_LLC_SACK) {
-		LOGP(DLLC, LOGL_NOTICE, "Unsupported SACK frame\n");
-		return -EIO;
-	}
-
-	return 0;
-}
-
 /* receive an incoming LLC PDU (BSSGP-UL-UNITDATA-IND, 7.2.4.2) */
 int gprs_llc_rcvmsg(struct msgb *msg, struct tlv_parsed *tv)
 {
diff --git a/openbsc/src/gprs/gprs_llc_parse.c b/openbsc/src/gprs/gprs_llc_parse.c
new file mode 100644
index 0000000..b1f1a56
--- /dev/null
+++ b/openbsc/src/gprs/gprs_llc_parse.c
@@ -0,0 +1,243 @@
+/* GPRS LLC protocol implementation as per 3GPP TS 04.64 */
+
+/* (C) 2009-2010 by Harald Welte <laforge at gnumonks.org>
+ *
+ * All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Affero General Public License as published by
+ * the Free Software Foundation; either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Affero General Public License for more details.
+ *
+ * You should have received a copy of the GNU Affero General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#include <errno.h>
+#include <stdint.h>
+
+#include <osmocom/core/msgb.h>
+#include <osmocom/core/linuxlist.h>
+#include <osmocom/core/timer.h>
+#include <osmocom/core/talloc.h>
+#include <osmocom/gprs/gprs_bssgp.h>
+
+#include <openbsc/gsm_data.h>
+#include <openbsc/debug.h>
+#include <openbsc/gprs_sgsn.h>
+#include <openbsc/gprs_gmm.h>
+#include <openbsc/gprs_llc.h>
+#include <openbsc/crc24.h>
+
+static const struct value_string llc_cmd_strs[] = {
+	{ GPRS_LLC_NULL,	"NULL" },
+	{ GPRS_LLC_RR,		"RR" },
+	{ GPRS_LLC_ACK,		"ACK" },
+	{ GPRS_LLC_RNR,		"RNR" },
+	{ GPRS_LLC_SACK,	"SACK" },
+	{ GPRS_LLC_DM,		"DM" },
+	{ GPRS_LLC_DISC,	"DISC" },
+	{ GPRS_LLC_UA,		"UA" },
+	{ GPRS_LLC_SABM,	"SABM" },
+	{ GPRS_LLC_FRMR,	"FRMR" },
+	{ GPRS_LLC_XID,		"XID" },
+	{ GPRS_LLC_UI,		"UI" },
+	{ 0, NULL }
+};
+
+#define LLC_ALLOC_SIZE 16384
+#define UI_HDR_LEN	3
+#define N202		4
+#define CRC24_LENGTH	3
+
+int gprs_llc_fcs(uint8_t *data, unsigned int len)
+{
+	uint32_t fcs_calc;
+
+	fcs_calc = crc24_calc(INIT_CRC24, data, len);
+	fcs_calc = ~fcs_calc;
+	fcs_calc &= 0xffffff;
+
+	return fcs_calc;
+}
+
+void gprs_llc_hdr_dump(struct gprs_llc_hdr_parsed *gph)
+{
+	DEBUGP(DLLC, "LLC SAPI=%u %c %c FCS=0x%06x",
+		gph->sapi, gph->is_cmd ? 'C' : 'R', gph->ack_req ? 'A' : ' ',
+		gph->fcs);
+
+	if (gph->cmd)
+		DEBUGPC(DLLC, "CMD=%s ", get_value_string(llc_cmd_strs, gph->cmd));
+
+	if (gph->data)
+		DEBUGPC(DLLC, "DATA ");
+
+	DEBUGPC(DLLC, "\n");
+}
+
+/* parse a GPRS LLC header, also check for invalid frames */
+int gprs_llc_hdr_parse(struct gprs_llc_hdr_parsed *ghp,
+		       uint8_t *llc_hdr, int len)
+{
+	uint8_t *ctrl = llc_hdr+1;
+
+	if (len <= CRC24_LENGTH)
+		return -EIO;
+
+	ghp->crc_length = len - CRC24_LENGTH;
+
+	ghp->ack_req = 0;
+
+	/* Section 5.5: FCS */
+	ghp->fcs = *(llc_hdr + len - 3);
+	ghp->fcs |= *(llc_hdr + len - 2) << 8;
+	ghp->fcs |= *(llc_hdr + len - 1) << 16;
+
+	/* Section 6.2.1: invalid PD field */
+	if (llc_hdr[0] & 0x80)
+		return -EIO;
+
+	/* This only works for the MS->SGSN direction */
+	if (llc_hdr[0] & 0x40)
+		ghp->is_cmd = 0;
+	else
+		ghp->is_cmd = 1;
+
+	ghp->sapi = llc_hdr[0] & 0xf;
+
+	/* Section 6.2.3: check for reserved SAPI */
+	switch (ghp->sapi) {
+	case 0:
+	case 4:
+	case 6:
+	case 0xa:
+	case 0xc:
+	case 0xd:
+	case 0xf:
+		return -EINVAL;
+	}
+
+	if ((ctrl[0] & 0x80) == 0) {
+		/* I (Information transfer + Supervisory) format */
+		uint8_t k;
+
+		ghp->data = ctrl + 3;
+
+		if (ctrl[0] & 0x40)
+			ghp->ack_req = 1;
+
+		ghp->seq_tx  = (ctrl[0] & 0x1f) << 4;
+		ghp->seq_tx |= (ctrl[1] >> 4);
+
+		ghp->seq_rx  = (ctrl[1] & 0x7) << 6;
+		ghp->seq_rx |= (ctrl[2] >> 2);
+
+		switch (ctrl[2] & 0x03) {
+		case 0:
+			ghp->cmd = GPRS_LLC_RR;
+			break;
+		case 1:
+			ghp->cmd = GPRS_LLC_ACK;
+			break;
+		case 2:
+			ghp->cmd = GPRS_LLC_RNR;
+			break;
+		case 3:
+			ghp->cmd = GPRS_LLC_SACK;
+			k = ctrl[3] & 0x1f;
+			ghp->data += 1 + k;
+			break;
+		}
+		ghp->data_len = (llc_hdr + len - 3) - ghp->data;
+	} else if ((ctrl[0] & 0xc0) == 0x80) {
+		/* S (Supervisory) format */
+		ghp->data = NULL;
+		ghp->data_len = 0;
+
+		if (ctrl[0] & 0x20)
+			ghp->ack_req = 1;
+		ghp->seq_rx  = (ctrl[0] & 0x7) << 6;
+		ghp->seq_rx |= (ctrl[1] >> 2);
+
+		switch (ctrl[1] & 0x03) {
+		case 0:
+			ghp->cmd = GPRS_LLC_RR;
+			break;
+		case 1:
+			ghp->cmd = GPRS_LLC_ACK;
+			break;
+		case 2:
+			ghp->cmd = GPRS_LLC_RNR;
+			break;
+		case 3:
+			ghp->cmd = GPRS_LLC_SACK;
+			break;
+		}
+	} else if ((ctrl[0] & 0xe0) == 0xc0) {
+		/* UI (Unconfirmed Inforamtion) format */
+		ghp->cmd = GPRS_LLC_UI;
+		ghp->data = ctrl + 2;
+		ghp->data_len = (llc_hdr + len - 3) - ghp->data;
+
+		ghp->seq_tx  = (ctrl[0] & 0x7) << 6;
+		ghp->seq_tx |= (ctrl[1] >> 2);
+		if (ctrl[1] & 0x02) {
+			ghp->is_encrypted = 1;
+			/* FIXME: encryption */
+		}
+		if (ctrl[1] & 0x01) {
+			/* FCS over hdr + all inf fields */
+		} else {
+			/* FCS over hdr + N202 octets (4) */
+			if (ghp->crc_length > UI_HDR_LEN + N202)
+				ghp->crc_length = UI_HDR_LEN + N202;
+		}
+	} else {
+		/* U (Unnumbered) format: 1 1 1 P/F M4 M3 M2 M1 */
+		ghp->data = NULL;
+		ghp->data_len = 0;
+
+		switch (ctrl[0] & 0xf) {
+		case GPRS_LLC_U_NULL_CMD:
+			ghp->cmd = GPRS_LLC_NULL;
+			break;
+		case GPRS_LLC_U_DM_RESP:
+			ghp->cmd = GPRS_LLC_DM;
+			break;
+		case GPRS_LLC_U_DISC_CMD:
+			ghp->cmd = GPRS_LLC_DISC;
+			break;
+		case GPRS_LLC_U_UA_RESP:
+			ghp->cmd = GPRS_LLC_UA;
+			break;
+		case GPRS_LLC_U_SABM_CMD:
+			ghp->cmd = GPRS_LLC_SABM;
+			break;
+		case GPRS_LLC_U_FRMR_RESP:
+			ghp->cmd = GPRS_LLC_FRMR;
+			break;
+		case GPRS_LLC_U_XID:
+			ghp->cmd = GPRS_LLC_XID;
+			ghp->data = ctrl + 1;
+			ghp->data_len = (llc_hdr + len - 3) - ghp->data;
+			break;
+		default:
+			return -EIO;
+		}
+	}
+
+	/* FIXME: parse sack frame */
+	if (ghp->cmd == GPRS_LLC_SACK) {
+		LOGP(DLLC, LOGL_NOTICE, "Unsupported SACK frame\n");
+		return -EIO;
+	}
+
+	return 0;
+}
-- 
1.7.9.5




From joshtoal17 at gmail.com  Tue Jun  3 17:09:19 2014
From: joshtoal17 at gmail.com (Josh toal)
Date: Tue, 3 Jun 2014 13:09:19 -0400
Subject: routing area reject and pdp deactivation
Message-ID: <CADXvYi5Xb9ojmvdpSMOVZPAuh+ZUpBDEH8JOiC0U1Z6f=N-5vw@mail.gmail.com>

Hi All

in my sgsn log I am getting


<0002> gprs_gmm.c:921 -> GMM RA UPDATE REQUEST type="RA updating"  LLC XID
RESET  REJECT
<0002> gprs_gmm.c:860 <- ROUTING AREA UPDATE REJECT

then
<0002> gprs_gmm.c:640 -> GMM ATTACH REQUEST MI(xxxxxxx) type="GPRS attach"
<0002> gprs_gmm.c:444 <- GPRS IDENTITY REQUEST: mi_type=02
<0011> gprs_bssgp.c:753 BSSGP BVCI=2 Rx Flow Control BVC
<0011> gprs_bssgp.c:376 BSSGP TLLI=0xxxxxx Rx UPLINK-UNITDATA
<0012> gprs_llc.c:554 LLC SAPI=1 C   FCS=0xxxxx=UI DATA
<0002> gprs_gmm.c:582 -> GMM IDENTITY RESPONSE: mi_type=0x02 MI(xxxxxxxxx)
<0002> gprs_gmm.c:352 <- GPRS ATTACH ACCEPT (new P-TMSI=0xxxxxxx)
<0011> gprs_bssgp.c:376 BSSGP TLLI=0xxxxxx Rx UPLINK-UNITDATA
<0012> gprs_llc.c:554 LLC SAPI=1 C   FCS=0xxxxxxxx=UI DATA
<0002> gprs_gmm.c:1052 -> ATTACH COMPLETE

and then
<0002> gprs_gmm.c:1319 -> ACTIVATE PDP CONTEXT REQ: SAPI=3 NSAPI=5 IETF
IPv4
<000f> sgsn_libgtp.c:126 Create PDP Context
<000f> sgsn_libgtp.c:379 libgtp cb_conf(type=16, cause=128, pdp=0xxxxxxx,
cbp=0x1xxxxx)
<000f> sgsn_libgtp.c:265 Received CREATE PDP CTX CONF, cause=128(Request
accepted)
<0002> gprs_gmm.c:1197 <- ACTIVATE PDP CONTEXT ACK

finally
<0002> gprs_gmm.c:1432 -> DEACTIVATE PDP CONTEXT REQ (cause: Regular
deactivation)
<000f> sgsn_libgtp.c:212 Delete PDP Context
<000f> sgsn_libgtp.c:402 PDP Context was deleted
<000f> sgsn_libgtp.c:379 libgtp cb_conf(type=20, cause=128, pdp=(nil),
cbp=0xxxxxx)
<000f> sgsn_libgtp.c:321 Received DELETE PDP CTX CONF, cause=128(Request
accepted)
<0002> gprs_gmm.c:1290 <- DEACTIVATE PDP CONTEXT ACK


Am I getting PDP deactivation because of routing area reject.
Also noticed that  TLLI changes from Activate PDP context. This TLLI is
based on TMSI/P-TMSI
Upto Attach complete procedure I have different TLLI.


For setup I have

BSC, SGSN on eth0 and eth0:1 respectively and
GGSN on eth1 ( I have external network adapter).

Can anybody suggest something why I am not getting pdp deactivation.

regards
Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140603/21d34e52/attachment.htm>

From joshtoal17 at gmail.com  Tue Jun  3 17:42:12 2014
From: joshtoal17 at gmail.com (Josh toal)
Date: Tue, 3 Jun 2014 13:42:12 -0400
Subject: routing area reject and pdp deactivation
Message-ID: <CADXvYi5BMGv2UHJ4Mn2Gu48=vpz_WvRgehG88S-1WgQ1Q9fq9w@mail.gmail.com>

Hi All

there was typo in my earlier post therefore posting again--sorry! for that

in my sgsn log I am getting


<0002> gprs_gmm.c:921 -> GMM RA UPDATE REQUEST type="RA updating"  LLC XID
RESET  REJECT
<0002> gprs_gmm.c:860 <- ROUTING AREA UPDATE REJECT

then
<0002> gprs_gmm.c:640 -> GMM ATTACH REQUEST MI(xxxxxxx) type="GPRS attach"
<0002> gprs_gmm.c:444 <- GPRS IDENTITY REQUEST: mi_type=02
<0011> gprs_bssgp.c:753 BSSGP BVCI=2 Rx Flow Control BVC
<0011> gprs_bssgp.c:376 BSSGP TLLI=0xxxxxx Rx UPLINK-UNITDATA
<0012> gprs_llc.c:554 LLC SAPI=1 C   FCS=0xxxxx=UI DATA
<0002> gprs_gmm.c:582 -> GMM IDENTITY RESPONSE: mi_type=0x02 MI(xxxxxxxxx)
<0002> gprs_gmm.c:352 <- GPRS ATTACH ACCEPT (new P-TMSI=0xxxxxxx)
<0011> gprs_bssgp.c:376 BSSGP TLLI=0xxxxxx Rx UPLINK-UNITDATA
<0012> gprs_llc.c:554 LLC SAPI=1 C   FCS=0xxxxxxxx=UI DATA
<0002> gprs_gmm.c:1052 -> ATTACH COMPLETE

and then
<0002> gprs_gmm.c:1319 -> ACTIVATE PDP CONTEXT REQ: SAPI=3 NSAPI=5 IETF
IPv4
<000f> sgsn_libgtp.c:126 Create PDP Context
<000f> sgsn_libgtp.c:379 libgtp cb_conf(type=16, cause=128, pdp=0xxxxxxx,
cbp=0x1xxxxx)
<000f> sgsn_libgtp.c:265 Received CREATE PDP CTX CONF, cause=128(Request
accepted)
<0002> gprs_gmm.c:1197 <- ACTIVATE PDP CONTEXT ACK

finally
<0002> gprs_gmm.c:1432 -> DEACTIVATE PDP CONTEXT REQ (cause: Regular
deactivation)
<000f> sgsn_libgtp.c:212 Delete PDP Context
<000f> sgsn_libgtp.c:402 PDP Context was deleted
<000f> sgsn_libgtp.c:379 libgtp cb_conf(type=20, cause=128, pdp=(nil),
cbp=0xxxxxx)
<000f> sgsn_libgtp.c:321 Received DELETE PDP CTX CONF, cause=128(Request
accepted)
<0002> gprs_gmm.c:1290 <- DEACTIVATE PDP CONTEXT ACK


Am I getting PDP deactivation because of routing area reject.
Also noticed that  TLLI changes from Activate PDP context onwards. This
TLLI is based on TMSI/P-TMSI
Upto Attach complete procedure I have different TLLI.


For setup I have

BSC, SGSN on eth0 and eth0:1 respectively and
GGSN on eth1 ( I have external network adapter).

Can anybody suggest something why I am  getting pdp deactivation.

regards

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

From dwillmann at sysmocom.de  Wed Jun  4 12:56:09 2014
From: dwillmann at sysmocom.de (Daniel Willmann)
Date: Wed,  4 Jun 2014 14:56:09 +0200
Subject: [osmo-pcu 1/2] gprs_rlcmac_pdch: Don't access private member structs
Message-ID: <c96190177bfbb6094d4d0b27f7a3fe53f4070c9f.1401886570.git.daniel@totalueberwachung.de>

This patch introduces methods to get ul and dl tbf by tfi and uses them
in gprs_rlcmac_sched.
---
 src/bts.cpp               | 14 ++++++++++++++
 src/bts.h                 |  3 +++
 src/gprs_rlcmac_sched.cpp |  4 ++--
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/src/bts.cpp b/src/bts.cpp
index 9003099..b383546 100644
--- a/src/bts.cpp
+++ b/src/bts.cpp
@@ -990,3 +990,17 @@ int gprs_rlcmac_pdch::rcv_block(uint8_t *data, uint8_t len, uint32_t fn, int8_t
 
 	return rc;
 }
+
+struct gprs_rlcmac_tbf *gprs_rlcmac_pdch::ul_tbf_by_tfi(uint8_t tfi)
+{
+	if (tfi >= ARRAY_SIZE(this->ul_tbf))
+		return NULL;
+	return this->ul_tbf[tfi];
+}
+
+struct gprs_rlcmac_tbf *gprs_rlcmac_pdch::dl_tbf_by_tfi(uint8_t tfi)
+{
+	if (tfi >= ARRAY_SIZE(this->dl_tbf))
+		return NULL;
+	return this->dl_tbf[tfi];
+}
diff --git a/src/bts.h b/src/bts.h
index 128b1e0..578c63d 100644
--- a/src/bts.h
+++ b/src/bts.h
@@ -61,6 +61,9 @@ struct gprs_rlcmac_pdch {
 	gprs_rlcmac_bts *bts_data() const;
 	BTS *bts() const;
 	uint8_t trx_no() const;
+
+	struct gprs_rlcmac_tbf *ul_tbf_by_tfi(uint8_t tfi);
+	struct gprs_rlcmac_tbf *dl_tbf_by_tfi(uint8_t tfi);
 #endif
 
 	uint8_t m_is_enabled; /* TS is enabled */
diff --git a/src/gprs_rlcmac_sched.cpp b/src/gprs_rlcmac_sched.cpp
index 123e375..92e97ec 100644
--- a/src/gprs_rlcmac_sched.cpp
+++ b/src/gprs_rlcmac_sched.cpp
@@ -81,7 +81,7 @@ static uint8_t sched_select_uplink(uint8_t trx, uint8_t ts, uint32_t fn,
 	/* select uplink resource */
 	for (i = 0, tfi = pdch->next_ul_tfi; i < 32;
 	     i++, tfi = (tfi + 1) & 31) {
-		tbf = pdch->ul_tbf[tfi];
+		tbf = pdch->ul_tbf_by_tfi(tfi);
 		/* no TBF for this tfi, go next */
 		if (!tbf)
 			continue;
@@ -169,7 +169,7 @@ static struct msgb *sched_select_downlink(struct gprs_rlcmac_bts *bts,
 	/* select downlink resource */
 	for (i = 0, tfi = pdch->next_dl_tfi; i < 32;
 	     i++, tfi = (tfi + 1) & 31) {
-		tbf = pdch->dl_tbf[tfi];
+		tbf = pdch->dl_tbf_by_tfi(tfi);
 		/* no TBF for this tfi, go next */
 		if (!tbf)
 			continue;
-- 
1.8.4.2




From dwillmann at sysmocom.de  Wed Jun  4 12:56:10 2014
From: dwillmann at sysmocom.de (Daniel Willmann)
Date: Wed,  4 Jun 2014 14:56:10 +0200
Subject: [osmo-pcu 2/2] gprs_rlcmac_pdch: Get rid of ul/dl_tbf
In-Reply-To: <c96190177bfbb6094d4d0b27f7a3fe53f4070c9f.1401886570.git.daniel@totalueberwachung.de>
References: <c96190177bfbb6094d4d0b27f7a3fe53f4070c9f.1401886570.git.daniel@totalueberwachung.de>
Message-ID: <5ca01827caed51b54def2b7396c01e4a7737486c.1401886570.git.daniel@totalueberwachung.de>

The current code keeps a reference to all tbfs in the bts and another
reference in the pdch. This allows for the possibility of both lists to
go out of sync.

This patch removes the pdch-specific list of ul and dl tbfs and uses the
lists in the bts to lookup tbfs everywhere.
---
 src/bts.cpp                  | 21 +++++++++++++++------
 src/bts.h                    |  3 +--
 src/gprs_rlcmac_ts_alloc.cpp |  4 +---
 src/tbf.cpp                  | 17 ++++-------------
 4 files changed, 21 insertions(+), 24 deletions(-)

diff --git a/src/bts.cpp b/src/bts.cpp
index b383546..a9043bc 100644
--- a/src/bts.cpp
+++ b/src/bts.cpp
@@ -991,16 +991,25 @@ int gprs_rlcmac_pdch::rcv_block(uint8_t *data, uint8_t len, uint32_t fn, int8_t
 	return rc;
 }
 
+struct gprs_rlcmac_tbf *gprs_rlcmac_pdch::tbf_from_list_by_tfi(struct llist_head *tbf_list, uint8_t tfi)
+{
+	struct gprs_rlcmac_tbf *tbf;
+
+	llist_for_each_entry(tbf, tbf_list, list) {
+		if (tbf->tfi() != tfi)
+			continue;
+		if (!tbf->pdch[this->ts_no])
+			continue;
+		return tbf;
+	}
+	return NULL;
+}
 struct gprs_rlcmac_tbf *gprs_rlcmac_pdch::ul_tbf_by_tfi(uint8_t tfi)
 {
-	if (tfi >= ARRAY_SIZE(this->ul_tbf))
-		return NULL;
-	return this->ul_tbf[tfi];
+	return this->tbf_from_list_by_tfi(&bts_main_data()->ul_tbfs, tfi);
 }
 
 struct gprs_rlcmac_tbf *gprs_rlcmac_pdch::dl_tbf_by_tfi(uint8_t tfi)
 {
-	if (tfi >= ARRAY_SIZE(this->dl_tbf))
-		return NULL;
-	return this->dl_tbf[tfi];
+	return this->tbf_from_list_by_tfi(&bts_main_data()->dl_tbfs, tfi);
 }
diff --git a/src/bts.h b/src/bts.h
index 578c63d..e5acef3 100644
--- a/src/bts.h
+++ b/src/bts.h
@@ -71,8 +71,6 @@ struct gprs_rlcmac_pdch {
 	uint8_t next_ul_tfi; /* next uplink TBF/TFI to schedule (0..31) */
 	uint8_t next_dl_tfi; /* next downlink TBF/TFI to schedule (0..31) */
 	uint8_t next_ctrl_prio; /* next kind of ctrl message to schedule */
-	struct gprs_rlcmac_tbf *ul_tbf[32]; /* array of UL TBF, by UL TFI */
-	struct gprs_rlcmac_tbf *dl_tbf[32]; /* array of DL TBF, by DL TFI */
 	struct llist_head paging_list; /* list of paging messages */
 	uint32_t last_rts_fn; /* store last frame number of RTS */
 
@@ -89,6 +87,7 @@ private:
 	void rcv_control_dl_ack_nack(Packet_Downlink_Ack_Nack_t *, uint32_t fn);
 	void rcv_resource_request(Packet_Resource_Request_t *t, uint32_t fn);
 	void rcv_measurement_report(Packet_Measurement_Report_t *t, uint32_t fn);
+	struct gprs_rlcmac_tbf *tbf_from_list_by_tfi(struct llist_head *tbf_list, uint8_t tfi);
 #endif
 };
 
diff --git a/src/gprs_rlcmac_ts_alloc.cpp b/src/gprs_rlcmac_ts_alloc.cpp
index 13fc636..b070c2e 100644
--- a/src/gprs_rlcmac_ts_alloc.cpp
+++ b/src/gprs_rlcmac_ts_alloc.cpp
@@ -83,7 +83,7 @@ static inline int8_t find_free_usf(struct gprs_rlcmac_pdch *pdch)
 
 	/* make map of used USF */
 	for (tfi = 0; tfi < 32; tfi++) {
-		tbf = pdch->ul_tbf[tfi];
+		tbf = pdch->ul_tbf_by_tfi(tfi);
 		if (!tbf)
 			continue;
 		usf_map |= (1 << tbf->dir.ul.usf[pdch->ts_no]);
@@ -121,7 +121,6 @@ static void assign_uplink_tbf_usf(
 				struct gprs_rlcmac_tbf *tbf, int8_t usf)
 {
 	tbf->trx->ul_tbf[tbf->tfi()] = tbf;
-	pdch->ul_tbf[tbf->tfi()] = tbf;
 	tbf->pdch[pdch->ts_no] = pdch;
 	tbf->dir.ul.usf[pdch->ts_no] = usf;
 }
@@ -131,7 +130,6 @@ static void assign_dlink_tbf(
 				struct gprs_rlcmac_tbf *tbf)
 {
 	tbf->trx->dl_tbf[tbf->tfi()] = tbf;
-	pdch->dl_tbf[tbf->tfi()] = tbf;
 	tbf->pdch[pdch->ts_no] = pdch;
 }
 
diff --git a/src/tbf.cpp b/src/tbf.cpp
index 3a2ad73..5943674 100644
--- a/src/tbf.cpp
+++ b/src/tbf.cpp
@@ -250,25 +250,16 @@ struct gprs_rlcmac_tbf *tbf_alloc_ul(struct gprs_rlcmac_bts *bts,
 
 static void tbf_unlink_pdch(struct gprs_rlcmac_tbf *tbf)
 {
-	struct gprs_rlcmac_pdch *pdch;
 	int ts;
 
 	if (tbf->direction == GPRS_RLCMAC_UL_TBF) {
 		tbf->trx->ul_tbf[tbf->tfi()] = NULL;
-		for (ts = 0; ts < 8; ts++) {
-			pdch = tbf->pdch[ts];
-			if (pdch)
-				pdch->ul_tbf[tbf->tfi()] = NULL;
+		for (ts = 0; ts < 8; ts++)
 			tbf->pdch[ts] = NULL;
-		}
 	} else {
 		tbf->trx->dl_tbf[tbf->tfi()] = NULL;
-		for (ts = 0; ts < 8; ts++) {
-			pdch = tbf->pdch[ts];
-			if (pdch)
-				pdch->dl_tbf[tbf->tfi()] = NULL;
+		for (ts = 0; ts < 8; ts++)
 			tbf->pdch[ts] = NULL;
-		}
 	}
 }
 
@@ -1472,10 +1463,10 @@ void gprs_rlcmac_tbf::free_all(struct gprs_rlcmac_pdch *pdch)
 	for (uint8_t tfi = 0; tfi < 32; tfi++) {
 		struct gprs_rlcmac_tbf *tbf;
 
-		tbf = pdch->ul_tbf[tfi];
+		tbf = pdch->ul_tbf_by_tfi(tfi);
 		if (tbf)
 			tbf_free(tbf);
-		tbf = pdch->dl_tbf[tfi];
+		tbf = pdch->dl_tbf_by_tfi(tfi);
 		if (tbf)
 			tbf_free(tbf);
 	}
-- 
1.8.4.2




From mailman at lists.osmocom.org  Wed Jun  4 13:04:19 2014
From: mailman at lists.osmocom.org (mailman at lists.osmocom.org)
Date: Wed, 04 Jun 2014 15:04:19 +0200
Subject: Bounce action notification
Message-ID: <mailman.1122.1401887059.1438.openbsc@lists.osmocom.org>

This is a Mailman mailing list bounce action notice:

    List:       OpenBSC
    Member:     osmocom at ninoc.nl
    Action:     Subscription disabled.
    Reason:     Excessive or fatal bounces.
    


The triggering bounce notice is attached below.

Questions? Contact the Mailman site administrator at
mailman at lists.osmocom.org.
-------------- next part --------------
An embedded message was scrubbed...
From: Mail Delivery System <Mailer-Daemon at ganesha.gnumonks.org>
Subject: Mail delivery failed: returning message to sender
Date: Wed, 04 Jun 2014 15:04:16 +0200
Size: 5068
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140604/307e41f4/attachment.eml>

From dwillmann at sysmocom.de  Wed Jun  4 13:21:09 2014
From: dwillmann at sysmocom.de (Daniel Willmann)
Date: Wed,  4 Jun 2014 15:21:09 +0200
Subject: [osmo-pcu 1/1] csn1: Add spaces between string literal and identifier
Message-ID: <02896a5449f90ee651e3c0efe81765680aa6b877.1401888069.git.daniel@totalueberwachung.de>

This is required by C++11

csn1.cpp:1147:44: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal]
LOGPC(DCSN1, LOGL_NOTICE, "%"PRIu64"|", bitvec_read_field(vector, readIndex, bits_to_handle));
---
 src/csn1.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/csn1.cpp b/src/csn1.cpp
index 258f7c9..377c50f 100644
--- a/src/csn1.cpp
+++ b/src/csn1.cpp
@@ -1144,13 +1144,13 @@ csnStreamDecoder(csnStream_t* ar, const CSN_DESCR* pDescr, bitvec *vector, unsig
             guint8 bits_to_handle = remaining_bits_len%8;
             if (bits_to_handle > 0)
             {
-              LOGPC(DCSN1, LOGL_NOTICE, "%"PRIu64"|", bitvec_read_field(vector, readIndex, bits_to_handle));
+              LOGPC(DCSN1, LOGL_NOTICE, "%" PRIu64 "|", bitvec_read_field(vector, readIndex, bits_to_handle));
               remaining_bits_len -= bits_to_handle;
               bit_offset += bits_to_handle;
             }
             else if (bits_to_handle == 0)
             {
-              LOGPC(DCSN1, LOGL_NOTICE, "%"PRIu64"|", bitvec_read_field(vector, readIndex, 8));
+              LOGPC(DCSN1, LOGL_NOTICE, "%" PRIu64 "|", bitvec_read_field(vector, readIndex, 8));
               remaining_bits_len -= 8;
               bit_offset += 8;
             }
-- 
1.8.4.2




From Max.Suraev at fairwaves.co  Wed Jun  4 16:21:54 2014
From: Max.Suraev at fairwaves.co (Max Suraev)
Date: Wed,  4 Jun 2014 18:21:54 +0200
Subject: [PATCH] use osmocom auth API instead of direct calls
Message-ID: <1401898914-23556-1-git-send-email-Max.Suraev@fairwaves.co>

---
 openbsc/src/libmsc/auth.c | 68 +++++++++++++++++++----------------------------
 1 file changed, 28 insertions(+), 40 deletions(-)

diff --git a/openbsc/src/libmsc/auth.c b/openbsc/src/libmsc/auth.c
index 10d8edf..ab84975 100644
--- a/openbsc/src/libmsc/auth.c
+++ b/openbsc/src/libmsc/auth.c
@@ -25,46 +25,11 @@
 #include <openbsc/auth.h>
 #include <openbsc/gsm_data.h>
 
-#include <osmocom/gsm/comp128.h>
+#include <osmocom/crypt/auth.h>
 
 #include <stdlib.h>
 
 
-static int
-_use_xor(struct gsm_auth_info *ainfo, struct gsm_auth_tuple *atuple)
-{
-	int i, l = ainfo->a3a8_ki_len;
-
-	if ((l > A38_XOR_MAX_KEY_LEN) || (l < A38_XOR_MIN_KEY_LEN)) {
-		LOGP(DMM, LOGL_ERROR, "Invalid XOR key (len=%d) %s\n",
-			ainfo->a3a8_ki_len,
-			osmo_hexdump(ainfo->a3a8_ki, ainfo->a3a8_ki_len));
-		return -1;
-	}
-
-	for (i=0; i<4; i++)
-		atuple->sres[i] = atuple->rand[i] ^ ainfo->a3a8_ki[i];
-	for (i=4; i<12; i++)
-		atuple->kc[i-4] = atuple->rand[i] ^ ainfo->a3a8_ki[i];
-
-	return 0;
-}
-
-static int
-_use_comp128_v1(struct gsm_auth_info *ainfo, struct gsm_auth_tuple *atuple)
-{
-	if (ainfo->a3a8_ki_len != A38_COMP128_KEY_LEN) {
-		LOGP(DMM, LOGL_ERROR, "Invalid COMP128v1 key (len=%d) %s\n",
-			ainfo->a3a8_ki_len,
-			osmo_hexdump(ainfo->a3a8_ki, ainfo->a3a8_ki_len));
-		return -1;
-	}
-
-	comp128(ainfo->a3a8_ki, atuple->rand, atuple->sres, atuple->kc);
-
-	return 0;
-}
-
 /* Return values 
  *  -1 -> Internal error
  *   0 -> Not available
@@ -76,6 +41,11 @@ int auth_get_tuple_for_subscr(struct gsm_auth_tuple *atuple,
 {
 	struct gsm_auth_info ainfo;
 	int i, rc;
+	static struct osmo_sub_auth_data auth = {
+	    .type = OSMO_AUTH_TYPE_GSM
+	};
+	struct osmo_auth_vector _vec;
+	struct osmo_auth_vector *vec = &_vec;
 
 	/* Get subscriber info (if any) */
 	rc = db_get_authinfo_for_subscr(&ainfo, subscr);
@@ -109,13 +79,23 @@ int auth_get_tuple_for_subscr(struct gsm_auth_tuple *atuple,
 		return 0;
 
 	case AUTH_ALGO_XOR:
-		if (_use_xor(&ainfo, atuple))
-			return 0;
+		auth.algo = OSMO_AUTH_ALG_XOR;
+		if ((ainfo.a3a8_ki_len > A38_XOR_MAX_KEY_LEN) || (ainfo.a3a8_ki_len < A38_XOR_MIN_KEY_LEN)) {
+			LOGP(DMM, LOGL_ERROR, "Invalid XOR key (len=%d) %s\n",
+			     ainfo.a3a8_ki_len,
+			     osmo_hexdump(ainfo.a3a8_ki, ainfo.a3a8_ki_len));
+			return -1;
+		}
 		break;
 
 	case AUTH_ALGO_COMP128v1:
-		if (_use_comp128_v1(&ainfo, atuple))
-			return 0;
+		auth.algo = OSMO_AUTH_ALG_COMP128v1;
+		if (ainfo.a3a8_ki_len != A38_COMP128_KEY_LEN) {
+			LOGP(DMM, LOGL_ERROR, "Invalid COMP128v1 key (len=%d) %s\n",
+			     ainfo.a3a8_ki_len,
+			     osmo_hexdump(ainfo.a3a8_ki, ainfo.a3a8_ki_len));
+			return -1;
+		}
 		break;
 
 	default:
@@ -124,6 +104,14 @@ int auth_get_tuple_for_subscr(struct gsm_auth_tuple *atuple,
 		return 0;
 	}
 
+	memcpy(auth.u.gsm.ki, ainfo.a3a8_ki, sizeof(auth.u.gsm.ki));
+
+	if (osmo_auth_gen_vec(vec, &auth, atuple->rand) < 0)
+		return -1;
+
+	memcpy(atuple->sres, vec->sres, 4);
+	memcpy(atuple->kc, vec->kc, 8);
+
         db_sync_lastauthtuple_for_subscr(atuple, subscr);
 
 	DEBUGP(DMM, "Need to do authentication and ciphering\n");
-- 
1.9.1




From Max.Suraev at fairwaves.co  Fri Jun  6 13:36:45 2014
From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=)
Date: Fri, 06 Jun 2014 15:36:45 +0200
Subject: [PATCH] use osmocom auth API instead of direct calls
In-Reply-To: <1401898914-23556-1-git-send-email-Max.Suraev@fairwaves.co>
References: <1401898914-23556-1-git-send-email-Max.Suraev@fairwaves.co>
Message-ID: <5391C3ED.3010608@fairwaves.co>

This patch switches away from directly calling COMP128 to using generic osmocom
authentication API. The idea is that bypassing auth API will be deprecated in future
versions of libosmocore. Using generic API will allow us to trivially introduce
support for other algorithms like COMP128v23 for example.

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



From daniel at totalueberwachung.de  Wed Jun  4 16:30:59 2014
From: daniel at totalueberwachung.de (Daniel Willmann)
Date: Wed,  4 Jun 2014 18:30:59 +0200
Subject: [osmo-pcu 1/1] Always exit and don't try to recover
Message-ID: <650b5f749cdd4f1fa49db282380a5ca8ebfb9818.1401899459.git.daniel@totalueberwachung.de>

From: Daniel Willmann <dwillmann at sysmocom.de>

The current code tries to recover from dropped connections and resets the
pcu state so it can keep running. However, this never worked correctly
which is why the -e option is used. This option exits the pcu as soon as
the internal state needs to be reset.

This patch removes this option and makes this behaviour default.

Ticket: SYS#390
Sponsored-by: On-Waves ehf
---
 src/gprs_bssgp_pcu.cpp | 13 +------------
 src/gprs_bssgp_pcu.h   |  4 +---
 src/openbts_sock.cpp   |  4 +++-
 src/pcu_l1_if.cpp      |  4 ++--
 src/pcu_main.cpp       |  3 +--
 src/sysmo_sock.cpp     |  8 ++------
 6 files changed, 10 insertions(+), 26 deletions(-)

diff --git a/src/gprs_bssgp_pcu.cpp b/src/gprs_bssgp_pcu.cpp
index 133eb97..6c5d72c 100644
--- a/src/gprs_bssgp_pcu.cpp
+++ b/src/gprs_bssgp_pcu.cpp
@@ -533,13 +533,8 @@ struct gprs_bssgp_pcu *gprs_bssgp_create_and_connect(struct gprs_rlcmac_bts *bts
 	return &the_pcu;
 }
 
-void gprs_bssgp_destroy_or_exit(void)
+void gprs_bssgp_destroy(void)
 {
-	if (the_pcu.exit_on_destroy) {
-		LOGP(DBSSGP, LOGL_NOTICE, "Exiting on BSSGP destruction.\n");
-		exit(0);
-	}
-
 	if (!bssgp_nsi)
 		return;
 
@@ -564,12 +559,6 @@ void gprs_bssgp_destroy_or_exit(void)
 	bssgp_nsi = NULL;
 }
 
-void gprs_bssgp_exit_on_destroy(void)
-{
-	LOGP(DBSSGP, LOGL_NOTICE, "Going to quit on BSSGP destruction\n");
-	the_pcu.exit_on_destroy = 1;
-}
-
 struct bssgp_bvc_ctx *gprs_bssgp_pcu_current_bctx(void)
 {
 	return the_pcu.bctx;
diff --git a/src/gprs_bssgp_pcu.h b/src/gprs_bssgp_pcu.h
index aedcfc0..32b6728 100644
--- a/src/gprs_bssgp_pcu.h
+++ b/src/gprs_bssgp_pcu.h
@@ -57,7 +57,6 @@ struct gprs_bssgp_pcu {
 	int bvc_sig_reset;
 	int bvc_reset;
 	int bvc_unblocked;
-	int exit_on_destroy;
 
 	/** callbacks below */
 
@@ -75,8 +74,7 @@ struct gprs_bssgp_pcu *gprs_bssgp_create_and_connect(struct gprs_rlcmac_bts *bts
 		uint16_t nsvci, uint16_t bvci, uint16_t mcc, uint16_t mnc,
 		uint16_t lac, uint16_t rac, uint16_t cell_id);
 
-void gprs_bssgp_exit_on_destroy(void);
-void gprs_bssgp_destroy_or_exit(void);
+void gprs_bssgp_destroy(void);
 
 struct bssgp_bvc_ctx *gprs_bssgp_pcu_current_bctx(void);
 
diff --git a/src/openbts_sock.cpp b/src/openbts_sock.cpp
index a09f834..2d9cae4 100644
--- a/src/openbts_sock.cpp
+++ b/src/openbts_sock.cpp
@@ -179,8 +179,10 @@ int pcu_l1if_open()
 
 void pcu_l1if_close(void)
 {
-	gprs_bssgp_destroy_or_exit();
+	gprs_bssgp_destroy();
 
 	/* FIXME: cleanup l1if */
 	talloc_free(l1fh->fl1h);
+
+	exit(0);
 }
diff --git a/src/pcu_l1_if.cpp b/src/pcu_l1_if.cpp
index ce13b96..0cb79eb 100644
--- a/src/pcu_l1_if.cpp
+++ b/src/pcu_l1_if.cpp
@@ -324,8 +324,8 @@ bssgp_failed:
 			for (ts = 0; ts < 8; ts++)
 				bts->trx[trx].pdch[ts].free_resources();
 		}
-		gprs_bssgp_destroy_or_exit();
-		return 0;
+		gprs_bssgp_destroy();
+		exit(0);
 	}
 	LOGP(DL1IF, LOGL_INFO, "BTS available\n");
 	LOGP(DL1IF, LOGL_DEBUG, " mcc=%x\n", info_ind->mcc);
diff --git a/src/pcu_main.cpp b/src/pcu_main.cpp
index c0dac14..8631ad3 100644
--- a/src/pcu_main.cpp
+++ b/src/pcu_main.cpp
@@ -56,7 +56,6 @@ static void print_help()
 			"provided by BTS\n"
 		"  -r   --realtime PRIO Use SCHED_RR with the specified "
 			"priority\n"
-		"  -e   --exit		Exit the application on disconnect\n"
 		);
 }
 
@@ -105,7 +104,7 @@ static void handle_options(int argc, char **argv)
 			rt_prio = atoi(optarg);
 			break;
 		case 'e':
-			gprs_bssgp_exit_on_destroy();
+			fprintf(stderr, "Warning: Option '-e' is deprecated!\n");
 			break;
 		default:
 			fprintf(stderr, "Unknown option '%c'\n", c);
diff --git a/src/sysmo_sock.cpp b/src/sysmo_sock.cpp
index 2e2d9d3..951653e 100644
--- a/src/sysmo_sock.cpp
+++ b/src/sysmo_sock.cpp
@@ -112,12 +112,8 @@ static void pcu_sock_close(struct pcu_sock_state *state, int lost)
 		gprs_rlcmac_tbf::free_all(&bts->trx[trx]);
 	}
 
-	gprs_bssgp_destroy_or_exit();
-
-	if (lost) {
-		state->timer.cb = pcu_sock_timeout;
-		osmo_timer_schedule(&state->timer, 5, 0);
-	}
+	gprs_bssgp_destroy();
+	exit(0);
 }
 
 static int pcu_sock_read(struct osmo_fd *bfd)
-- 
1.8.4.2




From dwillmann at sysmocom.de  Wed Jun  4 16:54:18 2014
From: dwillmann at sysmocom.de (Daniel Willmann)
Date: Wed,  4 Jun 2014 18:54:18 +0200
Subject: [osmo-pcu 1/1] bts: Remove outdated comment
Message-ID: <acb1a5db7f6fbb1a3485a61c9d844fc19a61ea60.1401900858.git.daniel@totalueberwachung.de>

There is no parameter in the function and the bts has a memeber trx
which has a member pdch.

Sponsored-by: On-Waves ehf
---
 src/bts.cpp | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/bts.cpp b/src/bts.cpp
index 9de6dc3..3dd5705 100644
--- a/src/bts.cpp
+++ b/src/bts.cpp
@@ -532,7 +532,6 @@ void gprs_rlcmac_pdch::disable()
 	m_is_enabled = 0;
 }
 
-/* TODO: kill the parameter and make a pdch belong to a trx.. to a bts.. */
 void gprs_rlcmac_pdch::free_resources()
 {
 	struct gprs_rlcmac_paging *pag;
-- 
1.8.4.2




From jerlbeck at sysmocom.de  Thu Jun 12 10:28:12 2014
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Thu, 12 Jun 2014 12:28:12 +0200
Subject: [PATCH] mgcp/test: Add test case using the fmtp_extra info
Message-ID: <1402568892-8750-1-git-send-email-jerlbeck@sysmocom.de>

Add tests setting the fmtp_extra field to check the response
generation. This triggers a bug found by Coverity.

Addresses: Coverity CID 1220873
Sponsored-by: On-Waves ehf
---
 openbsc/tests/mgcp/mgcp_test.c  | 31 +++++++++++++++++++++++++++++++
 openbsc/tests/mgcp/mgcp_test.ok | 38 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 69 insertions(+)

diff --git a/openbsc/tests/mgcp/mgcp_test.c b/openbsc/tests/mgcp/mgcp_test.c
index 19615d9..e185fbc 100644
--- a/openbsc/tests/mgcp/mgcp_test.c
+++ b/openbsc/tests/mgcp/mgcp_test.c
@@ -20,6 +20,7 @@
 #define _GNU_SOURCE
 
 #include <openbsc/mgcp.h>
+#include <openbsc/vty.h>
 #include <openbsc/mgcp_internal.h>
 
 #include <osmocom/core/application.h>
@@ -88,6 +89,17 @@ static void test_strline(void)
 		 "m=audio 0 RTP/AVP 126\r\n"	\
 		 "a=rtpmap:126 AMR/8000\r\n"	\
 		 "a=ptime:20\r\n"
+#define MDCX3_FMTP_RET "200 18983215 OK\r\n"		\
+		 "I: 3\n"			\
+		 "\n"				\
+		 "v=0\r\n"			\
+		 "o=- 3 23 IN IP4 0.0.0.0\r\n"	\
+		 "c=IN IP4 0.0.0.0\r\n"		\
+		 "t=0 0\r\n"			\
+		 "m=audio 0 RTP/AVP 126\r\n"	\
+		 "a=rtpmap:126 AMR/8000\r\n"	\
+		 "a=fmtp:126 0/1/2\r\n"		\
+		 "a=ptime:20\r\n"
 #define MDCX4 "MDCX 18983216 1 at mgw MGCP 1.0\r\n" \
 		 "M: sendrecv\r"		\
 		 "C: 2\r\n"          \
@@ -203,6 +215,18 @@ static void test_strline(void)
 		 "a=rtpmap:126 AMR/8000\r\n"	\
 		 "a=ptime:20\r\n"
 
+#define CRCX_FMTP_RET "200 2 OK\r\n"			\
+		 "I: 3\n"			\
+		 "\n"				\
+		 "v=0\r\n"			\
+		 "o=- 3 23 IN IP4 0.0.0.0\r\n"	\
+		 "c=IN IP4 0.0.0.0\r\n"		\
+		 "t=0 0\r\n"			\
+		 "m=audio 0 RTP/AVP 126\r\n"	\
+		 "a=rtpmap:126 AMR/8000\r\n"	\
+		 "a=fmtp:126 0/1/2\r\n"		\
+		 "a=ptime:20\r\n"
+
 #define CRCX_ZYN "CRCX 2 1 at mgw MGCP 1.0\r"	\
 		 "M: recvonly\r"		\
 		 "C: 2\r\r"			\
@@ -250,6 +274,8 @@ struct mgcp_test {
 	const char *exp_resp;
 	int exp_net_ptype;
 	int exp_bts_ptype;
+
+	char *extra_fmtp;
 };
 
 static const struct mgcp_test tests[] = {
@@ -275,6 +301,9 @@ static const struct mgcp_test tests[] = {
 	{ "RQNT1", RQNT, RQNT1_RET },
 	{ "RQNT2", RQNT2, RQNT2_RET },
 	{ "DLCX", DLCX, DLCX_RET, -1, -1 },
+	{ "CRCX", CRCX, CRCX_FMTP_RET, 97, 126, .extra_fmtp = "a=fmtp:126 0/1/2" },
+	{ "MDCX3", MDCX3, MDCX3_FMTP_RET, PTYPE_NONE, 126 , .extra_fmtp = "a=fmtp:126 0/1/2" },
+	{ "DLCX", DLCX, DLCX_RET, -1, -1 , .extra_fmtp = "a=fmtp:126 0/1/2" },
 };
 
 static const struct mgcp_test retransmit[] = {
@@ -398,6 +427,8 @@ static void test_messages(void)
 		last_endpoint = -1;
 		dummy_packets = 0;
 
+		bsc_replace_string(cfg, &cfg->trunk.audio_fmtp_extra, t->extra_fmtp);
+
 		inp = create_msg(t->req);
 		msg = mgcp_handle_message(cfg, inp);
 		msgb_free(inp);
diff --git a/openbsc/tests/mgcp/mgcp_test.ok b/openbsc/tests/mgcp/mgcp_test.ok
index 7301a81..6c5a6bc 100644
--- a/openbsc/tests/mgcp/mgcp_test.ok
+++ b/openbsc/tests/mgcp/mgcp_test.ok
@@ -75,6 +75,44 @@ Detected packet duration: 20
 Requested packetization period not set
 Connection mode: 0: NONE
 Testing CRCX
+CRCX failed '200 2 OK
+I: 3
+
+v=0
+o=- 3 23 IN IP4 0.0.0.0
+c=IN IP4 0.0.0.0
+t=0 0
+m=audio 0 RTP/AVP 126
+a=rtpmap:126 AMR/8000
+a=rtpmap:126 AMR/8000
+a=ptime:20
+'
+Dummy packets: 1
+Detected packet duration: 40
+Requested packetetization period: 20-20
+Connection mode: 1: RECV
+Testing MDCX3
+MDCX3 failed '200 18983215 OK
+I: 3
+
+v=0
+o=- 3 23 IN IP4 0.0.0.0
+c=IN IP4 0.0.0.0
+t=0 0
+m=audio 0 RTP/AVP 126
+a=rtpmap:126 AMR/8000
+a=rtpmap:126 AMR/8000
+a=ptime:20
+'
+Dummy packets: 1
+Packet duration not set
+Requested packetization period not set
+Connection mode not set
+Testing DLCX
+Detected packet duration: 20
+Requested packetization period not set
+Connection mode: 0: NONE
+Testing CRCX
 Re-transmitting CRCX
 Testing RQNT1
 Re-transmitting RQNT1
-- 
1.9.1




From holger at freyther.de  Sun Jun 15 17:14:04 2014
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 15 Jun 2014 19:14:04 +0200
Subject: [PATCH] mgcp/test: Add test case using the fmtp_extra info
In-Reply-To: <1402568892-8750-1-git-send-email-jerlbeck@sysmocom.de>
References: <1402568892-8750-1-git-send-email-jerlbeck@sysmocom.de>
Message-ID: <20140615171404.GJ5748@xiaoyu.lan>

On Thu, Jun 12, 2014 at 12:28:12PM +0200, Jacob Erlbeck wrote:

> +	char *extra_fmtp;

I made this const.

> +CRCX failed '200 2 OK

too bad, somewhere between your system, patchwork, git am
the \r\n got turned into a \n. :}




From jerlbeck at sysmocom.de  Thu Jun 12 10:42:38 2014
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Thu, 12 Jun 2014 12:42:38 +0200
Subject: [PATCH] mgcp: Fix SDP formatting of fmtp_extra (Coverity)
Message-ID: <1402569758-8960-1-git-send-email-jerlbeck@sysmocom.de>

Currently when ftmp_extra is set, a doubled a=rtpmap line is emitted
instead of the fmtp_extra info.

This patch fixes replaces the formerly copied and pasted but not
modified snprintf parameters by the correct ones.

Fixes: Coverity CID 1220873
Sponsored-by: On-Waves ehf
---
 openbsc/src/libmgcp/mgcp_protocol.c |  3 +--
 openbsc/tests/mgcp/mgcp_test.ok     | 24 ------------------------
 2 files changed, 1 insertion(+), 26 deletions(-)

diff --git a/openbsc/src/libmgcp/mgcp_protocol.c b/openbsc/src/libmgcp/mgcp_protocol.c
index f0457d1..6e48949 100644
--- a/openbsc/src/libmgcp/mgcp_protocol.c
+++ b/openbsc/src/libmgcp/mgcp_protocol.c
@@ -287,8 +287,7 @@ static int write_response_sdp(struct mgcp_endpoint *endp,
 
 		if (fmtp_extra) {
 			nchars = snprintf(sdp_record + len, size - len,
-					  "a=rtpmap:%d %s\r\n",
-					  payload_type, audio_name);
+					  "%s\r\n", fmtp_extra);
 
 			if (nchars < 0 || nchars >= size - len)
 				goto buffer_too_small;
diff --git a/openbsc/tests/mgcp/mgcp_test.ok b/openbsc/tests/mgcp/mgcp_test.ok
index 6c5a6bc..033f783 100644
--- a/openbsc/tests/mgcp/mgcp_test.ok
+++ b/openbsc/tests/mgcp/mgcp_test.ok
@@ -75,35 +75,11 @@ Detected packet duration: 20
 Requested packetization period not set
 Connection mode: 0: NONE
 Testing CRCX
-CRCX failed '200 2 OK
-I: 3
-
-v=0
-o=- 3 23 IN IP4 0.0.0.0
-c=IN IP4 0.0.0.0
-t=0 0
-m=audio 0 RTP/AVP 126
-a=rtpmap:126 AMR/8000
-a=rtpmap:126 AMR/8000
-a=ptime:20
-'
 Dummy packets: 1
 Detected packet duration: 40
 Requested packetetization period: 20-20
 Connection mode: 1: RECV
 Testing MDCX3
-MDCX3 failed '200 18983215 OK
-I: 3
-
-v=0
-o=- 3 23 IN IP4 0.0.0.0
-c=IN IP4 0.0.0.0
-t=0 0
-m=audio 0 RTP/AVP 126
-a=rtpmap:126 AMR/8000
-a=rtpmap:126 AMR/8000
-a=ptime:20
-'
 Dummy packets: 1
 Packet duration not set
 Requested packetization period not set
-- 
1.9.1




From joshtoal17 at gmail.com  Thu Jun 12 19:24:38 2014
From: joshtoal17 at gmail.com (Josh toal)
Date: Thu, 12 Jun 2014 15:24:38 -0400
Subject: XID parameters
Message-ID: <CADXvYi6yKTi0GY=n=Gx65u4vmChKNWUcW2PoFwJcgFOGzd7ENg@mail.gmail.com>

Hi All

As per the specs after PDP context accept mobile station should exchange
XID parameters with SGSN. before it initiate transfer of data.

As per the literature mobile station if not happy with the negotiated
quality of service it will send the deactivation request and I am getting
the same.

Is this is the only reason mobile station will send deactivation request or
something else, which I am missing.

Any suggestion to fix this problem.

can anybody comment on this please.

regards
Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140612/f4d97872/attachment.htm>

From rp.labs at gmx.ch  Thu Jun 12 20:18:10 2014
From: rp.labs at gmx.ch (Labs)
Date: Thu, 12 Jun 2014 22:18:10 +0200
Subject: XID parameters
In-Reply-To: <CADXvYi6yKTi0GY=n=Gx65u4vmChKNWUcW2PoFwJcgFOGzd7ENg@mail.gmail.com>
References: <CADXvYi6yKTi0GY=n=Gx65u4vmChKNWUcW2PoFwJcgFOGzd7ENg@mail.gmail.com>
Message-ID: <4484A666-7218-43B7-88F0-9F79923C96C4@gmx.ch>

Hello,

I think there is a confusion here.

The MS if it is not happy with the QoS will send a PDP modification request to change it or to change the traffic flow template. This can also be initiated by the network.

A PDP context deactivation is used for deleting/removing a PDP context. There are 3 cases when this can happen and can also be initiated by MS or the network:
a) GPRS detach
b) remove subscriber data
c) application deactivation

Maybe someone else can explain it better.

Regards,
R.

Sent from my iPad

> On Jun 12, 2014, at 21:24, Josh toal <joshtoal17 at gmail.com> wrote:
> 
> Hi All
> 
> As per the specs after PDP context accept mobile station should exchange XID parameters with SGSN. before it initiate transfer of data.
> 
> As per the literature mobile station if not happy with the negotiated quality of service it will send the deactivation request and I am getting the same.
> 
> Is this is the only reason mobile station will send deactivation request or something else, which I am missing.
> 
> Any suggestion to fix this problem.
> 
> can anybody comment on this please.
> 
> regards
> Josh
> 
> 
> 



From joshtoal17 at gmail.com  Fri Jun 13 16:54:16 2014
From: joshtoal17 at gmail.com (Josh toal)
Date: Fri, 13 Jun 2014 12:54:16 -0400
Subject: XID parameters
In-Reply-To: <4484A666-7218-43B7-88F0-9F79923C96C4@gmx.ch>
References: <CADXvYi6yKTi0GY=n=Gx65u4vmChKNWUcW2PoFwJcgFOGzd7ENg@mail.gmail.com>
	<4484A666-7218-43B7-88F0-9F79923C96C4@gmx.ch>
Message-ID: <CADXvYi5YXSf9K4gacSY9w2ZZXzmMCs0vvHDbajVmNb=mGSdx7Q@mail.gmail.com>

Hi

regarding qos I have seen in a book title "GPRS in practice a companion to
the specifications"

In chapter 11 it says " If the network layer does not like the allocated
QoS profile, it can terminate the session",, may be you are right.

I am not able to understand why after MS doing pdp activation accept  it
deactivate the pdp context.

Can somebody point out some potential reasons.

regards
Josh













On Thu, Jun 12, 2014 at 4:18 PM, Labs <rp.labs at gmx.ch> wrote:

> Hello,
>
> I think there is a confusion here.
>
> The MS if it is not happy with the QoS will send a PDP modification
> request to change it or to change the traffic flow template. This can also
> be initiated by the network.
>
> A PDP context deactivation is used for deleting/removing a PDP context.
> There are 3 cases when this can happen and can also be initiated by MS or
> the network:
> a) GPRS detach
> b) remove subscriber data
> c) application deactivation
>
> Maybe someone else can explain it better.
>
> Regards,
> R.
>
> Sent from my iPad
>
> > On Jun 12, 2014, at 21:24, Josh toal <joshtoal17 at gmail.com> wrote:
> >
> > Hi All
> >
> > As per the specs after PDP context accept mobile station should exchange
> XID parameters with SGSN. before it initiate transfer of data.
> >
> > As per the literature mobile station if not happy with the negotiated
> quality of service it will send the deactivation request and I am getting
> the same.
> >
> > Is this is the only reason mobile station will send deactivation request
> or something else, which I am missing.
> >
> > Any suggestion to fix this problem.
> >
> > can anybody comment on this please.
> >
> > regards
> > Josh
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140613/0966996a/attachment.htm>

From hulds at gmx.net  Tue Jun 17 17:13:05 2014
From: hulds at gmx.net (hulds at gmx.net)
Date: Tue, 17 Jun 2014 19:13:05 +0200
Subject: Unable to build openbsc due to missing 'libosmo-netif' package
Message-ID: <53A07721.4090801@gmx.net>

Hi,

i try to get openbsc to work. To do that i followed the steps on the page :
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS

till the last step everything go's ok, during the last step :

cd /root/openbsc/openbsc; autoreconf -fi; export
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig; ./configure; make

I get the message :
checking for LIBOSMONETIF... no
configure: error: Package requirements (libosmo-netif >= 0.0.1) were not
met:

No package 'libosmo-netif' found

I tried to find this package but was not able to find it.
Do you know where i can find this package so that i can get things working ?

Regards
Henry




From ciaby at autistici.org  Tue Jun 17 18:51:33 2014
From: ciaby at autistici.org (Ciaby)
Date: Tue, 17 Jun 2014 13:51:33 -0500
Subject: Unable to build openbsc due to missing 'libosmo-netif' package
In-Reply-To: <53A07721.4090801@gmx.net>
References: <53A07721.4090801@gmx.net>
Message-ID: <53A08E35.2070707@autistici.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 06/17/2014 12:13 PM, hulds at gmx.net wrote:
[...]
> I tried to find this package but was not able to find it. Do you
> know where i can find this package so that i can get things working
> ?
It's part of the Osmocom git repositories:
http://cgit.osmocom.org/libosmo-netif/

Something like this should work:
git clone git://git.osmocom.org/libosmo-netif
cd libosmo-netif
autoreconf -i
./configure
make
sudo make install

Cheers

Ciaby

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREKAAYFAlOgjjAACgkQC30ZhxNccpEg2AD9HhIFq3L2OgjEDJ5WvXNaP+lQ
Q2TeY7yXBJiPKIsgZ8cA+wSQ9RJ+zGCyFGv280i5ClLbYwXwDvasbbuF5zv8Y/O+
=yxET
-----END PGP SIGNATURE-----



From dchardware at gmail.com  Wed Jun 18 12:23:56 2014
From: dchardware at gmail.com (Sipos Csaba)
Date: Wed, 18 Jun 2014 14:23:56 +0200
Subject: Patch: handover check for E1 based BTS
Message-ID: <743382037.20140618142356@freemail.hu>

The function that checks for HO compatibility is wrong for quite some
time. Even for E1 based BTSs the function requires RTP proxy to be
enabled. The following patch is fixing this, by changing the condition
so RTP proxy is only required, when the BTS is an IP based unit:

diff --git a/openbsc/src/libbsc/bsc_vty.c b/openbsc/src/libbsc/bsc_vty.c
index 6acf0c6..fbf28ec 100644
--- a/openbsc/src/libbsc/bsc_vty.c
+++ b/openbsc/src/libbsc/bsc_vty.c

@@ -1427,8 +1427,9 @@ DEFUN(cfg_net_handover, cfg_net_handover_cmd,
 {
        int enable = atoi(argv[0]);
        struct gsm_network *gsmnet = gsmnet_from_vty(vty);
+       struct gsm_bts *bts = vty->index;

-       if (enable && ipacc_rtp_direct) {
+       if (enable && ((is_ipaccess_bts(bts)) && ipacc_rtp_direct)) {
                vty_out(vty, "%% Cannot enable handover unless RTP Proxy mode "
                        "is enabled by using the -P command line option%s",
                        VTY_NEWLINE);


The patch is tested with Nokia Insite.

I hope someone can commit this to the master branch.

Regards,
Csaba




From mailman at lists.osmocom.org  Sun Jun 22 10:08:14 2014
From: mailman at lists.osmocom.org (mailman at lists.osmocom.org)
Date: Sun, 22 Jun 2014 12:08:14 +0200
Subject: Bounce action notification
Message-ID: <mailman.1159.1403431694.1438.openbsc@lists.osmocom.org>

This is a Mailman mailing list bounce action notice:

    List:       OpenBSC
    Member:     mki at mki-consult.de
    Action:     Subscription disabled.
    Reason:     Excessive or fatal bounces.
    


The triggering bounce notice is attached below.

Questions? Contact the Mailman site administrator at
mailman at lists.osmocom.org.
-------------- next part --------------
An embedded message was scrubbed...
From: Mail Delivery System <Mailer-Daemon at ganesha.gnumonks.org>
Subject: Mail delivery failed: returning message to sender
Date: Sun, 22 Jun 2014 12:08:12 +0200
Size: 3499
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140622/58d4b653/attachment.eml>

From holger at freyther.de  Sun Jun 22 13:38:18 2014
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 22 Jun 2014 15:38:18 +0200
Subject: Questions regarding sysmoBTS2050 power management
Message-ID: <20140622133818.GB23949@xiaoyu.lan>

hi!

I would like to have your opinion on the power management of the
sysmoBTS2050 hardware in various conditions:


Using only a single TRX with 10:

We have to disable the second TRX. Would you want to set a
different device id in the EEPROM for the sysmoBTS2050 to indicate
a single TRX board? If yes we could have nominal power return 40
and something like the sysmobts-mgr could disable the power of the
second trx on start?

Another option would be to make it configurable inside the bts
configuration file. In this case the bts process would need to
tell the sysmobts-mgr to switch off the second trx?


Reducing power in a dual-bts setup:

The current unfinished idea would be that in case the system
heats up too much we reduce the transmit power on the first
TRX. Is this enough? Is this enough because in the long run we
will manage both TRX from the first one? Or shall we handle
the heat inside OpenBSC to temporarily reduce the power? This
way we would need to send information in case the system returns
to an acceptable temperature?



holger



From laforge at gnumonks.org  Mon Jun 23 07:03:51 2014
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 23 Jun 2014 09:03:51 +0200
Subject: Questions regarding sysmoBTS2050 power management
In-Reply-To: <20140622133818.GB23949@xiaoyu.lan>
References: <20140622133818.GB23949@xiaoyu.lan>
Message-ID: <20140623070351.GB5903@nataraja>

Hi Holger,

On Sun, Jun 22, 2014 at 03:38:18PM +0200, Holger Hans Peter Freyther wrote:
> Using only a single TRX with 10:
> 
> We have to disable the second TRX. Would you want to set a
> different device id in the EEPROM for the sysmoBTS2050 to indicate
> a single TRX board? 

If it actually is a sysmoBTS 1100 (1 TRX, 10W) and doesn't even hae a
second TRX board installed, then I would do that, yes.

If it is a unit with 2 TRX boards that the user for whatever reason
wants to use with only one TRX, then that shouldn't be stored in the
EEPROM.

> If yes we could have nominal power return 40 and something like the
> sysmobts-mgr could disable the power of the second trx on start?

I think this is an option, but only for the hypothetical option of a
sysmoBTS 1100, which we haven't built until now.

> Another option would be to make it configurable inside the bts
> configuration file. 

You can already do that today by using the 'nominal-tx-power' cofiguration
command at the TRX level.  It should override whatever the system default is.

> In this case the bts process would need to tell the sysmobts-mgr to switch
> off the second trx?

Right now there is no such safeguard, so somebody could run both TRX boards at
nominal power of 40dBm, overloading the PA.  So yes, maybe check if
nominal-tx-power is > 37dBm and then either
* refuse to start the master if DC power of second TRX is still active, or
* switch off the second TRX

Both cases are not foolproof, as the user could always manually switch on the
secondary TRX and again overload the PA.  Thermal management code should
prevent us from overheating, but that doesn't prevent the RF spectrum from
possibly looking quite awkward as you are moving out of the linear range of the
PA...

> Reducing power in a dual-bts setup:
> 
> The current unfinished idea would be that in case the system
> heats up too much we reduce the transmit power on the first
> TRX. Is this enough? 

In a real 2-TRX BTS, the second TRX is not constant/full power, as it is
only transmitting in active timeslots.  Also, it might do downlink power
control.  In this case, I would agree that primarily the first TRX power
should be reduced, as it is constant-full-power

> Is this enough because in the long run we will manage both TRX from
> the first one? 

I would think so. The first step would be an OML router inside
sysmoBTS-mgr, through which all OML messages pass (to both local and
remote TRX), and which then is able to control both of them.

> Or shall we handle the heat inside OpenBSC to temporarily reduce the
> power? This way we would need to send information in case the system
> returns to an acceptable temperature?

I wouldn't do that, it is too much effort for a clearly only temporary
solution.

-- 
- 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 edachleger at yahoo.com  Tue Jun 24 09:32:17 2014
From: edachleger at yahoo.com (Erich Dachleger)
Date: Tue, 24 Jun 2014 10:32:17 +0100
Subject: osmo-nitb: %This BTS does not support TSC!=BCC
Message-ID: <1403602337.43441.YahooMailNeo@web171801.mail.ir2.yahoo.com>

Hi all,

I have followed the the guide in network_from_scratch and use 1 osmocom phone as transceiver. I use the suggested configs for open-bsc.cfg and osmo-bts.cfg and can register to the network I run.


However in the output from osmo--nitb ,in the start I get a message about the training sequence:
________________________________________________

% This BTS does not support a TSC!=BCC, Falling back to BCC
and after the 

DB: Database initialized messages
DB: Database prepared
----------------------------------
--------------------------------

<0005>bsc.init.c:265 bootstrapping RSL for BTS/TRX(0/0) on ARFCN 533 using MCC=1 MNC=1 LAC=1 CID=0 BSIC=63 TSC 7
------------------------------------------
<0002> gsm.subscriber.c: 378 Subscriber <imsi> ATTACHED LAC=1
-----------------------------------------------------------------------------------------------------

I have entered hlr.sqlite and assigned an extension to my imsi but when I enter the VTY
and execute
enable

subscriber imsi <imsi> sms send test123
I get:
%Unknown command
So it appears smsqueue is not enabled. Does anyone know what to look for to enable it?
I have tried the vty commands? trigger smsqueue but to no avail..
According to the network from scratch wiki sms (and broadcast) should function with one phone where TS0 is served
-------------------------------------------------------------------


osmo-bts-trx outputs lines of

??????????????????????????????????????????????????????????????????????????? 

<0006> scheduler.c 338 ---- ???????????????????? chan=SDCC/4(0)
???????????????????????????????????????????? --- ?????????????????? chan=SACC/4(0)
?????????????????????????????????????????? ----- ???????????????????? chan=BCCH(0)
----------------------------------------------------------------------------------------------------------
When the firmware is loaded onto the phone I get time on arrival and? signal to noise ratio messages:
TOA=4 snr=16384 (Thres 2560) freq_err=40 pm=-70
--------------------------------------------------------
So that is grossly exceeding the threshold value.
But is that related to not being able to use smsqueue?

Regards
Erich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140624/2b53240e/attachment.htm>

From mailman-bounces at lists.osmocom.org  Wed Jun 25 07:00:03 2014
From: mailman-bounces at lists.osmocom.org (mailman-bounces at lists.osmocom.org)
Date: Wed, 25 Jun 2014 09:00:03 +0200
Subject: OpenBSC unsubscribe notification
Message-ID: <mailman.1.1403679603.27674.openbsc@lists.osmocom.org>

osmocom at ninoc.nl has been removed from OpenBSC.



From Max.Suraev at fairwaves.co  Thu Jun 26 08:50:35 2014
From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=)
Date: Thu, 26 Jun 2014 10:50:35 +0200
Subject: new buzzword for HLR
Message-ID: <53ABDEDB.1060702@fairwaves.co>

Hi all.

I recall talks about sqlite-backed HLR being bottleneck and that it should be
replaced with something more decent.

As far as I recall that idea is not materialized yet so I'd like to bring new db
buzz-word I've stumbled upon recently:
http://www.aerospike.com/press-releases/aerospike-open-sources-visionary-database/

If you remove all the marketing junk it's essentially greatly revamped AlchemyDB with
AGPL license for server (various language bindings for client library under apache
license), transactions and claim for very-small latencies (approx 5 ms!) which
grabbed my attention.

It's unlikely that I'll be able to allocate time to work on that ATM but maybe it'll
spark interest in someone else :)

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



From andrew at carrierdetect.com  Thu Jun 26 09:30:18 2014
From: andrew at carrierdetect.com (Andrew Back)
Date: Thu, 26 Jun 2014 10:30:18 +0100
Subject: new buzzword for HLR
In-Reply-To: <53ABDEDB.1060702@fairwaves.co>
References: <53ABDEDB.1060702@fairwaves.co>
Message-ID: <CADj1OPBUAjrJgfNUB7XkVmTR_Qd8=oBSA-8RdXc0vP9yVasFvw@mail.gmail.com>

On 26 June 2014 09:50, ? <Max.Suraev at fairwaves.co> wrote:
> Hi all.
>
> I recall talks about sqlite-backed HLR being bottleneck and that it should be
> replaced with something more decent.

I wonder if Redis might be a good candidate. The website is also
possibly easier to decipher and there is a page on latency:

http://redis.io/topics/latency

Regards,

Andrew

-- 
Andrew Back
http://carrierdetect.com



From daniel at totalueberwachung.de  Fri Jun 27 15:05:47 2014
From: daniel at totalueberwachung.de (Daniel Willmann)
Date: Fri, 27 Jun 2014 17:05:47 +0200
Subject: [openbsc 1/3] libbsc, osmo-bsc{,
	_nat}: Prevent unaligned access when casting TLVP_VAL
Message-ID: <096d31f102dec08830c6516348b4648515648006.1403881549.git.daniel@totalueberwachung.de>

foo = *((uintXX_t *) TLVP_VAL(...) can lead to unaligned access. To
prevent that use tlvp_valXX_unal() to get the values.
---
 openbsc/src/libbsc/abis_rsl.c             | 10 +++++-----
 openbsc/src/osmo-bsc/osmo_bsc_bssap.c     |  2 +-
 openbsc/src/osmo-bsc_nat/bsc_mgcp_utils.c |  2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/openbsc/src/libbsc/abis_rsl.c b/openbsc/src/libbsc/abis_rsl.c
index 748ab7e..d193078 100644
--- a/openbsc/src/libbsc/abis_rsl.c
+++ b/openbsc/src/libbsc/abis_rsl.c
@@ -1804,20 +1804,20 @@ static void ipac_parse_rtp(struct gsm_lchan *lchan, struct tlv_parsed *tv)
 	uint16_t port, conn_id;
 
 	if (TLVP_PRESENT(tv, RSL_IE_IPAC_LOCAL_IP)) {
-		ip.s_addr = *((uint32_t *) TLVP_VAL(tv, RSL_IE_IPAC_LOCAL_IP));
+		ip.s_addr = tlvp_val32_unal(tv, RSL_IE_IPAC_LOCAL_IP);
 		DEBUGPC(DRSL, "LOCAL_IP=%s ", inet_ntoa(ip));
 		lchan->abis_ip.bound_ip = ntohl(ip.s_addr);
 	}
 
 	if (TLVP_PRESENT(tv, RSL_IE_IPAC_LOCAL_PORT)) {
-		port = *((uint16_t *) TLVP_VAL(tv, RSL_IE_IPAC_LOCAL_PORT));
+		port = tlvp_val16_unal(tv, RSL_IE_IPAC_LOCAL_PORT);
 		port = ntohs(port);
 		DEBUGPC(DRSL, "LOCAL_PORT=%u ", port);
 		lchan->abis_ip.bound_port = port;
 	}
 
 	if (TLVP_PRESENT(tv, RSL_IE_IPAC_CONN_ID)) {
-		conn_id = *((uint16_t *) TLVP_VAL(tv, RSL_IE_IPAC_CONN_ID));
+		conn_id = tlvp_val16_unal(tv, RSL_IE_IPAC_CONN_ID);
 		conn_id = ntohs(conn_id);
 		DEBUGPC(DRSL, "CON_ID=%u ", conn_id);
 		lchan->abis_ip.conn_id = conn_id;
@@ -1838,13 +1838,13 @@ static void ipac_parse_rtp(struct gsm_lchan *lchan, struct tlv_parsed *tv)
 	}
 
 	if (TLVP_PRESENT(tv, RSL_IE_IPAC_REMOTE_IP)) {
-		ip.s_addr = *((uint32_t *) TLVP_VAL(tv, RSL_IE_IPAC_REMOTE_IP));
+		ip.s_addr = tlvp_val32_unal(tv, RSL_IE_IPAC_REMOTE_IP);
 		DEBUGPC(DRSL, "REMOTE_IP=%s ", inet_ntoa(ip));
 		lchan->abis_ip.connect_ip = ntohl(ip.s_addr);
 	}
 
 	if (TLVP_PRESENT(tv, RSL_IE_IPAC_REMOTE_PORT)) {
-		port = *((uint16_t *) TLVP_VAL(tv, RSL_IE_IPAC_REMOTE_PORT));
+		port = tlvp_val16_unal(tv, RSL_IE_IPAC_REMOTE_PORT);
 		port = ntohs(port);
 		DEBUGPC(DRSL, "REMOTE_PORT=%u ", port);
 		lchan->abis_ip.connect_port = port;
diff --git a/openbsc/src/osmo-bsc/osmo_bsc_bssap.c b/openbsc/src/osmo-bsc/osmo_bsc_bssap.c
index c2c2417..f58d96f 100644
--- a/openbsc/src/osmo-bsc/osmo_bsc_bssap.c
+++ b/openbsc/src/osmo-bsc/osmo_bsc_bssap.c
@@ -135,7 +135,7 @@ static int bssmap_handle_paging(struct osmo_msc_data *msc,
 
 	if (TLVP_PRESENT(&tp, GSM0808_IE_TMSI) &&
 	    TLVP_LEN(&tp, GSM0808_IE_TMSI) == 4) {
-		tmsi = ntohl(*(uint32_t *) TLVP_VAL(&tp, GSM0808_IE_TMSI));
+		tmsi = ntohl(tlvp_val32_unal(&tp, GSM0808_IE_TMSI));
 	}
 
 	/*
diff --git a/openbsc/src/osmo-bsc_nat/bsc_mgcp_utils.c b/openbsc/src/osmo-bsc_nat/bsc_mgcp_utils.c
index 22b8a35..e13827b 100644
--- a/openbsc/src/osmo-bsc_nat/bsc_mgcp_utils.c
+++ b/openbsc/src/osmo-bsc_nat/bsc_mgcp_utils.c
@@ -191,7 +191,7 @@ int bsc_mgcp_assign_patch(struct nat_sccp_connection *con, struct msgb *msg)
 		return -1;
 	}
 
-	cic = ntohs(*(uint16_t *)TLVP_VAL(&tp, GSM0808_IE_CIRCUIT_IDENTITY_CODE));
+	cic = ntohs(tlvp_val16_unal(&tp, GSM0808_IE_CIRCUIT_IDENTITY_CODE));
 	timeslot = cic & 0x1f;
 	multiplex = (cic & ~0x1f) >> 5;
 
-- 
1.8.4.2




From daniel at totalueberwachung.de  Fri Jun 27 15:05:48 2014
From: daniel at totalueberwachung.de (Daniel Willmann)
Date: Fri, 27 Jun 2014 17:05:48 +0200
Subject: [openbsc 2/3] gprs_llc: Prevent llme_alloc/lle_init from reading
	invalid memory
In-Reply-To: <096d31f102dec08830c6516348b4648515648006.1403881549.git.daniel@totalueberwachung.de>
References: <096d31f102dec08830c6516348b4648515648006.1403881549.git.daniel@totalueberwachung.de>
Message-ID: <9ea73a8c1fb0f60c8b36b8f2da24136450bf0460.1403881549.git.daniel@totalueberwachung.de>

Make the llc_default_params structure from which data is initialized
large enough. Otherwise address sanitizer complains with out-of-bounds
reads.
---
 openbsc/src/gprs/gprs_llc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c
index 70fe9dd..e6b1f07 100644
--- a/openbsc/src/gprs/gprs_llc.c
+++ b/openbsc/src/gprs/gprs_llc.c
@@ -84,7 +84,7 @@ static int _bssgp_tx_dl_ud(struct msgb *msg, struct sgsn_mm_ctx *mmctx)
 
 
 /* Section 8.9.9 LLC layer parameter default values */
-static const struct gprs_llc_params llc_default_params[] = {
+static const struct gprs_llc_params llc_default_params[NUM_SAPIS] = {
 	[1] = {
 		.t200_201	= 5,
 		.n200		= 3,
-- 
1.8.4.2




From daniel at totalueberwachung.de  Fri Jun 27 15:05:49 2014
From: daniel at totalueberwachung.de (Daniel Willmann)
Date: Fri, 27 Jun 2014 17:05:49 +0200
Subject: [openbsc 3/3] libtrau: Fix off-by-one read access to gsm_fr_map
In-Reply-To: <096d31f102dec08830c6516348b4648515648006.1403881549.git.daniel@totalueberwachung.de>
References: <096d31f102dec08830c6516348b4648515648006.1403881549.git.daniel@totalueberwachung.de>
Message-ID: <9a4d2bcbaafce627042f4f9531e5f9543d13470b.1403881549.git.daniel@totalueberwachung.de>

Address sanitizer complains with a buffer overflow to the end of
gsm_fr_map:

ERROR: AddressSanitizer: global-buffer-overflow on address 0x00000044f76c at pc 0x43c0dd bp 0x7fff18389db0 sp 0x7fff18389da8
READ of size 1 at 0x00000044f76c thread T0
    #0 0x43c0dc in trau_encode_fr /home/alphaone/scm/osmo/openbsc/openbsc/src/libtrau/trau_mux.c:441
    #1 0x42fad6 in test_trau_fr_efr /home/alphaone/scm/osmo/openbsc/openbsc/tests/trau/trau_test.c:35
    #2 0x4308f4 in main /home/alphaone/scm/osmo/openbsc/openbsc/tests/trau/trau_test.c:70
    #3 0x7f96e8cf04bc (/lib64/libc.so.6+0x224bc)
    #4 0x42f7ec (/home/alphaone/scm/osmo/openbsc/openbsc/tests/trau/trau_test+0x42f7ec)
0x00000044f76c is located 52 bytes to the left of global variable 'c_bits_check_fr' from 'trau_mux.c' (0x44f7a0) of size 5
0x00000044f76c is located 0 bytes to the right of global variable 'gsm_fr_map' from 'trau_mux.c' (0x44f720) of size 76
SUMMARY: AddressSanitizer: global-buffer-overflow /home/alphaone/scm/osmo/openbsc/openbsc/src/libtrau/trau_mux.c:441 trau_encode_fr

In the last iteration of the loop k is already set to the next element
in gsm_fr_map which leads to an out-of-bounds read. Instead decrement k
at the end of the loop and put the check before the data assignment.
This is functionally equivalent as k is never < 0 initially.

This happens in trau_decode_fr as well.
---
 openbsc/src/libtrau/trau_mux.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/openbsc/src/libtrau/trau_mux.c b/openbsc/src/libtrau/trau_mux.c
index 4f159e4..9b93eda 100644
--- a/openbsc/src/libtrau/trau_mux.c
+++ b/openbsc/src/libtrau/trau_mux.c
@@ -234,13 +234,14 @@ struct msgb *trau_decode_fr(uint32_t callref,
 	l = 0; /* counts element bits */
 	o = 0; /* offset input bits */
 	while (i < 260) {
-		data[j/8] |= (tf->d_bits[k+o] << (7-(j%8)));
-		if (--k < 0) {
+		if (k < 0) {
 			o += gsm_fr_map[l];
 			k = gsm_fr_map[++l]-1;
 		}
+		data[j/8] |= (tf->d_bits[k+o] << (7-(j%8)));
 		i++;
 		j++;
+		k--;
 	}
 	frame->msg_type = GSM_TCHF_FRAME;
 	frame->callref = callref;
@@ -435,16 +436,14 @@ void trau_encode_fr(struct decoded_trau_frame *tf,
 	l = 0; /* counts element bits */
 	o = 0; /* offset output bits */
 	while (i < 260) {
-		tf->d_bits[k+o] = (data[j/8] >> (7-(j%8))) & 1;
-		/* to avoid out-of-bounds access in gsm_fr_map[++l] */
-		if (i == 259)
-			break;
-		if (--k < 0) {
+		if (k < 0) {
 			o += gsm_fr_map[l];
 			k = gsm_fr_map[++l]-1;
 		}
+		tf->d_bits[k+o] = (data[j/8] >> (7-(j%8))) & 1;
 		i++;
 		j++;
+		k--;
 	}
 }
 
-- 
1.8.4.2




From mailman at lists.osmocom.org  Fri Jun 27 15:10:29 2014
From: mailman at lists.osmocom.org (mailman at lists.osmocom.org)
Date: Fri, 27 Jun 2014 17:10:29 +0200
Subject: Bounce action notification
Message-ID: <mailman.1165.1403881829.1438.openbsc@lists.osmocom.org>

This is a Mailman mailing list bounce action notice:

    List:       OpenBSC
    Member:     devinechristophe at gmail.com
    Action:     Subscription disabled.
    Reason:     Excessive or fatal bounces.
    


The triggering bounce notice is attached below.

Questions? Contact the Mailman site administrator at
mailman at lists.osmocom.org.
-------------- next part --------------
An embedded message was scrubbed...
From: Mail Delivery System <Mailer-Daemon at ganesha.gnumonks.org>
Subject: Mail delivery failed: returning message to sender
Date: Fri, 27 Jun 2014 17:10:26 +0200
Size: 6629
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140627/42cef38e/attachment.eml>

From dchardware at gmail.com  Sat Jun 28 14:33:26 2014
From: dchardware at gmail.com (Sipos Csaba)
Date: Sat, 28 Jun 2014 16:33:26 +0200
Subject: Nokia UltraSite
In-Reply-To: <mailman.1.1403949606.25064.openbsc@lists.osmocom.org>
References: <mailman.1.1403949606.25064.openbsc@lists.osmocom.org>
Message-ID: <42754572.20140628163326@freemail.hu>

Hi,

I wonder if anybody was ever able to start a Nokia UltraSite with
OpenBSC?

In a nut shell: OML link is up and running, TRX1 is successfully loaded
software, configured, and now it is stuck in "Waiting for LAPD..."
state.

The problem is that OpenBSC initiates the RSLSIG link for this TRX,
but it seems the BTS is never answering to that:

Sat Jun 28 14:33:27 2014 <0018> input/lapd.c:159 LAPD state change on TEI 1: NONE -> ASSIGNED
Sat Jun 28 14:33:27 2014 <0018> input/lapd.c:212 LAPD Allocating SAP for SAPI=0 / TEI=1
Sat Jun 28 14:33:27 2014 <0018> input/lapd.c:223 k=2 N200=3 N201=260 T200=1.0 T203=10.0
Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:288 Init DL layer: sequence range = 128, k = 2, history range = 4
Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:227 new state LAPD_STATE_NULL -> LAPD_STATE_IDLE
Sat Jun 28 14:33:27 2014 <0018> input/lapd.c:485 LAPD DL-ESTABLISH request TEI=1 SAPI=0
Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:2180 Message DL-ESTABLISH-REQUEST received in state LAPD_STATE_IDLE
Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:1694 perform normal establishm. (SABM)
Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:227 new state LAPD_STATE_IDLE -> LAPD_STATE_SABM_SENT
Sat Jun 28 14:33:27 2014 <0018> input/lapd.c:600 TX: 02 03 7f
Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:196 start T200
Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:1779 lapd_send_i() called from line 1609
Sat Jun 28 14:33:27 2014 <0018> lapd_core.c:1618 we are not busy and have no pending data, send RR
Sat Jun 28 14:33:27 2014 <0018> input/lapd.c:600 TX: f8 03 01 08
Sat Jun 28 14:33:28 2014 <0018> lapd_core.c:545 Timeout T200 (0x993ad40) state=5
Sat Jun 28 14:33:28 2014 <0018> input/lapd.c:600 TX: 02 03 7f
Sat Jun 28 14:33:28 2014 <0018> lapd_core.c:196 start T200
Sat Jun 28 14:33:29 2014 <0018> lapd_core.c:545 Timeout T200 (0x993ad40) state=5
Sat Jun 28 14:33:29 2014 <0018> input/lapd.c:600 TX: 02 03 7f
Sat Jun 28 14:33:29 2014 <0018> lapd_core.c:196 start T200
Sat Jun 28 14:33:30 2014 <0018> lapd_core.c:545 Timeout T200 (0x993ad40) state=5
Sat Jun 28 14:33:30 2014 <0018> input/lapd.c:600 TX: 02 03 7f
Sat Jun 28 14:33:30 2014 <0018> lapd_core.c:196 start T200
Sat Jun 28 14:33:31 2014 <0018> lapd_core.c:545 Timeout T200 (0x993ad40) state=5
Sat Jun 28 14:33:31 2014 <0018> input/lapd.c:628 LAPD DL-RELEASE indication TEI=1 SAPI=0
Sat Jun 28 14:33:31 2014 <0018> lapd_core.c:303 Resetting LAPDm instance
Sat Jun 28 14:33:31 2014 <0018> lapd_core.c:227 new state LAPD_STATE_SABM_SENT -> LAPD_STATE_IDLE
Sat Jun 28 14:33:31 2014 <001b> bsc_init.c:318 Lost some E1 TEI link: 2 0x991b8f0
Sat Jun 28 14:33:31 2014 <0018> lapd_core.c:378 sending MDL-ERROR-IND cause 1
Sat Jun 28 14:33:31 2014 <0018> lapd_core.c:227 new state LAPD_STATE_IDLE -> LAPD_STATE_IDLE

I set the correct E1 TS for TRX1 RSLSIG in Traffic manager, and double
checked the RSLSIG config parameters on both end (OpenBSC config file and the BTS
manager).

Nokia Insite and MetroSite uses RSL TEI = 1 for the first TRX. Maybe
Ultra uses other TEI number for the first TRX, this is something I
will try, but otherwise I don't know how it is possible that not even
the LAPD connection is being established...

Any help is appreciated.

Thanks,

Csaba