[2.4 PATCH] bugfix: ARP respond on all devices

[2.4 PATCH] bugfix: ARP respond on all devices

[Bas Bloemsaat]

Yesterday (20030726) I found out, that with two NICs on one ethernet
segment, ARPing for one IP address gave me two answers, one from each NIC
with the MAC address from each of them. They each have a seperate IP
address. First I thought the NICs where doing proxy arp on each other,
but it turned out that this wasn't the case. On closer examination it
turned out that any ARP request to a local IP resulted in a response,
even if the devices were on different subnets or ethernet segments.

I learned from the kernel sources that any NIC receiving an ARP request
for any local IP adress would respond to that request. Among others, that
has the following implications:
- when you have two NICs same ethernet segment, only one of them is used:
they both respond to any ARP request. As only the first response is ever
used (fasted router), only the NIC that responds first receives any
traffic. This NIC may or may not be bound to the destination IP. It may
not even be reachable because of iptables-rules. This also defeats a
common form of load balancing.
- when you have two NICs on seperate ethernet segments, for example on a
firewall, it is possible to probe one NIC for the IP address of the other.
This can be used to gain information about the inside network of the
firewall, which is a (minor) security risk. While this is not really
practical because every IP address has to be tried, often the inside is of
a limit range (10.x.x.x, 192.168.x.x), which makes it useful.

I think this is unwanted behaviour. This patch corrects the situation. It
makes every device only respond to ARP requests for IP addresses bound to
that device, not all local IP addresses. Proxy ARP still applies as
before.

The patch was made from 2.4.21. It patches 2.4.22-pre8 cleanly and tests
okay on both. Please apply.


diff -urN linux-2.4.21.orig/include/linux/inetdevice.h linux-2.4.21-okayclean/include/linux/inetdevice.h
--- linux-2.4.21.orig/include/linux/inetdevice.h	2002-08-03 02:39:45.000000000 +0200
+++ linux-2.4.21-okayclean/include/linux/inetdevice.h	2003-07-27 18:51:28.000000000 +0200
@@ -86,6 +86,7 @@
 extern u32		inet_select_addr(const struct net_device *dev, u32 dst, int scope);
 extern struct in_ifaddr *inet_ifa_byprefix(struct in_device *in_dev, u32 prefix, u32 mask);
 extern void		inet_forward_change(void);
+extern int 		inet_addr_local_dev(struct in_device *in_dev, u32 addr);

 static __inline__ int inet_ifa_match(u32 addr, struct in_ifaddr *ifa)
 {
diff -urN linux-2.4.21.orig/net/ipv4/arp.c linux-2.4.21-okayclean/net/ipv4/arp.c
--- linux-2.4.21.orig/net/ipv4/arp.c	2002-11-29 00:53:15.000000000 +0100
+++ linux-2.4.21-okayclean/net/ipv4/arp.c	2003-07-27 21:12:17.000000000 +0200
@@ -66,6 +66,7 @@
  *		Alexey Kuznetsov:	new arp state machine;
  *					now it is in net/core/neighbour.c.
  *		Krzysztof Halasa:	Added Frame Relay ARP support.
+ *		Bas Bloemsaat	:	(20030727) Fixed respond on all devices bug
  */

 #include <linux/types.h>
@@ -766,7 +767,9 @@
 		rt = (struct rtable*)skb->dst;
 		addr_type = rt->rt_type;

-		if (addr_type == RTN_LOCAL) {
+
+		/* check if arp is for this device */
+		if (inet_addr_local_dev(in_dev,tip)) {
 			n = neigh_event_ns(&arp_tbl, sha, &sip, dev);
 			if (n) {
 				int dont_send = 0;
@@ -778,6 +781,8 @@
 				neigh_release(n);
 			}
 			goto out;
+
+		/* check if we can and have to proxy it */
 		} else if (IN_DEV_FORWARD(in_dev)) {
 			if ((rt->rt_flags&RTCF_DNAT) ||
 			    (addr_type == RTN_UNICAST  && rt->u.dst.dev != dev &&
diff -urN linux-2.4.21.orig/net/ipv4/devinet.c linux-2.4.21-okayclean/net/ipv4/devinet.c
--- linux-2.4.21.orig/net/ipv4/devinet.c	2003-06-13 16:51:39.000000000 +0200
+++ linux-2.4.21-okayclean/net/ipv4/devinet.c	2003-07-27 18:50:19.000000000 +0200
@@ -199,6 +199,17 @@
 	return 0;
 }

+int
+inet_addr_local_dev(struct in_device *in_dev, u32 addr)
+{
+	for_ifa(in_dev) {
+		if (!(addr^ifa->ifa_address))
+			return -1;
+	} endfor_ifa(in_dev);
+
+	return 0;
+}
+
 static void
 inet_del_ifa(struct in_device *in_dev, struct in_ifaddr **ifap, int destroy)
 {

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Sun, 27 Jul 2003 22:52:48 +0200 (CEST)
Bas Bloemsaat <bloemsaa@xs4all.nl> wrote:

> I think this is unwanted behaviour.

Not a bug.  This behavior is on purpose.

Use source based routes if you want to control how ARP
responses behave in this way.

This is becomming a FAQ.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Carlos Velasco]

On 27/07/2003 at 22:52 Bas Bloemsaat wrote:

>I learned from the kernel sources that any NIC receiving an ARP request
>for any local IP adress would respond to that request. Among others, that
>has the following implications:
>- when you have two NICs same ethernet segment, only one of them is used:
>they both respond to any ARP request. As only the first response is ever
>used (fasted router), only the NIC that responds first receives any
>traffic. This NIC may or may not be bound to the destination IP. It may
>not even be reachable because of iptables-rules. This also defeats a
>common form of load balancing.

I stepped into the same problems you have reported here.

There's a feature to do linux to behave like other OS and systems, called "hidden".
However it's not included into the default kernel main stream. Although IMHO IT SHOULD BE.
Here is the patch:
http://www.ssi.bg/~ja/#hidden

Extracted from http://www.linuxvirtualserver.org/docs/arp.html:
===
Linux kernel 2.0.xx doesn't do arp response on loopback alias and tunneling interfaces, it is good for the LVS cluster. However, Linux kernel 2.2.xx does all arp responses of all its IP addresses except the loopback addresses (127.0.0.0/255.0.0.0) and multicast addresses. 
===

Currently linux is the only OS those I have tried with this behaviour:

Solaris 8 -> does not send ARP reply of other interface.
Cisco -> does not send ARP reply of other interface.
Windows 2000, XP -> does not send ARP reply of other interface.
Linux 2.6.0-pre1, 2.4.20, 2.4.21 -> DOES send ARP reply of other interface


>- when you have two NICs on seperate ethernet segments, for example on a
>firewall, it is possible to probe one NIC for the IP address of the other.
>This can be used to gain information about the inside network of the
>firewall, which is a (minor) security risk. While this is not really
>practical because every IP address has to be tried, often the inside is of
>a limit range (10.x.x.x, 192.168.x.x), which makes it useful.

Yes, minor security problem arise with this _INTENTIONAL_ behaviour of linux networking.

The official approach is that you play with routing and netfilter/arpfilter to solve this _INTENTIONAL_ behaviour and make linux behave like other OS do.

The unofficial (not in the kernel main stream, reason unknow) is to use the "hidden patch".
This works using a /proc switch: /proc/sys/net/ipv4/conf/<XXX>/hidden, so it should not break anything.
However is not into the main kernel.

Regards,
Carlos Velasco

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 28 Jul 2003 01:40:47 +0200
"Carlos Velasco" <carlosev@newipnet.com> wrote:

> I stepped into the same problems you have reported here.

No, your problem was completely different.

> There's a feature to do linux to behave like other OS and systems, called "hidden".

WRONG!  People please stop this misinformation already.

Bas's problem can be solved by him giving a "preferred source"
to each of his IPV4 routes and setting the "arpfilter" sysctl
variable for his devices to "1".

This particular case has been discussed to death in the past
and I really recommend people read up there before dragging this
out further.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Carlos Velasco]

On 27/07/2003 at 16:46 David S. Miller wrote:

>No, your problem was completely different.

The setting who show up the problem was different. The problem is the same.

>Bas's problem can be solved by him giving a "preferred source"
>to each of his IPV4 routes and setting the "arpfilter" sysctl
>variable for his devices to "1".

Yes, it's another approach to solve his problem. But he must play with routing.

With the "hidden patch" the only thing he needs is to switch the feature on.

Regards,
Carlos Velasco

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 28 Jul 2003 01:58:25 +0200
"Carlos Velasco" <carlosev@newipnet.com> wrote:

> On 27/07/2003 at 16:46 David S. Miller wrote:
> >Bas's problem can be solved by him giving a "preferred source"
> >to each of his IPV4 routes and setting the "arpfilter" sysctl
> >variable for his devices to "1".
> 
> Yes, it's another approach to solve his problem. But he must play with routing.

Precisely he must, because he has misconfigured routes for the
behavior he desires.

His problem is about source address selection when trying to
contact a given destination.

If there is no specific source address specified, the kernel may
legally use any source address, and this decision extends to ARP
handling as well.

It's totally illogical to say that it's easier for him to patch his
kernel and reboot it than fix his route configuration.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Carlos Velasco]

On 27/07/2003 at 16:58 David S. Miller wrote:

>> On 27/07/2003 at 16:46 David S. Miller wrote:
>> >Bas's problem can be solved by him giving a "preferred source"
>> >to each of his IPV4 routes and setting the "arpfilter" sysctl
>> >variable for his devices to "1".
>> 
>> Yes, it's another approach to solve his problem. But he must play with
>routing.
>
>Precisely he must, because he has misconfigured routes for the
>behavior he desires.
>
>His problem is about source address selection when trying to
>contact a given destination.

Bas said:
==
>but it turned out that this wasn't the case. On closer examination it
>turned out that any ARP request to a local IP resulted in a response,
>even if the devices were on different subnets or ethernet segments.
==

It's the "hidden" switch.... again.
I suppose that Bas can confirm it.

>It's totally illogical to say that it's easier for him to patch his
>kernel and reboot it than fix his route configuration.

Sure... it WOULD be the easiest thing if it would be into the kernel main stream. But it isn't, making linux behave different to other OS and systems without any way or feature to make it behave like the others.

Regards,
Carlos Velasco

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

[ Please wrap your lines at 72 characters, you emails are really
  difficult to read and reply to, thanks. ]

On Mon, 28 Jul 2003 02:11:59 +0200
"Carlos Velasco" <carlosev@newipnet.com> wrote:

> On 27/07/2003 at 16:58 David S. Miller wrote:
> >His problem is about source address selection when trying to
> >contact a given destination.
> 
> Bas said:
> ==
> >but it turned out that this wasn't the case. On closer examination it
> >turned out that any ARP request to a local IP resulted in a response,
> >even if the devices were on different subnets or ethernet segments.
> ==
> 
> It's the "hidden" switch.... again.
> I suppose that Bas can confirm it.

This only means your problem can also be fixed by correcting
your routing tables.

> >It's totally illogical to say that it's easier for him to patch his
> >kernel and reboot it than fix his route configuration.
> 
> Sure... it WOULD be the easiest thing if it would be into the kernel
> >main stream. But it isn't, making linux behave different to other
> >OS and systems without any way or feature to make it behave like
> >the others.

Show me the standard that Linux violates by behaving in this way?
There are none, our behavior is perfectly acceptable.

Other systems do not give you the capabilities our routing layer does,
such as route based source address selections.  So it is no surprise
that they behave differently in this area.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Carlos Velasco]

On 27/07/2003 at 17:14 David S. Miller wrote:

>[ Please wrap your lines at 72 characters, you emails are really
>  difficult to read and reply to, thanks. ]

Done.

>This only means your problem can also be fixed by correcting
>your routing tables.

Playing with routing table and using arp_filter.
Or using the hidden patch.
Or using a tool for filtering arp as iparp or netfilter/arpfilter.

IMHO "hidden" is the simpliest (provided it's compiled in the kernel).

>Show me the standard that Linux violates by behaving in this way?
>There are none, our behavior is perfectly acceptable.

Sure it's... I have never said it's wrong, I only say that its
behaviour is different to other OS and it's NOT usual.
And on certain scenaries it could be a desired behaviour.

>Other systems do not give you the capabilities our routing layer does,
>such as route based source address selections.  So it is no surprise
>that they behave differently in this area.

Problem is that linux is unable to behave like the other OS and systems
do in a simple way.
The easy way is the "hidden" patch, if it's applied in the kernel.

Regards,
Carlos Velasco

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 28 Jul 2003 02:35:21 +0200
"Carlos Velasco" <carlosev@newipnet.com> wrote:

> On 27/07/2003 at 17:14 David S. Miller wrote:
> >Other systems do not give you the capabilities our routing layer does,
> >such as route based source address selections.  So it is no surprise
> >that they behave differently in this area.
> 
> Problem is that linux is unable to behave like the other OS and systems
> do in a simple way.
> The easy way is the "hidden" patch, if it's applied in the kernel.

Not true, anyone is free to design a graphical GUI or shell script (or
even a wrapper for the /sbin/ip tool) that gives you the default
behavior you want, without any user interaction whatsoever.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Carlos Velasco]

On 27/07/2003 at 17:36 David S. Miller wrote:

>> The easy way is the "hidden" patch, if it's applied in the kernel.
>
>Not true, anyone is free to design a graphical GUI or shell script (or
>even a wrapper for the /sbin/ip tool) that gives you the default
>behavior you want, without any user interaction whatsoever.

Anyone is free to do many things.
But if the hidden patch and /proc switch would be in the main kernel,
it would be the simpliest way to solve all these "problems" (with an
echo "1" and without filtering or using iproute2).

Regards,
Carlos Velasco
 

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 28 Jul 2003 02:53:09 +0200
"Carlos Velasco" <carlosev@newipnet.com> wrote:

> But if the hidden patch and /proc switch would be in the main kernel,
> it would be the simpliest way to solve all these "problems" (with an
> echo "1" and without filtering or using iproute2).

With or without your suggestion, people have to do something
different.

This doesn't even address all the problems there are with
the hidden patch.  It does things that belong on the netfilter
level and not on the ARP/routing level.

Again, I'd like you to read all the discussions that have happened on
this topic in the past, in particular those made by Alexey Kuznetsov
on this topic.  He gives very clear and concise reasons why the
"hidden" patch is logically doing things in the wrong part of the
kernel, and therefore won't ever be put into the tree.

Assorted 2.6.0-test2 build warnings

[J.C. Wren]

Assorted warnings building 2.6.0-test2, on an Athlon:

  CC      fs/ntfs/super.o
fs/ntfs/super.c: In function `is_boot_sector_ntfs':
fs/ntfs/super.c:375: warning: integer constant is too large for "long" type

  CC      fs/smbfs/ioctl.o
fs/smbfs/ioctl.c: In function `smb_ioctl':
fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type
fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type
fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type
fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type

  CC      drivers/char/vt_ioctl.o
drivers/char/vt_ioctl.c: In function `do_kdsk_ioctl':
drivers/char/vt_ioctl.c:85: warning: comparison is always false due to limited range of data type
drivers/char/vt_ioctl.c:85: warning: comparison is always false due to limited range of data type
drivers/char/vt_ioctl.c: In function `do_kdgkb_ioctl':
drivers/char/vt_ioctl.c:211: warning: comparison is always false due to limited range of data type

  CC      drivers/char/keyboard.o
drivers/char/keyboard.c: In function `k_fn':
drivers/char/keyboard.c:665: warning: comparison is always true due to limited range of data type

  CC [M]  drivers/i2c/i2c-sensor.o
drivers/i2c/i2c-sensor.c: In function `i2c_detect':
drivers/i2c/i2c-sensor.c:54: warning: `check_region' is deprecated (declared at include/linux/ioport.h:117)

  CC      drivers/video/matrox/matroxfb_g450.o
drivers/video/matrox/matroxfb_g450.c: In function `g450_compute_bwlevel':
drivers/video/matrox/matroxfb_g450.c:129: warning: duplicate `const'
drivers/video/matrox/matroxfb_g450.c:130: warning: duplicate `const'

  AS      arch/i386/boot/setup.o
arch/i386/boot/setup.S: Assembler messages:
arch/i386/boot/setup.S:165: Warning: value 0x37ffffff truncated to 0x37ffffff

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Carlos Velasco]

On 27/07/2003 at 17:55 David S. Miller wrote:

>With or without your suggestion, people have to do something
>different.

Just enabling the hidden switch solved my setting and I think it solves
most of "problem" settings.

>This doesn't even address all the problems there are with
>the hidden patch.  It does things that belong on the netfilter
>level and not on the ARP/routing level.

Well... it's just your opinion... other OS and systems don't use
netfilter of firewalling at all (ex. Win) and behave like with "hidden"
applied.
Really, the only one I have tested that not do it is Linux 2.2+

For me (not a kernel developer), my world are the OSI layers, and the
isolation of the interfaces at layer 2 IMHO should be in the kernel not
any firewall module that you must install, tune and configure.

>Again, I'd like you to read all the discussions that have happened on
>this topic in the past, in particular those made by Alexey Kuznetsov
>on this topic.  He gives very clear and concise reasons why the
>"hidden" patch is logically doing things in the wrong part of the
>kernel, and therefore won't ever be put into the tree.

I will look... but doing arp filter is not a real simple solution in
any way.

Regards,
Carlos Velasco

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 28 Jul 2003 03:23:02 +0200
"Carlos Velasco" <carlosev@newipnet.com> wrote:

> On 27/07/2003 at 17:55 David S. Miller wrote:
> >With or without your suggestion, people have to do something
> >different.
> 
> Just enabling the hidden switch solved my setting and I think it solves
> most of "problem" settings.

So do my suggestions.

I don't deny that it fixes your problem, that is not what
we're talking about.  We're talking about how one should
fix the problem, and I'm trying to show you why "hidden"
patch is not the answer to that.

> >This doesn't even address all the problems there are with
> >the hidden patch.  It does things that belong on the netfilter
> >level and not on the ARP/routing level.
> 
> Well... it's just your opinion... other OS and systems don't use
> netfilter of firewalling at all (ex. Win) and behave like with "hidden"
> applied.

Ummm, with "hidden" you still have to make a configuration change.

Second of all, "hidden" makes the kernel behave in a non-RFC compliant
way.  This is the categorization that I use to determine if something
belongs on the netfilter level or not.

If something changes the way in which the Linux networking
behaves wrt. RFCs, this "operation" belongs at the netfilter level.

This is true for the "hidden" patch.  It causes the system to
ignore ARP requests it should respond to.

On the other hand, the "arpfilter" sysctl setting makes the kernel
still behave in an RFC compliant manner, it only responds to ARPs
on interfaces it would use to speak to the requestor.

> Really, the only one I have tested that not do it is Linux 2.2+

Yes, we removed "hidden" from 2.2.x in lieu of "arpfilter" sysctl
and the netfilter ARP filtering module.

> For me (not a kernel developer), my world are the OSI layers,

OSI layers have nothing to do with the problem we are discussing.

BTW, OSI layers are how networking stacks are described in textbooks
and standards and far away from how one should implement said stack.
Van Jacobson even said this once :-)

> I will look... but doing arp filter is not a real simple solution in
> any way.

It would be really nice if people might consider that it could even be
possible to make things like the IPVS layer install the appropriate
NETFILTER_ARP chain rules when the IPVS configuration installed dictates
that one is needed.

People using IPVS wouldn't even need to do _ANYTHING_ if IPVS were
to do that.

And all of that would be _FINE_ because like ARP netfilter, IPVS lies
inside of netfilter where such things which change networking behavior
semantics radically belong.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Ben Greear]

David S. Miller wrote:
> On Sun, 27 Jul 2003 22:52:48 +0200 (CEST)
> Bas Bloemsaat <bloemsaa@xs4all.nl> wrote:
> 
> 
>>I think this is unwanted behaviour.
> 
> 
> Not a bug.  This behavior is on purpose.

What is the benefit of having it work as it does currently
in the standard kernel?  I too was supprised to find it works
this way, but have since converted to use source-routes.

Interestingly, can only use 252 or so source routes because
the rfc for netlink only gives us an 8-bit identifier for the
route id, so this still breaks if you want to run lots of
vlans or something like that.

Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David Lang]

can a summary of this discussion get written and put into the
documentation directory so that every time a new person stubles on this
feature we don't have to go through this discussion again?

David Lang

P.S. there are standards that are written documents and there are
standards that are 'how everyone does it' for the most part Linux follows
both types of standards, in this case the network team has decided to
ignore the 'how everyone else does it' standards becouse there is nothing
in a written standard that they are violating

 On Sun, 27 Jul
2003, David S. Miller wrote:

> Date: Sun, 27 Jul 2003 17:55:57 -0700
> From: David S. Miller <davem@redhat.com>
> To: Carlos Velasco <carlosev@newipnet.com>
> Cc: bloemsaa@xs4all.nl, marcelo@conectiva.com.br, netdev@oss.sgi.com,
>      linux-net@vger.kernel.org, layes@loran.com, torvalds@osdl.org,
>      linux-kernel@vger.kernel.org
> Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices
>
> On Mon, 28 Jul 2003 02:53:09 +0200
> "Carlos Velasco" <carlosev@newipnet.com> wrote:
>
> > But if the hidden patch and /proc switch would be in the main kernel,
> > it would be the simpliest way to solve all these "problems" (with an
> > echo "1" and without filtering or using iproute2).
>
> With or without your suggestion, people have to do something
> different.
>
> This doesn't even address all the problems there are with
> the hidden patch.  It does things that belong on the netfilter
> level and not on the ARP/routing level.
>
> Again, I'd like you to read all the discussions that have happened on
> this topic in the past, in particular those made by Alexey Kuznetsov
> on this topic.  He gives very clear and concise reasons why the
> "hidden" patch is logically doing things in the wrong part of the
> kernel, and therefore won't ever be put into the tree.
> -
> 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/
>

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Sun, 27 Jul 2003 21:37:10 -0700 (PDT)
David Lang <david.lang@digitalinsight.com> wrote:

> P.S. there are standards that are written documents and there are
> standards that are 'how everyone does it' for the most part Linux follows
> both types of standards, in this case the network team has decided to
> ignore the 'how everyone else does it' standards becouse there is nothing
> in a written standard that they are violating

Keep in mind that we implemented sys_sendfile() with different
arguments and semantics than everyone else.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bas Bloemsaat]

Hi all,

> > Not a bug.  This behavior is on purpose.
First of all I'm sorry I rubbed some old sores. I didn't know the behaviour was on purpose, and I did google for it. Could have
saved my weekend, had I known.

