Can''t get proxy arp with arp -s <IPaddr> <MACaddr> pub to work with a 2.4 kernel. I see some evidence in the archive that this was broken in the 2.0.x timeframe and never fixed. Anyone know for sure if it''s broken or working ? (I''m attempting to route a few addresses into a routed network, from the ethernet side of a DSL router that has a /29 public subnet). The proxy_arp flag thing won''t help because the destination subnet is not on any of the ethernet interfaces on the router machine (it''s off a few hops distant in the middle of our network). Thanks! _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
David Boreham wrote:> > Can''t get proxy arp with arp -s <IPaddr> <MACaddr> pub > to work with a 2.4 kernel. I see some evidence in the archive > that this was broken in the 2.0.x timeframe and never fixed. > > Anyone know for sure if it''s broken or working ?It is working if you don''t try to pass a MAC: arp -s IPADDRESS -i INTERFACE -D INTERFACE pub To delete: arp -d IPADDRESS -i INTERFACE pub http://linux-ip.net/html/scripts/proxy-arp With a proper ip route, it is probably not necessary:> NS="206.XXX.89.158/32" > GW="206.XXX.89.153" > BRD="206.XXX.89.159" > YIC="206.XXX.89.154/32" > NEWS="206.XXX.89.155/32" > SON="206.XXX.89.156/32" > NOP="206.XXX.89.157/32" > IFI="eth0" > IFE="eth1" > IPNS="206.72.XXX.158" > ifconfig lo 127.0.0.1 > route add -net 127.0.0.0 netmask 255.0.0.0 lo > /etc/rc.d/rc.netdevice > ip link set dev $IFE up > ip address add dev $IFE local $NS broadcast $BRD > ip link set dev $IFI up > ip address add dev $IFI local $NS broadcast $BRD > > ip route add $YIC dev $IFI src $IPNS > ip route add $NEWS dev $IFI src $IPNS > ip route add $SON dev $IFI src $IPNS > ip route add $NOP dev $IFI src $IPNS > ip route add $GW dev $IFE src $IPNS > ip route add 0/0 via $GW dev $IFE src $IPNS > > # we want proxyARP: > echo 1 >/proc/sys/net/ipv4/conf/$IFE/proxy_arp > echo 1 >/proc/sys/net/ipv4/conf/$IFI/proxy_arp > > # turn on ip forwarding > echo 1 >/proc/sys/net/ipv4/ip_forward > > # Decide what to do about rp_filter. > # turn on antispoofing protection > #Off 23Oct04 for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 >$f; donegypsy _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> Anyone know for sure if it''s broken or working ?Well I finally made this work, so the answer is that it does indeed work. I will post some information in the hope that future generations may be retain their hair: There seem to be a number of preconditions that must be met before the arp...pub form of proxy arp will work. If these conditions are not met the kernel silently fails to answer the arp request (as oposed to for example the user seeing an error message when they run the user-space program). First, the /proc/sys/net/ipv4/conf/<dev>/proxy_arp must be enabled on the interface where you desire arp responses to be sent. Second, the address that you want to proxy arp must _not_ be arp-able on the interface that you want the arp response to be sent from (i.e. you can''t proxy arp addresses that are in a subnet assigned to the interface). This means that if you do want to proxy addresses from a subnet that also contains the address of the interface, then you need to either a) use some other address for the interface but assign the address from the subnet to the loopback interface or b) assign a point-to-point /32 address to the interface. In both cases you also need to insert a route for any host you want to talk to on that subnet (in my case the DSL router), because that host won''t be arp-able once you fix your addresses such that proxy arp functions. Third, the address that you are attempting to proxy must be routable from the host. The kernel''s definition of ''routable'' appears to be a little more complicated than might be imagined. For example in my case I did have a route (and I could even ping the host successfully), however I also had two route tables. For some reason the kernel refused to answer the arp request unless I put a route in the second route table (possibly because the arp request has a source IP address that if the kernel had been planning to route it, would have consulted the second route table). So perhaps the necessary condition is ''have a route from the arping node''s IP address to the proxied address ? After three days battling this, I am certain that something is broken : perhaps the ioctl() call should fail if the arp response wouldn''t be sent, or perhaps arp -e|a should tell the user that no arp response will be generated or perhaps the kernel shouldn''t be so picky about when and if it will respond to an arp request (after all, anyone messing around with proxy arp presumably knows what they are doing??). And surely the documentation could be improved. I plan to do all these things in a parallel universe where I have sufficient free time... _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
David Boreham wrote:> Can''t get proxy arp with arp -s <IPaddr> <MACaddr> pub > to work with a 2.4 kernel. I see some evidence in the archive > that this was broken in the 2.0.x timeframe and never fixed. > > Anyone know for sure if it''s broken or working ?Hello, this works for me in linux 2.0, 2.2 and 2.4 (2.6 not tested, probably works too): arp -i eth0 -Ds 1.2.3.4 eth0 pub i.e. answer arp requests for 1.2.3.4 comming to eth0 and put the hw address of eth0 into the answer HTH, -- Martin _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
David Boreham wrote: ...> There seem to be a number of preconditions that > must be met before the arp...pub form of proxy arp > will work. If these conditions are not met the kernel > silently fails to answer the arp request (as oposed to > for example the user seeing an error message when > they run the user-space program). > > First, the /proc/sys/net/ipv4/conf/<dev>/proxy_arp > must be enabled on the interface where you desire > arp responses to be sent.... I don''t have this enabled and the syntax "arp -i eth0 -Ds 1.2.3.4 eth0 pub" is working as expected. With /proc/.../proxy_arp enabled it seems that linux answers arp request for all ip addresses, which are routed to other interfaces, e.g. with this routing table: 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0 it answers arp request on eth1 for _all_ foreign ip addresses except 192.168.1.0/24. I saw it once, when a machine with ms windows was trying to find out its ip address from dhcp server, which I didn''t have. It didn''t get any and was trying to find unused one from the subnet 169.254.0.0/16 (link local addresses, RFC 3330) - it didn''t succeed, because my linux router, which had /proc/.../proxy_arp enabled, answered all arp requests for this subnet... -- Martin _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> I don''t have this enabled and the syntax "arp -i eth0 -Ds 1.2.3.4 eth0 > pub" is > working as expected.Interesting. It may be that I became confused about this in my random flailings. I''m doing this on a production router so I don''t have much potential to experiment. I''ll try disabling proxy_arp and see what happens...> With /proc/.../proxy_arp enabled it seems that linux answers arp request > for all ip addresses, which are routed to other interfaces, e.g. with this > routing table:Yes, your text would make a worthy addition to the existing ''howto'' (which is rather lacking in clarity). _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/