[net] Hacking the wholism of GNU/Linux net*

[Shawn]

hey Jeff,

On Tue, Aug 2, 2011 at 2:42 AM, Jeff Haran <jharan at bytemobile.com> wrote:
>
> I personally welcome all attempts to document this perplexing Linux
> kernel feature and applaud your attempt to do so.
>
> Couple of suggestions for improvement:
>
> "Your hook function's prototype is like below:
>
> typedef unsigned int nf_hookfn(unsigned int hooknum,
>                               struct sk_buff *skb,
>                               const struct net_device *in,
>                               const struct net_device *out,
>                               int (*okfn)(struct sk_buff *));"
>
> It would be nice if the document defined what the purpose of the okfn
> parameter that is passed to the above function is. What is it for and
> what does a hook function need to do with it? What do the "in" and "out"
> parameters point to and under which conditions are they valid? For
> instance, what is "out" going to point to during a PREROUTING hook?
>
I don't read the source code for this part yet.

> "The hook functions will return some values to tell Netfilter what to
> do then, when the hook functions are done. These values are displayed
> in the Table below:
>
> Table 3: Return code of hook function
>
> Return Code          Meaning
>  NF_DROP        Discard the packet.
>  NF_ACCEPT      Keep the packet.
>  NF_STOLEN      Forget about the packet.
>  NF_QUEUE       Queue packet for userspace.
>  NF_REPEAT      Call this hook function again."
>
> Likewise, it would be nice if the document provided some more
> explanation of the above return codes. For instance, what's the
> difference between NF_DROP and NF_STOLEN and when should your hook
> function return one vs. the other? If you return NF_REPEAT, when does
> the hook function get called again for the given packet and under what
> kind of circumstances would you want to return NF_REPEAT? If you return
> NF_QUEUE, how is the NF queue number that the packet will get queued to
> determined?
>
I cited Bioforge's article:"The   NF_DROP  return  code  means  that
this  packet  should  be  dropped completely  and  any  resources
allocated  for  it  should  be   released. NF_ACCEPT tells Netfilter
that so far the  packet is  still acceptable and that it should move
to the  next stage of the network stack.  NF_STOLEN is an interesting
one because it tells Netfilter to "forget" about the packet. What this
 tells Netfilter is  that the hook  function will take processing of
this packet from  here and that Netfilter  should drop all processing
of it.  This does  not  mean,  however, that  resources  for  the
packet  are released. The packet and it's respective sk_buff structure
are still valid, it's just that  the hook  function has  taken
ownership of the packet away from  Netfilter.  Unfortunately  I'm  not
 exactly  clear on  what NF_QUEUE really  does  so  for  now  I won't
discuss  it.  The  last return  value, NF_REPEAT requests that
Netfilter calls the hook  function again. Obviously one must be
careful using NF_REPEAT so as to avoid an endless loop.". The
netfilter will send the packet to the userspace when NF_QUEUE is
return. I do remember that someone writen a program with NF_QUEUE
return to snort which running on userspace.

> "Finally, I thank my beautiful wife for proofreading the article and
> helping me fix the grammar errors."
>
> Not to cast aspersions on your wife, but  you might want to pass this
> document through a spelling checker. It contains numerous spelling
> errors. For example, the word "firstable" that begins section 2.4.1 does
> not exist in the English language.
>
ooh, sorry about that. I'm not a english native speak. I will keep improve it.

> Thanks,
>
Thanks for your suggestion!



-- 
GNU powered it...
GPL protect it...
God blessing it...

regards
Shawn