From dwilllmann at sysmocom.de  Wed Feb  3 17:53:29 2016
From: dwilllmann at sysmocom.de (Daniel Willmann)
Date: Wed,  3 Feb 2016 18:53:29 +0100
Subject: [PATCH 1/3] gtp: Pass pdp along when calling gtp_req() in
 gtp_update_context()
In-Reply-To: <cover.1454521570.git.daniel@totalueberwachung.de>
References: <cover.1454521570.git.daniel@totalueberwachung.de>
Message-ID: <ec2961e2e7793b1a657913e0c980d7d4828292ef.1454521570.git.daniel@totalueberwachung.de>

From: Daniel Willmann <dwillmann at sysmocom.de>

With no pdp parameter gtp_req() will send the packet to TEID 0 which is
not what we want. When trying to modify an established pdp context the
correct TEID of that context must be used.
---
 gtp/gtp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gtp/gtp.c b/gtp/gtp.c
index a3772ff..7cc2328 100644
--- a/gtp/gtp.c
+++ b/gtp/gtp.c
@@ -1871,7 +1871,7 @@ int gtp_update_context(struct gsn_t *gsn, struct pdp_t *pdp, void *cbp,
 		gtpie_tlv(&packet, &length, GTP_MAX, GTPIE_OMC_ID,
 			  pdp->omcid.l, pdp->omcid.v);
 
-	gtp_req(gsn, pdp->version, NULL, &packet, length, inetaddr, cbp);
+	gtp_req(gsn, pdp->version, pdp, &packet, length, inetaddr, cbp);
 
 	return 0;
 }
-- 
2.1.4



From dwilllmann at sysmocom.de  Wed Feb  3 17:53:28 2016
From: dwilllmann at sysmocom.de (Daniel Willmann)
Date: Wed,  3 Feb 2016 18:53:28 +0100
Subject: [PATCH 0/3] Fix handling PDP update messages
Message-ID: <cover.1454521570.git.daniel@totalueberwachung.de>

From: Daniel Willmann <daniel at totalueberwachung.de>

Hello,

it seems PDP context updates was never really used/tested to an Update PDP
context would not go through. The following patches fix that (at least for
gtpv1).

Regards
Daniel 

Daniel Willmann (3):
  gtp: Pass pdp along when calling gtp_req() in gtp_update_context()
  gtp: Make gtp_update_pdp_conf() work for gtp0 and gtp1 connections
  gtp: Handle gtpv1 in gtp_update_pdp_conf() correctly

 gtp/gtp.c | 162 +++++++++++++++++++++++++++++++++++++++++++++-----------------
 1 file changed, 118 insertions(+), 44 deletions(-)

-- 
2.1.4

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


From dwilllmann at sysmocom.de  Wed Feb  3 17:53:30 2016
From: dwilllmann at sysmocom.de (Daniel Willmann)
Date: Wed,  3 Feb 2016 18:53:30 +0100
Subject: [PATCH 2/3] gtp: Make gtp_update_pdp_conf() work for gtp0 and gtp1
 connections
In-Reply-To: <cover.1454521570.git.daniel@totalueberwachung.de>
References: <cover.1454521570.git.daniel@totalueberwachung.de>
Message-ID: <2d3c22115fa4fc0e742b159a28951e83bdcad6fd.1454521570.git.daniel@totalueberwachung.de>

From: Daniel Willmann <dwillmann at sysmocom.de>

pdp_getgtp1(&pdp, get_tei(pack)) works like pdp_getgtp0 for gtp0
connections.
Using get_hlen() for gtpie_decaps is used in other places to decode ies
for both version 0 and 1.
---
 gtp/gtp.c | 16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/gtp/gtp.c b/gtp/gtp.c
