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.