Re: Patch suggestion for proxy arp on shaper interface

Re: Patch suggestion for proxy arp on shaper interface

[Roberto Arcomano]

Il 20:54, mercoledì 25 luglio 2001, hai scritto:
> Hello!
>
> > As I said in my first message, I tested it with 2.4.6 and it "appears" (I
> > tested it in a very little net) to work well
>
> The patch works right, I think. But it is so utterly ugly and its scope
> is so narrow, that I do think this is acceptable.
>
> Actually, you may use CBQ instead it does not create problems of this
> kind. Seems, scripts to setup it can be found in LRP. I can send it,
> but I am not sure that my copy is the newest.
>
> Alexey


Please send me script you was talking about.
I know that CBQ is a more recent (and I guess better) method to limit 
bandwidth, but I think also there are still many users of "shaper" device who 
would want to avoid proxy arp problems.

Thank you for all
Best Regards
Roberto Arcomano

Re: Patch suggestion for proxy arp on shaper interface

[kuznet]

Hello!

> As I said in my first message, I tested it with 2.4.6 and it "appears" (I 
> tested it in a very little net) to work well

The patch works right, I think. But it is so utterly ugly and its scope
is so narrow, that I do think this is acceptable.

Actually, you may use CBQ instead it does not create problems of this
kind. Seems, scripts to setup it can be found in LRP. I can send it,
but I am not sure that my copy is the newest.

Alexey

Patch suggestion for proxy arp on shaper interface

[Roberto Arcomano]

[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]

Hi all,
Recently I have had a problem with Linux proxy arp feature (using with shaper 
interface): when I machine starts up it was receiving a "IP conflits".
The problem is that Linux proxy_arp routine doesn't make difference between 
real interface (i.e. eth0) and shaper interface (i.e. shaper0 which has been 
attached to eth0).
I attach a first beta solution to the problem, which could be far from 
optimal! (I use a "strncmp", cause I didn't found another method to know if 
the device is a "shaper" device).


--- arp.c.orig  Wed May 16 19:21:45 2001
+++ arp.c       Sun Jul 22 19:31:20 2001
@@ -111,7 +111,7 @@
 
 #include <asm/system.h>
 #include <asm/uaccess.h>
