nespolehlivy prenos pres netcat (DELSI)

[Pavel Kankovsky]

On Thu, 23 Sep 2004, oldfrog.linux na volny.cz wrote:

> setsockopt(3, SOL_SOCKET, SO_LINGER, {onoff=1, linger=0}, 8) = 0

To je takove dost brutalni nastaveni, ale melo by to ovlivnovat jen
chovani pri zavirani socketu. Navic ten fungujici to podle vypisu
z strace dela taky, takze tim to nebude. Tedy presneji receno to
bude slozitejsi.

> Myslite primo odsnifovat posilane pakety? To jsem nikdy nedelal, co
> navrhujete pouzit za soft? Me stacil vzdycky tcpdump. Ten si muzete
> v pripade zajmu prohlednout na

Jo, klidne tcpdump. I kdyz byva lepsi pouzit -w a ulozit pakety
v neprechroustanem tvaru.

Nicmene i z toho, co jste vystavil lze neco zjistit. Zda se, ze zatimco
v tom fungujicim pripade mame vicemene pravidelny ping-pong dat s PSH
v segmentech velikosti 256 a nekdy 512 nebo 768 bajtu a acknowledgementu,
v nefungujicim pripade zacne vysilac zurive tlacit data v segmentech
maximalni velikosti, vesmes bez PSH, a po nejake dobe ziska znacny naskok
pred prijimacem, ktery mu potvrzeni posila s pomerne velkym zpozdenim
(treba i pul sekundy, coz uz je zatracene hodne).

Tato zmena v chovani je opravdu pozoruhodna az podezrela, protoze afaict
podporena zadnou zmenou v chovani procesu.

Ten prvni reset ze strany vysilajiciho se zda byt celkem nevyprovokovany,
akorat mu prave predchazi jedna z tech delsich prodlev, kdy prijimac
neodpovida a pak najednou leti RST. Trochu zvlastni je, ze ma na sobe
timestamp, protoze do RST se afaik zadne opsny davat nemaji.

Mozne vysvetleni je, ze treba behem te prodlevy vysilaci netcat zavrel
spojeni (na drate se objevila jen cast dat, protoze zbytek porad jeste
visel v bufferech na vysilaci) a kvuli nulovemu lingeru nebyl vysilac
ochoten cekat na opozdena potvrzeni a spojeni sestrelil. Zkusil jste to
s tim nc -l -p port -e 'cat soubor; sleep ...'?

Pak to ma jeste takove zvlastni pokracovani, kdy behem asi 4 ms jeste
chodi zpozdila potvrzeni od vysilace a prijimac po nich strili dalsimi
resety. Coz je opravdu podivne, protoze v okamziku, kdy vysilac dostane
prvni reset, tak by mel prestat okamzite vysilat. Ty vypada, ze je mezi
nimi nejaka dlouha roura, ve ktere muze byt najednou vetsi mnozstvi paketu
"en route". Jak jsou vybec ty pocitace propojeny?


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."