hey Jeff,

On Tue, Aug 2, 2011 at 2:42 AM, Jeff Haran [off-list ref] 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