From vicent.ferrerguasch at aalto.fi Thu Sep 1 07:51:32 2016
From: vicent.ferrerguasch at aalto.fi (Ferrer Guasch Vicent)
Date: Thu, 1 Sep 2016 07:51:32 +0000
Subject: GTP-u Kernel module
Message-ID: <36EDBB147A06874B9DF7A8F578B265BA0158CFE3EF@EXMDB04.org.aalto.fi>
Hi!
We are affiliated with Aalto University and conducting research in the area of mobile networks. We have been improving Amit Chawre's project NwEPC. I saw your implementation of the GTP-U kernel module and I started to check If I could integrate it to this project.
I couldn't find any roadmap of the GTP-U in your website. Do you have any future plans for it? I am interested in the following points:
- Creation, modification and removal of unidirectional tunnels, opposed to the creation of both tunnels without possibility of modification. In the real EPC nodes, the tunnels are never created at the same time. Also they can be removed due to the UE moving to Idle state (i.e. GTP downlink between the eNB and the S-GW).
- Possibility to send End Marker and direct and indirect forwarding tunnels.
- The S-GW receive from a GTP endpoint and sends it to a different one. What mechanisms do you have in mind to do this?
- Support of multiple EPS bearers for the same UE.
- Policy control, enforcement and statistics reporting (probably integrating it with netfilter).
How can I contribute to this project. Should I work on the whole kernel tree? I have no experience with kernel module development. If you want I could work on some API modification proposals and designs.
Kind Regards,
Vicent Ferrer Guasch
PhD candidate
Networking Technology
Department of Communications and Networking
Aalto University
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Arvind.Sirsikar at radisys.com Mon Sep 12 06:31:40 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Mon, 12 Sep 2016 06:31:40 +0000
Subject: [osmo-pcu] Unit test execution is reporting as failed
Message-ID:
Hi All,
Unit test execution of current master of osmo-pcu(9bbe1600cc02e1b538380393edb1dcdabe9247a2) is getting failed with below description
regression tests
1: rlcmac ok
2: ts_alloc ok
3: tbf FAILED (testsuite.at:23)
4: edge ok
5: types ok
6: ms ok
7: llc ok
8: llist ok
9: codel ok
## ------------- ##
## Test results. ##
## ------------- ##
ERROR: All 9 tests were run,
1 failed unexpectedly.
## -------------------------- ##
## testsuite.log was created. ##
## -------------------------- ##
Possible Reason being TbfTest.err is not updated
Thanks,
Aravind Sirsikar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Arvind.Sirsikar at radisys.com Mon Sep 12 10:44:05 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Mon, 12 Sep 2016 10:44:05 +0000
Subject: [osmo-pcu] Unit test execution is reporting as failed
In-Reply-To:
References:
Message-ID:
Hi All,
ERROR: All 9 tests were run,
>I have uploaded the patch https://gerrit.osmocom.org/#/c/843/ in Gerrit. Please have a look.
Thanks,
Aravind Sirsikar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Pravin.Manoharan at radisys.com Mon Sep 12 09:34:18 2016
From: Pravin.Manoharan at radisys.com (Pravin Kumaravel Manoharan)
Date: Mon, 12 Sep 2016 09:34:18 +0000
Subject: Regarding the status of gerrit Id 416
Message-ID:
Hi All,
I have addressed all the comments raised. please let me know the status of https://gerrit.osmocom.org/#/c/416/22
Regards,
Pravin Kumaravel M
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bjovan at gmail.com Tue Sep 13 08:00:37 2016
From: bjovan at gmail.com (BJovke .)
Date: Tue, 13 Sep 2016 10:00:37 +0200
Subject: sgsnemu failing to create PDP context with Cisco GGSN
Message-ID:
Hello.
sgsnemu cannot establish PDP context with latest Cisco GGSN.
There is additional information element "Bearer control mode" sent by GGSN
in create PDP context response message (attachment).
This information element is not recognized by sgsnemu.
Here are the changes in libgtp to support this information element:
9 gtp/gtpie.c
@@ -243,7 +243,8 @@ int gtpie_decaps(union gtpie_member *ie[], int
version, void *pack,
case GTPIE_RP_SMS:
case GTPIE_RP:
case GTPIE_MS_NOT_REACH:
- if (j < GTPIE_SIZE) {
+ case GTPIE_BCM:
+ if (j < GTPIE_SIZE) {
ie[j] = (union gtpie_member *)p;
if (GTPIE_DEBUG)
printf
@@ -457,7 +458,8 @@ int gtpie_encaps(union gtpie_member *ie[], void *pack,
unsigned *len)
case GTPIE_RP_SMS:
case GTPIE_RP:
case GTPIE_MS_NOT_REACH:
- iesize = 2;
+ case GTPIE_BCM:
+ iesize = 2;
break;
case GTPIE_FL_DI: /* TV GTPIE types with value length 2 */
case GTPIE_FL_C:
@@ -558,7 +560,8 @@ int gtpie_encaps2(union gtpie_member ie[], unsigned
int size,
case GTPIE_RP_SMS:
case GTPIE_RP:
case GTPIE_MS_NOT_REACH:
- iesize = 2;
+ case GTPIE_BCM:
+ iesize = 2;
break;
case GTPIE_PFI: /* TV GTPIE types with value length 2 */
case GTPIE_CHARGING_C:
1 gtp/gtpie.h
@@ -106,6 +106,7 @@ static __inline uint64_t hton64(uint64_t q)
#define GTPIE_USER_LOC 152 /* User Location Information */
#define GTPIE_MS_TZ 153 /* MS Time Zone */
#define GTPIE_IMEI_SV 154 /* IMEI Software Version */
+#define GTPIE_BCM 184 /* Bearer control mode */
/* 239-250 Reserved for the GPRS charging protocol (see GTP' in GSM
12.15) */
#define GTPIE_CHARGING_ADDR 251 /* Charging Gateway Address */
/* 252-254 Reserved for the GPRS charging protocol (see GTP' in GSM
12.15) */
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sgsnemu.pcap
Type: application/octet-stream
Size: 930 bytes
Desc: not available
URL:
From nhofmeyr at sysmocom.de Tue Sep 13 22:43:09 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 14 Sep 2016 00:43:09 +0200
Subject: sgsnemu failing to create PDP context with Cisco GGSN
In-Reply-To:
References:
Message-ID: <20160913224309.GA1405@dub7>
Thanks for your patch!
It looks good in principle, but let's clarify some details.
I can't find the 'Bearer Control Mode' in the GTP spec I have here (ETSI TS 129
060 V6.9.0 (2005-06) / 3GPP TS 29.060 version 6.9.0 Release 6), so it looks
like a vendor specific extension. You don't happen to have a spec on it?
Your patch includes some unwanted whitespace changes, it would be great to get
rid of those. I'm marking them below:
On Tue, Sep 13, 2016 at 10:00:37AM +0200, BJovke . wrote:
> - if (j < GTPIE_SIZE) {
> + case GTPIE_BCM:
> + if (j < GTPIE_SIZE) {
The 'if (j...' line shouldn't change.
> - iesize = 2;
> + case GTPIE_BCM:
> + iesize = 2;
The iesize line shouldn't change. (x2)
In fact, those whitespace changes look weird, because in the upstream file
version, the indenting you're apparently adding is already present.
It is easiest for us if you submit your patch using git send-email, or at least
git format-patch, which also ensures that we get a commit log message and
author information, and that the patch is based on our master HEAD.
It would be great if you could resolve these issues. Thanks again!
~Neels
--
- Neels Hofmeyr 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: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
From bjovan at gmail.com Wed Sep 14 12:11:53 2016
From: bjovan at gmail.com (BJovke .)
Date: Wed, 14 Sep 2016 14:11:53 +0200
Subject: sgsnemu failing to create PDP context with Cisco GGSN
In-Reply-To: <20160913224309.GA1405@dub7>
References:
<20160913224309.GA1405@dub7>
Message-ID:
Hello.
"Bearer control mode" is added in Release 7 as I am aware of. It's not
vendor specific.
You can check here: http://www.tech-invite.com/3m29/tinv-3gpp-29-060.html
"If Bearer Control Mode is provided by the GGSN in the PCO, the Bearer
Control Mode IE shall be included in order to inform the SGSN about the
bearer control mode and shall indicate the same bearer control mode as
indicated to the MS in the PCO."
Wireshark (I'm using latest version) decodes this information element with
no problem.
There's probably a method to select Release used by GGSN but the GGSN tests
were done on is in a live mobile network and doing configuration changes on
it is not an option.
I will make those changes in these files in a proper way so there's no
confusion what is added and what is deleted (actually nothing is deleted).
I will use git send-email/git format-patch. I suppose the e-mail to send is
the same (osmocom-net-gprs at lists.osmocom.org)?
Greetings.
2016-09-14 0:43 GMT+02:00 Neels Hofmeyr :
> Thanks for your patch!
> It looks good in principle, but let's clarify some details.
>
> I can't find the 'Bearer Control Mode' in the GTP spec I have here (ETSI
> TS 129
> 060 V6.9.0 (2005-06) / 3GPP TS 29.060 version 6.9.0 Release 6), so it looks
> like a vendor specific extension. You don't happen to have a spec on it?
>
> Your patch includes some unwanted whitespace changes, it would be great to
> get
> rid of those. I'm marking them below:
>
> On Tue, Sep 13, 2016 at 10:00:37AM +0200, BJovke . wrote:
> > - if (j < GTPIE_SIZE) {
> > + case GTPIE_BCM:
> > + if (j < GTPIE_SIZE) {
>
> The 'if (j...' line shouldn't change.
>
> > - iesize = 2;
> > + case GTPIE_BCM:
> > + iesize = 2;
>
> The iesize line shouldn't change. (x2)
>
> In fact, those whitespace changes look weird, because in the upstream file
> version, the indenting you're apparently adding is already present.
>
> It is easiest for us if you submit your patch using git send-email, or at
> least
> git format-patch, which also ensures that we get a commit log message and
> author information, and that the patch is based on our master HEAD.
>
> It would be great if you could resolve these issues. Thanks again!
>
> ~Neels
>
> --
> - Neels Hofmeyr 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: Harald Welte
>
--
Jovan Bunjeva?ki.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bjovan at gmail.com Wed Sep 14 13:12:59 2016
From: bjovan at gmail.com (BJovke .)
Date: Wed, 14 Sep 2016 15:12:59 +0200
Subject: [PATCH] gtp: Added 'Bearer control mode' information element from
Release 7
Message-ID:
---
gtp/gtpie.c | 3 +++
gtp/gtpie.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/gtp/gtpie.c b/gtp/gtpie.c
index a45df1c..c8db449 100644
--- a/gtp/gtpie.c
+++ b/gtp/gtpie.c
@@ -243,6 +243,7 @@ int gtpie_decaps(union gtpie_member *ie[], int version,
void *pack,
case GTPIE_RP_SMS:
case GTPIE_RP:
case GTPIE_MS_NOT_REACH:
+ case GTPIE_BCM:
if (j < GTPIE_SIZE) {
ie[j] = (union gtpie_member *)p;
if (GTPIE_DEBUG)
@@ -457,6 +458,7 @@ int gtpie_encaps(union gtpie_member *ie[], void *pack,
unsigned *len)
case GTPIE_RP_SMS:
case GTPIE_RP:
case GTPIE_MS_NOT_REACH:
+ case GTPIE_BCM:
iesize = 2;
break;
case GTPIE_FL_DI: /* TV GTPIE types with value length 2 */
@@ -558,6 +560,7 @@ int gtpie_encaps2(union gtpie_member ie[], unsigned int
size,
case GTPIE_RP_SMS:
case GTPIE_RP:
case GTPIE_MS_NOT_REACH:
+ case GTPIE_BCM:
iesize = 2;
break;
case GTPIE_PFI: /* TV GTPIE types with value length 2 */
diff --git a/gtp/gtpie.h b/gtp/gtpie.h
index 340a76c..fb8598e 100644
--- a/gtp/gtpie.h
+++ b/gtp/gtpie.h
@@ -106,6 +106,7 @@ static __inline uint64_t hton64(uint64_t q)
#define GTPIE_USER_LOC 152 /* User Location Information */
#define GTPIE_MS_TZ 153 /* MS Time Zone */
#define GTPIE_IMEI_SV 154 /* IMEI Software Version */
+#define GTPIE_BCM 184 /* Bearer control mode */
/* 239-250 Reserved for the GPRS charging protocol (see GTP' in GSM 12.15)
*/
#define GTPIE_CHARGING_ADDR 251 /* Charging Gateway Address */
/* 252-254 Reserved for the GPRS charging protocol (see GTP' in GSM 12.15)
*/
--
2.8.2.windows.1
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From nhofmeyr at sysmocom.de Thu Sep 15 11:07:08 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 15 Sep 2016 13:07:08 +0200
Subject: sgsnemu failing to create PDP context with Cisco GGSN
In-Reply-To:
References:
<20160913224309.GA1405@dub7>
Message-ID: <20160915110708.GA1456@dub7>
On Wed, Sep 14, 2016 at 02:11:53PM +0200, BJovke . wrote:
> Hello.
>
> "Bearer control mode" is added in Release 7 as I am aware of. It's not
> vendor specific.
> You can check here: http://www.tech-invite.com/3m29/tinv-3gpp-29-060.html
Ah, I was reading an outdated version. Thanks!
http://www.etsi.org/deliver/etsi_ts/129000_129099/129060/13.05.00_60/ts_129060v130500p.pdf
> I will make those changes in these files in a proper way so there's no
> confusion what is added and what is deleted (actually nothing is deleted).
> I will use git send-email/git format-patch. I suppose the e-mail to send is
> the same (osmocom-net-gprs at lists.osmocom.org)?
Yes, it is. (Many osmo projects have moved to gerrit.osmocom.org submission,
but OpenGGSN still works via the ML.) Thanks for your effort!
~Neels
--
- Neels Hofmeyr 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: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
From nhofmeyr at sysmocom.de Thu Sep 15 11:57:10 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 15 Sep 2016 13:57:10 +0200
Subject: [PATCH] gtp: Added 'Bearer control mode' information element
from Release 7
In-Reply-To:
References:
Message-ID: <20160915115710.GA2253@dub7>
I had a lot of trouble applying this patch with 'git am' because your
submission is completely broken. There are line wraps and broken indenting
everywhere.
The patch is also sent in HTML format (besides the plain text version).
How did all this happen?
Did you paste the patch file into some web mail UI?? :)
Since the patch is fairly trivial and to avoid more senseless cycles, I applied
it manually. But next time please post a proper patch, that avoids a lot of
time wasted on a trivial change.
~Neels
>
> diff --git a/gtp/gtpie.c b/gtp/gtpie.c
> index a45df1c..c8db449 100644
> --- a/gtp/gtpie.c
> +++ b/gtp/gtpie.c
> case GTPIE_RP_SMS:
> case GTPIE_RP:
> case GTPIE_MS_NOT_REACH:
> + case GTPIE_BCM:
> if (j < GTPIE_SIZE) {
> ie[j] = (union gtpie_member *)p;
> if (GTPIE_DEBUG)
> @@ -457,6 +458,7 @@ int gtpie_encaps(union gtpie_member *ie[], void *pack,
> unsigned *len)
> case GTPIE_RP_SMS:
> case GTPIE_RP:
> case GTPIE_MS_NOT_REACH:
> + case GTPIE_BCM:
> iesize = 2;
> break;
> case GTPIE_FL_DI: /* TV GTPIE types with value length 2 */
> @@ -558,6 +560,7 @@ int gtpie_encaps2(union gtpie_member ie[], unsigned int
> size,
> case GTPIE_RP_SMS:
> case GTPIE_RP:
> case GTPIE_MS_NOT_REACH:
> + case GTPIE_BCM:
> iesize = 2;
> break;
> case GTPIE_PFI: /* TV GTPIE types with value length 2 */
> diff --git a/gtp/gtpie.h b/gtp/gtpie.h
> index 340a76c..fb8598e 100644
> --- a/gtp/gtpie.h
> +++ b/gtp/gtpie.h
> @@ -106,6 +106,7 @@ static __inline uint64_t hton64(uint64_t q)
> #define GTPIE_USER_LOC 152 /* User Location Information */
> #define GTPIE_MS_TZ 153 /* MS Time Zone */
> #define GTPIE_IMEI_SV 154 /* IMEI Software Version */
> +#define GTPIE_BCM 184 /* Bearer control mode */
> /* 239-250 Reserved for the GPRS charging protocol (see GTP' in GSM 12.15)
> */
> #define GTPIE_CHARGING_ADDR 251 /* Charging Gateway Address */
> /* 252-254 Reserved for the GPRS charging protocol (see GTP' in GSM 12.15)
> */
> --
> 2.8.2.windows.1
--
- Neels Hofmeyr 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: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
From nhofmeyr at sysmocom.de Thu Sep 15 13:06:40 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 15 Sep 2016 15:06:40 +0200
Subject: [PATCH 3/3] cosmetic: gtp.c: clarify strncpy nul term
In-Reply-To: <1473944800-6054-1-git-send-email-nhofmeyr@sysmocom.de>
References: <1473944800-6054-1-git-send-email-nhofmeyr@sysmocom.de>
Message-ID: <1473944800-6054-3-git-send-email-nhofmeyr@sysmocom.de>
Rather nul-terminate string buffer after writing bytes. This is only cosmetic
since 'NAMESIZE - 1' is passed to the strn* functions. This ordering shows the
intention more clearly.
Also put the comment on its own line and explain in more detail.
---
gtp/gtp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gtp/gtp.c b/gtp/gtp.c
index cdff238..c974b7b 100644
--- a/gtp/gtp.c
+++ b/gtp/gtp.c
@@ -648,9 +648,10 @@ static void log_restart(struct gsn_t *gsn)
int counter = 0;
char filename[NAMESIZE];
- filename[NAMESIZE - 1] = 0; /* No null term. guarantee by strncpy */
strncpy(filename, gsn->statedir, NAMESIZE - 1);
strncat(filename, "/" RESTART_FILE, NAMESIZE - 1 - strlen(filename));
+ /* guarantee nul term, strncpy might omit if too long */
+ filename[NAMESIZE - 1] = 0;
i = umask(022);
--
2.1.4
From nhofmeyr at sysmocom.de Thu Sep 15 13:06:38 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 15 Sep 2016 15:06:38 +0200
Subject: [PATCH 1/3] Fix possible buffer overflow for gsn_restart file path
Message-ID: <1473944800-6054-1-git-send-email-nhofmeyr@sysmocom.de>
For strncat, to obtain n, one must not subtract the length of what is appended,
but the length of what is already written from the buffer size.
Verified with this little test program:
#include
#include
int main() {
char buf[20];
strncpy(buf, "123", 10);
strncat(buf, "456789012345", 10 - strlen(buf));
printf("%s\n", buf);
return 0;
}
It prints "1234567890".
---
gtp/gtp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gtp/gtp.c b/gtp/gtp.c
index 12cb492..55a8ce4 100644
--- a/gtp/gtp.c
+++ b/gtp/gtp.c
@@ -650,7 +650,7 @@ static void log_restart(struct gsn_t *gsn)
filename[NAMESIZE - 1] = 0; /* No null term. guarantee by strncpy */
strncpy(filename, gsn->statedir, NAMESIZE - 1);
- strncat(filename, RESTART_FILE, NAMESIZE - 1 - sizeof(RESTART_FILE));
+ strncat(filename, RESTART_FILE, NAMESIZE - 1 - strlen(filename));
i = umask(022);
--
2.1.4
From nhofmeyr at sysmocom.de Thu Sep 15 13:06:39 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 15 Sep 2016 15:06:39 +0200
Subject: [PATCH 2/3] add missing path separator for gsn_restart file
In-Reply-To: <1473944800-6054-1-git-send-email-nhofmeyr@sysmocom.de>
References: <1473944800-6054-1-git-send-email-nhofmeyr@sysmocom.de>
Message-ID: <1473944800-6054-2-git-send-email-nhofmeyr@sysmocom.de>
Put restart file in dir/gsn_restart instead of ../dirgsn_restart.
---
gtp/gtp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gtp/gtp.c b/gtp/gtp.c
index 55a8ce4..cdff238 100644
--- a/gtp/gtp.c
+++ b/gtp/gtp.c
@@ -650,7 +650,7 @@ static void log_restart(struct gsn_t *gsn)
filename[NAMESIZE - 1] = 0; /* No null term. guarantee by strncpy */
strncpy(filename, gsn->statedir, NAMESIZE - 1);
- strncat(filename, RESTART_FILE, NAMESIZE - 1 - strlen(filename));
+ strncat(filename, "/" RESTART_FILE, NAMESIZE - 1 - strlen(filename));
i = umask(022);
--
2.1.4
From nhofmeyr at sysmocom.de Thu Sep 15 13:12:07 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 15 Sep 2016 15:12:07 +0200
Subject: OpenGGSN - Re: [PATCH 1/3] Fix possible buffer overflow for
gsn_restart file path
In-Reply-To: <1473944800-6054-1-git-send-email-nhofmeyr@sysmocom.de>
References: <1473944800-6054-1-git-send-email-nhofmeyr@sysmocom.de>
Message-ID: <20160915131207.GA6279@dub7>
This is a patch series for OpenGGSN. It was submitted before on August 18th,
but this new version separates the nul termination thing to a separate commit
(and slightly tweaks it).
~Neels
On Thu, Sep 15, 2016 at 03:06:38PM +0200, Neels Hofmeyr wrote:
> For strncat, to obtain n, one must not subtract the length of what is appended,
> but the length of what is already written from the buffer size.
[...]
--
- Neels Hofmeyr 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: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
From holger at freyther.de Thu Sep 15 13:37:35 2016
From: holger at freyther.de (Holger Freyther)
Date: Thu, 15 Sep 2016 15:37:35 +0200
Subject: OpenGGSN - Re: [PATCH 1/3] Fix possible buffer overflow for
gsn_restart file path
In-Reply-To: <20160915131207.GA6279@dub7>
References: <1473944800-6054-1-git-send-email-nhofmeyr@sysmocom.de>
<20160915131207.GA6279@dub7>
Message-ID: <95A38987-1278-494F-9ED5-1016177913D1@freyther.de>
> On 15 Sep 2016, at 15:12, Neels Hofmeyr wrote:
>
> This is a patch series for OpenGGSN. It was submitted before on August 18th,
> but this new version separates the nul termination thing to a separate commit
> (and slightly tweaks it).
I think I had raised it before. The code is not performance critical on start so why not use talloc_strdup here?
holger
From bjovan at gmail.com Thu Sep 15 14:52:39 2016
From: bjovan at gmail.com (BJovke .)
Date: Thu, 15 Sep 2016 16:52:39 +0200
Subject: [PATCH] gtp: Added 'Bearer control mode' information element from
Release 7
In-Reply-To: <20160915115710.GA2253@dub7>
References:
<20160915115710.GA2253@dub7>
Message-ID:
Hello.
I'm sorry, you're right, I've pasted it to web mail...
I wasn't aware that you are applying it directly from e-mail.
Linux box I'm working on doesn't have direct access to Internet nor e-mail
server so git doesn't work completely.
I have a Windows machine for that but I haven't configured access to GMail
through SMTP/POP3, I will do that soon.
Again, I'm very sorry, I rarely use git and e-mail patching systems.
I will do my best to do it in a proper way next time.
Thank you for your assistance!
Greetings.
2016-09-15 13:57 GMT+02:00 Neels Hofmeyr :
> I had a lot of trouble applying this patch with 'git am' because your
> submission is completely broken. There are line wraps and broken indenting
> everywhere.
>
> The patch is also sent in HTML format (besides the plain text version).
>
> How did all this happen?
> Did you paste the patch file into some web mail UI?? :)
>
> Since the patch is fairly trivial and to avoid more senseless cycles, I
> applied
> it manually. But next time please post a proper patch, that avoids a lot of
> time wasted on a trivial change.
>
> ~Neels
>
> >
> > diff --git a/gtp/gtpie.c b/gtp/gtpie.c
> > index a45df1c..c8db449 100644
> > --- a/gtp/gtpie.c
> > +++ b/gtp/gtpie.c
> > case GTPIE_RP_SMS:
> > case GTPIE_RP:
> > case GTPIE_MS_NOT_REACH:
> > + case GTPIE_BCM:
> > if (j < GTPIE_SIZE) {
> > ie[j] = (union gtpie_member *)p;
> > if (GTPIE_DEBUG)
> > @@ -457,6 +458,7 @@ int gtpie_encaps(union gtpie_member *ie[], void
> *pack,
> > unsigned *len)
> > case GTPIE_RP_SMS:
> > case GTPIE_RP:
> > case GTPIE_MS_NOT_REACH:
> > + case GTPIE_BCM:
> > iesize = 2;
> > break;
> > case GTPIE_FL_DI: /* TV GTPIE types with value length 2 */
> > @@ -558,6 +560,7 @@ int gtpie_encaps2(union gtpie_member ie[], unsigned
> int
> > size,
> > case GTPIE_RP_SMS:
> > case GTPIE_RP:
> > case GTPIE_MS_NOT_REACH:
> > + case GTPIE_BCM:
> > iesize = 2;
> > break;
> > case GTPIE_PFI: /* TV GTPIE types with value length 2 */
> > diff --git a/gtp/gtpie.h b/gtp/gtpie.h
> > index 340a76c..fb8598e 100644
> > --- a/gtp/gtpie.h
> > +++ b/gtp/gtpie.h
> > @@ -106,6 +106,7 @@ static __inline uint64_t hton64(uint64_t q)
> > #define GTPIE_USER_LOC 152 /* User Location Information */
> > #define GTPIE_MS_TZ 153 /* MS Time Zone */
> > #define GTPIE_IMEI_SV 154 /* IMEI Software Version */
> > +#define GTPIE_BCM 184 /* Bearer control mode */
> > /* 239-250 Reserved for the GPRS charging protocol (see GTP' in GSM
> 12.15)
> > */
> > #define GTPIE_CHARGING_ADDR 251 /* Charging Gateway Address */
> > /* 252-254 Reserved for the GPRS charging protocol (see GTP' in GSM
> 12.15)
> > */
> > --
> > 2.8.2.windows.1
>
> --
> - Neels Hofmeyr 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: Harald Welte
>
--
Jovan Bunjeva?ki.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From nhofmeyr at sysmocom.de Fri Sep 16 10:58:14 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 16 Sep 2016 12:58:14 +0200
Subject: OpenGGSN - Re: [PATCH 1/3] Fix possible buffer overflow for
gsn_restart file path
In-Reply-To: <95A38987-1278-494F-9ED5-1016177913D1@freyther.de>
References: <1473944800-6054-1-git-send-email-nhofmeyr@sysmocom.de>
<20160915131207.GA6279@dub7>
<95A38987-1278-494F-9ED5-1016177913D1@freyther.de>
Message-ID: <20160916105814.GA27078@ass40.sysmocom.de>
On Thu, Sep 15, 2016 at 03:37:35PM +0200, Holger Freyther wrote:
> I think I had raised it before. The code is not performance critical on start so why not use talloc_strdup here?
I must have missed that somehow. Makes more sense indeed.
~Neels
--
- Neels Hofmeyr 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: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
From Arvind.Sirsikar at radisys.com Fri Sep 16 12:09:10 2016
From: Arvind.Sirsikar at radisys.com (Aravind Sirsikar)
Date: Fri, 16 Sep 2016 12:09:10 +0000
Subject: High level summary of the performance activity done by Radisys using
NuRAN 1.0 platform
Message-ID:
Hi All,
Below is the high level summary of the performance activity carried on NuRAN 1.0 board with Commercial UE and Dongle under lab conditions.
* Single MS test
1. UL Test
a. Performance test for long duration (24 hours) for EGPRS Uplink (MCS9) with stable data rate of 45.2kbps
2. DL Test
b. Performance test for long duration (24 hours) for EGPRS downlink(MCS9) with stable throughput of 223kbps with all slots configured for single UE
c. Performance test for all EGPRS MCS(MCS1-MCS9) with stable expected throughput
d. Stress test for short duration with more than theoretical max data rate (MCS9) without any breakage in the system.
e. Stress test for short duration with signaling load (MCS8) without any breakage in the system.
f. Speed test through speedtest.net downlink - 210kbps uplink - 40kbps
* Multi MS test
3. DL Test
a. Performance test for long duration (24 hours) for EGPRS downlink (4 UEs - MCS9) with a combined cell throughput of 223kbps.
Following are the links to the issues raised in Redmine and related patch information which is merged in master
1. https://osmocom.org/issues/1811
a. https://git.osmocom.org/osmo-pcu/commit/?id=22a901905c9749b03fceccda4d550f3da799d524
b. https://git.osmocom.org/osmo-pcu/commit/?id=3463bd4adc1598462560ed84da837d04d0e8e20c
2. https://osmocom.org/issues/1808
a. https://git.osmocom.org/osmo-pcu/commit/?id=e26ee01d56b4c4c2da6abc6b649cb765d5787b98
b. https://git.osmocom.org/osmo-pcu/commit/?id=8e70bb5bb4751e3a7f33b95b2994bff410235844
c. https://git.osmocom.org/osmo-pcu/commit/?id=0ee31cfa381282d0d724fb36c48bae297a0647ac
3. https://osmocom.org/issues/1806
a. https://git.osmocom.org/osmo-pcu/commit/?id=a35c911a91ea7b6d8b017fd103c0d86f79bb271e
b. https://git.osmocom.org/osmo-pcu/commit/?id=7c7a86c080edd9c92778c941bbe484f59a81f93c
4. https://osmocom.org/issues/1805
a. https://git.osmocom.org/osmo-pcu/commit/?id=9f5f008aedc910ff0ce18bf3f92b9b74f0438bf8
b. https://git.osmocom.org/osmo-pcu/commit/?id=024152683646f1b68c85de74f783b81db51d16b5
5. https://osmocom.org/issues/1792
a. https://git.osmocom.org/osmo-pcu/commit/?id=e26ee01d56b4c4c2da6abc6b649cb765d5787b98
Below issue in Redmine is still pending to be submitted to master.
1. https://osmocom.org/issues/1789
Relevant PCU configuration used is present at
https://git.osmocom.org/radisys/osmo-pcu/commit/?h=radisys/egprs_integration&id=0f29b91aff2171ad6bf287b9a402c508a94dbb5d
Thanks,
Aravind Sirsikar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From vicent.ferrerguasch at aalto.fi Thu Sep 22 09:56:05 2016
From: vicent.ferrerguasch at aalto.fi (Ferrer Guasch Vicent)
Date: Thu, 22 Sep 2016 09:56:05 +0000
Subject: GTP-u Kernel module
In-Reply-To: <36EDBB147A06874B9DF7A8F578B265BA0158CFE3EF@EXMDB04.org.aalto.fi>
References: <36EDBB147A06874B9DF7A8F578B265BA0158CFE3EF@EXMDB04.org.aalto.fi>
Message-ID: <36EDBB147A06874B9DF7A8F578B265BA0158D20466@EXMDB04.org.aalto.fi>
Hi all,
If this is not the correct mailing list, please let me know.
Kind Regards,
Vicent
From: osmocom-net-gprs [mailto:osmocom-net-gprs-bounces at lists.osmocom.org] On Behalf Of Ferrer Guasch Vicent
Sent: 1. syyskuuta 2016 10:52
To: osmocom-net-gprs ML
Cc: Llorente Santos Jesus
Subject: GTP-u Kernel module
Hi!
We are affiliated with Aalto University and conducting research in the area of mobile networks. We have been improving Amit Chawre's project NwEPC [1]. ?I saw your implementation of the GTP-U kernel module and I started to check If I could integrate it to this project.
I couldn't find any roadmap of the GTP-U in your website. Do you have any future plans for it? I am interested in the following points:
- Creation, modification and removal of unidirectional tunnels, opposed to the creation of both tunnels without possibility of modification. In the real EPC nodes, the tunnels are never created at the same time. Also they can be removed due to the UE moving to Idle state (i.e. GTP downlink between the eNB and the S-GW).
- Possibility to send End Marker and direct and indirect forwarding tunnels.
- The S-GW receive from a GTP endpoint and sends it to a different one. What mechanisms do you have in mind to do this?
- Support of multiple EPS bearers for the same UE.
- Policy control, enforcement and statistics reporting (probably integrating it with netfilter).
How can I contribute to this project. Should I work on the whole kernel tree? I have no experience with kernel module development. If you want I could work on some API modification proposals and designs.
Kind Regards,
Vicent Ferrer Guasch
PhD candidate
Networking Technology
Department of Communications and Networking
Aalto University
[1]: https://sourceforge.net/projects/nwepc/
From holger at freyther.de Thu Sep 22 12:41:02 2016
From: holger at freyther.de (Holger Freyther)
Date: Thu, 22 Sep 2016 14:41:02 +0200
Subject: GTP-u Kernel module
In-Reply-To: <36EDBB147A06874B9DF7A8F578B265BA0158D20466@EXMDB04.org.aalto.fi>
References: <36EDBB147A06874B9DF7A8F578B265BA0158CFE3EF@EXMDB04.org.aalto.fi>
<36EDBB147A06874B9DF7A8F578B265BA0158D20466@EXMDB04.org.aalto.fi>
Message-ID: <38AEBEB3-64E2-4F72-A71F-6D58A7EF296E@freyther.de>
> On 22 Sep 2016, at 11:56, Ferrer Guasch Vicent wrote:
>
> Hi all,
Hi,
> If this is not the correct mailing list, please let me know.
I think it is a good ml for the topic but you lost me on roadmap. It solves what it had to solve and now it is a matter of scratching your own itch.
> How can I contribute to this project. Should I work on the whole kernel tree? I have no experience with kernel module development. If you want I could work on some API modification proposals and designs.
I think after it hit the mainline kernel we don't have a formal process yet. Pablo, what do you think. Should we host a linux git tree to collect changes that are then fed to netdev, shall people contribute directly there?
holger
From nhofmeyr at sysmocom.de Thu Sep 22 12:48:09 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 22 Sep 2016 14:48:09 +0200
Subject: GTP-u Kernel module
In-Reply-To: <36EDBB147A06874B9DF7A8F578B265BA0158D20466@EXMDB04.org.aalto.fi>
References: <36EDBB147A06874B9DF7A8F578B265BA0158CFE3EF@EXMDB04.org.aalto.fi>
<36EDBB147A06874B9DF7A8F578B265BA0158D20466@EXMDB04.org.aalto.fi>
Message-ID: <20160922124809.GA1212@dub7>
On Thu, Sep 22, 2016 at 09:56:05AM +0000, Ferrer Guasch Vicent wrote:
> Hi all,
>
> If this is not the correct mailing list, please let me know.
> Kind Regards,
> Vicent
Dear Vicent,
you have reached the correct mailing list. We always appreciate contributions.
The reason that you haven't got a reply yet is probably because those of us
that have read the mail simply don't know any better.
Please be patient and possibly bump this list again in a few days' time. I'm
sure you will get an answer eventually. Thanks!
~Neels
--
- Neels Hofmeyr 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: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
From ashishbnv at gmail.com Fri Sep 23 09:50:39 2016
From: ashishbnv at gmail.com (Ashish Kurian)
Date: Fri, 23 Sep 2016 11:50:39 +0200
Subject: OVS GTP-U patch
Message-ID:
Dear Members,
I have applied the GTP-U patch for OVS which was available online and it
was applied successfully. But now I realised that a GTP-U kernel space
implementation is available from you. I am not sure of the interplay of OVS
and linux kernel. The patch for the OVS works in the kernel space and if I
want to use the patched OVS with your linux kernel patch, should I do some
modifications to the patch?
Best Regards,
Ashish Kurian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From msuraev at sysmocom.de Fri Sep 23 09:52:46 2016
From: msuraev at sysmocom.de (Max)
Date: Fri, 23 Sep 2016 11:52:46 +0200
Subject: OVS GTP-U patch
In-Reply-To:
References:
Message-ID: <226835bd-8dd9-a960-5ffe-70b67db0cd62@sysmocom.de>
Curious, I didn't know before about OVS patch. Where can I get it?
On 09/23/2016 11:50 AM, Ashish Kurian wrote:
> Dear Members,
>
> I have applied the GTP-U patch for OVS which was available online and
> it was applied successfully. But now I realised that a GTP-U kernel
> space implementation is available from you. I am not sure of the
> interplay of OVS and linux kernel. The patch for the OVS works in the
> kernel space and if I want to use the patched OVS with your linux
> kernel patch, should I do some modifications to the patch?
>
> Best Regards,
> Ashish Kurian
--
Max Suraev 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 Director: Harald Welte
From pablo at netfilter.org Sun Sep 25 12:25:10 2016
From: pablo at netfilter.org (Pablo Neira Ayuso)
Date: Sun, 25 Sep 2016 14:25:10 +0200
Subject: GTP-u Kernel module
In-Reply-To: <38AEBEB3-64E2-4F72-A71F-6D58A7EF296E@freyther.de>
References: <36EDBB147A06874B9DF7A8F578B265BA0158CFE3EF@EXMDB04.org.aalto.fi>
<36EDBB147A06874B9DF7A8F578B265BA0158D20466@EXMDB04.org.aalto.fi>
<38AEBEB3-64E2-4F72-A71F-6D58A7EF296E@freyther.de>
Message-ID: <20160925122510.GA9304@salvia>
Hi Holger and Vicent,
On Thu, Sep 22, 2016 at 02:41:02PM +0200, Holger Freyther wrote:
> > On 22 Sep 2016, at 11:56, Ferrer Guasch Vicent wrote:
[...]
>
> > If this is not the correct mailing list, please let me know.
>
> I think it is a good ml for the topic but you lost me on roadmap. It
> solves what it had to solve and now it is a matter of scratching
> your own itch.
On my side, I have no plans to add what you need, so patches are very
welcome. I can help providing indications on how to get things done if
you have time to work on this. So I would suggest you fire at one
front at a time.
I would start by adding the assymmetric tunnel ID allocation that you
need, which should not be too complicated to add. You have to extend
the netlink interface that we have on gtp to support this.
> > How can I contribute to this project. Should I work on the whole
> > kernel tree? I have no experience with kernel module development.
> > If you want I could work on some API modification proposals and
> > designs.
>
> I think after it hit the mainline kernel we don't have a formal
> process yet. Pablo, what do you think. Should we host a linux git
> tree to collect changes that are then fed to netdev, shall people
> contribute directly there?
I have just created a gtp specific kernel tree here:
http://git.kernel.org/cgit/linux/kernel/git/pablo/gtp.git/
more specifically, the GTP driver is at driver/net/gtp.c
You can submit patches based on that tree anytime. Please, read this
carefully:
https://www.kernel.org/doc/Documentation/SubmittingPatches
As I'll be taking your patches and submitting them to the Linux
networking kernel mailing list, I need that you make it in the right
way to reduce my maintainance burden here.
Thanks!
From vicent.ferrerguasch at aalto.fi Mon Sep 26 08:44:38 2016
From: vicent.ferrerguasch at aalto.fi (Ferrer Guasch Vicent)
Date: Mon, 26 Sep 2016 08:44:38 +0000
Subject: GTP-u Kernel module
In-Reply-To: <1247_1474806318_57E7C22D_1247_688_1_20160925122510.GA9304@salvia>
References: <36EDBB147A06874B9DF7A8F578B265BA0158CFE3EF@EXMDB04.org.aalto.fi>
<36EDBB147A06874B9DF7A8F578B265BA0158D20466@EXMDB04.org.aalto.fi>
<38AEBEB3-64E2-4F72-A71F-6D58A7EF296E@freyther.de>
<1247_1474806318_57E7C22D_1247_688_1_20160925122510.GA9304@salvia>
Message-ID: <36EDBB147A06874B9DF7A8F578B265BA0158D3492D@EXMDB04.org.aalto.fi>
> On my side, I have no plans to add what you need, so patches are very
> welcome. I can help providing indications on how to get things done if you
> have time to work on this. So I would suggest you fire at one front at a time.
>
> I would start by adding the assymmetric tunnel ID allocation that you need,
> which should not be too complicated to add. You have to extend the netlink
> interface that we have on gtp to support this.
>
Thanks Pablo for the kind response, I will study the docs and the gtp module and try to propose some patches.
Rgds,
Vicent
From nhofmeyr at sysmocom.de Tue Sep 27 18:20:59 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 27 Sep 2016 20:20:59 +0200
Subject: sgsn segfault wegen sndcp / v42.bis commits?
Message-ID: <20160927182059.GA8112@ass40.sysmocom.de>
I have a reproducable segfault in the SGSN, bisecting to below commit:
(To bisect, I rearranged the commits, see branches neels/sndcp_bisect and
neels/sndcp_bisect_bad in openbsc)
? git bisect bad
97991d56800fdc913e6fdf95cac68d598f66b498 is the first bad commit
commit 97991d56800fdc913e6fdf95cac68d598f66b498
Author: Philipp
Date: Fri Aug 26 17:00:21 2016 +0200
SNDCP: add RFC1144 header compression functionality
- Add module to handle compression entities
- Add module to control header compression
- Introduce VTY commands for heade compression configuration
- Add changes in sndcp and llc to integrate header compression
Change-Id: Ia00260dc09978844c2865957b4d43000b78b5e43
:040000 040000 de76aa0ab5dc11ad81666f9f4c933544eedcd4f1 c199c47cd19b5a1a334020a598dba3e0be922fe5 M openbsc
Reproduce: Have a 3G UE try to establish a PDP context. (basically just let it
subscribe to the network with mobile data enabled.) Yes, this is on the
sysmocom/iu branch.
Note: the N-DATA.ind shows the correct hexdump and data length, but the
backtrace shows that two lines below that a function is passed the values
ctx=0x6cf9d0, data=0x0, len=140737316187968) at ranap_common_cn.c:310
So it looks like a stack corruption caused somewhere completely different. It's
very reproducable though, even after rearranging things with other library
states I always get the exact same place segfaulting:
20160927195152039 <001a> iu.c:755 N-DATA.ind(0, 60 00 00 1d 00 00 01 00 34 40 16 00 00 01 00 33 40 0f 60 28 dc 35 00 01 0a 09 01 0b 00 00 00 00 01 , len 33)
20160927195152039 <001a> iu.c:757 1msg 0x6d07a8 len 33
20160927195152039 <001a> iu.c:767 2msg 0x6d07a8 len 33
51
60 28 DC 35 00 01 0A 09 01 0B 00 00 00 00 01
20160927195152039 <001a> iu.c:460 handle_co(dir=4, proc=0)
20160927195152039 <001a> iu.c:433 RAB Asignment Response:
00000101
00110101000000000000000100001010000010010000000100001011
00 00 00 01
Setup: (5/35 00 01 0a 09 01 0b )20160927195152039 <001a> sgsn_libgtp.c:483 Updating TEID on RNC side from 0x00000001 to 0x00000001
20160927195152039 <000f> gprs_gmm.c:2031 PDP(901990000000038/0) <- ACTIVATE PDP CONTEXT ACK
20160927195152039 <001a> iu.c:398 Transmitting L3 Message as RANAP DT (SUA link 0x6ce280 conn_id 0)
16
31 8A 42 03 0E 23 62 1F 72 99 3F 3F 11 43 FF FF
00 00 00 00 2B 06 01 21 0A 17 2A 02 27 14 80 80
21 10 02 00 00 10 81 06 08 08 08 08 83 06 00 00
00 00
59
00
20160927195152039 <001b> sua.c:591 Received SCCP User Primitive (N-DATArequest)
20160927195152039 <001b> sua.c:245 sua_link_send(01 00 08 08 00 00 00 60 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 46 00 14 00 3e 00 00 02 00 10 40 32 31 8a 42 03 0e 23 62 1f 72 99 3f 3f 11 43 ff ff 00 00 00 00 2b 06 01 21 0a 17 2a 02 27 14 80 80 21 10 02 00 00 10 81 06 08 08 08 08 83 06 00 00 00 00 00 3b 40 01 00 00 00 )
Program received signal SIGSEGV, Segmentation fault.
sndcp_sn_xid_req (lle=0x340, nsapi=5 '\005') at gprs_sndcp.c:926
926 gprs_sndcp_comp_free(lle->llme->comp.proto);
(gdb) bt
#0 sndcp_sn_xid_req (lle=0x340, nsapi=5 '\005') at gprs_sndcp.c:926
#1 0x0000000000415681 in send_act_pdp_cont_acc (pctx=0x6d0290)
at sgsn_libgtp.c:346
#2 0x0000000000416ba6 in sgsn_ranap_rab_ass_resp (ctx=0x340, setup_ies=0x0)
at sgsn_libgtp.c:492
#3 0x0000000000422e28 in ranap_handle_co_rab_ass_resp (ies=,
ies=, ctx=) at iu.c:445
#4 cn_ranap_handle_co (ctx=0x6cf9d0, message=0x0) at iu.c:510
#5 0x00007ffff5909f60 in ranap_cn_rx_co (cb=0x422890 ,
ctx=0x6cf9d0, data=0x0, len=140737316187968) at ranap_common_cn.c:310
#6 0x0000000000423d1c in sccp_sap_up (oph=0x6d06a8, link=0x6ce280) at iu.c:768
#7 0x00007ffff5be6c7f in sua_rx_codt (xua=,
link=) at sua.c:1164
#8 sua_rx_co (msg=, xua=, link=)
at sua.c:1196
#9 sua_rx_msg (link=0x0, msg=0x5) at sua.c:1232
#10 0x00007ffff5be7042 in sua_srv_conn_cb (conn=0x6cf300) at sua.c:1360
#11 0x00007ffff4c4c881 in osmo_stream_srv_read (conn=0x6ce1b0) at stream.c:512
#12 osmo_stream_srv_cb (ofd=, what=1) at stream.c:563
#13 0x00007ffff79bab82 in osmo_fd_disp_fds (_eset=0x7fffffffe360,
_wset=0x7fffffffe2e0, _rset=0x7fffffffe260) at select.c:149
#14 osmo_select_main (polling=0) at select.c:191
#15 0x0000000000404ee2 in main (argc=3, argv=0x0) at sgsn_main.c:448
(gdb)
How do we do this? Revert Philipps commits for now?
I need to go now, but next I'll take a short look whether I can reproduce with
other hardware / spot a bug anywhere. No idea yet whether it only happens for
3G.
~Neels
--
- Neels Hofmeyr 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: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
From laforge at gnumonks.org Wed Sep 28 00:15:07 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 28 Sep 2016 08:15:07 +0800
Subject: sgsn segfault wegen sndcp / v42.bis commits?
In-Reply-To: <20160927182059.GA8112@ass40.sysmocom.de>
References: <20160927182059.GA8112@ass40.sysmocom.de>
Message-ID: <20160928001507.r7xkjyh6orc35574@nataraja>
Hi Neels,
On Tue, Sep 27, 2016 at 08:20:59PM +0200, Neels Hofmeyr wrote:
> Note: the N-DATA.ind shows the correct hexdump and data length, but the
> backtrace shows that two lines below that a function is passed the values
> ctx=0x6cf9d0, data=0x0, len=140737316187968) at ranap_common_cn.c:310
> So it looks like a stack corruption caused somewhere completely different. i
If you suspect stack corruption: What does running in valgrind tell you?
--
- Harald Welte 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 Sep 28 00:23:28 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 28 Sep 2016 08:23:28 +0800
Subject: sgsn segfault wegen sndcp / v42.bis commits?
In-Reply-To: <20160927182059.GA8112@ass40.sysmocom.de>
References: <20160927182059.GA8112@ass40.sysmocom.de>
Message-ID: <20160928002328.bljd2ild6vr6dyzg@nataraja>
On Tue, Sep 27, 2016 at 08:20:59PM +0200, Neels Hofmeyr wrote:
> I have a reproducable segfault in the SGSN, bisecting to below commit:
The commit you refer to adds transmission of a SNDCP XID message after
successful PDP context activation. See the unk in
sgsn_libgtp.c:send_act_pdp_cont_acc(),were the code
* assumes there is an LLME and associated LLEs
* sends SNDCP over that
I guess all that's needed is to put this into a section that is
conditional to Gb/GPRS and skip that on Iu/UMTS
As the IuPS code was not in master yet at the time the GPRS compression
was developed, this is more or less a "logical" result.
Regards,
Harald
--
- Harald Welte http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
From nhofmeyr at sysmocom.de Fri Sep 30 23:10:47 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 1 Oct 2016 01:10:47 +0200
Subject: [PATCH 2/2] gsn_restart file: set umask back to original after write
failure
In-Reply-To: <1475277047-3068-1-git-send-email-nhofmeyr@sysmocom.de>
References: <1475277047-3068-1-git-send-email-nhofmeyr@sysmocom.de>
Message-ID: <1475277047-3068-3-git-send-email-nhofmeyr@sysmocom.de>
An fopen("w") error used to omit the umask() call to reinstate the previous
umask. Move the final umask() call to the bottom so that it is called in all
code paths.
---
gtp/gtp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gtp/gtp.c b/gtp/gtp.c
index 161a6f0..a46a76f 100644
--- a/gtp/gtp.c
+++ b/gtp/gtp.c
@@ -681,7 +681,6 @@ static void log_restart(struct gsn_t *gsn)
goto free_filename;
}
- umask(i);
fprintf(f, "%d\n", gsn->restart_counter);
close_file:
if (fclose(f))
@@ -689,6 +688,7 @@ close_file:
"fclose failed: Error = %s\n", strerror(errno));
free_filename:
talloc_free(filename);
+ umask(i);
}
int gtp_new(struct gsn_t **gsn, char *statedir, struct in_addr *listen,
--
2.1.4
From nhofmeyr at sysmocom.de Fri Sep 30 23:10:45 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 1 Oct 2016 01:10:45 +0200
Subject: [PATCH 0/2] OpenGGSN fixes for gsn_restart file path composition
Message-ID: <1475277047-3068-1-git-send-email-nhofmeyr@sysmocom.de>
Neels Hofmeyr (2):
fix gsn_restart file buffer overflow and missing path sep
gsn_restart file: set umask back to original after write failure
gtp/gtp.c | 20 +++++++++-----------
gtp/gtp.h | 1 -
2 files changed, 9 insertions(+), 12 deletions(-)
--
2.1.4
From nhofmeyr at sysmocom.de Fri Sep 30 23:10:46 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 1 Oct 2016 01:10:46 +0200
Subject: [PATCH 1/2] fix gsn_restart file buffer overflow and missing path sep
In-Reply-To: <1475277047-3068-1-git-send-email-nhofmeyr@sysmocom.de>
References: <1475277047-3068-1-git-send-email-nhofmeyr@sysmocom.de>
Message-ID: <1475277047-3068-2-git-send-email-nhofmeyr@sysmocom.de>
Fix errors during gsn_restart file path composition:
- possible buffer overflow because the wrong remaining length was fed to
strncat().
- missing path separator: put restart file in dir/gsn_restart instead of
../dirgsn_restart.
This assumes that the path separator is '/'.
Use talloc_asprintf() to fix all filename length problems and shorten the code.
In order to free the allocated path, add a free_filename label, and jump there
instead of returning from the fopen("w") failure branch. Also don't return from
"fclose failed" branch in order to free the path, remove the if {} braces.
Remove the NAMESIZE constant that is now unused.
---
gtp/gtp.c | 18 ++++++++----------
gtp/gtp.h | 1 -
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/gtp/gtp.c b/gtp/gtp.c
index 12cb492..161a6f0 100644
--- a/gtp/gtp.c
+++ b/gtp/gtp.c
@@ -646,13 +646,11 @@ static void log_restart(struct gsn_t *gsn)
FILE *f;
int i, rc;
int counter = 0;
- char filename[NAMESIZE];
-
- filename[NAMESIZE - 1] = 0; /* No null term. guarantee by strncpy */
- strncpy(filename, gsn->statedir, NAMESIZE - 1);
- strncat(filename, RESTART_FILE, NAMESIZE - 1 - sizeof(RESTART_FILE));
-
+ char *filename;
+
i = umask(022);
+ filename = talloc_asprintf(NULL, "%s/%s", gsn->statedir, RESTART_FILE);
+ OSMO_ASSERT(filename);
/* We try to open file. On failure we will later try to create file */
if (!(f = fopen(filename, "r"))) {
@@ -680,17 +678,17 @@ static void log_restart(struct gsn_t *gsn)
LOGP(DLGTP, LOGL_ERROR,
"fopen(path=%s, mode=%s) failed: Error = %s\n", filename,
"w", strerror(errno));
- return;
+ goto free_filename;
}
umask(i);
fprintf(f, "%d\n", gsn->restart_counter);
close_file:
- if (fclose(f)) {
+ if (fclose(f))
LOGP(DLGTP, LOGL_ERROR,
"fclose failed: Error = %s\n", strerror(errno));
- return;
- }
+free_filename:
+ talloc_free(filename);
}
int gtp_new(struct gsn_t **gsn, char *statedir, struct in_addr *listen,
diff --git a/gtp/gtp.h b/gtp/gtp.h
index 539e255..1434e1e 100644
--- a/gtp/gtp.h
+++ b/gtp/gtp.h
@@ -29,7 +29,6 @@
#define ERRMSG_SIZE 255
#define RESTART_FILE "gsn_restart"
-#define NAMESIZE 1024
/* GTP version 1 extension header type definitions. */
#define GTP_EXT_PDCP_PDU 0xC0 /* PDCP PDU Number */
--
2.1.4