From laforge at gnumonks.org  Tue Aug  2 10:09:40 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 2 Aug 2011 12:09:40 +0200
Subject: GSM @ Camp 2011 preparations
In-Reply-To: <20110604190601.GN21708@prithivi.gnumonks.org>
References: <20110604190601.GN21708@prithivi.gnumonks.org>
Message-ID: <20110802100940.GK18947@prithivi.gnumonks.org>

Hi all,

this is hopefully the last and final update before the Camp.

I'm happy that we now have the license and all the equipment required.

Please check http://openbsc.osmocom.org/trac/wiki/CCC_Camp_2011 for the
current plan.

Special thanks to Dieter Spaar for his effort to support the Nokia
Metrosite in OpenBSC on very short advance notice.  

(More thanks on http://events.ccc.de/camp/2011/wiki/GSM)

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



From admin at manateeshome.com  Mon Aug  1 17:30:14 2011
From: admin at manateeshome.com (Seungju Kim)
Date: Tue, 2 Aug 2011 02:30:14 +0900
Subject: GPRS issue after idle
Message-ID: <003801cc5070$adbaee10$0930ca30$@manateeshome.com>

Hello,I got everything up and running. Including EDGE data.

The throughput of the data from the osmo-sgsn is pretty good. But recently I
have spotted a problem with the SGSN.

The sgsn loses the phones SNDCP entity after idling or making a phone call.

 

Please see the log from the sgsn

http://pastebin.com/2W9dZdvW

 

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

From laforge at gnumonks.org  Thu Aug  4 11:13:31 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 4 Aug 2011 13:13:31 +0200
Subject: GPRS issue after idle
In-Reply-To: <003801cc5070$adbaee10$0930ca30$@manateeshome.com>
References: <003801cc5070$adbaee10$0930ca30$@manateeshome.com>
Message-ID: <20110804111331.GA15837@prithivi.gnumonks.org>

Hi!

On Tue, Aug 02, 2011 at 02:30:14AM +0900, Seungju Kim wrote:
> Hello,I got everything up and running. Including EDGE data.
> 
> The throughput of the data from the osmo-sgsn is pretty good. But recently I
> have spotted a problem with the SGSN.
> 
> The sgsn loses the phones SNDCP entity after idling or making a phone call.
> http://pastebin.com/2W9dZdvW

Interesting.  I have not yet observed this, as most likely my phones
don't include the "PDP Context Status IE" (TS 24.008 / 10.5.7.1).

Using this IE, the phone can tell the network "I think I still have PDP
contexts for the following NSAPIs active".  The network  then checks if
it has the smae view, and silently deletes all PDP contexts for other
NSAPIs.

It seems that the current code is interpreting the IE the wrong way.

We interpret it as an uint16_t, do ntohs() and it is 0x2000.
Apparently NSAPI 5 was active befor (your log snippet is a bit short):

<0002> gprs_gmm.c:884 Dropping PDP context for NSAPI=5 due to PDP CTX STATUS IE= 0x2000
<0014> sgsn_libgtp.c:212 Delete PDP Context
<0014> sgsn_libgtp.c:389 PDP Context was deleted

If I'm looking at Chapter 10.5.7.1, it seems the encoding is a bit odd,
i.e. actually the byte ordering is little endian!

Can you try the patch below and see if the problem is fixed?

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

From laforge at gnumonks.org  Thu Aug  4 11:11:18 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 4 Aug 2011 13:11:18 +0200
Subject: [PATCH] GPRS: Fix the byte ordering of the PDP context status IE
Message-ID: <mailman.38.1641744172.42898.openbsc@lists.osmocom.org>

It seems that 24.008 Section 10.5.7.1 specifies the IE to be encoded in
little endian...
---
 openbsc/src/gprs/gprs_gmm.c |   12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c
index 098e4c2..f83219f 100644
--- a/openbsc/src/gprs/gprs_gmm.c
+++ b/openbsc/src/gprs/gprs_gmm.c
@@ -870,6 +870,7 @@ static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx,
 				  uint16_t pdp_status)
 {
 	struct sgsn_pdp_ctx *pdp, *pdp2;
+	uint16_t pdp_status_reordered;
 	/* 24.008 4.7.5.1.3: If the PDP context status information element is
 	 * included in ROUTING AREA UPDATE REQUEST message, then the network
 	 * shall deactivate all those PDP contexts locally (without peer to
@@ -877,8 +878,13 @@ static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx,
 	 * state PDP-INACTIVE on network side but are indicated by the MS as
 	 * being in state PDP-INACTIVE. */
 
+	/* 24.008 10.5.7.1 indicates that the byte ordering is in fact
+	 * little endian, i.e. the first octet contains NSAPI0..7 and
+	 * the second payload octet NSAPI8..15 */
+	pdp_status_reordered = (pdp_status & 0xff << 8) || (pdp_status >> 8);
+
 	llist_for_each_entry_safe(pdp, pdp2, &mmctx->pdp_list, list) {
-		if (!(pdp_status & (1 << pdp->nsapi))) {
+		if (!(pdp_status_reordered & (1 << pdp->nsapi))) {
 			LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u "
 				"due to PDP CTX STATUS IE= 0x%04x\n",
 				pdp->nsapi, pdp_status);
@@ -977,6 +983,10 @@ static int gsm48_rx_gmm_ra_upd_req(struct sgsn_mm_ctx *mmctx, struct msgb *msg,
 	if (TLVP_PRESENT(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)) {
 		uint16_t pdp_status = ntohs(*(uint16_t *)
 				TLVP_VAL(&tp, GSM48_IE_GMM_PDP_CTX_STATUS));
+		/* pdp_status is now in big endian, which is the wrong
+		 * order. the wire encoding is little endian! We cannot
+		 * simply drop the ntohs() above, as we migh be running
+		 * on a big endian machine. */
 		process_ms_ctx_status(mmctx, pdp_status);
 	}
 
-- 
1.7.5.4


--iq/fWD14IMVFWBCD--



From admin at manateeshome.com  Thu Aug  4 14:17:18 2011
From: admin at manateeshome.com (Seungju Kim)
Date: Thu, 4 Aug 2011 23:17:18 +0900
Subject: GPRS issue after idle
In-Reply-To: <20110804111331.GA15837@prithivi.gnumonks.org>
References: <003801cc5070$adbaee10$0930ca30$@manateeshome.com>
	<20110804111331.GA15837@prithivi.gnumonks.org>
Message-ID: <017601cc52b1$39780e00$ac682a00$@manateeshome.com>

Hi!
I tested the patch but the problem still exists :(
Here is the new log from sgsn : http://pastebin.com/3PBKQwR5
If it helps, I am using an iPhone 4 with OpenBSC running under Debian 6 i686
VMWare.

-----Original Message-----
From: openbsc-bounces at lists.osmocom.org
[mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of Harald Welte
Sent: Thursday, August 04, 2011 8:14 PM
To: Seungju Kim
Cc: openbsc at lists.osmocom.org
Subject: Re: GPRS issue after idle

Hi!

On Tue, Aug 02, 2011 at 02:30:14AM +0900, Seungju Kim wrote:
> Hello,I got everything up and running. Including EDGE data.
> 
> The throughput of the data from the osmo-sgsn is pretty good. But 
> recently I have spotted a problem with the SGSN.
> 
> The sgsn loses the phones SNDCP entity after idling or making a phone
call.
> http://pastebin.com/2W9dZdvW

Interesting.  I have not yet observed this, as most likely my phones don't
include the "PDP Context Status IE" (TS 24.008 / 10.5.7.1).

Using this IE, the phone can tell the network "I think I still have PDP
contexts for the following NSAPIs active".  The network  then checks if it
has the smae view, and silently deletes all PDP contexts for other NSAPIs.

It seems that the current code is interpreting the IE the wrong way.

We interpret it as an uint16_t, do ntohs() and it is 0x2000.
Apparently NSAPI 5 was active befor (your log snippet is a bit short):

<0002> gprs_gmm.c:884 Dropping PDP context for NSAPI=5 due to PDP CTX STATUS
IE= 0x2000 <0014> sgsn_libgtp.c:212 Delete PDP Context <0014>
sgsn_libgtp.c:389 PDP Context was deleted

If I'm looking at Chapter 10.5.7.1, it seems the encoding is a bit odd, i.e.
actually the byte ordering is little endian!

Can you try the patch below and see if the problem is fixed?

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






From laforge at gnumonks.org  Fri Aug  5 06:05:29 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 5 Aug 2011 08:05:29 +0200
Subject: GPRS issue after idle
In-Reply-To: <017601cc52b1$39780e00$ac682a00$@manateeshome.com>
References: <003801cc5070$adbaee10$0930ca30$@manateeshome.com>
	<20110804111331.GA15837@prithivi.gnumonks.org>
	<017601cc52b1$39780e00$ac682a00$@manateeshome.com>
Message-ID: <20110805060529.GB20191@prithivi.gnumonks.org>

On Thu, Aug 04, 2011 at 11:17:18PM +0900, Seungju Kim wrote:
> Hi!
> I tested the patch but the problem still exists :(
> Here is the new log from sgsn : http://pastebin.com/3PBKQwR5

Then my patch is still wrong.  Please look at 24.008 / Section 10.5.7.1
and make sure the code parses the field correctly, i.e. as indicated in
the specs.

0x2000 == 0010 0000 0000 0000
corresponding SAPI:
	            1111 11
          7654 3210 5432 1098

i.e. the bit that is set _is_ NSAPI5.  This means, the code should _not_
release the PDP context for NSAPI5.  But due to erroneous parsing, it
_thinks_ that NSAPI5 is not set and it needs to be released.

Regards,
	Harald

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



From admin at manateeshome.com  Fri Aug  5 15:58:00 2011
From: admin at manateeshome.com (Seungju Kim)
Date: Sat, 6 Aug 2011 00:58:00 +0900
Subject: GPRS issue after idle
In-Reply-To: <20110805060529.GB20191@prithivi.gnumonks.org>
References: <003801cc5070$adbaee10$0930ca30$@manateeshome.com>
	<20110804111331.GA15837@prithivi.gnumonks.org>
	<017601cc52b1$39780e00$ac682a00$@manateeshome.com>
	<20110805060529.GB20191@prithivi.gnumonks.org>
Message-ID: <39DF1A75-1323-42F5-9DB1-FBD843A23EFA@manateeshome.com>

Alright, I see.
I just made an ugly hack and applied to my working copy.
So far it seems fine. Now my phone does not lose it's PDP context while making a phone call.
I'll be working on for some not ugly fix, but all these bits are confusing me haha.

Envoy? de mon iPhone

Le Aug 5, 2011 ? 3:05 PM, Harald Welte <laforge at gnumonks.org> a ?crit :

> On Thu, Aug 04, 2011 at 11:17:18PM +0900, Seungju Kim wrote:
>> Hi!
>> I tested the patch but the problem still exists :(
>> Here is the new log from sgsn : http://pastebin.com/3PBKQwR5
> 
> Then my patch is still wrong.  Please look at 24.008 / Section 10.5.7.1
> and make sure the code parses the field correctly, i.e. as indicated in
> the specs.
> 
> 0x2000 == 0010 0000 0000 0000
> corresponding SAPI:
>                1111 11
>          7654 3210 5432 1098
> 
> i.e. the bit that is set _is_ NSAPI5.  This means, the code should _not_
> release the PDP context for NSAPI5.  But due to erroneous parsing, it
> _thinks_ that NSAPI5 is not set and it needs to be released.
> 
> Regards,
>    Harald
> 
> -- 
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)
> 




From laforge at gnumonks.org  Fri Aug  5 19:22:43 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 5 Aug 2011 21:22:43 +0200
Subject: GPRS issue after idle
In-Reply-To: <39DF1A75-1323-42F5-9DB1-FBD843A23EFA@manateeshome.com>
References: <003801cc5070$adbaee10$0930ca30$@manateeshome.com>
	<20110804111331.GA15837@prithivi.gnumonks.org>
	<017601cc52b1$39780e00$ac682a00$@manateeshome.com>
	<20110805060529.GB20191@prithivi.gnumonks.org>
	<39DF1A75-1323-42F5-9DB1-FBD843A23EFA@manateeshome.com>
Message-ID: <20110805192243.GN21956@prithivi.gnumonks.org>

Hi,

On Sat, Aug 06, 2011 at 12:58:00AM +0900, Seungju Kim wrote:
> Alright, I see.
> I just made an ugly hack and applied to my working copy.
> So far it seems fine. Now my phone does not lose it's PDP context while making a phone call.
> I'll be working on for some not ugly fix, but all these bits are confusing me haha.

can you try the attached patch?  It should parse it correctly, without
the double-byte-swapping of the last patch.
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

From laforge at gnumonks.org  Fri Aug  5 19:19:12 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 5 Aug 2011 21:19:12 +0200
Subject: [PATCH] GPRS: Fix the parsing/interpretation of the PDP CTX status
 IE
Message-ID: <mailman.39.1641744172.42898.openbsc@lists.osmocom.org>

The byte ordering is a bit odd:  The least significant byte is ahead of
the most significant byte, different from everything else in GSM that
seems to be big-endian.

Thanks to Seungju Kim <admin at manateeshome.com> for repoerting the bug.
---
 openbsc/src/gprs/gprs_gmm.c    |   24 ++++++++++++++++--------
 1 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c
index 098e4c2..c9fe517 100644
--- a/openbsc/src/gprs/gprs_gmm.c
+++ b/openbsc/src/gprs/gprs_gmm.c
@@ -867,7 +867,7 @@ static int gsm48_tx_gmm_ra_upd_rej(struct msgb *old_msg, uint8_t cause)
 }
 
 static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx,
-				  uint16_t pdp_status)
+				  uint8_t *pdp_status)
 {
 	struct sgsn_pdp_ctx *pdp, *pdp2;
 	/* 24.008 4.7.5.1.3: If the PDP context status information element is
@@ -878,11 +878,20 @@ static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx,
 	 * being in state PDP-INACTIVE. */
 
 	llist_for_each_entry_safe(pdp, pdp2, &mmctx->pdp_list, list) {
-		if (!(pdp_status & (1 << pdp->nsapi))) {
-			LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u "
-				"due to PDP CTX STATUS IE= 0x%04x\n",
-				pdp->nsapi, pdp_status);
-			sgsn_delete_pdp_ctx(pdp);
+		if (pdp->nsapi < 8) {
+			if (!(pdp_status[0] & (1 << pdp->nsapi))) {
+				LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u "
+					"due to PDP CTX STATUS IE= 0x%02x%02x\n",
+					pdp->nsapi, pdp_status[1], pdp_status[0]);
+				sgsn_delete_pdp_ctx(pdp);
+			}
+		} else {
+			if (!(pdp_status[1] & (1 << (pdp->nsapi - 8)))) {
+				LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u "
+					"due to PDP CTX STATUS IE= 0x%02x%02x\n",
+					pdp->nsapi, pdp_status[1], pdp_status[0]);
+				sgsn_delete_pdp_ctx(pdp);
+			}
 		}
 	}
 }
@@ -975,8 +984,7 @@ static int gsm48_rx_gmm_ra_upd_req(struct sgsn_mm_ctx *mmctx, struct msgb *msg,
 	/* Look at PDP Context Status IE and see if MS's view of
 	 * activated/deactivated NSAPIs agrees with our view */
 	if (TLVP_PRESENT(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)) {
-		uint16_t pdp_status = ntohs(*(uint16_t *)
-				TLVP_VAL(&tp, GSM48_IE_GMM_PDP_CTX_STATUS));
+		uint8_t *pdp_status = TLVP_VAL(&tp, GSM48_IE_GMM_PDP_CTX_STATUS);
 		process_ms_ctx_status(mmctx, pdp_status);
 	}
 
-- 
1.7.5.4


--CE+1k2dSO48ffgeK--



From admin at manateeshome.com  Sat Aug  6 03:01:05 2011
From: admin at manateeshome.com (Seungju Kim)
Date: Sat, 6 Aug 2011 12:01:05 +0900
Subject: GPRS issue after idle
In-Reply-To: <20110805192243.GN21956@prithivi.gnumonks.org>
References: <003801cc5070$adbaee10$0930ca30$@manateeshome.com>
	<20110804111331.GA15837@prithivi.gnumonks.org>
	<017601cc52b1$39780e00$ac682a00$@manateeshome.com>
	<20110805060529.GB20191@prithivi.gnumonks.org>
	<39DF1A75-1323-42F5-9DB1-FBD843A23EFA@manateeshome.com>
	<20110805192243.GN21956@prithivi.gnumonks.org>
Message-ID: <9326D938-68F7-43A3-85A6-67F8FAEE3774@manateeshome.com>

I could confirm that this patch is working :)

Envoy? de mon iPhone

Le Aug 6, 2011 ? 4:22 AM, Harald Welte <laforge at gnumonks.org> a ?crit :

> Hi,
> 
> On Sat, Aug 06, 2011 at 12:58:00AM +0900, Seungju Kim wrote:
>> Alright, I see.
>> I just made an ugly hack and applied to my working copy.
>> So far it seems fine. Now my phone does not lose it's PDP context while making a phone call.
>> I'll be working on for some not ugly fix, but all these bits are confusing me haha.
> 
> can you try the attached patch?  It should parse it correctly, without
> the double-byte-swapping of the last patch.
> -- 
> - 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)
> <0001-GPRS-Fix-the-parsing-interpretation-of-the-PDP-CTX-s.patch>




From laforge at gnumonks.org  Sat Aug  6 06:40:47 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 6 Aug 2011 08:40:47 +0200
Subject: GPRS issue after idle
In-Reply-To: <9326D938-68F7-43A3-85A6-67F8FAEE3774@manateeshome.com>
References: <003801cc5070$adbaee10$0930ca30$@manateeshome.com>
	<20110804111331.GA15837@prithivi.gnumonks.org>
	<017601cc52b1$39780e00$ac682a00$@manateeshome.com>
	<20110805060529.GB20191@prithivi.gnumonks.org>
	<39DF1A75-1323-42F5-9DB1-FBD843A23EFA@manateeshome.com>
	<20110805192243.GN21956@prithivi.gnumonks.org>
	<9326D938-68F7-43A3-85A6-67F8FAEE3774@manateeshome.com>
Message-ID: <20110806064047.GU21956@prithivi.gnumonks.org>

On Sat, Aug 06, 2011 at 12:01:05PM +0900, Seungju Kim wrote:
> I could confirm that this patch is working :)