> >Bas's problem can be solved by him giving a "preferred source"
> >to each of his IPV4 routes and setting the "arpfilter" sysctl
> >variable for his devices to "1".
>
> Yes, it's another approach to solve his problem. But he must play with routing.

Routing isn't solving anything here, it's too dynamic. Only one of the devices has a fixed IP, and handles a link to the outside,
among others. The other is on DHCP: addresses can change without warning. Both are on the same ethernet segment.

I've looked at the hidden patch, and it's capable of doing this right. I do think this has to be solved at the device layer. It's
quite counter intuitive the way it is now. My vote goes to hidden.

Regards,
Bas

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Carlos Velasco]

On 27/07/2003 at 18:35 David S. Miller wrote:

>I don't deny that it fixes your problem, that is not what
>we're talking about.  We're talking about how one should
>fix the problem, and I'm trying to show you why "hidden"
>patch is not the answer to that.

Yes, and I'm trying to tell you that it's not the only way to solve it,
but it is the simpliest way to do it. As I'm sure most of linux users
that have steped into this "behaviour" think about it.

>Ummm, with "hidden" you still have to make a configuration change.

Just enabling it in the /proc switch.
It could be done "by default" but as we talked about it in the netdev
list, changing the default behaviour of linux when it has been working
this way for years is not a good thing.

>Second of all, "hidden" makes the kernel behave in a non-RFC compliant
>way.  This is the categorization that I use to determine if something
>belongs on the netfilter level or not.

Non-RFC compliant? What RFC is breaking?
I don't think the hidden breaks any RFC, aso I don't think the actual
behaviour breaks any RFC, but if it would do, it would be the actual
one.
The actual behaviour of linux makes loopback interfaces no sense.
Also, as long as I know, 127.0.0.1 is not answered in ARP, although
it's the default address of lo interface. So... there's some filter in
the kernel too.

>If something changes the way in which the Linux networking
>behaves wrt. RFCs, this "operation" belongs at the netfilter level.

I think you are wrong, RFCs do not say anything about interfaces. It's
decission of the OS how this is to be implemented.

>This is true for the "hidden" patch.  It causes the system to
>ignore ARP requests it should respond to.

Not at all, it ignore ARP requests coming from an interface and with
destination the IP address of OTHER interface.
If there's something wrong, I think this is the wrong behaviour.
If we go back to my "problem" setting, linux is doing an ARP request
putting in the src IP addreess, the address of the loopback interface,
that has no sense on the ethernet inteface, causing Cisco to not reply
to this packet (although I think Cisco is failing RFC).

>On the other hand, the "arpfilter" sysctl setting makes the kernel
>still behave in an RFC compliant manner, it only responds to ARPs
>on interfaces it would use to speak to the requestor.

I think the hidden patch is also RFC compliant.
More, the "hidden" patch makes Linux behave like other OS and systems I
have tested.
So... you say all these systems are NOT RFC compliant?

>> Really, the only one I have tested that not do it is Linux 2.2+
>
>Yes, we removed "hidden" from 2.2.x in lieu of "arpfilter" sysctl
>and the netfilter ARP filtering module.

Being the hidden patch the simpliest approach to solve of these
"problems".

>> For me (not a kernel developer), my world are the OSI layers,
>
>OSI layers have nothing to do with the problem we are discussing.
>
>BTW, OSI layers are how networking stacks are described in textbooks
>and standards and far away from how one should implement said stack.
>Van Jacobson even said this once :-)

As long as I know, the hidden patch does isolation of interfaces at
layer 2 (ARP).
About isolation of interfaces at layer 3, the forwarding switch in
/proc should be used.

About the kenel is not the right place to do these things, there are
switchs:
proxy_arp
rp_filter
accept_redirects
forwarding
send_redirects

These example switchs modify the behaviour of the linux box in the
kernel, without using netfilter.

>> I will look... but doing arp filter is not a real simple solution in
>> any way.
>
>It would be really nice if people might consider that it could even be
>possible to make things like the IPVS layer install the appropriate
>NETFILTER_ARP chain rules when the IPVS configuration installed
dictates
>that one is needed.
>
>People using IPVS wouldn't even need to do _ANYTHING_ if IPVS were
>to do that.
>
>And all of that would be _FINE_ because like ARP netfilter, IPVS lies
>inside of netfilter where such things which change networking behavior
>semantics radically belong.

I'm not sure, but IPVS is the Linux Virtual Server?
Well... my "problem" setting was not with LVS, I use a Cisco hardware
load balancing device.
Also, the problem in this setting is not in the load balancing device,
it's on the "real servers" that does not use the LVS software at all.
Just these servers don't know they are being "balanced".

But again, David, LVS is not the only setting that reveal this
"problem" with interface isolation. Bas has stepped into the same
"problem" in another setting.

Also, this "problem" with linux open a minor security hole (see Bas
mail), unless you use ARP filter or hidden patch.

Regards,
Carlos Velasco

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Carlos Velasco]

On 27/07/2003 at 21:37 David Lang wrote:

>P.S. there are standards that are written documents and there are
>standards that are 'how everyone does it' for the most part Linux
follows
>both types of standards, in this case the network team has decided to
>ignore the 'how everyone else does it' standards becouse there is
nothing
>in a written standard that they are violating

No problem behaving different. The questions are...
What is the advantage of doing it in this case?
Why not implementing an easy way to do linux behave like the other OS
and systems?

Regards,
Carlos Velasco

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Phil Oester]

What I think David fails to realize is that in the real world, people
use the hidden patch on a regular basis.  It is the simplest way to
achieve what we want to in a server farm consisting of hundreds of
servers.  It also involves the least overhead.  

And NO - I do not use IPVS.  I use one of the many hardware based
loadbalancers which work flawlessly with the hidden flag.

Those in ivory towers can pontificate endlessly about how one 'should'
fix the arp problem.  Those in the trenches will do it the easy way.

Phil Oester

> On 27/07/2003 at 18:35 David S. Miller wrote:
> 
> >I don't deny that it fixes your problem, that is not what
> >we're talking about.  We're talking about how one should
> >fix the problem, and I'm trying to show you why "hidden"
> >patch is not the answer to that.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bas Bloemsaat]

First of all, Im sorry I started this. It was a genuine error on my side, to assume I stumbled on a bug, while it is in fact a hotly
debated 'feature'. I did google for it, but must have missed it, it would have saved my weekend. I didn't want to (re)start a
religious war.

Maybe we should let it rest for a bit, until we have something to discuss about. Right now, I've have the idea that people are
talking about slightly different things.

> What I think David fails to realize is that in the real world, people
> use the hidden patch on a regular basis.  It is the simplest way to
> achieve what we want to in a server farm consisting of hundreds of
> servers.  It also involves the least overhead.
Me myself. I've downloaded it, and use it now. It works fine for me and I don't see any problems. But I do not oversee the whole
picture, and I don't think anybody fully understands the other camp's objections.

David, I hope that you will explain your side of the story, or maybe point to a webpage where it is explained clearly. I still have
no idea as to what your objections are, other than that in the past, another choice was made to do things.

Regards,
Bas

Re: Assorted 2.6.0-test2 build warnings

[Randy.Dunlap]

On Sun, 27 Jul 2003 20:57:31 -0400 "J.C. Wren" <jcwren@jcwren.com> wrote:

| Assorted warnings building 2.6.0-test2, on an Athlon:
| 
|   CC      fs/ntfs/super.o
| fs/ntfs/super.c: In function `is_boot_sector_ntfs':
| fs/ntfs/super.c:375: warning: integer constant is too large for "long" type

Please see if the patch below fixes this one.

|   CC      fs/smbfs/ioctl.o
| fs/smbfs/ioctl.c: In function `smb_ioctl':
| fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type
| fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type
| fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type
| fs/smbfs/ioctl.c:36: warning: comparison is always false due to limited range of data type

Hm, appears to be on NEW_TO_OLD_UID(server->mnt->mounted_uid)
to me.  mounted_uid is of type __kernel_uid_t, which is unsigned short
on i386, so NEW_TO_OLD_UID() is rather useless on it.
Should mounted_uid be __kernel_uid32_t instead?

|   CC      drivers/char/vt_ioctl.o
| drivers/char/vt_ioctl.c: In function `do_kdsk_ioctl':
| drivers/char/vt_ioctl.c:85: warning: comparison is always false due to limited range of data type
| drivers/char/vt_ioctl.c:85: warning: comparison is always false due to limited range of data type

Yes, line 85 is useless as it is.

What -W (?) options are you compiling with?  I'm not seeing these.

| drivers/char/vt_ioctl.c: In function `do_kdgkb_ioctl':
| drivers/char/vt_ioctl.c:211: warning: comparison is always false due to limited range of data type

Another unsigned char compared to value > 255.

|   CC      drivers/char/keyboard.o
| drivers/char/keyboard.c: In function `k_fn':
| drivers/char/keyboard.c:665: warning: comparison is always true due to limited range of data type

Right, same as above.


|   CC      drivers/video/matrox/matroxfb_g450.o
| drivers/video/matrox/matroxfb_g450.c: In function `g450_compute_bwlevel':
| drivers/video/matrox/matroxfb_g450.c:129: warning: duplicate `const'
| drivers/video/matrox/matroxfb_g450.c:130: warning: duplicate `const'

|   AS      arch/i386/boot/setup.o
| arch/i386/boot/setup.S: Assembler messages:
| arch/i386/boot/setup.S:165: Warning: value 0x37ffffff truncated to 0x37ffffff

Interesting.  How do I make this happen on my system?

Are you using some old (or new) version of gcc/gas or what?

--
~Randy


patch_name:	ntfs_ulong.patch
patch_version:	2003-07-28.14:29:57
author:		Randy.Dunlap <rddunlap@osdl.org>
description:	make a constant be UL;
product:	Linux
product_versions: 2.6.0-test2
maintainer:	Anton Altaparmakov <aia21@cantab.net>
diffstat:	=
 fs/ntfs/layout.h |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)


diff -Naurp ./fs/ntfs/layout.h~type ./fs/ntfs/layout.h
--- ./fs/ntfs/layout.h~type	2003-07-27 10:02:48.000000000 -0700
+++ ./fs/ntfs/layout.h	2003-07-28 14:05:20.000000000 -0700
@@ -43,7 +43,7 @@
 #define const_cpu_to_le64(x)	__constant_cpu_to_le64(x)
 
 /* The NTFS oem_id */
-#define magicNTFS	const_cpu_to_le64(0x202020205346544e) /* "NTFS    " */
+#define magicNTFS	const_cpu_to_le64(0x202020205346544eUL) /* "NTFS    " */
 
 /*
  * Location of bootsector on partition:

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bill Davidsen]

On Sun, 27 Jul 2003, David S. Miller wrote:

> On Mon, 28 Jul 2003 01:40:47 +0200
> "Carlos Velasco" <carlosev@newipnet.com> wrote:
> 
> > I stepped into the same problems you have reported here.
> 
> No, your problem was completely different.
> 
> > There's a feature to do linux to behave like other OS and systems, called "hidden".
> 
> WRONG!  People please stop this misinformation already.
> 
> Bas's problem can be solved by him giving a "preferred source"
> to each of his IPV4 routes and setting the "arpfilter" sysctl
> variable for his devices to "1".

You say this with total disregard for the fact that in actual practice it
only works for static routes. If you get a new connection it does not by
magic make an entry in the route table to go back out of the NIC with the
matching source IP, doing a "solution" with routing needs a route for
every destination (host or CIDR block).

Doing a "solution" with source routing works if you have a small number of
source IPs. However the number of routes is limited (252??) and again the
convenience factor of having the right information added with the route
addition is "do it by hand or write your own software."

> 
> This particular case has been discussed to death in the past
> and I really recommend people read up there before dragging this
> out further.

It will keep coming back because it's a real problem. I do agree that the
hidden patch is not the desired way to solve the problem, but until there
is a reasonable (not requiring a guru or large manual effort) solution
people will keep bringing it up.

You have stated that this is required by some RFC. I can see that the RFC
*allows* this behaviour, but I think there are a very small number of
people who believe that current 2.6 behaviour is better than doing what
most of the other o/s vandors have done. Feel free to quote the RFC saying
it must be done the way it is and at least some of us will stop mentioning
the problem.

I believe you were the one who said that my "require source IP on NIC"
patch (2.4.16) was non-compliant, but I don't quite see that either. It
didn't prevent accepting a packet on one NIC which matched an address on
another, but it did prevent packets from going out if the source address
was not on the NIC. The incoming seems to be a minor problem, since there
should *be* no incoming packets if arp-filter is on. It didn't have a
/proc interface, either, but that's a nit-pick, it could be added.

I would hope that you would either quote the RFC other vendors are
violating, or stop repeating "the hidden patch is bad" and start saying
"here is another convienient solution." As in one which can be set in a
single place and which will send packets out of a NIC with the matching
source address, similar to the behaviour of other implementations. 

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Lamont Granquist]

On Mon, 28 Jul 2003, Bill Davidsen wrote:
> On Sun, 27 Jul 2003, David S. Miller wrote:
> > This particular case has been discussed to death in the past
> > and I really recommend people read up there before dragging this
> > out further.
>
> It will keep coming back because it's a real problem. I do agree that the
> hidden patch is not the desired way to solve the problem, but until there
> is a reasonable (not requiring a guru or large manual effort) solution
> people will keep bringing it up.

And it severely violates the principle of least surprise.  Its unfortunate
that this principle isn't more widely discussed and considered on lkml.

Re: Assorted 2.6.0-test2 build warnings

[Adrian Bunk]

On Mon, Jul 28, 2003 at 03:11:04PM -0700, Randy.Dunlap wrote:
> On Sun, 27 Jul 2003 20:57:31 -0400 "J.C. Wren" <jcwren@jcwren.com> wrote:
> 
> | Assorted warnings building 2.6.0-test2, on an Athlon:
> | 
> |   CC      fs/ntfs/super.o
> | fs/ntfs/super.c: In function `is_boot_sector_ntfs':
> | fs/ntfs/super.c:375: warning: integer constant is too large for "long" type
> 
> Please see if the patch below fixes this one.
>...
> ~Randy
> 
> 
> patch_name:	ntfs_ulong.patch
> patch_version:	2003-07-28.14:29:57
> author:		Randy.Dunlap <rddunlap@osdl.org>
> description:	make a constant be UL;
> product:	Linux
> product_versions: 2.6.0-test2
> maintainer:	Anton Altaparmakov <aia21@cantab.net>
> diffstat:	=
>  fs/ntfs/layout.h |    2 +-
>  1 files changed, 1 insertion(+), 1 deletion(-)
> 
> 
> diff -Naurp ./fs/ntfs/layout.h~type ./fs/ntfs/layout.h
> --- ./fs/ntfs/layout.h~type	2003-07-27 10:02:48.000000000 -0700
> +++ ./fs/ntfs/layout.h	2003-07-28 14:05:20.000000000 -0700
> @@ -43,7 +43,7 @@
>  #define const_cpu_to_le64(x)	__constant_cpu_to_le64(x)
>  
>  /* The NTFS oem_id */
> -#define magicNTFS	const_cpu_to_le64(0x202020205346544e) /* "NTFS    " */
> +#define magicNTFS	const_cpu_to_le64(0x202020205346544eUL) /* "NTFS    " */
>...

s/UL/ULL/ (your patch fixed only 64 bit architectures)

The fix is already in Rusty's trivial patch.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Pekka Savola]

Hi,

Just a thought..

How about consider this change for 2.6 kernel series at this point, and 
don't backport it 2.4 at least first and/or make the behaviour 
configurable?

Upgrading from 2.4 to 2.6 should be a step big enough that folks should 
revisit their more advanced configurations, causing smaller surprises.  
Changing the behaviour inside 2.4.x series might not be reasonable.

On Mon, 28 Jul 2003, Lamont Granquist wrote:
> On Mon, 28 Jul 2003, Bill Davidsen wrote:
> > On Sun, 27 Jul 2003, David S. Miller wrote:
> > > This particular case has been discussed to death in the past
> > > and I really recommend people read up there before dragging this
> > > out further.
> >
> > It will keep coming back because it's a real problem. I do agree that the
> > hidden patch is not the desired way to solve the problem, but until there
> > is a reasonable (not requiring a guru or large manual effort) solution
> > people will keep bringing it up.
> 
> And it severely violates the principle of least surprise.  Its unfortunate
> that this principle isn't more widely discussed and considered on lkml.
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Carlos Velasco]

I have received reply from Cisco:

*********** BEGIN FORWARDED MESSAGE  ***********

On 06/08/2003 at 11:40 Oscar Madrid <omadrid@cisco.com> wrote:

>
>My name is Oscar Madrid and I'm Luis Isselin's escalation engineer.
I've
>decided to answer to this case straight as this is a question of
whether
>or not Cisco is following a standard.
>
>I can only think of one scenario where an arp request would come in
from
>192.168.140.x to a router interface that has 192.168.128.1.  That one
>scenario is a misconfiguration.    
>ARP is designed to find the next hop on a LAN.   If the host has an IP
>address of 192.168.140.140 and wants to get to 192.168.128.1, it will
have
>to have a default gateway configured.
>This default gateway would have to be on the same logical local
network.
>
>Now, lets say that the host has an IP address of 192.168.140.140/17
which
>will include both 192.168.128.x and 192.168.140.x.   This would still
be a
>misconfig as the router is not on the same subnet. (meaning the router
>does not have the same /17 mask. The host can see the router, but the
>router cannot see the host).
>
>You could, in theory, say that we're not following "similar algorithm"
in
>the RFC as we check the source, but this is more for a sanity check as
if
>it was a perfect world and everything is configured properly and there
>were no such things as bad implementations of TCP/IP stacks, then we
>wouldn't need to check.
>
>If the router for some reason was responding to the ARP broadcast, how
>would anyone know where the packet came from since the network is not
>being advertised as connected to this router? Meaning, how would a
return
>packet make it back to the host? The router doesn't "see" the host in
his
>logical network therefore it cannot communicate with it.
>
>I believe that reason we do the sanity check is because of basic IP
>routing. If the source is not from an IP address on the interface we
>received it on, we cannot reply to that IP address.  It is simple as
that.
>As I stated, ARP is designed to be used on a LAN.  This means that all
>stations that send/receive ARP packets are on the same subnet.  This
is
>the reason we do the check.   
>
>Please also note another portion of the RFC 0826 in question: 
>
>[The purpose of this RFC is to present a method of Converting
>Protocol Addresses (e.g., IP addresses) to Local Network
>Addresses (e.g., Ethernet addresses).  This is a issue of general
>concern in the ARPA Internet community at this time.  The
>method proposed here is presented for your consideration and
>comment.  This is not the specification of a Internet Standard.]
>
>When it is talking about Local Network Addresses, that means IP
addresses
>on the same network.   This is why we can perform the checks we
perform in
>our IOS.
>
>The point of the check would be to verify that the hosts are
configured
>correctly.   There is no case where a properly configured host should
ever
>send a ARP request for an IP address on a different subnet.
>
>The best example I can point out is this: 
>Ethernet is a Broadcast  network which uses ARP to find HW addresses
of
>other IP addresses on the same broadcast network.  If the IP address
is
>not on the same network, then the host/router/client needs to find the
>gateway which is on the local network.
>
>Basic and proper implementations of the TCP/IP stack should never ARP
out
>for a device that it is not located on the same logical network the
host
>is, the reason for this being they cannot communicate directly unless
a
>gateway is involved. The only ARP request a host should send in this
case
>is for its gateway that should also be a "local" device to the host
(same
>network).
>
>I hope this clears up the reson why Cisco's ARP implementation has
this
>safeguard you have found along with several others, HOWEVER, please
refer
>to RFC 1027, (http://www.ietf.org/rfc/rfc1027.txt) and under section
2.4,
>it contains the following paragraph:
>
>[If the IP networks of the source and target hosts of an ARP request 
>are different, an ARP subnet gateway implementation should not 
>reply. This is to prevent the ARP subnet gateway from being used to 
>reach foreign IP networks and thus possibly bypass security checks 
>provided by IP gateways. ]
>
>I would also ask you if you would be so kind to send me the link to
the
>netdev list of linux kernel you are making mention to so I can
escalate it
>and respond to the linux community if higher up is deemed up necesary.
>
>Best Regards,
>
>
>
>Oscar Madrid
>Customer Support Engineer
>Routing Protocols Team
>Cisco Systems
>omadrid@cisco.com
>
>                                    
>Open a TAC case on the web for faster response!
www.cisco.com/tac/caseopen
>Visit the TAC Web Site for quick access to technical support!
>www.cisco.com/tac
>Use the new TAC Advanced Search to find information fast!
>www.cisco.com/tac/advancedsearch
>
>

*********** END FORWARDED MESSAGE  ***********

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Carlos Velasco]

So,

According to RFC 1027:
http://www.ietf.org/rfc/rfc1027.txt

===
2.4  Sanity checks
    If the IP networks of the source and target hosts of an ARP request
    are different, an ARP subnet gateway implementation should not
    reply.  This is to prevent the ARP subnet gateway from being used
to
    reach foreign IP networks and thus possibly bypass security checks
    provided by IP gateways.
===

According to RFC 985:
http://www.ietf.org/rfc/rfc0985.txt?number=985

===
   A.3.  ARP datagram

      An ARP reply is discarded if the destination IP address does not
      match the local host address.  An ARP request is discarded if the
      source IP address is not in the same subnet.  It is desirable
that
      this test be overridden by a configuration parameter, in order to
      support the infrequent cases where more than one subnet may
      coexist on the same cable (see RFC-925 for examples).  An ARP
      reply is generated only if the destination protocol IP address is
      reachable from the local host (as determined by the routing
      algorithm) and the next hop is not via the same interface.  If
the
      local host functions as a gateway, this may result in ARP replies
      for destinations not in the same subnet.
===

Linux is doing the things _WRONG_ and on its own way without any switch
to change its behaviour.

Regards,
Carlos Velasco

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Alan Cox]

On Sul, 2003-08-17 at 14:09, Carlos Velasco wrote:>
> >I can only think of one scenario where an arp request would come in
> from
> >192.168.140.x to a router interface that has 192.168.128.1.  That one
> >scenario is a misconfiguration.    

Two virtual networks sharing the same lan is a perfectly valid one.
There since the router doesn't know how to reach 140.x it wouldnt reply,
if it also *is* 140.1 for example then it can reply if it wishes but I
see nothing in 826 requiring it does. In normal situations the routing
tables will indicate preferred routes and gateways.

> >I believe that reason we do the sanity check is because of basic IP
> >routing. If the source is not from an IP address on the interface we
> >received it on, we cannot reply to that IP address.  It is simple as
> that.

