Mellékelek tcpdumpot és a logfájlt 15-ös szinttel, sajna két külön mérés, de a lényeget ez egyáltalán nem befolyásolja amennyire látom. A folyam mindig máshol szakad meg, ha gyorsan bír menni az adat a szerverről, akkor azt hiszem kevésbé, van, hogy végigmegy. Ami érdekes, az az alábbi, ami mutatja, hogy a zorp "data line" sorai szépen tartanak a </html> részig. Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/server): data line: 6D 6C 3E 0A 0A ml>.. Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): Writing channel; fd='15', count='85' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 63 3D 31 22 20 77 69 64 74 68 3D 22 31 22 20 68 c=1" width="1" h Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 65 69 67 68 74 3D 22 31 22 3E 0A 3C 2F 4E 4F 53 eight="1">.</NOS Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 43 52 49 50 54 3E 0A 3C 21 2D 2D 20 4D 45 44 49 CRIPT>.<!-- MEDI Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 41 4E 20 57 45 42 41 55 44 49 54 20 45 4E 44 20 AN WEBAUDIT END Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 2D 2D 3E 0A 3C 2F 62 6F 64 79 3E 0A 3C 2F 68 74 -->.</body>.</ht Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 6D 6C 3E 0A 0A ml>.. Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/server): Reading channel; fd='18', count='0' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): eofmask updated; old_mask='0006', eof_mask='003f' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): exiting keep-alive loop; Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): calling __shutdown__() event; Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): calling shutDown() event; Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): calling __destroy__() event; Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): Proxy destroy; class='InHttp', module='http' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): Shutdown channel; fd='15', mode='2' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): Closing channel; fd='15' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/server): Shutdown channel; fd='18', mode='2' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/server): Closing channel; fd='18' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): Proxy ending; class='InHttp', module='http' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0): Ending proxy instance; a belso tcpdump rész így talán lényegtelen is, a fontos, hogy az adat a zorpig megjön. ellenben ekkor ugye a belso lezárja a kapcsolatot: 00:09:44.327607 0:4:75:cf:df:8d 0:d0:b7:b7:7a:75 0800 54: 1.2.3.4.49820 > 10.1.6.1.80: . ack 28371 win 35040 (DF) 00:09:44.418416 0:d0:b7:b7:7a:75 0:4:75:cf:df:8d 0800 60: 10.1.6.1.80 > 1.2.3.4.49820: F 28371:28371(0) ack 4116 win 64993 (DF) 00:09:44.457643 0:4:75:cf:df:8d 0:d0:b7:b7:7a:75 0800 54: 1.2.3.4.49820 > 10.1.6.1.80: . ack 28372 win 40880 (DF) 00:09:44.682136 0:4:75:cf:df:8d 0:d0:b7:b7:7a:75 0800 54: 1.2.3.4.49820 > 10.1.6.1.80: F 4116:4116(0) ack 28372 win 40880 (DF) 00:09:44.682228 0:d0:b7:b7:7a:75 0:4:75:cf:df:8d 0800 60: 10.1.6.1.80 > 1.2.3.4.49820: . ack 4117 win 64993 (DF) és kb ugyenkkor, .68-kor a külső kapcsolat is változik, megkapja a maga R flagjét, és mig bent kb. 28kb ment át addig kifele már csak a 20k megy át. 00:09:44.574709 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 1514: 195.228.75.150.80 > 1.2.3.4.2529: . 19189:20649(1460) ack 4118 win 14600 (DF) 00:09:44.681853 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 20649:20649(0) ack 4118 win 14600 (DF) 00:09:44.720159 0:d0:2:e0:47:fc 0:d0:b7:89:4f:95 0800 60: 1.2.3.4.2529 > 195.228.75.150.80: . ack 14649 win 6000 (DF) 00:09:44.720268 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 1163771020:1163771020(0) win 0 (DF) 00:09:44.720231 0:d0:2:e0:47:fc 0:d0:b7:89:4f:95 0800 60: 1.2.3.4.2529 > 195.228.75.150.80: . ack 16109 win 6000 (DF) 00:09:44.720303 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 1163772480:1163772480(0) win 0 (DF) 00:09:44.720417 0:d0:2:e0:47:fc 0:d0:b7:89:4f:95 0800 60: 1.2.3.4.2529 > 195.228.75.150.80: . ack 17569 win 6000 (DF) 00:09:44.720442 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 1163773940:1163773940(0) win 0 (DF) 00:09:44.720465 0:d0:2:e0:47:fc 0:d0:b7:89:4f:95 0800 60: 1.2.3.4.2529 > 195.228.75.150.80: . ack 19029 win 6000 (DF) 00:09:44.720489 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 1163775400:1163775400(0) win 0 (DF) 00:09:44.728346 0:d0:2:e0:47:fc 0:d0:b7:89:4f:95 0800 60: 1.2.3.4.2529 > 195.228.75.150.80: . ack 20649 win 6000 (DF) 00:09:44.728372 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 1163777020:1163777020(0) win 0 (DF) Próbáltam a window scaling mindkét oldali kikapcoslását, de az nem segített, hasonló módon a zorpos gép tcp paramétereinek állítgatása sem hozott jelentős változásokat. egyébként 2.4.27 + patchek, pl. grsecurity, tproxy amiben ugye lehetnek patch-összefüggések is. Mindenesetre ha van ötletetek ezalapján, örömmel veszem. -------------------------------- Bencsath Boldizsar boldi@mail2003.etl.hu -------------------------------- On Wed, 25 Aug 2004, Major Csaba wrote:
On Mon, 2004-08-09 at 15:12, Bencsath Boldizsar wrote:
A kovetkezo erdekes hibajelenseg tortenik mostanaban, egy olyan gepen ahol korabban is zorp (GPL) volt, a hiba nem tudom, volt-e korabban is. Tehat:
Ha a user post metodussal kuldd dolgokat, akkor csak bizonyos felhasznaloknak, de azoknak tobbnyire, megszakad a letoltott adat. Konkretan:
Kene rola legalabb 7-es loglevelen logreszlet az adott kapcsolatrol, illetve teljes tcpdump a tuzfal kulso es belso laban is!
MCS