RE: Bug with ARP - request source address on wrong subnet

From: Richard Underwood (richard@aspectgroup.co.uk)
Date: Fri Aug 15 2003 - 08:34:30 EST


David S. Miller wrote:
>
> This is pretty irrelevant. If I were to change the behavior
> then every who expects what we do now will break.
>
Can you give me one example when this works at all in the first
place?

> It has everything to do with your routes and the 'ip' command.
> 'arp_filter' works by looking at the route it would use to get
> from src to dst, and if it would go out this particular interface
> where we heard the ARP it sends the response out, else it does
> not respond.
>
Again, you're talking about ARP responses, I'm talking about ARP
requests. Entirely different packets altogether.

The problem is that the ARP *request* being generated by Linux is
from an IP number that isn't on the subnet it's being transmitted on.

11:23:55.650514 0:4:75:ca:c4:ef Broadcast arp 42: arp who-has 10.10.10.1
tell 212.xxx.yyy.9

... 10.10.10.1 receives the ARP request, how does it reply? It may
not even have an interface on the 212.xxx.yyy network! Sure, it could just
reply to the source ethernet address, but I'd hope that a router would do
some level of sanity-checking!

Should it add an ARP cache entry for the 212.xxx.yyy.9 address into
its cache for the 10.10.10 network? No! It's dropped, as is suggested in
RFC985: "An ARP request is discarded if the source IP address is not in the
same subnet."

I could understand what you're saying if I had two interfaces on the
SAME network, and I wanted the ARP replies to go out of the appropriate
interfaces ... but I've got two interfaces on different subnets, and I'm
talking about ARP requests, NOT replies.

Thanks,

Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html