Great, it's already part of the master branch now.
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From khorben at defora.org  Wed Aug  3 02:53:34 2011
From: khorben at defora.org (Pierre Pronchery)
Date: Wed, 03 Aug 2011 04:53:34 +0200
Subject: Packages in pkgsrc-wip (for NetBSD and more)
Message-ID: <4E38B82E.2090407@defora.org>

			Hi openbsc@,

for the record I have just packaged libosmocore 0.1.30 and OpenBSC
0.9.13 in pkgsrc-wip, as released by Harald about 5 months ago, see:
http://openbsc.osmocom.org/trac/wiki/Tarballs
and
http://cvsweb.netbsd.se/cgi-bin/bsdweb.cgi/wip/libosmocore/
http://cvsweb.netbsd.se/cgi-bin/bsdweb.cgi/wip/openbsc/

I had to apply a few changes, patches are found in the two links above
(not all of them good enough to be pushed though).

Unfortunately OpenBSC is probably not useful on NetBSD at the moment,
except with the isdn4bsd patches maybe (which I don't think are
maintained anymore). pkgsrc can be useful on Linux distributions though.

HTH anyway,
-- 
khorben



From holger at freyther.de  Wed Aug  3 08:31:29 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed, 03 Aug 2011 10:31:29 +0200
Subject: Packages in pkgsrc-wip (for NetBSD and more)
In-Reply-To: <4E38B82E.2090407@defora.org>
References: <4E38B82E.2090407@defora.org>
Message-ID: <4E390761.1030308@freyther.de>

On 08/03/2011 04:53 AM, Pierre Pronchery wrote:
> 			Hi openbsc@,

> 
> Unfortunately OpenBSC is probably not useful on NetBSD at the moment,
> except with the isdn4bsd patches maybe (which I don't think are
> maintained anymore). pkgsrc can be useful on Linux distributions though.
>

Hi,

OpenBSC supports various BTS that connect via IP. I am feeling a bit sorry
that you took 5 month old code. Is there a policy to only build from released
tarballs? E.g. the debian packages are created from the git repository (a
specific tag though).

thanks for the packaging and again sorry you were forced to use old code


holger



From khorben at defora.org  Wed Aug  3 16:36:40 2011
From: khorben at defora.org (Pierre Pronchery)
Date: Wed, 03 Aug 2011 18:36:40 +0200
Subject: Packages in pkgsrc-wip (for NetBSD and more)
In-Reply-To: <4E38B82E.2090407@defora.org>
References: <4E38B82E.2090407@defora.org>
Message-ID: <4E397918.4090409@defora.org>

			Hi openbsc@,

replying to Holger (I wasn't subscribed to the list yet)

On 03/08/2011 04:53, Pierre Pronchery wrote:
> 
> for the record I have just packaged libosmocore 0.1.30 and OpenBSC
> 0.9.13 in pkgsrc-wip, as released by Harald about 5 months ago [...]

There is no policy to build from released tarballs, it was just easier
for me for the time being. It's good to hear that OpenBSC can be useful
without ISDN cards, even though I do not have the relevant hardware at
my disposal currently.

I'll try to package more recent versions when I get the chance.

Cheers!
-- 
khorben



From gus at bourg.net  Fri Aug  5 23:51:45 2011
From: gus at bourg.net (Gus Bourg)
Date: Fri, 5 Aug 2011 16:51:45 -0700
Subject: OpenBSC + LCR
Message-ID: <CAKL=SEpdKWtFp=LxP2WBO3nc5CRbTEZSTEFbZUzj5O371QgUKg@mail.gmail.com>

Hello all,

I'm attempting to make my OpenBSC setup work with LCR and Asterisk.  I'm not
sure if the problem that I'm running into is specific to the nature of my
setup (running a Nokia BTS) or is a misconfiguration issue with LCR.  When I
run without LCR and Asterisk I can call between phones, SMS etc.  With LCR I
have no such luck.  I can place a call into the mobile from Asterisk, and
the mobile rings, but when I answer the call hangs up.

A pastebin of the LCR log can be found here:
http://pastebin.com/DbM3TfFp

Any insight into the cause would be much appreciated.  :)

Thanks,
Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110805/3371466d/attachment.htm>

From akibsayyed at gmail.com  Sun Aug  7 08:26:23 2011
From: akibsayyed at gmail.com (Akib Sayyed)
Date: Sun, 7 Aug 2011 13:56:23 +0530
Subject: what type of RRLP protocol supported in OpenBSC
Message-ID: <CAMG-S92LiiRZbH40iEDC_Uai7jCizOmAVmcz=zHjq0w7J1-BPw@mail.gmail.com>

OpenBSC support RRLP protocol
but in RRLP we have 2 modes
E-OTD
A-GPS
what modes are supported??
if E-OTD is supported can we use OpenBSC to triangulate normal Cellphones
like Motorola C123
??

-- 
Akib Sayyed
Matrix-Shell
akibsayyed at gmail.com
akibsayyed at matrixshell.com
Mob:- +91-966-514-2243
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110807/22220c20/attachment.htm>

From holger at freyther.de  Sun Aug  7 08:55:07 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 07 Aug 2011 10:55:07 +0200
Subject: what type of RRLP protocol supported in OpenBSC
In-Reply-To: <CAMG-S92LiiRZbH40iEDC_Uai7jCizOmAVmcz=zHjq0w7J1-BPw@mail.gmail.com>
References: <CAMG-S92LiiRZbH40iEDC_Uai7jCizOmAVmcz=zHjq0w7J1-BPw@mail.gmail.com>
Message-ID: <4E3E52EB.6040800@freyther.de>

On 08/07/2011 10:26 AM, Akib Sayyed wrote:
> OpenBSC support RRLP protocol
> but in RRLP we have 2 modes
> E-OTD
> A-GPS
> what modes are supported??
> if E-OTD is supported can we use OpenBSC to triangulate normal Cellphones like
> Motorola C123

Hello Akib,

the source of OpenBSC can be found here[1] and I encourage you to document
your findings in our wiki[2], but also RRLP in general and what is already
implemented and what is missing. Due issues with spamers you will need to ask
us for a username/password.

thanks for trying to contribute
	holger

[1] http://cgit.osmocom.org/cgit/openbsc/
[2] http://openbsc.osmocom.org/trac/



From admin at manateeshome.com  Tue Aug  9 14:45:09 2011
From: admin at manateeshome.com (Seungju Kim)
Date: Tue, 9 Aug 2011 23:45:09 +0900
Subject: Sudden connection drop
Message-ID: <B7B2BEB9-E5D5-4BAF-8342-194138C42E6F@manateeshome.com>

Hello,

I have been testing the data setup and I found another issue. I couldn't really find out exactly what causes this. This happens rarely but it does happen time to time. I am attaching the log file of the issue. I looked through the log but I could not find anything else interesting in the log.
http://pastebin.com/tQ0mcyeu
This is the log file of the issue. I'll be glad to hear any thoughts about this.

Envoy? de mon iPhone



From pablo at gnumonks.org  Tue Aug  9 23:35:49 2011
From: pablo at gnumonks.org (pablo at gnumonks.org)
Date: Wed, 10 Aug 2011 01:35:49 +0200
Subject: [PATCH 0/3] updates for Nokia support
Message-ID: <1312932952-5197-1-git-send-email-pablo@gnumonks.org>

From: Pablo Neira Ayuso <pablo at gnumonks.org>

Hi Harald,

This patchset contains two updates for the Nokia support
in the following scenario: the BSC stops after having
configured the BTS, then the BTS is launched again but
LAPD reports unknown TEI. To fix this, we report to the
E1 driver about unknown TEI so it can resend the SABM
message.

... and one patch from Daniel who thinks that we have
to promote some logs messages from debugging to error.

You can find them in the nokia-pablo branch.

We are using them in the camp.

Please, merge them.

Daniel Willmann (1):
  mncc: promote log level from debug to errors

Pablo Neira Ayuso (2):
  LAPD: Propagate lapd_receive() errors to the E1 driver
  NOKIA: Resend SABM on unknown TEI from LAPD

 openbsc/include/openbsc/signal.h    |    1 +
 openbsc/src/libabis/e1_input.c      |    1 +
 openbsc/src/libabis/input/dahdi.c   |   20 ++++++++++++++++----
 openbsc/src/libabis/input/lapd.c    |   14 ++++++++++++--
 openbsc/src/libabis/input/lapd.h    |   16 ++++++++++++++--
 openbsc/src/libbsc/bts_nokia_site.c |    9 ++++++++-
 openbsc/src/libmsc/gsm_04_08.c      |   10 +++++-----
 7 files changed, 57 insertions(+), 14 deletions(-)




From pablo at gnumonks.org  Tue Aug  9 23:35:50 2011
From: pablo at gnumonks.org (pablo at gnumonks.org)
Date: Wed, 10 Aug 2011 01:35:50 +0200
Subject: [PATCH 1/3] LAPD: Propagate lapd_receive() errors to the E1 driver
In-Reply-To: <1312932952-5197-1-git-send-email-pablo@gnumonks.org>
References: <1312932952-5197-1-git-send-email-pablo@gnumonks.org>
Message-ID: <1312932952-5197-2-git-send-email-pablo@gnumonks.org>

From: Pablo Neira Ayuso <pablo at gnumonks.org>

Scenario: BTS are configured and working, then the BSC stops working
for some reason (crash or administrative stop).

If the BSC comes back to life, LAPD among other things does not know
about the previous existing TEIs. Instead of ignoring these frames,
we notify the driver that we are seeing frames with unknown TEIs, so
it can try to recover, e.g. by resending the SABM message.
---
 openbsc/include/openbsc/signal.h  |    1 +
 openbsc/src/libabis/e1_input.c    |    1 +
 openbsc/src/libabis/input/dahdi.c |   20 ++++++++++++++++----
 openbsc/src/libabis/input/lapd.c  |   14 ++++++++++++--
 openbsc/src/libabis/input/lapd.h  |   16 ++++++++++++++--
 5 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/openbsc/include/openbsc/signal.h b/openbsc/include/openbsc/signal.h
