osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

2 participants
516 discussions

[PATCH net-next 0/4] gtp: support multiple APN's per GTP endpoint
by Andreas Schultz 14 Mar '17

14 Mar '17

Support multiple APN's per GTP endpoint and as an additional benefit support multiple GTP sockets per GTP entity. Use case multiple APN's: ------------------------ In 3GPP a APN is control path construct. When mappend into the data path, it mean that UE IP's can be source from independended IP networks with overlaping IP ranges. 3GPP, TS 29.061 version 13.6.0 Release 13, Section 11.3 describes this as: > 2. each private network manages its own addressing. In general this will > result in different private networks having overlapping address ranges. > A logically separate connection (e.g. an IP in IP tunnel or layer 2 > virtual circuit) is used between the GGSN/P-GW and each private network. > In this case the IP address alone is not necessarily unique. The pair > of values, Access Point Name (APN) and IPv4 address and/or IPv6 prefixes, > is unique. To support such a setup, each APN is mapped to a Linux network device. VRF-Lite, network namespaces or other mechanismns can the be used to realize the full separation of the per APN IP networks. Use case multiple GTP sockets per GTP entity: --------------------------------------------- A GTP entity like a PGW can use multiple GTP sockets for: * separate IPv4 and IPv6 transport endpoints * support multiple reference points in separated IP networks, e.g. have Gn/Gp/S5/S8 in a GRX attaches network and S2a/S2b in another private network Especially the S2a/S2b separation is an important scenario. The networks use for roaming and non roaming attachment (Gn/Gp/S5/S8 reference points) are usually different from the connection for trusted and untrusted WiFi access (S2a/S2b). Will the GTP transport networks are separated, it is still desirable to terminated the tunnels in the same GTP entity to ensure uninterrupted IP connectivity during 3G/LTE to/from WiFi handover. Implementation: --------------- APN's are a control path construct, the identification of the associated network device need therefore to be bound to be tunnel endpoint identifier. This series moves the hash for the incoming tunnel endpoint identifiers into the socket to support multiple network devices per GTP socket. It the adds a method of enabling the GTP encapsulation on a socket without having to bound the socket to a network device and finally allows to specify a GTP socket per PDP context. API impact: ----------- This is probably the most problematic part of this series... The removeal of the TEID form the netdevice also means that the gtp genl API for retriving tunnel information and removing tunnels needs to be adjusted. Before this change it was possible to change a GTP tunnel using the gtp netdevice id and the teid. The teid is no longer unique per gtp netdevice. After this change it has to be either the netdevice and MS IP or the GTP socket and teid. Fortunatly, libgtpnl has always populated the Link Id, TEID, GSN Peer IP and MS IP. The library interface has ensured that all information that is mandatory after this change is guaranteed to be present. The only project that doesn't use libgtpnl (OpenAir-CN) is also populating all of those values. The API change will therefore not break any existing userspace applications. -- Andreas Schultz (4): gtp: move TEID hash to per socket structure gtp: add genl cmd to enable GTP encapsulation on UDP socket gtp: add support to select a GTP socket during PDP context creation Extend Kernel GTP-U tunneling documentation Documentation/networking/gtp.txt | 103 ++++++++++++++- drivers/net/gtp.c | 263 ++++++++++++++++++++++++++++----------- include/uapi/linux/gtp.h | 4 + 3 files changed, 292 insertions(+), 78 deletions(-) -- 2.10.2

4 14

[PATCH net-next v5 0/7] gtp: misc improvements
by Andreas Schultz 13 Mar '17

13 Mar '17

