Incorrect ARP response (network)

Dagmar d'Surreal dagmar at
Sat Nov 30 13:19:12 PST 2002

On Sat, 2002-11-30 at 08:18, Sanjuro wrote:
>  > You're not going to like hearing this, but that's the default
>  > behaviour for the 2.4.x kernels
> You're right, from my point of view this is a very strange default 
> behaviour. But according to the Linux kernel doc this behaviour 
> "increases the chance of successful communication". Although I can't 
> think of a situation in which this would apply.

It gets around broken NICs in multiple NIC machines.

>  > Don't do that.  They might also point and laugh at you.  ;)
> Yes, well I thought they might if I had reported it. But I have spend 
> days trying to track down the problem, and i DID use Google. But I 
> couldn't find anything to help me. Now I know what the problem is I know 
> what to search for and now I found some usefull information, but still 
> some things are unclear. But how could I have found this on my own?!? 
> (This doesn't mean that I don't appreciate your help, i do, very much so.)

It initially took me about six hours to find a solution to this problem
myself (when I made my first firewall with a 2.4.x kernel), just because
I'm used to searching for this kind of thing.  Someone not used to
looking for this kind of stuff probably would have found the answer by
asking on a mailing list before finding it in a web search... BUT...
people with search engine skills will typically also search mailing list
archives and find out a lot of things that way, so that it is
occasionally asked about (and winds up in archives to be found later) is
a good thing.

>  > with 2.4.x you do need a patch to change this behaviour
>  > Don't forget to read the little hidden.txt file
> That was very helpfull, it suggested the use of rp_filter and arp_filter 
> for my setup (2 NICs on 1 hub), so I don't even have to apply the patch. 
> I did and everything is working know as -I- expect it too.

You may wind up wanting to apply the patch anyway if that machine is
ever on a network with amateurs who can't/won't keep their private
network traffic to themselves.

> But I fully agree with some other people who posted to other 
> mailinglists (I found them with Google once I knew what to look for) who 
> complained about lack of documentation about this subject.

It drove me nuts at first too, and I *think* the conclusion that I came
to then was that the behaviour apparently satisfies some obscure clause
in an RFC someplace, or was an alternative interpretation of one. 
Frankly, just so long as the behaviour is documented in an RFC someplace
was good enough for me, and even though it is annoying I still hold that
these little hurdles are good for people building firewalls, because if
they _didn't_ take the time to look over every little detail on them,
there'd be a hell of a lot more insecure Linux-based firewalls out
there.  On a machine that's just routing packets between segments with
properly defined netblocks, it all works just fine regardless and
actually does save a few interface hops now and then.

> Thank you for this reply,

Glad to have been of assistance.

Unsubscribe: send email to listar at
and put 'unsubscribe blfs-support' in the subject header of the message

More information about the blfs-support mailing list