From: fche@redhat.com (Frank Ch. Eigler)
To: =?KOI8-R?B?SWdvciAnTG8nICjpLkwuKQ==?= <bombsiteunrested@gmail.com>
Cc: netfilter-devel <netfilter-devel@vger.kernel.org>
Subject: Re: recommendations on implementing a custom Netfilter hook to QUEUE packets before their SEQ/ACK and size before fragmentation are known?
Date: Mon, 07 Mar 2011 18:52:00 -0500 [thread overview]
Message-ID: <y0maah61obj.fsf@fche.csb> (raw)
In-Reply-To: <AANLkTi=x_khzkObaG4F7PrVzbStd5c1OZMCE_oKHa35b@mail.gmail.com> (KOI8-R's message of "Wed, 2 Mar 2011 05:22:39 +0200")
Hi -
=?KOI8-R?B?SWdvciAnTG8nICjpLkwuKQ==?= <bombsiteunrested@gmail.com> writes:
> What I look for is reimplementing a part of NFQUEUE functionality at
> the stage where TCP packet is formed before sending to network.
I don't know what I'm talking about, but... :
Are you sure NFQUEUE gets involved in outgoing tcp fragmentation?
> It seems that NFQUEUE can't just handle expanded (> MTU) packet, and
> also want to have control over SEQ/ACK numbers assigned to
> both packets and connection structures.
It'd be the TCP layer's job to fragment outgoing packets, considering
the appropriate MSS. conntrack defragments, as far as I can see,
nfqueue doesn't deal with the issue at all.
> [...] Can anyone point me to correct place in kernel sources to
> see/attach with SystemTap and track how SEQs are generated and how
> outgoing packets are planned to be fragmented or even dropped?
> Deliberately want a good tour. [...]
For plain ipv4, for recent systemtap versions:
probe kernel.function("secure_tcp_sequence_number").return {
printf ("%s -> %d\n", @entry($$parms), $return)
}
[...]
saddr=0x100007f daddr=0x100007f sport=0xcee1 dport=0x3815 -> 1787682413
saddr=0x100007f daddr=0x100007f sport=0x3815 dport=0xcee1 -> 1793064379
saddr=0x100007f daddr=0x100007f sport=0x75c9 dport=0xf03 -> 1934845113
saddr=0x100007f daddr=0x100007f sport=0xf03 dport=0x75c9 -> 1938803971
[...]
probe kernel.function("tcp_fragment") {
println($$parms, " ", @cast(&$skb->cb[0], "tcp_skb_cb")->seq,
" ", @cast(&$skb->cb[0], "tcp_skb_cb")->end_seq)
}
sk=0xffff8805215d4880 skb=0xffff8805125fac00 len=0x500 mss_now=0x5a8 1280 3015968150 3016000006
[...]
- FChE
next prev parent reply other threads:[~2011-03-07 23:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-02 3:22 recommendations on implementing a custom Netfilter hook to QUEUE packets before their SEQ/ACK and size before fragmentation are known? Igor 'Lo' (И.L.)
2011-03-07 23:52 ` Frank Ch. Eigler [this message]
2011-03-08 3:18 ` Igor 'Lo' (И.L.)
2012-09-11 12:31 ` Hassan
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=y0maah61obj.fsf@fche.csb \
--to=fche@redhat.com \
--cc=bombsiteunrested@gmail.com \
--cc=netfilter-devel@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.