Re: [PATCH] proxy arp bug on shaper device

Re: [PATCH] proxy arp bug on shaper device

[Roberto Arcomano]

> 	If this is true then you have to provide support for all
> other devices, for example, tunnels.

Yes, unfortunately I tried but without success to extend patch to all that: I
need some info to do it (particolary I cannot understand how extract
"priv->dev" from a unknown device cause each (for each device) could be
different.....)

 The common for such setups is

> that asymmetric routing is used. OTOH, your change drops the ARP
> probe without updating the neighbour state. BTW, do you see any
> incoming traffic on the shaper device?

There should not be incoming traffic from shaper device (I never saw it).

Thank you for your help
Roberto Arcomano

> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>

-------------------------------------------------------

Re: [PATCH] proxy arp bug on shaper device

[Roberto Arcomano]

Hello Julian,
when I decided to write the patch I had to solve following problem:
LINUX with shaper devices and proxy arp   ----    WIN clients (which couldn't
start up).

I tried to solve problem with simple trick (like disable proxy arp or change
routing info), but I couldn't. Then, I realized that the problem was at
"kernel" level, cause I had:

host           interface
HOST1      shaper0 (eth0)

So, when HOST1 started up, kernel (wrongly) sent it an ARP REPLY cause source
interface was different from destination interface (for the host). This is
really wrong, I think, cause shaper0 is the SAME interface (at physical
level, where proxy arp works) of eth0 (it uses same first 2 level ISO/OSI,
shaper has to be managed exactly as eth0).

In the end I say that I prefer kernel mode solution, rather than use mode
solution.

I Hope to has been clear.
Let me know what you think.
Regards
Roberto Arcomano

Il 15:24, martedì 18 settembre 2001, hai scritto:
> Hello,
>
> On Tue, 18 Sep 2001, Roberto Arcomano wrote:
> > Hello Julian,
> > thank you very much for your answer. I'm sure your solution would be ok,
> > but I think the right solution should be modify the kernel, cause, shaper
> > device cannot be managed like a physical device (I mean about route check
> > before sending ARP REPLY): I think it is more clear than other solutions.
>
> 	If this is true then you have to provide support for all
> other devices, for example, tunnels. The common for such setups is
> that asymmetric routing is used. OTOH, your change drops the ARP
> probe without updating the neighbour state. BTW, do you see any
> incoming traffic on the shaper device?
>
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>

-------------------------------------------------------

Re: [PATCH] proxy arp bug on shaper device

[Julian Anastasov]

	Hello,

Roberto Arcomano wrote:

> This patch should correct proxy arp feature in shaper devices forcing kernel
> checking (before sending ARP REPLY) for "physical" device (i.e. eth0) instead
> of "shaper" device (i.e. shaper0): in this way we avoid useless ARP REPLY and
> "IP CONFLICT" messages on client hosts.

	You can also try to stop the ARP for your asymmetric route
using the per-route ARP flag (patch for 2.4 only):

http://www.linux-vs.org/~julian/
go to "Solution 2: Per-route ARP flag"

May be you need to add ip rule before reaching table main, i.e.
to use such commands:

ip rule add prio 100 to shaped_network/24 iif eth0 table 100
ip route add shaped_network/24 dev shaper0 table 100 noarp

I assume (if I understand your setup correctly) this command will
drop the ARP probes coming through eth0 and asking for non-local IP
addresses on shaped networks on shaper device(s). You can put all
your networks reachable through shaper devices in table 100. All
other networks on non-shaper devices will be reported from the
proxy_arp.

	I don't know whether this will work but you can try. At
least, I don't see a way the other device flags related to ARP
to work for you: hidden (only in 2.2), arp_filter and rp_filter.

Regards

--
Julian Anastasov <ja@ssi.bg>

[PATCH] proxy arp bug on shaper device

[Roberto Arcomano]

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

Hi all,
This patch should correct proxy arp feature in shaper devices forcing kernel 
checking (before sending ARP REPLY) for "physical" device (i.e. eth0) instead 
of "shaper" device (i.e. shaper0): in this way we avoid useless ARP REPLY and 
"IP CONFLICT" messages on client hosts.

I tested it for many days and it has been worked well.
See July messages for discussion about it.

Thank you for your great support.
Best Regards
Roberto arcomano