-
+#include <linux/if_shaper.h>
 
 
 /*
@@ -767,10 +767,17 @@
                        }
                        goto out;
                } else if (IN_DEV_FORWARD(in_dev)) {
+                        char shflag=0;
+                        if ( (rt->u.dst.dev) &&
+                            (rt->u.dst.dev->priv) &&
+                            (((struct shaper *) rt->u.dst.dev->priv)->dev) &&
+                            (strncmp(rt->u.dst.dev->name,"shaper",6)==0) )
+                         shflag=1;
                        if ((rt->rt_flags&RTCF_DNAT) ||
-                           (addr_type == RTN_UNICAST  && rt->u.dst.dev != 
dev &&
+                           (addr_type == RTN_UNICAST  &&
+                           ( ((shflag) && ( ((struct shaper *) 
rt->u.dst.dev->priv)->dev != dev)) || ((!shflag) && (rt->u.dst.dev != dev)) ) 
&&
                             (IN_DEV_PROXY_ARP(in_dev) || 
pneigh_lookup(&arp_tbl, &tip, dev, 0)))) {
-                               n = neigh_event_ns(&arp_tbl, sha, &sip, dev);
+                               n = neigh_event_ns(&arp_tbl, sha, &sip, dev);
                                if (n)


The patch declare a variable (flag to know if the interface is shaper-like), 
investigate on private data of shaper device (where we can know what is the 
attached interface) and set the flag. After we consider the "attached" 
interface if flag is set.

I tested it under 2.4.6 on RedHat 7.1 with success (there is no more IP 
conflit).
Hope it'll useful.

Best Regards
Roberto Arcomano

[-- Attachment #2: diff file --]
[-- Type: text/x-c, Size: 1014 bytes --]

--- arp.c.orig	Wed May 16 19:21:45 2001
+++ arp.c	Sun Jul 22 19:31:20 2001
@@ -111,7 +111,7 @@
 
 #include <asm/system.h>
 #include <asm/uaccess.h>
-
+#include <linux/if_shaper.h>
 
 
 /*
@@ -767,10 +767,17 @@
 			}
 			goto out;
 		} else if (IN_DEV_FORWARD(in_dev)) {
+                        char shflag=0;
+                        if ( (rt->u.dst.dev) &&
+			     (rt->u.dst.dev->priv) &&
+			     (((struct shaper *) rt->u.dst.dev->priv)->dev) &&
+			     (strncmp(rt->u.dst.dev->name,"shaper",6)==0) )
+			  shflag=1;
 			if ((rt->rt_flags&RTCF_DNAT) ||
-			    (addr_type == RTN_UNICAST  && rt->u.dst.dev != dev &&
+			    (addr_type == RTN_UNICAST  && 
+			    ( ((shflag) && ( ((struct shaper *) rt->u.dst.dev->priv)->dev != dev)) || ((!shflag) && (rt->u.dst.dev != dev)) ) &&
 			     (IN_DEV_PROXY_ARP(in_dev) || pneigh_lookup(&arp_tbl, &tip, dev, 0)))) {
-				n = neigh_event_ns(&arp_tbl, sha, &sip, dev);
+			        n = neigh_event_ns(&arp_tbl, sha, &sip, dev);
 				if (n)
 					neigh_release(n);
 

Re: Patch suggestion for proxy arp on shaper interface

[Roberto Arcomano]

[-- Attachment #1: Type: text/plain, Size: 2548 bytes --]

Il 22:31, domenica 22 luglio 2001, Roberto Arcomano ha scritto:
> Hi all,
> Recently I have had a problem with Linux proxy arp feature (using with
> shaper interface): when I machine starts up it was receiving a "IP
> conflits". The problem is that Linux proxy_arp routine doesn't make
> difference between real interface (i.e. eth0) and shaper interface (i.e.
> shaper0 which has been attached to eth0).
> I attach a first beta solution to the problem, which could be far from
> optimal! (I use a "strncmp", cause I didn't found another method to know if
> the device is a "shaper" device).
>
>
> --- arp.c.orig  Wed May 16 19:21:45 2001
> +++ arp.c       Sun Jul 22 19:31:20 2001
> @@ -111,7 +111,7 @@
>
>  #include <asm/system.h>
>  #include <asm/uaccess.h>
> -
> +#include <linux/if_shaper.h>
>
>
>  /*
> @@ -767,10 +767,17 @@
>                         }
>                         goto out;
>                 } else if (IN_DEV_FORWARD(in_dev)) {
> +                        char shflag=0;
> +                        if ( (rt->u.dst.dev) &&
> +                            (rt->u.dst.dev->priv) &&
> +                            (((struct shaper *) rt->u.dst.dev->priv)->dev)
> && +                           
> (strncmp(rt->u.dst.dev->name,"shaper",6)==0) ) +                        
> shflag=1;
>                         if ((rt->rt_flags&RTCF_DNAT) ||
> -                           (addr_type == RTN_UNICAST  && rt->u.dst.dev !=
> dev &&
> +                           (addr_type == RTN_UNICAST  &&
> +                           ( ((shflag) && ( ((struct shaper *)
> rt->u.dst.dev->priv)->dev != dev)) || ((!shflag) && (rt->u.dst.dev != dev))
> ) &&
>                              (IN_DEV_PROXY_ARP(in_dev) ||
> pneigh_lookup(&arp_tbl, &tip, dev, 0)))) {
> -                               n = neigh_event_ns(&arp_tbl, sha, &sip,
> dev); +                               n = neigh_event_ns(&arp_tbl, sha,
> &sip, dev); if (n)
>
>
> The patch declare a variable (flag to know if the interface is
> shaper-like), investigate on private data of shaper device (where we can
> know what is the attached interface) and set the flag. After we consider
> the "attached" interface if flag is set.
>
> I tested it under 2.4.6 on RedHat 7.1 with success (there is no more IP
> conflit).
> Hope it'll useful.
>
> Best Regards
> Roberto Arcomano

Please someone takes a look at it! This is a bug of proxy arp feature (when 
talking with shaper interface) could be correct (for example using my patch).
Thank you for your help

Best Regards
Roberto Arcomano




[-- Attachment #2: Diff file for arp.c --]
[-- Type: text/x-c, Size: 1014 bytes --]

--- arp.c.orig	Wed May 16 19:21:45 2001
+++ arp.c	Sun Jul 22 19:31:20 2001
@@ -111,7 +111,7 @@
 
 #include <asm/system.h>
 #include <asm/uaccess.h>
-
+#include <linux/if_shaper.h>
 
 
 /*
@@ -767,10 +767,17 @@
 			}
 			goto out;
 		} else if (IN_DEV_FORWARD(in_dev)) {
+                        char shflag=0;
+                        if ( (rt->u.dst.dev) &&
+			     (rt->u.dst.dev->priv) &&
+			     (((struct shaper *) rt->u.dst.dev->priv)->dev) &&
+			     (strncmp(rt->u.dst.dev->name,"shaper",6)==0) )
+			  shflag=1;
 			if ((rt->rt_flags&RTCF_DNAT) ||
-			    (addr_type == RTN_UNICAST  && rt->u.dst.dev != dev &&
+			    (addr_type == RTN_UNICAST  && 
+			    ( ((shflag) && ( ((struct shaper *) rt->u.dst.dev->priv)->dev != dev)) || ((!shflag) && (rt->u.dst.dev != dev)) ) &&
 			     (IN_DEV_PROXY_ARP(in_dev) || pneigh_lookup(&arp_tbl, &tip, dev, 0)))) {
-				n = neigh_event_ns(&arp_tbl, sha, &sip, dev);
+			        n = neigh_event_ns(&arp_tbl, sha, &sip, dev);
 				if (n)
 					neigh_release(n);
 

Re: Patch suggestion for proxy arp on shaper interface

[Alexey Kuznetsov]

Hello!

> Recently I have had a problem with Linux proxy arp feature (using with shaper

You must not enable proxy arp, when routing is asymmetric or configure
it manually. Shaper device is one of cases, when proxy arp cannot work
correctly.

Alexey

Re: Patch suggestion for proxy arp on shaper interface

[Roberto Arcomano]

Il 00:31, mercoledì 25 luglio 2001, Alexey Kuznetsov ha scritto:
> Hello!
>
> > Recently I have had a problem with Linux proxy arp feature (using with
> > shaper
>
> You must not enable proxy arp, when routing is asymmetric or configure
> it manually. Shaper device is one of cases, when proxy arp cannot work
> correctly.
>
> Alexey
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Hello,
First thank you for your answer. I must enable proxy arp cause I need it with 
shaper interface. During configuration in user mode I noticed that kernel 
sees shaper device instead of using its device attached (in fact I received 
from a lan machine a "IP conflit"): I think that it is more correct to use 
the device attached to shaper, for 2 reasons:
1-) shaper is not a "real" interface (I mean directly connected to a wire or 
wireless physical interface), while proxy arp sends "ARP REPLY" using 
physical devices only.

2-) Proxy arp would become more flexible, also using proxy arp interface: 
proxy arp is a great thing, particulary with complex wireless networks. Like 
all good thinks I think that we have to keep it under kernel to keep simplify 
sysadmin life!

Anyway, there are some applications that need shaper and proxy arp (for 
example using a traffic manager behind a firewall).

As I said in my first message, I tested it with 2.4.6 and it "appears" (I 
tested it in a very little net) to work well (but I think performance aren't 
so well...).

Thank you for your help.
Best regards
Roberto Arcomano