Hi Pablo, thanks for your reply. can you please refer me to any documentation on how to use ct extensions? thanks, Gidon On Mon, Sep 12, 2011 at 11:45 AM, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > On Thu, Sep 08, 2011 at 11:12:53AM +0300, Gidon Miller wrote: > > Hi, > > I hope I'm posting this question to the correct list. if not please > > let me know where I should be posting. > > > > I'm writing a kernel module (against 2.6.32) to add functionality to > > conntrack to maintain extra state information for certain tcp > > connections. > > Better use one ct extension. > > > the way I'm doing this is by unregistering the l4proto handler for tcp > > on module load and registering my own handler struct which is the same > > except for the new(), destroy(), packet() and print_conntrack() > > functions. my functions call the original tcp handler functions and > > then perform some of their own logic - they change the ct->mark to > > hold an id used to reference a table of "my" connection info (that > > holds my state and other data). I also have xtables matcher and target > > modules that reference this conntrack info and do some logic > > accordingly. > > therefore I'd like to protect my data and the nf_conn data while in my > > handler functions. > > > > this raises a few questions: > > 1. I see that xtables modules (such as xt_CONNMARK and xt_state) do > > not take the ct->lock. what protects the ct entry in this case? > > 2. since I cant take the ct->lock in my functions (because they call > > the tcp functions who take the lock) its not clear to me how to > > protect my data. in general, is my approach the correct one? > > The ct->lock is only used if you modify the internal TCP data for that > ct flow, like it happens in the nf_conntrack_tcp code. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
