Thread (77 messages) 77 messages, 18 authors, 2003-08-20

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

From: David S. Miller <hidden>
Date: 2003-07-28 01:24:28
Also in: lkml

On Mon, 28 Jul 2003 03:23:02 +0200
"Carlos Velasco" [off-list ref] wrote:
On 27/07/2003 at 17:55 David S. Miller wrote:
quoted
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.
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help