Re: Dynamic source MAC-NAT?

Feyd <[email protected]>
Newsgroups gmane.linux.network.bridge.ebtables.devel
Message-ID <[email protected]>
On Sun, 18 Dec 2005 15:20:19 +0000
Bart De Schuymer <[email protected]> wrote:

> Iptables conntrack uses skb->nf_conntrack to refer to the connection
> tracking info. If ebtables' conntracking is implemented similarly, we'd
> need something like that too. Suppose we don't keep this reference in
> the skb and we dnat mac address $a to $b in prerouting. From that point
> on there won't be an easy way to know if the mac destination address $b
> was modified or not. If the skb is dropped later on, we'll probably need
> to decrease the use count of the conntrack, so it can be destroyed if
> it's not used anymore. For iptables this is done with nf_conntrack_put
> (see skbuff.h) called from __kfree_skb (skbuff.c). We'll need something
> similar I think.

I see, the resistance to add anything to the sk_buff can be expected and
the way the nfct is currently used prevents multilayer connection tracking.
One way to avoid touching the sk_buff could be to separate the nf_conntrack
from the layer conntrack it currently masquerades and turn it into list of
pointers to the layer conntracks. This would however add a kmalloc/kfree
per new/destroyed conntrack, could this be noticeable performance hit?

struct nf_conntrack_layer {
        void (*destroy)(struct nf_conntrack *);
};

struct nf_conntrack {
        atomic_t l2_use;
        atomic_t l3_use;
        struct nf_conntrack_layer *l2_ct;
        struct nf_conntrack_layer *l3_ct;
};

static inline void nf_conntrack_put(struct nf_conntrack *nfct)
{
        if (nfct) {
                if(nfct->l2_ct && atomic_dec_and_test(&nfct->l2_use))
                        nfct->l2_ct->destroy(nfct);

                if(nfct->l3_ct && atomic_dec_and_test(&nfct->l3_use))
                        nfct->l3_ct->destroy(nfct);

                if(!atomic_read(&nfct->l2_use) && !atomic_read(&nfct->l3_use))
                        /* destroy self */
        }
}

Feyd



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.