osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

5 participants
507 discussions

Osmo-ggsn MTU issue with Kernel GTP
by Keith A. Milner 13 Apr '21

13 Apr '21

I've had an interesting situation with osmo-ggsn and kernel GTP module that I wonder if someone could shed some light on. I've set up osmo-ggsn (v1.7.1) on Debian 10. There are two ethernet interfaces on the system, ens224 (for the Gn Interface) and ens256 (for the Gi Interface). Using the following ggsn configuration seems to work fine: ggsn ggsn0 description Keith's Test APN gtp state-dir /tmp gtp bind-ip <ens224 IP> gtp control-ip <ens224 IP> apn keithtest gtpu-mode tun tun-device apn0 type-support v4 ip prefix dynamic 192.168.42.0/24 ip dns 0 <redacted> ip dns 1 <redacted> ip ifconfig 192.168.42.0/24 no shutdown default-apn keithtest no shutdown ggsn I get the following tun device: 5: apn0: <POINTOPOINT,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500 link/none inet 192.168.42.0/24 scope global apn0 valid_lft forever preferred_lft forever inet6 fe80::fada:2e69:ad71:a61b/64 scope link stable-privacy valid_lft forever preferred_lft forever Traffic routes, all is good with the world. However, if I change to using Kernel GTP, by changing the gtpu-mode to "kernel-gtp", traffic will not route (and, yes, I have done modprobe gtp). After some exploration, it appears the tun device is being created with an MTU of zero which then, cannot pass traffic: 10: apn0: <POINTOPOINT,UP,LOWER_UP> mtu 0 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet 192.168.42.0/24 scope global apn0 valid_lft forever preferred_lft forever Here are the logs: Tue Apr 13 11:02:06 2021 DGGSN NOTICE <0002> ggsn.c:830 GGSN(ggsn0): Successfully started Tue Apr 13 11:02:06 2021 DGGSN INFO <0002> ggsn.c:186 APN(keithtest): Starting Tue Apr 13 11:02:06 2021 DGGSN INFO <0002> ggsn.c:204 APN(keithtest): Opening Kernel GTP device apn0 Tue Apr 13 11:02:06 2021 DGGSN NOTICE <0002> gtp-kernel.c:79 Initialized GTP kernel mode (genl ID is 24) Tue Apr 13 11:02:06 2021 DTUN NOTICE <0001> tun.c:217 GTP kernel configured Tue Apr 13 11:02:06 2021 DGGSN INFO <0002> ggsn.c:236 APN(keithtest): Setting tun IP address 192.168.42.0/24 Tue Apr 13 11:02:06 2021 DGGSN INFO <0002> ggsn.c:294 APN(keithtest): Creating IPv4 pool 192.168.42.0/24 Tue Apr 13 11:02:06 2021 DGGSN INFO <0002> ggsn.c:168 APN(keithtest): Blacklist tun IP 192.168.42.0/24 Tue Apr 13 11:02:06 2021 DGGSN NOTICE <0002> ggsn.c:325 APN(keithtest): Successfully started Note that if I manually alter the MTU, everything starts working again: ip link set dev apn0 mtu 1500 So I can put this into a script and run it via ipup-script, and this works fine. I just get the impression I shouldn't have to do this, and the system should be setting the MTU, just as it does when I use tun mode. Any thoughts on what I'm doing wrong here? Cheers, Keith

2 2

Question about establishing stable internet link between UE and HNB connected to our developed network core.
by morteza ali Ahmadi 26 Mar '21

26 Mar '21

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...*

1 0

Automatic testing for kernel GTP tunnel driver
by Harald Welte 16 Mar '21