index 7cc2328..772ab08 100644
--- a/gtp/gtp.c
+++ b/gtp/gtp.c
@@ -2175,33 +2175,27 @@ int gtp_update_pdp_conf(struct gsn_t *gsn, int version,
 	uint8_t cause, recovery;
 	void *cbp = NULL;
 	uint8_t type = 0;
+	int hlen = get_hlen(pack);
 
 	/* Remove packet from queue */
 	if (gtp_conf(gsn, 0, peer, pack, len, &type, &cbp))
 		return EOF;
 
-	/* TODO This function is called from gtp_decaps1c() (for GTP v1) but
-	 * uses gtp0.h.flow (GTP v0 data element)
-	 */
 	/* Find the context in question */
-	if (pdp_getgtp0(&pdp, ntoh16(((union gtp_packet *)pack)->gtp0.h.flow))) {
+	if (pdp_getgtp1(&pdp, get_tei(pack))) {
 		gsn->err_unknownpdp++;
 		GTP_LOGPKG(LOGL_ERROR, peer, pack, len,
-			    "Unknown PDP context\n");
+			    "Unknown PDP context: %u\n", get_tei(pack));
 		if (gsn->cb_conf)
-			gsn->cb_conf(type, cause, NULL, cbp);
+			gsn->cb_conf(type, EOF, NULL, cbp);
 		return EOF;
 	}
 
 	/* Register that we have received a valid teic from GGSN */
 	pdp->teic_confirmed = 1;
 
-	/* TODO This function is called from gtp_decaps1c() (for GTP v1) but
-	 * explicitly passes version 0 and GTP0_HEADER_SIZE to gtpie_decaps()
-	 */
 	/* Decode information elements */
-	if (gtpie_decaps
-	    (ie, 0, pack + GTP0_HEADER_SIZE, len - GTP0_HEADER_SIZE)) {
+	if (gtpie_decaps(ie, version, pack + hlen, len - hlen)) {
 		gsn->invalid++;
 		GTP_LOGPKG(LOGL_ERROR, peer, pack, len,
 			    "Invalid message format\n");
-- 
2.1.4



From dwilllmann at sysmocom.de  Wed Feb  3 17:53:31 2016
From: dwilllmann at sysmocom.de (Daniel Willmann)
Date: Wed,  3 Feb 2016 18:53:31 +0100
Subject: [PATCH 3/3] gtp: Handle gtpv1 in gtp_update_pdp_conf() correctly
In-Reply-To: <cover.1454521570.git.daniel@totalueberwachung.de>
References: <cover.1454521570.git.daniel@totalueberwachung.de>
Message-ID: <31daf439e34a6f4b1b6a323ab84e437371f972d5.1454521570.git.daniel@totalueberwachung.de>

From: Daniel Willmann <dwillmann at sysmocom.de>

libgtp cannot understand its own update pdp request (in gtp v1)
Only require the conditional and mandatory fields for gtpv1 and not
others.
Refer to 3GPP TS 29.060 Ch. 7.3.4
---
 gtp/gtp.c | 144 ++++++++++++++++++++++++++++++++++++++++++++++++--------------
 1 file changed, 112 insertions(+), 32 deletions(-)

diff --git a/gtp/gtp.c b/gtp/gtp.c
index 772ab08..0ef4a54 100644
--- a/gtp/gtp.c
+++ b/gtp/gtp.c
@@ -2225,22 +2225,87 @@ int gtp_update_pdp_conf(struct gsn_t *gsn, int version,
 	}
 
 	/* Check all conditional information elements */
-	if (GTPCAUSE_ACC_REQ != cause) {
-		if (gsn->cb_conf)
-			gsn->cb_conf(type, cause, pdp, cbp);
-		/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
-		   pdp_freepdp(pdp); */
-		return 0;
-	} else {
-		/* Check for missing conditionary information elements */
-		if (!(gtpie_exist(ie, GTPIE_QOS_PROFILE0, 0) &&
-		      gtpie_exist(ie, GTPIE_REORDER, 0) &&
-		      gtpie_exist(ie, GTPIE_FL_DI, 0) &&
-		      gtpie_exist(ie, GTPIE_FL_C, 0) &&
-		      gtpie_exist(ie, GTPIE_CHARGING_ID, 0) &&
-		      gtpie_exist(ie, GTPIE_EUA, 0) &&
-		      gtpie_exist(ie, GTPIE_GSN_ADDR, 0) &&
-		      gtpie_exist(ie, GTPIE_GSN_ADDR, 1))) {
+	/* TODO: This does not handle GGSN-initiated update responses */
+	if (GTPCAUSE_ACC_REQ == cause) {
+		if (version == 0) {
+			if (gtpie_gettv0(ie, GTPIE_QOS_PROFILE0, 0,
+					 &pdp->qos_neg0,
+					 sizeof(pdp->qos_neg0))) {
+				gsn->missing++;
+				GTP_LOGPKG(LOGL_ERROR, peer,
+					    pack, len,
+					    "Missing conditional information field\n");
+				if (gsn->cb_conf)
+					gsn->cb_conf(type, EOF, pdp, cbp);
+				/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
+				   pdp_freepdp(pdp); */
+				return EOF;
+			}
+
+			if (gtpie_gettv2(ie, GTPIE_FL_DI, 0, &pdp->flru)) {
+				gsn->missing++;
+				GTP_LOGPKG(LOGL_ERROR, peer,
+					    pack, len,
+					    "Missing conditional information field\n");
+				if (gsn->cb_conf)
+					gsn->cb_conf(type, EOF, pdp, cbp);
+				/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
+				   pdp_freepdp(pdp); */
+				return EOF;
+			}
+
+			if (gtpie_gettv2(ie, GTPIE_FL_C, 0, &pdp->flrc)) {
+				gsn->missing++;
+				GTP_LOGPKG(LOGL_ERROR, peer,
+					    pack, len,
+					    "Missing conditional information field\n");
+				if (gsn->cb_conf)
+					gsn->cb_conf(type, EOF, pdp, cbp);
+				/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
+				   pdp_freepdp(pdp); */
+				return EOF;
+			}
+		}
+
+		if (version == 1) {
+			if (gtpie_gettv4(ie, GTPIE_TEI_DI, 0, &pdp->teid_gn)) {
+				gsn->missing++;
+				GTP_LOGPKG(LOGL_ERROR, peer,
+					    pack, len,
+					    "Missing conditional information field\n");
+				if (gsn->cb_conf)
+					gsn->cb_conf(type, EOF, pdp, cbp);
+				/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
+				   pdp_freepdp(pdp); */
+				return EOF;
+			}
+
+			if (gtpie_gettv4(ie, GTPIE_TEI_C, 0, &pdp->teic_gn)) {
+				gsn->missing++;
+				GTP_LOGPKG(LOGL_ERROR, peer,
+					    pack, len,
+					    "Missing conditional information field\n");
+				if (gsn->cb_conf)
+					gsn->cb_conf(type, EOF, pdp, cbp);
+				/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
+				   pdp_freepdp(pdp); */
+				return EOF;
+			}
+		}
+
+		if (gtpie_gettv4(ie, GTPIE_CHARGING_ID, 0, &pdp->cid)) {
+			gsn->missing++;
+			GTP_LOGPKG(LOGL_ERROR, peer, pack,
+				    len,
+				    "Missing conditional information field\n");
+			if (gsn->cb_conf)
+				gsn->cb_conf(type, EOF, pdp, cbp);
+			/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
+			   pdp_freepdp(pdp); */
+		}
+
+		if (gtpie_gettlv(ie, GTPIE_GSN_ADDR, 0, &pdp->gsnrc.l,
+				 &pdp->gsnrc.v, sizeof(pdp->gsnrc.v))) {
 			gsn->missing++;
 			GTP_LOGPKG(LOGL_ERROR, peer, pack,
 				    len,
@@ -2252,24 +2317,39 @@ int gtp_update_pdp_conf(struct gsn_t *gsn, int version,
 			return EOF;
 		}
 
-		/* Update pdp with new values */
-		gtpie_gettv0(ie, GTPIE_QOS_PROFILE0, 0,
-			     pdp->qos_neg0, sizeof(pdp->qos_neg0));
-		gtpie_gettv1(ie, GTPIE_REORDER, 0, &pdp->reorder);
-		gtpie_gettv2(ie, GTPIE_FL_DI, 0, &pdp->flru);
-		gtpie_gettv2(ie, GTPIE_FL_C, 0, &pdp->flrc);
-		gtpie_gettv4(ie, GTPIE_CHARGING_ID, 0, &pdp->cid);
-		gtpie_gettlv(ie, GTPIE_EUA, 0, &pdp->eua.l,
-			     &pdp->eua.v, sizeof(pdp->eua.v));
-		gtpie_gettlv(ie, GTPIE_GSN_ADDR, 0, &pdp->gsnrc.l,
-			     &pdp->gsnrc.v, sizeof(pdp->gsnrc.v));
-		gtpie_gettlv(ie, GTPIE_GSN_ADDR, 1, &pdp->gsnru.l,
-			     &pdp->gsnru.v, sizeof(pdp->gsnru.v));
+		if (gtpie_gettlv(ie, GTPIE_GSN_ADDR, 1, &pdp->gsnru.l,
+				 &pdp->gsnru.v, sizeof(pdp->gsnru.v))) {
+			gsn->missing++;
+			GTP_LOGPKG(LOGL_ERROR, peer, pack,
+				    len,
+				    "Missing conditional information field\n");
+			if (gsn->cb_conf)
+				gsn->cb_conf(type, EOF, pdp, cbp);
+			/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
+			   pdp_freepdp(pdp); */
+			return EOF;
+		}
 
-		if (gsn->cb_conf)
-			gsn->cb_conf(type, cause, pdp, cbp);
-		return 0;	/* Succes */
+		if (version == 1) {
+			if (gtpie_gettlv
+			    (ie, GTPIE_QOS_PROFILE, 0, &pdp->qos_neg.l,
+			     &pdp->qos_neg.v, sizeof(pdp->qos_neg.v))) {
+				gsn->missing++;
+				GTP_LOGPKG(LOGL_ERROR, peer,
+					    pack, len,
+					    "Missing conditional information field\n");
+				if (gsn->cb_conf)
+					gsn->cb_conf(type, EOF, pdp, cbp);
+				/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
+				   pdp_freepdp(pdp); */
+				return EOF;
+			}
+		}
 	}
+
+	if (gsn->cb_conf)
+		gsn->cb_conf(type, cause, pdp, cbp);
+	return 0;	/* Succes */
 }
 
 /* API: Send Delete PDP Context Request */
-- 
2.1.4



From laforge at gnumonks.org  Wed Feb  3 18:12:53 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 3 Feb 2016 19:12:53 +0100
Subject: [PATCH 3/3] gtp: Handle gtpv1 in gtp_update_pdp_conf() correctly
In-Reply-To: <31daf439e34a6f4b1b6a323ab84e437371f972d5.1454521570.git.daniel@totalueberwachung.de>
References: <cover.1454521570.git.daniel@totalueberwachung.de>
 <31daf439e34a6f4b1b6a323ab84e437371f972d5.1454521570.git.daniel@totalueberwachung.de>
Message-ID: <20160203181253.GB2572@nataraja>

Hi Daniel,

On Wed, Feb 03, 2016 at 06:53:31PM +0100, Daniel Willmann wrote:
> +			if (gtpie_gettv0(ie, GTPIE_QOS_PROFILE0, 0,
> +					 &pdp->qos_neg0,
> +					 sizeof(pdp->qos_neg0))) {
> +				gsn->missing++;
> +				GTP_LOGPKG(LOGL_ERROR, peer,
> +					    pack, len,
> +					    "Missing conditional information field\n");
> +				if (gsn->cb_conf)
> +					gsn->cb_conf(type, EOF, pdp, cbp);
> +				/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
> +				   pdp_freepdp(pdp); */
> +				return EOF;
> +			}
> +
> +			if (gtpie_gettv2(ie, GTPIE_FL_DI, 0, &pdp->flru)) {
> +				gsn->missing++;
> +				GTP_LOGPKG(LOGL_ERROR, peer,
> +					    pack, len,
> +					    "Missing conditional information field\n");
> +				if (gsn->cb_conf)
> +					gsn->cb_conf(type, EOF, pdp, cbp);
> +				/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
> +				   pdp_freepdp(pdp); */
> +				return EOF;
> +			}

This looks like a bit too much of copy+paste to me.  Can't we put that
into a separate function, or if not, at least a macro that hides all the
verbosity and the copy+paste?  Also, why is ther a commented-out section
about cb_delete_context involved?


-- 
- 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 dwillmann at sysmocom.de  Thu Feb  4 14:38:12 2016
From: dwillmann at sysmocom.de (Daniel Willmann)
Date: Thu,  4 Feb 2016 15:38:12 +0100
Subject: [PATCH 1/1] gtp: Handle gtpv1 in gtp_update_pdp_conf() correctly
In-Reply-To: <1454596518.856.105.camel@sysmocom.de>
References: <1454596518.856.105.camel@sysmocom.de>
Message-ID: <80cf42b077621bce0323cda270a8adfbe8a6098a.1454596571.git.daniel@totalueberwachung.de>

libgtp cannot understand its own update pdp request (in gtp v1)
Only require the conditional and mandatory fields for gtpv1 and not
others.
Refer to 3GPP TS 29.060 Ch. 7.3.4
---
 gtp/gtp.c | 120 +++++++++++++++++++++++++++++++++-----------------------------
 1 file changed, 63 insertions(+), 57 deletions(-)

diff --git a/gtp/gtp.c b/gtp/gtp.c
index 2a6ecd7..12cb492 100644
--- a/gtp/gtp.c
+++ b/gtp/gtp.c
@@ -2187,9 +2187,8 @@ int gtp_update_pdp_conf(struct gsn_t *gsn, int version,
 		gsn->err_unknownpdp++;
 		GTP_LOGPKG(LOGL_ERROR, peer, pack, len,
 			    "Unknown PDP context: %u\n", get_tei(pack));
-		if (gsn->cb_conf)
-			gsn->cb_conf(type, EOF, NULL, cbp);
-		return EOF;
+		pdp = NULL;
+		goto err_out;
 	}
 
 	/* Register that we have received a valid teic from GGSN */
@@ -2200,23 +2199,12 @@ int gtp_update_pdp_conf(struct gsn_t *gsn, int version,
 		gsn->invalid++;
 		GTP_LOGPKG(LOGL_ERROR, peer, pack, len,
 			    "Invalid message format\n");
-		if (gsn->cb_conf)
-			gsn->cb_conf(type, EOF, pdp, cbp);
-		/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
-		   pdp_freepdp(pdp); */
-		return EOF;
+		goto err_out;
 	}
 
 	/* Extract cause value (mandatory) */
 	if (gtpie_gettv1(ie, GTPIE_CAUSE, 0, &cause)) {
-		gsn->missing++;
-		GTP_LOGPKG(LOGL_ERROR, peer, pack, len,
-			    "Missing mandatory information field\n");
-		if (gsn->cb_conf)
-			gsn->cb_conf(type, EOF, pdp, cbp);
-		/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
-		   pdp_freepdp(pdp); */
-		return EOF;
+		goto err_missing;
 	}
 
 	/* Extract recovery (optional) */
@@ -2226,51 +2214,69 @@ int gtp_update_pdp_conf(struct gsn_t *gsn, int version,
 	}
 
 	/* Check all conditional information elements */
-	if (GTPCAUSE_ACC_REQ != cause) {
-		if (gsn->cb_conf)
-			gsn->cb_conf(type, cause, pdp, cbp);
-		/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
-		   pdp_freepdp(pdp); */
-		return 0;
-	} else {
-		/* Check for missing conditionary information elements */
-		if (!(gtpie_exist(ie, GTPIE_QOS_PROFILE0, 0) &&
-		      gtpie_exist(ie, GTPIE_REORDER, 0) &&
-		      gtpie_exist(ie, GTPIE_FL_DI, 0) &&
-		      gtpie_exist(ie, GTPIE_FL_C, 0) &&
-		      gtpie_exist(ie, GTPIE_CHARGING_ID, 0) &&
-		      gtpie_exist(ie, GTPIE_EUA, 0) &&
-		      gtpie_exist(ie, GTPIE_GSN_ADDR, 0) &&
-		      gtpie_exist(ie, GTPIE_GSN_ADDR, 1))) {
-			gsn->missing++;
-			GTP_LOGPKG(LOGL_ERROR, peer, pack,
-				    len,
-				    "Missing conditional information field\n");
-			if (gsn->cb_conf)
-				gsn->cb_conf(type, EOF, pdp, cbp);
-			/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
-			   pdp_freepdp(pdp); */
-			return EOF;
+	/* TODO: This does not handle GGSN-initiated update responses */
+	if (GTPCAUSE_ACC_REQ == cause) {
+		if (version == 0) {
+			if (gtpie_gettv0(ie, GTPIE_QOS_PROFILE0, 0,
+					 &pdp->qos_neg0,
+					 sizeof(pdp->qos_neg0))) {
+				goto err_missing;
+			}
+
+			if (gtpie_gettv2(ie, GTPIE_FL_DI, 0, &pdp->flru)) {
+				goto err_missing;
+			}
+
+			if (gtpie_gettv2(ie, GTPIE_FL_C, 0, &pdp->flrc)) {
+				goto err_missing;
+			}
 		}
 
-		/* Update pdp with new values */
-		gtpie_gettv0(ie, GTPIE_QOS_PROFILE0, 0,
-			     pdp->qos_neg0, sizeof(pdp->qos_neg0));
-		gtpie_gettv1(ie, GTPIE_REORDER, 0, &pdp->reorder);
-		gtpie_gettv2(ie, GTPIE_FL_DI, 0, &pdp->flru);
-		gtpie_gettv2(ie, GTPIE_FL_C, 0, &pdp->flrc);
-		gtpie_gettv4(ie, GTPIE_CHARGING_ID, 0, &pdp->cid);
-		gtpie_gettlv(ie, GTPIE_EUA, 0, &pdp->eua.l,
-			     &pdp->eua.v, sizeof(pdp->eua.v));
-		gtpie_gettlv(ie, GTPIE_GSN_ADDR, 0, &pdp->gsnrc.l,
-			     &pdp->gsnrc.v, sizeof(pdp->gsnrc.v));
-		gtpie_gettlv(ie, GTPIE_GSN_ADDR, 1, &pdp->gsnru.l,
-			     &pdp->gsnru.v, sizeof(pdp->gsnru.v));
+		if (version == 1) {
+			if (gtpie_gettv4(ie, GTPIE_TEI_DI, 0, &pdp->teid_gn)) {
+				goto err_missing;
+			}
 
-		if (gsn->cb_conf)
-			gsn->cb_conf(type, cause, pdp, cbp);
-		return 0;	/* Succes */
+			if (gtpie_gettv4(ie, GTPIE_TEI_C, 0, &pdp->teic_gn)) {
+				goto err_missing;
+			}
+		}
+
+		if (gtpie_gettv4(ie, GTPIE_CHARGING_ID, 0, &pdp->cid)) {
+			goto err_missing;
+		}
+
+		if (gtpie_gettlv(ie, GTPIE_GSN_ADDR, 0, &pdp->gsnrc.l,
+				 &pdp->gsnrc.v, sizeof(pdp->gsnrc.v))) {
+			goto err_missing;
+		}
+
+		if (gtpie_gettlv(ie, GTPIE_GSN_ADDR, 1, &pdp->gsnru.l,
+				 &pdp->gsnru.v, sizeof(pdp->gsnru.v))) {
+			goto err_missing;
+		}
+
+		if (version == 1) {
+			if (gtpie_gettlv
+			    (ie, GTPIE_QOS_PROFILE, 0, &pdp->qos_neg.l,
+			     &pdp->qos_neg.v, sizeof(pdp->qos_neg.v))) {
+				goto err_missing;
+			}
+		}
 	}
+
+	if (gsn->cb_conf)
+		gsn->cb_conf(type, cause, pdp, cbp);
+	return 0;	/* Succes */
+
+err_missing:
+	gsn->missing++;
+	GTP_LOGPKG(LOGL_ERROR, peer, pack, len,
+		    "Missing information field\n");
+err_out:
+	if (gsn->cb_conf)
+		gsn->cb_conf(type, EOF, pdp, cbp);
+	return EOF;
 }
 
 /* API: Send Delete PDP Context Request */
-- 
2.1.4



From jerlbeck at sysmocom.de  Thu Feb  4 17:59:05 2016
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Thu, 4 Feb 2016 18:59:05 +0100
Subject: EDGE over osmo-pcu
Message-ID: <56B39169.4050302@sysmocom.de>

Hi everybody,

we have just done the first download of an Internet page using the
current bleeding EDGE development version of the OSMO-PCU. Supported are
MCS-1 to MCS-9 in downlink and MCS-1 to MCS-4 in uplink direction.

The download of 'www.osmocom.org' has been documented in a PCAP file and
can be downloaded from

  https://openbsc.osmocom.org/trac/wiki/osmo-pcu

To decode the data blocks, an experimental patch for the gsmtab
dissector is also available from there.

Cheers

Jacob

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


From alexander.chemeris at gmail.com  Thu Feb  4 22:25:30 2016
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Thu, 4 Feb 2016 14:25:30 -0800
Subject: EDGE over osmo-pcu
In-Reply-To: <56169256.1216377.1454622005188.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <56B39169.4050302@sysmocom.de>
 <56169256.1216377.1454622005188.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <CABmJbFW4r6xg_A09oh2fAACozf-g0D1V1WCv9MsiozV=HZFgww@mail.gmail.com>

Hi Sipos,

Osmo-trx does not support 8-PSK at this moment, so you should implement it
if you want to test it. ;)

Please excuse typos. Written with a touchscreen keyboard.

--
Regards,
Alexander Chemeris
CEO Fairwaves, Inc.
https://fairwaves.co
On Feb 4, 2016 1:43 PM, "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu> wrote:

> Hi Jacob,
>
> Congratulations and thank you for all your hard work.
>
> I hope I can do some testing on the weekend with a B200. I will also
> update the wiki article if needed.
>
> Just one question: for MCS5-9 in the downlink there is no need to update
> the Osmo-TRX code? Does it support 8PSK as it is now?
>
> Regards,
> Csaba
>
> ----- Eredeti ?zenet -----
> Felad?: "Jacob Erlbeck" <jerlbeck at sysmocom.de>
> C?mzett: osmocom-net-gprs at lists.osmocom.org
> M?solatot kap: openbsc at lists.osmocom.org
> Elk?ld?tt ?zenetek: Cs?t?rt?k, 2016. Febru?r 4. 18:59:05
> T?rgy: EDGE over osmo-pcu
>
> Hi everybody,
>
> we have just done the first download of an Internet page using the
> current bleeding EDGE development version of the OSMO-PCU. Supported are
> MCS-1 to MCS-9 in downlink and MCS-1 to MCS-4 in uplink direction.
>
> The download of 'www.osmocom.org' has been documented in a PCAP file and
> can be downloaded from
>
>   https://openbsc.osmocom.org/trac/wiki/osmo-pcu
>
> To decode the data blocks, an experimental patch for the gsmtab
> dissector is also available from there.
>
> Cheers
>
> Jacob
>
> --
> - Jacob Erlbeck <jerlbeck at sysmocom.de>       http://www.sysmocom.de/
> =======================================================================
> * sysmocom - systems for mobile communications GmbH
> * Alt-Moabit 93
> * 10559 Berlin, Germany
> * Sitz / Registered office: Berlin, HRB 134158 B
> * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160204/46a89459/attachment.htm>

From alexander.chemeris at gmail.com  Thu Feb  4 23:32:30 2016
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Thu, 4 Feb 2016 15:32:30 -0800
Subject: EDGE over osmo-pcu
In-Reply-To: <1432656151.1221952.1454626732370.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <56B39169.4050302@sysmocom.de>
 <56169256.1216377.1454622005188.JavaMail.zimbra@kvk.uni-obuda.hu>
 <CABmJbFW4r6xg_A09oh2fAACozf-g0D1V1WCv9MsiozV=HZFgww@mail.gmail.com>
 <1432656151.1221952.1454626732370.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <CABmJbFVUu7q_tAxbnFwDUPaYOYakYR7UgNDhkUYO3YbF4wjmCw@mail.gmail.com>

Sipos,

All thanks for this EDGE development goes to Jacob/Sysmocom. We at
Fairwaves haven't looked at it yet. We're planning to add 8PSK to osmo-trx,
but we don't have a roadmap for it yet.

Please excuse typos. Written with a touchscreen keyboard.

--
Regards,
Alexander Chemeris
CEO Fairwaves, Inc.
https://fairwaves.co
On Feb 4, 2016 3:01 PM, "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu> wrote:

> Hi Alexander,
>
> Thats what I was afraid of :-)
>
> Anyway, even having EDGE with GMSK MCSs is a huge step forward, so I can't
> say anything but thank you, and I hope I can contribute with some testing
> and protocol analysis. :-)
>
> Now we are using OpenBSC in two lab exercises and I hope to extend it with
> SDR and EDGE. I can't wait to try it :-)
>
> Regards,
> Csaba
>
> ----- Eredeti ?zenet -----
> Felad?: "Alexander Chemeris" <alexander.chemeris at gmail.com>
> C?mzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
> M?solatot kap: "OpenBSC Mailing List" <openbsc at lists.osmocom.org>,
> osmocom-net-gprs at lists.osmocom.org, "Jacob Erlbeck" <jerlbeck at sysmocom.de>
> Elk?ld?tt ?zenetek: Cs?t?rt?k, 2016. Febru?r 4. 23:25:30
> T?rgy: Re: EDGE over osmo-pcu
>
> Hi Sipos,
>
> Osmo-trx does not support 8-PSK at this moment, so you should implement it
> if you want to test it. ;)
>
> Please excuse typos. Written with a touchscreen keyboard.
>
> --
> Regards,
> Alexander Chemeris
> CEO Fairwaves, Inc.
> https://fairwaves.co
> On Feb 4, 2016 1:43 PM, "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
> wrote:
>
> > Hi Jacob,
> >
> > Congratulations and thank you for all your hard work.
> >
> > I hope I can do some testing on the weekend with a B200. I will also
> > update the wiki article if needed.
> >
> > Just one question: for MCS5-9 in the downlink there is no need to update
> > the Osmo-TRX code? Does it support 8PSK as it is now?
> >
> > Regards,
> > Csaba
> >
> > ----- Eredeti ?zenet -----
> > Felad?: "Jacob Erlbeck" <jerlbeck at sysmocom.de>
> > C?mzett: osmocom-net-gprs at lists.osmocom.org
> > M?solatot kap: openbsc at lists.osmocom.org
> > Elk?ld?tt ?zenetek: Cs?t?rt?k, 2016. Febru?r 4. 18:59:05
> > T?rgy: EDGE over osmo-pcu
> >
> > Hi everybody,
> >
> > we have just done the first download of an Internet page using the
> > current bleeding EDGE development version of the OSMO-PCU. Supported are
> > MCS-1 to MCS-9 in downlink and MCS-1 to MCS-4 in uplink direction.
> >
> > The download of 'www.osmocom.org' has been documented in a PCAP file and
> > can be downloaded from
> >
> >   https://openbsc.osmocom.org/trac/wiki/osmo-pcu
> >
> > To decode the data blocks, an experimental patch for the gsmtab
> > dissector is also available from there.
> >
> > Cheers
> >
> > Jacob
> >
> > --
> > - Jacob Erlbeck <jerlbeck at sysmocom.de>       http://www.sysmocom.de/
> > =======================================================================
> > * sysmocom - systems for mobile communications GmbH
> > * Alt-Moabit 93
> > * 10559 Berlin, Germany
> > * Sitz / Registered office: Berlin, HRB 134158 B
> > * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160204/05ea5509/attachment.htm>

From jerlbeck at sysmocom.de  Fri Feb  5 10:22:40 2016
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Fri, 5 Feb 2016 11:22:40 +0100
Subject: EDGE over osmo-pcu
In-Reply-To: <56169256.1216377.1454622005188.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <56B39169.4050302@sysmocom.de>
 <56169256.1216377.1454622005188.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <56B477F0.2030508@sysmocom.de>

Hi Sipos

On 04.02.2016 22:40, Sipos Csaba wrote:
> 
> Congratulations and thank you for all your hard work.

Thank you. And many thanks to Sysmocom and On-Waves to make this possible.

> 
> I hope I can do some testing on the weekend with a B200. I will also update the wiki article if needed.

It is not in master yet and my development (wip) branch is still a mess
(GPRS is b0rken in the latter), but this should improve soon. I'll put
the revised commits to jerlbeck/master first.

> Just one question: for MCS5-9 in the downlink there is no need to update the Osmo-TRX code? Does it support 8PSK as it is now?

I've only tested it with the sysmobts with direct DSP access so far and
haven't looked at the Osmo-TRX or the pcu-if socket based connection to
the BTS. But currently the CS/MCS choice is only communicated indirectly
via the RLC block size which is unique for each coding scheme. The CPS
(coding and puncturing scheme) is also not passed explicitly, only
within the header which is different for each MCS header type. So the
API for downlink blocks hasn't change, and it should only depend of the
MCS encoding/decoding capabilities of the RF DSP/software.

Regards

Jacob

> ----- Eredeti ?zenet -----
> Felad?: "Jacob Erlbeck" <jerlbeck at sysmocom.de>
> C?mzett: osmocom-net-gprs at lists.osmocom.org
> M?solatot kap: openbsc at lists.osmocom.org
> Elk?ld?tt ?zenetek: Cs?t?rt?k, 2016. Febru?r 4. 18:59:05
> T?rgy: EDGE over osmo-pcu
> 
> Hi everybody,
> 
> we have just done the first download of an Internet page using the
> current bleeding EDGE development version of the OSMO-PCU. Supported are
> MCS-1 to MCS-9 in downlink and MCS-1 to MCS-4 in uplink direction.
> 
> The download of 'www.osmocom.org' has been documented in a PCAP file and
> can be downloaded from
> 
>   https://openbsc.osmocom.org/trac/wiki/osmo-pcu
> 
> To decode the data blocks, an experimental patch for the gsmtab
> dissector is also available from there.
> 
> Cheers
> 
> Jacob
> 


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


From dwillmann at sysmocom.de  Thu Feb  4 14:35:18 2016
From: dwillmann at sysmocom.de (Daniel Willmann)
Date: Thu, 04 Feb 2016 15:35:18 +0100
Subject: [PATCH 3/3] gtp: Handle gtpv1 in gtp_update_pdp_conf() correctly
In-Reply-To: <20160203181253.GB2572@nataraja>
 (sfid-20160203_191512_984670_59F8426C)
References: <cover.1454521570.git.daniel@totalueberwachung.de>
 <31daf439e34a6f4b1b6a323ab84e437371f972d5.1454521570.git.daniel@totalueberwachung.de>
 <20160203181253.GB2572@nataraja> (sfid-20160203_191512_984670_59F8426C)
Message-ID: <1454596518.856.105.camel@sysmocom.de>

Hi Harald,

On Wed, 2016-02-03 at 19:12 +0100, Harald Welte wrote:
> On Wed, Feb 03, 2016 at 06:53:31PM +0100, Daniel Willmann wrote:
> > +			if (gtpie_gettv0(ie, GTPIE_QOS_PROFILE0, 0,
> > +					 &pdp->qos_neg0,
> > +					 sizeof(pdp->qos_neg0))) {
> > +				gsn->missing++;
> > +				GTP_LOGPKG(LOGL_ERROR, peer,
> > +					    pack, len,
> > +					    "Missing conditional information field\n");
> > +				if (gsn->cb_conf)
> > +					gsn->cb_conf(type, EOF, pdp, cbp);
> > +				/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
> > +				   pdp_freepdp(pdp); */
> > +				return EOF;
> > +			}
> > +
> > +			if (gtpie_gettv2(ie, GTPIE_FL_DI, 0, &pdp->flru)) {
> > +				gsn->missing++;
> > +				GTP_LOGPKG(LOGL_ERROR, peer,
> > +					    pack, len,
> > +					    "Missing conditional information field\n");
> > +				if (gsn->cb_conf)
> > +					gsn->cb_conf(type, EOF, pdp, cbp);
> > +				/*    if (gsn->cb_delete_context) gsn->cb_delete_context(pdp);
> > +				   pdp_freepdp(pdp); */
> > +				return EOF;
> > +			}
> 
> This looks like a bit too much of copy+paste to me.  Can't we put that

true. Unfortunately, the whole code looks like this and I tried to stick
with the "style".

> into a separate function, or if not, at least a macro that hides all the
> verbosity and the copy+paste?  Also, why is ther a commented-out section
> about cb_delete_context involved?

A function or macro will need 7 variables passed to it which makes the
whole thing quite ugly (unless the macro makes assumptions about the
local variable names). I have now put the error handling code at the end
of the function and jump to it in case of an error.

We lose the ability to infer the missing element from the line number of
the log message, but I don't think it's a big issue. The message is
still logged and wireshark can be used for debugging as well.

The section about cb_delete_context was there before (and still is in
other parts of the code). I have removed it in that function now.


Regards
Daniel

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



From sipos.csaba at kvk.uni-obuda.hu  Thu Feb  4 21:40:05 2016
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Thu, 4 Feb 2016 22:40:05 +0100 (CET)
Subject: EDGE over osmo-pcu
In-Reply-To: <56B39169.4050302@sysmocom.de>
References: <56B39169.4050302@sysmocom.de>
Message-ID: <56169256.1216377.1454622005188.JavaMail.zimbra@kvk.uni-obuda.hu>

Hi Jacob,

Congratulations and thank you for all your hard work.

I hope I can do some testing on the weekend with a B200. I will also update the wiki article if needed.

Just one question: for MCS5-9 in the downlink there is no need to update the Osmo-TRX code? Does it support 8PSK as it is now?

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Jacob Erlbeck" <jerlbeck at sysmocom.de>
C?mzett: osmocom-net-gprs at lists.osmocom.org
M?solatot kap: openbsc at lists.osmocom.org
Elk?ld?tt ?zenetek: Cs?t?rt?k, 2016. Febru?r 4. 18:59:05
T?rgy: EDGE over osmo-pcu

Hi everybody,

we have just done the first download of an Internet page using the
current bleeding EDGE development version of the OSMO-PCU. Supported are
MCS-1 to MCS-9 in downlink and MCS-1 to MCS-4 in uplink direction.

The download of 'www.osmocom.org' has been documented in a PCAP file and
can be downloaded from

  https://openbsc.osmocom.org/trac/wiki/osmo-pcu

To decode the data blocks, an experimental patch for the gsmtab
dissector is also available from there.

Cheers

Jacob

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


From sipos.csaba at kvk.uni-obuda.hu  Thu Feb  4 22:58:52 2016
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Thu, 4 Feb 2016 23:58:52 +0100 (CET)
Subject: EDGE over osmo-pcu
In-Reply-To: <CABmJbFW4r6xg_A09oh2fAACozf-g0D1V1WCv9MsiozV=HZFgww@mail.gmail.com>
References: <56B39169.4050302@sysmocom.de>
 <56169256.1216377.1454622005188.JavaMail.zimbra@kvk.uni-obuda.hu>
 <CABmJbFW4r6xg_A09oh2fAACozf-g0D1V1WCv9MsiozV=HZFgww@mail.gmail.com>
Message-ID: <1432656151.1221952.1454626732370.JavaMail.zimbra@kvk.uni-obuda.hu>

Hi Alexander,

Thats what I was afraid of :-)

Anyway, even having EDGE with GMSK MCSs is a huge step forward, so I can't say anything but thank you, and I hope I can contribute with some testing and protocol analysis. :-)

Now we are using OpenBSC in two lab exercises and I hope to extend it with SDR and EDGE. I can't wait to try it :-)

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Alexander Chemeris" <alexander.chemeris at gmail.com>
C?mzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
M?solatot kap: "OpenBSC Mailing List" <openbsc at lists.osmocom.org>, osmocom-net-gprs at lists.osmocom.org, "Jacob Erlbeck" <jerlbeck at sysmocom.de>
Elk?ld?tt ?zenetek: Cs?t?rt?k, 2016. Febru?r 4. 23:25:30
T?rgy: Re: EDGE over osmo-pcu

Hi Sipos,

Osmo-trx does not support 8-PSK at this moment, so you should implement it
if you want to test it. ;)

Please excuse typos. Written with a touchscreen keyboard.

--
Regards,
Alexander Chemeris
CEO Fairwaves, Inc.
https://fairwaves.co
On Feb 4, 2016 1:43 PM, "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu> wrote:

> Hi Jacob,
>
> Congratulations and thank you for all your hard work.
>
> I hope I can do some testing on the weekend with a B200. I will also
> update the wiki article if needed.
>
> Just one question: for MCS5-9 in the downlink there is no need to update
> the Osmo-TRX code? Does it support 8PSK as it is now?
>
> Regards,
> Csaba
>
> ----- Eredeti ?zenet -----
> Felad?: "Jacob Erlbeck" <jerlbeck at sysmocom.de>
> C?mzett: osmocom-net-gprs at lists.osmocom.org
> M?solatot kap: openbsc at lists.osmocom.org
> Elk?ld?tt ?zenetek: Cs?t?rt?k, 2016. Febru?r 4. 18:59:05
> T?rgy: EDGE over osmo-pcu
>
> Hi everybody,
>
> we have just done the first download of an Internet page using the
> current bleeding EDGE development version of the OSMO-PCU. Supported are
> MCS-1 to MCS-9 in downlink and MCS-1 to MCS-4 in uplink direction.
>
> The download of 'www.osmocom.org' has been documented in a PCAP file and
> can be downloaded from
>
>   https://openbsc.osmocom.org/trac/wiki/osmo-pcu
>
> To decode the data blocks, an experimental patch for the gsmtab
> dissector is also available from there.
>
> Cheers
>
> Jacob
>
> --
> - Jacob Erlbeck <jerlbeck at sysmocom.de>       http://www.sysmocom.de/
> =======================================================================
> * sysmocom - systems for mobile communications GmbH
> * Alt-Moabit 93
> * 10559 Berlin, Germany
> * Sitz / Registered office: Berlin, HRB 134158 B
> * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
>


From jerlbeck at sysmocom.de  Tue Feb  9 22:28:24 2016
From: jerlbeck at sysmocom.de (Jacob Erlbeck)
Date: Tue, 9 Feb 2016 23:28:24 +0100
Subject: EDGE over osmo-pcu
In-Reply-To: <56B477F0.2030508@sysmocom.de>
References: <56B39169.4050302@sysmocom.de>
 <56169256.1216377.1454622005188.JavaMail.zimbra@kvk.uni-obuda.hu>
 <56B477F0.2030508@sysmocom.de>
Message-ID: <56BA6808.3050900@sysmocom.de>

Hi Sipos,

On 05.02.2016 11:22, Jacob Erlbeck wrote:
> 
> On 04.02.2016 22:40, Sipos Csaba wrote:
>>
>> I hope I can do some testing on the weekend with a B200. I will also update the wiki article if needed.
> 
> It is not in master yet and my development (wip) branch is still a mess
> (GPRS is b0rken in the latter), but this should improve soon. I'll put
> the revised commits to jerlbeck/master first.

GPRS is fixed and jerlbeck/master is updated. Make sure to limit the MCS
according to the HW/SW, so use the 'mcs max 4' command if the HW does
not support 8PSK. Note that 8PSK is only supported for downlink yet, but
the 'mcs max' command does not check this. So you should use 'mcs max 9
4' explicitely (this should be fixed by the additional commits
(currently) in jerlbeck/testing/pcu, which adds that check and proper
default values).