Thats not true at the IP level for basic situations like asymmetric
routing.

> >As I stated, ARP is designed to be used on a LAN.  This means that all
> >stations that send/receive ARP packets are on the same subnet.  This
> is
> >the reason we do the check.   

Actual ARP is used on everything from 300 baud radio networks up

> >correctly.   There is no case where a properly configured host should
> ever
> >send a ARP request for an IP address on a different subnet.

See above, multiple virtual networks. 

> >not on the same network, then the host/router/client needs to find the
> >gateway which is on the local network

See "both are my address" case above

> >Basic and proper implementations of the TCP/IP stack should never ARP
> out
> >for a device that it is not located on the same logical network the
> host
> >is, the reason for this being they cannot communicate directly unless

See above, multiple lans co-existing.

> >I hope this clears up the reson why Cisco's ARP implementation has
> this
> >safeguard you have found along with several others, HOWEVER, please
> refer
> >to RFC 1027, (http://www.ietf.org/rfc/rfc1027.txt) and under section
> 2.4,
> >it contains the following paragraph:

RFC1027 covers proxy ARP only

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Alan Cox]

On Sul, 2003-08-17 at 14:16, Carlos Velasco wrote:
> So,
> 
> According to RFC 1027:
> http://www.ietf.org/rfc/rfc1027.txt

Proxy ARP only.

>    A.3.  ARP datagram
> 
>       An ARP reply is discarded if the destination IP address does not
>       match the local host address.  

Linux counts all the IP addresses it has as being local host address.

And Linux btw has arpfilter which can do far more than just imitate your
favourite network religion of the week

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Carlos Velasco]

On 17/08/2003 at 14:41 Alan Cox wrote:

>On Sul, 2003-08-17 at 14:16, Carlos Velasco wrote:
>> So,
>> 
>> According to RFC 1027:
>> http://www.ietf.org/rfc/rfc1027.txt
>
>Proxy ARP only.

So, if you have a router performing Proxy ARP... you don't need to
reply to the "bad" Linux ARP Request, right?

>>    A.3.  ARP datagram
>> 
>>       An ARP reply is discarded if the destination IP address does
not
>>       match the local host address.  
>
>Linux counts all the IP addresses it has as being local host address.

You should pay more attention, the real thing is on the second phrase:

"An ARP request is discarded if the source IP address is not in the
same subnet."

>And Linux btw has arpfilter which can do far more than just imitate
your
>favourite network religion of the week

And you can just use other OS and solve the problem without messing
with firewalling and mangling techniques.
Maybe the "favourite network religion" should be called as "RedHat
favourite network religion"?
Or maybe it should be called... "Linux approaching Microsoft", as both
don't listen to real users.

Linux versus all other OSes and systems (Cisco, Foundry, ...)
It's clear this is not MY religious war... maybe others war.... I don't
live from Linux.

Regards,
Carlos Velasco

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bas Bloemsaat]

> Proxy ARP only.
>
> >    A.3.  ARP datagram
> >
> >       An ARP reply is discarded if the destination IP address does not
> >       match the local host address.
>
> Linux counts all the IP addresses it has as being local host address.
>
> And Linux btw has arpfilter which can do far more than just imitate your
> favourite network religion of the week
>

I think the whole mess comes from the ambigious use of the word host in RFC
826, and several possible interpretations. It can mean both ethernet host
(i.e. a NIC) or internet host (i.e. the whole server). This isn't clear from
the RFC. In fact, the meanings are mixed. It's not a good RFC.

The linux way is a perfectly legal, if somewhat awkward, way to interpret
the RFC. Me too, I'd like a device respond only to ARP requests that are
meant for an IP bound to it, but please, let's not turn this into a holy
war.

Regards,
Bas

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bernd Eckenfels]

In article <200308171555280781.0067FB36@192.168.128.16> you wrote:
> So, if you have a router performing Proxy ARP... you don't need to
> reply to the "bad" Linux ARP Request, right?

Linux does not do bad requests, it does only do "bad" answers.

> "An ARP request is discarded if the source IP address is not in the
> same subnet."

In the same subnet of what? Sure it is in the same subnet as the host, since
it counts all its interfaces, wich is generally a good thing.

Greetings
Bernd
-- 
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Alan Cox]

On Sul, 2003-08-17 at 14:55, Carlos Velasco wrote:
> >> According to RFC 1027:
> >> http://www.ietf.org/rfc/rfc1027.txt
> >
> >Proxy ARP only.
> 
> So, if you have a router performing Proxy ARP... you don't need to
> reply to the "bad" Linux ARP Request, right?

Linux doesn't issue "bad" requests. Linux will reply when it is
asked for an address that it owns, as per RFC826, unless you chose
to change the behaviour with things like arpfilter.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bas Bloemsaat]

What wonders me about the behaviour is that it is not consistent.

When I have the following situation: a box with twon nics, one 192.168.1.1,
ethernet adr aa , the other 192.168.1.2 ethernet adr bb

When I do an ARP request for 192.168.1.2, both respond. aa as wel as bb

But if I do another request for 192.168.1.2, and I direct it to the aa NIC,
it does not respond. Unless I turn on packet_forwarding (i.e. routing).
Remember, ARP is not routable, or shouldn't be, yet it is treated as such.

Regards,
Bas

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Carlos Velasco]

On 17/08/2003 at 16:28 Alan Cox wrote:

>Linux doesn't issue "bad" requests. Linux will reply when it is
>asked for an address that it owns, as per RFC826, unless you chose
>to change the behaviour with things like arpfilter.

We are not talking about ARP Replies, we are talking about ARP
Requests.
You can see the Richard post here, same issue I reported several weeks
ago:
http://marc.theaimsgroup.com/?l=linux-net&m=106094924813337&w=2

==
	On eth0, we see:

11:23:55.650514 0:4:75:ca:c4:ef Broadcast arp 42: arp who-has
10.10.10.1
tell 212.xxx.yyy.9
==

Linux is sending an ARP Request to a LAN where the source IP address of
the packet has not any sense in that IP network.
And, at least, 2 RFCs are stating that other devices should not reply
to this packet. Currently know Cisco, Foundry; possibly others, and
possibly others coming as ARP storms are not desired.

Regards,
Carlos Velasco

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Alan Cox]

On Sul, 2003-08-17 at 16:59, Carlos Velasco wrote:
> We are not talking about ARP Replies, we are talking about ARP
> Requests.
> You can see the Richard post here, same issue I reported several weeks
> ago:
> http://marc.theaimsgroup.com/?l=linux-net&m=106094924813337&w=2

You put the foundary devices IP on one of your interfaces ? In which case
your network is misconfigured - go fix it. Two systems are not permitted
to have the same IP address. Linux supports asymettric routing just fine.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Carlos Velasco]

On 17/08/2003 at 17:26 Alan Cox wrote:

>> http://marc.theaimsgroup.com/?l=linux-net&m=106094924813337&w=2
>
>You put the foundary devices IP on one of your interfaces ? In which
case
>your network is misconfigured - go fix it. Two systems are not
permitted
>to have the same IP address. Linux supports asymettric routing just
fine.

Really, I don't know if you don't uderstand or you don't want to
understand...

There is _NOT_ any problem of duplicated IPs or so.
It's a Load Balancing scenary, similar to linuxvirtualserver and ARP
problem that rise _ONLY_ when using Linux as real server:
http://www.linuxvirtualserver.org/docs/arp.html

If you send a packet through dev eth0 to dev lo IP address or other
interface, when Linux try to map the MAC address with the IP address of
the default gateway (or the gateway to reach the packet Source IP
address), it uses the lo IP address (or other dev) in the ARP Request.

Regards,
Carlos Velasco

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Carlos Velasco]

On 17/08/2003 at 12:51 David T Hollis wrote:

>Check out: http://www.linuxvirtualserver.org/docs/arp.html.  I 
>understand the problem you're talking about.  It's not a 'bug', it's a

>feature!  You need to use the hidden interface approach to have the
back 
>end system not broadcast it's MAC for the virtual IP.

I know it... but..

1. hidden patch is not in the main linuk kernel stream.... why?
2. that "feature" makes linux to send non-RFC ARP Requests
3. what's the meaning of that "feature"? It seems to do more problems
that it solves.

Regards,
Carlos Velasco

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David T Hollis]

Carlos Velasco wrote:

>On 17/08/2003 at 16:28 Alan Cox wrote:
>
>  
>
>>Linux doesn't issue "bad" requests. Linux will reply when it is
>>asked for an address that it owns, as per RFC826, unless you chose
>>to change the behaviour with things like arpfilter.
>>    
>>
>
>We are not talking about ARP Replies, we are talking about ARP
>Requests.
>You can see the Richard post here, same issue I reported several weeks
>ago:
>http://marc.theaimsgroup.com/?l=linux-net&m=106094924813337&w=2
>
>==
>	On eth0, we see:
>
>11:23:55.650514 0:4:75:ca:c4:ef Broadcast arp 42: arp who-has
>10.10.10.1
>tell 212.xxx.yyy.9
>==
>
>Linux is sending an ARP Request to a LAN where the source IP address of
>the packet has not any sense in that IP network.
>And, at least, 2 RFCs are stating that other devices should not reply
>to this packet. Currently know Cisco, Foundry; possibly others, and
>possibly others coming as ARP storms are not desired.
>
>Regards,
>Carlos Velasco
>
>
>-
>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/
>  
>
Check out: http://www.linuxvirtualserver.org/docs/arp.html.  I 
understand the problem you're talking about.  It's not a 'bug', it's a 
feature!  You need to use the hidden interface approach to have the back 
end system not broadcast it's MAC for the virtual IP.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Arjan van de Ven]

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


> 1. hidden patch is not in the main linuk kernel stream.... why?

because arpfilter is a more generic way of doing things like this, and
that IS in the main linux kernel


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Alan Cox]

On Sul, 2003-08-17 at 17:27, Carlos Velasco wrote:
> Really, I don't know if you don't uderstand or you don't want to
> understand...
> 
> There is _NOT_ any problem of duplicated IPs or so.
> It's a Load Balancing scenary, similar to linuxvirtualserver and ARP
> problem that rise _ONLY_ when using Linux as real server:
> http://www.linuxvirtualserver.org/docs/arp.html

Which says

| In the LVS/TUN and LVS/DR clusters, the Virtual IP (VIP) addresses are
| shared by both the load balancer and real servers, because they all 
| configure the VIP address on one of their interfaces.

Which is not legal IP, and is why you are having problems.

> If you send a packet through dev eth0 to dev lo IP address or other
> interface, when Linux try to map the MAC address with the IP address of
> the default gateway (or the gateway to reach the packet Source IP
> address), it uses the lo IP address (or other dev) in the ARP Request.

So stick the address on eth0 not on lo since its not a loopback but an eth0
address, then use arpfilter so you don't arp for the invalid magic shared IP
address, or NAT it, or it may work to do

         ip route add nexthop-addr src my-virtual-addr dev eth0 scope local onlink
         ip route add default src my-virtual-addr via nexthop-addr dev eth0 scope global

if you have no other routes getting in the way, especially old style ifconfig ones

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[insecure]

On Sunday 17 August 2003 20:13, Arjan van de Ven wrote:
> > 1. hidden patch is not in the main linuk kernel stream.... why?
>
> because arpfilter is a more generic way of doing things like this, and
> that IS in the main linux kernel

I am interested in that but last time I googled for it,
neither userspace utils nor any documentation turned up.
I only see some kernel parts of it.
-- 
vda

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Willy Tarreau]

Hi Alan !

On Sun, Aug 17, 2003 at 06:24:06PM +0100, Alan Cox wrote:
 
> So stick the address on eth0 not on lo since its not a loopback but an eth0
> address, then use arpfilter so you don't arp for the invalid magic shared IP
> address, or NAT it, or it may work to do
> 
>          ip route add nexthop-addr src my-virtual-addr dev eth0 scope local onlink
>          ip route add default src my-virtual-addr via nexthop-addr dev eth0 scope global
 
I have a case where this doesn't work, and which required me to apply Julian's
arp_prefsrc patch, because I couldn't resolve it with iproute alone. This is a
fairly simple and certainly common scenario :

   box A : client        router           box B
   +------------+     +---------+      +--------+
---+ eth0  eth1 +-----+ gateway +------+ server +
   +------------+     +---------+      +--------+
   10.1      11.1     11.2   12.2      12.3    <-- IP : 10.1 for 10.0.0.1, etc.

Network 11 is an interconnect network, it is not known from box B, but B knows
how to reach network 10 through the router (12.0.0.2), which also knows how to
reach 10 through 11.0.0.1 of course.

If I want to be able to reach box B from A (eg for debugging purposes), I need
it to join B from its 10.1 address, through gateway 11.2. I do the following
on Box A:
  ip route add 11.0.0.2 src 11.0.0.1 dev eth1 onlink
  ip route add 12.0.0.3 via 11.0.0.2 src 10.0.0.1 dev eth1

To me, it means that when talking to 12.0.0.3, I bind to source 10.0.0.1, and
route through 11.0.0.2, which I obtain the MAC address by asking with a source
of 11.0.0.1.

But it doesn't work this way : 11.0.0.2 receives ARP requests from 10.0.0.1
and obviously refuses them.

But now if I simply ping 11.0.0.2, this one won't work either because box A
will still try to request its MAC address with 10.0.0.1 as its source ! So I
manually delete the incomplete ARP entry, and ping 11.0.0.2 again. This time,
the valid address (11.0.0.1) is used, and I can reach 12.0.0.3 from 10.0.0.1
as long as the ARP entry stays valid.

Perhaps this is a standard arp_filter case, but I didn't find how to resolve
it, except by using Julian's arp_prefsrc patch which does a lookup of a valid
source address to send the ARP request. Now, each time I have these sort of
setup and I don't have a patched kernel, I prepare a background ping to feed
the ARP cache correctly.

And frankly, I don't understand what feature it brings to deliberately use a
wrong address as the source for ARP requests. I have searched a long time, but
still didn't find any advantage to this behaviour. Reading the code, I don't
think it was deliberate, but only a forgotten case. To me, the first route
entry above is explicit enough : use 11.0.0.1 as a source when trying to reach
11.0.0.2, so I don't see why ARP requests don't respect this.

If you want to reproduce the setup above, you only need ONE host and tcpdump.
Simply put the two addresses on the same NIC, add the routes and watch the ARP
requests go out with the wrong source.

Here is Julian's patch if you want to take a look at it. It seems fairly
logical to me, and I don't see what it could break. But again, if you have a
way to do something equivalent with iproute or any other standard method, I'd
be glad to try.

Cheers,
Willy

--- v2.4.12/linux/net/ipv4/arp.c	Tue Sep 25 02:38:23 2001
+++ linux/net/ipv4/arp.c	Mon Oct 22 22:58:49 2001
@@ -316,16 +316,19 @@
 
 static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb)
 {
+	struct rtable *rt;
 	u32 saddr;
 	u8  *dst_ha = NULL;
 	struct net_device *dev = neigh->dev;
 	u32 target = *(u32*)neigh->primary_key;
 	int probes = atomic_read(&neigh->probes);
 
-	if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL)
-		saddr = skb->nh.iph->saddr;
-	else
-		saddr = inet_select_addr(dev, target, RT_SCOPE_LINK);
+	if (ip_route_output(&rt, target, 0, 0, dev->ifindex) < 0)
+		return;
+	saddr = rt->rt_src;
+	ip_rt_put(rt);
+	if (!saddr)
+		return;
 
 	if ((probes -= neigh->parms->ucast_probes) < 0) {
 		if (!(neigh->nud_state&NUD_VALID))

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Sun, 17 Aug 2003 22:46:12 +0300
insecure <insecure@mail.od.ua> wrote:

> On Sunday 17 August 2003 20:13, Arjan van de Ven wrote:
> > > 1. hidden patch is not in the main linuk kernel stream.... why?
> >
> > because arpfilter is a more generic way of doing things like this, and
> > that IS in the main linux kernel
> 
> I am interested in that but last time I googled for it,
> neither userspace utils nor any documentation turned up.
> I only see some kernel parts of it.

The bridging netfilter (ie. "ebtables") maintainer has
tools available up on his site.

	http://ebtables.sourceforge.net/

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 18 Aug 2003 00:48:49 +0200
Willy Tarreau <willy@w.ods.org> wrote:

> I have a case where this doesn't work

And that's exactly what arpfilter is for.

There are zero performance implications from using
arpfilter too, if that is something people are worried
about.

Only ARP packets will go into the netfilter code, all
other packet types will bypass netfilter entirely.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Sun, 17 Aug 2003 15:55:28 +0200
"Carlos Velasco" <carlosev@newipnet.com> wrote:

> And you can just use other OS and solve the problem

Nobody hacking on Linux feels threatened by this.

And if anything, it's the last thing that would make us change Linux
to behave one way or another.  That would be a stupid reason to make a
change to the kernel, just because someone is shitting their pants on
some mailing list endlessly about it.

So please, go ahead, go use another OS if that suits your needs
better, it certainly has no bearing on how we'll make Linux's ARP
behave.

But the one thing you can't do is accuse us of not providing the
facility you need.  Your only valid complaint is that the facility
doesn't get configured in the way that you would like it to, and
frankly my answer to that is "tough".

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 18 Aug 2003 00:48:49 +0200
Willy Tarreau <willy@w.ods.org> wrote:

> On Sun, Aug 17, 2003 at 06:24:06PM +0100, Alan Cox wrote:
>  
> > So stick the address on eth0 not on lo since its not a loopback but an eth0
> > address, then use arpfilter so you don't arp for the invalid magic shared IP
> > address, or NAT it, or it may work to do
> > 
> >          ip route add nexthop-addr src my-virtual-addr dev eth0 scope local onlink
> >          ip route add default src my-virtual-addr via nexthop-addr dev eth0 scope global
>  
> I have a case where this doesn't work

Replying again... Alan does mention in the paragraph you've quoted
to use arpfilter, which works for every case imaginable.

The facilities to solve these problems are there, people simply
don't want to use them.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Willy Tarreau]

Hello David,

On Sun, Aug 17, 2003 at 10:22:58PM -0700, David S. Miller wrote:
> On Mon, 18 Aug 2003 00:48:49 +0200
> Willy Tarreau <willy@w.ods.org> wrote:
> 
> > I have a case where this doesn't work
> 
> And that's exactly what arpfilter is for.

That's indeed what I was supposing so.

> There are zero performance implications from using
> arpfilter too, if that is something people are worried
> about.

I'm not worried about performance, which I can easily imagine is not affected
for such rare events as ARP requests.

I'm more worried about how to set it up. I have already searched in
Documentation/networking, on google, etc... but didn't find any useful
information about how to set up an arpfilter configuration. I'd agree to test
it, but don't know where to start from. I even don't know if it's related to
'ip arp'. I guess that's what stops most people from using it. Others may even
not be aware that this feature exists at all.

Other than that, I don't know if the resulting configuration will still be
straightforward or look completely tricky.

Again, I don't know what we can break by applying the arp_prefsrc patch, which
will do the Right Thing most of the time. And when it won't, the current code
would also have required arpfilter anyway.

But I'm willing to try arpfilter if you show me where to start from.

Cheers,
Willy

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 18 Aug 2003 08:56:52 +0200
Willy Tarreau <willy@w.ods.org> wrote:

> But I'm willing to try arpfilter if you show me where to start from.

There are tools at:

	http://ebtables.sourceforge.net/

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Willy Tarreau]

On Mon, Aug 18, 2003 at 12:01:39AM -0700, David S. Miller wrote:
> On Mon, 18 Aug 2003 08:56:52 +0200
> Willy Tarreau <willy@w.ods.org> wrote:
> 
> > But I'm willing to try arpfilter if you show me where to start from.
> 
> There are tools at:
> 
> 	http://ebtables.sourceforge.net/

Thanks, I've downloaded them and will take a look at them. By the time, I did
some random tests with 'ip arp', and found a simple way to solve the problem
I reported initially. This can be of interest to others BTW :

Trivial example below :

   My host wants to use address 10.0.0.1 to talk to the world, but through
   the gateway 11.0.0.2 reachable from 11.0.0.1 :

   ip address add 10.0.0.1/24 dev eth0
   ip address add 11.0.0.1/24 dev eth0
   ip route   add default     via 11.0.0.2 src 10.0.0.1
=> same as before till this
   ip arp     append table output to 11.0.0.0/24 oif eth0 src 11.0.0.1
=> now it will use 11.0.0.1 to find its gateway (11.0.0.2)

So as a general rule of thumb, I would recommend people to systematically call
"ip arp append table output to [network] oif [NIC] src [local_ip]" after an
"ip address add [local_ip] dev [NIC]". And yes, I agree that these are standard
tools, but I maintain that the default behaviour should be cleaner.

I also found that I can filter incoming requests easily with "table input" :

   ip arp append table input deny
   ip arp add    table input allow from 11.0.0.0/24 to 11.0.0.0/24 iif eth0
   ip arp add    table input allow from 10.0.0.0/24 to 10.0.0.0/24 iif eth0

I don't understand how the forward table is used, BTW, but I'll search a bit
more. If I finally understand how all this works, I may propose a simple how-to
to put under Documentation/networking/arp.txt so solve most common problems.

Cheers,
Willy

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Willy Tarreau]

Hmmm replying to myself !

> So as a general rule of thumb, I would recommend people to systematically call
> "ip arp append table output to [network] oif [NIC] src [local_ip]" after an
> "ip address add [local_ip] dev [NIC]". And yes, I agree that these are
> standard tools, but I maintain that the default behaviour should be cleaner.

In fact, not standard. 'ip arp' was brought by Julian Anastasov's
iproute2-iparp-3 patch on top of iproute2. But it seems to do wonderful things.

Cheers,
Willy

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Robert Collier]

In article <1061127715.21885.35.camel@dhcp23.swansea.linux.org.uk> Alan writes:
>And Linux btw has arpfilter which can do far more than just imitate your
>favourite network religion of the week

I've been hearing about arpfilter for ages - but I've never been able
to find either documentation or a configuration tool - where can I
find these?

	- Regards, Rob.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Sun, 17 Aug 2003 22:31:18 -0700
"David S. Miller" <davem@redhat.com> wrote:

