Patch suggestion for proxy arp on shaper interface

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).

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

@@ -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);
 

Il 22:31, domenica 22 luglio 2001, Roberto Arcomano ha scritto:

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

@@ -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);
 

Hello!

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

Il 00:31, mercoledì 25 luglio 2001, Alexey Kuznetsov ha scritto:

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