index 2991cfa..71e1dee 100644
--- a/openbsc/include/openbsc/signal.h
+++ b/openbsc/include/openbsc/signal.h
@@ -145,6 +145,7 @@ enum signal_input {
 	S_INP_NONE,
 	S_INP_TEI_UP,
 	S_INP_TEI_DN,
+	S_INP_TEI_UNKNOWN,
 	S_INP_LINE_INIT,
 	S_INP_LINE_ALARM,
 	S_INP_LINE_NOALARM,
diff --git a/openbsc/src/libabis/e1_input.c b/openbsc/src/libabis/e1_input.c
index 97dcd33..293175e 100644
--- a/openbsc/src/libabis/e1_input.c
+++ b/openbsc/src/libabis/e1_input.c
@@ -570,6 +570,7 @@ int e1inp_event(struct e1inp_ts *ts, int evt, uint8_t tei, uint8_t sapi)
 	if (!link)
 		return -EINVAL;
 
+	isd.line = ts->line;
 	isd.link_type = link->type;
 	isd.trx = link->trx;
 	isd.tei = tei;
diff --git a/openbsc/src/libabis/input/dahdi.c b/openbsc/src/libabis/input/dahdi.c
index a7b45a1..eb66fa0 100644
--- a/openbsc/src/libabis/input/dahdi.c
+++ b/openbsc/src/libabis/input/dahdi.c
@@ -100,7 +100,7 @@ static int handle_ts1_read(struct osmo_fd *bfd)
 	struct msgb *msg = msgb_alloc(TS1_ALLOC_SIZE, "DAHDI TS1");
 	lapd_mph_type prim;
 	unsigned int sapi, tei;
-	int ilen, ret;
+	int ilen, ret, error = 0;
 	uint8_t *idata;
 
 	if (!msg)
@@ -122,9 +122,21 @@ static int handle_ts1_read(struct osmo_fd *bfd)
 
 	DEBUGP(DMI, "<= len = %d, sapi(%d) tei(%d)", ret, sapi, tei);
 
-	idata = lapd_receive(e1i_ts->driver.dahdi.lapd, msg->data, msg->len, &ilen, &prim);
-	if (!idata && prim == 0)
-		return -EIO;
+	idata = lapd_receive(e1i_ts->driver.dahdi.lapd, msg->data, msg->len, &ilen, &prim, &error);
+	if (!idata) {
+		switch(error) {
+		case LAPD_ERR_UNKNOWN_TEI:
+			/* We don't know about this TEI, probably the BSC
+			 * lost local states (it crashed or it was stopped),
+			 * notify the driver to see if it can do anything to
+			 * recover the existing signalling links with the BTS.
+			 */
+			e1inp_event(e1i_ts, S_INP_TEI_UNKNOWN, tei, sapi);
+			return -EIO;
+		}
+		if (prim == 0)
+			return -EIO;
+	}
 
 	msgb_pull(msg, 2);
 
diff --git a/openbsc/src/libabis/input/lapd.c b/openbsc/src/libabis/input/lapd.c
index 66ff05e..2934b58 100644
--- a/openbsc/src/libabis/input/lapd.c
+++ b/openbsc/src/libabis/input/lapd.c
@@ -310,8 +310,9 @@ static void lapd_tei_receive(struct lapd_instance *li, uint8_t *data, int len)
 };
 
 /* General input function for any data received for this LAPD instance */
-uint8_t *lapd_receive(struct lapd_instance *li, uint8_t * data, unsigned int len,
-		      int *ilen, lapd_mph_type *prim)
+uint8_t *
+lapd_receive(struct lapd_instance *li, uint8_t * data, unsigned int len,
+	     int *ilen, lapd_mph_type *prim, int *error)
 {
 	uint8_t sapi, cr, tei, command;
 	int pf, ns, nr;
@@ -327,12 +328,14 @@ uint8_t *lapd_receive(struct lapd_instance *li, uint8_t * data, unsigned int len
 
 	if (len < 2) {
 		LOGP(DMI, LOGL_ERROR, "LAPD receive len %d < 2, ignoring\n", len);
+		*error = LAPD_ERR_BAD_LEN;
 		return NULL;
 	};
 
 	if ((data[0] & 1) != 0 || (data[1] & 1) != 1) {
 		LOGP(DMI, LOGL_ERROR, "LAPD address field %x/%x not well formed\n",
 			data[0], data[1]);
+		*error = LAPD_ERR_BAD_ADDR;
 		return NULL;
 	};
 
@@ -344,6 +347,7 @@ uint8_t *lapd_receive(struct lapd_instance *li, uint8_t * data, unsigned int len
 
 	if (len < 3) {
 		LOGP(DMI, LOGL_ERROR, "LAPD receive len %d < 3, ignoring\n", len);
+		*error = LAPD_ERR_BAD_LEN;
 		return NULL;
 	};
 
@@ -356,6 +360,7 @@ uint8_t *lapd_receive(struct lapd_instance *li, uint8_t * data, unsigned int len
 		typ = LAPD_TYPE_I;
 		if (len < 4) {
 			LOGP(DMI, LOGL_ERROR, "LAPD I frame, len %d < 4\n", len);
+			*error = LAPD_ERR_BAD_LEN;
 			return NULL;
 		}
 		ns = data[2] >> 1;
@@ -366,6 +371,7 @@ uint8_t *lapd_receive(struct lapd_instance *li, uint8_t * data, unsigned int len
 		typ = LAPD_TYPE_S;
 		if (len < 4) {
 			LOGP(DMI, LOGL_ERROR, "LAPD S frame, len %d < 4\n", len);
+			*error = LAPD_ERR_BAD_LEN;
 			return NULL;
 		}
 		nr = data[3] >> 1;
@@ -382,6 +388,7 @@ uint8_t *lapd_receive(struct lapd_instance *li, uint8_t * data, unsigned int len
 			break;
 		default:
 			LOGP(DMI, LOGL_ERROR, "LAPD unknown S cmd %x\n", data[2]);
+			*error = LAPD_ERR_UNKNOWN_S_CMD;
 			return NULL;
 		};
 	} else if ((data[2] & 3) == 3) {
@@ -414,6 +421,7 @@ uint8_t *lapd_receive(struct lapd_instance *li, uint8_t * data, unsigned int len
 		default:
 			LOGP(DMI, LOGL_ERROR, "LAPD unknown U cmd %x "
 			     "(pf %x data %x)\n", val, pf, data[2]);
+			*error = LAPD_ERR_UNKNOWN_U_CMD;
 			return NULL;
 		};
 	};
@@ -429,6 +437,7 @@ uint8_t *lapd_receive(struct lapd_instance *li, uint8_t * data, unsigned int len
 	teip = teip_from_tei(li, tei);
 	if (!teip) {
 		LOGP(DMI, LOGL_NOTICE, "LAPD Unknown TEI %u\n", tei);
+		*error = LAPD_ERR_UNKNOWN_TEI;
 		return NULL;
 	}
 
@@ -587,6 +596,7 @@ uint8_t *lapd_receive(struct lapd_instance *li, uint8_t * data, unsigned int len
 		return contents;
 	}
 
+	*error = LAPD_ERR_BAD_CMD;
 	return NULL;
 };
 
diff --git a/openbsc/src/libabis/input/lapd.h b/openbsc/src/libabis/input/lapd.h
index fb980d1..dd22028 100644
--- a/openbsc/src/libabis/input/lapd.h
+++ b/openbsc/src/libabis/input/lapd.h
@@ -26,8 +26,20 @@ struct lapd_instance {
 	struct llist_head tei_list;	/* list of TEI in this LAPD instance */
 };
 
-extern uint8_t *lapd_receive(struct lapd_instance *li, uint8_t *data, unsigned int len,
-			     int *ilen, lapd_mph_type *prim);
+enum lapd_recv_errors {
+	LAPD_ERR_NONE = 0,
+	LAPD_ERR_BAD_LEN,
+	LAPD_ERR_BAD_ADDR,
+	LAPD_ERR_UNKNOWN_S_CMD,
+	LAPD_ERR_UNKNOWN_U_CMD,
+	LAPD_ERR_UNKNOWN_TEI,
+	LAPD_ERR_BAD_CMD,
+	__LAPD_ERR_MAX
+};
+
+extern uint8_t *lapd_receive(struct lapd_instance *li, uint8_t *data,
+			     unsigned int len, int *ilen, lapd_mph_type *prim,
+			     int *error);
 
 extern void lapd_transmit(struct lapd_instance *li, uint8_t tei, uint8_t sapi,
 			  uint8_t *data, unsigned int len);
-- 
1.7.1




From pablo at gnumonks.org  Tue Aug  9 23:35:51 2011
From: pablo at gnumonks.org (pablo at gnumonks.org)
Date: Wed, 10 Aug 2011 01:35:51 +0200
Subject: [PATCH 2/3] NOKIA: Resend SABM on unknown TEI from LAPD
In-Reply-To: <1312932952-5197-1-git-send-email-pablo@gnumonks.org>
References: <1312932952-5197-1-git-send-email-pablo@gnumonks.org>
Message-ID: <1312932952-5197-3-git-send-email-pablo@gnumonks.org>

From: Pablo Neira Ayuso <pablo at gnumonks.org>

---
 openbsc/src/libbsc/bts_nokia_site.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/openbsc/src/libbsc/bts_nokia_site.c b/openbsc/src/libbsc/bts_nokia_site.c
index 6d14bdd..b5bc2fe 100644
--- a/openbsc/src/libbsc/bts_nokia_site.c
+++ b/openbsc/src/libbsc/bts_nokia_site.c
@@ -84,7 +84,7 @@ static int shutdown_om(struct gsm_bts *bts)
   Attention: this has to be adapted for mISDN
 */
 
-static void start_sabm_in_line(struct e1inp_line *line, int start, int sapi)
+void start_sabm_in_line(struct e1inp_line *line, int start, int sapi)
 {
 	struct e1inp_sign_link *link;
 	int i;
@@ -162,6 +162,13 @@ static int inp_sig_cb(unsigned int subsys, unsigned int signal,
 			break;
 		}
 		break;
+	case S_INP_TEI_UNKNOWN:
+		/* We are receiving LAPD frames with one TEI that we do not
+		 * seem to know, likely that we (the BSC) stopped working
+		 * and lost our local states. However, the BTS is already
+		 * configured, we try to take over the RSL links. */
+		start_sabm_in_line(isd->line, 1, SAPI_RSL);
+		break;
 	}
 
 	return 0;
-- 
1.7.1




From pablo at gnumonks.org  Tue Aug  9 23:35:52 2011
From: pablo at gnumonks.org (pablo at gnumonks.org)
Date: Wed, 10 Aug 2011 01:35:52 +0200
Subject: [PATCH 3/3] mncc: promote log level from debug to errors
In-Reply-To: <1312932952-5197-1-git-send-email-pablo@gnumonks.org>
References: <1312932952-5197-1-git-send-email-pablo@gnumonks.org>
Message-ID: <1312932952-5197-4-git-send-email-pablo@gnumonks.org>

From: Daniel Willmann <daniel at totalueberwachung.de>

These should not be debug messages, instead they should be
error messages.
---
 openbsc/src/libmsc/gsm_04_08.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c
index e710f83..bd452ed 100644
--- a/openbsc/src/libmsc/gsm_04_08.c
+++ b/openbsc/src/libmsc/gsm_04_08.c
@@ -1602,7 +1602,7 @@ static int tch_map(struct gsm_lchan *lchan, struct gsm_lchan *remote_lchan)
 		remote_bts->nr, remote_lchan->ts->trx->nr, remote_lchan->ts->nr);
 
 	if (bts->type != remote_bts->type) {
-		DEBUGP(DCC, "Cannot switch calls between different BTS types yet\n");
+		LOGP(DCC, LOGL_ERROR, "Cannot switch calls between different BTS types yet\n");
 		return -EINVAL;
 	}
 
@@ -1638,7 +1638,7 @@ static int tch_map(struct gsm_lchan *lchan, struct gsm_lchan *remote_lchan)
 		trau_mux_map_lchan(lchan, remote_lchan);
 		break;
 	default:
-		DEBUGP(DCC, "Unknown BTS type %u\n", bts->type);
+		LOGP(DCC, LOGL_ERROR, "Unknown BTS type %u\n", bts->type);
 		return -EINVAL;
 	}
 
@@ -1681,7 +1681,7 @@ static int tch_recv_mncc(struct gsm_network *net, uint32_t callref, int enable)
 	switch (bts->type) {
 	case GSM_BTS_TYPE_NANOBTS:
 		if (ipacc_rtp_direct) {
-			DEBUGP(DCC, "Error: RTP proxy is disabled\n");
+			LOGP(DCC, LOGL_ERROR, "Error: RTP proxy is disabled\n");
 			return -EINVAL;
 		}
 		/* in case, we don't have a RTP socket yet, we note this
@@ -1711,7 +1711,7 @@ static int tch_recv_mncc(struct gsm_network *net, uint32_t callref, int enable)
 		return trau_mux_unmap(NULL, callref);
 		break;
 	default:
-		DEBUGP(DCC, "Unknown BTS type %u\n", bts->type);
+		LOGP(DCC, LOGL_ERROR, "Unknown BTS type %u\n", bts->type);
 		return -EINVAL;
 	}
 
@@ -2994,7 +2994,7 @@ int mncc_tx_to_cc(struct gsm_network *net, int msg_type, void *arg)
 		case GSM_BTS_TYPE_NOKIA_SITE:
 			return trau_send_frame(trans->conn->lchan, arg);
 		default:
-			DEBUGP(DCC, "Unknown BTS type %u\n", bts->type);
+			LOGP(DCC, LOGL_ERROR, "Unknown BTS type %u\n", bts->type);
 		}
 		return -EINVAL;
 	}
-- 
1.7.1




From laforge at gnumonks.org  Wed Aug 10 08:52:11 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 10 Aug 2011 10:52:11 +0200
Subject: [PATCH 0/3] updates for Nokia support
In-Reply-To: <1312932952-5197-1-git-send-email-pablo@gnumonks.org>
References: <1312932952-5197-1-git-send-email-pablo@gnumonks.org>
Message-ID: <20110810085211.GW23523@prithivi.gnumonks.org>

Hi pablo,

On Wed, Aug 10, 2011 at 01:35:49AM +0200, pablo at gnumonks.org wrote:
> This patchset contains two updates for the Nokia support
> in the following scenario: the BSC stops after having
> configured the BTS, then the BTS is launched again but
> LAPD reports unknown TEI. To fix this, we report to the
> E1 driver about unknown TEI so it can resend the SABM
> message.

I've applied it on top of spaar/nokia, and merged everything to master.

This means the 'spaar/nokia' branch is now gone and everything is in
master.

-- 
- 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 pablo at gnumonks.org  Wed Aug 10 12:06:34 2011
From: pablo at gnumonks.org (pablo at gnumonks.org)
Date: Wed, 10 Aug 2011 14:06:34 +0200
Subject: [PATCH 0/2] couple of openbsc fixes
Message-ID: <1312977996-15789-1-git-send-email-pablo@gnumonks.org>

From: Pablo Neira Ayuso <pablo at gnumonks.org>

Hi Harald,

These are a couple of fixes that we have applied to openBSC
in the CCC camp. Daniel's fixes a crash, mine fixes one
malformed TCH frame issue which was the cause of quite often
unexpected closures of MNCC <-> LCR connections.

You can find them in the fixes branch.
Please, merge them.

Daniel Willmann (1):
  libbsc: Don't free secondary lchan if it is NULL.

Pablo Neira Ayuso (1):
  trau: fix wrong message size for GSM_TCHF_FRAME passed to MNCC

 openbsc/src/libbsc/bsc_api.c   |    6 +++++-
 openbsc/src/libtrau/trau_mux.c |    1 +
 2 files changed, 6 insertions(+), 1 deletions(-)

-- 
1.7.2.5




From pablo at gnumonks.org  Wed Aug 10 12:06:35 2011
From: pablo at gnumonks.org (pablo at gnumonks.org)
Date: Wed, 10 Aug 2011 14:06:35 +0200
Subject: [PATCH 1/2] trau: fix wrong message size for GSM_TCHF_FRAME passed to
	MNCC
In-Reply-To: <1312977996-15789-1-git-send-email-pablo@gnumonks.org>
References: <1312977996-15789-1-git-send-email-pablo@gnumonks.org>
Message-ID: <1312977996-15789-2-git-send-email-pablo@gnumonks.org>

From: Pablo Neira Ayuso <pablo at gnumonks.org>

During the GSM deployment in the CCC Camp, Daniel Willmann
noticed that the LCR and the MNCC were closing the local
connection over unix sockets communication quite so often.

After some debugging, Peter Stuge noticed that openBSC was
closing the connection since write was returning 0.

Then, I suggested that it could be a malformed message with
zero length. By skipping empty messages, Peter confirmed that
the connection between the LCR and the MNCC was not closing
anymore. However, there was no voice in the calls that went
over MNCC.

After some more debugging I found that we were not building
GSM_TCHF_FRAME over MNCC appropriately in the TRAU multiplexer
code, since we forgot to msgb_put() the message.
---
 openbsc/src/libtrau/trau_mux.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/openbsc/src/libtrau/trau_mux.c b/openbsc/src/libtrau/trau_mux.c
index b8b90bd..5ae5ed7 100644
--- a/openbsc/src/libtrau/trau_mux.c
+++ b/openbsc/src/libtrau/trau_mux.c
@@ -212,6 +212,7 @@ int trau_mux_input(struct gsm_e1_subslot *src_e1_ss,
 		}
 		frame->msg_type = GSM_TCHF_FRAME;
 		frame->callref = ue->callref;
+		msgb_put(msg, sizeof(struct gsm_data_frame) + 33);
 		trau_tx_to_mncc(ue->net, msg);
 
 		return 0;
-- 
1.7.2.5




From pablo at gnumonks.org  Wed Aug 10 12:06:36 2011
From: pablo at gnumonks.org (pablo at gnumonks.org)
Date: Wed, 10 Aug 2011 14:06:36 +0200
Subject: [PATCH 2/2] libbsc: Don't free secondary lchan if it is NULL.
In-Reply-To: <1312977996-15789-1-git-send-email-pablo@gnumonks.org>
References: <1312977996-15789-1-git-send-email-pablo@gnumonks.org>
Message-ID: <1312977996-15789-3-git-send-email-pablo@gnumonks.org>

From: Daniel Willmann <daniel at totalueberwachung.de>

---
 openbsc/src/libbsc/bsc_api.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/openbsc/src/libbsc/bsc_api.c b/openbsc/src/libbsc/bsc_api.c
index 70d6413..ab71ebb 100644
--- a/openbsc/src/libbsc/bsc_api.c
+++ b/openbsc/src/libbsc/bsc_api.c
@@ -137,7 +137,11 @@ static void assignment_t10_timeout(void *_conn)
 	LOGP(DMSC, LOGL_ERROR, "Assigment T10 timeout on %p\n", conn);
 
 	/* normal release on the secondary channel */
-	lchan_release(conn->secondary_lchan, 0, 1);
+	if (conn->secondary_lchan) {
+		lchan_release(conn->secondary_lchan, 0, 1);
+	} else {
+		LOGP(DMSC, LOGL_NOTICE, "Secondary lchan is NULL, not releasing\n");
+	}
 	conn->secondary_lchan = NULL;
 
 	/* inform them about the failure */
-- 
1.7.2.5




From laforge at gnumonks.org  Wed Aug 10 13:38:46 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 10 Aug 2011 15:38:46 +0200
Subject: [PATCH 0/2] couple of openbsc fixes
In-Reply-To: <1312977996-15789-1-git-send-email-pablo@gnumonks.org>
References: <1312977996-15789-1-git-send-email-pablo@gnumonks.org>
Message-ID: <20110810133846.GB5546@prithivi.gnumonks.org>

On Wed, Aug 10, 2011 at 02:06:34PM +0200, pablo at gnumonks.org wrote:

> These are a couple of fixes that we have applied to openBSC
> in the CCC camp. Daniel's fixes a crash, mine fixes one
> malformed TCH frame issue which was the cause of quite often
> unexpected closures of MNCC <-> LCR connections.

thanks, applied.

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



From laforge at gnumonks.org  Wed Aug 10 21:22:30 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 10 Aug 2011 23:22:30 +0200
Subject: [PATCH] RSL: add timer for lchan activation/deactivation without BTS
	response
Message-ID: <20110810212230.GF5546@prithivi.gnumonks.org>

The timer callback will simply reset the lchan state to NONE in order
to prevent channels getting stuck in 'activation requested' or
'deactivation requested' states.
---
 openbsc/src/libbsc/abis_rsl.c |   36 +++++++++++++++++++++++++++++++++++-
 1 files changed, 35 insertions(+), 1 deletions(-)

diff --git a/openbsc/src/libbsc/abis_rsl.c b/openbsc/src/libbsc/abis_rsl.c
index f20b4f2..239c8c8 100644
--- a/openbsc/src/libbsc/abis_rsl.c
+++ b/openbsc/src/libbsc/abis_rsl.c
@@ -178,6 +178,27 @@ static void print_rsl_cause(int lvl, const uint8_t *cause_v, uint8_t cause_len)
 		LOGPC(DRSL, lvl, "%02x ", cause_v[i]);
 }
 
+static void lchan_act_tmr_cb(void *data)
+{
+	struct gsm_lchan *lchan = data;
+
+	LOGP(DRSL, LOGL_NOTICE, "%s Timeout during activation!\n",
+		gsm_lchan_name(lchan));
+
+	lchan->state = LCHAN_S_NONE;
+}
+
+static void lchan_deact_tmr_cb(void *data)
+{
+	struct gsm_lchan *lchan = data;
+
+	LOGP(DRSL, LOGL_NOTICE, "%s Timeout during deactivation!\n",
+		gsm_lchan_name(lchan));
+
+	lchan->state = LCHAN_S_NONE;
+}
+
+
 /* Send a BCCH_INFO message as per Chapter 8.5.1 */
 int rsl_bcch_info(struct gsm_bts_trx *trx, uint8_t type,
 		  const uint8_t *data, int len)
@@ -609,6 +630,11 @@ static int rsl_rf_chan_release(struct gsm_lchan *lchan, int error)
 				   msg->trx->bts->network->T3111 + 2, 0);
 	}
 
