From: "Miguel Alejandro González" <maggonzz@gmail.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: conntrack tuple
Date: Sat, 15 Sep 2012 19:08:48 -0500 [thread overview]
Message-ID: <CA+Z0r8OwQzXax9oT2hpsfmKHVHaBLE5iqD5qHJmpdcMBCTiU2g@mail.gmail.com> (raw)
In-Reply-To: <20120915211450.GA11216@1984>
So,
I have this code, I got it from the Writing netfilter code ebook:
const struct nf_conn *ct;
const struct nf_conntrack_tuple *t;
enum ip_conntrack_info ctinfo;
enum ip_conntrack_dir dir;
ct = nf_ct_get(skb, &ctinfo);
if (ct != NULL && (ctinfo == IP_CT_NEW || ctinfo == IP_CT_RELATED))
return false;
dir = CTINFO2DIR(ctinfo);
t = &ct->tuplehash[dir].tuple;
Assuming there was already an established UDP or TCP connection that
passed by conntrack. And with what you told me, conntrack should get a
tuple with the inner headers upon receiving a Destination unreachable
error message with an inner packet. I'm testing this code and I get a
ICMP tuple with 771 as id, is this ok? I think I should be getting a
UDP or TCP tuple with the l4 headers from the inner packet...
I'm using kernel 2.6.38, I think you guys changed the tuple to have
type and code instead of id in later versions.... maybe I should use
the latest version...
In my module I have the function need_ipv4_conntrack() in the init
function, I think this is enough to load conntrack.
Regards!
On Sat, Sep 15, 2012 at 4:14 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> Hi,
>
> On Fri, Sep 14, 2012 at 09:57:36AM -0500, Miguel Alejandro González wrote:
>> Hello
>>
>> I have some questions about how conntrack tuple handles ICMP error messages...
>>
>> When a ICMP error packet arrives containing an embedded UDP or TCP
>> packet, assuming there was already a UDP or TCP connection being
>> tracked by conntrack, what are the IP addresses of the tuple, the ones
>> from the ICMP error message or the ones from the embedded packet?
>
> It uses inner headers of the ICMP error message, ie. "the ones from
> the embedded packet".
>
> See net/ipv4/netfilter/nf_conntrack_proto_icmp.c
>
>> Also does the tuple saves port information in this case as well as icmp
>> type and code?
>
> Conntrack does not save any ICMP error information.
>
>> How does conntrack know that ICMP error message is related to an
>> existing connection?
>
> The conntrack code looks up for some existing entry by using the
> information in the inner headers of the ICMP error message.
>
> If no entry is found, the packet is considered invalid, and you can
> drop it with iptables ... -m state --state INVALID
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2012-09-16 0:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-14 14:57 conntrack tuple Miguel Alejandro González
2012-09-15 21:14 ` Pablo Neira Ayuso
2012-09-16 0:08 ` Miguel Alejandro González [this message]
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=CA+Z0r8OwQzXax9oT2hpsfmKHVHaBLE5iqD5qHJmpdcMBCTiU2g@mail.gmail.com \
--to=maggonzz@gmail.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).