Hello, On Tue, 18 Mar 2003, Arno Griffioen wrote: > > requests with src 17.70.0.1? Linux ARP follows the routing and will > > reply in this case (when used in place of the router). > > Yes that's true. Unfortunately it seems that Linux is one of the few > who implement this behaviour. Others seem to hold the view that > ARP is a link-level protocol and as such only has any relevance for > the scope defined on the interface itself. Hm, may be yes > So even though it's technically possible and legal to do so according > to the RFC, it's unfortunately not often used in practice.. The RFC does not recommend when to reply and it allows implementations with different behavior. > > to handle such case. The problem comes only if "router decides not > > to accept ARP from valid source IP from valid input device". > > Which seems to cover almost all dedicated routers (eg. Cisco) and probably > quite a few other OS'es too. Argh, I didn't tried with other OSes. The replies are unicast at link layer so I wonder why one should care what is the src IP if it passes the source address validation. > > Take a look at arp_solicit() > > Saw that.. I'll mangle it a bit so it will only send out the > link address. That way it's compatible with what other devices expect. If you like the idea of patching I have the exact patch for you: http://www.ssi.bg/~ja/01_arp_prefsrc-2.4.12-5.diff from http://www.ssi.bg/~ja/#routes Note that arp_prefsrc will work for your setup but it is not entirely correct for all users, the plain kernel has the correct behavior. Then playing with iparp can give you the desired behavior for the interfaces and gateways you want: http://www.ssi.bg/~ja/#iparp ip arp add table output from 17.70.0.1 src 0 Regards -- Julian Anastasov <ja@xxxxxx>
