osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

2 participants
516 discussions

Load balancing issue on Multi-TRX configuration
by Mrinal Mishra 20 Oct '16

20 Oct '16

Hello All, We are testing GPRS/EGPRS functionality in Multi-TRX(2 TRX) configuration for 2MS and we observed that both the MS are always assigned resources in TRX0. It seems like there is no load balancing done Across the TRXs. Similar issue "Bug #1775 LC15: No PDCH allocation across two TRX" is raised on Multi-TRX and its status is "In Progress". Please let us know if any updates on this issue. Thanks and Regards, Mrinal

1 0

OpenGGSN IPv6 support
by groos＠xiplink.com 11 Oct '16

11 Oct '16

Hi All I have added IPv6 support to OpenGGSN and if anybody is interested I will gladly make my patch available. It definitely needs more testing and perhaps a bit of cleanup, but currently it can do 4-in-4, 6-in-4, 4-in-6 and 6-in-6. Gerrie

3 2

[libgtpnl]add README.md file for build guide
by junpei yoshino 07 Oct '16

07 Oct '16

Hello I write build guide. README.md | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 README.md diff --git a/README.md b/README.md new file mode 100644 index 0000000..c6718d2 --- /dev/null +++ b/README.md @@ -0,0 +1,11 @@ +# How to build + +``` +$ git clone git://git.osmocom.org/libgtpnl +$ cd libgtpnl +$ autoreconf -fi +$ cd tools +$ make gtp-tunnel +$ make gtp-link +``` + Best Regards, Junpei Yoshino -- junpei.yoshino(a)gmail.com

3 8

OpenGGSN on live networks
by Bjørn Remseth 06 Oct '16

06 Oct '16

Hi I’m Bjørn, I work for Telenor Digital. We’re running a live experimental network (called “loltel” :-) that is technically operating as a full stack MVNO (mobile virtual network operator), renting network access from Telenor Norway. It’s mostly but not exclusively based on open source components. When we started up about two years ago we considered using OpenGGSN, but couldn’t figure out how to get it into an operational state and we couldn’t find anyone to help us, so we chose a commercial vendor instead. But today we’re again thinking of using OpenGGSN for an experiment, possibly in our live network. Are there anyone on this list with experiences either with running it in a live network, or with thoughts about how to do it / what would be necessary to get the job done? We’d love to have a discussion with you. Hope to hear from you soon. Best wishes Bjørn -- Bjørn Remseth --- Senior Software Engineer (+47) 47900184 | rmz(a)comoyo.com <mailto:ane@comoyo.com> | www.comoyo.com <http://www.comoyo.com/>

3 6

openggsn patches now via gerrit
by Neels Hofmeyr 06 Oct '16

06 Oct '16

