On 16 Jul 2002, Daniel Gryniewicz wrote:
> Okay, I have no problem with this. What I have a problem with is Linux
> sending an ARP request out an interface and using the address of
Please apply rp_filter_mask and be happy :) By this way
you can safely use rp_filter with hubs if that is your problem.
> *another interface* as the tell address. This is just broken.
From routing perspective it is not broken: ARP request is
built from data approved from routing and extracted from the
IP packet. If you provide different sender IP in the ARP request
you risk this probe to be answered on another target host's interface,
i.e. the remote host can answer it on eth0 and then our IP packet (with
different src IP) will be dropped on this device if it is allowed
on eth1 and the rp_filter_mask I mentioned in previous mail is not
supported/set (and it is usually not). This happens if the remote host
has 2 devices attached to the same hub we are connected and in such
case it usually accept one ARP probe on one interface (eth*/rp_filter=1).
This is the reason Linux ARP to use addresses from the IP packets.
You must not break this rule or you risk problems. Do you see the
symmetry? If you lie in your ARP probe then you can receive wrong MAC for
that target. Note that we resolve the path (SRCIP->DSTIP), not only DSTIP.
We ask "where should I send traffic from SRCIP to DSTIP?". The
question "where is DSTIP" is too ambiguous, you risk to receive
wrong answer (as usually happens). This is not mentioned in RFC826.
Nor the word "hub" :)
Again, you are welcome on linux-net where we can find solution for
every setup which involves Linux ARP :)
Regards
-- Julian Anastasov <ja@ssi.bg>- 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/