Re: netfilter-devel Digest, Vol 1, Issue 1257

Re: netfilter-devel Digest, Vol 1, Issue 1257

[linkai]

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
> ************************************************
>