Hi all, OpenGGSN has moved to gerrit today. Patch submissions shall go there now, no longer to this mailing list. ~Neels -- - Neels Hofmeyr <nhofmeyr(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 * Geschäftsführer / Managing Directors: Harald Welte

1 0

Installation error
by Ashish Kurian 06 Oct '16

06 Oct '16

Hi All, I downloaded the tar ball release libgtpnl-1.0.1.tar.gz and un tared it. Then I tried to build and install the package. But the command sudo ./configure is giving me the following error. configure: error: cannot find install-sh, install.sh, or shtool in build-aux "."/build-aux Do you know what could be the reason for this error? Best Regards, Ashish Kurian

2 1

Re: Dropping packet from invalid source address
by Holger Freyther 06 Oct '16

06 Oct '16

> On 06 Oct 2016, at 09:01, Peter Lithner <plithner(a)yahoo.com> wrote: > > Hello Holger, > > I can see packets now, after creating a PDP and running tcpdump on tun0. However, the ICMP requests I send are not GTP encapsulated as I would have expected, and I can only see the "downlink" data (the ping requests, and not the replies). The ping is successful though, so the replies are sent some way. Let's say tun1 is the SGSN emu device and you have a ICMP Request in it. The kernel will tell the sgsnemu process that new data is present and the sgsnemu will then wrap the data with GTP-u and send it to the GGSN. So you should be able to see the wrapped data on the loopback device. > And like I mentioned before, I can not force delays in packet delivery by temporarily pausing the GGSN with ctrl-z. > > What I did was, exactly what you proposed. I used your config, and you command lines (with the only exception that I created to virtual interfaces instead of using 127.0.0.1 and 127.0.0.2. I tried that as well though, and behaviour was the same. > > One thing that looks a bit odd, is that when I run tcpdump on tun0 (ggsn tun interface) and run ping, I can only see the "downlink" packets. That is to say, I only see the Ping requests and not the responses. The attachment shows this. > The setup once again: > Ubuntu 16.04.01 > ggsn installed with apt-get > ggsn.cfg: > root@ip-10-7-0-240:/home/ubuntu# cat ggsn.conf > listen 192.168.1.2 > logfile /tmp/foo > loglevel DEBUG > net 10.10.10.1/24 > pcodns1 8.8.8.8 > > ggsn command line: > ggsn -c ggsn.conf -f > > sgsnemu command line: > sgsnemu --listen 192.168.1.3 --remote 192.168.1.2 --apn internet --createif > > capture: > tcpdump -i tun0 -w tun0.pcap > ping: > ping -I tun1 10.10.10.1 > So if you trace on eth0 as well you should see ICMP Echo req and GTP+U ICMP echo req. As you trace on tun0 the GGSN has received GTP-u and wrote it into tun0. Now the kernel decides not to respond. E.g. maybe your cloud image has some kind of firewall, you could try to disable the rp_filter on tun0, etc.

2 2

Re: Dropping packet from invalid source address
by Holger Freyther 05 Oct '16

05 Oct '16

> On 05 Oct 2016, at 18:01, Peter Lithner <plithner(a)yahoo.com> wrote: > >> Dear Peter, > Peter: Did you mean ggsn on 127.0.0.2 and client on 127.0.0.1? yes. > >> While sgsnemu is running a new interface will be created (e.g. tun1 due the --createif route). Can you check >which netmask is being set there? E.g. tun_addroute is called by the sgsnemu and it might capture more than >you wanted? And in that case filter on tcpdump -i tun1 as well. > > Peter: The thing is, that I do not see any tun1 interface (only the ton0 which is created when i start ggsn). This was what I meant in my original post. > > Anyway, I used your config, and in the log file I see this: > <0002> ggsn.c:283 Set file log level to DEBUG > <0002> ggsn.c:492 gtpclient: Initialising GTP tunnel > <000c> gtp.c:700 GTP: gtp_newgsn() started > <000c> gtp.c:661 State information file (/var/lib/ggsn/gsn_restart) not found. Creating new file. > <000c> gtp.c:682 fopen(path=/var/lib/ggsn/gsn_restart, mode=w) failed: Error = No such file or directory > <0002> ggsn.c:510 Creating tun interface > <0002> ggsn.c:516 Setting tun IP address > > I'm probably just missing some stupid/obvious thing in my setup... with tcpdumo you should really see this packet and what kind of message it is. I just tried the following in Debian 8.0 VM with the config I had posted: GGSN: sudo ./ggsn/ggsn -c ./../../ggsn.conf -f SGSN: sudo ./sgsnemu/sgsnemu -l 127.0.0.1 -r 127.0.0.2 -a "foo" --createif Using default DNS server Local IP address is: 127.0.0.1 (127.0.0.1) Remote IP address is: 127.0.0.2 (127.0.0.2) IMSI is: 240010123456789 (0xf987654321010042) Using NSAPI: 0 Using GTP version: 1 Using APN: foo Using selection mode: 1 Using MSISDN: 46702123456 Initialising GTP library <000c> gtp.c:701 GTP: gtp_newgsn() started Setting up interface Done initialising GTP library Sending off echo request Setting up PDP context #0 Waiting for response from ggsn........ Received echo response Received create PDP context response. IP address: 10.23.42.2 After network config: tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.23.42.1 P-t-P:10.23.42.1 Mask:255.255.255.0 UP POINTOPOINT RUNNING MTU:1500 Metric:1 RX packets:3 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:252 (252.0 B) TX bytes:0 (0.0 B) tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.23.42.2 P-t-P:10.23.42.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 B) TX bytes:252 (252.0 B) So tun0 has been allocated by the GGSN and tun1 by the SGSN ping -I tun1 10.23.42.1 PING 10.23.42.1 (10.23.42.1) from 10.23.42.2 tun1: 56(84) bytes of data. 64 bytes from 10.23.42.1: icmp_seq=1 ttl=64 time=0.223 ms 64 bytes from 10.23.42.1: icmp_seq=2 ttl=64 time=0.132 ms 64 bytes from 10.23.42.1: icmp_seq=3 ttl=64 time=0.134 ms 64 bytes from 10.23.42.1: icmp_seq=4 ttl=64 time=0.123 ms 64 bytes from 10.23.42.1: icmp_seq=5 ttl=64 time=8914 ms (I used CTRL+Z on the ggsn to see that there are actually delays). Can you try to repeat that? holger

1 0

Dropping packet from invalid source address
by Peter Lithner 05 Oct '16

05 Oct '16

Hi I'm trying out openGGSN, currently running it on an Ubuntu 16.04 VM in Amazon. The reason I'm doing this is part of an evaluation I'm helping out with for a customer in the Telco-industry. I have been able to install, and run ggsn and sgsnemu to the point of sending the ECHO and creating the PDP-C (see attachment). However, I can't see that a network interface is created after the PDP-C has been accepted. According to the README on https://github.com/osmobuntu/openggsn that should happen: "After this it will attempt to establish a pdp context. If successful it will create a local interface and set up routing." Anyway, I have probably missed something in the setup. If you have any suggestions, that would be highly appreciated! What I did so far is: Install sudo apt-get update sudo apt-get install openggsn Create "virtual" interfaces (since I'm running everything on the same machine. Not sure if this is the right way to do it though) ifconfig eth0:0 192.168.1.2 netmask 255.255.255.0 up ifconfig eth0:1 192.168.1.3 netmask 255.255.255.0 up I also did the following steps, but I'm not sure exactly what they do... pardon my ignorance! 1. Add the following line to /etc/modules.conf: alias char-major-10-200 tun 2. depmod -a Start GGSN ggsn -c ggsn.conf --fg -l 192.168.1.2 --net 192.168.0.0/24 --dynip 192.168.0.0/24 After this I can see the new tun0 tun0: flags=81<UP,POINTOPOINT,RUNNING> mtu 1500 inet 192.168.0.1 netmask 255.255.255.0 destination 192.168.0.1 inet6 fe80::9ea3:6876:c4ce:fc96 prefixlen 64 scopeid 0x20<link> unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 7 bytes 448 (448.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 send ECHO (successfully) sgsnemu --listen 192.168.1.3 --remote 192.168.1.2 --dns 10.20.38.51 --timelimit 10 --contexts 0 Send ECHO + Create PDP-C sgsnemu --listen 192.168.1.3 --remote 192.168.1.2 --dns 10.20.38.51 --timelimit 10 --contexts 1 --apn internet --imsi 240011234567890 --msisdn 46702123456 --createif --defaultroute Which outputs the following: Using DNS server: 10.20.38.51 (10.20.38.51) Local IP address is: 192.168.1.3 (192.168.1.3) Remote IP address is: 192.168.1.2 (192.168.1.2) IMSI is: 240011234567890 (0xf098765432110042) Using NSAPI: 0 Using GTP version: 1 Using APN: internet Using selection mode: 1 Using MSISDN: 46702123456 Initialising GTP library <000c> gtp.c:700 GTP: gtp_newgsn() started After printing this line, sgsnemu stays very silent for 30-ish seconds, after which it prints (all in one go): Setting up interface Done initialising GTP library Sending off echo request Setting up PDP context #0 Waiting for response from ggsn........ Received echo response Received create PDP context response. IP address: 192.168.0.2 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 10.7.0.240 Disconnecting PDP context #0 Received delete PDP context response. Cause value: 128 Where 10.7.0.240 is the ip address of eth0 Once again, if you have any suggestions, I'm all ears! Thanks in advance! /peter

2 1

[PATCH 0/2] OpenGGSN fixes for gsn_restart file path composition
by Neels Hofmeyr 05 Oct '16

05 Oct '16

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

3 6

← Newer
1
...
30
31
32
33
34
35
36
...
52
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs