From: Patrick McHardy <kaber@trash.net>
To: Gopalakrishnan Raman <gopal@rgopal.com>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: tcpdump confused with NAT-T+IPSec Packets
Date: Mon, 22 Aug 2005 02:31:08 +0200 [thread overview]
Message-ID: <43091CCC.80906@trash.net> (raw)
In-Reply-To: <20050821165608.A9993@portal.rgopal.com>
[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]
Gopalakrishnan Raman wrote:
> Hi
> I'm using 2.6.11.7 and debugging why my ESP tunnel mode does
> not work between two 2.6 machines one of which is behind a NAT.
> I'm using tcpdump to capture NAT-T packets on one of the hosts
> and using espdecrypt (http://www.cs.rpi.edu/~flemej/freebsd/espdecrypt/)
> to see it in the clear.
>
> Turns out, tcpdump will display an incoming NAT-T packet after it
> has been mangled by udp_encap_rcv(). udp_encap_rcv() changes the
> protocol field in the IP hdr to ESP from UDP and also moves other
> bytes in the sk_buff data area.
>
> The problem is that packet_rcv() calls skb_clone() which is the
> right thing to do in all cases except when the data portion of the
> incoming skb is being modified in place. I replaced it with a pskb_copy()
> in the case when the packet is likely to be NAT-T or ESP. The patch
> for this follows the end of this mail and seems to work quite well.
>
> Note that af_packet.c is the right place for the ESP/NAT-T check.
> Can't do it in ESP or UDP code because we can't tell if these packets
> are also being captured by tcpdump/ethereal.
Herbert already fixed it with this patch.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1114 bytes --]
[IPSEC]: COW skb header in UDP decap
The following patch just makes the header part of the skb writeable.
This is needed since we modify the IP headers just a few lines below.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
commit 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9
tree e04f156e8d74c28b925bf53e62d3e4b424a6ffb7
parent c7f905f0f6d49ed8c1aa4566c31f0383a0ba0c9d
author Herbert Xu <herbert@gondor.apana.org.au> Tue, 19 Apr 2005 22:48:59 -0700
committer David S. Miller <davem@davemloft.net> Tue, 19 Apr 2005 22:48:59 -0700
net/ipv4/udp.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -955,6 +955,8 @@ static int udp_encap_rcv(struct sock * s
* header and optional ESP marker bytes) and then modify the
* protocol to ESP, and then call into the transform receiver.
*/
+ if (skb_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
+ return 0;
/* Now we can update and verify the packet length... */
iph = skb->nh.iph;
next prev parent reply other threads:[~2005-08-22 23:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-21 23:56 tcpdump confused with NAT-T+IPSec Packets Gopalakrishnan Raman
2005-08-22 0:31 ` Patrick McHardy [this message]
2005-08-22 3:22 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43091CCC.80906@trash.net \
--to=kaber@trash.net \
--cc=gopal@rgopal.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.