[-- Attachment #2: PATCH --]
[-- Type: text/x-c, Size: 2448 bytes --]

diff -ur linux-2.4.9.orig/drivers/net/shaper.c linux-2.4.9/drivers/net/shaper.c
--- linux-2.4.9.orig/drivers/net/shaper.c	Thu Jun 28 02:10:55 2001
+++ linux-2.4.9/drivers/net/shaper.c	Tue Sep 11 13:20:09 2001
@@ -670,6 +670,7 @@
 	dev->addr_len		= 0;
 	dev->tx_queue_len	= 10;
 	dev->flags		= 0;
+	dev->features		|= NETIF_F_SHAPER;
 		
 	/*
 	 *	Shaper is ok
diff -ur linux-2.4.9.orig/include/linux/if_shaper.h linux-2.4.9/include/linux/if_shaper.h
--- linux-2.4.9.orig/include/linux/if_shaper.h	Wed Aug 18 20:38:47 1999
+++ linux-2.4.9/include/linux/if_shaper.h	Tue Sep 11 13:20:00 2001
@@ -14,6 +14,8 @@
 #define SHAPER_MAXSLIP	2
 #define SHAPER_BURST	(HZ/50)		/* Good for >128K then */
 
+#define IS_SHAPERDEVICE(dev) ((dev)->features & NETIF_F_SHAPER)
+
 struct shaper
 {
 	struct sk_buff_head sendq;
diff -ur linux-2.4.9.orig/include/linux/netdevice.h linux-2.4.9/include/linux/netdevice.h
--- linux-2.4.9.orig/include/linux/netdevice.h	Sun Sep  9 16:15:40 2001
+++ linux-2.4.9/include/linux/netdevice.h	Tue Sep 11 13:20:04 2001
@@ -345,6 +345,7 @@
 #define NETIF_F_DYNALLOC	16	/* Self-dectructable device. */
 #define NETIF_F_HIGHDMA		32	/* Can DMA to high memory. */
 #define NETIF_F_FRAGLIST	64	/* Scatter/gather IO. */
+#define NETIF_F_SHAPER  	128	/* Shaper device. */
 
 	/* Called after device is detached from network. */
 	void			(*uninit)(struct net_device *dev);
diff -ur linux-2.4.9.orig/net/ipv4/arp.c linux-2.4.9/net/ipv4/arp.c
--- linux-2.4.9.orig/net/ipv4/arp.c	Wed May 16 19:21:45 2001
+++ linux-2.4.9/net/ipv4/arp.c	Tue Sep 11 13:19:51 2001
@@ -111,8 +111,7 @@
 
 #include <asm/system.h>
 #include <asm/uaccess.h>
-
-
+#include <linux/if_shaper.h>
 
 /*
  *	Interface to generic neighbour cache.
@@ -767,8 +766,15 @@
 			}
 			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) &&
+			     (IS_SHAPERDEVICE(rt->u.dst.dev)) )
+			  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);
 				if (n)

[-- Attachment #3: README file --]
[-- Type: text/plain, Size: 2610 bytes --]

Subject: PATCH to update proxy arp feature on shaper device

Author: Roberto Arcomano, berto@fatamorgana.com,
        http://www.fatamorgana.com/bertolinux

Date: 9/9/2001

Description: Shaper device is seen by the kernel like a 
             different device (i.e. shaper0) than the 
	     physical one (i.e. eth0)  to which is attached:
	     so kernel always issues an "ARP REPLY" 
	     (if proxy arp is active on shaper physical 
	     interface): this prevent us from use proxy arp on 
	     a shaper device cause, during turning on client
	     machine, we would receive an "IP conflit" message.
	     
Solution: Patch consists in 4 files:
	  a-) "include/linux/netdevice.h", where we add a new
	      net feature, NETIF_F_SHAPER which will help
	      us to understand if a device is a shaper one.
	      
	  b-) "drivers/net/shaper.c", in "shaper_probe" function
	      we set NETIF_F_SHAPER flag for a new shaper
	      device.
	  
	  c-) "include/linux/if_shaper.h" where we add the macro
	      IS_SHAPERDEVICE, used to know if the device is a 
	      shaper one (it checks NETIF_F_SHAPER flag in 
	      features field, under "netdevice" struct).
	
	  d-) "net/ipv4/arp.c" where finally we modify proxy arp;
	      We use shflag to determine if we are managing a
	      shaper device (with IS_SHAPERDEVICE macro): in 
	      this case we check 
	      "rt->u.dst.dev->priv->dev" (physical device) 
	      instead of 
	      "rt->u.dst.dev" (shaper device)
	      while if the device is a non shaper one, we check 
	      rt->u.dst.dev (anded with !shflag)
	      
TODO:	I used "features" field in netdevice struct: maybe it could
        be choosen another place where to put the shaper flag.	      
	      
Tests: I tested new feature using 3 PCs like that:

           CLIENT1  ------------- LINUX ------------- CLIENT2 
     	                   shaper0      ppp0
	                    [eth0]
	   
       LINUX host has proxy arp and shaper enabled, with CLIENT1
       reachable via shaper0.
       With classic proxy arp, when I turn on CLIENT machine I 
       receive an "IP conflit" from OS, while using patched version 
       there are no problems.
       Proxy arp still does its work cause, if I give CLIENT2 IP
       address to CLIENT1 machine, I receive (from CLIENT1 OS) a
       IP busy message.

       Also tests on commercial server have been done with good
       results.

       Kernel version tested is 2.4.9
       

Final notes: It should be very simple to port patch to older
             kernel version (2.0.xx, 2.1.xx, 2.2.xx, 2.3.xx)