Jacob

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


From sipos.csaba at kvk.uni-obuda.hu  Sat Feb 13 14:27:44 2016
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Sat, 13 Feb 2016 15:27:44 +0100 (CET)
Subject: EDGE over osmo-pcu
In-Reply-To: <56BA6808.3050900@sysmocom.de>
References: <56B39169.4050302@sysmocom.de>
 <56169256.1216377.1454622005188.JavaMail.zimbra@kvk.uni-obuda.hu>
 <56B477F0.2030508@sysmocom.de> <56BA6808.3050900@sysmocom.de>
Message-ID: <1324311217.2742117.1455373664759.JavaMail.zimbra@kvk.uni-obuda.hu>

Hi Jacob,

Thanks for the information.

Just wanted to test the new code, and I hit this problem:

make[1]: Entering directory `/root/new_osmocom/osmo-pcu/src'
  CXX      decoding.lo
decoding.cpp:26:34: fatal error: osmocom/core/bitcomp.h: No such file or directory
 #include <osmocom/core/bitcomp.h>
                                  ^
compilation terminated.
make[1]: *** [decoding.lo] Error 1
make[1]: Leaving directory `/root/new_osmocom/osmo-pcu/src'
make: *** [all-recursive] Error 1

The libosmocore (master) is updated today, and the missing file is actually in /usr/local/include/osmocom/core/bitvec.h

I tried both "jerlbeck/testing/pcu" and "jerlbeck/master" branches, the error is the same.

Maybe I am missing something?

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Jacob Erlbeck" <jerlbeck at sysmocom.de>
C?mzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
M?solatot kap: osmocom-net-gprs at lists.osmocom.org, openbsc at lists.osmocom.org
Elk?ld?tt ?zenetek: Kedd, 2016. Febru?r 9. 23:28:24
T?rgy: Re: EDGE over osmo-pcu

Hi Sipos,

On 05.02.2016 11:22, Jacob Erlbeck wrote:
> 
> On 04.02.2016 22:40, Sipos Csaba wrote:
>>
>> I hope I can do some testing on the weekend with a B200. I will also update the wiki article if needed.
> 
> It is not in master yet and my development (wip) branch is still a mess
> (GPRS is b0rken in the latter), but this should improve soon. I'll put
> the revised commits to jerlbeck/master first.

GPRS is fixed and jerlbeck/master is updated. Make sure to limit the MCS
according to the HW/SW, so use the 'mcs max 4' command if the HW does
not support 8PSK. Note that 8PSK is only supported for downlink yet, but
the 'mcs max' command does not check this. So you should use 'mcs max 9
4' explicitely (this should be fixed by the additional commits
(currently) in jerlbeck/testing/pcu, which adds that check and proper
default values).

Jacob

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


