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