> On Mon, 18 Aug 2003 00:48:49 +0200
> Willy Tarreau <willy@w.ods.org> wrote:
> 
> > On Sun, Aug 17, 2003 at 06:24:06PM +0100, Alan Cox wrote:
> >  
> > > So stick the address on eth0 not on lo since its not a loopback but an
> > > eth0 address, then use arpfilter so you don't arp for the invalid magic
> > > shared IP address, or NAT it, or it may work to do
> > > 
> > >          ip route add nexthop-addr src my-virtual-addr dev eth0 scope
> > >          local onlink ip route add default src my-virtual-addr via
> > >          nexthop-addr dev eth0 scope global
> >  
> > I have a case where this doesn't work
> 
> Replying again... Alan does mention in the paragraph you've quoted
> to use arpfilter, which works for every case imaginable.
> 
> The facilities to solve these problems are there, people simply
> don't want to use them.

It would be probably a good thing if anybody ever found a _positive_ scenario
where your view of the arp-world has _advantages_ compared to what the vast
majority of people I ever talked to sees as _expected_ behaviour...
(Please don't argue that my "vast majority" is not necessarily _the_ vast
majority, because that is true for merely every human being on this planet and
beyond)
I mean everybody is willing to follow you if you could say: "look at these type
of wide-spread operations and notice the positive (config shortening or
whatever) influence of the current default behaviour."
Can you please give us a striking example of a widespread application where
current behaviour is a requirement or at least a very positive thing?

Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 18 Aug 2003 13:39:57 +0200
Stephan von Krawczynski <skraw@ithnet.com> wrote:

> Can you please give us a striking example of a widespread application where
> current behaviour is a requirement or at least a very positive thing?

[ I've been waiting what seems like centuries for someone
  to even consider talking about source address selection,
  alas I have to bring it up myself :( ]

I'll responsd by asking questions of you.

Do you know how source address selection works when the user tries to
connect to a remote location yet doesn't specify a specific source
address to use?

Once you understand source address selection, the next thing
you need to do is:

1) consider how you might want to make that configurable
   by the user
2) what the default behavior should be
3) what kind of ARP behavior is necessary in order for
   these various configurations to work

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 18 Aug 2003 14:08:05 +0200
"Bas Bloemsaat" <bloemsaa@xs4all.nl> wrote:

> > > Replying again... Alan does mention in the paragraph you've quoted
> > > to use arpfilter, which works for every case imaginable.
>
> No it doesn't. When I have two nics on DHCP on the same ethernet segment, it
> cannot be made to work. I don't know the ip addresses beforehand. And if if
> I would get them with scripting and crafted some rules on the fly, there's
> no way I can be sure I'll get the same IP's on a renew, so I'd have to check
> often.

You don't understand how 'arpfilter' works.

It's a netfilter module that allows you to block ARP packets
going in and out of the system using any criteria you want.
It can block on device, on src MAC address, on destination
MAC address, whatever you want.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bas Bloemsaat]

> > Replying again... Alan does mention in the paragraph you've quoted
> > to use arpfilter, which works for every case imaginable.
No it doesn't. When I have two nics on DHCP on the same ethernet segment, it
cannot be made to work. I don't know the ip addresses beforehand. And if if
I would get them with scripting and crafted some rules on the fly, there's
no way I can be sure I'll get the same IP's on a renew, so I'd have to check
often.

Regards,
Bas

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 18 Aug 2003 14:34:01 +0200
Stephan von Krawczynski <skraw@ithnet.com> wrote:

> what is the _positive_ outcome of this
> implementation compared to others?

If you're not willing to think I can't help you resolve
the questions you have.

If you don't understand source address selection, than it's
not possible for me to have an intellegent conversation about
this topic.

So you need to make this crucial first step.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Mon, 18 Aug 2003 04:44:19 -0700
"David S. Miller" <davem@redhat.com> wrote:

> On Mon, 18 Aug 2003 13:39:57 +0200
> Stephan von Krawczynski <skraw@ithnet.com> wrote:
> 
> > Can you please give us a striking example of a widespread application where
> > current behaviour is a requirement or at least a very positive thing?
> 
> [ I've been waiting what seems like centuries for someone
>   to even consider talking about source address selection,
>   alas I have to bring it up myself :( ]
> 
> I'll responsd by asking questions of you.

David, this is the wrong way round. Others'/my question was not about the
implementation and technical considerations leading to it (bottom up), but pure
and simple (and top down): what is the _positive_ outcome of this
implementation compared to others? We are always talking of setups that seem to
be more complicated because of the current situation. So one would expect that
there are advantages that make up the discussed disadvantages.
And since I obviously don't have the knowledge to see them, I'd like to learn
and therefore ask: what are the advantages on the _users_ side?

Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Mr. James W. Laferriere]

	Hello Dave ,  I'm sorry He asked a valid question & saying that
	'you're not willing to think'  Doesn't cut it .
	I'll repeat his question :

	what are the advantages on the _users_ side?

	Please illucidate us .  Tia ,  JimL

On Mon, 18 Aug 2003, David S. Miller wrote:
> On Mon, 18 Aug 2003 14:34:01 +0200
> Stephan von Krawczynski <skraw@ithnet.com> wrote:
>
> > what is the _positive_ outcome of this
> > implementation compared to others?
>
> If you're not willing to think I can't help you resolve
> the questions you have.
>
> If you don't understand source address selection, than it's
> not possible for me to have an intellegent conversation about
> this topic.
>
> So you need to make this crucial first step.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Willy Tarreau]

On Mon, Aug 18, 2003 at 04:44:19AM -0700, David S. Miller wrote:
> On Mon, 18 Aug 2003 13:39:57 +0200
> Stephan von Krawczynski <skraw@ithnet.com> wrote:
> 
> > Can you please give us a striking example of a widespread application where
> > current behaviour is a requirement or at least a very positive thing?
> 
> [ I've been waiting what seems like centuries for someone
>   to even consider talking about source address selection,
>   alas I have to bring it up myself :( ]

You're not fair, David, that was *exactly* my concern when I jumped into the
thread : the SELECTED SOURCE address for ARP requests is wrong by default as
soon as you manually set the IP source address. (but perhaps you didn't have
time to read my long mail).

> Do you know how source address selection works when the user tries to
> connect to a remote location yet doesn't specify a specific source
> address to use?

In my case, although I don't know the internals, I think I have a clear enough
idea of it (but I may be wrong) : the IP source address used when connecting to
a remote host should be either the one manually specified on the most
appropriate route, or one local address which can reach the remote host or a
gateway indicated by the most appropriate route. The ARP source is the IP
source address if this address is a local one, or one of those assigned to the
NIC from which either the host or the gateway should be reached.

> 1) consider how you might want to make that configurable
>    by the user

ip route ... src ... is really fine to me for the IP part, and I would have
expected it to act on ARP too ;-)

> 2) what the default behavior should be

I think we should apply the exact same source selection as IP to ARP. That is,
if we need to reach host X or gateway X on the LAN, we should do a route lookup
and use a valid source (or the manually set one) associated to the most
appropriate route. That is what Julian Anastasov's patch does, and it does it
fairly well IMHO.

> 3) what kind of ARP behavior is necessary in order for
>    these various configurations to work

The one detailed above by default, then use arptables (or ip arp) for all
tricky configurations.

BTW, I've tried arptables-0.0.1. Except that I had to patch it to make it
usable on 2.4.22-rc2 (because the FORWARD chain doesn't exist on 2.4), it
allows me to do the same as what 'ip arp' did for me on a patched kernel
(although I prefer the iproute interface, just a matter of taste). Using my
previous example, I now do the following which works :

   ip address add 10.0.0.1/24 dev eth0
   ip address add 11.0.0.1/24 dev eth0
   ip route   add default     via 11.0.0.2 src 10.0.0.1
   arptables -A OUTPUT -d 11.0.0.0/24 -o eth0 -j mangle --mangle-ip-s 11.0.0.1

I'll send a fix to the arptable's maintainer so that it works again on 2.4.

Cheers,
Willy

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Mon, 18 Aug 2003 05:30:07 -0700
"David S. Miller" <davem@redhat.com> wrote:

> On Mon, 18 Aug 2003 14:34:01 +0200
> Stephan von Krawczynski <skraw@ithnet.com> wrote:
> 
> > what is the _positive_ outcome of this
> > implementation compared to others?
> 
> If you're not willing to think I can't help you resolve
> the questions you have.
> 
> If you don't understand source address selection, than it's
> not possible for me to have an intellegent conversation about
> this topic.
> 
> So you need to make this crucial first step.

Sorry, David. Your argument would only be valid, if there weren't other
implementations that behave differently. But in fact there are, and there are
patches for linux that do just the same. _And_ you did not explain so far why
these implementations should not be RFC-conform or else illegal. So there is no
validity in your claim one has to understand why the designer did what he did
to follow the discussion. In fact it is rather up to the designer to explain to
the users why he did it in another way other designers did, i.e. what is
_better_ about _this_ way compared to others.
Because if there is nothing better then the implementation is legal but
contestable, because all scenarios discussed so far have more complex solutions
then with other implementations.
Don't get me wrong, this is no technical argument. It is purely darwinism,
"legal and easy" is superior to "legal and complex" (as long as there are no
other benefits).

Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 18 Aug 2003 14:51:58 +0200
Willy Tarreau <willy@w.ods.org> wrote:

> > 1) consider how you might want to make that configurable
> >    by the user
> 
> ip route ... src ... is really fine to me for the IP part, and I would have
> expected it to act on ARP too ;-)

More precisely, "preferred source".

> > 2) what the default behavior should be
> 
> I think we should apply the exact same source selection as IP to ARP.

This is what setting the "arp_filter" sysctl on a device does
if you've setup the preferred source on your routes correctly.
If we would use that IP address to speak to the destination in
the ARP, we respond, else we do not.

I've quoted the 'arp_filter' entry in Documentation/sysctl/ip-sysctl.txt
please give it a read.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 18 Aug 2003 14:53:16 +0200
Stephan von Krawczynski <skraw@ithnet.com> wrote:

> _And_ you did not explain so far why these implementations should
> not be RFC-conform or else illegal.

Both responding and not responding on all interfaces for ARPs
is RFC conformant.  This means both Linux and other systems
are within the rules.

Under Linux, by default, IP addresses are owned by the system
not by interfaces.  This increases the likelyhood of successful
communication on a subnet.

For scenerios where this doesn't work, we have ways to make the
kernel behave the way you want it to.

There is no discussion about changing the default, because that
might break things for some people.  So this discussion is pretty
useless.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 18 Aug 2003 15:17:55 +0200
Stephan von Krawczynski <skraw@ithnet.com> wrote:

> If I remember that right kernels 2.0 and 2.2 behave differently, so
> you are talking about setups for 2.4 kernels.

All kernel versions have had the ARP behavior we have now.

Both 2.0 and 2.2 answer on all interfaces for ARP requests
by default just like 2.4 does.

This is why Alan is able to add constructive criticism to this
discussion, this behavior goes back even to when he was maintaining
the networking :)

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Mon, 18 Aug 2003 05:55:55 -0700
"David S. Miller" <davem@redhat.com> wrote:

> On Mon, 18 Aug 2003 14:53:16 +0200
> Stephan von Krawczynski <skraw@ithnet.com> wrote:
> 
> > _And_ you did not explain so far why these implementations should
> > not be RFC-conform or else illegal.
> 
> Both responding and not responding on all interfaces for ARPs
> is RFC conformant.  This means both Linux and other systems
> are within the rules.
> 
> Under Linux, by default, IP addresses are owned by the system
> not by interfaces.  This increases the likelyhood of successful
> communication on a subnet.

In other words: it is more tolerant against broken setups.
 
> For scenerios where this doesn't work, we have ways to make the
> kernel behave the way you want it to.

For sure.
 
> There is no discussion about changing the default, because that
> might break things for some people.  So this discussion is pretty
> useless.

Ah yes. Maybe we are getting to the real point of the discussion. If I remember
that right kernels 2.0 and 2.2 behave differently, so you are talking about
setups for 2.4 kernels. I am very interested to hear what a valid setup looks
like that is broken by the default behaviour of _other_ RFC-conformant
implementations. That is exactly what you are telling us here.
If you cannot describe such a setup, then you basically say you don't want to
follow the mainstream because you want to keep broken setups going.
I have heard things like that before from some well-known big company...
Can't you simply state the true reason why you are playing shepherd for a dead
cow?

Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On 18 Aug 2003 09:23:48 -0400
jamal <hadi@cyberus.ca> wrote:

> Ok, heres a neat little feature requst: someone create arp rewrite rules
> with ARPtable so we can have do MAC address aliasing.

What you ask for is in 2.6.x already, I'm more than happy to put a
backport it to 2.4.x too as it is a netfilter module that stands by
itself.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[jamal]

On Mon, 2003-08-18 at 08:55, David S. Miller wrote:

> Under Linux, by default, IP addresses are owned by the system
> not by interfaces.  

Folks, the above is the punch line. I am just going over all emails on
this thread and i see this point being missed. 
People are quoting tons of RFCs while the really important point being
missed is the above line.

> For scenerios where this doesn't work, we have ways to make the
> kernel behave the way you want it to.
> 

and you are provided with alternatives if you dont like the way it
works. I think even Julian is happy with this.
Ok, heres a neat little feature requst: someone create arp rewrite rules
with ARPtable so we can have do MAC address aliasing.

Guys, Lets have Davem worry about more imporant things.
Maybe we should have a web page or FAQ on this topic?

cheers,
jamal

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Dominik Kubla]

Am Montag, 18. August 2003 14:34 schrieb Stephan von Krawczynski:

> David, this is the wrong way round. Others'/my question was not about the
> implementation and technical considerations leading to it (bottom up), but
> pure and simple (and top down): what is the _positive_ outcome of this
> implementation compared to others? We are always talking of setups that
> seem to be more complicated because of the current situation. So one would
> expect that there are advantages that make up the discussed disadvantages.
> And since I obviously don't have the knowledge to see them, I'd like to
> learn and therefore ask: what are the advantages on the _users_ side?

Very simple: no need for any IPMP crap on Linux. It just works.  And that puts 
"answered" on all questions that were ever raised regarding that issue.

Regards,
  Dominik
-- 
ScioByte GmbH                     | ScioByte Information Technologies AG
Fritz-Erler-Strasse 6             | Innere Güterstrasse 4
55129 Mainz (Germany)             | 6304 Zug (Switzerland)
Phone: +49 700 724 629 83         | Phone: +41 41 710 30 18
Fax:   +49 700 724 629 84         |

GnuPG: 1024D/717F16BB A384 F5F1 F566 5716 5485  27EF 3B00 C007 717F 16BB

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Mon, 18 Aug 2003 06:21:02 -0700
"David S. Miller" <davem@redhat.com> wrote:

> On 18 Aug 2003 09:23:48 -0400
> jamal <hadi@cyberus.ca> wrote:
> 
> > Ok, heres a neat little feature requst: someone create arp rewrite rules
> > with ARPtable so we can have do MAC address aliasing.
> 
> What you ask for is in 2.6.x already, I'm more than happy to put a
> backport it to 2.4.x too as it is a netfilter module that stands by
> itself.

Is netfilter completely SMP safe currently?

Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 18 Aug 2003 16:23:10 +0200
Stephan von Krawczynski <skraw@ithnet.com> wrote:

> > Both 2.0 and 2.2 answer on all interfaces for ARP requests
> > by default just like 2.4 does.
> 
> Try it. Proven wrong. See above.

Ok then.

It still doesn't change the essence of this conversation.  Changing
things would break a lot of people's setups.

See the other posting from someone about IPMP (IP multipathing).

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Mon, 18 Aug 2003 06:14:20 -0700
"David S. Miller" <davem@redhat.com> wrote:

> On Mon, 18 Aug 2003 15:17:55 +0200
> Stephan von Krawczynski <skraw@ithnet.com> wrote:
> 
> > If I remember that right kernels 2.0 and 2.2 behave differently, so
> > you are talking about setups for 2.4 kernels.
> 
> All kernel versions have had the ARP behavior we have now.

They have not. I just tried.

I have two boxes with 2 interfaces each and a third for testing. Testbox 1 has
2.2 kernel, testbox 2 has 2.4 kernel.

The three are connected via same switch on primary if.

I ping the second if ip of testbox 2, then arp -vn and see the second ip with
a mac entry of testbox 2 primary if.
I ping the second if ip of testbox 1, then arp -vn and see _no_ entry for this
second ip, it is in fact routed (which I would state as the expected
behaviour as the second ip is from another subnet).
 
> Both 2.0 and 2.2 answer on all interfaces for ARP requests
> by default just like 2.4 does.

Try it. Proven wrong. See above.
 
Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 18 Aug 2003 16:28:47 +0200
Willy Tarreau <willy@w.ods.org> wrote:

> Now if you think that the behaviour I'm proposing is broken, please explain me
> why.

If the user overrides the source address (which is the case I believe
you're talking about, there are so many cases it's hard for me
to keep track) then HE KNOWS WHAT HE IS DOING even if using that
source address to talk to a particular remote address makes no sense.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Willy Tarreau]

[Cc: list stripped down to MLs only]

> > > 2) what the default behavior should be
> > 
> > I think we should apply the exact same source selection as IP to ARP.
> 
> This is what setting the "arp_filter" sysctl on a device does
> if you've setup the preferred source on your routes correctly.
> If we would use that IP address to speak to the destination in
> the ARP, we respond, else we do not.
> 
> I've quoted the 'arp_filter' entry in Documentation/sysctl/ip-sysctl.txt
> please give it a read.

I've read it, but it's not about the same problem. It solves some problems
related to *INCOMING REQUESTS*, that some people are complaining about. My
problem was with source address for *OUTGOING REQUESTS*, and the arp_filter
sysctl has nothing to do with it since it. Arptables helps fixing this problem.

I fully respect your desire not to break existing behaviour, because even if
I'm fairly certain that *nobody* uses the current "feature" I'm facing, it's
possible that a definitive fix would break the workarounds they have set up for
this problem.

But if you agree to review it, I'm willing to write a simple patch which
provides a sysctl to enable automatic valid source for *OUTGOING REQUESTS*.
Basically, echoing 1 to /proc/sys/net/ipv4/ethXXX/arp_auto_src would select a
valid source address for outgoing ARP requests. I can even do it both for 2.4
and 2.6 (just need a bit more time). All other strange setups will have to be
left to arptables.

Now if you think that the behaviour I'm proposing is broken, please explain me
why. I'm not closed, I just want to understand, and since the beginning, I've
only heard about ARP replies but not requests.

Cheers,
Willy

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Mon, 18 Aug 2003 07:19:28 -0700
"David S. Miller" <davem@redhat.com> wrote:

> On Mon, 18 Aug 2003 16:23:10 +0200
> Stephan von Krawczynski <skraw@ithnet.com> wrote:
> 
> > > Both 2.0 and 2.2 answer on all interfaces for ARP requests
> > > by default just like 2.4 does.
> > 
> > Try it. Proven wrong. See above.
> 
> Ok then.
> 
> It still doesn't change the essence of this conversation.  Changing
> things would break a lot of people's setups.

Please explain _one_. I mean you must have something special in your mind, or
not?

> See the other posting from someone about IPMP (IP multipathing).

Perhaps it would have been a good idea to explain some details about what he
thinks would break if default behaviour was changed. At least for me it is
non-obvious. He could have stated "42", too...

Regards,
Stephan

SRC IP selection in ARP request (Was: bugfix: ARP respond on all devices)

[Vladimir B. Savkin]

On Sun, Aug 17, 2003 at 06:27:13PM +0200, Carlos Velasco wrote:
> If you send a packet through dev eth0 to dev lo IP address or other
                                        ^^
	Did you mean "from"?

> interface, when Linux try to map the MAC address with the IP address of
> the default gateway (or the gateway to reach the packet Source IP
> address), it uses the lo IP address (or other dev) in the ARP Request.

I think I saw this problem, but in another situation:
Suppose we are the server and have TCP connection established,
using src address 10.0.0.1 (because the client have chosen this address 
to connect to). But the route to the client leads via gateway 10.1.0.1,
reachable through dev eth0. We have address 10.1.0.2/24 assigned to
eth0. All is fine until ARP table entry for 10.1.0.1 is expired and
we start to send ARP requests. We choose 10.0.0.1 for src ip in the
requests, because that's what upper layer uses, and gateway doesn't
respond because it's Cisco or BSD.

I didn't test arpfilter (I think it wasn't there when I met this
problem), but it can be solved with the following simple patch
(implemented as a new per-interface sysctl). I just tested it, works for
me. echo 1 > /proc/sys/net/ipv4/conf/all/arp_select_clean_src

diff -ur _orig_linux/include/linux/inetdevice.h linux/include/linux/inetdevice.h
--- _orig_linux/include/linux/inetdevice.h	Mon Aug 11 13:24:51 2003
+++ linux/include/linux/inetdevice.h	Mon Aug 18 18:21:30 2003
@@ -18,6 +18,7 @@
 	int	mc_forwarding;
 	int	tag;
 	int     arp_filter;
+	int 	arp_select_clean_src;
 	int	medium_id;
 	void	*sysctl;
 };
@@ -68,6 +69,7 @@
 	  (ipv4_devconf.accept_redirects || (in_dev)->cnf.accept_redirects)))
 
 #define IN_DEV_ARPFILTER(in_dev)	(ipv4_devconf.arp_filter || (in_dev)->cnf.arp_filter)
+#define IN_DEV_ARP_CLEAN_SRC(in_dev)	(ipv4_devconf.arp_select_clean_src || (in_dev)->cnf.arp_select_clean_src)
 
 struct in_ifaddr
 {
diff -ur _orig_linux/include/linux/sysctl.h linux/include/linux/sysctl.h
--- _orig_linux/include/linux/sysctl.h	Mon Aug 11 13:28:18 2003
+++ linux/include/linux/sysctl.h	Mon Aug 18 18:52:01 2003
@@ -349,6 +349,7 @@
 	NET_IPV4_CONF_TAG=12,
 	NET_IPV4_CONF_ARPFILTER=13,
 	NET_IPV4_CONF_MEDIUM_ID=14,
+	NET_IPV4_CONF_ARPSRC=15,
 };
 
 /* /proc/sys/net/ipv6 */
diff -ur _orig_linux/net/ipv4/arp.c linux/net/ipv4/arp.c
--- _orig_linux/net/ipv4/arp.c	Mon Aug 11 13:24:52 2003
+++ linux/net/ipv4/arp.c	Mon Aug 18 18:36:44 2003
@@ -322,8 +322,20 @@
 	struct net_device *dev = neigh->dev;
 	u32 target = *(u32*)neigh->primary_key;
 	int probes = atomic_read(&neigh->probes);
+	int inherit_src;
+	struct in_device *in_dev;
 