+	/* Start another timer or assume the BTS sends a ACK/NACK? */
+	lchan->act_timer.cb = lchan_deact_tmr_cb;
+	lchan->act_timer.data = lchan;
+	osmo_timer_schedule(&lchan->act_timer, 4, 0);
+
 	rc =  abis_rsl_sendmsg(msg);
 
 	/* BTS will respond by RF CHAN REL ACK */
@@ -626,6 +652,8 @@ static int rsl_rx_rf_chan_rel_ack(struct gsm_lchan *lchan)
 
 	DEBUGP(DRSL, "%s RF CHANNEL RELEASE ACK\n", gsm_lchan_name(lchan));
 
+	osmo_timer_del(&lchan->act_timer);
+
 	if (lchan->state != LCHAN_S_REL_REQ && lchan->state != LCHAN_S_REL_ERR)
 		LOGP(DRSL, LOGL_NOTICE, "%s CHAN REL ACK but state %s\n",
 			gsm_lchan_name(lchan),
@@ -791,6 +819,8 @@ static int rsl_rx_chan_act_ack(struct msgb *msg)
 	if (rslh->ie_chan != RSL_IE_CHAN_NR)
 		return -EINVAL;
 
+	osmo_timer_del(&msg->lchan->act_timer);
+
 	if (msg->lchan->state != LCHAN_S_ACT_REQ)
 		LOGP(DRSL, LOGL_NOTICE, "%s CHAN ACT ACK, but state %s\n",
 			gsm_lchan_name(msg->lchan),
@@ -1257,7 +1287,11 @@ static int rsl_rx_chan_rqd(struct msgb *msg)
 	lchan->rsl_cmode = RSL_CMOD_SPD_SIGN;
 	lchan->tch_mode = GSM48_CMODE_SIGN;
 
-	/* FIXME: Start another timer or assume the BTS sends a ACK/NACK? */
+	/* Start another timer or assume the BTS sends a ACK/NACK? */
+	lchan->act_timer.cb = lchan_act_tmr_cb;
+	lchan->act_timer.data = lchan;
+	osmo_timer_schedule(&lchan->act_timer, 4, 0);
+
 	rsl_chan_activate_lchan(lchan, 0x00, rqd_ta, 0);
 
 	DEBUGP(DRSL, "%s Activating ARFCN(%u) SS(%u) lctype %s "
-- 
1.7.5.4



From laforge at gnumonks.org  Wed Aug 10 21:26:33 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 10 Aug 2011 23:26:33 +0200
Subject: [PATCH] RSL: add timer for lchan activation/deactivation without
	BTS response
In-Reply-To: <20110810212230.GF5546@prithivi.gnumonks.org>
References: <20110810212230.GF5546@prithivi.gnumonks.org>
Message-ID: <20110810212633.GG5546@prithivi.gnumonks.org>

The timer callback will simply reset the lchan state to NONE in order
to prevent channels getting stuck in 'activation requested' or
'deactivation requested' states.
---
 THIS TIME WITH REQURED HEADER CHANGE
 openbsc/include/openbsc/gsm_data_shared.h |    1 +
 openbsc/src/libbsc/abis_rsl.c             |   38 ++++++++++++++++++++++++++++-
 2 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/openbsc/include/openbsc/gsm_data_shared.h b/openbsc/include/openbsc/gsm_data_shared.h
index e3ab5f4..89375cf 100644
--- a/openbsc/include/openbsc/gsm_data_shared.h
+++ b/openbsc/include/openbsc/gsm_data_shared.h
@@ -182,6 +182,7 @@ struct gsm_lchan {
 	struct osmo_timer_list T3101;
 	struct osmo_timer_list T3111;
 	struct osmo_timer_list error_timer;
+	struct osmo_timer_list act_timer;
 
 	/* table of neighbor cell measurements */
 	struct neigh_meas_proc neigh_meas[MAX_NEIGH_MEAS];
diff --git a/openbsc/src/libbsc/abis_rsl.c b/openbsc/src/libbsc/abis_rsl.c
index f20b4f2..8a326de 100644
--- a/openbsc/src/libbsc/abis_rsl.c
+++ b/openbsc/src/libbsc/abis_rsl.c
@@ -178,6 +178,27 @@ static void print_rsl_cause(int lvl, const uint8_t *cause_v, uint8_t cause_len)
 		LOGPC(DRSL, lvl, "%02x ", cause_v[i]);
 }
 
+static void lchan_act_tmr_cb(void *data)
+{
+	struct gsm_lchan *lchan = data;
+
+	LOGP(DRSL, LOGL_NOTICE, "%s Timeout during activation!\n",
+		gsm_lchan_name(lchan));
+
+	lchan->state = LCHAN_S_NONE;
+}
+
+static void lchan_deact_tmr_cb(void *data)
+{
+	struct gsm_lchan *lchan = data;
+
+	LOGP(DRSL, LOGL_NOTICE, "%s Timeout during deactivation!\n",
+		gsm_lchan_name(lchan));
+
+	lchan->state = LCHAN_S_NONE;
+}
+
+
 /* Send a BCCH_INFO message as per Chapter 8.5.1 */
 int rsl_bcch_info(struct gsm_bts_trx *trx, uint8_t type,
 		  const uint8_t *data, int len)
@@ -609,6 +630,11 @@ static int rsl_rf_chan_release(struct gsm_lchan *lchan, int error)
 				   msg->trx->bts->network->T3111 + 2, 0);
 	}
 
+	/* Start another timer or assume the BTS sends a ACK/NACK? */
+	lchan->act_timer.cb = lchan_deact_tmr_cb;
+	lchan->act_timer.data = lchan;
+	osmo_timer_schedule(&lchan->act_timer, 4, 0);
+
 	rc =  abis_rsl_sendmsg(msg);
 
 	/* BTS will respond by RF CHAN REL ACK */
@@ -626,6 +652,8 @@ static int rsl_rx_rf_chan_rel_ack(struct gsm_lchan *lchan)
 
 	DEBUGP(DRSL, "%s RF CHANNEL RELEASE ACK\n", gsm_lchan_name(lchan));
 
+	osmo_timer_del(&lchan->act_timer);
+
 	if (lchan->state != LCHAN_S_REL_REQ && lchan->state != LCHAN_S_REL_ERR)
 		LOGP(DRSL, LOGL_NOTICE, "%s CHAN REL ACK but state %s\n",
 			gsm_lchan_name(lchan),
@@ -791,6 +819,8 @@ static int rsl_rx_chan_act_ack(struct msgb *msg)
 	if (rslh->ie_chan != RSL_IE_CHAN_NR)
 		return -EINVAL;
 
+	osmo_timer_del(&msg->lchan->act_timer);
+
 	if (msg->lchan->state != LCHAN_S_ACT_REQ)
 		LOGP(DRSL, LOGL_NOTICE, "%s CHAN ACT ACK, but state %s\n",
 			gsm_lchan_name(msg->lchan),
@@ -815,6 +845,8 @@ static int rsl_rx_chan_act_nack(struct msgb *msg)
 	struct abis_rsl_dchan_hdr *dh = msgb_l2(msg);
 	struct tlv_parsed tp;
 
+	osmo_timer_del(&msg->lchan->act_timer);
+
 	LOGP(DRSL, LOGL_ERROR, "%s CHANNEL ACTIVATE NACK",
 		gsm_lchan_name(msg->lchan));
 
@@ -1257,7 +1289,11 @@ static int rsl_rx_chan_rqd(struct msgb *msg)
 	lchan->rsl_cmode = RSL_CMOD_SPD_SIGN;
 	lchan->tch_mode = GSM48_CMODE_SIGN;
 
-	/* FIXME: Start another timer or assume the BTS sends a ACK/NACK? */
+	/* Start another timer or assume the BTS sends a ACK/NACK? */
+	lchan->act_timer.cb = lchan_act_tmr_cb;
+	lchan->act_timer.data = lchan;
+	osmo_timer_schedule(&lchan->act_timer, 4, 0);
+
 	rsl_chan_activate_lchan(lchan, 0x00, rqd_ta, 0);
 
 	DEBUGP(DRSL, "%s Activating ARFCN(%u) SS(%u) lctype %s "
-- 
1.7.5.4




From pablo at gnumonks.org  Thu Aug 11 11:24:18 2011
From: pablo at gnumonks.org (pablo at gnumonks.org)
Date: Thu, 11 Aug 2011 13:24:18 +0200
Subject: [PATCH] logging: fix parsing of logging mask (-d DMI case)
Message-ID: <1313061858-3041-1-git-send-email-pablo@gnumonks.org>

From: Pablo Neira Ayuso <pablo at gnumonks.org>

Without this patch, `-d DMI' enables logging for DMI and DMIB.

Signed-off-by: Pablo Neira Ayuso <pablo at gnumonks.org>
---
 src/logging.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/src/logging.c b/src/logging.c
index 11d63ac..e85e8fc 100644
--- a/src/logging.c
+++ b/src/logging.c
@@ -157,6 +157,11 @@ void log_parse_category_mask(struct log_target* target, const char *_mask)
 		for (i = 0; i < osmo_log_info->num_cat; ++i) {
 			char* colon = strstr(category_token, ",");
 			int length = strlen(category_token);
+			int cat_length = strlen(osmo_log_info->cat[i].name);
+
+			/* Use longest length not to match subocurrences. */
+			if (cat_length > length)
+				length = cat_length;
 
 			if (!osmo_log_info->cat[i].name)
 				continue;
-- 
1.7.2.5




From laforge at gnumonks.org  Thu Aug 11 12:33:39 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 11 Aug 2011 14:33:39 +0200
Subject: [PATCH] logging: fix parsing of logging mask (-d DMI case)
In-Reply-To: <1313061858-3041-1-git-send-email-pablo@gnumonks.org>
References: <1313061858-3041-1-git-send-email-pablo@gnumonks.org>
Message-ID: <20110811123339.GB2105@prithivi.gnumonks.org>

On Thu, Aug 11, 2011 at 01:24:18PM +0200, pablo at gnumonks.org wrote:
> From: Pablo Neira Ayuso <pablo at gnumonks.org>
> 
> Without this patch, `-d DMI' enables logging for DMI and DMIB.

thanks, merged to master.
-- 
- 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 earlenceferns at gmail.com  Thu Aug 11 15:19:02 2011
From: earlenceferns at gmail.com (Earlence Fernandes)
Date: Thu, 11 Aug 2011 20:49:02 +0530
Subject: Voice Data Interception in OpenBSC
Message-ID: <CA+ve00S6FTFG8FKaFro8yBNnguoVT-5b2+VJQn+Jqv4go6maQQ@mail.gmail.com>

Hello,

We are trying to use OpenBSC to build a few prototype services for a GSM
network.
As such, I need to know where in the code I can intercept the voice data
that is received from an MS in the BTS.

Ideally, I would like to have intercept points in the outgoing (to MS) and
incoming (from MS) at the BTS in software.

Note: I have just started to read the source code of OpenBSC, and as it is
quite extensive, a few pointers will be useful.

Feel free to correct me if I'm way off base here.

-Earlence
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110811/89c68bc4/attachment.htm>

From akibsayyed at gmail.com  Fri Aug 12 16:23:48 2011
From: akibsayyed at gmail.com (Akib Sayyed)
Date: Fri, 12 Aug 2011 21:53:48 +0530
Subject: Increasing Range of nano bts
Message-ID: <CAMG-S90cD=Lo6m1dpTVaVO5eH9QZ95UwGApBLdqzkedYP=-=tA@mail.gmail.com>

hello guys i was wondering if we can increase range of nanoBTS for GSM. as
it is having external antenna support using power amplifier.
is it possible??

-- 
Akib Sayyed
Matrix-Shell
akibsayyed at gmail.com
akibsayyed at matrixshell.com
Mob:- +91-966-514-2243
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110812/743b648c/attachment.htm>

From admin at manateeshome.com  Fri Aug 12 17:36:57 2011
From: admin at manateeshome.com (Seungju Kim)
Date: Sat, 13 Aug 2011 02:36:57 +0900
Subject: Increasing Range of nano bts
In-Reply-To: <CAMG-S90cD=Lo6m1dpTVaVO5eH9QZ95UwGApBLdqzkedYP=-=tA@mail.gmail.com>
References: <CAMG-S90cD=Lo6m1dpTVaVO5eH9QZ95UwGApBLdqzkedYP=-=tA@mail.gmail.com>
Message-ID: <A6C64F88-3485-4BC6-875F-2E3846C7C7DC@manateeshome.com>

Surely it is possible

Envoy? de mon iPhone

Le Aug 13, 2011 ? 1:23 AM, Akib Sayyed <akibsayyed at gmail.com> a ?crit :

> hello guys i was wondering if we can increase range of nanoBTS for GSM. as it is having external antenna support using power amplifier.
> is it possible??
> 
> -- 
> Akib Sayyed
> Matrix-Shell
> akibsayyed at gmail.com
> akibsayyed at matrixshell.com
> Mob:- +91-966-514-2243
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110813/fb2f7a71/attachment.htm>

From akibsayyed at gmail.com  Sat Aug 13 03:44:54 2011
From: akibsayyed at gmail.com (Akib Sayyed)
Date: Sat, 13 Aug 2011 09:14:54 +0530
Subject: Cloning comp128v2,v3 sim cards for openbsc authetication
Message-ID: <CAMG-S93jm9c_hqNi_SMB7pbXf68koiHvd8d144f7s39jqVFbmQ@mail.gmail.com>

guys is it possible to clone comp128v2,v3 sim?
also how can we read ki of compv2,v3 sim. and if i have ki from comp126v2,v3
sim then can i make comp128v1 sim??


-- 
Akib Sayyed
Matrix-Shell
akibsayyed at gmail.com
akibsayyed at matrixshell.com
Mob:- +91-966-514-2243
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110813/d0b51e4d/attachment.htm>

From admin at manateeshome.com  Sat Aug 13 06:47:49 2011
From: admin at manateeshome.com (Seungju Kim)
Date: Sat, 13 Aug 2011 15:47:49 +0900
Subject: Cloning comp128v2,v3 sim cards for openbsc authetication
In-Reply-To: <CAMG-S93jm9c_hqNi_SMB7pbXf68koiHvd8d144f7s39jqVFbmQ@mail.gmail.com>
References: <CAMG-S93jm9c_hqNi_SMB7pbXf68koiHvd8d144f7s39jqVFbmQ@mail.gmail.com>
Message-ID: <DEAD66DD-5B65-483F-AFFC-E6E73C2619FE@manateeshome.com>


> guys is it possible to clone comp128v2,v3 sim? 

No,
> also how can we read ki of compv2,v3 sim.
We cannot read the ki of compv2 or v3
> and if i have ki from comp126v2,v3 sim then can i make comp128v1 
I do not understand this question....

> 
> 
> -- 
> Akib Sayyed
> Matrix-Shell
> akibsayyed at gmail.com
> akibsayyed at matrixshell.com
> Mob:- +91-966-514-2243
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110813/21d13c0d/attachment.htm>

From n6vale at googlemail.com  Mon Aug 15 09:33:08 2011
From: n6vale at googlemail.com (Simon Barnett)
Date: Mon, 15 Aug 2011 10:33:08 +0100
Subject: OpenBSC and MMS
Message-ID: <CAPU+0YR0zijqrjhBptK-r+ZCexk3+bfA0MX1Fso+Cw2uGgw7eA@mail.gmail.com>

Hi all,

I would like to test sending MMS messages to mobile devices.  Out of
the box I know OpenBSC supports SMS, which I have been able to use,
however, I feel that MMS will be more tricky.  My initial thoughts are
to set up OpenBSC with GPRS using this: -

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

And then try to bolt some kind of MMS support on top.  Before I get
started though, I was wondering if anyone had done this before and/or
had any ideas as to how I might go about implementing this.

I really would appreciate any guidance anyone could offer me.

Thanks in advance,

Simon



From gus at bourg.net  Mon Aug 15 18:54:55 2011
From: gus at bourg.net (Gus Bourg)
Date: Mon, 15 Aug 2011 11:54:55 -0700
Subject: OpenBSC and MMS
In-Reply-To: <CAPU+0YR0zijqrjhBptK-r+ZCexk3+bfA0MX1Fso+Cw2uGgw7eA@mail.gmail.com>
References: <CAPU+0YR0zijqrjhBptK-r+ZCexk3+bfA0MX1Fso+Cw2uGgw7eA@mail.gmail.com>
Message-ID: <CAKL=SEo1we=s-P5sABucRAvKb9y3nUkfd4r7oAR+Fbzyt9sN3A@mail.gmail.com>

You're on the right path - but there are a couple of things you should be
aware of.

First, for MO (Mobile Orignated) MMS - it's quite straight forward: The
Mobile Device sends an HTTP POST to the MMSC.  However, there is one very
important detail missing: identity management.  In order for the MMSC to
know "who" you are (aka who is posting the MMS Message), it relies on what
has been traditionally known as a "WAP Gateway".  In the WAP2 Context, this
is an HTTP Proxy (WAP1 has its own stack for communication between the
mobile and the WAPGW).  Usually, when you create a PDP Context, the GGSN
will send a RADIUS Accounting message to the WAP Gateway.  This gives the
WAP Gateway you Mobile IP Address and your Phone Number.  When you do the
HTTP POST to the MMSC, the MMSC relies on the WAP Gateway appending your
Phone Number (MSISDN) as an HTTP Request header.  For security reasons, the
MMSC is never directly accessible by the Mobile - only via the WAP Gateway.

So in order to support MO Originated MMS the following need to happen:
1) OpenGGSN needs to send RADIUS
2) An HTTP Proxy that appends the MSISDN as an HTTP Request Header needs to
be had


Second, for MT (Mobile Terminated) MMS - you need everything for MO plus you
need a Push Proxy Gateway.  That is, once an MMS is placed on your MMS it
needs to alert the subscriber that they have an MMS waiting.  This is done
by Posting an MMS Encapsulated MMS Notification to the PPG - with the
subscriber's MSISDN as the recipient.  The PPG will then encapsulate the
message, and send it as one or more specially crafted SMS's (typically via
SMPP).  Once the mobile receives the MMS notification, it'll retrieve the
MMS Content Location from the Notification.  It then sends an HTTP GET via
the WAPGW to the MMS Location (this is a unique url like
http://mmsc.carrier.com/fklvu348f9gervrfd).  The WAPGW will append the
MSISDN as a request header, and the MMSC will validate that the requester
(based on MSISDN in request header) is the owner of the message.  If so, the
response to the HTTP request will be the actual MMS Message.


So in addition to the requirements for MO Originated MMS, MT MMS also
requires:
1) A Push Proxy Gateway

There are opensource PPGs available (See: Kannel).  Where the challenge is,
is that OpenBSC does not have an SMPP Interface today (at least not
osmo-nitb).

I believe there's also an opensource MMSC available today.  Additionally, I
have written my own PPG and MMSC and could assist if you have questions on
these.  The biggest challenge, I think is the SMPP Interface to OpenBSC.
Hacking RADIUS into openggsn, and hacking squid to support radius request
headers (it may already support it?) seem very simple by comparison.

Thanks,
Gus


On Mon, Aug 15, 2011 at 2:33 AM, Simon Barnett <n6vale at googlemail.com>wrote:

> Hi all,
>
> I would like to test sending MMS messages to mobile devices.  Out of
> the box I know OpenBSC supports SMS, which I have been able to use,
> however, I feel that MMS will be more tricky.  My initial thoughts are
> to set up OpenBSC with GPRS using this: -
>
> http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS
>
> And then try to bolt some kind of MMS support on top.  Before I get
> started though, I was wondering if anyone had done this before and/or
> had any ideas as to how I might go about implementing this.
>
> I really would appreciate any guidance anyone could offer me.
>
> Thanks in advance,
>
> Simon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110815/44a367bd/attachment.htm>

From laforge at gnumonks.org  Tue Aug 16 09:02:25 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 16 Aug 2011 11:02:25 +0200
Subject: OpenBSC and MMS
In-Reply-To: <CAKL=SEo1we=s-P5sABucRAvKb9y3nUkfd4r7oAR+Fbzyt9sN3A@mail.gmail.com>
References: <CAPU+0YR0zijqrjhBptK-r+ZCexk3+bfA0MX1Fso+Cw2uGgw7eA@mail.gmail.com>
	<CAKL=SEo1we=s-P5sABucRAvKb9y3nUkfd4r7oAR+Fbzyt9sN3A@mail.gmail.com>
Message-ID: <20110816090225.GC23483@prithivi.gnumonks.org>

Hi Gus and others,

On Mon, Aug 15, 2011 at 11:54:55AM -0700, Gus Bourg wrote:

> So in order to support MO Originated MMS the following need to happen:
> 1) OpenGGSN needs to send RADIUS
> 2) An HTTP Proxy that appends the MSISDN as an HTTP Request Header needs to
> be had