16 Mar '21

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-l… 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-l… (make sure to click "Expand All") * ttcn3-ggsn-test-kernel-latest-torvalds https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test-kernel-l… 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-l… (make sure to click "Expand All") * ttcn3-ggsn-test-kernel-latest https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test-kernel-l… 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-l… (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/t… 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-g… 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 <osmith(a)sysmocom.de> 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 <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

[PATCH] Net: gtp: Fixed missing blank line after declaration
by Chinmayi Shetty 15 Mar '21

15 Mar '21

Signed-off-by: Chinmayi Shetty <chinmayishetty359(a)gmail.com> --- 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

2 1

[PATCH] Net: gtp: Fixed missing blank line after declaration
by Chinmayi Shetty 13 Mar '21

13 Mar '21

1 0

Osmocom Mailing List re-organization
by Harald Welte 03 Mar '21

03 Mar '21

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(a)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(a)lists.osmocom.org == osmocom-net-gprs(a)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(a)lists.osmocom.org == simtrace(a)lists.osmocom.org == Historically was created to cover only the simtrace project. We should rename this to osmocom-simcard(a)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(a)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(a)lists.osmocom.org instead? To differentiate: osmocom-event-orga(a)lists.osmocom.org should remain a private list related to organizational / administrative topics of those involved with organizing future events. == nextepc(a)lists.osmocom.org == Should have been renamed to open5gs(a)lists.osmocom.org quite some time ago, I simply forgot about it. My apologies. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

Osmocom CNI release 202102
by Pau Espin Pedrol 26 Feb '21

26 Feb '21

Dear all, I am pleased to announce new tagged releases for Osmocom Cellular Network Infrastructure components. Find more information about the release here [1]. Osmocom "Latest" repositories in OBS [2] should already contain packages for the new versions. OpenEmbedded related meta-layers such as meta-telephony usual stable/testing branch "201705" [3] have also been updated to build recipes for new versions. Regards, Pau [1] https://osmocom.org/news/132 [2] https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds [3] https://git.osmocom.org/meta-telephony/log/?h=201705 -- - Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

1 0

Very useful wireshark fix for NS / BSSGP decoding
by Harald Welte 13 Feb '21

13 Feb '21

In case anyone has been annoyed by this before: wireshark so far always showed _only_ the BSSGP decode in the Information column of a Gb interface pcap file, even if that BSSGP was contained in the "erroneous message" IE of a NS-STATUS message. This made it particularly difficult to spot NS-STATUS, and without custom coloring rules or search filters, a protocol trace would just look fine - except that in reality it isn't. I've now found out what's the proper method to resolve this and submitted a patch to wireshark, which was merged very quickly: https://gitlab.com/wireshark/wireshark/-/merge_requests/2081 After this change, the Information column in the packet list will show NS-STATUS with the human-redaable cause value for the reject, rather than displaying BSSGP as if nothing odd happened. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Question about OsmoGGSN project
by morteza ali Ahmadi 08 Feb '21

08 Feb '21

Hi, osmocom team members We have run OsmoGGSN project using the attached config file in this email and the following command: osmo-ggsn As you can see in the config file, we have set IP 127.0.0.2 for GGSN. After executing the above command, a tunnel named tun4 is created. To communicate with SGSN, we use the SGSN emulator in OsmoGGSN as follow: sgsnemu -l 127.0.0.1 -r 127.0.0.2 After executing the above command, we see that 2 packets are sent from SGSN to GGSN. These packets are "Echo request" and "Create PDP context request" and GGSN responses to SGSN with the packets "Echo response" and "Create PDP context response". To test tun4, we send a GTP <DNS> packet containing an arbitrary query to GGSN and we see that this GTP <DNS> packet is received in Loopback (lo) interface and also, the DNS packet is received in tun4 interface. But there is no DNS response to our query neither in tun4 interface nor lo interface. A screenshot of the lo interface and tun4 interface in the wireshark is attached in this email (right is lo and left is tun4). How can we receive DNS responses to our DNS query? (Does tun4 require routing or something else?) -- *When there is much light, The shadow is deep...*

2 2

Question about libgtpnl
by morteza ali Ahmadi 03 Feb '21

03 Feb '21

Hi Osmocom team We have a basic question about libgtpnl (Linux Kernel GTP-U). We receive a lot of GTP <DNS> packets which are sent from MS to our HNB and from HNB to our SGSN (a screenshot is attached in this email). As you can see in the one of these packets in the attached image, our MS IP is 10.250.0.114 and our SGSN IP is 172.60.3.154. Also, our TEID is 100 which is set in RAB-Assignment Request sending from SGSN to HNB. In order to put these GTP packets in our GTP tunnel, we use libgtpnl and the two following commands: gtp-link add gtp1 gtp-tunnel add gtp1 v1 100 1 10.250.0.114 172.60.3.154 But when we monitor the gtp1 interface in the wireshark, there is no packet on this interface. Could you please help us to know the reason for this problem? (It is worth mentioning that after receiving these GTP <DNS> packets from MS to SGSN and using netstat, we see that Recv-Q (bytes in UDP port 2152 which are ready to read) is increased to a value more than 0) Best regards -- *When there is much light, The shadow is deep...*

2 2

← Newer
1
...
10
11
12
13
14
15
16
...
51
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs