Mrznuce FTP

[Marian Cerny]

> 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