Hi Pablo, This is a resent of last series that missed the merge window. There are no changes compared to v4. v4: Compared to v3 it contains mostly smallish naming and spelling fixes. It also drops the documentation patch, Harald did a better job with the documentation and the some things I described do not yet match the implementation. I'll readd the relevant parts with a follow up series. This series lays the groundwork for removing the socket references from the GTP netdevice by removing duplicate code and simplifying the logic on some code paths. It slighly changes the GTP genl API by making the socket parameters optional (though one of them is still required). The removal of the socket references will break the 1:1 releation between GTP netdevice and GTP socket that prevents us to support multiple VRFs with overlapping IP addresse spaces attached to the same GTP-U entity (needed for multi APN support, coming a follow up series). Pablo found a socket hold problem in v2. In order to solve that I had to switch the socket references from the struct socket to the internal struct sock. This should have no functionl impact, but we can now hang on to the reference without blocking user space from closing the GTP socket. v4->v5: * resent for new merge window v3->v4: * drop the documentation patch * spelling fixes * pass nlattr instead of genl_info into gtp_find_dev, makes the code slightly more compact and readable v2->v3: * add documentation to explain the goal of all these changes * incorporate review comments * switch from struct socket to struct sock Regards Andreas -- Andreas Schultz (7): gtp: switch from struct socket to struct sock for the GTP sockets gtp: make GTP sockets in gtp_newlink optional gtp: merge gtp_get_net and gtp_genl_find_dev gtp: consolidate gtp socket rx path gtp: unify genl_find_pdp and prepare for per socket lookup gtp: consolidate pdp context destruction into helper gtp: add socket to pdp context drivers/net/gtp.c | 543 +++++++++++++++++++++++++++--------------------------- 1 file changed, 269 insertions(+), 274 deletions(-) -- 2.10.2

4 12

SMS over GPRS
by Christian Wilkinson 10 Mar '17

10 Mar '17

Hi! According to the OsmoSGSN wiki, SMS delivery over GPRS is currently a TODO item. I was wondering about the current state of this feature, and if there is any work in progress that could be built upon. Is there an estimate of the amount of dev work required to contribute this feature to the project? Thanks, Christian

2 2

Basic test setup for testing of Kernel GTP-U
by Harald Welte 24 Feb '17

24 Feb '17

