Hello Jan, Thank you once again for the reply. I asked the question because I was of the notion that it was not a very good play around with the memory which was allocated by some other NetFilter module. I had this doubt because I got confused between NDIS network drivers, where modifying the pointers in a packet which was allocated by some other module resulted in a BSOD, and NetFilter modules. Thank you once again for clarifying my doubts. Thank you and regards, Subhadeep Ghosh. On Fri, Apr 16, 2010 at 5:42 PM, Jan Engelhardt <jengelh@xxxxxxxxxx> wrote: > > On Friday 2010-04-16 13:01, Subhadeep Ghosh wrote: > >>Hello Jan, >> >>Thank you for your reply. Yes, I am aware of what NF_DROP and >>NF_STOLEN mean. My question was, is it possible for me to replace the >>original sk_buff with the new sk_buff which I created, in the sk_buff >>processing queue? >> >>For example in the earlier NetFilter hook implementations, the >>signature of a hook function was, >> >>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*)); > > This was once used because an skb could be shared, and making changes > to it in COW fashion requires the skb to be copied - something like > that, it's in the git logs (v2.6.23-3980-g3db05fe and its immediate > parent commits). > The double indirection was, I think, not originally meant > for replacing packets. > >>While in the current implementations, it has been changed to, >> >>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*)); >> >>The only difference between the two implementations is sk_buff** has >>been changed to sk_buff*. So, in the earlier versions if *skb was >>assigned with the address of the newly created sk_buff and marked the >>original sk_buff as NF_STOLEN > > NF_xxx is not a property of a skb, though. The implicit stealing > of the oldskb was just a side-effect. > >>and then did a kfree_skb on it, then it >>would work. However, in the current implementations a hook developer >>is not allowed to change the sk_buff pointer which NetFilter sends to >>the hook functions. And that is what I wanted to do. > > If you can replace a skb, you can just as well change the existing > one. > -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html