hey Jeff, On Tue, Aug 2, 2011 at 2:42 AM, Jeff Haran <jharan@xxxxxxxxxxxxxx> 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