Hi all, [intentionally breaking the thread here] On Thu, Feb 23, 2017 at 05:46:57PM +0100, Harald Welte wrote: > I'll try to cook up some instructions extending > https://osmocom.org/projects/openggsn/wiki/OpenGGSN to cover also > sgsnemu for a basic use case of establishing one single tunnel. That's > of course like a manual "HOWTO" and not yet anything that can be tested > automatically. I've documented the instructions at https://osmocom.org/projects/linux-kernel-gtp-u/wiki/Basic_Testing Please let me know any updates/corrections/questions if you try to reproduce this. The above instructions were working for me yesterday. Please find an ASCII export of this below (much less readable than the wiki). Regards, Harald h1. Basic Testing This page documents some basic testing setup for the Kenrel GTP-U code. It follows the below rationale: * focus on testing the kernel GTP-U module without too much external dependencies * test GTP-U interoperability of the kernel with at least one other implementation, not just kernel-to-kernel (which currently is not supported in the kernel, as it only implements the GGSN/P-GW role) * limit testing to SGSN/S-GW and GGSN/P-GW, without a real cellular network (which is possible e.g. using [[OsmoSGSN:]] and [[OsmoPCU:]]) h2. Building / Installing dependencies In order to follow below test instructions, you will need * A Linux kernel including the GTP-U driver (@drivers/net/gtp.c@) either compiled-in or as kernel module * [[libgtpnl]] - the userspace library providing an API around the kernel GTP-U netlink interface * [[OpenGGSN:]] - a minimal C-language implementation of a 3GPP GGSN, also contains a SGSN-side emulator called [[OpenGGSN:sgsnemu]] ** make sure you use Version 0.93 or later ** make sure you compile it with @--enable-gtp-linux@ enable during the @./configure@ step You can find some instructions on how to build [[OpenGGSN:]] with support for [[libgtpnl]] and kernel GTP-U at this wiki page: [[OpenGGSN:Kernel_GTP]] h2. Test setup description We will run the GGSN natively on the host, and put the emulated SGSN inside a separate network namespace. The two namespaces are interconnected by a virtual ethernet device using the transfer network 172.31.1.0/24 The GGSN is configured to provide a pool of IP addresses from the 192.168.71.0/24 range. Each PDP context will be allocated one dynamic address from that pool h2. Test instructions h3. create the network namespace for the SGSN ip netns add sgsn h3. add veth to be used between SGSN and GGSN ip link add veth0 type veth peer name veth1 h3. remote (SGSN) side of veth device <pre> ip link set veth1 netns sgsn ip netns exec sgsn ip addr add 172.31.1.2/24 dev veth1 ip netns exec sgsn ip link set veth1 up </pre> h3. local (GGSN) side of veth device <pre> ip addr add 172.31.1.1/24 dev veth0 ip link set veth0 up </pre> h3. execute the GGSN on the host ggsn -g -c ./ggsn.conf.test (use the file attached to this wiki page) The @-g@ option is responsible for activating kernel-GTP support. If you cannot get the example described in this document to work, try the pure GTP-U userspace implementation by removing @-g@ from the above command line. If it works then, there's something related to Kernel GTP-U that breaks the setup. h3. execute the emulated SGSN inside the sgsn namespace ip netns exec sgsn sgsnemu -d -r 172.31.1.1 -l 172.31.1.2 --defaultroute --createif h3. verify the existnace of the GTP tunnel <pre> ggsn:~# gtp-tunnel list version 1 tei 1/1 ms_addr 192.168.71.2 sgsn_addr 172.31.1.2 </pre> h3. further testing in the @sgsn@ namespace, there's now a default-route that points into the GTP tunnel. You can use this to ping any network address that's reachable to the GGSN host. If that host is connected to the internet, you can e.g. run a ping command from within the namespace using ip netns exec sgsn ping -c 10 8.8.8.8 which will send some IP packets to 8.8.8.8 via the tun0 device (created by [[OpenGGSN:sgsnemu]]). It will be encapsulated by the userspace GTP-U implementation of sgsnemu, sent via the veth device to the host, where it ends up inthe GTP-U kernel module, decapsulating the package and passing in on to the gtp0 device there. Anything beyond that point depends on your local routing configuration. == Building OpenGGSN == h1. OpenGGSN and Linux Kernel accelerated GTP-U OpenGGSN has support to use the Linux kernel GTP-U code to accelerate the data/user plane while still implementing the control plane (GTP-C) in userspace in OpenGGSN. For more information about the Linux kernel GTP-U code, please see [[linux-kernel-gtp-u:]] h2. Building OpenGGSN with kernel which has GTP-U support At the time of writing (2017-01-09) of this wiki, below listed distributions have support of GTP kernels : * Debian 4.9.1-1~exp1 - Debian's latest experimental build * Ubuntu 16.10 kernel 4.8 * OpenSUSE Tumbleweed (stable) 4.8 (.12) * Fedora 25 kernel 4.8 Following two Debian kernels do not activate GTP kernel module during build: 4.8.0 and 4.9.0. *It is expected that complete openbsc project and related dependencies are pre-installed.* Check if package @libc-ares-dev@ is installed and if not please add it. Ubuntu 16.10, kernel 4.8.0-30-generic is used. * Installing dependencies and build library @libgtpnl@ You can install those packages with: <pre> sudo apt install libtalloc-dev libpcsclite libmnl-dev </pre> Please follow instructions provided at [[cellular-infrastructure:Build from source]] in order to install following library and projects : Information about dependencies between Osmocom projects is given at the above link: * libgtpnl <pre> sudo make install sudo ldconfig </pre> * libosmocore * openggsn <pre> ./configure --enable-gtp-linux make sudo make install sudo ldconfig </pre> Following message is shown at end of the command: @ ./configure --enable-gtp-linux@ <pre> openggsn Configuration: GTP Linux kernel support: yes </pre> This means that appropriate header files are available. -- - 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)

1 0

[PATCH net-next v4 0/7] gtp: misc improvements
by Andreas Schultz 23 Feb '17

23 Feb '17

