Jak _opravdu_ zapnout proxy ARP?

[Jan Kasprzak]

	Dobrou noc,

stravil jsem dneska prijemny vecer tim, ze jsem zkoumal proc mi stroj
neodpovida na ARP dotazy jine nez svoji IP adresu - udelal jsem neco
jako

echo 1 >/proc/sys/net/ipv4/conf/eth0/proxy_arp
arp -i eth0 -Ds 10.0.0.5 eth0 pub

a kdyz jsem z jineho stroje v teze siti dal "ping 10.0.0.5", tak se
v ARP cache toho jineho stroje nic neobjevilo a tcpdumpem jsem
videl jen ARP dotaz, ne odpoved.

	Cili otazka zni, jak vlastne opravdu prinutit kernel, aby
poslal proxy ARP odpoved, ma-li v ARP tabulce spravny zaznam?

	Odpoved jsem zjistil az cetbou zdrojaku, konkretne
linux/net/ipv4/arp.c - Linux posila ARP odpoved jen tehdy, kdyz

- je nastaveno 1 v /proc/sys/.../proxy_arp
- k cilove IP adrese ARP dotazu je znama cesta, smerujici do jineho
	interface nez ze ktereho jde ten dotaz.

No a tento druhy bod byl prave kamenem urazu - ja jsem cestu mel
zpet do toho puvodniho rozhrani (resp. nemel jsem ji explicitne
specifikovanou vubec). Smerovaci smycku jsem ale nemel,
protoze zpracovani provozu pro tu danou IP adresu jsem resil pomoci
iptables/nat/PREROUTING.

	No a ted je otazka, co s tim. Podle me by se ta kontrola v kernelu
mela vypnout, protoze je spatne (nepokryva vsechny pripady) nebo udelat
nejake /proc/sys/.../opravdu_chci_posilat_proxy_arp. Protoze jsem nechtel
rekompilovat jadro, nakonec jsem k tem "virtualnim" IP adresam nastavil
cestu pres loopback, coz funguje (a nikdy se nepouzije, protoze DNAT prijde
ke slovu driv).

	Co si o tom myslite? Chova se v tomto kernel rozumne?

-Y.

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/   Czech Linux Homepage: http://www.linux.cz/ |
btw, David, I'm wondering about this loop: [...]  Is this
a busy-wait-until-someone-plugs-in-more-ram-chips thing? ;)  --Andrew Morton