* ip_queue, libnetfilter_queue, and packet alteration
@ 2008-07-23 0:02 Curtis Wyatt
2008-07-23 9:45 ` Eric Leblond
0 siblings, 1 reply; 10+ messages in thread
From: Curtis Wyatt @ 2008-07-23 0:02 UTC (permalink / raw)
To: netfilter
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? I don't want to move to
libnetfilter_queue because I can't find a redhat rpm and I can't find
hardly any documentation on it.
Thank you for any help.
-----------------------------
Curtis
http://gocalipso.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ip_queue, libnetfilter_queue, and packet alteration
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
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Eric Leblond @ 2008-07-23 9:45 UTC (permalink / raw)
To: Curtis Wyatt; +Cc: netfilter
[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]
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.
> I don't want to move to
> libnetfilter_queue because I can't find a redhat rpm and I can't find
> hardly any documentation on it.
Compilation is not really difficult but lack of documentation is a real
problem. The only thing for now is too look at snort-inline or NuFW code
to see how to use the library.
BR,
--
Eric Leblond
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ip_queue, libnetfilter_queue, and packet alteration
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-23 17:13 ` Patrick McHardy
2 siblings, 1 reply; 10+ messages in thread
From: Pablo Neira Ayuso @ 2008-07-23 10:02 UTC (permalink / raw)
To: Eric Leblond, Curtis Wyatt, netfilter
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.
>
>> I don't want to move to
>> libnetfilter_queue because I can't find a redhat rpm and I can't find
>> hardly any documentation on it.
>
> Compilation is not really difficult but lack of documentation is a real
> problem. The only thing for now is too look at snort-inline or NuFW code
> to see how to use the library.
I remember that you have mentioned some libnetfilter_queue's
documentation during the RMLL? I'm willing to include it if that helps
users. Where is it?
--
"Los honestos son inadaptados sociales" -- Les Luthiers
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ip_queue, libnetfilter_queue, and packet alteration
2008-07-23 10:02 ` Pablo Neira Ayuso
@ 2008-07-23 11:19 ` Eric Leblond
0 siblings, 0 replies; 10+ messages in thread
From: Eric Leblond @ 2008-07-23 11:19 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Curtis Wyatt, netfilter
Hello,
On Wednesday, 2008 July 23 at 12:02:53 +0200, Pablo Neira Ayuso 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?
> > problem. The only thing for now is too look at snort-inline or NuFW code
> > to see how to use the library.
>
> I remember that you have mentioned some libnetfilter_queue's
> documentation during the RMLL? I'm willing to include it if that helps
> users. Where is it?
I think this is the doc you are talking about:
http://lists.netfilter.org/pipermail/netfilter-devel/2006-February/023286.html
BR,
--
Eric Leblond
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ip_queue, libnetfilter_queue, and packet alteration
2008-07-23 9:45 ` Eric Leblond
2008-07-23 10:02 ` Pablo Neira Ayuso
@ 2008-07-23 16:43 ` Curtis Wyatt
2008-07-24 23:13 ` Curtis Wyatt
2008-07-23 17:13 ` Patrick McHardy
2 siblings, 1 reply; 10+ messages in thread
From: Curtis Wyatt @ 2008-07-23 16:43 UTC (permalink / raw)
To: Eric Leblond, Curtis Wyatt, netfilter
On Wed, Jul 23, 2008 at 2:45 AM, Eric Leblond <eric@inl.fr> wrote:
> On Tuesday, 2008 July 22 at 17:02:14 -0700, Curtis Wyatt wrote:
>>
>> Will libnetfilter_queue do this for me?
>
> Yes, but you will have to compute the checksum of the modified packet by
> yourself.
>
>
> BR,
> --
> Eric Leblond
I have to do that with ip_queue as well. I just can't understand why
the packet disappears then after I do the NF_ACCEPT on it. Or why the
payload is shifted over 7 spaces for me. I have to increment the
pointer to the payload 7 times to get it to line up correctly.
I really do appreciate the help guys :)
-----------------------------
Curtis
http://gocalipso.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ip_queue, libnetfilter_queue, and packet alteration
2008-07-23 9:45 ` Eric Leblond
2008-07-23 10:02 ` Pablo Neira Ayuso
2008-07-23 16:43 ` Curtis Wyatt
@ 2008-07-23 17:13 ` Patrick McHardy
2008-07-24 7:41 ` Eric Leblond
2 siblings, 1 reply; 10+ messages in thread
From: Patrick McHardy @ 2008-07-23 17:13 UTC (permalink / raw)
To: Eric Leblond, Curtis Wyatt, netfilter
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ip_queue, libnetfilter_queue, and packet alteration
2008-07-23 17:13 ` Patrick McHardy
@ 2008-07-24 7:41 ` Eric Leblond
2008-07-24 10:22 ` Patrick McHardy
0 siblings, 1 reply; 10+ messages in thread
From: Eric Leblond @ 2008-07-24 7:41 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Curtis Wyatt, netfilter, toady
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.
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.
BR,
--
Eric Leblond
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ip_queue, libnetfilter_queue, and packet alteration
2008-07-24 7:41 ` Eric Leblond
@ 2008-07-24 10:22 ` Patrick McHardy
2008-07-25 9:43 ` Sebastien Tricaud
0 siblings, 1 reply; 10+ messages in thread
From: Patrick McHardy @ 2008-07-24 10:22 UTC (permalink / raw)
To: Eric Leblond, Patrick McHardy, Curtis Wyatt, netfilter, toady
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ip_queue, libnetfilter_queue, and packet alteration
2008-07-23 16:43 ` Curtis Wyatt
@ 2008-07-24 23:13 ` Curtis Wyatt
0 siblings, 0 replies; 10+ messages in thread
From: Curtis Wyatt @ 2008-07-24 23:13 UTC (permalink / raw)
To: Eric Leblond, Curtis Wyatt, netfilter
On Wed, Jul 23, 2008 at 9:43 AM, Curtis Wyatt <zhackwyatt@gmail.com> wrote:
>
> I have to do that with ip_queue as well. I just can't understand why
> the packet disappears then after I do the NF_ACCEPT on it. Or why the
> payload is shifted over 7 spaces for me. I have to increment the
> pointer to the payload 7 times to get it to line up correctly.
>
Well I figured out the source of my problems, (this shifting that is
going on). It's because during the compile this was passed as a
switch: -fpack-struct
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ip_queue, libnetfilter_queue, and packet alteration
2008-07-24 10:22 ` Patrick McHardy
@ 2008-07-25 9:43 ` Sebastien Tricaud
0 siblings, 0 replies; 10+ messages in thread
From: Sebastien Tricaud @ 2008-07-25 9:43 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Leblond, Curtis Wyatt, netfilter, toady
|>>> Someone should send a patch which adds helper functions to ease that
|>>> task in a day or two.
I want to add a few features, but the patch will appear on the devel list very
shortly.
|
|> 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?
I wrote a program two years ago to alter packets without worrying about
checksums (putting 0 instead). Let's not do any assumption there.
I am going to send the checksum patch for libnetfilter_queue very soon, and
then write a sample program to explain how packet alteration can be done
easily.
Cheers,
Sebastien.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2008-07-25 9:43 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2008-07-25 9:43 ` Sebastien Tricaud
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.