QUEUE target and IPT_CONTINUE verdict ?

QUEUE target and IPT_CONTINUE verdict ?

[Laurent Guyon]

Hello,

(sorry for my bad english, i'm french ;)

Just wondering why we can't return an IPT_CONTINUE verdict at the end of the 
QUEUE target.

I understand that the QUEUE target registers on a Netfilter queue_handler 
(that is a special kind of hook), and then it must call nf_reinject in the 
end.

I understand too that the nf_reinject function accepts only NF_ACCEPT, 
NF_DROP ... verdicts, but why ? Is it technically impossible to give 
nf_reinject an IPT_CONTINUE verdict and implement the relevant code to 
let packets continue their path in the rules ? or anyone hadn't ever thought 
about such a feature ?

In fact i need to put packets ine the QUEUE target to process them in 
userspace, and then reinject them in Netfilter, but they must continue their 
path in the rules.

Thanks a lot,

Laurent

Re: QUEUE target and IPT_CONTINUE verdict ?

[Tobias DiPasquale]

On 5/13/05, Laurent Guyon <laurent.guyon@adelux.fr> wrote:
> Just wondering why we can't return an IPT_CONTINUE verdict at the end of the
> QUEUE target.
> 
> I understand that the QUEUE target registers on a Netfilter queue_handler
> (that is a special kind of hook), and then it must call nf_reinject in the
> end.
> 
> I understand too that the nf_reinject function accepts only NF_ACCEPT,
> NF_DROP ... verdicts, but why ? Is it technically impossible to give
> nf_reinject an IPT_CONTINUE verdict and implement the relevant code to
> let packets continue their path in the rules ? or anyone hadn't ever thought
> about such a feature ?

I believe the reason for this is that, to do this, the kernel would
have to remember where it was in the processing of the rules and thus
save some state with every packet sent to userspace to be used in the
case where the ip_queue handler returned IPT_CONTINUE.

I don't believe that such state is hard to add, it would just waste
space. Feel free to code up a patch and submit it.

-- 
[ Tobias DiPasquale ]
0x636f6465736c696e67657240676d61696c2e636f6d

Re: QUEUE target and IPT_CONTINUE verdict ?

[Henrik Nordstrom]

On Sun, 15 May 2005, Tobias DiPasquale wrote:

> I don't believe that such state is hard to add, it would just waste
> space. Feel free to code up a patch and submit it.

It is harder than it may seem unfortunately. QUEUE is implemented in 
netfilter as a hook verdict. Because of this QUEUE is terminal for 
iptables just like ACCEPT/DROP.

-j QUEUE

makes iptables return the IPT_QUEUE verdict to the netfilter kernel, which 
then sends this to the queue handler (normally ip_queue with it's netlink 
socket). On reinject netfilter continues on the next hook handler of the 
same hook, or returns the packet to the kernel if there is no more 
handlers on this hook.

Remembering the iptables state is a bit tricky here as you are several 
layers away from iptables.  (netfilter hook interface, iptables table 
interface). You also have time to worry about as the iptable may have 
been modified when the packet is later reinjected.

Regards
Henrik

Re: QUEUE target and IPT_CONTINUE verdict ?

[Tobias DiPasquale]

On 5/15/05, Henrik Nordstrom <hno@marasystems.com> wrote:
> -j QUEUE
> 
> makes iptables return the IPT_QUEUE verdict to the netfilter kernel, which
> then sends this to the queue handler (normally ip_queue with it's netlink
> socket). On reinject netfilter continues on the next hook handler of the
> same hook, or returns the packet to the kernel if there is no more
> handlers on this hook.

Is this also the reason that there can be only one ip_queue handler at a time?

-- 
[ Tobias DiPasquale ]
0x636f6465736c696e67657240676d61696c2e636f6d

Re: QUEUE target and IPT_CONTINUE verdict ?

[Henrik Nordstrom]

On Sun, 15 May 2005, Tobias DiPasquale wrote:

> Is this also the reason that there can be only one ip_queue handler at a time?

Yes, or no depending on how you want to use the ip_queue handlers..

If you want different rules to reach different queue handlers then yes.

If you simply want the packet to call both handlers then no, but as this 
generally can be implemented just fine in userspace it is not considered 
important to implement.

Why do you want more than one ip_queue handler, and how?

Regards
Henrik

Re: QUEUE target and IPT_CONTINUE verdict ?

[Henrik Nordstrom]

On Mon, 16 May 2005, Laurent Guyon wrote:

> Then, if I understand well, what I want to do isn't really possible this way.

Not easily anyway.

> If I can't reinject my packets in Netfilter from the QUEUE target, maybe I
> could systemacally return NF_DROP as verdict, and forge (from my userspace
> tool) new packets, identical but marked, with libnet to re-emit them, so they
> will pass again in Netfilter ?

Does not sound very good, but it depends on what kind of modifications you 
need to do to the packets and why you want them to be seen again by the 
same hook. There is complications from connection tracking etc if this is 
not done carefully.

So the key question is why do you need the packets to pass thru the same 
hook again?

Perhaps if you described what it is you are trying to accomplish at a 
higher level we could give you an advice how to best do this. The Linux 
kernel is quite multi-faceted in its networking capabilities and 
interfaces and almost always there is more than one way to approach any 
given problem.

Regards
Henrik

Re: QUEUE target and IPT_CONTINUE verdict ?

[Tobias DiPasquale]

On 5/16/05, Henrik Nordstrom <hno@marasystems.com> wrote:
> Why do you want more than one ip_queue handler, and how?

I don't. I had just wondered as to the reason there was only one
ip_queue handler allowed and when you explained the above, I figured
that was the reason. Multiplexing ip_queue in userspace over multiple
handlers is trivial; I don't see the need for more than one handler,
given the complexity that it would add to the kernel to implement
such.

-- 
[ Tobias DiPasquale ]
0x636f6465736c696e67657240676d61696c2e636f6d