All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Eric Leblond <eric@inl.fr>, Patrick McHardy <kaber@trash.net>,
	Curtis Wyatt <zhackwyatt@gmail.com>,
	netfilter@vger.kernel.org, toady@inl.fr
Subject: Re: ip_queue, libnetfilter_queue, and packet alteration
Date: Thu, 24 Jul 2008 12:22:06 +0200	[thread overview]
Message-ID: <488857CE.3060406@trash.net> (raw)
In-Reply-To: <20080724074144.GE2250@khasse.inl.fr>

Eric Leblond wrote:
> Hello,
> 
> On Wednesday, 2008 July 23 at 19:13:47 +0200, Patrick McHardy wrote:
>> Eric Leblond wrote:
>>> Hello,
>>>
>>> On Tuesday, 2008 July 22 at 17:02:14 -0700, Curtis Wyatt wrote:
>>>> I am using ip_queue.  I understand that is depreciated.
>>>>
>>>> I want to intercept a packet, alter it (change payload and source ip
>>>> address and destination ip address) and then do an NF_ACCEPT on it, to
>>>> have it continue on its way to another machine.  However it never
>>>> shows up at that other machine.  Is there anyway to do this without
>>>> doing an NF_DROP and then sending a new packet through?
>>>>
>>>> Will libnetfilter_queue do this for me?
>>> Yes, but you will have to compute the checksum of the modified packet by
>>> yourself.
>>>
>>> Someone should send a patch which adds helper functions to ease that
>>> task in a day or two.
>> That makes sense. It would also allow to take advantage of hardware
>> TX csumming.
> 
> You mean, doing this on kernel side ? That's seem nice but tha atch have
> been prepared for userspace.

Not necessarily, userspace could also get the partial checksums
if its aware of them (which could be indicated when configuring
the queue). But thats only one half of it, when modifying the
packet in a way that incremental checksum updates are not possible,
it has to be recalculated entirely. Thats where the hardware
could help.

> I will try to look into it. I know that kernel was automatically
> computing checksum if it was set to zero in packet vefore verdict but
> the feature seems to have disappear.

I'm not aware of this feature. Was it present in ip_queue?

  reply	other threads:[~2008-07-24 10:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-23  0:02 ip_queue, libnetfilter_queue, and packet alteration Curtis Wyatt
2008-07-23  9:45 ` Eric Leblond
2008-07-23 10:02   ` Pablo Neira Ayuso
2008-07-23 11:19     ` Eric Leblond
2008-07-23 16:43   ` Curtis Wyatt
2008-07-24 23:13     ` Curtis Wyatt
2008-07-23 17:13   ` Patrick McHardy
2008-07-24  7:41     ` Eric Leblond
2008-07-24 10:22       ` Patrick McHardy [this message]
2008-07-25  9:43         ` Sebastien Tricaud

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=488857CE.3060406@trash.net \
    --to=kaber@trash.net \
    --cc=eric@inl.fr \
    --cc=netfilter@vger.kernel.org \
    --cc=toady@inl.fr \
    --cc=zhackwyatt@gmail.com \
    /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.