From holger at freyther.de  Sat Feb 13 17:51:55 2016
From: holger at freyther.de (Holger Freyther)
Date: Sat, 13 Feb 2016 18:51:55 +0100
Subject: EDGE over osmo-pcu
In-Reply-To: <1324311217.2742117.1455373664759.JavaMail.zimbra@kvk.uni-obuda.hu>
References: <56B39169.4050302@sysmocom.de>
 <56169256.1216377.1454622005188.JavaMail.zimbra@kvk.uni-obuda.hu>
 <56B477F0.2030508@sysmocom.de> <56BA6808.3050900@sysmocom.de>
 <1324311217.2742117.1455373664759.JavaMail.zimbra@kvk.uni-obuda.hu>
Message-ID: <28DDF88A-101A-4C25-B334-1C516DD790A2@freyther.de>


> On 13 Feb 2016, at 15:27, Sipos Csaba <sipos.csaba at kvk.uni-obuda.hu> wrote:
> 
> Hi Jacob,
> 
> Thanks for the information.
> 
> Just wanted to test the new code, and I hit this problem:
> 
> make[1]: Entering directory `/root/new_osmocom/osmo-pcu/src'
>  CXX      decoding.lo
> decoding.cpp:26:34: fatal error: osmocom/core/bitcomp.h: No such file or directory
> #include <osmocom/core/bitcomp.h>

you need to grab the t4 patches Max from Sysmocom has posted. Due minor coding style issues these are not in master yet.



From Saurabh.Sharan at radisys.com  Mon Feb 22 12:32:03 2016
From: Saurabh.Sharan at radisys.com (Saurabh Sharan)
Date: Mon, 22 Feb 2016 12:32:03 +0000
Subject: Support of Basic EGPRS in OsmoPCU
Message-ID: <BY1PR08MB13082735543EA73BB5333F3485A30@BY1PR08MB1308.namprd08.prod.outlook.com>

Hello All,

We would like to provide the information that since Dec-2015 we have been working on adding the EGPRS support in OsmoPCU.  We have provided the support for Basic EGPRS feature, details of which explained below.

We would like to make the code available in Public domain so that we receive the feedback from all and upon approval would contribute to the master branch.

Following are the features added:

1)    EGPRS MCS 1 to MCS 9 coding scheme support

2)    Radio Link Control Block Structure Updates

3)    MCS Selection

4)    Transmission and reception data flows for MCS1 to MCS9

5)    EGPRS incremental redundancy (IR) mode, RLC function

6)    EGPRS Window selection

7)    RLC Re-segmentation and split block support

8)      RLC retransmission based on coding families A, A', B and C

We have taken interim rebase from the master during Jan-2016.

Regards,
Saurabh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160222/f580df1d/attachment.htm>

From dwillmann at sysmocom.de  Mon Feb 22 14:33:19 2016
From: dwillmann at sysmocom.de (Daniel Willmann)
Date: Mon, 22 Feb 2016 15:33:19 +0100
Subject: Support of Basic EGPRS in OsmoPCU
In-Reply-To: <BY1PR08MB13082735543EA73BB5333F3485A30@BY1PR08MB1308.namprd08.prod.outlook.com>
 (sfid-20160222_150644_696199_F2E4F678)
References: <BY1PR08MB13082735543EA73BB5333F3485A30@BY1PR08MB1308.namprd08.prod.outlook.com>
 (sfid-20160222_150644_696199_F2E4F678)
Message-ID: <1456151599.8409.25.camel@sysmocom.de>

Hello Saurabh,

On Mon, 2016-02-22 at 12:32 +0000, Saurabh Sharan wrote:
> Hello All,
> 
> We would like to provide the information that since Dec-2015 we have been working on adding the EGPRS support in OsmoPCU.  We have provided the support for Basic EGPRS feature, details of which explained below.
> 
> We would like to make the code available in Public domain so that we receive the feedback from all and upon approval would contribute to the master branch.

how about you upload the code to a public git hosting service (such as
github) and send the link to the mailing list? That way we can look at
the commits and give feedback.

Be aware that Jacob Erlbeck recently added support for EDGE to osmo-pcu
so some of your changes might be in conflict with changes in master.


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



From laforge at gnumonks.org  Mon Feb 22 14:45:06 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 22 Feb 2016 15:45:06 +0100
Subject: Support of Basic EGPRS in OsmoPCU
In-Reply-To: <BY1PR08MB13082735543EA73BB5333F3485A30@BY1PR08MB1308.namprd08.prod.outlook.com>
References: <BY1PR08MB13082735543EA73BB5333F3485A30@BY1PR08MB1308.namprd08.prod.outlook.com>
Message-ID: <20160222144506.GY5883@nataraja>

Hi Saurabh,

thanks for reaching out about this.

On Mon, Feb 22, 2016 at 12:32:03PM +0000, Saurabh Sharan wrote:
> We would like to provide the information that since Dec-2015 we have
> been working on adding the EGPRS support in OsmoPCU.  We have provided
> the support for Basic EGPRS feature, details of which explained below.
>
> We would like to make the code available in Public domain 

Sorry for being 'precise' here:  OsmoPCU is licensed under GNU GPL
v2-or-later.  This is a copyleft-style licenses that require any
modifications to be released under the same license.  That is contrary
to 'public domain' (which is a specific legal construct in the
anglo-american legal tradition whereby an author gives up all his rights
and anyone can do whatever he wants).  While we could merge code under
'public domain' into OsmoPCU, you cannot make modifications to the
GPL-licensed OsmoPCU and then put the result into public domain, sorry.

I suppose you just wanted to release it publicly and might have mixed up
the terms?

In either case, please send your changes as incremental per-feature
commits to this list, preferrably using git-send-email on your local
git repository.

In addition, it would also be great if you could push your git
repository to a public location.  If you send your SSH public key, we
can provide you a repository with write access on git.osmocom.org.

> We have taken interim rebase from the master during Jan-2016.

As Jacob has been working on EDGE support since October 2015 (see the
osmocom-commitlog mailing list), I fear there might be quite some
overlap to your changes.  It would have been great if you had reached
out before working in parallel on the same features.

So one the next step (after posting the current patches) would be to do
right now would be to re-base your changes on top of current
osmo-pcu.git/master.

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


From Saurabh.Sharan at radisys.com  Tue Feb 23 11:56:47 2016
From: Saurabh.Sharan at radisys.com (Saurabh Sharan)
Date: Tue, 23 Feb 2016 11:56:47 +0000
Subject: Support of Basic EGPRS in OsmoPCU
In-Reply-To: <20160222144506.GY5883@nataraja>
References: <BY1PR08MB13082735543EA73BB5333F3485A30@BY1PR08MB1308.namprd08.prod.outlook.com>
 <20160222144506.GY5883@nataraja>
Message-ID: <BY1PR08MB13086BF9ABEDEF43D970F50285A40@BY1PR08MB1308.namprd08.prod.outlook.com>

Thanks Harald and Daniel for your suggestions.
We will follow the steps as mentioned by you. I will send a separate mail with SSH-key details.

Regards
Saurabh

-----Original Message-----
From: Harald Welte [mailto:laforge at gnumonks.org] 
Sent: Monday, February 22, 2016 8:15 PM
To: Saurabh Sharan <Saurabh.Sharan at radisys.com>
Cc: osmocom-net-gprs at lists.osmocom.org
Subject: Re: Support of Basic EGPRS in OsmoPCU

Hi Saurabh,

thanks for reaching out about this.

On Mon, Feb 22, 2016 at 12:32:03PM +0000, Saurabh Sharan wrote:
> We would like to provide the information that since Dec-2015 we have 
> been working on adding the EGPRS support in OsmoPCU.  We have provided 
> the support for Basic EGPRS feature, details of which explained below.
>
> We would like to make the code available in Public domain

Sorry for being 'precise' here:  OsmoPCU is licensed under GNU GPL v2-or-later.  This is a copyleft-style licenses that require any modifications to be released under the same license.  That is contrary to 'public domain' (which is a specific legal construct in the anglo-american legal tradition whereby an author gives up all his rights and anyone can do whatever he wants).  While we could merge code under 'public domain' into OsmoPCU, you cannot make modifications to the GPL-licensed OsmoPCU and then put the result into public domain, sorry.

I suppose you just wanted to release it publicly and might have mixed up the terms?

In either case, please send your changes as incremental per-feature commits to this list, preferrably using git-send-email on your local git repository.

In addition, it would also be great if you could push your git repository to a public location.  If you send your SSH public key, we can provide you a repository with write access on git.osmocom.org.

> We have taken interim rebase from the master during Jan-2016.

As Jacob has been working on EDGE support since October 2015 (see the osmocom-commitlog mailing list), I fear there might be quite some overlap to your changes.  It would have been great if you had reached out before working in parallel on the same features.

So one the next step (after posting the current patches) would be to do right now would be to re-base your changes on top of current osmo-pcu.git/master.

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


From Saurabh.Sharan at radisys.com  Tue Feb 23 12:13:41 2016
From: Saurabh.Sharan at radisys.com (Saurabh Sharan)
Date: Tue, 23 Feb 2016 12:13:41 +0000
Subject: Support for Fast Ack/Nack Report in osmoPCU
Message-ID: <BY1PR08MB13088ACD8EC66D9BF2B091F485A40@BY1PR08MB1308.namprd08.prod.outlook.com>

Hello All,
We are currently working on providing the support of FANR in osmoPCU. We are in design phase and will share the design details soon.
Please provide your valuable feedback on the design.

Regards
Saurabh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160223/5b95592e/attachment.htm>

From laforge at gnumonks.org  Tue Feb 23 14:47:56 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 23 Feb 2016 15:47:56 +0100
Subject: Support for Fast Ack/Nack Report in osmoPCU
In-Reply-To: <BY1PR08MB13088ACD8EC66D9BF2B091F485A40@BY1PR08MB1308.namprd08.prod.outlook.com>
References: <BY1PR08MB13088ACD8EC66D9BF2B091F485A40@BY1PR08MB1308.namprd08.prod.outlook.com>
Message-ID: <20160223144756.GC18382@nataraja>

Hi Saurabh,

On Tue, Feb 23, 2016 at 12:13:41PM +0000, Saurabh Sharan wrote:

> We are currently working on providing the support of FANR in osmoPCU.
> We are in design phase and will share the design details soon.

'evolved edge' or 'later release' features have not been on our agenda
so far.  We have been working hard with very limited funding and
resources to get the most important basic GPRS and EDGE features
implemented so far.

>From our point of view, I wounldn't consider Fast Ack/Nack a
particularly important feature at this point.  The main important focus
areas are from my point of view are:
* interoperability testing with various handsets
* multi-slot allocations also for uplink
* 11bit RACH support
* implementation of regression tests, automatizing those tests
* continuous integration / testing setup

FANR seems like something really far at the horizon, with all the other
more basic "completeness" tasks at hand.  If you think it is important
to implement this now, I suggest you indeed shar your design details and
let us follow your development process by immediately pushing all
related changes to a public 'fanr' feature-branch in the git repository.

Irrespective of the above, we keep a list of known PCU issues / tasks at
https://projects.osmocom.org/projects/osmopcu/issues, where we invite
you to both report new bugs / features, as well as to help us to close
some of the existing ones.  If you register an account on the redmine,
just let me know the user name to provide write access to the OsmoPCU
issue tracker and wiki.

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 Saurabh.Sharan at radisys.com  Wed Feb 24 06:52:58 2016
From: Saurabh.Sharan at radisys.com (Saurabh Sharan)
Date: Wed, 24 Feb 2016 06:52:58 +0000
Subject: [PATCH] fix for encoding of padding bits
In-Reply-To: <1456225136-14177-1-git-send-email-saurabh.sharan@radisys.com>
References: <1456225136-14177-1-git-send-email-saurabh.sharan@radisys.com>
Message-ID: <BY1PR08MB130826D10666F77D40C163CC85A50@BY1PR08MB1308.namprd08.prod.outlook.com>

Hello Harald,
We had tried the option of sending one patch through git send-email. 
This was our first attempt so wanted to confirm whether we followed the process correctly. Please note that I am unable to see this patch(mail below) in Archive maintained at 
http://lists.osmocom.org/pipermail/osmocom-net-gprs/

Regards
Saurabh

-----Original Message-----
From: Saurabh Sharan [mailto:saurabh.sharan at radisys.com] 
Sent: Tuesday, February 23, 2016 4:29 PM
To: osmocom-net-gprs at lists.osmocom.org
Cc: Saurabh Sharan <Saurabh.Sharan at radisys.com>
Subject: [PATCH] fix for encoding of padding bits

---
 src/csn1.cpp |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/csn1.cpp b/src/csn1.cpp index 54cc411..9262c81 100644
--- a/src/csn1.cpp
+++ b/src/csn1.cpp
@@ -2400,7 +2400,12 @@ gint16 csnStreamEncoder(csnStream_t* ar, const CSN_DESCR* pDescr, bitvec *vector
             guint8 bits_to_handle = remaining_bits_len%8;
             if (bits_to_handle > 0)
             {
-              guint8 fl = filler&(0xff>>(8-bits_to_handle));
+	      /*section 11 of 44.060
+               *The padding bits may be the 'null' string. Otherwise, the
+	       *padding bits starts with bit '0', followed by 'spare padding'.
+	       *< padding bits > ::= { null | 0 < spare padding > ! < Ignore : 1 bit** = < no string > > } ;   
+	      */	 
+              guint8 fl = filler&(0xff>>(8-bits_to_handle + 1));
               bitvec_write_field(vector, writeIndex, fl, bits_to_handle);
               LOGPC(DCSN1, LOGL_NOTICE, "%u|", fl);
               remaining_bits_len -= bits_to_handle;
--
1.7.9.5




From laforge at gnumonks.org  Wed Feb 24 08:45:12 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 24 Feb 2016 09:45:12 +0100
Subject: [PATCH] fix for encoding of padding bits
In-Reply-To: <BY1PR08MB130826D10666F77D40C163CC85A50@BY1PR08MB1308.namprd08.prod.outlook.com>
References: <1456225136-14177-1-git-send-email-saurabh.sharan@radisys.com>
 <BY1PR08MB130826D10666F77D40C163CC85A50@BY1PR08MB1308.namprd08.prod.outlook.com>
Message-ID: <20160224084512.GO18382@nataraja>

Hi Saurabh,

On Wed, Feb 24, 2016 at 06:52:58AM +0000, Saurabh Sharan wrote:
> We had tried the option of sending one patch through git send-email. 
> This was our first attempt so wanted to confirm whether we followed
> the process correctly. Please note that I am unable to see this
> patch(mail below) in Archive maintained at 
> http://lists.osmocom.org/pipermail/osmocom-net-gprs/

Indeed, the mail did not arrive here.  Please check your git send-email
configuration.  By default, like it is customary on Unix/Linux systems,
git just hands over the mail to your local sysem-wide MTA installation.
(sendmail, exim, qmail, ...).  So that MTA might have accepted the mail,
but might itself not be configured to forward the mail.

However, git offers plenty of other config options, such as directly
speaking SMTP to an remote e-mail server, etc.

You can test this setup by setting the '--to' address to your own e-mail
addreess.  If the mails arrive there, chances are high they would also
make it to the list.

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 Saurabh.Sharan at radisys.com  Wed Feb 24 11:15:43 2016
From: Saurabh.Sharan at radisys.com (Saurabh Sharan)
Date: Wed, 24 Feb 2016 11:15:43 +0000
Subject: [PATCH] fix for encoding of padding bits
In-Reply-To: <20160224084512.GO18382@nataraja>
References: <1456225136-14177-1-git-send-email-saurabh.sharan@radisys.com>
 <BY1PR08MB130826D10666F77D40C163CC85A50@BY1PR08MB1308.namprd08.prod.outlook.com>
 <20160224084512.GO18382@nataraja>
Message-ID: <BY1PR08MB13085F440DD0AB9781C8444A85A50@BY1PR08MB1308.namprd08.prod.outlook.com>

Hello All,
Will it be fine for you to review the patch (csn1.cpp 1code line modified with 5 comment lines) sent as part of the earlier mail.
We are working on identifying for any issues in send mail. According to your suggestion I tried git send-email to my personal email which is working fine.

Regards
Saurabh

-----Original Message-----
From: Harald Welte [mailto:laforge at gnumonks.org] 
Sent: Wednesday, February 24, 2016 2:15 PM
To: Saurabh Sharan <Saurabh.Sharan at radisys.com>
Cc: osmocom-net-gprs at lists.osmocom.org
Subject: Re: [PATCH] fix for encoding of padding bits

Hi Saurabh,

On Wed, Feb 24, 2016 at 06:52:58AM +0000, Saurabh Sharan wrote:
> We had tried the option of sending one patch through git send-email. 
> This was our first attempt so wanted to confirm whether we followed 
> the process correctly. Please note that I am unable to see this 
> patch(mail below) in Archive maintained at 
> http://lists.osmocom.org/pipermail/osmocom-net-gprs/

Indeed, the mail did not arrive here.  Please check your git send-email configuration.  By default, like it is customary on Unix/Linux systems, git just hands over the mail to your local sysem-wide MTA installation.
(sendmail, exim, qmail, ...).  So that MTA might have accepted the mail, but might itself not be configured to forward the mail.

However, git offers plenty of other config options, such as directly speaking SMTP to an remote e-mail server, etc.

You can test this setup by setting the '--to' address to your own e-mail addreess.  If the mails arrive there, chances are high they would also make it to the list.

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  Wed Feb 24 12:01:20 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 24 Feb 2016 13:01:20 +0100
Subject: [PATCH] fix for encoding of padding bits
In-Reply-To: <BY1PR08MB130826D10666F77D40C163CC85A50@BY1PR08MB1308.namprd08.prod.outlook.com>
References: <1456225136-14177-1-git-send-email-saurabh.sharan@radisys.com>
 <BY1PR08MB130826D10666F77D40C163CC85A50@BY1PR08MB1308.namprd08.prod.outlook.com>
Message-ID: <20160224120120.GC23371@nataraja>

Hi Saurabh,

On Wed, Feb 24, 2016 at 06:52:58AM +0000, Saurabh Sharan wrote:
> Subject: [PATCH] fix for encoding of padding bits

1) no actual commit log message beyond the subjcet line

So you have a single-line commit message without further description.

This may be acceptable in some cases where it is completly ovious (like
a costmetic fix, or a == / != change, ...).  But at least for the change
you are proposing, it is not obvious to me what the problem was, and
why.

Sure, I see you are shifting it right one bit further.  Probably due to
the misgsing '0' ahead of the filler?  A single sentence explaining that
would be great.


2) encoding bugfix without a test caes

especially with bugs affecting the encoding of messages, it would be
very useful to have a small test case as part of the unit testing suite
of osmo-pcu.  The test should fail with the old behavior, and be fixed
with the new behavior.

By introducing the test case we make sure to avoid future regressions.

The test case should be submitted as a separate patch/commit,
independent of the actual bugfix.


3) cosmetics

> +	      /*section 11 of 44.060
> +               *The padding bits may be the 'null' string. Otherwise, the
> +	       *padding bits starts with bit '0', followed by 'spare padding'.
> +	       *< padding bits > ::= { null | 0 < spare padding > ! < Ignore : 1 bit** = < no string > > } ;   
> +	      */	 
> +              guint8 fl = filler&(0xff>>(8-bits_to_handle + 1));

Several cosmetic issues with this:

* no space between '/*' and start of comment
* whitespace/tab doesn't align right, i.e. different lines have
  different amount of tabs/spaces ending up in misaligned display.
  The file src/csn1.cpp was originally taken from the wireshark project
  and is thus following a completely different coding style.  They don't
  use tabs at all, but use spaces only to indent their lines.  That's
  unlike the other source code files in the osmo-pcu, and we should
  probably convert it - but that's a separate discussion.  In general
  it's best to follow the style of the surrounding code that you're
  editing.  Try 'git log' when the patch is applied an you will see what
  I mean.
* extra white spaces at the end of two lines in the comment, which is
  actually something even git is issuing a warning about when I try to
  apply it:

----
Applying: fix for encoding of padding bits
.git/rebase-apply/patch:16: trailing whitespace.
.git/rebase-apply/patch:17: trailing whitespace.
warning: 2 lines add whitespace errors.
----

Now all of the above might see a bit excessive if after all we want to
make such a minor change.  But I think it's important to get the
procedure/workflow right, particularly with further future patches in
mind.  Thanks for your understanding.

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 msuraev at sysmocom.de  Thu Feb 25 11:03:05 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 25 Feb 2016 12:03:05 +0100
Subject: PCU scheduling and PACCH timeout question
Message-ID: <56CEDF69.9000606@sysmocom.de>

Hello.

I'm trying to debug issue with current OsmoPCU master when some 
basebands ignore polling requests.

The debug output from RLCMAC layer and corresponding .pcap files are 
attached to ticket http://projects.osmocom.org/issues/1524

The issue appears somewhere after line 112 in debug.log
The corresponding packet in pcu.pcapng is 6866

After receiving PACKET_CONTROL_ACK from phone we're trying to schedule 
polling at FN 1137123 (see packet 6869 in pcap) and than at FN 1137127 
(packet 6874) which subsequently fails.
This seems suspiciously close but I have not found in the spec yet if 
this is legitimate thing to do.

There are several other occurrences like that in both log and pcap.

Have you experienced something like this? Do you have an idea why only 
some basebands are affected while others work fine?

-- 
Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte





From msuraev at sysmocom.de  Thu Feb 25 16:28:09 2016
From: msuraev at sysmocom.de (msuraev at sysmocom.de)
Date: Thu, 25 Feb 2016 17:28:09 +0100
Subject: [PATCH] Explicitly initialize m_v_n and m_v_b
Message-ID: <1456417689-16787-1-git-send-email-msuraev@sysmocom.de>

From: Max <msuraev at sysmocom.de>

Call reset() to initialize m_v_b in gprs_rlc_dl_window() and
m_v_n in gprs_rlc_ul_window() constructors. Add constructors to
gprs_rlc_v_b and gprs_rlc_v_n. Not sure about all the intimate details
of constructor calls in c++ so used both.

Fixes: Coverity: CID 1351738, 1351737
---
 src/rlc.h | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/src/rlc.h b/src/rlc.h
index 54f28df..eb527a0 100644
--- a/src/rlc.h
+++ b/src/rlc.h
@@ -143,8 +143,7 @@ struct gprs_rlc_v_b {
 	void mark_invalid(int bsn);
 
 	void reset();
-
-
+	gprs_rlc_v_b();
 private:
 	bool is_state(int bsn, const gprs_rlc_dl_bsn_state state) const;
 	void mark(int bsn, const gprs_rlc_dl_bsn_state state);
@@ -216,6 +215,7 @@ struct gprs_rlc_v_n {
 	bool is_received(int bsn) const;
 
 	gprs_rlc_ul_bsn_state state(int bsn) const;
+	gprs_rlc_v_n();
 private:
 	bool is_state(int bsn, const gprs_rlc_ul_bsn_state state) const;
 	void mark(int bsn, const gprs_rlc_ul_bsn_state state);
@@ -448,6 +448,7 @@ inline gprs_rlc_dl_window::gprs_rlc_dl_window()
 	: m_v_s(0)
 	, m_v_a(0)
 {
+	m_v_b.reset();
 }
 
 inline const uint16_t gprs_rlc_dl_window::v_s() const
@@ -490,10 +491,21 @@ inline const int16_t gprs_rlc_dl_window::distance() const
 	return (m_v_s - m_v_a) & mod_sns();
 }
 
+inline gprs_rlc_v_b::gprs_rlc_v_b()
+{
+	reset();
+}
+
+inline gprs_rlc_v_n::gprs_rlc_v_n()
+{
+	reset();
+}
+
 inline gprs_rlc_ul_window::gprs_rlc_ul_window()
 	: m_v_r(0)
 	, m_v_q(0)
 {
+	m_v_n.reset();
 }
 
 inline bool gprs_rlc_ul_window::is_in_window(uint16_t bsn) const
-- 
2.7.2



From msuraev at sysmocom.de  Thu Feb 25 16:39:15 2016
From: msuraev at sysmocom.de (msuraev at sysmocom.de)
Date: Thu, 25 Feb 2016 17:39:15 +0100
Subject: [PATCH] Expand RLCMAC diagnostics output
Message-ID: <1456418355-20529-1-git-send-email-msuraev@sysmocom.de>

From: Max <msuraev at sysmocom.de>

When smth bad happens (e. g. we hit timeout in RLCMAC) on TBF - obtain
corresponding MS object and print extended information about it and its
TBFs to aid troubleshooting. Diagnostic function should not change state
hence make it const with no return value.
---
 src/bts.cpp |  2 +-
 src/tbf.cpp | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
 src/tbf.h   |  2 +-
 3 files changed, 84 insertions(+), 9 deletions(-)

diff --git a/src/bts.cpp b/src/bts.cpp
index 715fb51..75766f1 100644
--- a/src/bts.cpp
+++ b/src/bts.cpp
@@ -1254,7 +1254,7 @@ int gprs_rlcmac_pdch::rcv_control_block(
 	bitvec *rlc_block, uint32_t fn)
 {
 	RlcMacUplink_t * ul_control_block = (RlcMacUplink_t *)talloc_zero(tall_pcu_ctx, RlcMacUplink_t);
-	LOGP(DRLCMAC, LOGL_DEBUG, "+++++++++++++++++++++++++ RX : Uplink Control Block +++++++++++++++++++++++++\n");
+	LOGP(DRLCMAC, LOGL_DEBUG, "+++++++++++++++++++++++++ RX : Uplink Control Block on FN = %d ++++++++++++++\n", fn);
 	decode_gsm_rlcmac_uplink(rlc_block, ul_control_block);
 	LOGPC(DCSN1, LOGL_NOTICE, "\n");
 	LOGP(DRLCMAC, LOGL_DEBUG, "------------------------- RX : Uplink Control Block -------------------------\n");
diff --git a/src/tbf.cpp b/src/tbf.cpp
index 69b9e3a..5f81e8b 100644
--- a/src/tbf.cpp
+++ b/src/tbf.cpp
@@ -490,7 +490,7 @@ void gprs_rlcmac_tbf::poll_timeout()
 		if (!(state_flags & (1 << GPRS_RLCMAC_FLAG_TO_UL_ACK))) {
 			LOGP(DRLCMAC, LOGL_NOTICE, "- Timeout for polling "
 				"PACKET CONTROL ACK for PACKET UPLINK ACK\n");
-			rlcmac_diag();
+			rlcmac_diag("POLL TIMEOUT for PACKET CONTROL ACK for PACKET UPLINK ACK");
 			state_flags |= (1 << GPRS_RLCMAC_FLAG_TO_UL_ACK);
 		}
 		ul_ack_state = GPRS_RLCMAC_UL_ACK_NONE;
@@ -514,7 +514,7 @@ void gprs_rlcmac_tbf::poll_timeout()
 			LOGP(DRLCMAC, LOGL_NOTICE, "- Timeout for polling "
 				"PACKET CONTROL ACK for PACKET UPLINK "
 				"ASSIGNMENT.\n");
-			rlcmac_diag();
+			rlcmac_diag("POLL TIMEOUT for PACKET CONTROL ACK for PACKET UPLINK ASSIGNMENT");
 			state_flags |= (1 << GPRS_RLCMAC_FLAG_TO_UL_ASS);
 		}
 		ul_ass_state = GPRS_RLCMAC_UL_ASS_NONE;
@@ -534,7 +534,7 @@ void gprs_rlcmac_tbf::poll_timeout()
 			LOGP(DRLCMAC, LOGL_NOTICE, "- Timeout for polling "
 				"PACKET CONTROL ACK for PACKET DOWNLINK "
 				"ASSIGNMENT.\n");
-			rlcmac_diag();
+			rlcmac_diag("POLL TIMEOUT for PACKET CONTROL ACK for PACKET DOWNLINK ASSIGNMENT");
 			state_flags |= (1 << GPRS_RLCMAC_FLAG_TO_DL_ASS);
 		}
 		dl_ass_state = GPRS_RLCMAC_DL_ASS_NONE;
@@ -555,7 +555,7 @@ void gprs_rlcmac_tbf::poll_timeout()
 		if (!(dl_tbf->state_flags & (1 << GPRS_RLCMAC_FLAG_TO_DL_ACK))) {
 			LOGP(DRLCMAC, LOGL_NOTICE, "- Timeout for polling "
 				"PACKET DOWNLINK ACK.\n");
-			dl_tbf->rlcmac_diag();
+			dl_tbf->rlcmac_diag("POLL TIMEOUT for PACKET DOWNLINK ACK");
 			dl_tbf->state_flags |= (1 << GPRS_RLCMAC_FLAG_TO_DL_ACK);
 		}
 		dl_tbf->n3105++;
@@ -872,7 +872,7 @@ void gprs_rlcmac_tbf::handle_timeout()
 	case 3195:
 		LOGP(DRLCMAC, LOGL_NOTICE, "%s T%d timeout during "
 			"transsmission\n", tbf_name(this), T);
-		rlcmac_diag();
+		rlcmac_diag("TRANSMISSION TIMEOUT");
 		/* fall through */
 	case 3193:
 		LOGP(DRLCMAC, LOGL_DEBUG,
@@ -887,8 +887,33 @@ void gprs_rlcmac_tbf::handle_timeout()
 	}
 }
 
-int gprs_rlcmac_tbf::rlcmac_diag()
+static inline void print_tbf_diag(const struct gprs_rlcmac_tbf * t, bool uplink)
 {
+	const char * d = uplink ? "UL" : "DL";
+
+	LOGP(DRLCMAC, LOGL_NOTICE, "- MS %s %s\n", d, t->name());
+	LOGP(DRLCMAC, LOGL_NOTICE, "- MS %s TBF 1st TS = %d, 1st common TS = %d, ctrl TS = %d\n",
+		d, t->first_ts, t->first_common_ts, t->control_ts);
+	LOGP(DRLCMAC, LOGL_NOTICE, "- MS %s TBF TSC = %d, DL: "OSMO_BIT_SPEC", UL: "OSMO_BIT_SPEC", mslot upgradeable: %d\n",
+		d, t->tsc(), OSMO_BIT_PRINT(t->dl_slots()), OSMO_BIT_PRINT(t->ul_slots()), t->upgrade_to_multislot);
+
+	unsigned i;
+	for (i = 0; i < 8; i++)
+		if (t->pdch[i])
+			if (t->pdch[i]->is_enabled())
+				LOGP(DRLCMAC, LOGL_NOTICE, "- MS %s PDCH[%d] USF = %d, last RTS FN = %d, TSC = %d, TS = %d\n",
+					d, i, t->pdch[i]->assigned_usf(), t->pdch[i]->last_rts_fn, t->pdch[i]->tsc, t->pdch[i]->ts_no);
+
+	if (GPRS_RLCMAC_POLL_SCHED == t->poll_state)
+		LOGP(DRLCMAC, LOGL_NOTICE, "- MS %s TBF poll. scheduled: FN = %d, TS = %d\n", d, t->poll_fn, t->poll_ts);
+	else
+		LOGP(DRLCMAC, LOGL_NOTICE, "- MS %s TBF no polling\n", d);
+}
+
+void gprs_rlcmac_tbf::rlcmac_diag(const char * context) const
+{
+	GprsMs * m = ms();
+	LOGP(DRLCMAC, LOGL_NOTICE, "- RLCMAC diag. report for %s:\n", context);
 	if ((state_flags & (1 << GPRS_RLCMAC_FLAG_CCCH)))
 		LOGP(DRLCMAC, LOGL_NOTICE, "- Assignment was on CCCH\n");
 	if ((state_flags & (1 << GPRS_RLCMAC_FLAG_PACCH)))
@@ -902,7 +927,57 @@ int gprs_rlcmac_tbf::rlcmac_diag()
 	else if (direction == GPRS_RLCMAC_DL_TBF)
 		LOGP(DRLCMAC, LOGL_NOTICE, "- No downlink ACK received yet\n");
 
-	return 0;
+	if (is_tfi_assigned())
+		LOGP(DRLCMAC, LOGL_NOTICE, "- TBF's TFI = %d\n", tfi());
+	else
+		LOGP(DRLCMAC, LOGL_NOTICE, "- No TFI is assigned to this TBF yet\n");
+
+	if (is_tlli_valid())
+		LOGP(DRLCMAC, LOGL_NOTICE, "- TBF's TLLI = 0x%x\n", tlli());
+	else
+		LOGP(DRLCMAC, LOGL_NOTICE, "- No TLLI is assigned to this TBF yet\n");
+
+	LOGP(DRLCMAC, LOGL_NOTICE, "- MS IMSI = %s, GPRS class = %d, EGPRS class = %d, TA = %d, TLLI = 0x%x\n",
+		m->imsi(), m->ms_class(), m->egprs_ms_class(), m->ta(), m->tlli());
+	LOGP(DRLCMAC, LOGL_NOTICE, "- MS 1st common TS = %d, current PACCH = %d\n",
+		m->first_common_ts(), m->current_pacch_slots());
+	LOGP(DRLCMAC, LOGL_NOTICE, "- MS DL: "OSMO_BIT_SPEC" (RSRVD: "OSMO_BIT_SPEC"), UL: "OSMO_BIT_SPEC" (RSRVD: "OSMO_BIT_SPEC")\n",
+		OSMO_BIT_PRINT(m->dl_slots()), OSMO_BIT_PRINT(m->reserved_dl_slots()), OSMO_BIT_PRINT(m->ul_slots()), OSMO_BIT_PRINT(m->reserved_ul_slots()));
+
+	if (m->is_idle())
+		LOGP(DRLCMAC, LOGL_NOTICE, "- MS id idle\n");
+	if (m->need_dl_tbf())
+		LOGP(DRLCMAC, LOGL_NOTICE, "- MS needs DL TBF\n");
+
+	if (m->dl_tbf()) {
+		struct gprs_rlcmac_dl_tbf * dl = m->dl_tbf();
+		print_tbf_diag(dl, false);
+
+		if (m->dl_tbf()->need_control_ts())
+			LOGP(DRLCMAC, LOGL_NOTICE, "- MS DL TBF needs ctrl TS\n");
+
+		if (m->dl_tbf()->have_data())
+			LOGP(DRLCMAC, LOGL_NOTICE, "- MS DL TBF have data\n");
+	} else
+		LOGP(DRLCMAC, LOGL_NOTICE, "- MS have no DL TBF\n");
+
+	if (m->ul_tbf()) {
+		struct gprs_rlcmac_ul_tbf * ul = m->ul_tbf();
+		print_tbf_diag(ul, true);
+
+		LOGP(DRLCMAC, LOGL_NOTICE, "- MS UL TBF USF: %d %d %d %d %d %d %d %d\n",
+			m->ul_tbf()->m_usf[0],
+			m->ul_tbf()->m_usf[1],
+			m->ul_tbf()->m_usf[2],
+			m->ul_tbf()->m_usf[3],
+			m->ul_tbf()->m_usf[4],
+			m->ul_tbf()->m_usf[5],
+			m->ul_tbf()->m_usf[6],
+			m->ul_tbf()->m_usf[7]);
+	} else
+		LOGP(DRLCMAC, LOGL_NOTICE, "- MS have no UL TBF\n");
+
+	LOGP(DRLCMAC, LOGL_NOTICE, "- RLCMAC diag. report complete\n\n");
 }
 
 struct msgb *gprs_rlcmac_tbf::create_dl_ass(uint32_t fn, uint8_t ts)
diff --git a/src/tbf.h b/src/tbf.h
index ad8ad4c..b556e0c 100644
--- a/src/tbf.h
+++ b/src/tbf.h
@@ -112,7 +112,7 @@ struct gprs_rlcmac_tbf {
 
 	uint8_t tsc() const;
 
-	int rlcmac_diag();
+	void rlcmac_diag(const char * context) const;
 
 	int update();
 	void handle_timeout();
-- 
2.7.2



From holger at freyther.de  Thu Feb 25 16:58:08 2016
From: holger at freyther.de (Holger Freyther)
Date: Thu, 25 Feb 2016 17:58:08 +0100
Subject: [PATCH] Explicitly initialize m_v_n and m_v_b
In-Reply-To: <1456417689-16787-1-git-send-email-msuraev@sysmocom.de>
References: <1456417689-16787-1-git-send-email-msuraev@sysmocom.de>
Message-ID: <E63B1D71-EDD3-4852-BE9A-594C07FF4777@freyther.de>


> On 25 Feb 2016, at 17:28, msuraev at sysmocom.de wrote:
> 
> 
> +inline gprs_rlc_v_b::gprs_rlc_v_b()
> +{
> +	reset();
> +}
> +
> +inline gprs_rlc_v_n::gprs_rlc_v_n()
> +{
> +	reset();
> +}
> +
> inline gprs_rlc_ul_window::gprs_rlc_ul_window()
> 	: m_v_r(0)
> 	, m_v_q(0)
> {
> +	m_v_n.reset();

why this? You have just added a ctor of the _v_n::.._v_n()?






From msuraev at sysmocom.de  Thu Feb 25 17:21:36 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 25 Feb 2016 18:21:36 +0100
Subject: [PATCH] Explicitly initialize m_v_n and m_v_b
In-Reply-To: <E63B1D71-EDD3-4852-BE9A-594C07FF4777@freyther.de>
References: <1456417689-16787-1-git-send-email-msuraev@sysmocom.de>
 <E63B1D71-EDD3-4852-BE9A-594C07FF4777@freyther.de>
Message-ID: <56CF3820.10408@sysmocom.de>

I'm not familiar enough with c++ to claim that the constructor will 
always be called so I've left it just in case.

On 02/25/2016 05:58 PM, Holger Freyther wrote:
>> On 25 Feb 2016, at 17:28, msuraev at sysmocom.de wrote:
>>
>>
>> +inline gprs_rlc_v_b::gprs_rlc_v_b()
>> +{
>> +	reset();
>> +}
>> +
>> +inline gprs_rlc_v_n::gprs_rlc_v_n()
>> +{
>> +	reset();
>> +}
>> +
>> inline gprs_rlc_ul_window::gprs_rlc_ul_window()
>> 	: m_v_r(0)
>> 	, m_v_q(0)
>> {
>> +	m_v_n.reset();
> why this? You have just added a ctor of the _v_n::.._v_n()?
>
>
>
>

-- 
Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte



From holger at freyther.de  Thu Feb 25 17:29:43 2016
From: holger at freyther.de (Holger Freyther)
Date: Thu, 25 Feb 2016 18:29:43 +0100
Subject: [PATCH] Explicitly initialize m_v_n and m_v_b
In-Reply-To: <56CF3820.10408@sysmocom.de>
References: <1456417689-16787-1-git-send-email-msuraev@sysmocom.de>
 <E63B1D71-EDD3-4852-BE9A-594C07FF4777@freyther.de>
 <56CF3820.10408@sysmocom.de>
Message-ID: <C228A17D-4F86-4B68-91B3-D302F8EC5D47@freyther.de>


> On 25 Feb 2016, at 18:21, Max <msuraev at sysmocom.de> wrote:
> 
> I'm not familiar enough with c++ to claim that the constructor will always be called so I've left it just in case.

Then write yourself an example? e.g. something like this?

#include <iostream>

struct internalmember {
	internalmember()
		: m_v(-1)
	{
		std::cout << "internalmember called" << std::endl;
	}

	int m_v;
};


struct outerstruct {
	outerstruct()
	{
		std::cout << "outerstruct called" << std::endl;
	}
}

int main(int argc, char **argv)
{
	outerstruct str;
	return 0;
}




From holger at freyther.de  Thu Feb 25 21:55:39 2016
From: holger at freyther.de (Holger Freyther)
Date: Thu, 25 Feb 2016 22:55:39 +0100
Subject: [PATCH] Refactor coding scheme assignment code
In-Reply-To: <1456315053-16934-1-git-send-email-msuraev@sysmocom.de>
References: <1456315053-16934-1-git-send-email-msuraev@sysmocom.de>
Message-ID: <B8FE7044-26D0-4A5C-9AA3-C39A4CE13696@freyther.de>


> On 24 Feb 2016, at 12:57, msuraev at sysmocom.de wrote:

Moving it to the BTS list. After we had some performance issues today (and just pointing out the need for a stable test setup and some repeated measurements). I looked at the code more carefully and have some more comments we should 



> 
> +inline static GprsCodingScheme assign_cs(GprsCodingScheme current, BTS *bts, bool uplink, GprsCodingScheme::Mode mode)
> +{

"assign" is a misleading name. It doesn't have a side-effect so it should be called pick_cs (or such). Please make "current" const as well.



> +	GprsCodingScheme tmp = GprsCodingScheme::UNKNOWN;
> +	struct gprs_rlcmac_bts * b = bts->bts_data();
> +
> +	if (GprsCodingScheme::GPRS == mode) {
> +		if (!current.isGprs()) {
> +			tmp = GprsCodingScheme::getGprsByNum(uplink ? b->initial_cs_ul : b->initial_cs_dl);
> +			if (!tmp.isValid())
> +				return GprsCodingScheme::CS1;
> +		}
> +	} else {
> +		if (!current.isEgprs()) {
> +			tmp = GprsCodingScheme::getEgprsByNum(uplink ? b->initial_mcs_ul : b->initial_mcs_dl);
> +			if (!tmp.isValid())
> +				return GprsCodingScheme::MCS1;
> +		}
> +	}
> +
> +    return tmp;
> +}
> +
> void GprsMs::set_mode(GprsCodingScheme::Mode mode)
> {
> +	GprsCodingScheme tmp;
> 	m_mode = mode;
> 
> 	if (!m_bts)
> 		return;
> 
> -	switch (m_mode) {
> -	case GprsCodingScheme::GPRS:
> -		if (!m_current_cs_ul.isGprs()) {
> -			m_current_cs_ul = GprsCodingScheme::getGprsByNum(
> -				m_bts->bts_data()->initial_cs_ul);
> -			if (!m_current_cs_ul.isValid())
> -				m_current_cs_ul = GprsCodingScheme::CS1;
> -		}
> -		if (!m_current_cs_dl.isGprs()) {
> -			m_current_cs_dl = GprsCodingScheme::getGprsByNum(
> -				m_bts->bts_data()->initial_cs_dl);
> -			if (!m_current_cs_dl.isValid())
> -				m_current_cs_dl = GprsCodingScheme::CS1;
> -		}
> -		break;
> -
> -	case GprsCodingScheme::EGPRS_GMSK:
> -	case GprsCodingScheme::EGPRS:
> -		if (!m_current_cs_ul.isEgprs()) {
> -			m_current_cs_ul = GprsCodingScheme::getEgprsByNum(
> -				m_bts->bts_data()->initial_mcs_ul);
> -			if (!m_current_cs_dl.isValid())
> -				m_current_cs_ul = GprsCodingScheme::MCS1;
> -		}
> -		if (!m_current_cs_dl.isEgprs()) {
> -			m_current_cs_dl = GprsCodingScheme::getEgprsByNum(
> -				m_bts->bts_data()->initial_mcs_dl);
> -			if (!m_current_cs_dl.isValid())
> -				m_current_cs_dl = GprsCodingScheme::MCS1;
> -		}
> -		break;
> -	}
> +	tmp = assign_cs(m_current_cs_ul, m_bts, true, mode);
> +	if (tmp)
> +		m_current_cs_ul = tmp;
> +
> +	tmp = assign_cs(m_current_cs_dl, m_bts, false, mode);
> +	if (tmp)
> +		m_current_cs_dl = tmp;


let us change the code-flow here. There is a subtle difference between operator bool() and isValid but we avoid that by:

a.) By passing m_current_cs_ul/m_current_cs_dl as pointer and really assign
b.) By making sure pick_cs always returns a valid result?



diff --git a/src/gprs_ms.cpp b/src/gprs_ms.cpp
index 78f03f8..98c4fda 100644
--- a/src/gprs_ms.cpp
+++ b/src/gprs_ms.cpp
@@ -209,6 +209,25 @@ void GprsMs::stop_timer()
 	unref();
 }
 
+static inline void assign_cs(GprsCodingScheme *current, BTS *bts, bool uplink, GprsCodingScheme::Mode mode)
+{
+	struct gprs_rlcmac_bts * b = bts->bts_data();
+
+	if (GprsCodingScheme::GPRS == mode) {
+		if (current->isGprs())
+			return;
+		*current = GprsCodingScheme::getGprsByNum(uplink ? b->initial_cs_ul : b->initial_cs_dl);
+		if (!current->isValid())
+			*current = GprsCodingScheme::CS1;
+	} else {
+		if (current->isEgprs())
+			return;
+		*current = GprsCodingScheme::getEgprsByNum(uplink ? b->initial_mcs_ul : b->initial_mcs_dl);
+		if (!current->isValid())
+			*current = GprsCodingScheme::MCS1;
+	}
+}
+
 void GprsMs::set_mode(GprsCodingScheme::Mode mode)
 {
 	m_mode = mode;
@@ -216,38 +235,11 @@ void GprsMs::set_mode(GprsCodingScheme::Mode mode)
 	if (!m_bts)
 		return;
 
-	switch (m_mode) {
-	case GprsCodingScheme::GPRS:
-		if (!m_current_cs_ul.isGprs()) {
-			m_current_cs_ul = GprsCodingScheme::getGprsByNum(
-				m_bts->bts_data()->initial_cs_ul);
-			if (!m_current_cs_ul.isValid())
-				m_current_cs_ul = GprsCodingScheme::CS1;
-		}
-		if (!m_current_cs_dl.isGprs()) {
-			m_current_cs_dl = GprsCodingScheme::getGprsByNum(
-				m_bts->bts_data()->initial_cs_dl);
-			if (!m_current_cs_dl.isValid())
-				m_current_cs_dl = GprsCodingScheme::CS1;
-		}
-		break;
-
-	case GprsCodingScheme::EGPRS_GMSK:
-	case GprsCodingScheme::EGPRS:
-		if (!m_current_cs_ul.isEgprs()) {
-			m_current_cs_ul = GprsCodingScheme::getEgprsByNum(
-				m_bts->bts_data()->initial_mcs_ul);
-			if (!m_current_cs_dl.isValid())
-				m_current_cs_ul = GprsCodingScheme::MCS1;
-		}
-		if (!m_current_cs_dl.isEgprs()) {
-			m_current_cs_dl = GprsCodingScheme::getEgprsByNum(
-				m_bts->bts_data()->initial_mcs_dl);
-			if (!m_current_cs_dl.isValid())
-				m_current_cs_dl = GprsCodingScheme::MCS1;
-		}
-		break;
-	}
+	assign_cs(&m_current_cs_ul, m_bts, true, mode);
+	assign_cs(&m_current_cs_dl, m_bts, false, mode);
+
+	LOGP(DRLCMAC, LOGL_DEBUG, "MS IMSI=%s mode set to %s: UL=%s, DL=%s\n",
+		imsi(), tmp.modeName(mode), m_current_cs_ul.name(), m_current_cs_dl.name());
 }
 
 void GprsMs::attach_tbf(struct gprs_rlcmac_tbf *tbf)



From Prasad.Kaup at radisys.com  Fri Feb 26 13:17:13 2016
From: Prasad.Kaup at radisys.com (Prasad Kaup)
Date: Fri, 26 Feb 2016 13:17:13 +0000
Subject: Support of 11 bit RACH support  in osmoPCU
Message-ID: <BN3PR08MB1237E1067ADB9CA2A1D1552BE6A70@BN3PR08MB1237.namprd08.prod.outlook.com>

Hello All,
We are currently working on providing the support of 11 bit RACH support  in osmoPCU  as mentioned in Bug #1548  at https://projects.osmocom.org/projects/osmopcu/issues

We have identified  impacts to be in  osmo-pcu, osmo-bts and osmocore

Main changes identified are
osmo-pcu:

*         In  file pcuif_proto.h,   modify "uint8_t ra" to "uint16_t ra"   in  struct  gsm_pcu_if_rach_ind

*         Corresponding function prototypes due to change in data type

*         11 bit RACH handling in bts.cpp

*         Changes in encoding.cpp to support  immediate assignment  with EGPRS allocation

osmocore:

*         In file l1sap.h,   modify "uint8_t ra" to "uint16_t ra"  in   structure "struct ph_rach_ind_param"

*         Function prototype changes


osmobts:

*         Function prototype changes due to change in data type

Please let us know your valuable feedback.
We plan to  have a separate branch from master for this development. Please let us know the procedure to do this.

Regards
Prasad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160226/92577022/attachment.htm>

From Prasad.Kaup at radisys.com  Fri Feb 26 13:03:17 2016
From: Prasad.Kaup at radisys.com (Prasad Kaup)
Date: Fri, 26 Feb 2016 13:03:17 +0000
Subject: Support of 11 bit RACH support  in osmoPCU
Message-ID: <BN3PR08MB1237DCB97E760EEDE411A1DEE6A70@BN3PR08MB1237.namprd08.prod.outlook.com>

Hello All,
We are currently working on providing the support of 11 bit RACH support  in osmoPCU  as mentioned in Bug #1548  at https://projects.osmocom.org/projects/osmopcu/issues

We have identified  impacts to be in  osmo-pcu, osmo-bts and osmocore

Main changes identified are
osmo-pcu:

*         In  file pcuif_proto.h,   modify "uint8_t ra" to "uint16_t ra"   in  struct  gsm_pcu_if_rach_ind

*         Corresponding function prototypes due to change in data type

*         11 bit RACH handling in bts.cpp

*         Changes in encoding.cpp to support  immediate assignment  with EGPRS allocation

osmocore:

*         In file l1sap.h,   modify "uint8_t ra" to "uint16_t ra"  in   structure "struct ph_rach_ind_param"

*         Function prototype changes


osmobts:

*         Function prototype changes due to change in data type

Please let us know your valuable feedback.
We plan to  have a separate branch from master for this development. Please let us know the procedure to do this.

Regards
Prasad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160226/e8f1a89e/attachment.htm>

From Prasad.Kaup at radisys.com  Fri Feb 26 12:46:46 2016
From: Prasad.Kaup at radisys.com (Prasad Kaup)
Date: Fri, 26 Feb 2016 12:46:46 +0000
Subject: Support of 11 bit RACH support  in osmoPCU 
Message-ID: <BN3PR08MB12376E3DB78EBF28B50F23C2E6A70@BN3PR08MB1237.namprd08.prod.outlook.com>

Hello All,
We are currently working on providing the support of 11 bit RACH support  in osmoPCU  as mentioned in Bug #1548  at https://projects.osmocom.org/projects/osmopcu/issues

We have identified  impacts to be in  osmo-pcu, osmo-bts and osmocore

Main changes identified are
osmo-pcu:

*         In  file pcuif_proto.h,   modify "uint8_t ra" to "uint16_t ra"   in  struct  gsm_pcu_if_rach_ind

*         Corresponding function prototypes due to change in data type

*         11 bit RACH handling in bts.cpp

*         Changes in encoding.cpp to support  immediate assignment  with EGPRS allocation

osmocore:

*         In file l1sap.h,   modify "uint8_t ra" to "uint16_t ra"  in   structure "struct ph_rach_ind_param"

*         Function prototype changes


osmobts:

*         Function prototype changes due to change in data type

Please let us know your valuable feedback.
We plan to  have a separate branch from master for this development. Please let us know the procedure to do this.


Regards
Prasad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160226/e85daaef/attachment.htm>

From holger at freyther.de  Fri Feb 26 13:53:47 2016
From: holger at freyther.de (Holger Freyther)
Date: Fri, 26 Feb 2016 14:53:47 +0100
Subject: Support of 11 bit RACH support  in osmoPCU
In-Reply-To: <BN3PR08MB1237E1067ADB9CA2A1D1552BE6A70@BN3PR08MB1237.namprd08.prod.outlook.com>
References: <BN3PR08MB1237E1067ADB9CA2A1D1552BE6A70@BN3PR08MB1237.namprd08.prod.outlook.com>
Message-ID: <25114B7A-A92F-46CE-BE53-DE719B8A1BEA@freyther.de>


> On 26 Feb 2016, at 14:17, Prasad Kaup <Prasad.Kaup at radisys.com> wrote:
> 
> Hello All,

Hi!


> We are currently working on providing the support of 11 bit RACH support  in osmoPCU  as mentioned in Bug #1548  athttps://projects.osmocom.org/projects/osmopcu/issues

great news!

>  
> We have identified  impacts to be in  osmo-pcu, osmo-bts and osmocore
>  
> Main changes identified are
> osmo-pcu:
> ?         In  file pcuif_proto.h,   modify ?uint8_t ra? to ?uint16_t ra?   in  struct  gsm_pcu_if_rach_ind
> ?         Corresponding function prototypes due to change in data type
> ?         11 bit RACH handling in bts.cpp
> ?         Changes in encoding.cpp to support  immediate assignment  with EGPRS allocation

* increase the version number of the protocol at the same time
* Add counters (if applicable) how often this extended method has been used
* Add unit tests (e.g. regression test for the encoding)
* If possible benchmark in a stable setting to see before/after changes


>  
> osmocore:
> ?         In file l1sap.h,   modify ?uint8_t ra? to ?uint16_t ra?  in   structure ?struct ph_rach_ind_param?
> ?         Function prototype changes

* This is changing the ABI of the structures, please look at the TODO-RELEASE file and previous comments. This reminds us that we need to increment the shared library version on the next release



> osmobts:
> ?         Function prototype changes due to change in data type

* Does osmo-trx support it? Does the sysmoBTS dsp code support it? What is needed for this functionality to be used? Does it make sense to report how many bits of the RACH were used (can we differentiate that?)

>  
> Please let us know your valuable feedback.
> We plan to  have a separate branch from master for this development. Please let us know the procedure to do this.

Yes, please work in branches and split the commits into small pieces that are each easy to review.


kind regards
	holger



From Saurabh.Sharan at radisys.com  Fri Feb 26 15:13:46 2016
From: Saurabh.Sharan at radisys.com (Saurabh Sharan)
Date: Fri, 26 Feb 2016 15:13:46 +0000
Subject: PCU scheduling and PACCH timeout question
In-Reply-To: <56CED717.9060409@sysmocom.de>
References: <56CED717.9060409@sysmocom.de>
Message-ID: <BY1PR08MB13085AC9043E6F6F846AAA9185A70@BY1PR08MB1308.namprd08.prod.outlook.com>

Hello Max,
Though I have not analyzed the missing UL poll response, few of my observations from the pcap file attached is mentioned below
1.      There seems to be difference in FN UL versus DL being processed at any given time by the order of approx. 10 FNs, example given below
a.      Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393
b.      Packet 7190,  FN 1137361 in UL @ 15:33:22.559427972
c.      From above example difference in time is 48milliseconds or approx.. 10FN duration
2.      For processing DL timeslots 2 to 6 at any given DL FN time taken seems to be approx. 3milliseconds, example given below
a.      Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393 for TS 2
b.      Packet 7178, FN 1137361 in DL @ 15:33:22.514310379 for TS 6

Please let me know if these are known behavior in your integration environment ?
These time variations may have an impact on the poll response behavior from MS as well.

Regards
Saurabh

-----Original Message-----
From: Max [mailto:msuraev at sysmocom.de]
Sent: Thursday, February 25, 2016 3:58 PM
To: osmocom-net-gprs at lists.osmocom.org; Saurabh Sharan <Saurabh.Sharan at radisys.com>
Subject: PCU scheduling and PACCH timeout question

Hello.

I'm trying to debug issue with current OsmoPCU master when some basebands ignore polling requests.

The debug output from RLCMAC layer and corresponding .pcap files are attached.
The issue appears somewhere after line 112 in debug.log The corresponding packet in pcu.pcapng is 6866

After receiving PACKET_CONTROL_ACK from phone we're trying to schedule polling at FN 1137123 (see packet 6869 in pcap) and than at FN 1137127 (packet 6874) which subsequently fails.
This seems suspiciously close but I have not found in the spec yet if this is legitimate thing to do.

There are several other occurrences like that in both log and pcap.

Have you experienced something like this? Do you have an idea why only some basebands are affected while others work fine?

--
Max Suraev <msuraev at sysmocom.de<mailto:msuraev at sysmocom.de>> http://www.sysmocom.de/ =======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160226/9cd8c514/attachment.htm>

From jacob01 at gmx.net  Fri Feb 26 15:31:51 2016
From: jacob01 at gmx.net (Jacob Erlbeck)
Date: Fri, 26 Feb 2016 16:31:51 +0100
Subject: Support of 11 bit RACH support in osmoPCU
In-Reply-To: <BN3PR08MB12376E3DB78EBF28B50F23C2E6A70@BN3PR08MB1237.namprd08.prod.outlook.com>
References: <BN3PR08MB12376E3DB78EBF28B50F23C2E6A70@BN3PR08MB1237.namprd08.prod.outlook.com>
Message-ID: <56D06FE7.6010209@gmx.net>

Hello Prasad

On 26.02.2016 13:46, Prasad Kaup wrote:

> We are currently working on providing the support of 11 bit RACH support
>  in osmoPCU  as mentioned in Bug #1548  at
> https://projects.osmocom.org/projects/osmopcu/issues
> 
> We have identified  impacts to be in  osmo-pcu, osmo-bts and osmocore
> 
> Main changes identified are
> 
> *osmo-pcu:*
> 
> ?         In  file pcuif_proto.h,   modify ?/uint8_t ra/? to ?/uint16_t
> ra/?   in  /struct  gsm_pcu_if_rach_ind/

Are you also planning to add the TSC being used which would be needed
for EGPRS as well?

Regards

Jacob


From msuraev at sysmocom.de  Fri Feb 26 17:07:07 2016
From: msuraev at sysmocom.de (Max)
Date: Fri, 26 Feb 2016 18:07:07 +0100
Subject: PCU scheduling and PACCH timeout question
In-Reply-To: <BY1PR08MB13085AC9043E6F6F846AAA9185A70@BY1PR08MB1308.namprd08.prod.outlook.com>
References: <56CED717.9060409@sysmocom.de>
 <BY1PR08MB13085AC9043E6F6F846AAA9185A70@BY1PR08MB1308.namprd08.prod.outlook.com>
Message-ID: <56D0863B.1000401@sysmocom.de>

I'm not sure what to make of this timing difference. I'm using sysmoBTS 
hw to test different osmoPCU versions (including ssharan/egprs) and I 
can see pacch timeouts on all of those I've tried. For some phones it 
really breaks connectivity, others seems to be able to ignore it 
somehow. I do not see a pattern yet.

Do you have some test setup where you try it and see if it's the same 
for you?

On 02/26/2016 04:13 PM, Saurabh Sharan wrote:
> Hello Max,
> Though I have not analyzed the missing UL poll response, few of my 
> observations from the pcap file attached is mentioned below
>
>  1. There seems to be difference in FN UL versus DL being processed at
>     any given time by the order of approx. 10 FNs, example given below
>
>  1. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393
>  2. Packet 7190,  FN 1137361 in UL @ 15:33:22.559427972
>  3. From above example difference in time is 48milliseconds or
>     approx.. 10FN duration
>
>  2. For processing DL timeslots 2 to 6 at any given DL FN time taken
>     seems to be approx. 3milliseconds, example given below
>
>  4. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393 for TS 2
>  5. Packet 7178, FN 1137361 in DL @ 15:33:22.514310379 for TS 6
>
> Please let me know if these are known behavior in your integration 
> environment ?
> These time variations may have an impact on the poll response behavior 
> from MS as well.
> Regards
> Saurabh
> -----Original Message-----
> From: Max [mailto:msuraev at sysmocom.de]
> Sent: Thursday, February 25, 2016 3:58 PM
> To: osmocom-net-gprs at lists.osmocom.org; Saurabh Sharan 
> <Saurabh.Sharan at radisys.com>
> Subject: PCU scheduling and PACCH timeout question
> Hello.
> I'm trying to debug issue with current OsmoPCU master when some 
> basebands ignore polling requests.
> The debug output from RLCMAC layer and corresponding .pcap files are 
> attached.
> The issue appears somewhere after line 112 in debug.log The 
> corresponding packet in pcu.pcapng is 6866
> After receiving PACKET_CONTROL_ACK from phone we're trying to schedule 
> polling at FN 1137123 (see packet 6869 in pcap) and than at FN 1137127 
> (packet 6874) which subsequently fails.
> This seems suspiciously close but I have not found in the spec yet if 
> this is legitimate thing to do.
> There are several other occurrences like that in both log and pcap.
> Have you experienced something like this? Do you have an idea why only 
> some basebands are affected while others work fine?
> --
> Max Suraev <msuraev at sysmocom.de <mailto:msuraev at sysmocom.de>> 
> http://www.sysmocom.de/ 
> =======================================================================
> * sysmocom - systems for mobile communications GmbH
> * Alt-Moabit 93
> * 10559 Berlin, Germany
> * Sitz / Registered office: Berlin, HRB 134158 B
> * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

-- 
Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160226/53498e1a/attachment.htm>

From holger at freyther.de  Fri Feb 26 20:40:14 2016
From: holger at freyther.de (Holger Freyther)
Date: Fri, 26 Feb 2016 21:40:14 +0100
Subject: PCU scheduling and PACCH timeout question
In-Reply-To: <BY1PR08MB13085AC9043E6F6F846AAA9185A70@BY1PR08MB1308.namprd08.prod.outlook.com>
References: <56CED717.9060409@sysmocom.de>
 <BY1PR08MB13085AC9043E6F6F846AAA9185A70@BY1PR08MB1308.namprd08.prod.outlook.com>
Message-ID: <7DFB76C0-2D80-45AF-908B-3BF01585DF72@freyther.de>


> On 26 Feb 2016, at 16:13, Saurabh Sharan <Saurabh.Sharan at radisys.com> wrote:
> 
> Hello Max,

Dear Saurabh,


> Though I have not analyzed the missing UL poll response, few of my observations from the pcap file attached is mentioned below
> 	? There seems to be difference in FN UL versus DL being processed at any given time by the order of approx. 10 FNs, example given below
> 	? Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393
> 	? Packet 7190,  FN 1137361 in UL @ 15:33:22.559427972
> 	? From above example difference in time is 48milliseconds or approx.. 10FN duration
> 	? For processing DL timeslots 2 to 6 at any given DL FN time taken seems to be approx. 3milliseconds, example given below
> 	? Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393 for TS 2
> 	? Packet 7178, FN 1137361 in DL @ 15:33:22.514310379 for TS 6
>  
> Please let me know if these are known behavior in your integration environment ? 
> These time variations may have an impact on the poll response behavior from MS as well.

In general the timing is to be expected. Our processing chain is that the DSP will request a frame by sending a "RTS.IND" and it will start to queue some frames before the next one. So we need to generate the frame some time before the first burst is being sent. While for received data frames we get the decoded frame after the last burst has been processed.

Do you have an independent receiver that can receive GSMK/8PSK and send the output to GSMTAP. It would be very helpful to see if we actually sent the data at the right frame number on the right timeslot. What is your setup to verify such a setup?

kind regards and have a nice weekend

	holger

From Saurabh.Sharan at radisys.com  Fri Feb 26 20:23:15 2016
From: Saurabh.Sharan at radisys.com (Saurabh Sharan)
Date: Fri, 26 Feb 2016 20:23:15 +0000
Subject: PCU scheduling and PACCH timeout question
In-Reply-To: <56D0863B.1000401@sysmocom.de>
References: <56CED717.9060409@sysmocom.de>
 <BY1PR08MB13085AC9043E6F6F846AAA9185A70@BY1PR08MB1308.namprd08.prod.outlook.com>
 <56D0863B.1000401@sysmocom.de>
Message-ID: <BY1PR08MB1308A7DA171754683E5937F285A70@BY1PR08MB1308.namprd08.prod.outlook.com>

Hello Max,
Please find below chart that indicate time skew is happening in the setup.
I have also attached the excel sheet used for this analysis here for reference.
TS4 in downlink is considered for drawing the plot. Please note that block duration value of 18 and 23 milliseconds are acceptable as transmission FNs increment by pattern of 4,4,5,4,4,5,..and so on.
4FN duration is 18.4ms and 5 FN is 23 ms approx.
But the spikes in the system as high as 26.8ms may result in incorrect air interface behavior from L1.


[cid:image002.png at 01D17101.8DA5BBD0]

Regards
Saurabh
From: Max [mailto:msuraev at sysmocom.de]
Sent: Friday, February 26, 2016 10:37 PM
To: Saurabh Sharan <Saurabh.Sharan at radisys.com>; osmocom-net-gprs at lists.osmocom.org
Subject: Re: PCU scheduling and PACCH timeout question

I'm not sure what to make of this timing difference. I'm using sysmoBTS hw to test different osmoPCU versions (including ssharan/egprs) and I can see pacch timeouts on all of those I've tried. For some phones it really breaks connectivity, others seems to be able to ignore it somehow. I do not see a pattern yet.

Do you have some test setup where you try it and see if it's the same for you?
On 02/26/2016 04:13 PM, Saurabh Sharan wrote:
Hello Max,
Though I have not analyzed the missing UL poll response, few of my observations from the pcap file attached is mentioned below
1.       There seems to be difference in FN UL versus DL being processed at any given time by the order of approx. 10 FNs, example given below
a.       Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393
b.      Packet 7190,  FN 1137361 in UL @ 15:33:22.559427972
c.       From above example difference in time is 48milliseconds or approx.. 10FN duration
2.       For processing DL timeslots 2 to 6 at any given DL FN time taken seems to be approx. 3milliseconds, example given below
d.      Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393 for TS 2
e.      Packet 7178, FN 1137361 in DL @ 15:33:22.514310379 for TS 6

Please let me know if these are known behavior in your integration environment ?
These time variations may have an impact on the poll response behavior from MS as well.

Regards
Saurabh

-----Original Message-----
From: Max [mailto:msuraev at sysmocom.de]
Sent: Thursday, February 25, 2016 3:58 PM
To: osmocom-net-gprs at lists.osmocom.org<mailto:osmocom-net-gprs at lists.osmocom.org>; Saurabh Sharan <Saurabh.Sharan at radisys.com><mailto:Saurabh.Sharan at radisys.com>
Subject: PCU scheduling and PACCH timeout question

Hello.

I'm trying to debug issue with current OsmoPCU master when some basebands ignore polling requests.

The debug output from RLCMAC layer and corresponding .pcap files are attached.
The issue appears somewhere after line 112 in debug.log The corresponding packet in pcu.pcapng is 6866

After receiving PACKET_CONTROL_ACK from phone we're trying to schedule polling at FN 1137123 (see packet 6869 in pcap) and than at FN 1137127 (packet 6874) which subsequently fails.
This seems suspiciously close but I have not found in the spec yet if this is legitimate thing to do.

There are several other occurrences like that in both log and pcap.

Have you experienced something like this? Do you have an idea why only some basebands are affected while others work fine?

--
Max Suraev <msuraev at sysmocom.de<mailto:msuraev at sysmocom.de>> http://www.sysmocom.de/ =======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte





--

Max Suraev <msuraev at sysmocom.de><mailto:msuraev at sysmocom.de> http://www.sysmocom.de/

=======================================================================

* sysmocom - systems for mobile communications GmbH

* Alt-Moabit 93

* 10559 Berlin, Germany

* Sitz / Registered office: Berlin, HRB 134158 B

* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160226/5706a127/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 24827 bytes
Desc: image002.png
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160226/5706a127/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dlTS4.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 761646 bytes
Desc: dlTS4.xlsx
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160226/5706a127/attachment.bin>

From terjeks at stud.ntnu.no  Mon Feb 29 11:46:30 2016
From: terjeks at stud.ntnu.no (Terje Kristoffer Hybbestad Skow)
Date: Mon, 29 Feb 2016 12:46:30 +0100
Subject: OpenGGSN
Message-ID: <CAK6q=ucoWvw6hj_GVWMwrA7NjEhaLRZDDtuj4OepoQme_JHjaw@mail.gmail.com>

Hi

Does this mailinglist also regard openGGSN?
If so do I have some questions. I have problem setting it up correctly.
Does anyone have a configuration file for both ggsn and sgsnemu that works?
Which flags are necessary to use and what should they be set to? I
understand it can differ based on IP addresses and similar, but can someone
please help? I'm using this program for my master thesis.


Regards
Terje Kristoffer H. Skow
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160229/edfb6831/attachment.htm>

From holger at freyther.de  Mon Feb 29 17:44:43 2016
From: holger at freyther.de (Holger Freyther)
Date: Mon, 29 Feb 2016 18:44:43 +0100
Subject: Fwd: New Defects reported by Coverity Scan for Osmocom
References: <56d4763a256cf_179cabd330944cb@ss1435.mail>
Message-ID: <FD3C8BD2-C24D-4BF8-B7B8-0663326EEC83@freyther.de>

Hi guys,

FYI after adding the do{} while and the log_check_level call coverity has found some dead code. The found_partial is a funny case of dead code. :)

holger



> Begin forwarded message:
> 
> From: scan-admin at coverity.com
> Subject: New Defects reported by Coverity Scan for Osmocom
> Date: 29 February 2016 at 17:47:54 GMT+1
> To: holger at freyther.de
> 
> 
> Hi,
> 
> Please find the latest report on new defect(s) introduced to Osmocom found with Coverity Scan.
> 
> 3 new defect(s) introduced to Osmocom found with Coverity Scan.
> 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
> 
> New defect(s) Reported-by: Coverity Scan
> Showing 3 of 3 defect(s)
> 
> 
> ** CID 70677:  Control flow issues  (DEADCODE)
> /source-iuh/osmo-pcu/src/gprs_rlcmac_ts_alloc.cpp: 907 in alloc_algorithm_b()
> 
> 
> ________________________________________________________________________________________________________
> *** CID 70677:  Control flow issues  (DEADCODE)
> /source-iuh/osmo-pcu/src/gprs_rlcmac_ts_alloc.cpp: 907 in alloc_algorithm_b()
> 901     					dl_slots, 'D'),
> 902     			single ? ", single" : "");
> 903     
> 904     		/* assign downlink */
> 905     		if (dl_slots == 0) {
> 906     			LOGP(DRLCMAC, LOGL_NOTICE, "No downlink slots "
>>>>    CID 70677:  Control flow issues  (DEADCODE)
>>>>    Execution cannot reach this statement "do  {
>  if (log_check_level...".
> 907     				"available\n");
> 908     			return -EINVAL;
> 909     		}
> 910     		slotcount = pcu_bitcount(dl_slots);
> 911     		first_ts = ffs(dl_slots) - 1;
> 912     		avail_count = pcu_bitcount(reserved_dl_slots);
> 
> ** CID 70676:  Control flow issues  (DEADCODE)
> /source-iuh/libosmo-netif/src/rtp.c: 124 in osmo_rtp_get_payload()
> 
> 
> ________________________________________________________________________________________________________
> *** CID 70676:  Control flow issues  (DEADCODE)
> /source-iuh/libosmo-netif/src/rtp.c: 124 in osmo_rtp_get_payload()
> 118     			return NULL;
> 119     		}
> 120     	}
> 121     	if (rtph->padding) {
> 122     		if (payload_len < 0) {
> 123     			DEBUGPC(DLMUX, "received RTP frame too short for "
>>>>    CID 70676:  Control flow issues  (DEADCODE)
>>>>    Execution cannot reach this statement "do  {
>  if (log_check_level...".
> 124     				"padding length\n");
> 125     			return NULL;
> 126     		}
> 127     		payload_len -= payload[payload_len - 1];
> 128     		if (payload_len < 0) {
> 129     			DEBUGPC(DLMUX, "received RTP frame with padding "
> 
> ** CID 70675:  Control flow issues  (DEADCODE)
> /source-iuh/libosmo-netif/src/channel.c: 57 in osmo_chan_create()
> 
> 
> ________________________________________________________________________________________________________
> *** CID 70675:  Control flow issues  (DEADCODE)
> /source-iuh/libosmo-netif/src/channel.c: 57 in osmo_chan_create()
> 51     		LOGP(DLINP, LOGL_ERROR, "unsupported channel type `%s'\n",
> 52     			cur->name);
> 53     		return NULL;
> 54     	}
> 55     	if (found_partial) {
> 56     		LOGP(DLINP, LOGL_ERROR, "Sorry, channel type `%s' does not "
>>>>    CID 70675:  Control flow issues  (DEADCODE)
>>>>    Execution cannot reach this statement "do  {
>  if (log_check_level...".
> 57     			"support subtype `%u'\n", cur->name, subtype_id);
> 58     		return NULL;
> 59     	}
> 60     
> 61     	c = talloc_zero_size(osmo_chan_ctx,
> 62     			     sizeof(struct osmo_chan) + cur->datasiz);
> 
> 
> ________________________________________________________________________________________________________
> To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/osmocom?tab=overview
> 
> To manage Coverity Scan email notifications for "holger at freyther.de", click https://scan.coverity.com/subscriptions/edit?email=holger%40freyther.de&token=90b620c1f1eaf964c8f6d3882b84a613
> 



From holger at freyther.de  Mon Feb 29 17:52:00 2016
From: holger at freyther.de (Holger Freyther)
Date: Mon, 29 Feb 2016 18:52:00 +0100
Subject: PCU scheduling and PACCH timeout question
In-Reply-To: <BY1PR08MB1308A7DA171754683E5937F285A70@BY1PR08MB1308.namprd08.prod.outlook.com>
References: <56CED717.9060409@sysmocom.de>
 <BY1PR08MB13085AC9043E6F6F846AAA9185A70@BY1PR08MB1308.namprd08.prod.outlook.com>
 <56D0863B.1000401@sysmocom.de>
 <BY1PR08MB1308A7DA171754683E5937F285A70@BY1PR08MB1308.namprd08.prod.outlook.com>
Message-ID: <040E1C04-E6BE-4917-B541-55F011401029@freyther.de>


> On 26 Feb 2016, at 21:23, Saurabh Sharan <Saurabh.Sharan at radisys.com> wrote:
> 
> Hello Max,

Dear Saurabh,


> Please find below chart that indicate time skew is happening in the setup.
> I have also attached the excel sheet used for this analysis here for reference.
> TS4 in downlink is considered for drawing the plot. Please note that block duration value of 18 and 23 milliseconds are acceptable as transmission FNs increment by pattern of 4,4,5,4,4,5,..and so on.
> 4FN duration is 18.4ms and 5 FN is 23 ms approx.
> But the spikes in the system as high as 26.8ms may result in incorrect air interface behavior from L1.

how did you extract the values? Did you create a lua script for wireshark/tshark? It would be interesting to automate this.

kind regards
	holger



From nhofmeyr at sysmocom.de  Mon Feb 29 17:50:42 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 29 Feb 2016 18:50:42 +0100
Subject: OpenGGSN
In-Reply-To: <CAK6q=ucoWvw6hj_GVWMwrA7NjEhaLRZDDtuj4OepoQme_JHjaw@mail.gmail.com>
References: <CAK6q=ucoWvw6hj_GVWMwrA7NjEhaLRZDDtuj4OepoQme_JHjaw@mail.gmail.com>
Message-ID: <20160229175042.GE1913@dub6>

Hey Terje,

On Mon, Feb 29, 2016 at 12:46:30PM +0100, Terje Kristoffer Hybbestad Skow wrote:
> Does this mailinglist also regard openGGSN?

Yes, the Osmocom community has adopted maintenance of OpenGGSN, even though it
wasn't written "here".

> If so do I have some questions. I have problem setting it up correctly.

To test the basic openggsn I used to do something like this:


  sudo -s

  LD_LIBRARY_PATH=/usr/local/lib ./git/openggsn/ggsn/ggsn -f -c ./localggsn.conf &

  ./git/openggsn/sgsnemu/sgsnemu --createif -l 127.0.0.1 -r 127.0.0.2


With localggsn.conf as

listen 127.0.0.2
net 127.0.0.0/24
pcodns1 8.8.8.8
logfile /tmp/foo


The above works on linux because it allows implicitly creating the 127.*.*.*
interfaces. On other OSes, you'd have to create those first on one of your
network interfaces.

See http://git.osmocom.org/openggsn/tree/examples/ggsn.conf for more config
options.

I'd recommend to use wireshark to see what packets are transmitted back and
forth, if you're not already doing that.

I've "recently" implemented GTPhub, which relays GTP, e.g. through a NAT. If
that's of interest too, call again, and I can give you an example config for
testing sgsnemu -> gtphub -> openggsn, too.

To actually relay data through the tunnel interface that is created, AFAIK you
first need to send a Create PDP Context message to the GGSN. Maybe read
http://git.osmocom.org/openbsc/tree/openbsc/tests/gtphub/gtphub_test.c
For testing real data, I used an actual sysmoBTS with a "special" SIM card
instead of sgsnemu, because here in the lab that was easier... :P

Hope to have helped :)

~Neels



-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160229/7ccc8d46/attachment.bin>