osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

2 participants
516 discussions

osmo-pcu build failures on Debian 8.0
by Harald Welte 06 Jun '18

06 Jun '18

For quite some time, osmo-pcu has been causing build failures on Debian 8. You can find a build log e.g. at https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o… The visible sign is that for some reasson there are additional log lines present in the output of our unit tests, like: [ 127s] TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) downlink acknowledge [ 127s] TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) Final ACK received. [ 127s] +DL packet loss of IMSI= / TLLI=0xffeeddcc: 0% [ 127s] TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) changes state from FLOW to WAIT RELEASE [ 127s] TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=WAIT RELEASE EGPRS) starting timer T3193 [release (DL-TBF)] with 0 sec. 0 microsec, cur_fn=0 where the "+" is the unexpected additional line. Does anyone have any information about why that is? I don't see any related changes recently. -- - 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

GTP-U support for a UE with multiple bearers (LTE)
by Shashank Prasad 18 Apr '18

18 Apr '18

Hi, I just started exploring the GTP-U module (maintained in the kernel) for LTE. In LTE, a UE can be associated with multiple bearers. This implies that an MS IP address can be associated with multiple TEIDs (one for each bearer). Based on browsing the kernel GTP implementation[1], it looks like the GTP-U (maintained in the kernel) can only support 1 TEID per MS IP address. In which case, the GTP implementation, as is, may NOT be usable by LTE modules. Is this a correct interpretation? - Shashank [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/dr…

2 1

GTP-U support for a UE with multiple bearers
by Shashank Prasad 17 Apr '18

17 Apr '18

Hi, I just started exploring the GTP-U module (maintained in the kernel) for LTE scenarios. In LTE, a UE can be associated with multiple bearers. This implies that an MS IP address can be associated with multiple TEIDs (one for each bearer). Based on browsing the kernel GTP implementation[1], it looks like the GTP-U (maintained in the kernel) can only support 1 TEID per MS IP address. In which case, the GTP implementation, as is, may NOT be usable by LTE modules. Is it an correct interpretation? - Shashank [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/dr…

1 0

Save the Date: OsmoCon 2018 on October 18-19, 2018
by Harald Welte 11 Apr '18

11 Apr '18

== OsmoCon 2018 == OsmoCon (Osmocom Conference) 2018 is the technical conference for Osmocom users, operators and developers! We are happy to announce the date of OsmoCon 2018. It has been scheduled on October 18 + 19, 2018 and will happen in Berlin, Germany. For the second time, the Osmocom Conference brings together users, operators and developers of the Osmocom Open Source cellular infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN and others. Join us for two days of presentations and discussions with the main developers behind Open Source Mobile Communications, as well as commercial and non-profit users of the Osmocom cellular infrastructure software. You can find some initial information in our wiki at http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018 which will be updated as more information becomes available. == Call for Participation == We're also at the same time announcing the Call for Participation and call on everyone with experiences to share around the Osmocom member projects to submit talks, workshops, discussions or other proposals. You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp We are particularly looking for contributions about: * updates on features/functionality/status of individual Osmocom projects * success stories on how Osmocom projects are deployed in practice * migration from OsmoNITB to the post-NITB architecture * tutorials / workshops on how to setup / analyze Osmocom projects * statistics, reporting, operations aspects of Osmocom projects * third-party open source utilities to be used with Osmocom projects Looking forward to meeting many existing and new Osmocom users at OsmCon this October! Regards, Harald Welte -- - 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

Data throughput issues. Increasing throughput.
by Dave Ellis 05 Apr '18

05 Apr '18

Hi, I need to increase the throughput through the GTP tunnels to around 9Gb/s. I have two servers and they are connected using two GTP tunnels over a Mellanox 25Gb/s link. Via the tunnels I am seeing a total of 4.2 Gb/s to 4.5 Gb/s using iPerf. If data is sent without the tunnels I see a throughput of around 24.5Gb/s. I have tried various tweaks to improve the throughput over the GTP tunnels and have only made marginal gains. I have tried iPerf 2.0.9 and iPerf3 and see the same results. Wireshark shows the iPerf MTU is reflected in the pcap logs. I have tried changing the txqueuelen on the tunnels, changing osmo-ggsn niceness, network buffer sizes etc. The restriction seems to be osmo-ggsn as that is taking up to 92% CPU on one of the cores when the throughput tests are running. I'm hoping I have made a mistake in the configuration of OsmoGGSN and sgsnemu. -- The servers are running Ubuntu 16.04 desktop. 16GB RAM - 12.6GB free when running throughput tests. Intel E52620v3. Mellanox MCX516A-CCAT network adapter. 25Gb direct attach copper connecting the two servers OsmoGGSN version 1.1.0.75-3e44-dirty. For one of the servers: - Mellanox interface details ens3f0 Link encap:Ethernet HWaddr ec:0d:9a:a0:1d:7c inet addr:172.16.8.1 Bcast:172.16.255.255 Mask:255.255.0.0 inet6 addr: fe80::8f38:33e3:bd46:dd65/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:142373677 errors:0 dropped:0 overruns:0 frame:0 TX packets:157500406 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10000 RX bytes:793825609487 (793.8 GB) TX bytes:879898325287 (879.8 GB) Tunnel interface details S1Utun Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.1.1.2 P-t-P:10.1.1.2 Mask:255.255.255.0 inet6 addr: fe80::b3fc:3d43:b751:bcbf/64 Scope:Link UP POINTOPOINT RUNNING MTU:9000 Metric:1 RX packets:4640412 errors:0 dropped:0 overruns:0 frame:0 TX packets:2272797 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:37729672063 (37.7 GB) TX bytes:118866016 (118.8 MB) X2Utun Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.1.2.2 P-t-P:10.1.2.2 Mask:255.255.255.0 inet6 addr: fe80::6ed8:8a79:b3e9:a51d/64 Scope:Link UP POINTOPOINT RUNNING MTU:9000 Metric:1 RX packets:1824011 errors:0 dropped:0 overruns:0 frame:0 TX packets:3856238 errors:0 dropped:4229 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:95648485 (95.6 MB) TX bytes:31367266755 (31.3 GB) client side iperf server1 iperf3 -c 10.1.2.1 -i1 -t 30 -M8100 -w 2048K -P8 server2 iperf3 -c 10.1.2.1 -i1 -t 30 -M8100 -w 2048K -P8 server1 and 2 iperf server iperf3 -s -i1 osmo-ggsn -c /home/osmo-ggsn.cfg -g 172.16.1.1 contents of osmo-ggsn.cfg ! ! OpenGGSN (0.94.1-adac) configuration saved from vty !! ! log stderr logging filter all 1 logging color 1 logging print category 0 logging timestamp 0 logging level ip info logging level tun info logging level ggsn info logging level sgsn notice logging level icmp6 notice logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp info logging level lstats notice logging level lgsup notice logging level loap notice logging level lss7 notice logging level lsccp notice logging level lsua notice logging level lm3ua notice logging level lmgcp notice ! stats interval 5 ! line vty no login ! ggsn X2Uggsn gtp state-dir /tmp gtp bind-ip 172.16.8.1 gtp gtp0-port 3386 gtp gtp1c-port 2123 gtp gtp1u-port 2153 gtp gtp1uremot-port 2153 apn X2U gtpu-mode tun tun-device X2Utun type-support v4 ip prefix dynamic 10.1.2.0/24 ip dns 0 192.168.100.1 ip dns 1 8.8.8.8 ip ifconfig 10.1.2.2/24 no shutdown default-apn X2U no shutdown ggsn ggsn S1Uggsn gtp state-dir /tmp gtp bind-ip 172.16.8.1 gtp gtp0-port 3387 gtp gtp1c-port 2124 gtp gtp1u-port 2152 gtp gtp1uremot-port 2152 apn S1U gtpu-mode tun tun-device S1Utun type-support v4 ip prefix dynamic 10.1.1.0/24 ip dns 0 192.168.100.1 ip dns 1 8.8.8.8 ip ifconfig 10.1.1.2/24 no shutdown default-apn S1U no shutdown ggsn sgsnemu -l 127.0.0.2 -r 172.16.8.1 --contexts 1 -a S1U -m 4412345678 -q 0x00000000000b921f --defaultroute --pingcount 0 --gtpteid=8 --gtpversion=1 --gsnuip 172.16.1.1 --enduserip 10.1.1.1 --gtp0port 3387 --gtp1cport 2124 --nsapi 1 sgsnemu -l 127.0.0.3 -r 172.16.8.1 --contexts 1 -a X2U -m 4412345678 -q 0x00000000000b921f --defaultroute --pingcount 0 --gtpteid=3 --gtpversion=1 --gsnuip 172.16.1.1 --enduserip 10.1.2.1 --gtp0port 3386 --gtp1cport 2123 --nsapi 2 Hopefully I have provided enough information. Any ideas on how to increase tunnel throughput? Thanks Dave

3 3

Interfering with the GTP-u Kernel module
by Thomas Boros 16 Feb '18

16 Feb '18

Hello, I would like to implement a command line tool, which will be able to open / close , read / write to gtp tunnels. I was able to install the libgtpnl library, but due to lack of documentation I have no idea where to start. Is there some sort of documentation available for this library? I need to be able to create and delete tunnels without the GTP-C communication, so just basic command line tool like create-gtp-tunnel + arguments like IPs, version and teid. The GTP-U tunnels must be kernel based. I have the latest kernel with the gtp kernel module loaded. Any help is appreciated. Thank you, Tomas

2 4

Problem when building OsmoSGSN
by XINKE ZHANG 16 Feb '18

16 Feb '18

Hi all, I built OsmoSGSN with the these following instructions. <build instructions> git clone git://git.osmocom.org/osmo-sgsn cd osmo-sgsn autoreconf -fi ./configure --enable-iu make -j5 make check make install sudo ldconfig <build instructions> And no error came out during building process, but no “osmo-sgsn” executable was found. Pls help me. Thank you in advance. Best Regards, Xinke

4 11

sgsnemu: no outgoing GTP-U in "createif" mode
by Viktor Tsymbalyuk 09 Feb '18

09 Feb '18

Hello, I tried to run sgsnemu in "createif" mode - transfer traffic via tun interface. tun interface created and routing too. But there are no outgoing GTP-U from test machine. (in my scenario sgsnemu on separated server). From gdb it looks, that in cb_tun_ind function ipm->pdp is 0x0, as result gtp_data_req(gsn, ipm->pdp, pack, len); not running. After changes like below, it's start working. Does I correctly understood internal logic? diff --git a/sgsnemu/sgsnemu.c b/sgsnemu/sgsnemu.c index 630733b..cf4aa44 100644 --- a/sgsnemu/sgsnemu.c +++ b/sgsnemu/sgsnemu.c @@ -1462,7 +1462,7 @@ static int create_pdp_conf(struct pdp_t *pdp, void *cbp, int cause) free(forwarding); } - ipset((struct iphash_t *)pdp->peer, &addr); + ipset(iph, &addr); state = 2; /* Connected */ If need more test details, please let me know. -- Viktor

2 1

GPRS trafic in PCU - type BVC-UNBLOCK unknown // Protocol error - unspecified
by Osmocom Mailing List 06 Feb '18

06 Feb '18

Hi, I'm trying to run GPRS in my network. So far I get flooded with the bellow trafic in the PCU and the GGNS doesn't appear to receive any traffic. <000c> gprs_bssgp_bss.c:294 BSSGP (BVCI=2) Tx BVC-RESET CAUSE=O&M intervention <000c> gprs_bssgp.c:551 BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified <000c> gprs_bssgp_pcu.cpp:348 Rx BSSGP BVCI=0 (SIGN) PDU type BVC-UNBLOCK unknown <000c> gprs_bssgp_util.c:238 BSSGP BVCI=0 Tx STATUS, cause=Protocol error - unspecified <000c> gprs_bssgp_pcu.cpp:298 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK <000c> gprs_bssgp_pcu.cpp:835 Sending unblock on BVCI 2 <000c> gprs_bssgp_bss.c:274 BSSGP (BVCI=2) Tx BVC-BLOCK <000c> gprs_bssgp.c:289 Cell 1-1-1-0 CI 0 on BVCI 2 Thanks, Filipe Laíns <https://github.com/FFY00> Sent via Migadu.com, world's easiest email hosting

2 1

Fwd: icmp encapsulation
by fırat sönmez 01 Feb '18

01 Feb '18

---------- Forwarded message ---------- From: fırat sönmez <firatssonmez(a)gmail.com> Date: 2018-02-01 15:51 GMT+03:00 Subject: Re: icmp encapsulation To: Pau Espin Pedrol <pespin(a)sysmocom.de> Hi Pau, Thank you for your response. You are right, I should have told the configuration in more detail. However, you came to the point already. I am talking about the second case where there is NAT. There is a slight difference though. After the NAT two IP (IP1 and IP2) will be IPnat, but the NAT maps the IP1 and IP2 to the port range. Since, there is no port in ICMP, both IP1 and IP2 will be go to uplink as IPg and but on the return there must be problem for NAT machine to traverse the two different paths from IPnat to IP1 and IPnat to IP2. I looked into the ICMP header and observed the packets have different identifiers. So, NAT machine must be using the identifies to reverse the packets. Anyways, in my case the *IP1=IP2* (In my experimental architecture, the GGSN will not be assigning distinct IP for each host. Instead, GGSN will assign 1 IP address for 32 hosts (seems like NAT). My configuration is probably out of standard architectures, but I need to understand how would gtp handle matching these two pdp contexts. I have tried this configuration, pinging from two different host with same IP and it was successful! Two packets coming from the server to the GGSN will be *[src:IPs | dst:IP1]* and *[src:IPs | dst:IP2]* IP1=IP2, but two packets have different icmp identifier. And pdp contexts are still resolved successfully. so a big HOW in my mind? Fırat 2018-02-01 13:46 GMT+03:00 Pau Espin Pedrol <pespin(a)sysmocom.de>: > Hi firat, > > I didn't understand fully the configuration you are describing. Something > like this? > > Host1 --SGSN1--\GGSN--Server > Host2 --SGSN2--/ > > Where Host1 has been assigned IP1 and Host2 has been assigned IP2, both > assigned by GGSN where IP1 != IP2. Let's assume the server IP is IPs and > the GGSN public uplink (non-GTP) IP is IPg. > > As far as I understand, it works as follow: > > - Case without NAT between GGSN and Server: > Host1 sends ICMP packet with saddr=IP1 daddr=IPs, which gets encapsulated > through GTP and GGSN decapsulates it. Same for Host2 but in this case the > packet will have saddr=IP2. As there's no NAT (eg. host clients are > assigned a public IP), the server receives 2 ICMP packets with different > saddr, and when answering back using the original saddr now as daddr. As > GGSN keeps track of the saddr assigned to each pdp context, when it > receives a packet from the uplink (non-GTP side), it matches the daddr of > the packet against the saddr of the active pdp ctx to find to which pdp ctx > should forward the packet. > > - Case with NAT between GGSN and Server: > Almost the same but with extra steps done by the NAT. When the GGSN sends > the packet saddr=IP1 daddr=IPs to the server, the NAT changes > saddr=IP1->IPg. It does the same for saddr=IP2, but the NAT keeps track of > the binding. When the response is received from the server, the NAT > converts back IPg->IP1 and GGSN can again track the pdp ctx as described in > the previous case. > > -- > - 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 >

2 1

← Newer
1
...
23
24
25
26
27
28
29
...
52
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs