linux-kernel - GRE keepalives, again

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 15 Sep 2008 00:49:15 +0200
From:	"Bosko Radivojevic" <bosko.radivojevic@...il.com>
To:	lkml <linux-kernel@...r.kernel.org>, linux-net@...r.kernel.org
Subject: GRE keepalives, again

Hi all

Ten days ago I asked if anyone has some info regarding Cisco's GRE
keepalive support. Later I've realized that idea behing that feature
is quite simple and nice. As it says on Cisco site:

> Router constructs the inner IP header and GRE header with a Protocol
> Type (PT) of 0. It then sends that packet out its tunnel interface, which
> results in the encapsulation of the packet with the outer IP header and a
> GRE header with PT = IP

Using the same idea, I've written small userspace app that do almost
the same - instead of constructing "inner" packet with GRE header, I'm
constructing UDP packet (it is easier to receive it in user space).
After all, that "keepalive" packet looks like - IP|GRE|IP|UDP. When
other end decapsulate it, inner IP|UDP packet should be sent back to
the originating end. So, my primary task to support GRE keepalives on
Linux side in Cisco-to-Linux "network" is accomplished. It's working
fine.

Problem is the other situation, when Cisco is sending keepalives, or
if a GRE tunnel is created between two Linux boxes and my app started
on any of them. Linux is not sending back the "inner" packet (when
"keepalive" packet is decapsulated on the other end, inner IP|UDP or
IP|GRE packet should be sent back to the originating end). Nor Cisco's
generated, nor generated by my app.

At the beginning I taught it has something with rp_filters or
something "adjustable" in /proc/sys/net/... But I was wrong. What
could be a reason for this behavior? I spent some time trying to debug
this, and it looks like inner packet never leave ip_gre code. It looks
like the journey of the packet ends in  ipgre_ecn_decapsulate() at the
very beginning:  if (INET_ECN_is_ce(iph->tos)) {

Does anyone have some hint for me? :)

Thanks!

PS. More info about GRE keepalive -
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a008048cffc.shtml#t6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/