[LARTC] Bug in the HOWTO: proxy-arp (?)

[SHuelbrock@Datasystems.de]

Hello alltogether,
I'm new to the list, so please excuse any violations of listiquette...

I didn't have to much to do with linux based firewalling and routing for
quite a time and found that proxy-arp changed in between...

As I struggled with it I found that the Advanced routing... howto wasn't to
helpfull. Especially the documentation seems to be rather vice versa to
what I found out using a 2.4.17 kernel. This is why I'm writing this mail
to the list...
What I wanted the machine to do was to answer with it's own MAC address on
the external Interface if a certain different IP on the network was
ARPrequested. The machine didn't need to route this address because it was
natted.

Cited from the howto (chap 13):
---8<---8<---8<
/proc/sys/net/ipv4/conf/DEV/proxy_arp
If you set this to 1, all other interfaces will respond to arp queries
destined for addresses on this interface. Can be very useful when building
'ip pseudo bridges'. Do take care that your netmasks are very correct
before enabling this!
---8<---8<---8<

I interpret this in a way that if I enable this proxy_arp setting on
(example) eth0 the machine will answer arp requests for the IPs in the
network bound to eth0 on all other interfaces.

What I found out was different (and makes significantly more sense to me):
If I enable proxy_arp on an interface, _this_ interface answers with
proxy-ARPs for all the IP addresses that are in it's local network, that
are routed to other interfaces.
Example:
---8<---8<---8<-
ifconfig eth0 192.168.1.1 netmask 255.255.255.0
ifconfig eth1 172.16.1.1 netmask 255.255.0.0
echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
route add -host 192.168.1.2 gw 172.16.1.2
Then this machine answers ARP requests on eth0 for 192.168.1.2 and
192.168.1.1. (And by the way not for any addresses in the 172.16 network on
eth0 and also not for any addresses in the 192.168.1.0 network on eth1).
---8<---8<---8<---
Maybe I do only get something wrong but in my opinion this is rather the
opposite to what's explained in the howto...

Still another thing I found out is that ip_forward needs to be turned on
for this to work.

Any comments?
Open questions from my side are:
- Why did they change the old behaviour? Ok, a pro for this behaviour is
that it does figure out the right (tm) mac address on it's own so changing
the NIC doesn't result in strange behaviour. But this also worked before
with "arp -Ds 192.168.1.2 eth0 pub".
- How do I proxy ARP for _another_ MAC address? Imagine a veryvery stupid
device in the network that can't do ARP itself although it has a MAC
address and should receive IP packets. I know of at least one device that's
produced today that's that stupid. So there needs to be someone in the
network that answers ARPs as a proxy for this device with the MAC for the
device. I found no solution to configure this with Linux.

Anyhow this new behaviour seems to be not overly the "unixway" to do
things... (ok I'm a traditionalist and that's no reason not to change
things).

Enough whining.
Thanks for the patience
Stefan


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/