* Re: netfilter-devel Digest, Vol 1, Issue 1257
[not found] <20040825203232.01BE515F240@mta9.x263.net>
@ 2004-08-26 2:09 ` linkai
0 siblings, 0 replies; only message in thread
From: linkai @ 2004-08-26 2:09 UTC (permalink / raw)
To: netfilter-devel
Hi all:
How can I delete an connection track entry in user space?
Is there any interface ?
----- Original Message -----
From: <netfilter-devel-request@lists.netfilter.org>
To: <netfilter-devel@lists.netfilter.org>
Sent: Thursday, August 26, 2004 4:32 AM
Subject: netfilter-devel Digest, Vol 1, Issue 1257
> Send netfilter-devel mailing list submissions to
> netfilter-devel@lists.netfilter.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.netfilter.org/mailman/listinfo/netfilter-devel
> or, via email, send a message with subject or body 'help' to
> netfilter-devel-request@lists.netfilter.org
>
> You can reach the person managing the list at
> netfilter-devel-owner@lists.netfilter.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of netfilter-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: [RFC] ct_sync 0.15 (corrected) (jamal)
> 2. Re: Billing 3: WAS(Re: [PATCH 2/4] deferred drop, __parent
> workaround, reshape_fail , netdev@oss.sgi.com , (jamal)
> 3. Re: [PATCH 2/4] deferred drop, __parent workaround,
> reshape_fail (jamal)
> 4. Active SIP conntrack/NAT development? (Kevin P. Fleming)
> 5. Iptables extension loading error (John)
> 6. Re: Linux 2.6.9-rc1 (Harald Welte)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: 25 Aug 2004 07:41:41 -0400
> X-Virus: 1
> From: jamal <hadi@cyberus.ca>
> Subject: Re: [RFC] ct_sync 0.15 (corrected)
> To: Harald Welte <laforge@netfilter.org>
> Cc: netfilter-devel <netfilter-devel@lists.netfilter.org>,
> Netfilter-failover list <netfilter-failover@lists.netfilter.org>,
> KOVACS Krisztian <hidden@balabit.hu>
> Message-ID: <1093434101.1041.163.camel@jzny.localdomain>
> Content-Type: text/plain
>
>
> As Harald says its a little heavyweight for what you guys need to do.
> And it doesnt run on IP proper.
> We are going to explore and probably use TIPC for ForCES as one of the
> options for transport in the case of non-IP.
> For IP we are thinking a dual transport approach. Two sockets, one
> UDP/multicast while other is TCP|SCTP/unicast reliable.
> Send always on UDP multicast; respond always on multicast. Reap the
> benefits of multicast. Do NOT retransmit on multicast, retransmits of
> either queries/updates etc are done over unicast.
> This simple technique is borrowed from OSPF.
>
> If you are interested we can discuss this more.
>
> cheers,
> jamal
>
> On Tue, 2004-08-24 at 14:37, Harald Welte wrote:
> > On Sun, Aug 22, 2004 at 10:43:26PM +0200, KOVACS Krisztian wrote:
> > >
> > > Hi,
> > >
> > > On Thu, Aug 19, 2004 at 01:06:46PM +0200, Harald Welte wrote:
> > > > > So, do anyone know of anything which could be used by ct_sync?
> > > > > (It has to be a semi-reliable, connectionless multicast protocol
> > > > > with a _very_ low overhead.)
> > > >
> > > > everything I've seen so far about reliable multicast is inherently
> > > > complex.
> > >
> > > Oops, I've just found TIPC. Does anyone know enough details of TIPC to
> > > judge if its reliable multicast service would be useful for us? I've just
> > > downloaded the IETF draft, and it seems to me that the reliable multicast
> > > service provided by TIPC may be useful (section 2.9 of the draft). Any
> > > ideas?
> >
> > Unfortunately I did only learn about TIPC recently. But looking at the
> > IETF draft and the current implementation, I think it is probably too
> > expensive. Another argument is to not base ct_sync on something big
> > outside of the official kernel tree that is not under our control..
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: 25 Aug 2004 07:50:51 -0400
> X-Virus: 1
> From: jamal <hadi@cyberus.ca>
> Subject: Re: Billing 3: WAS(Re: [PATCH 2/4] deferred drop, __parent
> workaround, reshape_fail , netdev@oss.sgi.com ,
> To: Harald Welte <laforge@netfilter.org>
> Cc: sandr8 <sandr8_NOSPAM_@crocetta.org>, devik@cdi.cz,
> netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com
> Message-ID: <1093434651.1039.182.camel@jzny.localdomain>
> Content-Type: text/plain
>
> On Tue, 2004-08-24 at 14:46, Harald Welte wrote:
> > On Sun, Aug 22, 2004 at 12:12:04PM -0400, jamal wrote:
>
> > > Such packets are cloned or copied. I am going to assume the contrack
> > > data remains intact in both cases. LaForge?
> >
> > Yes. But still it is a question of viewpoint what kind of behaviour is
> > correct. Let's say a single packet is accounted in ct_acct, and then
> > sent to multiple interfaces, where on more than one of them it gets
> > unbilled. So we add once, but 'unbill' (i prefer the term subtract)
> > more than once. In the end the ct_acct counter will be less than when
> > it first encountered the packet.
> >
>
> These are some of the challenges i posed to Allesandro as well.
>
> > > In the future we should make accounting a feature that could be turned
> > > on despite contracking and skbs should carry an accounting metadata with
> > > them.
> >
> > I don't really understand what you want to say. You want accounting
> > that is not conntrack-based? well, then you should maybe look at
> > one of the many methods, ranging from iptables rule counters to the
> > ipt_acct match/target, nacctd, pcap-mmap, PF_RING, ULOG-based, ...
> >
>
> The discussion with fairness lead to my assertion above.
> None of the above take care of fairness factor that Alessandro is trying
> to achieve. So my thinking is if we wanna fix the unbill problem, why
> not address the whole issue and get accounting to be an embedded piece.
>
> > btw, they all account the amount of RX packet on inbound interface and
> > do not 'unbill' ;)
>
> I suspect in such a case you have a passive box which just gets a copy
> of the packet from the wire ;-> Someone else in the real box where the
> packet gets forwarded will drop the packet and it will still be paid
> for ;->
> In the case of what you have introduced though, you are billing for
> localy generated packets as well (if i am not mistaken this is where the
> issues are).
>
> In general i dont think we need to be 100% accurate. PSAMP for example
> operates by merely sampling i.e not taking a precise measurement. People
> have written tons of papers to prove it was good enuf.
>
> cheers,
> jamal
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: 25 Aug 2004 08:12:05 -0400
> X-Virus: 1
> From: jamal <hadi@cyberus.ca>
> Subject: Re: [PATCH 2/4] deferred drop, __parent workaround,
> reshape_fail
> To: Harald Welte <laforge@netfilter.org>
> Cc: sandr8@crocetta.org, devik@cdi.cz,
> netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com
> Message-ID: <1093435925.1039.221.camel@jzny.localdomain>
> Content-Type: text/plain
>
> On Tue, 2004-08-24 at 14:57, Harald Welte wrote:
> > On Mon, Aug 16, 2004 at 09:29:59AM -0400, jamal wrote:
>
> > Yes, I am working on the next generation of ulogd (ulogd-2). It will
> > allow you to stack multiple plugins on top of each other, such as:
> >
> > ctnetlink -> ipfix
> >
> > or
> >
> > ulog -> packet parser -> flow_aggrgation -> ipfix
> >
> > or even exporting per-packet data in ipfix
> >
> > ulog -> packet parser -> ipfix
> >
> > It's far from complete, but I'm almost finished with the core and can
> > start to write the plugins:
> > http://svn.gnumonks.org/branches/ulog/ulogd2/
>
> cool. Looks nice.
>
> > > Let me think about it.
> > > Clearly the best place to account for things is on the wire once the
> > > packet has left the box ;->
> >
> > This is arguable. Why not once the packet was receieved on the incoming
> > wire? If you are Ingress router of your network, your ISP bills you for
> > the amout of traffic it sends to your ingress router.
> >
> > OTOTH, for egress traffic I agree.
>
> I think maybe the issue is to define what the end goal is.
> For a passive box getting copies of the packets on the wire, ingress
> would be fine. Unfairness would still be there incase the forwarding
> box (not the accounting box) actually immediately drops the packet
> that has already been accounted for.
> OTOH, in what you have introduced you are also accounting for
> localy generated packets in a box that is not dedicatedfor just
> accounting.
> In such a case, we can (if the cost of making the change is acceptable)
> make more intelligent decisions.
>
> > > How open are you to move accounting further down? My thoughts
> > > are along the lines of incrementing the contrack counters at the qdisc
> > > level. Since you transport after the structure has been deleted, it
> > > should work out fine and fair billing will be taken care of.
> >
> > Sure, it can be done... but you need to grab ip_conntrack_lock in order
> > to do so.
>
> Suggestion is you just do the marking, let the qdisc do the accounting
> on possibly independent accounting table with much more fine grained
> locks.
>
> > > Has someone done experimented and figured how expensive it would be to
> > > do it at the qdisc level? Note, you can probably have a low level
> > > grained lock just for stats.
> >
> > It doesn't help. Currently we still have one global rwlock for all
> > conntrack's. There are patches for per-bucket locking.
> >
> > But well, as long as the usage count of ip_conntrack doesn't drop to
> > zero (which we're guaranteed since our skb still references it), and we
> > don't need to walk the hash table, we don't actually need to grab
> > ip_conntrack_lock. A seperate accounting lock would be possible.
> >
> > Somebody needs to implement this and run profiles...
> >
>
> We should probably avoid this approach totaly if we are going to do all
> that work.
>
> > > INC_STATS is generic (goes in the generic stats code in attached patch)
> > > and will have an ifdef for contrack billing (which includes unbilling
> > > depending on reason code). Reason code could be results that are now
> > > returned.
> > > As an example NET_XMIT_DROP is definetely unbilling while
> > > NET_XMIT_SUCCESS implies bill.
> >
> > sounds fine to me. But this basically means that we would hide
> > conntrack counters behind generic API - the counters themselves are
> > stored in our own data structure.
> >
>
> yes, that would also be a good starting compromise.
> I am begining to question the wisdom of "fixing" this. The clear
> solution is to have the contracking code do nothing other
> than mark the packets. This is the most valuable thing we can
> get out of contracking. Let the tc bits do the accounting. You can still
> transport this over ctnetlink. There will somehow need to be signaling
> as well from contrack to indicate addition or deletion of marks (other
> alternative is to have admin select marks).
>
> Of course all this is a big bait so we can have the energetic Alessandro
> do all the work ;-> <wink, wink>
>
> cheers,
> jamal
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 25 Aug 2004 08:01:38 -0700
> X-Virus: 1
> From: "Kevin P. Fleming" <kpfleming@starnetworks.us>
> Subject: Active SIP conntrack/NAT development?
> To: netfilter-devel@lists.netfilter.org
> Message-ID: <412CA9D2.4030506@starnetworks.us>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> After perusing the list archives, I see that two or three people in the
> past year or so have started working on SIP/SDP/RTP conntrack/NAT
> helpers, but none of them have apparently gotten to a usable state.
>
> I want to get this done, I need to be able to use it soon :-) I am
> willing to put the time in to make this work, and I believe I have
> enough skills to get it done.
>
> If there are any starting points out there (other than the code that
> Dominik posted a year ago) I'd appreciate pointers to them, otherwise
> I'll just take the existing FTP/H.323 examples and go from there. Also,
> if there are any available docs on making helpers that will work with
> both 2.4 and 2.6 kernels that would be appreciated as well.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 25 Aug 2004 13:12:06 +0000
> X-Virus: 1
> From: John <jfastabe@up.edu>
> Subject: Iptables extension loading error
> To: netfilter-devel@lists.netfilter.org
> Message-ID: <412C9026.6050703@up.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I am having trouble getting an iptables extension to work. I compile the
> shared library with the commands,
>
> $ gcc -02 -Wall -Wunused -I /root/iptables/include/ -fPIC -o
> libipt_CHANGEIP.o -c libipt_CHANGEIP.c
>
> $ ld -shared -o libipt_CHANGEIP.so libipt_CHANGEIP.o
>
> The above commands give no errors, but when I try to run iptables with
> my new target extension i get the following error.
>
> $ iptables iptables -I INPUT -j CHANGEIP
> iptables v1.2.9: Couldn't load target `CHANGEIP'
>
> I know the module is loaded correctly because when I remove the module I
> get a different error and the shared library is also in the correct
> directory because when i move it i get a different error then this. I
> am at a loss for what I should start to do to look for this error.
> Below is the code to my shared library and module. If anyone could give
> me advice on where to start looking to fix this problem that would be
> greatly appreciated. The system I am using is,
>
> Linux nitbit 2.4.22-gentoo-r5 #4 SMP Tue Jan 20 01:33:31 UTC 2004 i686
> Intel(R) Celeron(R) CPU 2.30GHz GenuineIntel GNU/Linux
>
> If more information is needed to help please let me know thank you for
> your time,
> john
>
> /* Shared library add-on to iptables to add CHANGEIP target support.
> */
> #include <stdio.h>
> #include <string.h>
> #include <stdlib.h>
> #include <getopt.h>
> #include <netinet/in.h>
> #include <iptables.h>
> #include <linux/netfilter_ipv4/ip_tables.h>
> #include "ipt_CHANGEIP.h"
>
> #define NOCLOBBER 0
> #define CLOBBER 1
>
> /* Function that prints out usage message */
> static void
> help(void)
> {
> printf(
> "ChangeIP target v \n"
> " --dip \tip \t\t Change destination IP\n"
> " --sip \tip \t\t Change source IP\n"
> " --continue\t \t\t Let packet continue traversal\n"
> "\n");
> }
>
> static struct option opts[] = {
> {"dip", 1, 0, '1' },
> {"sip", 1, 0, '2' },
> {"clobber",0,0,'3'},
> { 0 }
> };
>
> static void init
> (struct ipt_entry_target *t , unsigned int *nfcache ){
> struct ipt_changeip_target_info *ipinfo =
> (struct ipt_changeip_target_info*)t->data;
> printf("hi\n");
> ipinfo->clobber = NOCLOBBER;
> ipinfo->dip = NULL;
> ipinfo->sip = NULL;
>
> }
>
>
>
> static int parse(int c, char **argv, int invert,
> unsigned int *flags,
> const struct ipt_entry *entry,
> struct ipt_entry_target **target)
> { printf("hello\n");
> struct ipt_changeip_target_info *ipinfo =
> (struct ipt_changeip_target_info *)(*target)->data;
>
> //if(entry->ip.proto != IPT_IP)
> // exit_error(PARAMETER_PROBLEM, "Needs to be an ip packet");
> switch (c){
> case '1':
> if(*flags) exit_error(PARAMETER_PROBLEM,
> "Only one destination ip allowed");
> ipinfo->dip = optarg;
> //inet_aton(optarg, ipinfo->dip.s_addr );
> *flags =1;
> break;
> case '2':
> if(*flags) exit_error(PARAMETER_PROBLEM,
> "Only one src ip allowed");
> ipinfo->sip = optarg;
> //inet_aton(optarg, ipinfo->sip.s_addr);
> *flags = 1;
> break;
> case '3':
> if(*flags) exit_error(PARAMETER_PROBLEM,
> "Syntax messed up");
> ipinfo->clobber = 1;
> break;
>
> default: return 0;
> }
>
> return 1;
> }
>
> static void final_check(unsigned int flags){
> if(!flags)
> exit_error(PARAMETER_PROBLEM,
> "Must have either source or destination ip to change");
>
> }
>
>
> static void print (const struct ipt_ip *ip,
> const struct ipt_entry_target *target,
> int numeric)
> {
> printf("hello\n");
> const struct ipt_changeip_target_info *ipinfo
> = (const struct ipt_changeip_target_info *)target->data;
> printf("Changing IP");
> }
>
> static void save(const struct ipt_ip *ip, const struct ipt_entry_target
> *target)
> {
>
> }
>
> static struct iptables_target changeip = { NULL,
> "CHANGEIP",
> "1.2.9",
> IPT_ALIGN(sizeof(struct ipt_changeip_target_info) ),
> IPT_ALIGN(sizeof(struct ipt_changeip_target_info) ),
> &help,
> &init,
> &parse,
> &final_check,
> &print,
> &save,
> opts
> };
>
> void _init(void)
> {
> printf("hello\n");
> register_target(&changeip);
> }
>
>
>
>
>
> //and finally the module code
> #include <linux/module.h>
> #include <linux/skbuff.h>
> #include "ipt_CHANGEIP.h"
> #include <linux/netfilter_ipv4/ip_tables.h>
>
> #include <linux/kernel.h>
> #include <linux/ip.h> /* For IP header */
> #include <linux/netfilter.h>
> #include <linux/netfilter_ipv4.h>
>
> MODULE_AUTHOR("John Fastabend");
> MODULE_DESCRIPTION("Changes ip addresses");
> MODULE_LICENSE("GPL");
>
>
> static unsigned int
> ipt_changeip_target(struct sk_buff **pskb,
> unsigned int hooknum,
> const struct net_device *in,
> const struct net_device *out,
> const void *targinfo,
> void *userinfo)
> {
> const struct ipt_changeip_target_info *ipinfo = targinfo;
> struct sk_buff *sb = *pskb;
>
> if(skb_cloned(*pskb) && !(*pskb)->sk){
> struct sk_buff *nskb
> = skb_copy(*pskb, GFP_ATOMIC);
> if(!pskb) return NF_DROP;
> kfree_skb(*pskb);
> *pskb = nskb;
> sb->nh.iph = (*pskb)->nh.iph;
> }
>
> if( ipinfo->clobber == 0 /*NOCLOBBER*/ ){
> struct sk_buff *origskb
> = skb_copy(*pskb, GFP_ATOMIC);
> skb_insert(origskb,*pskb);
> }
>
>
> sb->nh.iph->daddr = ipinfo->dip;
>
>
> sb->nh.iph->saddr = ipinfo->sip;
>
>
> return IPT_CONTINUE;
> }
>
> static int ipt_changeip_checkentry( const char *tablename,
> const struct ipt_entry *e,
> void *targinfo,
> unsigned int targinfosize,
> unsigned int hook_mask)
> {
> return 1;
> }
>
> static struct ipt_target ipt_changeip_reg = { {NULL, NULL},
> "CHANGEIP",
> ipt_changeip_target,
> ipt_changeip_checkentry,
> NULL,
> THIS_MODULE };
>
> static int __init init(void){
> return ipt_register_target(&ipt_changeip_reg);
> }
>
> static void __exit fini(void){
> return ipt_unregister_target(&ipt_changeip_reg);
> }
>
> module_init(init);
> module_exit(fini);
>
>
>
>
> PS. sorry if this email is too long I didnt have anywhere to post the
> code online.
>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 25 Aug 2004 22:32:06 +0200
> X-Virus: 1
> From: Harald Welte <laforge@netfilter.org>
> Subject: Re: Linux 2.6.9-rc1
> To: Joshua Kwan <joshk@triplehelix.org>
> Cc: David Miller <davem@redhat.com>, Netfilter Development Mailinglist
> <netfilter-devel@lists.netfilter.org>, linux-kernel@vger.kernel.org
> Message-ID: <20040825203206.GS5824@sunbeam.de.gnumonks.org>
> Content-Type: text/plain; charset="us-ascii"
>
> On Wed, Aug 25, 2004 at 11:52:30AM -0700, Joshua Kwan wrote:
> > Linus Torvalds wrote:
> > >Harald Welte:
> > ...
> > > o [NETFILTER]: Make 'helper' list of ip_nat_core static
> > ...
> >
> > I suspect that this changeset[1] somehow caused this to happen (many
> > times) in dmesg:
> >
> > ASSERT net/ipv4/netfilter/ip_nat_helper.c:428 &ip_nat_lock writelocked
>
> yes, indeed.
>
> > It seems to be working properly (NATting two machines behind a local
> > network to the Internet.)
>
> The 'problem' is that we try to get a readlock while we're already
> protected under a write lock.
>
> Please see the following [quite trivial, but yet untested] patch:
>
> --- linux-2.6.9-rc1/net/ipv4/netfilter/ip_nat_core.c 2004-08-25 22:22:36.450340504 +0200
> +++ linux-2.6.9-rc1-find_helper/net/ipv4/netfilter/ip_nat_core.c 2004-08-25 22:28:37.668273271 +0200
> @@ -635,7 +635,7 @@
>
> /* If there's a helper, assign it; based on new tuple. */
> if (!conntrack->master)
> - info->helper = ip_nat_find_helper(&reply);
> + info->helper = __ip_nat_find_helper(&reply);
>
> /* It's done. */
> info->initialized |= (1 << HOOK2MANIP(hooknum));
> --- linux-2.6.9-rc1/net/ipv4/netfilter/ip_nat_helper.c 2004-08-25 22:22:36.453340376 +0200
> +++ linux-2.6.9-rc1-find_helper/net/ipv4/netfilter/ip_nat_helper.c 2004-08-25 22:27:47.880335112 +0200
> @@ -421,12 +421,18 @@
> }
>
> struct ip_nat_helper *
> +__ip_nat_find_helper(const struct ip_conntrack_tuple *tuple)
> +{
> + return LIST_FIND(&helpers, helper_cmp, struct ip_nat_helper *, tuple);
> +}
> +
> +struct ip_nat_helper *
> ip_nat_find_helper(const struct ip_conntrack_tuple *tuple)
> {
> struct ip_nat_helper *h;
>
> READ_LOCK(&ip_nat_lock);
> - h = LIST_FIND(&helpers, helper_cmp, struct ip_nat_helper *, tuple);
> + h = __ip_nat_find_helper(tuple);
> READ_UNLOCK(&ip_nat_lock);
>
> return h;
> --- linux-2.6.9-rc1/net/ipv4/netfilter/ip_nat_standalone.c 2004-08-25 22:22:36.461340035 +0200
> +++ linux-2.6.9-rc1-find_helper/net/ipv4/netfilter/ip_nat_standalone.c 2004-08-25 22:29:30.047102589 +0200
> @@ -394,4 +394,5 @@
> EXPORT_SYMBOL(ip_nat_mangle_tcp_packet);
> EXPORT_SYMBOL(ip_nat_mangle_udp_packet);
> EXPORT_SYMBOL(ip_nat_used_tuple);
> +EXPORT_SYMBOL(ip_nat_find_helper);
> MODULE_LICENSE("GPL");
>
> --
> - Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
> ============================================================================
> "Fragmentation is like classful addressing -- an interesting early
> architectural error that shows how much experimentation was going
> on while IP was being designed." -- Paul Vixie
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 189 bytes
> Desc: Digital signature
> Url : /pipermail/netfilter-devel/attachments/20040825/c33abda6/attachment.bin
>
> ------------------------------
>
> _______________________________________________
> netfilter-devel mailing list
> netfilter-devel@lists.netfilter.org
> https://lists.netfilter.org/mailman/listinfo/netfilter-devel
>
>
> End of netfilter-devel Digest, Vol 1, Issue 1257
> ************************************************
>
^ permalink raw reply [flat|nested] only message in thread