Well, I'm not sure if it absolutely has to be radius based.  Of course,
it would be industry standard.  But I guess a quicker/simpler solution
could be invented, where the GGSN directly sends a simple "Source IP,
MSISDN, IMSI" tuple to the proxy.

> There are opensource PPGs available (See: Kannel).  Where the challenge is,
> is that OpenBSC does not have an SMPP Interface today (at least not
> osmo-nitb).

I don't think we want to add this to osmo-nitb.  Rather, we want to
externalize the entire SMS processing from the osmo-nitb process.  That
external process could then be interfaced using SMPP or other SMS
related protocols like EMI/UCP.

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



From peter.hasse at fokus.fraunhofer.de  Tue Aug 23 09:03:42 2011
From: peter.hasse at fokus.fraunhofer.de (Peter Hasse)
Date: Tue, 23 Aug 2011 11:03:42 +0200
Subject: How to fake Roaming?
Message-ID: <4E536CEE.1050300@fokus.fraunhofer.de>

Hi

We are planing to combine OpenBSC with our wifi mesh implementation in a 
static setup as a demo / testbed.
We would like to implement a roaming like behavior and have actually two 
approaches

1. Configuring a call forward on the phone so that it the "real" 
provider forwards the call to a number that we can route into the 
openBSC based network if the phone is not connected to its network. This 
would allow people to call "me" eager if i connected to the "real" 
network or the OpenBSC network.
Disadvantage would be that if I call somebody from the OpenBSC network 
the called party would not see the number from the "real" network.

2. Use a service like sipgate one. It would also allow a unified number 
for both "real" and OpenBSC network but if you call from the "real" 
network it has a different number.

Besides the unlikely way of real roaming with an carrier another option 
would be to fake the outgoing number. Does anybody know a service that 
could be used for that (i would need to fake a german GSM number).

Does anybody know how this is handled  on oil rigs or ships? Do they 
have a roaming agreement ?

thanks

mfg Peter



From 246tnt at gmail.com  Tue Aug 23 09:32:39 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Tue, 23 Aug 2011 11:32:39 +0200
Subject: How to fake Roaming?
In-Reply-To: <4E536CEE.1050300@fokus.fraunhofer.de>
References: <4E536CEE.1050300@fokus.fraunhofer.de>
Message-ID: <CAHL+j09xNdRqDaKZFqinAKA3GgZmPi+FZx5SoXYhxRnNc=Aotg@mail.gmail.com>

Hi,


> Besides the unlikely way of real roaming with an carrier another option
> would be to fake the outgoing number. Does anybody know a service that could
> be used for that (i would need to fake a german GSM number).

I know some SIP providers (like voipbuster) let you set the outgoing
caller ID. However those (often ?) require to register that caller ID
first and prove ownership of the number in question (SMS / test calls
/ ...)

> Does anybody know how this is handled ?on oil rigs or ships? Do they have a
> roaming agreement ?

