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 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 On Wed, Jul 3, 2013 at 10:16 AM, Rami Rosen <[email protected]> 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 <[email protected]> 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 > > [email protected] > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
