Discussion fucking closed WAS(Re: [2.4 PATCH] bugfix: ARP respondon all devices

From: jamal
Date: Tue Aug 19 2003 - 15:47:26 EST




Ok, go ahead and call my mama - tell her i used a bad word on a mailing
list.
Folks, this is a actually a republic model: in other words its a
democracy upto a certain level then there maybe a veto.
You have been provided a facility to go and do what funky thing that
pleases you. Use ARPTABLEs; if you dont like it maintain your own
patches - you have that freedom; dont enforce your freedom on someone
actually doing the maintanace work - they have more important things to
worry about.

You can quote all the RFCs you want - it wont change anything soon. I
got tired of following same cyclic arguements. What Linux is doing is
conformant. What other people following CISCO are doing is also
conformant. RFCs are written in an ambigous language called english.
People actually (lately anyways) sneak in ambiguity to make their
implementation look correct. So please stop quoting stoopid RFCs.

cheers,
jamal

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/