-	if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL)
+	read_lock(&inetdev_lock);
+	in_dev = __in_dev_get(dev);
+	if (in_dev != NULL) {
+		inherit_src = !IN_DEV_ARP_CLEAN_SRC(in_dev);
+	} else {
+		inherit_src = 1;
+	}
+	read_unlock(&inetdev_lock);
+
+	if ( inherit_src &&
+		  skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL)
 		saddr = skb->nh.iph->saddr;
 	else
 		saddr = inet_select_addr(dev, target, RT_SCOPE_LINK);
diff -ur _orig_linux/net/ipv4/devinet.c linux/net/ipv4/devinet.c
--- _orig_linux/net/ipv4/devinet.c	Fri Jun 13 18:51:39 2003
+++ linux/net/ipv4/devinet.c	Mon Aug 18 18:54:07 2003
@@ -1056,7 +1056,7 @@
 static struct devinet_sysctl_table
 {
 	struct ctl_table_header *sysctl_header;
-	ctl_table devinet_vars[15];
+	ctl_table devinet_vars[16];
 	ctl_table devinet_dev[2];
 	ctl_table devinet_conf_dir[2];
 	ctl_table devinet_proto_dir[2];
@@ -1104,6 +1104,9 @@
 	 &proc_dointvec},
 	{NET_IPV4_CONF_ARPFILTER, "arp_filter",
 	 &ipv4_devconf.arp_filter, sizeof(int), 0644, NULL,
+	 &proc_dointvec},
+	{NET_IPV4_CONF_ARPSRC, "arp_select_clean_src",
+	 &ipv4_devconf.arp_select_clean_src, sizeof(int), 0644, NULL,
 	 &proc_dointvec},
 	 {0}},
 

:wq
                                        With best regards, 
                                           Vladimir Savkin. 

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bill Davidsen]

On Sun, 17 Aug 2003, David S. Miller wrote:

> On Mon, 18 Aug 2003 00:48:49 +0200
> Willy Tarreau <willy@w.ods.org> wrote:
> 
> > On Sun, Aug 17, 2003 at 06:24:06PM +0100, Alan Cox wrote:
> >  
> > > So stick the address on eth0 not on lo since its not a loopback but an eth0
> > > address, then use arpfilter so you don't arp for the invalid magic shared IP
> > > address, or NAT it, or it may work to do
> > > 
> > >          ip route add nexthop-addr src my-virtual-addr dev eth0 scope local onlink
> > >          ip route add default src my-virtual-addr via nexthop-addr dev eth0 scope global
> >  
> > I have a case where this doesn't work
> 
> Replying again... Alan does mention in the paragraph you've quoted
> to use arpfilter, which works for every case imaginable.

Okay, I'll show my ignorance and ask... the Documentation for arp_filter
says source routing must be used. Is there some flag I'm missing, or a way
to avoid having a rule per address, or is the 8 bit rule number larger in
2.6, or ??? Or is having a lot of IPs on one machine not an imaginable
case?

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bill Davidsen]

On Mon, 18 Aug 2003, David S. Miller wrote:

> On Mon, 18 Aug 2003 14:34:01 +0200
> Stephan von Krawczynski <skraw@ithnet.com> wrote:
> 
> > what is the _positive_ outcome of this
> > implementation compared to others?
> 
> If you're not willing to think I can't help you resolve
> the questions you have.

Trying to think of something you have never seen is like trying to think
of a new color. I can not think of a case where the current default
behaviour is better (you can define that as your will, in terms of either
functionality or convenience).

> 
> If you don't understand source address selection, than it's
> not possible for me to have an intellegent conversation about
> this topic.
> 
> So you need to make this crucial first step.
> 

Good buzz words, your mailer dropped the URL of the document with the
examples... Complaining that people don't understand without providing a
pointer to some help for that lack is not helping them (or reducing the
call for changes). If you want people to stop asking for patches help them
do what they need to do.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Ben Greear]

Bill Davidsen wrote:

> Okay, I'll show my ignorance and ask... the Documentation for arp_filter
> says source routing must be used. Is there some flag I'm missing, or a way
> to avoid having a rule per address, or is the 8 bit rule number larger in
> 2.6, or ??? Or is having a lot of IPs on one machine not an imaginable
> case?

Last response I got was that one would have to hack the netlink api to get
a bigger index because the design (and rfc, unfortunately) describe the
field as only 8 bits.  I never did hear a response to my comment that this
was inadequate in this age of vlans...

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bas Bloemsaat]

>
> Okay, I'll show my ignorance and ask... the Documentation for arp_filter
> says source routing must be used. Is there some flag I'm missing, or a way
> to avoid having a rule per address, or is the 8 bit rule number larger in
> 2.6, or ??? Or is having a lot of IPs on one machine not an imaginable
> case?

I'll include a conversation I had with David, yesterday. Maybe it clear
things up:

Someone: Replying again... Alan does mention in the paragraph you've quoted
Someone: to use arpfilter, which works for every case imaginable.

Me: No it doesn't. When I have two nics on DHCP on the same ethernet
segment, it
M: cannot be made to work. I don't know the ip addresses beforehand. And if
if
M: I would get them with scripting and crafted some rules on the fly,
there's
M: no way I can be sure I'll get the same IP's on a renew, so I'd have to
check
M: often.

David: You don't understand how 'arpfilter' works.
D: It's a netfilter module that allows you to block ARP packets
D: going in and out of the system using any criteria you want.
D: It can block on device, on src MAC address, on destination
D: MAC address, whatever you want.

Me: Maybe you could explain to me how to filter out all ARP
M: responses to an IP not bound to that mac address, of letting through all
the
M: ARP responses for an IP bound to that mac, without specifying the IP
address
M: (because that can change, sometimes quite often). I really do not see it.

D: You wouldn't use 'arpfiler' for that.

D: You would use the 'arp_filter' sysctl on your devices and
D: proper setting of the preferred source in the routes on
D: your machine.

M: For that I'd still need the IP address. Don't I? And I don't have that
until
M: later, and it is prone to change.
M: So I have a feeling you are sending me in circles.

D: You need to change routes when the IP address changes, so all I'm
D: asking you to do is setup your routes correctly at those points
D: in time.

M: Which is on dhcp renew. Which calls for a rewrite of dhcpclient, or a
daemon
M: that monitors it.

D: Sure, if software is setting routes manually and it isn't
D: doing so the way you want it to it'll need changes.

In other words: it keeps being done the way it is now, never mind people
having problems with it. Never mind the changing it doesn't break anything.
Never mind I cannot come up with a scenario that actually benefits from the
current situation over the new situation.

IP Multipathing does not qualify. The current way actually violates IP
multipathing: Multipathing calls for two seperate, fixed internal IP's which
are seperated from each other. Multipathing requires you to restore the IP
address to it's preferred interface if it comes up again. In multipathing,
all IP's have preferred interfaces, not one left by chance. Remember that
multipathing doesn't need to be symmetric. It may very way have a fat pipe
on one end, and a smaller backup pipe.

All of this is not satisfied with the current, broken, linux arp. So we're
still short of an example that benefits from the current situation

Regards,
Bas

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Mon, 18 Aug 2003 20:21:00 -0700
Ben Greear <greearb@candelatech.com> wrote:

> I never did hear a response to my comment that this
> was inadequate in this age of vlans...

Just define a rtnetlink attribute to extend the ID
number, that's all.  It's not hard work and it eliminates
the 8-bit limit.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bas Bloemsaat]

> > Under Linux, by default, IP addresses are owned by the system
> > not by interfaces.
>
> Folks, the above is the punch line. I am just going over all emails on
> this thread and i see this point being missed.
> People are quoting tons of RFCs while the really important point being
> missed is the above line.

If that is true, then source routing would not work either: it would just
route it back to the host, select the next hop, and choose based on
destination routing tables. There would be no way to know which IP address
is bound to which interface.
If that is true, then then having multiple network interfaces on a segment
would in effect mean that you have one IP address on multiple interfaces. As
Alan mentioned that is an illegal configuration.
If that is true, seperation of firewall interfaces is impossible.

All of which isn't the case.

I'll let it rest for now. I don't think quoting rfc's, pointing out that it
doesn't confirm to any reference implementation of IP, or any argument are
going to help. This is not a case where technical merits win. This is
politics. I don't care anymore.

Regards,
Bas

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bill Davidsen]

On Wed, 20 Aug 2003, David S. Miller wrote:

> On Wed, 20 Aug 2003 10:44:41 -0700
> Ben Greear <greearb@candelatech.com> wrote:
> 
> > It seems that these reasons would not preclude the addition of a flag
> > that would default to the current behaviour but allow the behaviour that
> > other setups desire easily?
> 
> I would accept a patch that did something like
> the following in arp_solicit().
> 
> 	if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL &&
> 	    (in_dev->conf.shared_media ||
> 	     inet_addr_onlink(dev, skb->nh.iph->saddr, 0)))
> 		saddr = skb->nh.iph->saddr;
> 	else
> 		saddr = inet_select_addr(dev, target, RT_SCOPE_LINE);
> 
> Then people can frob the shared_media sysctl for devices
> where they want the behavior to be that we will only use
> addresses assigned to the device as the solicitor address.
> 
> The shared_media setting defaults to one and thus would preserve
> current behavior by default.
> 
> The idea is not mine, Alexey suggested it to me the other day.
> 
> I hope this pleases people wrt. ARP request solicitor address
> handling.

I'm not sure if you changed your mind or someone finally made a proposal
you like on the ARP issue, but is there an implementation your would find
acceptable (other than source routing) to send packets out from the NIC
with the SIP configured when there are multiple NICs and IPs in the same
subnet? Using a random NIC for a given SIP confuses Cisco routers (and
other things).

Source routing becomes very complicated when there are a lot of IPs and
they are changing, and there are several patches which force binding a SIP
to a NIC, but you don't seem to like any of them. Please suggest a better
way. 

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Julian Anastasov]

	Hello,

On Wed, 20 Aug 2003, David S. Miller wrote:

> Then people can frob the shared_media sysctl for devices
> where they want the behavior to be that we will only use
> addresses assigned to the device as the solicitor address.
>
> The shared_media setting defaults to one and thus would preserve
> current behavior by default.

	Hm, you are trying to save one additional flag :)

> The idea is not mine, Alexey suggested it to me the other day.
>
> I hope this pleases people wrt. ARP request solicitor address
> handling.

	More ideas/issues:

- can we add medium_id checks near the inet_addr_onlink check,
i.e. to extend the check for same medium, not only for same outdev,
eg. saddr and outdev can be from same medium. That means we
have to use ip_dev_find as replacement for inet_addr_type and
inet_addr_onlink

- fib_validate_source already drops packets from device with
in_dev==NULL, there is no good reason to send ARP requests.
Even ip_route_output_slow disallows such devices. That is, IP
is disabled, so and ARP.

- in the last days/weeks I have a doubt how asymmetric routing
can safely work with the default behaviour. The arp_queue can
contain packets with saddrs from different interfaces and subnets,
all to the same resolved target IP. I'm not sure the remote system
can properly answer to our requests in this case, at least, can
not do it properly without rp_filter_mask [1] if there are 2 or
more interfaces. Of course, the problem is when rp_filter is used
there.

- Broadcasting announcements for one saddr through many devices
can create problems for us if we later receive traffic for this
saddr when rp_filter=1 and there is no rp_filter_mask set. Can
someone provide example setup for asymmetric routing that relies
on the current behavior, I'll be glad to think on it.

- can we swicth to safe behavior according to the probe number?
For example, after the 1st ucast or bcast probe we can switch
to source auto selection?

[1] http://www.ssi.bg/~ja/#rp_filter_mask

Regards

--
Julian Anastasov <ja@ssi.bg>

RE: [2.4 PATCH] bugfix: ARP respond on all devices

[Richard Underwood]

David S. Miller wrote:
> 
> BTW, another thing which makes the source address selection for
> outgoing ARPs a real touchy area is the following.  Some weird
> configurations actually respond with different ARP answers based upon
> the source address in the ARP request.  You can ask Julian Anastasov
> about such (arguably pathological) setups.
> 
	*smirk* How horrible. I'm not sure you should be proud of supporting
this, and certainly not proud of only half-supporting it. It wouldn't work
reliably as things are now as packets will always follow the ARP reply
generated by the very first packet.

	If you want to facilitate this sort of network, you'd need to cache
an ARP reply for an IP number against BOTH the Interface AND the interface
address used as the source of the ARP request. Only then could you guarantee
that packets go to the correct IP number out of the correct interface based
on their source address.

		Richard

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bas Bloemsaat]

