2003-06-12, cs keltezéssel Balazs Scheidler ezt írta:
valami race condition-t sejtek, ugyanis ez azt jelenti, hogy a TPROXY jelenleg ket olyan socketet lat, aminek ugyanaz a local cime.
ez szerintem akkor kepzelheto el, ha 1) preemptiv kernel patched 2) vagy tobb procid van
Egyik sem. Gyári 2.4.20 + rsbac + xfs + freeswan + tproxy.
mivel a TPROXY a socket lezarasanak vegen veszi ki a sajat hashebol a socket cimet, ezert elofordulhat az, hogy a socket mar kikerult a TCP-s socket hashbol, de meg nem torlodott a TPROXY-s hashbol, kozben viszont egy masik thread mar bindolta (sikeresen, hiszen a TCP hashben mar nincs bent), es probalt ra IP_TPROXY_ASSIGN-t hivni.
Ez mondjuk azert eleg nehezen valosul meg, plane mivel a socketek lezaras utan egy darabig TIME_WAIT-ben maradnak (kb 2 perc)
raadasul az autobind sorban egymas utan veszi a portokat, tehat ehhez az is kell, hogy az osszes port foglalt legyen a local port range tartomanyban.
ez szinte lehetetlen. a local port range defaultbol 32768-61000 (2.4-es kernelen) itt most a 47832-es portrol van szo.
hany nyitott socketed van az autobind-ip -re bindolva?
Ezt hogyan számolom meg egyszerűen? Annyi adalék még, hogy két hejről jöhet kapcsolat. Az egyik internetről bárhonnan, de az nem sok, a másik egy konkrét proxy (Squid), utóbbi sok. Erre mondtam, hogy összesen átlag 150-180 Zorp thread-et számolok egyidőben. A Zorp ezt két tűzfalon is csinálja, melyek egymás után vanak, de egymástól függetlenül jön a jelenség. Az egyiken a Zorp két instance-al megy (internet és dmz felé 1-1). A dmz felől van 1 IP-ről minden kapcsolat. Ez a Zorp threads 200-al fut instance-onként, míg a másik Zorp melyhez az elsőn át vezet az út threads 400-al fut. A hiba utóbbin gyakoribb. Slapic -- Pilatus-Comp Ltd. HUNGARY * The Linux Expert * pilatuscomp@linux.co.hu http://www.linux.co.hu * Phone: +36-1-2481816 * Fax: +36-1-2481817