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
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,
Aravind Sirsikar
Hello All,
We have executed profiling test of two versions of algorithm for decoding compressed bitmap of EPDAN.
>From the results , we see that performance is better in Tree based decoding (Version2 as given below )
Version 1: Bitmap based decoding as present in current master branch ( Function name osmo_t4_decode )
Version 2: Tree based decoding ( Function name decompress_crbb , as proposed in patch "Decompress the CRBB bitmap using tree based approach"<http://lists.osmocom.org/pipermail/osmocom-net-gprs/2016-March/000525.html> )
A sample bitmap taken from a real mobile log is used for the test.
Host execution: Time taken to decode (micro seconds)
Version 1: (Bitmap based decoding) : MIN -17 MAX -19 AVERAGE -17.9
Version 2 (tree based decoding): MIN -4 MAX -13 AVERAGE - 5.2
Target execution: Time taken to decode (micro seconds)
Version 1: (Bitmap based decoding) : MIN -277 MAX -583 AVERAGE - 353
Version 2 (tree based decoding): MIN -67 MAX -86 AVERAGE - 69.8
Regards
Prasad
Dear Developers,
I have a question for you. As you might be knowing. there is a patch now
available for OVS for GTP-U support. When the developers of the patch
submitted it to add to the main branch of OVS, the OVS developers told the
following.
It doesn't look like upstream Linux has a GTP implementation. Because
our usual workflow is to get code upstream first, you should start by
submitting the kernel patches against net-next when that tree is open (I
don't follow netdev, so I have no idea when that is). Then, once the
GTP code is upstream, we can get it into OVS here.
So, is the upstream Linux having support for GTP now? I am asking this
because I am not certain about what upstream Linux means. If you say that
upstream Linux has support for GTP-U, then I can ask the patch developers
to port it for the latest version of OVS and add it to the main branch.
Best Regards,
Ashish Kurian
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
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
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/>
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
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
> 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.
> 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
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