Dropping packet from invalid source address

Holger Freyther holger at freyther.de
Thu Oct 6 07:07:55 UTC 2016


> On 06 Oct 2016, at 09:01, Peter Lithner <plithner at 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 at 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.





More information about the osmocom-net-gprs mailing list