Well, what made me think about such an idea is the following.
I am doing several operations on each SKB and after confirming several tests (in a kinda nested manner) I realize that a packet needs
Anyhow, I've already made the needed changes to reflect my 'tests' to the hook function so when they're all met, I return NF_STOLEN but was looking for something less messy.
I am doing several operations on each SKB and after confirming several tests (in a kinda nested manner) I realize that a packet needs
to be stolen.
The trouble is that I am doing in this in a long series of function calls so it would had looked ugly to propagate all my test results up to the hook function I have so I can know whether to return NF_ACCEPT or NF_STOLEN
Anyhow, I've already made the needed changes to reflect my 'tests' to the hook function so when they're all met, I return NF_STOLEN but was looking for something less messy.
Regards,
Adel
Adel
On Wed, Jul 3, 2013 at 10:16 AM, Rami Rosen <roszenrami@xxxxxxxxx> wrote:
Hi, Adel,
The NF_STOLEN return code is not assigned to any sk_buff field as you know.
What would it give you if you could mark somehow the sk_buff with
NF_STOLEN? what do you want to achieve with it ? what is wrong with
how things are now- first calling the other hooks and then the NF_STOLEN?
Best,
Rami Rosen
http://ramirose.wix.com/ramirosen
> _______________________________________________
On Tue, Jul 2, 2013 at 8:30 PM, Adel Qodmani <mpcadel@xxxxxxxxx> wrote:
> Hello everyone,
>
> In any Netfilter hook, we return NF_STOLEN to mark that we're handling the
> packet and we'd be responsible for its fate.
>
> My question is, my hook calls several functions on the SKB before knowing if
> I want to steal it or not so is there a way to just mark the SKB itself as
> stolen instead of using the hook NF_STOLEN return code?
>
> Thanks,
> Adel
>
> Kernelnewbies mailing list
> Kernelnewbies@xxxxxxxxxxxxxxxxx
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies