[lkml]   [2003]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [2.4 PATCH] bugfix: ARP respond on all devices
On 19 Aug 2003 20:08:20 +0100
Alan Cox <> wrote:

> > But if I was to do this in the other direction (arp -d;
> > ping -I then I'd lose connectivity over my default
> > route because won't accept ARP packets from IP numbers not on
> > the connected subnet. The <incomplete> ARP entry will block any further ARP
> > requests from valid IP numbers.
> One thing I agree with you about is that an ARP resolution for an
> address via one path should not block a resolution for it by another
> path since to begin with the two paths may be to different routers
> one of which is down.

Sounds logical.

Can you explain to me why there should be a difference in the source ip of an
arp request originated by an ip packet from another address of the same host
compared to a forwarded packet from another host, coming in on some secondary
If I understood David correctly the first case will do an arp request with
source ip equal to source ip of the packet (originated locally).
In the second case (the box has to forward some foreign packet) for sure its
interface address will be used, correct? Or does that read: _some_ interface
address will be used?
Why this difference? The destination host cannot distinguish between these two
cases, so they can be as well handled just the same. But it seems obvious that
a foreign IP cannot be used as a source for an arp request.
And overall, looking at an arp table, what is visible is: interface, MAC and
corresponding IP. So as soon as an arp request is successfully completed the
box doesn't even remember the source ip of the former arp request, right?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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