prerusovane stahovani fbsd5.4/apache2 [tcpdump]

[Dan Lukes]

Divacky Roman wrote:
>>	Zajimal me zaver te failujici TCP session - to ze session closed 
>>	jeste nerika jakym ze zpuzobu (na TCP urovni) byla 'closed' ...

>>	Treba se nekdo pokousi rozfungovat transparentni proxy nebo nejaky 
>>stavovy firewall ...
> 
> je to dost divne.. pac po nejake dobe (a mam nechutny pocit ze to je vzdycky
> chvilku pote co zapnu/vypnu tcpdump) to zacne fungovat normalne...

	TCPDUMP by nemel mit vliv na nic, pokud je je pouzit '-p' option. V 
opacnem pripade, samozrejme, promiskuitni mod muze ovlivnit beh veci - i 
kdyz - v tomto pripade bych to spis neocekaval.

> cely log (ktery zahrnuje nekolik tech zavreni) je na hysteria.sk/~neologism/log

	Technicka poznamka:

	Textovy LOG ma tu nestastnou vlastnost, ze se nad nim uz tezko pousteji 
jakekoliv filtry. Daleko snazsi je analyzovat to, co tcpdump ulozi do 
souboru (-w) v binarnim tvaru. Ostatne, kdyz budu chtit tvar textovy, z 
binarniho si to prevedu snadno.


	Nicmene, k veci. Soustredil jsem se na jednu session (nemam jak poznat, 
jestli je to nejaka "failujici" takze budu automaticky predpokladat, ze 
ano). Konkretne
r79s17p21.home.nbox.cz.63669 <=> hudson.mzm.cz.http
Ta zacala 10:02:55 a prvni pokus o ukonceni nastal 10:03:04.422655, po 
preneseni byte 962930 a ukonceni spojeni inicioval HTTP server.

	Pravda je, ze kvuli nejakym poztracenym paketum bylo fakticky spojeni 
ze strany uzavreno az 10:03:05.218978 (ktere uz klient obratem potvrdil) 
ale to neni pro nasi vec az tak podstatne.

	Klicove je, ze 'session closed' vzniklo na zaklade udalosti na siti - a 
jevi se, ze na zaklade udalosti na serveru.

	Bohuzel, zachyceny LOG podle vseho neobsahuje kompletni zaznam zadne 
jine session, tim mene obdobne session s jinym serverem - a na vzorku 
velikosti jedna se tezko delaji nejake statisticke analyzy.

	V kazdem pripade, ja navrhuji vyzkouset, zda se obobny problem 
vyskytuje pri komunikaci s jinymi servery - pokud ne, zameril bych se na 
tento konkretni server. Pokud ano, pak zjistit, jestli problem nastava 
pri prenosech velkych dat s jakymkoliv severem. Pokud ne, zjistit, co 
maji spolecneho ty, se kterymi problem nastava (software, cast sitove 
cesty a pod.). Pokud ano, je treba takove spojeni ucinit proti serveru, 
nad kterym mam kontriolu alespon takovou, ze na nem mohu spustit tcpdump 
take. Oba je pak treba porovnat - tim se zjisti, zda je spojeni skutecne 
prime, nebo zda pravdepodobny vyskyt transparentni proxy ci neceho 
jineho podobneho po ceste.

	No a pak by se dalek postupovalo podle toho, co by se zjistilo ...

						Dan


P.S. Pripominam, ze bych rad odkaz na tu zajimavou statistiku, o ktere 
jsme mluvili ...