On Waves ( http://www.on-waves.com/ ), the company that funded some
work on OpenBSC, does network on ships and they have "real" roaming
(SS7 connection / roaming agreements and everything AFAIK).


Cheers,

    Sylvain



From gus at bourg.net  Tue Aug 23 17:56:51 2011
From: gus at bourg.net (Gus Bourg)
Date: Tue, 23 Aug 2011 10:56:51 -0700
Subject: Multiple BTS's on one one E1?
Message-ID: <CAKL=SEpY989qYUDNY8iUWkMUE9kFprMc0vjtFstJCL=YRuCskQ@mail.gmail.com>

Hello all,

I'm attempting to connect multiple BTS's to one E1 card.  Each BTS is a
single TRX and I'm using a dahdi card plugged into a DCS.  The DCS maps the
channels as follows:

Name                Src                   Dest                  Speed
Type
--------------------------------------------------------------------------------
bscnok1             01.T1E1-A.02.01       01.T1E1-A.03.01       0256k D
FDX
bscnok2             01.T1E1-A.02.05       01.T1E1-A.04.01       0256k D
FDX
bscnok3             01.T1E1-A.01.09       01.T1E1-B.01.01       0256k D
FDX

So essentially:

TS 1,2,3,4 from OpenBSC (T1E1-A-02) are mapped to nok1 1,2,3,4 (T1E1-A-03)
TS 5,6,7,8 from OpenBSC (T1E1-A-02) are mapped to nok2 1,2,3,4 (T1E1-A-04)
TS 9,10,11,12 from OpenBSC (T1E1-A-02) are mapped to nok3 1,2,3,4
(T1E1-B-01)

This all works fine.  The BTS operates on TS1,2,3,4 on any of the ports I
have configured.  I just swap timeslots in openbsc.cfg from 1,2,3,4 to
5,6,7,8 or 9,10,11,12 and everything is happy.

Where I run into a problem is when I try to actually run multiple BTS's at
once.  So I take everything defined in "bts 0" and duplicate it as "bts 1".
I change the time slots for oml, rsl, and traffic channels to match the
appropriate channels for bts 1/2.  But when I go to start osmo-nitb I get an
error that it can't open /dev/dahdi/1 because it's already in use.  It
appears for some reason that it's attempting to open /dev/dahdi/1 for both
BTS's even though only bts 0 uses /dev/dahdi/1 for OML - bts 1 should use
/dev/dahdi/5 and bts 2 should use /dev/dahdi/9.

My /etc/dahdi/system.conf is defined as:
span=1,1,0,ccs,hdb3,crc4
bchan=2-4,6-8,10-12
dchan=1,5,9


I'm at a loss.  Has anyone tried to run multiple BTS's with dahdi on a
single E1 or T1 span?  Is there something special I need to specify so that
OpenBSC doesn't grab the first dchan for each BTS?

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

From laforge at gnumonks.org  Wed Aug 24 07:49:49 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 24 Aug 2011 09:49:49 +0200
Subject: Multiple BTS's on one one E1?
In-Reply-To: <CAKL=SEpY989qYUDNY8iUWkMUE9kFprMc0vjtFstJCL=YRuCskQ@mail.gmail.com>
References: <CAKL=SEpY989qYUDNY8iUWkMUE9kFprMc0vjtFstJCL=YRuCskQ@mail.gmail.com>
Message-ID: <20110824074949.GI22266@prithivi.gnumonks.org>

Hi Gus,

I hope the following two changes (see attachment) will solve the
problem.  They are already included in current libosmo-abis.git master.

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

From laforge at gnumonks.org  Wed Aug 24 07:45:11 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 24 Aug 2011 09:45:11 +0200
Subject: [PATCH 1/2] LAPD: Add function to release/free a LAPD instance
Message-ID: <mailman.40.1641744172.42898.openbsc@lists.osmocom.org>

---
 include/osmocom/abis/lapd.h |    1 +
 src/input/lapd.c            |    7 +++++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/include/osmocom/abis/lapd.h b/include/osmocom/abis/lapd.h
index dd22028..92dc2c3 100644
--- a/include/osmocom/abis/lapd.h
+++ b/include/osmocom/abis/lapd.h
@@ -48,6 +48,7 @@ struct lapd_instance *lapd_instance_alloc(int network_side,
 					  void (*tx_cb)(uint8_t *data, int len,
 							void *cbdata), void *cbdata);
 
+void lapd_instance_free(struct lapd_instance *li);
 
 /* Start a (user-side) SAP for the specified TEI/SAPI on the LAPD instance */
 int lapd_sap_start(struct lapd_instance *li, uint8_t tei, uint8_t sapi);
diff --git a/src/input/lapd.c b/src/input/lapd.c
index 0287e14..d94af58 100644
--- a/src/input/lapd.c
+++ b/src/input/lapd.c
@@ -730,3 +730,10 @@ struct lapd_instance *lapd_instance_alloc(int network_side,
 
 	return li;
 }
+
+void lapd_instance_free(struct lapd_instance *li)
+{
+	/* tei and sapis are allocated hierarchically of the lapd
+	 * instance, so one free is sufficient here */
+	talloc_free(li);
+}
-- 
1.7.5.4


--oJ71EGRlYNjSvfq7
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="0002-DAHDI-Make-sure-dahdi_e1_setup-can-be-called-multipl.patch"


From laforge at gnumonks.org  Wed Aug 24 07:45:36 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 24 Aug 2011 09:45:36 +0200
Subject: [PATCH 2/2] DAHDI: Make sure dahdi_e1_setup() can be called multiple
 times
Message-ID: <mailman.41.1641744172.42898.openbsc@lists.osmocom.org>

In case we have multiple BTS attached to the same E1 line, the
e1inp_driver::line_update() function will be called multiple times,
and we need to make sure this is handled gracefully.
---
 src/input/dahdi.c |   27 ++++++++++++++++++++++++---
 1 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/src/input/dahdi.c b/src/input/dahdi.c
index a4dbd03..66bf53f 100644
--- a/src/input/dahdi.c
+++ b/src/input/dahdi.c
@@ -393,6 +393,10 @@ static int dahdi_e1_setup(struct e1inp_line *line)
 		struct osmo_fd *bfd = &e1i_ts->driver.dahdi.fd;
 		int dev_nr;
 
+		/* unregister FD if it was already registered */
+		if (bfd->list.next && bfd->list.next != LLIST_POISON1)
+			osmo_fd_unregister(bfd);
+
 		/* DAHDI device names/numbers just keep incrementing
 		 * even over multiple boards.  So TS1 of the second
 		 * board will be 32 */
@@ -405,10 +409,20 @@ static int dahdi_e1_setup(struct e1inp_line *line)
 
 		switch (e1i_ts->type) {
 		case E1INP_TS_TYPE_NONE:
+			/* close/release LAPD instance, if any */
+			if (e1i_ts->lapd) {
+				lapd_instance_free(e1i_ts->lapd);
+				e1i_ts->lapd = NULL;
+			}
+			if (bfd->fd) {
+				close(bfd->fd);
+				bfd->fd = 0;
+			}
 			continue;
 			break;
 		case E1INP_TS_TYPE_SIGN:
-			bfd->fd = open(openstr, O_RDWR | O_NONBLOCK);
+			if (!bfd->fd)
+				bfd->fd = open(openstr, O_RDWR | O_NONBLOCK);
 			if (bfd->fd == -1) {
 				fprintf(stderr, "%s could not open %s %s\n",
 					__func__, openstr, strerror(errno));
@@ -416,10 +430,17 @@ static int dahdi_e1_setup(struct e1inp_line *line)
 			}
 			bfd->when = BSC_FD_READ | BSC_FD_EXCEPT;
 			dahdi_set_bufinfo(bfd->fd, 1);
-			e1i_ts->lapd = lapd_instance_alloc(1, dahdi_write_msg, bfd);
+			if (!e1i_ts->lapd)
+				e1i_ts->lapd = lapd_instance_alloc(1, dahdi_write_msg, bfd);
 			break;
 		case E1INP_TS_TYPE_TRAU:
-			bfd->fd = open(openstr, O_RDWR | O_NONBLOCK);
+			/* close/release LAPD instance, if any */
+			if (e1i_ts->lapd) {
+				lapd_instance_free(e1i_ts->lapd);
+				e1i_ts->lapd = NULL;
+			}
+			if (!bfd->fd)
+				bfd->fd = open(openstr, O_RDWR | O_NONBLOCK);
 			if (bfd->fd == -1) {
 				fprintf(stderr, "%s could not open %s %s\n",
 					__func__, openstr, strerror(errno));
-- 
1.7.5.4


--oJ71EGRlYNjSvfq7--



From holger at freyther.de  Wed Aug 24 11:41:15 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed, 24 Aug 2011 13:41:15 +0200
Subject: Multiple BTS's on one one E1?
In-Reply-To: <20110824074949.GI22266@prithivi.gnumonks.org>
References: <CAKL=SEpY989qYUDNY8iUWkMUE9kFprMc0vjtFstJCL=YRuCskQ@mail.gmail.com>
	<20110824074949.GI22266@prithivi.gnumonks.org>
Message-ID: <4E54E35B.8090007@freyther.de>

On 08/24/2011 09:49 AM, Harald Welte wrote:
> +			if (bfd->fd) {
> +				close(bfd->fd);
> +				bfd->fd = 0;
> +			}

maybe using -1 for 'invalid' fd's is better?



From laforge at gnumonks.org  Thu Aug 25 07:51:49 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 25 Aug 2011 09:51:49 +0200
Subject: Multiple BTS's on one one E1?
In-Reply-To: <4E54E35B.8090007@freyther.de>
References: <CAKL=SEpY989qYUDNY8iUWkMUE9kFprMc0vjtFstJCL=YRuCskQ@mail.gmail.com>
	<20110824074949.GI22266@prithivi.gnumonks.org>
	<4E54E35B.8090007@freyther.de>
Message-ID: <20110825075149.GV22266@prithivi.gnumonks.org>

On Wed, Aug 24, 2011 at 01:41:15PM +0200, Holger Hans Peter Freyther wrote:
> On 08/24/2011 09:49 AM, Harald Welte wrote:
> > +			if (bfd->fd) {
> > +				close(bfd->fd);
> > +				bfd->fd = 0;
> > +			}
> 
> maybe using -1 for 'invalid' fd's is better?

"-1" already has a different meaning in the same part of the code, it
means that there was some error in return to "open"

But yes, we could do "-2" or store the open result in a variable rather
than a structure member.  Feel free to do a follow-up patch ;)

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



From laforge at gnumonks.org  Thu Aug 25 07:41:04 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 25 Aug 2011 09:41:04 +0200
Subject: Multiple BTS's on one one E1?
In-Reply-To: <CAKL=SEpyQcPR8Z2Fr7i6Kz7uZQgx9K427tBYpi-vAydSUf43Ww@mail.gmail.com>
References: <CAKL=SEpY989qYUDNY8iUWkMUE9kFprMc0vjtFstJCL=YRuCskQ@mail.gmail.com>
	<20110824074949.GI22266@prithivi.gnumonks.org>
	<CAKL=SEpyQcPR8Z2Fr7i6Kz7uZQgx9K427tBYpi-vAydSUf43Ww@mail.gmail.com>
Message-ID: <20110825074104.GS22266@prithivi.gnumonks.org>

_please_ use the mailing list!

On Wed, Aug 24, 2011 at 11:39:53AM -0700, Gus Bourg wrote:
> It looks like e1inp_ts needs to have a member lapd:
> 
> input/dahdi.c:471:14: error: ?struct e1inp_ts? has no member named ?lapd?

you are probably using a non-current version of openbsc.git and
libosmo-abis.git

> Problem is that we go into a bootstrap loop:

Well, that should be relatively easy to workaround with a small hack
like a static variable that checks whether the BTS has  been
bootstrapped before.  That's of course not a proper solution...  I
currently don't have time to debug this further, and I am far away from
any of my E1 equipment for testing.

-- 
- 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 aegington at btinternet.com  Wed Aug 24 10:38:40 2011
From: aegington at btinternet.com (Andre Egington)
Date: Wed, 24 Aug 2011 11:38:40 +0100
Subject: open bts project
Message-ID: <000c01cc6249$fd3d9d30$f7b8d790$@btinternet.com>

Dear Group

> 

>  

> 

> I have been for the past few months Following your project very 

> closely and have to say how amazed I am at this project. I would love 

> to do something like this here in the uk but finding hardware to do it 

> is just impossible I would like to get my hands on a Simens BS-11  but 

> cant source any. I will continue to watch this project but felt I 

> should email you to ask if you know of anywhere that I can purchase 

> hardware that able to work with your open bts software if there is any
advice you can give that would be great.

> 

 

Regards Andre

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

From gus at bourg.net  Thu Aug 25 16:03:48 2011
From: gus at bourg.net (Gus Bourg)
Date: Thu, 25 Aug 2011 09:03:48 -0700
Subject: Core dump in trunk
Message-ID: <CAKL=SEqrmepcECBLmF0o-Yqiy77D8jW1iZRYZVYqhnmM0D3edw@mail.gmail.com>

I've pulled everything fresh from trunk in my quest to get multiple BTS's
working on one E1 card.  :)  However, I'm seeing a core dump when I start
osmo-nitb in the box now.

A BT is available here:
http://pastebin.com/KAaxt5d3

This is in a configuration where I only have one BTS configured.  Though I
get the same issue if I have more than one configured too.

Thanks,
Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110825/105043a8/attachment.htm>

From laforge at gnumonks.org  Fri Aug 26 06:02:49 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 26 Aug 2011 08:02:49 +0200
Subject: Core dump in trunk
In-Reply-To: <CAKL=SEqrmepcECBLmF0o-Yqiy77D8jW1iZRYZVYqhnmM0D3edw@mail.gmail.com>
References: <CAKL=SEqrmepcECBLmF0o-Yqiy77D8jW1iZRYZVYqhnmM0D3edw@mail.gmail.com>
Message-ID: <20110826060249.GC22266@prithivi.gnumonks.org>

hi Gus,

On Thu, Aug 25, 2011 at 09:03:48AM -0700, Gus Bourg wrote:
> I've pulled everything fresh from trunk in my quest to get multiple BTS's
> working on one E1 card.  :)  However, I'm seeing a core dump when I start
> osmo-nitb in the box now.
> 
> A BT is available here:
> http://pastebin.com/KAaxt5d3

the backtrace clearly looks as if the experimental and untested
laforge/lapd branch of openbsc.git was used.

The suggested configuration is 'master' from libosmocore, libosmo-abis
and openbsc.git

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



From gus at bourg.net  Fri Aug 26 15:22:50 2011
From: gus at bourg.net (Gus Bourg)
Date: Fri, 26 Aug 2011 08:22:50 -0700
Subject: Core dump in trunk
In-Reply-To: <20110826060249.GC22266@prithivi.gnumonks.org>
References: <CAKL=SEqrmepcECBLmF0o-Yqiy77D8jW1iZRYZVYqhnmM0D3edw@mail.gmail.com>
	<20110826060249.GC22266@prithivi.gnumonks.org>
Message-ID: <CAKL=SEpVX8c4XP=kOZ=TBxC2rP+Z92oAuV_Yo8GPVnThqE0z7w@mail.gmail.com>

On Thu, Aug 25, 2011 at 11:02 PM, Harald Welte <laforge at gnumonks.org> wrote:

> the backtrace clearly looks as if the experimental and untested
> laforge/lapd branch of openbsc.git was used.
>