Hi Pablo, This is v4 of the GTP improvements. Compared to v3 it contains mostly smallish naming and spelling fixes. It also drops the documentation patch, Harald did a better job with the documentation and the some things I described do not yet match the implementation. I'll readd the relevant parts with a follow up series. This series lays the groundwork for removing the socket references from the GTP netdevice by removing duplicate code and simplifying the logic on some code paths. It slighly changes the GTP genl API by making the socket parameters optional (though one of them is still required). The removal of the socket references will break the 1:1 releation between GTP netdevice and GTP socket that prevents us to support multiple VRFs with overlaping IP addresse spaces attached to the same GTP-U entity (needed for multi APN support, comming a follow up series). Pablo found a socket hold problem in v2. In order to solve that I had to switch the socket references from the struct socket to the internal struct sock. This should have no functionl impact, but we can now hang on to the reference without blocking user space from closing the GTP socket. v3->v4: * drop the documentation patch * spelling fixes * pass nlattr instead of genl_info into gtp_find_dev, makes the code slightly more compact and readable v2->v3: * add documentation to explain the goal of all these changes * incorporate review comments * switch from struct socket to struct sock Regards Andreas -- Andreas Schultz (7): gtp: switch from struct socket to struct sock for the GTP sockets gtp: make GTP sockets in gtp_newlink optional gtp: merge gtp_get_net and gtp_genl_find_dev gtp: consolidate gtp socket rx path gtp: unify genl_find_pdp and prepare for per socket lookup gtp: consolidate pdp context destruction into helper gtp: add socket to pdp context drivers/net/gtp.c | 543 +++++++++++++++++++++++++++--------------------------- 1 file changed, 269 insertions(+), 274 deletions(-) -- 2.10.2

4 16

[PATCH net-next v3 0/8] gtp: misc improvements
by Andreas Schultz 22 Feb '17

22 Feb '17

Hi Pablo, This is v3 of the GTP improvements. This series lays the groundwork for removing the socket references from the GTP netdevice by removing duplicate code and simplifying the logic on some code paths. It slighly changes the GTP genl API by making the socket parameters optional (though one of them is still required). The removal of the socket references will break the 1:1 releation between GTP netdevice and GTP socket that prevents us to support multiple VRFs with overlaping IP addresse spaces attached to the same GTP-U entity (needed for multi APN support). Pablo found a socket hold problem in v2. In order to solve that I had to switch the socket references from the struct socket to the internal struct sock. This should have no functionl impact, but we can now hang on to the reference without blocking user space from closing the GTP socket. There was also some length off-list conversation about why the netdevice to socket relation needs to be changed at all. Harald did already agree to this but Pablo had some questions. I've tried to address that with a bit of dokumentation for the GTP module. Hopefully this will explain the need for the change sufficiently. This series does have conflicts with the SGSN side tunnel work done by Jonas Bonn. The unification of the tunnel Rx code touches the same places he changed. v2->v3: * add documentation to explain the goal of all these changes * incorporate review comments * switch from struct socket to struct sock Regards Andreas -- Andreas Schultz (8): gtp: add documentation gtp: switch from struct socket to struct sock for the GTP sockets gtp: make GTP sockets in gtp_newlink optional gtp: merge gtp_get_net and gtp_genl_find_dev gtp: consolidate gtp socket rx path gtp: unify genl_find_pdp and prepare for per socket lookup gtp: consolidate pdp context destruction into helper gtp: add socket to pdp context Documentation/networking/gtp.txt | 112 ++++++++ drivers/net/gtp.c | 548 +++++++++++++++++++-------------------- 2 files changed, 386 insertions(+), 274 deletions(-) create mode 100644 Documentation/networking/gtp.txt -- 2.10.2

4 17

Roaming allowed for using local sims
by Saba Arshad 20 Feb '17

20 Feb '17

Hello, I want to use the local sims having different MNC/MCC for implementing GPRS using osmocoms with OpenBTS same as I have used them for GSM calls and sms using only openBTS. But your site http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS says, "it is currently not possible". As it is long when posted on this site so I want to ask is it possible *now* to use the local sims? Hope you have understood my question. Waiting for your reply. Thanks. Regards, Saba Arshad

2 1

osmocom Kernel GTPU module - Support for incoming DL packets for idle mode users in S-GW /SGSN
by Anoop Singh Tomar 19 Feb '17

19 Feb '17

