Igazabol errol lenne szo http://hup.hu/node/65299, csak lehet, hogy rossz temakorben irtam elsore...
Kerdes az, hogy van-e linux alatt olyan tool, amivel ki lehet deriteni, hogy miert kuldi a FIN,ACK-et latszolag indokolatlanul?
- 1775 megtekintés
Hozzászólások
Esetleg egy masik szal zarja a kapcsolatot ? Hogy nezted strace-el ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Az sctrace-t -ff kapcsoloval inditottam, es elvileg kulon pid szerint mentette fajlba a kimenetet. Viszont nem talaltam, csak egy fajlt...
- A hozzászóláshoz be kell jelentkezni
A FIN nem jelenti a kapcsolat lezárását, hanem csak azt, hogy a küldőnek már több küldeni valója nem lesz. Ezt az állapotot hívják félig lezárásnak is. Attól még adatot fogadni tud. Egy kapcsolat (ideális esetben) akkor van lezárva, ha mindkét fél küldött FIN-t.
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
Ez rendben is lenne, de a szerver valaszol egy ACK-el erre a FIN-re es amikor jon az adat tole (par masodpercel kesobb), akkor a kliens mar egy RST-el valaszol ra, amire FIN, ACK-et kap vissza.
Igy zajlik a folyamat:
|Ido | kliens | szerver |
|806057,856| SYN | |Seq = 0 Ack = 3403829159
| |(43115) ------------------> (80) |
|806057,889| SYN, ACK | |Seq = 0 Ack = 1
| |(43115) <------------------ (80) |
|806057,890| ACK | |Seq = 1 Ack = 1
| |(43115) ------------------> (80) |
|806057,893| PSH, ACK - Len: 860 |Seq = 1 Ack = 1
| |(43115) ------------------> (80) |
|806058,153| ACK | |Seq = 1 Ack = 861
| |(43115) <------------------ (80) |
|806058,619| FIN, ACK | |Seq = 861 Ack = 1
| |(43115) ------------------> (80) |
|806058,653| ACK | |Seq = 1 Ack = 862
| |(43115) <------------------ (80) |
|806093,237| PSH, ACK - Len: 613 |Seq = 1 Ack = 862
| |(43115) <------------------ (80) |
|806093,237| RST | |Seq = 862 Ack = 3403829159
| |(43115) ------------------> (80) |
|806093,237| FIN, ACK | |Seq = 614 Ack = 862
| |(43115) <------------------ (80) |
Egyebkent, ha minden rendben zajlik, akkor a kliens nem kuld FIN-t...
Es az egesz azert erdekes, mert reprodukalni nem tudom, viszont idonkent "magatol" is jol mukodik.
- A hozzászóláshoz be kell jelentkezni
Hali!
Nem olvastam végig a problémát, csak a hozzászólásokat.
Az ethereal, vagy mostanában wireshark-nak nevezett programmal elég jól tudod analizálni a csomagokat, esetleg érdemes megpróbálnod.
Egyébként ha hol jó, hol nem, akkor főként a hálózat fizikai értelmében keresném a hibát. Kábelek, hálózati eszközök, legutolsó sorban az a két eszköz, amit használsz. Az egészben az RST csomag fura, ha jól látom... Esetlegesen hálózati TTL időtúllépés lehet a háttérben.
URL: http://reznor.dyndns.org
skype: reznorbaa
mail
Os: OpenSuse 11.0, meg minden amit érek az Ecomstation-t is beleértve. Szeretem az oprendszereket.
- A hozzászóláshoz be kell jelentkezni
A fenti reszt a wireshark-bol mentettem ki...
Az a baj, hogy ezzel csak azt latom, hogy mit kuld, de azt sajnos nem, hogy miert. Arra lennek kivancsi - amint mar korabban is irtam, hogy letezik-e linux alatt olyan tool, amivel ki tudom deriteni, hogy egy progra miert kuld FIN,ACK--et, amikor latszolag semmi alapja nincs ra.
Elkepzelheto halozati problema, de a helyzet az, hogy mas halozati kapcsolatnal nem fordul elo semmilyen megszakadas. De azt meg kiprobalom, hogy folyamatosan ping-elem a kliensrol a szervert, es megnezem, hogy mi tortenik... Viszont az eredmenyre varni kell, mert a hibat nem tudom reprodukalni.
Igazad lehet a TTL-el kapcsolatban, megprobalom mas oldalrol megkozeliteni a dolgot...
- A hozzászóláshoz be kell jelentkezni
Mert a felhasználó meggondolta magát, és mégsem akarja megnézni az oldaladat. Lenyomta a Home gombot, erre a borzoló program gyorsan lezárta a kapcsolatot, a választ meg sem várva.
- A hozzászóláshoz be kell jelentkezni
Az ignore_user_abort() függvényt próbáld meg használni, hogy akkor is ez a jelenség áll-e fönt (plusz nézd meg a timeout értékeket a PHP configban).
- A hozzászóláshoz be kell jelentkezni