Ale vratme sa k nastaveniu PFka. Ty hovoris, ze riesenim by mohlo byt
nizenie tcp.closed na povadzme 20 sekund z povodnych 90.
Ale podla dokumentacie:
tcp.closed - The state after one endpoint sends an RST.
Tam ale predsa nikto neposiela RST...
Ano, to bola moja chyba, ja mam nastavene aj tcp.closed aj tcp.finwait
na 20 sekund. Videl som v konfiguraku closed a nezamyslal som sa nad
tym, ze to nemusi byt tento.
Podla mna to funguje takto. Server povie klientovi "vezmi si data na
porte XY" a zacne na porte pocuvat. Klient sa pripoji. Prebehne TCP 3W
handshake. Server v cykle zacne data posielat a klient ich prijimat.
Ked server posle vsetko, zavola close() a urobi tzv. aktivny close tj.
posle FIN. Cele sa to dostane do stavu FIN_WAIT_1. Klient posle ACK
pripadne aj s FIN. Tj. spojenie sa moze zavriet v jednom alebo dvoch
krokoch na konci ktorych je ale TIME_WAIT. Ten by mal trvat 2 krat
MSL. MSL je pre FreeBSD defaultne 30 sekund (pozrel som to v sysctl).
Cize 60 sekund by kernel nemal pridelit ten isty port lebo cokolvek co
nan pride z toho isteho paru IP/port (soketu) by mohol byt napr. lost
duplicate.
Ano, malo by to tak byt. Ale mne sa tie iste porty pouzivali. Bol to
problem klienta (u serveru bol port pevny). Stavalo sa mi to u MySQL a
HTTP. Myslim, ze problem je v tom, ze TIME_WAIT nie je na oboch
stranach, ale iba na strane, kto uzatvara spojenie. Ked spojenie
uzatvori server, tak na klientovi nie je TIME_WAIT a ten zdrojovy port
dokaze pouzit skor nez by mal. Otestoval som to teraz cez telnet.
V kazdom pripade ma celkom serie, ze ked som teraz nastavil debug misc
a pustil tail -f na messages tak vsetko chodi :)
No, mozno nie je problem v PF.
Marian
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