Hi , Posting question related to capability to implement user plane (GTP tunnel) for S1-U and Iu-PS interface between S-GW & eNB and SGSN & RNC respectively via osmocom kernel GTP-U module. At present it seems if TE-ID is not valid packet is dropped in kernel GTP-U module. So in order to use this for S1-U/Iu-PS interface it is required to add support for following use-case: * Down link packet arrival in S-GW /SGSN for UE which is in idle mode - Buffer the packet and trigger paging to move the UE to connected. a. When UE moves to idle mode - S1-U or IuPS bearer is released. In this case IP address and TE-ID of eNB/RNC becomes invalid. b. DL Packet is received for the idle mode UE in S-GW/SGSN - In this case , kernel GTP-U module should deliver packet to user-space application (SGW/osmoSGSN) so that these packets can be buffered in user space and paging can be initiated. Question - Is there any plan to support above in near-future in osmocom kernel GTP-U module or larger question would be to plan to enable usage of kernel GTP-U module in SGSN and SGW towards RAN ? Thanks, Anoop

3 2

Re: [PATCH 1/1] gtp: support SGSN-side tunnels
by Harald Welte 13 Feb '17

13 Feb '17

Hi Andreas, Pablo, Jonas, I think that the SGSN/GGSN role flag (or whatever it may end up being called) logically belongs in the gtp-device at this point, and will in the future belong to the UDP/GTP-socket (with Andreas' proposed changes). Having it per-pdp-context indeed seems odd and just provide a way to create broken configurations (and increase the memory use per pdp context, of which you have many more than netdevs or gtp-sockets). -- - 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)

1 0

tbf test segfault
by Max 12 Jan '17

12 Jan '17

Hi. The current OsmoPCU master has segfault in tbf test - at least on my machine: Destroying MS object, TLLI = 0x00000000 === start test_tbf_dl_llc_loss === Assert failed !check_element_exists(cnode, cmd->string) command.c:626 backtrace() returned 9 addresses /usr/lib/x86_64-linux-gnu/libosmovty.so.3(install_element+0xce) [0x7ffff77a5f9e] /usr/lib/x86_64-linux-gnu/libosmovty.so.3(install_element_ve+0x11) [0x7ffff77a6411] /usr/lib/x86_64-linux-gnu/libosmogb.so.4(gprs_ns_vty_init+0x17) [0x7ffff79c1da7] /home/max/source/gsm/osmo-pcu/tests/tbf/TbfTest(+0x22640) [0x555555576640] /home/max/source/gsm/osmo-pcu/tests/tbf/TbfTest(+0x1a73a) [0x55555556e73a] /home/max/source/gsm/osmo-pcu/tests/tbf/TbfTest(+0x1697f) [0x55555556a97f] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7ffff67e53f1] /home/max/source/gsm/osmo-pcu/tests/tbf/TbfTest(+0x16eda) [0x55555556aeda] Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58 58 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58 #1 0x00007ffff67fc3ea in __GI_abort () at abort.c:89 #2 0x00007ffff77a5fa3 in cmd_make_descvec (descstr=<optimized out>, string=<optimized out>) at command.c:327 #3 install_element (ntype=ntype@entry=1, cmd=cmd@entry=0x7ffff7bcf680 <show_ns_cmd>) at command.c:630 #4 0x00007ffff77a6411 in install_element_ve (cmd=cmd@entry=0x7ffff7bcf680 <show_ns_cmd>) at command.c:637 #5 0x00007ffff79c1da7 in gprs_ns_vty_init (nsi=<optimized out>) at gprs_ns_vty.c:578 #6 0x0000555555576640 in gprs_bssgp_create_and_connect (bts=<optimized out>, local_port=<optimized out>, sgsn_ip=<optimized out>, sgsn_port=<optimized out>, nsei=<optimized out>, nsvci=<optimized out>, bvci=1234, mcc=1, mnc=1, lac=0, rac=0, cell_id=0) at gprs_bssgp_pcu.cpp:847 #7 0x000055555556e73a in test_tbf_dl_llc_loss () at tbf/TbfTest.cpp:499 #8 0x000055555556a97f in main (argc=<optimized out>, argv=<optimized out>) at tbf/TbfTest.cpp:2883 Which also seems to be reproducible in jenkins: http://jenkins.osmocom.org/jenkins/job/osmo-pcu-gerrit/477/label=linux_amd6… That's odd cause it should have been caught by jenkins way before. Anyone else seeing this? -- Max Suraev <msuraev(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

2 3

← Newer
1
...
28
29
30
31
32
33
34
...
52
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs