> 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