> I don't think anyone is asking for a change in the default behaviour
> (although my point about breaking modules does apply), people would be
> satisfied, even ecstatic, if we had a simple way (flag) to set to make
> Linux work without setting /proc filters, using arpfilter, applying source
> routes (David's suggestion) and generally jumping through hoops.
Agree! Just a flag (ARP_ISOLATED, default to 0) in
/proc/sys/net/ipv4/conf/*? The default behaviour of the current (and future
kernels) stays as it is now, so it doesn't break for anyone, and a lot of
people (including me :) benefit from a much easier setup.

No need to implement a whole hidden scenario either.

Regards,
Bas

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bill Davidsen]

On Wed, 20 Aug 2003, David S. Miller wrote:

> On Wed, 20 Aug 2003 12:49:14 -0400 (EDT)
> Bill Davidsen <davidsen@tmr.com> wrote:
> 
> > On 19 Aug 2003, Daniel Gryniewicz wrote:
> > 
> > I have been asking for a similar thing as well, David mentioned some
> > things that would break, but I believe they break if you use source
> > routing, so that seems not to be a real objection.
> 
> It's not about source routing.  It's about failover and being
> able to use ARP on interfaces which don't have addresses assigned
> to them yet.

David mentioned that you could solve the problem by using *rp_filter and
source routing. I don't think that's entirely true, but doing so has the
same drawbacks and breaks the same things as a flag to make Linux behave
like Sun/BSD/Windows (and work with Cisco is the cases previously
mentioned).

> 
> > I find it interesting that we can't change networking because a few
> > complex systems would have to be reconfigured, but we *can* change modules
> > which requires config changes on probably 90% of all systems (commercial
> > distributions).
> 
> Decisions about Networking will always be in a different domain
> because the way one behaves has effects upon other systems not
> just the local one.

Yes, that's exactly the point, the way Linux works has bad effects on
certain other machines, as in leaves them disconnected to the Linux
system.

> 
> BTW, another thing which makes the source address selection for
> outgoing ARPs a real touchy area is the following.  Some weird
> configurations actually respond with different ARP answers based upon
> the source address in the ARP request.  You can ask Julian Anastasov
> about such (arguably pathological) setups.
> 

I don't think anyone is asking for a change in the default behaviour
(although my point about breaking modules does apply), people would be
satisfied, even ecstatic, if we had a simple way (flag) to set to make
Linux work without setting /proc filters, using arpfilter, applying source
routes (David's suggestion) and generally jumping through hoops.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Wed, 20 Aug 2003 10:44:41 -0700
Ben Greear <greearb@candelatech.com> wrote:

> It seems that these reasons would not preclude the addition of a flag
> that would default to the current behaviour but allow the behaviour that
> other setups desire easily?

I would accept a patch that did something like
the following in arp_solicit().

	if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL &&
	    (in_dev->conf.shared_media ||
	     inet_addr_onlink(dev, skb->nh.iph->saddr, 0)))
		saddr = skb->nh.iph->saddr;
	else
		saddr = inet_select_addr(dev, target, RT_SCOPE_LINE);

Then people can frob the shared_media sysctl for devices
where they want the behavior to be that we will only use
addresses assigned to the device as the solicitor address.

The shared_media setting defaults to one and thus would preserve
current behavior by default.

The idea is not mine, Alexey suggested it to me the other day.

I hope this pleases people wrt. ARP request solicitor address
handling.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Ben Greear]

David S. Miller wrote:
> On Wed, 20 Aug 2003 12:49:14 -0400 (EDT)
> Bill Davidsen <davidsen@tmr.com> wrote:
> 
> 
>>On 19 Aug 2003, Daniel Gryniewicz wrote:
>>
>>I have been asking for a similar thing as well, David mentioned some
>>things that would break, but I believe they break if you use source
>>routing, so that seems not to be a real objection.
> 
> 
> It's not about source routing.  It's about failover and being
> able to use ARP on interfaces which don't have addresses assigned
> to them yet.

[snip]

> BTW, another thing which makes the source address selection for
> outgoing ARPs a real touchy area is the following.  Some weird
> configurations actually respond with different ARP answers based upon
> the source address in the ARP request.  You can ask Julian Anastasov
> about such (arguably pathological) setups.

It seems that these reasons would not preclude the addition of a flag
that would default to the current behaviour but allow the behaviour that
other setups desire easily?  That seems to be all that folks are really
arguing for.  If/when the user enabled this new flag, then they should
be fully responsible for the change in behaviour, and they can deal with
it as needed.

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Wed, 20 Aug 2003 12:49:14 -0400 (EDT)
Bill Davidsen <davidsen@tmr.com> wrote:

> On 19 Aug 2003, Daniel Gryniewicz wrote:
> 
> I have been asking for a similar thing as well, David mentioned some
> things that would break, but I believe they break if you use source
> routing, so that seems not to be a real objection.

It's not about source routing.  It's about failover and being
able to use ARP on interfaces which don't have addresses assigned
to them yet.

> I find it interesting that we can't change networking because a few
> complex systems would have to be reconfigured, but we *can* change modules
> which requires config changes on probably 90% of all systems (commercial
> distributions).

Decisions about Networking will always be in a different domain
because the way one behaves has effects upon other systems not
just the local one.

BTW, another thing which makes the source address selection for
outgoing ARPs a real touchy area is the following.  Some weird
configurations actually respond with different ARP answers based upon
the source address in the ARP request.  You can ask Julian Anastasov
about such (arguably pathological) setups.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bill Davidsen]

On 19 Aug 2003, Daniel Gryniewicz wrote:

> I realize that, but is that a reason to keep linux from working with
> these?  (And it's not just cisco, all the *BSDs (and therefore anything
> that took the BSD stack such as MS) work this way too.)  As nearly as I
> can tell, there's no way to make linux work with these, and the
> situation I gave is one where linux could easily get it right, and
> isn't.  Saying "They're broken.  Tough." is not really helpful.  At
> least can we get a "work with broken other systems in certain
> circumstances" switch somewhere?

I have been asking for a similar thing as well, David mentioned some
things that would break, but I believe they break if you use source
routing, so that seems not to be a real objection.

> 
> (Funny you should mention Cisco, as we write routing software and must
> interoperate with Cisco.  What Cisco says *does* go in the routing
> community, if you wish your product to be used.  Currently, when our
> customers come to us, we have to say "Either don't use Linux or run 2.2
> with the arp fix patch.")

Unless all your customers do odd things with networking, or you are not
using source routing for some reason, you don't do customers a favor by
giving that advice. Most users have one NIC with one IP and Linux works.

The Linux implementation is not broken by standard, it's just that there
were two ways to do it, and the one chosen is allowed by frequently
non-functional.

I find it interesting that we can't change networking because a few
complex systems would have to be reconfigured, but we *can* change modules
which requires config changes on probably 90% of all systems (commercial
distributions). Linus has rethought some of his design decisions, but
David seems intent on not only keeping this one, but preventing the
addition of a flag which would solve the problem for most people.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Roman Pletka]

Stephan von Krawczynski wrote:
 >On Wed, 20 Aug 2003 16:43:42 +0200
 >Roman Pletka <rap@zurich.ibm.com> wrote:
 >
 >
 >>Please read carefully what you have quoted:
 >>It says: *An* implementation... and then goes on with a citation of RFC 826.
 >>A simple citation does not make a valid standard yet. It just refers to it
 >>as an example for this specific issue. That's all.
 >
 >
 >Sorry, but my reading is this "An implementation of the ( Address Resolution
 >Protocol (ARP) [LINK:2] ) ..."
 >Do you understand what I mean?
 >
 >If you insist on RFC-826 being only one of several (possible) ARP
 >implementations, can you then please name an RFC where ARP as a protocol is
 >clearly defined? I mean there must be one, or not?

This is not the point. As has already been mentioned some days ago by davem
RFC 826 explicitely states at the beginning that it is not the specification
of an Internet Standard and thats what I meant.

So let's stop spinning round on this.

-- Roman

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Wed, 20 Aug 2003 16:43:42 +0200
Roman Pletka <rap@zurich.ibm.com> wrote:

> Stephan von Krawczynski wrote:
> > <qoute RFC 1122>
> >       2.3.2  Address Resolution Protocol -- ARP
> > 
> >          2.3.2.1  ARP Cache Validation
> > 
> >             An implementation of the Address Resolution Protocol (ARP)
> >             [LINK:2] MUST provide a mechanism to flush out-of-date cache
> >             entries.  If this mechanism involves a timeout, it SHOULD be
> >             possible to configure the timeout value.
> > 
> > ...
> > 
> > [LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826,
> >      November 1982.
> > 
> > </quote>
> > 
> 
> Please read carefully what you have quoted:
> It says: *An* implementation... and then goes on with a citation of RFC 826.
> A simple citation does not make a valid standard yet. It just refers to it
> as an example for this specific issue. That's all.

Sorry, but my reading is this "An implementation of the ( Address Resolution
Protocol (ARP) [LINK:2] ) ..."
Do you understand what I mean?

If you insist on RFC-826 being only one of several (possible) ARP
implementations, can you then please name an RFC where ARP as a protocol is
clearly defined? I mean there must be one, or not?

Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Tue, 19 Aug 2003 12:28:47 -0700
"David S. Miller" <davem@redhat.com> wrote:

> On 19 Aug 2003 21:32:35 +0200
> Andi Kleen <ak@colin2.muc.de> wrote:
> 
> > What happens on outgoing active ARPs is a different thing. Reasonable
> > choices would be either the prefered source address of the route or
> > the local interface's address. I must admit I don't have a strong
> > opinion on what the better behaviour of those is, but neither of them would
> > seem particularly wrong to me.
> 
> Andi, we take the source address from the packet we are
> trying to send out that interface.
> 
> Just as it is going to be legal to send out a packet from
> that interface using that source address, it is legal to
> send out an ARP request from that interface using that source
> address.

Aehm, sorry but the logic is bogus. A routed packet will be sent out this
interface with a foreign IP as source, too. Though nobody will want to send an
arp request with a foreign ip as source.
But you say here: Just as I can send out a packet with IP X from that interface
I can send out ARP request with same source.
Obviously you don't want that.
So you cannot step from A to B in your logical chain here.

Again. I'd like to stress I don't want to insult you or anything. The simple
thing is this: there are a lot setups out there that could benefit from your
tolerance in this issue. Can't we simply take the issue to the point: "you are
right, but you show tolerance for boxes that are not completely wrong" ?
I mean the world is full of people that are right and intolerant, so that in
fact doesn't really make them special ...

Please let us keep in mind that joe-average-user cannot handle complex setups
with arpfilter, arp_filter or anything the like. But he can right away enter
IT-superstore XYZ and buy a brand new router box for 20 bucks. If he is unlucky
(and you stay intolerant) he will for sure _not_ blame this box but his desktop
linux if things don't work out as expected.
I think we should at least make a minimum effort to keep things simple (and
explainable to joe-average-user), even if the background is complex.
Everywhere we have a solution for a problem that is overly complex, we will
fail to gain a broad market share, because there may very likely be easier
solutions under <name-some-os> _and_ we attract support problems for all
distributors.

Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Wed, 20 Aug 2003 17:41:33 +0200
Stephan von Krawczynski <skraw@ithnet.com> wrote:

> Aehm, sorry but the logic is bogus. A routed packet will be sent out this
> interface with a foreign IP as source, too.

I'm talking about "local" addresses.

When we're routing, we'll use an interface address of
course.

But when the packet is originating from our host, and
the source address in the outgoing packet is local to
us, we will use it as the source in the ARP packet.

Look at the algorithm in net/ipv4/arp_solicit() to see
what I mean.

RE: [2.4 PATCH] bugfix: ARP respond on all devices

[jamal]

On Wed, 2003-08-20 at 11:23, jamal wrote:
> What Dave meant is the state machine used in 2461 for IPV6 is actually
> used in v4 as well. 

I should have said in linux - dont think in any BSD derived OSes.
To be specific look at the neighbor code.

cheers,
jamal

RE: [2.4 PATCH] bugfix: ARP respond on all devices

[jamal]

What Dave meant is the state machine used in 2461 for IPV6 is actually
used in v4 as well. There is no equivalent RFC that is valid for IPv4.
Maybe one can be written (fire! fire! where are the firemen?).

for V6 (ndisc not ARP) check the validation tests the usagi people have
been doing against 2461.

cheers,
jamal

On Wed, 2003-08-20 at 04:58, Richard Underwood wrote:
> David S. Miller wrote:
> > 
> > Indeed, would people stop quoting from RFC 985 and
> > RFC 826.
> 
> 	In case anyone missed it, the following message was posted to
> linux-net and netdev. This is currently a draft standard, but anyone
> implementing IPv6 should be following it. It clearly states that the the
> source address for the equivalent of the ARP request should be the INTERFACE
> address.
> 
> 	While it doesn't directly apply to IPv4 (except for David's claim
> that IPv4 ARP is based on IPv6 ARP) it does clarify the situation nicely.
> 
> 	I, for one, will be glad when (!) we all migrade to IPv6 and we can
> once and all be done with this nonsense, unless Linux plans to deviate from
> the standard?
> 
> 	Thanks,
> 
> 		Richard
> 
> -----Original Message-----
> From: Steven Blake [mailto:slblake@petri-meat.com]
> Sent: 20 August 2003 05:58
> To: David S. Miller
> Cc: netdev@oss.sgi.com; linux-net@vger.kernel.org
> Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices
> 
> 
> On Tue, 2003-08-19 at 13:53, David S. Miller wrote:
> 
> > BTW, this ARP source address algorithm we use comes from
> > ipv6, it would be instructive to go and see why they do
> > things the way they do.
> 
> Are you sure?  See below:
> 
> ========================================================================
> 
> RFC 2461              Neighbor Discovery for IPv6          December 1998
> 
> 
> 4.3.  Neighbor Solicitation Message Format
> 
>    Nodes send Neighbor Solicitations to request the link-layer address
>    of a target node while also providing their own link-layer address to
>    the target.  Neighbor Solicitations are multicast when the node needs
>    to resolve an address and unicast when the node seeks to verify the
>    reachability of a neighbor.
> 
>          0                   1                   2                   3
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |     Type      |     Code      |          Checksum             |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                           Reserved                            |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                                                               |
>         +                                                               +
>         |                                                               |
>         +                       Target Address                          +
>         |                                                               |
>         +                                                               +
>         |                                                               |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |   Options ...
>         +-+-+-+-+-+-+-+-+-+-+-+-
> 
>    IP Fields:
> 
>       Source Address
>                      Either an address assigned to the interface from
>                      which this message is sent or (if Duplicate Address
>                      Detection is in progress [ADDRCONF]) the
>                      unspecified address.
> 
>       Destination Address
>                      Either the solicited-node multicast address
>                      corresponding to the target address, or the target
>                      address.
> 
>       Hop Limit      255
> 
>       Authentication Header
>                      If a Security Association for the IP Authentication
>                      Header exists between the sender and the
>                      destination address, then the sender SHOULD include
>                      this header.
> 
> 
> 
> 
> 
> Narten, et. al.             Standards Track                    [Page 21]
> 
> ========================================================================
> 
> 
> Regards,
> 
> // Steve
> 
> 

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Roman Pletka]

Stephan von Krawczynski wrote:
> <qoute RFC 1122>
>       2.3.2  Address Resolution Protocol -- ARP
> 
>          2.3.2.1  ARP Cache Validation
> 
>             An implementation of the Address Resolution Protocol (ARP)
>             [LINK:2] MUST provide a mechanism to flush out-of-date cache
>             entries.  If this mechanism involves a timeout, it SHOULD be
>             possible to configure the timeout value.
> 
> ...
> 
> [LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826,
>      November 1982.
> 
> </quote>
> 

Please read carefully what you have quoted:
It says: *An* implementation... and then goes on with a citation of RFC 826.
A simple citation does not make a valid standard yet. It just refers to it
as an example for this specific issue. That's all.

-- Roman

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Wed, 20 Aug 2003 10:49:46 +0200
Roman Pletka <rap@zurich.ibm.com> wrote:

> Bas Bloemsaat wrote:
> >>Indeed, would people stop quoting from RFC 985 and
> >>RFC 826.
> > 
> > 
> > RFC 826 is referenced from 1009 as describing ARP. So in effect it does
> > define a standard.
> 
> RFC 1009 is obsolete too (by 1812 for the sake of completeness).
> Please stop quoting obsolete RFC's.
> 
> -- Roman

One of the big advantages of RFCs is that everybody can read them. In fact if
one names a special RFC for proving something he said, he should at least have
read it once:

<quote RFC 1812>
3.3.2 Address Resolution Protocol - ARP

   Routers that implement ARP MUST be compliant and SHOULD be
   unconditionally compliant with the requirements in [INTRO:2].

...

   INTRO:2.
        Internet Engineering Task Force (R. Braden, Editor),
        "Requirements for Internet Hosts - Communication Layers", STD 3,
        RFC 1122, USC/Information Sciences Institute, October 1989.

</quote>

=>

<qoute RFC 1122>
      2.3.2  Address Resolution Protocol -- ARP

         2.3.2.1  ARP Cache Validation

            An implementation of the Address Resolution Protocol (ARP)
            [LINK:2] MUST provide a mechanism to flush out-of-date cache
            entries.  If this mechanism involves a timeout, it SHOULD be
            possible to configure the timeout value.

...

[LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826,
     November 1982.

</quote>

=>

RFC-826 is _valid_

Why do you think it is not valid, Roman? Where do you read that?

Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Harley Stenzel]

David S. Miller wrote:
> On Tue, 19 Aug 2003 19:05:13 +0100
> Richard Underwood <richard@aspectgroup.co.uk> wrote:
> 
>>	The ARP request represents all FUTURE
>>packets being sent out that interface, not just the one single packet that
>>happened to kick of this ARP request.
> 
> That's RIGHT!  And by your own argument the source address
> in the ARP request IS IRRELEVANT and is to be ignored!
> 

The source address in the ARP request is not irrelevant, because a 
broadcast arp request causes all recipients of that broadcast request to 
update their arp cache entry (if they have a cache entry for that IP) 
for the IP specified in the source with the MAC specified in the request.

So, in an environment where a single address is aliased in multiple 
places, such as tunnel endpoints and loopback aliases, and in 
multi-homed same-segment configs, it is unpredictable asto which IP will 
be bound to which MAC for every machine (or arp cache) on the network.

--Harley

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Alan Cox]

On Maw, 2003-08-19 at 20:28, David S. Miller wrote:
> Andi, we take the source address from the packet we are
> trying to send out that interface.
> 
> Just as it is going to be legal to send out a packet from
> that interface using that source address, it is legal to
> send out an ARP request from that interface using that source
> address.

Legal yes, but it can get you into holes with asymettric routing.

RE: [2.4 PATCH] bugfix: ARP respond on all devices

[Richard Underwood]

David S. Miller wrote:
> 
> Indeed, would people stop quoting from RFC 985 and
> RFC 826.

	In case anyone missed it, the following message was posted to
linux-net and netdev. This is currently a draft standard, but anyone
implementing IPv6 should be following it. It clearly states that the the
source address for the equivalent of the ARP request should be the INTERFACE
address.

	While it doesn't directly apply to IPv4 (except for David's claim
that IPv4 ARP is based on IPv6 ARP) it does clarify the situation nicely.

	I, for one, will be glad when (!) we all migrade to IPv6 and we can
once and all be done with this nonsense, unless Linux plans to deviate from
the standard?

	Thanks,

		Richard

-----Original Message-----
From: Steven Blake [mailto:slblake@petri-meat.com]
Sent: 20 August 2003 05:58
To: David S. Miller
Cc: netdev@oss.sgi.com; linux-net@vger.kernel.org
Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices


On Tue, 2003-08-19 at 13:53, David S. Miller wrote:

> BTW, this ARP source address algorithm we use comes from
> ipv6, it would be instructive to go and see why they do
> things the way they do.

Are you sure?  See below:

========================================================================

RFC 2461              Neighbor Discovery for IPv6          December 1998


4.3.  Neighbor Solicitation Message Format

   Nodes send Neighbor Solicitations to request the link-layer address
   of a target node while also providing their own link-layer address to
   the target.  Neighbor Solicitations are multicast when the node needs
   to resolve an address and unicast when the node seeks to verify the
   reachability of a neighbor.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |     Code      |          Checksum             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                           Reserved                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                                                               +
        |                                                               |
        +                       Target Address                          +
        |                                                               |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Options ...
        +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     Either an address assigned to the interface from
                     which this message is sent or (if Duplicate Address
                     Detection is in progress [ADDRCONF]) the
                     unspecified address.

      Destination Address
                     Either the solicited-node multicast address
                     corresponding to the target address, or the target
                     address.

      Hop Limit      255

      Authentication Header
                     If a Security Association for the IP Authentication
                     Header exists between the sender and the
                     destination address, then the sender SHOULD include
                     this header.





Narten, et. al.             Standards Track                    [Page 21]

========================================================================


Regards,

// Steve

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Roman Pletka]

Bas Bloemsaat wrote:
>>Indeed, would people stop quoting from RFC 985 and
>>RFC 826.
> 
> 
> RFC 826 is referenced from 1009 as describing ARP. So in effect it does
> define a standard.

RFC 1009 is obsolete too (by 1812 for the sake of completeness).
Please stop quoting obsolete RFC's.

-- Roman

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Tue, 19 Aug 2003 15:11:37 -0700
"David S. Miller" <davem@redhat.com> wrote:

> On Tue, 19 Aug 2003 23:12:38 +0100
> Richard Underwood <richard@aspectgroup.co.uk> wrote:
> 
> > 	I'm certain that Cisco (for example) won't change their ways.
> 
> I don't believe this.
> 
> In cases where we've been able to show their devices to
> be faulty, they've fixed their kit.  Go check out what
> happened wrt. the ECN issues their firewall products had.

Yes, but you failed to explain their fault in this discussed issue so far. 
Still there is no good explanation for what can be broken if setting the source
ip of an arp request with the interface ip instead of the originating ip (iff
localhost).
According to your own words:
1) the destination host must not care
2) the source ip is no more visible if the request succeeds and a corresponding
entry in the table is made. So originating host has no chance to find out what
it was later on.

Who else should care? 

This discussion could btw have ended months ago (it is coming up now and then)
if a _simple_ way was implemented (like proc-setting) to switch between the two
possibilities.
I always thought we are doing a consensus project here. 
I guess it would be utmost simple to create a patch that implements something
like:

echo > /proc/sys/net/ethX/idontknowwhat 0   (current default behaviour)
echo > /proc/sys/net/ethX/idontknowwhat 1   (source ip of arp request following
the interface)
echo > /proc/sys/net/ethX/idontknowwhat 2   (don't answer arps on this
interface)

It's _simple_ for the user and contains every piece we talked about so far.
Shoot me for not being member of any religion.

Regards,
Stephan

RE: [2.4 PATCH] bugfix: ARP respond on all devices

[Richard Underwood]

Alan Cox wrote:
> 
> One thing I agree with you about is that an ARP resolution for an
> address via one path should not block a resolution for it by another
> path since to begin with the two paths may be to different routers
> one of which is down.

Alan,

	I can't believe that you're advocating networking code where:

1) It's not predictable - the route of a packet depends on the ARP reply
generated due to a previous packet.

2) Linux will fail to communicate with the vast majority of routers under
some, fairly basic, conditions.

	I'm certain that Cisco (for example) won't change their ways. I
can't blame them, either - no one else does it this way and there's no good
reason for doing it like this either.

	I think I'm going to give up at this point because I know I'm not
going to get anywhere. A simple static ARP entry will fix my problems,
although I'd prefer a more generic solution.

	Good luck!

		Richard

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 23:12:38 +0100
Richard Underwood <richard@aspectgroup.co.uk> wrote:

> 	I'm certain that Cisco (for example) won't change their ways.

I don't believe this.

In cases where we've been able to show their devices to
be faulty, they've fixed their kit.  Go check out what
happened wrt. the ECN issues their firewall products had.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On 19 Aug 2003 20:08:20 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > 	But if I was to do this in the other direction (arp -d 172.20.240.1;
> > ping -I 172.24.0.1 172.20.240.1) then I'd lose connectivity over my default
> > route because 172.20.240.1 won't accept ARP packets from IP numbers not on
> > the connected subnet. The <incomplete> ARP entry will block any further ARP
> > requests from valid IP numbers.
> 
> One thing I agree with you about is that an ARP resolution for an
> address via one path should not block a resolution for it by another
> path since to begin with the two paths may be to different routers
> one of which is down.

Sounds logical.

Can you explain to me why there should be a difference in the source ip of an
arp request originated by an ip packet from another address of the same host
compared to a forwarded packet from another host, coming in on some secondary
interface?
If I understood David correctly the first case will do an arp request with
source ip equal to source ip of the packet (originated locally).
In the second case (the box has to forward some foreign packet) for sure its
interface address will be used, correct? Or does that read: _some_ interface
address will be used?
Why this difference? The destination host cannot distinguish between these two
cases, so they can be as well handled just the same. But it seems obvious that
a foreign IP cannot be used as a source for an arp request.
And overall, looking at an arp table, what is visible is: interface, MAC and
corresponding IP. So as soon as an arp request is successfully completed the
box doesn't even remember the source ip of the former arp request, right?

Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Harley Stenzel]

David S. Miller wrote:
> 
> And, as Alan said, we provide a way for one to obtain your networking
> religion of week.

To the best of my knowledge, there is presently no way to change the arp 
behavior of Linux such that it uses the interface-based arp mechanizm in 
  a manner compatable with load-balancing and hot-standby techniques 
involving aliasing the loopback interface.  In all the proposed 
solutions the cache-update by an arp request problem still exists (arp 
source ip problem).

I would love to be proven wrong.  Presently I have to either patch the 
kernel or suffer the throughput penalty of doing dnat to myself, all to 
do something that Solaris, AIX, HP-UX, *BSD, and even Windows can do 
natively.

--Harley

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Valdis.Kletnieks]

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

On Tue, 19 Aug 2003 12:37:11 PDT, "David S. Miller" said:

> Please set the preferred source for eth1 to $(IP_OF_ETH1)
> and the preferred source for eth3 to $(IP_OF_ETH3) then
> do this:
> 
> bash# echo "1" >/proc/sys/net/ipv4/conf/eth1/arp_filter
> bash# echo "1" >/proc/sys/net/ipv4/conf/eth3/arp_filter
> 
> This also will make applications connecting using unspecified
> source addresses behave more sanely as well.

If I'm reading the code right, this will cause the interface to only deal with
ARP that have that interface's IP configured, whatever it happens to be at this
instant, so will DTRT for my configuration even when I'm doing DHCP or other
similar...

> The thing you claim is the right thing to do is the wrong thing
> to do in environments other than your own.

I never said it was the Right Thing for all environments, only that
the default is sub-optimal for some (probably common) setups...

I'm off to test - if that's all that's needed, I'm outta this thread. ;)




[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Andi Kleen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>
> One thing I agree with you about is that an ARP resolution for an
> address via one path should not block a resolution for it by another
> path since to begin with the two paths may be to different routers
> one of which is down.

ARP resolution is per device. You can have multiple neighbours per
route, either using a multipath route (ip route add ... nexthop 1 nexthop ...)
or using default routing failover for the default route. When there
is an existing neighbour entry (valid or invalid) on a device there
cannot be another one, but there could be one on another device.
The routing code could transparently fail over to other devices using
suitable routes.

One long standing problem however in that code is that there is no 
feedback from ARP to the multipath routing code to trigger failover. 
The only way  currently to get a failover in the multipath route is to run
a daemon with a keepalive protocol (like gated/zebra with OSPF) that does 
ifconfig down for bad interfaces, triggering the route failover.
The kernel already has such a keepalive protocol in the form
of ARP, just it doesn't use the information for routing.

For multiple default routes it should work already transparently
in the kernel, just not for normal multipath routes.

I suspect if someone fixed this (implementing feedback from the
neighbour state engine to the rt cache/FIB code for failover) cleanly
the network maintainers would consider it favourably.

-Andi

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[bill davidsen]

In article <20030819100712.2470d18d.davem@redhat.com>,
David S. Miller <davem@redhat.com> wrote:
| On Tue, 19 Aug 2003 19:10:10 +0200
| Stephan von Krawczynski <skraw@ithnet.com> wrote:
| 
| > Well, then you have a problem, at least with RFC-985 as quoted in my other
| > email.
| 
| RFC-985 does not take into consideration a system model where IP
| addresses are owned by the host not specific interfaces which is a
| valid system model that the RFC standards allow.

No one who has read the RFC would argue that the current implementation
is wrong, what people are saying is that in many common case it just
doesn't bloody *work*!

To say that the solution for common cases is to set a bunch of flags and
run source routing is not going to make the endless discussion,
complaints, and really bad patches go away. Why are you opposed to
having a tunable to allow *easy* selection of the functionality which is
needed by many people, particularly when you have stated that such
behaviour also conforms to RFCs?
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 22:00:09 +0200
Andi Kleen <ak@muc.de> wrote:

> I suspect if someone fixed this (implementing feedback from the
> neighbour state engine to the rt cache/FIB code for failover) cleanly
> the network maintainers would consider it favourably.

Indeed, I'd be thrilled to see such patches.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[bill davidsen]

In article <20030819112912.359eaea6.davem@redhat.com>,
David S. Miller <davem@redhat.com> wrote:
| On 19 Aug 2003 14:30:26 -0400
| Daniel Gryniewicz <dang@fprintf.net> wrote:
| 
| > If you are not on a shared lan, then it will *ONLY* work if linux is
| > on the other end.  No other system will work.
| 
| And these other systems are broken.  (actually, older Cisco equipment
| correctly responds to the ARP regardless of source IP)
| 
| Just because some Cisco engineer says that it is correct doesn't
| make it is.

What you say is true, but in the real world being able to work with the
most commonly used network hardware is a hard requirement. When
"conforms to RFC" colides with "works" there's an issue, particularly
when the RFC allows several behaviours (bad RFC!).

I would hope that it is possible to get a single flag to force all
packets out of a NIC configured with the source IP in the packet, I
don't feel the need to make that the default behaviour, just to find
some alternative to patches or source routing.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Valdis.Kletnieks]

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

On Tue, 19 Aug 2003 15:17:00 EDT, Daniel Gryniewicz said:

> So, changing your default route is a "hack"?  That's all that's
> necessary.  You can even do it with "route del/route add".

(trimming down a bit)

% ip link show
3: eth3: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:06:5b:ea:8e:4e brd ff:ff:ff:ff:ff:ff
6: eth1: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:02:2d:5c:11:48 brd ff:ff:ff:ff:ff:ff
% ip route sho
198.82.168.0/24 dev eth1  proto kernel  scope link  src 198.82.168.169 
128.173.12.0/22 dev eth3  proto kernel  scope link  src 128.173.14.107 
127.0.0.0/8 dev lo  scope link 
default via 128.173.12.1 dev eth3 

eth1 is an 11mbit wireless on a fairly loaded net, eth3 is a 100mbit line.

If I try 'ip ro add default dev eth1 metric 1 via 198.82.168.1', things
actually work As Expected - if I'm in the docking station, traffic goes via
eth3 because it's lower cost, if I'm wandering it goes via wireless.

Until I fall out of the 128.173.12.1 ARP cache, it ARPS for my eth3 address,
and my laptop gratuitously answers via eth1 - and since that isn't even the
same router, it doesn't listen.  Meanwhile, my laptop *doesnt* fall over to
using wireless because it still has a lower-cost default route for the 100mbit
side (and even if it did, any existing connections would still be hosed).

I can't believe I need to go beat my kernel over the head with 'arpfilter' or
other crap just to get 2 interfaces to each reliably say "here I am" on their
own damned subnet, not the OTHER subnet where nobody gives a rat's posterior
about the other interface....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 15:38:51 -0400
Valdis.Kletnieks@vt.edu wrote:

> % ip route sho
> 198.82.168.0/24 dev eth1  proto kernel  scope link  src 198.82.168.169 
> 128.173.12.0/22 dev eth3  proto kernel  scope link  src 128.173.14.107 
> 127.0.0.0/8 dev lo  scope link 
> default via 128.173.12.1 dev eth3 

Please set the preferred source for eth1 to $(IP_OF_ETH1)
and the preferred source for eth3 to $(IP_OF_ETH3) then
do this:

bash# echo "1" >/proc/sys/net/ipv4/conf/eth1/arp_filter
bash# echo "1" >/proc/sys/net/ipv4/conf/eth3/arp_filter

This also will make applications connecting using unspecified
source addresses behave more sanely as well.

The thing you claim is the right thing to do is the wrong thing
to do in environments other than your own.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Andi Kleen]

On Tue, Aug 19, 2003 at 03:27:48PM -0400, Daniel Gryniewicz wrote:
> On Tue, 2003-08-19 at 15:21, Andi Kleen wrote:
> > On Tue, Aug 19, 2003 at 03:17:00PM -0400, Daniel Gryniewicz wrote:
> > > On Tue, 2003-08-19 at 14:48, Andi Kleen wrote:
> > > > In my experience everybody who wants a different behaviour use some
> > > > more or less broken stateful L2/L3 switching hacks (like ipvs) or
> > > > having broken routing tables. While such hacks may be valid for some
> > > > uses they should not impact the default case.
> > > 
> > > So, changing your default route is a "hack"?  That's all that's
> > > necessary.  You can even do it with "route del/route add".
> > 
> > Necessary to do what exactly? 
> 
> Cause Linux to issue an arp request with a tell address not on the
> interface sending the arp.

I was merely talking about _answering_ ARP requests on all interfaces.

What happens on outgoing active ARPs is a different thing. Reasonable
choices would be either the prefered source address of the route or
the local interface's address. I must admit I don't have a strong
opinion on what the better behaviour of those is, but neither of them would
seem particularly wrong to me.

-Andi

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On 19 Aug 2003 21:32:35 +0200
Andi Kleen <ak@colin2.muc.de> wrote:

> What happens on outgoing active ARPs is a different thing. Reasonable
> choices would be either the prefered source address of the route or
> the local interface's address. I must admit I don't have a strong
> opinion on what the better behaviour of those is, but neither of them would
> seem particularly wrong to me.

Andi, we take the source address from the packet we are
trying to send out that interface.

Just as it is going to be legal to send out a packet from
that interface using that source address, it is legal to
send out an ARP request from that interface using that source
address.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Daniel Gryniewicz]

On Tue, 2003-08-19 at 15:21, Andi Kleen wrote:
> On Tue, Aug 19, 2003 at 03:17:00PM -0400, Daniel Gryniewicz wrote:
> > On Tue, 2003-08-19 at 14:48, Andi Kleen wrote:
> > > In my experience everybody who wants a different behaviour use some
> > > more or less broken stateful L2/L3 switching hacks (like ipvs) or
> > > having broken routing tables. While such hacks may be valid for some
> > > uses they should not impact the default case.
> > 
> > So, changing your default route is a "hack"?  That's all that's
> > necessary.  You can even do it with "route del/route add".
> 
> Necessary to do what exactly? 

Cause Linux to issue an arp request with a tell address not on the
interface sending the arp.
-- 
Daniel Gryniewicz <dang@fprintf.net>

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On 19 Aug 2003 15:27:48 -0400
Daniel Gryniewicz <dang@fprintf.net> wrote:

> On Tue, 2003-08-19 at 15:21, Andi Kleen wrote:
> > On Tue, Aug 19, 2003 at 03:17:00PM -0400, Daniel Gryniewicz wrote:
> > > On Tue, 2003-08-19 at 14:48, Andi Kleen wrote:
> > > > In my experience everybody who wants a different behaviour use some
> > > > more or less broken stateful L2/L3 switching hacks (like ipvs) or
> > > > having broken routing tables. While such hacks may be valid for some
> > > > uses they should not impact the default case.
> > > 
> > > So, changing your default route is a "hack"?  That's all that's
> > > necessary.  You can even do it with "route del/route add".
> > 
> > Necessary to do what exactly? 
> 
> Cause Linux to issue an arp request with a tell address not on the
> interface sending the arp.

Nobody has shown this to be invalid.  In fact, it has been shown
clearly that systems not responding to such ARP requests are buggy.

The only thing a system implementor can claim this accomplishes
is "pseudo security", and it barely even provides that.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Andi Kleen]

On Tue, Aug 19, 2003 at 03:17:00PM -0400, Daniel Gryniewicz wrote:
> On Tue, 2003-08-19 at 14:48, Andi Kleen wrote:
> > In my experience everybody who wants a different behaviour use some
> > more or less broken stateful L2/L3 switching hacks (like ipvs) or
> > having broken routing tables. While such hacks may be valid for some
> > uses they should not impact the default case.
> 
> So, changing your default route is a "hack"?  That's all that's
> necessary.  You can even do it with "route del/route add".

Necessary to do what exactly? 

-Andi

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bas Bloemsaat]

> Indeed, would people stop quoting from RFC 985 and
> RFC 826.

RFC 826 is referenced from 1009 as describing ARP. So in effect it does
define a standard.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Daniel Gryniewicz]

On Tue, 2003-08-19 at 14:48, Andi Kleen wrote:
> In my experience everybody who wants a different behaviour use some
> more or less broken stateful L2/L3 switching hacks (like ipvs) or
> having broken routing tables. While such hacks may be valid for some
> uses they should not impact the default case.

So, changing your default route is a "hack"?  That's all that's
necessary.  You can even do it with "route del/route add".
-- 
Daniel Gryniewicz <dang@fprintf.net>

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 21:19:44 +0200
"Bas Bloemsaat" <bloemsaa@xs4all.nl> wrote:

> > Indeed, would people stop quoting from RFC 985 and
> > RFC 826.
> 
> RFC 826 is referenced from 1009 as describing ARP. So in effect it does
> define a standard.

The RFC 826 document clearly says, at the top, "This is not
an Internet Standard"

It does not define a standard.  And given that it really isn't
surprising it has errors in it as we've clearly shown in these
threads.  The authors of said document didn't scuritinize it
to the level it would need to be in order to truly be a standards
document people must follow to have a conformant implementation.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Daniel Gryniewicz]

I realize that, but is that a reason to keep linux from working with
these?  (And it's not just cisco, all the *BSDs (and therefore anything
that took the BSD stack such as MS) work this way too.)  As nearly as I
can tell, there's no way to make linux work with these, and the
situation I gave is one where linux could easily get it right, and
isn't.  Saying "They're broken.  Tough." is not really helpful.  At
least can we get a "work with broken other systems in certain
circumstances" switch somewhere?

(Funny you should mention Cisco, as we write routing software and must
interoperate with Cisco.  What Cisco says *does* go in the routing
community, if you wish your product to be used.  Currently, when our
customers come to us, we have to say "Either don't use Linux or run 2.2
with the arp fix patch.")

Daniel

On Tue, 2003-08-19 at 14:29, David S. Miller wrote:
> On 19 Aug 2003 14:30:26 -0400
> Daniel Gryniewicz <dang@fprintf.net> wrote:
> 
> > If you are not on a shared lan, then it will *ONLY* work if linux is
> > on the other end.  No other system will work.
> 
> And these other systems are broken.  (actually, older Cisco equipment
> correctly responds to the ARP regardless of source IP)
> 
> Just because some Cisco engineer says that it is correct doesn't
> make it is.
> 
> Consider the situation logically.  When you're replying to an
> ARP, _HOW_ do you know what IP addresses are assigned to _MY_
> outgoing interfaces and _HOW_ do you know what subnets _EXIST_
> on the LAN?
> 
> The answer to both is, you'd don't know these things _EVEN_ if
> you are a router/gateway.
> 
> Therefore there is no valid reason not to respond to an ARP using one
> source address as opposed to another.
-- 
Daniel Gryniewicz <dang@fprintf.net>

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On 19 Aug 2003 15:12:43 -0400
Daniel Gryniewicz <dang@fprintf.net> wrote:

> (And it's not just cisco, all the *BSDs (and therefore anything
> that took the BSD stack such as MS) work this way too.)

Not true.  Microsoft systems do respond properly to these ARPs.

RE: [2.4 PATCH] bugfix: ARP respond on all devices

[Alan Cox]

On Maw, 2003-08-19 at 15:34, Richard Underwood wrote:
> # arp -d 172.24.0.80
> # ping -I 172.20.240.2 172.24.0.80
> 
> 	I see:
> 
> 16:18:40.856328 arp who-has 172.24.0.80 tell 172.20.240.2
> 16:18:40.856431 arp reply 172.24.0.80 is-at 0:50:da:44:f:37

Fine

> 	But if I was to do this in the other direction (arp -d 172.20.240.1;
> ping -I 172.24.0.1 172.20.240.1) then I'd lose connectivity over my default
> route because 172.20.240.1 won't accept ARP packets from IP numbers not on
> the connected subnet. The <incomplete> ARP entry will block any further ARP
> requests from valid IP numbers.

One thing I agree with you about is that an ARP resolution for an
address via one path should not block a resolution for it by another
path since to begin with the two paths may be to different routers
one of which is down.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Alan Cox]

On Maw, 2003-08-19 at 17:52, Stephan von Krawczynski wrote:
> <quote RFC-985>

Effectively Obsolete.

>       An ARP reply is discarded if the destination IP address does not
>       match the local host address.  An ARP request is discarded if the

The local host address. Singular. Back from the days where addresses
lived by box

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On 19 Aug 2003 20:04:25 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Maw, 2003-08-19 at 17:52, Stephan von Krawczynski wrote:
> > <quote RFC-985>
> 
> Effectively Obsolete.

Indeed, would people stop quoting from RFC 985 and
RFC 826.

RE: [2.4 PATCH] bugfix: ARP respond on all devices

[Richard Underwood]

David S. Miller wrote: 
> > 	IP packets you mean? You don't? ;) It would depend on why you're
> > doing it naturally. Mostly, I'd have thought that if a host 
> doesn't have an
> > IP number it doesn't get to use ARP.
> 
> Of course it gets to use ARP, nothing prevents this.
> 
> If I know that IP X has my configuration information, I
> have every right to send X a packet from zero-net to
> ask for that information before I have any IP addresses
> attached to the interface.
> 
	Ick! And how is IP X going to get the information back? Broadcast
it, too? Here was me thinking that protocols like BOOTP and DHCP were
appropriate for this.

	If you are going to send from 0.0.0.0, then I assume there's
something in the ARP standard to say "don't cache this ARP request" - I must
have missed it. If so, that's a special case - no need to spoil things
elsewhere, though.

> Also, when one specifies a specific device in an output
> address and we cannot find the IP part of the address
> in the routing tables, we still procure a valid route for
> the requester.
> 
	Well, what do you do currently? If the packet you're routeing came
from another host, there's no way in hell you can use their IP address in an
ARP request ... is there? I certainly hope you don't go that far!!!

	If it's a locally generated packet, then the next hop must be on the
same subnet as the address it's coming from - there's your IP number.

> Besides normal IP addresses, multicast tools use these
> facilities.
> 
	Multicast uses ARP? That's news to me!

		Richard

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 20:00:44 +0100
Richard Underwood <richard@aspectgroup.co.uk> wrote:

> David S. Miller wrote: 
> > If I know that IP X has my configuration information, I
> > have every right to send X a packet from zero-net to
> > ask for that information before I have any IP addresses
> > attached to the interface.
> > 
> 	Ick! And how is IP X going to get the information back?

It knows the MAC address of the intended receiver, there is
no problem here.

> 	If you are going to send from 0.0.0.0, then I assume there's
> something in the ARP standard to say "don't cache this ARP request" - I must
> have missed it. If so, that's a special case - no need to spoil things
> elsewhere, though.

What is the caching problem?  The ARP response is valid, and we
have no reason to believe otherwise.

> 	Well, what do you do currently? If the packet you're routeing came
> from another host, there's no way in hell you can use their IP address in an
> ARP request ... is there? I certainly hope you don't go that far!!!

We're not talking about routing scenerios, we're talking strictly
about packets being originated by an application on the local host.

> > Besides normal IP addresses, multicast tools use these
> > facilities.
> > 
> 	Multicast uses ARP? That's news to me!

It uses routes that only have been determined only using the desired
device index.  There is no "interface address" to match up to when
we're trying to send to a multicast address.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Andi Kleen]

Lars Marowsky-Bree <lmb@suse.de> writes:

> Yes, both are "correct" in the sense that the RFC allows this
> interpretation. The _sensible_ interpretation for practical networking
> however is #2, and the only persons who seem to believe differently are
> those in charge of the Linux network code...

Just spend a minute to think about multihoming and failover
between multiple links on a host.

For that the Linux default makes a lot of sense - you get automatic
transparent failover between interfaces without any effort.

In my experience everybody who wants a different behaviour use some
more or less broken stateful L2/L3 switching hacks (like ipvs) or
having broken routing tables. While such hacks may be valid for some
uses they should not impact the default case.

-Andi

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bas Bloemsaat]

> > > Ok, then how would you propose to be able to send
> > > packets out an interface _before_ we have addresses
> > > assigned to it?
> > >
> > IP packets you mean? You don't? ;) It would depend on why you're
> > doing it naturally. Mostly, I'd have thought that if a host doesn't have
an
> > IP number it doesn't get to use ARP.
>
> Of course it gets to use ARP, nothing prevents this.
Huh? RFC 826 states that the requesting arp packet sends the protocol
address of itself. So no address is no arp.

Allowing it to is a violation of that rfc

Regards,
Bas

RE: [2.4 PATCH] bugfix: ARP respond on all devices

[Daniel Gryniewicz]

On Tue, 2003-08-19 at 08:35, Alan Cox wrote:
> You increase it and you shortcut on shared lans. Thats really a seperate
> issue to the question of which source is used. If you loopback someone
> elses address on your own lo device I'm not suprised weird shit happens,
> put the alias on eth0 where it belongs.

Only if you are on a shared lan.  If you are not on a shared lan, then
it will *ONLY* work if linux is on the other end.  No other system will
work.  And, you don't need an alias on loopback.  Merely changing the
default route will result in this.  Change default route from gw 1.1.1.1
on eth0 to gw 2.2.2.2 on eth1 (making sure that 2.2.2.2 doesn't have an
arp entry), and linux will say, on eth1:
whohas 2.2.2.2 tell 1.1.1.2
where 1.1.1.2 is the address on eth0.  No one will respond to this, so
all communication from beyond a directly connected network will now
fail.

-- 
Daniel Gryniewicz <dang@fprintf.net>

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On 19 Aug 2003 14:30:26 -0400
Daniel Gryniewicz <dang@fprintf.net> wrote:

> If you are not on a shared lan, then it will *ONLY* work if linux is
> on the other end.  No other system will work.

And these other systems are broken.  (actually, older Cisco equipment
correctly responds to the ARP regardless of source IP)

Just because some Cisco engineer says that it is correct doesn't
make it is.

Consider the situation logically.  When you're replying to an
ARP, _HOW_ do you know what IP addresses are assigned to _MY_
outgoing interfaces and _HOW_ do you know what subnets _EXIST_
on the LAN?

The answer to both is, you'd don't know these things _EVEN_ if
you are a router/gateway.

Therefore there is no valid reason not to respond to an ARP using one
source address as opposed to another.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 19:05:13 +0100
Richard Underwood <richard@aspectgroup.co.uk> wrote:

> 	The ARP request represents all FUTURE
> packets being sent out that interface, not just the one single packet that
> happened to kick of this ARP request.

That's RIGHT!  And by your own argument the source address
in the ARP request IS IRRELEVANT and is to be ignored!

Ok, I've lost 3 days of talking about ARP non-stop, I think
I'll take a break from these threads for a while, it's getting
to be a bit much.

RE: [2.4 PATCH] bugfix: ARP respond on all devices

[Richard Underwood]

David S. Miller wrote:
> > 	Which nicely sums up the bug, really.
> 
> Ok, then how would you propose to be able to send
> packets out an interface _before_ we have addresses
> assigned to it?
> 
	IP packets you mean? You don't? ;) It would depend on why you're
doing it naturally. Mostly, I'd have thought that if a host doesn't have an
IP number it doesn't get to use ARP.

> Linux allows that, and in fact it's a useful feature.
> 
> Consider MSG_DONTROUTE as well.
> 
	Irrelevant, ARP should stick to resolving Layer 2 issues, not be
misused as some Layer 3 routeing protocol.

> BTW, this ARP source address algorithm we use comes from
> ipv6, it would be instructive to go and see why they do
> things the way they do.
> 
	If you'd like to give me a reference, I'd be happy to look at the
spec. It doesn't matter where you got the concept from, though - it's
flawed.

		Richard

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 19:16:18 +0100
Richard Underwood <richard@aspectgroup.co.uk> wrote:

> David S. Miller wrote:
> > Ok, then how would you propose to be able to send
> > packets out an interface _before_ we have addresses
> > assigned to it?
> > 
> 	IP packets you mean? You don't? ;) It would depend on why you're
> doing it naturally. Mostly, I'd have thought that if a host doesn't have an
> IP number it doesn't get to use ARP.

Of course it gets to use ARP, nothing prevents this.

If I know that IP X has my configuration information, I
have every right to send X a packet from zero-net to
ask for that information before I have any IP addresses
attached to the interface.

This is nothing wrong nor strange about this and we've
supported it for years.

Also, when one specifies a specific device in an output
address and we cannot find the IP part of the address
in the routing tables, we still procure a valid route for
the requester.

Besides normal IP addresses, multicast tools use these
facilities.

RE: [2.4 PATCH] bugfix: ARP respond on all devices

[Richard Underwood]

David S. Miller wrote:
> 
> In the ARP request we are using the source address in the packet we
> are building for output.
> 
	Well, you shouldn't be! The ARP request represents all FUTURE
packets being sent out that interface, not just the one single packet that
happened to kick of this ARP request.

> If ARP doesn't work using that source address, we can only assume IP
> communication is not possible either.
> 
	That's clearly not a valid assumption. For a start it precludes IP
routeing, but I've also demonstrated it not to be the case with a simple
multi-homed server.

	Thanks,

		Richard

RE: [2.4 PATCH] bugfix: ARP respond on all devices

[Richard Underwood]

David S. Miller wrote:
> > 	When a HOST sends out an ARP request, it's NOT associated with a
> > single connection, it's associated with the host. Why 
> should it pick a
> > "random" IP number to send as the source address?
> 
> It's not "random", it is using the IP address it intends
> to use as the source in packets it will output once the
> ARP completes.
> 
> In fact, if you look at the code in arp_solicit(), the source address
> is coming directly from the packet we are trying to output.
> 
	Which nicely sums up the bug, really.

1) The ARP response (or lack thereof) will be used for more than that
connection, using a single packet's source IP address is meaningless and
just a little aribtrary.

2) Depending on which ARP request or reply gets seen first, packets may get
routed over different interfaces or not sent out at all.

3) The code is over-complex. There must already be perfectly good code to
pick up the interface's IP address as this would HAVE to be the case when a
packet has been routed from another host.

	This sort of randomness is not acceptable in a reliable network.

		Richard

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 18:56:18 +0100
Richard Underwood <richard@aspectgroup.co.uk> wrote:

> 	Which nicely sums up the bug, really.

Ok, then how would you propose to be able to send
packets out an interface _before_ we have addresses
assigned to it?

Linux allows that, and in fact it's a useful feature.

Consider MSG_DONTROUTE as well.

BTW, this ARP source address algorithm we use comes from
ipv6, it would be instructive to go and see why they do
things the way they do.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Lars Marowsky-Bree]

On 2003-08-19T08:34:38,
   "David S. Miller" <davem@redhat.com> said:

> There are two valid ways the RFCs allow systems to handle
> IP addresses.
> 
> 1) IP addresses are owned by "the host"
> 2) IP addresses are owned by "the interface"
> 
> Linux does #1, many systems do #2, both are correct.

Yes, both are "correct" in the sense that the RFC allows this
interpretation. The _sensible_ interpretation for practical networking
however is #2, and the only persons who seem to believe differently are
those in charge of the Linux network code...


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering		ever tried. ever failed. no matter.
SuSE Labs				try again. fail again. fail better.
Research & Development, SuSE Linux AG		-- Samuel Beckett

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 19:39:20 +0200
Lars Marowsky-Bree <lmb@suse.de> wrote:

> On 2003-08-19T08:34:38,
>    "David S. Miller" <davem@redhat.com> said:
> 
> > There are two valid ways the RFCs allow systems to handle
> > IP addresses.
> > 
> > 1) IP addresses are owned by "the host"
> > 2) IP addresses are owned by "the interface"
> > 
> > Linux does #1, many systems do #2, both are correct.
> 
> Yes, both are "correct" in the sense that the RFC allows this
> interpretation. The _sensible_ interpretation for practical networking
> however is #2, and the only persons who seem to believe differently are
> those in charge of the Linux network code...

And, as Alan said, we provide a way for one to obtain your networking
religion of week.

Changing the default is not an option, that would undoubtedly
break things.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bill Davidsen]

On Tue, 19 Aug 2003, David S. Miller wrote:

> On Tue, 19 Aug 2003 11:53:29 -0400 (EDT)
> Bill Davidsen <davidsen@tmr.com> wrote:
> 
> > I wonder if a change to add a flag preventing *any* packet from being sent
> > on a NIC which doesn't have the proper source address would be politically
> > acceptable.
> 
> This would disable things like MSG_DONTROUTE and many valid
> uses of RAW sockets.
> 

Probably would, but since it's a flag people could use it or not. I did
that via a patch and it didn't show any problems in a tcp/udp environment.
I would assume that source routing would produce the same problem in some
cases, would it not? And I bet that using rp_filter can break some things
as well, so there is precedent for having capabilities which could impact
some valid procedures.

I appreciate your point (which I totally overlooked), but I don't see that
we have avoided other capabilities which could cause problems if
misconfigured. It is clearly the responsibility of the admin to do
configuration, and this seems (based on my actual experience) to work in
an environment where arp/tcp/udp are being used.

Unless you have additional issues, I would suggest that there are good
reasons to add this capability.
- no more dangerous than source routing and much easier to use
- saves much discussion and time
- much better to have one change done properly than lots of half-assed
  patches

I understand your objections to the hidden patch, I think the approach I
suggest could be done at the proper level and would provide a standard way
to solve a common problem. If this can be reasonably done I would think
you would support it just to be able to say "use default_source_routing"
when the hidden patch visits the next time ;-)

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Tue, 19 Aug 2003 09:54:54 -0700
"David S. Miller" <davem@redhat.com> wrote:

> Which is all irrelevant because the IPv4 RFCs say that host
> based and interface based address ownership are both valid
> system models.

Can you (for completeness) name (the number) or quote the RFC you are talking
about.

Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Tue, 19 Aug 2003 09:53:02 -0700
"David S. Miller" <davem@redhat.com> wrote:

> On Tue, 19 Aug 2003 18:52:19 +0200
> Stephan von Krawczynski <skraw@ithnet.com> wrote:
> 
> > On Tue, 19 Aug 2003 08:57:17 -0700
> > "David S. Miller" <davem@redhat.com> wrote:
> > 
> > > "Be liberal in what you accept, and conservative in what you send"
> > > -Jon Postel
> > 
> > If I understood what Richard said in this thread Jon just shot you
> > down. The conservative way to _request_ arp would definitely be to
> > request it from the "correct" subnet, because as a sender you ought
> > to give credit to knowing that "bad" boxes out there won't answer if
> > you do otherwise.
> 
> In the ARP request we are using the source address in the packet we
> are building for output.
> 
> If ARP doesn't work using that source address, we can only assume IP
> communication is not possible either.
> 
> It is the box not responding to this ARP which is preventing
> communication not the box creating the ARP request.

Please read my example from other email. Very simple to prove you wrong here.

Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Tue, 19 Aug 2003 09:51:05 -0700
"David S. Miller" <davem@redhat.com> wrote:

> On Tue, 19 Aug 2003 17:54:26 +0100
> Richard Underwood <richard@aspectgroup.co.uk> wrote:
> 
> > 	When a HOST sends out an ARP request, it's NOT associated with a
> > single connection, it's associated with the host. Why should it pick a
> > "random" IP number to send as the source address?
> 
> It's not "random", it is using the IP address it intends
> to use as the source in packets it will output once the
> ARP completes.
> 
> In fact, if you look at the code in arp_solicit(), the source address
> is coming directly from the packet we are trying to output.

Well, then you have a problem, at least with RFC-985 as quoted in my other
email.
If your host has two interfaces on two different pyhsical nets and host A from
net A shall be contacted by a service bound to your interface on net B you will
obviously send an arp request with a source ip from wrong subnet.
I did not read the code, I take your code explanation as true, of course.
It is very likely you will not receive a valid answer in this case:

<quote RFC-985>
An ARP request is discarded if the source IP address is not in the same subnet.
</quote>

Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 19:12:46 +0200
Stephan von Krawczynski <skraw@ithnet.com> wrote:

> On Tue, 19 Aug 2003 09:53:02 -0700
> "David S. Miller" <davem@redhat.com> wrote:
> 
> > In the ARP request we are using the source address in the packet we
> > are building for output.
> > 
> > If ARP doesn't work using that source address, we can only assume IP
> > communication is not possible either.
> > 
> > It is the box not responding to this ARP which is preventing
> > communication not the box creating the ARP request.
> 
> Please read my example from other email. Very simple to prove you wrong here.

Not really, the RFC you keep quoting is broken in several
regards:

1) It is non-functional in environments containing systems
   using the host ownership model for IP addresses which the
   RFC standards fully allow.

2) It does not consider the cases where a host is not completely
   aware of all subnets present on a given link.  This is actually
   quite common.

   Dropping such ARP requests can only be done when the
   the host is aware of all subnets that exist, which is cannot
   be possibly true.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 19:10:10 +0200
Stephan von Krawczynski <skraw@ithnet.com> wrote:

> Well, then you have a problem, at least with RFC-985 as quoted in my other
> email.

RFC-985 does not take into consideration a system model where IP
addresses are owned by the host not specific interfaces which is a
valid system model that the RFC standards allow.

> <quote RFC-985>
> An ARP request is discarded if the source IP address is not in the same subnet.
> </quote>

This RFC is broken in an environment consistent of systems using
the host address ownership model.

It also doesn't consider cases where the host receiving the
ARP request is not aware of all subnets present on a LAN.

Ignoring such ARPs is therefore broken and prevents valid
communications from occuring.

Some systems implement this check to provide "pseudo security",
but it isn't even that.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 13:02:20 +0100
Richard Underwood <richard@aspectgroup.co.uk> wrote:

> David S. Miller wrote:
> > Under Linux, by default, IP addresses are owned by the system
> > not by interfaces.  This increases the likelyhood of successful
> > communication on a subnet.
> > 
> 	This is crap.

Nope, the RFCs allow this.

So this is where we must agree to disagree.  Because host ownership of
IP addresses is the basis for all of the arguments and it completely
justifies Linux's ARP behavior on both sides.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 15:11:59 +0200
"Bas Bloemsaat" <bloemsaa@xs4all.nl> wrote:

> > The RFC I quoted (985) says the ARP packets generated by Linux
> > should be dropped. Sure, the RFC isn't a standard, but there ARE plenty of
> > implementations that obey it for perfectly valid security reasons.
>
> Same goes for 1180. It it doesn't define a standard either, but makes
> perfectly clear that any interface has it's own ARP, not one ARP for the
> entire system.

Which is all irrelevant because the IPv4 RFCs say that host
based and interface based address ownership are both valid
system models.

Any document saying that they must be per-interface is therefore
invalid.

RE: [2.4 PATCH] bugfix: ARP respond on all devices

[Richard Underwood]

David S. Miller wrote:
> 
> It means that systems (like Linux) that make IP addresses owned by the
> host instead of specific interfaces cannot correctly interoperate with
> such remote systems.
> 
	This makes sense for replies, but not for requests.

	When a HOST sends out an ARP request, it's NOT associated with a
single connection, it's associated with the host. Why should it pick a
"random" IP number to send as the source address?

	The way the network code is currently, you're reducing your
connectivity to chance. There should be a defined process for making a
connection to another host. As it stands, this process is simply not
predictable.

	If you insist that an ARP request IS directly associated with a
connection, then you are required to have one ARP cache per source IP
address. It'd be predictable again ... but I don't think anyone wants to go
there.

> It is also the case that a host cannot possibly be aware of all
> subnets present on a given LAN, therefore is should be liberal in it's
> replies to ARP requests.
> 
	Well, actually, I know exactly which IP subnets are on which LAN
segments - they're defined by the IP address and subnet of the interface. I
think you'll find that this a pretty basic feature of most hosts.

> Finally, it violates the most basic rule of IP networking:
> 
> "Be liberal in what you accept, and conservative in what you send"
> -Jon Postel
> 
	I'm sorry, but Linux simply isn't being conservative in what it
sends. It's being bloody awkward.

	Look at it this way - when a host sends out an ARP request, it WANTS
a reply, it's not doing it for fun. If it uses the IP number of the
interface it's sending the ARP request on, it will ALWAYS get a reply
(assuming there's one to get.) If it uses the IP number of another
interface, it MAY get a reply, but it MAY NOT.

	Are there any cases when this is reversed? I don't think so! Linux
is being intentionally difficult, and as far as I can tell, for no good
reason.

> In general, when a host posses the information necessary to allow
> other hosts to communicate, it should provide that information
> whenever possible.
> 
	No, it should follow the rules for letting traffic pass through it.
Just because a host can see two networks, doesn't mean it should route
between them - it possesses information, but there have to be rules to
determine how this information is used.

	Compare it to IP: If a firewall sees a packet come in on an
interface it shouldn't, it'll probably drop it - it's called anti-spoofing.
Should the firewall forward the packet on just because it can?

	So at the lower layer, a router sees an ARP packet with what looks
like a "spoofed" source address. Should it trust it implicitly and place it
in its cache, or should it drop it?

	No one yet has given one single example of a network that relies on
Linux's current behaviour. I've given two examples of networks that break
because of it. I would kindly suggest that the default should be changed.

	Thanks,

		Richard

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 18:52:19 +0200
Stephan von Krawczynski <skraw@ithnet.com> wrote:

> On Tue, 19 Aug 2003 08:57:17 -0700
> "David S. Miller" <davem@redhat.com> wrote:
> 
> > "Be liberal in what you accept, and conservative in what you send"
> > -Jon Postel
> 
> If I understood what Richard said in this thread Jon just shot you
> down. The conservative way to _request_ arp would definitely be to
> request it from the "correct" subnet, because as a sender you ought
> to give credit to knowing that "bad" boxes out there won't answer if
> you do otherwise.

In the ARP request we are using the source address in the packet we
are building for output.

If ARP doesn't work using that source address, we can only assume IP
communication is not possible either.

It is the box not responding to this ARP which is preventing
communication not the box creating the ARP request.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Tue, 19 Aug 2003 08:57:17 -0700
"David S. Miller" <davem@redhat.com> wrote:

> On Tue, 19 Aug 2003 17:07:51 +0200
> Stephan von Krawczynski <skraw@ithnet.com> wrote:
> 
> > Hm, what rule is broken by the remote host, then?
> 
> It means that systems (like Linux) that make IP addresses owned by the
> host instead of specific interfaces cannot correctly interoperate with
> such remote systems.
> 
> It is also the case that a host cannot possibly be aware of all
> subnets present on a given LAN, therefore is should be liberal in it's
> replies to ARP requests.
> 
> Finally, it violates the most basic rule of IP networking:
> 
> "Be liberal in what you accept, and conservative in what you send"
> -Jon Postel

If I understood what Richard said in this thread Jon just shot you down. The
conservative way to _request_ arp would definitely be to request it from the
"correct" subnet, because as a sender you ought to give credit to knowing that
"bad" boxes out there won't answer if you do otherwise. There can be no doubt
what "conservative" means here.
Additionally, the remote box is not really bad behaving:

<quote RFC-985>
   A.3.  ARP datagram

      An ARP reply is discarded if the destination IP address does not
      match the local host address.  An ARP request is discarded if the
      source IP address is not in the same subnet.  It is desirable that
      this test be overridden by a configuration parameter, in order to
      support the infrequent cases where more than one subnet may
      coexist on the same cable (see RFC-925 for examples).

</quote>

This means the remote box is completely ok if not answering to a request with
source ip from another subnet.
So from what I read here requesting arp should really only happen with a source
ip from the same subnet.

Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 17:54:26 +0100
Richard Underwood <richard@aspectgroup.co.uk> wrote:

> 	When a HOST sends out an ARP request, it's NOT associated with a
> single connection, it's associated with the host. Why should it pick a
> "random" IP number to send as the source address?

It's not "random", it is using the IP address it intends
to use as the source in packets it will output once the
ARP completes.

In fact, if you look at the code in arp_solicit(), the source address
is coming directly from the packet we are trying to output.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Tue, 19 Aug 2003 15:11:59 +0200
"Bas Bloemsaat" <bloemsaa@xs4all.nl> wrote:

> > The RFC I quoted (985) says the ARP packets generated by Linux
> > should be dropped. Sure, the RFC isn't a standard, but there ARE plenty of
> > implementations that obey it for perfectly valid security reasons.
> Same goes for 1180. It it doesn't define a standard either, but makes
> perfectly clear that any interface has it's own ARP, not one ARP for the
> entire system.

Does "has its own ARP" mean "has its own ARP-table"?
I just want to understand you correctly.

Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 11:53:29 -0400 (EDT)
Bill Davidsen <davidsen@tmr.com> wrote:

> I wonder if a change to add a flag preventing *any* packet from being sent
> on a NIC which doesn't have the proper source address would be politically
> acceptable.

This would disable things like MSG_DONTROUTE and many valid
uses of RAW sockets.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 17:07:51 +0200
Stephan von Krawczynski <skraw@ithnet.com> wrote:

> Hm, what rule is broken by the remote host, then?

It means that systems (like Linux) that make IP addresses owned by the
host instead of specific interfaces cannot correctly interoperate with
such remote systems.

It is also the case that a host cannot possibly be aware of all
subnets present on a given LAN, therefore is should be liberal in it's
replies to ARP requests.

Finally, it violates the most basic rule of IP networking:

"Be liberal in what you accept, and conservative in what you send"
-Jon Postel

In general, when a host posses the information necessary to allow
other hosts to communicate, it should provide that information
whenever possible.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bill Davidsen]

On Tue, 19 Aug 2003, Willy Tarreau wrote:

> Hello,
> 
> On Tue, Aug 19, 2003 at 03:34:43PM +0100, Richard Underwood wrote:

> > 	Now, since 172.24.0.80 is a Linux box, it's happily adding
> > 172.20.240.2 into its ARP table and reply to it, hence the reply.
> > 
> > 	But if I was to do this in the other direction (arp -d 172.20.240.1;
> > ping -I 172.24.0.1 172.20.240.1) then I'd lose connectivity over my default
> > route because 172.20.240.1 won't accept ARP packets from IP numbers not on
> > the connected subnet. The <incomplete> ARP entry will block any further ARP
> > requests from valid IP numbers.
> 
> This is exactly the case I calmly discussed privately with David then Alexey.
> Both explained me that in fact, the remote host shouldn't be filtering the ARP
> requests based on the source IP they provide, but agreed that it seems to be a
> general trend today. Alexey proposed a slight change which can at least solve
> this very common case by preventing the system from using the local address as
> a source IP if it is not on the interface through which the request is sent.
> 
> Obviously it will not solve all very special cases, which people can work
> around with arptables, but it will solve this common one.

I wonder if a change to add a flag preventing *any* packet from being sent
on a NIC which doesn't have the proper source address would be politically
acceptable. I did that type of patch for 2.4.16 to prevent killing
routers by having the MAC change for an IP. It will hurt performance on at
least some routers, and the patch eliminated the problem.

I later changed to using source routing, since the number of IPs was
modest and didn't change, but I am still fighting the issue in a test
environment, where the number of IPs is high and I can't just grab a range
in some cases.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[David S. Miller]

On Tue, 19 Aug 2003 15:11:59 +0200
"Bas Bloemsaat" <bloemsaa@xs4all.nl> wrote:

> It it doesn't define a standard either, but makes
> perfectly clear that any interface has it's own ARP,
> not one ARP for the entire system.

This is absolutely not true.

There are two valid ways the RFCs allow systems to handle
IP addresses.

1) IP addresses are owned by "the host"
2) IP addresses are owned by "the interface"

Linux does #1, many systems do #2, both are correct.

We provide ways for you to obtain the behavior or #2
so there is nothing to complain about.

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Stephan von Krawczynski]

On Tue, 19 Aug 2003 16:54:03 +0200
Willy Tarreau <willy@w.ods.org> wrote:

> This is exactly the case I calmly discussed privately with David then Alexey.
> Both explained me that in fact, the remote host shouldn't be filtering the
> ARP requests based on the source IP they provide,

Hm, what rule is broken by the remote host, then? I mean "remote host shouln't"
reads like "according to RFC-XYZ he should not".
IFF of course the remote host is not broken, then our idea must be broken. Else
world would have kind of a definition gap in this layer of networking, and I
hardly believe that.

Regards,
Stephan

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Willy Tarreau]

Hello,

On Tue, Aug 19, 2003 at 03:34:43PM +0100, Richard Underwood wrote:
> 	As an example, I have a router/firewall for the office that has two
> interface cards, both with perfectly valid internal addresses - these
> addresses aren't used anywhere else on the network.
> 
> 	Two of the interfaces are: 172.20.240.2/24 and 172.24.0.1/16. My
> default gateway is 172.20.240.1 and there aren't any other non-interface
> routes. If I do:
> 
> # arp -d 172.24.0.80
> # ping -I 172.20.240.2 172.24.0.80
> 
> 	I see:
> 
> 16:18:40.856328 arp who-has 172.24.0.80 tell 172.20.240.2
> 16:18:40.856431 arp reply 172.24.0.80 is-at 0:50:da:44:f:37
> 
> 	Now, since 172.24.0.80 is a Linux box, it's happily adding
> 172.20.240.2 into its ARP table and reply to it, hence the reply.
> 
> 	But if I was to do this in the other direction (arp -d 172.20.240.1;
> ping -I 172.24.0.1 172.20.240.1) then I'd lose connectivity over my default
> route because 172.20.240.1 won't accept ARP packets from IP numbers not on
> the connected subnet. The <incomplete> ARP entry will block any further ARP
> requests from valid IP numbers.

This is exactly the case I calmly discussed privately with David then Alexey.
Both explained me that in fact, the remote host shouldn't be filtering the ARP
requests based on the source IP they provide, but agreed that it seems to be a
general trend today. Alexey proposed a slight change which can at least solve
this very common case by preventing the system from using the local address as
a source IP if it is not on the interface through which the request is sent.

Obviously it will not solve all very special cases, which people can work
around with arptables, but it will solve this common one.

Cheers,
Willy

RE: [2.4 PATCH] bugfix: ARP respond on all devices

[Richard Underwood]

Alan Cox wrote:
> 
> You increase it and you shortcut on shared lans. Thats really a seperate
> issue to the question of which source is used. If you loopback someone
> elses address on your own lo device I'm not suprised weird 
> shit happens, put the alias on eth0 where it belongs.
> 
	Woah! I'm not talking about JUST load-balanced networks. This is a
far more generic problem.

	As an example, I have a router/firewall for the office that has two
interface cards, both with perfectly valid internal addresses - these
addresses aren't used anywhere else on the network.

	Two of the interfaces are: 172.20.240.2/24 and 172.24.0.1/16. My
default gateway is 172.20.240.1 and there aren't any other non-interface
routes. If I do:

# arp -d 172.24.0.80
# ping -I 172.20.240.2 172.24.0.80

	I see:

16:18:40.856328 arp who-has 172.24.0.80 tell 172.20.240.2
16:18:40.856431 arp reply 172.24.0.80 is-at 0:50:da:44:f:37

	Now, since 172.24.0.80 is a Linux box, it's happily adding
172.20.240.2 into its ARP table and reply to it, hence the reply.

	But if I was to do this in the other direction (arp -d 172.20.240.1;
ping -I 172.24.0.1 172.20.240.1) then I'd lose connectivity over my default
route because 172.20.240.1 won't accept ARP packets from IP numbers not on
the connected subnet. The <incomplete> ARP entry will block any further ARP
requests from valid IP numbers.

	This, in my opinion, isn't on. There must be thousands of Linux
installations out there that (1) have more than one interfaces and (2) are
connected to routers or firewalls that drop ARP requests in the same way. 

	Actually, it's not that bad in this case as the next hop will
probably send an ARP request at some point which will override it - but
that's really not the point.

	If the routeing was asymetric, or the next hop had a static ARP
entry for me, all communication would quite simply be lost. It'd just take
the first packet after an ARP entry times out to be from the wrong IP
address, and the host would be off the net.

	I personally don't think "shared LANs" should be favoured over best
practice. Even in the case of shared LANs, nothing "breaks" as David Miller
suggests would happen if the ARPs were fixed.

	Thanks,

		Richard

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Bas Bloemsaat]

> The RFC I quoted (985) says the ARP packets generated by Linux
> should be dropped. Sure, the RFC isn't a standard, but there ARE plenty of
> implementations that obey it for perfectly valid security reasons.
Same goes for 1180. It it doesn't define a standard either, but makes
perfectly clear that any interface has it's own ARP, not one ARP for the
entire system.

Regards,
Bas

RE: [2.4 PATCH] bugfix: ARP respond on all devices

[Alan Cox]

On Maw, 2003-08-19 at 13:02, Richard Underwood wrote:
> 	ARP is local to a broadcast net. The ARP standard explicitly
> prohibits responding to an ARP request on a different interface.

Correct, but we don't do that

> 	If you broadcast a request asking for a reply on an entirely
> different subnet, you're asking for trouble. You REDUCE the likelyhood of a
> successful ARP reply, not increase it.

You increase it and you shortcut on shared lans. Thats really a seperate
issue to the question of which source is used. If you loopback someone
elses address on your own lo device I'm not suprised weird shit happens,
put the alias on eth0 where it belongs.

> 	All you can possibly achieve by sending REQUESTS from the wrong IP
> number is assist screwed up networks where you've got multiple subnets on
> the same copper and cause a shed-load of security issues.

Not in general. If you are using ARP your lan is hardly "secure". For
most situations the trust across multiple aggregated lans is the same,
if it isnt people use vlan (which rarely helps 8))

RE: [2.4 PATCH] bugfix: ARP respond on all devices

[Richard Underwood]

David S. Miller wrote:
>
> > _And_ you did not explain so far why these implementations should
> > not be RFC-conform or else illegal.
> 
> Both responding and not responding on all interfaces for ARPs
> is RFC conformant.  This means both Linux and other systems
> are within the rules.
> 
	Firstly, can I point out that you have consistently talked about
REPLIES when everyone else has been talking about REQUESTS. I suspect that
this may be confusing more people than you realise.

	The RFC I quoted (985) says the ARP packets generated by Linux
should be dropped. Sure, the RFC isn't a standard, but there ARE plenty of
implementations that obey it for perfectly valid security reasons.

> Under Linux, by default, IP addresses are owned by the system
> not by interfaces.  This increases the likelyhood of successful
> communication on a subnet.
> 
	This is crap.

	ARP is local to a broadcast net. The ARP standard explicitly
prohibits responding to an ARP request on a different interface.

	If you broadcast a request asking for a reply on an entirely
different subnet, you're asking for trouble. You REDUCE the likelyhood of a
successful ARP reply, not increase it.

	All you can possibly achieve by sending REQUESTS from the wrong IP
number is assist screwed up networks where you've got multiple subnets on
the same copper and cause a shed-load of security issues.

> For scenerios where this doesn't work, we have ways to make the
> kernel behave the way you want it to.
> 
	There are many ways of "fixing" it. I've chosen a static ARP entry
for my next-hop. I really don't care. The issue is that the Linux ARP code
is, apparently by design, flawed.

> There is no discussion about changing the default, because that
> might break things for some people.  So this discussion is pretty
> useless.

	Can you give one good example where this is the case?

	What makes all this worse is that once an ARP request has been
queued using the wrong IP number, further connections that would otherwise
have generated a valid ARP request will be blocked as Linux won't queue a
second request - despite it coming from a different IP number.

	This means that connectivity is non-deterministic, and while
everything may work for 99.9% of the time, when an ARP entry gets deleted
and the next ARP request comes from the wrong IP number you lose
connectivity.

	I wonder how many unsolved random network problems there have been
due to this. "Just reboot it, it'll work again." Great!

	If you insist on leaving the code as it is, at the very least allow
multiple incomplete ARP requests, one per source IP.

	Thanks,

		Richard

Re: [2.4 PATCH] bugfix: ARP respond on all devices

[Julien Oster]

"Carlos Velasco" <carlosev@newipnet.com> writes:

Hello Carlos,

>>I don't deny that it fixes your problem, that is not what
>>we're talking about.  We're talking about how one should
>>fix the problem, and I'm trying to show you why "hidden"
>>patch is not the answer to that.

> Yes, and I'm trying to tell you that it's not the only way to solve it,
> but it is the simpliest way to do it. As I'm sure most of linux users
> that have steped into this "behaviour" think about it.

I can only speak for me, but I think the same.

I'd also like to constate, that not only I see the hidden patch as the
better and easier way, I also think it should not only be in the
standard kernel but also enabled by default.

For the majority of all cases, why should I want the current standard
behaviour? If I have two network cards but each of them on different
segments, I only want the machine to respond to the IP address
attached to the network card on the corresponding segment. If I want
both network cards with different IP adresses on the same segment (for
whatever reason, maybe load balancing), I'll put them both on the same
segment.

There may be reasons why someone wants the current behaviour in
special cases, but I think those cases are so special that you should
need additional configuration tweaks to enable the kernel doing
so. *Not* the other way round.

Regards,
Julien