[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

[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

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

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

[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

[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: [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

[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

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

[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: [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: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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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: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

[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 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 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: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 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

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

[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

[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

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

[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

[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

[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

[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

[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

[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: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

[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

[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

[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]

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

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

[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

[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

[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

[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

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

[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

[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

[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