From laforge at osmocom.org Wed Mar 3 09:00:06 2021 From: laforge at osmocom.org (Harald Welte) Date: Wed, 3 Mar 2021 10:00:06 +0100 Subject: Osmocom Mailing List re-organization Message-ID: Dear Osmocom community, This topic has been past due for way too many years by now: A re-organization of our major mailing lists. I would like to propose the following changes. Pleas let me know if you have any comments or feedback. I'm aware that renaming will mean people have to update their mail filter rules, but I think we're long past the point where the names of some of our lists started to confuse users. == openbsc at lists.osmocom.org == * openbsc doesn't exist anymore since OsmoNITB, which is also obsolete * does already cover anything "Osmocom CNI" related * Proposed new name: osmocom-cni at lists.osmocom.org == osmocom-net-gprs at lists.osmocom.org == This date back to when GPRS was a highly experimental add-on to our GSM code base. This list should simply be merged with openbsc@ as osmocom-cni at lists.osmocom.org == simtrace at lists.osmocom.org == Historically was created to cover only the simtrace project. We should rename this to osmocom-simcard at lists.osmocom.org or something along those lines. I would like to suggest it covers * SIMtrace / SIMtrace2 hardware + firmware * pySim and related tools for working with SIM/USIM/UICC cards * any other information / discussion related to SIM/USIM/UICC cards, like OTA, ARA-M, ... == osmodevcon at lists.osmocom.org == This has been a private list for people attending OsmoDevCon I would like to open up list membership to the general public, and ensure it also covers the new OsmoDevCall. We could then have discussions regarding feedback, topics, scheduling, etc. on that list. Maybe rename it to osmocom-events at lists.osmocom.org instead? To differentiate: osmocom-event-orga at lists.osmocom.org should remain a private list related to organizational / administrative topics of those involved with organizing future events. == nextepc at lists.osmocom.org == Should have been renamed to open5gs at lists.osmocom.org quite some time ago, I simply forgot about it. My apologies. -- - 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 Wed Mar 3 19:41:07 2021 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 3 Mar 2021 20:41:07 +0100 Subject: Osmocom Mailing List re-organization In-Reply-To: References: Message-ID: <20210303194107.GC1166@my.box> I think we also could change jenkins-notifications and/or gerrit-log, IIRC one of those was once named "the high noise mailing list" and catches more than just what the name says, currently don't remember which/both of them? builds@ ? noise@ ? build-noise@ ? From kuba at kernel.org Mon Mar 15 18:20:21 2021 From: kuba at kernel.org (Jakub Kicinski) Date: Mon, 15 Mar 2021 11:20:21 -0700 Subject: [PATCH] Net: gtp: Fixed missing blank line after declaration In-Reply-To: <20210313165128.jc2u2pnpm3enbx2h@client-VirtualBox> References: <20210313165128.jc2u2pnpm3enbx2h@client-VirtualBox> Message-ID: <20210315112021.0278875d@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> On Sat, 13 Mar 2021 22:21:28 +0530 Chinmayi Shetty wrote: > Signed-off-by: Chinmayi Shetty > --- > drivers/net/gtp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c > index efe5247d8c42..79998f4394e5 100644 > --- a/drivers/net/gtp.c > +++ b/drivers/net/gtp.c > @@ -437,7 +437,7 @@ static inline void gtp1_push_header(struct sk_buff *skb, struct pdp_ctx *pctx) > gtp1->length = htons(payload_len); > gtp1->tid = htonl(pctx->u.v1.o_tei); > > - /* TODO: Suppport for extension header, sequence number and N-PDU. > + /* TODO: Support for extension header, sequence number and N-PDU. > * Update the length field if any of them is available. > */ > } Subject does not match the patch. From chinmayishetty359 at gmail.com Sat Mar 13 15:45:03 2021 From: chinmayishetty359 at gmail.com (Chinmayi Shetty) Date: Sat, 13 Mar 2021 21:15:03 +0530 Subject: [PATCH] Net: gtp: Fixed missing blank line after declaration Message-ID: <20210313154503.nrz3bzrdy4hw4ypk@client-VirtualBox> Signed-off-by: Chinmayi Shetty --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index efe5247d8c42..79998f4394e5 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -437,7 +437,7 @@ static inline void gtp1_push_header(struct sk_buff *skb, struct pdp_ctx *pctx) gtp1->length = htons(payload_len); gtp1->tid = htonl(pctx->u.v1.o_tei); - /* TODO: Suppport for extension header, sequence number and N-PDU. + /* TODO: Support for extension header, sequence number and N-PDU. * Update the length field if any of them is available. */ } -- 2.25.1 From chinmayishetty359 at gmail.com Sat Mar 13 16:51:28 2021 From: chinmayishetty359 at gmail.com (Chinmayi Shetty) Date: Sat, 13 Mar 2021 22:21:28 +0530 Subject: [PATCH] Net: gtp: Fixed missing blank line after declaration Message-ID: <20210313165128.jc2u2pnpm3enbx2h@client-VirtualBox> Signed-off-by: Chinmayi Shetty --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index efe5247d8c42..79998f4394e5 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -437,7 +437,7 @@ static inline void gtp1_push_header(struct sk_buff *skb, struct pdp_ctx *pctx) gtp1->length = htons(payload_len); gtp1->tid = htonl(pctx->u.v1.o_tei); - /* TODO: Suppport for extension header, sequence number and N-PDU. + /* TODO: Support for extension header, sequence number and N-PDU. * Update the length field if any of them is available. */ } -- 2.25.1 From laforge at gnumonks.org Tue Mar 16 20:07:32 2021 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 16 Mar 2021 21:07:32 +0100 Subject: Automatic testing for kernel GTP tunnel driver Message-ID: Hi all, in recent months - after many years of no patches at all - the kernel GTP driver has received significant interest in terms of contributions. Given the presumed few users of the GTP tunnel driver, as well as the tendency to use super ancient versions of software in the telecom world, I think that the usual "let's have the users test -rcX kernels" approach is unlikely going to work. Within Osmocom (a group of FOSS projects implementing various cellular standards, protocol stacks and network elements) we are used to rather comprehensive functional test suites that we execute automatically at least once per 24 hours. That is for the 99% of our software that is userspace code. For the kernel GTP code, it's of course not that simple, and we never had any related testing so far. In 2021, 5 years after the GTP kernel driver was merged mainline, we now finally have set up some test jobs for kernel GTP. Those jobs execute the same GGSN test suite that we run against the userspace dataplane (handling GTP-U and GTP-C in a userspace program "osmo-ggsn"). The only difference is that they configure osmo-ggsn to use the kernel GTP driver for GTP-U. Those tests are executed by jenkins, in the following jobs: * ttcn3-ggsn-test-kernel-latest-torvalds https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test-kernel-latest-torvalds/ runs GGSN test suite against latest released osmo-ggsn version with kernel-gtp of torvalds/linux.git test results at https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test-kernel-latest-torvalds/test_results_analyzer/ (make sure to click "Expand All") * ttcn3-ggsn-test-kernel-latest-torvalds https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test-kernel-latest-net-next/ runs GGSN test suite against latest released osmo-ggsn version with kernel-gtp of net-next.git test results at https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test-kernel-latest-net-next/test_results_analyzer/ (make sure to click "Expand All") * ttcn3-ggsn-test-kernel-latest https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test-kernel-latest/ runs GGSN test suite against latest released osmo-ggsn version with kernel-gtp of Debian 10 kernel package test results at https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test-kernel-latest/test_results_analyzer/ (make sure to click "Expand All") * ttcn3-ggsn-test-latest https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test-latest/ runs GGSN test suite against latest released osmo-ggsn version with userspace GTP-U, not using any kernel GTP driver test results at https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test-latest/test_results_analyzer/ this serves as a base line that shows the test suite can fully pass, and any failures in the aove are either bugs or lack of features (like IPv6) Contrary to the above jenkins jobs which all run automatically once every 24 hours, there is also one jenkins job for manual execution: * ttcn3-ggsn-test-kernel-git https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test-kernel-git/ this is the same test suite and osmo-ggsn as above, but a developer can manually trigger the job and specify * URL of the kernel git repo to build * branch of the kernel git repo to build * whether to use osmo-ggsn latest tag or master If any one is working on the kernel GTP driver and wants to get access to triggering that jenkins job in order to test your patches/branches before submission, please register an account at https://jenkins.osmocom.org/ and contact me privately. We are always happy about any contributions in terms of extending test coverage. This could be done by e.g. adding jobs using other P-GW/GGSN software than osmo-ggsn, or by extending the coverage of the test cases of the test suite. For anyone interested in more details, please see our redmine issue https://osmocom.org/issues/3208 tracks the development of the tests. The test suite source code (in TTCN-3) is at https://git.osmocom.org/osmo-ttcn3-hacks/tree/ggsn_tests with containerization + configs at https://git.osmocom.org/docker-playground/tree/ttcn3-ggsn-test I'd like to thank Oliver Smith for creating the above automatic test CI integration. Development of this was funded by sysmocom (https://sysmocom.de/) If you have any questions, please feel free to reach out to Oliver and/or me. 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 kuba at kernel.org Tue Mar 16 21:48:01 2021 From: kuba at kernel.org (Jakub Kicinski) Date: Tue, 16 Mar 2021 14:48:01 -0700 Subject: Automatic testing for kernel GTP tunnel driver In-Reply-To: References: Message-ID: <20210316144801.3b03ab5b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> On Tue, 16 Mar 2021 21:07:32 +0100 Harald Welte wrote: > If you have any questions, please feel free to reach out to Oliver > and/or me. Perhaps worth dropping a paragraph and the links into Documentation/? From morteza.ali.ahmadi at gmail.com Fri Mar 26 15:19:13 2021 From: morteza.ali.ahmadi at gmail.com (morteza ali Ahmadi) Date: Fri, 26 Mar 2021 19:49:13 +0430 Subject: Question about establishing stable internet link between UE and HNB connected to our developed network core. Message-ID: Hi, osmocom team members. In order to have an internet connection in UE, we have run OsmoGGSN project to set up GGSN. Also, SGSN is developed in our system. At this step, UE connects to our network core and we can query to an arbitrary site in the UE browser and we see the answer of the query without any problem and everything is OK. But after about 30 or 40 seconds, UE sends "Deactivate PDP Context Request" with SM Cause "SM Cause: Protocol error, unspecified (111)" and the connection is reset and a new "Activate PDP Context Request" is required. What is the reason and how can we solve it? -- *When there is much light, The shadow is deep...* -------------- next part -------------- An HTML attachment was scrubbed... URL: