All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adel Belhouane <bugs.a.b@free.fr>
To: Michael Fomichev <fomichev.michael@gmail.com>, netfilter@vger.kernel.org
Subject: Re: Is it possible to access ip fragments with libnetfilter_queue?
Date: Tue, 28 Apr 2015 21:04:37 +0200	[thread overview]
Message-ID: <553FD9C5.8030805@free.fr> (raw)
In-Reply-To: <CAEVBFLi1CZaKyXNMROtmyYScNOo9wYnQOCQrBbDqsxieAGce9g@mail.gmail.com>

Le 28/04/2015 09:39, Michael Fomichev a écrit :
> Hello,
>
> I am using libnetfilter_queue in C to capture packets. I am setting an
> iptable rule to queue the incoming packets that would later be
> processed by the userspace implementation like this: iptables -A INPUT
> -j NFQUEUE --queue-num 0. I used nfqnl_test.c example as a framework
> to implement the capture. Everything works as expected. However, I
> noticed that it is impossible to inspect the queue on the level of ip
> fragments. That is, if a packet is coming in fragments it is first
> reassembled before being put into the queue. But I would like to work
> with fragments. So is there a way to enforce that kind of behavior?
> What I want to have is a queue where I could observe raw incoming
> packets (both fragmented and unfragmented) so I would be able to act
> on them accordingly.

[...]

 > "fragmentation granularity" which I am looking for. I also tried
 > adjusting iptable rules (e.g. iptables -t raw -D PREROUTING -i eth0 -j
 > NFQUEUE --queue-num 0), but the result is still the same. I can only

Defragmentation has the lowest priority in include/uapi/linux/netfilter_ipv4.h:
NF_IP_PRI_CONNTRACK_DEFRAG = -400
This is even before the RAW priority (-300), so iptables can't work before 
defragmentation, unless of course nf_defrag_ipv4 isn't loaded, that is you 
don't use connection tracking at all, which I'd doubt.

Try with nft/nftables, because you can choose the hook priority with nft. The 
nft rules shouldn't interfere with iptables rules, both can be loaded and be 
working together. I chose priority -450 because -450 < -400 , so it will run 
before nf_defrag_ipv4 and I called it predefrag.

# nft -i
nft> add table filter
nft> add chain filter predefrag { type filter hook prerouting priority -450; }
nft> add filter predefrag meta iif eth0 counter queue num 0 bypass

When I run nfqnl_test, if I switch from ping -s 1472 to ping -s 1473 (ethernet 
size from 1500 to 1501) from an other box, I go from 1 packet with 
payload_len=1500 to two packets (payload_len 1500 and 21).
With priority -300 I get only one packet with payload_len 1501. Appears to be 
working!

Normally (in all the examples...) the priority should be -300. I don't know if 
there's any side effect when using -450.

Relevant documentation:
http://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains
http://wiki.nftables.org/wiki-nftables/index.php/Queueing_to_userspace

>
> Any help is really appreciated
>
> Best regards,
>
> Michael

Best regards,
Adel


      reply	other threads:[~2015-04-28 19:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-28  7:39 Is it possible to access ip fragments with libnetfilter_queue? Michael Fomichev
2015-04-28 19:04 ` Adel Belhouane [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=553FD9C5.8030805@free.fr \
    --to=bugs.a.b@free.fr \
    --cc=fomichev.michael@gmail.com \
    --cc=netfilter@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.