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