lkml.org 
[lkml]   [2003]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [2.4 PATCH] bugfix: ARP respond on all devices
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.
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.100 / U:3.976 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site