From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wang Jian Subject: Re: extending conntrack event data Date: Thu, 21 Apr 2005 18:14:08 +0800 Message-ID: <20050421180723.03CF.LARK@linux.net.cn> References: <42677180.60003@ufomechanic.net> <42677732.1000905@ufomechanic.net> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: netfilter-devel@lists.netfilter.org, Pablo Neira Return-path: To: Amin Azez In-Reply-To: <42677732.1000905@ufomechanic.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org Hi Amin Azez, On Thu, 21 Apr 2005 10:49:38 +0100, Amin Azez wrote: > OK, I see that the skb is only available in ip_conntrack_event_cache and > not ip_conntrack_event. I'm not clear on the different purposes of these > two functions, but I see that both could potentially cause events in > conntrack(-tool). I also see that notifier_call_chain is a general > function and that my suggestion of adding an extra parameter to it is > not likely to be well received. ip_conntrack_event_cache() marks a bitmap to indicate that certain event occurs. The message will not be delivered immediately due to whatever reason such as performance. I think one ctnetlink message can carry more than one event so it is reasonable to cache different kinds of (not emergent) event till one type of event occurs again. > > It is thus not practical to do as I suggested and make skb information > available at conntrack events. > If we use skb everywhere (because it can contains conntrack information), then you can do what you want. > Perhaps my real answer is to store the mac address as part of the > conntrack info? > Is it legitimate to maintain link layer information of a connection with > the other conntrack info? > I can see that some people won't care for it, while in other cases it > forms an important part of the connection state. > > Perhaps it should be a configure option, whether or not to maintain link > layer information in the conntrack? > (I'm likely to also store the conntrack creation time, and some kind of > serial number for my own purposes.) > > Opinions? You can always use your own patch :) > > Amin > > Amin Azez wrote: > > > I realise that I may be extending the scope of ctevent too far for > > some, but I would like to make some more info available for conntrack > > events. > > > > Specifically: mac addresses, and the time stamp associated with the > > skb that triggered the conntrack event. > > > > notifier_call_chain in include/linux/netfilter_ipv4/ip_conntrack.h > > extacts the ip_conntrack from the skb and passes that to each event > > callback. > > As notifier_call_chain is not passed the addresses of any members of > > the skb the callback can't use any container tricks to extract the skb > > address. > > For my own convenience, and for compatability, I would like to modifer > > notify_call_chain to pass the skb address as a 4th parameter so that > > callback handlers may receive it. How do others feel about this? > > > > Also, I realise that at the moment the mac member of an sk_buff > > presumes that all mac info will be ethernet; however I would like to > > write clean code that does not presume this will always be the case. > > What is the best way to check from an sk_buff that the link layer is > > ethernet, or rather that it is valid to presume that sk->mac.raw > > points to an ethhdr (if not null)? The best I could think of was > > sk->inputdev but this seems to have no members to indicate device > > type. Is it true that the kernel only supports ethernet-type devices, > > or devices that masquerade as ethernet type devices? > > > > Finally, I know the issue of conntrack id's has been discussed before, > > and that in kernel space the tuples are actually the best way to > > relate skb's to conntracks. I realise that tuple contents could also > > be used to maintain user-space references there is a race condition > > that exists; if a user-space application requests some action on a > > conntrack or related connection, because by the time this instruction > > is acted on in the kernel it might be applied to a different actual > > connection with the same tuple (previous connection has been closed). > > As netlink/netfilter stuff introduces more user-space connection > > management capabilities, we surely need to consider this problem? > > > > Amin > > > > > > -- lark