Incorrect ARP response (network)
sanjuroe at xs4all.nl
Sat Nov 30 06:18:33 PST 2002
> 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.
> 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.)
> 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.
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.
Thank you for this reply,
Dagmar d'Surreal wrote:
> On Fri, 2002-11-29 at 04:09, Sanjuro wrote:
>>So both cards are responding to an IP that is attached to only one of
>>them. This behaviour is the same in kernel 2.4.19 and 2.4.20. This is a
>>problem because depending on which one arrives first Windows send
>>network traffic to the wrong network card, which happens to be blocked
>>using iptables resulting in a loss of connection.
>>My question: What could I have possible to get the kernel to do this? Is
>>it possible I compiled a strange options into the kernel? I am not
>>setting any kernel parameters at run-time or a boot time, so that can't
> You're not going to like hearing this, but that's the default (and
> considered "normal") behaviour for the 2.4.x kernels--to respond to ARP
> queries for all it's addressses on any interface.
>>I have tried everything else, if no-one can think of something that
>>might causing this I think I will file a bug report with the Realtek
>>kernel driver maintainer.
> Don't do that. It's not their responsibility. They might also point
> and laugh at you. ;)
> If you were running a 2.2.x kernel, this wouldn't be necessary but since
> the mechanism has been changed around somewhat with 2.4.x you do need a
> patch to change this behaviour (which can be more than just a little
> annoying when you're trying to set up a firewall and lamers outside your
> private network are leaking private network addresses that match
> yours--well, annoying for _them_ anyway). You could hop over to Google
> and punch in "linux 2.4 hidden patch" or you could just cut to the chase
> and go straight to http://www.linux-vs.org/~julian/#hidden. Don't
> forget to read the little hidden.txt file listed on that page which
> explains a little more about what's going on and what (little) you need
> to do once you've applied the patch and rebuilt your kernel.
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message
More information about the blfs-support