Sorry about that, you're right - I got my branches mixed up.


> The suggested configuration is 'master' from libosmocore, libosmo-abis
> and openbsc.git
>

I've been having troubles getting master to compile since the move to
osmo-abis.  I have the latest version of osmo-abis (and osmocore) installed,
but for some reason I'm getting this:

bts_ericsson_rbs2000.c: In function ?start_sabm_in_line?:
bts_ericsson_rbs2000.c:73:36: error: ?struct <anonymous>? has no member
named ?lapd?
bts_ericsson_rbs2000.c:75:35: error: ?struct <anonymous>? has no member
named ?lapd?

If I comment out these lines, I run into the same problem with the Nokias
(which I need) as they're trying to send sabms too.

I'm confused why it says its anonymous - when it should be an e1inp_ts. The
offending line is:

lapd_sap_start(ts->driver.dahdi.lapd, link->tei, link->sapi);

Looking at e1_input.h from libosmo-abis:
struct e1inp_ts {
...
   struct e1inp_line *line;
   struct lapd_instance *lapd;
...
   union {
...
      struct {
         /* DAHDI driver has one fd for each ts */
         struct osmo_fd fd;
      } dahdi;
...
   } driver;
};

Is this correct?  I don't think I'm including an old non libosmo-abis
e1_input.h.

Thanks,
Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110826/7da1b8be/attachment.htm>

From laforge at gnumonks.org  Fri Aug 26 17:16:01 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 26 Aug 2011 19:16:01 +0200
Subject: Core dump in trunk
In-Reply-To: <CAKL=SEpVX8c4XP=kOZ=TBxC2rP+Z92oAuV_Yo8GPVnThqE0z7w@mail.gmail.com>
References: <CAKL=SEqrmepcECBLmF0o-Yqiy77D8jW1iZRYZVYqhnmM0D3edw@mail.gmail.com>
	<20110826060249.GC22266@prithivi.gnumonks.org>
	<CAKL=SEpVX8c4XP=kOZ=TBxC2rP+Z92oAuV_Yo8GPVnThqE0z7w@mail.gmail.com>
Message-ID: <20110826171601.GJ22266@prithivi.gnumonks.org>

Hi Gus,

On Fri, Aug 26, 2011 at 08:22:50AM -0700, Gus Bourg wrote:
> I've been having troubles getting master to compile since the move to
> osmo-abis.  I have the latest version of osmo-abis (and osmocore) installed,
> but for some reason I'm getting this:
> 
> bts_ericsson_rbs2000.c: In function ?start_sabm_in_line?:
> bts_ericsson_rbs2000.c:73:36: error: ?struct <anonymous>? has no member
> named ?lapd?
> bts_ericsson_rbs2000.c:75:35: error: ?struct <anonymous>? has no member
> named ?lapd?

For some strange reason I didn't run into this bug so far.  I've now
built from a 'make distclean' and could clearly reproduce it.

git commit b4d913d336d7a52dff840378726b1d3dc5f81268 of current master
should fix it.

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



From gus at bourg.net  Fri Aug 26 23:03:52 2011
From: gus at bourg.net (Gus Bourg)
Date: Fri, 26 Aug 2011 16:03:52 -0700
Subject: Core dump in trunk
In-Reply-To: <20110826171601.GJ22266@prithivi.gnumonks.org>
References: <CAKL=SEqrmepcECBLmF0o-Yqiy77D8jW1iZRYZVYqhnmM0D3edw@mail.gmail.com>
	<20110826060249.GC22266@prithivi.gnumonks.org>
	<CAKL=SEpVX8c4XP=kOZ=TBxC2rP+Z92oAuV_Yo8GPVnThqE0z7w@mail.gmail.com>
	<20110826171601.GJ22266@prithivi.gnumonks.org>
Message-ID: <CAKL=SEp+5iyWFnQGyKvCPuHJA49QwLrh8qzLi62UyHa=vRKmcw@mail.gmail.com>

Hi Harald,

On Fri, Aug 26, 2011 at 10:16 AM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Gus,
>
> For some strange reason I didn't run into this bug so far.  I've now
> built from a 'make distclean' and could clearly reproduce it.
>
> git commit b4d913d336d7a52dff840378726b1d3dc5f81268 of current master
> should fix it.
>
>
Thanks for fixing this!  I can confirm that it compiles now - and my BTS
comes up with trunk.  However, when I configure two BTS's, I get a core dump
(for real this time : -)

Here's the startup:
http://pastebin.com/2ER4CgyX

And here's the backtrace:
http://pastebin.com/vHK5cZmV

Thanks,
Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110826/3f177c88/attachment.htm>

From laforge at gnumonks.org  Sat Aug 27 11:54:45 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 27 Aug 2011 13:54:45 +0200
Subject: Core dump in trunk
In-Reply-To: <CAKL=SEp+5iyWFnQGyKvCPuHJA49QwLrh8qzLi62UyHa=vRKmcw@mail.gmail.com>
References: <CAKL=SEqrmepcECBLmF0o-Yqiy77D8jW1iZRYZVYqhnmM0D3edw@mail.gmail.com>
	<20110826060249.GC22266@prithivi.gnumonks.org>
	<CAKL=SEpVX8c4XP=kOZ=TBxC2rP+Z92oAuV_Yo8GPVnThqE0z7w@mail.gmail.com>
	<20110826171601.GJ22266@prithivi.gnumonks.org>
	<CAKL=SEp+5iyWFnQGyKvCPuHJA49QwLrh8qzLi62UyHa=vRKmcw@mail.gmail.com>
Message-ID: <20110827115445.GC20845@prithivi.gnumonks.org>

Hi Gus,

On Fri, Aug 26, 2011 at 04:03:52PM -0700, Gus Bourg wrote:
> Thanks for fixing this!  I can confirm that it compiles now - and my BTS
> comes up with trunk.  However, when I configure two BTS's, I get a core dump
> (for real this time : -)

feel free to debug this further by yourself.  It's a bit hard without
access to the equipment.  For some reason, ts->lapd is NULL, i.e. there
was no LAPD instance allocated for this timeslot.

The allocation happens at line 434 of libosmo-abis/src/input/dahdi.c

So the first step would be to add some LOGP messages about which LAPD
instances are allocated (or released).  This can be used to see if the
expected LAPD instances (one on each signalling timeslot) are created
or not.

-- 
- 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 pablo at gnumonks.org  Sun Aug 28 21:36:47 2011
From: pablo at gnumonks.org (Pablo Neira Ayuso)
Date: Sun, 28 Aug 2011 23:36:47 +0200
Subject: Core dump in trunk
In-Reply-To: <20110827115445.GC20845@prithivi.gnumonks.org>
References: <CAKL=SEqrmepcECBLmF0o-Yqiy77D8jW1iZRYZVYqhnmM0D3edw@mail.gmail.com>
	<20110826060249.GC22266@prithivi.gnumonks.org>
	<CAKL=SEpVX8c4XP=kOZ=TBxC2rP+Z92oAuV_Yo8GPVnThqE0z7w@mail.gmail.com>
	<20110826171601.GJ22266@prithivi.gnumonks.org>
	<CAKL=SEp+5iyWFnQGyKvCPuHJA49QwLrh8qzLi62UyHa=vRKmcw@mail.gmail.com>
	<20110827115445.GC20845@prithivi.gnumonks.org>
Message-ID: <20110828213647.GA6441@1984>

On Sat, Aug 27, 2011 at 01:54:45PM +0200, Harald Welte wrote:
> Hi Gus,
> 
> On Fri, Aug 26, 2011 at 04:03:52PM -0700, Gus Bourg wrote:
> > Thanks for fixing this!  I can confirm that it compiles now - and my BTS
> > comes up with trunk.  However, when I configure two BTS's, I get a core dump
> > (for real this time : -)
> 
> feel free to debug this further by yourself.  It's a bit hard without
> access to the equipment.  For some reason, ts->lapd is NULL, i.e. there
> was no LAPD instance allocated for this timeslot.
> 
> The allocation happens at line 434 of libosmo-abis/src/input/dahdi.c
> 
> So the first step would be to add some LOGP messages about which LAPD
> instances are allocated (or released).  This can be used to see if the
> expected LAPD instances (one on each signalling timeslot) are created
> or not.

I introduced refcounting in the ->line_update() update path in
libosmo-abis, which calls the setup function only once (I needed this
to avoid binding the A-bis over IP socket twice).

Before, the line_update() function was called once per BTS. I'm
traveling back home, so I didn't have too much time to look in depth,
but my guess is that this can be related to the problem that Gus is
reporting.



From laforge at gnumonks.org  Mon Aug 29 07:15:23 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 29 Aug 2011 09:15:23 +0200
Subject: Core dump in trunk
In-Reply-To: <20110828213647.GA6441@1984>
References: <CAKL=SEqrmepcECBLmF0o-Yqiy77D8jW1iZRYZVYqhnmM0D3edw@mail.gmail.com>
	<20110826060249.GC22266@prithivi.gnumonks.org>
	<CAKL=SEpVX8c4XP=kOZ=TBxC2rP+Z92oAuV_Yo8GPVnThqE0z7w@mail.gmail.com>
	<20110826171601.GJ22266@prithivi.gnumonks.org>
	<CAKL=SEp+5iyWFnQGyKvCPuHJA49QwLrh8qzLi62UyHa=vRKmcw@mail.gmail.com>
	<20110827115445.GC20845@prithivi.gnumonks.org>
	<20110828213647.GA6441@1984>
Message-ID: <20110829071523.GI23789@prithivi.gnumonks.org>

Hi Pablo,

On Sun, Aug 28, 2011 at 11:36:47PM +0200, Pablo Neira Ayuso wrote:

> > So the first step would be to add some LOGP messages about which LAPD
> > instances are allocated (or released).  This can be used to see if the
> > expected LAPD instances (one on each signalling timeslot) are created
> > or not.
> 
> I introduced refcounting in the ->line_update() update path in
> libosmo-abis, which calls the setup function only once (I needed this
> to avoid binding the A-bis over IP socket twice).

I see.  But I believe this is the wrong path to "solve" the problem.
The function is called "update" since it is supposed to be called
multiple times, every time something has changed about the line (e.g.
timeslot configuration).

> Before, the line_update() function was called once per BTS. I'm
> traveling back home, so I didn't have too much time to look in depth,
> but my guess is that this can be related to the problem that Gus is
> reporting.

With multiple BTS attached to a signle line, there is no other way but
to call the function multiple times.  It has to be written with that in
mind.

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



From pablo at gnumonks.org  Tue Aug 30 10:44:38 2011
From: pablo at gnumonks.org (Pablo Neira Ayuso)
Date: Tue, 30 Aug 2011 12:44:38 +0200
Subject: Core dump in trunk
In-Reply-To: <20110829071523.GI23789@prithivi.gnumonks.org>
References: <CAKL=SEqrmepcECBLmF0o-Yqiy77D8jW1iZRYZVYqhnmM0D3edw@mail.gmail.com>
	<20110826060249.GC22266@prithivi.gnumonks.org>
	<CAKL=SEpVX8c4XP=kOZ=TBxC2rP+Z92oAuV_Yo8GPVnThqE0z7w@mail.gmail.com>
	<20110826171601.GJ22266@prithivi.gnumonks.org>
	<CAKL=SEp+5iyWFnQGyKvCPuHJA49QwLrh8qzLi62UyHa=vRKmcw@mail.gmail.com>
	<20110827115445.GC20845@prithivi.gnumonks.org>
	<20110828213647.GA6441@1984>
	<20110829071523.GI23789@prithivi.gnumonks.org>
Message-ID: <20110830104438.GA31145@1984>

Hi Harald!

On Mon, Aug 29, 2011 at 09:15:23AM +0200, Harald Welte wrote:
> Hi Pablo,
> 
> On Sun, Aug 28, 2011 at 11:36:47PM +0200, Pablo Neira Ayuso wrote:
> 
> > > So the first step would be to add some LOGP messages about which LAPD
> > > instances are allocated (or released).  This can be used to see if the
> > > expected LAPD instances (one on each signalling timeslot) are created
> > > or not.
> > 
> > I introduced refcounting in the ->line_update() update path in
> > libosmo-abis, which calls the setup function only once (I needed this
> > to avoid binding the A-bis over IP socket twice).
> 
> I see.  But I believe this is the wrong path to "solve" the problem.
> The function is called "update" since it is supposed to be called
> multiple times, every time something has changed about the line (e.g.
> timeslot configuration).

I can recover the ->start() callback that would be called once for
A-bis over IP drivers, so I don't need to use line_update() for this.
Or add some flag to the lines, so we can know which ones can be
updated several times or not.
 
> > Before, the line_update() function was called once per BTS. I'm
> > traveling back home, so I didn't have too much time to look in depth,
> > but my guess is that this can be related to the problem that Gus is
> > reporting.
> 
> With multiple BTS attached to a signle line, there is no other way but
> to call the function multiple times.  It has to be written with that in
> mind.

I missed the multiple-BTS-to-single-line setup, I'll send you a patch
to fix this situation.

Cheers,
Pablo



From laforge at gnumonks.org  Tue Aug 30 11:38:55 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 30 Aug 2011 13:38:55 +0200
Subject: Core dump in trunk
In-Reply-To: <20110830104438.GA31145@1984>
References: <CAKL=SEqrmepcECBLmF0o-Yqiy77D8jW1iZRYZVYqhnmM0D3edw@mail.gmail.com>
	<20110826060249.GC22266@prithivi.gnumonks.org>
	<CAKL=SEpVX8c4XP=kOZ=TBxC2rP+Z92oAuV_Yo8GPVnThqE0z7w@mail.gmail.com>
	<20110826171601.GJ22266@prithivi.gnumonks.org>
	<CAKL=SEp+5iyWFnQGyKvCPuHJA49QwLrh8qzLi62UyHa=vRKmcw@mail.gmail.com>
	<20110827115445.GC20845@prithivi.gnumonks.org>
	<20110828213647.GA6441@1984>
	<20110829071523.GI23789@prithivi.gnumonks.org>
	<20110830104438.GA31145@1984>
Message-ID: <20110830113855.GL822@prithivi.gnumonks.org>

Hi Pablo,

On Tue, Aug 30, 2011 at 12:44:38PM +0200, Pablo Neira Ayuso wrote:

> > > I introduced refcounting in the ->line_update() update path in
> > > libosmo-abis, which calls the setup function only once (I needed this
> > > to avoid binding the A-bis over IP socket twice).
> > 
> > I see.  But I believe this is the wrong path to "solve" the problem.
> > The function is called "update" since it is supposed to be called
> > multiple times, every time something has changed about the line (e.g.
> > timeslot configuration).
> 
> I can recover the ->start() callback that would be called once for
> A-bis over IP drivers, so I don't need to use line_update() for this.
> Or add some flag to the lines, so we can know which ones can be
> updated several times or not.

I think having one 'update' callback is fine, no need for an extra
'start' callback.

The abis/ip line driver simlpy would have to use some privat per-line
data structure to keep the state if it has already been 'updated' once
and skip further update calls.

Regards,
	Harald

> > With multiple BTS attached to a signle line, there is no other way but
> > to call the function multiple times.  It has to be written with that in
> > mind.
> 
> I missed the multiple-BTS-to-single-line setup, I'll send you a patch
> to fix this situation.

no problem, looking forward to your patch.

-- 
- 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 pablo at gnumonks.org  Tue Aug 30 14:45:27 2011
From: pablo at gnumonks.org (pablo at gnumonks.org)
Date: Tue, 30 Aug 2011 16:45:27 +0200
Subject: [PATCH] input: fix multiple BTS attached to single line scenario
Message-ID: <1314715527-23467-1-git-send-email-pablo@gnumonks.org>

From: Pablo Neira Ayuso <pablo at gnumonks.org>

With multiple BTS attached to a single line, we have to call
->line_update() multiple times. I broke this myself while avoiding
that A-bis over IP drivers bind to the socket several times.

To fix this situation, this patch adds the E1INP_DRV_F_LINE_ETHER
flag which allows us to skip multiple invocation of ->line_update()
only in case that this is an A-bis over IP driver.

Reported-by: Gus Bourg <gus at bourg.net>
---
 include/osmocom/abis/e1_input.h |    5 +++++
 src/e1_input.c                  |    4 ++--
 src/input/hsl.c                 |    1 +
 src/input/ipaccess.c            |    1 +
 4 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/include/osmocom/abis/e1_input.h b/include/osmocom/abis/e1_input.h
index 42b1758..bbbbf29 100644
--- a/include/osmocom/abis/e1_input.h
+++ b/include/osmocom/abis/e1_input.h
@@ -124,9 +124,14 @@ enum e1inp_line_role {
 	E1INP_LINE_R_MAX
 };
 
+enum {
+	E1INP_DRV_F_LINE_ETHER = (1 << 0),	/* Driver uses ethernet line. */
+};
+
 struct e1inp_driver {
 	struct llist_head list;
 	const char *name;
+	unsigned int flags;
 	int (*want_write)(struct e1inp_ts *ts);
 	int (*line_update)(struct e1inp_line *line);
 	void (*close)(struct e1inp_sign_link *link);
diff --git a/src/e1_input.c b/src/e1_input.c
index a549ba4..3c5ac7d 100644
--- a/src/e1_input.c
+++ b/src/e1_input.c
@@ -676,8 +676,8 @@ int e1inp_line_update(struct e1inp_line *line)
 
 	e1inp_line_get(line);
 
-	/* This line has been already initialized, skip this. */
-	if (line->refcnt > 2)
+	/* This ethernet line has been already initialized, skip this. */
+	if ((line->driver->flags & E1INP_DRV_F_LINE_ETHER) && line->refcnt > 2)
 		return 0;
 
 	if (line->driver && line->ops && line->driver->line_update) {
diff --git a/src/input/hsl.c b/src/input/hsl.c
index dc7532b..fe9e70c 100644
--- a/src/input/hsl.c
+++ b/src/input/hsl.c
@@ -322,6 +322,7 @@ static int hsl_line_update(struct e1inp_line *line);
 
 struct e1inp_driver hsl_driver = {
 	.name = "hsl",
+	.flags = E1INP_DRV_F_LINE_ETHER,
 	.want_write = ts_want_write,
 	.line_update = hsl_line_update,
 	.close = hsl_close,
diff --git a/src/input/ipaccess.c b/src/input/ipaccess.c
index b7391b3..b12383b 100644
--- a/src/input/ipaccess.c
+++ b/src/input/ipaccess.c
@@ -555,6 +555,7 @@ static int ipaccess_line_update(struct e1inp_line *line);
 
 struct e1inp_driver ipaccess_driver = {
 	.name = "ipa",
+	.flags = E1INP_DRV_F_LINE_ETHER,
 	.want_write = ts_want_write,
 	.line_update = ipaccess_line_update,
 	.close = ipaccess_close,
-- 
1.7.2.5




From laforge at gnumonks.org  Tue Aug 30 15:25:52 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 30 Aug 2011 17:25:52 +0200
Subject: [PATCH] input: fix multiple BTS attached to single line scenario
In-Reply-To: <1314715527-23467-1-git-send-email-pablo@gnumonks.org>
References: <1314715527-23467-1-git-send-email-pablo@gnumonks.org>
Message-ID: <20110830152551.GQ822@prithivi.gnumonks.org>

Hi Pablo,

this is unfortunately not what I would like to see.  The flag should be
hidden in the ipaccess.c / hsl.c driver, and it should not be globally
visible.

I think it's a bid odd to handle a special case like this in the generic
code / data structure.

By definition, the driver has to cope with the fact that the
line_update() function is called multiple times.  That's what the name
also indicates.  If a driver wants to do something different, it has to
solve the problem on the driver side.

Each driver can allocate its own structure and tie it to
line->driver_data, like the misdn.c driver is doing it.  In there it can
handle local state like 'has this line been initialized before and do I
thus want to skip another round of initialization'.

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



From pablo at gnumonks.org  Tue Aug 30 14:48:19 2011
From: pablo at gnumonks.org (pablo at gnumonks.org)
Date: Tue, 30 Aug 2011 16:48:19 +0200
Subject: [PATCH] vty: bail out if we cannot enable logging from VTY
Message-ID: <1314715699-23618-1-git-send-email-pablo@gnumonks.org>

From: Pablo Neira Ayuso <pablo at gnumonks.org>

---
 src/vty/logging_vty.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/src/vty/logging_vty.c b/src/vty/logging_vty.c
index b037a5b..b4ab748 100644
--- a/src/vty/logging_vty.c
+++ b/src/vty/logging_vty.c
@@ -78,8 +78,10 @@ DEFUN(enable_logging,
 	}
 
 	conn->dbg = log_target_create_vty(vty);
-	if (!conn->dbg)
+	if (!conn->dbg) {
+		vty_out(vty, "Cannot enable logging to this VTY.%s", VTY_NEWLINE);
 		return CMD_WARNING;
+	}
 
 	log_add_target(conn->dbg);
 	return CMD_SUCCESS;
-- 
1.7.2.5




From openbsc at wehrle.it  Wed Aug 31 10:39:26 2011
From: openbsc at wehrle.it (Dennis Wehrle)
Date: Wed, 31 Aug 2011 12:39:26 +0200
Subject: Missing libosmoabis-library
Message-ID: <4E5E0F5E.8000109@wehrle.it>

Hi

I just tried to use the newest versions of libosmocore, openbsc and lcr. 
But i can't configure openbsc (the master branch). It complains about 
missing libosmoabis. Where can i find this library? This happens even if 
i use the pablo/libosmo-abis branch from libosmocore.

Best regards
Dennis




From 246tnt at gmail.com  Wed Aug 31 10:49:34 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 31 Aug 2011 12:49:34 +0200
Subject: Missing libosmoabis-library
In-Reply-To: <4E5E0F5E.8000109@wehrle.it>
References: <4E5E0F5E.8000109@wehrle.it>
Message-ID: <CAHL+j0_R1Pd4xPAQ-iY3D_eJW7UKGt12CwWT7nzi5C_nLFLJxw@mail.gmail.com>

> I just tried to use the newest versions of libosmocore, openbsc and lcr. But
> i can't configure openbsc (the master branch). It complains about missing
> libosmoabis. Where can i find this library?

It's like on the first page of the wiki in the news section ...
It's also listed in the list of all osmocom code http://git.osmocom.org/
And finally it's also the first hit on google for 'libosmo-abis':
http://openbsc.osmocom.org/trac/wiki/libosmo-abis

> This happens even if i use the
> pablo/libosmo-abis branch from libosmocore.

Don't do that, use master for all.

Cheers,

    Sylvain



From openbsc at wehrle.it  Wed Aug 31 11:59:28 2011
From: openbsc at wehrle.it (Dennis Wehrle)
Date: Wed, 31 Aug 2011 13:59:28 +0200
Subject: Missing libosmoabis-library
In-Reply-To: <CAHL+j0_R1Pd4xPAQ-iY3D_eJW7UKGt12CwWT7nzi5C_nLFLJxw@mail.gmail.com>
References: <4E5E0F5E.8000109@wehrle.it>
	<CAHL+j0_R1Pd4xPAQ-iY3D_eJW7UKGt12CwWT7nzi5C_nLFLJxw@mail.gmail.com>
Message-ID: <4E5E2220.7050504@wehrle.it>

Hi Sylvain

Oh ok, sorry! I was searching for libosmoabis (without the dash)....
Sorry for the spam ...

Best Regards
Dennis

On 31.08.2011 12:49, Sylvain Munaut wrote:
>> I just tried to use the newest versions of libosmocore, openbsc and lcr. But
>> i can't configure openbsc (the master branch). It complains about missing
>> libosmoabis. Where can i find this library?
> It's like on the first page of the wiki in the news section ...
> It's also listed in the list of all osmocom code http://git.osmocom.org/
> And finally it's also the first hit on google for 'libosmo-abis':
> http://openbsc.osmocom.org/trac/wiki/libosmo-abis
>
>> This happens even if i use the
>> pablo/libosmo-abis branch from libosmocore.
> Don't do that, use master for all.
>
> Cheers,
>
>      Sylvain
>




From pablo at gnumonks.org  Wed Aug 31 14:47:44 2011
From: pablo at gnumonks.org (pablo at gnumonks.org)
Date: Wed, 31 Aug 2011 16:47:44 +0200
Subject: [PATCH] input: fix multiple BTS attached to single line scenario
Message-ID: <1314802064-4928-1-git-send-email-pablo@gnumonks.org>

From: Pablo Neira Ayuso <pablo at gnumonks.org>

With multiple BTS attached to a single line, we have to call
->line_update() multiple times. I broke this myself while avoiding
that A-bis over IP drivers bind to the socket several times.

To fix this situation, Harald prefers that this case is internally
handled by the ipaccess and hsl drivers by means of the driver_data
field in the e1inp_line structure.

Reported-by: Gus Bourg <gus at bourg.net>
---
 src/e1_input.c       |    4 ----
 src/input/hsl.c      |   20 ++++++++++++++++++++
 src/input/ipaccess.c |   20 ++++++++++++++++++++
 3 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/src/e1_input.c b/src/e1_input.c
index a549ba4..ad0778a 100644
--- a/src/e1_input.c
+++ b/src/e1_input.c
@@ -676,10 +676,6 @@ int e1inp_line_update(struct e1inp_line *line)
 
 	e1inp_line_get(line);
 
-	/* This line has been already initialized, skip this. */
-	if (line->refcnt > 2)
-		return 0;
-
 	if (line->driver && line->ops && line->driver->line_update) {
 		rc = line->driver->line_update(line);
 	} else
diff --git a/src/input/hsl.c b/src/input/hsl.c
index dc7532b..60eea17 100644
--- a/src/input/hsl.c
+++ b/src/input/hsl.c
@@ -456,9 +456,29 @@ static int hsl_bts_connect(struct ipa_client_link *link)
 	return 0;
 }
 
+struct hsl_line {
+	int line_already_initialized;
+};
+
 static int hsl_line_update(struct e1inp_line *line)
 {
 	int ret = -ENOENT;
+	struct hsl_line *hl;
+
+	if (!line->driver_data)
+		line->driver_data = talloc_zero(line, struct hsl_line);
+
+	if (!line->driver_data) {
+		LOGP(DLINP, LOGL_NOTICE, "hsl: OOM in line update\n");
+		return -ENOMEM;
+	}
+	hl = line->driver_data;
+
+	/* We only initialize this line once. */
+	if (hl->line_already_initialized)
+		return 0;
+
+	hl->line_already_initialized = 1;
 
 	switch(line->ops->cfg.ipa.role) {
 	case E1INP_LINE_R_BSC:
diff --git a/src/input/ipaccess.c b/src/input/ipaccess.c
index b7391b3..ea04e8d 100644
--- a/src/input/ipaccess.c
+++ b/src/input/ipaccess.c
@@ -813,9 +813,29 @@ static int ipaccess_bts_cb(struct ipa_client_link *link, struct msgb *msg)
 	return 0;
 }
 
+struct ipaccess_line {
+	int line_already_initialized;
+};
+
 static int ipaccess_line_update(struct e1inp_line *line)
 {
 	int ret = -ENOENT;
+	struct ipaccess_line *il;
+
+	if (!line->driver_data)
+		line->driver_data = talloc_zero(line, struct ipaccess_line);
+
+	if (!line->driver_data) {
+		LOGP(DLINP, LOGL_ERROR, "ipaccess: OOM in line update\n");
+		return -ENOMEM;
+	}
+	il = line->driver_data;
+
+	/* We only initialize this line once. */
+	if (il->line_already_initialized)
+		return 0;
+
+	il->line_already_initialized = 1;
 
 	switch(line->ops->cfg.ipa.role) {
 	case E1INP_LINE_R_BSC: {
-- 
1.7.2.5




From laforge at gnumonks.org  Wed Aug 31 15:56:17 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 31 Aug 2011 17:56:17 +0200
Subject: [PATCH] input: fix multiple BTS attached to single line scenario
In-Reply-To: <1314802064-4928-1-git-send-email-pablo@gnumonks.org>
References: <1314802064-4928-1-git-send-email-pablo@gnumonks.org>
Message-ID: <20110831155617.GZ13522@prithivi.gnumonks.org>

hi Pablo,

On Wed, Aug 31, 2011 at 04:47:44PM +0200, pablo at gnumonks.org wrote:
> To fix this situation, Harald prefers that this case is internally
> handled by the ipaccess and hsl drivers by means of the driver_data
> field in the e1inp_line structure.

thanks.  Gus, can you give some feedback on this latest patch (or
libosmo-abis master)?
-- 
- 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 gus at bourg.net  Wed Aug 31 18:11:05 2011
From: gus at bourg.net (Gus Bourg)
Date: Wed, 31 Aug 2011 11:11:05 -0700
Subject: [PATCH] input: fix multiple BTS attached to single line scenario
In-Reply-To: <20110831155617.GZ13522@prithivi.gnumonks.org>
References: <1314802064-4928-1-git-send-email-pablo@gnumonks.org>
	<20110831155617.GZ13522@prithivi.gnumonks.org>
Message-ID: <CAKL=SEo8sy7-G=5UO12j8Txbn2qqPc73NLUh10BPDKPByxGJKQ@mail.gmail.com>

I can confirm this new patch allowed me to bring up 3 InSites on a single
Dahdi E1 card.

On Wed, Aug 31, 2011 at 8:56 AM, Harald Welte <laforge at gnumonks.org> wrote:

> hi Pablo,
>
> On Wed, Aug 31, 2011 at 04:47:44PM +0200, pablo at gnumonks.org wrote:
> > To fix this situation, Harald prefers that this case is internally
> > handled by the ipaccess and hsl drivers by means of the driver_data
> > field in the e1inp_line structure.
>
> thanks.  Gus, can you give some feedback on this latest patch (or
> libosmo-abis master)?
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110831/7e67274a/attachment.htm>